Danny McPherson | 1 Oct 02:56 2002
Picon

WG Last Call: PWE3 Requirements


Folks,
Please consider this the start of the WG Last Call for the 
PWE3 Requirements document.  Comments on the draft should be
sent to pwe3 <at> ietf.org, or the authors directly.

The document can be obtained via:  

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-requirements-03.txt

The last call ends Oct 15  <at> 12P GMT.

Thanks!

-danny
Stewart Bryant | 2 Oct 12:52 2002
Picon

draft-bryant-pwe3-terms-00.txt

At IETF-54 it was agreed that a single PWE3 terminology document
would be generated defining common terms. My understanding is that
PWE3 authors would then remove these common terms from their drafts
thereby removing any conflicting definitions.

I have derived these terms from a combination of the protocol-
layering draft and the framework draft.

This has been posted as <draft-bryant-pwe3-terms-00.txt>.

I plan to put out a revised version before IETF-55, that will include
feedback received.

Stewart
Dave Danenberg | 2 Oct 15:33 2002

Collection of CEP MIB change requests

The list below represents the set of change requests received from pwe3 members wrt the CEP MIB. See http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cep-mib-00.txt

The 3 requests below are not required to go in together. So reply with individual comments, if you would
like. Also, feel free to reply with any new requests.

If there is rough consensus (or absence of comment) on any of the following, the co-authors will submit a new
version: cep-mib-01.

-----------------------

1) Support for SONET-VT emulation work underway in PWE3.

This includes generalizing the main CEP table to handle single VT mode, and adding an optional table for
configuring fractional SPE. See http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-vt-00.txt

2) Support for RTP.

Add an object to CEP config table (pwVcCepCfgTable) to specify whether RTP header is suppressed or not.
This is per http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-00.txt

3) Remove "Jitter Buffer Rebuild" objects.

Delete 2 objects from the CEP config table (pwVcCepCfgTable): pwVcCepCfgJtrBfrRebuildOor and
pwVcCepCfgJtrBfrRebuildOorCount. Without additional objects, the feature intended via these 2
objects is not fully functional. Also, when considering that this feature is not part of the pwe3-sonet
draft, these objects should be removed. See http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-00.txt
Stewart Bryant | 2 Oct 21:25 2002
Picon

comments on draft-ietf-pwe3-requirements-03.txt

Some comments on <draft-ietf-pwe3-requirements-03.txt>

Stewart

<snip>

1.1.  Reference Model of PWE3

    A pseudo-wire (PW) is a connection between two provider edge (PE)
    devices which connects two pseudo-wire end-services (PWESs) of the
    same type. A PWES is either:
      - an Ethernet link or a VLAN link between two ports, or
      - an ATM VC or VP, or
      - a Frame Relay VC, or
      - a TDM circuit, or
      - an MPLS LSP

SB> Why not raw HDLC frames?
SB> Do you mean TDM or something more generic? How does SONET fit in
SB> to this taxonomy?

    between a customer edge (CE) device and a PE (See Figure 1).  During
    the setup of a PW, the two PEs will be configured or will
    automatically exchange information about the service to be emulated
    so that later they know how to process packets coming from the other
    end. After the PW is set up, layer-2 (e.g. Ethernet, ATM, Frame Relay
    and MPLS) or layer-1 (e.g. SONET/SDH) PDUs from a PWES are
    encapsulated at the PW ingress. The encapsulated PDUs are then sent
    over the PW to the egress, where L2 or L1 headers are re-constructed

(Continue reading)

Thomas D. Nadeau | 2 Oct 21:39 2002
Picon

Re: comments on draft-ietf-pwe3-requirements-03.txt


         One comment inline.

>Some comments on <draft-ietf-pwe3-requirements-03.txt>
>
>Stewart
>
><snip>
>
>1.1.  Reference Model of PWE3
>
>    A pseudo-wire (PW) is a connection between two provider edge (PE)
>    devices which connects two pseudo-wire end-services (PWESs) of the
>    same type. A PWES is either:
>      - an Ethernet link or a VLAN link between two ports, or
>      - an ATM VC or VP, or
>      - a Frame Relay VC, or
>      - a TDM circuit, or
>      - an MPLS LSP
>
>SB> Why not raw HDLC frames?
>SB> Do you mean TDM or something more generic? How does SONET fit in
>SB> to this taxonomy?
>
>    between a customer edge (CE) device and a PE (See Figure 1).  During
>    the setup of a PW, the two PEs will be configured or will
>    automatically exchange information about the service to be emulated
>    so that later they know how to process packets coming from the other
>    end. After the PW is set up, layer-2 (e.g. Ethernet, ATM, Frame Relay
>    and MPLS) or layer-1 (e.g. SONET/SDH) PDUs from a PWES are
(Continue reading)

W. Mark Townsley | 3 Oct 08:03 2002
Picon

Re: comments on draft-ietf-pwe3-requirements-03.txt


Thomas D. Nadeau wrote:
> 
>>
>> 4.6.  Pseudo-Wire Traceroute
>>
>>    It can be desirable to know the exact path of a PW, especially for
>>    troubleshooting purpose. A PW emulation service MUST support PW
>>    traceroute.
>>
>> SB> Wow, you need to be very careful here. I think that if you
>> SB> only have access to a TDM circuit, figuring how it got
>> SB> across the PSN is pretty tough. It also breaks the transparancy
>> SB> of the wire. This needs to be re-written or deleted.
> 
> 
>         Given the operational requirements that I have seen,
> it is paramount for deployment of services to have a tracing/ping

Trace or ping, which one do we care most about? They tend to have very different 
implementation requirements, and lumping them together at the same level of 
requirement may not be fully respecting this.

> function before these folks will deploy PWs in their networks.
> I would be okay to change "MUST" to "SHOULD" if that would
> make you happy.
> 
>         --Tom
Stewart Bryant | 3 Oct 09:41 2002
Picon

Re: comments on draft-ietf-pwe3-requirements-03.txt


>> <snip>
>>
>> 4.6.  Pseudo-Wire Traceroute
>>
>>    It can be desirable to know the exact path of a PW, especially for
>>    troubleshooting purpose. A PW emulation service MUST support PW
>>    traceroute.
>>
>> SB> Wow, you need to be very careful here. I think that if you
>> SB> only have access to a TDM circuit, figuring how it got
>> SB> across the PSN is pretty tough. It also breaks the transparancy
>> SB> of the wire. This needs to be re-written or deleted.
> 
> 
>         Given the operational requirements that I have seen,
> it is paramount for deployment of services to have a tracing/ping
> function before these folks will deploy PWs in their networks.
> I would be okay to change "MUST" to "SHOULD" if that would
> make you happy.
> 
>         --Tom
> 
> 
> 

I would be fine with SHOULD.
MUST means put the project on hold until we find a solution
and depending on what you have in mind, it is not clear that
we have such a solution on the horizon.
(Continue reading)

neil.2.harrison | 3 Oct 10:08 2002

RE: comments on draft-ietf-pwe3-requirements-03.txt

Thomas D. Nadeau wrote 02 October 2002 20:40

<snipped>
> >4.6.  Pseudo-Wire Traceroute
> >
> >    It can be desirable to know the exact path of a PW, 
> especially for
> >    troubleshooting purpose. A PW emulation service MUST support PW
> >    traceroute.
> >
> >SB> Wow, you need to be very careful here. I think that if you
> >SB> only have access to a TDM circuit, figuring how it got
> >SB> across the PSN is pretty tough. It also breaks the transparancy
> >SB> of the wire. This needs to be re-written or deleted.
> 
>          Given the operational requirements that I have seen,
> it is paramount for deployment of services to have a tracing/ping
> function before these folks will deploy PWs in their networks.
> I would be okay to change "MUST" to "SHOULD" if that would
> make you happy.
NH=> The operations requirements don't specifically ask for trace-route or
LSP-Ping.....that is your interpretation.  Operations people now want to
able to manage the technoloogy they have been sold that came without any
such fault-management tools.  The p2p case of LSPs is trivally solved with
Y.1711...and you cannot get any simpler than that as you ought to know.  LDP
is the problem.....though what real *operators network problem* LDP solves
that is not better solved by a pure IP solution beats me...I have asked this
question loads of times and I can't find anyone who can answer it.  However,
given the nature of the beast and that its out there, I would not want to
preclude other solutions for the network management headaches LDP mp2p
(Continue reading)

Thomas D. Nadeau | 3 Oct 15:38 2002
Picon

Re: comments on draft-ietf-pwe3-requirements-03.txt

At 08:03 AM 10/3/2002 +0200, W. Mark Townsley wrote:

>Thomas D. Nadeau wrote:
>>
>>>
>>>4.6.  Pseudo-Wire Traceroute
>>>
>>>    It can be desirable to know the exact path of a PW, especially for
>>>    troubleshooting purpose. A PW emulation service MUST support PW
>>>    traceroute.
>>>
>>>SB> Wow, you need to be very careful here. I think that if you
>>>SB> only have access to a TDM circuit, figuring how it got
>>>SB> across the PSN is pretty tough. It also breaks the transparancy
>>>SB> of the wire. This needs to be re-written or deleted.
>>
>>         Given the operational requirements that I have seen,
>>it is paramount for deployment of services to have a tracing/ping
>
>Trace or ping, which one do we care most about? They tend to have very 
>different implementation requirements, and lumping them together at the 
>same level of requirement may not be fully respecting this.

         Both are important, CV is important to detect failures and the 
other (trace) to detect
where the failure occurred. Currently MPLS LSP ping integrates both, for 
example. So,
I think that we can change the text to something like:

         It can be desirable to verify the connection status between the edges
(Continue reading)

Thomas D. Nadeau | 3 Oct 15:42 2002
Picon

Re: comments on draft-ietf-pwe3-requirements-03.txt

At 08:41 AM 10/3/2002 +0100, Stewart Bryant wrote:

>>><snip>
>>>
>>>4.6.  Pseudo-Wire Traceroute
>>>
>>>    It can be desirable to know the exact path of a PW, especially for
>>>    troubleshooting purpose. A PW emulation service MUST support PW
>>>    traceroute.
>>>
>>>SB> Wow, you need to be very careful here. I think that if you
>>>SB> only have access to a TDM circuit, figuring how it got
>>>SB> across the PSN is pretty tough. It also breaks the transparancy
>>>SB> of the wire. This needs to be re-written or deleted.
>>
>>         Given the operational requirements that I have seen,
>>it is paramount for deployment of services to have a tracing/ping
>>function before these folks will deploy PWs in their networks.
>>I would be okay to change "MUST" to "SHOULD" if that would
>>make you happy.
>>         --Tom
>>
>
>I would be fine with SHOULD.
>MUST means put the project on hold until we find a solution
>and depending on what you have in mind, it is not clear that
>we have such a solution on the horizon.
>
>When you say "know the exact path", who should know the exact
>path and from what point of view?
(Continue reading)


Gmane