From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Peter Willis Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 09:00:38 +0100 Lines: 10 Sender: pwe3-admin@ietf.org References: <200303311807.NAA04541@bifocal.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 10:05:51 2003 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: George Swallow In-reply-to: Your message of "Mon, 31 Mar 2003 13:07:52 CDT." <200303311807.NAA04541@bifocal.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O George, I agree with you, MPLS LDP delivers a CNLS service and may deliver packets out of order. Therefore if we use PWE3 over MPLS LDP then we have to cater for out of order packets. My concern is if we used PWE3 over MPLS RSVP-TE (or similar) then we would assume packets would be delivered in order and we wouldn't want to bear the cost of the re-sequencing mechanism in PWE3. Regards, Peter. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Tim.Frost@Zarlink.Com Subject: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt Date: Tue, 1 Apr 2003 08:50:24 +0000 Lines: 134 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 11:03:07 2003 Return-path: To: "tom k. johnson" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.11 |July 24, 2002) at 04/01/2003 03:59:15 AM, Serialize complete at 04/01/2003 03:59:15 AM Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, I agree to support the first three changes. Tim "tom k. johnson" 31-Mar-2003 03:14 PM To: , cc: Subject: RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt Tim - Thanks for the excellent summary of issues. I would support the first three changes that you suggest for sure. The 4th item (as you've noted) continues to be the key point of contention. I personally would support making the use of the pointer mandatory, but I certainly understand and appreciate the arguments to the contrary... Perhaps at a minimum we could all agree on the first the modifications (?) Thanks -Tom > -----Original Message----- > From: Tim.Frost@zarlink.com [mailto:Tim.Frost@zarlink.com] > Sent: Thursday, March 27, 2003 9:40 AM > To: pwe3@ietf.org > Subject: RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt > > > I have noted the following main comments on draft-johnson > over the last > month, both on the list and at the San Francisco meeting: > > 1. The default payload size for unstructured E1/T1 is too > large at 376, > this should be reduced to 141 (47*3) or 188 (47*4). > Since other payload sizes may be supported at will, I don't > anticipate any > significant objection to this. > > 2. The default payload size for unstructured E3/T3 should be > separated > from that for E1/T1. It could remain at 376. > This seems reasonable to me. > > 3. The use of a superframe format for NxDS0 without CAS is unjustified > I think everyone on the list agrees with this point. We seem to be in > agreement that the only relevant structure is the 125us frame. > > 4. The structure pointer mechanism for NxDS0 with/without CAS > should be > made mandatory > This is the main point of controversy. > > One of the main benefits of the pointer mechanism is to make > interworking > with AAL1 CES easier. AAL1 CES delivers cells with no fixed > relationship > to the frame structure, but with a pointer to identify where that > structure starts. Therefore these cells may be received by an > inter-working function, the ATM and AAL1 header bytes > stripped, and the > cells placed into a packet, with the AAL1 structure pointer > modified as > required to point to the first occurence of the frame > structure within the > packet. > > AAL1 required a pointer mechanism because the cell size was fixed. > Therefore it was not possible to vary the size of the payload > with the > value of N, or to suit the application. In fact the payload > size varies > with the addition of the pointer in every eighth cell. > > A packet switched network on the other hand copes with a wide > range of > packet sizes. This allows signficant possibilities, such as > specifying the > packet size in terms of packetization delay, e.g. packet size > = N * number > of frames delay required. This is important, since a key > attribute of TDM > systems is the overall latency, of which the packetization > delay may be a > signficant component in many applications. It also allows > the delay to be > kept constant regardless of the value of N, which is an important > consideration for service providers who may be providing > fractional T1 > service with different values of N to different customers, > but keep the > latency budget the same for each customer. > > If the packet size is defined in this way, the structure > pointer is no > longer required. This is because the packet size is now > locked to the TDM > frame boundary, simplifying the construction of the header. > > Therefore the question comes down to what Shahram expressed > at the San > Francisco meeting: What is most important, the ability to define > packetization delay that is constant with N , or making > inter-working with > AAL1 services easier? > > As we requested at the San Francisco meeting, please express your > arguments to the list. > > Cheers, > Tim > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Tim.Frost@Zarlink.Com Subject: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt Date: Tue, 1 Apr 2003 09:13:32 +0000 Lines: 49 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 11:26:54 2003 Return-path: To: "Yaakov Stein" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.11 |July 24, 2002) at 04/01/2003 04:22:24 AM, Serialize complete at 04/01/2003 04:22:24 AM Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, > As I have stated in the past, defining an IP packet size > in microseconds is entirely opaque to the IETF. > Packet sizes have to be stated in bytes. Actually I don't believe the IETF cares about packet sizes. Packet switched networks cope well with any packet size. What I am suggesting is that we use one of the fundamental parameters for a TDM network (i.e. delay) to specify how that TDM circuit is carried over the PSN. It seems to me that any users of this type of system will understand TDM and therefore will be entirely comfortable with this approach. > What you are suggesting is an elaborate scheme for > selecting a default packet size in bytes, based > on TDM frames, numbers of active timeslots, > type of service (E1, T1, E3, T3), etc. > Not only is this scheme extremely confusing > when presented in IETF terms, it is not required. No, it is not. It is expressing the size in a metric the TDM user will understand, and hence doing the calculation for them. This removes variables such as the numbers of active timeslots and type of service from consideration - just pick an acceptable delay for the application. > No, the question is - should one define an elaborate > scheme to force a packet size to agree with that of > a pre-existing implementation (CESoIP), or should > one allow users to use the packet size that best fits > their requirements? Well this is really coming down to the nub of the problem. Should we pick a complex, unnecessary pointer based mechanism to fit with a pre-existing implementation (TDMoIP) based on an AAL1 SAR and an ASIC, or should we allow the users to choose network parameters in terms that are fundamental to the TDM network being emulated? We have reached the point where technical arguments don't matter any more, because both sides of the argument have implementations to protect. There have been arguments in another part of the PWE3 group recently along the same lines: should existing implementations be allowed to force standards? I commend Tom Johnson for picking up the baton with draft-johnson, because at least he can't be criticised for trying to protect an implementation. I think it should now be for Tom and others outside of the immediate design team to suggest the way forward here. One (or both) of the "camps" will not like it, but it might point the way forward to a better standard. Tim From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 10:36:48 +0100 Organization: Cisco Systems, Inc. Lines: 27 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: George Swallow , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 11:42:07 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Peter Willis Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter Willis wrote: > George, > > I agree with you, MPLS LDP delivers a CNLS service and may deliver > packets out of order. Therefore if we use PWE3 over MPLS LDP then we have to > cater for out of order packets. My concern is if we used PWE3 over MPLS > RSVP-TE (or similar) then we would assume packets would be delivered in order > and we wouldn't want to bear the cost of the re-sequencing mechanism in PWE3. > Correct order would not be guaranteed during a fast re-route or a return to service. Stewart > Regards, > Peter. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: MPLS PID Date: Tue, 1 Apr 2003 16:59:07 +0200 Lines: 78 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B3FACEE@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Andrew G. Malis'" , X-From: pwe3-admin@ietf.org Tue Apr 01 16:07:33 2003 Return-path: To: "'George Swallow'" , "'W. Mark Townsley'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <89D0584BBFBFE74F9057A389BA3F239B3FACEE@gaya.lycium.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O George and all, Would reserving two PID values for PWE3 flows be ok? The current SONET CEP header is by default 1 word long (4 bytes), but also supports several optional modes that uses an extended (longer) control word. The CEP header has an extension bit that tells the receiver whether the incoming flow carries an extended control word or not. Two PID values that differentiate between the two, and provides the same functionality as the E bit would be of great help, something along: PID = 0000 : PW Short/Default Control Word PID = xxxx : PW Extended Control Word This would take only 2 out of the 16 values, and can be used by all PW to support similar functions. Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of George Swallow > Sent: Tuesday, March 25, 2003 10:39 PM > To: W. Mark Townsley > Cc: Andrew G. Malis; pwe3@ietf.org; swallow@cisco.com > Subject: Re: [PWE3] MPLS PID > > > > Regarding whether the MPLS WG has discussed this before, Eric Rosen > > suggested at > > the microphone in SF that it had, but at that time the > decision obviously was to > > not include a PID within MPLS. The bottom line is that > perhaps we are seeing > > that in hindsight this was an error, and if so this should > be openly resolved > > within the MPLS WG. > > For a few of us is was foresight, but that didn't carry the > day. I would be most happy to have this discussed in MPLS. > > It would seem that there three identified uses for the PID. > > 1. Dealing with ECMP behavior > 2. Inband OAM flows > 3. Identifying flows for netmanagement applications. > > The first seems fairly straightforward. > > Define IPv4 and v6, reserve a few more values for possible > future versions of IP. Figure out whether there is any ST > left in the world. > > For the second define a single PID for any OAM flow. It > would be imprudent to had out pair of PIDs to apps that want > inband OAM. Something collecting flow information in the > middle of the network won't be able to identify the inband > OAM, but that may be a good thing as the result will be just > counting the data. > > The third is a bit tickier. Given the resolution of (1&2) > we'll have a small number of PID values to play with to use > for flow identification. What that small set should be needs > to be resolved. I look to operators of networks for input. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: MPLS PID Date: Tue, 1 Apr 2003 09:15:31 -0500 Lines: 336 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F859.2763DBCE" Cc: "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Tue Apr 01 16:28:36 2003 Return-path: To: "'Dan Tappan'" , Shahram Davari X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F859.2763DBCE Content-Type: text/plain; charset="iso-8859-1" Dan: The issue specific to ECMP is granularity vs. other trade offs (such as requiring control words, losing path consistency etc.), there is simply no free lunch. Obviously you cannot hash one label. If there is no usable label stack, consider FEC/incoming interface, sure it is not as fine grained as hashing the payload, the point is there are options that are less destructive to other useful properties. I think we can all agree with the argument that on paper, the finer the microflow classification the better for load spreading of a single LSP, do we have real measurement to back that up where there are large numbers of LSPs, or are we well into diminshing returns at that point? NOW If there are issues w.r.t. MPLS here, they are: 1) are we going to permanently break the paradigm where labels are PIDs?, because that's where we're headed. IMHO that's fairly fundamental. MPLS cannot just carry "anything" via signalled convention, because intermediate boxes are making their own assumptions as to what the payload is. 2) if we codify snooping the first nybble, it still does not fix ECMP hashing of reserved labels, we're still in the woods. We also hang out to dry work in PWE3 and other SDOs that are not compliant with this "new" convention. If the goal is that ECMP trumps the MPLS architecture, we have a few things to fix, not just the PID. If the goal is that MPLS must be backwards compliant with deployed or may be deployed ECMP gear making PW 1st nybbles == 0 is only a start. However I consider there to be a lot of practical difficulties with such a dictate, mandating that all future work to support proprietary and therefore unknowable implementations (a.k.a. arbitrary layer violations) is a bit of an oxymoron. cheers Dave > > You keep talking about using the label stack. Consider the case: > - at the end of an LSP, where the forwarding operation is > "pop and forward" > - and where the packets being carried are IP > - and there is ECMP on the output paths > > How is one supposed to make the ECMP decision in that case? > There's only > one label, so hashing on the label stack will only choose a > single path. > > And don't say "well, it's ok to look at the IP packet in that > case". If > it's "fundamentally wrong" to look at the data, as opposed to > the label(s), > in the packet to make an ECMP decision in the middle of the > LSP, then it's > "fundamentally wrong" at the end. > > Or is that case acceptable, because the particular pre-standard > implementation that you're trying to protect won't encounter it? > > Is it a layer violation for an IP ECMP implementation to look at the > TCP/UDP ports when spreading the traffic over paths? Or to > look under an > IPinIP tunnel header? Or for a WFQ implementation to look at > any packet > fields? Maybe, but there can be practical value in doing so. > > For that matter, if we're worrying about layer violations, > why is it ok to > look below the top label (as in "hash the label stack"). > Isn't that also a > layer violation? > > If your answer is "you know what the labels are, but you > don't know that > what the encapsulated data is" then that's the whole point of > this PID > discussion. > > IMO, if you want to make an argument based on architectural > purity and > "layering" then you need to stick with the top label. In any > other case > we've decided what we are, we're just arguing over the price. > > But, in fact I don't accept that any of these are layer > violations. In all > these cases, the fundamental forwarding decision is on the outermost > header. Any examination of underlying data is simply selecting finer > granularity of flows. In most of these discussions "layer > violation" is > simply a debating trick, holding out for OSI architectural > purity as when > all else fails. > > As I see it there are two possible approaches: > > 1. Require that an LSP set up for an IP L3PID or IP FEC carry > IP packets. 2. Allow non-IP packets on such an LSP, but > require that they be > distinguishable. > > The simple facts are: > - it turns out that [2] has value operationally, otherwise we > wouldn't be > having this discussion > - there is a proposal on the table which provides a backward > compatible > way to achieve [2], without affecting any fielded, standardized, > implementations. > - the only negative impact of the proposal is on existing > implementations > of pre-standard drafts. And we all know the risks of > implementing prior to > standardization. Even there, an operator can deploy the pre-standard > implementation, as long as they avoid [2]. > > Why isn't this a no-brainer? > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C2F859.2763DBCE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] MPLS PID

Dan:

The issue specific to ECMP is granularity vs. other = trade offs (such as requiring control words, losing path consistency = etc.), there is simply no free lunch. Obviously you cannot hash one = label. If there is no usable label stack, consider FEC/incoming = interface, sure it is not as fine grained as hashing the payload, the = point is there are options that are less destructive to other useful = properties.

I think we can all agree with the argument that on = paper, the finer the microflow classification the better for load = spreading of a single LSP, do we have real measurement to back that up = where there are large numbers of LSPs, or are we well into diminshing = returns at that point?

NOW If there are issues w.r.t. MPLS here, they = are:

1) are we going to permanently break the paradigm = where labels are PIDs?, because that's where we're headed. IMHO that's = fairly fundamental. MPLS cannot just carry "anything" via = signalled convention, because intermediate boxes are making their own = assumptions as to what the payload is.

2) if we codify snooping the first nybble, it still = does not fix ECMP hashing of reserved labels, we're still in the woods. = We also hang out to dry work in PWE3 and other SDOs that are not = compliant with this "new" convention.

If the goal is that ECMP trumps the MPLS = architecture, we have a few things to fix, not just the PID. If the = goal is that MPLS must be backwards compliant with deployed or may be = deployed ECMP gear making PW 1st nybbles =3D=3D 0 is only a start. =

However I consider there to be a lot of practical = difficulties with such a dictate, mandating that all future work to = support proprietary and therefore unknowable implementations (a.k.a. = arbitrary layer violations) is a bit of an oxymoron.

cheers
Dave


>
> You keep talking about using the label stack. = Consider the case:
> - at the end of an LSP, where the forwarding = operation is
> "pop and forward"
> - and where the packets being carried are = IP
> - and there is ECMP on the output paths
>
> How is one supposed to make the ECMP decision = in that case?
> There's only
> one label, so hashing on the label stack will = only choose a
> single path.
>
> And don't say "well, it's ok to look at = the IP packet in that
> case". If
> it's "fundamentally wrong" to look at = the data, as opposed to
> the label(s),
> in the packet to make an ECMP decision in the = middle of the
> LSP, then it's
> "fundamentally wrong" at the = end.
>
> Or is that case acceptable, because the = particular pre-standard
> implementation that you're trying to protect = won't encounter it?
>
> Is it a layer violation for an IP ECMP = implementation to look at the
> TCP/UDP ports when spreading the traffic over = paths? Or to
> look under an
> IPinIP tunnel header? Or for a WFQ = implementation to look at
> any packet
> fields? Maybe, but there can be practical value = in doing so.
>
> For that matter, if we're worrying about layer = violations,
> why is it ok to
> look below the top label (as in "hash the = label stack").
> Isn't that also a
> layer violation?
>
> If your answer is "you know what the = labels are, but you
> don't know that
> what the encapsulated data is" then that's = the whole point of
> this PID
> discussion.
>
> IMO, if you want to make an argument based on = architectural
> purity and
> "layering" then you need to stick = with the top label. In any
> other case
> we've decided what we are,  we're just = arguing over the price.
>
> But, in fact I don't accept that any of these = are layer
> violations. In all
> these cases, the fundamental forwarding = decision is on the outermost
> header. Any examination of underlying data is = simply selecting finer
> granularity of flows.  In most of these = discussions "layer
> violation" is
> simply a debating trick, holding out for OSI = architectural
> purity as when
> all else fails.
>
> As I see it there are two possible = approaches:
>
> 1. Require that an LSP set up for an IP L3PID = or IP FEC carry
> IP packets. 2. Allow non-IP packets on such an = LSP, but
> require that they be
> distinguishable.
>
> The simple facts are:
> - it turns out that [2] has value = operationally, otherwise we
> wouldn't be
> having this discussion
> -  there is a proposal on the table which = provides a backward
> compatible
> way to achieve [2], without affecting any = fielded, standardized,
> implementations.
> -  the only negative impact of the = proposal is on existing
> implementations
> of pre-standard drafts. And we all know the = risks of
> implementing prior to
> standardization. Even there, an operator can = deploy the pre-standard
> implementation, as long as they avoid = [2].
>
> Why isn't this a no-brainer?
>
>
>
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C2F859.2763DBCE-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: What is PWE3 chartered to do? Date: Tue, 1 Apr 2003 09:40:23 -0500 Lines: 52 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F85C.A058C6CC" Cc: George Swallow , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 16:51:26 2003 Return-path: To: "'stbryant@cisco.com'" , Peter Willis X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F85C.A058C6CC Content-Type: text/plain; charset="iso-8859-1" Stewart: > > Correct order would not be guaranteed during a fast re-route > or a return to service. > Do you envision this being a frequent occurrance ? Dave ------_=_NextPart_001_01C2F85C.A058C6CC Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] What is PWE3 chartered to do?

Stewart:

>
> Correct order would not be guaranteed during a fast re-route
> or a return to service.
>

Do you envision this being a frequent occurrance ?

Dave


------_=_NextPart_001_01C2F85C.A058C6CC-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: AAL12oPSN Date: Tue, 1 Apr 2003 17:57:44 +0300 Lines: 28 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Tue Apr 01 17:03:58 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] AAL12oPSN Thread-Index: AcL34InJqBh/SOBYQritRYdh3SoL9QAfnGdQ To: , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31FJqK26781 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I fully support its adoption. Y(J)S > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net] > Sent: Tuesday, April 01, 2003 2:36 AM > To: pwe3@ietf.org > Subject: [PWE3] AAL12oPSN > > > > Folks, > Shahram has requested that this document be accepted as a WG > item. > > http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-ov > er-psn-01.txt > > Comments please.... > > -danny > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From owner-mpls@UU.NET Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: [PWE3] MPLS PID Date: Tue, 01 Apr 2003 10:18:30 -0500 Lines: 71 Sender: owner-mpls@UU.NET References: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org, mpls@UU.NET X-From: owner-mpls@UU.NET Tue Apr 01 17:35:04 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Shahram Davari , "'Lloyd Wood'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-s ierra.bc.ca> Precedence: bulk Status: O At 02:40 PM 3/31/2003 -0800, Shahram Davari wrote: >I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network >is fundamentally wrong, and is impossible to do for all ECMP >implementations such as the one that I described >in earlier emails in which both the first nibble and the CRC are used to >detect IP. > >The best way to solve this problem is to do ECMP only based on label >stack. Doing so should be >easier than introducing new standard. Sharam, it sounds like you are introducing a new standard by insisting that ECMP only be based on the label stack. --Tom >-Shahram > > > >-----Original Message----- > >From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > >Sent: Sunday, March 30, 2003 6:11 PM > >To: Eric Rosen > >Cc: jeremy.de_clercq@alcatel.be; David Allan; 'Scott W Brim'; > >pwe3@ietf.org; mpls@UU.NET > >Subject: Re: [PWE3] MPLS PID > > > > > >On Thu, 27 Mar 2003, Eric Rosen wrote: > > > >> 1. The only reason for a PID field in MPLS and/or > >PWE3 is to allow > >> intermediate routers to determine whether a particular > >MPLS payload is an > >> IP packet or not. > > > >which is a layer violation, and shouldn't be done. > > > >> There are a number of reasons why this is useful, and > >no one has argued > >> that this is not useful. > > > >not appropriate, more like. > > > >if you're going to sniff for an IP packet (so you can sniff TCP/UDP or > >higher) you might want to ask why you even have any form of mpls > >label stack in there in the first place. > > > >if you're not separating out your ip flows via explicit mpls label, > >why not? > > > >L. > > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt Date: Tue, 1 Apr 2003 18:17:29 +0300 Lines: 105 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Tue Apr 01 17:36:28 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt Thread-Index: AcL4MDFmqp5+rRE1RkywZgPe5O5YUwALwKtw To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31FdiK02224 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tim, > > As I have stated in the past, defining an IP packet size > > in microseconds is entirely opaque to the IETF. > > Packet sizes have to be stated in bytes. > > Actually I don't believe the IETF cares about packet sizes. Packet > switched networks cope well with any packet size. What I am > suggesting is that we use one of the fundamental parameters for a TDM network (i.e. > delay) to specify how that TDM circuit is carried over the PSN. It seems > to me that any users of this type of system will understand TDM and > therefore will be entirely comfortable with this approach. If the IETF doesn't care about packet sizes, then let's remove all mention of default sizes from the draft. > > > What you are suggesting is an elaborate scheme for > > selecting a default packet size in bytes, based > > on TDM frames, numbers of active timeslots, > > type of service (E1, T1, E3, T3), etc. > > Not only is this scheme extremely confusing > > when presented in IETF terms, it is not required. > > No, it is not. It is expressing the size in a metric the TDM > user will understand, and hence doing the calculation for them. This removes > variables such as the numbers of active timeslots and type of > service from consideration - just pick an acceptable delay for the application. Agreed. Let the user pick whatever size best suits the application. This is precisely what I have been saying all along. > > No, the question is - should one define an elaborate > > scheme to force a packet size to agree with that of > > a pre-existing implementation (CESoIP), or should > > one allow users to use the packet size that best fits > > their requirements? > > Well this is really coming down to the nub of the problem. > Should we pick a complex, unnecessary pointer based mechanism to fit with a > pre-existing implementation (TDMoIP) based on an AAL1 SAR and an ASIC, or > should we allow the users to choose network parameters in terms that > are fundamental to the TDM network being emulated? Quite the contrary. As you well know, draft-johnson with the pointer is only marginally helpful in allowing interworking with AAL1 networks, and is in NO WAY related to draf-anavi. However, draft-johnson with no pointer and frame-locking is EXACTLY CESoPSN !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! So what you are suggesting is to throw out an obviously useful feature - the pointer - which allows all known applications to be supported, ONLY in order to degenerate to a previously existing (if only marginally deployed) system. What I am suggesting is to keep the pointer and enable interworking with a vast number of actually deployed systems. > We have reached the point where technical arguments don't matter any more, > because both sides of the argument have implementations to protect. Sorry, but I don't agree. draft-johnson is simply CESoPSN with an optional pointer. In no way can it be seen to resemble draft-anavi. How can you say that my insisting on a pointer is because I want to stick to my existing implementation? If I was insisting on having draft-anavi I wouldn't be considering draft-johnson, with or without a pointer. I WOULD be insisting that the header be the standard PWE header rather than one which causes a lot of head-aches (as we have seen on the list). I WOULD be insisting on AAL1 payloads, with the embedded sequence numbers and pointers. The only thing I see here is some people insisting on a bit-exact CESoPSN draft, without even minor additions. > There have been arguments in another part of the PWE3 group > recently along the same lines: should existing implementations be allowed to > force standards? Absolutely not. Especially not when we are talking about CESoPSN which has only been marginally deployed, if at all. > I commend Tom Johnson for picking up the baton with > draft-johnson, because at least he can't be criticised for trying to protect an > implementation. I think it should now be for Tom and others outside of the > immediate design team to suggest the way forward here. One (or both) of the > "camps" will not like it, but it might point the way forward to a better standard. I agree that Tom did a good job, and as you know was willing to support the effort even though it was unrelated to my system (which has been extensively deployed). But then the pressure was put on him to make the draft into a CESoPSN double, at the expense of major loss of functionality. That is when my support ended. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 10:23:35 -0500 Lines: 8 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: George Swallow , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 17:39:19 2003 Return-path: To: Peter Willis In-reply-to: Your message of Tue, 01 Apr 2003 09:00:38 +0100. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter> My concern is if we used PWE3 over MPLS RSVP-TE (or similar) then we Peter> would assume packets would be delivered in order and we wouldn't Peter> want to bear the cost of the re-sequencing mechanism in PWE3. Irrespective of the truth of the assumption, given that PWE3 can run over either an unsequenced or a sequenced PSN layer, if PWE3 needs sequencing, sequencing must be provided at the PWE3 layer. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: MPLS PID Date: Tue, 1 Apr 2003 07:32:11 -0800 Lines: 155 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Tue Apr 01 17:42:15 2003 Return-path: To: "'Dan Tappan'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Dan, I know that doing a fine level ECMP is best for load balancing. But it seems that your ONLY goal is to preserve the fine level load balancing, without looking at other aspects which might be negatively affected by doing so. I don't believe people want to do perfect load balancing, at the expense of breaking other properties of MPLS. For example: 1) what would L3PID mean any more in MPLS signaling? would that be deprecated? If not what happens if the L3PID in the signaling does not match the PID in the payload? Who is going to detect that and what error message or actions should be taken? 2) what happens to other proprietary ECMP implementations? should only the implementations checking the first nibble to detect IP be supported or all others too? what if an ECMP implementation checks the checksum to detect IP (which is much more reliable than checking the first nibble)? if the PID is standardized to cater for the first nibble, then should it also cater for the checksum too? In other words should we state that when standardizing a PID, octets 11 and 12 of the payload should not result a valid checksum over the first 20 bytes? 3) How do you solve the ECMP for the case that a reserved label is used is the stack? 4) What does IPv4/v6 null mean in the future if the PID is standardized? will they be irrelevant? if not what happens if the PID and explicit null don't match? Please see specific comments in-line. -Shahram >-----Original Message----- >From: Dan Tappan [mailto:tappan@cisco.com] >Sent: Monday, March 31, 2003 7:42 PM >To: Shahram Davari >Cc: 'Lloyd Wood'; pwe3@ietf.org; mpls@UU.NET >Subject: RE: [PWE3] MPLS PID > > >At 02:40 PM 3/31/2003 -0800, Shahram Davari wrote: >>I agree with Lloyd. Sniffing IP packets in the middle of an >MPLS network >>is fundamentally wrong, and is impossible to do for all ECMP >>implementations such as the one that I described >>in earlier emails in which both the first nibble and the CRC >are used to >>detect IP. >> >>The best way to solve this problem is to do ECMP only based >on label stack. > >You keep talking about using the label stack. Consider the case: >- at the end of an LSP, where the forwarding operation is "pop >and forward" I assume you mean PHP. >- and where the packets being carried are IP If you know that the payload is IP why do you need PID? >- and there is ECMP on the output paths > >How is one supposed to make the ECMP decision in that case? >There's only >one label, so hashing on the label stack will only choose a >single path. You could always use incoming label stack, or even incoming port for ECMP decision. Or if as you said you know the payload is IP the use the IP header (which would be non-standard). > >And don't say "well, it's ok to look at the IP packet in that >case". If >it's "fundamentally wrong" to look at the data, as opposed to >the label(s), >in the packet to make an ECMP decision in the middle of the >LSP, then it's >"fundamentally wrong" at the end. If you know payload is IP use IP header, if you don't know then use label stack. > >Or is that case acceptable, because the particular pre-standard >implementation that you're trying to protect won't encounter it? As opposed to you, I have no implementation and am not protecting anybody's implementation. I am just stating what is the right architectural thing to do. > >Is it a layer violation for an IP ECMP implementation to look at the >TCP/UDP ports when spreading the traffic over paths? Or to >look under an >IPinIP tunnel header? Or for a WFQ implementation to look at >any packet >fields? Maybe, but there can be practical value in doing so. > >For that matter, if we're worrying about layer violations, why >is it ok to >look below the top label (as in "hash the label stack"). Isn't >that also a >layer violation? > >If your answer is "you know what the labels are, but you don't >know that >what the encapsulated data is" then that's the whole point of this PID >discussion. > >IMO, if you want to make an argument based on architectural purity and >"layering" then you need to stick with the top label. In any >other case >we've decided what we are, we're just arguing over the price. > >But, in fact I don't accept that any of these are layer >violations. In all >these cases, the fundamental forwarding decision is on the outermost >header. Any examination of underlying data is simply selecting finer >granularity of flows. In most of these discussions "layer >violation" is >simply a debating trick, holding out for OSI architectural >purity as when >all else fails. > >As I see it there are two possible approaches: > >1. Require that an LSP set up for an IP L3PID or IP FEC carry >IP packets. >2. Allow non-IP packets on such an LSP, but require that they be >distinguishable. > >The simple facts are: >- it turns out that [2] has value operationally, otherwise we >wouldn't be >having this discussion >- there is a proposal on the table which provides a backward >compatible >way to achieve [2], without affecting any fielded, standardized, >implementations. >- the only negative impact of the proposal is on existing >implementations >of pre-standard drafts. And we all know the risks of >implementing prior to >standardization. Even there, an operator can deploy the pre-standard >implementation, as long as they avoid [2]. > >Why isn't this a no-brainer? Because you are trying to be backward compatible with some proprietary implementations but do not want to be backward compatible with pre-standard implementations? Has a proprietary implementation more weight that a pres-standard implementation? Also there are other reasons that I have stated at the beginning of this email. -Shahram > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt Date: Tue, 1 Apr 2003 18:39:02 +0300 Lines: 105 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Tue Apr 01 17:48:17 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt Thread-Index: AcL4MDFmqp5+rRE1RkywZgPe5O5YUwALwKtw To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31G1BK09220 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tim, > > As I have stated in the past, defining an IP packet size > > in microseconds is entirely opaque to the IETF. > > Packet sizes have to be stated in bytes. > > Actually I don't believe the IETF cares about packet sizes. Packet > switched networks cope well with any packet size. What I am > suggesting is that we use one of the fundamental parameters for a TDM network (i.e. > delay) to specify how that TDM circuit is carried over the PSN. It seems > to me that any users of this type of system will understand TDM and > therefore will be entirely comfortable with this approach. If the IETF doesn't care about packet sizes, then let's remove all mention of default sizes from the draft. > > > What you are suggesting is an elaborate scheme for > > selecting a default packet size in bytes, based > > on TDM frames, numbers of active timeslots, > > type of service (E1, T1, E3, T3), etc. > > Not only is this scheme extremely confusing > > when presented in IETF terms, it is not required. > > No, it is not. It is expressing the size in a metric the TDM > user will understand, and hence doing the calculation for them. This removes > variables such as the numbers of active timeslots and type of > service from consideration - just pick an acceptable delay for the application. Agreed. Let the user pick whatever size best suits the application. This is precisely what I have been saying all along. > > No, the question is - should one define an elaborate > > scheme to force a packet size to agree with that of > > a pre-existing implementation (CESoIP), or should > > one allow users to use the packet size that best fits > > their requirements? > > Well this is really coming down to the nub of the problem. > Should we pick a complex, unnecessary pointer based mechanism to fit with a > pre-existing implementation (TDMoIP) based on an AAL1 SAR and an ASIC, or > should we allow the users to choose network parameters in terms that > are fundamental to the TDM network being emulated? Quite the contrary. As you well know, draft-johnson with the pointer is only marginally helpful in allowing interworking with AAL1 networks, and is in NO WAY related to draf-anavi. However, draft-johnson with no pointer and frame-locking is EXACTLY CESoPSN !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! So what you are suggesting is to throw out an obviously useful feature - the pointer - which allows all known applications to be supported, ONLY in order to degenerate to a previously existing (if only marginally deployed) system. What I am suggesting is to keep the pointer and enable interworking with a vast number of actually deployed systems. > We have reached the point where technical arguments don't matter any more, > because both sides of the argument have implementations to protect. Sorry, but I don't agree. draft-johnson is simply CESoPSN with an optional pointer. In no way can it be seen to resemble draft-anavi. How can you say that my insisting on a pointer is because I want to stick to my existing implementation? If I was insisting on having draft-anavi I wouldn't be considering draft-johnson, with or without a pointer. I WOULD be insisting that the header be the standard PWE header rather than one which causes a lot of head-aches (as we have seen on the list). I WOULD be insisting on AAL1 payloads, with the embedded sequence numbers and pointers. The only thing I see here is some people insisting on a bit-exact CESoPSN draft, without even minor additions. > There have been arguments in another part of the PWE3 group > recently along the same lines: should existing implementations be allowed to > force standards? Absolutely not. Especially not when we are talking about CESoPSN which has only been marginally deployed, if at all. > I commend Tom Johnson for picking up the baton with > draft-johnson, because at least he can't be criticised for trying to protect an > implementation. I think it should now be for Tom and others outside of the > immediate design team to suggest the way forward here. One (or both) of the > "camps" will not like it, but it might point the way forward to a better standard. I agree that Tom did a good job, and as you know was willing to support the effort even though it was unrelated to my system (which has been extensively deployed). But then the pressure was put on him to make the draft into a CESoPSN double, at the expense of major loss of functionality. That is when my support ended. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: MPLS PID Date: Tue, 1 Apr 2003 07:40:33 -0800 Lines: 19 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Tue Apr 01 17:55:17 2003 Return-path: To: "'Thomas D. Nadeau'" , "'Lloyd Wood'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >>The best way to solve this problem is to do ECMP only based on label >>stack. Doing so should be >>easier than introducing new standard. > > Sharam, it sounds like you are introducing a new standard >by insisting that ECMP only be based on the label stack. > > --Tom > Tom, no I am not standardizing anything. I said, if you are not sure the payload is IP, you could always use the label stack for ECMP? After all isn't this what you do in case the payload is not IP? In other words there is a way around the problem that you are trying to solve. Whether you use it or not is up to you. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt Date: Tue, 1 Apr 2003 07:42:12 -0800 Lines: 138 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 17:58:53 2003 Return-path: To: "'Yaakov Stein'" , Tim.Frost@zarlink.com X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tim, I also agree with Yaakov. If the payload size does not matter in IP networks, let's then remove the default packet sizes from all modes. -Shahram >-----Original Message----- >From: Yaakov Stein [mailto:yaakov_s@rad.com] >Sent: Tuesday, April 01, 2003 10:17 AM >To: Tim.Frost@zarlink.com >Cc: pwe3@ietf.org >Subject: RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt > > >Tim, > >> > As I have stated in the past, defining an IP packet size >> > in microseconds is entirely opaque to the IETF. >> > Packet sizes have to be stated in bytes. >> >> Actually I don't believe the IETF cares about packet sizes. Packet >> switched networks cope well with any packet size. What I am >> suggesting is that we use one of the fundamental parameters >for a TDM network (i.e. >> delay) to specify how that TDM circuit is carried over the >PSN. It seems >> to me that any users of this type of system will understand TDM and >> therefore will be entirely comfortable with this approach. > >If the IETF doesn't care about packet sizes, >then let's remove all mention of default sizes from the draft. > >> >> > What you are suggesting is an elaborate scheme for >> > selecting a default packet size in bytes, based >> > on TDM frames, numbers of active timeslots, >> > type of service (E1, T1, E3, T3), etc. >> > Not only is this scheme extremely confusing >> > when presented in IETF terms, it is not required. >> >> No, it is not. It is expressing the size in a metric the TDM >> user will understand, and hence doing the calculation for >them. This removes >> variables such as the numbers of active timeslots and type of >> service from consideration - just pick an acceptable delay >for the application. > >Agreed. Let the user pick whatever size best suits the application. >This is precisely what I have been saying all along. > >> > No, the question is - should one define an elaborate >> > scheme to force a packet size to agree with that of >> > a pre-existing implementation (CESoIP), or should >> > one allow users to use the packet size that best fits >> > their requirements? >> >> Well this is really coming down to the nub of the problem. >> Should we pick a complex, unnecessary pointer based >mechanism to fit with a >> pre-existing implementation (TDMoIP) based on an AAL1 SAR >and an ASIC, or >> should we allow the users to choose network parameters in terms that >> are fundamental to the TDM network being emulated? > >Quite the contrary. >As you well know, draft-johnson with the pointer is only >marginally helpful in allowing interworking with AAL1 networks, >and is in NO WAY related to draf-anavi. > >However, draft-johnson with no pointer and frame-locking >is EXACTLY CESoPSN !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > >So what you are suggesting is to throw out an obviously >useful feature - the pointer - which allows all known >applications to be supported, ONLY in order to degenerate >to a previously existing (if only marginally deployed) system. > >What I am suggesting is to keep the pointer and enable >interworking with a vast number of actually deployed systems. > >> We have reached the point where technical arguments don't >matter any more, >> because both sides of the argument have implementations to protect. > >Sorry, but I don't agree. > >draft-johnson is simply CESoPSN with an optional pointer. >In no way can it be seen to resemble draft-anavi. > >How can you say that my insisting on a pointer is because >I want to stick to my existing implementation? >If I was insisting on having draft-anavi I wouldn't be >considering draft-johnson, with or without a pointer. > >I WOULD be insisting that the header be the standard PWE header >rather than one which causes a lot of head-aches (as we have >seen on the list). > >I WOULD be insisting on AAL1 payloads, with the embedded >sequence numbers >and pointers. > >The only thing I see here is some people insisting on >a bit-exact CESoPSN draft, without even minor additions. > >> There have been arguments in another part of the PWE3 group >> recently along the same lines: should existing >implementations be allowed to >> force standards? > >Absolutely not. >Especially not when we are talking about CESoPSN >which has only been marginally deployed, if at all. > >> I commend Tom Johnson for picking up the baton with >> draft-johnson, because at least he can't be criticised for >trying to protect an >> implementation. I think it should now be for Tom and others >outside of the >> immediate design team to suggest the way forward here. One >(or both) of the >> "camps" will not like it, but it might point the way forward >to a better standard. > >I agree that Tom did a good job, and as you know was willing to support >the effort even though it was unrelated to my system >(which has been extensively deployed). > >But then the pressure was put on him to make the draft into >a CESoPSN double, at the expense of major loss of functionality. >That is when my support ended. > >Y(J)S >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Tim.Frost@Zarlink.Com Subject: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt Date: Tue, 1 Apr 2003 15:40:20 +0000 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "" , Yaakov Stein X-From: pwe3-admin@ietf.org Tue Apr 01 17:59:29 2003 Return-path: To: Lloyd Wood X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.11 |July 24, 2002) at 04/01/2003 10:49:10 AM, Serialize complete at 04/01/2003 10:49:10 AM Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O That's true Lloyd, but nobody's suggesting that these packets are going to be enormous here. Perhaps to be strictly accurate I should have said "within limits, I don't believe the IETF cares about packet sizes." What I am saying is that a PSN doesn't care whether all TDM packets are the same length, different lengths, variable lengths etc., they are just packets - provided they fit within the network MTU :-) Tim Lloyd Wood 01-Apr-2003 04:41 PM Please respond to Lloyd Wood To: Tim.Frost@zarlink.com cc: Yaakov Stein , "" Subject: RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt On Tue, 1 Apr 2003 Tim.Frost@Zarlink.Com wrote: > Actually I don't believe the IETF cares about packet sizes. Packet > switched networks cope well with any packet size. You may wish to read up on fragmentation, the difficulties of path mtu discovery, jumbograms, jumboframes and superframes... L. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "White, Craig (Level 3)" Subject: RE: What is PWE3 chartered to do? Date: Tue, 1 Apr 2003 09:01:25 -0700 Lines: 110 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F867.F2966392" Cc: X-From: pwe3-admin@ietf.org Tue Apr 01 18:12:40 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] What is PWE3 chartered to do? Thread-Index: AcL4XZcDSxi1TS1DS76UuxhjmqShNAACGfGg To: "David Allan" , X-OriginalArrivalTime: 01 Apr 2003 16:01:25.0825 (UTC) FILETIME=[F2C71B10:01C2F867] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F867.F2966392 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to put some numbers around this.... =20 The rule of thumb that I hear tossed around is 1 cut per 1000 Miles of = fiber per year... So a US network will consist of 15,000-20,000 miles, = that's 15-20 cuts per year (assuming Link rather than Node protection = fast re-route and further assuming all routers never die :) =20 If you add in a couple of tech brain fades while connecting all these = PWE's :) so say you can expect 2 cuts per month somewhere on the = network. Obviously the impact of each cut won't effect all LSP's, but... = =20 -craig -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Tuesday, April 01, 2003 7:40 AM To: 'stbryant@cisco.com'; Peter Willis Cc: George Swallow; neil.2.harrison@bt.com; pwe3@ietf.org Subject: RE: [PWE3] What is PWE3 chartered to do? Stewart:=20 >=20 > Correct order would not be guaranteed during a fast re-route=20 > or a return to service.=20 >=20 Do you envision this being a frequent occurrance ?=20 Dave=20 ------_=_NextPart_001_01C2F867.F2966392 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] What is PWE3 chartered to do?
Just=20 to put some numbers around this....
 
The=20 rule of thumb that I hear tossed around is 1 cut per 1000 Miles of = fiber=20 per year... So a US network will consist of 15,000-20,000 miles,=20 that's 15-20 cuts per year (assuming Link rather than Node = protection fast=20 re-route and further assuming all routers never die = :)
 
If=20 you add in a couple of tech brain fades while connecting all = these=20 PWE's :) so say you can expect 2 cuts per month somewhere on the = network.=20 Obviously the impact of each cut won't effect all LSP's, but...=20
 
-craig
-----Original Message-----
From: David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Tuesday, April 01, = 2003=20 7:40 AM
To: 'stbryant@cisco.com'; Peter Willis
Cc: = George=20 Swallow; neil.2.harrison@bt.com; pwe3@ietf.org
Subject: RE: = [PWE3]=20 What is PWE3 chartered to do?

Stewart:

>
> Correct order = would not be=20 guaranteed during a fast re-route
> or a = return to=20 service.
>

Do you envision this being a frequent occurrance = ?

Dave


------_=_NextPart_001_01C2F867.F2966392-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: Re: PWE3 requirements Date: Tue, 01 Apr 2003 11:01:30 -0500 Lines: 14 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030331122332.04d68e60@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Thomas D. Nadeau" , Xipeng Xiao , Danny McPherson , Prayson Pate , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Tue Apr 01 18:15:13 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: stbryant@cisco.com In-Reply-To: <3E8880D1.1020201@cisco.com> X-OriginalArrivalTime: 01 Apr 2003 16:02:04.0316 (UTC) FILETIME=[09B85DC0:01C2F868] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, >Yes, it's a difficult call. I don't want to disrupt the document >and I too am concerned about how late in the day we realised the >need to do this. On the other hand I am also concerned that folks >could argue that the issue is OOS because it unless it is in the >requirements. Was the realization for this need as a result of experience in the field with core routers with ECMP enabled? If so, reporting the field experience would help to scope the requirement. Thanks, Andy From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: MPLS PID Date: Tue, 1 Apr 2003 08:07:40 -0800 Lines: 46 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Tue Apr 01 18:21:43 2003 Return-path: To: "'Lloyd Wood'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Lloyd, >-----Original Message----- >From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] >Sent: Tuesday, April 01, 2003 11:03 AM >To: Shahram Davari >Cc: pwe3@ietf.org; mpls@UU.NET >Subject: RE: [PWE3] MPLS PID > > >On Mon, 31 Mar 2003, Shahram Davari wrote: > >> for all ECMP >> implementations such as the one that I described >> in earlier emails in which both the first nibble >> and the CRC are used to detect IP. > >IPv6 doesn't _have_ a header checksum. Yes. The method I said only works for IPV4. >IPv4's header checksum is a pain to work with. !!!! > >Are you describing an existing implementation? It sounds broken. Why is it broken? It works much better than using the first nibble to detect IP. > >If you know from context you're carrying IP, then the intended >identification in the first nibble is enough to identify 4 or 6 or >something else, and you don't need to sniff the packet contents. Sure. But the question was how can you detect that the payload is IP. -Shahram > >L. > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: AAL12oPSN Date: Tue, 1 Apr 2003 08:26:30 -0800 Lines: 70 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 18:33:21 2003 Return-path: To: "'Andrew G. Malis'" , Yaakov Stein X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy, I am sure we can address all your issues satisfactorily. And yes, the draft is intended to be informational. In that case would you accept it as WG document? -Shahram >-----Original Message----- >From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] >Sent: Tuesday, April 01, 2003 11:20 AM >To: Yaakov Stein >Cc: danny@tcb.net; pwe3@ietf.org >Subject: RE: [PWE3] AAL12oPSN > > >Unfortunately, as I said in the meeting, I have issues with >this draft. I >could perhaps accept it as a WG draft under the clear >understanding that it >is informational. Also, the draft needs to note that in PDU >mode, AAL1 and >OAM don't work well together - if you need both OAM and AAL1, >you must use >either N:1 or 1:1 cell mode encapsulation. > >Andy > >------- > >At 4/1/2003 05:57 PM +0300, Yaakov Stein wrote: > >>I fully support its adoption. >> >>Y(J)S >> >> > -----Original Message----- >> > From: Danny McPherson [mailto:danny@tcb.net] >> > Sent: Tuesday, April 01, 2003 2:36 AM >> > To: pwe3@ietf.org >> > Subject: [PWE3] AAL12oPSN >> > >> > >> > >> > Folks, >> > Shahram has requested that this document be accepted as a WG >> > item. >> > >> > http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-ov >> > er-psn-01.txt >> > >> > Comments please.... >> > >> > -danny >> > >> > _______________________________________________ >> > pwe3 mailing list >> > pwe3@ietf.org >> > https://www1.ietf.org/mailman/listinfo/pwe3 >> > >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: Mandatory Structure Pointer for TDM PWs (was: RE: I-D ACTI ON:draft-johnson-pwe3-tdm-00.txt) Date: Tue, 1 Apr 2003 19:24:56 +0200 Lines: 182 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'Riegel Maximilian' (E-mail)" , "Danny McPherson (E-mail)" , "Stewart Bryant (E-mail)" , pwe3@ietf.org, Alik Shimelmits X-From: pwe3-admin@ietf.org Tue Apr 01 18:35:18 2003 Return-path: To: "'tom k. johnson'" , Tim.Frost@zarlink.com, "Yaakov Stein (E-mail)" , "Shahram Davari (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, Tim, Yaakov and all, I would like to add some comments both to Tim's analysis of the issue with mandatory vs. optional structure pointer and to the possible resolution(s) of contention. I would highly appreciate TECHNICAL answers to questions/objections raised below. And I apologize in advance for rather a long text. But I did not have much choice because most of the questions raised have never been presented before. 1. IMO, no one has really defined what exactly a "mandatory structure pointer" means. This does not contribute to the technical level of the discussion. Below I will try to explain why making the structure pointer mandatory carries with it a substantial price tag without solving any real problems. Hopefully this (in addition to an already asked question - why should we go forward with violation of the PWE3 architectural principles) would be helpful for whoever still wants to address this problem as a technical one. 2. What is the cost of making the structure pointer mandatory? Please note that while POINTER GENERATION has been defined (point to the first encounter of the beginning of the structure in the packet, or set the pointer to INVALID if the packet payload does not contain beginning of the structure), POINTER PROCESSING (part of the packet play out) has NOT been specified. Here are some issues related to pointer processing: a) Play out of the packet payload becomes STATEFUL. Or, in other words, independent play out of payload of a single packet is not possible any more. This is an explicit contradiction both to the TDM requirements document (draft-ietf-pwe3-tdm-requirements-00.txt, Section 7.3.1) and to the recommendations of RFC 2736 (which is explicitly referenced in the PWE3 Charter). Note also that the stateless play out approach has been de-facto accepted for all the non-TDM PWs: e.g., * The PW fragmentation mechanism for the packet payload type(s) (draft-ietf-pwe3-fragmentation-00.txt) is OPTIONAL and has been intentionally designed in such a way that unfragmented packets are indistinguishable from the packets generated by the PE that does not support fragmentation * All the encapsulations for the cell payload type always carry one or more cells per packet (never split the cells between the packets). b) As a consequence of (a), handling of lost packets becomes more complicated ( the lost pointer must be reconstructed as part of this handling) c) The pointer processing must define detection and handling of the pointer "jumps", i.e., the situations when the segment between the two pointers cannot be broken into structures of the specified size. Note that this situation can be detected when part of the segment has been already played out, so its handling is non-trivial. Note also that detection of pointer jumps is stateful and must cover the situation when one or more INVALID pointers have been encountered between two valid values. d) If the TDM (or TDM-like) structures are not homogeneous, the fact that they may be spread between several packets adds to the complexity of the play out. E.g., if your "CAS signaling" substructure is spread between two packets, when exactly should it be played out? Another example could be adding a kind of Path Overhead Monitoring (POM) function at egress of SONET PWs. So much for the cost of a mandatory structure pointer. 3. Which problems can be solved with the structure pointer? AFAIK, using the structure pointer solves one and only one problem: decoupling between the fixed size of structures constituting the structured bit-stream payload and fixed size of the PW packets' payload. I can identify three cases when this problem may be encountered: a) The TDM structures exceed Path MTU and hence must be fragmented between several packers. This is definitely NOT the case for basic (aka without CAS) NxDS0, where the size of the structure is just N. I will discuss the case of NxDS0 with CAS below. (IMO this answers Lloyd's remark.) b) The TDM structures take too long to packetize. This situation is not relevant for basic NxDS0 (just 125 uS to packetize the structure in question). I will discuss the case of NxDS0 with CAS below. c) The packet payload size must meet some conditions that stem neither from the nature of the TDM traffic (case "b" above) nor from the nature of the PSN (case "a" above). I am aware of exactly one such use case: the declared "simple interworking" between structured ATM-CES and CEP-TDM. And I am afraid that, while such limitations may be NECESSARY, they are NOT SUFFICIENT for this purpose - a well-known logical error. This really bothers me because, AFAIK, no one has ever specified how this "simple interworking" works, i.e. how a stream of AAL1 cells is converted into CEP-TDM packets and vice versa - with the same level of detail it has been done for packetization and de-packetization of TDM streams. (If somebody wants to know why it is NOT SO SIMPLE, please consider how loss of an AAL1 cell should be detected and handled by the packetizer. Somehow no one has bothered to define this aspect of interworking as if we are discussing just the "special case" when the ATM-CES engine resides directly in the PE device. IMO this "special case" has nothing in common with interworking with ATM-CES. I strongly suspect that if we really look into this issue we shall find out that the AAL1 sublayer of ATM-CES must be fully terminated/regenerated for any robust interworking with ATM-CES. If you take into account that off-the-shelf available HW usually terminates both AAL1 and ATM-CES sub-layers, simplicity of a solution that must fully terminate just AAL1 becomes highly problematic.) 4. As I have said already, the structures (TDM frames) associated with the basic NxDS0 are neither long (just N octets) nor take long time to packetize (just 125 microseconds). So what about NxDS0 with CAS? The "superframe structure with signaling" described in draft-johnson is not too long (up to 588 bytes) but, maybe, it takes too much time to packetize (2 ms for E1 and 3 ms for T1)? IMO this is a MISUNDERSTANDING because the "superframe structure with signaling" DOES NOT EXIST anywhere in the TDM traffic. It has been first invented by the ATM-CES designers because they had to overcome the limitation of structured AAL1. ( The latter has been designed to carry streams of structures of arbitrary, but FIXED size over ATM.) These limitations are not relevant for TDM PWs carried over a PSN. Yes, there is an important and valid requirement to carry fixed amount of TDM data per TDM PW packet - because this allows to generate the correct amount of "replacement data" if a PW packet has been lost in a stateless way. And, yes, if you only carry TDM data in the PW packets, it is equivalent to having the packet payload size fixed. But if you spread "superframe structures with signaling" among several PW packets with fixed payload size you VIOLATE this requirement (because in the common case each packet would carry a variable amount of TDM data and a variable amount of CAS signaling; only the sum of the two would be fixed). On the other hand, I do not see any problem with a solution for NxDS0 with CAS that: a) Carries fixed amount of TDM data (agreed upon at the PW setup) per PW packet b) From time to time, appends a CAS signaling substructure to these packets (so that the packet payload size varies!) c) Indicates the presence of these substructures in some way in the PW header (the exact method is TBD). Such a mechanism would be compatible with the default mode for NxDS0 with CAS described in draft-johnson-pwe3-tdm-00.txt without introducing problems in non-default modes already discussed at this list. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: RE: AAL12oPSN Date: Tue, 01 Apr 2003 11:19:57 -0500 Lines: 44 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5281AC52@exrad2.ad.rad.co.il > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: , X-From: pwe3-admin@ietf.org Tue Apr 01 18:35:20 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: "Yaakov Stein" In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5281AC52@exrad2.ad.rad.co.il > X-OriginalArrivalTime: 01 Apr 2003 16:20:10.0533 (UTC) FILETIME=[9127ED50:01C2F86A] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Unfortunately, as I said in the meeting, I have issues with this draft. I could perhaps accept it as a WG draft under the clear understanding that it is informational. Also, the draft needs to note that in PDU mode, AAL1 and OAM don't work well together - if you need both OAM and AAL1, you must use either N:1 or 1:1 cell mode encapsulation. Andy ------- At 4/1/2003 05:57 PM +0300, Yaakov Stein wrote: >I fully support its adoption. > >Y(J)S > > > -----Original Message----- > > From: Danny McPherson [mailto:danny@tcb.net] > > Sent: Tuesday, April 01, 2003 2:36 AM > > To: pwe3@ietf.org > > Subject: [PWE3] AAL12oPSN > > > > > > > > Folks, > > Shahram has requested that this document be accepted as a WG > > item. > > > > http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-ov > > er-psn-01.txt > > > > Comments please.... > > > > -danny > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 11:28:15 -0500 Lines: 22 Sender: pwe3-admin@ietf.org References: Cc: George Swallow , neil.2.harrison@bt.com, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue Apr 01 18:40:00 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Peter Willis In-reply-to: Your message of "Tue, 01 Apr 2003 09:00:38 +0100." Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter - > I agree with you, MPLS LDP delivers a CNLS service and may deliver > packets out of order. Therefore if we use PWE3 over MPLS LDP then we have to > cater for out of order packets. My concern is if we used PWE3 over MPLS > RSVP-TE (or similar) then we would assume packets would be delivered in order > and we wouldn't want to bear the cost of the re-sequencing mechanism in PWE3. The whole point of this discussion on the first nibble is that if you obey certain rules then most (all?) currently available P nodes will deliver both the data and associated OAM in sequence, except during a reroute operation. As Stewart points out, RSVP-TE may also be disordered during a fast reroute. Either way you have to be prepared for a few things to be out of order. An if you engineer it right either approach can offer excellent service. ...George ================================================================== George Swallow Cisco Systems (978) 936-1398 250 Apollo Drive Chelmsford, Ma 01824 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: AAL12oPSN Date: Tue, 1 Apr 2003 19:29:08 +0300 Lines: 72 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , X-From: pwe3-admin@ietf.org Tue Apr 01 18:41:41 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] AAL12oPSN Thread-Index: AcL4ao8slKOvzN82R3aqTKmE1yb5BAAAN1/w To: "Andrew G. Malis" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31GpJK28544 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy, Yes, the idea is that Shahram's draft will be informational, since it does not suggest any new protocol, just how best to use the existing atm-encap modes for AAL1. Regarding PDU mode, the issue with OAM cells has been discussed at length. I suggest that Shahram state the restrictions explicitly in his text. Y(J)S > -----Original Message----- > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Tuesday, April 01, 2003 7:20 PM > To: Yaakov Stein > Cc: danny@tcb.net; pwe3@ietf.org > Subject: RE: [PWE3] AAL12oPSN > > > Unfortunately, as I said in the meeting, I have issues with > this draft. I > could perhaps accept it as a WG draft under the clear > understanding that it > is informational. Also, the draft needs to note that in PDU > mode, AAL1 and > OAM don't work well together - if you need both OAM and AAL1, > you must use > either N:1 or 1:1 cell mode encapsulation. > > Andy > > ------- > > At 4/1/2003 05:57 PM +0300, Yaakov Stein wrote: > > >I fully support its adoption. > > > >Y(J)S > > > > > -----Original Message----- > > > From: Danny McPherson [mailto:danny@tcb.net] > > > Sent: Tuesday, April 01, 2003 2:36 AM > > > To: pwe3@ietf.org > > > Subject: [PWE3] AAL12oPSN > > > > > > > > > > > > Folks, > > > Shahram has requested that this document be accepted as a WG > > > item. > > > > > > http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-ov > > > er-psn-01.txt > > > > > > Comments please.... > > > > > > -danny > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: RE: AAL12oPSN Date: Tue, 01 Apr 2003 11:33:31 -0500 Lines: 85 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C871@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Andrew G. Malis'" , Yaakov Stein , danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 18:44:16 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C871@nt-exch-yow.pmc-s ierra.bc.ca> X-OriginalArrivalTime: 01 Apr 2003 16:33:38.0840 (UTC) FILETIME=[72F1C980:01C2F86C] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, In that case, it's OK. However, talking about PDU mode, an issue that now needs to be addressed, assuming the WG accepts the PID in the CW, is the effect on PDU and 1-1 cell mode. Cheers, Andy ------- At 4/1/2003 08:26 AM -0800, Shahram Davari wrote: >Andy, > >I am sure we can address all your issues satisfactorily. >And yes, the draft is intended to be informational. >In that case would you accept it as WG document? > >-Shahram > > >-----Original Message----- > >From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > >Sent: Tuesday, April 01, 2003 11:20 AM > >To: Yaakov Stein > >Cc: danny@tcb.net; pwe3@ietf.org > >Subject: RE: [PWE3] AAL12oPSN > > > > > >Unfortunately, as I said in the meeting, I have issues with > >this draft. I > >could perhaps accept it as a WG draft under the clear > >understanding that it > >is informational. Also, the draft needs to note that in PDU > >mode, AAL1 and > >OAM don't work well together - if you need both OAM and AAL1, > >you must use > >either N:1 or 1:1 cell mode encapsulation. > > > >Andy > > > >------- > > > >At 4/1/2003 05:57 PM +0300, Yaakov Stein wrote: > > > >>I fully support its adoption. > >> > >>Y(J)S > >> > >> > -----Original Message----- > >> > From: Danny McPherson [mailto:danny@tcb.net] > >> > Sent: Tuesday, April 01, 2003 2:36 AM > >> > To: pwe3@ietf.org > >> > Subject: [PWE3] AAL12oPSN > >> > > >> > > >> > > >> > Folks, > >> > Shahram has requested that this document be accepted as a WG > >> > item. > >> > > >> > http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-ov > >> > er-psn-01.txt > >> > > >> > Comments please.... > >> > > >> > -danny > >> > > >> > _______________________________________________ > >> > pwe3 mailing list > >> > pwe3@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/pwe3 > >> > > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: What is PWE3 chartered to do? Date: Tue, 1 Apr 2003 11:58:54 -0500 Lines: 78 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F86F.FA5E42D8" Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 19:07:55 2003 Return-path: To: "'George Swallow'" , Peter Willis X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F86F.FA5E42D8 Content-Type: text/plain; charset="iso-8859-1" George: > Peter - > > > I agree with you, MPLS LDP delivers a CNLS service and may deliver > > packets out of order. Therefore if we use PWE3 over MPLS > LDP then we > > have to cater for out of order packets. My concern is if we > used PWE3 > > over MPLS RSVP-TE (or similar) then we would assume packets > would be > > delivered in order and we wouldn't want to bear the cost of the > > re-sequencing mechanism in PWE3. > > The whole point of this discussion on the first nibble is > that if you obey certain rules then most (all?) currently > available P nodes will deliver both the data and associated > OAM in sequence, It will????? News to me. Dave ------_=_NextPart_001_01C2F86F.FA5E42D8 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] What is PWE3 chartered to do?

George:

> Peter -
>
> > I agree with you, MPLS LDP delivers a CNLS service and may deliver 
> > packets out of order. Therefore if we use PWE3 over MPLS
> LDP then we
> > have to cater for out of order packets. My concern is if we
> used PWE3
> > over MPLS RSVP-TE (or similar) then we would assume packets
> would be
> > delivered in order and we wouldn't want to bear the cost of the
> > re-sequencing mechanism in PWE3.
>
> The whole point of this discussion on the first nibble is
> that if you obey certain rules then most (all?) currently
> available P nodes will deliver both the data and associated
> OAM in sequence,

It will????? News to me.

Dave

 

------_=_NextPart_001_01C2F86F.FA5E42D8-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Mandatory Structure Pointer for TDM PWs (was: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt) Date: Tue, 1 Apr 2003 20:08:29 +0300 Lines: 285 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Tue Apr 01 19:14:14 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: Mandatory Structure Pointer for TDM PWs (was: RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt) Thread-Index: AcL4a68xiM80x2pWR2mOjV/ve6KpXgAAFRtQ To: "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31HUgK09136 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, Thanks for your insightful and technically relevant comments. I respond partially below, but due to the late hour here, will respond more fully tomorrow. You will forgice me if I snip a little, in order to make the reading easier. Y(J)S > 1. IMO, no one has really defined what exactly a "mandatory > structure pointer" means. My original statement to the TDM DT was clear, but perhaps not repeated on the list. When transmitting you can choose to send 125 microsec packets, in which case the pointer is identically zero. However, the receiver MUST be able to properly interpret a packet which is not precisely 125 microseconds in length. > a) Play out of the packet payload becomes STATEFUL. > Or, in other words, independent play out of payload of a > single packet is not possible any more. > This is an explicit contradiction both to the TDM requirements > document (draft-ietf-pwe3-tdm-requirements-00.txt, Section 7.3.1) > and to the recommendations of RFC 2736 (which is explicitly > referenced in the PWE3 Charter). The playout is no different then when full-frames are used. When a packet arrives, its contents are appended to a jitter buffer, which is played out independently of the arrival rate. This is not a consequence of using the pointer, this is a requirement for the TDM service which requires timing to be preserved. > Note also that the stateless play out approach has been de-facto > accepted for all the non-TDM PWs: e.g., The other services you detail do not have the real-time constraints of TDM, and hence the comparison is not exact. You can play out ATM cells or FR frames whenever you want, you needn't hold them until their time comes. > b) As a consequence of (a), handling of lost packets becomes > more complicated ( the lost pointer must be reconstructed as > part of this handling) Once again, there is no essential difference between the pointer-free and the pointer-used cases from the data play-out point of view. In both cases, TDM data must be inserted, at least in order to preserve the TDM clock (and perhaps to conceal the packet loss event). In the pointer-free case you have to calculate the number of lost packets times the number of frames per packet times the number of octets per frame, and play-out that number of interpolated octets. In the pointer-used case you have to play out octets until the octet the pointer points to is reached, or alternatively, until the first correctly received octet, which can be determined relative to the pointer by a single subtraction. > > c) The pointer processing must define detection and > handling of the pointer "jumps", i.e., the situations when the > segment between the two pointers cannot be broken into structures of the > specified size. What size? The whole idea of the pointer is to change the "frame-stream" into a byte-stream. You can then use any size you want. > > Note that this situation can be detected when part of the segment > has been already played out, so its handling is non-trivial. > Note also that detection of pointer jumps is stateful and must > cover the situation when one or more INVALID pointers have > been encountered between two valid values. Yes, the problem of an incorrect pointer is a valid one. This is one reason I prefer the draft-anavi method to the draft-johnson one. In draft-anavi the pointer is strongly protected by an error correcting code. > d) If the TDM (or TDM-like) structures are not homogeneous, the fact that > they may be spread between several packets adds to the complexity > of the play out. E.g., if your "CAS signaling" substructure is spread > between two packets, when exactly should it be played out? Another > example could be adding a kind of Path Overhead Monitoring > (POM) function at egress of SONET PWs. The TDM requirements draft does not talk about TDM-like structures, only true TDM structures, which by definition are quite homogenous. > > So much for the cost of a mandatory structure pointer. > > 3. Which problems can be solved with the structure pointer? > AFAIK, using the structure pointer solves one and only one > problem: decoupling between the fixed size of structures > constituting the structured bit-stream payload and fixed size > of the PW packets' payload. That is precisely the idea. > > I can identify three cases when this problem may be encountered: > > a) The TDM structures exceed Path MTU and hence must be > fragmented between several packers. This is definitely NOT > the case for basic (aka without CAS) NxDS0, where the size > of the structure is just N. > I will discuss the case of NxDS0 with CAS below. > (IMO this answers Lloyd's remark.) > > b) The TDM structures take too long to packetize. This > situation is not relevant for basic NxDS0 (just 125 uS > to packetize the structure in question). > I will discuss the case of NxDS0 with CAS below. I don't see either of these cases as being important. The true reason is to allow maximum flexibility in the overhead vs. latency trade-off. > c) The packet payload size must meet some conditions that > stem neither from the nature of the TDM traffic (case "b" above) > nor from the nature of the PSN (case "a" above). Quite the contrary, the reason can be exactly the nature of the PSN. For example, in multi-access wireless applications, there is a strong requirement to completely fill up the packet (since you have no idea how long you will have to wait until getting permission to transmit again). This translates to a precise number of bytes in the payload. Unfortunately, this number of bytes does not correspond to 125 microseconds. I have given several other examples in the past. > > I am aware of exactly one such use case: the declared > "simple interworking" between structured ATM-CES and > CEP-TDM. And I am afraid that, while such limitations > may be NECESSARY, they are NOT SUFFICIENT > for this purpose - a well-known logical error. This really > bothers me because, AFAIK, no one has ever specified > how this "simple interworking" works, i.e. how a stream of > AAL1 cells is converted into CEP-TDM packets and > vice versa - with the same level of detail it has been done > for packetization and de-packetization of TDM streams. I think you should look at Shahram's draft. In any case, as you know the method has been widely deployed and implemented by multiple vendors. This is an existence proof to its definability. > (If somebody wants to know why it is NOT SO SIMPLE, > please consider how loss of an AAL1 cell should be detected > and handled by the packetizer. Somehow no one has > bothered to define this aspect of interworking as if we > are discussing just the "special case" when the ATM-CES > engine resides directly in the PE device. IMO this "special > case" has nothing in common with interworking with ATM-CES. This point too has been discussed at length with regards to Shahram's draft. It is true that using atm-encap with AAL1 is inferior to using draft-anavi when multiple (i.e. 8 or more) cells are lost. > I strongly suspect that if we really look into this issue we shall > find out that the AAL1 sublayer of ATM-CES must be fully > terminated/regenerated for any robust interworking with ATM-CES. > If you take into account that off-the-shelf available HW usually > terminates both AAL1 and ATM-CES sub-layers, simplicity > of a solution that must fully terminate just AAL1 becomes > highly problematic.) Full termination is not required. Once again I refer to draft-davari. > 4. As I have said already, the structures (TDM frames) associated > with the basic NxDS0 are neither long (just N octets) nor take > long time to packetize (just 125 microseconds). > So what about NxDS0 with CAS? The "superframe structure > with signaling" described in draft-johnson is not too long > (up to 588 bytes) but, maybe, it takes too much time > to packetize (2 ms for E1 and 3 ms for T1)? > > IMO this is a MISUNDERSTANDING because the > "superframe structure with signaling" DOES NOT EXIST > anywhere in the TDM traffic. It has been first invented by > the ATM-CES designers because they had to overcome > the limitation of structured AAL1. ( The latter > has been designed to carry streams of structures of > arbitrary, but FIXED size over ATM.) Superframes DO exist in the TDM, and the 2-3 ms only depends on their existence, not on the repetition of the signaling. The signaling substructure is indeed an artificial construct, designed to simplify handling of the fractional E1/T1 case. > These limitations are not relevant for TDM PWs carried > over a PSN. But they are! For many applications (the most notable being CAS) the superframes MUST be preserved. > Yes, there is an important and valid requirement to carry > fixed amount of TDM data per TDM PW packet - > because this allows to generate the correct amount > of "replacement data" if a PW packet has been lost > in a stateless way. And, yes, if you only carry TDM > data in the PW packets, it is equivalent to having the > packet payload size fixed. But if you spread > "superframe structures with signaling" among > several PW packets with fixed payload size you > VIOLATE this requirement (because in the common case > each packet would carry a variable amount of TDM data > and a variable amount of CAS signaling; only the sum > of the two would be fixed). Unfortunately, when sending full frames, but not full superframes, you violate the requirement of being able to reconstruct the TDM information stream (which includes the signaling) based only on the packet. And no one was suggesting spreading signaling substructures over several packets. So there was no reason to set up this strawman just in order to knock it over. > On the other hand, I do not see any problem with a > solution for NxDS0 with CAS that: You don't ? > > a) Carries fixed amount of TDM data (agreed upon at > the PW setup) per PW packet > b) From time to time, appends a CAS signaling substructure > to these packets (so that the packet payload size varies!) This is a clear violation of the principle you keep reminding us about, the reconstruction of the information based only on the present packet. In addition, the loss of the packet with the signaling substructure becomes a much more critical event than the loss of a signal-less packet. > c) Indicates the presence of these substructures in some > way in the PW header (the exact method is TBD). > > Such a mechanism would be compatible with the default > mode for NxDS0 with CAS described in draft-johnson-pwe3-tdm-00.txt > without introducing problems in non-default modes already > discussed at this list. Such a mechanism IS draft-johnson, and is insufficient for the reasons we have discussed at length in the past. 1) It does not robustly carry CAS or CCS signaling 2) It does not enable flexible tradeoff of overhead for latency 3) It does not enable satisfying specific PSN requirement (see above) 4) It needlessly complicates interworking with existing CES which could be accomodated by the mere introduction of a pointer that you need not transmit if you don't need it. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 12:19:30 -0500 Lines: 16 Sender: pwe3-admin@ietf.org References: Cc: "'George Swallow'" , Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue Apr 01 19:24:58 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "David Allan" In-reply-to: Your message of "Tue, 01 Apr 2003 11:58:54 EST." Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > The whole point of this discussion on the first nibble is > > that if you obey certain rules then most (all?) currently > > available P nodes will deliver both the data and associated > > OAM in sequence, > > It will????? News to me. Not if you insist of using label 14. But there are other way to skin the cat! ...George ================================================================== George Swallow Cisco Systems (978) 936-1398 250 Apollo Drive Chelmsford, Ma 01824 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: What is PWE3 chartered to do? Date: Tue, 1 Apr 2003 12:48:52 -0500 Lines: 154 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F876.F58EBEFC" Cc: Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 19:57:03 2003 Return-path: To: "'George Swallow'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F876.F58EBEFC Content-Type: text/plain; charset="iso-8859-1" George: Not parsing this.... if an OAM flow is an IP packet, as LSP-PING is, then is gets forwarded independently of the majority of microflows it potentially represents unless one is actually ICMPinging the microflow destination impersonating the microflow source (whoa). If it is label 14 it has similar problems although not being an IP packet, it cannot impersonate one ;-). If your skinning the cat is a means of transporting OAM protocols hidden from ECMP and without using reserved labels (a la Tom's VCCV proposal when Router Alert label is not employed), doesn't that potentially make all OAM protocols equal (as they can all be smuggled across the network hidden from the OAM evils of ECMP)? And equally irrelevant to IP flows? So what that poor skinless cat represents is that 1) No one has yet codified a layer violation for PWs, give folks time, ECMP based on an Ethernet MAC sec/dest would work wonderfully. 2) OAM is perceived as to only providing benefits to some applications of MPLS. Too bad. cheers Dave > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, April 01, 2003 12:20 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: 'George Swallow'; Peter Willis; neil.2.harrison@bt.com; > pwe3@ietf.org; swallow@cisco.com > Subject: Re: [PWE3] What is PWE3 chartered to do? > > > > > The whole point of this discussion on the first nibble is > > > that if you obey certain rules then most (all?) currently > > > available P nodes will deliver both the data and associated > > > OAM in sequence, > > > > It will????? News to me. > > Not if you insist of using label 14. But there are other way > to skin the cat! > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 936-1398 > 250 Apollo Drive > Chelmsford, Ma 01824 > ------_=_NextPart_001_01C2F876.F58EBEFC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] What is PWE3 chartered to do?

George:

Not parsing this.... if an OAM flow is an IP packet, = as LSP-PING is, then is gets forwarded independently of the majority of = microflows it potentially represents unless one is actually ICMPinging = the microflow destination impersonating the microflow source (whoa). If = it is label 14 it has similar problems although not being an IP packet, = it cannot impersonate one ;-).

If your skinning the cat is a means of transporting = OAM protocols hidden from ECMP and without using reserved labels (a la = Tom's VCCV proposal when Router Alert label is not employed), doesn't = that potentially make all OAM protocols equal (as they can all be = smuggled across the network hidden from the OAM evils of ECMP)? And = equally irrelevant to IP flows?

So what that poor skinless cat represents is = that
1) No one has yet codified a layer violation for = PWs, give folks time, ECMP based on an Ethernet MAC sec/dest would work = wonderfully.

2) OAM is perceived as to only providing benefits to = some applications of MPLS. Too bad.

cheers
Dave

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Tuesday, April 01, 2003 12:20 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'George Swallow'; Peter Willis; = neil.2.harrison@bt.com;
> pwe3@ietf.org; swallow@cisco.com
> Subject: Re: [PWE3] What is PWE3 chartered to = do?
>
>
> > > The whole point of this discussion on = the first nibble is
> > > that if you obey certain rules then = most (all?) currently
> > > available P nodes will deliver both = the data and associated
> > > OAM in sequence,
> >
> > It will????? News to me.
>
> Not if you insist of using label 14.  But = there are other way
> to skin the cat!
>
> ...George
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> George = Swallow       Cisco = Systems           = ;       (978) 936-1398
>          = ;            250 = Apollo Drive
>          = ;            = Chelmsford, Ma 01824
>

------_=_NextPart_001_01C2F876.F58EBEFC-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 13:37:15 -0500 Lines: 24 Sender: pwe3-admin@ietf.org References: Cc: "'George Swallow'" , Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue Apr 01 20:44:04 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "David Allan" In-reply-to: Your message of "Tue, 01 Apr 2003 12:48:52 EST." Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > If your skinning the cat is a means of transporting OAM protocols hidden > from ECMP and without using reserved labels (a la Tom's VCCV proposal when > Router Alert label is not employed), doesn't that potentially make all OAM > protocols equal (as they can all be smuggled across the network hidden from > the OAM evils of ECMP)? And equally irrelevant to IP flows? As far as I know either the inband or the router alert will work with most equipment. (I'd like very much to hear if I'm wrong). The VCCV draft puts the RA label next to the bottom, so if you hash on just the bottom label, you get the same result. > doesn't that potentially make all OAM > protocols equal (as they can all be smuggled across the network hidden from > the OAM evils of ECMP)? Yes! You can get a PPP codepoint (or whatever we end up with) that says the payload is MPLS OAM. ...George ================================================================== George Swallow Cisco Systems (978) 936-1398 250 Apollo Drive Chelmsford, Ma 01824 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: VCCV OAM question Date: Tue, 1 Apr 2003 11:04:13 -0800 Lines: 16 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Tue Apr 01 21:07:23 2003 Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, Would some one (Tom?) explain why can't the LSP-ping be used instead of VCCV for the PW? Thanks, > __________________________________________ > Shahram Davari, B.Eng., M.A.Sc. > Senior Product Research Engineer > PMC_Sierra, Inc. > Tel: (613)271-4018 > Fax: (613)271-6468 > MailTo: Shahram_Davari@pmc-sierra.com > __________________________________________ > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: What is PWE3 chartered to do? Date: Tue, 1 Apr 2003 14:10:21 -0500 Lines: 60 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F882.571DD026" Cc: Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 21:13:46 2003 Return-path: To: "'George Swallow'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F882.571DD026 Content-Type: text/plain; charset="iso-8859-1" Hi Again: > As far as I know either the inband or the router alert will > work with most equipment. (I'd like very much to hear if I'm > wrong). The VCCV draft puts the RA label next to the bottom, > so if you hash on just the bottom label, you get the same result. Why is Router Alert somehow more immune than OAM Alert to the vagarities of ECMP? As an aside, it appears simply to be overloaded as a programmable PID negotiated with signalling (if there's an RA it must be ICMP). Dave ------_=_NextPart_001_01C2F882.571DD026 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] What is PWE3 chartered to do?

Hi Again:

> As far as I know either the inband or the router = alert will
> work with most equipment.  (I'd like very = much to hear if I'm
> wrong).  The VCCV draft puts the RA label = next to the bottom,
> so if you hash on just the bottom label, you = get the same result.

Why is Router Alert somehow more immune than OAM = Alert to the vagarities of ECMP? As an aside, it appears simply to be = overloaded as a programmable PID negotiated with signalling (if there's = an RA it must be ICMP).

Dave

------_=_NextPart_001_01C2F882.571DD026-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 14:14:05 -0500 Lines: 30 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 21:19:05 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Peter Willis , George Swallow In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >George, > >I agree with you, MPLS LDP delivers a CNLS service and may deliver > packets out of order. Therefore if we use PWE3 over MPLS LDP then we > have to >cater for out of order packets. My concern is if we used PWE3 over MPLS >RSVP-TE (or similar) then we would assume packets would be delivered in order >and we wouldn't want to bear the cost of the re-sequencing mechanism in PWE3. There is no free lunch. Setting up fixed tunnels everywhere is not cheap operationally compared to using LDP. But you are an operator and can appreciate that. --Tom >Regards, >Peter. > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 14:14:46 -0500 Lines: 18 Sender: pwe3-admin@ietf.org References: Cc: "'George Swallow'" , Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue Apr 01 21:19:18 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "David Allan" In-reply-to: Your message of "Tue, 01 Apr 2003 14:10:21 EST." Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > As far as I know either the inband or the router alert will > > work with most equipment. (I'd like very much to hear if I'm > > wrong). The VCCV draft puts the RA label next to the bottom, > > so if you hash on just the bottom label, you get the same result. > > Why is Router Alert somehow more immune than OAM Alert to the vagarities of > ECMP? As an aside, it appears simply to be overloaded as a programmable PID > negotiated with signalling (if there's an RA it must be ICMP). Can't speak for others, but we has on the bottom label. Y.1711 says the label goes on the bottom. Has nothing to do with the value. ...George ================================================================== George Swallow Cisco Systems (978) 936-1398 250 Apollo Drive Chelmsford, Ma 01824 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: MPLS PID Date: Tue, 01 Apr 2003 14:17:59 -0500 Lines: 33 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C86D@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Tue Apr 01 21:27:32 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Shahram Davari , "'Lloyd Wood'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C86D@nt-exch-yow.pmc-s ierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > >>The best way to solve this problem is to do ECMP only based on label > >>stack. Doing so should be > >>easier than introducing new standard. > > > > Sharam, it sounds like you are introducing a new standard > >by insisting that ECMP only be based on the label stack. > > > > --Tom > > > >Tom, no I am not standardizing anything. I said, if you are not sure >the payload is IP, you could always use the label stack for ECMP? >After all isn't this what you do in case the payload is not IP? > >In other words there is a way around the problem that you are trying to solve. >Whether you use it or not is up to you. No, the point is that there are lots of ways around the ECMP problem, as is evident from the fact that most vendors do ECMP differently from everyone else. What seems clear to me is that through the use of a PID in the PWE header we can clearly identify what is in the packet regardless of these mechanisms. --Tom >-Shahram http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: MPLS PID Date: Tue, 1 Apr 2003 11:27:18 -0800 Lines: 19 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Tue Apr 01 21:33:42 2003 Return-path: To: "'Thomas D. Nadeau'" , "'Lloyd Wood'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > No, the point is that there are lots of ways around the ECMP >problem, as is evident from the fact that most vendors do ECMP >differently from everyone else. What seems clear to me is that >through the use of a PID in the PWE header we can clearly >identify what is in the packet regardless of these mechanisms. Are you saying you are OK with a generic PID to be added to the PW even though the value 2 & 4 may be used for other purposes than IPv4/6? If so then I retract my comment, but if not so, then I wonder what "regardless of mechanism" means? -Shahram > > --Tom > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: What is PWE3 chartered to do? Date: Tue, 1 Apr 2003 11:31:57 -0800 Lines: 11 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 21:37:59 2003 Return-path: To: "'George Swallow'" , David Allan X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > >Can't speak for others, but we has on the bottom label. Y.1711 says >the label goes on the bottom. Has nothing to do with the value. > George, But as Tom said, shouldn't a generic solution be ECMP implementation independent? -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 14:39:04 -0500 Lines: 14 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C879@nt-exch-yow.pmc-sierra.bc.ca> Cc: "'George Swallow'" , David Allan , Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue Apr 01 21:42:15 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari In-reply-to: Your message of "Tue, 01 Apr 2003 11:31:57 PST." <4B6D09F3B826D411A67300D0B706EFDE0115C879@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > But as Tom said, shouldn't a generic solution be ECMP implementation > independent? It would be nice. But some folks are insisting that they run without PWE headers. And there's some hardware out there that can't inspect newly defined header bits. Otherwise we'd only have the inband solution. ...George ================================================================== George Swallow Cisco Systems (978) 936-1398 250 Apollo Drive Chelmsford, Ma 01824 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: Question regarding draft-ietf-pwe3-control-protocol-02.txt Date: Tue, 1 Apr 2003 12:46:08 -0800 Lines: 26 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Tue Apr 01 22:50:53 2003 Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, I have two questions: 1) What does "followed by " mean here: "- SAII, encoded as a one byte length field followed by the SAI. - TAII, encoded as a one byte length field followed by the TAI. - AGI, encoded as a one byte length field followed by the AGI. " 2) Why isn't the 16-bit SAI=AGI+SAII or TAI=AGI+TAII not sufficient in all cases? and therefore why do we need the PWid FEC? Thanks, > __________________________________________ > Shahram Davari, B.Eng., M.A.Sc. > Senior Product Research Engineer > PMC_Sierra, Inc. > Tel: (613)271-4018 > Fax: (613)271-6468 > MailTo: Shahram_Davari@pmc-sierra.com > __________________________________________ > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: Question regarding draft-ietf-pwe3-control-protocol-02.txt Date: Tue, 01 Apr 2003 16:03:50 -0500 Lines: 9 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C87C@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "'pwe3@ietf.org'" X-From: pwe3-admin@ietf.org Tue Apr 01 23:07:40 2003 Return-path: To: Shahram Davari In-reply-to: Your message of Tue, 01 Apr 2003 12:46:08 -0800. <4B6D09F3B826D411A67300D0B706EFDE0115C87C@nt-exch-yow.pmc-sierra.bc.ca> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > What does "followed by" mean here Field A is "followed by" Field B means that the last byte of Field A immediately precedes the first byte of Field B. > why do we need the PWid FEC? This is discussed at length in draft-rosen-ppvpn-l2-signaling-02.txt. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: Re: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 16:06:35 -0500 Lines: 40 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: George Swallow , neil.2.harrison@bt.com, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue Apr 01 23:11:08 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: George Swallow , Peter Willis In-Reply-To: <200304011628.LAA15323@bifocal.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 11:28 AM 4/1/2003 -0500, George Swallow wrote: >Peter - > > > I agree with you, MPLS LDP delivers a CNLS service and may deliver > > packets out of order. Therefore if we use PWE3 over MPLS LDP then we > have to > > cater for out of order packets. My concern is if we used PWE3 over MPLS > > RSVP-TE (or similar) then we would assume packets would be delivered in > order > > and we wouldn't want to bear the cost of the re-sequencing mechanism in > PWE3. > >The whole point of this discussion on the first nibble is that if you >obey certain rules then most (all?) currently available P nodes will >deliver both the data and associated OAM in sequence, except during a >reroute operation. As Stewart points out, RSVP-TE may also be >disordered during a fast reroute. Either way you have to be prepared >for a few things to be out of order. An if you engineer it right >either approach can offer excellent service. Right. As Eric points out, if you want sequencing, add it to the PWE header and don't worry about the transport misordering. --Tom >...George > >================================================================== >George Swallow Cisco Systems (978) 936-1398 > 250 Apollo Drive > Chelmsford, Ma 01824 >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Question regarding draft-ietf-pwe3-control-protocol-02 .txt Date: Tue, 1 Apr 2003 13:14:57 -0800 Lines: 19 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'pwe3@ietf.org'" X-From: pwe3-admin@ietf.org Tue Apr 01 23:18:30 2003 Return-path: To: "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > >> What does "followed by" mean here > >Field A is "followed by" Field B means that the last >byte of Field A >immediately precedes the first byte of Field B. Shouldn't it be: - SAII, encoded as a one byte length field followed by the SAII (not SAI). - TAII, encoded as a one byte length field followed by the TAII (not TAI). - AGI, encoded as a one byte length field followed by the AGI. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 16:12:55 -0500 Lines: 35 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 23:29:27 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: "David Allan" , "'George Swallow'" , Peter Willis In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 11:58 AM 4/1/2003 -0500, David Allan wrote: >George: > > > Peter - > > > > > I agree with you, MPLS LDP delivers a CNLS service and may deliver > > > packets out of order. Therefore if we use PWE3 over MPLS > > LDP then we > > > have to cater for out of order packets. My concern is if we > > used PWE3 > > > over MPLS RSVP-TE (or similar) then we would assume packets > > would be > > > delivered in order and we wouldn't want to bear the cost of the > > > re-sequencing mechanism in PWE3. > > > > The whole point of this discussion on the first nibble is > > that if you obey certain rules then most (all?) currently > > available P nodes will deliver both the data and associated > > OAM in sequence, > >It will????? News to me. If you don't use special labels (i.e.: label 14) this will work fine. --Tom >Dave > > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: What is PWE3 chartered to do? Date: Tue, 1 Apr 2003 16:31:07 -0500 Lines: 168 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F895.89CE84C6" Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 01 23:34:52 2003 Return-path: To: "'Thomas D. Nadeau'" , "'George Swallow'" , Peter Willis X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F895.89CE84C6 Content-Type: text/plain; charset="iso-8859-1" Tom: I think George clarified that it's not the label value, its the position, at least specifically for the Cisco implementation. I love trying to solve problems in the presence of incomplete information. So any other surprises you folks would care to share? rgds Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, April 01, 2003 4:13 PM > To: Allan, David [CAR:NS00:EXCH]; 'George Swallow'; Peter Willis > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > Subject: RE: [PWE3] What is PWE3 chartered to do? > > > At 11:58 AM 4/1/2003 -0500, David Allan wrote: > > >George: > > > > > Peter - > > > > > > > I agree with you, MPLS LDP delivers a CNLS service and > may deliver > > > > packets out of order. Therefore if we use PWE3 over MPLS > > > LDP then we > > > > have to cater for out of order packets. My concern is if we > > > used PWE3 > > > > over MPLS RSVP-TE (or similar) then we would assume packets > > > would be > > > > delivered in order and we wouldn't want to bear the cost of the > > > > re-sequencing mechanism in PWE3. > > > > > > The whole point of this discussion on the first nibble is that if > > > you obey certain rules then most (all?) currently > available P nodes > > > will deliver both the data and associated OAM in sequence, > > > >It will????? News to me. > > If you don't use special labels (i.e.: label 14) > this will work fine. > > --Tom > > > >Dave > > > > > > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X ------_=_NextPart_001_01C2F895.89CE84C6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] What is PWE3 chartered to do?

Tom:

I think George clarified that it's not the label = value, its the position, at least specifically for the Cisco = implementation.

I love trying to solve problems in the presence of = incomplete information. So any other surprises you folks would care to = share?

rgds
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Tuesday, April 01, 2003 4:13 PM
> To: Allan, David [CAR:NS00:EXCH]; 'George = Swallow'; Peter Willis
> Cc: neil.2.harrison@bt.com; = pwe3@ietf.org
> Subject: RE: [PWE3] What is PWE3 chartered to = do?
>
>
> At 11:58 AM 4/1/2003 -0500, David Allan = wrote:
>
> >George:
> >
> > > Peter -
> > >
> > > > I agree with you, MPLS LDP = delivers a CNLS service and
> may deliver
> > > > packets out of order. Therefore = if we use PWE3 over MPLS
> > > LDP then we
> > > > have to cater for out of order = packets. My concern is if we
> > > used PWE3
> > > > over MPLS RSVP-TE (or similar) = then we would assume packets
> > > would be
> > > > delivered in order and we = wouldn't want to bear the cost of the
> > > > re-sequencing mechanism in = PWE3.
> > >
> > > The whole point of this discussion on = the first nibble is that if
> > > you obey certain rules then most = (all?) currently
> available P nodes
> > > will deliver both the data and = associated OAM in sequence,
> >
> >It will????? News to me.
>
>          If = you don't use special labels (i.e.: label 14)
> this will work fine.
>
>          = --Tom
>
>
> >Dave
> >
> >
>
>
http://www.elsevier-international.com/catalogue/title.= cfm?ISBN=3D155860751X


------_=_NextPart_001_01C2F895.89CE84C6-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Luca Martini Subject: Re: MPLS PID Date: Tue, 01 Apr 2003 14:31:46 -0700 Organization: Level3 Communications LLC. Lines: 83 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Tue Apr 01 23:38:13 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote: > I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network is fundamentally wrong, and is impossible to do for all ECMP implementations such as the one that I described > in earlier emails in which both the first nibble and the CRC are used to detect IP. > Shahram, It might be fundamentally wrong but this is deployed today , and we run our hole network based on this little point. It seems to work fine for a network that transport 90gb/s to 100Gb/s of actual traffic. So if we put the theory, and layer arguments aside , what is the issue with determining that a particular flow is not IP ( assuming IP = 99% of traffic ) ? Luca It might be fundamentally wrong > The best way to solve this problem is to do ECMP only based on label stack. Doing so should be > easier than introducing new standard. > > -Shahram > > > >>-----Original Message----- >>From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] >>Sent: Sunday, March 30, 2003 6:11 PM >>To: Eric Rosen >>Cc: jeremy.de_clercq@alcatel.be; David Allan; 'Scott W Brim'; >>pwe3@ietf.org; mpls@UU.NET >>Subject: Re: [PWE3] MPLS PID >> >> >>On Thu, 27 Mar 2003, Eric Rosen wrote: >> >> >>>1. The only reason for a PID field in MPLS and/or >> >>PWE3 is to allow >> >>> intermediate routers to determine whether a particular >> >>MPLS payload is an >> >>> IP packet or not. >> >>which is a layer violation, and shouldn't be done. >> >> >>> There are a number of reasons why this is useful, and >> >>no one has argued >> >>> that this is not useful. >> >>not appropriate, more like. >> >>if you're going to sniff for an IP packet (so you can sniff TCP/UDP or >>higher) you might want to ask why you even have any form of mpls >>label stack in there in the first place. >> >>if you're not separating out your ip flows via explicit mpls label, >>why not? >> >>L. >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 16:38:38 -0500 Lines: 75 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Tue Apr 01 23:41:54 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: pwe3@ietf.org In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 12:48 PM 4/1/2003 -0500, David Allan wrote: >George: > >Not parsing this.... if an OAM flow is an IP packet, as LSP-PING is, then >is gets forwarded independently of the majority of microflows it >potentially represents unless one is actually ICMPinging the microflow >destination impersonating the microflow source (whoa). If it is label 14 >it has similar problems although not being an IP packet, it cannot >impersonate one ;-). The point of impersonation is to be forwarded through the data plane precisely as the normal data is. Use of a different label *may* change the forwarding behavior depending on ECMP. The current version of LSP Ping for instance, will detect and test all and only all of the actual paths (LSP ECMPs). I don't see how the microflows inside of those ECMPs are relevant, but I might be missing something. >If your skinning the cat is a means of transporting OAM protocols hidden >from ECMP and without using reserved labels (a la Tom's VCCV proposal when >Router Alert label is not employed), doesn't that potentially make all OAM >protocols equal I don't think so. 8) >(as they can all be smuggled across the network hidden from the OAM evils >of ECMP)? And equally irrelevant to IP flows? VCCV is specified in such a way that the test traffic is forwarded precisely as the data would be all the way to the disposition point. Again, in this case, the use of a special label might change ECMP behavior which is what we don't want. --Tom >So what that poor skinless cat represents is that >1) No one has yet codified a layer violation for PWs, give folks time, >ECMP based on an Ethernet MAC sec/dest would work wonderfully. > >2) OAM is perceived as to only providing benefits to some applications of >MPLS. Too bad. >cheers >Dave > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Tuesday, April 01, 2003 12:20 PM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: 'George Swallow'; Peter Willis; neil.2.harrison@bt.com; > > pwe3@ietf.org; swallow@cisco.com > > Subject: Re: [PWE3] What is PWE3 chartered to do? > > > > > > > > The whole point of this discussion on the first nibble is > > > > that if you obey certain rules then most (all?) currently > > > > available P nodes will deliver both the data and associated > > > > OAM in sequence, > > > > > > It will????? News to me. > > > > Not if you insist of using label 14. But there are other way > > to skin the cat! > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 936-1398 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: What is PWE3 chartered to do? Date: Tue, 1 Apr 2003 14:01:27 -0800 Lines: 85 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Wed Apr 02 00:05:16 2003 Return-path: To: "'Thomas D. Nadeau'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > >>If your skinning the cat is a means of transporting OAM >protocols hidden >>from ECMP and without using reserved labels (a la Tom's VCCV >proposal when >>Router Alert label is not employed), doesn't that potentially >make all OAM >>protocols equal > > I don't think so. 8) Why? > >>(as they can all be smuggled across the network hidden from >the OAM evils >>of ECMP)? And equally irrelevant to IP flows? > > VCCV is specified in such a way that the test traffic is >forwarded precisely as the data would be all the way to the disposition >point. Again, in this case, the use of a special label might >change ECMP >behavior which is what we don't want. 1) I think what Dave said is that you could do the same thing you did with VCCV, and signal Y.1711 (without reserved label) and it would fine. 2) Isn't alert label a special reserved label? And wouldn't it change the ECMP behavior of some implementations? -Shahram > > --Tom > > > >>So what that poor skinless cat represents is that >>1) No one has yet codified a layer violation for PWs, give >folks time, >>ECMP based on an Ethernet MAC sec/dest would work wonderfully. >> >>2) OAM is perceived as to only providing benefits to some >applications of >>MPLS. Too bad. >>cheers >>Dave >> >> > -----Original Message----- >> > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Tuesday, April 01, 2003 12:20 PM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: 'George Swallow'; Peter Willis; neil.2.harrison@bt.com; > > pwe3@ietf.org; swallow@cisco.com > > Subject: Re: [PWE3] What is PWE3 chartered to do? > > > > > > > > The whole point of this discussion on the first nibble is > > > > that if you obey certain rules then most (all?) currently > > > > available P nodes will deliver both the data and associated > > > > OAM in sequence, > > > > > > It will????? News to me. > > > > Not if you insist of using label 14. But there are other way > > to skin the cat! > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 936-1398 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: What is PWE3 chartered to do? Date: Tue, 01 Apr 2003 17:05:26 -0500 Lines: 27 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C879@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 00:10:03 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Shahram Davari , "'George Swallow'" , David Allan In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C879@nt-exch-yow.pmc-s ierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 11:31 AM 4/1/2003 -0800, Shahram Davari wrote: > > > >Can't speak for others, but we has on the bottom label. Y.1711 says > >the label goes on the bottom. Has nothing to do with the value. > > > >George, > >But as Tom said, shouldn't a generic solution be ECMP implementation >independent? Please be careful when you paraphrase me. I did not say that we need a generic OAM solution. --Tom >-Shahram >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: What is PWE3 chartered to do? Date: Tue, 1 Apr 2003 14:10:51 -0800 Lines: 13 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 00:16:23 2003 Return-path: To: "'Thomas D. Nadeau'" , "'George Swallow'" , David Allan X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >> >>But as Tom said, shouldn't a generic solution be ECMP implementation >>independent? > > Please be careful when you paraphrase me. I did not say >that we need a generic OAM solution. > > --Tom > Ok, any solution shouldn't be ECMP implementation dependent. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: Re: VCCV OAM question Date: Tue, 01 Apr 2003 17:12:35 -0500 Lines: 34 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C875@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Wed Apr 02 00:17:33 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Shahram Davari , "'pwe3@ietf.org'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C875@nt-exch-yow.pmc-s ierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O One reason is that use of VCCV will get you as close as you can get to the disposition point when using either of the supported PWE3 transports to test a particular VC. Use of just LSP ping may not. The requirements I have gathered from providers have instructed me to get as close as possible (the MPLS OAM requirements also reflect this point). --Tom >Would some one (Tom?) explain why can't the LSP-ping be used instead of >VCCV for the PW? > >Thanks, > > > __________________________________________ > > Shahram Davari, B.Eng., M.A.Sc. > > Senior Product Research Engineer > > PMC_Sierra, Inc. > > Tel: (613)271-4018 > > Fax: (613)271-6468 > > MailTo: Shahram_Davari@pmc-sierra.com > > __________________________________________ > > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: VCCV OAM question Date: Tue, 1 Apr 2003 14:30:33 -0800 Lines: 9 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Wed Apr 02 00:34:07 2003 Return-path: To: "'Thomas D. Nadeau'" , "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >(the MPLS OAM requirements also reflect this >point). > Where in MPLS OAM requirements? And isn't this a PW issue independent of the PSN? -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: VCCV OAM question Date: Tue, 01 Apr 2003 19:24:55 -0500 Lines: 30 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C882@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Wed Apr 02 02:32:16 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Shahram Davari , "'pwe3@ietf.org'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C882@nt-exch-yow.pmc-s ierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 02:30 PM 4/1/2003 -0800, Shahram Davari wrote: > >(the MPLS OAM requirements also reflect this > >point). > > > >Where in MPLS OAM requirements? Packets must flow the way of data packets. >And isn't this a PW issue independent of the PSN? Yes, but when MPLS is the PSN the MPLS requirements apply. I have spoken with L2TP customers that feel the same way, which makes complete sense to me. I suspect your customers will tell you the same. --Tom >-Shahram >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Peter Willis Subject: Re: What is PWE3 chartered to do? Date: Wed, 02 Apr 2003 09:56:08 +0100 Lines: 18 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030401160610.029eca00@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: George Swallow , Peter Willis , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 10:59:20 2003 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: "Thomas D. Nadeau" In-reply-to: Your message of "Tue, 01 Apr 2003 16:06:35 CDT." <5.2.0.9.2.20030401160610.029eca00@bucket.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Right. As Eric points out, if you want sequencing, add it > to the PWE header and don't worry about the transport misordering. > Which is fine if sequencing comes for free. However sequencing does not come for free. It consumes memory & processing. And its also a difficult algorithm to implement correctly (is it still broken in the PWE3 drafts?) --- the problem being telling the difference between misordering, drops & something delayed for a long time, and if you cater for the latter then your delay and jitter targets go out the window. Now if you use MPLS correctly you will only get misordering very infrequently. So if I can use MPLS RSVP-TE (or similar) and not implement the sequencing stuff wouldn't it be lower cost to implement? And wouldn't it give better performance? Peter. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Peter Willis Subject: Re: What is PWE3 chartered to do? Date: Wed, 02 Apr 2003 10:03:43 +0100 Lines: 15 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030401141247.04cd5c28@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Willis , George Swallow , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 11:06:51 2003 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: "Thomas D. Nadeau" In-reply-to: Your message of "Tue, 01 Apr 2003 14:14:05 CDT." <5.2.0.9.2.20030401141247.04cd5c28@bucket.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > There is no free lunch. Setting up fixed tunnels everywhere is not > cheap > operationally compared to using LDP. But you are an operator and can > appreciate > that. As an operator we are well aware of the pros & cons of LDP. Seems to me the tunnel problem is an OSS/config problem where as the resequencing problem is something that has to be done to every packet. My gut feeling is that something that has to be done per tunnel is cheaper than something that has to be done per packet. Peter. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt Date: Wed, 2 Apr 2003 12:40:38 +0200 Lines: 59 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 11:50:57 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, Please see some comments inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Tuesday, April 01, 2003 5:39 PM > To: pwe3@ietf.org > Subject: RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt > > > Tim, > ... snipped ... > > As you well know, draft-johnson with the pointer is only > marginally helpful in allowing interworking with AAL1 networks, > and is in NO WAY related to draf-anavi. > The structure pointer in draft-johnson is only marginally (if at all) helpful for interworking with AAL1 networks. I agree with that, and this is why I do not understand why it should become mandatory. > > However, draft-johnson with no pointer and frame-locking > is EXACTLY CESoPSN !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > Looks like similarity to CESoPSN is your main point of objection. I am ready to accept this as a personal position, but not as a technical one. > > So what you are suggesting is to throw out an obviously > useful feature - the pointer - which allows all known > applications to be supported, ONLY in order to degenerate > to a previously existing (if only marginally deployed) system. > Usefulness of this "feature" is far from obvious to me. Can you give at least one example when using the pointer solves a provider or a customer problem? > ... snipped ... > > Especially not when we are talking about CESoPSN > which has only been marginally deployed, if at all. > Just for the record (this is NOT a technical argument!): Interoperability of independent CESoPSN implementations has been successfully tested between several vendors. In three cases this fact has been publicly announced. > ... snipped to the end ... From owner-mpls@UU.NET Wed Dec 27 16:41:44 2006 From: Curtis Villamizar Subject: Re: [PWE3] MPLS PID Date: Wed, 02 Apr 2003 09:26:07 -0500 Lines: 47 Sender: owner-mpls@UU.NET References: Reply-To: curtis@fictitious.org Cc: "'Dan Tappan'" , Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET X-From: owner-mpls@UU.NET Wed Apr 02 16:41:40 2003 Return-path: To: "David Allan" In-reply-to: Your message of "Tue, 01 Apr 2003 09:15:31 EST." Precedence: bulk Status: O In message , " David Allan" writes: > > If the goal is that ECMP trumps the MPLS architecture, we have a few things > to fix, not just the PID. If the goal is that MPLS must be backwards > compliant with deployed or may be deployed ECMP gear making PW 1st nybbles > == 0 is only a start. Dave, I never knew that MPLS architecture was a religion. I always thought MPLS was deployed and because it solved real world practical problems. Requiring the martinni control word would seem like a no brainer. However maybe we don't buy into that for some **technical** reason, perhaps overhead on the control word in the edge of the network makes a difference. If so, then the control word must be added along the way if the traffic type is known. The only truly deterministic way to know the traffic type is if L3PID tells you. The two common values are IPv4 and MPLS. MPLS essentially means "don't know". The issue comes up when hierarchical LSPs contain more than one LSP of different type and currently the only choice is MPLS. If we add L3PID types of "IP or PWE3 contains control word" or "PWE3 without control word" a control word of "unknown type" can be added at the PSC tunnel ingress and stripped at the PSC tunnel egress. This adding and removing a control word would be a painful solution to swallow but it would be the cleanest solution and would provide *both* low overhead on the edge *and* load split (ECMP) in the core without reordering non-IP flows. Some people want to depricate L3PID but this issue is proving that it may be worth keeping it. This whole argument is predicated on there being a sound reason to make the control word optional. By far the simplest solution is to make implementing the control word a requirement but make enabling the control word optional. This would give the provider the option of lower overhead near the edges *or* ECMP in the core but not both (without risking reordering). Curtis From owner-mpls@UU.NET Wed Dec 27 16:41:44 2006 From: Curtis Villamizar Subject: Re: [PWE3] MPLS PID Date: Wed, 02 Apr 2003 09:34:06 -0500 Lines: 39 Sender: owner-mpls@UU.NET References: <3E8A0542.40603@level3.net> Reply-To: curtis@fictitious.org Cc: Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET X-From: owner-mpls@UU.NET Wed Apr 02 16:56:30 2003 Return-path: To: Luca Martini In-reply-to: Your message of "Tue, 01 Apr 2003 14:31:46 MST." <3E8A0542.40603@level3.net> Precedence: bulk Status: O In message <3E8A0542.40603@level3.net>, Luca Martini writes: > > > Shahram Davari wrote: > > I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network is > fundamentally wrong, and is impossible to do for all ECMP implementations su > ch as the one that I described > > in earlier emails in which both the first nibble and the CRC are used to de > tect IP. > > > Shahram, > It might be fundamentally wrong but this is deployed today , and we run our > hole network based on this little point. It seems to work fine for a network > that transport 90gb/s to 100Gb/s of actual traffic. > > So if we put the theory, and layer arguments aside , what is the issue with > determining that a particular flow is not IP ( assuming IP = 99% of traffic ) > ? > > Luca > > It might be fundamentally wrong > > > > The best way to solve this problem is to do ECMP only based on label stack. > Doing so should be > > easier than introducing new standard. > > > > -Shahram Solving real world problems is never fundamentally wrong. If all traffic is know to be either IP or contain a control word then there is no chance of reorder so its not wrong at all. Curtis From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Dan Tappan Subject: RE: MPLS PID Date: Wed, 02 Apr 2003 10:01:43 -0500 Lines: 44 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Wed Apr 02 17:05:08 2003 Return-path: X-Sender: tappan@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "David Allan" In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 09:15 AM 4/1/2003 -0500, David Allan wrote: >1) are we going to permanently break the paradigm where labels are PIDs?, >because that's where we're headed. IMHO that's fairly fundamental. MPLS >cannot just carry "anything" via signalled convention, because >intermediate boxes are making their own assumptions as to what the payload is. I believe that I addressed this point: I wrote: > As I see it there are two possible approaches: > >1. Require that an LSP set up for an IP L3PID or IP FEC carry IP packets. >2. Allow non-IP packets on such an LSP, but require that they >be distinguishable. The immediate situation is that we have cases where a TE LSP is signalled using L3PID==IP, or an LDP LSP is setup for an IP FEC, but the encapsulated data (under a multi-level label stack) is not IP. You seem to be arguing in favor of [1] - requiring a strict interpretation of the L3PID, which means those packets should never be injected into that LSP. That's an internally consistent model, and it's the one which was used during the arguments which removed the L3PID from the original MPLS encapsulation. Unfortunately it seems to fail the reality test - if there were not operational benefit in violating [1] then we would not be having this discussion. >2) if we codify snooping the first nybble, it still does not fix ECMP >hashing of reserved labels, we're still in the woods. We also hang out to >dry work in PWE3 and other SDOs that are not compliant with this "new" >convention. Either I'm missing your point or this is a red herring. Fundamentally, any ECMP algorithm needs to be designed to avoid misordering flows. If someone implements an algorithm that uses a hash of the label stack then it needs to avoid fields which are not constant for a flow. IF we codify standards which require arbitrarily inserting additional labels into a stack then it can certainly impact an ECMP algorithm which depends on the contents of the stack. So we can have a whole separate argument about whether that is a good idea. BUT, that is all orthogonal to the issue of whether it should-be/needs-to-be possible to distinguish an IP from a non-IP packet on an IP LSP. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: VCCV OAM question Date: Wed, 02 Apr 2003 10:26:47 -0500 Organization: Alcatel Networks Corporaton Lines: 63 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030401192322.029bc0a0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" X-From: pwe3-admin@ietf.org Wed Apr 02 17:34:17 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Thomas D. Nadeau" , Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom and Shahram, I think there are a couple of points in terms of OAM for pseudo-wires: 1. Yes it is important to be able to check connectivity all the way to the PW endpoints. Having said that, I do not think that connectivity verification such as the proposed VCCV is sufficient. Connectivity verification is a pro-active OAM function. We also need to have reactive OAM such as reasonably fast defect indication that will be triggered without having the service provider inject traffic on thousands of PWs. I believe we need to discuss the following: - a defect indication for a PW: in this case we should try to rely as much as possible on the native service OAM capabilities. This is true in the case of same L2 access technology (e.g., ATM-MPLS-ATM). In the case where there is a different L2 access technology (e.g., ATM-MPLS-Ethernet), then each technology will have to rely on its own OAM since the interworking here is at a higher layer. - connectivity verification. - performance monitoring. 2. Correlation of defect states between the PSN and the PW levels. You cannot assume that a PW is just being set up independently of the PSN it is riding on. For example, when a transport LSP is in defect state (whether this is detected through inband or out-of band), there is a need to generate defect indication at the PW level. Mustapha. ---------- "Thomas D. Nadeau" wrote: > At 02:30 PM 4/1/2003 -0800, Shahram Davari wrote: > > > >(the MPLS OAM requirements also reflect this > > >point). > > > > > > >Where in MPLS OAM requirements? > > Packets must flow the way of data > packets. > > >And isn't this a PW issue independent of the PSN? > > Yes, but when MPLS is the PSN the MPLS > requirements apply. I have spoken with L2TP customers > that feel the same way, which makes complete > sense to me. I suspect your customers will tell you the > same. > > --Tom > > >-Shahram > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: Re: VCCV OAM question Date: Wed, 02 Apr 2003 10:49:35 -0500 Lines: 92 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030401192322.029bc0a0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'pwe3@ietf.org'" X-From: pwe3-admin@ietf.org Wed Apr 02 17:52:34 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Mustapha Aissaoui , Shahram Davari In-Reply-To: <3E8B0137.E55CA0C2@alcatel.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >Tom and Shahram, >I think there are a couple of points in terms of OAM for pseudo-wires: > >1. Yes it is important to be able to check connectivity all the way to the PW >endpoints. Having said that, I do not think that connectivity verification >such as the proposed VCCV is sufficient. Connectivity verification is a >pro-active OAM function. We also need to have reactive OAM such as reasonably >fast defect indication that will be triggered without having the service >provider inject traffic on thousands of PWs. As I pointed out during the meeting, we are not proposing VCCV as the be-all-end-all to OAM for PWE3. It is just one diagnostic mechanism in the quiver of OAM tools for PWE3 as is LSP ping and native end-to-end OAM that is passed transparently over the PWs. When these are used in combination, we get a complete solution. >I believe we need to discuss the following: >- a defect indication for a PW: in this case we should try to rely as much as >possible on the native service OAM capabilities. I totally agree with you. I think that native capabilities used in conjunction with mechanisms like LSP ping/VCCV to bridge the gaps make for a complete solution. This should also make those architectural purists happy as well, since we make separate tools/functions for each piece of the network and then determine how each works together instead of trying to design the OAM swiss army knife, as has been proposed elsewhere. We also describe how to bridge these gaps in the OAM message mapping draft. >This is true in the case of >same L2 access technology (e.g., ATM-MPLS-ATM). In the case where there is a >different L2 access technology (e.g., ATM-MPLS-Ethernet), then each >technology will have to rely on its own OAM since the interworking here is at >a higher layer. >- connectivity verification. >- performance monitoring. > >2. Correlation of defect states between the PSN and the PW levels. You cannot >assume that a PW is just being set up independently of the PSN it is riding >on. For example, when a transport LSP is in defect state (whether this is >detected through inband or out-of band), there is a need to generate defect >indication at the PW level. Yes, I agree. Again, this is why message mapping between the PSN, PWs and the native services is important. --Tom >Mustapha. >---------- >"Thomas D. Nadeau" wrote: > > > At 02:30 PM 4/1/2003 -0800, Shahram Davari wrote: > > > > > >(the MPLS OAM requirements also reflect this > > > >point). > > > > > > > > > >Where in MPLS OAM requirements? > > > > Packets must flow the way of data > > packets. > > > > >And isn't this a PW issue independent of the PSN? > > > > Yes, but when MPLS is the PSN the MPLS > > requirements apply. I have spoken with L2TP customers > > that feel the same way, which makes complete > > sense to me. I suspect your customers will tell you the > > same. > > > > --Tom > > > > >-Shahram > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "himanshu shah" Subject: RE: VCCV OAM question Date: Wed, 2 Apr 2003 11:04:58 -0500 Lines: 98 Sender: pwe3-admin@ietf.org References: <3E8B0137.E55CA0C2@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Wed Apr 02 18:07:55 2003 Return-path: To: "'Mustapha Aissaoui'" , "'Thomas D. Nadeau'" , "'Shahram Davari'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E8B0137.E55CA0C2@alcatel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O There is a proposal to extend PWE3 control signaling to notify VC status to the remote peer. The VC status could either be attachment circuit or head end PW status or both. There are two aspects of VC status 1) generation - based on attachment circuit or head end PW 2) processing of received status - propagating it to attachment circuit - pkt processing action on incoming PW Please refer to draft-shah-pwe3-control-protocol-extension-00.txt. /himanshu -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Mustapha Aissaoui Sent: Wednesday, April 02, 2003 10:27 AM To: Thomas D. Nadeau; Shahram Davari Cc: 'pwe3@ietf.org' Subject: Re: [PWE3] VCCV OAM question Tom and Shahram, I think there are a couple of points in terms of OAM for pseudo-wires: 1. Yes it is important to be able to check connectivity all the way to the PW endpoints. Having said that, I do not think that connectivity verification such as the proposed VCCV is sufficient. Connectivity verification is a pro-active OAM function. We also need to have reactive OAM such as reasonably fast defect indication that will be triggered without having the service provider inject traffic on thousands of PWs. I believe we need to discuss the following: - a defect indication for a PW: in this case we should try to rely as much as possible on the native service OAM capabilities. This is true in the case of same L2 access technology (e.g., ATM-MPLS-ATM). In the case where there is a different L2 access technology (e.g., ATM-MPLS-Ethernet), then each technology will have to rely on its own OAM since the interworking here is at a higher layer. - connectivity verification. - performance monitoring. 2. Correlation of defect states between the PSN and the PW levels. You cannot assume that a PW is just being set up independently of the PSN it is riding on. For example, when a transport LSP is in defect state (whether this is detected through inband or out-of band), there is a need to generate defect indication at the PW level. Mustapha. ---------- "Thomas D. Nadeau" wrote: > At 02:30 PM 4/1/2003 -0800, Shahram Davari wrote: > > > >(the MPLS OAM requirements also reflect this > > >point). > > > > > > >Where in MPLS OAM requirements? > > Packets must flow the way of data > packets. > > >And isn't this a PW issue independent of the PSN? > > Yes, but when MPLS is the PSN the MPLS > requirements apply. I have spoken with L2TP customers > that feel the same way, which makes complete > sense to me. I suspect your customers will tell you the > same. > > --Tom > > >-Shahram > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Mandatory Structure Pointer for TDM PWs (was: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt) Date: Wed, 2 Apr 2003 19:26:30 +0200 Lines: 393 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 18:37:13 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, Thank you for a really prompt response. Please see some comments inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Tuesday, April 01, 2003 7:08 PM > To: Sasha Vainshtein > Cc: pwe3@ietf.org > Subject: RE: Mandatory Structure Pointer for TDM PWs (was: > RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt) > > > Sasha, > > Thanks for your insightful and technically relevant comments. > ... snipped ... > > You will forgive me if I snip a little, > in order to make the reading easier. > OK with me (even if you have forgotten to mark your snips...) > > Y(J)S > > > > 1. IMO, no one has really defined what exactly a "mandatory > > structure pointer" means. > > My original statement to the TDM DT was clear, but perhaps > not repeated on the list. > When transmitting you can choose to send 125 microsec > packets, in which case the pointer is identically zero. > > However, the receiver MUST be able to properly interpret > a packet which is not precisely 125 microseconds in length. > Sorry, but I do not see "not precisely 125 microseconds" as a technical specification. > > > > a) Play out of the packet payload becomes STATEFUL. > > Or, in other words, independent play out of payload of a > > single packet is not possible any more. > > This is an explicit contradiction both to the TDM > requirements > > document (draft-ietf-pwe3-tdm-requirements-00.txt, > Section 7.3.1) > > and to the recommendations of RFC 2736 (which is explicitly > > referenced in the PWE3 Charter). > > The playout is no different then when full-frames are used. > When a packet arrives, its contents are appended to a jitter buffer, > which is played out independently of the arrival rate. > If you imply that pointers can be ignored at playout of packets, then why should anybody bother to put them in? If they are not ignored (as I suspect), then their processing must be defined. I do not see this definition in your text. > ... snipped... > > > b) As a consequence of (a), handling of lost packets becomes > > more complicated ( the lost pointer must be > reconstructed as > > part of this handling) > > Once again, there is no essential difference between > the pointer-free and the pointer-used cases > from the data play-out point of view. > > In both cases, TDM data must be inserted, > at least in order to preserve the TDM clock > (and perhaps to conceal the packet loss event). > > In the pointer-free case you have to calculate the > number of lost packets times the number of frames per packet > times the number of octets per frame, and play-out that > number of interpolated octets. > > In the pointer-used case you have to play out octets > until the octet the pointer points to is reached, > or alternatively, until the first correctly received octet, > which can be determined relative to the pointer by a single > subtraction. > AFAIK, in emulation of NxDS0 you do not play out "octets": you play out frames, i.e. you take care to play out N octets that have been received, each from its specific DS0 channel, in the same 125 microseconds frame at ingress within the same 125 microseconds frame at egress; and you take care that each packet goes to its appropriate DS0 channel as well. This is called "frame integrity", and NxDS0 emulation MUST preserve that. If the packet is aligned with the NxDS0 frames, your playout and replacement (in the case of packet loss) are simple. If the packet is NOT aligned with NxDS0 frames, you must handle incomplete frames at two ends of the packet; the incomplete frame from the last received packet becomes the state for playing out the next one. And if you cannot "glue" the incomplete frame at the end of the previous packet with the incomplete frame at the start of the next one into a single frame, you have a problem. > > > c) The pointer processing must define detection and > > handling of the pointer "jumps", i.e., the situations when the > > segment between the two pointers cannot be broken into > structures of the > > specified size. > > What size? The whole idea of the pointer > is to change the "frame-stream" into a byte-stream. > You can then use any size you want. > You may be surprised, but structured TDM emulation is about preserving structures across the PSN, and these structures have size, and you do not have much control over it. E.g., the structure to be preserved for emulation of NxDS0 is a single TDM frame, and its size is N. We may have different opinions wrt the structure that must be preserved for emulation of NxDS0 with CAS, and it is worth to specify it explicitly. > > ... snipped... > > Yes, the problem of an incorrect pointer is a valid one. > > This is one reason I prefer the draft-anavi method to the > draft-johnson one. > In draft-anavi the pointer is strongly protected by an error > correcting code. > AFAIK draft-anavi does not define pointer processing. It relegates this to structured AAL1. And, BTW, adding an even parity bit to a 7-bit AAL1 pointer does not enable any error correction. > > > d) If the TDM (or TDM-like) structures are not > > homogeneous, the fact that > > they may be spread between several packets adds to >> the complexity > > of the play out. E.g., if your "CAS signaling" > > substructure is spread > > between two packets, when exactly should it be > > played out? Another > > example could be adding a kind of Path Overhead Monitoring > > (POM) function at egress of SONET PWs. > > The TDM requirements draft does not talk about TDM-like structures, > only true TDM structures, which by definition are quite homogenous. > Is the "superframe structure with signaling" homogeneous? I agree, though, that it is neither part of the TDM stream nor is mentioned in the TDM requirements draft... > > > > > So much for the cost of a mandatory structure pointer. > > > > 3. Which problems can be solved with the structure pointer? ... snipped ... > > I can identify three cases when this problem may be encountered: > > > > a) The TDM structures exceed Path MTU and hence must be > > fragmented between several packers. This is definitely NOT > > the case for basic (aka without CAS) NxDS0, where the size > > of the structure is just N. > > I will discuss the case of NxDS0 with CAS below. > > (IMO this answers Lloyd's remark.) > > > > b) The TDM structures take too long to packetize. This > > situation is not relevant for basic NxDS0 (just 125 uS > > to packetize the structure in question). > > I will discuss the case of NxDS0 with CAS below. > > I don't see either of these cases as being important. > The first case is definitely encountered with SONET emulation. And that is (AFAIK) the source of the structure pointer in draft-johnson. > > The true reason is to allow maximum flexibility > in the overhead vs. latency trade-off. > I believe you do NOT imply that, for NxDS0, the single byte granularity of the packet size is that much more flexible than the granulalrity of N bytes? > > > c) The packet payload size must meet some conditions that > > stem neither from the nature of the TDM traffic > (case "b" above) > > nor from the nature of the PSN (case "a" above). > > Quite the contrary, the reason can be exactly the nature of the PSN. > For example, in multi-access wireless applications, there is > a strong requirement > to completely fill up the packet (since you have no idea how long you > will have to wait until getting permission to transmit again). > How do you run IP/MPLS over such a network? Do you pad all your IP packets (e.g., TCP ACKs) to the full packet? How do you run FRoPSN over such a network? The Martini CW supports only padding to 64 bytes, right? IMO, something is fundamentally wrong with your example. > ... snipped ... > > > > > I am aware of exactly one such use case: the declared > > "simple interworking" between structured ATM-CES and > > CEP-TDM. And I am afraid that, while such limitations > > may be NECESSARY, they are NOT SUFFICIENT > > for this purpose - a well-known logical error. This really > > bothers me because, AFAIK, no one has ever specified > > how this "simple interworking" works, i.e. how a stream of > > AAL1 cells is converted into CEP-TDM packets and > > vice versa - with the same level of detail it has been done > > for packetization and de-packetization of TDM streams. > > I think you should look at Shahram's draft. > Shahram's draft defines ONLY a method to carry AAL1 cell streams over PSN. And, BTW, I am OK with this method for this application. > > In any case, as you know the method has been widely deployed > and implemented by multiple vendors. > This is an existence proof to its definability. > As I have said already, draft-anavi does not define any pointer processing: it relegates it to AAL1. And, AFAIK, draft-johnson has NEVER been implemented. Hence I doubt that your "proof of definability by existence" is applicable and think that the definition must be present in the spec. > > > (If somebody wants to know why it is NOT SO SIMPLE, > > please consider how loss of an AAL1 cell should be detected > > and handled by the packetizer. Somehow no one has > > bothered to define this aspect of interworking as if we > > are discussing just the "special case" when the ATM-CES > > engine resides directly in the PE device. IMO this "special > > case" has nothing in common with interworking with ATM-CES. > > This point too has been discussed at length with regards to > Shahram's draft. > I suggest you take a careful look at Shahram's draft: it does not say anything at all about it. > > It is true that using atm-encap with AAL1 is inferior to > using draft-anavi > when multiple (i.e. 8 or more) cells are lost. > AFAIK, atm-encap and draft-anavi discuss two different things: one deals with ATM cell streams while the other - with TDM. So your comparison is totally out of context. > > > I strongly suspect that if we really look into this > issue we shall > > find out that the AAL1 sublayer of ATM-CES must be fully > > terminated/regenerated for any robust interworking > with ATM-CES. > > If you take into account that off-the-shelf > available HW usually > > terminates both AAL1 and ATM-CES sub-layers, simplicity > > of a solution that must fully terminate just AAL1 becomes > > highly problematic.) > > Full termination is not required. > Once again I refer to draft-davari. > You can refer to draft-davari as much as you wish: it does not say ANYTHING on the subject. It simply explains how the ATM-ENCAP mentod can be applied to AAL1 cell streams. > > > 4. As I have said already, the structures (TDM frames) associated > > with the basic NxDS0 are neither long (just N octets) nor take > > long time to packetize (just 125 microseconds). > > So what about NxDS0 with CAS? The "superframe structure > > with signaling" described in draft-johnson is not too long > > (up to 588 bytes) but, maybe, it takes too much time > > to packetize (2 ms for E1 and 3 ms for T1)? > > > > IMO this is a MISUNDERSTANDING because the > > "superframe structure with signaling" DOES NOT EXIST > > anywhere in the TDM traffic. It has been first invented by > > the ATM-CES designers because they had to overcome > > the limitation of structured AAL1. ( The latter > > has been designed to carry streams of structures of > > arbitrary, but FIXED size over ATM.) > > Superframes DO exist in the TDM, > and the 2-3 ms only depends on their existence, > not on the repetition of the signaling. > > The signaling substructure is indeed an artificial > construct, designed to simplify handling of the fractional > E1/T1 case. > I agree with your position presented on this list that there is no need to preserve MF strcutures because native TDM equipment (DS0 cross-connect) does not preserve them. So, let's do the following evident step and ask: Why should we try to carry "artifical constructs" over PSN? > > > These limitations are not relevant for TDM PWs carried > > over a PSN. > > But they are! For many applications (the most notable being CAS) > the superframes MUST be preserved. > I think that you contradict yourself (see above) wrt preservation of MF. And the limitations I have been speaking about have been ones of AAL1, not of TDM. But if we must preserve MF synchronization - which I doubt - then I would ask: " what is the best way to do that?" > > > Yes, there is an important and valid requirement to carry > > fixed amount of TDM data per TDM PW packet - > > because this allows to generate the correct amount > > of "replacement data" if a PW packet has been lost > > in a stateless way. And, yes, if you only carry TDM > > data in the PW packets, it is equivalent to having the > > packet payload size fixed. But if you spread > > "superframe structures with signaling" among > > several PW packets with fixed payload size you > > VIOLATE this requirement (because in the common case > > each packet would carry a variable amount of TDM data > > and a variable amount of CAS signaling; only the sum > > of the two would be fixed). > > Unfortunately, when sending full frames, > but not full superframes, you violate the requirement > of being able to reconstruct the TDM information stream > (which includes the signaling) based only on the packet. > Glad to know that this requirement is important to you. And no, it is not violated. Please re-read the text in the original email. > > And no one was suggesting spreading signaling substructures > over several packets. So there was no reason to set up this > strawman just in order to knock it over. > The issue is not what is someone suggesting. The question is what is (or is not) defined. The current revision of draft-johnson does not provide any guidelines for generation of packets in non-default modes. This is the place that definetely needs clarification to avoid misinterpretation problems. And this MUST be done before requesting that the structure pointer becomes mandatory. So this may be a strawman, but I did not set it up; rather, you did (and still do) by requesting the pointer being mandatory. > > > On the other hand, I do not see any problem with a > > solution for NxDS0 with CAS that: > > You don't ? > > > > a) Carries fixed amount of TDM data (agreed upon at > > the PW setup) per PW packet > > b) From time to time, appends a CAS signaling substructure > > to these packets (so that the packet payload size varies!) > > This is a clear violation of the principle you keep reminding us > about, the reconstruction of the information based only > on the present packet. > I have answered this already. I think that the proposal is clear enough. > > In addition, the loss of the packet with the signaling > substructure becomes a much more critical event > than the loss of a signal-less packet. > No it is not - depends on how often you send your packets with the signaling substructure. > ... snipped ... > > 4) It needlessly complicates interworking with existing CES > which could be accomodated by the mere introduction of a pointer > that you need not transmit if you don't need it. > Which CES? I believe you have said in a previous mail that the pointer only marginally helps in interworking with ATM-CES. > > From owner-mpls@UU.NET Wed Dec 27 16:41:44 2006 From: "James R. Leu" Subject: Re: [PWE3] MPLS PID Date: Wed, 2 Apr 2003 12:34:11 -0600 Organization: none Lines: 69 Sender: owner-mpls@UU.NET References: <4.3.2.7.2.20030402093708.09931ca8@pilgrim.cisco.com> Reply-To: jleu@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Allan , Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET X-From: owner-mpls@UU.NET Wed Apr 02 18:49:42 2003 Return-path: To: Dan Tappan X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.2.20030402093708.09931ca8@pilgrim.cisco.com>; from tappan@cisco.com on Wed, Apr 02, 2003 at 10:01:43AM -0500 Precedence: bulk Status: O I've been quietly following this thread, but I would like to add my $.02(US). One of the proposed solutions to this problem is to add a 4 bit nibble after the label stack. What if we trimmed it to 3 bits and threw it in the bottom most labels EXP bits? A side effect of this is that networks that utilized hierarchical E-LSPs would be forced to convert the inner LSPs to L-LSPs. Although I thought at one point EXP bits were being "promoted" to the outer most label, but I'd have to go back add read the diffserv draft to verify. If this were still the case then this would free up the EXP bits for all labels below the top of the stack (thus alleviating the necessity to convert inner E-LSPs to L-LSPs). Even if EXP bits are not being "promoted" forcing networks to switch to L-LSPs I think is a minimal cost to gain a finer granularity of ECMP. Some might consider it a hack some might consider it an optimization, I like to think of it as a compromise ;-) Jim On Wed, Apr 02, 2003 at 10:01:43AM -0500, Dan Tappan wrote: > At 09:15 AM 4/1/2003 -0500, David Allan wrote: > > >1) are we going to permanently break the paradigm where labels are PIDs?, > >because that's where we're headed. IMHO that's fairly fundamental. MPLS > >cannot just carry "anything" via signalled convention, because > >intermediate boxes are making their own assumptions as to what the payload is. > > I believe that I addressed this point: > I wrote: > > As I see it there are two possible approaches: > > > >1. Require that an LSP set up for an IP L3PID or IP FEC carry IP packets. > >2. Allow non-IP packets on such an LSP, but require that they > >be distinguishable. > > The immediate situation is that we have cases where a TE LSP is signalled > using L3PID==IP, or an LDP LSP is setup for an IP FEC, but the encapsulated > data (under a multi-level label stack) is not IP. > > You seem to be arguing in favor of [1] - requiring a strict interpretation > of the L3PID, which means those packets should never be injected into that > LSP. That's an internally consistent model, and it's the one which was used > during the arguments which removed the L3PID from the original MPLS > encapsulation. Unfortunately it seems to fail the reality test - if there > were not operational benefit in violating [1] then we would not be having > this discussion. > > >2) if we codify snooping the first nybble, it still does not fix ECMP > >hashing of reserved labels, we're still in the woods. We also hang out to > >dry work in PWE3 and other SDOs that are not compliant with this "new" > >convention. > > Either I'm missing your point or this is a red herring. Fundamentally, any > ECMP algorithm needs to be designed to avoid misordering flows. If someone > implements an algorithm that uses a hash of the label stack then it needs > to avoid fields which are not constant for a flow. IF we codify standards > which require arbitrarily inserting additional labels into a stack then it > can certainly impact an ECMP algorithm which depends on the contents of the > stack. So we can have a whole separate argument about whether that is a > good idea. > > BUT, that is all orthogonal to the issue of whether it > should-be/needs-to-be possible to distinguish an IP from a non-IP packet on > an IP LSP. > -- James R. Leu From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: MPLS PID Date: Wed, 2 Apr 2003 11:55:01 -0500 Lines: 115 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F938.99B58490" Cc: "'Dan Tappan'" , Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Wed Apr 02 18:59:23 2003 Return-path: To: "'curtis@fictitious.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F938.99B58490 Content-Type: text/plain; charset="iso-8859-1" Curtis: > I never knew that MPLS architecture was a religion. I always > thought MPLS was deployed and because it solved real world > practical problems. The above seems to be orthogonal to the discussion at hand :-( > > Requiring the martinni control word would seem like a no > brainer. However maybe we don't buy into that for some > **technical** reason, perhaps overhead on the control word in > the edge of the network makes a difference. If so, then the > control word must be added along the way if the traffic type is known. My comment was more along the lines that if we accept ECMP as defacto, then we have more to do than simply making sure PWs do not occasionally re-order. IMHO it may solve some problems but would still be a major obstacle to solving others. > > The only truly deterministic way to know the traffic type is > if L3PID tells you. Yes, but as you note, that information is on a need to know basis and you still end up inserting a dummy control word for those folks in the core that will not be privy to this information. The core still expects stuff to self identify. BTW I presume you're exclusively discussing TE L3PID? cheers Dave ------_=_NextPart_001_01C2F938.99B58490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] MPLS PID

Curtis:


> I never knew that MPLS architecture was a = religion.  I always
> thought MPLS was deployed and because it solved = real world
> practical problems.

The above seems to be orthogonal to the discussion at = hand :-(

>
> Requiring the martinni control word would seem = like a no
> brainer. However maybe we don't buy into that = for some
> **technical** reason, perhaps overhead on the = control word in
> the edge of the network makes a = difference.  If so, then the
> control word must be added along the way if the = traffic type is known.

My comment was more along the lines that if we accept = ECMP as defacto, then we have more to do than simply making sure PWs do = not occasionally re-order. IMHO it may solve some problems but would = still be a major obstacle to solving others.


>
> The only truly deterministic way to know the = traffic type is
> if L3PID tells you. 

Yes, but as you note, that information is on a need = to know basis and you still end up inserting a dummy control word for = those folks in the core that will not be privy to this information. The = core still expects stuff to self identify.

BTW I presume you're exclusively discussing TE = L3PID?

cheers
Dave

------_=_NextPart_001_01C2F938.99B58490-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: MPLS PID Date: Wed, 2 Apr 2003 11:55:45 -0500 Lines: 262 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F938.B4027560" Cc: Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Wed Apr 02 19:01:42 2003 Return-path: To: "'Dan Tappan'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F938.B4027560 Content-Type: text/plain; charset="iso-8859-1" Hi Dan: > >1) are we going to permanently break the paradigm where labels are > >PIDs?, > >because that's where we're headed. IMHO that's fairly > fundamental. MPLS > >cannot just carry "anything" via signalled convention, because > >intermediate boxes are making their own assumptions as to > what the payload is. > > I believe that I addressed this point: > I wrote: > > As I see it there are two possible approaches: > > > >1. Require that an LSP set up for an IP L3PID or IP FEC carry IP > >packets. 2. Allow non-IP packets on such an LSP, but > require that they > >be distinguishable. In other words all traffic on an MPLS network must "self identify". Only scenario where this is not true would be a TE tunnel set up with a non IP PID. > > The immediate situation is that we have cases where a TE LSP > is signalled > using L3PID==IP, or an LDP LSP is setup for an IP FEC, but > the encapsulated > data (under a multi-level label stack) is not IP. Yes. > You seem to be arguing in favor of [1] - requiring a strict > interpretation > of the L3PID, which means those packets should never be > injected into that > LSP. The L3 PID only really exists for TE tunnels. Strict interpretation would seem to undermine any utility in having a label stack. I'm not arguing in favor of that.... > That's an internally consistent model, and it's the one > which was used > during the arguments which removed the L3PID from the original MPLS > encapsulation. Unfortunately it seems to fail the reality > test - if there > were not operational benefit in violating [1] then we would > not be having > this discussion. > > >2) if we codify snooping the first nybble, it still does not fix ECMP > >hashing of reserved labels, we're still in the woods. We > also hang out to > >dry work in PWE3 and other SDOs that are not compliant with > this "new" > >convention. > > Either I'm missing your point or this is a red herring. Q1: Are we fixing misordering of PW payloads, or are we fixing misordering of PW LSPs? Q2: The SONET PWE3 draft, ATMF-AIC-178 etc. are all broken if we assume the payload must self identify as an IPv4 packet or not. > Fundamentally, any ECMP algorithm needs to be designed to avoid misordering > flows. If someone implements an algorithm that uses a hash of the label stack > then it needs to avoid fields which are not constant for a flow. Which was proposed in the "guidelines for load balancing" draft and rejected by the WG. > IF we > codify standards > which require arbitrarily inserting additional labels into a > stack then it > can certainly impact an ECMP algorithm which depends on the > contents of the > stack. So we can have a whole separate argument about whether > that is a > good idea. Sounds like we are not arguing ;-) > > BUT, that is all orthogonal to the issue of whether it > should-be/needs-to-be possible to distinguish an IP from a > non-IP packet on > an IP LSP. I stick by my assertion that its only part of the solution to the overall problem cheers Dave ------_=_NextPart_001_01C2F938.B4027560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] MPLS PID

Hi Dan:

> >1) are we going to permanently break the = paradigm where labels are
> >PIDs?,
> >because that's where we're headed. IMHO = that's fairly
> fundamental. MPLS
> >cannot just carry "anything" via = signalled convention, because
> >intermediate boxes are making their own = assumptions as to
> what the payload is.
>
> I believe that I addressed this point:
> I wrote:
> >  As I see it there are two possible = approaches:
> >
> >1. Require that an LSP set up for an IP = L3PID or IP FEC carry  IP
> >packets. 2. Allow non-IP packets on such an = LSP, but 
> require that they
> >be  distinguishable.

In other words all traffic on an MPLS network must = "self identify". Only scenario where this is not true would = be a TE tunnel set up with a non IP PID.

>
> The immediate situation is that we have cases = where a TE LSP
> is signalled
> using L3PID=3D=3DIP, or an LDP LSP is setup for = an IP FEC, but
> the encapsulated
> data (under a multi-level label stack) is not = IP.

Yes.

> You seem to be arguing in favor of [1] - = requiring a strict
> interpretation
> of the L3PID, which means those packets should = never be
> injected into that
> LSP.

The L3 PID only really exists for TE tunnels. Strict = interpretation would seem to undermine any utility in having a label = stack. I'm not arguing in favor of that....

> That's an internally consistent model, and it's = the one
> which was used
> during the arguments which removed the L3PID = from the original MPLS
> encapsulation. Unfortunately it seems to fail = the reality
> test - if there
> were not operational benefit in violating [1] = then we would
> not be having
> this discussion.
>
> >2) if we codify snooping the first nybble, = it still does not fix ECMP
> >hashing of reserved labels, we're still in = the woods. We
> also hang out to
> >dry work in PWE3 and other SDOs that are = not compliant with
> this "new"
> >convention.
>
> Either I'm missing your point or this is a red = herring.

Q1: Are we fixing misordering of PW payloads, or are = we fixing misordering of PW LSPs?
Q2: The SONET PWE3 draft, ATMF-AIC-178 etc. are all = broken if we assume the payload must self identify as an IPv4 packet or = not.

> Fundamentally, any ECMP algorithm needs to be = designed to avoid misordering
> flows. If someone implements an algorithm that = uses a hash of the label stack
> then it needs to avoid fields which are not = constant for a flow.

Which was proposed in the "guidelines for load = balancing" draft and rejected by the WG.

> IF we
> codify standards
> which require arbitrarily inserting additional = labels into a
> stack then it
> can certainly impact an ECMP algorithm which = depends on the
> contents of the
> stack. So we can have a whole separate argument = about whether
> that is a
> good idea.

Sounds like we are not arguing ;-)

>
> BUT, that is all orthogonal to the issue of = whether it
> should-be/needs-to-be possible to distinguish = an IP from a
> non-IP packet on
> an IP LSP.

I stick by my assertion that its only part of the = solution to the overall problem

cheers
Dave

------_=_NextPart_001_01C2F938.B4027560-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 requirements draft, version 5 Date: Wed, 02 Apr 2003 12:19:02 -0500 Organization: Alcatel Networks Corporaton Lines: 72 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Xipeng Xiao , pwe3@ietf.org, "Thomas D. Nadeau" X-From: pwe3-admin@ietf.org Wed Apr 02 19:24:50 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Akiva Sadovski Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Akiva, sorry for this late reply but I a catching up with my emails. See below. Mustapha. ----------- Akiva Sadovski wrote: > Mustapha, Xipeng and all, > > About: > > > > > Section 5.3: paragraph 8, last sentence says: "If a PE needs to > > > > generate and send a maintenance message to a remote PE, the > > > > maintenance message MUST be sent via the control plane, > > not via the > > > > PW" > > IMHO maintenance information may be passed from PE to PE not only in > separate messages > but also via CW bits (f.ex. N and P bits in draft-ietf-pwe3-sonet-01). > Should this kind of > communication be restricted or prohibited ? I doubt... > > Have i missed something ? If is is in the control word, then I would assume it is inband since the maintenance information is sent within the same channel as the user information. > > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Wednesday, March 19, 2003 8:26 PM > > To: Xipeng Xiao > > Cc: pwe3@ietf.org; Thomas D. Nadeau > > Subject: Re: [PWE3] PWE3 requirements draft, version 5 > > > > > > Xipeng, > > when OAM messages are sent inband, they travel within the PW. You > > are referring to out-of-band maintenance. We should allow both > > inband and out-of-band maintenance messages. > > > > Mustapha. > > ----------- > > Xipeng Xiao wrote: > > > > > > Mustapha, > > > > > > Thank you for your comments! One response below. > > > > > > > Section 5.3: paragraph 8, last sentence says: "If a PE needs to > > > > generate and send a maintenance message to a remote PE, the > > > > maintenance message MUST be sent via the control plane, > > not via the > > > > PW" > > > > Where does this requirement come from? This is too > > restrictive. We > > > > should allow the option to send a maintenance message > > over the PW. > > > > > > A maintenance message is a control plane thing. It has to > > stay inside the control plane. > > > > > > We will consider your other suggestions. > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > From owner-mpls@UU.NET Wed Dec 27 16:41:44 2006 From: Curtis Villamizar Subject: Re: [PWE3] MPLS PID Date: Wed, 02 Apr 2003 12:27:08 -0500 Lines: 69 Sender: owner-mpls@UU.NET References: Reply-To: curtis@fictitious.org Cc: "'curtis@fictitious.org'" , "'Dan Tappan'" , Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET X-From: owner-mpls@UU.NET Wed Apr 02 19:37:28 2003 Return-path: To: "David Allan" In-reply-to: Your message of "Wed, 02 Apr 2003 11:55:01 EST." Precedence: bulk Status: O In message , " David Allan" writes: > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C2F938.99B58490 > Content-Type: text/plain; > charset="iso-8859-1" > > Curtis: > > > > I never knew that MPLS architecture was a religion. I always > > thought MPLS was deployed and because it solved real world > > practical problems. > > The above seems to be orthogonal to the discussion at hand :-( Very much like the statements you made regarding "violating the MPLS architecture", including the one I quoted that you omited. > > Requiring the martinni control word would seem like a no > > brainer. However maybe we don't buy into that for some > > **technical** reason, perhaps overhead on the control word in > > the edge of the network makes a difference. If so, then the > > control word must be added along the way if the traffic type is known. > > My comment was more along the lines that if we accept ECMP as defacto, then > we have more to do than simply making sure PWs do not occasionally re-order. > IMHO it may solve some problems but would still be a major obstacle to > solving others. The martinni control word is one complete solution. The only possible objection is the added overhead. > > The only truly deterministic way to know the traffic type is > > if L3PID tells you. > > Yes, but as you note, that information is on a need to know basis and you > still end up inserting a dummy control word for those folks in the core that > will not be privy to this information. The core still expects stuff to self > identify. > > BTW I presume you're exclusively discussing TE L3PID? > > cheers > Dave Yes I mean the TE L3PID. And the same is needed for LDP. As I said (which you omitted), the easiest solution is requiring that the martinni control word be implemented but making its use optional. A more complete solution would involve using the L3PID, essentially signaling whether the traffic within an LSP was 1) all IP, 2) a mix of IP and not IP with control word, or 3) not IP with no control word, or 4) a mix of IP and not IP with no control word. For the first two ECMP is possible. The third can be mixed with IP if a control word indicating "non-IP of unknown type" is added, then removed at egress. For the last set ECMP can't be used without risking reorder. There is also the value of L3PID of MPLS which indicates that there is no clue what is contained in the LSP and the LSR has to be configured to either "make a guess" (which ISPs will configure if they are using IP and non-IP with control word) or to not do ECMP. Curtis From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Matthew.Bocci@alcatel.co.uk Subject: Control words in the architecture draft Date: Wed, 2 Apr 2003 18:21:07 +0100 Lines: 34 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Wed Apr 02 19:41:38 2003 Return-path: To: pwe3@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/02/2003 18:36:57 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I have a question about section 5.4.3. of draft-ietf-pwe3-arch-02.txt. This is the section that shows a PW over MPLS Generic Control Word. We already have different control words for some applications, including TDM and some of the ATM modes. There was a lot of discussion back arount IETF 55 about whether the control word should be moved from the individual encap drafts into the architecture document, and if so what text should be moved. My understanding was that the functionality of the control word could be described in the architecture document (since this is generic), but that the positioning of the bits and bytes would remain in the individual encap drafts. However, the 'generic' control word shown in the architecture draft is not really generic at all and does not accomodate the design decisions made for a number of the encapsulations. We could simply move all of the different control words into the architecture draft, but that would be confusing since the encapsulations would be spread across multiple documents. Would it not be clearer for the architecture draft to describe the need for and functonality of the control word, but to leave diagrams of its structure to the individual encap drafts? Regards, Matthew ----------------------------------------- Matthew Bocci Office of the CTO Alcatel Fixed Networks Division ----------------------------------------- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Control words in the architecture draft Date: Wed, 2 Apr 2003 09:57:55 -0800 Lines: 77 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Wed Apr 02 20:01:34 2003 Return-path: To: "'Matthew.Bocci@alcatel.co.uk'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Matthew, I agree with you . It seems that figure 11 was corrected but not Figure 12. My suggestion is to delete section 5.4.3, because as you said it is not generic, and for example there is no structure pointer in it that is used for TDM/Sonet draft, or that the size and position of other fields are not necessarily the same in all PW types. Yours, -Shahram PS- BTW I noticed that the PWE3 website lists older version of this draft, when it was called draft-ietf-pwe3-protocol-layer-00.txt. Danny, you may want to correct this. >-----Original Message----- >From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk] >Sent: Wednesday, April 02, 2003 12:21 PM >To: pwe3@ietf.org >Subject: [PWE3] Control words in the architecture draft > > >I have a question about section 5.4.3. of >draft-ietf-pwe3-arch-02.txt. This >is the section that shows a PW over MPLS Generic Control Word. >We already >have different control words for some applications, including >TDM and some >of the ATM modes. > >There was a lot of discussion back arount IETF 55 about >whether the control >word should be moved from the individual encap drafts into the >architecture >document, and if so what text should be moved. My >understanding was that >the functionality of the control word could be described in the >architecture document (since this is generic), but that the >positioning of >the bits and bytes would remain in the individual encap >drafts. However, >the 'generic' control word shown in the architecture draft is >not really >generic at all and does not accomodate the design decisions made for a >number of the encapsulations. > >We could simply move all of the different control words into the >architecture draft, but that would be confusing since the >encapsulations >would be spread across multiple documents. > >Would it not be clearer for the architecture draft to describe >the need for >and functonality of the control word, but to leave diagrams of its >structure to the individual encap drafts? > >Regards, > >Matthew > > > >----------------------------------------- >Matthew Bocci >Office of the CTO >Alcatel Fixed Networks Division >----------------------------------------- > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: MPLS PID Date: Wed, 02 Apr 2003 13:14:47 -0500 Lines: 46 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Dan Tappan'" , Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Wed Apr 02 20:20:02 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: "David Allan" , "'curtis@fictitious.org'" In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >Curtis: > > > I never knew that MPLS architecture was a religion. I always > > thought MPLS was deployed and because it solved real world > > practical problems. > >The above seems to be orthogonal to the discussion at hand :-( > > > > > Requiring the martinni control word would seem like a no > > brainer. However maybe we don't buy into that for some > > **technical** reason, perhaps overhead on the control word in > > the edge of the network makes a difference. If so, then the > > control word must be added along the way if the traffic type is known. > >My comment was more along the lines that if we accept ECMP as defacto, >then we have >more to do than simply making sure PWs do not occasionally re-order. IMHO >it may solve >some problems but would still be a major obstacle to solving others. I think that trying to mandate through standards how ECMP should work and predicating that PWE3 only working based on that is going to be a bigger obstacle than you might think. --Tom > > The only truly deterministic way to know the traffic type is > > if L3PID tells you. > >Yes, but as you note, that information is on a need to know basis and you >still end up inserting a dummy control word for those folks in the core >that will not be privy to this information. The core still expects stuff >to self identify. > >BTW I presume you're exclusively discussing TE L3PID? > >cheers >Dave http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: Control words in the architecture draft Date: Wed, 02 Apr 2003 19:34:46 +0100 Organization: Cisco Systems, Inc. Lines: 110 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C88B@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Matthew.Bocci@alcatel.co.uk'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 20:39:11 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote: > Matthew, > > I agree with you . It seems that figure 11 was corrected but not Figure 12. > My suggestion is to delete section 5.4.3, because as you said it is not generic, > and for example there is no structure pointer in it that is used for TDM/Sonet > draft, or that the size and position of other fields are not necessarily the same > in all PW types. > I disagree. Unless there are documented technical reasons to do otherwise the encaps should follow the recommended style. This then leaves most of the encaps to just specify their use of the flags. The only TECHNICAL case that I have seen to use another CW dsign is the TDM need for a long pointer. The revised version of 5.4.3 also discusses the need for discrimination between IP and PW, and shows how the Martini CW design and the MPLS payload identifier (needed for non-MArtini CWs) each achieve this. Stewart > Yours, > -Shahram > > PS- BTW I noticed that the PWE3 website lists older version of this draft, when > it was called draft-ietf-pwe3-protocol-layer-00.txt. > > Danny, you may want to correct this. > We will fix this. Stewart > > > > >>-----Original Message----- >>From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk] >>Sent: Wednesday, April 02, 2003 12:21 PM >>To: pwe3@ietf.org >>Subject: [PWE3] Control words in the architecture draft >> >> >>I have a question about section 5.4.3. of >>draft-ietf-pwe3-arch-02.txt. This >>is the section that shows a PW over MPLS Generic Control Word. >>We already >>have different control words for some applications, including >>TDM and some >>of the ATM modes. >> >>There was a lot of discussion back arount IETF 55 about >>whether the control >>word should be moved from the individual encap drafts into the >>architecture >>document, and if so what text should be moved. My >>understanding was that >>the functionality of the control word could be described in the >>architecture document (since this is generic), but that the >>positioning of >>the bits and bytes would remain in the individual encap >>drafts. However, >>the 'generic' control word shown in the architecture draft is >>not really >>generic at all and does not accomodate the design decisions made for a >>number of the encapsulations. >> >>We could simply move all of the different control words into the >>architecture draft, but that would be confusing since the >>encapsulations >>would be spread across multiple documents. >> >>Would it not be clearer for the architecture draft to describe >>the need for >>and functonality of the control word, but to leave diagrams of its >>structure to the individual encap drafts? >> >>Regards, >> >>Matthew >> >> >> >>----------------------------------------- >>Matthew Bocci >>Office of the CTO >>Alcatel Fixed Networks Division >>----------------------------------------- >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From owner-mpls@UU.NET Wed Dec 27 16:41:44 2006 From: Curtis Villamizar Subject: Re: [PWE3] MPLS PID Date: Wed, 02 Apr 2003 13:37:20 -0500 Lines: 36 Sender: owner-mpls@UU.NET References: <20030402123411.B19376@mindspring.com> Reply-To: curtis@fictitious.org Cc: Dan Tappan , David Allan , Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET X-From: owner-mpls@UU.NET Wed Apr 02 20:51:09 2003 Return-path: To: jleu@mindspring.com In-reply-to: Your message of "Wed, 02 Apr 2003 12:34:11 CST." <20030402123411.B19376@mindspring.com> Precedence: bulk Status: O In message <20030402123411.B19376@mindspring.com>, "James R. Leu" writes: > I've been quietly following this thread, but I would like to add my $.02(US). > > One of the proposed solutions to this problem is to add a 4 bit nibble after > the label stack. What if we trimmed it to 3 bits and threw it in the bottom > most labels EXP bits? A side effect of this is that networks that utilized > hierarchical E-LSPs would be forced to convert the inner LSPs to L-LSPs. > Although I thought at one point EXP bits were being "promoted" to the outer > most label, but I'd have to go back add read the diffserv draft to verify. > If this were still the case then this would free up the EXP bits for all > labels below the top of the stack (thus alleviating the necessity to convert > inner E-LSPs to L-LSPs). Even if EXP bits are not being "promoted" forcing > networks to switch to L-LSPs I think is a minimal cost to gain a finer > granularity of ECMP. > > Some might consider it a hack some might consider it an optimization, I > like to think of it as a compromise ;-) > > Jim Its too late to completely depricate the use of EXP as COS. Unsignaled E-LSPs seems to be the most widespread. ECMP is being used on them. draft-martinni encaps is being used with control word to make it all work where any form of PW is used. Its not possible to make incompatible changes to the deployed base. Even the relatively simple action of putting something reasonable in the L3PID may meet resistance. Curtis From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Control words in the architecture draft Date: Wed, 2 Apr 2003 10:51:34 -0800 Lines: 146 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Matthew.Bocci@alcatel.co.uk'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 20:53:57 2003 Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I wonder how can one disagree with the following facts: 1) In ATM Encap draft you have 3 types of control word: (N:1=SDU, 1:1, PDU) Note that in 1:1 and PDU mode the flags are after the length/sequence #. 2) Sonet draft does not use any FRG, PID or length, instead it uses a pointer 3) Ethernet draft does not use FRG, PID or length, instead these fields are reserved. 4) I am not sure any future PW could in fact use only the header that you have shown Also it seems to me that since this draft is a WG draft, it needs WG consensus to add/remove any text. So I assume you will wait for the consensus before adding the text regarding PID that you mentioned. -Shahram >-----Original Message----- >From: Stewart Bryant [mailto:stbryant@cisco.com] >Sent: Wednesday, April 02, 2003 1:35 PM >To: Shahram Davari >Cc: 'Matthew.Bocci@alcatel.co.uk'; pwe3@ietf.org >Subject: Re: [PWE3] Control words in the architecture draft > > > > >Shahram Davari wrote: >> Matthew, >> >> I agree with you . It seems that figure 11 was corrected but >not Figure 12. >> My suggestion is to delete section 5.4.3, because as you >said it is not generic, >> and for example there is no structure pointer in it that is >used for TDM/Sonet >> draft, or that the size and position of other fields are not >necessarily the same >> in all PW types. >> > >I disagree. > >Unless there are documented technical reasons to do otherwise >the encaps >should follow the recommended style. This then leaves most of >the encaps >to just specify their use of the flags. The only TECHNICAL case that I >have seen to use another CW dsign is the TDM need for a long pointer. > >The revised version of 5.4.3 also discusses the need for discrimination >between IP and PW, and shows how the Martini CW design and the MPLS >payload identifier (needed for non-MArtini CWs) each achieve this. > >Stewart > > > > >> Yours, >> -Shahram >> >> PS- BTW I noticed that the PWE3 website lists older version >of this draft, when >> it was called draft-ietf-pwe3-protocol-layer-00.txt. >> >> Danny, you may want to correct this. >> > >We will fix this. > >Stewart > >> >> >> >> >>>-----Original Message----- >>>From: Matthew.Bocci@alcatel.co.uk >[mailto:Matthew.Bocci@alcatel.co.uk] >>>Sent: Wednesday, April 02, 2003 12:21 PM >>>To: pwe3@ietf.org >>>Subject: [PWE3] Control words in the architecture draft >>> >>> >>>I have a question about section 5.4.3. of >>>draft-ietf-pwe3-arch-02.txt. This >>>is the section that shows a PW over MPLS Generic Control Word. >>>We already >>>have different control words for some applications, including >>>TDM and some >>>of the ATM modes. >>> >>>There was a lot of discussion back arount IETF 55 about >>>whether the control >>>word should be moved from the individual encap drafts into the >>>architecture >>>document, and if so what text should be moved. My >>>understanding was that >>>the functionality of the control word could be described in the >>>architecture document (since this is generic), but that the >>>positioning of >>>the bits and bytes would remain in the individual encap >>>drafts. However, >>>the 'generic' control word shown in the architecture draft is >>>not really >>>generic at all and does not accomodate the design decisions >made for a >>>number of the encapsulations. >>> >>>We could simply move all of the different control words into the >>>architecture draft, but that would be confusing since the >>>encapsulations >>>would be spread across multiple documents. >>> >>>Would it not be clearer for the architecture draft to describe >>>the need for >>>and functonality of the control word, but to leave diagrams of its >>>structure to the individual encap drafts? >>> >>>Regards, >>> >>>Matthew >>> >>> >>> >>>----------------------------------------- >>>Matthew Bocci >>>Office of the CTO >>>Alcatel Fixed Networks Division >>>----------------------------------------- >>> >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >>> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: MPLS PID Date: Wed, 2 Apr 2003 10:58:10 -0800 Lines: 11 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: Dan Tappan , David Allan , "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Wed Apr 02 20:59:35 2003 Return-path: To: "'curtis@fictitious.org'" , jleu@mindspring.com X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >Unsignaled E-LSPs seems to be the most widespread. ECMP is being used >on them. If you meant EXP bits are taken to account during ECMP, then that could reorder the microflows, because in E-LSP the EXP represents both PSC and drop precedence. If you didn't mean that, then putting PID in the EXP would not cause any reordering. Off course there would be some issues if the bottom label is of uniform model. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: Control words in the architecture draft Date: Wed, 02 Apr 2003 14:37:31 -0500 Lines: 15 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C88C@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "'stbryant@cisco.com'" , "'Matthew.Bocci@alcatel.co.uk'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 21:41:20 2003 Return-path: To: Shahram Davari In-reply-to: Your message of Wed, 02 Apr 2003 10:51:34 -0800. <4B6D09F3B826D411A67300D0B706EFDE0115C88C@nt-exch-yow.pmc-sierra.bc.ca> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram> In ATM Encap draft you have 3 types of control word: Indeed, it's hard to see how the ATM draft can be advanced in its current hodgepodge state. Many people have pointed out how ridiculous it is to have simply incorporated all the different proposals. Shahram> Ethernet draft does not use FRG, PID or length, instead these Shahram> fields are reserved. Well, this is an example of the sort of inconsequential but confusing differences that have crept in. Specifying this sort of thing in one place is supposed to eliminate these gratuitous differences. There's no substantive difference between the ethernet draft and what Stewart has proposed. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Control words in the architecture draft Date: Wed, 2 Apr 2003 11:39:34 -0800 Lines: 40 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'stbryant@cisco.com'" , "'Matthew.Bocci@alcatel.co.uk'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 21:47:18 2003 Return-path: To: "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O So you are proposing to change the 1:1 and PDU mode header as well as the SONET header to match Bryant's control word? -Shahram >-----Original Message----- >From: Eric Rosen [mailto:erosen@cisco.com] >Sent: Wednesday, April 02, 2003 2:38 PM >To: Shahram Davari >Cc: 'stbryant@cisco.com'; 'Matthew.Bocci@alcatel.co.uk'; pwe3@ietf.org >Subject: Re: [PWE3] Control words in the architecture draft > > > >Shahram> In ATM Encap draft you have 3 types of control word: > >Indeed, it's hard to see how the ATM draft can be advanced >in its current >hodgepodge state. Many people have pointed out how ridiculous >it is to have >simply incorporated all the different proposals. > >Shahram> Ethernet draft does not use FRG, PID or length, >instead these >Shahram> fields are reserved. > >Well, this is an example of the sort of inconsequential >but confusing >differences that have crept in. Specifying this sort of >thing in one place >is supposed to eliminate these gratuitous differences. > There's no >substantive difference between the ethernet draft and >what Stewart has >proposed. > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: MPLS PID Date: Wed, 02 Apr 2003 14:41:04 -0500 Lines: 12 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C88D@nt-exch-yow.pmc-sierra.bc.ca> Cc: "'curtis@fictitious.org'" , jleu@mindspring.com, Dan Tappan , David Allan , "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net, swallow@cisco.com X-From: pwe3-admin@ietf.org Wed Apr 02 21:51:23 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari In-reply-to: Your message of "Wed, 02 Apr 2003 10:58:10 PST." <4B6D09F3B826D411A67300D0B706EFDE0115C88D@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > If you didn't mean that, then putting PID in the EXP would not cause any reordering. > Off course there would be some issues if the bottom label is of uniform model. This alone is enough to prevent us from trying to redefine a deployed standard. ...George ================================================================== George Swallow Cisco Systems (978) 936-1398 250 Apollo Drive Chelmsford, Ma 01824 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Luca Martini Subject: Re: AAL12oPSN Date: Wed, 02 Apr 2003 13:23:46 -0700 Organization: Level3 Communications LLC. Lines: 24 Sender: pwe3-admin@ietf.org References: <20030331233624.671ED55F62@nomad.tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 02 22:25:43 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- To: danny@tcb.net Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I can support this draft as informational. There is only one ATM document in the standard track right now, and no charter item for this particular optimization case. I have no problem with this draft as a wg item targeted for informational RFC if you can get it past the IESG. Luca Danny McPherson wrote: > Folks, > Shahram has requested that this document be accepted as a WG > item. > > http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-over-psn-01.txt > > Comments please.... > > -danny > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From owner-mpls@UU.NET Wed Dec 27 16:41:44 2006 From: Curtis Villamizar Subject: Re: [PWE3] MPLS PID Date: Wed, 02 Apr 2003 16:53:47 -0500 Lines: 29 Sender: owner-mpls@UU.NET References: <4B6D09F3B826D411A67300D0B706EFDE0115C88D@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: curtis@fictitious.org Cc: "'curtis@fictitious.org'" , jleu@mindspring.com, Dan Tappan , David Allan , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET X-From: owner-mpls@UU.NET Thu Apr 03 00:10:55 2003 Return-path: To: Shahram Davari In-reply-to: Your message of "Wed, 02 Apr 2003 10:58:10 PST." <4B6D09F3B826D411A67300D0B706EFDE0115C88D@nt-exch-yow.pmc-sierra.bc.ca> Precedence: bulk Status: O In message <4B6D09F3B826D411A67300D0B706EFDE0115C88D@nt-exch-yow.pmc-sierra.bc. ca>, Shahram Davari writes: > >Unsignaled E-LSPs seems to be the most widespread. ECMP is being used > >on them. > > If you meant EXP bits are taken to account during ECMP, then that could > reorder the microflows, because in E-LSP the EXP represents both PSC and > drop precedence. No I don't mean that. ECMP is being used on E-LSP. ECMP is not considering EXP. > If you didn't mean that, then putting PID in the EXP would not cause any reor > dering. > Off course there would be some issues if the bottom label is of uniform model > . The EXP bits are already being used on unsignaled E-LSPs. E-LSPs are widespread. They carry both IP and non-IP. ECMP is applied to the E-LSPs but do not consider the EXP bits since doing that would obviously cause massive microflow reordering problems and deployments don't do things incredibly stupid (for very long). > -Shahram Curtis From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Luca Martini Subject: Re: MPLS PID Date: Wed, 02 Apr 2003 15:42:37 -0700 Organization: Level3 Communications LLC. Lines: 87 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20030402093708.09931ca8@pilgrim.cisco.com> <20030402123411.B19376@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Tappan , David Allan , Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Thu Apr 03 00:52:25 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- To: jleu@mindspring.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Too late, I wish we stop calling those bits EXP, they really are Class of service (COS). James R. Leu wrote: > I've been quietly following this thread, but I would like to add my $.02(US). > > One of the proposed solutions to this problem is to add a 4 bit nibble after > the label stack. What if we trimmed it to 3 bits and threw it in the bottom > most labels EXP bits? A side effect of this is that networks that utilized > hierarchical E-LSPs would be forced to convert the inner LSPs to L-LSPs. > Although I thought at one point EXP bits were being "promoted" to the outer > most label, but I'd have to go back add read the diffserv draft to verify. yes they are , exp bits are copied to the pushed label. > If this were still the case then this would free up the EXP bits for all > labels below the top of the stack (thus alleviating the necessity to convert > inner E-LSPs to L-LSPs). Even if EXP bits are not being "promoted" forcing > networks to switch to L-LSPs I think is a minimal cost to gain a finer > granularity of ECMP. > this is mush more difficult then simply identifying MPLS frames as non-ip. I would like to remind you that 99% of the MPLS traffic is IP. And even the current implementations of the martini protocol that are deployed end up transporting 99% IP over some layer2 protocol. SO it's probably easier to adapt the emerging PWE3 application then to try to change the existing base. > Some might consider it a hack some might consider it an optimization, I > like to think of it as a compromise ;-) > > Jim > > On Wed, Apr 02, 2003 at 10:01:43AM -0500, Dan Tappan wrote: > >>At 09:15 AM 4/1/2003 -0500, David Allan wrote: >> >> >>>1) are we going to permanently break the paradigm where labels are PIDs?, >>>because that's where we're headed. IMHO that's fairly fundamental. MPLS >>>cannot just carry "anything" via signalled convention, because >>>intermediate boxes are making their own assumptions as to what the payload is. >> >>I believe that I addressed this point: >>I wrote: >> >>> As I see it there are two possible approaches: >>> >>>1. Require that an LSP set up for an IP L3PID or IP FEC carry IP packets. >>>2. Allow non-IP packets on such an LSP, but require that they >>>be distinguishable. >> >>The immediate situation is that we have cases where a TE LSP is signalled >>using L3PID==IP, or an LDP LSP is setup for an IP FEC, but the encapsulated >>data (under a multi-level label stack) is not IP. >> >>You seem to be arguing in favor of [1] - requiring a strict interpretation >>of the L3PID, which means those packets should never be injected into that >>LSP. That's an internally consistent model, and it's the one which was used >>during the arguments which removed the L3PID from the original MPLS >>encapsulation. Unfortunately it seems to fail the reality test - if there >>were not operational benefit in violating [1] then we would not be having >>this discussion. >> >> >>>2) if we codify snooping the first nybble, it still does not fix ECMP >>>hashing of reserved labels, we're still in the woods. We also hang out to >>>dry work in PWE3 and other SDOs that are not compliant with this "new" >>>convention. >> >>Either I'm missing your point or this is a red herring. Fundamentally, any >>ECMP algorithm needs to be designed to avoid misordering flows. If someone >>implements an algorithm that uses a hash of the label stack then it needs >>to avoid fields which are not constant for a flow. IF we codify standards >>which require arbitrarily inserting additional labels into a stack then it >>can certainly impact an ECMP algorithm which depends on the contents of the >>stack. So we can have a whole separate argument about whether that is a >>good idea. >> >>BUT, that is all orthogonal to the issue of whether it >>should-be/needs-to-be possible to distinguish an IP from a non-IP packet on >>an IP LSP. >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Luca Martini Subject: Re: Control words in the architecture draft Date: Wed, 02 Apr 2003 15:54:50 -0700 Organization: Level3 Communications LLC. Lines: 35 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C88C@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'stbryant@cisco.com'" , "'Matthew.Bocci@alcatel.co.uk'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 03 01:01:05 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote: > I wonder how can one disagree with the following facts: > > 1) In ATM Encap draft you have 3 types of control word: (N:1=SDU, 1:1, PDU) > Note that in 1:1 and PDU mode the flags are after the length/sequence #. > > 2) Sonet draft does not use any FRG, PID or length, instead it uses a pointer > > 3) Ethernet draft does not use FRG, PID or length, instead these fields are reserved. > > 4) I am not sure any future PW could in fact use only the header that you have shown > the reserved field can be easily converted to PID, since that is why we were keeping them reserved. If a field is not used for a particular protocol the CW still fits the general architecture. > Also it seems to me that since this draft is a WG draft, it needs WG consensus to > add/remove any text. So I assume you will wait for the consensus before adding > the text regarding PID that you mentioned. > Yes, but I have not seen much opposition, only lot's of arguing, but it seems to me that we have not made a sufficient argument for not using this PID. All we have is "we could do better". But right now , without major changes to the working and deployed code this simple solution can work pretty well. Maybe we should have renamed it as I proposed a while back to class of traffic, (COT) not PID would that make it better ? :-) Luca From owner-mpls@UU.NET Wed Dec 27 16:41:44 2006 From: Curtis Villamizar Subject: Re: [PWE3] MPLS PID Date: Wed, 02 Apr 2003 23:01:35 -0500 Lines: 111 Sender: owner-mpls@UU.NET References: <3E8B675D.6010204@level3.net> Reply-To: curtis@fictitious.org Cc: jleu@mindspring.com, Dan Tappan , David Allan , Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET X-From: owner-mpls@UU.NET Thu Apr 03 10:29:27 2003 Return-path: To: Luca Martini In-reply-to: Your message of "Wed, 02 Apr 2003 15:42:37 MST." <3E8B675D.6010204@level3.net> Precedence: bulk Status: O In message <3E8B675D.6010204@level3.net>, Luca Martini writes: > > Too late, I wish we stop calling those bits EXP, they really are Class of > service (COS). Maybe the experiment is over. In any case they are not the only way to support service classes and we'd have to rename unsignaled E-LSP to unsignaled C-LSP, etc. Curtis > James R. Leu wrote: > > I've been quietly following this thread, but I would like to add my $.02(US > ). > > > > One of the proposed solutions to this problem is to add a 4 bit nibble afte > r > > the label stack. What if we trimmed it to 3 bits and threw it in the botto > m > > most labels EXP bits? A side effect of this is that networks that utilized > > hierarchical E-LSPs would be forced to convert the inner LSPs to L-LSPs. > > Although I thought at one point EXP bits were being "promoted" to the outer > > most label, but I'd have to go back add read the diffserv draft to verify. > > yes they are , exp bits are copied to the pushed label. > > > If this were still the case then this would free up the EXP bits for all > > labels below the top of the stack (thus alleviating the necessity to conver > t > > inner E-LSPs to L-LSPs). Even if EXP bits are not being "promoted" forcing > > networks to switch to L-LSPs I think is a minimal cost to gain a finer > > granularity of ECMP. > > > this is mush more difficult then simply identifying MPLS frames as non-ip. I > would like to remind you that 99% of the MPLS traffic is IP. And even the > current implementations of the martini protocol that are deployed end up > transporting 99% IP over some layer2 protocol. SO it's probably easier to ada > pt > the emerging PWE3 application then to try to change the existing base. > > > > Some might consider it a hack some might consider it an optimization, I > > like to think of it as a compromise ;-) > > > > Jim > > > > On Wed, Apr 02, 2003 at 10:01:43AM -0500, Dan Tappan wrote: > > > >>At 09:15 AM 4/1/2003 -0500, David Allan wrote: > >> > >> > >>>1) are we going to permanently break the paradigm where labels are PIDs?, > >>>because that's where we're headed. IMHO that's fairly fundamental. MPLS > >>>cannot just carry "anything" via signalled convention, because > >>>intermediate boxes are making their own assumptions as to what the payload > is. > >> > >>I believe that I addressed this point: > >>I wrote: > >> > >>> As I see it there are two possible approaches: > >>> > >>>1. Require that an LSP set up for an IP L3PID or IP FEC carry IP packets. > >>>2. Allow non-IP packets on such an LSP, but require that they > >>>be distinguishable. > >> > >>The immediate situation is that we have cases where a TE LSP is signalled > >>using L3PID==IP, or an LDP LSP is setup for an IP FEC, but the encapsulated > > >>data (under a multi-level label stack) is not IP. > >> > >>You seem to be arguing in favor of [1] - requiring a strict interpretation > >>of the L3PID, which means those packets should never be injected into that > >>LSP. That's an internally consistent model, and it's the one which was used > > >>during the arguments which removed the L3PID from the original MPLS > >>encapsulation. Unfortunately it seems to fail the reality test - if there > >>were not operational benefit in violating [1] then we would not be having > >>this discussion. > >> > >> > >>>2) if we codify snooping the first nybble, it still does not fix ECMP > >>>hashing of reserved labels, we're still in the woods. We also hang out to > >>>dry work in PWE3 and other SDOs that are not compliant with this "new" > >>>convention. > >> > >>Either I'm missing your point or this is a red herring. Fundamentally, any > >>ECMP algorithm needs to be designed to avoid misordering flows. If someone > >>implements an algorithm that uses a hash of the label stack then it needs > >>to avoid fields which are not constant for a flow. IF we codify standards > >>which require arbitrarily inserting additional labels into a stack then it > >>can certainly impact an ECMP algorithm which depends on the contents of the > > >>stack. So we can have a whole separate argument about whether that is a > >>good idea. > >> > >>BUT, that is all orthogonal to the issue of whether it > >>should-be/needs-to-be possible to distinguish an IP from a non-IP packet on > > >>an IP LSP. > >> > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: Control words in the architecture draft Date: Thu, 03 Apr 2003 09:35:18 +0100 Organization: Cisco Systems, Inc. Lines: 196 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C88C@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Matthew.Bocci@alcatel.co.uk'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 03 10:43:32 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote: > I wonder how can one disagree with the following facts: > > 1) In ATM Encap draft you have 3 types of control word: (N:1=SDU, 1:1, PDU) > Note that in 1:1 and PDU mode the flags are after the length/sequence #. With no technical justification in the text, and against a background of prior art that had useful properties for the Internet. Perhaps it should go back for re-design? > > 2) Sonet draft does not use any FRG, PID or length, instead it uses a pointer Indeed, and the SONET draft describes the technical basis for this. > > 3) Ethernet draft does not use FRG, PID or length, instead these fields are reserved. > This is just muddying the water. The draft needs only minor edits to conform, and no implementation changes. I know that most Ethernets can handle long frames, but to cover the general Ethernet case the draft should have some text on FRG. > 4) I am not sure any future PW could in fact use only the header that you have shown The important point is that the text sets a baseline. If there is a sound reason to deviate from the baseline the text makes it clear that is OK. The only issue is with encapsulations that deviate from the standard without good reason. > > Also it seems to me that since this draft is a WG draft, it needs WG consensus to > add/remove any text. So I assume you will wait for the consensus before adding > the text regarding PID that you mentioned. The changes have been discussed at two IETFs (look at the minutes), and on the mailing list. Stewart > > -Shahram > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Wednesday, April 02, 2003 1:35 PM >>To: Shahram Davari >>Cc: 'Matthew.Bocci@alcatel.co.uk'; pwe3@ietf.org >>Subject: Re: [PWE3] Control words in the architecture draft >> >> >> >> >>Shahram Davari wrote: >> >>>Matthew, >>> >>>I agree with you . It seems that figure 11 was corrected but >> >>not Figure 12. >> >>>My suggestion is to delete section 5.4.3, because as you >> >>said it is not generic, >> >>>and for example there is no structure pointer in it that is >> >>used for TDM/Sonet >> >>>draft, or that the size and position of other fields are not >> >>necessarily the same >> >>>in all PW types. >>> >> >>I disagree. >> >>Unless there are documented technical reasons to do otherwise >>the encaps >>should follow the recommended style. This then leaves most of >>the encaps >>to just specify their use of the flags. The only TECHNICAL case that I >>have seen to use another CW dsign is the TDM need for a long pointer. >> >>The revised version of 5.4.3 also discusses the need for discrimination >>between IP and PW, and shows how the Martini CW design and the MPLS >>payload identifier (needed for non-MArtini CWs) each achieve this. >> >>Stewart >> >> >> >> >> >>>Yours, >>>-Shahram >>> >>>PS- BTW I noticed that the PWE3 website lists older version >> >>of this draft, when >> >>>it was called draft-ietf-pwe3-protocol-layer-00.txt. >>> >>>Danny, you may want to correct this. >>> >> >>We will fix this. >> >>Stewart >> >> >>> >>> >>> >>>>-----Original Message----- >>>>From: Matthew.Bocci@alcatel.co.uk >>> >>[mailto:Matthew.Bocci@alcatel.co.uk] >> >>>>Sent: Wednesday, April 02, 2003 12:21 PM >>>>To: pwe3@ietf.org >>>>Subject: [PWE3] Control words in the architecture draft >>>> >>>> >>>>I have a question about section 5.4.3. of >>>>draft-ietf-pwe3-arch-02.txt. This >>>>is the section that shows a PW over MPLS Generic Control Word. >>>>We already >>>>have different control words for some applications, including >>>>TDM and some >>>>of the ATM modes. >>>> >>>>There was a lot of discussion back arount IETF 55 about >>>>whether the control >>>>word should be moved from the individual encap drafts into the >>>>architecture >>>>document, and if so what text should be moved. My >>>>understanding was that >>>>the functionality of the control word could be described in the >>>>architecture document (since this is generic), but that the >>>>positioning of >>>>the bits and bytes would remain in the individual encap >>>>drafts. However, >>>>the 'generic' control word shown in the architecture draft is >>>>not really >>>>generic at all and does not accomodate the design decisions >>> >>made for a >> >>>>number of the encapsulations. >>>> >>>>We could simply move all of the different control words into the >>>>architecture draft, but that would be confusing since the >>>>encapsulations >>>>would be spread across multiple documents. >>>> >>>>Would it not be clearer for the architecture draft to describe >>>>the need for >>>>and functonality of the control word, but to leave diagrams of its >>>>structure to the individual encap drafts? >>>> >>>>Regards, >>>> >>>>Matthew >>>> >>>> >>>> >>>>----------------------------------------- >>>>Matthew Bocci >>>>Office of the CTO >>>>Alcatel Fixed Networks Division >>>>----------------------------------------- >>>> >>>>_______________________________________________ >>>>pwe3 mailing list >>>>pwe3@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>> >>> >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >> >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Matthew.Bocci@alcatel.co.uk Subject: Re: Control words in the architecture draft Date: Thu, 3 Apr 2003 10:33:54 +0100 Lines: 255 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, pwe3-admin@ietf.org, Shahram Davari X-From: pwe3-admin@ietf.org Thu Apr 03 11:48:13 2003 Return-path: To: stbryant@cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/03/2003 10:44:05 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, The fundamental problem is that I don't believe that bits and bytes positioning in the control word should be in the architecture document. This is an encap issue, and I would be quite happy to see technical justifications for this added to the individual encap drafts for *all* of the encapsulations. The position of the sequence number and flags is only of concern to the PEs that would have to implement the rest of the service-specific encapsulation anyway. The only thing that seems to be of concern to the core routers is if we implement a PID, which I believe can be accomodated in all the control word designs we have today (the 1:1 and PDU modes in ATM have the first octet reserved, just as in Ethernet). Cheers, Matthew ----------------------------------------- Matthew Bocci Office of the CTO Alcatel Fixed Networks Division ----------------------------------------- Stewart Bryant To: Shahram Davari Subject: Re: [PWE3] Control words in the architecture draft Sent by: pwe3-admin@ie tf.org 03/04/2003 09:35 Please respond to stbryant Shahram Davari wrote: > I wonder how can one disagree with the following facts: > > 1) In ATM Encap draft you have 3 types of control word: (N:1=SDU, 1:1, PDU) > Note that in 1:1 and PDU mode the flags are after the length/sequence #. With no technical justification in the text, and against a background of prior art that had useful properties for the Internet. Perhaps it should go back for re-design? > > 2) Sonet draft does not use any FRG, PID or length, instead it uses a pointer Indeed, and the SONET draft describes the technical basis for this. > > 3) Ethernet draft does not use FRG, PID or length, instead these fields are reserved. > This is just muddying the water. The draft needs only minor edits to conform, and no implementation changes. I know that most Ethernets can handle long frames, but to cover the general Ethernet case the draft should have some text on FRG. > 4) I am not sure any future PW could in fact use only the header that you have shown The important point is that the text sets a baseline. If there is a sound reason to deviate from the baseline the text makes it clear that is OK. The only issue is with encapsulations that deviate from the standard without good reason. > > Also it seems to me that since this draft is a WG draft, it needs WG consensus to > add/remove any text. So I assume you will wait for the consensus before adding > the text regarding PID that you mentioned. The changes have been discussed at two IETFs (look at the minutes), and on the mailing list. Stewart > > -Shahram > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Wednesday, April 02, 2003 1:35 PM >>To: Shahram Davari >>Cc: 'Matthew.Bocci@alcatel.co.uk'; pwe3@ietf.org >>Subject: Re: [PWE3] Control words in the architecture draft >> >> >> >> >>Shahram Davari wrote: >> >>>Matthew, >>> >>>I agree with you . It seems that figure 11 was corrected but >> >>not Figure 12. >> >>>My suggestion is to delete section 5.4.3, because as you >> >>said it is not generic, >> >>>and for example there is no structure pointer in it that is >> >>used for TDM/Sonet >> >>>draft, or that the size and position of other fields are not >> >>necessarily the same >> >>>in all PW types. >>> >> >>I disagree. >> >>Unless there are documented technical reasons to do otherwise >>the encaps >>should follow the recommended style. This then leaves most of >>the encaps >>to just specify their use of the flags. The only TECHNICAL case that I >>have seen to use another CW dsign is the TDM need for a long pointer. >> >>The revised version of 5.4.3 also discusses the need for discrimination >>between IP and PW, and shows how the Martini CW design and the MPLS >>payload identifier (needed for non-MArtini CWs) each achieve this. >> >>Stewart >> >> >> >> >> >>>Yours, >>>-Shahram >>> >>>PS- BTW I noticed that the PWE3 website lists older version >> >>of this draft, when >> >>>it was called draft-ietf-pwe3-protocol-layer-00.txt. >>> >>>Danny, you may want to correct this. >>> >> >>We will fix this. >> >>Stewart >> >> >>> >>> >>> >>>>-----Original Message----- >>>>From: Matthew.Bocci@alcatel.co.uk >>> >>[mailto:Matthew.Bocci@alcatel.co.uk] >> >>>>Sent: Wednesday, April 02, 2003 12:21 PM >>>>To: pwe3@ietf.org >>>>Subject: [PWE3] Control words in the architecture draft >>>> >>>> >>>>I have a question about section 5.4.3. of >>>>draft-ietf-pwe3-arch-02.txt. This >>>>is the section that shows a PW over MPLS Generic Control Word. >>>>We already >>>>have different control words for some applications, including >>>>TDM and some >>>>of the ATM modes. >>>> >>>>There was a lot of discussion back arount IETF 55 about >>>>whether the control >>>>word should be moved from the individual encap drafts into the >>>>architecture >>>>document, and if so what text should be moved. My >>>>understanding was that >>>>the functionality of the control word could be described in the >>>>architecture document (since this is generic), but that the >>>>positioning of >>>>the bits and bytes would remain in the individual encap >>>>drafts. However, >>>>the 'generic' control word shown in the architecture draft is >>>>not really >>>>generic at all and does not accomodate the design decisions >>> >>made for a >> >>>>number of the encapsulations. >>>> >>>>We could simply move all of the different control words into the >>>>architecture draft, but that would be confusing since the >>>>encapsulations >>>>would be spread across multiple documents. >>>> >>>>Would it not be clearer for the architecture draft to describe >>>>the need for >>>>and functonality of the control word, but to leave diagrams of its >>>>structure to the individual encap drafts? >>>> >>>>Regards, >>>> >>>>Matthew >>>> >>>> >>>> >>>>----------------------------------------- >>>>Matthew Bocci >>>>Office of the CTO >>>>Alcatel Fixed Networks Division >>>>----------------------------------------- >>>> >>>>_______________________________________________ >>>>pwe3 mailing list >>>>pwe3@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>> >>> >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >> >> > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Proposed changes to MPLS CW in arch draft Date: Thu, 03 Apr 2003 14:00:13 +0100 Organization: Cisco Systems, Inc. Lines: 211 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Apr 03 15:06:28 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "pwe3@ietf.org" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is the text that I propose for sections 5.4.2, 5.4.3 and the new 5.4.4 in draft-pwe3-arch-03.txt In section 5.4.2 the MPLS payload type identifier is shown in the relation to the PW label and the CW. In section 5.4.3 the issue of IP packet aliasing is introduced, and the generic and the SONET CWs are defined. It is noted that the "Martini" style of CW does not have this aliasing issue. The new section 5.4.4 includes the MPLS payload type identifier for reference and shows how IP packets can be multiplexed over the PW for management purposes. Stewart 5.4.2. PWE3 over an MPLS PSN The MPLS ethos places importance on wire efficiency. By using a control word, some components of the PWE3 protocol layers can be compressed to increase this efficiency. +---------------------+ | Payload | /=====================\ H Payload Convergence H-----+ H---------------------H | H Timing H------------------------+ H---------------------H | | H Sequencing H-----| | \=====================/ | | | PW Demultiplexer |---+ | v +---------------------+ | | +--------------------------------+ | PSN Convergence |-----| . . +---------------------+ | | . RTP . | PSN |-+ | | | | +---------------------+ | | | +--------------------------------+ | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | +---------------------+ | | +--------------------------------+ | Physical | | | | MPLS Payl'd Type Indent | +---------------------+ | | +--------------------------------+ | +--->| PW Label | | +--------------------------------+ +----->| Outer Label or MPLS-in-IP encap| +--------------------------------+ Figure 11: PWE3 over an MPLS PSN using a control word Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An inner MPLS label is used to provide the PW demultiplexing function. A control word is used to carry most of the information needed by the PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact format. The flags in the control word provide the necessary payload convergence. A sequence field provides support for both in-order payload delivery and (supported by a fragmentation control method) a PSN fragmentation service within the PSN Convergence Layer. Ethernet pads all frames to a minimum size of 64 bytes. The MPLS header does not include a length indicator. Therefore to allow PWE3 to be carried in MPLS to correctly pass over an Ethernet data-link, a length correction field is needed in the control word. Where the design of the control word would alias an IP packet, an MPLS Payload Type Identifier should be interposed between the PW label and the control word (see 5.4.4). As with an IP PSN, where appropriate, timing is provided by RTP [RFC1889]. In some networks it may be necessary to carry PWE3 over MPLS over IP. In these circumstances, the PW is encapsulated for carriage over MPLS as described in this section, and then a method of carrying MPLS over an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the resultant PW-PDU. 5.4.3. PW over MPLS Generic Control Word To allow accurate packet inspection in an MPLS PSN, and to operate correctly over MPLS PSNs that have deployed equal-cost multiple-path load-ballancing a PW packet MUST NOT alias an IP packet. IP packets are carried in MPLS label stacks without any protocol identifier. Historic values of the IP version number [RFC791] [RFC1881] are therefore used to distinguish between IP and non-IP MPLS payloads. A PW SHOULD employ either the generic PW control word or an MPLS payload type identifier to disambiguate the PW from an IP flow. The PW set-up protocol determines whether a particular PW uses a control word. When a control word is used, it MUST have the following form for non-SONET encapsulations: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: MPLS Generic Control Word (non-SONET) Note that a with packet bits 0..3 = 4 indicates an IPv4 MPLS payload and a packet with bits 0..3 = 6 indicates an IPv6 MPLS playload. The meaning of the fields of the MPLS Generic Control Word (non- SONET) (Figure 12) is as follows: Flags (bits 4 to 7): These bits are available for per payload signaling. Their definition is encapsulation specific. FRG (bits 8 and 9): These bits are used when fragmenting a PW payload. Their use is defined in [FRAG]. When the PW is of a type that will never need payload fragmentation, these bits may be used as general purpose flags. Length (bits 10 to 15): The length field is used to determine the size of a PW payload that might have been padded to the minimum Ethernet MAC frame size during its transit across the PSN. If the MPLS payload (defined as the CW + the PW payload + any additional PW headers is less than 46 bytes, the length MUST be set to the length of the MPLS payload. If the MPLS payload is between 46 bytes and 63 bytes the implementation MAY either set to the length to the length of the MPLS payload, or it MAY set it to 0. If the length of the MPLS payload is greater than 63 bytes the length MUST be set to 0. Sequence number (Bit 16 to 31): If the sequence number is not used, it is set to zero by the sender and ignored by the receiver. Otherwise it specifies the sequence number of a packet. A circular list of sequence numbers is used. A sequence number takes a value from 1 to 65535 (2**16-1). If the payload is an OAM packet the sequence number MAY be used to mark the position in the sequence, in which case it has the same value as the last data PDU sent. The use of the sequence number is optional for OAM payloads. The PW control word used in SONET applications must use the following general forms. Non-extended: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Flags | Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Flags | Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional encapsulation-specific header fields | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: MPLS Generic Control Word (SONET) The meaning of the fields of the MPLS Generic Control Word (SONET) (Figure 13) is as follows: Structure Pointer[0:12]: If used, the Structure Pointer contains the offset of the first byte of the payload structure. Sequence Number[0:13]: This is a packet sequence number, which continuously cycles from 0 to 0x3FFF. It is generated and processed in accordance with the rules established in [RFC1889]. When the RTP header is used, this sequence number MUST match the LSBs of the RTP sequence Number. 5.4.4. MPLS Payload Identifier Where the PW control word may alias an IP packet (for example the MPLS Generic Control Word (SONET)), the control word SHOULD be preceeded by an MPLS payload type identifier. For reference the MPLS payload type identifier [TBD] is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved | PPP DLL Protocol Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PPP DLL protocol definition | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: MPLS Payload Type Identifier PPP DLL Protocol Number [16:31]: These numbers are assigned by IANA. Some PW management messages such as OAM and LSP ping may require IP packets to be multiplexed onto the PW. These are carried over the PW using the IP MPLS payload type indicator, show in Figure 15: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved | IPv4 = 0x21, or IPv6 = 0x57 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP packet and management payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: MPLS Payload Type Identifier From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Control words in the architecture draft Date: Thu, 3 Apr 2003 07:27:00 -0800 Lines: 232 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Matthew.Bocci@alcatel.co.uk'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 03 17:34:25 2003 Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >> 1) In ATM Encap draft you have 3 types of control word: >(N:1=SDU, 1:1, PDU) >> Note that in 1:1 and PDU mode the flags are after the >length/sequence #. > >With no technical justification in the text, and against a background >of prior art that had useful properties for the Internet. > >Perhaps it should go back for re-design? That is a separate issue. What currently exist does not match your draft. Perhaps you should start an thread and try to achieve a consensus to change all those drafts before introducing a single generic header in architecture draft. > >> >> 2) Sonet draft does not use any FRG, PID or length, instead >it uses a pointer > >Indeed, and the SONET draft describes the technical basis for this. So, if SONET header, which is different than Generic PW header, is OK then what does "Generic PW header mean"? > >> >> 3) Ethernet draft does not use FRG, PID or length, instead >these fields are reserved. >> > >This is just muddying the water. The draft needs only minor edits to >conform, and no implementation changes. I know that most Ethernets can >handle long frames, but to cover the general Ethernet case the draft >should have some text on FRG. I again suggest that you first try to achieve consensus on changing this draft and not assume such consensus in advance. > >> 4) I am not sure any future PW could in fact use only the >header that you have shown > >The important point is that the text sets a baseline. If there >is a sound >reason to deviate from the baseline the text makes it clear >that is OK. The >only issue is with encapsulations that deviate from the >standard without good >reason. I am not sure the position of bits/bytes should be part of the architecture draft. Perhaps you could mention that it is desirable to have a single control word. > >> >> Also it seems to me that since this draft is a WG draft, it >needs WG consensus to >> add/remove any text. So I assume you will wait for the >consensus before adding >> the text regarding PID that you mentioned. > >The changes have been discussed at two IETFs (look at the >minutes), and on the >mailing list. There is a difference between "discussion" and "consensus". I don't remember any consensus on this subject. In fact when Yaakov Stein in IETF 55 suggested a single control word for all PW types, it was heavily objected. -Shahram > >Stewart > > >> >> -Shahram >> >> >>>-----Original Message----- >>>From: Stewart Bryant [mailto:stbryant@cisco.com] >>>Sent: Wednesday, April 02, 2003 1:35 PM >>>To: Shahram Davari >>>Cc: 'Matthew.Bocci@alcatel.co.uk'; pwe3@ietf.org >>>Subject: Re: [PWE3] Control words in the architecture draft >>> >>> >>> >>> >>>Shahram Davari wrote: >>> >>>>Matthew, >>>> >>>>I agree with you . It seems that figure 11 was corrected but >>> >>>not Figure 12. >>> >>>>My suggestion is to delete section 5.4.3, because as you >>> >>>said it is not generic, >>> >>>>and for example there is no structure pointer in it that is >>> >>>used for TDM/Sonet >>> >>>>draft, or that the size and position of other fields are not >>> >>>necessarily the same >>> >>>>in all PW types. >>>> >>> >>>I disagree. >>> >>>Unless there are documented technical reasons to do otherwise >>>the encaps >>>should follow the recommended style. This then leaves most of >>>the encaps >>>to just specify their use of the flags. The only TECHNICAL >case that I >>>have seen to use another CW dsign is the TDM need for a long pointer. >>> >>>The revised version of 5.4.3 also discusses the need for >discrimination >>>between IP and PW, and shows how the Martini CW design and the MPLS >>>payload identifier (needed for non-MArtini CWs) each achieve this. >>> >>>Stewart >>> >>> >>> >>> >>> >>>>Yours, >>>>-Shahram >>>> >>>>PS- BTW I noticed that the PWE3 website lists older version >>> >>>of this draft, when >>> >>>>it was called draft-ietf-pwe3-protocol-layer-00.txt. >>>> >>>>Danny, you may want to correct this. >>>> >>> >>>We will fix this. >>> >>>Stewart >>> >>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Matthew.Bocci@alcatel.co.uk >>>> >>>[mailto:Matthew.Bocci@alcatel.co.uk] >>> >>>>>Sent: Wednesday, April 02, 2003 12:21 PM >>>>>To: pwe3@ietf.org >>>>>Subject: [PWE3] Control words in the architecture draft >>>>> >>>>> >>>>>I have a question about section 5.4.3. of >>>>>draft-ietf-pwe3-arch-02.txt. This >>>>>is the section that shows a PW over MPLS Generic Control Word. >>>>>We already >>>>>have different control words for some applications, including >>>>>TDM and some >>>>>of the ATM modes. >>>>> >>>>>There was a lot of discussion back arount IETF 55 about >>>>>whether the control >>>>>word should be moved from the individual encap drafts into the >>>>>architecture >>>>>document, and if so what text should be moved. My >>>>>understanding was that >>>>>the functionality of the control word could be described in the >>>>>architecture document (since this is generic), but that the >>>>>positioning of >>>>>the bits and bytes would remain in the individual encap >>>>>drafts. However, >>>>>the 'generic' control word shown in the architecture draft is >>>>>not really >>>>>generic at all and does not accomodate the design decisions >>>> >>>made for a >>> >>>>>number of the encapsulations. >>>>> >>>>>We could simply move all of the different control words into the >>>>>architecture draft, but that would be confusing since the >>>>>encapsulations >>>>>would be spread across multiple documents. >>>>> >>>>>Would it not be clearer for the architecture draft to describe >>>>>the need for >>>>>and functonality of the control word, but to leave diagrams of its >>>>>structure to the individual encap drafts? >>>>> >>>>>Regards, >>>>> >>>>>Matthew >>>>> >>>>> >>>>> >>>>>----------------------------------------- >>>>>Matthew Bocci >>>>>Office of the CTO >>>>>Alcatel Fixed Networks Division >>>>>----------------------------------------- >>>>> >>>>>_______________________________________________ >>>>>pwe3 mailing list >>>>>pwe3@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> >>>> >>>>_______________________________________________ >>>>pwe3 mailing list >>>>pwe3@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>> >>>> >>> >>> >> >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Control words in the architecture draft Date: Thu, 3 Apr 2003 18:47:56 +0300 Lines: 28 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Thu Apr 03 17:50:05 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Control words in the architecture draft Thread-Index: AcL5yBq6kKQCv7saShCl5Z+3rXVKYwAL1big To: , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33FmdK26874 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > The fundamental problem is that I don't believe that bits and bytes > positioning in the control word should be in the architecture > document. > This is an encap issue, and I would be quite happy to see technical > justifications for this added to the individual encap drafts > for *all* of the encapsulations. Matthew, While I think you are right in principle that an architecture document should not get into the bit positions, we simply don't have any other common document for all encapsulations where this could be put. Unlike all the other encap issues, the control word is rather generic in functionality (although each service will have its own flags). I don't see any reason for each encap type to specify its own bit positionings for essentially the same information. We are a single WG and should be able to come up with a single solution for all the parts which are common to all the services. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: Proposed changes to MPLS CW in arch draft Date: Thu, 03 Apr 2003 11:20:57 -0500 Organization: Alcatel Networks Corporaton Lines: 222 Sender: pwe3-admin@ietf.org References: <3E8C305D.5090305@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Apr 03 18:27:53 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: stbryant@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, I suggest to keep the specific OAM identification to a separate PW-OAM document. There will be more than one type of OAM message we want a PE to identify. All what I heard so far, was for the core routers to be able to distinguish between a IPv4, IPv6, and the rest of the traffic. The OAM identification has no impact on the core routers. Regards, Mustapha. ---------- Stewart Bryant wrote: > This is the text that I propose for sections 5.4.2, 5.4.3 and the > new 5.4.4 in draft-pwe3-arch-03.txt > > In section 5.4.2 the MPLS payload type identifier is shown in the > relation to the PW label and the CW. > > In section 5.4.3 the issue of IP packet aliasing is introduced, > and the generic and the SONET CWs are defined. It is noted that > the "Martini" style of CW does not have this aliasing issue. > > The new section 5.4.4 includes the MPLS payload type identifier for > reference and shows how IP packets can be multiplexed over the PW > for management purposes. > > Stewart > > 5.4.2. PWE3 over an MPLS PSN > > The MPLS ethos places importance on wire efficiency. By using a > control word, some components of the PWE3 protocol layers can be > compressed to increase this efficiency. > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H------------------------+ > H---------------------H | | > H Sequencing H-----| | > \=====================/ | | > | PW Demultiplexer |---+ | v > +---------------------+ | | +--------------------------------+ > | PSN Convergence |-----| . . > +---------------------+ | | . RTP . > | PSN |-+ | | | | > +---------------------+ | | | +--------------------------------+ > | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | Physical | | | | MPLS Payl'd Type Indent | > +---------------------+ | | +--------------------------------+ > | +--->| PW Label | > | +--------------------------------+ > +----->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > Figure 11: PWE3 over an MPLS PSN using a control word > > Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An > inner MPLS label is used to provide the PW demultiplexing function. > A control word is used to carry most of the information needed by the > PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact > format. The flags in the control word provide the necessary payload > convergence. A sequence field provides support for both in-order > payload delivery and (supported by a fragmentation control method) a > PSN fragmentation service within the PSN Convergence Layer. Ethernet > pads all frames to a minimum size of 64 bytes. The MPLS header does > not include a length indicator. Therefore to allow PWE3 to be carried > in MPLS to correctly pass over an Ethernet data-link, a length > correction field is needed in the control word. Where the design of > the control word would alias an IP packet, an MPLS Payload Type > Identifier should be interposed between the PW label and the control > word (see 5.4.4). As with an IP PSN, where appropriate, timing is > provided by RTP [RFC1889]. > > In some networks it may be necessary to carry PWE3 over MPLS over IP. > In these circumstances, the PW is encapsulated for carriage over MPLS > as described in this section, and then a method of carrying MPLS over > an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the > resultant PW-PDU. > > 5.4.3. PW over MPLS Generic Control Word > > To allow accurate packet inspection in an MPLS PSN, and to operate > correctly over MPLS PSNs that have deployed equal-cost multiple-path > load-ballancing a PW packet MUST NOT alias an IP packet. IP packets > are carried in MPLS label stacks without any protocol identifier. > Historic values of the IP version number [RFC791] [RFC1881] are > therefore used to distinguish between IP and non-IP MPLS payloads. > > A PW SHOULD employ either the generic PW control word or an MPLS > payload type identifier to disambiguate the PW from an IP flow. > > The PW set-up protocol determines whether a particular PW uses a > control word. When a control word is used, it MUST have the > following form for non-SONET encapsulations: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Flags |FRG| Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: MPLS Generic Control Word (non-SONET) > > Note that a with packet bits 0..3 = 4 indicates an IPv4 MPLS payload > and a packet with bits 0..3 = 6 indicates an IPv6 MPLS playload. > > The meaning of the fields of the MPLS Generic Control Word (non- > SONET) (Figure 12) is as follows: > > Flags (bits 4 to 7): > These bits are available for per payload signaling. Their > definition is encapsulation specific. > > FRG (bits 8 and 9): > These bits are used when fragmenting a PW payload. Their use > is defined in [FRAG]. When the PW is of a type that will never > need payload fragmentation, these bits may be used as general > purpose flags. > > Length (bits 10 to 15): > The length field is used to determine the size of a PW > payload that might have been padded to the minimum Ethernet > MAC frame size during its transit across the PSN. If the > MPLS payload (defined as the CW + the PW payload + any > additional PW headers is less than 46 bytes, the length MUST > be set to the length of the MPLS payload. If the MPLS > payload is between 46 bytes and 63 bytes the implementation > MAY either set to the length to the length of the MPLS > payload, or it MAY set it to 0. If the length of the MPLS > payload is greater than 63 bytes the length MUST be set to 0. > > Sequence number (Bit 16 to 31): > If the sequence number is not used, it is set to zero by > the sender and ignored by the receiver. Otherwise it > specifies the sequence number of a packet. A circular list > of sequence numbers is used. A sequence number takes a value > from 1 to 65535 (2**16-1). If the payload is an OAM packet > the sequence number MAY be used to mark the position in the > sequence, in which case it has the same value as the last > data PDU sent. The use of the sequence number is optional > for OAM payloads. > > The PW control word used in SONET applications must use the following > general forms. > > Non-extended: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Flags | Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Extended: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Flags | Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Additional encapsulation-specific header fields | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: MPLS Generic Control Word (SONET) > > The meaning of the fields of the MPLS Generic Control Word (SONET) > (Figure 13) is as follows: > > Structure Pointer[0:12]: > If used, the Structure Pointer contains the offset of the > first byte of the payload structure. > > Sequence Number[0:13]: This is a packet sequence number, which > continuously cycles from 0 to 0x3FFF. It is generated and > processed in accordance with the rules established in [RFC1889]. > When the RTP header is used, this sequence number MUST match the > LSBs of the RTP sequence Number. > > 5.4.4. MPLS Payload Identifier > > Where the PW control word may alias an IP packet (for example the > MPLS Generic Control Word (SONET)), the control word SHOULD be > preceeded by an MPLS payload type identifier. > > For reference the MPLS payload type identifier [TBD] is defined as > follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved | PPP DLL Protocol Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | As defined by PPP DLL protocol definition | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: MPLS Payload Type Identifier > > PPP DLL Protocol Number [16:31]: > These numbers are assigned by IANA. > > Some PW management messages such as OAM and LSP ping may require IP > packets to be multiplexed onto the PW. These are carried over the PW > using the IP MPLS payload type indicator, show in Figure 15: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved | IPv4 = 0x21, or IPv6 = 0x57 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IP packet and management payload | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 15: MPLS Payload Type Identifier > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: Control words in the architecture draft Date: Thu, 03 Apr 2003 11:21:43 -0500 Lines: 28 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C895@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "'stbryant@cisco.com'" , "'Matthew.Bocci@alcatel.co.uk'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 03 18:28:06 2003 Return-path: To: Shahram Davari In-reply-to: Your message of Thu, 03 Apr 2003 07:27:00 -0800. <4B6D09F3B826D411A67300D0B706EFDE0115C895@nt-exch-yow.pmc-sierra.bc.ca> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram> In fact when Yaakov Stein in IETF 55 suggested a single control Shahram> word for all PW types, it was heavily objected. I'd have said "lightly objected", I think there were only a couple of objections. In judging consensus, one has to take into account more than just the noise level; to judge lack of consensus, I think one has to take into account whether there are technical arguments on both sides. On the issue of the ethernet draft, I have yet to see an objection from anyone who has been involved with that draft or even anyone who has ever shown interest in that draft. So the issue of "but we'd have to change the picture in the ethernet encaps draft" is just a red herring. I think that WG consensus is required in order to advance a document along the process. But I don't think it is required for every single release of the document. I also think that WG consensus is a criterion applied to the technical content of the document, not necessarily to the way in which the documents are organized, or to the way in which the agreed upon technical material is divided among the set of documents. Matthew> the 1:1 and PDU modes in ATM have the first octet reserved, just as Matthew> in Ethernet I couldn't find this in the ATM encaps draft; where does it say that exactly? From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: VCCV OAM question Date: Thu, 03 Apr 2003 12:04:52 -0500 Organization: Alcatel Networks Corporaton Lines: 29 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030401192322.029bc0a0@bucket.cisco.com> <5.2.0.9.2.20030402104212.02aea018@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Apr 03 19:08:03 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "'pwe3@ietf.org'" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, "Thomas D. Nadeau" wrote: > > >Tom and Shahram, > >I think there are a couple of points in terms of OAM for pseudo-wires: > > > >1. Yes it is important to be able to check connectivity all the way to the PW > >endpoints. Having said that, I do not think that connectivity verification > >such as the proposed VCCV is sufficient. Connectivity verification is a > >pro-active OAM function. We also need to have reactive OAM such as reasonably > >fast defect indication that will be triggered without having the service > >provider inject traffic on thousands of PWs. > > As I pointed out during the meeting, we are not proposing > VCCV as the be-all-end-all to OAM for PWE3. It is just one > diagnostic mechanism in the quiver of OAM tools for PWE3 > as is LSP ping and native end-to-end OAM that is passed > transparently over the PWs. When these are used in combination, > we get a complete solution. Not quite complete. In the case of dissimilar L2 access to the PSN, say ATM-PSN-Ethernet, we need a specific PW defect indication to be sent inband or out-of band in response to a failure of the attachement circuit or inside the PE between the PW endpoint and the tunnel originating point. Himanshu made a proposal for a possible mechanism for sending status messages out-of-band in draft-shah-pwe3-control-protocol-extension. We need another one for inband notification. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: VCCV OAM question Date: Thu, 03 Apr 2003 12:10:42 -0500 Organization: Alcatel Networks Corporaton Lines: 111 Sender: pwe3-admin@ietf.org References: <007e01c2f931$9cb84170$021ea8c0@HSHAH700> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Apr 03 19:17:22 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: pwe3@ietf.org Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Himanshu, thanks for providing a reference to the draft. Clearly, it is better to indicate status of an attachement circuit to the remote PE and let it deal with it than to systematically withdraw a label. In reference to the requirement document, I classify your mechanism in the out-of-band OAM or link management category. This is because the notification is not forwarded in the same channel as the user data. Regards, Mustapha. ----------- himanshu shah wrote: > > There is a proposal to extend PWE3 control signaling > to notify VC status to the remote peer. The VC status > could either be attachment circuit or head end PW status > or both. > > There are two aspects of VC status > 1) generation - based on attachment circuit or head end PW > 2) processing of received status > - propagating it to attachment circuit > - pkt processing action on incoming PW > > Please refer to draft-shah-pwe3-control-protocol-extension-00.txt. > > /himanshu > > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Mustapha Aissaoui > Sent: Wednesday, April 02, 2003 10:27 AM > To: Thomas D. Nadeau; Shahram Davari > Cc: 'pwe3@ietf.org' > Subject: Re: [PWE3] VCCV OAM question > > Tom and Shahram, > I think there are a couple of points in terms of OAM for pseudo-wires: > > 1. Yes it is important to be able to check connectivity all the way to the > PW > endpoints. Having said that, I do not think that connectivity verification > such as the proposed VCCV is sufficient. Connectivity verification is a > pro-active OAM function. We also need to have reactive OAM such as > reasonably > fast defect indication that will be triggered without having the service > provider inject traffic on thousands of PWs. > > I believe we need to discuss the following: > - a defect indication for a PW: in this case we should try to rely as much > as > possible on the native service OAM capabilities. This is true in the case of > same L2 access technology (e.g., ATM-MPLS-ATM). In the case where there is a > different L2 access technology (e.g., ATM-MPLS-Ethernet), then each > technology will have to rely on its own OAM since the interworking here is > at > a higher layer. > - connectivity verification. > - performance monitoring. > > 2. Correlation of defect states between the PSN and the PW levels. You > cannot > assume that a PW is just being set up independently of the PSN it is riding > on. For example, when a transport LSP is in defect state (whether this is > detected through inband or out-of band), there is a need to generate defect > indication at the PW level. > > Mustapha. > ---------- > "Thomas D. Nadeau" wrote: > > > At 02:30 PM 4/1/2003 -0800, Shahram Davari wrote: > > > > > >(the MPLS OAM requirements also reflect this > > > >point). > > > > > > > > > >Where in MPLS OAM requirements? > > > > Packets must flow the way of data > > packets. > > > > >And isn't this a PW issue independent of the PSN? > > > > Yes, but when MPLS is the PSN the MPLS > > requirements apply. I have spoken with L2TP customers > > that feel the same way, which makes complete > > sense to me. I suspect your customers will tell you the > > same. > > > > --Tom > > > > >-Shahram > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Alex Conta Subject: Re: AAL12oPSN Date: Thu, 03 Apr 2003 12:15:31 -0800 Lines: 146 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5281AC58@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms26A5B4429C8DB685F1A5F303" Cc: "Andrew G. Malis" , danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 03 19:21:08 2003 Return-path: X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en To: Yaakov Stein Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a cryptographically signed message in MIME format. --------------ms26A5B4429C8DB685F1A5F303 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I also support this draft as a WG draft, with the intent to make it an "informational" RFC. Regards, Alex Yaakov Stein wrote: > > Andy, > > Yes, the idea is that Shahram's draft will be informational, > since it does not suggest any new protocol, > just how best to use the existing atm-encap modes for AAL1. > > Regarding PDU mode, the issue with OAM cells > has been discussed at length. > I suggest that Shahram state the restrictions > explicitly in his text. > > Y(J)S > > > -----Original Message----- > > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > > Sent: Tuesday, April 01, 2003 7:20 PM > > To: Yaakov Stein > > Cc: danny@tcb.net; pwe3@ietf.org > > Subject: RE: [PWE3] AAL12oPSN > > > > > > Unfortunately, as I said in the meeting, I have issues with > > this draft. I > > could perhaps accept it as a WG draft under the clear > > understanding that it > > is informational. Also, the draft needs to note that in PDU > > mode, AAL1 and > > OAM don't work well together - if you need both OAM and AAL1, > > you must use > > either N:1 or 1:1 cell mode encapsulation. > > > > Andy > > > > ------- > > > > At 4/1/2003 05:57 PM +0300, Yaakov Stein wrote: > > > > >I fully support its adoption. > > > > > >Y(J)S > > > > > > > -----Original Message----- > > > > From: Danny McPherson [mailto:danny@tcb.net] > > > > Sent: Tuesday, April 01, 2003 2:36 AM > > > > To: pwe3@ietf.org > > > > Subject: [PWE3] AAL12oPSN > > > > > > > > > > > > > > > > Folks, > > > > Shahram has requested that this document be accepted as a WG > > > > item. > > > > > > > > http://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-ov > > > > er-psn-01.txt > > > > > > > > Comments please.... > > > > > > > > -danny > > > > > > > > _______________________________________________ > > > > pwe3 mailing list > > > > pwe3@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 --------------ms26A5B4429C8DB685F1A5F303 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhAwgIjt1LtpV2AM64D0R8bCMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkyMDAwMDAw MFoXDTAzMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFIjccjs9g z0DiQcpTsg+mbY5L+R2YaTNN6k2fRGSLMLitaA2YwdeN3goXG45bXCP8DldBS38EWHFT2/5Q cy9HnNQaS1GnG2xzngdev5HpVm/oAy1M9YPt96Zp2W5MKGIb87vxyXvb1KqRMA9paf/6xZ2C B4tH127oHyF1xT4k8wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQBUOS83AALNc8pTZDApKndtQBiFQLPTu5ZL pE1TDsyd4y75K3gXUvqlprCFY8HgKwodqs9wTltqYRlvhZVlMXu1y0g8Z3MJ9KSddePYuuli jop+PplaAHS7DHXDJNNQt+n2i2K4j4uJFokE2JnvaEyBEHjtTmIt+JjS2Dygm57mwzCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDCAiO3Uu2lXYAzrgPRHxsIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDMyMDE1MzNaMCMGCSqGSIb3DQEJ BDEWBBQZ9jHRIDlAM/T2UCfbuxAwCQnhhTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgCjUQ95uhaaU4zimqj70aZzE8F7cb3qsb+xyWv2SKKEqLLQt oA3muLP9JB+T3WoLKFwB6Nt5oLtvDA4WTc2oV1xWF1MjX64EM2MuWIgxrv/XSAx2YDK3IHBu VO00d+9E3ALJjp7jROsGZM8FYMRBbexJRldY+RseLMtDXdru8xdL --------------ms26A5B4429C8DB685F1A5F303-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 requirements Date: Thu, 03 Apr 2003 12:31:52 -0500 Organization: Alcatel Networks Corporaton Lines: 47 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030331122332.04d68e60@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, Xipeng Xiao , Danny McPherson , Prayson Pate , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Apr 03 19:38:35 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Thomas D. Nadeau" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, "Thomas D. Nadeau" wrote: > > >The Requirements document says nothing about the issue > >of a PW aliasing an IP packet (the CW PID issue). It > >is clear from comments on the list that a PW that > >does not take this into account will be subject to > >disruption when traversing an ECMP enabled MPLS core, and > >I raised concerns about psamp/ipfix. > > > >I think that there needs to be a requirement added to > >to the effect that a PW must operate correctly over a PSN > >that provides ECMP, and a possibly a requirement that > >allows IP flow monitoring. Whether this gets resolved in > >PWE3 or in MPLS is OoS, but as PWE3 is the first payload > >that he IETF has defined that has this problem, it > >generates the requirement. > > > >Something like: > > > >"If the PSN uses an ECMP or IP flow recognition method, > >then the PW encapsulation must use a method discriminating > >between itself and an IP flow" > > I think that it is hard to determine if the PSN > employs an ECMP or flow recognition method other > that knowing a priori that they might exist. I think it > might be more straight-forward to just state, > > "The PW encapsulation must use a method whereby > any PW can be distinguished from other flows traversing the > PSN." > > That seems to cover all the cases. Your sentence generalizes the issue beyond what the stated issue was. What was stated was to make sure that the PSN does not misinterpret a PW payload for a IPv4 or IPv6 packet in some specific situations (ECMP was one). We are not saying that the core nodes require to distinguish a PW from some other TBD payload, which may not be relevant to it (e.g., OAM messages). Therefore, I suggest that we stick to Stewart's original sentence. Regards, Mustapha. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: Proposed changes to MPLS CW in arch draft Date: Thu, 03 Apr 2003 13:01:50 -0500 Organization: Alcatel Networks Corporaton Lines: 234 Sender: pwe3-admin@ietf.org References: <3E8C305D.5090305@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Apr 03 20:06:09 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: stbryant@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, It looks like only the SONET control word may have an issue with the IP payload aliasing. The 1:1 and PDU encapsulations in the ATM draft do not make use of the length field and the first byte following the bottom label is always set to all zeros. I spoke to Matthew and Luca and they are going to update the draft. So, I really do not see the justification for a MPLS Payload Identifier. We should ask the authors of the SONET draft come with a proposal on how to fix the SONET encapsulation. Furthermore, the control word is optional and I cannot see how we can have a Payload Identifier in an optional field. This clearly does not address the stated issue of IP aliasing. If we really want to resolve the issue of payload identification once for all, I would second Andy's suggestion to look into the proposed multiprotocol encapsulation draft, draft-moreels-multiproto-mpls-00.txt. Regards, Mustapha. --------- Stewart Bryant wrote: > > This is the text that I propose for sections 5.4.2, 5.4.3 and the > new 5.4.4 in draft-pwe3-arch-03.txt > > In section 5.4.2 the MPLS payload type identifier is shown in the > relation to the PW label and the CW. > > In section 5.4.3 the issue of IP packet aliasing is introduced, > and the generic and the SONET CWs are defined. It is noted that > the "Martini" style of CW does not have this aliasing issue. > > The new section 5.4.4 includes the MPLS payload type identifier for > reference and shows how IP packets can be multiplexed over the PW > for management purposes. > > Stewart > > 5.4.2. PWE3 over an MPLS PSN > > The MPLS ethos places importance on wire efficiency. By using a > control word, some components of the PWE3 protocol layers can be > compressed to increase this efficiency. > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H------------------------+ > H---------------------H | | > H Sequencing H-----| | > \=====================/ | | > | PW Demultiplexer |---+ | v > +---------------------+ | | +--------------------------------+ > | PSN Convergence |-----| . . > +---------------------+ | | . RTP . > | PSN |-+ | | | | > +---------------------+ | | | +--------------------------------+ > | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | Physical | | | | MPLS Payl'd Type Indent | > +---------------------+ | | +--------------------------------+ > | +--->| PW Label | > | +--------------------------------+ > +----->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > Figure 11: PWE3 over an MPLS PSN using a control word > > Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An > inner MPLS label is used to provide the PW demultiplexing function. > A control word is used to carry most of the information needed by the > PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact > format. The flags in the control word provide the necessary payload > convergence. A sequence field provides support for both in-order > payload delivery and (supported by a fragmentation control method) a > PSN fragmentation service within the PSN Convergence Layer. Ethernet > pads all frames to a minimum size of 64 bytes. The MPLS header does > not include a length indicator. Therefore to allow PWE3 to be carried > in MPLS to correctly pass over an Ethernet data-link, a length > correction field is needed in the control word. Where the design of > the control word would alias an IP packet, an MPLS Payload Type > Identifier should be interposed between the PW label and the control > word (see 5.4.4). As with an IP PSN, where appropriate, timing is > provided by RTP [RFC1889]. > > In some networks it may be necessary to carry PWE3 over MPLS over IP. > In these circumstances, the PW is encapsulated for carriage over MPLS > as described in this section, and then a method of carrying MPLS over > an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the > resultant PW-PDU. > > 5.4.3. PW over MPLS Generic Control Word > > To allow accurate packet inspection in an MPLS PSN, and to operate > correctly over MPLS PSNs that have deployed equal-cost multiple-path > load-ballancing a PW packet MUST NOT alias an IP packet. IP packets > are carried in MPLS label stacks without any protocol identifier. > Historic values of the IP version number [RFC791] [RFC1881] are > therefore used to distinguish between IP and non-IP MPLS payloads. > > A PW SHOULD employ either the generic PW control word or an MPLS > payload type identifier to disambiguate the PW from an IP flow. > > The PW set-up protocol determines whether a particular PW uses a > control word. When a control word is used, it MUST have the > following form for non-SONET encapsulations: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Flags |FRG| Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: MPLS Generic Control Word (non-SONET) > > Note that a with packet bits 0..3 = 4 indicates an IPv4 MPLS payload > and a packet with bits 0..3 = 6 indicates an IPv6 MPLS playload. > > The meaning of the fields of the MPLS Generic Control Word (non- > SONET) (Figure 12) is as follows: > > Flags (bits 4 to 7): > These bits are available for per payload signaling. Their > definition is encapsulation specific. > > FRG (bits 8 and 9): > These bits are used when fragmenting a PW payload. Their use > is defined in [FRAG]. When the PW is of a type that will never > need payload fragmentation, these bits may be used as general > purpose flags. > > Length (bits 10 to 15): > The length field is used to determine the size of a PW > payload that might have been padded to the minimum Ethernet > MAC frame size during its transit across the PSN. If the > MPLS payload (defined as the CW + the PW payload + any > additional PW headers is less than 46 bytes, the length MUST > be set to the length of the MPLS payload. If the MPLS > payload is between 46 bytes and 63 bytes the implementation > MAY either set to the length to the length of the MPLS > payload, or it MAY set it to 0. If the length of the MPLS > payload is greater than 63 bytes the length MUST be set to 0. > > Sequence number (Bit 16 to 31): > If the sequence number is not used, it is set to zero by > the sender and ignored by the receiver. Otherwise it > specifies the sequence number of a packet. A circular list > of sequence numbers is used. A sequence number takes a value > from 1 to 65535 (2**16-1). If the payload is an OAM packet > the sequence number MAY be used to mark the position in the > sequence, in which case it has the same value as the last > data PDU sent. The use of the sequence number is optional > for OAM payloads. > > The PW control word used in SONET applications must use the following > general forms. > > Non-extended: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Flags | Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Extended: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Flags | Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Additional encapsulation-specific header fields | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: MPLS Generic Control Word (SONET) > > The meaning of the fields of the MPLS Generic Control Word (SONET) > (Figure 13) is as follows: > > Structure Pointer[0:12]: > If used, the Structure Pointer contains the offset of the > first byte of the payload structure. > > Sequence Number[0:13]: This is a packet sequence number, which > continuously cycles from 0 to 0x3FFF. It is generated and > processed in accordance with the rules established in [RFC1889]. > When the RTP header is used, this sequence number MUST match the > LSBs of the RTP sequence Number. > > 5.4.4. MPLS Payload Identifier > > Where the PW control word may alias an IP packet (for example the > MPLS Generic Control Word (SONET)), the control word SHOULD be > preceeded by an MPLS payload type identifier. > > For reference the MPLS payload type identifier [TBD] is defined as > follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved | PPP DLL Protocol Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | As defined by PPP DLL protocol definition | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: MPLS Payload Type Identifier > > PPP DLL Protocol Number [16:31]: > These numbers are assigned by IANA. > > Some PW management messages such as OAM and LSP ping may require IP > packets to be multiplexed onto the PW. These are carried over the PW > using the IP MPLS payload type indicator, show in Figure 15: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved | IPv4 = 0x21, or IPv6 = 0x57 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IP packet and management payload | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 15: MPLS Payload Type Identifier > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: Re: PWE3 requirements Date: Thu, 03 Apr 2003 13:43:51 -0500 Lines: 63 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030331122332.04d68e60@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Apr 03 20:48:03 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Mustapha Aissaoui In-Reply-To: <3E8C7008.825C0A34@alcatel.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 12:31 PM 4/3/2003 -0500, Mustapha Aissaoui wrote: >Tom, > >"Thomas D. Nadeau" wrote: > > > > >The Requirements document says nothing about the issue > > >of a PW aliasing an IP packet (the CW PID issue). It > > >is clear from comments on the list that a PW that > > >does not take this into account will be subject to > > >disruption when traversing an ECMP enabled MPLS core, and > > >I raised concerns about psamp/ipfix. > > > > > >I think that there needs to be a requirement added to > > >to the effect that a PW must operate correctly over a PSN > > >that provides ECMP, and a possibly a requirement that > > >allows IP flow monitoring. Whether this gets resolved in > > >PWE3 or in MPLS is OoS, but as PWE3 is the first payload > > >that he IETF has defined that has this problem, it > > >generates the requirement. > > > > > >Something like: > > > > > >"If the PSN uses an ECMP or IP flow recognition method, > > >then the PW encapsulation must use a method discriminating > > >between itself and an IP flow" > > > > I think that it is hard to determine if the PSN > > employs an ECMP or flow recognition method other > > that knowing a priori that they might exist. I think it > > might be more straight-forward to just state, > > > > "The PW encapsulation must use a method whereby > > any PW can be distinguished from other flows traversing the > > PSN." > > > > That seems to cover all the cases. > >Your sentence generalizes the issue beyond what the stated issue >was. What was stated was to make sure that the PSN does not >misinterpret a PW payload for a IPv4 or IPv6 packet in some specific >situations (ECMP was one). We are not saying that the core nodes >require to distinguish a PW from some other TBD payload, which may >not be relevant to it (e.g., OAM messages). My suggestion says nothing about core or edge or otherwise nodes and neityher does the original one. The implicit assumption is that the PW encapsulation not violate the forwarding behavior of existing MPLS or IP P routers. --Tom >Therefore, I suggest that we stick to Stewart's original sentence. > >Regards, >Mustapha. >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 requirements Date: Thu, 03 Apr 2003 14:27:37 -0500 Organization: Alcatel Networks Corporaton Lines: 57 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030331122332.04d68e60@bucket.cisco.com> <5.2.0.9.2.20030403133908.02b366a0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Apr 03 21:32:29 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Thomas D. Nadeau" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O "Thomas D. Nadeau" wrote: > > At 12:31 PM 4/3/2003 -0500, Mustapha Aissaoui wrote: > >Tom, > > > >"Thomas D. Nadeau" wrote: > > > > > > >The Requirements document says nothing about the issue > > > >of a PW aliasing an IP packet (the CW PID issue). It > > > >is clear from comments on the list that a PW that > > > >does not take this into account will be subject to > > > >disruption when traversing an ECMP enabled MPLS core, and > > > >I raised concerns about psamp/ipfix. > > > > > > > >I think that there needs to be a requirement added to > > > >to the effect that a PW must operate correctly over a PSN > > > >that provides ECMP, and a possibly a requirement that > > > >allows IP flow monitoring. Whether this gets resolved in > > > >PWE3 or in MPLS is OoS, but as PWE3 is the first payload > > > >that he IETF has defined that has this problem, it > > > >generates the requirement. > > > > > > > >Something like: > > > > > > > >"If the PSN uses an ECMP or IP flow recognition method, > > > >then the PW encapsulation must use a method discriminating > > > >between itself and an IP flow" > > > > > > I think that it is hard to determine if the PSN > > > employs an ECMP or flow recognition method other > > > that knowing a priori that they might exist. I think it > > > might be more straight-forward to just state, > > > > > > "The PW encapsulation must use a method whereby > > > any PW can be distinguished from other flows traversing the > > > PSN." > > > > > > That seems to cover all the cases. > > > >Your sentence generalizes the issue beyond what the stated issue > >was. What was stated was to make sure that the PSN does not > >misinterpret a PW payload for a IPv4 or IPv6 packet in some specific > >situations (ECMP was one). We are not saying that the core nodes > >require to distinguish a PW from some other TBD payload, which may > >not be relevant to it (e.g., OAM messages). > > My suggestion says nothing about core or edge or otherwise > nodes and neityher does the original one. The implicit assumption is > that the PW encapsulation not violate the forwarding behavior of > existing MPLS or IP P routers. > > --Tom Yes, but your statement says that a router has to be able to distinguish a PW from any other payload type, not just IP. This is not required at all. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: Re: PWE3 requirements Date: Thu, 03 Apr 2003 14:47:35 -0500 Lines: 68 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030331122332.04d68e60@bucket.cisco.com> <5.2.0.9.2.20030403133908.02b366a0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Apr 03 21:56:36 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Mustapha Aissaoui In-Reply-To: <3E8C8B29.DF6836EC@alcatel.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 02:27 PM 4/3/2003 -0500, Mustapha Aissaoui wrote: >"Thomas D. Nadeau" wrote: > > > > At 12:31 PM 4/3/2003 -0500, Mustapha Aissaoui wrote: > > >Tom, > > > > > >"Thomas D. Nadeau" wrote: > > > > > > > > >The Requirements document says nothing about the issue > > > > >of a PW aliasing an IP packet (the CW PID issue). It > > > > >is clear from comments on the list that a PW that > > > > >does not take this into account will be subject to > > > > >disruption when traversing an ECMP enabled MPLS core, and > > > > >I raised concerns about psamp/ipfix. > > > > > > > > > >I think that there needs to be a requirement added to > > > > >to the effect that a PW must operate correctly over a PSN > > > > >that provides ECMP, and a possibly a requirement that > > > > >allows IP flow monitoring. Whether this gets resolved in > > > > >PWE3 or in MPLS is OoS, but as PWE3 is the first payload > > > > >that he IETF has defined that has this problem, it > > > > >generates the requirement. > > > > > > > > > >Something like: > > > > > > > > > >"If the PSN uses an ECMP or IP flow recognition method, > > > > >then the PW encapsulation must use a method discriminating > > > > >between itself and an IP flow" > > > > > > > > I think that it is hard to determine if the PSN > > > > employs an ECMP or flow recognition method other > > > > that knowing a priori that they might exist. I think it > > > > might be more straight-forward to just state, > > > > > > > > "The PW encapsulation must use a method whereby > > > > any PW can be distinguished from other flows traversing the > > > > PSN." > > > > > > > > That seems to cover all the cases. > > > > > >Your sentence generalizes the issue beyond what the stated issue > > >was. What was stated was to make sure that the PSN does not > > >misinterpret a PW payload for a IPv4 or IPv6 packet in some specific > > >situations (ECMP was one). We are not saying that the core nodes > > >require to distinguish a PW from some other TBD payload, which may > > >not be relevant to it (e.g., OAM messages). > > > > My suggestion says nothing about core or edge or otherwise > > nodes and neityher does the original one. The implicit assumption is > > that the PW encapsulation not violate the forwarding behavior of > > existing MPLS or IP P routers. > > > > --Tom > >Yes, but your statement says that a router has to be able to >distinguish a PW from any other payload type, not just IP. This is >not required at all. Again, I don't see how the original statement or my refined one say anything about any router or packet handling. They both state that the format must allow for the packet to be self-describing so that it can be distinguished from other types of traffic. --Tom http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Xipeng Xiao" Subject: RE: PWE3 requirements Date: Thu, 3 Apr 2003 15:40:18 -0800 Lines: 48 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Fri Apr 04 01:43:10 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Thread-Topic: PWE3 requirements Thread-Index: AcL3oqMjuuT+5/uTSdqWvQ3/x3NtlQCl6foQ To: , "Danny McPherson" , "Prayson Pate" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33NeoK11780 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Stewart, I will look into this. regards, XiPeng > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, March 31, 2003 8:27 AM > To: Xipeng Xiao; Danny McPherson; Prayson Pate; pwe3@ietf.org > Subject: PWE3 requirements > > > > > The Requirements document says nothing about the issue > of a PW aliasing an IP packet (the CW PID issue). It > is clear from comments on the list that a PW that > does not take this into account will be subject to > disruption when traversing an ECMP enabled MPLS core, and > I raised concerns about psamp/ipfix. > > I think that there needs to be a requirement added to > to the effect that a PW must operate correctly over a PSN > that provides ECMP, and a possibly a requirement that > allows IP flow monitoring. Whether this gets resolved in > PWE3 or in MPLS is OoS, but as PWE3 is the first payload > that he IETF has defined that has this problem, it > generates the requirement. > > Something like: > > "If the PSN uses an ECMP or IP flow recognition method, > then the PW encapsulation must use a method discriminating > between itself and an IP flow" > > My personal view is that we should always provide the > discrimination (because that is future proof), but the > text I suggest above says: > > "Discriminate if your network needs it. How you discriminate > is up to you i.e. in the CW or by an MPLS extension" > > Stewart > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: What is PWE3 chartered to do? Date: Fri, 4 Apr 2003 07:37:50 +0100 Lines: 50 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: swallow@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Apr 04 08:41:28 2003 Return-path: To: pjw@ip-engineering.bt.com, tnadeau@cisco.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, I have previously pointed out that we, as a service provider, require simple client/server adaptation between arbitrary X/Y client/server layer network relationships for reasons like you remark.....also required for client and server independence. These guys are creating the beginings of another 'in-between' layer network that will have to be managed by those you wish to use it....though I could never see anyone here touching it. However, all these bolt-on functions in this 'in-between' layer primarily come about because of LDP....so, since LDP does not provide any benefit (that cannot be better addressed directly via or IP or using p2p LSPs), but only gives hard management problems, then the right answer is simply to deprecate these and not try and bodge some fixes for them. regards, Neil > -----Original Message----- > From: Peter Willis [mailto:pjw@ip-engineering.bt.com] > Sent: 02 April 2003 09:56 > To: Thomas D. Nadeau > Cc: George Swallow; Peter Willis; Harrison,N,Neil,IKL2 R; > pwe3@ietf.org > Subject: Re: [PWE3] What is PWE3 chartered to do? > > > > > Right. As Eric points out, if you want sequencing, add it > > to the PWE header and don't worry about the transport misordering. > > > > Which is fine if sequencing comes for free. However > sequencing does not come > for free. It consumes memory & processing. And its also a > difficult algorithm > to implement correctly (is it still broken in the PWE3 > drafts?) --- the > problem being telling the difference between misordering, > drops & something > delayed for a long time, and if you cater for the latter then your > delay and jitter targets go out the window. > > Now if you use MPLS correctly you will only get misordering > very infrequently. > So if I can use MPLS RSVP-TE (or similar) and not implement > the sequencing stuff > wouldn't it be lower cost to implement? And wouldn't it give better > performance? > > Peter. > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Matthew.Bocci@alcatel.co.uk Subject: Re: Control words in the architecture draft Date: Fri, 4 Apr 2003 10:28:03 +0100 Lines: 90 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, pwe3-admin@ietf.org, Shahram Davari , "'stbryant@cisco.com'" X-From: pwe3-admin@ietf.org Fri Apr 04 11:48:03 2003 Return-path: To: erosen@cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/04/2003 10:43:37 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eric, With regard to your point about the 1:1 and PDU modes in the ATM draft, the length field is not used for either of these modes because the length is always greater than the minimum transfer unit on an ethernet link. Therefore, this field becomes reserved and is set to all zeros (I agree that the text in the current version of the draft needs to be clarified). This means that there are 4 bits in exactly the same position as the martini control word that could be used for PID. Bets regards, Matthew ----------------------------------------- Matthew Bocci Office of the CTO Alcatel Fixed Networks Division ----------------------------------------- Eric Rosen .com> cc: "'stbryant@cisco.com'" , Matthew BOCCI/GB/ALCATEL@ALCATEL, pwe3@ietf.org Sent by: Subject: Re: [PWE3] Control words in the architecture draft pwe3-admin@ie tf.org 03/04/2003 17:21 Please respond to erosen Shahram> In fact when Yaakov Stein in IETF 55 suggested a single control Shahram> word for all PW types, it was heavily objected. I'd have said "lightly objected", I think there were only a couple of objections. In judging consensus, one has to take into account more than just the noise level; to judge lack of consensus, I think one has to take into account whether there are technical arguments on both sides. On the issue of the ethernet draft, I have yet to see an objection from anyone who has been involved with that draft or even anyone who has ever shown interest in that draft. So the issue of "but we'd have to change the picture in the ethernet encaps draft" is just a red herring. I think that WG consensus is required in order to advance a document along the process. But I don't think it is required for every single release of the document. I also think that WG consensus is a criterion applied to the technical content of the document, not necessarily to the way in which the documents are organized, or to the way in which the agreed upon technical material is divided among the set of documents. Matthew> the 1:1 and PDU modes in ATM have the first octet reserved, just as Matthew> in Ethernet I couldn't find this in the ATM encaps draft; where does it say that exactly? _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: PWE3 requirements Date: Fri, 04 Apr 2003 11:38:25 +0100 Organization: Cisco Systems, Inc. Lines: 79 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030331122332.04d68e60@bucket.cisco.com> <5.2.0.9.2.20030403133908.02b366a0@bucket.cisco.com> <3E8C8B29.DF6836EC@alcatel.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Apr 04 12:43:16 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Mustapha Aissaoui Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha Aissaoui wrote: > "Thomas D. Nadeau" wrote: > >>At 12:31 PM 4/3/2003 -0500, Mustapha Aissaoui wrote: >> >>>Tom, >>> >>>"Thomas D. Nadeau" wrote: >>> >>>>>The Requirements document says nothing about the issue >>>>>of a PW aliasing an IP packet (the CW PID issue). It >>>>>is clear from comments on the list that a PW that >>>>>does not take this into account will be subject to >>>>>disruption when traversing an ECMP enabled MPLS core, and >>>>>I raised concerns about psamp/ipfix. >>>>> >>>>>I think that there needs to be a requirement added to >>>>>to the effect that a PW must operate correctly over a PSN >>>>>that provides ECMP, and a possibly a requirement that >>>>>allows IP flow monitoring. Whether this gets resolved in >>>>>PWE3 or in MPLS is OoS, but as PWE3 is the first payload >>>>>that he IETF has defined that has this problem, it >>>>>generates the requirement. >>>>> >>>>>Something like: >>>>> >>>>>"If the PSN uses an ECMP or IP flow recognition method, >>>>>then the PW encapsulation must use a method discriminating >>>>>between itself and an IP flow" >>>> >>>> I think that it is hard to determine if the PSN >>>>employs an ECMP or flow recognition method other >>>>that knowing a priori that they might exist. I think it >>>>might be more straight-forward to just state, >>>> >>>> "The PW encapsulation must use a method whereby >>>>any PW can be distinguished from other flows traversing the >>>>PSN." >>>> >>>> That seems to cover all the cases. >>> >>>Your sentence generalizes the issue beyond what the stated issue >>>was. What was stated was to make sure that the PSN does not >>>misinterpret a PW payload for a IPv4 or IPv6 packet in some specific >>>situations (ECMP was one). We are not saying that the core nodes >>>require to distinguish a PW from some other TBD payload, which may >>>not be relevant to it (e.g., OAM messages). >> >> My suggestion says nothing about core or edge or otherwise >>nodes and neityher does the original one. The implicit assumption is >>that the PW encapsulation not violate the forwarding behavior of >>existing MPLS or IP P routers. >> >> --Tom > > > Yes, but your statement says that a router has to be able to > distinguish a PW from any other payload type, not just IP. This is > not required at all. At the moment we only have 3 payload types, IPv4, IPv6 and PW. We cannot make the assumption that there will not be another of interest to a core router at some time in the future. This issue arrises in PWE3, not because PWs are special, but because they are the first non-IP MPLS payload standardised by the IETF. Stewart > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Peter Willis Subject: Re: What is PWE3 chartered to do? Date: Fri, 04 Apr 2003 11:57:01 +0100 Lines: 60 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D66AE@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pjw@ip-engineering.bt.com, tnadeau@cisco.com, swallow@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Apr 04 12:59:10 2003 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: neil.2.harrison@bt.com In-reply-to: Your message of "Fri, 04 Apr 2003 07:37:50 BST." <0536FC9B908BEC4597EE721BE6A35389025D66AE@i2km07-ukbr.domain1.systemhost.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Seems to me PWE3 has an expensive solution engineered in to its charter! What can we do? We could lobby to get the PWE3 charter changed but most of the very few other network operators on this list have vested interests in the current solution. Peter. > Peter, > > I have previously pointed out that we, as a service provider, require simple > client/server adaptation between arbitrary X/Y client/server layer network > relationships for reasons like you remark.....also required for client and > server independence. These guys are creating the beginings of another > 'in-between' layer network that will have to be managed by those you wish to > use it....though I could never see anyone here touching it. However, all > these bolt-on functions in this 'in-between' layer primarily come about > because of LDP....so, since LDP does not provide any benefit (that cannot be > better addressed directly via or IP or using p2p LSPs), but only gives hard > management problems, then the right answer is simply to deprecate these and > not try and bodge some fixes for them. > > regards, Neil > > > -----Original Message----- > > From: Peter Willis [mailto:pjw@ip-engineering.bt.com] > > Sent: 02 April 2003 09:56 > > To: Thomas D. Nadeau > > Cc: George Swallow; Peter Willis; Harrison,N,Neil,IKL2 R; > > pwe3@ietf.org > > Subject: Re: [PWE3] What is PWE3 chartered to do? > > > > > > > > > Right. As Eric points out, if you want sequencing, add it > > > to the PWE header and don't worry about the transport misordering. > > > > > > > Which is fine if sequencing comes for free. However > > sequencing does not come > > for free. It consumes memory & processing. And its also a > > difficult algorithm > > to implement correctly (is it still broken in the PWE3 > > drafts?) --- the > > problem being telling the difference between misordering, > > drops & something > > delayed for a long time, and if you cater for the latter then your > > delay and jitter targets go out the window. > > > > Now if you use MPLS correctly you will only get misordering > > very infrequently. > > So if I can use MPLS RSVP-TE (or similar) and not implement > > the sequencing stuff > > wouldn't it be lower cost to implement? And wouldn't it give better > > performance? > > > > Peter. > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-allan-mpls-pid-00.txt Date: Fri, 04 Apr 2003 06:43:34 -0500 Lines: 81 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: mpls@uu.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Apr 04 13:48:29 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS and IP PW Payload ID Author(s) : D. Allan Filename : draft-allan-mpls-pid-00.txt Pages : 0 Date : 2003-4-3 This memo defines an MPLS and PW payload ID. It describes how an MPLS payload ID may be used to address a number of issues associated with proprietary ECMP deployments. It describes how when used with PWs permits OAM and control protocols to be multiplexed with a PW. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-allan-mpls-pid-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-allan-mpls-pid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: What is PWE3 chartered to do? Date: Fri, 04 Apr 2003 10:15:57 -0500 Lines: 69 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D66AE@i2km07-ukbr.domai n1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Fri Apr 04 17:17:25 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: pwe3@ietf.org In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D66AE@i2km07-ukbr.domai n1.systemhost.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, In a utopian/white-board world that disregards the reality of deployed kit, such a conclusion makes perfect sense. So did similar reasoning to those in the past who reasoned that Earth was flat because that argument too looked good at least on paper. However, the reality is that 100s of thousands of LSRs are currently deployed in real networks and run LDP, so it is not a realistic option to just say lets stop using LDP today or in the future because it is hard to manage. There are plenty of other technologies that are difficult to manage and use that are still widely deployed today because they still get the job done most of the time. Perhaps you are familiar with a technology called Windows? --tom >I have previously pointed out that we, as a service provider, require simple >client/server adaptation between arbitrary X/Y client/server layer network >relationships for reasons like you remark.....also required for client and >server independence. These guys are creating the beginings of another >'in-between' layer network that will have to be managed by those you wish to >use it....though I could never see anyone here touching it. However, all >these bolt-on functions in this 'in-between' layer primarily come about >because of LDP....so, since LDP does not provide any benefit (that cannot be >better addressed directly via or IP or using p2p LSPs), but only gives hard >management problems, then the right answer is simply to deprecate these and >not try and bodge some fixes for them. > >regards, Neil > > > -----Original Message----- > > From: Peter Willis [mailto:pjw@ip-engineering.bt.com] > > Sent: 02 April 2003 09:56 > > To: Thomas D. Nadeau > > Cc: George Swallow; Peter Willis; Harrison,N,Neil,IKL2 R; > > pwe3@ietf.org > > Subject: Re: [PWE3] What is PWE3 chartered to do? > > > > > > > > > Right. As Eric points out, if you want sequencing, add it > > > to the PWE header and don't worry about the transport misordering. > > > > > > > Which is fine if sequencing comes for free. However > > sequencing does not come > > for free. It consumes memory & processing. And its also a > > difficult algorithm > > to implement correctly (is it still broken in the PWE3 > > drafts?) --- the > > problem being telling the difference between misordering, > > drops & something > > delayed for a long time, and if you cater for the latter then your > > delay and jitter targets go out the window. > > > > Now if you use MPLS correctly you will only get misordering > > very infrequently. > > So if I can use MPLS RSVP-TE (or similar) and not implement > > the sequencing stuff > > wouldn't it be lower cost to implement? And wouldn't it give better > > performance? > > > > Peter. > > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 requirements Date: Fri, 04 Apr 2003 12:41:48 -0500 Organization: Alcatel Networks Corporaton Lines: 96 Sender: pwe3-admin@ietf.org References: <5.2.0.9.2.20030331122332.04d68e60@bucket.cisco.com> <5.2.0.9.2.20030403133908.02b366a0@bucket.cisco.com> <3E8C8B29.DF6836EC@alcatel.com> <3E8D60A1.4010901@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Apr 04 19:49:23 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: stbryant@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, Stewart Bryant wrote: > > Mustapha Aissaoui wrote: > > "Thomas D. Nadeau" wrote: > > > >>At 12:31 PM 4/3/2003 -0500, Mustapha Aissaoui wrote: > >> > >>>Tom, > >>> > >>>"Thomas D. Nadeau" wrote: > >>> > >>>>>The Requirements document says nothing about the issue > >>>>>of a PW aliasing an IP packet (the CW PID issue). It > >>>>>is clear from comments on the list that a PW that > >>>>>does not take this into account will be subject to > >>>>>disruption when traversing an ECMP enabled MPLS core, and > >>>>>I raised concerns about psamp/ipfix. > >>>>> > >>>>>I think that there needs to be a requirement added to > >>>>>to the effect that a PW must operate correctly over a PSN > >>>>>that provides ECMP, and a possibly a requirement that > >>>>>allows IP flow monitoring. Whether this gets resolved in > >>>>>PWE3 or in MPLS is OoS, but as PWE3 is the first payload > >>>>>that he IETF has defined that has this problem, it > >>>>>generates the requirement. > >>>>> > >>>>>Something like: > >>>>> > >>>>>"If the PSN uses an ECMP or IP flow recognition method, > >>>>>then the PW encapsulation must use a method discriminating > >>>>>between itself and an IP flow" > >>>> > >>>> I think that it is hard to determine if the PSN > >>>>employs an ECMP or flow recognition method other > >>>>that knowing a priori that they might exist. I think it > >>>>might be more straight-forward to just state, > >>>> > >>>> "The PW encapsulation must use a method whereby > >>>>any PW can be distinguished from other flows traversing the > >>>>PSN." > >>>> > >>>> That seems to cover all the cases. > >>> > >>>Your sentence generalizes the issue beyond what the stated issue > >>>was. What was stated was to make sure that the PSN does not > >>>misinterpret a PW payload for a IPv4 or IPv6 packet in some specific > >>>situations (ECMP was one). We are not saying that the core nodes > >>>require to distinguish a PW from some other TBD payload, which may > >>>not be relevant to it (e.g., OAM messages). > >> > >> My suggestion says nothing about core or edge or otherwise > >>nodes and neityher does the original one. The implicit assumption is > >>that the PW encapsulation not violate the forwarding behavior of > >>existing MPLS or IP P routers. > >> > >> --Tom > > > > > > Yes, but your statement says that a router has to be able to > > distinguish a PW from any other payload type, not just IP. This is > > not required at all. > > At the moment we only have 3 payload types, IPv4, IPv6 and PW. > We cannot make the assumption that there will not be another > of interest to a core router at some time in the future. > > This issue arrises in PWE3, not because PWs are special, but > because they are the first non-IP MPLS payload standardised > by the IETF. I agree that we cannot make that assumption. This is why I suggest that we resolve the issue of protocol identification in broader context than the current IP aliasing issue. So far I have seen the following three issues raised: 1. IP aliasing: making sure that PW wire traffic does not get mistaken for an IPv4 or an IPv6 packet when ECMP or some sort of load-balancing is applied. 2. Making sure that PW OAM messages are identified properly from user packets in a PE. Then make sure they traverses the same path as user traffic, again in the case of ECMP or load-balancing. 3. Allow for more than one protocol in the pseudo-wire. I have customers telling me that their customers have a mix of protocols in the same VC in the current FR/ATM L2 services (mix of bridged and routed PDUs where bridged does not mean it is always Ethernet). In many cases, these service providers cannot make assumptions about what their customers are carrying in a VC (this is what a L2 service is about in the first place). Regards, Mustapha. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Proposed changes to MPLS CW in arch draft Date: Fri, 4 Apr 2003 21:38:09 +0200 Lines: 339 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Apr 04 20:47:56 2003 Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart (and all), Thank you for presenting the proposed text for review. This, by itself, is most commendable. I also have a (hopefully, minor) issue with the proposed text. Section 5.4.2 explicitly allows presence of an RTP header immediately after the PW demutiplexer and, indeed, the SONET and (most of) the TDM drafts by default place this header in the prescribed position. However, in this case the first word of the RTP header is placed exactly where, in all the rest of the cases, the PW control word would be. On the other hand, Section 5.4.4 opens with words: Where the PW control word may alias an IP packet... So, first of all, the consequent text does not seem to cover the case when the RTP header is present between the PW demultiplexer and the PW control word. Second, it is not clear whether an MPLS payload type identifier should be inserted between the MPLS PW demultiplexer and RTP header: a) This header cannot alias an IPv4 or IPv6 packet. In fact, its first nibble is always '1000' in all known proposals and we may probably enforce that by specifying that, when RTP is used in conjunction with PWs, neither RTP header extensions nor padding can be used. b) However, if we rely exclusively on the first nibble of the RTP header for not aliasing IP packets, we de-facto reserve one more 4-bit value (8) for the use of PWs. So if we go for this approach, this fact IMO should be mentioned in the "IANA Considerations" section of the draft. Personally I think that it would be quite safe to allow an RTP header directly between the MPLS PW demultiplexer (aka VC label) and the PW CW, and I hope that the WG would accept that. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, April 03, 2003 3:00 PM > To: pwe3@ietf.org > Subject: [PWE3] Proposed changes to MPLS CW in arch draft > > > > > This is the text that I propose for sections 5.4.2, 5.4.3 and the > new 5.4.4 in draft-pwe3-arch-03.txt > > In section 5.4.2 the MPLS payload type identifier is shown in the > relation to the PW label and the CW. > > In section 5.4.3 the issue of IP packet aliasing is introduced, > and the generic and the SONET CWs are defined. It is noted that > the "Martini" style of CW does not have this aliasing issue. > > The new section 5.4.4 includes the MPLS payload type identifier for > reference and shows how IP packets can be multiplexed over the PW > for management purposes. > > Stewart > > > > 5.4.2. PWE3 over an MPLS PSN > > The MPLS ethos places importance on wire efficiency. By using a > control word, some components of the PWE3 protocol layers can be > compressed to increase this efficiency. > > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H------------------------+ > H---------------------H | | > H Sequencing H-----| | > \=====================/ | | > | PW Demultiplexer |---+ | v > +---------------------+ | | +--------------------------------+ > | PSN Convergence |-----| . . > +---------------------+ | | . RTP . > | PSN |-+ | | | | > +---------------------+ | | | +--------------------------------+ > | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | Physical | | | | MPLS Payl'd Type Indent | > +---------------------+ | | +--------------------------------+ > | +--->| PW Label | > | +--------------------------------+ > +----->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > Figure 11: PWE3 over an MPLS PSN using a control word > > Figure 11 shows the protocol layering for PWE3 over an > MPLS PSN. An > inner MPLS label is used to provide the PW demultiplexing > function. > A control word is used to carry most of the information > needed by the > PWE3 Encapsulation Layer and the PSN Convergence Layer in > a compact > format. The flags in the control word provide the > necessary payload > convergence. A sequence field provides support for both in-order > payload delivery and (supported by a fragmentation > control method) a > PSN fragmentation service within the PSN Convergence > Layer. Ethernet > pads all frames to a minimum size of 64 bytes. The MPLS > header does > not include a length indicator. Therefore to allow PWE3 > to be carried > in MPLS to correctly pass over an Ethernet data-link, a length > correction field is needed in the control word. Where the > design of > the control word would alias an IP packet, an MPLS Payload Type > Identifier should be interposed between the PW label and > the control > word (see 5.4.4). As with an IP PSN, where appropriate, timing is > provided by RTP [RFC1889]. > > In some networks it may be necessary to carry PWE3 over > MPLS over IP. > In these circumstances, the PW is encapsulated for > carriage over MPLS > as described in this section, and then a method of > carrying MPLS over > an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the > resultant PW-PDU. > > 5.4.3. PW over MPLS Generic Control Word > > To allow accurate packet inspection in an MPLS PSN, and to operate > correctly over MPLS PSNs that have deployed equal-cost > multiple-path > load-ballancing a PW packet MUST NOT alias an IP packet. > IP packets > are carried in MPLS label stacks without any protocol identifier. > Historic values of the IP version number [RFC791] [RFC1881] are > therefore used to distinguish between IP and non-IP MPLS payloads. > > A PW SHOULD employ either the generic PW control word or an MPLS > payload type identifier to disambiguate the PW from an IP flow. > > The PW set-up protocol determines whether a particular PW uses a > control word. When a control word is used, it MUST have the > following form for non-SONET encapsulations: > > > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Flags |FRG| Length | Sequence Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: MPLS Generic Control Word (non-SONET) > > Note that a with packet bits 0..3 = 4 indicates an IPv4 > MPLS payload > and a packet with bits 0..3 = 6 indicates an IPv6 MPLS playload. > > The meaning of the fields of the MPLS Generic Control Word (non- > SONET) (Figure 12) is as follows: > > Flags (bits 4 to 7): > These bits are available for per payload signaling. Their > definition is encapsulation specific. > > FRG (bits 8 and 9): > These bits are used when fragmenting a PW > payload. Their use > is defined in [FRAG]. When the PW is of a type > that will never > need payload fragmentation, these bits may be > used as general > purpose flags. > > Length (bits 10 to 15): > The length field is used to determine the size of a PW > payload that might have been padded to the > minimum Ethernet > MAC frame size during its transit across the PSN. If the > MPLS payload (defined as the CW + the PW payload + any > additional PW headers is less than 46 bytes, the > length MUST > be set to the length of the MPLS payload. If the MPLS > payload is between 46 bytes and 63 bytes the > implementation > MAY either set to the length to the length of the MPLS > payload, or it MAY set it to 0. If the length of the MPLS > payload is greater than 63 bytes the length MUST > be set to 0. > > Sequence number (Bit 16 to 31): > If the sequence number is not used, it is set to zero by > the sender and ignored by the receiver. Otherwise it > specifies the sequence number of a packet. A > circular list > of sequence numbers is used. A sequence number > takes a value > from 1 to 65535 (2**16-1). If the payload is an > OAM packet > the sequence number MAY be used to mark the > position in the > sequence, in which case it has the same value as the last > data PDU sent. The use of the sequence number is optional > for OAM payloads. > > The PW control word used in SONET applications must use > the following > general forms. > > Non-extended: > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Flags | Structure Pointer[0:12] | Sequence > Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Extended: > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Flags | Structure Pointer[0:12] | Sequence > Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Additional encapsulation-specific header > fields | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: MPLS Generic Control Word (SONET) > > The meaning of the fields of the MPLS Generic Control Word (SONET) > (Figure 13) is as follows: > > Structure Pointer[0:12]: > If used, the Structure Pointer contains the offset of the > first byte of the payload structure. > > Sequence Number[0:13]: This is a packet sequence > number, which > continuously cycles from 0 to 0x3FFF. It is generated and > processed in accordance with the rules > established in [RFC1889]. > When the RTP header is used, this sequence number > MUST match the > LSBs of the RTP sequence Number. > > 5.4.4. MPLS Payload Identifier > > Where the PW control word may alias an IP packet (for example the > MPLS Generic Control Word (SONET)), the control word SHOULD be > preceeded by an MPLS payload type identifier. > > For reference the MPLS payload type identifier [TBD] is defined as > follows: > > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved | PPP DLL Protocol > Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | As defined by PPP DLL protocol > definition | > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: MPLS Payload Type Identifier > > PPP DLL Protocol Number [16:31]: > These numbers are assigned by IANA. > > Some PW management messages such as OAM and LSP ping may > require IP > packets to be multiplexed onto the PW. These are carried > over the PW > using the IP MPLS payload type indicator, show in Figure 15: > > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved | IPv4 = 0x21, or > IPv6 = 0x57 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IP packet and management payload > | > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 15: MPLS Payload Type Identifier > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Proposed changes to MPLS CW in arch draft Date: Fri, 4 Apr 2003 10:58:37 -0800 Lines: 371 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Apr 04 21:02:31 2003 Return-path: To: "'Sasha Vainshtein'" , "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, Why don't you put RTP header after the CW? -Shahram >-----Original Message----- >From: Sasha Vainshtein [mailto:Sasha@axerra.com] >Sent: Friday, April 04, 2003 2:38 PM >To: 'stbryant@cisco.com' >Cc: pwe3@ietf.org >Subject: RE: [PWE3] Proposed changes to MPLS CW in arch draft > > >Stewart (and all), >Thank you for presenting the proposed text for review. >This, by itself, is most commendable. > >I also have a (hopefully, minor) issue with the proposed text. >Section 5.4.2 explicitly allows presence of an RTP header >immediately after the PW demutiplexer and, indeed, the SONET >and (most of) the TDM drafts by default place this header >in the prescribed position. However, in this case the first >word of the RTP header is placed exactly where, in all the >rest of the cases, the PW control word would be. On the other >hand, Section 5.4.4 opens with words: > > > Where the PW control word may alias an IP packet... > > >So, first of all, the consequent text does not seem to cover the >case when the RTP header is present between the PW demultiplexer >and the PW control word. > >Second, it is not clear whether an MPLS payload type identifier >should be inserted between the MPLS PW demultiplexer and RTP header: > >a) This header cannot alias an IPv4 or IPv6 packet. > In fact, its first nibble is always '1000' in all known proposals > and we may probably enforce that by specifying that, when RTP > is used in conjunction with PWs, neither RTP header extensions > nor padding can be used. >b) However, if we rely exclusively on the first nibble of the >RTP header > for not aliasing IP packets, we de-facto reserve one more >4-bit value > (8) for the use of PWs. So if we go for this approach, this fact IMO > should be mentioned in the "IANA Considerations" section of >the draft. > >Personally I think that it would be quite safe to allow an RTP header >directly between the MPLS PW demultiplexer (aka VC label) and >the PW CW, >and I hope that the WG would accept that. > >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Thursday, April 03, 2003 3:00 PM >> To: pwe3@ietf.org >> Subject: [PWE3] Proposed changes to MPLS CW in arch draft >> >> >> >> >> This is the text that I propose for sections 5.4.2, 5.4.3 and the >> new 5.4.4 in draft-pwe3-arch-03.txt >> >> In section 5.4.2 the MPLS payload type identifier is shown in the >> relation to the PW label and the CW. >> >> In section 5.4.3 the issue of IP packet aliasing is introduced, >> and the generic and the SONET CWs are defined. It is noted that >> the "Martini" style of CW does not have this aliasing issue. >> >> The new section 5.4.4 includes the MPLS payload type identifier for >> reference and shows how IP packets can be multiplexed over the PW >> for management purposes. >> >> Stewart >> >> >> >> 5.4.2. PWE3 over an MPLS PSN >> >> The MPLS ethos places importance on wire efficiency. By using a >> control word, some components of the PWE3 protocol layers can be >> compressed to increase this efficiency. >> >> >> +---------------------+ >> | Payload | >> /=====================\ >> H Payload Convergence H-----+ >> H---------------------H | >> H Timing H------------------------+ >> H---------------------H | | >> H Sequencing H-----| | >> \=====================/ | | >> | PW Demultiplexer |---+ | v >> +---------------------+ | | +--------------------------------+ >> | PSN Convergence |-----| . . >> +---------------------+ | | . RTP . >> | PSN |-+ | | | | >> +---------------------+ | | | +--------------------------------+ >> | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | >> +---------------------+ | | +--------------------------------+ >> | Physical | | | | MPLS Payl'd Type Indent | >> +---------------------+ | | +--------------------------------+ >> | +--->| PW Label | >> | +--------------------------------+ >> +----->| Outer Label or MPLS-in-IP encap| >> +--------------------------------+ >> >> Figure 11: PWE3 over an MPLS PSN using a control word >> >> Figure 11 shows the protocol layering for PWE3 over an >> MPLS PSN. An >> inner MPLS label is used to provide the PW demultiplexing >> function. >> A control word is used to carry most of the information >> needed by the >> PWE3 Encapsulation Layer and the PSN Convergence Layer in >> a compact >> format. The flags in the control word provide the >> necessary payload >> convergence. A sequence field provides support for both in-order >> payload delivery and (supported by a fragmentation >> control method) a >> PSN fragmentation service within the PSN Convergence >> Layer. Ethernet >> pads all frames to a minimum size of 64 bytes. The MPLS >> header does >> not include a length indicator. Therefore to allow PWE3 >> to be carried >> in MPLS to correctly pass over an Ethernet data-link, a length >> correction field is needed in the control word. Where the >> design of >> the control word would alias an IP packet, an MPLS Payload Type >> Identifier should be interposed between the PW label and >> the control >> word (see 5.4.4). As with an IP PSN, where appropriate, >timing is >> provided by RTP [RFC1889]. >> >> In some networks it may be necessary to carry PWE3 over >> MPLS over IP. >> In these circumstances, the PW is encapsulated for >> carriage over MPLS >> as described in this section, and then a method of >> carrying MPLS over >> an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the >> resultant PW-PDU. >> >> 5.4.3. PW over MPLS Generic Control Word >> >> To allow accurate packet inspection in an MPLS PSN, and >to operate >> correctly over MPLS PSNs that have deployed equal-cost >> multiple-path >> load-ballancing a PW packet MUST NOT alias an IP packet. >> IP packets >> are carried in MPLS label stacks without any protocol identifier. >> Historic values of the IP version number [RFC791] [RFC1881] are >> therefore used to distinguish between IP and non-IP MPLS >payloads. >> >> A PW SHOULD employ either the generic PW control word or an MPLS >> payload type identifier to disambiguate the PW from an IP flow. >> >> The PW set-up protocol determines whether a particular PW uses a >> control word. When a control word is used, it MUST have the >> following form for non-SONET encapsulations: >> >> >> 0 1 2 >> 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 0 0| Flags |FRG| Length | Sequence Number >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 12: MPLS Generic Control Word (non-SONET) >> >> Note that a with packet bits 0..3 = 4 indicates an IPv4 >> MPLS payload >> and a packet with bits 0..3 = 6 indicates an IPv6 MPLS playload. >> >> The meaning of the fields of the MPLS Generic Control Word (non- >> SONET) (Figure 12) is as follows: >> >> Flags (bits 4 to 7): >> These bits are available for per payload >signaling. Their >> definition is encapsulation specific. >> >> FRG (bits 8 and 9): >> These bits are used when fragmenting a PW >> payload. Their use >> is defined in [FRAG]. When the PW is of a type >> that will never >> need payload fragmentation, these bits may be >> used as general >> purpose flags. >> >> Length (bits 10 to 15): >> The length field is used to determine the size of a PW >> payload that might have been padded to the >> minimum Ethernet >> MAC frame size during its transit across the PSN. If the >> MPLS payload (defined as the CW + the PW payload + any >> additional PW headers is less than 46 bytes, the >> length MUST >> be set to the length of the MPLS payload. If the MPLS >> payload is between 46 bytes and 63 bytes the >> implementation >> MAY either set to the length to the length of the MPLS >> payload, or it MAY set it to 0. If the length >of the MPLS >> payload is greater than 63 bytes the length MUST >> be set to 0. >> >> Sequence number (Bit 16 to 31): >> If the sequence number is not used, it is set to zero by >> the sender and ignored by the receiver. Otherwise it >> specifies the sequence number of a packet. A >> circular list >> of sequence numbers is used. A sequence number >> takes a value >> from 1 to 65535 (2**16-1). If the payload is an >> OAM packet >> the sequence number MAY be used to mark the >> position in the >> sequence, in which case it has the same value as the last >> data PDU sent. The use of the sequence number >is optional >> for OAM payloads. >> >> The PW control word used in SONET applications must use >> the following >> general forms. >> >> Non-extended: >> 0 1 2 >> 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| Flags | Structure Pointer[0:12] | Sequence >> Number[0:13] | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Extended: >> 0 1 2 >> 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1| Flags | Structure Pointer[0:12] | Sequence >> Number[0:13] | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Additional encapsulation-specific header >> fields | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 13: MPLS Generic Control Word (SONET) >> >> The meaning of the fields of the MPLS Generic Control >Word (SONET) >> (Figure 13) is as follows: >> >> Structure Pointer[0:12]: >> If used, the Structure Pointer contains the offset of the >> first byte of the payload structure. >> >> Sequence Number[0:13]: This is a packet sequence >> number, which >> continuously cycles from 0 to 0x3FFF. It is >generated and >> processed in accordance with the rules >> established in [RFC1889]. >> When the RTP header is used, this sequence number >> MUST match the >> LSBs of the RTP sequence Number. >> >> 5.4.4. MPLS Payload Identifier >> >> Where the PW control word may alias an IP packet (for example the >> MPLS Generic Control Word (SONET)), the control word SHOULD be >> preceeded by an MPLS payload type identifier. >> >> For reference the MPLS payload type identifier [TBD] is >defined as >> follows: >> >> 0 1 2 >> 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 >> 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 0 1| reserved | PPP DLL Protocol >> Number | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | As defined by PPP DLL protocol >> definition | >> | >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 14: MPLS Payload Type Identifier >> >> PPP DLL Protocol Number [16:31]: >> These numbers are assigned by IANA. >> >> Some PW management messages such as OAM and LSP ping may >> require IP >> packets to be multiplexed onto the PW. These are carried >> over the PW >> using the IP MPLS payload type indicator, show in Figure 15: >> >> 0 1 2 >> 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 >> 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 0 1| reserved | IPv4 = 0x21, or >> IPv6 = 0x57 | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IP packet and management payload >> | >> | >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 15: MPLS Payload Type Identifier >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: I-D ACTION:draft-allan-mpls-pid-00.txt Date: Fri, 4 Apr 2003 12:25:03 -0800 Lines: 77 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Fri Apr 04 22:28:41 2003 Return-path: To: "David Allan (E-mail)" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Dave, I have a few questions/comments: 1) Last sentence of section 2: It is not clear what the loopback address is. I assume it is not a 127/8 address. 2) Could you please explain bullet 2 of section 4 a bit more. 3) Section 6: I assume by no PHP you mean when there is only one label to be poped. right? Also it might be possible to get a PPP PID for the extended Payload ID control-word. Yours, Shahram >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Friday, April 04, 2003 6:44 AM >Cc: mpls@uu.net; pwe3@ietf.org >Subject: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > > > Title : MPLS and IP PW Payload ID > Author(s) : D. Allan > Filename : draft-allan-mpls-pid-00.txt > Pages : 0 > Date : 2003-4-3 > >This memo defines an MPLS and PW payload ID. It describes how an >MPLS payload ID may be used to address a number of issues associated >with proprietary ECMP deployments. It describes how when used with >PWs permits OAM and control protocols to be multiplexed with a PW. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of >the message. > >Internet-Drafts are also available by anonymous FTP. Login >with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-allan-mpls-pid-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-allan-mpls-pid-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant >mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: I-D ACTION:draft-allan-mpls-pid-00.txt Date: Fri, 4 Apr 2003 12:28:29 -0800 Lines: 96 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'pwe3@ietf.org'" , "'mpls@uu.net'" X-From: pwe3-admin@ietf.org Fri Apr 04 22:31:10 2003 Return-path: To: Shahram Davari , "'David Allan (E-mail)'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Dave, Also isn't it better to use '0000' instead of '1000' for the first nibble. This way it won't interfere with any implementation. -Shahram >-----Original Message----- >From: Shahram Davari >Sent: Friday, April 04, 2003 3:25 PM >To: David Allan (E-mail) >Cc: pwe3@ietf.org; mpls@uu.net >Subject: RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt > > >Hi Dave, > >I have a few questions/comments: > >1) Last sentence of section 2: It is not clear what the >loopback address is. I assume it is not a 127/8 address. > >2) Could you please explain bullet 2 of section 4 a bit more. > >3) Section 6: I assume by no PHP you mean when there is only >one label to be poped. right? >Also it might be possible to get a PPP PID for the extended >Payload ID control-word. > >Yours, >Shahram > >>-----Original Message----- >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Sent: Friday, April 04, 2003 6:44 AM >>Cc: mpls@uu.net; pwe3@ietf.org >>Subject: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt >> >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >> >> >> Title : MPLS and IP PW Payload ID >> Author(s) : D. Allan >> Filename : draft-allan-mpls-pid-00.txt >> Pages : 0 >> Date : 2003-4-3 >> >>This memo defines an MPLS and PW payload ID. It describes how an >>MPLS payload ID may be used to address a number of issues associated >>with proprietary ECMP deployments. It describes how when used with >>PWs permits OAM and control protocols to be multiplexed with a PW. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt >> >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body of >>the message. >> >>Internet-Drafts are also available by anonymous FTP. Login >>with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-allan-mpls-pid-00.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-allan-mpls-pid-00.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >>mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: I-D ACTION:draft-allan-mpls-pid-00.txt Date: Fri, 4 Apr 2003 15:42:41 -0500 Lines: 304 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FAEA.BCF6311C" Cc: pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Fri Apr 04 22:45:17 2003 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FAEA.BCF6311C Content-Type: text/plain; charset="iso-8859-1" Hi Shahram: > I have a few questions/comments: > > 1) Last sentence of section 2: It is not clear what the > loopback address is. I assume it is not a 127/8 address. Correct, it is the LSR/PEs own loopback address. not an internal link loopback address. > 2) Could you please explain bullet 2 of section 4 a bit more. Hmmmm, if an LSP of level 'n' transports other LSPs (carries MPLS payload), and load spreading makes a descision for forwarding that includes those other LSPs labels in its deliberations, then those other LSPs do not necessarily forward consistently with the LSP that you tested at level 'n'. If the LSP of level 'n' only carries other payloads (IP, PW payloads etc.), then you will have consistency. I'll try to come up with some better wording. > 3) Section 6: I assume by no PHP you mean when there is only > one label to be poped. right? Deployed PHP would then forward the Payload ID and subsequent payload. Probably a good reason for using an unassigned version number. > Also it might be possible to > get a PPP PID for the extended Payload ID control-word. The more PID types we add, the more complex implementations will be. Lets discuss. cheers Dave > > Yours, > Shahram > > >-----Original Message----- > >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >Sent: Friday, April 04, 2003 6:44 AM > >Cc: mpls@uu.net; pwe3@ietf.org > >Subject: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt > > > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > > > > > > Title : MPLS and IP PW Payload ID > > Author(s) : D. Allan > > Filename : draft-allan-mpls-pid-00.txt > > Pages : 0 > > Date : 2003-4-3 > > > >This memo defines an MPLS and PW payload ID. It describes > how an MPLS > >payload ID may be used to address a number of issues associated with > >proprietary ECMP deployments. It describes how when used with PWs > >permits OAM and control protocols to be multiplexed with a PW. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt > > > >To remove yourself from the IETF Announcement list, send a message to > >ietf-announce-request with the word unsubscribe in the body of > >the message. > > > >Internet-Drafts are also available by anonymous FTP. Login > >with the username > >"anonymous" and a password of your e-mail address. After logging in, > >type "cd internet-drafts" and then > > "get draft-allan-mpls-pid-00.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html or > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-allan-mpls-pid-00.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > >mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > > > ------_=_NextPart_001_01C2FAEA.BCF6311C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt

Hi Shahram:

> I have a few questions/comments:
>
> 1) Last sentence of section 2: It is not clear = what the
> loopback address is. I assume it is not a 127/8 = address.

Correct, it is the LSR/PEs own loopback address. not = an internal link loopback address.

> 2) Could you please explain bullet 2 of section = 4 a bit more.

Hmmmm, if an LSP of level 'n' transports other LSPs = (carries MPLS payload), and load spreading makes a descision for = forwarding that includes those other LSPs labels in its deliberations, = then those other LSPs do not necessarily forward consistently with the = LSP that you tested at level 'n'.

If the LSP of level 'n' only carries other payloads = (IP, PW payloads etc.), then you will have consistency. I'll try to = come up with some better wording.

 
> 3) Section 6: I assume by no PHP you mean when = there is only
> one label to be poped. right?

Deployed PHP would then forward the Payload ID and = subsequent payload. Probably a good reason for using an unassigned = version number.

> Also it might be possible to
> get a PPP PID for the extended Payload ID = control-word.

The more PID types we add, the more complex = implementations will be. Lets discuss.

cheers
Dave
 
>
> Yours,
> Shahram
>
> >-----Original Message-----
> >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> >Sent: Friday, April 04, 2003 6:44 AM
> >Cc: mpls@uu.net; pwe3@ietf.org
> >Subject: [PWE3] I-D = ACTION:draft-allan-mpls-pid-00.txt
> >
> >
> >A New Internet-Draft is available from the = on-line
> >Internet-Drafts directories.
> >
> >
> >     Title   =         : MPLS and IP PW Payload = ID
> >     = Author(s)       : D. Allan
> >     = Filename        : = draft-allan-mpls-pid-00.txt
> >     Pages   =         : 0
> >     = Date            : = 2003-4-3
> >    
> >This memo defines an MPLS and PW payload = ID. It describes
> how an MPLS
> >payload ID may be used to address a number = of issues associated with
> >proprietary ECMP deployments. It describes = how when used with PWs
> >permits OAM and control protocols to be = multiplexed with a PW.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-allan-mpls-p= id-00.txt
> >
> >To remove yourself from the IETF = Announcement list, send a message to
> >ietf-announce-request with the word = unsubscribe in the body of
> >the message.
> >
> >Internet-Drafts are also available by = anonymous FTP. Login
> >with the username
> >"anonymous" and a password of = your e-mail address. After logging in,
> >type "cd internet-drafts" and = then
> >     "get = draft-allan-mpls-pid-00.txt".
> >
> >A list of Internet-Drafts directories can = be found in
> >http://www.ietf.org/shadow.html or
> >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by = e-mail.
> >
> >Send a message to:
> >     = mailserv@ietf.org.
> >In the body type:
> >     "FILE = /internet-drafts/draft-allan-mpls-pid-00.txt".
> >    
> = >NOTE:        The mail server at = ietf.org can return the document in
> >     MIME-encoded form = by using the "mpack" utility.  To use this
> >     feature, insert = the command "ENCODING mime" before the = "FILE"
> >     command.  To = decode the response(s), you will need "munpack" or
> >     a MIME-compliant = mail reader.  Different MIME-compliant
> >mail readers
> >     exhibit different = behavior, especially when dealing with
> >     = "multipart" MIME messages (i.e. documents which have been = split
> >     up into multiple = messages), so check your local documentation on
> >     how to manipulate = these messages.
> >     =        
> >     =        
> >Below is the data which will enable a MIME = compliant mail reader
> >implementation to automatically retrieve = the ASCII version of the
> >Internet-Draft.
> >
>

------_=_NextPart_001_01C2FAEA.BCF6311C-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: I-D ACTION:draft-allan-mpls-pid-00.txt Date: Fri, 4 Apr 2003 12:49:12 -0800 Lines: 269 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FAEB.A57D12F2" Cc: pwe3@ietf.org, mpls@uu.net X-From: pwe3-admin@ietf.org Fri Apr 04 22:52:50 2003 Return-path: To: "'David Allan'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FAEB.A57D12F2 Content-Type: text/plain; charset="iso-8859-1" Dave, For the PHP, I didn't mean a new PID inside extended control word. What I meant was a link PID. For example if the link is POS (packet over sonet) then a PPP PID for the PPP header that wraps the packet could identify the payload as being of extended control word nature. -Shahram -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Friday, April 04, 2003 3:43 PM To: Shahram Davari Cc: pwe3@ietf.org; mpls@uu.net Subject: RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt Hi Shahram: > I have a few questions/comments: > > 1) Last sentence of section 2: It is not clear what the > loopback address is. I assume it is not a 127/8 address. Correct, it is the LSR/PEs own loopback address. not an internal link loopback address. > 2) Could you please explain bullet 2 of section 4 a bit more. Hmmmm, if an LSP of level 'n' transports other LSPs (carries MPLS payload), and load spreading makes a descision for forwarding that includes those other LSPs labels in its deliberations, then those other LSPs do not necessarily forward consistently with the LSP that you tested at level 'n'. If the LSP of level 'n' only carries other payloads (IP, PW payloads etc.), then you will have consistency. I'll try to come up with some better wording. > 3) Section 6: I assume by no PHP you mean when there is only > one label to be poped. right? Deployed PHP would then forward the Payload ID and subsequent payload. Probably a good reason for using an unassigned version number. > Also it might be possible to > get a PPP PID for the extended Payload ID control-word. The more PID types we add, the more complex implementations will be. Lets discuss. cheers Dave > > Yours, > Shahram > > >-----Original Message----- > >From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org ] > >Sent: Friday, April 04, 2003 6:44 AM > >Cc: mpls@uu.net; pwe3@ietf.org > >Subject: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt > > > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > > > > > > Title : MPLS and IP PW Payload ID > > Author(s) : D. Allan > > Filename : draft-allan-mpls-pid-00.txt > > Pages : 0 > > Date : 2003-4-3 > > > >This memo defines an MPLS and PW payload ID. It describes > how an MPLS > >payload ID may be used to address a number of issues associated with > >proprietary ECMP deployments. It describes how when used with PWs > >permits OAM and control protocols to be multiplexed with a PW. > > > >A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt > > > >To remove yourself from the IETF Announcement list, send a message to > >ietf-announce-request with the word unsubscribe in the body of > >the message. > > > >Internet-Drafts are also available by anonymous FTP. Login > >with the username > >"anonymous" and a password of your e-mail address. After logging in, > >type "cd internet-drafts" and then > > "get draft-allan-mpls-pid-00.txt". > > > >A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-allan-mpls-pid-00.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > >mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > > > ------_=_NextPart_001_01C2FAEB.A57D12F2 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt
Dave,
 
For the PHP, I didn't mean a new PID inside extended control word. What I meant was a link PID. For example if
the link is POS (packet over sonet) then a PPP PID for the PPP header that wraps the packet could identify the
payload as being of extended control word nature.
 
-Shahram
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Friday, April 04, 2003 3:43 PM
To: Shahram Davari
Cc: pwe3@ietf.org; mpls@uu.net
Subject: RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt

Hi Shahram:

> I have a few questions/comments:
>
> 1) Last sentence of section 2: It is not clear what the
> loopback address is. I assume it is not a 127/8 address.

Correct, it is the LSR/PEs own loopback address. not an internal link loopback address.

> 2) Could you please explain bullet 2 of section 4 a bit more.

Hmmmm, if an LSP of level 'n' transports other LSPs (carries MPLS payload), and load spreading makes a descision for forwarding that includes those other LSPs labels in its deliberations, then those other LSPs do not necessarily forward consistently with the LSP that you tested at level 'n'.

If the LSP of level 'n' only carries other payloads (IP, PW payloads etc.), then you will have consistency. I'll try to come up with some better wording.

 
> 3) Section 6: I assume by no PHP you mean when there is only
> one label to be poped. right?

Deployed PHP would then forward the Payload ID and subsequent payload. Probably a good reason for using an unassigned version number.

> Also it might be possible to
> get a PPP PID for the extended Payload ID control-word.

The more PID types we add, the more complex implementations will be. Lets discuss.

cheers
Dave
 
>
> Yours,
> Shahram
>
> >-----Original Message-----
> >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> >Sent: Friday, April 04, 2003 6:44 AM
> >Cc: mpls@uu.net; pwe3@ietf.org
> >Subject: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt
> >
> >
> >A New Internet-Draft is available from the on-line
> >Internet-Drafts directories.
> >
> >
> >     Title           : MPLS and IP PW Payload ID
> >     Author(s)       : D. Allan
> >     Filename        : draft-allan-mpls-pid-00.txt
> >     Pages           : 0
> >     Date            : 2003-4-3
> >    
> >This memo defines an MPLS and PW payload ID. It describes
> how an MPLS
> >payload ID may be used to address a number of issues associated with
> >proprietary ECMP deployments. It describes how when used with PWs
> >permits OAM and control protocols to be multiplexed with a PW.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt
> >
> >To remove yourself from the IETF Announcement list, send a message to
> >ietf-announce-request with the word unsubscribe in the body of
> >the message.
> >
> >Internet-Drafts are also available by anonymous FTP. Login
> >with the username
> >"anonymous" and a password of your e-mail address. After logging in,
> >type "cd internet-drafts" and then
> >     "get draft-allan-mpls-pid-00.txt".
> >
> >A list of Internet-Drafts directories can be found in
> >http://www.ietf.org/shadow.html or
> >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >     mailserv@ietf.org.
> >In the body type:
> >     "FILE /internet-drafts/draft-allan-mpls-pid-00.txt".
> >    
> >NOTE:        The mail server at ietf.org can return the document in
> >     MIME-encoded form by using the "mpack" utility.  To use this
> >     feature, insert the command "ENCODING mime" before the "FILE"
> >     command.  To decode the response(s), you will need "munpack" or
> >     a MIME-compliant mail reader.  Different MIME-compliant
> >mail readers
> >     exhibit different behavior, especially when dealing with
> >     "multipart" MIME messages (i.e. documents which have been split
> >     up into multiple messages), so check your local documentation on
> >     how to manipulate these messages.
> >            
> >            
> >Below is the data which will enable a MIME compliant mail reader
> >implementation to automatically retrieve the ASCII version of the
> >Internet-Draft.
> >
>

------_=_NextPart_001_01C2FAEB.A57D12F2-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: I-D ACTION:draft-allan-mpls-pid-00.txt Date: Fri, 4 Apr 2003 15:54:04 -0500 Lines: 335 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FAEC.54121AF6" Cc: "'pwe3@ietf.org'" , "'mpls@uu.net'" X-From: pwe3-admin@ietf.org Fri Apr 04 22:57:20 2003 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FAEC.54121AF6 Content-Type: text/plain; charset="iso-8859-1" Actually I suspect someone will suggest that 0000 will collide with deployed stuff ;-) 1000 was chosen not to collide with stuff that after writing I found may not be an issue. If we accept that existing PHP may lead to somthing trying to interpret this stuff, then avoiding all assigned IP version numbers is probably the best choice, which leaves 1-3 and 10-14, or 0 and 15 (the explicitly reserved values). IMO I would lean towards 15, which cannot be interpreted as a protocol at all and does not collide with IANA space. Dave > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Friday, April 04, 2003 3:28 PM > To: Shahram Davari; Allan, David [CAR:NS00:EXCH] > Cc: 'pwe3@ietf.org'; 'mpls@uu.net' > Subject: RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt > > > Dave, > > Also isn't it better to use '0000' instead of '1000' for the > first nibble. This way it won't interfere with any implementation. > > -Shahram > > >-----Original Message----- > >From: Shahram Davari > >Sent: Friday, April 04, 2003 3:25 PM > >To: David Allan (E-mail) > >Cc: pwe3@ietf.org; mpls@uu.net > >Subject: RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt > > > > > >Hi Dave, > > > >I have a few questions/comments: > > > >1) Last sentence of section 2: It is not clear what the > >loopback address is. I assume it is not a 127/8 address. > > > >2) Could you please explain bullet 2 of section 4 a bit more. > > > >3) Section 6: I assume by no PHP you mean when there is only > >one label to be poped. right? > >Also it might be possible to get a PPP PID for the extended > >Payload ID control-word. > > > >Yours, > >Shahram > > > >>-----Original Message----- > >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>Sent: Friday, April 04, 2003 6:44 AM > >>Cc: mpls@uu.net; pwe3@ietf.org > >>Subject: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt > >> > >> > >>A New Internet-Draft is available from the on-line > >>Internet-Drafts directories. > >> > >> > >> Title : MPLS and IP PW Payload ID > >> Author(s) : D. Allan > >> Filename : draft-allan-mpls-pid-00.txt > >> Pages : 0 > >> Date : 2003-4-3 > >> > >>This memo defines an MPLS and PW payload ID. It describes > how an MPLS > >>payload ID may be used to address a number of issues > associated with > >>proprietary ECMP deployments. It describes how when used with PWs > >>permits OAM and control protocols to be multiplexed with a PW. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt > >> > >>To remove yourself from the IETF Announcement list, send a > message to > >>ietf-announce-request with the word unsubscribe in the body of > >>the message. > >> > >>Internet-Drafts are also available by anonymous FTP. Login > >>with the username > >>"anonymous" and a password of your e-mail address. After logging in, > >>type "cd internet-drafts" and then > >> "get draft-allan-mpls-pid-00.txt". > >> > >>A list of Internet-Drafts directories can be found in > >>http://www.ietf.org/shadow.html or > >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE /internet-drafts/draft-allan-mpls-pid-00.txt". > >> > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant > >>mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> > >>Below is the data which will enable a MIME compliant mail reader > >>implementation to automatically retrieve the ASCII version of the > >>Internet-Draft. > >> > > > ------_=_NextPart_001_01C2FAEC.54121AF6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt

Actually I suspect someone will suggest that 0000 = will collide with deployed stuff ;-)

1000 was chosen not to collide with stuff that after = writing I found may not be an issue. If we accept that existing PHP may = lead to somthing trying to interpret this stuff, then avoiding all = assigned IP version numbers is probably the best choice, which leaves = 1-3 and 10-14, or 0 and 15 (the explicitly reserved values). IMO I = would lean towards 15, which cannot be interpreted as a protocol at all = and does not collide with IANA space.

Dave

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-= sierra.com]
> Sent: Friday, April 04, 2003 3:28 PM
> To: Shahram Davari; Allan, David = [CAR:NS00:EXCH]
> Cc: 'pwe3@ietf.org'; 'mpls@uu.net'
> Subject: RE: [PWE3] I-D = ACTION:draft-allan-mpls-pid-00.txt
>
>
> Dave,
>
> Also isn't it better to use '0000' instead of = '1000' for the
> first nibble. This way it won't interfere with = any implementation.
>
> -Shahram
>
> >-----Original Message-----
> >From: Shahram Davari
> >Sent: Friday, April 04, 2003 3:25 PM
> >To: David Allan (E-mail)
> >Cc: pwe3@ietf.org; mpls@uu.net
> >Subject: RE: [PWE3] I-D = ACTION:draft-allan-mpls-pid-00.txt
> >
> >
> >Hi Dave,
> >
> >I have a few questions/comments:
> >
> >1) Last sentence of section 2: It is not = clear what the
> >loopback address is. I assume it is not a = 127/8 address.
> >
> >2) Could you please explain bullet 2 of = section 4 a bit more.
> >
> >3) Section 6: I assume by no PHP you mean = when there is only
> >one label to be poped. right?
> >Also it might be possible to get a PPP PID = for the extended
> >Payload ID control-word.
> >
> >Yours,
> >Shahram
> >
> >>-----Original Message-----
> >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> >>Sent: Friday, April 04, 2003 6:44 = AM
> >>Cc: mpls@uu.net; pwe3@ietf.org
> >>Subject: [PWE3] I-D = ACTION:draft-allan-mpls-pid-00.txt
> >>
> >>
> >>A New Internet-Draft is available from = the on-line
> >>Internet-Drafts directories.
> >>
> >>
> >>    Title   =         : MPLS and IP PW Payload = ID
> >>    = Author(s)       : D. Allan
> >>    = Filename        : = draft-allan-mpls-pid-00.txt
> >>    Pages   =         : 0
> >>    = Date            : = 2003-4-3
> >>   
> >>This memo defines an MPLS and PW = payload ID. It describes
> how an MPLS
> >>payload ID may be used to address a = number of issues
> associated with
> >>proprietary ECMP deployments. It = describes how when used with PWs
> >>permits OAM and control protocols to be = multiplexed with a PW.
> >>
> >>A URL for this Internet-Draft is: =
> >>http://www.ietf.org/internet-drafts/draft-allan-mpls-p= id-00.txt
> >>
> >>To remove yourself from the IETF = Announcement list, send a
> message to
> >>ietf-announce-request with the word = unsubscribe in the body of
> >>the message.
> >>
> >>Internet-Drafts are also available by = anonymous FTP. Login
> >>with the username
> >>"anonymous" and a password of = your e-mail address. After logging in,
> >>type "cd internet-drafts" and = then
> >>    "get = draft-allan-mpls-pid-00.txt".
> >>
> >>A list of Internet-Drafts directories = can be found in
> >>http://www.ietf.org/shadow.html or
> >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >>
> >>Internet-Drafts can also be obtained by = e-mail.
> >>
> >>Send a message to:
> >>    = mailserv@ietf.org.
> >>In the body type:
> >>    "FILE = /internet-drafts/draft-allan-mpls-pid-00.txt".
> >>   
> = >>NOTE:       The mail server at = ietf.org can return the document in
> >>    MIME-encoded form by = using the "mpack" utility.  To use this
> >>    feature, insert the = command "ENCODING mime" before the "FILE"
> >>    command.  To = decode the response(s), you will need "munpack" or
> >>    a MIME-compliant = mail reader.  Different MIME-compliant
> >>mail readers
> >>    exhibit different = behavior, especially when dealing with
> >>    = "multipart" MIME messages (i.e. documents which have been = split
> >>    up into multiple = messages), so check your local documentation on
> >>    how to manipulate = these messages.
> >>    =        
> >>    =        
> >>Below is the data which will enable a = MIME compliant mail reader
> >>implementation to automatically = retrieve the ASCII version of the
> >>Internet-Draft.
> >>
> >
>

------_=_NextPart_001_01C2FAEC.54121AF6-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Control words in the architecture draft Date: Sun, 6 Apr 2003 08:59:42 +0300 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Shahram Davari" , X-From: pwe3-admin@ietf.org Sun Apr 06 08:06:11 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Control words in the architecture draft Thread-Index: AcL6kY1+C/YOFtE4T+e8qO5Z3nHbPwBbda6Q To: , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3661g815058 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Matthew, > Eric, > > With regard to your point about the 1:1 and PDU modes in the > ATM draft, the length field is not used for either of these modes because > the length is always greater than the minimum transfer unit on an ethernet link. Why? >From section 6.6 (ATM VCC Cell Transport Service) for the 1:1 single cell VCC case we have a 48 byte payload, one byte "ATM specific", three more bytes for the "optional" SN and length (and I think the diagram in atm-encap is misleading, since the text states that the content is optional, but the field still remains with zeros) four bytes for the PW header four bytes for the MPLS transport header (if there is one) for a total of 60 bytes (but possibly only 56). So the length may be less than 64, and can even be less than 64 and nonunique. > Therefore, this field becomes reserved and is set to all zeros. That's an interpretation, but not clear in the text. > This means that there are 4 bits in exactly the same position as the > martini control word that could be used for PID. But that would completely undermine the mechanism presently used for determining whether the length is used. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE3 requirements Date: Sun, 6 Apr 2003 09:06:00 +0300 Lines: 20 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "Thomas D. Nadeau" , X-From: pwe3-admin@ietf.org Sun Apr 06 08:08:08 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 requirements Thread-Index: AcL6mNKq0bgGJv2TTbGN2PAzgJTtUgBaRE4g To: , "Mustapha Aissaoui" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3667x815967 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > At the moment we only have 3 payload types, IPv4, IPv6 and PW. > We cannot make the assumption that there will not be another > of interest to a core router at some time in the future. > I still really don't understand why "PW" is a type. As splendidly explained in the architecture draft, there are many different types of PWs. Some have real-time constraints, some don't. Some require sequencing, some don't. Etc. Why are these completely different PWs more alike than IPv4 and IPv6, which are equivalent services with equivalent requirements, differing only in the length of their headers? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: What is PWE3 chartered to do? Date: Sun, 6 Apr 2003 09:12:50 +0300 Lines: 15 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Sun Apr 06 08:16:06 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] What is PWE3 chartered to do? Thread-Index: AcL6mzEHecjqozGJShec/n0eYAM3cABZ87Gw To: "Peter Willis" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h366En816122 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Seems to me PWE3 has an expensive solution engineered in to > its charter! PWE was not defined to be purely MPLS, quite the opposite, it is supposed to be PSN-agnostic. Quite a few of us are still providing most of our PW services over IPv4. So putting the sequencing (when needed) into the PW layer, rather than relying on the PSN services, simplifies the design by removing complex interdependencies between the PW and the PSN. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: What is PWE3 chartered to do? Date: Sun, 6 Apr 2003 10:41:55 +0100 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-From: pwe3-admin@ietf.org Sun Apr 06 11:44:06 2003 Return-path: To: tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Thomas D. Nadeau wrote 04 April 2003 16:16 > Neil, > > In a utopian/white-board world that disregards the > reality of deployed kit, such a conclusion makes **perfect sense**. NH=> Good. Then you do at least admit LDP and PHP are 'mistakes', this is a required initial 1st step, ie acknowledge the true source of the problem. > So did similar reasoning to those in the past who reasoned that > Earth was flat because that argument too looked good at least > on paper. NH=> This is simply a Universal truth that was discovered......it is not a man-made creation like LDP. So I don't see the relevance of this statement. > However, the reality is that 100s of thousands of LSRs > are currently deployed in real networks and run LDP, so it is not a > realistic option to just say lets stop using LDP today or in > the future > because it is hard to manage. NH=> Agreed. We all make mistakes in our professional/private lives. The only thing I am asking for is to accept these, learn from them (stop doing kludge on kludge) and move on. Sure, we have to find ways to manage the stuff we now have, but I want to see a position where we recognise that this chapter needs closing at some point. To not learn from one's mistakes is not acceptable engineering practice IMO. > There are plenty of other technologies > that are difficult to manage and use that are still widely > deployed today > because they still get the job done most of the time. Perhaps you are > familiar with a technology called Windows? NH=> Not sure the point you are trying to make here. The only logical conclusion I can draw is that there is no need for bodies like IETF to exist because we simply let the dominant supplier to the industry-sector of relevance set the de facto stds that we all just accept. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Proposed changes to MPLS CW in arch draft Date: Sun, 6 Apr 2003 16:26:47 +0200 Lines: 426 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org, "'stbryant@cisco.com'" X-From: pwe3-admin@ietf.org Sun Apr 06 15:57:34 2003 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram and all, I follow the design presented in the Architecture draft (Section 5.4.2). IMO, this design complies with the recommendations of RFC 2736 as required by the PWE3 Charter. Note also that, if you use IP and UDP as your transport and demultiplexing, existing infrastructure can compress IP/UDP/RTP headers in a very effective way. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Friday, April 04, 2003 8:59 PM > To: Sasha Vainshtein; 'stbryant@cisco.com' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Proposed changes to MPLS CW in arch draft > > > Sasha, > > Why don't you put RTP header after the CW? > > -Shahram > > >-----Original Message----- > >From: Sasha Vainshtein [mailto:Sasha@axerra.com] > >Sent: Friday, April 04, 2003 2:38 PM > >To: 'stbryant@cisco.com' > >Cc: pwe3@ietf.org > >Subject: RE: [PWE3] Proposed changes to MPLS CW in arch draft > > > > > >Stewart (and all), > >Thank you for presenting the proposed text for review. > >This, by itself, is most commendable. > > > >I also have a (hopefully, minor) issue with the proposed text. > >Section 5.4.2 explicitly allows presence of an RTP header > >immediately after the PW demutiplexer and, indeed, the SONET > >and (most of) the TDM drafts by default place this header > >in the prescribed position. However, in this case the first > >word of the RTP header is placed exactly where, in all the > >rest of the cases, the PW control word would be. On the other > >hand, Section 5.4.4 opens with words: > > > > > > Where the PW control word may alias an IP packet... > > > > > >So, first of all, the consequent text does not seem to cover the > >case when the RTP header is present between the PW demultiplexer > >and the PW control word. > > > >Second, it is not clear whether an MPLS payload type identifier > >should be inserted between the MPLS PW demultiplexer and RTP header: > > > >a) This header cannot alias an IPv4 or IPv6 packet. > > In fact, its first nibble is always '1000' in all known proposals > > and we may probably enforce that by specifying that, when RTP > > is used in conjunction with PWs, neither RTP header extensions > > nor padding can be used. > >b) However, if we rely exclusively on the first nibble of the > >RTP header > > for not aliasing IP packets, we de-facto reserve one more > >4-bit value > > (8) for the use of PWs. So if we go for this approach, > this fact IMO > > should be mentioned in the "IANA Considerations" section of > >the draft. > > > >Personally I think that it would be quite safe to allow an > RTP header > >directly between the MPLS PW demultiplexer (aka VC label) and > >the PW CW, > >and I hope that the WG would accept that. > > > >With best regards, > > Sasha Vainshtein > >email: sasha@axerra.com > >tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > >> -----Original Message----- > >> From: Stewart Bryant [mailto:stbryant@cisco.com] > >> Sent: Thursday, April 03, 2003 3:00 PM > >> To: pwe3@ietf.org > >> Subject: [PWE3] Proposed changes to MPLS CW in arch draft > >> > >> > >> > >> > >> This is the text that I propose for sections 5.4.2, 5.4.3 and the > >> new 5.4.4 in draft-pwe3-arch-03.txt > >> > >> In section 5.4.2 the MPLS payload type identifier is shown in the > >> relation to the PW label and the CW. > >> > >> In section 5.4.3 the issue of IP packet aliasing is introduced, > >> and the generic and the SONET CWs are defined. It is noted that > >> the "Martini" style of CW does not have this aliasing issue. > >> > >> The new section 5.4.4 includes the MPLS payload type identifier for > >> reference and shows how IP packets can be multiplexed over the PW > >> for management purposes. > >> > >> Stewart > >> > >> > >> > >> 5.4.2. PWE3 over an MPLS PSN > >> > >> The MPLS ethos places importance on wire efficiency. > By using a > >> control word, some components of the PWE3 protocol > layers can be > >> compressed to increase this efficiency. > >> > >> > >> +---------------------+ > >> | Payload | > >> /=====================\ > >> H Payload Convergence H-----+ > >> H---------------------H | > >> H Timing H------------------------+ > >> H---------------------H | | > >> H Sequencing H-----| | > >> \=====================/ | | > >> | PW Demultiplexer |---+ | v > >> +---------------------+ | | > +--------------------------------+ > >> | PSN Convergence |-----| . > . > >> +---------------------+ | | . RTP > . > >> | PSN |-+ | | | > | > >> +---------------------+ | | | > +--------------------------------+ > >> | Data-link | | | +->| Flags, Frag, Len, Seq > #, etc | > >> +---------------------+ | | > +--------------------------------+ > >> | Physical | | | | MPLS Payl'd Type > Indent | > >> +---------------------+ | | > +--------------------------------+ > >> | +--->| PW Label > | > >> | > +--------------------------------+ > >> +----->| Outer Label or > MPLS-in-IP encap| > >> > +--------------------------------+ > >> > >> Figure 11: PWE3 over an MPLS PSN using a control word > >> > >> Figure 11 shows the protocol layering for PWE3 over an > >> MPLS PSN. An > >> inner MPLS label is used to provide the PW demultiplexing > >> function. > >> A control word is used to carry most of the information > >> needed by the > >> PWE3 Encapsulation Layer and the PSN Convergence Layer in > >> a compact > >> format. The flags in the control word provide the > >> necessary payload > >> convergence. A sequence field provides support for > both in-order > >> payload delivery and (supported by a fragmentation > >> control method) a > >> PSN fragmentation service within the PSN Convergence > >> Layer. Ethernet > >> pads all frames to a minimum size of 64 bytes. The MPLS > >> header does > >> not include a length indicator. Therefore to allow PWE3 > >> to be carried > >> in MPLS to correctly pass over an Ethernet data-link, a length > >> correction field is needed in the control word. Where the > >> design of > >> the control word would alias an IP packet, an MPLS Payload Type > >> Identifier should be interposed between the PW label and > >> the control > >> word (see 5.4.4). As with an IP PSN, where appropriate, > >timing is > >> provided by RTP [RFC1889]. > >> > >> In some networks it may be necessary to carry PWE3 over > >> MPLS over IP. > >> In these circumstances, the PW is encapsulated for > >> carriage over MPLS > >> as described in this section, and then a method of > >> carrying MPLS over > >> an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the > >> resultant PW-PDU. > >> > >> 5.4.3. PW over MPLS Generic Control Word > >> > >> To allow accurate packet inspection in an MPLS PSN, and > >to operate > >> correctly over MPLS PSNs that have deployed equal-cost > >> multiple-path > >> load-ballancing a PW packet MUST NOT alias an IP packet. > >> IP packets > >> are carried in MPLS label stacks without any protocol > identifier. > >> Historic values of the IP version number [RFC791] [RFC1881] are > >> therefore used to distinguish between IP and non-IP MPLS > >payloads. > >> > >> A PW SHOULD employ either the generic PW control word > or an MPLS > >> payload type identifier to disambiguate the PW from an IP flow. > >> > >> The PW set-up protocol determines whether a particular > PW uses a > >> control word. When a control word is used, it MUST have the > >> following form for non-SONET encapsulations: > >> > >> > >> 0 1 2 > >> 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > >> 6 7 8 9 0 1 > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |0 0 0 0| Flags |FRG| Length | Sequence Number > >> | > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Figure 12: MPLS Generic Control Word (non-SONET) > >> > >> Note that a with packet bits 0..3 = 4 indicates an IPv4 > >> MPLS payload > >> and a packet with bits 0..3 = 6 indicates an IPv6 MPLS > playload. > >> > >> The meaning of the fields of the MPLS Generic Control > Word (non- > >> SONET) (Figure 12) is as follows: > >> > >> Flags (bits 4 to 7): > >> These bits are available for per payload > >signaling. Their > >> definition is encapsulation specific. > >> > >> FRG (bits 8 and 9): > >> These bits are used when fragmenting a PW > >> payload. Their use > >> is defined in [FRAG]. When the PW is of a type > >> that will never > >> need payload fragmentation, these bits may be > >> used as general > >> purpose flags. > >> > >> Length (bits 10 to 15): > >> The length field is used to determine the size of a PW > >> payload that might have been padded to the > >> minimum Ethernet > >> MAC frame size during its transit across the > PSN. If the > >> MPLS payload (defined as the CW + the PW payload + any > >> additional PW headers is less than 46 bytes, the > >> length MUST > >> be set to the length of the MPLS payload. If the MPLS > >> payload is between 46 bytes and 63 bytes the > >> implementation > >> MAY either set to the length to the length of the MPLS > >> payload, or it MAY set it to 0. If the length > >of the MPLS > >> payload is greater than 63 bytes the length MUST > >> be set to 0. > >> > >> Sequence number (Bit 16 to 31): > >> If the sequence number is not used, it is set > to zero by > >> the sender and ignored by the receiver. Otherwise it > >> specifies the sequence number of a packet. A > >> circular list > >> of sequence numbers is used. A sequence number > >> takes a value > >> from 1 to 65535 (2**16-1). If the payload is an > >> OAM packet > >> the sequence number MAY be used to mark the > >> position in the > >> sequence, in which case it has the same value > as the last > >> data PDU sent. The use of the sequence number > >is optional > >> for OAM payloads. > >> > >> The PW control word used in SONET applications must use > >> the following > >> general forms. > >> > >> Non-extended: > >> 0 1 2 > >> 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > >> 6 7 8 9 0 1 > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |0| Flags | Structure Pointer[0:12] | Sequence > >> Number[0:13] | > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Extended: > >> 0 1 2 > >> 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > >> 6 7 8 9 0 1 > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |1| Flags | Structure Pointer[0:12] | Sequence > >> Number[0:13] | > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Additional encapsulation-specific header > >> fields | > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Figure 13: MPLS Generic Control Word (SONET) > >> > >> The meaning of the fields of the MPLS Generic Control > >Word (SONET) > >> (Figure 13) is as follows: > >> > >> Structure Pointer[0:12]: > >> If used, the Structure Pointer contains the > offset of the > >> first byte of the payload structure. > >> > >> Sequence Number[0:13]: This is a packet sequence > >> number, which > >> continuously cycles from 0 to 0x3FFF. It is > >generated and > >> processed in accordance with the rules > >> established in [RFC1889]. > >> When the RTP header is used, this sequence number > >> MUST match the > >> LSBs of the RTP sequence Number. > >> > >> 5.4.4. MPLS Payload Identifier > >> > >> Where the PW control word may alias an IP packet (for > example the > >> MPLS Generic Control Word (SONET)), the control word SHOULD be > >> preceeded by an MPLS payload type identifier. > >> > >> For reference the MPLS payload type identifier [TBD] is > >defined as > >> follows: > >> > >> 0 1 2 > >> 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > >> 5 6 7 8 9 0 1 > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |0 0 0 1| reserved | PPP DLL Protocol > >> Number | > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | As defined by PPP DLL protocol > >> definition | > >> | > >> | > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Figure 14: MPLS Payload Type Identifier > >> > >> PPP DLL Protocol Number [16:31]: > >> These numbers are assigned by IANA. > >> > >> Some PW management messages such as OAM and LSP ping may > >> require IP > >> packets to be multiplexed onto the PW. These are carried > >> over the PW > >> using the IP MPLS payload type indicator, show in Figure 15: > >> > >> 0 1 2 > >> 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > >> 5 6 7 8 9 0 1 > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |0 0 0 1| reserved | IPv4 = 0x21, or > >> IPv6 = 0x57 | > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | IP packet and management payload > >> | > >> | > >> | > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Figure 15: MPLS Payload Type Identifier > >> > >> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Proposed changes to MPLS CW in arch draft Date: Mon, 7 Apr 2003 10:01:05 +0300 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: 8bit Cc: , X-From: pwe3-admin@ietf.org Mon Apr 07 09:07:39 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Proposed changes to MPLS CW in arch draft Thread-Index: AcL8R20Xc5rI56wjSDWX2Nn1dMpYuQAixeGw To: "Alexander Vainshtein" , "Shahram Davari" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3773D815971 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > Sasha, > > > > Why don't you put RTP header after the CW? > > > > -Shahram > Shahram and all, > I follow the design presented in the Architecture > draft (Section 5.4.2). IMO, this design complies with > the recommendations of RFC 2736 as required by the PWE3 Charter. That is beggin the question. You assumption is that PW is an RTP payload type, and thus subject to 2736 recommendations. You could just as easily say that the main type is PW, and that RTP should fit "inside" the PW protocol. > Note also that, if you use IP and UDP as your transport and > demultiplexing, existing infrastructure can compress > IP/UDP/RTP headers in a very effective way. This header "compression" is not yet very widely deployed, and some parts are protected by IPR. Incidentally, as someone who has spent many years in image, audio, and speech compression, I find it ridiculous to call these methods "compression". In any case, no-one was asking about the overhead here, merely about the "first nibble" problem. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Proposed changes to MPLS CW in arch draft Date: Mon, 7 Apr 2003 10:54:50 +0200 Lines: 50 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org, stbryant@cisco.com, "Danny McPherson (E-mail)" X-From: pwe3-admin@ietf.org Mon Apr 07 10:01:34 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, Please see some comments inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Monday, April 07, 2003 9:01 AM > To: Sasha Vainshtein; Shahram Davari > Cc: pwe3@ietf.org; stbryant@cisco.com > Subject: RE: [PWE3] Proposed changes to MPLS CW in arch draft > > > > > > Sasha, > > > > > > Why don't you put RTP header after the CW? > > > > > > -Shahram > > > Shahram and all, > > I follow the design presented in the Architecture > > draft (Section 5.4.2). IMO, this design complies with > > the recommendations of RFC 2736 as required by the PWE3 Charter. > > That is beggin the question. > > You assumption is that PW is an RTP payload type, > and thus subject to 2736 recommendations. > This is not my personal assumption but, rather, an explicit requirement in the PWE3 WG Charter: PWE3 will use RTP where necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and payloads will follow RFC 2736. If you think that this statement should be out of the WG charter, please raise this issue explicitly with the WG Chairs and the ADs. ... snipped to the end ... From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Monique Morrow (mmorrow)" Subject: RE: What is PWE3 chartered to do? Date: Mon, 7 Apr 2003 10:08:07 +0200 Lines: 89 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Cc: "Tom Nadeau (tnadeau)" , X-From: pwe3-admin@ietf.org Mon Apr 07 10:14:41 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] What is PWE3 chartered to do? Thread-Index: AcL8IViPgaRRbwMSTe2544RZsjvCSgAt8GNw To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h378AR821791 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, Reading the thread thus far and having worked for a service provider myself in both network operations, engineering and service development and having spoken with service providers throughout the world one of the challenges we all have (service providers and vendors) is to balance pragmatism, architectural efficiency and business impact (for carrier customers and vendors). This thread clearly points out the difficulty is doing the above. Service providers (specifically the organizations who are developing and deploying services) are very sensitive to customer impact to whatever technology, architecture, mechanism that may be introduced in a production environment -- I believe we all understand this point and are attempting to articulate mechanisms that are evolutionary, that is with minimal disruption and yet may address service and operational requirements moving forward. Using terms such as "mistakes" is useless and really has no value in this discussion as numerous providers have developed services and business models based on this technology. However when one speaks about "deprecating LDP," I suggest an operational and business risk assessment (for production networks) on what this concretely means, what is operational impact to my customers? What do I need to do with existing services? What is service management impact? What mechanisms do I require to evolve new services? I would like to suggest that we approach the problem in balancing pragmatism, architectural efficiency and business impact. Best regards, Monique -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: 06 April 2003 11:42 To: Tom Nadeau (tnadeau); pwe3@ietf.org Subject: RE: [PWE3] What is PWE3 chartered to do? Thomas D. Nadeau wrote 04 April 2003 16:16 > Neil, > > In a utopian/white-board world that disregards the > reality of deployed kit, such a conclusion makes **perfect sense**. NH=> Good. Then you do at least admit LDP and PHP are 'mistakes', this is a required initial 1st step, ie acknowledge the true source of the problem. > So did similar reasoning to those in the past who reasoned that > Earth was flat because that argument too looked good at least > on paper. NH=> This is simply a Universal truth that was discovered......it is not a man-made creation like LDP. So I don't see the relevance of this statement. > However, the reality is that 100s of thousands of LSRs > are currently deployed in real networks and run LDP, so it is not a > realistic option to just say lets stop using LDP today or in > the future > because it is hard to manage. NH=> Agreed. We all make mistakes in our professional/private lives. The only thing I am asking for is to accept these, learn from them (stop doing kludge on kludge) and move on. Sure, we have to find ways to manage the stuff we now have, but I want to see a position where we recognise that this chapter needs closing at some point. To not learn from one's mistakes is not acceptable engineering practice IMO. > There are plenty of other technologies > that are difficult to manage and use that are still widely > deployed today > because they still get the job done most of the time. Perhaps you are > familiar with a technology called Windows? NH=> Not sure the point you are trying to make here. The only logical conclusion I can draw is that there is no need for bodies like IETF to exist because we simply let the dominant supplier to the industry-sector of relevance set the de facto stds that we all just accept. regards, Neil _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Proposed changes to MPLS CW in arch draft Date: Mon, 7 Apr 2003 11:25:12 +0300 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: 8bit Cc: , , "Danny McPherson (E-mail)" X-From: pwe3-admin@ietf.org Mon Apr 07 10:27:26 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Proposed changes to MPLS CW in arch draft Thread-Index: AcL822FDKDZXDAR5RXym3eps2UWv4QAAxJ7w To: "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h378RO822551 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > This is not my personal assumption but, rather, an explicit > requirement in the PWE3 WG Charter: > > > PWE3 will use RTP where necessary to perform clock recovery and > other real-time signaling functions. This work will be > coordinated with the AVT WG and payloads will follow RFC 2736. > > > If you think that this statement should be out of the WG > charter, please raise this issue explicitly with the WG > Chairs and the ADs. Although I don't really see the need for RTP (and as you know almost none of the encapsulation drafts use it), this was not my point here. Yes, go ahead and use RTP if you think it is needed for your payload. And yes, go ahead and encapsulate your PAYLOAD according to 2736 ideas (e.g. separately decodable, etc). But no-where does it say that the PW itself has to be encapsulated as an RTP payload. The difference between the PW and the payload is precisely the control word, and that is where the question lies. Using reductio ad absurdum on your argument, you might claim that the charter requires the MPLS labels to be inside the RTP payload too. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Proposed changes to MPLS CW in arch draft Date: Mon, 7 Apr 2003 11:41:54 +0200 Lines: 49 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org, stbryant@cisco.com, "Danny McPherson (E-mail)" X-From: pwe3-admin@ietf.org Mon Apr 07 10:52:16 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, Please see inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Monday, April 07, 2003 10:25 AM > To: Sasha Vainshtein > ... snipped ... > > And yes, go ahead and encapsulate your PAYLOAD > according to 2736 ideas (e.g. separately decodable, etc). > Please read 2736. It explains what is and what is not part of the RTP payload. It is only 10 pages long, and very well written. It is also an IETF Best Current Practice document. > ... snipped ... > > The difference between the PW and the payload > is precisely the control word, and that is where > the question lies. > What about PWs that do not use (or, rather, do not mandate) Control words? Do you claim that they are NOT PWs just by this fact? And, by the way, please try to use common terminology (as defined in the Architecture document). This would probably help to make your objections more coherent. > > Using reductio ad absurdum on your argument, > you might claim that the charter requires the > MPLS labels to be inside the RTP payload too. > I have expected something better from you. Please re-read the architecture document. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: PWE3 requirements Date: Mon, 07 Apr 2003 09:45:21 +0100 Organization: Cisco Systems, Inc. Lines: 57 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5281AC83@exrad2.ad.rad.co.il> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mustapha Aissaoui , "Thomas D. Nadeau" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 07 10:53:42 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Yaakov Stein Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov Stein wrote: >>At the moment we only have 3 payload types, IPv4, IPv6 and PW. >>We cannot make the assumption that there will not be another >>of interest to a core router at some time in the future. >> > > > I still really don't understand why "PW" is a type. > Well technically it is a class. > As splendidly explained in the architecture draft, > there are many different types of PWs. > Some have real-time constraints, some don't. > Some require sequencing, some don't. > Etc. > > Why are these completely different PWs more alike > than IPv4 and IPv6, which are equivalent services > with equivalent requirements, differing only in the length > of their headers? The issue is that we are stealing IP's very small historic version number space to discriminate IP from PW. If you want fine grained distinction the MPLS payload identifier can carry it. Perhaps the better way to look at it is: 0x0 Undisclosed MPLS payload 0x1 Identified by MPLS payload identifier 0x2 Reserved for allocation by IANA 0x3 Reserved for allocation by IANA 0x4 IPv4 0x5 ????? 0x6 IPv6 0x7..0xF Reserved for allocation by IANA Stewart > > > Y(J)S > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Matthew.Bocci@alcatel.co.uk Subject: RE: Control words in the architecture draft Date: Mon, 7 Apr 2003 13:44:43 +0100 Lines: 72 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: erosen@cisco.com, pwe3@ietf.org, "Shahram Davari" , stbryant@cisco.com X-From: pwe3-admin@ietf.org Mon Apr 07 14:53:50 2003 Return-path: To: "Yaakov Stein" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/07/2003 13:51:22 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yakov, Please see below for clarification. Best regards, Matthew "Yaakov Stein" To: Matthew BOCCI/GB/ALCATEL@ALCATEL, , "Shahram Davari" .com> , Subject: RE: [PWE3] Control words in the architecture draft 06/04/2003 06:59 Matthew, > Eric, > > With regard to your point about the 1:1 and PDU modes in the > ATM draft, the length field is not used for either of these modes because > the length is always greater than the minimum transfer unit on an ethernet link. Why? >From section 6.6 (ATM VCC Cell Transport Service) for the 1:1 single cell VCC case we have a 48 byte payload, one byte "ATM specific", three more bytes for the "optional" SN and length (and I think the diagram in atm-encap is misleading, since the text states that the content is optional, but the field still remains with zeros) four bytes for the PW header four bytes for the MPLS transport header (if there is one) for a total of 60 bytes (but possibly only 56). So the length may be less than 64, and can even be less than 64 and nonunique. MB> Yes, but in 1:1 single cell mode you know that there is only one cell, so you implicitly know how long the payload is. Therefore, the length field is redundant. > Therefore, this field becomes reserved and is set to all zeros. That's an interpretation, but not clear in the text. MB> I agree that this needs clarifying. > This means that there are 4 bits in exactly the same position as the > martini control word that could be used for PID. But that would completely undermine the mechanism presently used for determining whether the length is used. MB > The length is never used in 1:1 or PDU mode. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Peter Willis Subject: Re: What is PWE3 chartered to do? Date: Mon, 07 Apr 2003 14:34:01 +0100 Lines: 19 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5281AC84@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "Peter Willis" , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 07 15:36:34 2003 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: "Yaakov Stein" In-reply-to: Your message of "Sun, 06 Apr 2003 09:12:50 +0300." <27A0F290348F8E45AEF79889DDE65A5281AC84@exrad2.ad.rad.co.il> Content-Transfer-Encoding: 8bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > Seems to me PWE3 has an expensive solution engineered in to > > its charter! > > PWE was not defined to be purely MPLS, > quite the opposite, it is supposed to be PSN-agnostic. > > Quite a few of us are still providing most of our PW > services over IPv4. > > So putting the sequencing (when needed) into the PW layer, > rather than relying on the PSN services, > simplifies the design by removing complex interdependencies > between the PW and the PSN. Which is OK so long as the operators that have networks that deliver packets in order do not have to bear the costs associated with resequencing because some other operators have networks that can't deliver packets in order! Peter. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE3 requirements Date: Mon, 7 Apr 2003 16:51:50 +0300 Lines: 21 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "Mustapha Aissaoui" , "Thomas D. Nadeau" , X-From: pwe3-admin@ietf.org Mon Apr 07 15:54:58 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 requirements Thread-Index: AcL84jvHEt/rUEvAQXeOnt9EhxuNUwAKgUEg To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h37Ds7812072 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Perhaps the better way to look at it is: > > 0x0 Undisclosed MPLS payload > 0x1 Identified by MPLS payload identifier > 0x2 Reserved for allocation by IANA > 0x3 Reserved for allocation by IANA > 0x4 IPv4 > 0x5 ????? > 0x6 IPv6 > 0x7..0xF Reserved for allocation by IANA > Agreed. I suggest putting that specifically into the architecture draft. Then, later drafts can suggest how best to use the limited identifier space. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Proposed changes to MPLS CW in arch draft Date: Mon, 7 Apr 2003 07:09:27 -0700 Lines: 39 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: pwe3@ietf.org, "'stbryant@cisco.com'" X-From: pwe3-admin@ietf.org Mon Apr 07 16:12:19 2003 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, >Shahram and all, >I follow the design presented in the Architecture >draft (Section 5.4.2). IMO, this design complies with >the recommendations of RFC 2736 as required by the PWE3 Charter. I don't think so. The Arch draft section 5.4.2 shows the following figure: +---------------------+ | Payload | /=====================\ H Payload Convergence H-----+ H---------------------H | H Timing H------------------------+ H---------------------H | | H Sequencing H-----| | \=====================/ | | | PW Demultiplexer |---+ | v +---------------------+ | | +--------------------------------+ | PSN Convergence |-----| . . +---------------------+ | | . RTP . | PSN |-+ | | | | +---------------------+ | | | +--------------------------------+ | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | +---------------------+ | | +--------------------------------+ | Physical | | +--->| PW Label | +---------------------+ | +--------------------------------+ +----->| Outer Label or MPLS-in-IP encap| +--------------------------------+ In which RTP is after the control word. In other words the header is: Outer Label->PW label->Control word-> RTP -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ghassem Koleyni" Subject: RE: Control words in the architecture draft Date: Mon, 7 Apr 2003 10:26:24 -0400 Lines: 390 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FD11.AAA051E0" Cc: erosen@cisco.com, pwe3@ietf.org, Shahram Davari , stbryant@cisco.com X-From: pwe3-admin@ietf.org Mon Apr 07 16:29:52 2003 Return-path: To: "'Matthew.Bocci@alcatel.co.uk'" , Yaakov Stein X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FD11.AAA051E0 Content-Type: text/plain; charset="iso-8859-1" Yaakov, When discussing minimum length of 64 octets you should consider size of Ethernet header too. So, when a single cell (48 octets, plus any octets containing complete or partial PCI) is transported, the minimum length exceeds 64. Best regards, Ghassem Koleyni Nortel Networks Tel: (613) 763-4154 3500 Carling Ave. Fax: (613) 765-6295 Ottawa, Canada K1Y 4H7 Internet: ghassem@nortelnetworks.com http://www.nortelnetworks.com -----Original Message----- From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk] Sent: Monday, April 07, 2003 8:45 AM To: Yaakov Stein Cc: erosen@cisco.com; pwe3@ietf.org; Shahram Davari; stbryant@cisco.com Subject: RE: [PWE3] Control words in the architecture draft Yakov, Please see below for clarification. Best regards, Matthew "Yaakov Stein" To: Matthew BOCCI/GB/ALCATEL@ALCATEL, , "Shahram Davari" .com> , Subject: RE: [PWE3] Control words in the architecture draft 06/04/2003 06:59 Matthew, > Eric, > > With regard to your point about the 1:1 and PDU modes in the > ATM draft, the length field is not used for either of these modes because > the length is always greater than the minimum transfer unit on an ethernet link. Why? >From section 6.6 (ATM VCC Cell Transport Service) for the 1:1 single cell VCC case we have a 48 byte payload, one byte "ATM specific", three more bytes for the "optional" SN and length (and I think the diagram in atm-encap is misleading, since the text states that the content is optional, but the field still remains with zeros) four bytes for the PW header four bytes for the MPLS transport header (if there is one) for a total of 60 bytes (but possibly only 56). So the length may be less than 64, and can even be less than 64 and nonunique. MB> Yes, but in 1:1 single cell mode you know that there is only one cell, so you implicitly know how long the payload is. Therefore, the length field is redundant. > Therefore, this field becomes reserved and is set to all zeros. That's an interpretation, but not clear in the text. MB> I agree that this needs clarifying. > This means that there are 4 bits in exactly the same position as the > martini control word that could be used for PID. But that would completely undermine the mechanism presently used for determining whether the length is used. MB > The length is never used in 1:1 or PDU mode. Y(J)S _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C2FD11.AAA051E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Control words in the architecture draft

Yaakov,

When discussing minimum length of 64 octets you = should consider size of Ethernet header too. So, when a single cell (48 = octets, plus any octets containing complete or partial PCI) is = transported, the minimum length exceeds 64.

Best regards,

Ghassem = Koleyni           = ;            = ;      Nortel Networks
Tel: (613) = 763-4154          &nbs= p;           &nbs= p;    3500 Carling Ave.
Fax: (613) = 765-6295          &nbs= p;           &nbs= p;   Ottawa, Canada K1Y 4H7
Internet: = ghassem@nortelnetworks.com     http://www.nortelnetworks.com

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel= .co.uk]
Sent: Monday, April 07, 2003 8:45 AM
To: Yaakov Stein
Cc: erosen@cisco.com; pwe3@ietf.org; Shahram Davari; = stbryant@cisco.com
Subject: RE: [PWE3] Control words in the = architecture draft


Yakov,

Please see below for clarification.

Best regards,

Matthew



          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      
          &nb= sp;         = "Yaakov          =             =             =             =             =             =             =     
          &nb= sp;         = Stein"          &= nbsp;    To:     Matthew = BOCCI/GB/ALCATEL@ALCATEL, <erosen@cisco.com>   &nbs= p;        
          &nb= sp;         = <yaakov_s@rad        = cc:     <pwe3@ietf.org>, "Shahram = Davari"          =             =          
          &nb= sp;         = .com>          &nb= sp;     <Shahram_Davari@pmc-sierra.com>, = <stbryant@cisco.com>       &nbs= p;            =
          &nb= sp;           &nb= sp;           &nb= sp;      Subject:     RE: = [PWE3] Control words in the architecture = draft         
          &nb= sp;         = 06/04/2003          &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;
          &nb= sp;         = 06:59           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;    
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      




Matthew,

> Eric,
>
> With regard to your point about the 1:1 and PDU = modes in the
> ATM draft, the length field is not used for = either of these modes because

> the length is always greater than the minimum = transfer unit on an
ethernet link.

Why?

From section 6.6 (ATM VCC Cell Transport = Service)
for the 1:1 single cell VCC case we have
 a 48 byte payload,
 one byte "ATM specific",
 three more bytes for the "optional" = SN and length
  (and I think the diagram in atm-encap is = misleading,
   since the text states that the content = is optional,
   but the field still remains with = zeros)
 four bytes for the PW header
 four bytes for the MPLS transport header (if = there is one)
 for a total of 60 bytes (but possibly only = 56).

So the length may be less than 64,
and can even be less than 64 and nonunique.

MB> Yes, but in 1:1 single cell mode you know that = there is only one cell,
so you implicitly know how long the payload is. = Therefore, the length field
is redundant.

> Therefore,  this field becomes reserved and = is set to all zeros.

That's an interpretation, but not clear in the = text.

MB> I agree that this needs clarifying.

> This means that there are 4 bits in exactly the = same position as the
> martini control word that could be used for = PID.

But that would completely undermine the mechanism = presently used for
determining whether the length is used.

MB > The length is never used in 1:1 or PDU = mode.


Y(J)S





_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3=

------_=_NextPart_001_01C2FD11.AAA051E0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: What is PWE3 chartered to do? Date: Mon, 07 Apr 2003 10:42:55 -0400 Lines: 18 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "Yaakov Stein" , neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 07 16:45:50 2003 Return-path: To: Peter Willis In-reply-to: Your message of Mon, 07 Apr 2003 14:34:01 +0100. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter> Which is OK so long as the operators that have networks that deliver Peter> packets in order do not have to bear the costs associated with Peter> resequencing because some other operators have networks that can't Peter> deliver packets in order! All of the PSN technologies under consideration may misorder packets under normal operation. Implementations of all of the PSN technologies under consideration generally do strive to keep the packets of a microflow in order, as those packets pass through a single router. This suggests that at the PWE3 layer, the sequencing (for data packets, at least) operations can be (a) made optional, and (b) restricted to the discarding of out-of- sequence packets. Which is exactly the functionality we have built into PWE3. It seems to me that PWE3 has clear requirements in this area, and that it meets its those requirements in this area. The current thread does not seem to provide any relevant content here. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 requirements draft, version 5 Date: Sat, 05 Apr 2003 11:15:08 -0500 Organization: Alcatel Networks Corporaton Lines: 116 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Xipeng Xiao , pwe3@ietf.org, "Thomas D. Nadeau" X-From: pwe3-admin@ietf.org Mon Apr 07 17:19:14 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Akiva Sadovski Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Akiva, this is exactly the issue I raised after reading the latest update from Xipeng. I think Tom also agrees that we should allow both: - inbandand OAM messages, either as standalone messages or piggybacked to user packets. In both cases, the follow the user plane channel. - out-of-band OAM meesages, through the control plane. Mustapha. ------------ Akiva Sadovski wrote: > Mustapha, > (also cleaning my mailbox) > thank you for your clarifications, > > so the PE-generated maintenance "messages" may be sent to the remote PE: > -- via the control plane > -- via the data plane along with payload > -- as the PW's CW flags > > however, the draft-ietf-pwe3-requirements specifies only one way of > maintenance messages > sending - via the control plane. Why ? What's wrong with signalling local AC > states via > the CW flags ? > > thanks, > Akiva > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Wednesday, April 02, 2003 7:19 PM > > To: Akiva Sadovski > > Cc: Xipeng Xiao; pwe3@ietf.org; Thomas D. Nadeau > > Subject: Re: [PWE3] PWE3 requirements draft, version 5 > > > > > > Akiva, > > sorry for this late reply but I a catching up with my emails. > > See below. > > > > Mustapha. > > ----------- > > > > Akiva Sadovski wrote: > > > > > Mustapha, Xipeng and all, > > > > > > About: > > > > > > > > > Section 5.3: paragraph 8, last sentence says: "If a > > PE needs to > > > > > > generate and send a maintenance message to a remote PE, the > > > > > > maintenance message MUST be sent via the control plane, > > > > not via the > > > > > > PW" > > > > > > IMHO maintenance information may be passed from PE to PE > > not only in > > > separate messages > > > but also via CW bits (f.ex. N and P bits in > > draft-ietf-pwe3-sonet-01). > > > Should this kind of > > > communication be restricted or prohibited ? I doubt... > > > > > > Have i missed something ? > > > > If is is in the control word, then I would assume it is > > inband since the > > maintenance information is sent within the same channel as the user > > information. > > > > > > > > > > > > -----Original Message----- > > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > > Sent: Wednesday, March 19, 2003 8:26 PM > > > > To: Xipeng Xiao > > > > Cc: pwe3@ietf.org; Thomas D. Nadeau > > > > Subject: Re: [PWE3] PWE3 requirements draft, version 5 > > > > > > > > > > > > Xipeng, > > > > when OAM messages are sent inband, they travel within the PW. You > > > > are referring to out-of-band maintenance. We should allow both > > > > inband and out-of-band maintenance messages. > > > > > > > > Mustapha. > > > > ----------- > > > > Xipeng Xiao wrote: > > > > > > > > > > Mustapha, > > > > > > > > > > Thank you for your comments! One response below. > > > > > > > > > > > Section 5.3: paragraph 8, last sentence says: "If a > > PE needs to > > > > > > generate and send a maintenance message to a remote PE, the > > > > > > maintenance message MUST be sent via the control plane, > > > > not via the > > > > > > PW" > > > > > > Where does this requirement come from? This is too > > > > restrictive. We > > > > > > should allow the option to send a maintenance message > > > > over the PW. > > > > > > > > > > A maintenance message is a control plane thing. It has to > > > > stay inside the control plane. > > > > > > > > > > We will consider your other suggestions. > > > > _______________________________________________ > > > > pwe3 mailing list > > > > pwe3@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Akiva Sadovski Subject: RE: PWE3 requirements draft, version 5 Date: Mon, 7 Apr 2003 17:59:55 +0200 Lines: 105 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Xipeng Xiao , pwe3@ietf.org, "Thomas D. Nadeau" X-From: pwe3-admin@ietf.org Mon Apr 07 17:54:22 2003 Return-path: To: "'Mustapha Aissaoui'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha, (also cleaning my mailbox) thank you for your clarifications, so the PE-generated maintenance "messages" may be sent to the remote PE: -- via the control plane -- via the data plane along with payload -- as the PW's CW flags however, the draft-ietf-pwe3-requirements specifies only one way of maintenance messages sending - via the control plane. Why ? What's wrong with signalling local AC states via the CW flags ? thanks, Akiva > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, April 02, 2003 7:19 PM > To: Akiva Sadovski > Cc: Xipeng Xiao; pwe3@ietf.org; Thomas D. Nadeau > Subject: Re: [PWE3] PWE3 requirements draft, version 5 > > > Akiva, > sorry for this late reply but I a catching up with my emails. > See below. > > Mustapha. > ----------- > > Akiva Sadovski wrote: > > > Mustapha, Xipeng and all, > > > > About: > > > > > > > Section 5.3: paragraph 8, last sentence says: "If a > PE needs to > > > > > generate and send a maintenance message to a remote PE, the > > > > > maintenance message MUST be sent via the control plane, > > > not via the > > > > > PW" > > > > IMHO maintenance information may be passed from PE to PE > not only in > > separate messages > > but also via CW bits (f.ex. N and P bits in > draft-ietf-pwe3-sonet-01). > > Should this kind of > > communication be restricted or prohibited ? I doubt... > > > > Have i missed something ? > > If is is in the control word, then I would assume it is > inband since the > maintenance information is sent within the same channel as the user > information. > > > > > > > > -----Original Message----- > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > Sent: Wednesday, March 19, 2003 8:26 PM > > > To: Xipeng Xiao > > > Cc: pwe3@ietf.org; Thomas D. Nadeau > > > Subject: Re: [PWE3] PWE3 requirements draft, version 5 > > > > > > > > > Xipeng, > > > when OAM messages are sent inband, they travel within the PW. You > > > are referring to out-of-band maintenance. We should allow both > > > inband and out-of-band maintenance messages. > > > > > > Mustapha. > > > ----------- > > > Xipeng Xiao wrote: > > > > > > > > Mustapha, > > > > > > > > Thank you for your comments! One response below. > > > > > > > > > Section 5.3: paragraph 8, last sentence says: "If a > PE needs to > > > > > generate and send a maintenance message to a remote PE, the > > > > > maintenance message MUST be sent via the control plane, > > > not via the > > > > > PW" > > > > > Where does this requirement come from? This is too > > > restrictive. We > > > > > should allow the option to send a maintenance message > > > over the PW. > > > > > > > > A maintenance message is a control plane thing. It has to > > > stay inside the control plane. > > > > > > > > We will consider your other suggestions. > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Peter Willis Subject: Re: What is PWE3 chartered to do? Date: Mon, 07 Apr 2003 17:11:32 +0100 Lines: 106 Sender: pwe3-admin@ietf.org References: <012BF47C53CAE941A5BFA3C3B4058985021D1638@xbe-ams-313.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: neil.2.harrison@bt.com, "Tom Nadeau (tnadeau)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 07 18:27:32 2003 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: "Monique Morrow (mmorrow)" In-reply-to: Your message of "Mon, 07 Apr 2003 10:08:07 +0200." <012BF47C53CAE941A5BFA3C3B4058985021D1638@xbe-ams-313.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Monique, It is precisely all these issues we have considered and for us (i.e. a network operator with existing ATM, FR, SDH networks) we think that building PWE3 on a PSN that does not use MPLS LDP, but rather MPLS RSVP-TE (or similar), would be more efficient and have less impact on customers. Have any network operators currently deployed PWE3 over MPLS LDP? If so why didn't those operators just do PWE3 over IP? And what has using MPLS LDP bought them? Peter. > Neil, > > Reading the thread thus far and having worked for a service provider > myself in both network operations, engineering and service development > and having spoken with service providers throughout the world one of the > challenges we all have (service providers and vendors) is to balance > pragmatism, architectural efficiency and business impact (for carrier > customers and vendors). This thread clearly points out the difficulty > is doing the above. Service providers (specifically the organizations > who are developing and deploying services) are very sensitive to > customer impact to whatever technology, architecture, mechanism that may > be introduced in a production environment -- I believe we all understand > this point and are attempting to articulate mechanisms that are > evolutionary, that is with minimal disruption and yet may address > service and operational requirements moving forward. Using terms such > as "mistakes" is useless and really has no value in this discussion as > numerous providers have developed services and business models based on > this technology. However when one speaks about "deprecating LDP," I > suggest an operational and business risk assessment (for production > networks) on what this concretely means, what is operational impact to > my customers? What do I need to do with existing services? What is > service management impact? What mechanisms do I require to evolve new > services? > > I would like to suggest that we approach the problem in balancing > pragmatism, architectural efficiency and business impact. > > Best regards, > > Monique > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: 06 April 2003 11:42 > To: Tom Nadeau (tnadeau); pwe3@ietf.org > Subject: RE: [PWE3] What is PWE3 chartered to do? > > > Thomas D. Nadeau wrote 04 April 2003 16:16 > > > Neil, > > > > In a utopian/white-board world that disregards the > > reality of deployed kit, such a conclusion makes **perfect sense**. > NH=> Good. Then you do at least admit LDP and PHP are 'mistakes', this > is a > required initial 1st step, ie acknowledge the true source of the > problem. > > > So did similar reasoning to those in the past who reasoned that > > Earth was flat because that argument too looked good at least > > on paper. > NH=> This is simply a Universal truth that was discovered......it is not > a > man-made creation like LDP. So I don't see the relevance of this > statement. > > > However, the reality is that 100s of thousands of LSRs > > are currently deployed in real networks and run LDP, so it is not a > > realistic option to just say lets stop using LDP today or in > > the future > > because it is hard to manage. > NH=> Agreed. We all make mistakes in our professional/private lives. > The > only thing I am asking for is to accept these, learn from them (stop > doing > kludge on kludge) and move on. Sure, we have to find ways to manage the > stuff we now have, but I want to see a position where we recognise that > this > chapter needs closing at some point. To not learn from one's mistakes > is > not acceptable engineering practice IMO. > > > There are plenty of other technologies > > that are difficult to manage and use that are still widely > > deployed today > > because they still get the job done most of the time. Perhaps you are > > familiar with a technology called Windows? > NH=> Not sure the point you are trying to make here. The only logical > conclusion I can draw is that there is no need for bodies like IETF to > exist > because we simply let the dominant supplier to the industry-sector of > relevance set the de facto stds that we all just accept. > > regards, Neil > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 requirements draft, version 5 Date: Mon, 07 Apr 2003 12:56:42 -0400 Lines: 119 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Xipeng Xiao , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 07 18:59:27 2003 Return-path: X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Akiva Sadovski , "'Mustapha Aissaoui'" In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >Mustapha, > (also cleaning my mailbox) > thank you for your clarifications, > >so the PE-generated maintenance "messages" may be sent to the remote PE: >-- via the control plane >-- via the data plane along with payload >-- as the PW's CW flags > >however, the draft-ietf-pwe3-requirements specifies only one way of >maintenance messages >sending - via the control plane. Why ? What's wrong with signalling local AC >states via the CW flags ? Nothing. This suggestion was already made and I think there was consensus to make the change. --Tom >thanks, > Akiva > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Wednesday, April 02, 2003 7:19 PM > > To: Akiva Sadovski > > Cc: Xipeng Xiao; pwe3@ietf.org; Thomas D. Nadeau > > Subject: Re: [PWE3] PWE3 requirements draft, version 5 > > > > > > Akiva, > > sorry for this late reply but I a catching up with my emails. > > See below. > > > > Mustapha. > > ----------- > > > > Akiva Sadovski wrote: > > > > > Mustapha, Xipeng and all, > > > > > > About: > > > > > > > > > Section 5.3: paragraph 8, last sentence says: "If a > > PE needs to > > > > > > generate and send a maintenance message to a remote PE, the > > > > > > maintenance message MUST be sent via the control plane, > > > > not via the > > > > > > PW" > > > > > > IMHO maintenance information may be passed from PE to PE > > not only in > > > separate messages > > > but also via CW bits (f.ex. N and P bits in > > draft-ietf-pwe3-sonet-01). > > > Should this kind of > > > communication be restricted or prohibited ? I doubt... > > > > > > Have i missed something ? > > > > If is is in the control word, then I would assume it is > > inband since the > > maintenance information is sent within the same channel as the user > > information. > > > > > > > > > > > > -----Original Message----- > > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > > Sent: Wednesday, March 19, 2003 8:26 PM > > > > To: Xipeng Xiao > > > > Cc: pwe3@ietf.org; Thomas D. Nadeau > > > > Subject: Re: [PWE3] PWE3 requirements draft, version 5 > > > > > > > > > > > > Xipeng, > > > > when OAM messages are sent inband, they travel within the PW. You > > > > are referring to out-of-band maintenance. We should allow both > > > > inband and out-of-band maintenance messages. > > > > > > > > Mustapha. > > > > ----------- > > > > Xipeng Xiao wrote: > > > > > > > > > > Mustapha, > > > > > > > > > > Thank you for your comments! One response below. > > > > > > > > > > > Section 5.3: paragraph 8, last sentence says: "If a > > PE needs to > > > > > > generate and send a maintenance message to a remote PE, the > > > > > > maintenance message MUST be sent via the control plane, > > > > not via the > > > > > > PW" > > > > > > Where does this requirement come from? This is too > > > > restrictive. We > > > > > > should allow the option to send a maintenance message > > > > over the PW. > > > > > > > > > > A maintenance message is a control plane thing. It has to > > > > stay inside the control plane. > > > > > > > > > > We will consider your other suggestions. > > > > _______________________________________________ > > > > pwe3 mailing list > > > > pwe3@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: SONET/SDH header issues and proposed resolution (long) Date: Mon, 07 Apr 2003 16:45:59 -0400 Lines: 157 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andy Malis" X-From: pwe3-admin@ietf.org Mon Apr 07 22:48:42 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: pwe3@ietf.org X-OriginalArrivalTime: 07 Apr 2003 20:46:23.0069 (UTC) FILETIME=[C00200D0:01C2FD46] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O From following the PWE3 WG list, there is a clear consensus that PWs need to take ECMP into account be using the upper nibble as a PID. So there are a few issues that have to be discussed in order to amend the SONET/SDH draft to conform. To review, draft-ietf-pwe3-sonet-01.txt currently has the following packet structure: +-----------------------------------+ | PSN and Multiplexing Layer | | Headers | +-----------------------------------+ | RTP Header | | (RFC1889) | +-----------------------------------+ | CEP Header | +-----------------------------------+ | | | | | SONET/SDH | | Fragment | | | | | +-----------------------------------+ The first issue is the RTP header, which currently immediately follows the labels. Note that the RTP header can commonly be compressed out, but when it is used, its first nibble will always be '1000' (version = 2, P = 0, X = 0, as shown in figure 3 in draft-ietf-pwe3-sonet-01.txt). The placement of the RTP header prior to the CEP header isn't written in stone, and has been debated on the PWE3 list in the last few days. The second issue is the CEP header, which is either 32 or 64 bits, and has the following structure: Basic format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended Fractional STS-1 format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|0|0|0| Equipped Bit Mask (EBM) [0:27] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Neither of these formats conforms to the ECMP requirement. There are some alternatives that can be used to bring the above in compliance with the ECMP requirement. 1. Allocate the nibble '1000' to indicate RTP after the labels. As has already been noted, IP version 8 has already been assigned by IANA to "The P Internet Protocol". While this protocol was never widely implemented (was it ever implemented?), I cannot predict with any certainty how easy or hard it would be reassign this value. I can also imagine arguments outside of the PWE3 WG that RTP should always be preceded by IP and UDP, and should not immediately follow a link layer (treating MPLS as the link layer in this case). So this is probably a nonstarter. 2. Use an MPLS payload identifier. This would place George and Stewart's proposed MPLS payload identifier immediately after the labels and before the RTP header: +-----------------------------------+ | PSN and Multiplexing Layer | | Headers | +----+------------------------------+ |0001| protocol identifier | +----+------------------------------+ | RTP Header | | (RFC1889) | +-----------------------------------+ | CEP Header | +-----------------------------------+ | | | | | SONET/SDH | | Fragment | | | | | +-----------------------------------+ The primary problem with this solution is efficiency. The protocol identifier is actually 28 bits of redundant information, since signaling and/or provisioning have already been used to identify the PW contents. So we're really only using 4 bits to say "this is not IPv4 or IPv6", and the other 28 bits are unnecessary. To really illustrate the efficiently problem, recall that the CEP header is currently 4 or 8 octets in length. In the common case when RTP is unused, this would in effect always be adding 4 octets to the CEP header, increasing it to 8 or 12 octets, with the 12-octet header being used in the more BW-constrained situations, or where you're creating more PWs (SONET VTs). 3. Change the headers and the RTP location. In this proposal, we would change the packet structure to: +-----------------------------------+ | PSN and Multiplexing Layer | | Headers | +-----------------------------------+ | CEP Header | +-----------------------------------+ | RTP Header | | (RFC1889) | +-----------------------------------+ | | | | | SONET/SDH | | Fragment | | | | | +-----------------------------------+ and the CEP header would become a constant 8 octets in all cases: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| Equipped Bit Mask (EBM) [0:27] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When VTs are not in use, the first word will always be all zeros, and the header length is the same as in option 2. But when VTs are in use, the header length is 4 octets LESS than in option 2. This alternative does not require the allocation of any new PIDs, since we're going to be using 0000 anyway. And how do we know that this is a SONET header and not the usual other PWE3 header? The same as always - though PW signaling and/or provisioning. The only possible downside to this alternative is that it is less architecturally "pure" than alternative 2, since the RTP header follows the CEP header rather than precedes it. But that's OK with me! Personally, I prefer this alternative. I would be interested in hearing other opinions. Thanks for listening, Andy From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Control words in the architecture draft Date: Tue, 8 Apr 2003 08:55:31 +0300 Lines: 453 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FD93.77138806" Cc: , , "Shahram Davari" , X-From: pwe3-admin@ietf.org Tue Apr 08 07:59:30 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Control words in the architecture draft Thread-Index: AcL9EbkQp9Dz8Ir1SgqgsGCulpTCAwAgQIbg To: "Ghassem Koleyni" , Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FD93.77138806 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ghassem,=20 =20 I stand corrected. =20 Taking the 2 MACs, length, and FCS into account,=20 the minimum length is 46 bytes, conveniently below the 48 bytes of the ATM cell payload. =20 So there is never a need to use a length field=20 in any ATM-over-X-over-Ethernet packet. =20 Y(J)S =20 -----Original Message----- From: Ghassem Koleyni [mailto:ghassem@nortelnetworks.com] Sent: Monday, April 07, 2003 5:26 PM To: 'Matthew.Bocci@alcatel.co.uk'; Yaakov Stein Cc: erosen@cisco.com; pwe3@ietf.org; Shahram Davari; stbryant@cisco.com Subject: RE: [PWE3] Control words in the architecture draft Yaakov,=20 When discussing minimum length of 64 octets you should consider size of = Ethernet header too. So, when a single cell (48 octets, plus any octets = containing complete or partial PCI) is transported, the minimum length = exceeds 64. Best regards,=20 Ghassem Koleyni Nortel Networks=20 Tel: (613) 763-4154 3500 Carling Ave.=20 Fax: (613) 765-6295 Ottawa, Canada K1Y 4H7=20 Internet: ghassem@nortelnetworks.com http://www.nortelnetworks.com=20 -----Original Message-----=20 From: Matthew.Bocci@alcatel.co.uk [ mailto:Matthew.Bocci@alcatel.co.uk]=20 Sent: Monday, April 07, 2003 8:45 AM=20 To: Yaakov Stein=20 Cc: erosen@cisco.com; pwe3@ietf.org; Shahram Davari; stbryant@cisco.com=20 Subject: RE: [PWE3] Control words in the architecture draft=20 Yakov,=20 Please see below for clarification.=20 Best regards,=20 Matthew=20 = =20 "Yaakov = =20 Stein" To: Matthew = BOCCI/GB/ALCATEL@ALCATEL, =20 , = "Shahram Davari" =20 .com> = , = Subject: RE: [PWE3] Control = words in the architecture draft =20 06/04/2003 = =20 06:59 = =20 = =20 = =20 Matthew,=20 > Eric,=20 >=20 > With regard to your point about the 1:1 and PDU modes in the=20 > ATM draft, the length field is not used for either of these modes = because=20 > the length is always greater than the minimum transfer unit on an=20 ethernet link.=20 Why?=20 >From section 6.6 (ATM VCC Cell Transport Service)=20 for the 1:1 single cell VCC case we have=20 a 48 byte payload,=20 one byte "ATM specific",=20 three more bytes for the "optional" SN and length=20 (and I think the diagram in atm-encap is misleading,=20 since the text states that the content is optional,=20 but the field still remains with zeros)=20 four bytes for the PW header=20 four bytes for the MPLS transport header (if there is one)=20 for a total of 60 bytes (but possibly only 56).=20 So the length may be less than 64,=20 and can even be less than 64 and nonunique.=20 MB> Yes, but in 1:1 single cell mode you know that there is only one = cell,=20 so you implicitly know how long the payload is. Therefore, the length = field=20 is redundant.=20 > Therefore, this field becomes reserved and is set to all zeros.=20 That's an interpretation, but not clear in the text.=20 MB> I agree that this needs clarifying.=20 > This means that there are 4 bits in exactly the same position as the=20 > martini control word that could be used for PID.=20 But that would completely undermine the mechanism presently used for=20 determining whether the length is used.=20 MB > The length is never used in 1:1 or PDU mode.=20 Y(J)S=20 _______________________________________________=20 pwe3 mailing list=20 pwe3@ietf.org=20 https://www1.ietf.org/mailman/listinfo/pwe3=20 ------_=_NextPart_001_01C2FD93.77138806 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Control words in the architecture draft
Ghassem,
 
I=20 stand corrected.
 
Taking=20 the 2 MACs, length, and FCS into account,
the=20 minimum length is 46 bytes, conveniently below
the 48=20 bytes of the ATM cell payload.
 
So=20 there is never a need to use a length field=20
in any=20 ATM-over-X-over-Ethernet packet.
 
Y(J)S
 
-----Original Message-----
From: Ghassem Koleyni=20 [mailto:ghassem@nortelnetworks.com]
Sent: Monday, April 07, = 2003=20 5:26 PM
To: 'Matthew.Bocci@alcatel.co.uk'; Yaakov=20 Stein
Cc: erosen@cisco.com; pwe3@ietf.org; Shahram Davari;=20 stbryant@cisco.com
Subject: RE: [PWE3] Control words in the=20 architecture draft

Yaakov,

When discussing minimum length of 64 octets you = should=20 consider size of Ethernet header too. So, when a single cell (48 = octets, plus=20 any octets containing complete or partial PCI) is transported, the = minimum=20 length exceeds 64.

Best regards,

Ghassem=20 = Koleyni           =             &= nbsp;    =20 Nortel Networks
Tel: (613)=20 = 763-4154           = ;            =    =20 3500 Carling Ave.
Fax: (613)=20 = 765-6295           = ;            =   =20 Ottawa, Canada K1Y 4H7
Internet:=20 ghassem@nortelnetworks.com     http://www.nortelnetworks.com =

-----Original Message-----
From:=20 Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.= co.uk]=20
Sent: Monday, April 07, 2003 8:45 AM =
To: Yaakov Stein
Cc: = erosen@cisco.com;=20 pwe3@ietf.org; Shahram Davari; stbryant@cisco.com
Subject: RE: [PWE3] Control words in the architecture = draft=20


Yakov,

Please see below for clarification.

Best regards,

Matthew



          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      =20
          &nbs= p;        =20 = "Yaakov           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =   =20
          &nbs= p;        =20 = Stein"           &= nbsp;  =20 To:     Matthew BOCCI/GB/ALCATEL@ALCATEL,=20 = <erosen@cisco.com>        &= nbsp;   =20
          &nbs= p;        =20 <yaakov_s@rad       =20 cc:     <pwe3@ietf.org>, "Shahram=20 = Davari"           =             &= nbsp;       =20
          &nbs= p;        =20 = .com>           = ;    =20 <Shahram_Davari@pmc-sierra.com>,=20 = <stbryant@cisco.com>        = ;           =20
          &nbs= p;            = ;            =      =20 Subject:     RE: [PWE3] Control words in the = architecture=20 draft          =
          &nbs= p;        =20 = 06/04/2003          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           =20
          &nbs= p;        =20 = 06:59           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   =20
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      =20
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      =20




Matthew,

> Eric,
> =
> With regard to your point about the 1:1 and PDU modes in = the
> ATM draft, the length field is not = used for=20 either of these modes because

> the length is always greater than the minimum = transfer=20 unit on an
ethernet link.

Why?

From section 6.6 (ATM VCC Cell Transport = Service)=20
for the 1:1 single cell VCC case we have =
 a 48 byte payload,
 one = byte "ATM=20 specific",
 three more bytes for the = "optional"=20 SN and length
  (and I think the = diagram in=20 atm-encap is misleading,
   since = the text=20 states that the content is optional,
   but=20 the field still remains with zeros)
 four bytes=20 for the PW header
 four bytes for the = MPLS=20 transport header (if there is one)
 for = a total=20 of 60 bytes (but possibly only 56).

So the length may be less than 64,
and=20 can even be less than 64 and nonunique.

MB> Yes, but in 1:1 single cell mode you know = that there is=20 only one cell,
so you implicitly know how = long the=20 payload is. Therefore, the length field
is=20 redundant.

> Therefore,  this field becomes reserved = and is set=20 to all zeros.

That's an interpretation, but not clear in the = text.=20

MB> I agree that this needs clarifying. =

> This means that there are 4 bits in exactly the = same=20 position as the
> martini control word = that could=20 be used for PID.

But that would completely undermine the mechanism = presently=20 used for
determining whether the length is=20 used.

MB > The length is never used in 1:1 or PDU = mode.=20


Y(J)S





_______________________________________________=20
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.or= g/mailman/listinfo/pwe3=20

------_=_NextPart_001_01C2FD93.77138806-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: SONET/SDH header issues and proposed resolution (long) Date: Tue, 8 Apr 2003 13:02:59 +0200 Lines: 251 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 08 12:32:50 2003 Return-path: To: "'Andrew G. Malis'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy and all, I think you have given a very good analysis of the existing options. And I agree with you that using value '1000' (= 8) in the first nibble of the RTP header (my original preference) is a non-starter. However, I disagree with your preference and think that Option 2 (an explicit MPLS PID word preceding the RTP header followed by the CW) is preferable to Option 3 (placing the potentially unused EBM before the CW); below I'll try to explain why. 1. As you have noticed, this option is "architecturally pure". IMO, this minimizes the risk of potential future problems 2. Please consider the case when the transport network is IP, and not MPLS. (The demultiplexing method is not important - it may be L2TPv3, MPLS-in-IP, MPLS-in-GRE or something else). In this case: a) There is no need at all in the MPLS PID b) There is a definite added value in using the same encapsulations for IP and MPLS transports c) There is a definite added value in preserving the traditional position of the RTP header relative to IP transport 3. IMO, Option 3 (your preference) does not provide a solution for the case of Fractional VC4 (see Section 8.2.3.2 and Figure 16 in draft-ieft-pwe3-sonet-01.txt). I also think that estimates of BW effectiveness of Option 3 vs. Option 2 must take into account that, BW-wise, Fractional STS-1 and Fractional VC4 methods only make sense when you carry a substantial number of (concatenated) VTs between the given pair of endpoints. This is due to the fact that, with an individual VT, you MAY limit yourself to one packet every 500 uS, while with fractional STS-1 or Fractional VC-4 you MUST generate at least one packet every 125 uS and, in addition to that, must one additional byte (the TU pointer) per VT per 125 uS. So adding the MPLS PID will simply change the break-even condition. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Monday, April 07, 2003 10:46 PM > To: pwe3@ietf.org > Cc: Andy Malis > Subject: [PWE3] SONET/SDH header issues and proposed resolution (long) > > > From following the PWE3 WG list, there is a clear consensus > that PWs need > to take ECMP into account be using the upper nibble as a PID. > So there are > a few issues that have to be discussed in order to amend the > SONET/SDH > draft to conform. > > To review, draft-ietf-pwe3-sonet-01.txt currently has the > following packet > structure: > > +-----------------------------------+ > | PSN and Multiplexing Layer | > | Headers | > +-----------------------------------+ > | RTP Header | > | (RFC1889) | > +-----------------------------------+ > | CEP Header | > +-----------------------------------+ > | | > | | > | SONET/SDH | > | Fragment | > | | > | | > +-----------------------------------+ > > The first issue is the RTP header, which currently > immediately follows the > labels. Note that the RTP header can commonly be compressed > out, but when > it is used, its first nibble will always be '1000' (version = > 2, P = 0, X = > 0, as shown in figure 3 in draft-ietf-pwe3-sonet-01.txt). > > The placement of the RTP header prior to the CEP header isn't > written in > stone, and has been debated on the PWE3 list in the last few days. > > The second issue is the CEP header, which is either 32 or 64 > bits, and has > the following structure: > > Basic format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Extended Fractional STS-1 format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |E|0|0|0| Equipped Bit Mask (EBM) [0:27] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Neither of these formats conforms to the ECMP requirement. > > There are some alternatives that can be used to bring the above in > compliance with the ECMP requirement. > > > 1. Allocate the nibble '1000' to indicate RTP after the labels. > > As has already been noted, IP version 8 has already been > assigned by IANA > to "The P Internet Protocol". While this protocol was never widely > implemented (was it ever implemented?), I cannot predict with > any certainty > how easy or hard it would be reassign this value. I can also imagine > arguments outside of the PWE3 WG that RTP should always be > preceded by IP > and UDP, and should not immediately follow a link layer > (treating MPLS as > the link layer in this case). So this is probably a nonstarter. > > > 2. Use an MPLS payload identifier. > > This would place George and Stewart's proposed MPLS payload > identifier > immediately after the labels and before the RTP header: > > +-----------------------------------+ > | PSN and Multiplexing Layer | > | Headers | > +----+------------------------------+ > |0001| protocol identifier | > +----+------------------------------+ > | RTP Header | > | (RFC1889) | > +-----------------------------------+ > | CEP Header | > +-----------------------------------+ > | | > | | > | SONET/SDH | > | Fragment | > | | > | | > +-----------------------------------+ > > The primary problem with this solution is efficiency. The protocol > identifier is actually 28 bits of redundant information, > since signaling > and/or provisioning have already been used to identify the PW > contents. So > we're really only using 4 bits to say "this is not IPv4 or > IPv6", and the > other 28 bits are unnecessary. > > To really illustrate the efficiently problem, recall that the > CEP header is > currently 4 or 8 octets in length. In the common case when > RTP is unused, > this would in effect always be adding 4 octets to the CEP header, > increasing it to 8 or 12 octets, with the 12-octet header > being used in the > more BW-constrained situations, or where you're creating more > PWs (SONET VTs). > > > 3. Change the headers and the RTP location. > > In this proposal, we would change the packet structure to: > > +-----------------------------------+ > | PSN and Multiplexing Layer | > | Headers | > +-----------------------------------+ > | CEP Header | > +-----------------------------------+ > | RTP Header | > | (RFC1889) | > +-----------------------------------+ > | | > | | > | SONET/SDH | > | Fragment | > | | > | | > +-----------------------------------+ > > and the CEP header would become a constant 8 octets in all cases: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0|0|0| Equipped Bit Mask (EBM) [0:27] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > When VTs are not in use, the first word will always be all > zeros, and the > header length is the same as in option 2. But when VTs are > in use, the > header length is 4 octets LESS than in option 2. > > This alternative does not require the allocation of any new > PIDs, since > we're going to be using 0000 anyway. And how do we know that > this is a > SONET header and not the usual other PWE3 header? The same > as always - > though PW signaling and/or provisioning. > > The only possible downside to this alternative is that it is less > architecturally "pure" than alternative 2, since the RTP > header follows the > CEP header rather than precedes it. But that's OK with me! > > Personally, I prefer this alternative. I would be interested > in hearing > other opinions. > > Thanks for listening, > Andy > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: RE: SONET/SDH header issues and proposed resolution (long) Date: Tue, 08 Apr 2003 06:33:41 -0400 Lines: 294 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Andrew G. Malis'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 08 12:35:14 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Sasha Vainshtein In-Reply-To: X-OriginalArrivalTime: 08 Apr 2003 10:33:56.0132 (UTC) FILETIME=[5B8A2640:01C2FDBA] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, Thanks for your reply. Comments inline .... At 4/8/2003 01:02 PM +0200, Sasha Vainshtein wrote: >Andy and all, > >I think you have given a very good analysis of the existing >options. And I agree with you that using value '1000' (= 8) >in the first nibble of the RTP header (my original >preference) is a non-starter. > >However, I disagree with your preference and think that >Option 2 (an explicit MPLS PID word preceding the RTP header >followed by the CW) is preferable to Option 3 (placing the >potentially unused EBM before the CW); below I'll try to >explain why. > >1. As you have noticed, this option is "architecturally pure". > IMO, this minimizes the risk of potential future problems With all due respect, "potential future problems" is vague at best and FUD at worst. If there's an actual problem to address, that's something else entirely. >2. Please consider the case when the transport network is IP, and not > MPLS. (The demultiplexing method is not important - it may be > L2TPv3, MPLS-in-IP, MPLS-in-GRE or something else). In this case: > a) There is no need at all in the MPLS PID > b) There is a definite added value in using the same encapsulations > for IP and MPLS transports > c) There is a definite added value in preserving the traditional > position of the RTP header relative to IP transport Note that section 4.5 in the SONET draft (L2TP) is for future study, and for good reason. There has been zero interest in running SONET/SDH over anything but MPLS. Certainly those of us that are implementing this (at least those of which I am aware) are only doing MPLS implementations. I would rather optimize for the common case. >3. IMO, Option 3 (your preference) does not provide a solution > for the case of Fractional VC4 (see Section 8.2.3.2 and > Figure 16 in draft-ieft-pwe3-sonet-01.txt). It does handle it - that's the use of the "E" bit in the header - bit 0 in the second word. But you're right in that we'll be unable to use the first word for this one case. So in this case, the header will be: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Equipped Bit Mask #1 (EBM) [0:29] TUG-3#1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Equipped Bit Mask #2 (EBM) [0:29] TUG-3#2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|0| Equipped Bit Mask #3 (EBM) [0:29] TUG-3#3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >I also think that estimates of BW effectiveness of >Option 3 vs. Option 2 must take into account that, BW-wise, >Fractional STS-1 and Fractional VC4 methods only make sense >when you carry a substantial number of (concatenated) VTs >between the given pair of endpoints. This is due to the >fact that, with an individual VT, you MAY limit yourself >to one packet every 500 uS, while with fractional STS-1 or >Fractional VC-4 you MUST generate at least one packet every >125 uS and, in addition to that, must one additional byte >(the TU pointer) per VT per 125 uS. So adding the MPLS PID >will simply change the break-even condition. Actually, I think that helps make the case that you want to be as BW-efficient as possible in general. We make out better in almost all cases with my proposal except for VC4, and in VC4 we break even with the MPLS protocol identifier proposal. Cheers, Andy --------- >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > > Sent: Monday, April 07, 2003 10:46 PM > > To: pwe3@ietf.org > > Cc: Andy Malis > > Subject: [PWE3] SONET/SDH header issues and proposed resolution (long) > > > > > > From following the PWE3 WG list, there is a clear consensus > > that PWs need > > to take ECMP into account be using the upper nibble as a PID. > > So there are > > a few issues that have to be discussed in order to amend the > > SONET/SDH > > draft to conform. > > > > To review, draft-ietf-pwe3-sonet-01.txt currently has the > > following packet > > structure: > > > > +-----------------------------------+ > > | PSN and Multiplexing Layer | > > | Headers | > > +-----------------------------------+ > > | RTP Header | > > | (RFC1889) | > > +-----------------------------------+ > > | CEP Header | > > +-----------------------------------+ > > | | > > | | > > | SONET/SDH | > > | Fragment | > > | | > > | | > > +-----------------------------------+ > > > > The first issue is the RTP header, which currently > > immediately follows the > > labels. Note that the RTP header can commonly be compressed > > out, but when > > it is used, its first nibble will always be '1000' (version = > > 2, P = 0, X = > > 0, as shown in figure 3 in draft-ietf-pwe3-sonet-01.txt). > > > > The placement of the RTP header prior to the CEP header isn't > > written in > > stone, and has been debated on the PWE3 list in the last few days. > > > > The second issue is the CEP header, which is either 32 or 64 > > bits, and has > > the following structure: > > > > Basic format: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Extended Fractional STS-1 format: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |E|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Neither of these formats conforms to the ECMP requirement. > > > > There are some alternatives that can be used to bring the above in > > compliance with the ECMP requirement. > > > > > > 1. Allocate the nibble '1000' to indicate RTP after the labels. > > > > As has already been noted, IP version 8 has already been > > assigned by IANA > > to "The P Internet Protocol". While this protocol was never widely > > implemented (was it ever implemented?), I cannot predict with > > any certainty > > how easy or hard it would be reassign this value. I can also imagine > > arguments outside of the PWE3 WG that RTP should always be > > preceded by IP > > and UDP, and should not immediately follow a link layer > > (treating MPLS as > > the link layer in this case). So this is probably a nonstarter. > > > > > > 2. Use an MPLS payload identifier. > > > > This would place George and Stewart's proposed MPLS payload > > identifier > > immediately after the labels and before the RTP header: > > > > +-----------------------------------+ > > | PSN and Multiplexing Layer | > > | Headers | > > +----+------------------------------+ > > |0001| protocol identifier | > > +----+------------------------------+ > > | RTP Header | > > | (RFC1889) | > > +-----------------------------------+ > > | CEP Header | > > +-----------------------------------+ > > | | > > | | > > | SONET/SDH | > > | Fragment | > > | | > > | | > > +-----------------------------------+ > > > > The primary problem with this solution is efficiency. The protocol > > identifier is actually 28 bits of redundant information, > > since signaling > > and/or provisioning have already been used to identify the PW > > contents. So > > we're really only using 4 bits to say "this is not IPv4 or > > IPv6", and the > > other 28 bits are unnecessary. > > > > To really illustrate the efficiently problem, recall that the > > CEP header is > > currently 4 or 8 octets in length. In the common case when > > RTP is unused, > > this would in effect always be adding 4 octets to the CEP header, > > increasing it to 8 or 12 octets, with the 12-octet header > > being used in the > > more BW-constrained situations, or where you're creating more > > PWs (SONET VTs). > > > > > > 3. Change the headers and the RTP location. > > > > In this proposal, we would change the packet structure to: > > > > +-----------------------------------+ > > | PSN and Multiplexing Layer | > > | Headers | > > +-----------------------------------+ > > | CEP Header | > > +-----------------------------------+ > > | RTP Header | > > | (RFC1889) | > > +-----------------------------------+ > > | | > > | | > > | SONET/SDH | > > | Fragment | > > | | > > | | > > +-----------------------------------+ > > > > and the CEP header would become a constant 8 octets in all cases: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > When VTs are not in use, the first word will always be all > > zeros, and the > > header length is the same as in option 2. But when VTs are > > in use, the > > header length is 4 octets LESS than in option 2. > > > > This alternative does not require the allocation of any new > > PIDs, since > > we're going to be using 0000 anyway. And how do we know that > > this is a > > SONET header and not the usual other PWE3 header? The same > > as always - > > though PW signaling and/or provisioning. > > > > The only possible downside to this alternative is that it is less > > architecturally "pure" than alternative 2, since the RTP > > header follows the > > CEP header rather than precedes it. But that's OK with me! > > > > Personally, I prefer this alternative. I would be interested > > in hearing > > other opinions. > > > > Thanks for listening, > > Andy > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Tue, 08 Apr 2003 11:45:15 +0100 Organization: Cisco Systems, Inc. Lines: 193 Sender: pwe3-admin@ietf.org References: <5.2.1.1.0.20030407155713.02eed1e0@po1.vivacenetworks.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 08 12:48:54 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "Andrew G. Malis" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Good summary Andy Given that we have surfaced the issue of MPLS payload type discrimination we should probably run the issue to its natural conclusion. However Option (3) has the right ECMP properties, the byte efficiency properties you are looking for and is consistent with the other CW's at the necessary level. If this becomes the chosen option I suggest modifying the PW arch draft to say : Preferably use the "Martini" encapsulation. If there are technical reasons, i.e. the requirements of the PW, or the need for compatibility with other standards then keep the first nibble == 0 for ECMP reasons. If even this is not possible, or there is a need multiplex something else over the mux label, then use the MPLS PID. Do I have consensus? Stewart Andrew G. Malis wrote: > From following the PWE3 WG list, there is a clear consensus that PWs > need to take ECMP into account be using the upper nibble as a PID. So > there are a few issues that have to be discussed in order to amend the > SONET/SDH draft to conform. > > To review, draft-ietf-pwe3-sonet-01.txt currently has the following > packet structure: > > +-----------------------------------+ > | PSN and Multiplexing Layer | > | Headers | > +-----------------------------------+ > | RTP Header | > | (RFC1889) | > +-----------------------------------+ > | CEP Header | > +-----------------------------------+ > | | > | | > | SONET/SDH | > | Fragment | > | | > | | > +-----------------------------------+ > > The first issue is the RTP header, which currently immediately follows > the labels. Note that the RTP header can commonly be compressed out, > but when it is used, its first nibble will always be '1000' (version = > 2, P = 0, X = 0, as shown in figure 3 in draft-ietf-pwe3-sonet-01.txt). > > The placement of the RTP header prior to the CEP header isn't written in > stone, and has been debated on the PWE3 list in the last few days. > > The second issue is the CEP header, which is either 32 or 64 bits, and > has the following structure: > > Basic format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Extended Fractional STS-1 format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |E|0|0|0| Equipped Bit Mask (EBM) [0:27] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Neither of these formats conforms to the ECMP requirement. > > There are some alternatives that can be used to bring the above in > compliance with the ECMP requirement. > > > 1. Allocate the nibble '1000' to indicate RTP after the labels. > > As has already been noted, IP version 8 has already been assigned by > IANA to "The P Internet Protocol". While this protocol was never widely > implemented (was it ever implemented?), I cannot predict with any > certainty how easy or hard it would be reassign this value. I can also > imagine arguments outside of the PWE3 WG that RTP should always be > preceded by IP and UDP, and should not immediately follow a link layer > (treating MPLS as the link layer in this case). So this is probably a > nonstarter. > > > 2. Use an MPLS payload identifier. > > This would place George and Stewart's proposed MPLS payload identifier > immediately after the labels and before the RTP header: > > +-----------------------------------+ > | PSN and Multiplexing Layer | > | Headers | > +----+------------------------------+ > |0001| protocol identifier | > +----+------------------------------+ > | RTP Header | > | (RFC1889) | > +-----------------------------------+ > | CEP Header | > +-----------------------------------+ > | | > | | > | SONET/SDH | > | Fragment | > | | > | | > +-----------------------------------+ > > The primary problem with this solution is efficiency. The protocol > identifier is actually 28 bits of redundant information, since signaling > and/or provisioning have already been used to identify the PW contents. > So we're really only using 4 bits to say "this is not IPv4 or IPv6", and > the other 28 bits are unnecessary. > > To really illustrate the efficiently problem, recall that the CEP header > is currently 4 or 8 octets in length. In the common case when RTP is > unused, this would in effect always be adding 4 octets to the CEP > header, increasing it to 8 or 12 octets, with the 12-octet header being > used in the more BW-constrained situations, or where you're creating > more PWs (SONET VTs). > > > 3. Change the headers and the RTP location. > > In this proposal, we would change the packet structure to: > > +-----------------------------------+ > | PSN and Multiplexing Layer | > | Headers | > +-----------------------------------+ > | CEP Header | > +-----------------------------------+ > | RTP Header | > | (RFC1889) | > +-----------------------------------+ > | | > | | > | SONET/SDH | > | Fragment | > | | > | | > +-----------------------------------+ > > and the CEP header would become a constant 8 octets in all cases: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0|0|0| Equipped Bit Mask (EBM) [0:27] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > When VTs are not in use, the first word will always be all zeros, and > the header length is the same as in option 2. But when VTs are in use, > the header length is 4 octets LESS than in option 2. > > This alternative does not require the allocation of any new PIDs, since > we're going to be using 0000 anyway. And how do we know that this is a > SONET header and not the usual other PWE3 header? The same as always - > though PW signaling and/or provisioning. > > The only possible downside to this alternative is that it is less > architecturally "pure" than alternative 2, since the RTP header follows > the CEP header rather than precedes it. But that's OK with me! > > Personally, I prefer this alternative. I would be interested in hearing > other opinions. > > Thanks for listening, > Andy > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Tue, 08 Apr 2003 07:25:44 -0400 Lines: 175 Sender: pwe3-admin@ietf.org References: <5.2.1.1.0.20030407155713.02eed1e0@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 08 13:31:24 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: stbryant@cisco.com In-Reply-To: <3E92A83B.9050708@cisco.com> X-OriginalArrivalTime: 08 Apr 2003 11:25:49.0719 (UTC) FILETIME=[9B61D270:01C2FDC1] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, You have consensus from me. :-) Cheers, Andy ------- At 4/8/2003 11:45 AM +0100, Stewart Bryant wrote: >Good summary Andy > >Given that we have surfaced the issue of MPLS payload type >discrimination we should probably run the issue to its natural >conclusion. > >However Option (3) has the right ECMP properties, the >byte efficiency properties you are looking for and is >consistent with the other CW's at the necessary level. > >If this becomes the chosen option I suggest modifying the >PW arch draft to say : > >Preferably use the "Martini" encapsulation. > >If there are technical reasons, i.e. the requirements of the >PW, or the need for compatibility with other standards >then keep the first nibble == 0 for ECMP reasons. > >If even this is not possible, or there is a need multiplex something >else over the mux label, then use the MPLS PID. > >Do I have consensus? > >Stewart > >Andrew G. Malis wrote: >> From following the PWE3 WG list, there is a clear consensus that PWs >> need to take ECMP into account be using the upper nibble as a PID. So >> there are a few issues that have to be discussed in order to amend the >> SONET/SDH draft to conform. >>To review, draft-ietf-pwe3-sonet-01.txt currently has the following >>packet structure: >>+-----------------------------------+ >>| PSN and Multiplexing Layer | >>| Headers | >>+-----------------------------------+ >>| RTP Header | >>| (RFC1889) | >>+-----------------------------------+ >>| CEP Header | >>+-----------------------------------+ >>| | >>| | >>| SONET/SDH | >>| Fragment | >>| | >>| | >>+-----------------------------------+ >>The first issue is the RTP header, which currently immediately follows >>the labels. Note that the RTP header can commonly be compressed out, but >>when it is used, its first nibble will always be '1000' (version = 2, P = >>0, X = 0, as shown in figure 3 in draft-ietf-pwe3-sonet-01.txt). >>The placement of the RTP header prior to the CEP header isn't written in >>stone, and has been debated on the PWE3 list in the last few days. >>The second issue is the CEP header, which is either 32 or 64 bits, and >>has the following structure: >>Basic format: >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>|0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>Extended Fractional STS-1 format: >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>|1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>|E|0|0|0| Equipped Bit Mask (EBM) [0:27] | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>Neither of these formats conforms to the ECMP requirement. >>There are some alternatives that can be used to bring the above in >>compliance with the ECMP requirement. >> >>1. Allocate the nibble '1000' to indicate RTP after the labels. >>As has already been noted, IP version 8 has already been assigned by IANA >>to "The P Internet Protocol". While this protocol was never widely >>implemented (was it ever implemented?), I cannot predict with any >>certainty how easy or hard it would be reassign this value. I can also >>imagine arguments outside of the PWE3 WG that RTP should always be >>preceded by IP and UDP, and should not immediately follow a link layer >>(treating MPLS as the link layer in this case). So this is probably a >>nonstarter. >> >>2. Use an MPLS payload identifier. >>This would place George and Stewart's proposed MPLS payload identifier >>immediately after the labels and before the RTP header: >>+-----------------------------------+ >>| PSN and Multiplexing Layer | >>| Headers | >>+----+------------------------------+ >>|0001| protocol identifier | >>+----+------------------------------+ >>| RTP Header | >>| (RFC1889) | >>+-----------------------------------+ >>| CEP Header | >>+-----------------------------------+ >>| | >>| | >>| SONET/SDH | >>| Fragment | >>| | >>| | >>+-----------------------------------+ >>The primary problem with this solution is efficiency. The protocol >>identifier is actually 28 bits of redundant information, since signaling >>and/or provisioning have already been used to identify the PW contents. >>So we're really only using 4 bits to say "this is not IPv4 or IPv6", and >>the other 28 bits are unnecessary. >>To really illustrate the efficiently problem, recall that the CEP header >>is currently 4 or 8 octets in length. In the common case when RTP is >>unused, this would in effect always be adding 4 octets to the CEP header, >>increasing it to 8 or 12 octets, with the 12-octet header being used in >>the more BW-constrained situations, or where you're creating more PWs >>(SONET VTs). >> >>3. Change the headers and the RTP location. >>In this proposal, we would change the packet structure to: >>+-----------------------------------+ >>| PSN and Multiplexing Layer | >>| Headers | >>+-----------------------------------+ >>| CEP Header | >>+-----------------------------------+ >>| RTP Header | >>| (RFC1889) | >>+-----------------------------------+ >>| | >>| | >>| SONET/SDH | >>| Fragment | >>| | >>| | >>+-----------------------------------+ >>and the CEP header would become a constant 8 octets in all cases: >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>|0|0|0|0| Equipped Bit Mask (EBM) [0:27] | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>|E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>When VTs are not in use, the first word will always be all zeros, and the >>header length is the same as in option 2. But when VTs are in use, the >>header length is 4 octets LESS than in option 2. >>This alternative does not require the allocation of any new PIDs, since >>we're going to be using 0000 anyway. And how do we know that this is a >>SONET header and not the usual other PWE3 header? The same as always - >>though PW signaling and/or provisioning. >>The only possible downside to this alternative is that it is less >>architecturally "pure" than alternative 2, since the RTP header follows >>the CEP header rather than precedes it. But that's OK with me! >>Personally, I prefer this alternative. I would be interested in hearing >>other opinions. >>Thanks for listening, >>Andy >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: SONET/SDH header issues and proposed resolution (long) Date: Tue, 8 Apr 2003 15:36:19 +0200 Lines: 322 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 08 14:43:20 2003 Return-path: To: "'Andrew G. Malis'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy, Please see some comments inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Tuesday, April 08, 2003 12:34 PM > To: Sasha Vainshtein > Cc: 'Andrew G. Malis'; pwe3@ietf.org > Subject: RE: [PWE3] SONET/SDH header issues and proposed > resolution (long) > > > Sasha, > ... snipped ... > > >2. Please consider the case when the transport network is IP, and not > > MPLS. (The demultiplexing method is not important - it may be > > L2TPv3, MPLS-in-IP, MPLS-in-GRE or something else). In this case: > > a) There is no need at all in the MPLS PID > > b) There is a definite added value in using the same > encapsulations > > for IP and MPLS transports > > c) There is a definite added value in preserving the traditional > > position of the RTP header relative to IP transport > > Note that section 4.5 in the SONET draft (L2TP) is for future > study, and > What about Section 4.4.1 and Figure 4 in the SONET draft? Are you going to limit the draft to MPLS-only? And if not, then what do you propose? > > for good reason. There has been zero interest in running > SONET/SDH over > anything but MPLS. Certainly those of us that are > implementing this (at > least those of which I am aware) are only doing MPLS > implementations. I > would rather optimize for the common case. > > Does this include SONET-VT and Fractional STS-1/VC4? In other words, do you mean that there is zero interest in carrying just one or two VT-1.5s or VC-2s over an IP core? And does this include inter-AS (with MPLS-in-IP) cases as well? > > >3. IMO, Option 3 (your preference) does not provide a solution > > for the case of Fractional VC4 (see Section 8.2.3.2 and > > Figure 16 in draft-ieft-pwe3-sonet-01.txt). > > It does handle it - that's the use of the "E" bit in the > header - bit 0 in > the second word. But you're right in that we'll be unable to > use the first > word for this one case. So in this case, the header will be: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0|0|0| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Why not the MPLS PID as defined by Stewart? And why such a difference between the case of Fractional VC4 vs. Fractional STS-1? (In one case the flags, the structure pointer and the sequence number follow the EBM, in the other case they precede it)? In other words, why three different solutions instead of one generic? > ... snipped ... > > >I also think that estimates of BW effectiveness of > >Option 3 vs. Option 2 must take into account that, BW-wise, > >Fractional STS-1 and Fractional VC4 methods only make sense > >when you carry a substantial number of (concatenated) VTs > >between the given pair of endpoints. This is due to the > >fact that, with an individual VT, you MAY limit yourself > >to one packet every 500 uS, while with fractional STS-1 or > >Fractional VC-4 you MUST generate at least one packet every > >125 uS and, in addition to that, must one additional byte > >(the TU pointer) per VT per 125 uS. So adding the MPLS PID > >will simply change the break-even condition. > > Actually, I think that helps make the case that you want to be as > BW-efficient as possible in general. We make out better in > almost all > cases with my proposal except for VC4, and in VC4 we break > even with the > MPLS protocol identifier proposal. > I would say that you only do better for Fractional STS-1. For all the rest of the cases your proposal gives exactly the same BW efficiency as Option 2 (add 32 bits per packet). > > Cheers, > Andy > > --------- > > >With best regards, > > Sasha Vainshtein > >email: sasha@axerra.com > >tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > > > -----Original Message----- > > > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > > > Sent: Monday, April 07, 2003 10:46 PM > > > To: pwe3@ietf.org > > > Cc: Andy Malis > > > Subject: [PWE3] SONET/SDH header issues and proposed > resolution (long) > > > > > > > > > From following the PWE3 WG list, there is a clear consensus > > > that PWs need > > > to take ECMP into account be using the upper nibble as a PID. > > > So there are > > > a few issues that have to be discussed in order to amend the > > > SONET/SDH > > > draft to conform. > > > > > > To review, draft-ietf-pwe3-sonet-01.txt currently has the > > > following packet > > > structure: > > > > > > +-----------------------------------+ > > > | PSN and Multiplexing Layer | > > > | Headers | > > > +-----------------------------------+ > > > | RTP Header | > > > | (RFC1889) | > > > +-----------------------------------+ > > > | CEP Header | > > > +-----------------------------------+ > > > | | > > > | | > > > | SONET/SDH | > > > | Fragment | > > > | | > > > | | > > > +-----------------------------------+ > > > > > > The first issue is the RTP header, which currently > > > immediately follows the > > > labels. Note that the RTP header can commonly be compressed > > > out, but when > > > it is used, its first nibble will always be '1000' (version = > > > 2, P = 0, X = > > > 0, as shown in figure 3 in draft-ietf-pwe3-sonet-01.txt). > > > > > > The placement of the RTP header prior to the CEP header isn't > > > written in > > > stone, and has been debated on the PWE3 list in the last few days. > > > > > > The second issue is the CEP header, which is either 32 or 64 > > > bits, and has > > > the following structure: > > > > > > Basic format: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Extended Fractional STS-1 format: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |E|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Neither of these formats conforms to the ECMP requirement. > > > > > > There are some alternatives that can be used to bring the above in > > > compliance with the ECMP requirement. > > > > > > > > > 1. Allocate the nibble '1000' to indicate RTP after the labels. > > > > > > As has already been noted, IP version 8 has already been > > > assigned by IANA > > > to "The P Internet Protocol". While this protocol was > never widely > > > implemented (was it ever implemented?), I cannot predict with > > > any certainty > > > how easy or hard it would be reassign this value. I can > also imagine > > > arguments outside of the PWE3 WG that RTP should always be > > > preceded by IP > > > and UDP, and should not immediately follow a link layer > > > (treating MPLS as > > > the link layer in this case). So this is probably a nonstarter. > > > > > > > > > 2. Use an MPLS payload identifier. > > > > > > This would place George and Stewart's proposed MPLS payload > > > identifier > > > immediately after the labels and before the RTP header: > > > > > > +-----------------------------------+ > > > | PSN and Multiplexing Layer | > > > | Headers | > > > +----+------------------------------+ > > > |0001| protocol identifier | > > > +----+------------------------------+ > > > | RTP Header | > > > | (RFC1889) | > > > +-----------------------------------+ > > > | CEP Header | > > > +-----------------------------------+ > > > | | > > > | | > > > | SONET/SDH | > > > | Fragment | > > > | | > > > | | > > > +-----------------------------------+ > > > > > > The primary problem with this solution is efficiency. > The protocol > > > identifier is actually 28 bits of redundant information, > > > since signaling > > > and/or provisioning have already been used to identify the PW > > > contents. So > > > we're really only using 4 bits to say "this is not IPv4 or > > > IPv6", and the > > > other 28 bits are unnecessary. > > > > > > To really illustrate the efficiently problem, recall that the > > > CEP header is > > > currently 4 or 8 octets in length. In the common case when > > > RTP is unused, > > > this would in effect always be adding 4 octets to the CEP header, > > > increasing it to 8 or 12 octets, with the 12-octet header > > > being used in the > > > more BW-constrained situations, or where you're creating more > > > PWs (SONET VTs). > > > > > > > > > 3. Change the headers and the RTP location. > > > > > > In this proposal, we would change the packet structure to: > > > > > > +-----------------------------------+ > > > | PSN and Multiplexing Layer | > > > | Headers | > > > +-----------------------------------+ > > > | CEP Header | > > > +-----------------------------------+ > > > | RTP Header | > > > | (RFC1889) | > > > +-----------------------------------+ > > > | | > > > | | > > > | SONET/SDH | > > > | Fragment | > > > | | > > > | | > > > +-----------------------------------+ > > > > > > and the CEP header would become a constant 8 octets in all cases: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > When VTs are not in use, the first word will always be all > > > zeros, and the > > > header length is the same as in option 2. But when VTs are > > > in use, the > > > header length is 4 octets LESS than in option 2. > > > > > > This alternative does not require the allocation of any new > > > PIDs, since > > > we're going to be using 0000 anyway. And how do we know that > > > this is a > > > SONET header and not the usual other PWE3 header? The same > > > as always - > > > though PW signaling and/or provisioning. > > > > > > The only possible downside to this alternative is that it is less > > > architecturally "pure" than alternative 2, since the RTP > > > header follows the > > > CEP header rather than precedes it. But that's OK with me! > > > > > > Personally, I prefer this alternative. I would be interested > > > in hearing > > > other opinions. > > > > > > Thanks for listening, > > > Andy > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: SONET/SDH header issues and proposed resolution (long) Date: Tue, 8 Apr 2003 15:52:01 +0200 Lines: 250 Sender: pwe3-admin@ietf.org References: <3E92A83B.9050708@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Tue Apr 08 14:55:28 2003 Return-path: To: , "'Andrew G. Malis'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E92A83B.9050708@cisco.com> Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, No. There is no consensus. Please see my previous email. My vote is for option 2 that Andy described. This is most consistent with the current SONET/SDH draft and with the proposal you sent earlier to the list. Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Stewart Bryant > Sent: Tuesday, April 08, 2003 12:45 PM > To: Andrew G. Malis > Cc: pwe3@ietf.org > Subject: Re: [PWE3] SONET/SDH header issues and proposed > resolution (long) > > > Good summary Andy > > Given that we have surfaced the issue of MPLS payload type > discrimination we should probably run the issue to its > natural conclusion. > > However Option (3) has the right ECMP properties, the > byte efficiency properties you are looking for and is > consistent with the other CW's at the necessary level. > > If this becomes the chosen option I suggest modifying the > PW arch draft to say : > > Preferably use the "Martini" encapsulation. > > If there are technical reasons, i.e. the requirements of the > PW, or the need for compatibility with other standards then > keep the first nibble == 0 for ECMP reasons. > > If even this is not possible, or there is a need multiplex > something else over the mux label, then use the MPLS PID. > > Do I have consensus? > > Stewart > > Andrew G. Malis wrote: > > From following the PWE3 WG list, there is a clear > consensus that PWs > > need to take ECMP into account be using the upper nibble as > a PID. So > > there are a few issues that have to be discussed in order > to amend the > > SONET/SDH draft to conform. > > > > To review, draft-ietf-pwe3-sonet-01.txt currently has the following > > packet structure: > > > > +-----------------------------------+ > > | PSN and Multiplexing Layer | > > | Headers | > > +-----------------------------------+ > > | RTP Header | > > | (RFC1889) | > > +-----------------------------------+ > > | CEP Header | > > +-----------------------------------+ > > | | > > | | > > | SONET/SDH | > > | Fragment | > > | | > > | | > > +-----------------------------------+ > > > > The first issue is the RTP header, which currently > immediately follows > > the labels. Note that the RTP header can commonly be > compressed out, > > but when it is used, its first nibble will always be '1000' > (version = > > 2, P = 0, X = 0, as shown in figure 3 in > draft-ietf-pwe3-sonet-01.txt). > > > > The placement of the RTP header prior to the CEP header > isn't written > > in > > stone, and has been debated on the PWE3 list in the last few days. > > > > The second issue is the CEP header, which is either 32 or > 64 bits, and > > has the following structure: > > > > Basic format: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Extended Fractional STS-1 format: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |E|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Neither of these formats conforms to the ECMP requirement. > > > > There are some alternatives that can be used to bring the above in > > compliance with the ECMP requirement. > > > > > > 1. Allocate the nibble '1000' to indicate RTP after the labels. > > > > As has already been noted, IP version 8 has already been assigned by > > IANA to "The P Internet Protocol". While this protocol was > never widely > > implemented (was it ever implemented?), I cannot predict with any > > certainty how easy or hard it would be reassign this value. > I can also > > imagine arguments outside of the PWE3 WG that RTP should always be > > preceded by IP and UDP, and should not immediately follow a > link layer > > (treating MPLS as the link layer in this case). So this is > probably a > > nonstarter. > > > > > > 2. Use an MPLS payload identifier. > > > > This would place George and Stewart's proposed MPLS payload > identifier > > immediately after the labels and before the RTP header: > > > > +-----------------------------------+ > > | PSN and Multiplexing Layer | > > | Headers | > > +----+------------------------------+ > > |0001| protocol identifier | > > +----+------------------------------+ > > | RTP Header | > > | (RFC1889) | > > +-----------------------------------+ > > | CEP Header | > > +-----------------------------------+ > > | | > > | | > > | SONET/SDH | > > | Fragment | > > | | > > | | > > +-----------------------------------+ > > > > The primary problem with this solution is efficiency. The protocol > > identifier is actually 28 bits of redundant information, > since signaling > > and/or provisioning have already been used to identify the > PW contents. > > So we're really only using 4 bits to say "this is not IPv4 > or IPv6", and > > the other 28 bits are unnecessary. > > > > To really illustrate the efficiently problem, recall that the CEP > > header > > is currently 4 or 8 octets in length. In the common case > when RTP is > > unused, this would in effect always be adding 4 octets to the CEP > > header, increasing it to 8 or 12 octets, with the 12-octet > header being > > used in the more BW-constrained situations, or where you're > creating > > more PWs (SONET VTs). > > > > > > 3. Change the headers and the RTP location. > > > > In this proposal, we would change the packet structure to: > > > > +-----------------------------------+ > > | PSN and Multiplexing Layer | > > | Headers | > > +-----------------------------------+ > > | CEP Header | > > +-----------------------------------+ > > | RTP Header | > > | (RFC1889) | > > +-----------------------------------+ > > | | > > | | > > | SONET/SDH | > > | Fragment | > > | | > > | | > > +-----------------------------------+ > > > > and the CEP header would become a constant 8 octets in all cases: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > When VTs are not in use, the first word will always be all > zeros, and > > the header length is the same as in option 2. But when VTs > are in use, > > the header length is 4 octets LESS than in option 2. > > > > This alternative does not require the allocation of any new PIDs, > > since > > we're going to be using 0000 anyway. And how do we know > that this is a > > SONET header and not the usual other PWE3 header? The same > as always - > > though PW signaling and/or provisioning. > > > > The only possible downside to this alternative is that it is less > > architecturally "pure" than alternative 2, since the RTP > header follows > > the CEP header rather than precedes it. But that's OK with me! > > > > Personally, I prefer this alternative. I would be interested in > > hearing > > other opinions. > > > > Thanks for listening, > > Andy > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: SONET/SDH header issues and proposed resolution (long) Date: Tue, 8 Apr 2003 15:52:01 +0200 Lines: 359 Sender: pwe3-admin@ietf.org References: <5.2.1.1.0.20030408060956.01b35fc0@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Tue Apr 08 14:59:03 2003 Return-path: To: "'Andrew G. Malis'" , "'Sasha Vainshtein'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.2.1.1.0.20030408060956.01b35fc0@po1.vivacenetworks.com> Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy, I agree with Sasha. The MPLS PID is the only option that is relevant out of the options you have listed. I can just repeat what Sasha said, with the following remarks: 1. There are implementations that run SONET/SDH CEP over IP. There are providers that do not run MPLS on their core and are interested in this solution. 2. We need consistent fractional STS-1 and VC-4 encapsulations. We can not reverse the encapsulation just for fractional STS-1, and have it different for VC-4. 3. I think that it should be a mistake to reverse the order of RTP compared to the CEP header. It should be consistent in running any TDM encapsulation on top of IP or MPLS. The CEP header should reside between the RTP header and the SONET/SDH payload. 4. I think that we should not restrict RTP to run without X or P bits set (here I disagree with Sasha). If one needs to run RTP on top of MPLS, over ECMP enabled network, it should add the MPLS PID. 5. The MPLS PID should be optional, and should be used only when the network requires IP flow support. Hence, the CEP header would be 4 bytes for VT or STS-1, only longer for fractional STS-1/VC-4. Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Andrew G. Malis > Sent: Tuesday, April 08, 2003 12:34 PM > To: Sasha Vainshtein > Cc: 'Andrew G. Malis'; pwe3@ietf.org > Subject: RE: [PWE3] SONET/SDH header issues and proposed > resolution (long) > > > Sasha, > > Thanks for your reply. Comments inline .... > > At 4/8/2003 01:02 PM +0200, Sasha Vainshtein wrote: > > >Andy and all, > > > >I think you have given a very good analysis of the existing options. > >And I agree with you that using value '1000' (= 8) in the > first nibble > >of the RTP header (my original > >preference) is a non-starter. > > > >However, I disagree with your preference and think that > >Option 2 (an explicit MPLS PID word preceding the RTP header > followed > >by the CW) is preferable to Option 3 (placing the potentially unused > >EBM before the CW); below I'll try to explain why. > > > >1. As you have noticed, this option is "architecturally pure". > > IMO, this minimizes the risk of potential future problems > > With all due respect, "potential future problems" is vague at > best and FUD > at worst. If there's an actual problem to address, that's > something else > entirely. > > >2. Please consider the case when the transport network is IP, and not > > MPLS. (The demultiplexing method is not important - it may be > > L2TPv3, MPLS-in-IP, MPLS-in-GRE or something else). In this case: > > a) There is no need at all in the MPLS PID > > b) There is a definite added value in using the same > encapsulations > > for IP and MPLS transports > > c) There is a definite added value in preserving the traditional > > position of the RTP header relative to IP transport > > Note that section 4.5 in the SONET draft (L2TP) is for future > study, and > for good reason. There has been zero interest in running > SONET/SDH over > anything but MPLS. Certainly those of us that are > implementing this (at > least those of which I am aware) are only doing MPLS > implementations. I > would rather optimize for the common case. > > >3. IMO, Option 3 (your preference) does not provide a solution > > for the case of Fractional VC4 (see Section 8.2.3.2 and > > Figure 16 in draft-ieft-pwe3-sonet-01.txt). > > It does handle it - that's the use of the "E" bit in the > header - bit 0 in > the second word. But you're right in that we'll be unable to > use the first > word for this one case. So in this case, the header will be: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0|0|0| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| Equipped Bit Mask #1 (EBM) [0:29] TUG-3#1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| Equipped Bit Mask #2 (EBM) [0:29] TUG-3#2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |E|0| Equipped Bit Mask #3 (EBM) [0:29] TUG-3#3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >I also think that estimates of BW effectiveness of > >Option 3 vs. Option 2 must take into account that, BW-wise, > Fractional > >STS-1 and Fractional VC4 methods only make sense when you carry a > >substantial number of (concatenated) VTs between the given pair of > >endpoints. This is due to the fact that, with an individual > VT, you MAY > >limit yourself to one packet every 500 uS, while with > fractional STS-1 > >or Fractional VC-4 you MUST generate at least one packet every > >125 uS and, in addition to that, must one additional byte > >(the TU pointer) per VT per 125 uS. So adding the MPLS PID > >will simply change the break-even condition. > > Actually, I think that helps make the case that you want to be as > BW-efficient as possible in general. We make out better in > almost all > cases with my proposal except for VC4, and in VC4 we break > even with the > MPLS protocol identifier proposal. > > Cheers, > Andy > > --------- > > >With best regards, > > Sasha Vainshtein > >email: sasha@axerra.com > >tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > > > -----Original Message----- > > > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > > > Sent: Monday, April 07, 2003 10:46 PM > > > To: pwe3@ietf.org > > > Cc: Andy Malis > > > Subject: [PWE3] SONET/SDH header issues and proposed resolution > > > (long) > > > > > > > > > From following the PWE3 WG list, there is a clear consensus that > > > PWs need to take ECMP into account be using the upper nibble as a > > > PID. So there are > > > a few issues that have to be discussed in order to amend the > > > SONET/SDH > > > draft to conform. > > > > > > To review, draft-ietf-pwe3-sonet-01.txt currently has the > following > > > packet > > > structure: > > > > > > +-----------------------------------+ > > > | PSN and Multiplexing Layer | > > > | Headers | > > > +-----------------------------------+ > > > | RTP Header | > > > | (RFC1889) | > > > +-----------------------------------+ > > > | CEP Header | > > > +-----------------------------------+ > > > | | > > > | | > > > | SONET/SDH | > > > | Fragment | > > > | | > > > | | > > > +-----------------------------------+ > > > > > > The first issue is the RTP header, which currently immediately > > > follows the labels. Note that the RTP header can commonly be > > > compressed out, but when > > > it is used, its first nibble will always be '1000' (version = > > > 2, P = 0, X = > > > 0, as shown in figure 3 in draft-ietf-pwe3-sonet-01.txt). > > > > > > The placement of the RTP header prior to the CEP header isn't > > > written in stone, and has been debated on the PWE3 list > in the last > > > few days. > > > > > > The second issue is the CEP header, which is either 32 or > 64 bits, > > > and has the following structure: > > > > > > Basic format: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Extended Fractional STS-1 format: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |E|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Neither of these formats conforms to the ECMP requirement. > > > > > > There are some alternatives that can be used to bring the > above in > > > compliance with the ECMP requirement. > > > > > > > > > 1. Allocate the nibble '1000' to indicate RTP after the labels. > > > > > > As has already been noted, IP version 8 has already been > assigned by > > > IANA to "The P Internet Protocol". While this protocol was never > > > widely implemented (was it ever implemented?), I cannot > predict with > > > any certainty > > > how easy or hard it would be reassign this value. I can > also imagine > > > arguments outside of the PWE3 WG that RTP should always be > > > preceded by IP > > > and UDP, and should not immediately follow a link layer > > > (treating MPLS as > > > the link layer in this case). So this is probably a nonstarter. > > > > > > > > > 2. Use an MPLS payload identifier. > > > > > > This would place George and Stewart's proposed MPLS payload > > > identifier immediately after the labels and before the RTP header: > > > > > > +-----------------------------------+ > > > | PSN and Multiplexing Layer | > > > | Headers | > > > +----+------------------------------+ > > > |0001| protocol identifier | > > > +----+------------------------------+ > > > | RTP Header | > > > | (RFC1889) | > > > +-----------------------------------+ > > > | CEP Header | > > > +-----------------------------------+ > > > | | > > > | | > > > | SONET/SDH | > > > | Fragment | > > > | | > > > | | > > > +-----------------------------------+ > > > > > > The primary problem with this solution is efficiency. > The protocol > > > identifier is actually 28 bits of redundant information, since > > > signaling and/or provisioning have already been used to > identify the > > > PW contents. So > > > we're really only using 4 bits to say "this is not IPv4 or > > > IPv6", and the > > > other 28 bits are unnecessary. > > > > > > To really illustrate the efficiently problem, recall that the CEP > > > header is currently 4 or 8 octets in length. In the common case > > > when RTP is unused, > > > this would in effect always be adding 4 octets to the CEP header, > > > increasing it to 8 or 12 octets, with the 12-octet header > > > being used in the > > > more BW-constrained situations, or where you're creating more > > > PWs (SONET VTs). > > > > > > > > > 3. Change the headers and the RTP location. > > > > > > In this proposal, we would change the packet structure to: > > > > > > +-----------------------------------+ > > > | PSN and Multiplexing Layer | > > > | Headers | > > > +-----------------------------------+ > > > | CEP Header | > > > +-----------------------------------+ > > > | RTP Header | > > > | (RFC1889) | > > > +-----------------------------------+ > > > | | > > > | | > > > | SONET/SDH | > > > | Fragment | > > > | | > > > | | > > > +-----------------------------------+ > > > > > > and the CEP header would become a constant 8 octets in all cases: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > When VTs are not in use, the first word will always be all zeros, > > > and the header length is the same as in option 2. But > when VTs are > > > in use, the > > > header length is 4 octets LESS than in option 2. > > > > > > This alternative does not require the allocation of any new PIDs, > > > since we're going to be using 0000 anyway. And how do we > know that > > > this is a > > > SONET header and not the usual other PWE3 header? The same > > > as always - > > > though PW signaling and/or provisioning. > > > > > > The only possible downside to this alternative is that it is less > > > architecturally "pure" than alternative 2, since the RTP header > > > follows the CEP header rather than precedes it. But > that's OK with > > > me! > > > > > > Personally, I prefer this alternative. I would be interested in > > > hearing other opinions. > > > > > > Thanks for listening, > > > Andy > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "tom k. johnson" Subject: RE: SONET/SDH header issues and proposed resolution (long) Date: Tue, 8 Apr 2003 09:26:33 -0400 Lines: 251 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Tue Apr 08 15:29:00 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] SONET/SDH header issues and proposed resolution (long) Thread-Index: AcL9vO12+gPFblnSTP6h9JyDAFNyqQAFKu8A To: , "Andrew G. Malis" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h38DTG824196 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart/Andy If I'm reading your text correctly, that would say that either option 2 or option 3 would be acceptable (?) If so, then I agree with your proposal for updating the architecture doc. Then (I assume) it's up to each service draft to come up with an implementation. For SONET, I'm fine with either option 2 or option 3. Thanks! -Tom > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, April 08, 2003 6:45 AM > To: Andrew G. Malis > Cc: pwe3@ietf.org > Subject: Re: [PWE3] SONET/SDH header issues and proposed resolution > (long) > > > Good summary Andy > > Given that we have surfaced the issue of MPLS payload type > discrimination we should probably run the issue to its natural > conclusion. > > However Option (3) has the right ECMP properties, the > byte efficiency properties you are looking for and is > consistent with the other CW's at the necessary level. > > If this becomes the chosen option I suggest modifying the > PW arch draft to say : > > Preferably use the "Martini" encapsulation. > > If there are technical reasons, i.e. the requirements of the > PW, or the need for compatibility with other standards > then keep the first nibble == 0 for ECMP reasons. > > If even this is not possible, or there is a need multiplex something > else over the mux label, then use the MPLS PID. > > Do I have consensus? > > Stewart > > Andrew G. Malis wrote: > > From following the PWE3 WG list, there is a clear > consensus that PWs > > need to take ECMP into account be using the upper nibble as > a PID. So > > there are a few issues that have to be discussed in order > to amend the > > SONET/SDH draft to conform. > > > > To review, draft-ietf-pwe3-sonet-01.txt currently has the following > > packet structure: > > > > +-----------------------------------+ > > | PSN and Multiplexing Layer | > > | Headers | > > +-----------------------------------+ > > | RTP Header | > > | (RFC1889) | > > +-----------------------------------+ > > | CEP Header | > > +-----------------------------------+ > > | | > > | | > > | SONET/SDH | > > | Fragment | > > | | > > | | > > +-----------------------------------+ > > > > The first issue is the RTP header, which currently > immediately follows > > the labels. Note that the RTP header can commonly be > compressed out, > > but when it is used, its first nibble will always be '1000' > (version = > > 2, P = 0, X = 0, as shown in figure 3 in > draft-ietf-pwe3-sonet-01.txt). > > > > The placement of the RTP header prior to the CEP header > isn't written in > > stone, and has been debated on the PWE3 list in the last few days. > > > > The second issue is the CEP header, which is either 32 or > 64 bits, and > > has the following structure: > > > > Basic format: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Extended Fractional STS-1 format: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |E|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Neither of these formats conforms to the ECMP requirement. > > > > There are some alternatives that can be used to bring the above in > > compliance with the ECMP requirement. > > > > > > 1. Allocate the nibble '1000' to indicate RTP after the labels. > > > > As has already been noted, IP version 8 has already been > assigned by > > IANA to "The P Internet Protocol". While this protocol was > never widely > > implemented (was it ever implemented?), I cannot predict with any > > certainty how easy or hard it would be reassign this value. > I can also > > imagine arguments outside of the PWE3 WG that RTP should always be > > preceded by IP and UDP, and should not immediately follow a > link layer > > (treating MPLS as the link layer in this case). So this is > probably a > > nonstarter. > > > > > > 2. Use an MPLS payload identifier. > > > > This would place George and Stewart's proposed MPLS payload > identifier > > immediately after the labels and before the RTP header: > > > > +-----------------------------------+ > > | PSN and Multiplexing Layer | > > | Headers | > > +----+------------------------------+ > > |0001| protocol identifier | > > +----+------------------------------+ > > | RTP Header | > > | (RFC1889) | > > +-----------------------------------+ > > | CEP Header | > > +-----------------------------------+ > > | | > > | | > > | SONET/SDH | > > | Fragment | > > | | > > | | > > +-----------------------------------+ > > > > The primary problem with this solution is efficiency. The protocol > > identifier is actually 28 bits of redundant information, > since signaling > > and/or provisioning have already been used to identify the > PW contents. > > So we're really only using 4 bits to say "this is not IPv4 > or IPv6", and > > the other 28 bits are unnecessary. > > > > To really illustrate the efficiently problem, recall that > the CEP header > > is currently 4 or 8 octets in length. In the common case > when RTP is > > unused, this would in effect always be adding 4 octets to the CEP > > header, increasing it to 8 or 12 octets, with the 12-octet > header being > > used in the more BW-constrained situations, or where you're > creating > > more PWs (SONET VTs). > > > > > > 3. Change the headers and the RTP location. > > > > In this proposal, we would change the packet structure to: > > > > +-----------------------------------+ > > | PSN and Multiplexing Layer | > > | Headers | > > +-----------------------------------+ > > | CEP Header | > > +-----------------------------------+ > > | RTP Header | > > | (RFC1889) | > > +-----------------------------------+ > > | | > > | | > > | SONET/SDH | > > | Fragment | > > | | > > | | > > +-----------------------------------+ > > > > and the CEP header would become a constant 8 octets in all cases: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0|0|0|0| Equipped Bit Mask (EBM) [0:27] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > When VTs are not in use, the first word will always be all > zeros, and > > the header length is the same as in option 2. But when VTs > are in use, > > the header length is 4 octets LESS than in option 2. > > > > This alternative does not require the allocation of any new > PIDs, since > > we're going to be using 0000 anyway. And how do we know > that this is a > > SONET header and not the usual other PWE3 header? The same > as always - > > though PW signaling and/or provisioning. > > > > The only possible downside to this alternative is that it is less > > architecturally "pure" than alternative 2, since the RTP > header follows > > the CEP header rather than precedes it. But that's OK with me! > > > > Personally, I prefer this alternative. I would be > interested in hearing > > other opinions. > > > > Thanks for listening, > > Andy > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Tue, 08 Apr 2003 14:59:40 +0100 Organization: Cisco Systems, Inc. Lines: 330 Sender: pwe3-admin@ietf.org References: <0E2DFCE7E586904DA0F583CB5EAD73CC3C5B0A@WATERTOWN.litchfieldcomm.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Andrew G. Malis" , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Tue Apr 08 16:04:32 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "tom k. johnson" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O tom k. johnson wrote: > Stewart/Andy > > If I'm reading your text correctly, that would say that either option 2 or option 3 would be acceptable (?) > Yes. Clearly the purest approach is always to use the MPLS PID (opt 2), but just as we found a way to grandfather the Martini and ITU encaps (and save the four bytes), I am OK with the SONET team saving the bytes. However we do have to get to ONE solution, i.e. to decide if it is more important to grandfather the existing work, or save the bytes. Stewart > If so, then I agree with your proposal for updating the architecture doc. > > Then (I assume) it's up to each service draft to come up with an implementation. For SONET, I'm fine with either option 2 or option 3. > > Thanks! > > -Tom > > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Tuesday, April 08, 2003 6:45 AM >>To: Andrew G. Malis >>Cc: pwe3@ietf.org >>Subject: Re: [PWE3] SONET/SDH header issues and proposed resolution >>(long) >> >> >>Good summary Andy >> >>Given that we have surfaced the issue of MPLS payload type >>discrimination we should probably run the issue to its natural >>conclusion. >> >>However Option (3) has the right ECMP properties, the >>byte efficiency properties you are looking for and is >>consistent with the other CW's at the necessary level. >> >>If this becomes the chosen option I suggest modifying the >>PW arch draft to say : >> >>Preferably use the "Martini" encapsulation. >> >>If there are technical reasons, i.e. the requirements of the >>PW, or the need for compatibility with other standards >>then keep the first nibble == 0 for ECMP reasons. >> >>If even this is not possible, or there is a need multiplex something >>else over the mux label, then use the MPLS PID. >> >>Do I have consensus? >> >>Stewart >> >>Andrew G. Malis wrote: >> >>> From following the PWE3 WG list, there is a clear >> >>consensus that PWs >> >>>need to take ECMP into account be using the upper nibble as >> >>a PID. So >> >>>there are a few issues that have to be discussed in order >> >>to amend the >> >>>SONET/SDH draft to conform. >>> >>>To review, draft-ietf-pwe3-sonet-01.txt currently has the following >>>packet structure: >>> >>>+-----------------------------------+ >>>| PSN and Multiplexing Layer | >>>| Headers | >>>+-----------------------------------+ >>>| RTP Header | >>>| (RFC1889) | >>>+-----------------------------------+ >>>| CEP Header | >>>+-----------------------------------+ >>>| | >>>| | >>>| SONET/SDH | >>>| Fragment | >>>| | >>>| | >>>+-----------------------------------+ >>> >>>The first issue is the RTP header, which currently >> >>immediately follows >> >>>the labels. Note that the RTP header can commonly be >> >>compressed out, >> >>>but when it is used, its first nibble will always be '1000' >> >>(version = >> >>>2, P = 0, X = 0, as shown in figure 3 in >> >>draft-ietf-pwe3-sonet-01.txt). >> >>>The placement of the RTP header prior to the CEP header >> >>isn't written in >> >>>stone, and has been debated on the PWE3 list in the last few days. >>> >>>The second issue is the CEP header, which is either 32 or >> >>64 bits, and >> >>>has the following structure: >>> >>>Basic format: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>|0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>>Extended Fractional STS-1 format: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>|1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>|E|0|0|0| Equipped Bit Mask (EBM) [0:27] | >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>>Neither of these formats conforms to the ECMP requirement. >>> >>>There are some alternatives that can be used to bring the above in >>>compliance with the ECMP requirement. >>> >>> >>>1. Allocate the nibble '1000' to indicate RTP after the labels. >>> >>>As has already been noted, IP version 8 has already been >> >>assigned by >> >>>IANA to "The P Internet Protocol". While this protocol was >> >>never widely >> >>>implemented (was it ever implemented?), I cannot predict with any >>>certainty how easy or hard it would be reassign this value. >> >> I can also >> >>>imagine arguments outside of the PWE3 WG that RTP should always be >>>preceded by IP and UDP, and should not immediately follow a >> >>link layer >> >>>(treating MPLS as the link layer in this case). So this is >> >>probably a >> >>>nonstarter. >>> >>> >>>2. Use an MPLS payload identifier. >>> >>>This would place George and Stewart's proposed MPLS payload >> >>identifier >> >>>immediately after the labels and before the RTP header: >>> >>>+-----------------------------------+ >>>| PSN and Multiplexing Layer | >>>| Headers | >>>+----+------------------------------+ >>>|0001| protocol identifier | >>>+----+------------------------------+ >>>| RTP Header | >>>| (RFC1889) | >>>+-----------------------------------+ >>>| CEP Header | >>>+-----------------------------------+ >>>| | >>>| | >>>| SONET/SDH | >>>| Fragment | >>>| | >>>| | >>>+-----------------------------------+ >>> >>>The primary problem with this solution is efficiency. The protocol >>>identifier is actually 28 bits of redundant information, >> >>since signaling >> >>>and/or provisioning have already been used to identify the >> >>PW contents. >> >>>So we're really only using 4 bits to say "this is not IPv4 >> >>or IPv6", and >> >>>the other 28 bits are unnecessary. >>> >>>To really illustrate the efficiently problem, recall that >> >>the CEP header >> >>>is currently 4 or 8 octets in length. In the common case >> >>when RTP is >> >>>unused, this would in effect always be adding 4 octets to the CEP >>>header, increasing it to 8 or 12 octets, with the 12-octet >> >>header being >> >>>used in the more BW-constrained situations, or where you're >> >>creating >> >>>more PWs (SONET VTs). >>> >>> >>>3. Change the headers and the RTP location. >>> >>>In this proposal, we would change the packet structure to: >>> >>>+-----------------------------------+ >>>| PSN and Multiplexing Layer | >>>| Headers | >>>+-----------------------------------+ >>>| CEP Header | >>>+-----------------------------------+ >>>| RTP Header | >>>| (RFC1889) | >>>+-----------------------------------+ >>>| | >>>| | >>>| SONET/SDH | >>>| Fragment | >>>| | >>>| | >>>+-----------------------------------+ >>> >>>and the CEP header would become a constant 8 octets in all cases: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>|0|0|0|0| Equipped Bit Mask (EBM) [0:27] | >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>|E|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | >>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>>When VTs are not in use, the first word will always be all >> >>zeros, and >> >>>the header length is the same as in option 2. But when VTs >> >>are in use, >> >>>the header length is 4 octets LESS than in option 2. >>> >>>This alternative does not require the allocation of any new >> >>PIDs, since >> >>>we're going to be using 0000 anyway. And how do we know >> >>that this is a >> >>>SONET header and not the usual other PWE3 header? The same >> >>as always - >> >>>though PW signaling and/or provisioning. >>> >>>The only possible downside to this alternative is that it is less >>>architecturally "pure" than alternative 2, since the RTP >> >>header follows >> >>>the CEP header rather than precedes it. But that's OK with me! >>> >>>Personally, I prefer this alternative. I would be >> >>interested in hearing >> >>>other opinions. >>> >>>Thanks for listening, >>>Andy >>> >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: SONET/SDH header issues and proposed resolution (long) Date: Tue, 8 Apr 2003 17:10:55 +0200 Lines: 25 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "tom k. johnson" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 08 16:19:55 2003 Return-path: To: "'stbryant@cisco.com'" , "Andrew G. Malis" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, Andy and all, Please see inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] ... snipped ... > > However we do have to get to ONE solution, i.e. to decide if > it is more > important to grandfather the existing work, or save the bytes. > IMO Option 3 as presented in Andy's latest email cannot be considered as ONE solution: it saves the bytes in one case and grandfathers the existing work in some other ones. > ... snipped to the end ... From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Arch sections 5.4.3 and 5.4.4 Date: Thu, 10 Apr 2003 12:38:04 +0100 Organization: Cisco Systems, Inc. Lines: 145 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Apr 10 13:45:10 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "pwe3@ietf.org" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I have redrafted sections 5.4.3 and 5.4.4 of the arch draft, and hopefully the this moves us closer to consensus. I have removed the SONET text. The SONET team need to resolve whether they wish to use the bits 0..3 == 0x0 approach, or the payload type identifier approach, but the arch text is invariant to this decision. It is known that I have concerns over the ITU ATM format, but due to an artifact of the way that length is defined this conforms to figure 12. I have renamed the most basic 0x0 nibble CW the generic CW and the old Martini CW the preferred CW, and introduced then in that order, as this seems a more logical flow. There are two current proposals for MPLS payload type, which the authors are in the process of merging. I will produce a further update when this has happened. Comments? Stewart 5.4.3. PW over MPLS Generic Control Word To allow accurate packet inspection in an MPLS PSN, and to operate correctly over MPLS PSNs that have deployed equal-cost multiple-path load-ballancing a PW packet MUST NOT alias an IP packet. IP packets are carried in MPLS label stacks without any protocol identifier. Historic values of the IP version number [RFC791] [RFC1881] are therefore used to distinguish between IP and non-IP MPLS payloads. To disambiguate the PW from an IP flow the PW SHOULD employ either the generic PW control word shown in Figure 12, or an MPLS payload type identifier. Note that an MPLS payload with bits 0..3 = 4 is an IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Specified by PW Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Generic PW Control Word The PW set-up protocol determines whether a PW uses a control word. When a control word is used, it SHOULD have the following preferred form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: MPLS Preferred Control Word The meaning of the fields of the MPLS Preferred Control Word (Figure 13) is as follows: Flags (bits 4 to 7): These bits are available for per payload signaling. Their definition is encapsulation specific. FRG (bits 8 and 9): These bits are used when fragmenting a PW payload. Their use is defined in [FRAG]. When the PW is of a type that will never need payload fragmentation, these bits may be used as general purpose flags. Length (bits 10 to 15): The length field is used to determine the size of a PW payload that might have been padded to the minimum Ethernet MAC frame size during its transit across the PSN. If the MPLS payload (defined as the CW + the PW payload + any additional PW headers is less than 46 bytes, the length MUST be set to the length of the MPLS payload. If the MPLS payload is between 46 bytes and 63 bytes the implementation MAY either set to the length to the length of the MPLS payload, or it MAY set it to 0. If the length of the MPLS payload is greater than 63 bytes the length MUST be set to 0. Sequence number (Bit 16 to 31): If the sequence number is not used, it is set to zero by the sender and ignored by the receiver. Otherwise it specifies the sequence number of a packet. A circular list of sequence numbers is used. A sequence number takes a value from 1 to 65535 (2**16-1). If the payload is an OAM packet the sequence number MAY be used to mark the position in the sequence, in which case it has the same value as the last data PDU sent. The use of the sequence number is optional for OAM payloads. 5.4.4. MPLS Payload Identifier NOTE There are two proposals, the George Swallow proposal and the David Alan Proposal. We are working to merge these proposals and this text will then be aligned with that proposal. END NOTE If technical considerations result in a PW control word that may alias an IP packet, the control word SHOULD be preceded by an MPLS payload type identifier. For reference the MPLS payload type identifier [TBD] is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved | PPP DLL Protocol Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PPP DLL protocol definition | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: MPLS Payload Type Identifier PPP DLL Protocol Number [16:31]: These numbers are assigned by IANA. Some PW management messages such as OAM and LSP ping may require IP packets to be multiplexed onto the PW. These are carried over the PW using the IP MPLS payload type indicator, show in Figure 15: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved | IPv4 = 0x21, or IPv6 = 0x57 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP packet and management payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: MPLS Payload Type Identifier From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 10 Apr 2003 07:06:30 -0700 Lines: 17 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Thu Apr 10 16:14:47 2003 Return-path: To: "'stbryant@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Stewart, > > If technical considerations result in a PW control word that may > alias an IP packet, the control word SHOULD be preceded by an MPLS > payload type identifier. > Does this mean that if a PW control word does not alias an IP packet, it can't be preceded by an MPLS payload identifier? If not why? Also we need some clarification on what does this mean in the presence of the signaled L3PID/PW FEC? Would this PID supercede the protocol ID signaled via L3PID/PW FEC? Also is this MPLS PID applicable only to PW? if so why not make it general for any MPLS LSP? Yours, -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 10 Apr 2003 18:16:47 +0200 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'stbryant@cisco.com'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 10 17:26:24 2003 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, April 10, 2003 4:07 PM > To: 'stbryant@cisco.com'; pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > Hi Stewart, ... snipped ... > > Also is this MPLS PID applicable only to PW? if so why not > make it general for any MPLS LSP? > I believe that the answer is in the text posted by Stewart: IPv4/IPv6 packets are carried over MPLS without MPLS PID. > > Yours, > -Shahram > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 10 Apr 2003 08:22:16 -0700 Lines: 9 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: "'stbryant@cisco.com'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 10 17:31:47 2003 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >> Also is this MPLS PID applicable only to PW? if so why not >> make it general for any MPLS LSP? >> >I believe that the answer is in the text posted by Stewart: IPv4/IPv6 >packets are carried over MPLS without MPLS PID. I meant for non-IP traffic, which one is valid MPLS PID or signaled PW FEC type? -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: Arch sections 5.4.3 and 5.4.4 Date: Thu, 10 Apr 2003 17:39:02 +0100 Organization: Cisco Systems, Inc. Lines: 39 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C8C1@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 10 18:47:34 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote: > Hi Stewart, > > >> If technical considerations result in a PW control word that may >> alias an IP packet, the control word SHOULD be preceded by an MPLS >> payload type identifier. >> > > > Does this mean that if a PW control word does not alias an IP packet, > it can't be preceded by an MPLS payload identifier? If not why? > That was not the intent - I will clarify. My assumption was the reverse to yours - that any label stack could get followed by an MPLS PL ident, and that the use of the zero niblle was a dispensation. > Also we need some clarification on what does this mean in the presence of the > signaled L3PID/PW FEC? Would this PID supercede the protocol ID signaled via L3PID/PW FEC? Since there are people that want to multiplex IP packets on the PW, ie to have an parallel stream on the same FEC, I guess so. You could however argue that the set of allowable protocol types should be signalled. > Also is this MPLS PID applicable only to PW? > No. > if so why not make it general for any MPLS LSP? Indeed, I am of the view that we are just the first group to have to produce a solution to the problem rather than the last. This is being worked in parallel by the MPLS WG. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: Arch sections 5.4.3 and 5.4.4 Date: Thu, 10 Apr 2003 17:49:27 +0100 Organization: Cisco Systems, Inc. Lines: 21 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C8C3@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 10 18:55:30 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote: >>>Also is this MPLS PID applicable only to PW? if so why not >>>make it general for any MPLS LSP? >>> >> >>I believe that the answer is in the text posted by Stewart: IPv4/IPv6 >>packets are carried over MPLS without MPLS PID. > > > I meant for non-IP traffic, which one is valid MPLS PID or signaled PW FEC type? Isn't it an error if they dissagree, or am I missing something? Stewart > > -Shahram > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 10 Apr 2003 09:56:09 -0700 Lines: 11 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: "'Sasha Vainshtein'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 10 19:05:36 2003 Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >> I meant for non-IP traffic, which one is valid MPLS PID or >signaled PW FEC type? > >Isn't it an error if they dissagree, or am I missing something? > >Stewart Correct. That would be an error, but I am wondering what should be the follow up action. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: Arch sections 5.4.3 and 5.4.4 Date: Thu, 10 Apr 2003 19:00:17 +0100 Organization: Cisco Systems, Inc. Lines: 25 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C8C5@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 10 20:07:54 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote: >>>I meant for non-IP traffic, which one is valid MPLS PID or >> >>signaled PW FEC type? >> >>Isn't it an error if they dissagree, or am I missing something? >> I suggest discard the payload, but teardown is possible. Who needs to specify (if anyone), us or MPLS? Stewart >>Stewart > > > Correct. That would be an error, but I am wondering what should be > the follow up action. > > -Shahram > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Thu, 10 Apr 2003 14:46:18 -0400 Lines: 49 Sender: pwe3-admin@ietf.org References: <0E2DFCE7E586904DA0F583CB5EAD73CC3C5B0A@WATERTOWN.litchfieldcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "tom k. johnson" , "Andrew G. Malis" , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Apr 10 20:51:23 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: stbryant@cisco.com In-Reply-To: <3E92D5CC.4020705@cisco.com> X-OriginalArrivalTime: 10 Apr 2003 18:46:22.0686 (UTC) FILETIME=[7B7BFFE0:01C2FF91] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, The co-authors have put their heads together, as it were (and it wasn't all that painful, either :-) and agreed to go with option #2 (the architecturally pure approach, summarized below). So that's how you can write it up in the architecture spec, and we'll update the SONET/SDH spec to match. Cheers, Andy -------- At 4/8/2003 02:59 PM +0100, Stewart Bryant wrote: Clearly the purest approach is always to use the MPLS PID (opt 2), but just as we found a way to grandfather the Martini and ITU encaps (and save the four bytes), I am OK with the SONET team saving the bytes. However we do have to get to ONE solution, i.e. to decide if it is more important to grandfather the existing work, or save the bytes. Stewart ........ 2. Use an MPLS payload identifier. This would place George and Stewart's proposed MPLS payload identifier immediately after the labels and before the RTP header: +-----------------------------------+ | PSN and Multiplexing Layer | | Headers | +----+------------------------------+ |0001| protocol identifier | +----+------------------------------+ | RTP Header | | (RFC1889) | +-----------------------------------+ | CEP Header | +-----------------------------------+ | | | | | SONET/SDH | | Fragment | | | | | +-----------------------------------+ From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Thu, 10 Apr 2003 21:22:24 +0100 Organization: Cisco Systems, Inc. Lines: 62 Sender: pwe3-admin@ietf.org References: <0E2DFCE7E586904DA0F583CB5EAD73CC3C5B0A@WATERTOWN.litchfieldcomm.com> <5.2.1.1.0.20030410144215.03f67638@po1.vivacenetworks.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "tom k. johnson" , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Apr 10 22:32:05 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "Andrew G. Malis" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Good News. I think that the version of the 5.4.3 and 5.4.4 that I sent to the list earlier today is consistent with this. If not please let me know. Stewart Andrew G. Malis wrote: > Stewart, > > The co-authors have put their heads together, as it were (and it wasn't > all that painful, either :-) and agreed to go with option #2 (the > architecturally pure approach, summarized below). So that's how you can > write it up in the architecture spec, and we'll update the SONET/SDH > spec to match. > > Cheers, > Andy > > -------- > > At 4/8/2003 02:59 PM +0100, Stewart Bryant wrote: > > Clearly the purest approach is always to use the MPLS PID (opt 2), but > just as we found a way to grandfather the Martini and ITU encaps (and > save the four bytes), I am OK with the SONET team saving the bytes. > > However we do have to get to ONE solution, i.e. to decide if it is more > important to grandfather the existing work, or save the bytes. > > Stewart > > ........ > > 2. Use an MPLS payload identifier. > > This would place George and Stewart's proposed MPLS payload identifier > immediately after the labels and before the RTP header: > > +-----------------------------------+ > | PSN and Multiplexing Layer | > | Headers | > +----+------------------------------+ > |0001| protocol identifier | > +----+------------------------------+ > | RTP Header | > | (RFC1889) | > +-----------------------------------+ > | CEP Header | > +-----------------------------------+ > | | > | | > | SONET/SDH | > | Fragment | > | | > | | > +-----------------------------------+ > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Thu, 10 Apr 2003 17:45:28 -0400 Lines: 100 Sender: pwe3-admin@ietf.org References: <0E2DFCE7E586904DA0F583CB5EAD73CC3C5B0A@WATERTOWN.litchfieldcomm.com> <5.2.1.1.0.20030410144215.03f67638@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andrew G. Malis" , "tom k. johnson" , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Thu Apr 10 23:52:15 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: stbryant@cisco.com In-Reply-To: <3E95D280.9070100@cisco.com> X-OriginalArrivalTime: 10 Apr 2003 21:46:04.0599 (UTC) FILETIME=[96015C70:01C2FFAA] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, I would like to suggest some simplifications to the first part in your text: To allow accurate packet inspection in an MPLS PSN, and/or to operate correctly over MPLS PSNs that have deployed equal-cost multiple-path load-balancing, a PW packet MUST NOT alias an IP packet. IP packets are carried in MPLS label stacks without any protocol identifier. Historic values of the IP version number [RFC791] [RFC1881] are therefore used to distinguish between IP and non-IP MPLS payloads. Thus,an MPLS payload with bits 0..3 = 4 is a priori an IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. To disambiguate the PW from an IP flow the PW MAY either employ the preferred PW control word shown in Figure 12 or an MPLS payload type identifier (see Section 5.4.4): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: MPLS Preferred Control Word Note that not all PWE3 encapsulations over MPLS use this control word format. For example, the SONET/SDH encapsulation uses a different control word format. In the general case, if the MPLS payload does not begin with a control word as illustrated in Figure 12, then the payload MUST begin with an MPLS payload type identifier. There is one exception to this requirement; if a service provider is not using ECMP, then the provider SHOULD be able to use provisioning to suppress the transmission of the MPLS payload type identifier. The meaning of the fields of the MPLS Preferred Control Word (Figure 12) is as follows: The rest of the text is the same. Thanks, Andy ------- At 4/10/2003 09:22 PM +0100, Stewart Bryant wrote: >Good News. > >I think that the version of the 5.4.3 and 5.4.4 that I sent to >the list earlier today is consistent with this. If not please >let me know. > >Stewart > >Andrew G. Malis wrote: >>Stewart, >>The co-authors have put their heads together, as it were (and it wasn't >>all that painful, either :-) and agreed to go with option #2 (the >>architecturally pure approach, summarized below). So that's how you can >>write it up in the architecture spec, and we'll update the SONET/SDH spec >>to match. >>Cheers, >>Andy >>-------- >>At 4/8/2003 02:59 PM +0100, Stewart Bryant wrote: >>Clearly the purest approach is always to use the MPLS PID (opt 2), but >>just as we found a way to grandfather the Martini and ITU encaps (and >>save the four bytes), I am OK with the SONET team saving the bytes. >>However we do have to get to ONE solution, i.e. to decide if it is more >>important to grandfather the existing work, or save the bytes. >>Stewart >>........ >>2. Use an MPLS payload identifier. >>This would place George and Stewart's proposed MPLS payload identifier >>immediately after the labels and before the RTP header: >>+-----------------------------------+ >>| PSN and Multiplexing Layer | >>| Headers | >>+----+------------------------------+ >>|0001| protocol identifier | >>+----+------------------------------+ >>| RTP Header | >>| (RFC1889) | >>+-----------------------------------+ >>| CEP Header | >>+-----------------------------------+ >>| | >>| | >>| SONET/SDH | >>| Fragment | >>| | >>| | >>+-----------------------------------+ >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Thu, 10 Apr 2003 18:10:39 -0400 Organization: Alcatel Networks Corporaton Lines: 116 Sender: pwe3-admin@ietf.org References: <0E2DFCE7E586904DA0F583CB5EAD73CC3C5B0A@WATERTOWN.litchfieldcomm.com> <5.2.1.1.0.20030410144215.03f67638@po1.vivacenetworks.com> <5.2.1.1.0.20030410171131.04343390@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Apr 11 00:21:23 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Andrew G. Malis" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy, I would like to keep the original Figure 12 in Stewart's text as it covers the case of the 1:1 and PDU ATM encapsulations. If a PW encapsulation cannot comply to the Generic PW Control Word, then it should use the MPLS Payload Identifier, which is the option the SONET draft authors chose to make. Regards, Mustapha. ----------- "Andrew G. Malis" wrote: > > Stewart, > > I would like to suggest some simplifications to the first part in your text: > > To allow accurate packet inspection in an MPLS PSN, and/or to operate > correctly over MPLS PSNs that have deployed equal-cost multiple-path > load-balancing, a PW packet MUST NOT alias an IP packet. IP packets > are carried in MPLS label stacks without any protocol identifier. > Historic values of the IP version number [RFC791] [RFC1881] are > therefore used to distinguish between IP and non-IP MPLS payloads. > Thus,an MPLS payload with bits 0..3 = 4 is a priori an > IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. > > To disambiguate the PW from an IP flow the PW MAY either employ > the preferred PW control word shown in Figure 12 or an MPLS payload > type identifier (see Section 5.4.4): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Flags |FRG| Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: MPLS Preferred Control Word > > Note that not all PWE3 encapsulations over MPLS use this control word > format. > For example, the SONET/SDH encapsulation uses a different control word > format. > In the general case, if the MPLS payload does not begin with a control word > as illustrated in Figure 12, then the payload MUST begin with an MPLS > payload > type identifier. There is one exception to this requirement; if a service > provider is not using ECMP, then the provider SHOULD be able to use > provisioning to suppress the transmission of the MPLS payload type > identifier. > > The meaning of the fields of the MPLS Preferred Control Word (Figure > 12) is as follows: > > The rest of the text is the same. > > Thanks, > Andy > > ------- > > At 4/10/2003 09:22 PM +0100, Stewart Bryant wrote: > > >Good News. > > > >I think that the version of the 5.4.3 and 5.4.4 that I sent to > >the list earlier today is consistent with this. If not please > >let me know. > > > >Stewart > > > >Andrew G. Malis wrote: > >>Stewart, > >>The co-authors have put their heads together, as it were (and it wasn't > >>all that painful, either :-) and agreed to go with option #2 (the > >>architecturally pure approach, summarized below). So that's how you can > >>write it up in the architecture spec, and we'll update the SONET/SDH spec > >>to match. > >>Cheers, > >>Andy > >>-------- > >>At 4/8/2003 02:59 PM +0100, Stewart Bryant wrote: > >>Clearly the purest approach is always to use the MPLS PID (opt 2), but > >>just as we found a way to grandfather the Martini and ITU encaps (and > >>save the four bytes), I am OK with the SONET team saving the bytes. > >>However we do have to get to ONE solution, i.e. to decide if it is more > >>important to grandfather the existing work, or save the bytes. > >>Stewart > >>........ > >>2. Use an MPLS payload identifier. > >>This would place George and Stewart's proposed MPLS payload identifier > >>immediately after the labels and before the RTP header: > >>+-----------------------------------+ > >>| PSN and Multiplexing Layer | > >>| Headers | > >>+----+------------------------------+ > >>|0001| protocol identifier | > >>+----+------------------------------+ > >>| RTP Header | > >>| (RFC1889) | > >>+-----------------------------------+ > >>| CEP Header | > >>+-----------------------------------+ > >>| | > >>| | > >>| SONET/SDH | > >>| Fragment | > >>| | > >>| | > >>+-----------------------------------+ > >> > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Thu, 10 Apr 2003 18:25:35 -0400 Lines: 68 Sender: pwe3-admin@ietf.org References: <0E2DFCE7E586904DA0F583CB5EAD73CC3C5B0A@WATERTOWN.litchfieldcomm.com> <5.2.1.1.0.20030410144215.03f67638@po1.vivacenetworks.com> <5.2.1.1.0.20030410171131.04343390@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andrew G. Malis" , stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Apr 11 00:34:37 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Mustapha Aissaoui In-Reply-To: <3E95EBDF.F0C54D3A@alcatel.com> X-OriginalArrivalTime: 10 Apr 2003 22:25:41.0208 (UTC) FILETIME=[1E931D80:01C2FFB0] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha, Good comment. Does this work: To allow accurate packet inspection in an MPLS PSN, and/or to operate correctly over MPLS PSNs that have deployed equal-cost multiple-path load-balancing, a PW packet MUST NOT alias an IP packet. IP packets are carried in MPLS label stacks without any protocol identifier. Historic values of the IP version number [RFC791] [RFC1881] are therefore used to distinguish between IP and non-IP MPLS payloads. Thus,an MPLS payload with bits 0..3 = 4 is a priori an IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. To disambiguate the PW from an IP flow the PW MAY either employ the Generic PW Control Word shown in Figure 12 or an MPLS payload type identifier (see Section 5.4.4): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Specified by PW Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Generic PW Control Word Note that not all PWE3 encapsulations over MPLS use this control word format. For example, the SONET/SDH encapsulation uses a different control word format. In the general case, if the MPLS payload does not begin with a control word as illustrated in Figure 12, then the payload MUST begin with an MPLS payload type identifier. There is one exception to this requirement; if a service provider is not using ECMP, then the provider SHOULD be able to use provisioning to suppress the transmission of the MPLS payload type identifier. A particular usage of the MPLS Generic Control Word is the MPLS Preferred Control Word, shown in Figure 13: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: MPLS Preferred Control Word The meaning of the fields of the MPLS Preferred Control Word (Figure 12) is as follows: Cheers, Andy ------ At 4/10/2003 06:10 PM -0400, Mustapha Aissaoui wrote: >Andy, >I would like to keep the original Figure 12 in Stewart's text as it >covers the case of the 1:1 and PDU ATM encapsulations. If a PW >encapsulation cannot comply to the Generic PW Control Word, then it >should use the MPLS Payload Identifier, which is the option the >SONET draft authors chose to make. > >Regards, >Mustapha. >----------- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: SONET/SDH header issues and proposed resolution(long) Date: Thu, 10 Apr 2003 18:33:33 -0400 Organization: Alcatel Networks Corporaton Lines: 75 Sender: pwe3-admin@ietf.org References: <0E2DFCE7E586904DA0F583CB5EAD73CC3C5B0A@WATERTOWN.litchfieldcomm.com> <5.2.1.1.0.20030410144215.03f67638@po1.vivacenetworks.com> <5.2.1.1.0.20030410171131.04343390@po1.vivacenetworks.com> <5.2.1.1.0.20030410182053.03f50520@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Apr 11 00:41:23 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Andrew G. Malis" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy, it looks good to me. Thanks. Mustapha. ------------ "Andrew G. Malis" wrote: > > Mustapha, > > Good comment. Does this work: > > To allow accurate packet inspection in an MPLS PSN, and/or to operate > correctly over MPLS PSNs that have deployed equal-cost multiple-path > load-balancing, a PW packet MUST NOT alias an IP packet. IP packets > are carried in MPLS label stacks without any protocol identifier. > Historic values of the IP version number [RFC791] [RFC1881] are > therefore used to distinguish between IP and non-IP MPLS payloads. > Thus,an MPLS payload with bits 0..3 = 4 is a priori an > IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. > > To disambiguate the PW from an IP flow the PW MAY either employ > the Generic PW Control Word shown in Figure 12 or an MPLS payload > type identifier (see Section 5.4.4): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Specified by PW Encapsulation | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: Generic PW Control Word > > Note that not all PWE3 encapsulations over MPLS use this control word > format. > For example, the SONET/SDH encapsulation uses a different control word > format. > In the general case, if the MPLS payload does not begin with a control word > as illustrated in Figure 12, then the payload MUST begin with an MPLS > payload > type identifier. There is one exception to this requirement; if a service > provider is not using ECMP, then the provider SHOULD be able to use > provisioning to suppress the transmission of the MPLS payload type > identifier. > > A particular usage of the MPLS Generic Control Word is the MPLS Preferred > Control Word, shown in Figure 13: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Flags |FRG| Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: MPLS Preferred Control Word > > The meaning of the fields of the MPLS Preferred Control Word (Figure > 12) is as follows: > > Cheers, > Andy > > ------ > > At 4/10/2003 06:10 PM -0400, Mustapha Aissaoui wrote: > > >Andy, > >I would like to keep the original Figure 12 in Stewart's text as it > >covers the case of the 1:1 and PDU ATM encapsulations. If a PW > >encapsulation cannot comply to the Generic PW Control Word, then it > >should use the MPLS Payload Identifier, which is the option the > >SONET draft authors chose to make. > > > >Regards, > >Mustapha. > >----------- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Fri, 11 Apr 2003 07:40:43 +0100 Organization: Cisco Systems, Inc. Lines: 117 Sender: pwe3-admin@ietf.org References: <0E2DFCE7E586904DA0F583CB5EAD73CC3C5B0A@WATERTOWN.litchfieldcomm.com> <5.2.1.1.0.20030410144215.03f67638@po1.vivacenetworks.com> <5.2.1.1.0.20030410171131.04343390@po1.vivacenetworks.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" , tom_johnson@litchfieldcomm.com X-From: pwe3-admin@ietf.org Fri Apr 11 08:47:52 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "Andrew G. Malis" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy This works fine for everything except the ATM modes. Hence the generic/prefered text. Stewart Andrew G. Malis wrote: > Stewart, > > I would like to suggest some simplifications to the first part in your > text: > > To allow accurate packet inspection in an MPLS PSN, and/or to operate > correctly over MPLS PSNs that have deployed equal-cost multiple-path > load-balancing, a PW packet MUST NOT alias an IP packet. IP packets > are carried in MPLS label stacks without any protocol identifier. > Historic values of the IP version number [RFC791] [RFC1881] are > therefore used to distinguish between IP and non-IP MPLS payloads. > Thus,an MPLS payload with bits 0..3 = 4 is a priori an > IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. > > To disambiguate the PW from an IP flow the PW MAY either employ > the preferred PW control word shown in Figure 12 or an MPLS payload > type identifier (see Section 5.4.4): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Flags |FRG| Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: MPLS Preferred Control Word > > Note that not all PWE3 encapsulations over MPLS use this control word > format. > For example, the SONET/SDH encapsulation uses a different control > word format. > In the general case, if the MPLS payload does not begin with a > control word > as illustrated in Figure 12, then the payload MUST begin with an MPLS > payload > type identifier. There is one exception to this requirement; if a > service > provider is not using ECMP, then the provider SHOULD be able to use > provisioning to suppress the transmission of the MPLS payload type > identifier. > > The meaning of the fields of the MPLS Preferred Control Word (Figure > 12) is as follows: > > The rest of the text is the same. > > Thanks, > Andy > > ------- > > At 4/10/2003 09:22 PM +0100, Stewart Bryant wrote: > > >> Good News. >> >> I think that the version of the 5.4.3 and 5.4.4 that I sent to >> the list earlier today is consistent with this. If not please >> let me know. >> >> Stewart >> >> Andrew G. Malis wrote: >> >>> Stewart, >>> The co-authors have put their heads together, as it were (and it >>> wasn't all that painful, either :-) and agreed to go with option #2 >>> (the architecturally pure approach, summarized below). So that's how >>> you can write it up in the architecture spec, and we'll update the >>> SONET/SDH spec to match. >>> Cheers, >>> Andy >>> -------- >>> At 4/8/2003 02:59 PM +0100, Stewart Bryant wrote: >>> Clearly the purest approach is always to use the MPLS PID (opt 2), but >>> just as we found a way to grandfather the Martini and ITU encaps (and >>> save the four bytes), I am OK with the SONET team saving the bytes. >>> However we do have to get to ONE solution, i.e. to decide if it is more >>> important to grandfather the existing work, or save the bytes. >>> Stewart >>> ........ >>> 2. Use an MPLS payload identifier. >>> This would place George and Stewart's proposed MPLS payload identifier >>> immediately after the labels and before the RTP header: >>> +-----------------------------------+ >>> | PSN and Multiplexing Layer | >>> | Headers | >>> +----+------------------------------+ >>> |0001| protocol identifier | >>> +----+------------------------------+ >>> | RTP Header | >>> | (RFC1889) | >>> +-----------------------------------+ >>> | CEP Header | >>> +-----------------------------------+ >>> | | >>> | | >>> | SONET/SDH | >>> | Fragment | >>> | | >>> | | >>> +-----------------------------------+ >>> >> >> > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: Re: SONET/SDH header issues and proposed resolution (long) Date: Fri, 11 Apr 2003 05:42:55 -0400 Lines: 113 Sender: pwe3-admin@ietf.org References: <0E2DFCE7E586904DA0F583CB5EAD73CC3C5B0A@WATERTOWN.litchfieldcomm.com> <5.2.1.1.0.20030410144215.03f67638@po1.vivacenetworks.com> <5.2.1.1.0.20030410171131.04343390@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andrew G. Malis" , "pwe3@ietf.org" , tom_johnson@litchfieldcomm.com X-From: pwe3-admin@ietf.org Fri Apr 11 11:49:28 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: stbryant@cisco.com In-Reply-To: <3E96636B.4070807@cisco.com> X-OriginalArrivalTime: 11 Apr 2003 09:42:59.0567 (UTC) FILETIME=[BCEC97F0:01C3000E] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, Did you see my revised text after Mustapha made the same comment? Cheers, Andy --------- At 4/11/2003 07:40 AM +0100, Stewart Bryant wrote: >Andy > >This works fine for everything except the ATM modes. Hence the >generic/prefered text. > >Stewart > > > >Andrew G. Malis wrote: >>Stewart, >>I would like to suggest some simplifications to the first part in your text: >> To allow accurate packet inspection in an MPLS PSN, and/or to operate >> correctly over MPLS PSNs that have deployed equal-cost multiple-path >> load-balancing, a PW packet MUST NOT alias an IP packet. IP packets >> are carried in MPLS label stacks without any protocol identifier. >> Historic values of the IP version number [RFC791] [RFC1881] are >> therefore used to distinguish between IP and non-IP MPLS payloads. >> Thus,an MPLS payload with bits 0..3 = 4 is a priori an >> IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. >> To disambiguate the PW from an IP flow the PW MAY either employ >> the preferred PW control word shown in Figure 12 or an MPLS payload >> type identifier (see Section 5.4.4): >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 0 0| Flags |FRG| Length | Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Figure 12: MPLS Preferred Control Word >> Note that not all PWE3 encapsulations over MPLS use this control word >> format. >> For example, the SONET/SDH encapsulation uses a different control >> word format. >> In the general case, if the MPLS payload does not begin with a >> control word >> as illustrated in Figure 12, then the payload MUST begin with an MPLS >> payload >> type identifier. There is one exception to this requirement; if a >> service >> provider is not using ECMP, then the provider SHOULD be able to use >> provisioning to suppress the transmission of the MPLS payload type >> identifier. >> The meaning of the fields of the MPLS Preferred Control Word (Figure >> 12) is as follows: >>The rest of the text is the same. >>Thanks, >>Andy >>------- >>At 4/10/2003 09:22 PM +0100, Stewart Bryant wrote: >> >>>Good News. >>> >>>I think that the version of the 5.4.3 and 5.4.4 that I sent to >>>the list earlier today is consistent with this. If not please >>>let me know. >>> >>>Stewart >>> >>>Andrew G. Malis wrote: >>> >>>>Stewart, >>>>The co-authors have put their heads together, as it were (and it wasn't >>>>all that painful, either :-) and agreed to go with option #2 (the >>>>architecturally pure approach, summarized below). So that's how you >>>>can write it up in the architecture spec, and we'll update the >>>>SONET/SDH spec to match. >>>>Cheers, >>>>Andy >>>>-------- >>>>At 4/8/2003 02:59 PM +0100, Stewart Bryant wrote: >>>>Clearly the purest approach is always to use the MPLS PID (opt 2), but >>>>just as we found a way to grandfather the Martini and ITU encaps (and >>>>save the four bytes), I am OK with the SONET team saving the bytes. >>>>However we do have to get to ONE solution, i.e. to decide if it is more >>>>important to grandfather the existing work, or save the bytes. >>>>Stewart >>>>........ >>>>2. Use an MPLS payload identifier. >>>>This would place George and Stewart's proposed MPLS payload identifier >>>>immediately after the labels and before the RTP header: >>>>+-----------------------------------+ >>>>| PSN and Multiplexing Layer | >>>>| Headers | >>>>+----+------------------------------+ >>>>|0001| protocol identifier | >>>>+----+------------------------------+ >>>>| RTP Header | >>>>| (RFC1889) | >>>>+-----------------------------------+ >>>>| CEP Header | >>>>+-----------------------------------+ >>>>| | >>>>| | >>>>| SONET/SDH | >>>>| Fragment | >>>>| | >>>>| | >>>>+-----------------------------------+ >>> >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Danny McPherson Subject: Minutes from IETF 56 PWE3 Date: Sun, 13 Apr 2003 11:35:59 -0600 Lines: 253 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Sun Apr 13 19:43:10 2003 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Any final comments, I need to submit these tomorrow (4/14). -danny PWE3 @IETF56 -- San Francisco, CA March 19, 2003 Minutes Recorded by Vach Kompella No agenda bashing allowed - lack of time Progress (Danny) - security considerations needs more work - need feedback from security wg - terminology, and refs need to be cleaned up 3 week last call on new rev of pwe3 requirements Architecture (Stewart) - all feedback incorporated except - all syntax/terminology is more ietf-oriented - ref models retained from the reqmts draft - generic control word - need more flag bits - specify ttl = 2 - use pid to make a first level determination that the packet is NOT ip - propose pid=0 for pwe3 - reject control words that use 4 for the first nibble - itu-based control word violate this (stewart) - dave allan: isn't this iana issue - yaakov s: at least 2 in violation of the basic limitation != 0, 4, 6 - chris l: why assume that it is always ip? - mark t: this is for pw that requires control, or requires all pws to implement cw - mark t: can't accidentally use 4 or 6 - stewart b: can't squander the bits, so can't limit to not using 0, 4, 6 - mustafa: don't use that position (1st nibble) for anything - andy m: mpls implied that ipv4/ipv6 carried by mpls need lot more discussion - andy m: make it self-describing, not this half-baked approach - luca m: don't call pid because it is not a protocol id, but maybe a class - find out packet is ip by computing checksum, other methods (general groans from audience) - george swallow: for better or worse, mpls decided not to have protocol - need some way to find what is in there, to identify flows - various hacks out there - eric r: original encap did have pid but it was deemed unnecessary - mark t: need to have defined value that is pw - vach k: this is really version, so can use 1, 2, 3, 5 - dave mcdysan: 5 may still be in use - congestion - pwe3 may be used by end-user and so it will be - text from rtp wg - if known to carry tcp, then its own backoff mech kicks in so no need for extra work - if not, pw must provide a loss-sensitive backoff mech - done by nsp, and out of scope - long term avg for tcp throughput - issues - do we need cong ctrl - is perfect emulation more important than congestion mgmt - what to do if we detect congestion? - how to identify a traffic class to do measurements on? - run over dccp? - congestion mech like red and yellow cards - backoff or drop - need more description on the pwe3 congestion approach? - rahul a: if qos sla is broken, what to do? We haven't reached that point because we don't know what to do yet - rahul a: some measuring mechanism is required [Stewart Agrees] - steve casner: perfect emulation means that when congestion occurs, the pw is probably breaking anyway, - what about other protocols over ip? who is responsible for better behavior, pw mgmt or just regular internet behavior - sb: whatever the internet does - mustafa: how to make some AS's take action, across admin boundary. can't take unilateral action to curb traffic - how to provide enough info so that the feeder of the congestion is notified of what is causing congestion - need fault notification - mark t: hope i'm not hearing that p routers have to worry about congestion OAM reqmts (Tom Nadeau) - promised not to bore us - sp reqmts - common set of oam reqmts for mpls networks - read the draft VCCV (Tom Nadeau) - mech for pwe3 using inband diagnostic - two approaches - use a bit in the flags (although none are left) - use a pid - mustafa: can't use existing tools to test PWs. use existing tools - there are already existing approaches. - tom: using those mechs you can't tell whether a p router is broken - mustafa: if you have native oam, then you can determine pw connectivity - lsp-ping for tunnel, and native oam for pw - not needed - but what fixes the problem with vc lsp and tunnel connectivity - dave allan: use a bit to identify the packet is an inband test packet - the reply is back over the vc - tom: yes, the pw is bi-di - what identifies what comes in the test packet? read the draft - shahram: can't use lsp-ping? because of ecmp? - tom: not necessarily, want to follow the disposition path of the egress, so we want the packet to be encapped correctly - george: you can't just ping the vc lsp, you need to identify the packet as a test packet - george swallow: (off-mike) something about informal survey of ecmp hashing methods - if detected to be ip, then fish in packet header , etc. - yaakov s: pws are defined as uni-directional - george s: always send the reply in the control plane - single-sided downstream unsolicited - incorrect in draft - still need to find a way to identify the test nature of a packet - take to wg for discussion Mesg mapping (Tom Nadeau) - based on a customer oam reqmt - translation of failures in lsp-ping or vccv to atm oam or other l2 oam messages - what to do about ethernet? - mustafa: mapping of state: need to check several things - cv is pro-active - but need defect indication (e.g., mpls tunnel failure needs to be used to generate ais type messages) - look into the proper oam and mapping of defects, rather than looking at it as a mapping of messages (which sounds like interworking of the native and mpls oam) - reactive mechanisms need to be addressed - tom n: this is not the be-all end-all, look at all the tools to solve the problems, this is only part of the solution - dave a: use of withdrawal of label as failure manifestation - so need to address in data plane ATM mib (Tom Nadeau) - adds to the basic structure of the mibs for pwe3 TDM (Tim Frost filling in for tom johnson) - why another? - 2 years of deadlock, and no compromises have worked - tom put in charge of dt to address this - draft-johnson - same control word structure more or less as sonet draft - unstructured em mode: pure bitstream, normal segmentation - (see draft for details) - broad agreement on this mode from dt (debate on default size of payload) - structured em (NxDS0 w/ CAS) - similar to atm cem doc - structured em (NxDS0 w/o CAS) - based on tdm multiframe format - discussion on how to choose the arbitrary payload length - need feedback from list as to whether this draft breaks the deadlock - yaakov: unstruct mode - everyone agrees struct mode: disagreement because the optional mandatory mode is not well-defined - tim: why pick a size that fits the tdm network when we are going into a pkt network that can have - alex: how many advantages of the other drafts are preserved? - tim: succeeds in preserving structure, uses the same cas structure (atm interworking is more difficult) - alex: why not preserve draft-anavi advantage (atm interworking) - tim: because it is not possible to solve both problems - alex: but draft-anavi is for unstruct mode - danny: if you have a draft that preserves all advantages then we'd be happy, but we need a compromise - danny: bring it to the mailing list - steve (axerra): big picture - lot of activity suggesting solutions or identifying problems - what changes are in the offing? - tim: in the area of how to segment it into different payload sizes, with the tradeoff into efficiency or latency - steve: what about areas like lost packets? - tim: needs to be addressed, but probably minor (in terms of controversy) - shahram: ask list which is more important. constant delay from pe to pe regardless of the bit rate, or ease of atm interworking TDM reqmts (Max Riegel) - init draft covered t1, e1, t3, e3 - needed to cover sdh/sonet - rest from the slides - revised edition out beginning of may, continue discussion on list TDMOIP-LE (Yaakov Stein) - loop emulation for congestion control - form id does not conflict with pid - aal2 is variable bit rate so allows more nsp processing (e.g., vad, compression, etc.) - tcp is 1st class citizen, and tdm is dropped with congestion (which is contrary to service provider needs) - if pw traffic is small, and not all of it is tdm. so for statistical peak situation by dropping packets and conceal with nsp techniques - to deal with congestion avoidance - we must have vbr mode - cw must have length field - form id is needed (since we can't change modes in control plane) TDM Structured Em (Sasha - who subbed for him?) - mostly stuff right from the slides - main concept: nsp function allows for less perfect structure - see convergence on tdm in the offing - Why there has been difficulty in obtaining consensus for TDM work, and how to resolve it? - Good news - - consensus on emulation of unstructured TDM (E1,T1,E3,T3) is close - Bad news - situation with structured tDM, because different people mean different things - clear WG position on scope, reqts and arch lacking for structured TDM. - Tried to clarify what structured TDM means and why we care about it. - Bandwidth saving on psn by skipping unused channels - efficiency - resilience of attachment circuit and specific applications to packet loss - application-specific BW mgmt - Piece of wire vs. Distributed DXC approaches. - Conclusion - optimistic for consensus on different approaches. MPLS FORUM liaison (Andy Malis) - current draft for tdm is ready - please read and comment PWE3 control and maintenance changes (Luca) - changes include - refs - single sided mode - atm modes - numeric allocations to separate iana draft atm-encap - n-to-1 cell mode default - need some defs in 1-to-1 mode - may conflict with the arch doc ethernet-encap - tagged option needs reworking: move to nsp function - resolve and move to wg last call danny: need to resolve other docs before ethernet encap moves forward even though it is ready - rahul a: don't understand need to change. the tagged mode supports tagged mode and the spec should be left unchanged. - rahul a: there are existing implementations and some deployment around the tagged mode. - luca m: tagged mode is needed to overcome limitations of ip routers - ali s: both modes are useful - luca m: send comments to mailing list AAL1 transport (Shahram) - does not introduce new protocol - suggest move to informational wg - andy m: third suggestion - don't use pdu mode - also, l&r bits handling is not just informational, adds protocol changes so draft can't be info - yaakov s: support the draft, need atm encap draft changes L2TPV3 (Mark Townsley) - draft is in hands of iesg - companion drafts are in last call - will post to the list on the status David Allan - y1711 and lsp-ping are complementary - for pwe3: easy to do oam interworking with y1711 - with oam in dp, will prevent overloading control plane and label removal - danny: send points to mailing list Danny: work on documents between meetings, and not just near the IETFs From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Ali Sajassi Subject: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Sun, 13 Apr 2003 20:06:47 -0700 Lines: 53 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ali Sajassi X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon Apr 14 05:07:25 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: ppvpn@nortelnetworks.com, pwe3@ietf.org X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] Status: O There are several issues with this draft which I would like to be addressed first before being considered as WG document. I am copying PWE3 here as well because one of the issue is pertinent to them. 1) PW Signaling: The draft suggests using BGP as signaling mechanism for Point-to-Point PWs of type Ethernet. The encapsulation and setup of PtP Ethernet PWs are already covered in the PWE3 and LDP-based signaling is the recommended signaling mechanism for PtP PWs in MPLS network. I don't see any benefits of introducing yet another signaling mechanism for this propose; however, the drawback of it are: i) intertwining signaling mechanism w/ auto-discovery restricts the service provider to using BGP auto-discovery only - e.g. if a SP wants to use non-BGP auto-discovery mechanism (such as directory-based radius), then BGP signaling is useless. However LDP-based signaling based on PWE3 draft (draft-ietf-pwe3-control-protocol-02.txt) is independent from auto-discovery mechanism and both BGP and non-BGP auto-discovery can be used by it. ii) inter-operability issues: having two different signaling mechanism for the same PW type and network type (e.g., EoMPLS PW), would necessitate the need for interworking (either at the control plane or at the date plane). This is an unnecessary complication which is not needed. If the interworking is done at the signaling level, it is tedious and unprecedented. And if it is done at the data-plane level, then it creates unnecessary scalability issues for the ASBRs. iii) it limits all the PWs in a VPLS set to have the same characteristics. 2) MAC address flush: This mechanism is inconsistent with 802.1D and the new proposals for 802.1ad. The PE should NOT signal MAC address withdrawal upon link failure but instead it should signal it upon link activation (in case of multiple redundant links). The reason for this is to avoid unnecessary flooding of customer packets when a link failure happens without having redundant links. 3) Customer's BPDUs There is no description of how customers BPDUs are tunneled and in case of back-door connection by customer, how these BPDUs are handled by the SP. These is important in order for the customer's network to operate properly. Among these three issues, the PW signaling for MPLS is the bigger issue and I would like it to be addressed first in the PWE3 before reinventing it in a different form for PPVPN. -Ali From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Yakov Rekhter Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 06:55:48 -0700 Lines: 68 References: <4.3.2.7.2.20030413145204.01bc6ec8@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon Apr 14 15:56:27 2003 Return-path: To: Ali Sajassi In-Reply-To: Your message of "Sun, 13 Apr 2003 20:06:47 PDT." <4.3.2.7.2.20030413145204.01bc6ec8@airborne.cisco.com> Content-ID: <97155.1050328548.1@juniper.net> X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] Status: O Ali, > There are several issues with this draft which I would like to be addressed > first before being considered as WG document. I am copying PWE3 here as > well because one of the issue is pertinent to them. > > 1) PW Signaling: > The draft suggests using BGP as signaling mechanism for Point-to-Point PWs > of type Ethernet. The encapsulation and setup of PtP Ethernet PWs are > already covered in the PWE3 and LDP-based signaling is the recommended > signaling mechanism for PtP PWs in MPLS network. I don't see any benefits > of introducing yet another signaling mechanism for this propose; however, > the drawback of it are: You didn't mention one important point. Namely, that the draft uses BGP for auto-discovery, and piggybacks label information (signaling) on top of auto-discovery. So, instead of one protocol for signaling (LDP), and another for auto-discovery (BGP) the draft accomplishes both with a single protocol. So, why two protocols (LDP + BGP) is any better than one (BGP) ? In addition, using BGP for both auto-discovery and signaling, instead of using BGP for auto-discovery and LDP for signaling, simplifies inter-provider operations, fits into a common framework for both L2 and 2547 VPNs, etc.... Furthermore, perhaps rereading recently posted e-mails from from several service providers who support draft-kompella-ppvpn-vpls-01.txt may also help you to understand the benefits of the approach described in draft-kompella-ppvpn-vpls-01.txt. > i) intertwining signaling mechanism w/ auto-discovery restricts the service > provider to using BGP auto-discovery only - e.g. if a SP wants to use > non-BGP auto-discovery mechanism (such as directory-based radius), then BGP > signaling is useless. That is correct. But paraphrasing you one could also say that if a SP wants to use a non-MPLS signaling mechanism, then LDP signaling, as described in draft-lasserre-vkompella-ppvpn-vpls-04.txt, is useless. > However LDP-based signaling based on PWE3 draft > (draft-ietf-pwe3-control-protocol-02.txt) is independent from > auto-discovery mechanism and both BGP and non-BGP auto-discovery can be > used by it. > > ii) inter-operability issues: having two different signaling mechanism for > the same PW type and network type (e.g., EoMPLS PW), would necessitate the > need for interworking (either at the control plane or at the date plane). > This is an unnecessary complication which is not needed. If the > interworking is done at the signaling level, it is tedious and > unprecedented. And if it is done at the data-plane level, then it creates > unnecessary scalability issues for the ASBRs. I am really glad you brought up the inter-operability issue, as draft-lasserre-vkompella-ppvpn-vpls-04.txt does not prescribe any auto-discovery mechanism, while listing "three potential candidates, [BGP-DISC], [DNS-DISC], [LDP-DISC]." Perhaps you could explain to the rest of us how inter-operability could be accomplished in this case (e.g., one vendor implements BGP auto-discovery, and another vendor implements Radius-based auto-discovery). > iii) it limits all the PWs in a VPLS set to have the same characteristics. And why exactly this is a problem of *practical* significance in the context of VPLS ? Yakov. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: Fwd: Re: SONET/SDH header issues and proposed resolution (long) Date: Mon, 14 Apr 2003 10:45:11 -0400 Lines: 107 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 14 17:03:47 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Stewart Bryant X-OriginalArrivalTime: 14 Apr 2003 14:45:41.0915 (UTC) FILETIME=[85C436B0:01C30294] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, Are you all set on the enclosed text? Thanks, Andy ------- Begin of Forwarded Message ------- X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 10 Apr 2003 18:25:35 -0400 To: Mustapha Aissaoui From: "Andrew G. Malis" Subject: Re: [PWE3] SONET/SDH header issues and proposed resolution (long) Cc: "Andrew G. Malis" , stbryant@cisco.com, "pwe3@ietf.org" X-OriginalArrivalTime: 10 Apr 2003 22:25:41.0208 (UTC) FILETIME=[1E931D80:01C2FFB0] Sender: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Mustapha, Good comment. Does this work: To allow accurate packet inspection in an MPLS PSN, and/or to operate correctly over MPLS PSNs that have deployed equal-cost multiple-path load-balancing, a PW packet MUST NOT alias an IP packet. IP packets are carried in MPLS label stacks without any protocol identifier. Historic values of the IP version number [RFC791] [RFC1881] are therefore used to distinguish between IP and non-IP MPLS payloads. Thus,an MPLS payload with bits 0..3 = 4 is a priori an IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. To disambiguate the PW from an IP flow the PW MAY either employ the Generic PW Control Word shown in Figure 12 or an MPLS payload type identifier (see Section 5.4.4): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Specified by PW Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Generic PW Control Word Note that not all PWE3 encapsulations over MPLS use this control word format. For example, the SONET/SDH encapsulation uses a different control word format. In the general case, if the MPLS payload does not begin with a control word as illustrated in Figure 12, then the payload MUST begin with an MPLS payload type identifier. There is one exception to this requirement; if a service provider is not using ECMP, then the provider SHOULD be able to use provisioning to suppress the transmission of the MPLS payload type identifier. A particular usage of the MPLS Generic Control Word is the MPLS Preferred Control Word, shown in Figure 13: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: MPLS Preferred Control Word The meaning of the fields of the MPLS Preferred Control Word (Figure 12) is as follows: Cheers, Andy ------ At 4/10/2003 06:10 PM -0400, Mustapha Aissaoui wrote: >Andy, >I would like to keep the original Figure 12 in Stewart's text as it >covers the case of the 1:1 and PDU ATM encapsulations. If a PW >encapsulation cannot comply to the Generic PW Control Word, then it >should use the MPLS Payload Identifier, which is the option the >SONET draft authors chose to make. > >Regards, >Mustapha. >----------- _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------- End of Forwarded Message ------- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Alik Shimelmits Subject: RE: Minutes from IETF 56 PWE3 Date: Mon, 14 Apr 2003 18:52:50 +0200 Lines: 12 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Mon Apr 14 18:03:43 2003 Return-path: To: "'danny@tcb.net'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O ...snipped > MPLS FORUM liaison (Andy Malis) > > - current draft for tdm is ready - the agreement name (and actual content) is "tdm emulation over MPLS using AAL1" > - please read and comment Alik From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Ali Sajassi Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 09:56:33 -0700 Lines: 122 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon Apr 14 18:57:01 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Yakov Rekhter , Ali Sajassi In-Reply-To: <200304141355.h3EDtmu59315@merlot.juniper.net> X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] Status: O Yakov, Please see the reply inline ... At 06:55 AM 4/14/2003 -0700, Yakov Rekhter wrote: >Ali, > > > There are several issues with this draft which I would like to be > addressed > > first before being considered as WG document. I am copying PWE3 here as > > well because one of the issue is pertinent to them. > > > > 1) PW Signaling: > > The draft suggests using BGP as signaling mechanism for Point-to-Point PWs > > of type Ethernet. The encapsulation and setup of PtP Ethernet PWs are > > already covered in the PWE3 and LDP-based signaling is the recommended > > signaling mechanism for PtP PWs in MPLS network. I don't see any benefits > > of introducing yet another signaling mechanism for this propose; however, > > the drawback of it are: > >You didn't mention one important point. Namely, that the draft uses >BGP for auto-discovery, and piggybacks label information (signaling) >on top of auto-discovery. So, instead of one protocol for signaling >(LDP), and another for auto-discovery (BGP) the draft accomplishes >both with a single protocol. So, why two protocols (LDP + BGP) is >any better than one (BGP) ? In addition, using BGP for both >auto-discovery and signaling, instead of using BGP for auto-discovery >and LDP for signaling, simplifies inter-provider operations, fits >into a common framework for both L2 and 2547 VPNs, etc.... Yes, with tightly coupling (intertwining) auto-discovery with signaling, you can use one protocol for both at the expense of overloading that protocol even more. However, that is not my point. My point is we already have a singling mechanism for PtP PW as prescribed in PWE3 which is more flexible and more appropriate for PtP PWs and why do we need yet another one which doesn't offer any clear benefit and that signaling would only be applicable to BGP auto-discovery and doesn't work w/ any other types of auto-discovery. With respect to 2547 VPN, at the surface it may look that both are similar but looking at it in more details, we see that 2547 uses MPtP PWs; whereas VPLS does not (it uses PtP). So we are talking about apple and oranges although it may look like apples at first :-) >Furthermore, perhaps rereading recently posted e-mails from from >several service providers who support draft-kompella-ppvpn-vpls-01.txt >may also help you to understand the benefits of the approach >described in draft-kompella-ppvpn-vpls-01.txt. There might be some support because lumping the signaling and auto-discovery together may result in quicker implementation but I would question the long term viability of it. I would also be interested in knowing how many other vendors are planning to support this draft because that is another factor for SPs to consider. > > i) intertwining signaling mechanism w/ auto-discovery restricts the > service > > provider to using BGP auto-discovery only - e.g. if a SP wants to use > > non-BGP auto-discovery mechanism (such as directory-based radius), then > BGP > > signaling is useless. > >That is correct. But paraphrasing you one could also say that >if a SP wants to use a non-MPLS signaling mechanism, then LDP signaling, >as described in draft-lasserre-vkompella-ppvpn-vpls-04.txt, is useless. That is not a good analogy. MPLS and IP are two different technologies; however, within the same MPLS technology having two different ways of doing the same thing is at best redundant and at worst useless. > > > However LDP-based signaling based on PWE3 draft > > (draft-ietf-pwe3-control-protocol-02.txt) is independent from > > auto-discovery mechanism and both BGP and non-BGP auto-discovery can be > > used by it. > > > > ii) inter-operability issues: having two different signaling mechanism for > > the same PW type and network type (e.g., EoMPLS PW), would necessitate the > > need for interworking (either at the control plane or at the date plane). > > This is an unnecessary complication which is not needed. If the > > interworking is done at the signaling level, it is tedious and > > unprecedented. And if it is done at the data-plane level, then it creates > > unnecessary scalability issues for the ASBRs. > >I am really glad you brought up the inter-operability issue, as >draft-lasserre-vkompella-ppvpn-vpls-04.txt does not prescribe any >auto-discovery mechanism, while listing "three potential candidates, >[BGP-DISC], [DNS-DISC], [LDP-DISC]." Perhaps you could explain to >the rest of us how inter-operability could be accomplished in this case >(e.g., one vendor implements BGP auto-discovery, and another vendor >implements Radius-based auto-discovery). Decoupling signaling and auto-discovery helps in this case since as long as the PEs have the endpoints identifiers, tunnels and PWs can be established using the same signaling mechanism. The endpoints ID can be a) configured manually or b) configured into the auto-discovery mechanism (e.g., into the DNS/Radius records). > > iii) it limits all the PWs in a VPLS set to have the same characteristics. > >And why exactly this is a problem of *practical* significance in >the context of VPLS ? in case you need different SLAs for different PWs - e.g., PWs between different sites have different QoS requirements. Again I would like to reiterate that if we are introducing a new signaling for the same PW type, it should first get approved by PWE3 (since their charter covers maintenance/setup of PWs). -Ali >Yakov. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Hamid Ould-Brahim" Subject: RE: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 13:37:43 -0400 Lines: 105 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C302AC.8DAEA7D0" Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 14 19:46:05 2003 Return-path: To: Ali Sajassi , Yakov Rekhter X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C302AC.8DAEA7D0 Content-Type: text/plain; charset="iso-8859-1" Ali, [clipped...] > > That is not a good analogy. MPLS and IP are two different > technologies; > however, within the same MPLS technology having two different > ways of doing > the same thing is at best redundant and at worst useless. > Maybe a good analogy (within the same MPLS technology) is to look at the existence of multiple ways of distributing MPLS label that includes the use of BGP (and even RFC3031 captured that: "THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL. In fact, a number of different label distribution protocols are being standardized. Existing protocols have been extended so that label distribution can be piggybacked on them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New protocols have also been defined for the explicit purpose of distributing labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP]."). Although one may conclude that having multiple ways of distributing labels can be redundant, I don't think it was useless (since later on such approach - of using BGP - was useful in rfc2547). Hamid. ------_=_NextPart_001_01C302AC.8DAEA7D0 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt

Ali,

[clipped...]

>
> That is not a good analogy. MPLS and IP are two different
> technologies;
> however, within the same MPLS technology having two different
> ways of doing
> the same thing is at best redundant and at worst useless.
>

Maybe a good analogy (within the same MPLS technology)
is to look at the existence of multiple ways of distributing
MPLS label that includes the use of BGP (and even RFC3031
captured that:

"THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL
   DISTRIBUTION PROTOCOL.  In fact, a number of different label
   distribution protocols are being standardized.  Existing protocols
   have been extended so that label distribution can be piggybacked on
   them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]).  New protocols
   have also been defined for the explicit purpose of distributing
   labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].").

Although one may conclude that having multiple ways of
distributing labels can be redundant, I don't think it was useless
(since later on such approach - of using BGP - was useful
in rfc2547).

Hamid.






------_=_NextPart_001_01C302AC.8DAEA7D0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Kireeti Kompella Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 10:48:12 -0700 (PDT) Lines: 73 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20030414085848.01bce2f0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Yakov Rekhter , "" , "" X-From: pwe3-admin@ietf.org Mon Apr 14 19:56:33 2003 Return-path: X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs To: Ali Sajassi In-Reply-To: <4.3.2.7.2.20030414085848.01bce2f0@airborne.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Ali, On Mon, 14 Apr 2003, Ali Sajassi wrote: > Yes, with tightly coupling (intertwining) auto-discovery with signaling, > you can use one protocol for both at the expense of overloading that > protocol even more. If you use BGP for auto-discovery, adding signaling information is a minor addition with major benefits: o a single advertisement accomplishes both auto-discovery and signaling; o there is no inter-protocol dependency, and attendant complexity of both code and deployment/debugging/...; o one gets a complete solution, instead of promises to add enough to LDP/radius/... to complete that solution. If the issue is "overloading BGP", it is clear that 2547 overloads BGP far more significantly. And implementations have proven that BGP is nonetheless perfectly happy; deployments have shown that this "overloading" has not resulted in any practical problems. The fact that people who bring up this "overloading" argument forget is that in the end, all relevant information must be communicated. The "overloading" of the PE in doing so does *not* decrease if you use BGP+LDP (or radius+LDP or whatever) -- it only increases. If you compare the protocol state, the use of memory/CPU, the inter-protocol interactions, etc. -- if you use any measurable criteria for the complexity of a solution, on all these measures, the solution proposed in draft-kompella-ppvpn-vpls is clearly superior. > However, that is not my point. My point is we already > have a singling mechanism for PtP PW as prescribed in PWE3 which is more > flexible and more appropriate for PtP PWs and why do we need yet another > one which doesn't offer any clear benefit and that signaling would only be > applicable to BGP auto-discovery and doesn't work w/ any other types of > auto-discovery. First of all, there are several clear benefits. Just ask the Service Providers who responded. Second, a proposal that only shows how to do signaling is clearly inferior -- so to turn your argument around, one might suggest that the PWE3 work be scrapped in favor of a complete solution :-) I have no desire to suggest this, but your argument doesn't hold water. > With respect to 2547 VPN, at the surface it may look that both are similar > but looking at it in more details, we see that 2547 uses MPtP PWs; whereas > VPLS does not (it uses PtP). So we are talking about apple and oranges > although it may look like apples at first :-) Instead of playing semantic games. if you look at the service offered, you see strong parallels -- any-to-any connectivity, learned forwarding (as opposed to static mapping in the case of PWs). And there are strong parallels in how a BGP-based VPLS service and a BGP-based IP VPN service are deployed. > There might be some support because lumping the signaling and > auto-discovery together may result in quicker implementation but I would > question the long term viability of it. I would also be interested in > knowing how many other vendors are planning to support this draft because > that is another factor for SPs to consider. "Lumping the signaling and auto-discovery together" actually results in a more coordinated implementation, not a quicker one. And instead of imputing reasons why SPs may like this, just read their emails and see what they say. Finally, to address your issues in your first email, we are not asking that this doc be made an RFC -- just that it be made a WG doc. As Alex said: "For a document to become a WG draft, it doesn't have to be 100% correct." Kireeti. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 14:05:53 -0400 Lines: 19 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Ali Sajassi , Yakov Rekhter , ppvpn@nortelnetworks.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 14 20:11:53 2003 Return-path: To: "Hamid Ould-Brahim" In-reply-to: Your message of Mon, 14 Apr 2003 13:37:43 -0400. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hamid> Maybe a good analogy (within the same MPLS technology) is to look at Hamid> the existence of multiple ways of distributing MPLS label Hamid> Although one may conclude that having multiple ways of distributing Hamid> labels can be redundant, I don't think it was useless (since later on Hamid> such approach - of using BGP - was useful in rfc2547). Generally, we use LDP to distribute labels that correspond to IGP routes, and we use BGP to distribute labels that correspond to BGP routes. I guess you could call this "multiple ways of distributing labels", but I think a better thing to call it would be "distribute the label in the way which is most suited to its application". For a given application, an example of multiple ways to distribute labels would be RSVP-TE and CR-LDP. Did we need both ways? Apparently not. The argument that CR-LDP is better because LDP + CR-LDP = one protocol,while LDP + RSVP-TE is two protocols, now just seems quaint. Unfortunately, bad arguments tend to recur over and over again ;-) From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Yakov Rekhter Subject: Re: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 11:19:27 -0700 Lines: 40 Sender: pwe3-admin@ietf.org References: <200304141805.h3EI5sB0029591@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "Hamid Ould-Brahim" , Ali Sajassi , ppvpn@nortelnetworks.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 14 20:25:27 2003 Return-path: To: erosen@cisco.com In-Reply-To: Your message of "Mon, 14 Apr 2003 14:05:53 EDT." <200304141805.h3EI5sB0029591@rtp-core-1.cisco.com> Content-ID: <48057.1050344367.1@juniper.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eric, > Hamid> Maybe a good analogy (within the same MPLS technology) is to look at > Hamid> the existence of multiple ways of distributing MPLS label > > Hamid> Although one may conclude that having multiple ways of distributing > Hamid> labels can be redundant, I don't think it was useless (since later on > Hamid> such approach - of using BGP - was useful in rfc2547). > > Generally, we use LDP to distribute labels that correspond to IGP routes, > and we use BGP to distribute labels that correspond to BGP routes. I guess > you could call this "multiple ways of distributing labels", but I think a > better thing to call it would be "distribute the label in the way which is > most suited to its application". We use BGP to distribute labels that correspond to the information (e.g., routes) carried in BGP. We use RSVP to distribute labels that correspond to the information carried in RSVP. We use LDP when piggybacking is not possible. And if you insist that LDP is used to distribute labels that correspond to IGP routes, then LDP should not be used to carry label information across AS boundaries - this should be done with BGP. > For a given application, an example of multiple ways to distribute labels > would be RSVP-TE and CR-LDP. Did we need both ways? Apparently not. The > argument that CR-LDP is better because LDP + CR-LDP = one protocol,while > LDP + RSVP-TE is two protocols, now just seems quaint. This is a rather poor analogy, as in the context of VPLS we are talking not just about multiple ways of distributing labels, but whether one always have to have one protocol for distributing labels, and another for auto-discovery, or one protocol for both would be enough. > Unfortunately, bad arguments tend to recur over and over again ;-) On that I agree with you - we just disagree on what are these bad arguments :-) Yakov. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Ali Sajassi Subject: RE: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 11:33:42 -0700 Lines: 125 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_90429711==_.ALT" Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 14 20:39:13 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Hamid Ould-Brahim" , Ali Sajassi , Yakov Rekhter In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --=====================_90429711==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hamid, In case of RFC2547 that you are giving as an example of using BGP for delivery of MPLS label, it was done for a different PW type. RFC 2547 uses multipoint signaling mechanism for the setup of MPtP PW; whereas, for VPLS we are talking about using a multipoint signaling to setup PtP PW which frankly doesn't make sense to me. Also, we shouldn't use the argument that if in the past we have developed multiple standards for doing the same thing, we should keep doing it in the future. -Ali At 01:37 PM 4/14/2003 -0400, Hamid Ould-Brahim wrote: >Ali, > >[clipped...] > > > > > That is not a good analogy. MPLS and IP are two different > > technologies; > > however, within the same MPLS technology having two different > > ways of doing > > the same thing is at best redundant and at worst useless. > > > >Maybe a good analogy (within the same MPLS technology) >is to look at the existence of multiple ways of distributing >MPLS label that includes the use of BGP (and even RFC3031 >captured that: > >"THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL > DISTRIBUTION PROTOCOL. In fact, a number of different label > distribution protocols are being standardized. Existing protocols > have been extended so that label distribution can be piggybacked on > them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New protocols > have also been defined for the explicit purpose of distributing > labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP]."). > >Although one may conclude that having multiple ways of >distributing labels can be redundant, I don't think it was useless >(since later on such approach - of using BGP - was useful >in rfc2547). > >Hamid. > > > > --=====================_90429711==_.ALT Content-Type: text/html; charset="us-ascii" Hamid,

In case of RFC2547 that you are giving as an example of using BGP for delivery of MPLS label, it was done for a different PW type. RFC 2547 uses multipoint signaling mechanism for the setup of MPtP PW; whereas, for VPLS we are talking about using a multipoint signaling to setup PtP PW which frankly doesn't make sense to me. Also, we shouldn't use the argument that if in the past we have developed multiple standards for doing the same thing, we should keep doing it in the future.

-Ali

At 01:37 PM 4/14/2003 -0400, Hamid Ould-Brahim wrote:

Ali,

[clipped...]

>
> That is not a good analogy. MPLS and IP are two different
> technologies;
> however, within the same MPLS technology having two different
> ways of doing
> the same thing is at best redundant and at worst useless.
>

Maybe a good analogy (within the same MPLS technology)
is to look at the existence of multiple ways of distributing
MPLS label that includes the use of BGP (and even RFC3031
captured that:

"THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL
   DISTRIBUTION PROTOCOL.  In fact, a number of different label
   distribution protocols are being standardized.  Existing protocols
   have been extended so that label distribution can be piggybacked on
   them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]).  New protocols
   have also been defined for the explicit purpose of distributing
   labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].").

Although one may conclude that having multiple ways of
distributing labels can be redundant, I don't think it was useless
(since later on such approach - of using BGP - was useful
in rfc2547).

Hamid.




--=====================_90429711==_.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 14:58:35 -0400 Lines: 100 Sender: pwe3-admin@ietf.org References: <20030414100850.X40151@kummer.juniper.net> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Ali Sajassi , Yakov Rekhter , "" , "" X-From: pwe3-admin@ietf.org Mon Apr 14 21:05:23 2003 Return-path: To: Kireeti Kompella In-reply-to: Your message of Mon, 14 Apr 2003 10:48:12 -0700. <20030414100850.X40151@kummer.juniper.net> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Kireeti> If you use BGP for auto-discovery, adding signaling information is Kireeti> a minor addition Yeah, that's what people used to say about adding traffic engineering to LDP ;-) When I look at the PWE3 signaling docs, I see that the signaling involves quite a bit more than just sending a label. I think you need to look at everything which can be signaled in PWE3 and say how you would handle it in BGP, or else say why it is not needed. I also think that VPLS signaling needs to be general enough to handle certain mix and match cases, such as connecting a p2p pseudowire into an emulated LAN. I can see how this can be done with PWE3 signaling, but I'm not sure I see how the BGP-based signaling could handle it. Kireeti> there is no inter-protocol dependency If you are planning to use BGP to set up the PE-PE tunnels as well as the pseudowires, I haven't seen the proposal for that. Otherwise, there's no avoiding inter-protocol dependencies. In any event, auto-discovery and signaling are well-layered from each other, and do not introduce any sort of ugly dependencies. Kireeti> If the issue is "overloading BGP", it is clear that 2547 overloads Kireeti> BGP far more significantly. I don't believe in the "overloading BGP" argument myself, though it is clear that that argument has many adherents. To my mind, the issue is really whether BGP is a good protocol for the kind of signaling that needs to be done. Sure, "with enough thrust, even pigs can fly". In 2547, we chose to use BGP not because it was there, but because it is a good protocol for distributing a large amount of routing information that originates from other routing domains. I like BGP for auto-discovery because in auto-discovery, we want a protocol that provides a point-to-multipoint capability and allows an originator to update and withdraw information at will; BGP as a protocol seems like a good match. Is it a good match for point-to-point signaling? That's a lot more of a stretch. Kireeti> if you use any measurable criteria for the complexity of a Kireeti> solution, on all these measures, Well, that's the claim. Let's see, suppose you need to resynchronize the sequence numbers on a particular PE-PE pseudowire. How efficient is BGP at doing that? Suppose there is some problem in getting data from one PE to another? Does the fact that the control plane goes through a third party (route reflector) make it easier to troubleshoot that problem, or more difficult? Kireeti> First of all, there are several clear benefits. Just ask the Kireeti> Service Providers who responded. You're referring to the benefit of "elegance"? Kireeti> Finally, to address your issues in your first email, we are not Kireeti> asking that this doc be made an RFC -- just that it be made a WG Kireeti> doc. As Alex said: "For a document to become a WG draft, it Kireeti> doesn't have to be 100% correct." Adopting your document as a WG doc would be an expression by the WG of support for using BGP as a way to do p2p signaling. The WG should be very sure that it wants to do that before adopting your doc. Kireeti> if you look at the service offered, you see strong parallels -- Kireeti> any-to-any connectivity, learned forwarding If you compare bridging to routing, you'll see the very same parallels, yet the technologies are very different, have very different applicabilities, and require very different solutions. Kireeti> a proposal that only shows how to do signaling is clearly inferior Certainly what is needed is a complete solution, rather than just a piece. However, when the solution contains multiple identifiable components, proper layering generally results in more long term simplicity and flexibility. If the proposal is to use BGP for signaling pseudowires, I think the technical discussion should focus on its suitability for that purpose. Yakov> in the context of VPLS we are talking not just about multiple ways of Yakov> distributing labels, but whether one always have to have one protocol Yakov> for distributing labels, and another for auto-discovery, or one Yakov> protocol for both would be enough. Well, I don't really see how this is different than the "CR-LDP isn't another protocol" argument. The arguments are being repeated almost word for word, albeit not by the same set of people ;-) You seem to be arguing that "given a protocol to do X, if we need to do Y, it is better to piggyback Y on the X-protocol than to use a protocol that is designed to do Y." In general, this argument form is not valid, it really is a matter of how suitable the X protocol is for Y. Yakov> The fact that the two drafts [kompella and lasserre/vkompella] share Yakov> the same data plane is a feature, not a bug. Of course, I never said otherwise. But the specification of that data plane should not be in both places, one doc should reference the other. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Yakov Rekhter Subject: Re: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 12:08:53 -0700 Lines: 33 Sender: pwe3-admin@ietf.org References: <200304141858.h3EIwaB0015936@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Kireeti Kompella , Ali Sajassi , Yakov Rekhter , "" , "" X-From: pwe3-admin@ietf.org Mon Apr 14 21:14:19 2003 Return-path: To: erosen@cisco.com In-Reply-To: Your message of "Mon, 14 Apr 2003 14:58:35 EDT." <200304141858.h3EIwaB0015936@rtp-core-1.cisco.com> Content-ID: <67093.1050347333.1@juniper.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eric, [clipped...] > Yakov> in the context of VPLS we are talking not just about multiple ways of > Yakov> distributing labels, but whether one always have to have one protocol > Yakov> for distributing labels, and another for auto-discovery, or one > Yakov> protocol for both would be enough. > > Well, I don't really see how this is different than the "CR-LDP isn't > another protocol" argument. The arguments are being repeated almost word > for word, albeit not by the same set of people ;-) > > You seem to be arguing that "given a protocol to do X, if we need to do Y, > it is better to piggyback Y on the X-protocol than to use a protocol that is > designed to do Y. In general, this argument form is not valid, it really > is a matter of how suitable the X protocol is for Y. Agreed. I guess all we arguing about is whether in the case where BGP is used for auto-discovery BGP is also suitable for distributing labels (note we are *not* arguing on suitability of BGP for distributing labels when some other than BGP mechanism is used for auto-discovery). > Yakov> The fact that the two drafts [kompella and lasserre/vkompella] share > Yakov> the same data plane is a feature, not a bug. > > Of course, I never said otherwise. But the specification of that data plane > should not be in both places, one doc should reference the other. That would be fine with me. Or the data plane could be pulled into a separate document... Yakov. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Ali Sajassi Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 13:13:04 -0700 Lines: 136 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20030414085848.01bce2f0@airborne.cisco.com> <4.3.2.7.2.20030414085848.01bce2f0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Yakov Rekhter , "" , "" X-From: pwe3-admin@ietf.org Mon Apr 14 22:18:28 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Kireeti Kompella , Ali Sajassi In-Reply-To: <20030414100850.X40151@kummer.juniper.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Kireeti, Please refer to my comments inline ... At 10:48 AM 4/14/2003 -0700, Kireeti Kompella wrote: >Hi Ali, > >On Mon, 14 Apr 2003, Ali Sajassi wrote: > > > Yes, with tightly coupling (intertwining) auto-discovery with signaling, > > you can use one protocol for both at the expense of overloading that > > protocol even more. > >If you use BGP for auto-discovery, adding signaling information is a minor >addition with major benefits: > o a single advertisement accomplishes both auto-discovery and signaling; > o there is no inter-protocol dependency, and attendant complexity of > both code and deployment/debugging/...; > o one gets a complete solution, instead of promises to add enough to > LDP/radius/... to complete that solution. Although BGP is a very legitimate approach for auto-discovery and a proven way for doing MPtP PW signaling, I don't see any benefits for VPLS type application where it requires signaling for PtP PWs. One can use BGP auto-discovery with existing LDP signaling (per PWE3) and get all the benefits plus more (more in the sense of having the flexibility to use different SLAs and QoS for different PWs. Also having the flexibility to offer different auto-discovery mechanism to the SPs. >If the issue is "overloading BGP", it is clear that 2547 overloads BGP >far more significantly. And implementations have proven that BGP is >nonetheless perfectly happy; deployments have shown that this >"overloading" has not resulted in any practical problems. When I talked about overloading BGP, I was referring to overloading it more than we have to. 2547 is a different application with different requirements and it makes sense to use multipoint signaling for multipoint PWs but for VPLS application, the PW is of type PtP and the associated signaling as described in PWE3 works well for this type of PW. So using BGP as auto-discovery, doesn't mean overloading it for signaling as well. >The fact that people who bring up this "overloading" argument forget is >that in the end, all relevant information must be communicated. The >"overloading" of the PE in doing so does *not* decrease if you use >BGP+LDP (or radius+LDP or whatever) -- it only increases. If you >compare the protocol state, the use of memory/CPU, the inter-protocol >interactions, etc. -- if you use any measurable criteria for the >complexity of a solution, on all these measures, the solution proposed >in draft-kompella-ppvpn-vpls is clearly superior. I didn't talk about overloading the PE but instead about the protocol more than we have to. If we don't use route reflector, then BGP has even higher overhead than LDP for PtP signaling. And even with route reflector, there is a trade off between number of connections versus number of messages need to be processed between BGP and LDP signaling - so BGP has higher overhead in terms of packet processing than LDP !! Also what you're going to do for the SP who don't want to use BGP auto-discovery (e.g., they prefer directory-based) ? Are you going to force them to use BGP ? > > However, that is not my point. My point is we already > > have a singling mechanism for PtP PW as prescribed in PWE3 which is more > > flexible and more appropriate for PtP PWs and why do we need yet another > > one which doesn't offer any clear benefit and that signaling would only be > > applicable to BGP auto-discovery and doesn't work w/ any other types of > > auto-discovery. > >First of all, there are several clear benefits. Just ask the Service >Providers who responded. I would like to ask those service providers to explain the benefits of using BGP for PtP signaling in VPLS applications instead of LDP as recommended in PWE3 ? Again I am not talking about BGP usage for auto-discovery as it can serve well for auto-discovery. >Second, a proposal that only shows how to do signaling is clearly >inferior -- so to turn your argument around, one might suggest that >the PWE3 work be scrapped in favor of a complete solution :-) I have >no desire to suggest this, but your argument doesn't hold water. There is a difference between a draft containing all the pieces of a solution versus all the pieces of a solution being available and can be nicely referenced in a draft (e.g., functional decomposition). So if there are drafts that describe PW signaling and auto-discovery, then I don't see any point in lumping them all in one draft. In fact we should avoid this as much as possible. > > With respect to 2547 VPN, at the surface it may look that both are similar > > but looking at it in more details, we see that 2547 uses MPtP PWs; whereas > > VPLS does not (it uses PtP). So we are talking about apple and oranges > > although it may look like apples at first :-) > >Instead of playing semantic games. if you look at the service offered, >you see strong parallels -- any-to-any connectivity, learned forwarding >(as opposed to static mapping in the case of PWs). And there are strong >parallels in how a BGP-based VPLS service and a BGP-based IP VPN service >are deployed. There are also significant differences - e.g., control-plane learning vesus data-plane learning and connectivity among FIBs between the two. So lets not make a general statement that they are the same. As the matter of fact the PW between a pair of FIB in VPLS look exactly the same as for PW PtP operation (VPWS) but you cannot say the same thing for 2547. > > There might be some support because lumping the signaling and > > auto-discovery together may result in quicker implementation but I would > > question the long term viability of it. I would also be interested in > > knowing how many other vendors are planning to support this draft because > > that is another factor for SPs to consider. > >"Lumping the signaling and auto-discovery together" actually results >in a more coordinated implementation, not a quicker one. And instead >of imputing reasons why SPs may like this, just read their emails and >see what they say. O.K., I would like to hear from them to describe the reasons in details. >Finally, to address your issues in your first email, we are not asking >that this doc be made an RFC -- just that it be made a WG doc. As >Alex said: "For a document to become a WG draft, it doesn't have to be >100% correct." Yes but I am concern about PPVPN group try to duplicate the effort of other WG and as I said the signaling portion of PtP PW falls within the charter of PWE3. -Ali >Kireeti. From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Yakov Rekhter Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 13:50:40 -0700 Lines: 94 References: <4.3.2.7.2.20030414120526.01c8d2e0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Kireeti Kompella , "" , "" X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon Apr 14 22:51:18 2003 Return-path: To: Ali Sajassi In-Reply-To: Your message of "Mon, 14 Apr 2003 13:13:04 PDT." <4.3.2.7.2.20030414120526.01c8d2e0@airborne.cisco.com> Content-ID: <93174.1050353440.1@juniper.net> X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] Status: O Ali, > Please refer to my comments inline ... > > At 10:48 AM 4/14/2003 -0700, Kireeti Kompella wrote: > >Hi Ali, > > > >On Mon, 14 Apr 2003, Ali Sajassi wrote: > > > > > Yes, with tightly coupling (intertwining) auto-discovery with signaling, > > > you can use one protocol for both at the expense of overloading that > > > protocol even more. > > > >If you use BGP for auto-discovery, adding signaling information is a minor > >addition with major benefits: > > o a single advertisement accomplishes both auto-discovery and signaling; > > o there is no inter-protocol dependency, and attendant complexity of > > both code and deployment/debugging/...; > > o one gets a complete solution, instead of promises to add enough to > > LDP/radius/... to complete that solution. > > Although BGP is a very legitimate approach for auto-discovery and a proven > way for doing MPtP PW signaling, I don't see any benefits for VPLS type > application where it requires signaling for PtP PWs. That is quite clear :-( > One can use BGP > auto-discovery with existing LDP signaling (per PWE3) and get all the > benefits plus more (more in the sense of having the flexibility to use > different SLAs and QoS for different PWs. You've yet to show that in the context of VPLS this flexibility is of any *practical* significance. > Also having the flexibility to > offer different auto-discovery mechanism to the SPs. This seems like trying to optimize from a vendor's perspective. So, just say so. However, one may also consider trying to optimize from a service provider perspective (the two are not always the same). > >If the issue is "overloading BGP", it is clear that 2547 overloads BGP > >far more significantly. And implementations have proven that BGP is > >nonetheless perfectly happy; deployments have shown that this > >"overloading" has not resulted in any practical problems. > > When I talked about overloading BGP, I was referring to overloading it more > than we have to. 2547 is a different application with different > requirements and it makes sense to use multipoint signaling for multipoint > PWs but for VPLS application, the PW is of type PtP and the associated > signaling as described in PWE3 works well for this type of PW. So using BGP > as auto-discovery, doesn't mean overloading it for signaling as well. > > > >The fact that people who bring up this "overloading" argument forget is > >that in the end, all relevant information must be communicated. The > >"overloading" of the PE in doing so does *not* decrease if you use > >BGP+LDP (or radius+LDP or whatever) -- it only increases. If you > >compare the protocol state, the use of memory/CPU, the inter-protocol > >interactions, etc. -- if you use any measurable criteria for the > >complexity of a solution, on all these measures, the solution proposed > >in draft-kompella-ppvpn-vpls is clearly superior. > > I didn't talk about overloading the PE but instead about the protocol more > than we have to. If we don't use route reflector, then BGP has even higher > overhead than LDP for PtP signaling. And even with route reflector, there > is a trade off between number of connections versus number of messages need > to be processed between BGP and LDP signaling - so BGP has higher overhead > in terms of packet processing than LDP !! To get the overall picture one needs to compare BGP for both auto-discovery and signaling vs BGP for auto-discovery + LDP for signaling, and *not* BGP vs LDP just for signaling. Comparing just BGP for signaling vs LDP for signaling is quite misleading, as it ignores the fact that auto-discovery is an essential part of VPLS. > Also what you're going to do for the SP who don't want to use BGP > auto-discovery (e.g., they prefer directory-based) ? Are you going to force > them to use BGP ? draft-kompella-ppvpn-vpls-01.txt isn't intended to be "all things for all people". But paraphrasing your question, what you're going to do for the SPs who don't want to use LDP for signaling (e.g., they prefer BGP, as they use BGP for auto-discovery) ? Are you going to force them to use LDP ? As I said before, it is time to realize that "one size doesn't fit all". Yakov. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Tue, 15 Apr 2003 16:36:06 +0300 Lines: 15 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Tue Apr 15 15:43:53 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcL/V+taXVqnZkcNSv+/KQ3Dnk1qXgD+1pKw To: , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3FDge804544 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, I just got back from a few days vacation, and see that a lot of progress has been made on the control word issue. I might have missed it in the torrent of emails, but what happened regarding the RTP issue? Was it decided to place the RTP header after the control word, which, as Shahram pointed out, seems to be most consistent with section 5.4.2 ? If not, how does one disambiguate when there is RTP ? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Tue, 15 Apr 2003 18:24:30 +0200 Lines: 40 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B3FAF5C@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Apr 15 17:29:38 2003 Return-path: To: "'Yaakov Stein'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <89D0584BBFBFE74F9057A389BA3F239B3FAF5C@gaya.lycium.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, My 2cents: The location of RTP header compared to the Control word should not depend on the PSN encapsulation. Therefore, when RTP is run over MPLS, the recommendation would be to use the MPLS PID. The MPLS PID can be suppressed when IP identification is not needed. Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Yaakov Stein > Sent: Tuesday, April 15, 2003 3:36 PM > To: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > Stewart, > > I just got back from a few days vacation, > and see that a lot of progress has been made > on the control word issue. > > I might have missed it in the torrent of emails, > but what happened regarding the RTP issue? > > Was it decided to place the RTP header after the control > word, which, as Shahram pointed out, seems to be most > consistent with section 5.4.2 ? > > If not, how does one disambiguate when there is RTP ? > > Y(J)S > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Tue, 15 Apr 2003 20:05:50 +0200 Lines: 68 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Tue Apr 15 19:12:50 2003 Return-path: To: "'Ron Cohen'" , "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ron, Yaakov, Stewart and all, I concur with Ron (both with his reasoning and his conclusions). ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Ron Cohen [mailto:ronc@lyciumnetworks.com] > Sent: Tuesday, April 15, 2003 6:25 PM > To: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > Yaakov, > > My 2cents: The location of RTP header compared to the Control word > should not depend on the PSN encapsulation. Therefore, when RTP is run > over MPLS, the recommendation would be to use the MPLS PID. > The MPLS PID > can be suppressed when IP identification is not needed. > > Ron > > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Yaakov Stein > > Sent: Tuesday, April 15, 2003 3:36 PM > > To: stbryant@cisco.com; pwe3@ietf.org > > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > > > Stewart, > > > > I just got back from a few days vacation, > > and see that a lot of progress has been made > > on the control word issue. > > > > I might have missed it in the torrent of emails, > > but what happened regarding the RTP issue? > > > > Was it decided to place the RTP header after the control > > word, which, as Shahram pointed out, seems to be most > > consistent with section 5.4.2 ? > > > > If not, how does one disambiguate when there is RTP ? > > > > Y(J)S > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Re: SONET/SDH header issues and proposed resolution (l ong) Date: Tue, 15 Apr 2003 20:03:00 +0200 Lines: 78 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 15 19:15:30 2003 Return-path: To: "'Andrew G. Malis'" , Stewart Bryant X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy and Stewart, Please see some questions/comments inline. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] ... snipped ... > > To disambiguate the PW from an IP flow the PW MAY either employ > I suggest to replace MAY with SHOULD in the statement above. IMO, this would be consistent with the text below. > > the Generic PW Control Word shown in Figure 12 or an MPLS payload > type identifier (see Section 5.4.4): > > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Specified by PW Encapsulation > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: Generic PW Control Word > > Note that not all PWE3 encapsulations over MPLS use this > control word > format. > For example, the SONET/SDH encapsulation uses a different > control word > format. > I would add that some encapsulations do not use CW at all, and some use RTP header. > > In the general case, if the MPLS payload does not begin > with a control word > as illustrated in Figure 12, then the payload MUST begin > with an MPLS > payload > type identifier. There is one exception to this > requirement; if a service > provider is not using ECMP, then the provider SHOULD be > I am not sure this text in unambiguous. E.g., the (PW) service provider may noy use ECMP. However, the PW may be tunneled across a carrier's carrier network (providing this service to the provider of the PW servvice) and this network may use ECMP without the PW service provider being aware of the fact. Hence I suggest the following alternative text: --------alternative text begins -------------------- The PW service provider MAY suppress, by configuration, the usage of the MPLS PID at the two ends of the PW (taking full responsibility for possible side effects of ECMP being used in the network between the pair of PEs terminating such a PW). --------alternative text ends -------------------- > > able to use > provisioning to suppress the transmission of the MPLS > payload type > identifier. ... snipped to the end ... From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Re: SONET/SDH header issues and proposed resolution (l ong) Date: Tue, 15 Apr 2003 11:37:38 -0700 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 15 20:42:48 2003 Return-path: To: "'Sasha Vainshtein'" , "'Andrew G. Malis'" , Stewart Bryant X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >I would add that some encapsulations do not use CW at all, and >some use RTP header. Stewart, I think you need to clarify whether RTP header should be before or after the CW. Currently section 5.4.2 shows it after the CW. In other words we need to clarify whether PW is a payload of RTP or RTP is a payload of PW? >> >> In the general case, if the MPLS payload does not begin >> with a control word >> as illustrated in Figure 12, then the payload MUST begin >> with an MPLS >> payload >> type identifier. There is one exception to this >> requirement; if a service >> provider is not using ECMP, then the provider SHOULD be >> >I am not sure this text in unambiguous. E.g., the (PW) service >provider may noy use ECMP. However, the PW may be tunneled across >a carrier's carrier network (providing this service to the provider >of the PW servvice) and this network may use ECMP without the PW >service provider being aware of the fact. > >Hence I suggest the following alternative text: > >--------alternative text begins -------------------- >The PW service provider MAY suppress, by configuration, the usage >of the MPLS PID at the two ends of the PW (taking full responsibility >for possible side effects of ECMP being used in the network between >the pair of PEs terminating such a PW). >--------alternative text ends -------------------- As you said since in a multi-provider environment no one can guarantee that ECMP won't be used, then MPLS PID should be necessary. So I think Andy's text is capturing that very well. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 16 Apr 2003 12:19:50 +0300 Lines: 15 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Wed Apr 16 11:22:25 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcMDY07CLOGAeurcQuqaUFpZCDunvAAlc5Hg To: "Ron Cohen" , , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3G9Ql802155 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > My 2cents: The location of RTP header compared to the Control word > should not depend on the PSN encapsulation. Therefore, when RTP is run > over MPLS, the recommendation would be to use the MPLS PID. > The MPLS PID can be suppressed when IP identification is not needed. Ron, I don't see your point. We can quite consistently put the RTP AFTER the control word, whether in MPLS or IP. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 16 Apr 2003 12:44:17 +0200 Lines: 41 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B3FAFBA@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Apr 16 11:47:37 2003 Return-path: To: "'Yaakov Stein'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <89D0584BBFBFE74F9057A389BA3F239B3FAFBA@gaya.lycium.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, My point is that when you run RTP applications over IP, in all cases I'm aware of you use IP/UDP/RTP/Payload, and you do not put any Control Words between the UDP and the RTP headers. Any information which is payload specific is part of the RTP payload. You can use various header compression techniques to get read of the overhead over slow links, etc. I'm suggesting that we should use the same layering principles over all possible PSNs. Ron > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Wednesday, April 16, 2003 11:20 AM > To: Ron Cohen; stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > My 2cents: The location of RTP header compared to the Control word > > should not depend on the PSN encapsulation. Therefore, when > RTP is run > > over MPLS, the recommendation would be to use the MPLS PID. > The MPLS > > PID can be suppressed when IP identification is not needed. > > Ron, > > I don't see your point. > > We can quite consistently put the RTP > AFTER the control word, > whether in MPLS or IP. > > > Y(J)S > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Alik Shimelmits Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 16 Apr 2003 12:43:47 +0200 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Wed Apr 16 11:52:31 2003 Return-path: To: "'Yaakov Stein'" , Ron Cohen , stbryant@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, when UDP transport is used it is an advantage to put RTP in a place where other system may recognize/track that it is RTP. And, IMO, this is the only reasonable position if we want to re-use RTP as is and not to invent something new. Regards Alik -----Original Message----- From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Wednesday, April 16, 2003 11:20 AM To: Ron Cohen; stbryant@cisco.com; pwe3@ietf.org Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > My 2cents: The location of RTP header compared to the Control word > should not depend on the PSN encapsulation. Therefore, when RTP is run > over MPLS, the recommendation would be to use the MPLS PID. > The MPLS PID can be suppressed when IP identification is not needed. Ron, I don't see your point. We can quite consistently put the RTP AFTER the control word, whether in MPLS or IP. Y(J)S _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 16 Apr 2003 06:33:41 -0700 Lines: 5 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Wed Apr 16 15:36:29 2003 Return-path: To: "'Ron Cohen'" , "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Therefore, when RTP is run over MPLS, the recommendation would be to use the MPLS PID. So are you suggesting the MPLS PID should be set a value that is assigned to RTP? -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: CESoPSN question Date: Wed, 16 Apr 2003 06:59:54 -0700 Lines: 23 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" X-From: pwe3-admin@ietf.org Wed Apr 16 16:02:40 2003 Return-path: To: "'Sasha Vainshtein'" , "'Ron Cohen'" , "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, Could you please explain why RTP is Required in CESoPSN draft? CESoPSN makes optional use of the following fields in RTP: 1) Sequence #: is optional because there is already a sequence number in the CW 2) Time stamp: Since only the Absolute timing mode is mandatory, and since as you mention in section 9.4, the Absolute mode time stamp correlates with the CW Seq #. It seems that Time stamp is also optional. 3) SSRS: As you have stated in the draft it "MAY be used for detection of misconnections". So it is optional. Besides if you are not multiplexing RTP streams over the same PW, which I think should be the case (because Muxing header is in charge of Muxing), I don't see any need for SSRC, because any misconnection could be detected by the Muxing layer. 4) Payload Type: If RTP is not present then UDP or MPLS PID could identify the PT as CESoPSN. So if all the RTP fields are optional, why is it required for CESoPSN? Thanks, -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Tim.Frost@Zarlink.Com Subject: Re: CESoPSN question Date: Thu, 17 Apr 2003 10:03:58 +0100 Lines: 69 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: pwe3@ietf.org, pwe3-admin@ietf.org, "'Ron Cohen'" , "'Sasha Vainshtein'" , stbryant@cisco.com, "'Yaakov Stein'" X-From: pwe3-admin@ietf.org Thu Apr 17 11:20:44 2003 Return-path: To: Shahram Davari X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.11 |July 24, 2002) at 04/17/2003 05:13:31 AM, Serialize complete at 04/17/2003 05:13:31 AM Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, See section 5.3, draft-vainshtein-cesopsn-05.txt (submitted in February this year): Second para reads: Note: Under certain circumstances the RTP header MAY be suppressed in order to conserve network bandwidth. See section 9.4 for details. In other words, the RTP header is optional. The one case where it is not optional is when the RFC2833 scheme is used to carry CAS, since this relies on the timestamp to re-align the signalling packets with the data. This is what is explained in section 9.4. Tim Shahram Davari Sent by: pwe3-admin@ietf.org 16-Apr-2003 02:59 PM To: "'Sasha Vainshtein'" , "'Ron Cohen'" , "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org cc: Subject: [PWE3] CESoPSN question Sasha, Could you please explain why RTP is Required in CESoPSN draft? CESoPSN makes optional use of the following fields in RTP: 1) Sequence #: is optional because there is already a sequence number in the CW 2) Time stamp: Since only the Absolute timing mode is mandatory, and since as you mention in section 9.4, the Absolute mode time stamp correlates with the CW Seq #. It seems that Time stamp is also optional. 3) SSRS: As you have stated in the draft it "MAY be used for detection of misconnections". So it is optional. Besides if you are not multiplexing RTP streams over the same PW, which I think should be the case (because Muxing header is in charge of Muxing), I don't see any need for SSRC, because any misconnection could be detected by the Muxing layer. 4) Payload Type: If RTP is not present then UDP or MPLS PID could identify the PT as CESoPSN. So if all the RTP fields are optional, why is it required for CESoPSN? Thanks, -Shahram _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 17 Apr 2003 13:03:51 +0200 Lines: 22 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C8D5@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Apr 17 12:10:06 2003 Return-path: To: "'Shahram Davari'" , "'Yaakov Stein'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C8D5@nt-exch-yow.pmc-sierra.bc.ca> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, > > Therefore, when RTP is run over MPLS, the recommendation > would be to > > use the MPLS PID. > > So are you suggesting the MPLS PID should be set a value that > is assigned to RTP? > Yes. Ron > -Shahram > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: CESoPSN question Date: Thu, 17 Apr 2003 07:48:49 -0700 Lines: 39 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, pwe3-admin@ietf.org, "'Ron Cohen'" , "'Sasha Vainshtein'" , stbryant@cisco.com, "'Yaakov Stein'" X-From: pwe3-admin@ietf.org Thu Apr 17 16:52:30 2003 Return-path: To: "'Tim.Frost@Zarlink.Com'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tim, >Shahram, >See section 5.3, draft-vainshtein-cesopsn-05.txt (submitted in >February >this year): >Second para reads: > >Note: Under certain circumstances the RTP header MAY be suppressed in >order to conserve network bandwidth. See section 9.4 for details. So could you please add (optional) in front of RTP header in all the diagrams. In other words replace the term saying "fixed RTP header" with "Optional RTP header". > >In other words, the RTP header is optional. The one case where >it is not >optional is when the RFC2833 scheme is used to carry CAS, since this >relies on the timestamp to re-align the signalling packets >with the data. >This is what is explained in section 9.4. Since doing RFC2833 is optional by itself, then RTP should be optional in your draft. Correct? Also the text says: " o Optional sequence number - implementation MAY copy 14 least significant bits of the RTP sequence number into this field. Otherwise it SHOULD be set to 0 at ingress. " If RTP is optional then how can this statement be true? Thanks, -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Tim.Frost@Zarlink.Com Subject: Re: Liaison from MPLS Forum to PWE3 Date: Thu, 17 Apr 2003 17:13:24 +0100 Lines: 238 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "'pwe3@ietf.org'" , pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 17 18:25:49 2003 Return-path: To: "Walsh, Thomas D (Tom)" , "Andrew G. Malis" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.11 |July 24, 2002) at 04/17/2003 12:22:59 PM, Serialize complete at 04/17/2003 12:22:59 PM Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Dear Tom, Here is my response to your recent liaison request to the PWE3 Forum regarding the document "TDM Transport over MPLS using AAL1 Implementation Agreement". Overall, the document is a commendable approach to carrying TDM over an MPLS network, based on a mature, pre-existing technology (i.e. AAL1). A similar proposal, draft-anavi-tdmoip, has been before the IETF for some time, and extensively discussed on the list. My main comment on the document is that although it describes a means of carrying TDM over an MPLS network, it does not clearly show what quality of TDM service will result from its use. While for low-cost, customer equipment performing a "cheap and cheerful" toll bypass type application the absolute level of quality may not be important, the fidelity of the service is important if this technology is ever to gain acceptance as a carrier-operated technology. Therefore I would like to see more details on the quality of the TDM service one can expect, and the performance of the underlying MPLS network required to achieve it. I have various comments about specific parts of the text which are outlined below. These include several recommendations for changes. Some of the points outlined below are covered in the other TDM drafts currently before the IETF, particularly draft-johnson-pwe3-tdm and draft-vainshtein-cesopsn. Since these drafts, along with draft-anavi-tdmoip (the companion draft to the MPLS Forum document), are still under discussion in the IETF, I would recommend that MPLS Forum members join in the debate to find a common solution, rather than run the risk of different, non-interoperable standards being developed in various separate organisations. Regards, Tim Tim Frost, System Architect, Zarlink Semiconductor ---------------------------------------------------------- Address: Tamerton Road, Roborough, Plymouth, PL6 7BQ, U.K. Tel.: +44 1752 693840 Mobile: +44 7720 700405 Fax.: +44 1752 693743 Email: tim.frost@zarlink.com ---------------------------------------------------------- The specific comments I have on the document are outlined below. Section 2, TDM and MPLS Network Interworking Requirements 4. Timing "May" seems very weak for something so important to TDM networks. If there is no method for clock reconstruction, then the use of the scheme is restricted to scenarios where either the TDM devices at each end or the PE devices at each edge share a common clock, or have access to a PRS traceable reference. Essentially this means CO to CO scenario, which is small subset of the possible applications of this type of device. The lack of clock reconstruction in other scenarios would lead to a serious degradation in quality, expressed in frequent uncontrolled TDM frame slips. I recommend that this is at least a "should", i.e. a strong recommendation, not merely a permission. 6. Interworking Given the documents stated purpose "to define the network interworking between the TDM circuits (nx64kbps, T1, E1, T3, E3) over MPLS Label Switched Paths", I question whether the ability to inter-work with ATM AAL1 services is a requirement, or merely a desirable feature of the chosen implementation. Inter-working with AAL1 is clearly an area where a vendor could add value to their equipment, but it is not necessary to achieve the stated purpose. Section 4, TDM-MPLS Payload General comments on payload format: 1. In unstructured mode, there is no requirement to carry the protected sequence number in every AAL1 sub-frame. This serves no purpose, and is therefore wasted bandwidth. 2. In structured mode, the structure pointer is buried within the payload. This makes is awkward for an implementation to find the pointer, particularly since it may be in different places depending on the number of sub-frames in each packet. In general, I recommend that any control information such as a pointer is placed in the header where it is in a consistent position and may be easily found and processed. This pointer would also be more resistant to packet loss since it is transmitted with every packet (or at least every packet containing a structure start), not every eight sub-frames. The TDM-MPLS Agreement also inherits the following undesirable properties of AAL1: 1. For nx64kbps, the granularity of delay introduced by the packet formation process may be high, particularly for small values of n. This is because the sub-frames need to be filled with payload. The use of partially filled sub-frames is a rather inefficient means of keeping the packet formation delay low. There is no need in an MPLS packet network to have packets of a fixed size as in ATM, therefore the packet size could be tuned to a better compromise between efficiency and latency. 2. The carriage of CAS is handled by a sub-structure, which may span across cell boundaries, or be found buried in the middle of a cell. With a fixed cell size, this was an unavoidable complication. With an MPLS packet network permitting variable packet sizes, this is no longer true. Since the CAS sub-structure will be processed separately from the data, it is desirable to place it in an easily accessible location within the packet, e.g. a header extension, or appended to the end of the data section with a pointer in the header to its location. Service Inter-working with ATM 1.The document recommends checking the contents of the CRC and P bits in the protected sequence number when interworking with ATM. As the cells come in from the ATM network, I agree this checking must occur. However, in common with other layer 2 pseudo-wire schemes, these bits should then be discarded (e.g. discarding of the Ethernet FCS in draft-ietf-pwe3-ethernet-encap, or the Frame Relay FCS in draft-ietf-pwe3-frame-relay). For inter-working in the opposite direction, these bits can be generated on entry to the ATM network. This is consistent with the suggestions on payload format given above. 2. The document describes data-plane interworking with AAL1 - i.e. translation of AAL1 sub-frames into TDM-MPLS packets and vice versa. It doesn't cover control-plane or OAM inter-working. Therefore it would appear to me that the document doesn't describe everything that would need to be done to provide full service interworking between AAL1 and TDM-MPLS. I am not sufficiently expert in ATM to know how much of an omission this is. The addressing of the above points would simplify any implementation of a TDM-MPLS interworking function. The implementation agreement as it stands strongly favours the inclusion of an AAL1 SAR function as an intermediate step, even when inter-working with ATM is not required. It would be better to structure the agreement such that the AAL1 SAR function would be required ONLY when inter-working with ATM is required. Section 5, General Requirements Apart from a vague suggestion that the MPLS network support quality of service, there are no requirements on the MPLS network itself. I envisage a section describing a service level specification that would allow the TDM-MPLS service to achieve a stated level of quality. For example, what service level specification on the MPLS network would I require in order to operate a TDM-MPLS service that meets the existing TDM standards? This would include parameters such as edge to edge packet delay and packet delay variation, packet loss rates, packet error rates and so on. Section 7, Clock Recovery Requirements on clock recovery are weak. The document describes a "whole network" scenario, where the TDM-MPLS is used to replace the TDM infrastructure. Timing recovery is described as mandatory in this application, yet the quality of the timing recovery is only "recommended" to be in conformance with the relevant ITU-T standards. For this type of scenario, meeting the ITU-T standards is mandatory, or no carrier will ever deploy this technology. It is also a strange omission given that the authors have already noted that the use of time standards less accurate than Stratum 3 is not recommended. The requirement "The regenerated clock SHOULD conform to ITU-T recommendations G.823 for E1 and G.824 for T1 trunks" doesn't specify which type of interface it should conform to, e.g. traffic interface, synchronisation interface, reference interface. The implementation agreement does not contain any information about clock recovery, how it should be carried out, or how it may be guaranteed to meet the standards quoted. This may be because it is part of a particular vendor's value add, but consideration should be given as to whether any means of guaranteeing accuracy should be included as part of this implementation agreement, otherwise it may hinder inter-operability between different vendors' equipment. "Walsh, Thomas D (Tom)" Sent by: pwe3-admin@ietf.org 28-Feb-2003 06:20 PM To: "'pwe3@ietf.org'" cc: Subject: [PWE3] Liaison from MPLS Forum to PWE3 To: IETF PWE3 working group From: MPLS Forum The MPLS Forum Technical Committee has been discussing the transport of TDM over MPLS networks, and we now have a draft of the "TDM Transport over MPLS using AAL1 Implementation Agreement" reaching its final stages. Since the PWE3 working group has also been working on this issue, we would like to invite comments from the WG before progressing this text to final ballot. For this purpose, we have placed the straw ballot text of the Implementation Agreement in the public area of our web site, at http://www.mplsforum.org/tech/mpls2003.036.01.pdf . We have temporarily delayed the advancement of our Implementation Agreement in order to avoid conflicts between the specifications. Alignment with IETF RFCs is a key objective for implementation agreements reached in the MPLS Forum. However, there is also significant interest in the MPLS Forum to bring this work to a conclusion. The MPLS Forum encourages the PWE3 WG to reach a timely agreement on this topic so that our two bodies can produce an aligned solution. Comments are invited from individual IETF and IESG participants, the working group as a body, and the IESG as a body. We will look for comments and discussion on the PWE3 mailing list. Best regards, Andy Malis MPLS Forum President Tom Walsh MPLS Forum External Relations _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Christopher N. \"Nick\" DelRegno" Subject: RE: pwe3-ethernet-encap - FCS... Date: Thu, 17 Apr 2003 11:53:02 -0500 Organization: WorldCom, Global Access Technology Development Lines: 71 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Thu Apr 17 18:56:56 2003 Return-path: To: pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HH0f820920 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3HH3S821037 Status: O Beware, can of worms opening=85 =A0 >From the original =93Martini=94 draft to today, the customer FCS data has been discarded. =A0Initially, my interest was in the =93tagged=94 mode mo= re than the =93port=94 or =93raw=94 mode of encapsulation.=A0 I noted that t= he FCS was discarded in order to save 4 bytes as well as the fact that many deployed implementations discard the FCS today. =A0Until recently, we wer= e okay with this since each link has some error checking mechanism in place. =A0 In testing a very widely deployed Ethernet switch, we encountered an anomaly which, if the FCS is discarded, would be a nightmare to troubleshoot in a live network. =A0Briefly, while we weren=92t seeing any packet loss across an Ethernet network and every packet was being received by the destination host, all higher-layer frames were being dropped by the host. =A0After spending an inordinate amount of time using traditional Ethernet performance metrics to attempt to isolate the problem, not until we intrusively placed Ethernet test equipment on both ends did we discover that while the Ethernet FCS of every delivered packet was good, the customer data was corrupt. =A0 Apparently one of the Ethernet switches in the network was internally corrupting the data between the discarding of the customer FCS and the calculation of a new FCS.=A0 Mind you, there were no VLAN tag swaps or stacks or the like.=A0 This was a simple bridged connection, where the Ethernet packet in theory shouldn=92t change, that was consistently corrupting the data. =A0 Now, had the FCS been maintained throughout the data path, the customer=92s network-facing Ethernet switch would have dropped every corrupted packet due to the FCS error. =A0 In the pwe3-ethernet-encap draft as it stands, there is no provision for keeping the received FCS. =A0In tagged mode, this is more understandable since I very well may change the VLAN ID at the far end of the network.=A0 However, in the Ethernet mode, where I am sending ALL of the customer=92s frames, without looking at the VLAN ID, I need the ability to maintain the customer=92s FCS as well. =A0 I realize that A) this is not how the draft is written, B) that if the FCS is optional, then pwe3-control-protocol will have to be updated as well to signal the presence or lack of the FCS (possibly via the Interface Parameters field) and C) that many popular techniques to stack tags don=92t retain the customer FCS.=A0 However, the cost of the additio= nal 4 bytes per packet and extra signaling information is worth it.=A0 When providing Ethernet private line type services, we have to rely on the Layer 2 information to determine the performance of the network. =A0Maintaining the customer=92s FCS, resulting in a =93Path FCS=94, gives= the SP an end-to-end error check. =A0 In the truest sense of the term pseudo-wire, we are using a PSN to emulate an Ethernet-cable. =A0It would be unacceptable if an Ethernet cable somehow corrupted the payload of the MAC frames without the FCS being able to detect it.=A0 It is just as unacceptable if that Ethernet cable is composed of packet switched networks instead of twisted pairs. =A0 Admittedly, if such internal errors occur in network devices, having a =93Path FCS=94 will not tell me which switch is errant.=A0 However, it wi= ll tell me a problem exists, hopefully prior to my customer=92s contacting me.=A0=20 =A0 Regards, Nick DelRegno =A0 =A0 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: Liaison from MPLS Forum to PWE3 Date: Thu, 17 Apr 2003 18:20:04 +0100 Lines: 82 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 17 19:29:29 2003 Return-path: To: Tim.Frost@zarlink.com, tdwalsh@lucent.com, Andy.Malis@vivacenetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tim....I am finding it hard to appreciate the sentiments of your comments (which BTW I agree with) in the context of what I see unfurling in PWE3. Please see below. regards, Neil Tim.Frost@zarlink.com wrote 17 April 2003 17:13 > Dear Tom, > > Here is my response to your recent liaison request to the PWE3 Forum > regarding the document "TDM Transport over MPLS using AAL1 > Implementation > Agreement". > > Overall, the document is a commendable approach to carrying > TDM over an > MPLS network, based on a mature, pre-existing technology > (i.e. AAL1). NH=> Agreed. > A similar proposal, draft-anavi-tdmoip, has been before the > IETF for some > time, and extensively discussed on the list. > > My main comment on the document is that although it describes > a means of > carrying TDM over an MPLS network, it does not clearly show > what quality > of TDM service will result from its use. NH=> The performance experienced by a client layer network (TDM here) will be *inherited* (not necessarily linearly for some metrics) from *all* layers below this to the duct. Let's just take the immediately lower MPLS server layer case however. The implication of this statement is that the MPLS layer must therefore be just as well defined in this sense....I don't think is the case. Now what about an IP server layer? The fact is the two cases are not (and indeed have no need to be) the same....you can try and force such behaviour, but I really see no benefit. Horses for courses......use the 3 basic networks modes (of cnls, co pkt-sw and co cct-sw(L1)) wisely since they solve different problems and *all* are needed by carriers. > While for low-cost, customer > equipment performing a "cheap and cheerful" toll bypass type > application > the absolute level of quality may not be important, the > fidelity of the > service is important if this technology is ever to gain > acceptance as a > carrier-operated technology. NH=> Just how does one define (the requirements of) 'carrier-operated technology'? Again, I can see that X/IP and X/MPLS can give different results (and very validly so).....one of these *could* be classed as carrier-grade whilst the other may not for a *given* client type. For example TDMoverMPLS is different from TDMoverIP IMO. I would have thought a key/general carrier-grade client/server requirements ought to be functional client/server layer independence..........which includes simple, yet must be robust/consistent, fault-management of both the client and the server layers {dare I say Y.1711 for MPLS? Outside of Y.1711 there are no defects defined for MPLS.....and if we dont't have these then how can we start to define availability?....and if we can't do this then how can we even start to discuss QoS?....and if this is not defined for MPLS then how can we seriously expect to ask others to define the performance delivered to the clients of MPLS? There is a logical sequence here.} Get the above right and we don't need (and certainly don't want) unecessary functions in the 'in-between' layer between client layer and server layer (like OAM for PWS for goodness sake!).....this is creating more stuff (=problems/costs) for carriers to manage. Keep it simple/independent....and differentiate X/IP from X/MPLS....there is no reason (outside dogma) to force them to be the same. > Therefore I would like to see > more details on > the quality of the TDM service one can expect, and the > performance of the > underlying MPLS network required to achieve it. NH=> Agreed Tim....my very point above.....this starts with defects, moves through availability and then (and only then) defines QoS. And these considerations are different in the X/IP or X/MPLS cases. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Christopher N. \"Nick\" DelRegno" Subject: pwe3-ethernet-encap - FCS... Date: Wed, 16 Apr 2003 23:29:07 -0500 Organization: WorldCom, Global Access Technology Development Lines: 330 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary_(ID_RlREiFcLqdWRAaYmT+NI0A)" X-From: pwe3-admin@ietf.org Fri Apr 18 06:51:11 2003 Return-path: To: pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. --Boundary_(ID_RlREiFcLqdWRAaYmT+NI0A) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Beware, can of worms opening. >From the original "Martini" draft to today, the customer FCS data has been discarded. Initially, my interest was in the "tagged" mode more than the "port" or "raw" mode of encapsulation. I noted that the FCS was discarded in order to save 4 bytes as well as the fact that many deployed implementations discard the FCS today. Until recently, we were okay with this. In testing a very widely deployed Ethernet switch, we encountered an anomaly which, if the FCS is discarded, would be a nightmare to troubleshoot in a live network. Briefly, while we weren't seeing any packet loss across a fairly large Ethernet network and every packet was being received by the destination host, all higher-layer frames were being dropped by the host. After spending an inordinate amount of time using traditional Ethernet performance metrics to attempt to isolate the problem, not until we intrusively placed Ethernet test equipment on both ends did we discover that while the Ethernet FCS of every delivered packet was good, the customer data was corrupt. Interestingly it was only in one direction. Apparently one of the Ethernet switches in the network was internally corrupting the data between the discarding of the customer FCS and the calculation of a new FCS. Mind you, there were no VLAN tag swaps or stacks or the like. This was a simple bridged connection, where the Ethernet packet in theory shouldn't change, that was consistently corrupting the data. Now, had the FCS been maintained throughout the data path, the customer's network-facing Ethernet switch would have dropped every corrupted packet due to the FCS error. In the pwe3-ethernet-encap draft as it stands, there is no provision for keeping the received FCS. In tagged mode, this is understandable since I very well may change the VLAN ID at the far end of the network. However, in the Ethernet mode, where I am sending ALL of the customer's frames, without looking at the VLAN ID, I need the ability to maintain the customer's FCS as well. I realize that A) this is not how the draft is written, B) that if the FCS is optional, then pwe3-control-protocol will have to be updated as well to signal the presence or lack of the FCS (possibly via the Interface Parameters field) and C) that many popular techniques to stacked tags don't retain the customer FCS. However, the cost of the additional 4 bytes per packet and extra signaling information is worth it. When providing Ethernet private line type services, we have to rely on the Layer 2 information to determine the performance of the network. Maintaining the customer's FCS, resulting in a "Path FCS", gives the SP an end-to-end error check. In the truest sense of the term pseudo-wire, we are using a PSN to emulate an Ethernet-cable. It would be unacceptable if an Ethernet cable somehow corrupted the payload of the MAC frames without the FCS being able to detect it. It is just as unacceptable if that Ethernet cable is composed of packet switched networks instead of twisted pairs. Admittedly, if such internal errors occur in network devices, having a "Path FCS" will not tell me which switch is errant. However, it will tell me a problem exists, hopefully prior to my customer's contacting me. Regards, Nick DelRegno --Boundary_(ID_RlREiFcLqdWRAaYmT+NI0A) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Beware, can of worms opening…

 

From the original “Martini” draft to = today, the customer FCS data has been discarded.  Initially, my interest was = in the “tagged” mode more than the “port” or “raw” mode of encapsulation.  I noted that the FCS was discarded in order to save = 4 bytes as well as the fact that many deployed implementations discard the = FCS today.  Until recently, we were okay with this.

 

In testing a very widely deployed Ethernet switch, we = encountered an anomaly which, if the FCS is discarded, would be a nightmare to = troubleshoot in a live network.  Briefly, while we weren’t seeing any = packet loss across a fairly large Ethernet network and every packet was being = received by the destination host, all higher-layer frames were being dropped by the = host.  After spending an inordinate amount of time using traditional Ethernet = performance metrics to attempt to isolate the problem, not until we intrusively = placed Ethernet test equipment on both ends did we discover that while the = Ethernet FCS of every delivered packet was good, the customer data was corrupt. =  Interestingly it was only in one direction.

 

Apparently one of the Ethernet switches in the = network was internally corrupting the data between the discarding of the customer FCS and the calculation of a new FCS.  Mind you, there were no VLAN tag swaps = or stacks or the like.  This was a simple bridged connection, where = the Ethernet packet in theory shouldn’t change, that was consistently corrupting the data.

 

Now, had the FCS been maintained throughout the data = path, the customer’s network-facing Ethernet switch would have dropped = every corrupted packet due to the FCS error.

 

In the pwe3-ethernet-encap draft as it stands, there = is no provision for keeping the received FCS.  In tagged mode, this is = understandable since I very well may change the VLAN ID at the far end of the = network.  However, in the Ethernet mode, where I am sending ALL of the = customer’s frames, without looking at the VLAN ID, I need the ability to maintain = the customer’s FCS as well.

 

I realize that A) this is not how the draft is = written, B) that if the FCS is optional, then pwe3-control-protocol will have to be = updated as well to signal the presence or lack of the FCS (possibly via the = Interface Parameters field) and C) that many popular techniques to stacked tags don’t = retain the customer FCS.  However, the cost of the additional 4 bytes per = packet and extra signaling information is worth it.  When providing = Ethernet private line type services, we have to rely on the Layer 2 information = to determine the performance of the network.  Maintaining the = customer’s FCS, resulting in a “Path FCS”, gives the SP an end-to-end = error check.

 

In the truest sense of the term pseudo-wire, we are = using a PSN to emulate an Ethernet-cable.  It would be unacceptable if an = Ethernet cable somehow corrupted the payload of the MAC frames without the FCS = being able to detect it.  It is just as unacceptable if that Ethernet = cable is composed of packet switched networks instead of twisted pairs.

 

Admittedly, if such internal errors occur in network devices, having a “Path FCS” will not tell me which switch = is errant.  However, it will tell me a problem exists, hopefully prior = to my customer’s contacting me. 

 

Regards,

Nick DelRegno

 

 

--Boundary_(ID_RlREiFcLqdWRAaYmT+NI0A)-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Akiva Sadovski Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Fri, 18 Apr 2003 10:30:00 +0200 Lines: 44 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Fri Apr 18 09:41:43 2003 Return-path: To: "'Ron Cohen '" , "''Shahram Davari' '" , "''Yaakov Stein' '" , "'stbryant@cisco.com '" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shaharam and Ron, Just a naive question: why can't we assign TWO MPLS PIDs: -- one value for PW with RTP -- and another for PW without RTP ? Are we limited in the nuber of PIDs to use ? Regards, Akiva Sadovski -----Original Message----- From: Ron Cohen To: 'Shahram Davari'; 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org Sent: 17/04/2003 13:03 Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 Shahram, > > Therefore, when RTP is run over MPLS, the recommendation > would be to > > use the MPLS PID. > > So are you suggesting the MPLS PID should be set a value that > is assigned to RTP? > Yes. Ron > -Shahram > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Akiva Sadovski Subject: RE: pwe3-ethernet-encap - FCS... Date: Fri, 18 Apr 2003 12:57:27 +0200 Lines: 103 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Fri Apr 18 12:04:23 2003 Return-path: To: "'Christopher N. \"Nick\" DelRegno '" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, Nick, As i understand, your point is that in Ethernet-over-PSN PW some malicious switch/router can corrupt the payload; in that case some layer 2 FCS of the PW packets will be unable to detect these corrupted packets. Is that so ? Note, that exactly the same problem may exist in the FrameRelav-over-PSN encapsulation, where FCS is stripped by the PE device. But in case of FR-over-PSN the solution will be complicated by the fact that the FCS must be carried along with bit stuffing, and bit stuffing presence complicate DLCI analysis etc... Thanks, Akiva Sadovski -----Original Message----- From: Christopher N. "Nick" DelRegno To: pwe3@ietf.org Sent: 17/04/2003 06:29 Subject: [PWE3] pwe3-ethernet-encap - FCS... Beware, can of worms opening... >From the original "Martini" draft to today, the customer FCS data has been discarded. Initially, my interest was in the "tagged" mode more than the "port" or "raw" mode of encapsulation. I noted that the FCS was discarded in order to save 4 bytes as well as the fact that many deployed implementations discard the FCS today. Until recently, we were okay with this. In testing a very widely deployed Ethernet switch, we encountered an anomaly which, if the FCS is discarded, would be a nightmare to troubleshoot in a live network. Briefly, while we weren't seeing any packet loss across a fairly large Ethernet network and every packet was being received by the destination host, all higher-layer frames were being dropped by the host. After spending an inordinate amount of time using traditional Ethernet performance metrics to attempt to isolate the problem, not until we intrusively placed Ethernet test equipment on both ends did we discover that while the Ethernet FCS of every delivered packet was good, the customer data was corrupt. Interestingly it was only in one direction. Apparently one of the Ethernet switches in the network was internally corrupting the data between the discarding of the customer FCS and the calculation of a new FCS. Mind you, there were no VLAN tag swaps or stacks or the like. This was a simple bridged connection, where the Ethernet packet in theory shouldn't change, that was consistently corrupting the data. Now, had the FCS been maintained throughout the data path, the customer's network-facing Ethernet switch would have dropped every corrupted packet due to the FCS error. In the pwe3-ethernet-encap draft as it stands, there is no provision for keeping the received FCS. In tagged mode, this is understandable since I very well may change the VLAN ID at the far end of the network. However, in the Ethernet mode, where I am sending ALL of the customer's frames, without looking at the VLAN ID, I need the ability to maintain the customer's FCS as well. I realize that A) this is not how the draft is written, B) that if the FCS is optional, then pwe3-control-protocol will have to be updated as well to signal the presence or lack of the FCS (possibly via the Interface Parameters field) and C) that many popular techniques to stacked tags don't retain the customer FCS. However, the cost of the additional 4 bytes per packet and extra signaling information is worth it. When providing Ethernet private line type services, we have to rely on the Layer 2 information to determine the performance of the network. Maintaining the customer's FCS, resulting in a "Path FCS", gives the SP an end-to-end error check. In the truest sense of the term pseudo-wire, we are using a PSN to emulate an Ethernet-cable. It would be unacceptable if an Ethernet cable somehow corrupted the payload of the MAC frames without the FCS being able to detect it. It is just as unacceptable if that Ethernet cable is composed of packet switched networks instead of twisted pairs. Admittedly, if such internal errors occur in network devices, having a "Path FCS" will not tell me which switch is errant. However, it will tell me a problem exists, hopefully prior to my customer's contacting me. Regards, Nick DelRegno From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Christopher N. \"Nick\" DelRegno" Subject: RE: pwe3-ethernet-encap - Ethernet FCS needed... Date: Fri, 18 Apr 2003 12:35:42 -0500 Organization: WorldCom, Global Access Technology Development Lines: 158 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri Apr 18 19:39:12 2003 Return-path: In-reply-to: To: "'Akiva Sadovski'" , pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Akiva: > As i understand, your point is that in Ethernet-over-PSN PW some >malicious >switch/router can corrupt the payload; in that case some layer 2 FCS of the >PW packets will be unable to detect these corrupted packets. Is that so ? Yes. As Lloyd Wood clarifies, a switch/router which is buggy or failing. While the Layer 2 over the wire will protect packets from bit errors on the line, the customer MAC is vulnerable inside the box. How often does this occur?...It's hard to say. We have seen it consistently with one switch from one vendor. We only saw it because it was so dramatic, but damn hard to isolate. My point in raising this issue is that for the network to arbitrarily discard the customer FCS it requires a leap of faith that the network is not going to screw up the payload prior to calculating a new FCS at the far end of the network. The error we saw was internal to an Ethernet switch. In the case of a pseudowire, there may be opportunity for this to occur, however rarely. What I am asking is that we have an option to keep or discard the FCS and signal accordingly. That way, vendor equipment which doesn't support FCS retention would interoperate with those that do. It is then a SP's choice of which they would rather use in their network. I am not asking that the FCS be checked anywhere in the pseudowire path, only that it be maintained intact. Regards, Nick -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Akiva Sadovski Sent: Friday, April 18, 2003 5:57 AM To: 'Christopher N. "Nick" DelRegno '; 'pwe3@ietf.org ' Subject: RE: [PWE3] pwe3-ethernet-encap - FCS... Hi, Nick, As i understand, your point is that in Ethernet-over-PSN PW some malicious switch/router can corrupt the payload; in that case some layer 2 FCS of the PW packets will be unable to detect these corrupted packets. Is that so ? Note, that exactly the same problem may exist in the FrameRelav-over-PSN encapsulation, where FCS is stripped by the PE device. But in case of FR-over-PSN the solution will be complicated by the fact that the FCS must be carried along with bit stuffing, and bit stuffing presence complicate DLCI analysis etc... Thanks, Akiva Sadovski -----Original Message----- From: Christopher N. "Nick" DelRegno To: pwe3@ietf.org Sent: 17/04/2003 06:29 Subject: [PWE3] pwe3-ethernet-encap - FCS... Beware, can of worms opening... >From the original "Martini" draft to today, the customer FCS data has been discarded. Initially, my interest was in the "tagged" mode more than the "port" or "raw" mode of encapsulation. I noted that the FCS was discarded in order to save 4 bytes as well as the fact that many deployed implementations discard the FCS today. Until recently, we were okay with this. In testing a very widely deployed Ethernet switch, we encountered an anomaly which, if the FCS is discarded, would be a nightmare to troubleshoot in a live network. Briefly, while we weren't seeing any packet loss across a fairly large Ethernet network and every packet was being received by the destination host, all higher-layer frames were being dropped by the host. After spending an inordinate amount of time using traditional Ethernet performance metrics to attempt to isolate the problem, not until we intrusively placed Ethernet test equipment on both ends did we discover that while the Ethernet FCS of every delivered packet was good, the customer data was corrupt. Interestingly it was only in one direction. Apparently one of the Ethernet switches in the network was internally corrupting the data between the discarding of the customer FCS and the calculation of a new FCS. Mind you, there were no VLAN tag swaps or stacks or the like. This was a simple bridged connection, where the Ethernet packet in theory shouldn't change, that was consistently corrupting the data. Now, had the FCS been maintained throughout the data path, the customer's network-facing Ethernet switch would have dropped every corrupted packet due to the FCS error. In the pwe3-ethernet-encap draft as it stands, there is no provision for keeping the received FCS. In tagged mode, this is understandable since I very well may change the VLAN ID at the far end of the network. However, in the Ethernet mode, where I am sending ALL of the customer's frames, without looking at the VLAN ID, I need the ability to maintain the customer's FCS as well. I realize that A) this is not how the draft is written, B) that if the FCS is optional, then pwe3-control-protocol will have to be updated as well to signal the presence or lack of the FCS (possibly via the Interface Parameters field) and C) that many popular techniques to stacked tags don't retain the customer FCS. However, the cost of the additional 4 bytes per packet and extra signaling information is worth it. When providing Ethernet private line type services, we have to rely on the Layer 2 information to determine the performance of the network. Maintaining the customer's FCS, resulting in a "Path FCS", gives the SP an end-to-end error check. In the truest sense of the term pseudo-wire, we are using a PSN to emulate an Ethernet-cable. It would be unacceptable if an Ethernet cable somehow corrupted the payload of the MAC frames without the FCS being able to detect it. It is just as unacceptable if that Ethernet cable is composed of packet switched networks instead of twisted pairs. Admittedly, if such internal errors occur in network devices, having a "Path FCS" will not tell me which switch is errant. However, it will tell me a problem exists, hopefully prior to my customer's contacting me. Regards, Nick DelRegno _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: pwe3-ethernet-encap - FCS... Date: Fri, 18 Apr 2003 14:48:08 -0400 Lines: 21 Sender: pwe3-admin@ietf.org References: <017701c30499$e6408000$639232a6@maggot> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Apr 18 20:51:46 2003 Return-path: To: "Christopher N. \"Nick\" DelRegno" In-reply-to: Your message of Wed, 16 Apr 2003 23:29:07 -0500. <017701c30499$e6408000$639232a6@maggot> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Nick> Apparently one of the Ethernet switches in the network was internally Nick> corrupting the data between the discarding of the customer FCS and the Nick> calculation of a new FCS. Well, this is a classic; you wouldn't believe how many IP routers I've run across that modify the header and then recompute the header checksum from scratch. Generally though a box that corrupts the data internally would not make it past beta test. Further, in routed networks, if a box is corrupting the data, there is no detecting it until you reach the TCP layer at the destination host. Nick> What I am asking is that we have an option to keep or discard the FCS Nick> and signal accordingly. I don't think that's unreasonable, but would like to see more input on whether it is worthwhile to have the network protect against "in-box" corruption (as opposed to "on wire" corruption) in the special case where the packets being carried are PWE3 ethernet packets. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Christopher N. \"Nick\" DelRegno" Subject: RE: pwe3-ethernet-encap - FCS... Date: Fri, 18 Apr 2003 14:07:49 -0500 Organization: WorldCom, Global Access Technology Development Lines: 59 Sender: pwe3-admin@ietf.org References: <200304181848.h3IIm9B0010682@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Apr 18 21:12:19 2003 Return-path: In-reply-to: <200304181848.h3IIm9B0010682@rtp-core-1.cisco.com> To: erosen@cisco.com, "'Christopher N. \"Nick\" DelRegno'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eric: I thought of the IP analogy as well and agree that such corruption is likely very rare. Regarding the problematic switch, it was only one faulty box out of several good one of the same make, model and software rev. Clearly it didn't act this way in QC. In some newer designs we have seen vendors implementing a sanity check on the payload content prior to recalculating the FCS. This would alleviate the situation, but is not universal. I am not asking the network to protect against "in-box" corruption. I am asking the network to not arbitrarily take away the protection which is already built in. Thanks, Nick -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Friday, April 18, 2003 1:48 PM To: Christopher N. "Nick" DelRegno Cc: pwe3@ietf.org Subject: Re: [PWE3] pwe3-ethernet-encap - FCS... Nick> Apparently one of the Ethernet switches in the network was internally Nick> corrupting the data between the discarding of the customer FCS and the Nick> calculation of a new FCS. Well, this is a classic; you wouldn't believe how many IP routers I've run across that modify the header and then recompute the header checksum from scratch. Generally though a box that corrupts the data internally would not make it past beta test. Further, in routed networks, if a box is corrupting the data, there is no detecting it until you reach the TCP layer at the destination host. Nick> What I am asking is that we have an option to keep or discard the FCS Nick> and signal accordingly. I don't think that's unreasonable, but would like to see more input on whether it is worthwhile to have the network protect against "in-box" corruption (as opposed to "on wire" corruption) in the special case where the packets being carried are PWE3 ethernet packets. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Mon, 21 Apr 2003 18:16:40 +0300 Lines: 19 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Mon Apr 21 17:23:03 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcMD/RfD6iKt0UHbTBu+wLwPfUuA6QEGzBfw To: "Alik Shimelmits" , "Ron Cohen" , , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3LFQ8804989 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi all, >From what Alik and Ron have said, RTP should ONLY be used with UDP, and NOT with MPLS. If this is indeed the case, then its use contradicts the goal of PWs being PSN-agnostic. As I remember it, the architecture draft specifically depicts RTP for the MPLS case. More importantly, if RTP is actually needed for the IP case (e.g. for carrying TDM or other RT traffic) why does the need disappear for MPLS? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Alik Shimelmits Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Mon, 21 Apr 2003 18:23:55 +0200 Lines: 15 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Mon Apr 21 17:33:14 2003 Return-path: To: "'Yaakov Stein'" , Ron Cohen , stbryant@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, >Hi all, > >From what Alik and Ron have said, >RTP should ONLY be used with UDP, >and NOT with MPLS. This is NOT what I said. Regards Alik Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Peter Willis Subject: Re: pwe3-ethernet-encap - FCS... Date: Tue, 22 Apr 2003 11:00:59 +0100 Lines: 29 Sender: pwe3-admin@ietf.org References: <00c801c305dd$ce2e7bd0$2d7a32a6@maggot> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 22 12:08:45 2003 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: "Christopher N. \"Nick\" DelRegno" In-reply-to: Your message of "Fri, 18 Apr 2003 14:07:49 CDT." <00c801c305dd$ce2e7bd0$2d7a32a6@maggot> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I thought of the IP analogy as well and agree that such corruption is > likely very rare. Reminds me that some vendors used ECC memory & some didn't. > > Regarding the problematic switch, it was only one faulty box out of > several good one of the same make, model and software rev. Clearly it > didn't act this way in QC. I've seen similar faults as well. > I am not asking the network to protect against "in-box" corruption. I > am asking the network to not arbitrarily take away the protection which > is already built in. > It is also essential to be able to locate the faulty box. Remember boxes break and when one has a large network even "very rare" faults happen. And the "rarer" the fault the harder it is to find. Given the choice between a dozen common faults or 1 rare one I'd pick the dozen common faults. So consider that my input on whether it is worthwhile to have the network protect against "in-box" corruption. Peter. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Tue, 22 Apr 2003 07:17:41 -0700 Lines: 57 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" X-From: pwe3-admin@ietf.org Tue Apr 22 16:27:09 2003 Return-path: To: "'Akiva Sadovski'" , "'Ron Cohen '" , "''Yaakov Stein' '" , "'stbryant@cisco.com '" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I think it should be possible. -Shahram >-----Original Message----- >From: Akiva Sadovski [mailto:akiva@AXERRA.com] >Sent: Friday, April 18, 2003 4:30 AM >To: 'Ron Cohen '; Shahram Davari; ''Yaakov Stein' '; >'stbryant@cisco.com '; 'pwe3@ietf.org ' >Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > >Shaharam and Ron, > Just a naive question: why can't we assign TWO MPLS PIDs: > -- one value for PW with RTP > -- and another for PW without RTP ? >Are we limited in the nuber of PIDs to use ? > >Regards, > Akiva Sadovski > >-----Original Message----- >From: Ron Cohen >To: 'Shahram Davari'; 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org >Sent: 17/04/2003 13:03 >Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > >Shahram, > >> > Therefore, when RTP is run over MPLS, the recommendation >> would be to >> > use the MPLS PID. >> >> So are you suggesting the MPLS PID should be set a value that >> is assigned to RTP? >> > >Yes. > >Ron > > >> -Shahram >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Tue, 22 Apr 2003 21:04:55 +0200 Lines: 51 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5283B3C2@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Apr 22 20:17:00 2003 Return-path: To: "'Yaakov Stein'" , "'Alik Shimelmits'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5283B3C2@exrad2.ad.rad.co.il> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, Let me try again. In order to run RTP over an MPLS core, one can run: MPLS->VC-label->RTP->CW->Data And if IP flow identification is required (ECMP and the like) one would use: MPLS->VC-label->MPLS PID->RTP->CW->Data. Hope this helps Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Yaakov Stein > Sent: Monday, April 21, 2003 5:17 PM > To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > Hi all, > > >From what Alik and Ron have said, > RTP should ONLY be used with UDP, > and NOT with MPLS. > > If this is indeed the case, > then its use contradicts the goal > of PWs being PSN-agnostic. > > As I remember it, the architecture draft > specifically depicts RTP for the MPLS case. > > More importantly, if RTP is actually needed > for the IP case (e.g. for carrying TDM or other RT traffic) > why does the need disappear for MPLS? > > > Y(J)S > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 24 Apr 2003 14:27:55 +0300 Lines: 24 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Thu Apr 24 13:31:40 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcMI+ehH+JJ2mQDORF6aWHGAUqXSvQBWm08g To: "Ron Cohen" , "Alik Shimelmits" , , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3OBSw801067 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Yaakov, > > Let me try again. > > In order to run RTP over an MPLS core, one can run: > > MPLS->VC-label->RTP->CW->Data > > And if IP flow identification is required (ECMP and the like) > one would use: > > MPLS->VC-label->MPLS PID->RTP->CW->Data. > > Hope this helps > Ron It helps clarify what you mean. I assume by MPLS PID you mean four bytes, the first of which contains the PID bits. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-allan-mpls-a-bit-00.txt Date: Thu, 24 Apr 2003 07:31:40 -0400 Lines: 79 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: mpls@uu.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 24 13:36:01 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Case for the 'A' Bit in the MPLS and IP PID Author(s) : D. Allan Filename : draft-allan-mpls-a-bit-00.txt Pages : 8 Date : 2003-4-23 This memo describes the underlying rationale for inclusion of the LSR alert bit in the proposed MPLS payload ID. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-allan-mpls-a-bit-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-allan-mpls-a-bit-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-allan-mpls-a-bit-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 24 Apr 2003 15:20:58 +0200 Lines: 31 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5281ACE6@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Apr 24 14:27:06 2003 Return-path: To: "'Yaakov Stein'" , "'Alik Shimelmits'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5281ACE6@exrad2.ad.rad.co.il> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yakkov, > > Yaakov, > > > > Let me try again. > > > > In order to run RTP over an MPLS core, one can run: > > > > MPLS->VC-label->RTP->CW->Data > > > > And if IP flow identification is required (ECMP and the like) > > one would use: > > > > MPLS->VC-label->MPLS PID->RTP->CW->Data. > > > > Hope this helps > > Ron > > It helps clarify what you mean. > > I assume by MPLS PID you mean four bytes, > the first of which contains the PID bits. Yes. Ron > > Y(J)S > > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: lidefeng Subject: What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Fri, 25 Apr 2003 11:05:44 +0800 Lines: 15 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Fri Apr 25 05:12:22 2003 Return-path: To: pwe3@ietf.org, ppvpn@nortelnetworks.com X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] Status: O Hi,all, Could anyone please tell me the difference between the Ethernet Service in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site attached to VPLS when there is need to access each other? And how to process mac learning,flooding address unknows unicast,broadcast and multicast frames in PWE3? Regards Li Defeng From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Fri, 25 Apr 2003 11:56:36 +0100 Organization: Cisco Systems, Inc. Lines: 32 References: <003901c30ad7$901138c0$07436e0a@HUAWEI.COM> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, ppvpn@nortelnetworks.com X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Fri Apr 25 12:58:13 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: lidefeng X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: stbryant@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] Status: O PWE3 simply provides a point to point "wire" capable of carrying Ethernet frames. How the frames are chosen for transmission on the "wire", and what happens at the far end of the "wire" is outside the scope of PWE3. VPLS uses PWE3 as a point to point service to carry Ethernet packets between its PEs. Stewart lidefeng wrote: > Hi,all, > > Could anyone please tell me the difference between the Ethernet Service > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > attached to VPLS when there is > need to access each other? And how to process mac learning,flooding address > unknows unicast,broadcast and multicast frames in PWE3? > > Regards > > Li Defeng > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Rick Osteen" Subject: Re: What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Mon, 28 Apr 2003 20:59:15 -0400 Lines: 31 Sender: pwe3-admin@ietf.org References: <003901c30ad7$901138c0$07436e0a@HUAWEI.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Apr 29 03:05:05 2003 Return-path: To: "lidefeng" , , X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Please remember, VPLS is "Cisco Centric". Their marketing department does a good job of placing a technological name/acronym onto a real name draft/technology. ----- Original Message ----- From: "lidefeng" To: ; Sent: Thursday, April 24, 2003 11:05 PM Subject: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? > Hi,all, > > Could anyone please tell me the difference between the Ethernet Service > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > attached to VPLS when there is > need to access each other? And how to process mac learning,flooding address > unknows unicast,broadcast and multicast frames in PWE3? > > Regards > > Li Defeng > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: "Vach Kompella" Subject: RE: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Mon, 28 Apr 2003 18:11:53 -0700 Lines: 67 References: <006201c30dea$8e744a00$dcac0944@ri.cox.net> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Tue Apr 29 03:10:51 2003 Return-path: To: "Rick Osteen" , "lidefeng" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <006201c30dea$8e744a00$dcac0944@ri.cox.net> X-OriginalArrivalTime: 29 Apr 2003 01:11:33.0360 (UTC) FILETIME=[45F47F00:01C30DEC] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] Status: O Rick, I beg to differ. Marc Lasserre (Riverstone) and I (TiMetra Networks) (along with a number of co-authors, not including cisco) wrote the original versions of VPLS. Those versions pre-date cisco's input. How do you come to the conclusion that VPLS is cisco-centric? If drafts are company-centric, then cisco shouldn't be the first one to spring to mind when you talk of VPLS. At least, not in my mind :-) Of course, some people have considerable marketing power... Every company wants to extract their marketing worth out of their employees' participation on drafts. But a draft presented at the IETF is NOT accepted as a company-centric draft; it is considered an individual submission until it is accepted as a working group document, and that with working group consensus. After that, it is the product of the working group. -Vach > -----Original Message----- > From: Rick Osteen [mailto:rick.osteen@cox.net] > Sent: Monday, April 28, 2003 5:59 PM > To: lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > Subject: Re: [PWE3] What is the difference between the Ethernet > Service in PWE3 and VPLS? > > > Please remember, VPLS is "Cisco Centric". Their marketing department does a > good job of placing a technological name/acronym onto a real name > draft/technology. > > > ----- Original Message ----- > From: "lidefeng" > To: ; > Sent: Thursday, April 24, 2003 11:05 PM > Subject: [PWE3] What is the difference between the Ethernet Service in PWE3 > and VPLS? > > > > Hi,all, > > > > Could anyone please tell me the difference between the Ethernet > Service > > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > > attached to VPLS when there is > > need to access each other? And how to process mac learning,flooding > address > > unknows unicast,broadcast and multicast frames in PWE3? > > > > Regards > > > > Li Defeng > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Du Wenhua Subject: Re: RE: [PWE3] What is the difference between the Ethernet Service in PWE3and VPLS? Date: Tue, 29 Apr 2003 11:28:58 +0800 Lines: 129 Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Tue Apr 29 05:28:50 2003 Return-path: To: "vkompella@timetra.com" , Rick Osteen , lidefeng , "pwe3@ietf.org" , "ppvpn@nortelnetworks.com" X-Mailer: Foxmail 4.2 [cn] X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] Status: O Hi, Vach Kompella =09I know Lasserre and you are the authors, and I suport HVPLS to= become a working group draft. How do you think about the correspondence between a P-VLAN= and a VPLS instance as follow? In setction 11 of the draft-lasserre-vkompella-ppvpn-vpls-04.txt,= it say: * 11. Hierarchical VPLS model using Ethernet Access Network ..... * One approach of tunneling a customer?s Ethernet traffic via= an * Ethernet access network is to add an additional VLAN tag to= the * customer?s data (either tagged or untagged). The additional= tag is * referred to as Provider?s VLAN (P-VLAN). Inside the= provider?s * network each P-VLAN designates a customer or more= specifically a VPLS ** instance for that customer. Therefore, there is a one to one= ** correspondence between a P-VLAN and a VPLS instance. In my option, the last sentece in above is not true. There is= also a many-to-one correspondence between a P-VLAN and a VPLS= instance, not only a one-to-one. i.e, a customer with P-VLAN 3= and another customer with P-VLAN 4 belong to the same VPLS. Much more, to PE-rs the ethernet port is not a traditional= standard port. When flooding, PE-rs need to send more than one= copy for each ehternet port, because there are serveral= custumers in one ethernet port each have different P-VLAN. =09=09=09=09 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12003-04-29 At 18:11:00 2003-04-28, Vach Kompella wrote: >>Rick, > >I beg to differ. Marc Lasserre (Riverstone) and I (TiMetra= Networks) (along >with a number of co-authors, not including cisco) wrote the= original versions of >VPLS. Those versions pre-date cisco's input. How do you come= to the conclusion >that VPLS is cisco-centric? > >If drafts are company-centric, then cisco shouldn't be the first= one to spring >to mind when you talk of VPLS. At least, not in my mind :-) Of= course, some >people have considerable marketing power... > >Every company wants to extract their marketing worth out of= their employees' >participation on drafts. But a draft presented at the IETF is= NOT accepted as a >company-centric draft; it is considered an individual submission= until it is >accepted as a working group document, and that with working= group consensus. >After that, it is the product of the working group. > >-Vach > >> -----Original Message----- >> From: Rick Osteen [mailto:rick.osteen@cox.net] >> Sent: Monday, April 28, 2003 5:59 PM >> To: lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com >> Subject: Re: [PWE3] What is the difference between the= Ethernet >> Service in PWE3 and VPLS? >> >> >> Please remember, VPLS is "Cisco Centric". Their marketing= department does a >> good job of placing a technological name/acronym onto a real= name >> draft/technology. >> >> >> ----- Original Message ----- >> From: "lidefeng" >> To: ; >> Sent: Thursday, April 24, 2003 11:05 PM >> Subject: [PWE3] What is the difference between the Ethernet= Service in PWE3 >> and VPLS? >> >> >> > Hi,all, >> > >> > Could anyone please tell me the difference between the= Ethernet >> Service >> > in PWE3 and VPLS,how to interoperte the site attached to= PWE3 and the site >> > attached to VPLS when there is >> > need to access each other? And how to process mac= learning,flooding >> address >> > unknows unicast,broadcast and multicast frames in PWE3? >> > >> > Regards >> > >> > Li Defeng >> > >> > _______________________________________________ >> > pwe3 mailing list >> > pwe3@ietf.org >> > https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> >> =09=09=09 From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: "Vach Kompella" Subject: RE: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Mon, 28 Apr 2003 20:50:23 -0700 Lines: 91 References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Tue Apr 29 05:49:48 2003 Return-path: To: , "Rick Osteen" , "lidefeng" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: X-OriginalArrivalTime: 29 Apr 2003 03:50:04.0860 (UTC) FILETIME=[6B4037C0:01C30E02] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] Status: O That was a little brusque. Individuals who work for TiMetra, Riverstone, PacketExchange, cisco, Hatteras, SBC, Masergy, Level3, and some who are true individual contributors, have assisted and in very helpful ways. I object to it being called cisco-centric. One hopes that the IETF doesn't descend to drafts being company-centric. -Vach > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetra.com] > Sent: Monday, April 28, 2003 6:12 PM > To: Rick Osteen; lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > Subject: RE: [PWE3] What is the difference between the Ethernet > Service in PWE3 and VPLS? > > > Rick, > > I beg to differ. Marc Lasserre (Riverstone) and I (TiMetra Networks) (along > with a number of co-authors, not including cisco) wrote the original > versions of > VPLS. Those versions pre-date cisco's input. How do you come to the > conclusion > that VPLS is cisco-centric? > > If drafts are company-centric, then cisco shouldn't be the first one to spring > to mind when you talk of VPLS. At least, not in my mind :-) Of course, some > people have considerable marketing power... > > Every company wants to extract their marketing worth out of their employees' > participation on drafts. But a draft presented at the IETF is NOT > accepted as a > company-centric draft; it is considered an individual submission until it is > accepted as a working group document, and that with working group consensus. > After that, it is the product of the working group. > > -Vach > > > -----Original Message----- > > From: Rick Osteen [mailto:rick.osteen@cox.net] > > Sent: Monday, April 28, 2003 5:59 PM > > To: lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > > Subject: Re: [PWE3] What is the difference between the Ethernet > > Service in PWE3 and VPLS? > > > > > > Please remember, VPLS is "Cisco Centric". Their marketing department does a > > good job of placing a technological name/acronym onto a real name > > draft/technology. > > > > > > ----- Original Message ----- > > From: "lidefeng" > > To: ; > > Sent: Thursday, April 24, 2003 11:05 PM > > Subject: [PWE3] What is the difference between the Ethernet Service in PWE3 > > and VPLS? > > > > > > > Hi,all, > > > > > > Could anyone please tell me the difference between the Ethernet > > Service > > > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > > > attached to VPLS when there is > > > need to access each other? And how to process mac learning,flooding > > address > > > unknows unicast,broadcast and multicast frames in PWE3? > > > > > > Regards > > > > > > Li Defeng > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: "Rick Osteen" Subject: Re: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Tue, 29 Apr 2003 06:54:05 -0400 Lines: 124 References: Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Tue Apr 29 12:54:06 2003 Return-path: To: , "lidefeng" , , X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: lakemtao01.cox.net X-SMTP-MAIL-FROM: rick.osteen@cox.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: lakemtao01.cox.net [68.1.17.244] Status: O All, My apologies. I suppose I've been to one too many presentations and did not intend to stir trouble. Thanks, Rick Osteen ----- Original Message ----- From: "Vach Kompella" To: ; "Rick Osteen" ; "lidefeng" ; ; Sent: Monday, April 28, 2003 11:50 PM Subject: RE: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? > That was a little brusque. Individuals who work for TiMetra, Riverstone, > PacketExchange, cisco, Hatteras, SBC, Masergy, Level3, and some who are true > individual contributors, have assisted and in very helpful ways. I object to it > being called cisco-centric. One hopes that the IETF doesn't descend to drafts > being company-centric. > > -Vach > > > -----Original Message----- > > From: Vach Kompella [mailto:vkompella@timetra.com] > > Sent: Monday, April 28, 2003 6:12 PM > > To: Rick Osteen; lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > > Subject: RE: [PWE3] What is the difference between the Ethernet > > Service in PWE3 and VPLS? > > > > > > Rick, > > > > I beg to differ. Marc Lasserre (Riverstone) and I (TiMetra Networks) (along > > with a number of co-authors, not including cisco) wrote the original > > versions of > > VPLS. Those versions pre-date cisco's input. How do you come to the > > conclusion > > that VPLS is cisco-centric? > > > > If drafts are company-centric, then cisco shouldn't be the first one to spring > > to mind when you talk of VPLS. At least, not in my mind :-) Of course, some > > people have considerable marketing power... > > > > Every company wants to extract their marketing worth out of their employees' > > participation on drafts. But a draft presented at the IETF is NOT > > accepted as a > > company-centric draft; it is considered an individual submission until it is > > accepted as a working group document, and that with working group consensus. > > After that, it is the product of the working group. > > > > -Vach > > > > > -----Original Message----- > > > From: Rick Osteen [mailto:rick.osteen@cox.net] > > > Sent: Monday, April 28, 2003 5:59 PM > > > To: lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > > > Subject: Re: [PWE3] What is the difference between the Ethernet > > > Service in PWE3 and VPLS? > > > > > > > > > Please remember, VPLS is "Cisco Centric". Their marketing department does a > > > good job of placing a technological name/acronym onto a real name > > > draft/technology. > > > > > > > > > ----- Original Message ----- > > > From: "lidefeng" > > > To: ; > > > Sent: Thursday, April 24, 2003 11:05 PM > > > Subject: [PWE3] What is the difference between the Ethernet Service in PWE3 > > > and VPLS? > > > > > > > > > > Hi,all, > > > > > > > > Could anyone please tell me the difference between the Ethernet > > > Service > > > > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > > > > attached to VPLS when there is > > > > need to access each other? And how to process mac learning,flooding > > > address > > > > unknows unicast,broadcast and multicast frames in PWE3? > > > > > > > > Regards > > > > > > > > Li Defeng > > > > > > > > _______________________________________________ > > > > pwe3 mailing list > > > > pwe3@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: Arch sections 5.4.3 and 5.4.4 Date: Tue, 29 Apr 2003 12:38:57 +0100 Organization: Cisco Systems, Inc. Lines: 162 Sender: pwe3-admin@ietf.org References: <002f01c30902$1447a4d0$6d001aac@lycium.net> <3EAE629B.6060904@cisco.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Apr 29 13:49:51 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "pwe3@ietf.org" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I cut and paste from the wrong version of the base document the current version is actually: +---------------------+ | Payload | /=====================\\ H Payload Convergence H-----+ H---------------------H | H Timing H------------------------+ H---------------------H | | H Sequencing H-----| | \\=====================/ | | | PW Demultiplexer |---+ | v +---------------------+ | | +--------------------------------+ | PSN Convergence |-----| . . +---------------------+ | | . RTP . | PSN |-+ | | | | +---------------------+ | | | +--------------------------------+ | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | +---------------------+ | | +--------------------------------+ | Physical | | | | MPLS Payl'd Type Indent | +---------------------+ | | +--------------------------------+ | +--->| PW Label | | +--------------------------------+ +----->| Outer Label or MPLS-in-IP encap| +--------------------------------+ but the question remains, should we swap RTP and the CW? Stewart Stewart Bryant wrote: > > Is the WG concensus: > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H------------------------+ > H---------------------H | | > H Sequencing H-----| | > \=====================/ | | > | PW Demultiplexer |---+ | v > +---------------------+ | | +--------------------------------+ > | PSN Convergence |-----| . . > +---------------------+ | | . RTP . > | PSN |-+ | | | | > +---------------------+ | | | +--------------------------------+ > | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | Physical | | +--->| PW Label | > +---------------------+ | +--------------------------------+ > +----->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > Which is what the current text says, or is it: > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H-------+ > H---------------------H | | > H Sequencing H-----+ | > \=====================/ | | > | PW Demultiplexer |---+ | | > +---------------------+ | | | +--------------------------------+ > | PSN Convergence |-----+--->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | PSN |-+ | | | | > +---------------------+ | | +->. RTP . > | MAC/Data-link | | | | | > +---------------------+ | | +--------------------------------+ > | Physical | | +----->| PW Label | > +---------------------+ | +--------------------------------+ > +------->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > Figure 11: PWE3 over an MPLS PSN using a control word > > > Which is what this thread seems to conclude? > > Thanks > > Stewart > > > > Ron Cohen wrote: > >> Yaakov, >> >> Let me try again. >> >> In order to run RTP over an MPLS core, one can run: >> >> MPLS->VC-label->RTP->CW->Data >> >> And if IP flow identification is required (ECMP and the like) one would >> use: >> >> MPLS->VC-label->MPLS PID->RTP->CW->Data. >> >> Hope this helps >> Ron >> >> >> >> >>> -----Original Message----- >>> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of >>> Yaakov Stein >>> Sent: Monday, April 21, 2003 5:17 PM >>> To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; pwe3@ietf.org >>> Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 >>> >>> >>> Hi all, >>> >>>> From what Alik and Ron have said, >>> >>> RTP should ONLY be used with UDP, >>> and NOT with MPLS. >>> >>> If this is indeed the case, then its use contradicts the goal >>> of PWs being PSN-agnostic. >>> >>> As I remember it, the architecture draft >>> specifically depicts RTP for the MPLS case. >>> >>> More importantly, if RTP is actually needed for the IP case (e.g. for >>> carrying TDM or other RT traffic) >>> why does the need disappear for MPLS? >>> >>> >>> Y(J)S >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >> >> >> >> >> > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Tue, 29 Apr 2003 17:03:39 +0200 Lines: 215 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org, "Ron Cohen (E-mail)" , Alik Shimelmits X-From: pwe3-admin@ietf.org Tue Apr 29 16:22:23 2003 Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, I think that Ron Cohen has answered this question at least twice on this mailing list: the RTP header, if used, MUST immediately follow the demultiplexor (whatever it happens to be) and MUST be immediately followed by the CW. There are at least two valid reasons for that: 1. This coresponds to the recommendations on the RTP payload formats with the CW acting as the "payload header" in terms of Section 4.1 of RFC 2736. And, if IP/UDP is used as the Transport/demultiplexing, it corresponds to the common usage of RTP (including RTP header compression etc.) 2. This greatly simplifies implementations that allow inclusion and suppression of RTP header. E.g., the value of the structure pointer (or the rules of its application) in draft-ietf-pwe3-sonet-01.txt will not depend on the presence or absense of the RTP header in the encapsulation. Hopefully this note clarifies the issue. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, April 29, 2003 1:39 PM > To: pwe3@ietf.org > Subject: Re: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > I cut and paste from the wrong version of the base document > the current version is actually: > > +---------------------+ > | Payload | > /=====================\\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H------------------------+ > H---------------------H | | > H Sequencing H-----| | > \\=====================/ | | > | PW Demultiplexer |---+ | v > +---------------------+ | | +--------------------------------+ > | PSN Convergence |-----| . . > +---------------------+ | | . RTP . > | PSN |-+ | | | | > +---------------------+ | | | +--------------------------------+ > | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | Physical | | | | MPLS Payl'd Type Indent | > +---------------------+ | | +--------------------------------+ > | +--->| PW Label | > | +--------------------------------+ > +----->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > but the question remains, should we swap RTP and the CW? > > Stewart > > > > > Stewart Bryant wrote: > > > > Is the WG concensus: > > > > +---------------------+ > > | Payload | > > /=====================\ > > H Payload Convergence H-----+ > > H---------------------H | > > H Timing H------------------------+ > > H---------------------H | | > > H Sequencing H-----| | > > \=====================/ | | > > | PW Demultiplexer |---+ | v > > +---------------------+ | | +--------------------------------+ > > | PSN Convergence |-----| . . > > +---------------------+ | | . RTP . > > | PSN |-+ | | | | > > +---------------------+ | | | +--------------------------------+ > > | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > > +---------------------+ | | +--------------------------------+ > > | Physical | | +--->| PW Label | > > +---------------------+ | +--------------------------------+ > > +----->| Outer Label or MPLS-in-IP encap| > > +--------------------------------+ > > > > > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > > > Which is what the current text says, or is it: > > > > +---------------------+ > > | Payload | > > /=====================\ > > H Payload Convergence H-----+ > > H---------------------H | > > H Timing H-------+ > > H---------------------H | | > > H Sequencing H-----+ | > > \=====================/ | | > > | PW Demultiplexer |---+ | | > > +---------------------+ | | | > +--------------------------------+ > > | PSN Convergence |-----+--->| Flags, Frag, Len, Seq > #, etc | > > +---------------------+ | | > +--------------------------------+ > > | PSN |-+ | | | > | > > +---------------------+ | | +->. RTP > . > > | MAC/Data-link | | | | > | > > +---------------------+ | | > +--------------------------------+ > > | Physical | | +----->| PW Label > | > > +---------------------+ | > +--------------------------------+ > > +------->| Outer Label or > MPLS-in-IP encap| > > > +--------------------------------+ > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > > > > > Which is what this thread seems to conclude? > > > > Thanks > > > > Stewart > > > > > > > > Ron Cohen wrote: > > > >> Yaakov, > >> > >> Let me try again. > >> > >> In order to run RTP over an MPLS core, one can run: > >> > >> MPLS->VC-label->RTP->CW->Data > >> > >> And if IP flow identification is required (ECMP and the > like) one would > >> use: > >> > >> MPLS->VC-label->MPLS PID->RTP->CW->Data. > >> > >> Hope this helps > >> Ron > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of > >>> Yaakov Stein > >>> Sent: Monday, April 21, 2003 5:17 PM > >>> To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; pwe3@ietf.org > >>> Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > >>> > >>> > >>> Hi all, > >>> > >>>> From what Alik and Ron have said, > >>> > >>> RTP should ONLY be used with UDP, > >>> and NOT with MPLS. > >>> > >>> If this is indeed the case, then its use contradicts the goal > >>> of PWs being PSN-agnostic. > >>> > >>> As I remember it, the architecture draft > >>> specifically depicts RTP for the MPLS case. > >>> > >>> More importantly, if RTP is actually needed for the IP > case (e.g. for > >>> carrying TDM or other RT traffic) > >>> why does the need disappear for MPLS? > >>> > >>> > >>> Y(J)S > >>> _______________________________________________ > >>> pwe3 mailing list > >>> pwe3@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pwe3 > >>> > >>> > >> > >> > >> > >> > >> > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Tue, 29 Apr 2003 13:38:43 -0400 Lines: 229 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'stbryant@cisco.com'" , pwe3@ietf.org, "Ron Cohen (E-mail)" , Alik Shimelmits X-From: pwe3-admin@ietf.org Tue Apr 29 19:44:23 2003 Return-path: X-Sender: andymalis@mail.attbi.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Sasha Vainshtein In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I would like to support Sasha's reply. RTP should immediately precede, not follow, the CW. Cheers, Andy ------- At 4/29/2003 05:03 PM +0200, Sasha Vainshtein wrote: >Stewart, >I think that Ron Cohen has answered this question at least twice on this >mailing list: the RTP header, if used, MUST immediately follow the >demultiplexor (whatever it happens to be) and MUST be immediately followed >by the CW. There are at least two valid reasons for that: >1. This coresponds to the recommendations on the RTP payload formats with >the CW acting as the "payload header" in terms of Section 4.1 of RFC 2736. >And, if IP/UDP is used as the Transport/demultiplexing, it corresponds to >the common usage of RTP (including RTP header compression etc.) >2. This greatly simplifies implementations that allow inclusion and >suppression of RTP header. E.g., the value of the structure pointer (or the >rules of its application) in draft-ietf-pwe3-sonet-01.txt will not depend on >the presence or absense of the RTP header in the encapsulation. > >Hopefully this note clarifies the issue. >---------------------------------------------------------------------------- >-------- >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) > > > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Tuesday, April 29, 2003 1:39 PM > > To: pwe3@ietf.org > > Subject: Re: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > > > I cut and paste from the wrong version of the base document > > the current version is actually: > > > > +---------------------+ > > | Payload | > > /=====================\\ > > H Payload Convergence H-----+ > > H---------------------H | > > H Timing H------------------------+ > > H---------------------H | | > > H Sequencing H-----| | > > \\=====================/ | | > > | PW Demultiplexer |---+ | v > > +---------------------+ | | +--------------------------------+ > > | PSN Convergence |-----| . . > > +---------------------+ | | . RTP . > > | PSN |-+ | | | | > > +---------------------+ | | | +--------------------------------+ > > | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > > +---------------------+ | | +--------------------------------+ > > | Physical | | | | MPLS Payl'd Type Indent | > > +---------------------+ | | +--------------------------------+ > > | +--->| PW Label | > > | +--------------------------------+ > > +----->| Outer Label or MPLS-in-IP encap| > > +--------------------------------+ > > > > but the question remains, should we swap RTP and the CW? > > > > Stewart > > > > > > > > > > Stewart Bryant wrote: > > > > > > Is the WG concensus: > > > > > > +---------------------+ > > > | Payload | > > > /=====================\ > > > H Payload Convergence H-----+ > > > H---------------------H | > > > H Timing H------------------------+ > > > H---------------------H | | > > > H Sequencing H-----| | > > > \=====================/ | | > > > | PW Demultiplexer |---+ | v > > > +---------------------+ | | +--------------------------------+ > > > | PSN Convergence |-----| . . > > > +---------------------+ | | . RTP . > > > | PSN |-+ | | | | > > > +---------------------+ | | | +--------------------------------+ > > > | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > > > +---------------------+ | | +--------------------------------+ > > > | Physical | | +--->| PW Label | > > > +---------------------+ | +--------------------------------+ > > > +----->| Outer Label or MPLS-in-IP encap| > > > +--------------------------------+ > > > > > > > > > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > > > > > Which is what the current text says, or is it: > > > > > > +---------------------+ > > > | Payload | > > > /=====================\ > > > H Payload Convergence H-----+ > > > H---------------------H | > > > H Timing H-------+ > > > H---------------------H | | > > > H Sequencing H-----+ | > > > \=====================/ | | > > > | PW Demultiplexer |---+ | | > > > +---------------------+ | | | > > +--------------------------------+ > > > | PSN Convergence |-----+--->| Flags, Frag, Len, Seq > > #, etc | > > > +---------------------+ | | > > +--------------------------------+ > > > | PSN |-+ | | | > > | > > > +---------------------+ | | +->. RTP > > . > > > | MAC/Data-link | | | | > > | > > > +---------------------+ | | > > +--------------------------------+ > > > | Physical | | +----->| PW Label > > | > > > +---------------------+ | > > +--------------------------------+ > > > +------->| Outer Label or > > MPLS-in-IP encap| > > > > > +--------------------------------+ > > > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > > > > > > > > Which is what this thread seems to conclude? > > > > > > Thanks > > > > > > Stewart > > > > > > > > > > > > Ron Cohen wrote: > > > > > >> Yaakov, > > >> > > >> Let me try again. > > >> > > >> In order to run RTP over an MPLS core, one can run: > > >> > > >> MPLS->VC-label->RTP->CW->Data > > >> > > >> And if IP flow identification is required (ECMP and the > > like) one would > > >> use: > > >> > > >> MPLS->VC-label->MPLS PID->RTP->CW->Data. > > >> > > >> Hope this helps > > >> Ron > > >> > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of > > >>> Yaakov Stein > > >>> Sent: Monday, April 21, 2003 5:17 PM > > >>> To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; pwe3@ietf.org > > >>> Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > >>> > > >>> > > >>> Hi all, > > >>> > > >>>> From what Alik and Ron have said, > > >>> > > >>> RTP should ONLY be used with UDP, > > >>> and NOT with MPLS. > > >>> > > >>> If this is indeed the case, then its use contradicts the goal > > >>> of PWs being PSN-agnostic. > > >>> > > >>> As I remember it, the architecture draft > > >>> specifically depicts RTP for the MPLS case. > > >>> > > >>> More importantly, if RTP is actually needed for the IP > > case (e.g. for > > >>> carrying TDM or other RT traffic) > > >>> why does the need disappear for MPLS? > > >>> > > >>> > > >>> Y(J)S > > >>> _______________________________________________ > > >>> pwe3 mailing list > > >>> pwe3@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/pwe3 > > >>> > > >>> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Tue, 29 Apr 2003 21:37:26 +0200 Lines: 218 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B3FB05F@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Apr 29 20:42:33 2003 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <89D0584BBFBFE74F9057A389BA3F239B3FB05F@gaya.lycium.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, I'm with Andy and Sasha. I do have a remark on the PSN convergence layer location. I view the MPLS PID as a PSN convergence layer for MPLS. The PW Demultiplexing layer in MPLS is just another label. Therefore the right layering would be: PSN > PW demultiplexing > PSN convergence > RTP > CW > Payload Which would work nicely with IP PSN: IP > UDP > RTP > CW > Payload And with MPLS PSN: MPLS > VC-label > MPLS PID > RTP > CW > Payload. Where the RTP and MPLS PID are optional. Thanks Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Stewart Bryant > Sent: Tuesday, April 29, 2003 1:39 PM > To: pwe3@ietf.org > Subject: Re: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > I cut and paste from the wrong version of the base document > the current version is actually: > > +---------------------+ > | Payload | > /=====================\\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H------------------------+ > H---------------------H | | > H Sequencing H-----| | > \\=====================/ | | > | PW Demultiplexer |---+ | v > +---------------------+ | | +--------------------------------+ > | PSN Convergence |-----| . . > +---------------------+ | | . RTP . > | PSN |-+ | | | | > +---------------------+ | | | +--------------------------------+ > | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | Physical | | | | MPLS Payl'd Type Indent | > +---------------------+ | | +--------------------------------+ > | +--->| PW Label | > | +--------------------------------+ > +----->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > but the question remains, should we swap RTP and the CW? > > Stewart > > > > > Stewart Bryant wrote: > > > > Is the WG concensus: > > > > +---------------------+ > > | Payload | > > /=====================\ > > H Payload Convergence H-----+ > > H---------------------H | > > H Timing H------------------------+ > > H---------------------H | | > > H Sequencing H-----| | > > \=====================/ | | > > | PW Demultiplexer |---+ | v > > +---------------------+ | | +--------------------------------+ > > | PSN Convergence |-----| . . > > +---------------------+ | | . RTP . > > | PSN |-+ | | | | > > +---------------------+ | | | +--------------------------------+ > > | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > > +---------------------+ | | +--------------------------------+ > > | Physical | | +--->| PW Label | > > +---------------------+ | +--------------------------------+ > > +----->| Outer Label or MPLS-in-IP encap| > > +--------------------------------+ > > > > > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > > > Which is what the current text says, or is it: > > > > +---------------------+ > > | Payload | > > /=====================\ > > H Payload Convergence H-----+ > > H---------------------H | > > H Timing H-------+ > > H---------------------H | | > > H Sequencing H-----+ | > > \=====================/ | | > > | PW Demultiplexer |---+ | | > > +---------------------+ | | | > +--------------------------------+ > > | PSN Convergence |-----+--->| Flags, Frag, Len, Seq > #, etc | > > +---------------------+ | | > +--------------------------------+ > > | PSN |-+ | | | > | > > +---------------------+ | | +->. RTP > . > > | MAC/Data-link | | | | > | > > +---------------------+ | | > +--------------------------------+ > > | Physical | | +----->| PW Label > | > > +---------------------+ | > +--------------------------------+ > > +------->| Outer Label or > MPLS-in-IP encap| > > > +--------------------------------+ > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > > > > > Which is what this thread seems to conclude? > > > > Thanks > > > > Stewart > > > > > > > > Ron Cohen wrote: > > > >> Yaakov, > >> > >> Let me try again. > >> > >> In order to run RTP over an MPLS core, one can run: > >> > >> MPLS->VC-label->RTP->CW->Data > >> > >> And if IP flow identification is required (ECMP and the like) one > >> would > >> use: > >> > >> MPLS->VC-label->MPLS PID->RTP->CW->Data. > >> > >> Hope this helps > >> Ron > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of > >>> Yaakov Stein > >>> Sent: Monday, April 21, 2003 5:17 PM > >>> To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; pwe3@ietf.org > >>> Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > >>> > >>> > >>> Hi all, > >>> > >>>> From what Alik and Ron have said, > >>> > >>> RTP should ONLY be used with UDP, > >>> and NOT with MPLS. > >>> > >>> If this is indeed the case, then its use contradicts the > goal of PWs > >>> being PSN-agnostic. > >>> > >>> As I remember it, the architecture draft > >>> specifically depicts RTP for the MPLS case. > >>> > >>> More importantly, if RTP is actually needed for the IP case (e.g. > >>> for > >>> carrying TDM or other RT traffic) > >>> why does the need disappear for MPLS? > >>> > >>> > >>> Y(J)S > >>> _______________________________________________ > >>> pwe3 mailing list > >>> pwe3@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pwe3 > >>> > >>> > >> > >> > >> > >> > >> > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: Arch sections 5.4.3 and 5.4.4 Date: Tue, 29 Apr 2003 12:31:39 +0100 Organization: Cisco Systems, Inc. Lines: 122 Sender: pwe3-admin@ietf.org References: <002f01c30902$1447a4d0$6d001aac@lycium.net> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron Cohen , "'Yaakov Stein'" , "'Alik Shimelmits'" X-From: pwe3-admin@ietf.org Wed Apr 30 02:20:14 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: pwe3@ietf.org Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Is the WG concensus: +---------------------+ | Payload | /=====================\ H Payload Convergence H-----+ H---------------------H | H Timing H------------------------+ H---------------------H | | H Sequencing H-----| | \=====================/ | | | PW Demultiplexer |---+ | v +---------------------+ | | +--------------------------------+ | PSN Convergence |-----| . . +---------------------+ | | . RTP . | PSN |-+ | | | | +---------------------+ | | | +--------------------------------+ | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc | +---------------------+ | | +--------------------------------+ | Physical | | +--->| PW Label | +---------------------+ | +--------------------------------+ +----->| Outer Label or MPLS-in-IP encap| +--------------------------------+ Figure 11: PWE3 over an MPLS PSN using a control word Which is what the current text says, or is it: +---------------------+ | Payload | /=====================\ H Payload Convergence H-----+ H---------------------H | H Timing H-------+ H---------------------H | | H Sequencing H-----+ | \=====================/ | | | PW Demultiplexer |---+ | | +---------------------+ | | | +--------------------------------+ | PSN Convergence |-----+--->| Flags, Frag, Len, Seq #, etc | +---------------------+ | | +--------------------------------+ | PSN |-+ | | | | +---------------------+ | | +->. RTP . | MAC/Data-link | | | | | +---------------------+ | | +--------------------------------+ | Physical | | +----->| PW Label | +---------------------+ | +--------------------------------+ +------->| Outer Label or MPLS-in-IP encap| +--------------------------------+ Figure 11: PWE3 over an MPLS PSN using a control word Which is what this thread seems to conclude? Thanks Stewart Ron Cohen wrote: > Yaakov, > > Let me try again. > > In order to run RTP over an MPLS core, one can run: > > MPLS->VC-label->RTP->CW->Data > > And if IP flow identification is required (ECMP and the like) one would > use: > > MPLS->VC-label->MPLS PID->RTP->CW->Data. > > Hope this helps > Ron > > > > >>-----Original Message----- >>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >>Behalf Of Yaakov Stein >>Sent: Monday, April 21, 2003 5:17 PM >>To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; pwe3@ietf.org >>Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 >> >> >>Hi all, >> >>>From what Alik and Ron have said, >>RTP should ONLY be used with UDP, >>and NOT with MPLS. >> >>If this is indeed the case, >>then its use contradicts the goal >>of PWs being PSN-agnostic. >> >>As I remember it, the architecture draft >>specifically depicts RTP for the MPLS case. >> >>More importantly, if RTP is actually needed >>for the IP case (e.g. for carrying TDM or other RT traffic) >>why does the need disappear for MPLS? >> >> >>Y(J)S >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Akiva Sadovski Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 09:36:36 +0200 Lines: 256 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Wed Apr 30 08:49:58 2003 Return-path: To: "'Ron Cohen'" , stbryant@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, Ron and all ... and i'm with Ron. Can we swap PW Demultiplexer and PSN Convergence layers in PW layering diagram ? We also can change the PW Demultiplexer layer name to Demultiplexer layer for those who'd like to deal with PW only "after" handling all PSN issues. Regards, Akiva Sadovski > -----Original Message----- > From: Ron Cohen [mailto:ronc@lyciumnetworks.com] > Sent: Tuesday, April 29, 2003 9:37 PM > To: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > Stewart, > > I'm with Andy and Sasha. > > I do have a remark on the PSN convergence layer location. I view the > MPLS PID as a PSN convergence layer for MPLS. The PW Demultiplexing > layer in MPLS is just another label. Therefore the right > layering would > be: > > PSN > PW demultiplexing > PSN convergence > RTP > CW > Payload > > Which would work nicely with IP PSN: > > IP > UDP > RTP > CW > Payload > > And with MPLS PSN: > > MPLS > VC-label > MPLS PID > RTP > CW > Payload. > > Where the RTP and MPLS PID are optional. > > Thanks > Ron > > > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Stewart Bryant > > Sent: Tuesday, April 29, 2003 1:39 PM > > To: pwe3@ietf.org > > Subject: Re: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > > > I cut and paste from the wrong version of the base document > > the current version is actually: > > > > +---------------------+ > > | Payload | > > /=====================\\ > > H Payload Convergence H-----+ > > H---------------------H | > > H Timing H------------------------+ > > H---------------------H | | > > H Sequencing H-----| | > > \\=====================/ | | > > | PW Demultiplexer |---+ | v > > +---------------------+ | | +--------------------------------+ > > | PSN Convergence |-----| . . > > +---------------------+ | | . RTP . > > | PSN |-+ | | | | > > +---------------------+ | | | +--------------------------------+ > > | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > > +---------------------+ | | +--------------------------------+ > > | Physical | | | | MPLS Payl'd Type Indent | > > +---------------------+ | | +--------------------------------+ > > | +--->| PW Label | > > | +--------------------------------+ > > +----->| Outer Label or MPLS-in-IP encap| > > +--------------------------------+ > > > > but the question remains, should we swap RTP and the CW? > > > > Stewart > > > > > > > > > > Stewart Bryant wrote: > > > > > > Is the WG concensus: > > > > > > +---------------------+ > > > | Payload | > > > /=====================\ > > > H Payload Convergence H-----+ > > > H---------------------H | > > > H Timing H------------------------+ > > > H---------------------H | | > > > H Sequencing H-----| | > > > \=====================/ | | > > > | PW Demultiplexer |---+ | v > > > +---------------------+ | | > +--------------------------------+ > > > | PSN Convergence |-----| . > . > > > +---------------------+ | | . RTP > . > > > | PSN |-+ | | | > | > > > +---------------------+ | | | > +--------------------------------+ > > > | MAC/Data-link | | | +->| Flags, Frag, Len, Seq > #, etc | > > > +---------------------+ | | > +--------------------------------+ > > > | Physical | | +--->| PW Label > | > > > +---------------------+ | > +--------------------------------+ > > > +----->| Outer Label or > MPLS-in-IP encap| > > > > +--------------------------------+ > > > > > > > > > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > > > > > Which is what the current text says, or is it: > > > > > > +---------------------+ > > > | Payload | > > > /=====================\ > > > H Payload Convergence H-----+ > > > H---------------------H | > > > H Timing H-------+ > > > H---------------------H | | > > > H Sequencing H-----+ | > > > \=====================/ | | > > > | PW Demultiplexer |---+ | | > > > +---------------------+ | | | > > +--------------------------------+ > > > | PSN Convergence |-----+--->| Flags, Frag, Len, Seq > > #, etc | > > > +---------------------+ | | > > +--------------------------------+ > > > | PSN |-+ | | | > > | > > > +---------------------+ | | +->. RTP > > . > > > | MAC/Data-link | | | | > > | > > > +---------------------+ | | > > +--------------------------------+ > > > | Physical | | +----->| PW Label > > | > > > +---------------------+ | > > +--------------------------------+ > > > +------->| Outer Label or > > MPLS-in-IP encap| > > > > > +--------------------------------+ > > > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > > > > > > > > Which is what this thread seems to conclude? > > > > > > Thanks > > > > > > Stewart > > > > > > > > > > > > Ron Cohen wrote: > > > > > >> Yaakov, > > >> > > >> Let me try again. > > >> > > >> In order to run RTP over an MPLS core, one can run: > > >> > > >> MPLS->VC-label->RTP->CW->Data > > >> > > >> And if IP flow identification is required (ECMP and the > like) one > > >> would > > >> use: > > >> > > >> MPLS->VC-label->MPLS PID->RTP->CW->Data. > > >> > > >> Hope this helps > > >> Ron > > >> > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of > > >>> Yaakov Stein > > >>> Sent: Monday, April 21, 2003 5:17 PM > > >>> To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; > pwe3@ietf.org > > >>> Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > >>> > > >>> > > >>> Hi all, > > >>> > > >>>> From what Alik and Ron have said, > > >>> > > >>> RTP should ONLY be used with UDP, > > >>> and NOT with MPLS. > > >>> > > >>> If this is indeed the case, then its use contradicts the > > goal of PWs > > >>> being PSN-agnostic. > > >>> > > >>> As I remember it, the architecture draft > > >>> specifically depicts RTP for the MPLS case. > > >>> > > >>> More importantly, if RTP is actually needed for the IP > case (e.g. > > >>> for > > >>> carrying TDM or other RT traffic) > > >>> why does the need disappear for MPLS? > > >>> > > >>> > > >>> Y(J)S > > >>> _______________________________________________ > > >>> pwe3 mailing list > > >>> pwe3@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/pwe3 > > >>> > > >>> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 09:55:34 +0200 Lines: 177 Sender: pwe3-admin@ietf.org References: <3EAE629B.6060904@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Yaakov Stein'" , "'Alik Shimelmits'" X-From: pwe3-admin@ietf.org Wed Apr 30 09:03:00 2003 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3EAE629B.6060904@cisco.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, In ASCII Art the layering should look like: +---------------------+ | Payload | /=====================\ H Payload Convergence H-------+ H---------------------H | H Timing H---------+ H---------------------H | | H Sequencing H-------+ | \=====================/ | | | PSN Convergence |-----+ | | +---------------------+ | | | +--------------------------------+ | PW Demultiplexer |---+ | +--->| Flags, Frag, Len, Seq #, etc | +---------------------+ | | | +--------------------------------+ | PSN |-+ | | +->| RTP | +---------------------+ | | | +--------------------------------+ | MAC/Data-link | | | +----->| MPLS PID | +---------------------+ | | +--------------------------------+ | Physical | | +------->| PW Label | +---------------------+ | +--------------------------------+ +--------->| Outer Label or MPLS-in-IP encap| +--------------------------------+ Figure 11: PWE3 over an MPLS PSN using a control word And similar for IP. Ron > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, April 29, 2003 1:32 PM > To: pwe3@ietf.org > Cc: Ron Cohen; 'Yaakov Stein'; 'Alik Shimelmits' > Subject: Re: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > Is the WG concensus: > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H------------------------+ > H---------------------H | | > H Sequencing H-----| | > \=====================/ | | > | PW Demultiplexer |---+ | v > +---------------------+ | | +--------------------------------+ > | PSN Convergence |-----| . . > +---------------------+ | | . RTP . > | PSN |-+ | | | | > +---------------------+ | | | +--------------------------------+ > | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | Physical | | +--->| PW Label | > +---------------------+ | +--------------------------------+ > +----->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > Which is what the current text says, or is it: > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H-------+ > H---------------------H | | > H Sequencing H-----+ | > \=====================/ | | > | PW Demultiplexer |---+ | | > +---------------------+ | | | +--------------------------------+ > | PSN Convergence |-----+--->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | PSN |-+ | | | | > +---------------------+ | | +->. RTP . > | MAC/Data-link | | | | | > +---------------------+ | | +--------------------------------+ > | Physical | | +----->| PW Label | > +---------------------+ | +--------------------------------+ > +------->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > Figure 11: PWE3 over an MPLS PSN using a control word > > > Which is what this thread seems to conclude? > > Thanks > > Stewart > > > > Ron Cohen wrote: > > Yaakov, > > > > Let me try again. > > > > In order to run RTP over an MPLS core, one can run: > > > > MPLS->VC-label->RTP->CW->Data > > > > And if IP flow identification is required (ECMP and the like) one > > would > > use: > > > > MPLS->VC-label->MPLS PID->RTP->CW->Data. > > > > Hope this helps > > Ron > > > > > > > > > >>-----Original Message----- > >>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of > >>Yaakov Stein > >>Sent: Monday, April 21, 2003 5:17 PM > >>To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; pwe3@ietf.org > >>Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > >> > >> > >>Hi all, > >> > >>>From what Alik and Ron have said, > >>RTP should ONLY be used with UDP, > >>and NOT with MPLS. > >> > >>If this is indeed the case, > >>then its use contradicts the goal > >>of PWs being PSN-agnostic. > >> > >>As I remember it, the architecture draft > >>specifically depicts RTP for the MPLS case. > >> > >>More importantly, if RTP is actually needed > >>for the IP case (e.g. for carrying TDM or other RT traffic) why does > >>the need disappear for MPLS? > >> > >> > >>Y(J)S > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> > > > > > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Alik Shimelmits Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 09:57:14 +0200 Lines: 189 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'Yaakov Stein'" X-From: pwe3-admin@ietf.org Wed Apr 30 09:17:12 2003 Return-path: To: "'Ron Cohen'" , stbryant@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I support Ron's diagram Alik -----Original Message----- From: Ron Cohen [mailto:ronc@lyciumnetworks.com] Sent: Wednesday, April 30, 2003 9:56 AM To: stbryant@cisco.com; pwe3@ietf.org Cc: 'Yaakov Stein'; Alik Shimelmits Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 Stewart, In ASCII Art the layering should look like: +---------------------+ | Payload | /=====================\ H Payload Convergence H-------+ H---------------------H | H Timing H---------+ H---------------------H | | H Sequencing H-------+ | \=====================/ | | | PSN Convergence |-----+ | | +---------------------+ | | | +--------------------------------+ | PW Demultiplexer |---+ | +--->| Flags, Frag, Len, Seq #, etc | +---------------------+ | | | +--------------------------------+ | PSN |-+ | | +->| RTP | +---------------------+ | | | +--------------------------------+ | MAC/Data-link | | | +----->| MPLS PID | +---------------------+ | | +--------------------------------+ | Physical | | +------->| PW Label | +---------------------+ | +--------------------------------+ +--------->| Outer Label or MPLS-in-IP encap| +--------------------------------+ Figure 11: PWE3 over an MPLS PSN using a control word And similar for IP. Ron > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, April 29, 2003 1:32 PM > To: pwe3@ietf.org > Cc: Ron Cohen; 'Yaakov Stein'; 'Alik Shimelmits' > Subject: Re: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > Is the WG concensus: > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H------------------------+ > H---------------------H | | > H Sequencing H-----| | > \=====================/ | | > | PW Demultiplexer |---+ | v > +---------------------+ | | +--------------------------------+ > | PSN Convergence |-----| . . > +---------------------+ | | . RTP . > | PSN |-+ | | | | > +---------------------+ | | | +--------------------------------+ > | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | Physical | | +--->| PW Label | > +---------------------+ | +--------------------------------+ > +----->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > > > Figure 11: PWE3 over an MPLS PSN using a control word > > Which is what the current text says, or is it: > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-----+ > H---------------------H | > H Timing H-------+ > H---------------------H | | > H Sequencing H-----+ | > \=====================/ | | > | PW Demultiplexer |---+ | | > +---------------------+ | | | +--------------------------------+ > | PSN Convergence |-----+--->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | +--------------------------------+ > | PSN |-+ | | | | > +---------------------+ | | +->. RTP . > | MAC/Data-link | | | | | > +---------------------+ | | +--------------------------------+ > | Physical | | +----->| PW Label | > +---------------------+ | +--------------------------------+ > +------->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > > Figure 11: PWE3 over an MPLS PSN using a control word > > > Which is what this thread seems to conclude? > > Thanks > > Stewart > > > > Ron Cohen wrote: > > Yaakov, > > > > Let me try again. > > > > In order to run RTP over an MPLS core, one can run: > > > > MPLS->VC-label->RTP->CW->Data > > > > And if IP flow identification is required (ECMP and the like) one > > would > > use: > > > > MPLS->VC-label->MPLS PID->RTP->CW->Data. > > > > Hope this helps > > Ron > > > > > > > > > >>-----Original Message----- > >>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of > >>Yaakov Stein > >>Sent: Monday, April 21, 2003 5:17 PM > >>To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; pwe3@ietf.org > >>Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > >> > >> > >>Hi all, > >> > >>>From what Alik and Ron have said, > >>RTP should ONLY be used with UDP, > >>and NOT with MPLS. > >> > >>If this is indeed the case, > >>then its use contradicts the goal > >>of PWs being PSN-agnostic. > >> > >>As I remember it, the architecture draft > >>specifically depicts RTP for the MPLS case. > >> > >>More importantly, if RTP is actually needed > >>for the IP case (e.g. for carrying TDM or other RT traffic) why does > >>the need disappear for MPLS? > >> > >> > >>Y(J)S > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> > > > > > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 10:20:52 +0100 Organization: Cisco Systems, Inc. Lines: 259 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B036CD7@gaya.lycium.net> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 30 11:27:22 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Ron Cohen Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O OK I will look at moving that text Stewart Ron Cohen wrote: > Stewart, > > I'm with Andy and Sasha. > > I do have a remark on the PSN convergence layer location. I view the > MPLS PID as a PSN convergence layer for MPLS. The PW Demultiplexing > layer in MPLS is just another label. Therefore the right layering would > be: > > PSN > PW demultiplexing > PSN convergence > RTP > CW > Payload > > Which would work nicely with IP PSN: > > IP > UDP > RTP > CW > Payload > > And with MPLS PSN: > > MPLS > VC-label > MPLS PID > RTP > CW > Payload. > > Where the RTP and MPLS PID are optional. > > Thanks > Ron > > > > >>-----Original Message----- >>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >>Behalf Of Stewart Bryant >>Sent: Tuesday, April 29, 2003 1:39 PM >>To: pwe3@ietf.org >>Subject: Re: [PWE3] Arch sections 5.4.3 and 5.4.4 >> >> >>I cut and paste from the wrong version of the base document >>the current version is actually: >> >>+---------------------+ >>| Payload | >>/=====================\\ >>H Payload Convergence H-----+ >>H---------------------H | >>H Timing H------------------------+ >>H---------------------H | | >>H Sequencing H-----| | >>\\=====================/ | | >>| PW Demultiplexer |---+ | v >>+---------------------+ | | +--------------------------------+ >>| PSN Convergence |-----| . . >>+---------------------+ | | . RTP . >>| PSN |-+ | | | | >>+---------------------+ | | | +--------------------------------+ >>| Data-link | | | +->| Flags, Frag, Len, Seq #, etc | >>+---------------------+ | | +--------------------------------+ >>| Physical | | | | MPLS Payl'd Type Indent | >>+---------------------+ | | +--------------------------------+ >> | +--->| PW Label | >> | +--------------------------------+ >> +----->| Outer Label or MPLS-in-IP encap| >> +--------------------------------+ >> >>but the question remains, should we swap RTP and the CW? >> >>Stewart >> >> >> >> >>Stewart Bryant wrote: >> >>>Is the WG concensus: >>> >>> +---------------------+ >>> | Payload | >>> /=====================\ >>> H Payload Convergence H-----+ >>> H---------------------H | >>> H Timing H------------------------+ >>> H---------------------H | | >>> H Sequencing H-----| | >>> \=====================/ | | >>> | PW Demultiplexer |---+ | v >>> +---------------------+ | | +--------------------------------+ >>> | PSN Convergence |-----| . . >>> +---------------------+ | | . RTP . >>> | PSN |-+ | | | | >>> +---------------------+ | | | +--------------------------------+ >>> | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc | >>> +---------------------+ | | +--------------------------------+ >>> | Physical | | +--->| PW Label | >>> +---------------------+ | +--------------------------------+ >>> +----->| Outer Label or MPLS-in-IP encap| >>> +--------------------------------+ >>> >>> >>> >>>Figure 11: PWE3 over an MPLS PSN using a control word >>> >>>Which is what the current text says, or is it: >>> >>> +---------------------+ >>> | Payload | >>> /=====================\ >>> H Payload Convergence H-----+ >>> H---------------------H | >>> H Timing H-------+ >>> H---------------------H | | >>> H Sequencing H-----+ | >>> \=====================/ | | >>> | PW Demultiplexer |---+ | | >>> +---------------------+ | | | >> >>+--------------------------------+ >> >>> | PSN Convergence |-----+--->| Flags, Frag, Len, Seq >> >>#, etc | >> >>> +---------------------+ | | >> >>+--------------------------------+ >> >>> | PSN |-+ | | | >> >> | >> >>> +---------------------+ | | +->. RTP >> >> . >> >>> | MAC/Data-link | | | | >> >> | >> >>> +---------------------+ | | >> >>+--------------------------------+ >> >>> | Physical | | +----->| PW Label >> >> | >> >>> +---------------------+ | >> >>+--------------------------------+ >> >>> +------->| Outer Label or >> >>MPLS-in-IP encap| >> >>> >> >>+--------------------------------+ >> >>>Figure 11: PWE3 over an MPLS PSN using a control word >>> >>> >>>Which is what this thread seems to conclude? >>> >>>Thanks >>> >>>Stewart >>> >>> >>> >>>Ron Cohen wrote: >>> >>> >>>>Yaakov, >>>> >>>>Let me try again. >>>> >>>>In order to run RTP over an MPLS core, one can run: >>>> >>>>MPLS->VC-label->RTP->CW->Data >>>> >>>>And if IP flow identification is required (ECMP and the like) one >>>>would >>>>use: >>>> >>>>MPLS->VC-label->MPLS PID->RTP->CW->Data. >>>> >>>>Hope this helps >>>>Ron >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >>>> >>Behalf Of >> >>>>>Yaakov Stein >>>>>Sent: Monday, April 21, 2003 5:17 PM >>>>>To: Alik Shimelmits; Ron Cohen; stbryant@cisco.com; pwe3@ietf.org >>>>>Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 >>>>> >>>>> >>>>>Hi all, >>>>> >>>>> >>>>>>From what Alik and Ron have said, >>>>> >>>>>RTP should ONLY be used with UDP, >>>>>and NOT with MPLS. >>>>> >>>>>If this is indeed the case, then its use contradicts the >>>> >>goal of PWs >> >>>>>being PSN-agnostic. >>>>> >>>>>As I remember it, the architecture draft >>>>>specifically depicts RTP for the MPLS case. >>>>> >>>>>More importantly, if RTP is actually needed for the IP case (e.g. >>>>>for >>>>>carrying TDM or other RT traffic) >>>>>why does the need disappear for MPLS? >>>>> >>>>> >>>>>Y(J)S >>>>>_______________________________________________ >>>>>pwe3 mailing list >>>>>pwe3@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 05:52:38 -0400 Lines: 40 Sender: pwe3-admin@ietf.org References: <3EAE629B.6060904@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: , "Ron Cohen" X-From: pwe3-admin@ietf.org Wed Apr 30 12:00:08 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: pwe3@ietf.org In-Reply-To: <000101c30eed$e3414750$6601010a@lycium.net> X-OriginalArrivalTime: 30 Apr 2003 09:52:49.0783 (UTC) FILETIME=[4291A870:01C30EFE] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ron's got it perfect. Cheers, Andy ------- At 4/30/2003 09:55 AM +0200, Ron Cohen wrote: >Stewart, > >In ASCII Art the layering should look like: > > +---------------------+ > | Payload | > /=====================\ > H Payload Convergence H-------+ > H---------------------H | > H Timing H---------+ > H---------------------H | | > H Sequencing H-------+ | > \=====================/ | | > | PSN Convergence |-----+ | | > +---------------------+ | | | +--------------------------------+ > | PW Demultiplexer |---+ | +--->| Flags, Frag, Len, Seq #, etc | > +---------------------+ | | | +--------------------------------+ > | PSN |-+ | | +->| RTP | > +---------------------+ | | | +--------------------------------+ > | MAC/Data-link | | | +----->| MPLS PID | > +---------------------+ | | +--------------------------------+ > | Physical | | +------->| PW Label | > +---------------------+ | +--------------------------------+ > +--------->| Outer Label or MPLS-in-IP encap| > +--------------------------------+ > >Figure 11: PWE3 over an MPLS PSN using a control word > >And similar for IP. > >Ron From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 14:48:41 +0300 Lines: 41 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen (E-mail)" X-From: pwe3-admin@ietf.org Wed Apr 30 13:53:59 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcMOW0SS5eoZlBY/RdGzejh62M5EhQAsnG7w To: "Alexander Vainshtein" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3UBqV817168 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, Ron, Stewart > I think that Ron Cohen has answered this question at least > twice on this mailing list: the RTP header, if used, > MUST immediately follow the demultiplexor > (whatever it happens to be) and MUST be > immediately followed by the CW. I think that Ron has voiced AN opinion at least twice on the list, and I think that Sasha has as well. However, I do not believe that this is the BEST or even the correct solution. The logical way to do it is to ALWAYS have the CW first. > 1. This coresponds to the recommendations on the RTP payload > formats with the CW acting as the "payload header" in > terms of Section 4.1 of RFC 2736. As I have already stated in the past, this in no way contradicts RFC 2736, it just does not consider PWs to be a type of RTP, rather RTP to be a tool that CAN be used with PWs. By using this method a SINGLE mechanism which is in common to ALL PWs which do not omit the CW can be used. This mechanism can include the four-bit PID, if this is the way we decide to go. All other methods, e.g. Ron's suggestion that we should add a full 32 bit PID before the RTP and then a CW after the RTP, are either BW wasteful, or inconsistent with the other PW encaps, or both. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 14:56:37 +0300 Lines: 27 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" X-From: pwe3-admin@ietf.org Wed Apr 30 13:59:17 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcMPAN9chowSuJHJReyH6OZOMWY9nAADagog To: "Andrew G. Malis" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3UC0N817389 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Ron's got it perfect. Unfortunately, just as the last time I brought the CW inconsistencies up, no-one is thinking of edge devices that have to handle multiple PW types. Say I have a PWE chip that may receive atm-encap or tdm-encap-with-RTP, it would either have to have a very complex algorithm (which I am not even sure exists) or be informed of an awful lot of network state, in order to function. Let's please keep the architecture consistent. After the MPLS labels comes the CW. It can be used for disambiguation if needed. After it comes all the PW-type related details, which include RTP (which is simply a submode of the real-time PW type). By separating the CW from the labels you are making the CW part of a OSI layer which is higher than the RTP, in addition to implying a client-server relationship between the PW and RTP which is exactly the inverse of what should exist. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 15:05:39 +0200 Lines: 75 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org, "Ron Cohen (E-mail)" , stbryant@cisco.com, "Danny McPherson (E-mail)" X-From: pwe3-admin@ietf.org Wed Apr 30 14:14:03 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, Please see some comments inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Wednesday, April 30, 2003 1:49 PM > To: Sasha Vainshtein; stbryant@cisco.com > Cc: pwe3@ietf.org; Ron Cohen (E-mail) > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > Sasha, Ron, Stewart > ... snipped ... > > The logical way to do it is > to ALWAYS have the CW first. > I am not sure I understand your logic. Please see some details below. > > > 1. This coresponds to the recommendations on the RTP payload > > formats with the CW acting as the "payload header" in > > terms of Section 4.1 of RFC 2736. > > As I have already stated in the past, > this in no way contradicts RFC 2736, > it just does not consider PWs to be > a type of RTP, rather RTP to be > a tool that CAN be used with PWs. > The PWE3 Charter states that: PWE3 will use RTP where necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and payloads will follow RFC 2736. I think that the word "payload" here refers to the PW payload because the PWE3 WG does not deal with any other payload - Stewart/Danny? And if the PW payload is required to follow RFC 2736, then the only logical place of the CW is to treat it as "additional header information to be carried in addition to that included in the fixed RTP packet header" (above-mentioned RFC, Section 4.1). FYI, the next sentence is "The recommended way of conveying this information is in the payload section of the packet." And this exactly matches Ron's proposal. > > By using this method a SINGLE mechanism > which is in common to ALL PWs which > do not omit the CW can be used. > This mechanism can include the four-bit PID, > if this is the way we decide to go. > I do not understand what kind of consitency with "other PW encaps" is missing. The situation when the CW immediately precedes the payload is preserved for all kinds of the PE encapsulations. And if you think that RTP is BW-wasteful, you MAY omit it without breaking this consistency. > ... snipped to the end ... From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 15:35:13 +0200 Lines: 67 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 30 14:44:48 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all: Just for the reference: Axerra develops, produces and sells an edge device that handles multiple PW types. Some of the supported PWs use RTP and some don't. And, so far, we have not experienced any problem due to different encapsulations. I do not see why supporting multiple encapsulations in a "PWE3 chip" would be different in any way. Granted, I am not an ASIC expert. But Ron and Tim are. IMO, an attempt to insert a (possibly suppressed) RTP header between the CW and the payload would make such a chip really complicated. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Wednesday, April 30, 2003 1:57 PM > To: Andrew G. Malis; pwe3@ietf.org > Cc: stbryant@cisco.com; Ron Cohen > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > > Ron's got it perfect. > > Unfortunately, just as the last time I brought > the CW inconsistencies up, no-one is thinking > of edge devices that have to handle multiple PW types. > > Say I have a PWE chip that may receive atm-encap or > tdm-encap-with-RTP, > it would either have to have a very complex algorithm > (which I am not even sure exists) or be informed of an awful lot of > network state, in order to function. > > Let's please keep the architecture consistent. > After the MPLS labels comes the CW. > It can be used for disambiguation if needed. > After it comes all the PW-type related details, > which include RTP (which is simply a submode of the > real-time PW type). > > By separating the CW from the labels > you are making the CW part of a OSI layer > which is higher than the RTP, > in addition to implying a client-server relationship > between the PW and RTP > which is exactly the inverse of what should exist. > > Y(J)S > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Wed, 30 Apr 2003 09:23:12 -0400 Lines: 83 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Yaakov Stein'" , stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 30 15:27:38 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Sasha Vainshtein In-Reply-To: X-OriginalArrivalTime: 30 Apr 2003 13:23:18.0795 (UTC) FILETIME=[AA0BF5B0:01C30F1B] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I agree with Sasha's points. In addition, section 4.4 in draft-ietf-pwe3-sonet-01.txt (compare figures 4 and 5) is a good illustration of why it makes sense to have the CW after the RTP header. As it says in the draft, the choice to utilize RTP header suppression may be statically configured using [CEM-MIB], or signaled using a PW maintenance protocol such as [PWE3-CONTROL]. This is the way it's been since RTP was first introduced into the SONET draft. Thanks, Andy --------- At 4/30/2003 03:35 PM +0200, Sasha Vainshtein wrote: >Yaakov and all: > >Just for the reference: Axerra develops, produces and sells an edge device >that handles multiple PW types. Some of the supported PWs use RTP and >some don't. And, so far, we have not experienced any problem due to >different >encapsulations. > >I do not see why supporting multiple encapsulations in a "PWE3 chip" >would be different in any way. Granted, I am not an ASIC expert. >But Ron and Tim are. > >IMO, an attempt to insert a (possibly suppressed) >RTP header between the CW and the payload would > make such a chip really complicated. > >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > Sent: Wednesday, April 30, 2003 1:57 PM > > To: Andrew G. Malis; pwe3@ietf.org > > Cc: stbryant@cisco.com; Ron Cohen > > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > > > > > > Ron's got it perfect. > > > > Unfortunately, just as the last time I brought > > the CW inconsistencies up, no-one is thinking > > of edge devices that have to handle multiple PW types. > > > > Say I have a PWE chip that may receive atm-encap or > > tdm-encap-with-RTP, > > it would either have to have a very complex algorithm > > (which I am not even sure exists) or be informed of an awful lot of > > network state, in order to function. > > > > Let's please keep the architecture consistent. > > After the MPLS labels comes the CW. > > It can be used for disambiguation if needed. > > After it comes all the PW-type related details, > > which include RTP (which is simply a submode of the > > real-time PW type). > > > > By separating the CW from the labels > > you are making the CW part of a OSI layer > > which is higher than the RTP, > > in addition to implying a client-server relationship > > between the PW and RTP > > which is exactly the inverse of what should exist. > > > > Y(J)S > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Yaron Nachman Subject: TTL value of VC Label? Date: Wed, 30 Apr 2003 09:23:01 +0200 Lines: 17 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Wed Apr 30 23:44:14 2003 Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, I have just noticed that in the yesterday-updated draft-martini-l2circuit-encap-mpls-05.txt, the TTL value to be placed by an Ingress LER on the VC Label is 2. I have noticed in the past that it was changed to 255. So, is it 2 or 255? or even some other value?? Thanks, Yaron Nachman SEABRIDGE Ltd. Tel: 972-9-7751359 Fax: 972-9-7751212 E-mail: yaron.nachman@SeabridgeNetworks.com From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Nandakumar Kuttiyeri Subject: ethernet over mpls Date: Wed, 30 Apr 2003 00:06:54 -0700 (PDT) Lines: 27 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Wed Apr 30 23:47:37 2003 Return-path: To: townsley@cisco.com, pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hello, I have a small clarification on ethernet over mpls (martini feature). I had used Cisco 7200 series router with an IOS version of 12.0 (23)S as my peer router, PE. I used Fast Ethernet on the CE-PE side, enabled 802.1Q encapsulation on the sub-interface and had the VC up with the commands "mpls l2transport route" command. The VC status was UP. The data from PE1 to Cisco (PE2) was fine. But, from CE2 to PE2, the data from fast ethernet wasnt getting switched to the l2VPN tunnel at PE2 (Cisco). Could anyone clarify whether I am missing out some configuration? Thanks. With Best Regards Nandakumar __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Nandakumar Kuttiyeri Subject: ethernet over mpls Date: Wed, 30 Apr 2003 06:50:07 -0700 (PDT) Lines: 27 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Wed Apr 30 23:51:47 2003 Return-path: To: pwe3@ietf.org, erosen@cisco.com Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hello, I have a small clarification on ethernet over mpls (martini feature). I had used Cisco 7200 series router with an IOS version of 12.0 (23)S as my peer router, PE. I used Fast Ethernet on the CE-PE side, enabled 802.1Q encapsulation on the sub-interface and had the VC up with the commands "mpls l2transport route" command. The VC status was UP. The data from PE1 to Cisco (PE2) was fine. But, from CE2 to PE2, the data from fast ethernet wasnt getting switched to the l2VPN tunnel at PE2 (Cisco). Could anyone clarify whether I am missing out some configuration? Thanks. With Best Regards Nandakumar __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Dmitry Bokotey" Subject: RE: ethernet over mpls Date: Wed, 30 Apr 2003 17:08:28 -0600 Lines: 39 Sender: pwe3-admin@ietf.org References: <20030430135007.88711.qmail@web80505.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu May 01 01:13:02 2003 Return-path: To: "'Nandakumar Kuttiyeri'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20030430135007.88711.qmail@web80505.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Can you send me configs. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Nandakumar Kuttiyeri Sent: Wednesday, April 30, 2003 7:50 AM To: pwe3@ietf.org; erosen@cisco.com Subject: [PWE3] ethernet over mpls Hello, I have a small clarification on ethernet over mpls (martini feature). I had used Cisco 7200 series router with an IOS version of 12.0 (23)S as my peer router, PE. I used Fast Ethernet on the CE-PE side, enabled 802.1Q encapsulation on the sub-interface and had the VC up with the commands "mpls l2transport route" command. The VC status was UP. The data from PE1 to Cisco (PE2) was fine. But, from CE2 to PE2, the data from fast ethernet wasnt getting switched to the l2VPN tunnel at PE2 (Cisco). Could anyone clarify whether I am missing out some configuration? Thanks. With Best Regards Nandakumar __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Danny McPherson Subject: Re: ethernet over mpls Date: Wed, 30 Apr 2003 17:56:15 -0600 Lines: 10 Sender: pwe3-admin@ietf.org References: <20030430135007.88711.qmail@web80505.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu May 01 02:07:18 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: In-Reply-To: <20030430135007.88711.qmail@web80505.mail.yahoo.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Folks, Needless to say [or apparently not], these types of issues should be addressed with your vendor support channels, not on an IETF mailing list. Replies as well (as I'm guessing you [now] realize).... Presumably, these were inadvertently addressed to pwe3@ietf.org. Thanks in advance for future cooperation! -danny