From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "W. Mark Townsley" Subject: Re: Scaling hierarchical LDP/PW stitching Date: Sun, 01 Aug 2004 17:10:37 -0700 Lines: 307 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, pwe3@ietf.org, 'Chris Metz' , "'richard.spencer@bt.com'" , 'Mustapha Aissaoui' X-From: pwe3-bounces@ietf.org Mon Aug 02 02:32:37 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en To: "Busschbach, Peter B (Peter)" In-Reply-To: X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Busschbach, Peter B (Peter) wrote: > Hi Chris, > > You ask an important question. I don't have the answer. I don't know if there > are documents that describe requirements for inter-provider services. If not, > it would be good if service providers got together to produce one. > > As I wrote in my email to Mustapha, I believe that inter-provider services > form a special case. We should be careful not to mix a general discussion of > multi-hop PWs with the special requirements that apply when you cross > provider boundaries. I concur with this statement. Motivations for PW-switching to reduce the number of control connections, shared secrets between peers, etc. within a single administrative domain can be very different from those for PW-switching deployed at administrative boundaries. As such, the ideal mechanisms for each may be quite different. > > Two comments on your email: > > 1) draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt discusses extensions to > RSVP-TE to make it suitable for inter-domain connection setup. The draft > acknowledges that at the provider boundary there may be a need to stitch > tunnels rather than to create a contiguous end-to-end tunnel. Therefore, > applying LSP Hierarchy does not prevent a provider from confining the PW > control channnel to inter-AS neighbors and ASBRs. > > 2) I don't know how much providers care about the advertisements of specific > IP addresses. After all, through BGP they advertise all addresses. > Furthermore, in the IP VPN inter-AS scenarios described in 2547bis I don't > see any attempt to hide the PE's IP address when crossing the AS boundary. Using L2TP (RFC 2661) deployments as an example, it is common to see tunnel switches deployed at administrative boundaries for a variety of reasons. Hiding internal network topology (sometimes referring to as "tunnel grooming") are among the reasons I have seen cited for this. - Mark > > Peter > > >> -----Original Message----- From: Chris Metz [mailto:chmetz@cisco.com] Sent: >> Friday, July 30, 2004 1:12 PM To: Busschbach, Peter B (Peter) Cc: 'Mustapha >> Aissaoui'; l2vpn@ietf.org; pwe3@ietf.org; 'richard.spencer@bt.com' Subject: >> RE: [PWE3] Scaling hierarchical LDP/PW stitching >> >> >> At 04:49 PM 7/27/2004 -0400, Busschbach, Peter B (Peter) wrote: >> >> >> >> >>> My contention is: we already have a topology discovery >> >> mechanism. If you >> >>> identify a MH-PW with the IP addresses of its ingress and >> >> egress PE and >> >>> you use the principles of >> >> draft-ietf-mpls-lsp-hierarchy-08.txt, you have a >> >>> solution. >> >> Hey Peter- I do find the use of LSP hierarchy intriguing ... but it seems >> to me that if the ultimate source PE of the MH-PW in one AS must "learn" >> the IP address of the ultimate target PE in another AS, then we are at risk >> of exposing one provider's internal addressing structure to another. I note >> that these addresses are used to establish the PW control channels ... be >> they RSVP or LDP or whatever. They are separate from whatever PW ID scheme >> (i.e. TAII) that might be used. >> >> I find some merit in the idea that PW control channels are confined to >> intra-AS PE neighbors and ASBR peering points. Is this the case with LSP >> hierarchy? >> >> Cheers ... >> >> >> >> >> >>> Peter >>> >>> >>> >>>> -----Original Message----- From: Mustapha Aissaoui >>>> [mailto:mustapha.aissaoui@alcatel.com] Sent: Tuesday, July 27, 2004 >>>> 3:26 PM To: Busschbach, Peter B (Peter) Cc: 'du.ke@zte.com.cn'; >>>> l2vpn@ietf.org; pwe3@ietf.org; 'richard.spencer@bt.com' Subject: Re: >>>> [PWE3] Scaling hierarchical LDP/PW stitching >>>> >>>> >>>> Peter, I added a few comments below. >>>> >>>> Regards, Mustapha. --------- "Busschbach, Peter B (Peter)" wrote: >>>> >>>>> Hi Mustapha, >>>>> >>>>> I agree with your last point, i.e. that we need to >>>> >>>> understand the requirements before we decide which solution is best >>>> suited. However, IMO your email obscures some important issues. >>>> >>>>> Peter >>>>> >>>>> >>>>>> -----Original Message----- From: Mustapha Aissaoui >>>>>> [mailto:mustapha.aissaoui@alcatel.com] Sent: Monday, July 26, 2004 >>>>>> 5:20 PM To: Busschbach, Peter B (Peter) Cc: 'du.ke@zte.com.cn'; >>>>>> l2vpn@ietf.org; pwe3-bounces@ietf.org; pwe3@ietf.org; >>>>>> 'richard.spencer@bt.com' Subject: Re: [PWE3] Scaling hierarchical >>>>>> LDP/PW stitching >>>>>> >>>>>> >>>>>> Peter, in networks where end-to-end traffic engineering of PWs >>>> >>>> is required, >>>> >>>>>> or where any intermediate LSR could act as a stitching >>>> >>>> node, the use >>>> >>>>>> of RSVP-TE for PW setup makes a lot sense. >>>>> >>>>> One of the things I was trying to get across in earlier >>>> >>>> emails is that >every LSR _can_ function as a stitching node. A MH-PW >>>> is nothing more >than a pt-to-pt LSP between two PEs and the stitching >>>> points are nothing >more than LSRs that switch PW labels. >>>> >>>> MA> If every LSR could function as a stitching node, which implies that >>>> it would keep state for each PW and know how to >> >> forward it, why >> >>>> bother carrying PWs over a tunnel LSP? The reachability >> >> information >> >>>> required by the PW will be exactly the same as that of the tunnel LSP. >>>> In my view, we cannot start with the assumption that every node could >>>> be a stichting node as this has the consequence of degenerating into an >>>> all PW routable network. >>>> >>>> >>>>> RSVP-TE is the appropriate tool for the setup of such >>>> >>>> pt-to-pt LSPs. CR-LDP is an alternative. >>>> >>>>> I don't think it is correct to say that RSVP-TE only makes >>>> >>>> sense if you >need to do traffic engineering. RSVP-TE makes sense >>>> anyway. The fact that >it can be used for traffic engineering is an >>>> added benefit. >>>> >>>> MA> I said RSVP-TE made sense in this case. I do not >> >> think it is the >> >>>> only case. Have you thought of other cases? >>>> >>>> >>>>>> However, in many cases this will not be a requirement. There will >>>>>> be a few >> >> stiching nodes >> >>>>>> which are known a priori. >>>>> >>>>> I am not sure what your point is. You are saying that in >>>> >>>> many cases there is no need for a scaleable solution. But in other >>>> cases there is. Should we just ignore the latter? >>>> >>>> MA> My starting point is different from yours. I am looking into a >>>> network where most of the label switching is performed at >> >> the tunnel >> >>>> LSP level and where a few nodes act as stitching points. So the >>>> forwarding information is mostly based on the tunnel LSP routing >>>> information. I need to use a policy to decide how a stitching node >>>> should move a PW from one tunnel LSP to another one. I do >> >> not need a >> >>>> routable PW label to perform a local forwarding operation in a few >>>> stiching nodes. >>>> >>>> >>>>> The other problem I have with this statement is your >>>> >>>> suggestion that >stitching nodes are known a priori and that >>>> (therefore?) we can get away >with simple solutions. As far as I can >>>> see, every solution that uses a >hierarchy of LSPs requires certain >>>> a-priori policies. But that is not >the point. The crux of the >>>> discussion between Du Ke and Richard Spencer >was that you need to have >>>> mechanisms to find an end-to-end path between >two PEs. Therefore, even >>>> if a PE would have the choice between only two >stitching nodes, it >>>> needs to select one of the two. And if the primary >selection fails, it >>>> has to be able to switch over to the secondary node. >>>> >>>> MA> How is this different from a node dual-homed to a network? A local >>>> policy in the node states which is the primary node and if >>>> load-balancing is allowed over both links. This node does not need to >>>> participate in the exchange of reachability >> >> information with the >> >>>> rest of the network. >>>> >>>> >>>>> draft-martini-pwe3-pw-switching-00.txt assumes that the >>>> >>>> stitching point >is manually configured. That could create problems for >>>> protection >switching. draft-yudong-pwe3-control-protocol-ext-00.txt >>>> adopts a >>>> >>>>> solution that is at least capable of routing around >>>> >>>> failures, but it >assumes that the operator assigns an absolute >>>> priority to the stitching >nodes. That would nto work well if the >>>> operator is interested in load >balancing. >>>> >>>> MA> I am not sure why this should not work for load balancing. How is >>>> this different from a node which performs load-balancing over >>>> dual-homed links? Unless you are thinking of load balancing PWs >>>> end-to-end >> >> over a set >> >>>> of tunnel LSPs. In this case you want to traffic engineer >> >> your PWs. >> >>>>> I am sure that LDP-based proposals can be enhanced to deal >>>> >>>> with these >issues, but why not use an existing protocol for which >>>> these issues have >already been investigated and solved? And not only >>>> that. It already has >solutions for traffic engineering, fast reroute >>>> and graceful restart as >well. >>>> >>>> MA> Again, you can take advantage of all this but you >> >> really did not >> >>>> need the tunnel LSPs and just let the PWs be routable across the >>>> network. >>>> >>>> >>>>>> For instance, one may want to stitch PWs over a set of >>>> >>>> intra-domain >>>> >>>>>> tunnel LSPs which may or may not have been separately traffic >>>>>> engineered inside their own domain. The stitching >> >> nodes will be a >> >>>>>> few ASBRs. >>>>> >>>>> I consider inter-AS scenarios (and especially, >>>> >>>> inter-provider scenarios) as a special case and I can see that we adopt >>>> a different solution for inter-AS cases than for intra-AS cases. >>>> >>>>> I agree that we need to uderstand the target applications. >>>> >>>> I would just be careful in making general statement based on an >>>> inter-AS example. It can easily lead you in the wrong >> >> direction. >> >>>>>> Thus, having a solution based on Targeted LDP which removes >>>>>> pre-configuration at the stitching node is >> >> desirable. One >> >>>>>> possible solution is to use the "Self-Mode" described in >>>>>> draft-yudong-pwe3-control-protocol-ext-00.txt where >> >> the boundary >> >>>>>> routers act as the stitching nodes. >>>>>> >>>>>> So, the targetted application one wants to address should be >>>>>> examined to understand which solution is best suited. >>>>>> >>>>>> Regards, Mustapha. ----------- >>>>>> >>>>> >>>>> [snipped] >>>> >>> _______________________________________________ pwe3 mailing list >>> pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 >> > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Danny McPherson Subject: Meeting Agenda Date: Mon, 2 Aug 2004 07:25:18 -0600 Lines: 8 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Mon Aug 02 15:32:09 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.618) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Folks, The current meeting agenda and slides are available here: http://pwe3.tcb.net/meetings/ietf60/agenda.html -danny & stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: Draft PWE3 Charter Date: Mon, 2 Aug 2004 15:18:07 +0100 Lines: 29 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Mon Aug 02 16:40:20 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Draft PWE3 Charter thread-index: AcR2RQbuKFUrZrymRJehmLya7/gG4wCVVMiw To: X-OriginalArrivalTime: 02 Aug 2004 14:18:11.0713 (UTC) FILETIME=[8ACC5F10:01C4789B] X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Folks, One of the WG objectives of the old charter was: "The WG will determine the requirements for having a pseudo wire pass = across an administrative boundary." One of the WG objectives of the new charter is: "Define mechanisms to allow the inter-domain operation of PWs." IMO a requirements definition should come before a solution definition. = Given that there are now drafts proposing solutions to the problem of = inter-domain PWs (i.e. PW switching/stitching) can I assume that the = requirements for "inter-domain operation of PWs" have been identified? = If so, where can I find those requirements documented? Thanks Ben --=20 Ben Niven-Jenkins Networking Specialist Next Generation IP/Optical Networks, BT Exact e-mail: benjamin.niven-jenkins@bt.com tel: +44(0) 1473 648225 fax: +44(0) 1473 620109 pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, = UK From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Mon, 2 Aug 2004 18:27:27 +0100 Lines: 238 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Mon Aug 02 20:04:08 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR0G1aptbhC2J+8QwKcgK67yl9jUwEfQC2A To: , X-OriginalArrivalTime: 02 Aug 2004 17:27:27.0769 (UTC) FILETIME=[FB890090:01C478B5] X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, I agree that using FA-LSPs as described in = draft-ietf-mpls-lsp-hierarchy-08.txt (which I must admit I hadn't read) = is one solution to the MH-PW provisioning issue. It solves the = next-hop/routing problem by having PW switching nodes advertise FA-LSPs = as next-hops to PE loopback IP addresses via the IGP. Routing = policies/metrics could be used to ensure that the PW next hop was always = via the best directly connected FA-LSP. However, the above solution requires that FA-LSPs are provisioned = between PW switching capable nodes, what about providers that use LDP = signalling for tunnel LSPs? I believe an alternative solution is = required in this case. Regards, Richard > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: 27 July 2004 21:50 > To: 'Mustapha Aissaoui' > Cc: 'du.ke@zte.com.cn'; l2vpn@ietf.org; pwe3@ietf.org; > Spencer,R,Richard,XGH5 R > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching >=20 >=20 > > In my view, we cannot start with the assumption that every node > > could be a stichting node as this has the consequence of > > degenerating into an all PW routable network. >=20 > Hi Mustapha, >=20 > Every LSR *can* be a PW stitching node. It is not an=20 > assumption. It is a simple observation based on the=20 > recognition that a MH-PW is really nothing more than an LSP. >=20 > That does not mean that every LSR *should* be used as a=20 > stitching node. That would eventually not result in a=20 > scaleable solution. Operators will use Transport LSPs to=20 > aggregate PWs. They will identify specific nodes that will=20 > function as stitching nodes and they will set policies that=20 > prompt those nodes to establish the segments of a MH-PW=20 > through the Transport LSPs. >=20 > I think that thus far we agree. We seem to disagree on how=20 > you actually determine the end-to-end route. >=20 > You write: "I need to use a policy to decide how a stitching=20 > node should move a PW from one tunnel LSP to another one. I=20 > do not need a routable PW label to perform a local forwarding=20 > operation in a few stiching nodes." >=20 > By saying that there are only a few nodes, you imply that=20 > there is no need for a true routing solution. I disagree. The=20 > question is: when the first stitching node receives a PW=20 > setup request from a PE, how does it know what the next hop=20 > on the path is? Or, in your words, the PW has to be moved to=20 > the next tunnel, but which tunnel? You say: there are=20 > policies. What kind of policies? Are you suggesting that the=20 > operator manually provisions a routing table? Something like:=20 > for AGI=3DX and AII=3DY, the next hop is Z? >=20 > I thought that the email exchange between Richard Spencer and=20 > Du Ke illustrated this problem very well and after a few=20 > emails up and down, Du Ke acknowledged that there is a need=20 > for some topology discovery mechanism. >=20 > My contention is: we already have a topology discovery=20 > mechanism. If you identify a MH-PW with the IP addresses of=20 > its ingress and egress PE and you use the principles of=20 > draft-ietf-mpls-lsp-hierarchy-08.txt, you have a solution. >=20 > Peter >=20 >=20 > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Tuesday, July 27, 2004 3:26 PM > > To: Busschbach, Peter B (Peter) > > Cc: 'du.ke@zte.com.cn'; l2vpn@ietf.org; pwe3@ietf.org; > > 'richard.spencer@bt.com' > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > >=20 > >=20 > > Peter, > > I added a few comments below. > >=20 > > Regards, > > Mustapha. > > --------- > > "Busschbach, Peter B (Peter)" wrote: > > >=20 > > > Hi Mustapha, > > >=20 > > > I agree with your last point, i.e. that we need to=20 > > understand the requirements before we decide which solution=20 > > is best suited. However, IMO your email obscures some=20 > > important issues. > > >=20 > > > Peter > > >=20 > > > > -----Original Message----- > > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > > Sent: Monday, July 26, 2004 5:20 PM > > > > To: Busschbach, Peter B (Peter) > > > > Cc: 'du.ke@zte.com.cn'; l2vpn@ietf.org; pwe3-bounces@ietf.org; > > > > pwe3@ietf.org; 'richard.spencer@bt.com' > > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > > > > > Peter, > > > > in networks where end-to-end traffic engineering of PWs=20 > > is required, > > > > or where any intermediate LSR could act as a stitching=20 > > node, the use > > > > of RSVP-TE for PW setup makes a lot sense. > > >=20 > > > One of the things I was trying to get across in earlier=20 > > emails is that >every LSR _can_ function as a stitching node.=20 > > A MH-PW is nothing more >than a pt-to-pt LSP between two PEs=20 > > and the stitching points are nothing >more than LSRs that=20 > > switch PW labels. > >=20 > > MA> If every LSR could function as a stitching node, which implies > > that it would keep state for each PW and know how to forward it, why > > bother carrying PWs over a tunnel LSP? The reachability information > > required by the PW will be exactly the same as that of the tunnel > > LSP. > > In my view, we cannot start with the assumption that every node > > could be a stichting node as this has the consequence of > > degenerating into an all PW routable network. > > =20 > > > RSVP-TE is the appropriate tool for the setup of such=20 > > pt-to-pt LSPs. CR-LDP is an alternative. > > >=20 > > > I don't think it is correct to say that RSVP-TE only makes=20 > > sense if you >need to do traffic engineering. RSVP-TE makes=20 > > sense anyway. The fact that >it can be used for traffic=20 > > engineering is an added benefit. > >=20 > > MA> I said RSVP-TE made sense in this case. I do not think it is the > > only case. Have you thought of other cases? > > =20 > > > > However, in many cases > > > > this will not be a requirement. There will be a few=20 > stiching nodes > > > > which are known a priori. > > >=20 > > > I am not sure what your point is. You are saying that in=20 > > many cases there is no need for a scaleable solution. But in=20 > > other cases there is. Should we just ignore the latter? > >=20 > > MA> My starting point is different from yours. I am looking into a > > network where most of the label switching is performed at the tunnel > > LSP level and where a few nodes act as stitching points. So the > > forwarding information is mostly based on the tunnel LSP routing > > information. I need to use a policy to decide how a stitching node > > should move a PW from one tunnel LSP to another one. I do not need a > > routable PW label to perform a local forwarding operation in a few > > stiching nodes. =20 > >=20 > > > The other problem I have with this statement is your=20 > > suggestion that >stitching nodes are known a priori and that=20 > > (therefore?) we can get away >with simple solutions. As far=20 > > as I can see, every solution that uses a >hierarchy of LSPs=20 > > requires certain a-priori policies. But that is not >the=20 > > point. The crux of the discussion between Du Ke and Richard=20 > > Spencer >was that you need to have mechanisms to find an=20 > > end-to-end path between >two PEs. Therefore, even if a PE=20 > > would have the choice between only two >stitching nodes, it=20 > > needs to select one of the two. And if the primary >selection=20 > > fails, it has to be able to switch over to the secondary node. > >=20 > > MA> How is this different from a node dual-homed to a network? A > > local policy in the node states which is the primary node and if > > load-balancing is allowed over both links. This node does not need > > to participate in the exchange of reachability information with the > > rest of the network.=20 > >=20 > > > draft-martini-pwe3-pw-switching-00.txt assumes that the=20 > > stitching point >is manually configured. That could create=20 > > problems for protection >switching.=20 > > draft-yudong-pwe3-control-protocol-ext-00.txt adopts a=20 > > >solution that is at least capable of routing around=20 > > failures, but it >assumes that the operator assigns an=20 > > absolute priority to the stitching >nodes. That would nto=20 > > work well if the operator is interested in load >balancing. > >=20 > > MA> I am not sure why this should not work for load balancing. How > > is this different from a node which performs load-balancing over > > dual-homed links? > > Unless you are thinking of load balancing PWs end-to-end over a set > > of tunnel LSPs. In this case you want to traffic engineer your PWs. > > =20 > > > I am sure that LDP-based proposals can be enhanced to deal=20 > > with these >issues, but why not use an existing protocol for=20 > > which these issues have >already been investigated and=20 > > solved? And not only that. It already has >solutions for=20 > > traffic engineering, fast reroute and graceful restart as >well. > > =20 > > MA> Again, you can take advantage of all this but you really did not > > need the tunnel LSPs and just let the PWs be routable across the > > network. > >=20 > > > > For instance, one may want to stitch PWs over a set of=20 > > intra-domain > > > > tunnel LSPs which may or may not have been separately traffic > > > > engineered inside their own domain. The stitching nodes=20 > will be a > > > > few ASBRs. > > >=20 > > > I consider inter-AS scenarios (and especially,=20 > > inter-provider scenarios) as a special case and I can see=20 > > that we adopt a different solution for inter-AS cases than=20 > > for intra-AS cases. > > >=20 > > > I agree that we need to uderstand the target applications.=20 > > I would just be careful in making general statement based on=20 > > an inter-AS example. It can easily lead you in the wrong direction. > > >=20 > > > > Thus, having a solution based on Targeted LDP which > > > > removes pre-configuration at the stitching node is=20 > desirable. One > > > > possible solution is to use the "Self-Mode" described in > > > > draft-yudong-pwe3-control-protocol-ext-00.txt where the boundary > > > > routers act as the stitching nodes. > > > > > > > > So, the targetted application one wants to address should be > > > > examined to understand which solution is best suited. > > > > > > > > Regards, > > > > Mustapha. > > > > ----------- > > > > > > > [snipped] > >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Mon, 2 Aug 2004 18:29:00 +0100 Lines: 47 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, busschbach@lucent.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Mon Aug 02 20:06:20 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR2jGHerwIMVRWbREih/GumfPj+CgCERehQ To: , , X-OriginalArrivalTime: 02 Aug 2004 17:29:01.0024 (UTC) FILETIME=[331E9600:01C478B6] X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Dimitri, > > b. FA-LSP are mandated to connect SNs. This is restrictive in my=20 > > view. It is not clear to me how non FA-LSPs could be used as tunnel=20 > > LSPs. >=20 > the questions turns out to be if i have a set of FA-LSPs and a set of > tunnels LSPs, the former being advertized as FA links but not=20 > the latter > how does the global mechanism work ? >=20 > the response is be setting up a routing adjacency on top of=20 > the tunnels=20 > LSPs that can not be advertized as FA LSPs >=20 > so, on one side, advertize these LSPs as simple IP/MPLS links so that=20 > the non-FA capable nodes see these links (also i assume here=20 > that a FA=20 > capable node is also "non-FA" capable) >=20 > and on the other side, for non-FA capable nodes to see established FA=20 > LSPs, mandate that FA link advertisement are beforehand=20 > translated into=20 > common IP/MPLS link advertisement >=20 > note: as we're at the bottom of the stack here there is also=20 > no level issue Please can you elaborate as to how this solves the problem Mustapha = raises? If I understand correctly, Mustapha is raising the issue that if = non FA-LSPs (e.g. LDP LSPs) are used then they are not advertised via = the IGP as tunnels (P2P links), and therefore can not be used in the = same way that FA-LSPs can be used to establish MH-PWs. This would be the = case if a provider only used LDP LSPs or used LDP LSPs in conjunction = with TE LSPs for different traffic types. In the latter case, some PWs = will need to be tunnelled over the FA-LSPs, and some of the PWs will = need to be tunnelled over the LDP LSPs, i.e. they will follow separate = paths. Your solution appears to just mandate that FA link advertisements are = advertised as common IP/MPLS link advertisements so that they can be = processed by non-FA capable nodes. This still requires FA-LSPs to be = provisioned and therefore does not address the issue of using non-FA = LSPs for tunnelling PWs. Thanks, Richard=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: A few questions on draft-bryant-mcpherson-pwe3-cw-00.txt Date: Mon, 2 Aug 2004 23:59:12 +0200 Lines: 30 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Sharon Galtzur , "PWE3 WG \(E-mail\)" , Alik Shimelmits X-From: pwe3-bounces@ietf.org Mon Aug 02 23:24:05 2004 Return-path: To: "Danny McPherson (E-mail)" , "Stewart Bryant (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Danny, Stewart and all, A few questions/comments on draft-bryant-mcpherson-pwe3-cw-00.txt: 1. The draft says that the payload type in the PW-PTI is "the PW Type assigned by IANA". I assume that it is the same PW type that is defined in the IANA Allocation draft? 2. The VCCV draft defines somewhat different semantics of the payload type field in the CW with the 1st nibble of '0001' as it refers to the PPP DLL Proto Numbers. Note that the rest of the CW is the same and PPP DLL Proto Numbers are not the same as PW Types (belong to a different registry). To the best of my understanding this means the PWs that use PW-PTI cannot use VCCV; did I miss something? 3. The conflict described in the previous comment seems to be easily resolvable by using some discriminator between the VCCV and PW PTIs (using some of the reserved bits).Is there any fundamental reason preventing that? Hopefully these questions will be useful. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: Draft PWE3 Charter Date: Tue, 3 Aug 2004 00:24:48 +0200 Lines: 106 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: Sharon Galtzur , pwe3@ietf.org, Alik Shimelmits X-From: pwe3-bounces@ietf.org Mon Aug 02 23:47:13 2004 Return-path: To: "'benjamin.niven-jenkins@bt.com'" , "Stewart Bryant (E-mail)" , "Danny McPherson (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Ben, Stewart, Danny and all, It looks like there are multiple interpretations of the desired WG scope wrt multi-hop PWs. One interpretation considers these PWs as solutions for inter-provider/inter-area problems. Another deals with limited number of targeted LDP sessions and different PSN technologies etc. There are also issues related to QoS, dual homing etc. And, IMHO, there are issues that go beyond the mere PW stitching/switching, like routing (how do you find your S-PEs where the switching is done?) and OAM (how do you identify the faulty PW segment if you have U-PE-to-U-PE problems?) etc. I think that we need a wider definition of scope of the related work in the Charter that would include: - clear specification of requirements for MH-PWs including some guidelines as to when these must be preferred over some simpler solution (e.g., a SH-PW over L2TPv3). These requirements should address the inter-provider/inter-area case but are not necessarily limited to this case - additions to the PWE3 architecture/reference models addressing the MH-PW issues (the present architecture seems tightly bound to the SH-PW case). The mere fact that I have to use the new terms like U-PE/S-PE proves in my eyes that this work is necessary - identification of a small number of solutions addressing these requirements with the appropriate applicability statements - specification of the appropriate OAM mechanisms (or modification of the existing OAM mechanisms) facilitating effective fault localization - extension of the PWE3 MIBs supporting MH-PWs (I suspect - even if I did not check - that the current PWE3 MIBs do not address the MH-PW issues?) In fact, I think that there is a lot of work to do - and I think this work is necessary, too. Hopefully these notes will be useful. ---------------------------------------------------------------------------- -------- 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: benjamin.niven-jenkins@bt.com > [mailto:benjamin.niven-jenkins@bt.com] > Sent: Monday, August 02, 2004 4:18 PM > To: pwe3@ietf.org > Subject: RE: [PWE3] Draft PWE3 Charter > > > Folks, > > One of the WG objectives of the old charter was: > "The WG will determine the requirements for having a pseudo > wire pass across an administrative boundary." > > One of the WG objectives of the new charter is: > "Define mechanisms to allow the inter-domain operation of PWs." > > IMO a requirements definition should come before a solution > definition. Given that there are now drafts proposing > solutions to the problem of inter-domain PWs (i.e. PW > switching/stitching) can I assume that the requirements for > "inter-domain operation of PWs" have been identified? If so, > where can I find those requirements documented? > > Thanks > Ben > > -- > Ben Niven-Jenkins > Networking Specialist > Next Generation IP/Optical Networks, BT Exact > > e-mail: benjamin.niven-jenkins@bt.com > tel: +44(0) 1473 648225 > fax: +44(0) 1473 620109 > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, > Ipswich IP5 3RE, UK > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Mustapha Aissaoui Subject: Re: Scaling hierarchical LDP/PW stitching Date: Mon, 02 Aug 2004 18:15:57 -0400 Organization: Alcatel Networks Corporaton Lines: 58 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, busschbach@lucent.com, dpapadimitriou@psg.com X-From: pwe3-bounces@ietf.org Tue Aug 03 00:40:17 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: richard.spencer@bt.com X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard and Dimitri, this issue is in my view one of the critical issues. I believe a workable solution should have the following characteristics: 1. State how stitching nodes are discovered. I do not agree with Peter that a stiching node is just another LSP switching node. There are PW specific operations to be performed in the data, control, and management (OAM) planes on a PW segment. 2. State how routing of PW control messages are performed once the stitching nodes have been discovered. It seems to me that a solution that mandates the use of FA-LSPs is too restrictive. 3. Avoid if possible making the PW label routable. Not that I have anything against that but if a solution turns PWs into routable entities on their own, then we should discuss it in that wider context. In that case, the use of tunnel LSPs becomes a convenience as opposed to a requirement of the architecture. Regards, Mustapha. ---------- richard.spencer@bt.com wrote: > > Dimitri, > > > > b. FA-LSP are mandated to connect SNs. This is restrictive in my > > > view. It is not clear to me how non FA-LSPs could be used as tunnel > > > LSPs. > > > > the questions turns out to be if i have a set of FA-LSPs and a set of > > tunnels LSPs, the former being advertized as FA links but not > > the latter > > how does the global mechanism work ? > > > > the response is be setting up a routing adjacency on top of > > the tunnels > > LSPs that can not be advertized as FA LSPs > > > > so, on one side, advertize these LSPs as simple IP/MPLS links so that > > the non-FA capable nodes see these links (also i assume here > > that a FA > > capable node is also "non-FA" capable) > > > > and on the other side, for non-FA capable nodes to see established FA > > LSPs, mandate that FA link advertisement are beforehand > > translated into > > common IP/MPLS link advertisement > > > > note: as we're at the bottom of the stack here there is also > > no level issue > > Please can you elaborate as to how this solves the problem Mustapha raises? If I understand correctly, Mustapha is raising the issue that if non FA-LSPs (e.g. LDP LSPs) are used then they are not advertised via the IGP as tunnels (P2P links), and therefore can not be used in the same way that FA-LSPs can be used to establish MH-PWs. This would be the case if a provider only used LDP LSPs or used LDP LSPs in conjunction with TE LSPs for different traffic types. In the latter case, some PWs will need to be tunnelled over the FA-LSPs, and some of the PWs will need to be tunnelled over the LDP LSPs, i.e. they will follow separate paths. > > Your solution appears to just mandate that FA link advertisements are advertised as common IP/MPLS link advertisements so that they can be processed by non-FA capable nodes. This still requires FA-LSPs to be provisioned and therefore does not address the issue of using non-FA LSPs for tunnelling PWs. > > Thanks, > Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: dimitri papadimitriou Subject: Re: Scaling hierarchical LDP/PW stitching Date: Tue, 03 Aug 2004 00:49:07 +0200 Lines: 71 Sender: pwe3-bounces@ietf.org References: Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, busschbach@lucent.com X-From: pwe3-bounces@ietf.org Tue Aug 03 01:06:23 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en To: richard.spencer@bt.com In-Reply-To: X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org richard, richard.spencer@bt.com wrote: > Dimitri, > > >>> b. FA-LSP are mandated to connect SNs. This is restrictive in my >>> view. It is not clear to me how non FA-LSPs could be used as >>> tunnel LSPs. >> >> the questions turns out to be if i have a set of FA-LSPs and a set >> of tunnels LSPs, the former being advertized as FA links but not >> the latter how does the global mechanism work ? >> >> the response is be setting up a routing adjacency on top of the >> tunnels LSPs that can not be advertized as FA LSPs >> >> so, on one side, advertize these LSPs as simple IP/MPLS links so >> that the non-FA capable nodes see these links (also i assume here >> that a FA capable node is also "non-FA" capable) >> >> and on the other side, for non-FA capable nodes to see established >> FA LSPs, mandate that FA link advertisement are beforehand >> translated into common IP/MPLS link advertisement >> >> note: as we're at the bottom of the stack here there is also no >> level issue > > > Please can you elaborate as to how this solves the problem Mustapha > raises? If I understand correctly, Mustapha is raising the issue that > if non FA-LSPs (e.g. LDP LSPs) are used then they are not advertised > via the IGP as tunnels (P2P links), and therefore can not be used in > the same way that FA-LSPs can be used to establish MH-PWs. This would > be the case if a provider only used LDP LSPs or used LDP LSPs in > conjunction with TE LSPs for different traffic types. In the latter > case, some PWs will need to be tunnelled over the FA-LSPs, and some > of the PWs will need to be tunnelled over the LDP LSPs, i.e. they > will follow separate paths. > > Your solution appears to just mandate that FA link advertisements are > advertised as common IP/MPLS link advertisements so that they can be > processed by non-FA capable nodes. This still requires FA-LSPs to be > provisioned and therefore does not address the issue of using non-FA > LSPs for tunnelling PWs. there are several point to clarify from the above, in particular re - stating the question that was "how non FA-LSPs could be used as tunnel LSPs." the question boils down to "how a set of FA-LSPs and a set of tunnel LSPs (i.e. non FA-LSPs), the former being advertized as FA links but not the latter how does the global mechanism work ?" on the other side the question turns out to be having established a FA-LSP how do i make the existence of the correspond link information to nodes that do not under stand "FA links" - you're making another distinction which is for the non-FA LSPs are they "TE LSPs" or "LSPs" and the response is that it only dependent on the PE capability to advertize the corr. link that can further be used by other nodes to tunnel PWs coming to your last statement, it boils down to what you do today, more precisely, the fact that FA-LSPs are provisioned or triggered doesn't impact the non-FA LSPs are used for tunneling PWs thanks, - dimitri. > Thanks, Richard > > > . > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 3 Aug 2004 00:50:40 +0100 Lines: 42 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, busschbach@lucent.com, pwe3@ietf.org, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Tue Aug 03 02:07:27 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR44vs566nfAGEaR6qAAAvAxk8hCwAAPxxQ To: , X-OriginalArrivalTime: 02 Aug 2004 23:50:40.0901 (UTC) FILETIME=[84828350:01C478EB] X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Dimitri, > there are several point to clarify from the above, in particular re -=20 > stating the question that was "how non FA-LSPs could be used=20 > as tunnel LSPs." the question boils down to "how a set of FA-LSPs and = a set of=20 > tunnel LSPs (i.e. non FA-LSPs), the former being advertized=20 > as FA links but not the latter how does the global mechanism work ?" I believe this is your (mis)interpretation of the question and is not = the question Mustapha raised. > on the other side the question turns out to be having established a = FA-LSP=20 > how do i make the existence of the correspond link information to=20 > nodes that do not under stand "FA links" Again, I believe this is a question that you have raised. PEs and PW = switching nodes are the only nodes that need to set up FA-LSPs (to be = able to support MH-PWs), if they don't support FA-LSPs then the solution = Peter describes won't work making this a non-issue. If you disagree, = please can you explain how MH-PWs can be established using PEs/PW = switching nodes that don't support FA-LSPs? > - you're making another distinction which is for the non-FA LSPs are=20 > they "TE LSPs" or "LSPs" and the response is that it only dependent=20 > on the PE capability to advertize the corr. link that can further be=20 > used by other nodes to tunnel PWs coming to your last statement, it=20 > boils down to what you do today, more precisely, the fact that FA-LSPs = are provisioned=20 > or triggered doesn't impact the non-FA LSPs are used for tunneling PWs Sorry Dimitri but I don't understand the relevance of your response or = the point you are trying to make. I wrote "This still requires FA-LSPs = to be provisioned and therefore does not address the issue of using = non-FA LSPs for tunnelling PWs." No one is suggesting that using FA-LSPs = impacts non-FA LSPs used for tunnelling PWs, the question again is - If = non-FA LSPs are used for tunneling PWs, how can the PE and PW switching = node (or PW layer) topology be discovered and paths calculated/selected. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "David Allan" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Mon, 2 Aug 2004 20:34:44 -0400 Lines: 87 Sender: pwe3-bounces@ietf.org Cc: l2vpn@ietf.org, busschbach@lucent.com, pwe3@ietf.org, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Tue Aug 03 02:44:54 2004 Return-path: To: "'richard.spencer@bt.com'" , dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I think FA-LSPs is the wrong concept to be using in this discussion, the creation of FA-LSPs that would superficially appear to be superior routes to direct PE-PE PSN LSPs in order to force desired behavior, and share a common routing instance between the PW and PSN layers, would have rather bizarre ramifications. One implication is that routing may change over time, and therefore each PW requires a switch table entry in every PW-Switch as it may be a viable alternate path to either going directly to the PE or transiting a different PW switch. IMO if you are tandeming PWs in the middle of the network, you have a pinned mid-point and it needs to be forced to be pinned in order to achieve useful behavior....this is different semantics than that of an FA-LSP. You will have distinct topologies for the PW and the PSN layers. cheers Dave > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of richard.spencer@bt.com > Sent: Monday, August 02, 2004 7:51 PM > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > Cc: l2vpn@ietf.org; busschbach@lucent.com; pwe3@ietf.org; > mustapha.aissaoui@alcatel.com > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > Dimitri, > > > there are several point to clarify from the above, in > particular re - > > stating the question that was "how non FA-LSPs could be used > > as tunnel LSPs." the question boils down to "how a set of > FA-LSPs and a set of > > tunnel LSPs (i.e. non FA-LSPs), the former being advertized > > as FA links but not the latter how does the global mechanism work ?" > > I believe this is your (mis)interpretation of the question > and is not the question Mustapha raised. > > > on the other side the question turns out to be having established a > > FA-LSP > > how do i make the existence of the correspond link information to > > nodes that do not under stand "FA links" > > Again, I believe this is a question that you have raised. PEs > and PW switching nodes are the only nodes that need to set up > FA-LSPs (to be able to support MH-PWs), if they don't support > FA-LSPs then the solution Peter describes won't work making > this a non-issue. If you disagree, please can you explain how > MH-PWs can be established using PEs/PW switching nodes that > don't support FA-LSPs? > > > - you're making another distinction which is for the non-FA LSPs are > > they "TE LSPs" or "LSPs" and the response is that it only dependent > > on the PE capability to advertize the corr. link that can > further be > > used by other nodes to tunnel PWs coming to your last statement, it > > boils down to what you do today, more precisely, the fact > that FA-LSPs are provisioned > > or triggered doesn't impact the non-FA LSPs are used for > tunneling PWs > > Sorry Dimitri but I don't understand the relevance of your > response or the point you are trying to make. I wrote "This > still requires FA-LSPs to be provisioned and therefore does > not address the issue of using non-FA LSPs for tunnelling > PWs." No one is suggesting that using FA-LSPs impacts non-FA > LSPs used for tunnelling PWs, the question again is - If > non-FA LSPs are used for tunneling PWs, how can the PE and PW > switching node (or PW layer) topology be discovered and paths > calculated/selected. > > Regards, > Richard > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: UDP questions Date: Tue, 3 Aug 2004 06:09:19 +0300 Lines: 106 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0674921785==" X-From: pwe3-bounces@ietf.org Tue Aug 03 05:25:20 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: UDP questions Thread-Index: AcR5B0TGdj1IYCPEQkeitnEw5zdvOA== To: X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0674921785== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47907.3F825ED5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C47907.3F825ED5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following my presentation today, I would like to solicit responses to the 2 questions I raised. 1) Should the PW label be placed in A) destination UDP port field (has NAT/firewall issues) B) source UDP port ? 2) What label distribution should be used=20 A) implicit upstream (has security considerations) B) standard LDP-based PWE protocol C) other ? Y(J)S ------_=_NextPart_001_01C47907.3F825ED5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable UDP questions

Following my presentation today,

I would = like to solicit responses to the 2 questions I raised.

1) = Should the PW label be placed in

    A) destination UDP port field (has = NAT/firewall issues)

    B) source UDP = port     ?


2) What = label distribution should be used

    A) implicit upstream (has security = considerations)

    B) standard LDP-based PWE = protocol

    C) other     = ?


Y(J)S

------_=_NextPart_001_01C47907.3F825ED5-- --===============0674921785== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0674921785==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 3 Aug 2004 01:01:37 -0400 Lines: 318 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: l2vpn@ietf.org, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Tue Aug 03 07:17:29 2004 Return-path: To: "'Mustapha Aissaoui'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Friday, July 30, 2004 6:03 PM > To: Busschbach, Peter B (Peter) > Cc: l2vpn@ietf.org; pwe3@ietf.org; 'richard.spencer@bt.com' > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > Peter, > Let us decompose the problem to gain more insight into the issue. > Sorry for the lengthy message. Any comments are appreciated. > > I will be using the following diagram as an example to help walk > through the various functions required to set up a MH-PW. I > abstracted the network to only show the PEs and the Stitching Nodes > (SNs). These nodes are inter-connected over a set of Tunnel LSPs > (TLSPs). For now, assume these are FA-LSPs. Also, let us assume that > all these nodes are in a single domain. > > |PE1|--(TLSP)--|SN1|--(TLSP)------|SN3|--(TLSP)---|PE2| > | | | | > | |---------------| | | > | | | | > | |---------------|--| | > | | | | > |---(TLSP)---|SN2|---(TLSP)---|SN4|--(TLSP)-------| > > 1. The first thing to do is to discover the nodes which are capable > of acting as "stitching nodes". This will allow a specific PE or > stitching node to know which nodes it can direct the PW signaling > messages to. There may be several ways to do that including the > possibility you mentioned in which any node can act as a stitching > node and therfore you can skip to (2) below. > > 2. When SN1 receives a PW signaling message, RSVP-TE or Targeted LDP > (TLDP), from PE1, it needs to figure out which is the next-hop SN. > Assume that either a Explicit Route object or a local reachability > lookup indicates SN2. An explicit route object can be received in a > RSVP-TE path message. A local reachability lookup is used in the > case of TLDP PW signaling and is based on the destination PE address > which needs to be included in the PW signaling message. The local > lookup selects SN2 as a result of a FA-LSP advertisement. Hi Mustapha, This is the crux of the matter. How do you envision the local reachability look-up in case of TLDP? In my view there are two options: 1) SN1 uses the IP address of PE2 to determine that SN2 is the next hop on the path. 2) SN1 uses AGI and AII to determine that SN2 is the next hop on the path. To me solution 1) seems to have an obvious advantage: all nodes in the network run IP routing protocols already. To support 2) in an automatic fashion (i.e. not manually provisioned by the service provider) you need to use some form of autodiscovery protocol, so that SNs learn how to route AGIs and AIIs. That is not impossible. E.g. draft-hlmu-l2vpn-bgp-discovery-00.txt describes a possible solution. This could be the right solution for inter-AS PW setup, but is it the right thing to do for intra-AS MH-PWs? I don't think so. In your email you mention "routable PA labels". The issue is not that the PW labels are routable. The issue is that the identifiers used in PW setup messages must be routable. My argument is that it is better to use the IP address of the destination PE than to use AGI/AII. Peter > > 3. In the case of TLDP PW signaling, the TLDP session between PE1 > and SN1 is separate from that between SN1 and SN2. However, for the > purpose of MH-PW signaling, they need to be coordinated. This means > that SN1, and other transit SNs, can continue to process the > signaling messages for the two directions independently but will > only perform the sticthing in the datapath when both directions have > been setup. > > 5. The above procedures are repeated at each node until the PW > signaling message reaches PE2. PE2 may trigger the reverse direction > either independently or in response to the received label mapping > message. > > So far, it appears that we can have MH-PW without making the PW > labels routable and that both RSVP-TE or TLDP could be used for PW > signaling. > > Though, we have the following open issues: > a. How do stitching nodes get identified? The mere fact that a > FA-LSP exists between SN1 and another node cannot be used as an > indication that the latter can be used as a stitching node. > b. FA-LSP are mandated to connect SNs. This is restrictive in my > view. It is not clear to me how non FA-LSPs could be used as tunnel > LSPs. > > Regards, > Mustapha. > ----------- > "Busschbach, Peter B (Peter)" wrote: > > > > > In my view, we cannot start with the assumption that every node > > > could be a stichting node as this has the consequence of > > > degenerating into an all PW routable network. > > > > Hi Mustapha, > > > > Every LSR *can* be a PW stitching node. It is not an > assumption. It is a simple observation based on the > recognition that a MH-PW is really nothing more than an LSP. > > > > That does not mean that every LSR *should* be used as a > stitching node. That would eventually not result in a > scaleable solution. Operators will use Transport LSPs to > aggregate PWs. They will identify specific nodes that will > function as stitching nodes and they will set policies that > prompt those nodes to establish the segments of a MH-PW > through the Transport LSPs. > > > > I think that thus far we agree. We seem to disagree on how > you actually determine the end-to-end route. > > > > You write: "I need to use a policy to decide how a > stitching node should move a PW from one tunnel LSP to > another one. I do not need a routable PW label to perform a > local forwarding operation in a few stiching nodes." > > > > By saying that there are only a few nodes, you imply that > there is no need for a true routing solution. I disagree. The > question is: when the first stitching node receives a PW > setup request from a PE, how does it know what the next hop > on the path is? Or, in your words, the PW has to be moved to > the next tunnel, but which tunnel? You say: there are > policies. What kind of policies? Are you suggesting that the > operator manually provisions a routing table? Something like: > for AGI=X and AII=Y, the next hop is Z? > > > > I thought that the email exchange between Richard Spencer > and Du Ke illustrated this problem very well and after a few > emails up and down, Du Ke acknowledged that there is a need > for some topology discovery mechanism. > > > > My contention is: we already have a topology discovery > mechanism. If you identify a MH-PW with the IP addresses of > its ingress and egress PE and you use the principles of > draft-ietf-mpls-lsp-hierarchy-08.txt, you have a solution. > > > > Peter > > > > > -----Original Message----- > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > Sent: Tuesday, July 27, 2004 3:26 PM > > > To: Busschbach, Peter B (Peter) > > > Cc: 'du.ke@zte.com.cn'; l2vpn@ietf.org; pwe3@ietf.org; > > > 'richard.spencer@bt.com' > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > > Peter, > > > I added a few comments below. > > > > > > Regards, > > > Mustapha. > > > --------- > > > "Busschbach, Peter B (Peter)" wrote: > > > > > > > > Hi Mustapha, > > > > > > > > I agree with your last point, i.e. that we need to > > > understand the requirements before we decide which solution > > > is best suited. However, IMO your email obscures some > > > important issues. > > > > > > > > Peter > > > > > > > > > -----Original Message----- > > > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > > > Sent: Monday, July 26, 2004 5:20 PM > > > > > To: Busschbach, Peter B (Peter) > > > > > Cc: 'du.ke@zte.com.cn'; l2vpn@ietf.org; pwe3-bounces@ietf.org; > > > > > pwe3@ietf.org; 'richard.spencer@bt.com' > > > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > > > > > > > > Peter, > > > > > in networks where end-to-end traffic engineering of PWs > > > is required, > > > > > or where any intermediate LSR could act as a stitching > > > node, the use > > > > > of RSVP-TE for PW setup makes a lot sense. > > > > > > > > One of the things I was trying to get across in earlier > > > emails is that >every LSR _can_ function as a stitching node. > > > A MH-PW is nothing more >than a pt-to-pt LSP between two PEs > > > and the stitching points are nothing >more than LSRs that > > > switch PW labels. > > > > > > MA> If every LSR could function as a stitching node, which implies > > > that it would keep state for each PW and know how to > forward it, why > > > bother carrying PWs over a tunnel LSP? The reachability > information > > > required by the PW will be exactly the same as that of the tunnel > > > LSP. > > > In my view, we cannot start with the assumption that every node > > > could be a stichting node as this has the consequence of > > > degenerating into an all PW routable network. > > > > > > > RSVP-TE is the appropriate tool for the setup of such > > > pt-to-pt LSPs. CR-LDP is an alternative. > > > > > > > > I don't think it is correct to say that RSVP-TE only makes > > > sense if you >need to do traffic engineering. RSVP-TE makes > > > sense anyway. The fact that >it can be used for traffic > > > engineering is an added benefit. > > > > > > MA> I said RSVP-TE made sense in this case. I do not > think it is the > > > only case. Have you thought of other cases? > > > > > > > > However, in many cases > > > > > this will not be a requirement. There will be a few > stiching nodes > > > > > which are known a priori. > > > > > > > > I am not sure what your point is. You are saying that in > > > many cases there is no need for a scaleable solution. But in > > > other cases there is. Should we just ignore the latter? > > > > > > MA> My starting point is different from yours. I am looking into a > > > network where most of the label switching is performed at > the tunnel > > > LSP level and where a few nodes act as stitching points. So the > > > forwarding information is mostly based on the tunnel LSP routing > > > information. I need to use a policy to decide how a stitching node > > > should move a PW from one tunnel LSP to another one. I do > not need a > > > routable PW label to perform a local forwarding operation in a few > > > stiching nodes. > > > > > > > The other problem I have with this statement is your > > > suggestion that >stitching nodes are known a priori and that > > > (therefore?) we can get away >with simple solutions. As far > > > as I can see, every solution that uses a >hierarchy of LSPs > > > requires certain a-priori policies. But that is not >the > > > point. The crux of the discussion between Du Ke and Richard > > > Spencer >was that you need to have mechanisms to find an > > > end-to-end path between >two PEs. Therefore, even if a PE > > > would have the choice between only two >stitching nodes, it > > > needs to select one of the two. And if the primary >selection > > > fails, it has to be able to switch over to the secondary node. > > > > > > MA> How is this different from a node dual-homed to a network? A > > > local policy in the node states which is the primary node and if > > > load-balancing is allowed over both links. This node does not need > > > to participate in the exchange of reachability > information with the > > > rest of the network. > > > > > > > draft-martini-pwe3-pw-switching-00.txt assumes that the > > > stitching point >is manually configured. That could create > > > problems for protection >switching. > > > draft-yudong-pwe3-control-protocol-ext-00.txt adopts a > > > >solution that is at least capable of routing around > > > failures, but it >assumes that the operator assigns an > > > absolute priority to the stitching >nodes. That would nto > > > work well if the operator is interested in load >balancing. > > > > > > MA> I am not sure why this should not work for load balancing. How > > > is this different from a node which performs load-balancing over > > > dual-homed links? > > > Unless you are thinking of load balancing PWs end-to-end > over a set > > > of tunnel LSPs. In this case you want to traffic engineer > your PWs. > > > > > > > I am sure that LDP-based proposals can be enhanced to deal > > > with these >issues, but why not use an existing protocol for > > > which these issues have >already been investigated and > > > solved? And not only that. It already has >solutions for > > > traffic engineering, fast reroute and graceful restart as >well. > > > > > > MA> Again, you can take advantage of all this but you > really did not > > > need the tunnel LSPs and just let the PWs be routable across the > > > network. > > > > > > > > For instance, one may want to stitch PWs over a set of > > > intra-domain > > > > > tunnel LSPs which may or may not have been separately traffic > > > > > engineered inside their own domain. The stitching > nodes will be a > > > > > few ASBRs. > > > > > > > > I consider inter-AS scenarios (and especially, > > > inter-provider scenarios) as a special case and I can see > > > that we adopt a different solution for inter-AS cases than > > > for intra-AS cases. > > > > > > > > I agree that we need to uderstand the target applications. > > > I would just be careful in making general statement based on > > > an inter-AS example. It can easily lead you in the wrong > direction. > > > > > > > > > Thus, having a solution based on Targeted LDP which > > > > > removes pre-configuration at the stitching node is > desirable. One > > > > > possible solution is to use the "Self-Mode" described in > > > > > draft-yudong-pwe3-control-protocol-ext-00.txt where > the boundary > > > > > routers act as the stitching nodes. > > > > > > > > > > So, the targetted application one wants to address should be > > > > > examined to understand which solution is best suited. > > > > > > > > > > Regards, > > > > > Mustapha. > > > > > ----------- > > > > > > > > > [snipped] > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 3 Aug 2004 01:18:16 -0400 Lines: 274 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 03 07:26:26 2004 Return-path: To: "'richard.spencer@bt.com'" , mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: Monday, August 02, 2004 1:27 PM > To: busschbach@lucent.com; mustapha.aissaoui@alcatel.com > Cc: du.ke@zte.com.cn; l2vpn@ietf.org; pwe3@ietf.org > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > Peter, > > I agree that using FA-LSPs as described in > draft-ietf-mpls-lsp-hierarchy-08.txt (which I must admit I > hadn't read) is one solution to the MH-PW provisioning issue. > It solves the next-hop/routing problem by having PW switching > nodes advertise FA-LSPs as next-hops to PE loopback IP > addresses via the IGP. Routing policies/metrics could be used > to ensure that the PW next hop was always via the best > directly connected FA-LSP. > > However, the above solution requires that FA-LSPs are > provisioned between PW switching capable nodes, what about > providers that use LDP signalling for tunnel LSPs? I believe > an alternative solution is required in this case. Hi Richard, You are right. In the case of LDP signaling for tunnel LSPs, a PW switching node would need additional policies to determine when to tunnel traffic and where to tunnel it to. In the worst case, we could revert to the solution that other drafts propose: the Service Provider explicitly identifies which nodes are PW switching nodes. However, I could imagine that there are more general policies that require less manual engineering and provisioning. E.g rules like: (a) if the destination PE is in the same OSPF area use a tunnel that terminates directly on that PE. If the PE is in a different OSPF area, use a tunnel that terminates on an Area Border Router. In my first email to you, I wrote: "The question is therefore not: what routing protocols do we need to find multi-hop capable routers?; but: what are the policies that drive an LSR to bundle multiple PW-LSPs into a single transport LSP?" I don't think the second problem is trivial, but I think it is better to try to solve the second problem than the first. (Unless we decide that PW switching is only relevant when crossing AS boundaries, in which case BGP probably offers a good solution for the first problem.) Peter > > Regards, > Richard > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: 27 July 2004 21:50 > > To: 'Mustapha Aissaoui' > > Cc: 'du.ke@zte.com.cn'; l2vpn@ietf.org; pwe3@ietf.org; > > Spencer,R,Richard,XGH5 R > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > In my view, we cannot start with the assumption that every node > > > could be a stichting node as this has the consequence of > > > degenerating into an all PW routable network. > > > > Hi Mustapha, > > > > Every LSR *can* be a PW stitching node. It is not an > > assumption. It is a simple observation based on the > > recognition that a MH-PW is really nothing more than an LSP. > > > > That does not mean that every LSR *should* be used as a > > stitching node. That would eventually not result in a > > scaleable solution. Operators will use Transport LSPs to > > aggregate PWs. They will identify specific nodes that will > > function as stitching nodes and they will set policies that > > prompt those nodes to establish the segments of a MH-PW > > through the Transport LSPs. > > > > I think that thus far we agree. We seem to disagree on how > > you actually determine the end-to-end route. > > > > You write: "I need to use a policy to decide how a stitching > > node should move a PW from one tunnel LSP to another one. I > > do not need a routable PW label to perform a local forwarding > > operation in a few stiching nodes." > > > > By saying that there are only a few nodes, you imply that > > there is no need for a true routing solution. I disagree. The > > question is: when the first stitching node receives a PW > > setup request from a PE, how does it know what the next hop > > on the path is? Or, in your words, the PW has to be moved to > > the next tunnel, but which tunnel? You say: there are > > policies. What kind of policies? Are you suggesting that the > > operator manually provisions a routing table? Something like: > > for AGI=X and AII=Y, the next hop is Z? > > > > I thought that the email exchange between Richard Spencer and > > Du Ke illustrated this problem very well and after a few > > emails up and down, Du Ke acknowledged that there is a need > > for some topology discovery mechanism. > > > > My contention is: we already have a topology discovery > > mechanism. If you identify a MH-PW with the IP addresses of > > its ingress and egress PE and you use the principles of > > draft-ietf-mpls-lsp-hierarchy-08.txt, you have a solution. > > > > Peter > > > > > > > -----Original Message----- > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > Sent: Tuesday, July 27, 2004 3:26 PM > > > To: Busschbach, Peter B (Peter) > > > Cc: 'du.ke@zte.com.cn'; l2vpn@ietf.org; pwe3@ietf.org; > > > 'richard.spencer@bt.com' > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > > Peter, > > > I added a few comments below. > > > > > > Regards, > > > Mustapha. > > > --------- > > > "Busschbach, Peter B (Peter)" wrote: > > > > > > > > Hi Mustapha, > > > > > > > > I agree with your last point, i.e. that we need to > > > understand the requirements before we decide which solution > > > is best suited. However, IMO your email obscures some > > > important issues. > > > > > > > > Peter > > > > > > > > > -----Original Message----- > > > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > > > Sent: Monday, July 26, 2004 5:20 PM > > > > > To: Busschbach, Peter B (Peter) > > > > > Cc: 'du.ke@zte.com.cn'; l2vpn@ietf.org; pwe3-bounces@ietf.org; > > > > > pwe3@ietf.org; 'richard.spencer@bt.com' > > > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > > > > > > > > Peter, > > > > > in networks where end-to-end traffic engineering of PWs > > > is required, > > > > > or where any intermediate LSR could act as a stitching > > > node, the use > > > > > of RSVP-TE for PW setup makes a lot sense. > > > > > > > > One of the things I was trying to get across in earlier > > > emails is that >every LSR _can_ function as a stitching node. > > > A MH-PW is nothing more >than a pt-to-pt LSP between two PEs > > > and the stitching points are nothing >more than LSRs that > > > switch PW labels. > > > > > > MA> If every LSR could function as a stitching node, which implies > > > that it would keep state for each PW and know how to > forward it, why > > > bother carrying PWs over a tunnel LSP? The reachability > information > > > required by the PW will be exactly the same as that of the tunnel > > > LSP. > > > In my view, we cannot start with the assumption that every node > > > could be a stichting node as this has the consequence of > > > degenerating into an all PW routable network. > > > > > > > RSVP-TE is the appropriate tool for the setup of such > > > pt-to-pt LSPs. CR-LDP is an alternative. > > > > > > > > I don't think it is correct to say that RSVP-TE only makes > > > sense if you >need to do traffic engineering. RSVP-TE makes > > > sense anyway. The fact that >it can be used for traffic > > > engineering is an added benefit. > > > > > > MA> I said RSVP-TE made sense in this case. I do not > think it is the > > > only case. Have you thought of other cases? > > > > > > > > However, in many cases > > > > > this will not be a requirement. There will be a few > > stiching nodes > > > > > which are known a priori. > > > > > > > > I am not sure what your point is. You are saying that in > > > many cases there is no need for a scaleable solution. But in > > > other cases there is. Should we just ignore the latter? > > > > > > MA> My starting point is different from yours. I am looking into a > > > network where most of the label switching is performed at > the tunnel > > > LSP level and where a few nodes act as stitching points. So the > > > forwarding information is mostly based on the tunnel LSP routing > > > information. I need to use a policy to decide how a stitching node > > > should move a PW from one tunnel LSP to another one. I do > not need a > > > routable PW label to perform a local forwarding operation in a few > > > stiching nodes. > > > > > > > The other problem I have with this statement is your > > > suggestion that >stitching nodes are known a priori and that > > > (therefore?) we can get away >with simple solutions. As far > > > as I can see, every solution that uses a >hierarchy of LSPs > > > requires certain a-priori policies. But that is not >the > > > point. The crux of the discussion between Du Ke and Richard > > > Spencer >was that you need to have mechanisms to find an > > > end-to-end path between >two PEs. Therefore, even if a PE > > > would have the choice between only two >stitching nodes, it > > > needs to select one of the two. And if the primary >selection > > > fails, it has to be able to switch over to the secondary node. > > > > > > MA> How is this different from a node dual-homed to a network? A > > > local policy in the node states which is the primary node and if > > > load-balancing is allowed over both links. This node does not need > > > to participate in the exchange of reachability > information with the > > > rest of the network. > > > > > > > draft-martini-pwe3-pw-switching-00.txt assumes that the > > > stitching point >is manually configured. That could create > > > problems for protection >switching. > > > draft-yudong-pwe3-control-protocol-ext-00.txt adopts a > > > >solution that is at least capable of routing around > > > failures, but it >assumes that the operator assigns an > > > absolute priority to the stitching >nodes. That would nto > > > work well if the operator is interested in load >balancing. > > > > > > MA> I am not sure why this should not work for load balancing. How > > > is this different from a node which performs load-balancing over > > > dual-homed links? > > > Unless you are thinking of load balancing PWs end-to-end > over a set > > > of tunnel LSPs. In this case you want to traffic engineer > your PWs. > > > > > > > I am sure that LDP-based proposals can be enhanced to deal > > > with these >issues, but why not use an existing protocol for > > > which these issues have >already been investigated and > > > solved? And not only that. It already has >solutions for > > > traffic engineering, fast reroute and graceful restart as >well. > > > > > > MA> Again, you can take advantage of all this but you > really did not > > > need the tunnel LSPs and just let the PWs be routable across the > > > network. > > > > > > > > For instance, one may want to stitch PWs over a set of > > > intra-domain > > > > > tunnel LSPs which may or may not have been separately traffic > > > > > engineered inside their own domain. The stitching nodes > > will be a > > > > > few ASBRs. > > > > > > > > I consider inter-AS scenarios (and especially, > > > inter-provider scenarios) as a special case and I can see > > > that we adopt a different solution for inter-AS cases than > > > for intra-AS cases. > > > > > > > > I agree that we need to uderstand the target applications. > > > I would just be careful in making general statement based on > > > an inter-AS example. It can easily lead you in the wrong > direction. > > > > > > > > > Thus, having a solution based on Targeted LDP which > > > > > removes pre-configuration at the stitching node is > > desirable. One > > > > > possible solution is to use the "Self-Mode" described in > > > > > draft-yudong-pwe3-control-protocol-ext-00.txt where > the boundary > > > > > routers act as the stitching nodes. > > > > > > > > > > So, the targetted application one wants to address should be > > > > > examined to understand which solution is best suited. > > > > > > > > > > Regards, > > > > > Mustapha. > > > > > ----------- > > > > > > > > > [snipped] > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Draft PWE3 Charter Date: Tue, 3 Aug 2004 11:41:20 +0100 Lines: 260 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: dave.milham@bt.com, peter.j.willis@bt.com, pwe3@ietf.org, alik@AXERRA.com, andy.bd.reid@bt.com, sharon@AXERRA.com, alan.mcguire@bt.com, richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Tue Aug 03 12:42:49 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Draft PWE3 Charter Thread-Index: AcR42oYbjRDj4alHRym9mFFDAsDAngAUxY/g To: , , , X-OriginalArrivalTime: 03 Aug 2004 10:41:21.0214 (UTC) FILETIME=[6A5985E0:01C47946] X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Not half Sasha! We in BT are very concerned at where PWE3 are now heading, and we had a long internal discussion on this yesterday. PWE3 work is clearly nothing to do with the Internet any longer (as if it ever was), but what is being created now is hardly what operators need either in our view (and if I get chance I'll post some comments on the proposed revised charter later today....as we see it, both the large operator requirements and the public Internet requirements are being compromised by what looks like a bunch of enterprise grade stuff). Wrt PW sw/titching, and no matter how this is dressed-up, as Richard pointed out a few days ago this is creating a new layer network......that is simply a fact whether it is understood or not by some folks. Further, there is a tangle of protocols now that is functionally becoming a right dog's dinner. Let me try and briefly explain what I mean by this...... The root problem is MPLS !=3D IP. How anyone can continue to maintain a pretence that this is not true is beyond us. We need all 3 modes (ie cl-ps, co-ps and co-cs) to operate in concert.....but this is not the same as assuming they can all somehow be treated the same. The real problems that need fixing 1st for MPLS are these: - Deprecate the stuff that creates violations (and thus operational/service problems) of the co-ps mode....so that's LDP mp2p, PHP and ECMP (ECMP is fine in IP); - Add the missing/important functional components.....so that's: consistent access point addressing of LSPs, an OOB control/management plane and carrier-grade OAM. This cannot be done overnight, but if you really want to work on the next generation network standards for large operators then stuff that is broken/missing has to be recognised as such and not ignored. Currently PWE3 stuff is building on flawed foundations (ie the above) and then adding further kludges (in some cases to try and compensate for these). Now let me come to some of the protocol tangle/mess: When a trail (eg an LSP here) is created/destroyed one needs to activate/deactivate the OAM fault-management in sync with this....else there are going to be operational problems. Two key things here: - the trails must *all* use the same form of access point identification so that this can be used in the OAM packets to detect all break/swap/mismerging defects in a consistent manner network-wide; - given the activation/deactivation of the OAM fault-management (at the trail term sink point) must be harmonised to the set-up/tear-down of the LSP, its obvious that the LSP source identifier should be loaded into the LSP sink trail termination point in harness with whatever agent is doing the trail set-up/tear-down, eg the signalling protocol or the management protocol. The above is not difficult *if* its done properly....however, here is some of the mess we currently see here: Some folks also want to use LDP as a proxy device for data-plane fault notification in the case of peer-partition interworking across different technologies/modes. Bad call for many reasons. On reason is that fault management must be done in the data-plane because it has to work even if the control-plane fails, and it also has to be consistent irrespective of the signalling protocol used (inc case of 'none', ie static). But targeted LDP is now starting to look like CR-LDP and some folks don't like that....RSVP-TE is the stated preferred signalling protocol here is it not. So what about fault notification handling in this case? Is RSVP-TE going to get the same treatment? BFD: This has several issues: - its supposed to be a lightweight OAM connectivity verification function, rather reminiscent of the Y.1711 CV in fact. But I find it needs LSP-Ping, which is a bloated heavyweight protocol (largely to cater for the mp2p and ECMP violations), to 'boot-strap' it, ie load the LSP source ID (see next item) at the LSP sink point. So a lightweight protocol needs a heavyweight protocol to boot-strap it?.....that does not look right. But in any case, this function ought to be done via the signalling agent and *not* LSP-Ping. Further, if you keep this LSP-Ping boot-strap behaviour, how is OAM activation/deactivation going to be synchronised to the signalling protocol (and which is this, LDP or RTSVP-TE)? - BFD uses a locally generated 'discriminator' as the LSP source ID. This could be OK if this was the true access point address of whatever the trail it was being used on......but we don't have consistent LSP access point addressing in MPLS (these are not IP layer addresses in case anyone is making that (wrong) connection here). - The CV/BFD OAM packet must be injected/extracted at the right trail termination points.....this is *not* the PW trail term points but the LSP trail term points, ie we want the same/consistent behaviour over all LSPs, not just PW LSPs.=20 In addition to these issues we also of course have: - the fact that martini CW is an optional, still not fully specified (ie seq no defect handling) and largely redundant entity for a properly specified co-ps server layer network (or indeed any co-cs server layer network)......the general issue here that does not seem to be understood is that the adaptation function that is required between 2 layer networks in a client/server relationship depends on the mode of both the client and server layer networks. 1-size does not fit all here. - in any client/server relationship one must have an ability for layer independence (ie client and server owned by different parties....very common case, *not* an exception). This also means the default behaviour is client layer transparency......not BW squeezing as we find in many cases. Note also that real networks run at rather low loads over the vast majority of their operating life, so BW squeezing is not a priority issue for major operators.....but getting rid of complexity is (and PWE3 is creating significant complexity for no good technical reason), and so is solving the commercial problem of 'how to create fair/meaningful/consistent services over all load points'......though this is another matter. - the PID/VCCV stuff....yet another set of optional behaviours, ie more complexity. - nowhere in any IETF work are there any defects specified, ie entry/exit criteria and consequent actions. This is simply not acceptable if you are trying to 'sell' any of this stuff to a large operator like BT. Further, as I have painfully kept pointing out.....the defects that can affect the cl-ps mode (eg IP) are not the same as those that can affect the co-ps mode, and neither of these is the same as those that can affect the co-cs mode. Y.1711 is actually a generic OAM solution for the co-ps mode.......the fact it can be directly applied to arch valid forms of MPLS is just an obvious consequence of this.=20 It's a mess folks, and its getting worse.....and it all starts with the flawed notion that MPLS =3D=3D IP, and the arch violations and func deficiencies of MPLS as-is.....the rest then follows. This stuff is not meeting our requirements as a large network operator....yet the re-spun charter's opening bars strongly suggest this is who this is targeted at.=20 Regards, Neil > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Sasha Vainshtein > Sent: 02 August 2004 23:25 > To: Niven-jenkins,B,Ben,XGH5 R; Stewart Bryant (E-mail);=20 > Danny McPherson (E-mail) > Cc: Sharon Galtzur; pwe3@ietf.org; Alik Shimelmits > Subject: RE: [PWE3] Draft PWE3 Charter >=20 >=20 > Ben, Stewart, Danny and all, >=20 > It looks like there are multiple interpretations of the > desired WG scope wrt multi-hop PWs. >=20 > One interpretation considers these PWs as solutions for > inter-provider/inter-area problems. >=20 > Another deals with limited number of targeted LDP sessions > and different PSN technologies etc.=20 >=20 > There are also issues related to QoS, dual homing etc. >=20 > And, IMHO, there are issues that go beyond the mere PW > stitching/switching, like routing=20 > (how do you find your S-PEs where the switching is done?) and=20 > OAM (how do you identify the faulty=20 > PW segment if you have U-PE-to-U-PE problems?) etc. >=20 > I think that we need a wider definition of scope of the > related work in the Charter that would include: >=20 > - clear specification of requirements for MH-PWs including > some guidelines as to when these must be > preferred over some simpler solution (e.g., a SH-PW over=20 > L2TPv3). These requirements should address > the inter-provider/inter-area case but are not necessarily=20 > limited to this case >=20 > - additions to the PWE3 architecture/reference models > addressing the MH-PW issues (the present > architecture seems tightly bound to the SH-PW case). The=20 > mere fact that I have to use the new > terms like U-PE/S-PE proves in my eyes that this work is necessary >=20 > - identification of a small number of solutions addressing > these requirements with the appropriate > applicability statements >=20 > - specification of the appropriate OAM mechanisms (or > modification of the existing OAM mechanisms) > facilitating effective fault localization >=20 > - extension of the PWE3 MIBs supporting MH-PWs (I suspect - > even if I did not check - that the current > PWE3 MIBs do not address the MH-PW issues?) >=20 > In fact, I think that there is a lot of work to do - and I > think this work is necessary, too. >=20 > Hopefully these notes will be useful. >=20 > -------------------------------------------------------------- > -------------- > -------- > With best regards, > Sasha Vainshtein > email: sasha@axerra.com =20 > phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) >=20 >=20 > > -----Original Message----- > > From: benjamin.niven-jenkins@bt.com=20 > > [mailto:benjamin.niven-jenkins@bt.com] > > Sent: Monday, August 02, 2004 4:18 PM > > To: pwe3@ietf.org > > Subject: RE: [PWE3] Draft PWE3 Charter > >=20 > >=20 > > Folks, > >=20 > > One of the WG objectives of the old charter was: > > "The WG will determine the requirements for having a pseudo wire=20 > > pass across an administrative boundary." > >=20 > > One of the WG objectives of the new charter is: > > "Define mechanisms to allow the inter-domain operation of PWs." > >=20 > > IMO a requirements definition should come before a solution=20 > > definition. Given that there are now drafts proposing solutions to=20 > > the problem of inter-domain PWs (i.e. PW > > switching/stitching) can I assume that the requirements for > > "inter-domain operation of PWs" have been identified? If so,=20 > > where can I find those requirements documented? > >=20 > > Thanks > > Ben > >=20 > > -- > > Ben Niven-Jenkins > > Networking Specialist > > Next Generation IP/Optical Networks, BT Exact > >=20 > > e-mail: benjamin.niven-jenkins@bt.com > > tel: +44(0) 1473 648225 > > fax: +44(0) 1473 620109 > >=20 > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5=20 > > 3RE, UK > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Draft PWE3 Charter Date: Tue, 3 Aug 2004 14:48:25 +0100 Lines: 206 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: narten@us.ibm.com, benjamin.niven-jenkins@bt.com, peter.j.willis@bt.com, danny@arbor.net, richard.spencer@bt.com, andy.bd.reid@bt.com, alan.mcguire@bt.com X-From: pwe3-bounces@ietf.org Tue Aug 03 15:49:51 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Draft PWE3 Charter Thread-Index: AcR2RQbYqQTQMbTgSbev2sWpHLZsNgABPn+Q To: , X-OriginalArrivalTime: 03 Aug 2004 13:48:26.0329 (UTC) FILETIME=[8D0A2490:01C47960] X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Stewart....a few observations in-line. Regards, Neil > Here is the proposed updated PWE3 Charter that Danny and I sent to=20 > Thomas a little while ago. >=20 > We will be working on this at the meeting next week, but comments=20 > ahead of time would be appreciated. >=20 > - Stewart >=20 >=20 > Description of Working Group: >=20 > Network operators NH=3D> So this is now aimed at the likes of BT I take it and has very little to do with the Internet? > and their subscribers NH=3D> 'Subscribers' is a bit old-hat these days.....suggest 'customers' (noting that there are client/server relationships even between operators). Though I am not sure why even 'customers' needs to appear here anyway. > are seeking to > rationalize their networks by migrating to a single, IP or=20 > MPLS based packet switched network. NH=3D> This is not completely accurate. A full service operator like BT actually needs all 3 network modes....as they do different jobs. What we primarily want is rationalisation of technologies that belong to the same mode, because in the past this has created the so-called 'stovepipe' problem (ie selling a specific technology and its features as the 'service'). This also continues the interworking headache. So its not appropriate to say 'a single network' nor, as a slight technical correction, is it 'IP *or* MPLS'.....both a cl-ps mode and co-ps mode are required if one wants to correctly cater for all public/private services. As a suggestion try this text: "Operators want to reduce the number of different technologies in each network mode that support both public and private services. This essentially means convergence to IP and MPLS as the target core technologies." > This migration requires=20 > communications services that can emulate the essential=20 > properties of traditional communications links over a packet=20 > switched network (PSN). NH=3D> I am not sure that the word 'emulation' is correct here. If I = look at the current PW stuff it is simply client/server encapsulation. Client compression is not really emulation....this is simply BW squeezing, which is hardly a key issue anyway given core networks usually run at low loads. So IMO a more accurate description of what PWE3 are currently doing (or should be doing) would be: "As part of the convergence process there will be a requirement for the IP and MPLS target core networks to carry various legacy technologies. This places no obligations on the functions/features of the core IP and MPLS networks (but see Note) to replicate legacy technology functions or features. However, there is an overarching requirement for transparent client carriage and an ability to meet the availability and transfer network performance requirements of the clients. Note - The core IP and MPLS networks still require to be completely functionally specified in their own right for the mode they represent, and they must respect the connectivity constraints of their mode." >=20 > Pseudowire Emulation Edge to Edge (PWE3) will specify the=20 > encapsulation, transport, control, management, interworking=20 > and security of services emulated over IETF specified packet=20 > switched networks. NH=3D> Just an observation here. Not sure you need 'interworking' mentioned. The word 'encapsulation' intimates one has a client/server relationship here. The so-called (badly) 'service-interworking' concept that was used with FR and ATM in FRF.8 is not a general case, because when one has different server technologies partitions (carrying some common client on each) all the characteristic information of each server technology partition must be terminated at the interworking point. This ought to be obvious IMO as there will be a mismatch of functions and/or features, especially when the technology partitions belong to different modes. >=20 > A pseudowire emulates a point-to-point link, and provides a=20 > service which is perceived by its user as an unshared link or=20 > circuit of the chosen service. >=20 > It is not intended that an emulated service will be=20 > indistinguishable from the service that is being emulated.=20 > The emulation need only be sufficient for the satisfactory=20 > operation of the service. Emulation necessarily involves a=20 > degree cost-performance trade-off. In some cases it may=20 > necessary to design more than one emulation mechanism in=20 > order to resolve these design conflicts. All emulated service=20 > definitions will provide an applicability statement=20 > describing the faithfulness of the emulation. NH=3D> Seems a lot of text to describe something that is not even being done (see prior common wrt 'emulation vs encapsulation'). The real issue here is wrt to satisfying the transfer network performance that the client will get IMO. >=20 > Switching, multiplexing, modification or other operation on > the traditional service, unless needed as part of the=20 > emulation is out of the scope of the PWE3 WG. >=20 > PWE3 will make use of existing IETF specified mechanisms > unless there are technical reasons why the existing=20 > mechanisms are insufficient or unnecessary. >=20 > PWE3 will not exert control on the underlying PSN, other than=20 > to use any existing QoS or path control mechanism to provide=20 > the required connectivity between the two ends of the PW. >=20 > PWE3 will use RTP where necessary to perform clock recovery=20 > and other real-time signaling functions. This work will be=20 > coordinated with the AVT WG and payloads will follow RFC 2736. >=20 >=20 > WG Objectives (in order of priority): >=20 > Specify the following PW types: > Ethernet, Frame Relay, PPP, HDLC, ATM, TDM and SONET >=20 > Specify the control and management of the PW types > identified above. >=20 > Specify OAM mechanisms for all PW types, suitable for > operation over both IP and MPLS PSNs, and capable of > providing the necessary interworking with the OAM mechanisms > of the emulated service. NH=3D> If a client is transparently carried (which ought to be the default) this is a non-issue as the client OAM should be carried completely transparently. The only thing you have to get right is this: the defects that occur in the server layer need detecting/handling there, and one consequence is the generation of the appropriate client FDI. And this really should be be done in the data-plane (though some clients are not well specified in this respect). Further, speaking as an operator I don't want to see a plethora of OAM (or indeed other functional components)......esp when there are unnecessarily complex relationships between the components (see my earlier posting where I tagged a mail from Sasha). The defects of the cl-ps mode are *not* the same as the co-ps mode, and neither are the same as those of the co-cs mode. 1 size does not fit all, but neither are multiple solutions per mode required. Use the right functional solutions for the mode considered. Putting this more simply: The OAM required for IP is not the same as that required for MPLS, and neither is the same as that required for SDH (read this as GMPLS if that helps).=20 >=20 > Enhance packet-based PW specifications as necessary to > allow the emulated service to be carried transparently > over the PSN, for example by the retention of the FCS > across the PW. NH=3D> This is hardly an 'enhancement'. Removing it in the 1st place is an error of judgement IMO. BW squeezing of the client is not a priority requirement. The default behaviour should be transparent client carriage over the server. >=20 > Define mechanisms to permit the operation of a PW over > a PSN that deploys equal cost multiple path packet (ECMP) switching. NH=3D> How can you do this (or make it a requirement) when ECMP is not standardised? ECMP in IP is not at all the same thing as ECMP in MPLS IMO. >=20 > Specify the encapsulation, control and management of an > IP PW type. >=20 > A PW operating over a shared PSN does not have the same=20 > intrinsic security as a dedicated purpose built network. In=20 > some cases this is perfectly satisfactory. In other cases it=20 > will be necessary to enhance the security of the PW to=20 > emulate the intrinsic security of the emulated service. NH=3D> There is no reason IMO why a properly specified MPLS network = cannot offer similar security levels to other co-ps technologies. >=20 > Whilst a service provider may traffic engineer their network > is such a way that PW traffic will not cause significant=20 > congestion, a PW deployed by an end-user may cause congestion=20 > of the underlying PSN. Suitable congestion mechanisms are=20 > therefore needed to protect the Internet from the=20 > unconstrained deployment of PWs. NH=3D> I thought this stuff was being targeted at operators of = commercial networks? Well that's what the opening paragraph implies. >=20 > Define mechanisms to allow the interconnection of PWs. NH=3D> What does this mean? Is this between PWs supported by the same server layer technology (ie both IP or both MPLS) or different server layer technologies (which also seems to imply some interworking of (at least) signalling of the IP or MPLS server layer networks)? >=20 > Define mechanisms to allow the inter-domain operation of PWs. >=20 > Define the mechanisms needed to allow the operation of=20 > switched virtual circuits over a PSN. NH=3D> Which SVCs? I assume you must mean ATM SVCs. One could of = course imagine MPLS LSP SVCs. >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Yakov Rekhter Subject: Re: UDP questions Date: Tue, 03 Aug 2004 07:37:46 -0700 Lines: 12 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202D9B107@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 03 16:44:16 2004 Return-path: To: "Yaakov Stein" In-Reply-To: Your message of "Tue, 03 Aug 2004 06:09:19 +0300." <27A0F290348F8E45AEF79889DDE65A5202D9B107@exrad2.ad.rad.co.il> Content-ID: <85479.1091543866.1@juniper.net> X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yaakov, > Following my presentation today, > I would like to solicit responses to the 2 questions I raised. > > 1) Should the PW label be placed in > A) destination UDP port field (has NAT/firewall issues) > B) source UDP port ? Should the PW label be placed in the UDP header in the first place ? Yakov. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Yakov Rekhter Subject: Re: Draft PWE3 Charter Date: Tue, 03 Aug 2004 08:00:58 -0700 Lines: 20 Sender: pwe3-bounces@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538909FE8F4B@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: benjamin.niven-jenkins@bt.com, peter.j.willis@bt.com, alik@AXERRA.com, alan.mcguire@bt.com, dave.milham@bt.com, pwe3@ietf.org, richard.spencer@bt.com, andy.bd.reid@bt.com, danny@tcb.net, sharon@AXERRA.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Tue Aug 03 17:11:52 2004 Return-path: To: neil.2.harrison@bt.com In-Reply-To: Your message of "Tue, 03 Aug 2004 11:41:20 BST." <0536FC9B908BEC4597EE721BE6A3538909FE8F4B@i2km07-ukbr.domain1.systemhost.net> Content-ID: <87874.1091545258.1@juniper.net> X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Neil, > Not half Sasha! We in BT are very concerned at where PWE3 are now > heading, and we had a long internal discussion on this yesterday. > > PWE3 work is clearly nothing to do with the Internet any longer (as if > it ever was), If that is indeed the case, then the PWE3 WG should be dissolved, as its work would be outside of the mission for the IETF. Quoting from draft-alvestrand-ietf-mission-02 (" A Mission Statement for the IETF"): The goal of the IETF is to make the Internet work better. The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use and manage the Internet in such a way as to make the Internet work better. Yakov. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 3 Aug 2004 16:32:50 +0100 Lines: 69 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, busschbach@lucent.com, dpapadimitriou@psg.com X-From: pwe3-bounces@ietf.org Tue Aug 03 17:38:58 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR43lCDn2wMNlTcRo6Hybg2c7nXpQAVwbvw To: X-OriginalArrivalTime: 03 Aug 2004 15:32:51.0526 (UTC) FILETIME=[23635660:01C4796F] X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Mustapha, > Richard and Dimitri, > this issue is in my view one of the critical issues. I believe a > workable solution should have the following characteristics: >=20 > 1. State how stitching nodes are discovered. I do not agree with > Peter that a stiching node is just another LSP switching node. There > are PW specific operations to be performed in the data, control, and > management (OAM) planes on a PW segment. I agree that a PW stitching node is not just another (tunnel) LSP switching node. The data plane behaviour (i.e. MPLS label switching) may be the same but the tunnel LSP control protocols needs to be modified (or separate control protocols/instances used) in order to support single sided provisioning of switched PWs. I think discovery can be split up into two aspects, i) discovery of ingress/egress PEs, and ii) discovery of PW switching nodes. Regarding i) this is required to support single sided provisioning. Regarding ii), this is only required if routers use the same address space (i.e. same loopback addresses) at the PW layer that they use at the MPLS tunnel layer. If a different address space was used then support for PW switching would be explicit. The consequence of using the same addresses is that PW switching capable nodes must be distinguish from non PW switching capable nodes explicitly using a discovery mechanism or implicitly, e.g. using routing metrics as is the case with the FA-LSP solution. > 2. State how routing of PW control messages are performed once the > stitching nodes have been discovered. It seems to me that a solution > that mandates the use of FA-LSPs is too restrictive. I agree that mandating FA-LSPs is too restrictive and that a common PW routing solution should be specified.=20 > 3. Avoid if possible making the PW label routable. Not that I have > anything against that but if a solution turns PWs into routable > entities on their own, then we should discuss it in that wider > context. In that case, the use of tunnel LSPs becomes a convenience > as opposed to a requirement of the architecture. I'm not sure I understand your last point; it appears to me to be a contradiction. In 2 you state that routing of PW control messages must be addressed but then in 3 state that making PWs routable should be avoided. I think there are two issues here, a) routing at the PW layer where LSPs tunnels are used (resulting in a two layer LSP hierarchy), b) routing where tunnel LSPs are not used (resulting in a single LSP layer). Regarding a), in the control plane, routing is required at the PW layer to calculate/select the PW path from ingress PE to egress PE across intermediate PW switching points and therefore the PE IP addresses must be routable. In the (PW) data plane the PW label needs to be used at each hop to make a forwarding decision. However, even though PWs need to be routable at the PW level, they are not routable at the tunnel LSP level, i.e. forwarding at the LSP tunnel level is based on tunnel LSP labels not PW labels, just like VP switching in ATM is based on VPIs not VCIs. Regarding b), if tunnel LSPs are not used then PWs must still be routable at the PW layer, but as this is the only layer each hop must belong to the PW layer, i.e. each hop must support PW switching. For scaling reasons its highly unlikely that a single LSP layer would be used in the core, but I think using a single LSP layer would make sense for spoke connections in the hierarchical LDP model. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 3 Aug 2004 16:52:35 +0100 Lines: 76 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 03 18:07:23 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR5GWIEkDpMIvLoTbCU5/L2FkXUxwAKMwNA To: , X-OriginalArrivalTime: 03 Aug 2004 15:52:36.0784 (UTC) FILETIME=[E5DB5B00:01C47971] X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, > Hi Richard, >=20 > You are right. In the case of LDP signaling for tunnel LSPs, a PW > switching node would need additional policies to determine when to tunnel > traffic and where to tunnel it to. >=20 > In the worst case, we could revert to the solution that other drafts > propose: the Service Provider explicitly identifies which nodes are PW > switching nodes. However, I could imagine that there are more general > policies that require less manual engineering and provisioning. E.g rules > like: (a) if the destination PE is in the same OSPF area use a tunnel that > terminates directly on that PE. If the PE is in a different OSPF area, use > a tunnel that terminates on an Area Border Router. PW switching only needs to be performed when a provider doesn't have a full mesh of tunnel LSPs, which is why I do not agree with your suggestion in an earlier post that any LSR may need to support PW switching. IMO only specific LSRs will need to support PW switching and therefore a provider will always know which nodes need to be PW switching capable. In the hierarchical LDP case the nodes that need to be PW switching capable are the hub (PErs) nodes, in the intra-provider case the nodes that need to be PW switching capable are the border routers (on which the tunnel LSPs terminate). As a provider will know before deploying a node whether or not it will need to support PW switching, I do not think manually provisioning (or using OSS) to configure nodes to support PW switching when they are deployed will be an issue. > In my first email to you, I wrote: "The question is therefore not: what > routing protocols do we need to find multi-hop capable routers?; but: what > are the policies that drive an LSR to bundle multiple PW-LSPs into a > single transport LSP?" >=20 > I don't think the second problem is trivial, but I think it is better to > try to solve the second problem than the first. (Unless we decide that PW > switching is only relevant when crossing AS boundaries, in which case BGP > probably offers a good solution for the first problem.) I'm not asking which routing protocols need to be used at this stage, I'm just saying that from a functional perspective routing needs to be performed. I still don't think the issue has anything to do with policies, IMO the problem is routing at the PW layer. The FA-LSP solution works because FA-LSPs are advertised as next hops to reach PE IP loopback addresses, which creates a server layer topology that can be used by the PW layer. As far as the PW layer is concerned, the FA-LSPs are point-to-point links, the P routers between FA-LSP source/sink pairs are transparent to the PW layer. However, this only works if routing metrics are used correctly to ensure that FA-LSP next hops are always chosen over IGP adjacency based next hops. As David Allan points out, manipulating routing metrics to ensure FA-LSP next hops are always chosen over IGP adjacency next hops may lead to problems. If however LDP tunnel LSPs are to be used for carrying MH-PWs then they can not be advertised by the IGP as links and therefore PW layer routing/next hop information must somehow be distributed in order to determine the MH-PW topology. Also, if the PW layer and tunnel LSP layer share the same addressing, then a mechanism must be used to distinguish between PW switching capable nodes and non PW switching capable nodes. In the FA-LSP solution, this is achieved via manipulating routing metrics to ensure that PW-LSP next hops are chosen over IGP adjacency next hops, i.e. discovery is implicit rather than explicit, the best next hop *should* support PW switching. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: UDP questions Date: Tue, 3 Aug 2004 19:18:37 +0300 Lines: 40 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 03 18:29:57 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] UDP questions Thread-Index: AcR5Z1iAqPxaRZieRTKtidel7UyeFwADaxig To: "Yakov Rekhter" X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yakov,=20 We have already had this discussion, with Eric asking this question. The main reasons for allowing this are: 1) it is already widely employed for TDM PWs 2) it is arguably the first PW technique 3) it aligns with avt work 4) it is in the charter 5) it is in the arcitecture document. So if we find strong reasons AGAINST its use, then I can understand our considering prohibiting it. But wouldn't any such reason would impact avt work as well? Y(J)S > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net]=20 > Sent: Tuesday, August 03, 2004 17:38 > To: Yaakov Stein > Cc: pwe3@ietf.org > Subject: Re: [PWE3] UDP questions=20 >=20 > Yaakov, >=20 > > Following my presentation today, > > I would like to solicit responses to the 2 questions I raised. > >=20 > > 1) Should the PW label be placed in > > A) destination UDP port field (has NAT/firewall issues) > > B) source UDP port ? >=20 > Should the PW label be placed in the UDP header in the first place ? >=20 > Yakov. >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Ron Cohen" Subject: RE: UDP questions Date: Tue, 3 Aug 2004 09:34:20 -0700 Lines: 151 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202D9B107@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0733280325==" X-From: pwe3-bounces@ietf.org Tue Aug 03 18:46:52 2004 Return-path: To: "'Yaakov Stein'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5202D9B107@exrad2.ad.rad.co.il> X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0733280325== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C4793D.0F3C9110" This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C4793D.0F3C9110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaakov, My input: 1. Destination UDP port should be the multiplexer 2. Don't know Thanks Ron -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein Sent: Monday, August 02, 2004 8:09 PM To: pwe3@ietf.org Subject: [PWE3] UDP questions Following my presentation today, I would like to solicit responses to the 2 questions I raised. 1) Should the PW label be placed in A) destination UDP port field (has NAT/firewall issues) B) source UDP port ? 2) What label distribution should be used A) implicit upstream (has security considerations) B) standard LDP-based PWE protocol C) other ? Y(J)S ------=_NextPart_000_0004_01C4793D.0F3C9110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Yaakov,
 
My=20 input:
 
1. = Destination=20 UDP port should be the multiplexer
2. = Don't=20 know
 
Thanks
Ron
-----Original Message-----
From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of=20 Yaakov Stein
Sent: Monday, August 02, 2004 8:09 = PM
To:=20 pwe3@ietf.org
Subject: [PWE3] UDP = questions


Following = my presentation=20 today,

I would = like to solicit=20 responses to the 2 questions I raised.

1) Should = the PW label be=20 placed in

    A)=20 destination UDP port field (has NAT/firewall issues)

    B)=20 source UDP port     ?


2) What = label distribution=20 should be used

    A)=20 implicit upstream (has security considerations)

    B)=20 standard LDP-based PWE protocol

    C)=20 other     ?


Y(J)S

------=_NextPart_000_0004_01C4793D.0F3C9110-- --===============0733280325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0733280325==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: UDP questions Date: Tue, 3 Aug 2004 19:34:04 +0200 Lines: 73 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Yakov Rekhter , pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 03 18:53:40 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yaakov, Please see a brief comment 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: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Tuesday, August 03, 2004 6:19 PM > To: Yakov Rekhter > Cc: pwe3@ietf.org > Subject: RE: [PWE3] UDP questions > > > Yakov, > > We have already had this discussion, > with Eric asking this question. > > The main reasons for allowing this are: > > 1) it is already widely employed for TDM PWs > 2) it is arguably the first PW technique > 3) it aligns with avt work [Sasha] If this is the reason, then the answer to the rest of the questions seems obvious, as this reason only makes sense if the UDP ports are used in an AVT-compliant way. And this is OK with me. > 4) it is in the charter > 5) it is in the arcitecture document. > > So if we find strong reasons AGAINST its use, > then I can understand our considering prohibiting it. > But wouldn't any such reason would impact avt work as well? > > Y(J)S > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Tuesday, August 03, 2004 17:38 > > To: Yaakov Stein > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] UDP questions > > > > Yaakov, > > > > > Following my presentation today, > > > I would like to solicit responses to the 2 questions I raised. > > > > > > 1) Should the PW label be placed in > > > A) destination UDP port field (has NAT/firewall issues) > > > B) source UDP port ? > > > > Should the PW label be placed in the UDP header in the first place ? > > > > Yakov. > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: Draft PWE3 Charter Date: Tue, 3 Aug 2004 19:37:16 +0300 Lines: 52 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 03 18:54:09 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] Draft PWE3 Charter Thread-Index: AcR42oYbjRDj4alHRym9mFFDAsDAngAUxY/gABIBplA= To: X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > PWE3 work is clearly nothing to do with the Internet any=20 > longer (as if it ever was) The PWE work is begin done in the IETF due to its being related to MPLS and L2TP, both of which are being=20 developed here. No-one is implying that PWs MUST be sent over the public Internet, rather than well-engineered IP networks,=20 although nothing prohibits this either. > but what is being created now is=20 > hardly what operators need either in our view=20 Well, perhaps there are other types of operators. Also, as I have argued before, perhaps a lot of this work should be directed towards the enterprise space instead. So I would assume that you would have no problem with our specifically adding enterprise applications to our charter? > as we see it, both the large operator=20 > requirements and the public Internet requirements are being=20 > compromised by what looks like a bunch of enterprise grade=20 > stuff). =20 See my question above. Please take into account that the IETF, unlike the ITU, first solves the data transfer problem, and only afterwards looks into other issues (e.g. OAM). > Wrt PW sw/titching, and no matter how this is=20 > dressed-up, as Richard pointed out a few days ago this is=20 > creating a new layer network......that is simply a fact=20 > whether it is understood or not by some folks.=20 I have been saying for a long time that we should stop pretending that PWs are NOT a full blown layer network. > The root problem is MPLS !=3D IP. How anyone can continue to=20 > maintain a pretence that this is not true is beyond us.=20 No-one is. We are just saying that it is useful to design a layer network (PWE) which can be run over many different PSNs. Obviously, the various aspects will function somewhat differently, e.g. QoS will be different over RSVP-TE MPLS and best-effort IP. But then again RSVP-TE MPLS and LDP MPLS are just as different in this regard. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: UDP questions Date: Tue, 3 Aug 2004 19:38:37 +0300 Lines: 211 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0440357114==" X-From: pwe3-bounces@ietf.org Tue Aug 03 18:58:40 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] UDP questions Thread-Index: AcR5d4D1XhD1MpWKSnmOj0xT0LKe7AAAKyhA To: "Ron Cohen" , X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0440357114== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47978.4D3A3A5B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C47978.4D3A3A5B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ron,=20 =20 Sorry you couldn't make it to San Diego. =20 Do you have a solution to the NAT/firewall issues that arise when using destination UDP field ? =20 Y(J)S =20 ________________________________ From: Ron Cohen [mailto:ronc@lyciumnetworks.com]=20 Sent: Tuesday, August 03, 2004 19:34 To: Yaakov Stein; pwe3@ietf.org Subject: RE: [PWE3] UDP questions =09 =09 Yaakov, =20 My input: =20 1. Destination UDP port should be the multiplexer 2. Don't know =20 Thanks Ron -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein Sent: Monday, August 02, 2004 8:09 PM To: pwe3@ietf.org Subject: [PWE3] UDP questions =09 =09 Following my presentation today, I would like to solicit responses to the 2 questions I raised. 1) Should the PW label be placed in A) destination UDP port field (has NAT/firewall issues) B) source UDP port ? 2) What label distribution should be used=20 A) implicit upstream (has security considerations) B) standard LDP-based PWE protocol C) other ? Y(J)S ------_=_NextPart_001_01C47978.4D3A3A5B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Ron,=20
 
Sorry=20 you couldn't make it to San Diego.
 
Do you=20 have a solution to the NAT/firewall issues
that=20 arise when using destination UDP field ?
 
Y(J)S
 

From: Ron Cohen=20 [mailto:ronc@lyciumnetworks.com]
Sent: Tuesday, August 03, = 2004=20 19:34
To: Yaakov Stein; pwe3@ietf.org
Subject: RE: = [PWE3]=20 UDP questions

Yaakov,
 
My=20 input:
 
1. Destination=20 UDP port should be the multiplexer
2. Don't=20 know
 
Thanks
Ron
-----Original Message-----
From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Yaakov Stein
Sent: Monday, August 02, 2004 8:09=20 PM
To: pwe3@ietf.org
Subject: [PWE3] UDP=20 questions


Following my=20 presentation today,

I would = like to solicit=20 responses to the 2 questions I raised.

1) = Should the PW label=20 be placed in

    A)=20 destination UDP port field (has NAT/firewall = issues)

    B)=20 source UDP port     ?


2) What = label=20 distribution should be used

    A)=20 implicit upstream (has security considerations)

    B)=20 standard LDP-based PWE protocol

    C)=20 other     ?


Y(J)S

------_=_NextPart_001_01C47978.4D3A3A5B-- --===============0440357114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0440357114==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Scott W Brim Subject: Re: UDP questions Date: Tue, 3 Aug 2004 09:40:44 -0700 Lines: 9 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202D9B2A4@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Tue Aug 03 18:58:45 2004 Return-path: X-BrightmailFiltered: true To: pwe3@ietf.org Mail-Followup-To: Scott W Brim , pwe3@ietf.org Content-Disposition: inline In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5202D9B2A4@exrad2.ad.rad.co.il> User-Agent: Mutt/1.4.1i X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Tue, Aug 03, 2004 07:18:37PM +0300, Yaakov Stein allegedly wrote: > 1) it is already widely employed for TDM PWs > > > 1) Should the PW label be placed in > > > A) destination UDP port field (has NAT/firewall issues) > > > B) source UDP port ? If it's already widely deployed, we can go with the format that is dominant in real networks? From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: UDP questions Date: Tue, 3 Aug 2004 19:42:28 +0300 Lines: 26 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Yakov Rekhter , pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 03 19:00:31 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] UDP questions Thread-Index: AcR5eAdQSYpQQGelQ46st9rBJeuRLAAAFoDw To: "Sasha Vainshtein" X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org =20 > > 3) it aligns with avt work > [Sasha] If this is the reason, then the answer to the rest of=20 > the questions seems obvious, as this reason only makes sense=20 > if the UDP ports are used in an AVT-compliant way. >=20 > And this is OK with me. Sasha,=20 This is certainly a complelling argument. Unfortunately, as I am sure you know, VoIP has terrible problems with getting through firewalls. I can't use VoIP from my office PC. Skype and others are having tremendous success with alternative protocols, precisely because they can get around this issue. So why repeat this fiasco and have someone come up with a non-PWE-sanctioned protocol and capture the market claiming it is better for this reason? Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: TDM Control Protocol extensions to a WG draft Date: Tue, 3 Aug 2004 19:41:19 +0200 Lines: 20 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: "Stewart Bryant \(E-mail\)" , "Danny McPherson \(E-mail\)" X-From: pwe3-bounces@ietf.org Tue Aug 03 19:03:11 2004 Return-path: To: "PWE3 WG (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi all, Following my yesterday presentation of draft-vainshtein-pwe3-tdm-control-protocol-extensi-01.txt, I ask the WG to accept it as a WG item. As I have explained, the reason for not including this stuff in one of the 3 WG TDM drafts is the fact that it covers all the encapsulations with lots of common elements. And triplicating it in the different encapsulation drafts (ofwhich one has been already sent to the IESG) seems a non-starter. Your feedback will be highly appreciated. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 3 Aug 2004 13:10:31 -0400 Lines: 127 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 03 19:38:45 2004 Return-path: To: "'richard.spencer@bt.com'" , mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: Tuesday, August 03, 2004 11:53 AM > To: busschbach@lucent.com; mustapha.aissaoui@alcatel.com > Cc: du.ke@zte.com.cn; l2vpn@ietf.org; pwe3@ietf.org > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > Peter, > > > Hi Richard, > > > > You are right. In the case of LDP signaling for tunnel LSPs, a PW > > switching node would need additional policies to determine when to > tunnel > > traffic and where to tunnel it to. > > > > In the worst case, we could revert to the solution that other drafts > > propose: the Service Provider explicitly identifies which > nodes are PW > > switching nodes. However, I could imagine that there are > more general > > policies that require less manual engineering and provisioning. E.g > rules > > like: (a) if the destination PE is in the same OSPF area > use a tunnel > that > > terminates directly on that PE. If the PE is in a different > OSPF area, > use > > a tunnel that terminates on an Area Border Router. > > PW switching only needs to be performed when a provider doesn't have a > full mesh of tunnel LSPs, which is why I do not agree with your > suggestion in an earlier post that any LSR may need to support PW > switching. Richard, I never said that every LSR needs to function as PW switching node. I said every LSR *can* support PW switching. The issue is the following. If you read draft-martini-pwe3-pw-switching-00.txt, you get the impression that a PW Switching node is a special network element. It needs to support PW control protocols, be aware of PW-specific identifiers, support various data plnae interworking functions, etc. The point I was trying to make is that in many cases, a PW Switching node is nothing more than an LSR that switches PW labels. As you correctly pointed out: that is not the end of the story. If a Service Provider does not want to pre-provision FA-LSPs, an LSR that has been selected as a PW Switching node needs additional functionality. I called that additional functionality "policies regarding when to tunnel LSPs". You call it "PW routing". I think these are two aspects of the same problem, but I am happy to use your terminology. The important issue, though, is that this could be treated as a general problem related to label stacking and not just as a PW specific problem. So in my view there are two options: 1) Consider PW switching nodes as special network elements that are tailor-made for PW switching 2) Add a function to the MPLS control plane (like fast reroute or graceful restart) to deal with label stacking and its impact on routing and LSP setup. In yesterday's WG meeting we decided that we need to establish the requirements for PW switching first, before we discuss solutions. Based on the requirements it is well possible that we end up doing 1). However, in the long rung, 2) might be more useful as it could apply to other problems than PWE as well. Peter IMO only specific LSRs will need to support PW > switching and > therefore a provider will always know which nodes need to be PW > switching capable. In the hierarchical LDP case the nodes that need to > be PW switching capable are the hub (PErs) nodes, in the > intra-provider > case the nodes that need to be PW switching capable are the border > routers (on which the tunnel LSPs terminate). As a provider will know > before deploying a node whether or not it will need to support PW > switching, I do not think manually provisioning (or using OSS) to > configure nodes to support PW switching when they are deployed will be > an issue. > > > In my first email to you, I wrote: "The question is therefore not: > what > > routing protocols do we need to find multi-hop capable > routers?; but: > what > > are the policies that drive an LSR to bundle multiple PW-LSPs into a > > single transport LSP?" > > > > I don't think the second problem is trivial, but I think it > is better > to > > try to solve the second problem than the first. (Unless we > decide that > PW > > switching is only relevant when crossing AS boundaries, in > which case > BGP > > probably offers a good solution for the first problem.) > > I'm not asking which routing protocols need to be used at this stage, > I'm just saying that from a functional perspective routing needs to be > performed. I still don't think the issue has anything to do with > policies, IMO the problem is routing at the PW layer. The FA-LSP > solution works because FA-LSPs are advertised as next hops to reach PE > IP loopback addresses, which creates a server layer topology > that can be > used by the PW layer. As far as the PW layer is concerned, the FA-LSPs > are point-to-point links, the P routers between FA-LSP > source/sink pairs > are transparent to the PW layer. However, this only works if routing > metrics are used correctly to ensure that FA-LSP next hops are always > chosen over IGP adjacency based next hops. As David Allan points out, > manipulating routing metrics to ensure FA-LSP next hops are always > chosen over IGP adjacency next hops may lead to problems. > > If however LDP tunnel LSPs are to be used for carrying MH-PWs > then they > can not be advertised by the IGP as links and therefore PW layer > routing/next hop information must somehow be distributed in order to > determine the MH-PW topology. Also, if the PW layer and > tunnel LSP layer > share the same addressing, then a mechanism must be used to > distinguish > between PW switching capable nodes and non PW switching capable nodes. > In the FA-LSP solution, this is achieved via manipulating routing > metrics to ensure that PW-LSP next hops are chosen over IGP adjacency > next hops, i.e. discovery is implicit rather than explicit, the best > next hop *should* support PW switching. > > Regards, > Richard > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: UDP questions Date: Tue, 03 Aug 2004 13:11:08 -0400 Lines: 12 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202D9B2B2@exrad2.ad.rad.co.il> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Yakov Rekhter , pwe3@ietf.org, Sasha Vainshtein X-From: pwe3-bounces@ietf.org Tue Aug 03 19:41:07 2004 Return-path: X-BrightmailFiltered: true To: "Yaakov Stein" In-reply-to: Your message of Tue, 03 Aug 2004 19:42:28 +0300. <27A0F290348F8E45AEF79889DDE65A5202D9B2B2@exrad2.ad.rad.co.il> 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.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I am still opposed to this use of UDP and would like to see a WG consensus before we respond positively to the ITU-T liaison. However, if one were going to use one of the UDP port fields for PW multiplexing, the only things that makes any sense to me is using the source port field, with a well known value in the destination port field. Of course, since there is no signaling to support the use of this encapsulation, I don't really see the point. If L2TP cannot be used, then MPLS-in-GRE would seem to be the best thing. One advantage is that the security section for it has already been written. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Ron Cohen" Subject: RE: UDP questions Date: Tue, 3 Aug 2004 10:12:17 -0700 Lines: 302 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202D9B2AE@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1807629984==" X-From: pwe3-bounces@ietf.org Tue Aug 03 19:42:03 2004 Return-path: To: "'Yaakov Stein'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5202D9B2AE@exrad2.ad.rad.co.il> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1807629984== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C47942.5C7D8970" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C47942.5C7D8970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaakov, >Do you have a solution to the NAT/firewall issues >that arise when using destination UDP field ? 1. No 2. Have the same solution as VoIP or whatever else 3. It is out of the scope of PWE3 charter (or at least I hope it is) 4. Per spec UDP dest port is the multiplexer that selects the process/socket on the destination system. If the suggestion is to use src port as multiplexer I would prefer not to have UDP option for PWE3 at all. Cheers Ron -----Original Message----- From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Tuesday, August 03, 2004 9:39 AM To: Ron Cohen; pwe3@ietf.org Subject: RE: [PWE3] UDP questions Ron, Sorry you couldn't make it to San Diego. Do you have a solution to the NAT/firewall issues that arise when using destination UDP field ? Y(J)S _____ From: Ron Cohen [mailto:ronc@lyciumnetworks.com] Sent: Tuesday, August 03, 2004 19:34 To: Yaakov Stein; pwe3@ietf.org Subject: RE: [PWE3] UDP questions Yaakov, My input: 1. Destination UDP port should be the multiplexer 2. Don't know Thanks Ron -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein Sent: Monday, August 02, 2004 8:09 PM To: pwe3@ietf.org Subject: [PWE3] UDP questions Following my presentation today, I would like to solicit responses to the 2 questions I raised. 1) Should the PW label be placed in A) destination UDP port field (has NAT/firewall issues) B) source UDP port ? 2) What label distribution should be used A) implicit upstream (has security considerations) B) standard LDP-based PWE protocol C) other ? Y(J)S ------=_NextPart_000_000E_01C47942.5C7D8970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Yaakov,
 
>Do you have a = solution to the=20 NAT/firewall issues
>that arise when = using=20 destination UDP field ?
 
1. No
2. Have the same solution as VoIP = or whatever=20 else
3. It is out of the scope of PWE3 = charter (or at=20 least I hope it is)
4. Per spec UDP dest port is the=20 multiplexer that selects the process/socket on the=20 destination system. If the suggestion is to use src port as = multiplexer I=20 would prefer not to have UDP option for PWE3 at all. =
 
Cheers
Ron
 
 
-----Original = Message-----
From: Yaakov=20 Stein [mailto:yaakov_s@rad.com]
Sent: Tuesday, August 03, = 2004 9:39=20 AM
To: Ron Cohen; pwe3@ietf.org
Subject: RE: [PWE3] = UDP=20 questions

Ron,=20
 
Sorry you couldn't make it to San Diego.
 
Do=20 you have a solution to the NAT/firewall issues
that=20 arise when using destination UDP field ?
 
Y(J)S
 

From: Ron Cohen=20 [mailto:ronc@lyciumnetworks.com]
Sent: Tuesday, August = 03, 2004=20 19:34
To: Yaakov Stein; pwe3@ietf.org
Subject: = RE:=20 [PWE3] UDP questions

Yaakov,
 
My=20 input:
 
1.=20 Destination UDP port should be the multiplexer
2. Don't=20 know
 
Thanks
Ron
-----Original Message-----
From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of=20 Yaakov Stein
Sent: Monday, August 02, 2004 8:09=20 PM
To: pwe3@ietf.org
Subject: [PWE3] UDP=20 questions


Following my=20 presentation today,

I = would like to=20 solicit responses to the 2 questions I raised.

1) = Should the PW label=20 be placed in

    A)=20 destination UDP port field (has NAT/firewall = issues)

    B)=20 source UDP port     ?


2) = What label=20 distribution should be used

    A)=20 implicit upstream (has security considerations)

    B)=20 standard LDP-based PWE protocol

    C)=20 other     ?


Y(J)S

------=_NextPart_000_000E_01C47942.5C7D8970-- --===============1807629984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1807629984==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Draft PWE3 Charter Date: Tue, 3 Aug 2004 19:17:46 +0100 Lines: 84 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 03 20:41:36 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Draft PWE3 Charter Thread-Index: AcR42oYbjRDj4alHRym9mFFDAsDAngAUxY/gABIBplAAA0TE4A== To: X-OriginalArrivalTime: 03 Aug 2004 18:17:46.0622 (UTC) FILETIME=[2D5329E0:01C47986] X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > > PWE3 work is clearly nothing to do with the Internet any longer (as > > if it ever was) >=20 > The PWE work is begin done in the IETF due to its > being related to MPLS and L2TP, both of which are being developed=20 > here. >=20 > No-one is implying that PWs MUST be sent over the public Internet,=20 > rather than well-engineered IP networks, although nothing prohibits=20 > this either. NH=3D> I am very confused as what is the target audience here. I don't see the requirements of the public Internet, the ISP/altnet community, the enterprise community or the large operator community as being the same. The charter does open up saying this is for operators '....seeking to rationalise their networks....'. So this assumes these networks exist.....ISPs and the Internet don't have such legacy networks, we however do.....so I can therefore only infer this is being done for our 'benefit'. >=20 > > but what is being created now is > > hardly what operators need either in our view >=20 > Well, perhaps there are other types of operators. NH=3D> Yes, but far fewer than before......when the technology/architecture creates an environment where opex > profit this tends to happen ;-) > Also, as I have argued before, perhaps a lot of this work should be=20 > directed towards the enterprise space instead. NH=3D> Looks like that sort of stuff to me. >=20 > So I would assume that you would have no problem with > our specifically adding enterprise applications to our charter? NH=3D> Adding? Why not re-spin it to clearly state exactly who the = target audience is so that we are all clear? >=20 > > as we see it, both the large operator > > requirements and the public Internet requirements are being=20 > > compromised by what looks like a bunch of enterprise grade stuff). >=20 > See my question above. >=20 > Please take into account that the IETF, unlike the ITU, > first solves the data transfer problem, and only afterwards looks into > other issues (e.g. OAM). NH=3D> I have noticed. >=20 > > Wrt PW sw/titching, and no matter how this is > > dressed-up, as Richard pointed out a few days ago this is creating a > > new layer network......that is simply a fact whether it is=20 > > understood or not by some folks. >=20 > I have been saying for a long time that we should stop pretending that > PWs are NOT a full blown layer network. NH=3D> Richard continues to make this point quite nicely IMO. Its just = a fact. >=20 > > The root problem is MPLS !=3D IP. How anyone can continue to = maintain > > a pretence that this is not true is beyond us. >=20 > No-one is. NH=3D> Are you sure about that? > We are just saying that it is useful to design a > layer network (PWE) which can be run over many different > PSNs. Obviously, the various aspects will function somewhat=20 > differently, e.g. QoS will be different over RSVP-TE MPLS and=20 > best-effort IP. >=20 > But then again RSVP-TE MPLS and LDP MPLS are just as different in this > regard. NH=3D> Quite. Regards, Neil >=20 > Y(J)S >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Danny McPherson Subject: meeting minutes Date: Tue, 3 Aug 2004 17:28:30 -0600 Lines: 440 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Wed Aug 04 01:46:07 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.618) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Folks, Inline below are the IETF60 PWE3 WG meeting minutes. Thanks yet again to Matthew for serving as scribe. Please send me comments and corrections by 8/20/2004. Thanks! -danny & stewart [snip] Pseudo Wire Emulation Edge to Edge (pwe3) ========================================= MONDAY, August 2, 2004 (1530-1730) CHAIR: "Danny McPherson" "Stewart Bryant" MINUTES: Matthew Bocci matthew.bocci@alcatel.co.uk SLIDES: Available at http://pwe3.tcb.net/meetings/ietf60/index.html ========================================== WG Document Status & Charter Update: Danny McPherson danny@tcb.net & Stewart Bryant --------------------------- Shows slides on WG document status These will be posted to the mailing list. Requirements and architecture are in RFC editor queue. Waiting on some documents: TDM reqs, ATM encap, SATOP, sent to IESG HDLC/PPP to IESG. FCS retention needs update then sent to IESG. WG last call: Frame Relay and cesopsn Work in progress: MIBs are going in parallel with other specs Tom Nadeau: the 1st 3 docs + ethernet MIB and ATM should be ready for last call after meeting Danny McPherson: please send comments to Tom. Most been around for a while Andy Malis: Asked several times for cell transport draft to become WG draft. Danny: noted, OK Charter Update (ppt) Danny: We have moved to the Internet area. Tom Narten is area advisor. Margaret Wasserman is other AD. Stewart: Proposed charter sent to Tom. Waiting for comments. Rewritten text. No work items have been removed, but some new ones added to regularise what we were doing, and in response to suggestions from the list. - Allows more than one emulation for a service (e.g. ATM) - HDLC/PPP - OAM - Transparency - ECMP New: - Including users as well sas SPs - Interconnections between different PWS and the same PWs - IP PW - Congestion PW Control Word & MPLS BCP: Stewart Bryant & Danny McPherson ------------------------------------------------------------ http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw -00.txt MPLS PW control word. Control word removed from PWE3 architecture at request of IETF. George swallow has a BCP draft addressing ECMP Control word draft shows how to address ECMP in PWE3 Explains preferred control word. IANA considerations for 1st 4 bits: 3 ranges - Reserved - PW standards track - Experimental / vendor specific Registry is a catch-all. Tom Nadeau: do we have 2 PW types? Stweart : will regularise text between the two Sahsa Vainstein: Current PWE3 draft specifies IPv4 and IPv6 types. What is proposed if you don't use these for VCCV? Stewart: Setup a dictionary for PWE3. VCCV is VCCV's issue Sasha V: May be resolved by allocated special values for VCCV payloads. A Rahul Aggarwal: need to go back to VCCV document and make sure these things match Mustapha Aissaoui: problem is that we use identifier for both control plane and data plane identifier. We have to understand how we differentiate and signal the two. In some cases may need control word for both data and control planes. General idea of a registry is good. George swallow: If you want to use OAM with control word, you signal it and it uses all zeros. Otherwise you have to signal one of the other needs. Dave Allen: PID avoids gratuitous complexity. Be careful. Tom Nadeau: This is the same PW type as control plane setup. When we need a CW with PW type, will use same registry Dave Allen: Seems like a new way to signal IP. seems complex Danny: we have PWE3 registry for specific purpose. Ther eis still only one. Stewart: have to ask if this can become WG draft Danny: send to list and look at Georges draft too. PWE3 OAM Message Map: Thomas D. Nadeau tnadeau@cisco.com --------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-00 Changes: aligned with WG input (any-to-any), Aligned with draft-aissoui-l2vpn-vpws-iw-oam-01, aligned with MPLS/ATM/FR Alliance OAM documents Trying to work with other groups and not redefine anything Issues: - Timing synchronisation between protocols - End to end vs. partitioned loop model Does anyone care about end-to-end model? Dave Allen: yes Tom: why? Dave Allen: with end to end, don't care what the notification method is in any particular AC. In partitioned case, I'm note sure this is true. Want to discuss this with other authors Rahul Aggarwal: Agrees with point Dave made. Transparent OAM end to end, and second is where you break down end to end OAM from PE to CE, PE to PE, etc. Need to break down both. Yakov Stein: both models have justification: trail extended vs. trail terminated. Mustapha Aissaoui: Draft currently has both models used in specific contexts. Less of an issue with this draft, more of an issue with draft-aissaoui. Plan to discuss on the mailing list. - Congestion Do we need to add congestion control like counting lost packets Danny: need a problem statement, but in priciple yes Tom: leave a placeholder George Swallow: just sets up control channels for this. Tom: need to get document to the ID repository. Sorry, were a little late. Also need to include Ethernet OAM over MPLS mappings Didn't change title, but this is an open question. Respond on mailing list. We are fairly close to what we want. ITU-T Update: Thomas Walsh tdwalsh@lucent.com ---------------------------------------------- Andy Malis presents. Liaison is available online at IESG liasons site. X.84 text online at: see slides for URL Approved for publication in March 2004 Completely based and aligned with PWE3 FR draft, plus some optional stuff for end to end PVC status signalling Needs some IANA actions: FEC128, FEC129, and status code points. Several liaisons have asked for this to be formalised Current IANA procedures, as long as it is in 1st come 1st served space, can do allocation while it is still an ID. Tom Narten: Not just the code points, but also needs the drafts to be approved. IANA cannot hand out code points for a registry that doesn't exist. Sasha Vainstein: is not the allocation of the PW type also needed? This is in FEC 128/129 Andy: That's true Luca Martini: No problem: status TLV code points are not reserved Andy: So really need to get these documents done. FR draft has completed editing at v03, but not in time for this IETF. Is on PWE3 WG server. Yakov Stein: SG 13 approved Y.1413, TDM PW document. Contains 3 drafts here. Danny: have not yet seen liaison from SG13, so would be good to follow up RSVP-TE for Multi-hop PWs: Rahul Aggarwal rahul@juniper.net ----------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-00.txt Idea is to introduce a problem space, a solution, and get a discussion going. Single hop PW: a PW with only 2 PW demux allocation nodes Multi-hop PW: a PW with more than 2 demux allocation nodes Why? - PWs across multiple domains Multiple IGP domains and multiple ASs - PW QoS SLA with emulated service: signalling QoS parameters such as BW, interface types etc PW redundancy - Primary PW and backup PW. Shares QoS resources with primary PW on common nodes. like secondary LSPs in RSVP-TE Motivations: - explicit routing of PWs (QoS provisioning and administration) Why RSVP-TE: - look at entire picture, RSVP-TE provides required mechanisms. Especially of interest to providers running RSVP-TE No intent to pitch against LDP solutions. Simply saying that one solution doesn't fit all. Lists capabilities of RSVP-TE Overview of the mechanisms is given A few points: - Convergence requires QoS, multihop, and PW redundancy. PWE3 needs to look at all of these. PWE3 must look at all of these. We feel RSVP-TE fits the bill. Yakov Stein: anything that helps stitching is good. A few questions about RSVP. - Charter says cannot exert influence on underlying PSN. This sounds like we are forcing the PSN to give us something. Not sure how this works with different underlying PSNs. Rahul: Using RSVP for PW signalling. If underlying PSN signalling is RSVP TE, then its good. They are orthogonal issues. Luca Martini: that's not what the draft says. Nobody is preventing you from using RSVP TE with one tunnel per PW. Eric Rosen: Nobody would use one tunnel per PW. Could use BGP for setting up the PW ;-) We already have two ways to setup a PW. We need to understand what we can't do with existing protocols. No issue with QoS in the PSN (tunnel does this). Doesn't see what RSVP gives you here, or understand sharing of BW Rahul: need to TE the PW over several hops. Tell me how to do this with LDP? Eric Rosen: want to have some architecture to see what is missing from today's protocols and see the requirements. Rahul: once you want PW QoS you need this Kireeti Kompella: should we just do auto-discovery with RSVP, or LDP? Dimitri Papadimitriou: what prevents us from progressing enhanced requirements? Stewart: continue on the list PW Switching (Inter-provider/AS PWs): Luca Martini luca@cisco.com ------------------------------------------------------------------ http://www.ietf.org/internet-drafts/draft-martini-pwe3-pw-switching -00.txt Trying to solve inter-domain PW problem. Slides show an overview of the problem. Sometimes don't want reachability info to be passed between providers, or you may have multiple PSN technologies. Proposes additional control plane between ASBRs, and between ASBRs and PEs Not meant to be a new protocol, or to make LDP scale better. LDP scales very well already; this does not have same issue as BGP. Illustrates differences. Peter Busschbach: So this is really for inter-provider communication. This is not clear in the draft. I like this for inter-provider. For intra provider, would have to configure switching points Luca: don't confuse auto-discovery with this. Configuration of this can be dealt with L2VPN draft. Peter B: This goes back to previous discussion. If inter-provider, this makes sense as you don't want to exchange all information. But, would be more comfortable if we had clear requirements. However, thinks RSVP TE draft makes more sense for intra-provider. Luca: Auto-discovery doesn't come with RSVP-TE. Can use BGP with this draft. Kireeti Kompella: We need requirements for stitching and for QoS for PWs before we go down the path of solutions. These are new aspects. Also, if you take LDP and add all these things, we get CR-LDP. Luca: unclear whether you need to actually signal the QoS. Most implementations don't use single sided signalling. Danny: take it to the mailing list. Need a requirements draft. PWE3 QOS Signaling: Himanshu Shah hshah@ciena.com -------------------------------------------------- http://www.ietf.org/internet-drafts/draft-shah-pwe3-qos-signaling-00.txt Presents a list of requirements: QoS is an inherent attribute of the service Typically service delivery with a specific QoS is realised by configuring appropriate parameters. The sender of the PW FEC provides guidance for the receiving PE Should be backwards compatible with the existing LDP protocol. Explains the proposed solution. Can use the same mechanism for congestion notifications Comments: - Policing upstream would not make sense - This is not a QoS TLV, a traffic parameter TLV - Should not use for congestion indication - PW affects the traffic stream, to signalled parameters do not indicate this Dry-Martini: Ping Pan ppan@hammerheadsystems.com ------------------------------------------------ http://www.ietf.org/internet-drafts/draft-pan-pwe3-over-sub-ip-00.txt This gives a PW perspective to IP centric technology for Sub IP traffic An aggregation mechanism. Shows how dry this could be: Shows how you can aggregate through any Eric Rosen: clearly out of scope. This is PWs over no PSN. Ping Pan: No, PWs over any layer 2 network ?: ITU SG13 is working on this very problem: Ethernet over SDH etc Ali Sajassi: Are you doing the whole thing to save one label at the edge of the network? Don't need IP/MPLS in network. Luca Martini: Don't understand what you are trying to do. Do you want a statement as to what the PSN is? GMPLS? ATM? Ping Pan: Can allow any PSN Yakov Stein: Can't use TDM on it's own. You need something to get a packet across it. ?: For MPLS over SONET, can just use PPP Dave Allen: This is a valid scenario. PHP will replicate this behaviour. Control plane draft acknowledges this. CESoPSN and WG LC: Sasha Vainshtein sasha@axerra.com ---------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-01.txt Reviews the main issues raised in last call, Reference PE architecture is clarified, simple vs. enhanced NSP Draft is now in last call after fixing issues raised Yakov Stein: Last 2 issues are questions of trail terminated vs. trail extended Sasha: want to do trail terminated Yakov: please add wording for which model you want TDM Extensions to PWE3: Sasha Vainstein --------------------------------------- http://www.ietf.org/internet-drafts/draft-vainshtein-pwe3-tdm-control- protocol-extensi-01.txt Lists motivation for control protocol extensions. Setup of TDM PWs needs additional parameters, but these were not included in any of the encapsulation drafts. TDM PW over UDP and TDMoIP Updates: Yaakov Stein yaakov_s@rad.com --------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-02.txt Issues: UDP/IP based PWs in PWE3 architecture UDP/IP extensively deployed in TDM PWs ITU-T SG13 has questions about this too Where do we put PW label? - destination UDP port should be a registered value - source UDP port number = PW label The constraint about using the destination port number is to get through NATs and firewalls. Can get through with relatively few changes How do we distribute the label? use a well known port number at the begining to exchange port numbers Asks for immediate decisions on where to put PW labels, and what label distribution methods Sasha Vainstein: alternative 2 looks like what L2TPv3 lets you do over UDP. Source IP address identify uniqueness Yakov: That gives you the tunnel Sasha V: not so Stewart Bryant: what are security implications of implicit method? Eric Rosen: We already have 3 ways of doing this over IP networks. Don't see why we need another way. Stewart Bryant: please consider this request from ITU-T as they have asked for an answer Other TDM updates: Explains trail terminated vs. trail extended OAM models Explains performance OAM IP Pseudowire Encapsulation: Florin Balus -------------------------------------------------------------------- http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt Defines motivation and requirements for IP PW. PWs used for transport between unlike ACs, but traffic is known to be IP. Ensure consistent PW OAM. Maintain same datapath for OAM and data frames using IP PW Explains control word: IP header already has length and fragmentation fields, so don't need this and set to reserved. Pass the layer 2 discard priority bit using the D flag, signal FR congestion using B flag Any Malis: ARP mediation draft already covers this Florin: No it doesn't Luca Martini: RFC1332 is encapsulation for this Florin: control word moves this into the PW domain Luca: IP already has TCP, and QoS parameters. Florin: SP cannot touch IP header on PWs Ali Sajassi: jist is to take care of ECMP. This is one instantiation of control word draft. Can incorporate this in control word draft Florin: need to discuss on the list where this should go PWE3 Control Protocol Extensions: Mr. Cagatay Buyukkoc du.ke@zte.com.cn ------------------------------------------------------------------------ - http://www.ietf.org/internet-drafts/draft-yudong-pwe3-control-protocol- ext-00.txt The presenter claims there is an issue of scaling when there are large numbers of tunnels. Introduces a reflector to reduce the number of T-LDP sessions from N^2 to N Extensions to LDP: simple relay mode where reflector participates in sinalling messages, but not in routing Second mode (next hop self mode) reflector participates in routing as well Explains the stitching points of the PW and an auto negotiation of the capability to support the reflector. Tom Nadeau: Is this basically another PW switching mechanism? Earlier consensus went a couple of ways, We need to write requirements. This could be one of several ways to do PW stitching. Cagatay Buyukkoc: can also be used for inter AS Stewart Bryant: please continue this on the list MEETING CLOSES From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: meeting minutes Date: Wed, 4 Aug 2004 03:23:46 +0200 Lines: 149 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-bounces@ietf.org Wed Aug 04 02:36:55 2004 Return-path: To: "'Danny McPherson '" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Danny and all, Please see a correction in my answer to Yaakov (inline below). The non-relevant text has been snipped for clarity. Regards, Sasha -----Original Message----- From: Danny McPherson To: pwe3@ietf.org Sent: 8/4/2004 1:28 AM Subject: [PWE3] meeting minutes Folks, Inline below are the IETF60 PWE3 WG meeting minutes. Thanks yet again to Matthew for serving as scribe. Please send me comments and corrections by 8/20/2004. Thanks! -danny & stewart [snip] Pseudo Wire Emulation Edge to Edge (pwe3) ========================================= ... snipped ... CESoPSN and WG LC: Sasha Vainshtein sasha@axerra.com ---------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-01.txt Reviews the main issues raised in last call, Reference PE architecture is clarified, simple vs. enhanced NSP Draft is now in last call after fixing issues raised Yakov Stein: Last 2 issues are questions of trail terminated vs. trail extended Sasha: want to do trail terminated [Sasha] What I really said was "trail extended as the basic mode and optionally trail terminated based on using a DXC as an extended NSP". Yakov: please add wording for which model you want TDM Extensions to PWE3: Sasha Vainstein --------------------------------------- http://www.ietf.org/internet-drafts/draft-vainshtein-pwe3-tdm-control- protocol-extensi-01.txt Lists motivation for control protocol extensions. Setup of TDM PWs needs additional parameters, but these were not included in any of the encapsulation drafts. TDM PW over UDP and TDMoIP Updates: Yaakov Stein yaakov_s@rad.com --------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-02.txt Issues: UDP/IP based PWs in PWE3 architecture UDP/IP extensively deployed in TDM PWs ITU-T SG13 has questions about this too Where do we put PW label? - destination UDP port should be a registered value - source UDP port number = PW label The constraint about using the destination port number is to get through NATs and firewalls. Can get through with relatively few changes How do we distribute the label? use a well known port number at the begining to exchange port numbers Asks for immediate decisions on where to put PW labels, and what label distribution methods Sasha Vainstein: alternative 2 looks like what L2TPv3 lets you do over UDP. Source IP address identify uniqueness Yakov: That gives you the tunnel Sasha V: not so Stewart Bryant: what are security implications of implicit method? Eric Rosen: We already have 3 ways of doing this over IP networks. Don't see why we need another way. Stewart Bryant: please consider this request from ITU-T as they have asked for an answer Other TDM updates: Explains trail terminated vs. trail extended OAM models Explains performance OAM IP Pseudowire Encapsulation: Florin Balus -------------------------------------------------------------------- http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt Defines motivation and requirements for IP PW. PWs used for transport between unlike ACs, but traffic is known to be IP. Ensure consistent PW OAM. Maintain same datapath for OAM and data frames using IP PW Explains control word: IP header already has length and fragmentation fields, so don't need this and set to reserved. Pass the layer 2 discard priority bit using the D flag, signal FR congestion using B flag Any Malis: ARP mediation draft already covers this Florin: No it doesn't Luca Martini: RFC1332 is encapsulation for this Florin: control word moves this into the PW domain Luca: IP already has TCP, and QoS parameters. Florin: SP cannot touch IP header on PWs Ali Sajassi: jist is to take care of ECMP. This is one instantiation of control word draft. Can incorporate this in control word draft Florin: need to discuss on the list where this should go PWE3 Control Protocol Extensions: Mr. Cagatay Buyukkoc du.ke@zte.com.cn ------------------------------------------------------------------------ - http://www.ietf.org/internet-drafts/draft-yudong-pwe3-control-protocol- ext-00.txt The presenter claims there is an issue of scaling when there are large numbers of tunnels. Introduces a reflector to reduce the number of T-LDP sessions from N^2 to N Extensions to LDP: simple relay mode where reflector participates in sinalling messages, but not in routing Second mode (next hop self mode) reflector participates in routing as well Explains the stitching points of the PW and an auto negotiation of the capability to support the reflector. Tom Nadeau: Is this basically another PW switching mechanism? Earlier consensus went a couple of ways, We need to write requirements. This could be one of several ways to do PW stitching. Cagatay Buyukkoc: can also be used for inter AS Stewart Bryant: please continue this on the list MEETING CLOSES _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: IANA PWE3 Document. Date: Tue, 03 Aug 2004 19:17:38 -0600 Lines: 10 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Wed Aug 04 02:40:55 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: Italian [it], French/Canada [fr-CA], French/France [fr-FR], English/United States [en-US] To: pwe3 X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org WG, I would like to suggest that we do a last call on the IANA document , and then publish it ahead of all other documents so that that IANA registry can be setup ASAP. Can the chairs issue a last call ? Thanks. Luca From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: dimitri papadimitriou Subject: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 04 Aug 2004 08:27:30 +0200 Lines: 130 Sender: pwe3-bounces@ietf.org References: <87AC5F88F03E6249AEA68D40BD3E00BE8C7D33@zcarhxm2.corp.nortel.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, busschbach@lucent.com, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Wed Aug 04 08:36:32 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en To: David Allan In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE8C7D33@zcarhxm2.corp.nortel.com> X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org David Allan wrote: > I think FA-LSPs is the wrong concept to be using in this discussion, the > creation of FA-LSPs that would superficially appear to be superior routes to > direct PE-PE PSN LSPs in order to force desired behavior, and share a common > routing instance between the PW and PSN layers, would have rather bizarre > ramifications. > > One implication is that routing may change over time, and therefore each PW > requires a switch table entry in every PW-Switch as it may be a viable > alternate path to either going directly to the PE or transiting a different > PW switch. you speak about an issue which is independent to the use of FA LSPs it just depend on the TE metric setup for the links subsequently used during the MH-PW establishment (note that LSP-HIER proposes a default setup for the FA link metric but this may be overridden) - would you also be more accurate when you mention "routing may change over time" in the present context > IMO if you are tandeming PWs in the middle of the network, you have a pinned > mid-point and it needs to be forced to be pinned in order to achieve useful > behavior....this is different semantics than that of an FA-LSP. You will > have distinct topologies for the PW and the PSN layers. i don't clearly see where the problem lies here if you have a tunnel LSP between to nodes (say N_2 and N_3) and the tunnel LSP bandwidth is large enough to carry another PWs between N_1 and N_3 why a MH-HOP PW [N_1 - N_2 - N_3] couldn't be established if all QoS conditions would be met over this path ? note that i didn't mention the word FA-LSP in the above, and even if the tunnel between PE_2 and PE_3 would have been advertized as such (i.e. FA link) its semantic would not have been different from the current definition as an adjacency within the data plane is created between PE_2 and PE_3 through this LSP (see section 3.5 for the details) so the usage of provisioned FA LSPs is meant to address cases when a known set of PWs is to be setup within a given period of time > cheers > Dave > > > > > >>-----Original Message----- >>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >>Behalf Of richard.spencer@bt.com >>Sent: Monday, August 02, 2004 7:51 PM >>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be >>Cc: l2vpn@ietf.org; busschbach@lucent.com; pwe3@ietf.org; >>mustapha.aissaoui@alcatel.com >>Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching >> >> >>Dimitri, >> >> >>>there are several point to clarify from the above, in >> >>particular re - >> >>>stating the question that was "how non FA-LSPs could be used >>>as tunnel LSPs." the question boils down to "how a set of >> >>FA-LSPs and a set of >> >>>tunnel LSPs (i.e. non FA-LSPs), the former being advertized >>>as FA links but not the latter how does the global mechanism work ?" >> >>I believe this is your (mis)interpretation of the question >>and is not the question Mustapha raised. >> >> >>>on the other side the question turns out to be having established a >>>FA-LSP >>>how do i make the existence of the correspond link information to >>>nodes that do not under stand "FA links" >> >>Again, I believe this is a question that you have raised. PEs >>and PW switching nodes are the only nodes that need to set up >>FA-LSPs (to be able to support MH-PWs), if they don't support >>FA-LSPs then the solution Peter describes won't work making >>this a non-issue. If you disagree, please can you explain how >>MH-PWs can be established using PEs/PW switching nodes that >>don't support FA-LSPs? >> >> >>>- you're making another distinction which is for the non-FA LSPs are >>>they "TE LSPs" or "LSPs" and the response is that it only dependent >>>on the PE capability to advertize the corr. link that can >> >>further be >> >>>used by other nodes to tunnel PWs coming to your last statement, it >>>boils down to what you do today, more precisely, the fact >> >>that FA-LSPs are provisioned >> >>>or triggered doesn't impact the non-FA LSPs are used for >> >>tunneling PWs >> >>Sorry Dimitri but I don't understand the relevance of your >>response or the point you are trying to make. I wrote "This >>still requires FA-LSPs to be provisioned and therefore does >>not address the issue of using non-FA LSPs for tunnelling >>PWs." No one is suggesting that using FA-LSPs impacts non-FA >>LSPs used for tunnelling PWs, the question again is - If >>non-FA LSPs are used for tunneling PWs, how can the PE and PW >>switching node (or PW layer) topology be discovered and paths >>calculated/selected. >> >>Regards, >>Richard >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> > > > > . > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: UDP questions Date: Wed, 4 Aug 2004 09:14:09 +0100 Lines: 87 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 04 10:15:39 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] UDP questions Thread-Index: AcR5Z1iAqPxaRZieRTKtidel7UyeFwADaxigACDNlbA= To: , X-OriginalArrivalTime: 04 Aug 2004 08:14:10.0181 (UTC) FILETIME=[050E9350:01C479FB] X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yaakov, With all due respect I don't find your arguments compelling....in 1-5 below only 3 offers an 'argument', the rest are simply statements of 'this is what we are doing' (whether right or wrong). Let me briefly re-state my take on this topic: - UDP (and TCP) are application adaptation functions, ie they adapt applications to the layer network they will run on, here IP. - This is quite different to 'inter-layer client/server adaptation' between 2 layer networks.....and the nature of the adaptation required varies as a function of the mode/technology of both the client and the server. 1 size does not fit all here. - Voice (or video) say is an application. It is not a PDH E1 layer network entity. It is not an SDH VC4 layer network enity. Voice is not 'TDM' either....in fact its pretty bursty. Sure it has timing requirements that must be satisfied, but these are not the same as those for a proper TDM layer network. TDM layer networks also require fault management and performance management that is not the same (obviously!) to a voice application. I therefore conclude that the AVT argument is not appropriate either. So I don't regard UDP as an appropriate inter-layer adaptation function for the carriage of co-cs mode layer networks (or indeed any mode layer networks). And I assume you would not be advocating this as a 'solution' anyway for large operators or the Internet.....I guess this is targeted at enterprises right? Regards, Neil > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Yaakov Stein > Sent: 03 August 2004 17:19 > To: Yakov Rekhter > Cc: pwe3@ietf.org > Subject: RE: [PWE3] UDP questions=20 >=20 >=20 > Yakov,=20 >=20 > We have already had this discussion, > with Eric asking this question. >=20 > The main reasons for allowing this are: >=20 > 1) it is already widely employed for TDM PWs > 2) it is arguably the first PW technique > 3) it aligns with avt work > 4) it is in the charter > 5) it is in the arcitecture document. >=20 > So if we find strong reasons AGAINST its use, > then I can understand our considering prohibiting it. > But wouldn't any such reason would impact avt work as well? >=20 > Y(J)S >=20 > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Tuesday, August 03, 2004 17:38 > > To: Yaakov Stein > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] UDP questions=20 > >=20 > > Yaakov, > >=20 > > > Following my presentation today, > > > I would like to solicit responses to the 2 questions I raised. > > >=20 > > > 1) Should the PW label be placed in > > > A) destination UDP port field (has NAT/firewall issues) > > > B) source UDP port ? > >=20 > > Should the PW label be placed in the UDP header in the first place ? > >=20 > > Yakov. > >=20 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: peter.3.morgan@bt.com Subject: RE: Draft PWE3 Charter Date: Wed, 4 Aug 2004 09:57:31 +0100 Lines: 76 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 04 11:02:42 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Draft PWE3 Charter Thread-Index: AcR42oYbjRDj4alHRym9mFFDAsDAngAUxY/gABIBplAAIudRAA== To: , X-OriginalArrivalTime: 04 Aug 2004 08:57:32.0486 (UTC) FILETIME=[1426CE60:01C47A01] X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org >Please take into account that the IETF, unlike the ITU, >first solves the data transfer problem, and only afterwards looks into other issues (e.g. OAM). Pity. Peter.=20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein Sent: 03 August 2004 17:37 To: Harrison,N,Neil,IKR2 R Cc: pwe3@ietf.org Subject: RE: [PWE3] Draft PWE3 Charter > PWE3 work is clearly nothing to do with the Internet any > longer (as if it ever was) The PWE work is begin done in the IETF due to its being related to MPLS and L2TP, both of which are being=20 developed here. No-one is implying that PWs MUST be sent over the public Internet, rather than well-engineered IP networks,=20 although nothing prohibits this either. > but what is being created now is > hardly what operators need either in our view=20 Well, perhaps there are other types of operators. Also, as I have argued before, perhaps a lot of this work should be directed towards the enterprise space instead. So I would assume that you would have no problem with our specifically adding enterprise applications to our charter? > as we see it, both the large operator > requirements and the public Internet requirements are being=20 > compromised by what looks like a bunch of enterprise grade=20 > stuff). =20 See my question above. Please take into account that the IETF, unlike the ITU, first solves the data transfer problem, and only afterwards looks into other issues (e.g. OAM). > Wrt PW sw/titching, and no matter how this is > dressed-up, as Richard pointed out a few days ago this is=20 > creating a new layer network......that is simply a fact=20 > whether it is understood or not by some folks.=20 I have been saying for a long time that we should stop pretending that PWs are NOT a full blown layer network. > The root problem is MPLS !=3D IP. How anyone can continue to > maintain a pretence that this is not true is beyond us.=20 No-one is. We are just saying that it is useful to design a layer network (PWE) which can be run over many different PSNs. Obviously, the various aspects will function somewhat differently, e.g. QoS will be different over RSVP-TE MPLS and best-effort IP. But then again RSVP-TE MPLS and LDP MPLS are just as different in this regard. Y(J)S _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: PW/Multi-layer LSP switching Date: Wed, 4 Aug 2004 10:41:49 +0100 Lines: 221 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 04 11:45:48 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR5fOMVCbPwUuPCT1S6aAXyfvSn7gAdDeDA To: , X-OriginalArrivalTime: 04 Aug 2004 09:41:49.0955 (UTC) FILETIME=[44206530:01C47A07] X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, Thanks for the clarification regarding your thoughts on LSP = switching/routing/policies, and I agree with your assertion that this is = not a PW specific problem. The problem applies to any MPLS LSP = (regardless of its label stack depth) for which label switching (or = swapping) is performed. Whenever label switching is performed there must = be at least one LSR between the source and destination LER, and = therefore a route at the given label stack depth must be calculated from = source LER to destination LER.=20 Another way of describing the problem would be to say that routing is = required for a client layer LSP if an end-to-end server layer LSP does = not exist between the source and destination LERs at the client layer. = If multiple server layer LSPs (or server layer partitions) are required = to establish connectivity between source and destination LERs at the = client layer, then forwarding (or selection as to which outbound server = layer LSP to use) at nodes where server layer LSPs are = terminated/sourced must be based on the client layer label. The = difference being that if an end-to-end server layer LSP exists between = the source and destination LERs at the client layer then this is = effectively a one hop point-to-point link and therefore no routing is = required. On the other hand, if multiple server layer LSPs are required = to provide connectivity between the source and destination LERs at the = client layer then these are effectively separate point-to-point links = between multiple hops, and therefore a route between the source and = destination LERs across alternative multiple hops must be = calculated/selected. Obviously this problem is not MPLS specific, it is a problem common to = all cases where an end-to-end server layer partition (which is seen as a = point-to-point link by the client layer) does not exist between the = source and destination at the client layer. For instance, if a leased = line exists between a source router and a destination router then there = is no need for routing at the client (IP) layer as the server layer = (leased line in this case but could equally be a LSP) provides a = point-to-point link between ingress and egress. If on the other hand to = provide connectivity between the source and destination routers at the = client layer requires multiple leased lines between intermediate = routers, then routing is required at the client (IP) layer to = discover/calculate/select a route across the alternative intermediate = routers between source and destination. Regards, Richard > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: 03 August 2004 18:11 > To: Spencer,R,Richard,XGH5 R; mustapha.aissaoui@alcatel.com > Cc: du.ke@zte.com.cn; l2vpn@ietf.org; pwe3@ietf.org > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > Sent: Tuesday, August 03, 2004 11:53 AM > > To: busschbach@lucent.com; mustapha.aissaoui@alcatel.com > > Cc: du.ke@zte.com.cn; l2vpn@ietf.org; pwe3@ietf.org > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > >=20 > >=20 > > Peter, > >=20 > > > Hi Richard, > > >=20 > > > You are right. In the case of LDP signaling for tunnel LSPs, a PW > > > switching node would need additional policies to determine when to > > tunnel > > > traffic and where to tunnel it to. > > >=20 > > > In the worst case, we could revert to the solution that=20 > other drafts > > > propose: the Service Provider explicitly identifies which=20 > > nodes are PW > > > switching nodes. However, I could imagine that there are=20 > > more general > > > policies that require less manual engineering and=20 > provisioning. E.g > > rules > > > like: (a) if the destination PE is in the same OSPF area=20 > > use a tunnel > > that > > > terminates directly on that PE. If the PE is in a different=20 > > OSPF area, > > use > > > a tunnel that terminates on an Area Border Router. > >=20 > > PW switching only needs to be performed when a provider=20 > doesn't have a > > full mesh of tunnel LSPs, which is why I do not agree with your > > suggestion in an earlier post that any LSR may need to support PW > > switching. >=20 > Richard, >=20 > I never said that every LSR needs to function as PW switching=20 > node. I said every LSR *can* support PW switching. >=20 > The issue is the following. If you read=20 > draft-martini-pwe3-pw-switching-00.txt, you get the=20 > impression that a PW Switching node is a special network=20 > element. It needs to support PW control protocols, be aware=20 > of PW-specific identifiers, support various data plnae=20 > interworking functions, etc. >=20 > The point I was trying to make is that in many cases, a PW=20 > Switching node is nothing more than an LSR that switches PW labels. >=20 > As you correctly pointed out: that is not the end of the=20 > story. If a Service Provider does not want to pre-provision=20 > FA-LSPs, an LSR that has been selected as a PW Switching node=20 > needs additional functionality. I called that additional=20 > functionality "policies regarding when to tunnel LSPs". You=20 > call it "PW routing". I think these are two aspects of the=20 > same problem, but I am happy to use your terminology. The=20 > important issue, though, is that this could be treated as a=20 > general problem related to label stacking and not just as a=20 > PW specific problem. >=20 > So in my view there are two options: >=20 > 1) Consider PW switching nodes as special network elements=20 > that are tailor-made for PW switching >=20 > 2) Add a function to the MPLS control plane (like fast=20 > reroute or graceful restart) to deal with label stacking and=20 > its impact on routing and LSP setup. >=20 >=20 > In yesterday's WG meeting we decided that we need to=20 > establish the requirements for PW switching first, before we=20 > discuss solutions. Based on the requirements it is well=20 > possible that we end up doing 1). However, in the long rung,=20 > 2) might be more useful as it could apply to other problems=20 > than PWE as well. >=20 > Peter > =20 >=20 >=20 > IMO only specific LSRs will need to support PW=20 > > switching and > > therefore a provider will always know which nodes need to be PW > > switching capable. In the hierarchical LDP case the nodes=20 > that need to > > be PW switching capable are the hub (PErs) nodes, in the=20 > > intra-provider > > case the nodes that need to be PW switching capable are the border > > routers (on which the tunnel LSPs terminate). As a provider=20 > will know > > before deploying a node whether or not it will need to support PW > > switching, I do not think manually provisioning (or using OSS) to > > configure nodes to support PW switching when they are=20 > deployed will be > > an issue. > >=20 > > > In my first email to you, I wrote: "The question is therefore not: > > what > > > routing protocols do we need to find multi-hop capable=20 > > routers?; but: > > what > > > are the policies that drive an LSR to bundle multiple=20 > PW-LSPs into a > > > single transport LSP?" > > >=20 > > > I don't think the second problem is trivial, but I think it=20 > > is better > > to > > > try to solve the second problem than the first. (Unless we=20 > > decide that > > PW > > > switching is only relevant when crossing AS boundaries, in=20 > > which case > > BGP > > > probably offers a good solution for the first problem.) > >=20 > > I'm not asking which routing protocols need to be used at=20 > this stage, > > I'm just saying that from a functional perspective routing=20 > needs to be > > performed. I still don't think the issue has anything to do with > > policies, IMO the problem is routing at the PW layer. The FA-LSP > > solution works because FA-LSPs are advertised as next hops=20 > to reach PE > > IP loopback addresses, which creates a server layer topology=20 > > that can be > > used by the PW layer. As far as the PW layer is concerned,=20 > the FA-LSPs > > are point-to-point links, the P routers between FA-LSP=20 > > source/sink pairs > > are transparent to the PW layer. However, this only works if routing > > metrics are used correctly to ensure that FA-LSP next hops=20 > are always > > chosen over IGP adjacency based next hops. As David Allan=20 > points out, > > manipulating routing metrics to ensure FA-LSP next hops are always > > chosen over IGP adjacency next hops may lead to problems. > >=20 > > If however LDP tunnel LSPs are to be used for carrying MH-PWs=20 > > then they > > can not be advertised by the IGP as links and therefore PW layer > > routing/next hop information must somehow be distributed in order to > > determine the MH-PW topology. Also, if the PW layer and=20 > > tunnel LSP layer > > share the same addressing, then a mechanism must be used to=20 > > distinguish > > between PW switching capable nodes and non PW switching=20 > capable nodes. > > In the FA-LSP solution, this is achieved via manipulating routing > > metrics to ensure that PW-LSP next hops are chosen over IGP=20 > adjacency > > next hops, i.e. discovery is implicit rather than explicit, the best > > next hop *should* support PW switching. > >=20 > > Regards, > > Richard > >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Wed, 4 Aug 2004 10:47:59 +0100 Lines: 191 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, busschbach@lucent.com, pwe3@ietf.org, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Wed Aug 04 11:57:10 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR57C5KtWKx2jJXSKSKQX8nSpE36AABH0JA To: , , X-OriginalArrivalTime: 04 Aug 2004 09:48:00.0105 (UTC) FILETIME=[20C0CD90:01C47A08] X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Dimitri, If I understand correctly, David is talking here about the specific use = of FA-LSPs in setting up MH-PWs rather than the generic use of TE = tunnels (FA or otherwise) for carrying PWs. A PW switching solution based on FA-LSPs is dependant on the FA-LSP next = hop with the best path to the destination PE being chosen, in which case = problems will arise if for whatever reason an alternative next hop is = selected.=20 For example, if a FA-LSP was to fail and there were no other FA-LSPs to = reach the destination PE, the default behaviour would be for the next = best next hop to be selected. In the case of core FA-LSP failure, the = best next hop is likely to be an IGP adjacency next hop (a P router) = which does not support PW switching. IMO it is not clear what happens = under these kind of circumstances and further study is required to = determine what the implications are of using routing metrics to = implicitly select next hop PW switching nodes. Regards, Richard > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Sent: 04 August 2004 07:28 > To: David Allan > Cc: Spencer,R,Richard,XGH5 R; dimitri.papadimitriou@alcatel.be; > l2vpn@ietf.org; busschbach@lucent.com; pwe3@ietf.org; > mustapha.aissaoui@alcatel.com > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching >=20 >=20 >=20 >=20 > David Allan wrote: >=20 > > I think FA-LSPs is the wrong concept to be using in this=20 > discussion, the > > creation of FA-LSPs that would superficially appear to be=20 > superior routes to > > direct PE-PE PSN LSPs in order to force desired behavior,=20 > and share a common > > routing instance between the PW and PSN layers, would have=20 > rather bizarre > > ramifications. > >=20 > > One implication is that routing may change over time, and=20 > therefore each PW > > requires a switch table entry in every PW-Switch as it may=20 > be a viable > > alternate path to either going directly to the PE or=20 > transiting a different > > PW switch. >=20 > you speak about an issue which is independent to the use of=20 > FA LSPs it=20 > just depend on the TE metric setup for the links subsequently used=20 > during the MH-PW establishment (note that LSP-HIER proposes a default=20 > setup for the FA link metric but this may be overridden) - would you=20 > also be more accurate when you mention "routing may change=20 > over time" in=20 > the present context >=20 > > IMO if you are tandeming PWs in the middle of the network,=20 > you have a pinned > > mid-point and it needs to be forced to be pinned in order=20 > to achieve useful > > behavior....this is different semantics than that of an=20 > FA-LSP. You will > > have distinct topologies for the PW and the PSN layers. >=20 > i don't clearly see where the problem lies here if you have a=20 > tunnel LSP > between to nodes (say N_2 and N_3) and the tunnel LSP=20 > bandwidth is large > enough to carry another PWs between N_1 and N_3 why a MH-HOP=20 > PW [N_1 -=20 > N_2 - N_3] couldn't be established if all QoS conditions would be met=20 > over this path ? >=20 > note that i didn't mention the word FA-LSP in the above, and=20 > even if the=20 > tunnel between PE_2 and PE_3 would have been advertized as=20 > such (i.e. FA=20 > link) its semantic would not have been different from the current=20 > definition as an adjacency within the data plane is created=20 > between PE_2=20 > and PE_3 through this LSP (see section 3.5 for the details)=20 > so the usage=20 > of provisioned FA LSPs is meant to address cases when a known=20 > set of PWs=20 > is to be setup within a given period of time >=20 > > cheers > > Dave > >=20 > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > >>Behalf Of richard.spencer@bt.com > >>Sent: Monday, August 02, 2004 7:51 PM > >>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > >>Cc: l2vpn@ietf.org; busschbach@lucent.com; pwe3@ietf.org;=20 > >>mustapha.aissaoui@alcatel.com > >>Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > >> > >> > >>Dimitri, > >> > >> > >>>there are several point to clarify from the above, in=20 > >> > >>particular re - > >> > >>>stating the question that was "how non FA-LSPs could be used=20 > >>>as tunnel LSPs." the question boils down to "how a set of=20 > >> > >>FA-LSPs and a set of=20 > >> > >>>tunnel LSPs (i.e. non FA-LSPs), the former being advertized=20 > >>>as FA links but not the latter how does the global=20 > mechanism work ?" > >> > >>I believe this is your (mis)interpretation of the question=20 > >>and is not the question Mustapha raised. > >> > >> > >>>on the other side the question turns out to be having=20 > established a=20 > >>>FA-LSP > >>>how do i make the existence of the correspond link information to=20 > >>>nodes that do not under stand "FA links" > >> > >>Again, I believe this is a question that you have raised. PEs=20 > >>and PW switching nodes are the only nodes that need to set up=20 > >>FA-LSPs (to be able to support MH-PWs), if they don't support=20 > >>FA-LSPs then the solution Peter describes won't work making=20 > >>this a non-issue. If you disagree, please can you explain how=20 > >>MH-PWs can be established using PEs/PW switching nodes that=20 > >>don't support FA-LSPs? > >> > >> > >>>- you're making another distinction which is for the=20 > non-FA LSPs are > >>>they "TE LSPs" or "LSPs" and the response is that it only=20 > dependent=20 > >>>on the PE capability to advertize the corr. link that can=20 > >> > >>further be=20 > >> > >>>used by other nodes to tunnel PWs coming to your last=20 > statement, it=20 > >>>boils down to what you do today, more precisely, the fact=20 > >> > >>that FA-LSPs are provisioned=20 > >> > >>>or triggered doesn't impact the non-FA LSPs are used for=20 > >> > >>tunneling PWs > >> > >>Sorry Dimitri but I don't understand the relevance of your=20 > >>response or the point you are trying to make. I wrote "This=20 > >>still requires FA-LSPs to be provisioned and therefore does=20 > >>not address the issue of using non-FA LSPs for tunnelling=20 > >>PWs." No one is suggesting that using FA-LSPs impacts non-FA=20 > >>LSPs used for tunnelling PWs, the question again is - If=20 > >>non-FA LSPs are used for tunneling PWs, how can the PE and PW=20 > >>switching node (or PW layer) topology be discovered and paths=20 > >>calculated/selected. > >> > >>Regards, > >>Richard > >> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> > >=20 > >=20 > >=20 > > . > >=20 >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: PW/Multi-layer LSP switching Date: Wed, 4 Aug 2004 14:12:13 +0100 Lines: 285 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 04 15:16:04 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PW/Multi-layer LSP switching Thread-Index: AcR5fOMVCbPwUuPCT1S6aAXyfvSn7gAdDeDAAAuaIrA= To: , , X-OriginalArrivalTime: 04 Aug 2004 13:12:13.0877 (UTC) FILETIME=[A8920650:01C47A24] X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thanks Richard....that is a pretty good summary of client/server functional arch relationships as per G.805 wrt to what this means for routing. Couple of further points: - the essence of client layer topology creation is that: A client layer link connection is formed by a server layer trail. This is a recursive bahviour to the duct. This is aka TE in IETF. So this is how an MPLS *server layer network* provides this function for an IP *client layer network*. - if there is not a 1:1 relationship between a client and server then we need muxing. All such cases (ie 1 hop or N hops) need this *per hop*. Muxing is a property of the link connection and is considered to belong to the server layer as it will vary with server layer technology/mode. Muxing is part of the client/server adaptation function. Further, if the server layer is co-cs we will also require rate-adaptation and delineation processes within the adaptation function. - below this there is the server layer access point....this must have an address that belongs to the server layer (it has nothing to do with the access point addressing in the client layer network even if it they both have the same format). =20 - below the server layer access point there is the server layer trail termination point....this is a very important point since this is where the integrity of the server layer network is ensured. So it is here that we have OAM insertion/extraction, defects detected/handled and performance/availability SLAs measured. And as Richard points out, if the client entity is always just 1 hop thenthere can be no path construction in the client layer network itself....so a routing capability here is a non-issue. However, if the client layer entity can be multi-hop then this all changes and we now need some form of routing capability in the client. Also note that in the *general* client/server case, the client and server layer networks can be owned by different parties. So full functional independence, which includes client layer transparency (ie no compression), must always be the base default behaviour here. Regards, Neil > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of richard.spencer@bt.com > Sent: 04 August 2004 10:42 > To: busschbach@lucent.com; mustapha.aissaoui@alcatel.com > Cc: l2vpn@ietf.org; pwe3@ietf.org > Subject: [PWE3] PW/Multi-layer LSP switching >=20 >=20 > Peter, >=20 > Thanks for the clarification regarding your thoughts on LSP=20 > switching/routing/policies, and I agree with your assertion=20 > that this is not a PW specific problem. The problem applies=20 > to any MPLS LSP (regardless of its label stack depth) for=20 > which label switching (or swapping) is performed. Whenever=20 > label switching is performed there must be at least one LSR=20 > between the source and destination LER, and therefore a route=20 > at the given label stack depth must be calculated from source=20 > LER to destination LER.=20 >=20 > Another way of describing the problem would be to say that=20 > routing is required for a client layer LSP if an end-to-end=20 > server layer LSP does not exist between the source and=20 > destination LERs at the client layer. If multiple server=20 > layer LSPs (or server layer partitions) are required to=20 > establish connectivity between source and destination LERs at=20 > the client layer, then forwarding (or selection as to which=20 > outbound server layer LSP to use) at nodes where server layer=20 > LSPs are terminated/sourced must be based on the client layer=20 > label. The difference being that if an end-to-end server=20 > layer LSP exists between the source and destination LERs at=20 > the client layer then this is effectively a one hop=20 > point-to-point link and therefore no routing is required. On=20 > the other hand, if multiple server layer LSPs are required to=20 > provide connectivity between the source and destination LERs=20 > at the client layer then these are effectively separate=20 > point-to-point links between multiple hops, and therefore a=20 > route between the source and destination LERs across=20 > alternative multiple hops must be calculated/selected. >=20 > Obviously this problem is not MPLS specific, it is a problem=20 > common to all cases where an end-to-end server layer=20 > partition (which is seen as a point-to-point link by the=20 > client layer) does not exist between the source and=20 > destination at the client layer. For instance, if a leased=20 > line exists between a source router and a destination router=20 > then there is no need for routing at the client (IP) layer as=20 > the server layer (leased line in this case but could equally=20 > be a LSP) provides a point-to-point link between ingress and=20 > egress. If on the other hand to provide connectivity between=20 > the source and destination routers at the client layer=20 > requires multiple leased lines between intermediate routers,=20 > then routing is required at the client (IP) layer to=20 > discover/calculate/select a route across the alternative=20 > intermediate routers between source and destination. >=20 > Regards, > Richard >=20 > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: 03 August 2004 18:11 > > To: Spencer,R,Richard,XGH5 R; mustapha.aissaoui@alcatel.com > > Cc: du.ke@zte.com.cn; l2vpn@ietf.org; pwe3@ietf.org > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > > Sent: Tuesday, August 03, 2004 11:53 AM > > > To: busschbach@lucent.com; mustapha.aissaoui@alcatel.com > > > Cc: du.ke@zte.com.cn; l2vpn@ietf.org; pwe3@ietf.org > > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > >=20 > > >=20 > > > Peter, > > >=20 > > > > Hi Richard, > > > >=20 > > > > You are right. In the case of LDP signaling for tunnel=20 > LSPs, a PW=20 > > > > switching node would need additional policies to=20 > determine when to > > > tunnel > > > > traffic and where to tunnel it to. > > > >=20 > > > > In the worst case, we could revert to the solution that > > other drafts > > > > propose: the Service Provider explicitly identifies which > > > nodes are PW > > > > switching nodes. However, I could imagine that there are > > > more general > > > > policies that require less manual engineering and > > provisioning. E.g > > > rules > > > > like: (a) if the destination PE is in the same OSPF area > > > use a tunnel > > > that > > > > terminates directly on that PE. If the PE is in a different > > > OSPF area, > > > use > > > > a tunnel that terminates on an Area Border Router. > > >=20 > > > PW switching only needs to be performed when a provider > > doesn't have a > > > full mesh of tunnel LSPs, which is why I do not agree with your=20 > > > suggestion in an earlier post that any LSR may need to support PW=20 > > > switching. > >=20 > > Richard, > >=20 > > I never said that every LSR needs to function as PW switching > > node. I said every LSR *can* support PW switching. > >=20 > > The issue is the following. If you read > > draft-martini-pwe3-pw-switching-00.txt, you get the=20 > > impression that a PW Switching node is a special network=20 > > element. It needs to support PW control protocols, be aware=20 > > of PW-specific identifiers, support various data plnae=20 > > interworking functions, etc. > >=20 > > The point I was trying to make is that in many cases, a PW > > Switching node is nothing more than an LSR that switches PW labels. > >=20 > > As you correctly pointed out: that is not the end of the > > story. If a Service Provider does not want to pre-provision=20 > > FA-LSPs, an LSR that has been selected as a PW Switching node=20 > > needs additional functionality. I called that additional=20 > > functionality "policies regarding when to tunnel LSPs". You=20 > > call it "PW routing". I think these are two aspects of the=20 > > same problem, but I am happy to use your terminology. The=20 > > important issue, though, is that this could be treated as a=20 > > general problem related to label stacking and not just as a=20 > > PW specific problem. > >=20 > > So in my view there are two options: > >=20 > > 1) Consider PW switching nodes as special network elements > > that are tailor-made for PW switching > >=20 > > 2) Add a function to the MPLS control plane (like fast > > reroute or graceful restart) to deal with label stacking and=20 > > its impact on routing and LSP setup. > >=20 > >=20 > > In yesterday's WG meeting we decided that we need to > > establish the requirements for PW switching first, before we=20 > > discuss solutions. Based on the requirements it is well=20 > > possible that we end up doing 1). However, in the long rung,=20 > > 2) might be more useful as it could apply to other problems=20 > > than PWE as well. > >=20 > > Peter > > =20 > >=20 > >=20 > > IMO only specific LSRs will need to support PW > > > switching and > > > therefore a provider will always know which nodes need to be PW=20 > > > switching capable. In the hierarchical LDP case the nodes > > that need to > > > be PW switching capable are the hub (PErs) nodes, in the > > > intra-provider > > > case the nodes that need to be PW switching capable are the border > > > routers (on which the tunnel LSPs terminate). As a provider=20 > > will know > > > before deploying a node whether or not it will need to support PW=20 > > > switching, I do not think manually provisioning (or using OSS) to=20 > > > configure nodes to support PW switching when they are > > deployed will be > > > an issue. > > >=20 > > > > In my first email to you, I wrote: "The question is=20 > therefore not: > > > what > > > > routing protocols do we need to find multi-hop capable > > > routers?; but: > > > what > > > > are the policies that drive an LSR to bundle multiple > > PW-LSPs into a > > > > single transport LSP?" > > > >=20 > > > > I don't think the second problem is trivial, but I think it > > > is better > > > to > > > > try to solve the second problem than the first. (Unless we > > > decide that > > > PW > > > > switching is only relevant when crossing AS boundaries, in > > > which case > > > BGP > > > > probably offers a good solution for the first problem.) > > >=20 > > > I'm not asking which routing protocols need to be used at > > this stage, > > > I'm just saying that from a functional perspective routing > > needs to be > > > performed. I still don't think the issue has anything to do with=20 > > > policies, IMO the problem is routing at the PW layer. The FA-LSP=20 > > > solution works because FA-LSPs are advertised as next hops > > to reach PE > > > IP loopback addresses, which creates a server layer topology > > > that can be > > > used by the PW layer. As far as the PW layer is concerned,=20 > > the FA-LSPs > > > are point-to-point links, the P routers between FA-LSP > > > source/sink pairs > > > are transparent to the PW layer. However, this only works=20 > if routing > > > metrics are used correctly to ensure that FA-LSP next hops=20 > > are always > > > chosen over IGP adjacency based next hops. As David Allan > > points out, > > > manipulating routing metrics to ensure FA-LSP next hops=20 > are always=20 > > > chosen over IGP adjacency next hops may lead to problems. > > >=20 > > > If however LDP tunnel LSPs are to be used for carrying MH-PWs > > > then they > > > can not be advertised by the IGP as links and therefore PW layer > > > routing/next hop information must somehow be distributed=20 > in order to > > > determine the MH-PW topology. Also, if the PW layer and=20 > > > tunnel LSP layer > > > share the same addressing, then a mechanism must be used to=20 > > > distinguish > > > between PW switching capable nodes and non PW switching=20 > > capable nodes. > > > In the FA-LSP solution, this is achieved via manipulating routing=20 > > > metrics to ensure that PW-LSP next hops are chosen over IGP > > adjacency > > > next hops, i.e. discovery is implicit rather than=20 > explicit, the best=20 > > > next hop *should* support PW switching. > > >=20 > > > Regards, > > > Richard > > >=20 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Hamid Ould-Brahim" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Wed, 4 Aug 2004 14:54:31 -0400 Lines: 37 Sender: pwe3-bounces@ietf.org Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 04 21:16:06 2004 Return-path: To: "Busschbach, Peter B (Peter)" , "'richard.spencer@bt.com'" , mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, [clipped...] > > In yesterday's WG meeting we decided that we need to > establish the requirements for PW switching first, before we > discuss solutions. Based on the requirements it is well > possible that we end up doing 1). However, in the long rung, > 2) might be more useful as it could apply to other problems > than PWE as well. > In addition to requirements I think in light of this discussion and proposed solution drafts we need to clarify maybe as new sections to existing framework draft the following: a) The terminology: PW switching/stitching/multihop PW, PW switching points and PW demultiplexor allocation points (suggest stick with one or two terms). b) Deployment scenarios of multihop/switching in terms of - an inter-as/domain - single/inter-providers - a PW-enabled access network to an PW-MPLS core network - A PW "private" segment stitched to another "provider-based" PW (not sure this is needed?). c) switching point determination (dynamic -routing, pre-configured) d) mp-pw path determination (implicit/explicit -ERO). e) switching node being PW aware or not f) end-to-end MP-PW signaling versus no end-to-end signaling (just switching per config). etc... Hamid. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: Scaling hierarchical LDP/PW stitching Date: Wed, 4 Aug 2004 22:20:06 +0200 Lines: 68 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: l2vpn@ietf.org, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Wed Aug 04 21:36:02 2004 Return-path: To: "'Hamid Ould-Brahim'" , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hamid, Peter and all, I tend to agree with Hamid wrt the scope of work to be done. I would also include the OAM tools e.g., localization of fault on a specific hop of a MH-PW - probably useful in the inter-provider scenarios. ---------------------------------------------------------------------------- -------- 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: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] > Sent: Wednesday, August 04, 2004 10:55 AM > To: Busschbach, Peter B (Peter); 'richard.spencer@bt.com'; > mustapha.aissaoui@alcatel.com > Cc: l2vpn@ietf.org; pwe3@ietf.org > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > Peter, > > [clipped...] > > > > > In yesterday's WG meeting we decided that we need to > > establish the requirements for PW switching first, before we > > discuss solutions. Based on the requirements it is well > > possible that we end up doing 1). However, in the long rung, > > 2) might be more useful as it could apply to other problems > > than PWE as well. > > > > In addition to requirements I think in light of this > discussion and proposed solution drafts we need to clarify > maybe as new sections to existing framework draft the > following: > > a) The terminology: PW switching/stitching/multihop PW, > PW switching points and PW demultiplexor > allocation points (suggest stick with one or two terms). > > b) Deployment scenarios of multihop/switching in terms of > - an inter-as/domain > - single/inter-providers > - a PW-enabled access network to an PW-MPLS core network > - A PW "private" segment stitched to another "provider-based" > PW (not sure this is needed?). > > c) switching point determination (dynamic -routing, pre-configured) > d) mp-pw path determination (implicit/explicit -ERO). > e) switching node being PW aware or not > f) end-to-end MP-PW signaling versus no end-to-end signaling > (just switching per config). > etc... > > Hamid. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Wed, 4 Aug 2004 21:09:07 +0100 Lines: 100 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Wed Aug 04 22:20:55 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR6WnfjZMH0OIpTRwuEreiXI0zDYAAA0E5Q To: , , X-OriginalArrivalTime: 04 Aug 2004 20:09:08.0803 (UTC) FILETIME=[E6A0D130:01C47A5E] X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org No disrespect to the manufacturer community, but don't folks think it might be good idea to ask operators what they might want here? But please bear in mind....the requirements for: - the Internet - altnets/ISps - trad operators - enterprises are not the same. So can I ask again *who* is the PWE3 WG intending doing this work for? Regards, Neil > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Sasha Vainshtein > Sent: 04 August 2004 21:20 > To: 'Hamid Ould-Brahim'; Busschbach, Peter B (Peter) > Cc: l2vpn@ietf.org; pwe3@ietf.org;=20 > mustapha.aissaoui@alcatel.com; Spencer,R,Richard,XGH5 R > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching >=20 >=20 > Hamid, Peter and all, > I tend to agree with Hamid wrt the scope of work to be done. I would=20 > also include the OAM tools e.g., localization of fault on a specific=20 > hop of a MH-PW - probably useful in the inter-provider scenarios. > -------------------------------------------------------------- > -------------- > -------- > With best regards, > Sasha Vainshtein > email: sasha@axerra.com =20 > phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) >=20 >=20 > > -----Original Message----- > > From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] > > Sent: Wednesday, August 04, 2004 10:55 AM > > To: Busschbach, Peter B (Peter); 'richard.spencer@bt.com';=20 > > mustapha.aissaoui@alcatel.com > > Cc: l2vpn@ietf.org; pwe3@ietf.org > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > >=20 > >=20 > > Peter, > >=20 > > [clipped...] > >=20 > > >=20 > > > In yesterday's WG meeting we decided that we need to > establish the > > > requirements for PW switching first, before we discuss solutions. > > > Based on the requirements it is well possible that we end=20 > up doing > > > 1). However, in the long rung, > > > 2) might be more useful as it could apply to other problems than=20 > > > PWE as well. > > >=20 > >=20 > > In addition to requirements I think in light of this discussion and > > proposed solution drafts we need to clarify maybe as new=20 > sections to > > existing framework draft the > > following: > >=20 > > a) The terminology: PW switching/stitching/multihop PW, > > PW switching points and PW demultiplexor=20 > > allocation points (suggest stick with one or two terms). > >=20 > > b) Deployment scenarios of multihop/switching in terms of > > - an inter-as/domain=20 > > - single/inter-providers > > - a PW-enabled access network to an PW-MPLS core network > > - A PW "private" segment stitched to another "provider-based"=20 > > PW (not sure this is needed?). > >=20 > > c) switching point determination (dynamic -routing, pre-configured) > > d) mp-pw path determination (implicit/explicit -ERO). > > e) switching node being PW aware or not > > f) end-to-end MP-PW signaling versus no end-to-end signaling=20 > > (just switching per config). > > etc... > >=20 > > Hamid. > >=20 > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: UDP questions Date: Thu, 5 Aug 2004 00:28:17 +0300 Lines: 121 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 04 23:37:45 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] UDP questions Thread-Index: AcR5Z1iAqPxaRZieRTKtidel7UyeFwADaxigACDNlbAAHDwB4A== To: , X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Neil,=20 The use of UDP/IP is one of the two methods for CE to CE PWs (the other being the "naked inner label" method I described in the past). So, yes, this is for the enterprise space. Regarding the "voice" vs TDM argument. If your problem is OAM and timing recovery,=20 I am willing to discuss these issues. I don't see that the OAM issues are that much different than for LDP MPLS PSNs, as these presently stand (and you yourself have discussed this at great length=20 in the past on this very list). The timing recovery problem depends on packet-loss rates and PDV, these are not directly dependent on whether we have UDP/IP or MPLS (unless we have some TE in the MPLS case, or RSVP in the UDP/IP case). Y(J)S=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Wednesday, August 04, 2004 11:14 > To: Yaakov Stein; yakov@juniper.net > Cc: pwe3@ietf.org > Subject: RE: [PWE3] UDP questions=20 >=20 > Yaakov, >=20 > With all due respect I don't find your arguments=20 > compelling....in 1-5 below only 3 offers an 'argument', the=20 > rest are simply statements of 'this is what we are doing'=20 > (whether right or wrong). >=20 > Let me briefly re-state my take on this topic: > - UDP (and TCP) are application adaptation functions, ie they > adapt applications to the layer network they will run on, here IP. > - This is quite different to 'inter-layer client/server > adaptation' between 2 layer networks.....and the nature of=20 > the adaptation required varies as a function of the=20 > mode/technology of both the client and the server. 1 size=20 > does not fit all here. > - Voice (or video) say is an application. It is not a PDH E1 > layer network entity. It is not an SDH VC4 layer network=20 > enity. Voice is not 'TDM' either....in fact its pretty=20 > bursty. Sure it has timing requirements that must be=20 > satisfied, but these are not the same as those for a proper=20 > TDM layer network. TDM layer networks also require fault=20 > management and performance management that is not the same=20 > (obviously!) to a voice application. I therefore conclude=20 > that the AVT argument is not appropriate either. >=20 > So I don't regard UDP as an appropriate inter-layer=20 > adaptation function for the carriage of co-cs mode layer=20 > networks (or indeed any mode layer networks). >=20 > And I assume you would not be advocating this as a 'solution'=20 > anyway for large operators or the Internet.....I guess this=20 > is targeted at enterprises right? >=20 > Regards, Neil >=20 > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]=20 > On Behalf=20 > > Of Yaakov Stein > > Sent: 03 August 2004 17:19 > > To: Yakov Rekhter > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] UDP questions > >=20 > >=20 > > Yakov, > >=20 > > We have already had this discussion, > > with Eric asking this question. > >=20 > > The main reasons for allowing this are: > >=20 > > 1) it is already widely employed for TDM PWs > > 2) it is arguably the first PW technique > > 3) it aligns with avt work > > 4) it is in the charter > > 5) it is in the arcitecture document. > >=20 > > So if we find strong reasons AGAINST its use, then I can understand=20 > > our considering prohibiting it. > > But wouldn't any such reason would impact avt work as well? > >=20 > > Y(J)S > >=20 > > > -----Original Message----- > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > Sent: Tuesday, August 03, 2004 17:38 > > > To: Yaakov Stein > > > Cc: pwe3@ietf.org > > > Subject: Re: [PWE3] UDP questions > > >=20 > > > Yaakov, > > >=20 > > > > Following my presentation today, > > > > I would like to solicit responses to the 2 questions I raised. > > > >=20 > > > > 1) Should the PW label be placed in > > > > A) destination UDP port field (has NAT/firewall issues) > > > > B) source UDP port ? > > >=20 > > > Should the PW label be placed in the UDP header in the=20 > first place ? > > >=20 > > > Yakov. > > >=20 > > >=20 > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: UDP questions Date: Thu, 5 Aug 2004 02:19:23 +0200 Lines: 102 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Yakov Rekhter , pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Aug 05 01:39:28 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yaakov and all, Please see some comments/answers 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: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Tuesday, August 03, 2004 8:42 AM > To: Sasha Vainshtein > Cc: pwe3@ietf.org; Yakov Rekhter > Subject: RE: [PWE3] UDP questions > > > > > > 3) it aligns with avt work > > [Sasha] If this is the reason, then the answer to the rest of > > the questions seems obvious, as this reason only makes sense > > if the UDP ports are used in an AVT-compliant way. > > > > And this is OK with me. > > Sasha, > > This is certainly a complelling argument. > > Unfortunately, as I am sure you know, > VoIP has terrible problems with getting through > firewalls. I can't use VoIP from my office PC. > [Sasha] Actually I only wanted to say that you cannot have it both ways: claim VoIP and other RTP applications as justification for having UDP-based PWs, AND promote a method that is absolutely different from what these applications consistently use. > > Skype and others are having tremendous success > with alternative protocols, precisely because > they can get around this issue. > [Sasha] The following text is quoted verbatim (with only Q: and A: inserted for clarity)from the official Skype FAQ/Technical page (http://www.skype.com/help_faq.html#Technical) Q: I can't connect to Skype from work or due to a restrictive firewall. Which ports need to be opened in order to use Skype? A: If you aren't familiar with firewalls or ports, it may be a good idea to ask a system administrator or tech-savvy friend to help you. The minimum requirement is that Skype needs unrestricted outgoing TCP access to all destination ports above 1024 or to port 80 (the former is better, however). If you don't allow either of those, Skype will not work reliably at all. Voice quality and some other aspects of Skype functionality will be greatly improved if you also open up outgoing UDP traffic to all ports above 1024, and allow UDP replies to come back in. In the quest for even better voice quality, it is also advisable to open up incoming TCP and/or UDP to the specific port you see in Skype Options. This port is chosen randomly when you install Skype. In the case of firewalls, this should be easy to arrange. In some routers, however, you cannot configure incoming UDP at all (but you still can configure incoming TCP port forwarding, which you could/should do). The randomness in port selection is to improve NAT traversal for cases where several users are behind the same NAT; if they all used same ports, many NATs would behave in a way that would reduce Skype voice quality. An additional reference (http://www.skype.com/help_firewalls.html) explicitly states that Ideally, outgoing TCP connections to all ports (1..65535) should be opened. This option results in Skype working most reliably. So it seems to me that your reference to Skype as being free from the firewall/NAT traversal problems is not correct. > > So why repeat this fiasco and have someone > come up with a non-PWE-sanctioned protocol > and capture the market claiming it is better > for this reason? > [Sasha] I am afraid that any FREE product (like Skype) has a very good chance to capture the market regardless of its being sanctioned or not sanctioned by any SDO. This fact cannot, IMO, attest to the quality of the product, its ability to solve any problems etc. > > Y(J)S > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Tony Li Subject: Re: UDP questions Date: Wed, 4 Aug 2004 17:56:07 -0700 Lines: 136 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , 'Yaakov Stein' , pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Aug 05 03:00:05 2004 Return-path: In-Reply-To: To: Sasha Vainshtein X-Mailer: Apple Mail (2.618) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org It may well be easier to get a different protocol that does NOT use ports through a NAT/firewall device. If nothing else, you will be quite certain that the NAT is not messing with your demuxing. Tony p.s. A de-facto standard that solves no problems is an oxymoron. A de-facto standard becomes established precisely because it is solving real world problems, usually because the SDO is not doing so as rapidly as the market would like. Pedal on the right, please. On Aug 4, 2004, at 5:19 PM, Sasha Vainshtein wrote: > Yaakov and all, > Please see some comments/answers 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: Yaakov Stein [mailto:yaakov_s@rad.com] >> Sent: Tuesday, August 03, 2004 8:42 AM >> To: Sasha Vainshtein >> Cc: pwe3@ietf.org; Yakov Rekhter >> Subject: RE: [PWE3] UDP questions >> >> >> >>>> 3) it aligns with avt work >>> [Sasha] If this is the reason, then the answer to the rest of >>> the questions seems obvious, as this reason only makes sense >>> if the UDP ports are used in an AVT-compliant way. >>> >>> And this is OK with me. >> >> Sasha, >> >> This is certainly a complelling argument. >> >> Unfortunately, as I am sure you know, >> VoIP has terrible problems with getting through >> firewalls. I can't use VoIP from my office PC. >> > [Sasha] Actually I only wanted to say that you cannot have it > both ways: claim VoIP and other RTP applications as justification > for having UDP-based PWs, AND promote a method that is > absolutely different from what these applications consistently use. >> >> Skype and others are having tremendous success >> with alternative protocols, precisely because >> they can get around this issue. >> > [Sasha] The following text is quoted verbatim (with only Q: and A: > inserted for clarity)from the official Skype FAQ/Technical page > (http://www.skype.com/help_faq.html#Technical) > > > Q: I can't connect to Skype from work or due to a restrictive firewall. > Which ports need to be opened in order to use Skype? > > A: If you aren't familiar with firewalls or ports, > it may be a good idea to ask a system administrator > or tech-savvy friend to help you. The minimum requirement is that > Skype > needs unrestricted outgoing TCP access to all destination ports > above > 1024 > or to port 80 (the former is better, however). > If you don't allow either of those, Skype will not work reliably at > all. > Voice quality and some other aspects of Skype functionality will be > greatly improved if you also open up outgoing UDP traffic to all > ports above 1024, and allow UDP replies to come back in. > In the quest for even better voice quality, it is also advisable > to open up incoming TCP and/or UDP to the specific port you see in > Skype Options. This port is chosen randomly when you install Skype. > In the case of firewalls, this should be easy to arrange. > In some routers, however, you cannot configure incoming UDP > at all (but you still can configure incoming TCP port forwarding, > which you could/should do). > The randomness in port selection is to improve NAT traversal > for cases where several users are behind the same NAT; > if they all used same ports, many NATs would behave in a way > that would reduce Skype voice quality. > > > An additional reference (http://www.skype.com/help_firewalls.html) > explicitly states that > > > Ideally, outgoing TCP connections to all ports (1..65535) > should be opened. This option results in Skype working most > reliably. > > > So it seems to me that your reference to Skype as being free > from the firewall/NAT traversal problems is not correct. > >> >> So why repeat this fiasco and have someone >> come up with a non-PWE-sanctioned protocol >> and capture the market claiming it is better >> for this reason? >> > [Sasha] I am afraid that any FREE product (like Skype) has > a very good chance to capture the market regardless of > its being sanctioned or not sanctioned by any SDO. > This fact cannot, IMO, attest to the quality of the product, > its ability to solve any problems etc. >> >> Y(J)S >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Mustapha Aissaoui Subject: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 04 Aug 2004 21:41:29 -0400 Organization: Alcatel Networks Corporaton Lines: 112 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, busschbach@lucent.com, dpapadimitriou@psg.com X-From: pwe3-bounces@ietf.org Thu Aug 05 03:44:35 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: richard.spencer@bt.com X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard, see below. Regards, Mustapha. ----------- richard.spencer@bt.com wrote: > > Mustapha, > > > Richard and Dimitri, > > this issue is in my view one of the critical issues. I believe a > > workable solution should have the following characteristics: > > > > 1. State how stitching nodes are discovered. I do not agree with > > Peter that a stiching node is just another LSP switching node. There > > are PW specific operations to be performed in the data, control, and > > management (OAM) planes on a PW segment. > > I agree that a PW stitching node is not just another (tunnel) LSP > switching node. The data plane behaviour (i.e. MPLS label switching) may > be the same but the tunnel LSP control protocols needs to be modified > (or separate control protocols/instances used) in order to support > single sided provisioning of switched PWs. MA> Add to that OAM on the PW segment. > I think discovery can be > split up into two aspects, i) discovery of ingress/egress PEs, and ii) > discovery of PW switching nodes. > Regarding i) this is required to support single sided provisioning. MA> I think single sided signaling is a separate issue. You can still configure the AC and PW information at both PEs but have one side trigger the PW setup (master PE) and the other reply only when it receives it (slave PW). This is the dominant mode of operation of SPVCs in ATM networks today. > Regarding ii), this is only required if routers use the same address > space (i.e. same loopback addresses) at the PW layer that they use at > the MPLS tunnel layer. If a different address space was used then > support for PW switching would be explicit. The consequence of using the > same addresses is that PW switching capable nodes must be distinguish > from non PW switching capable nodes explicitly using a discovery > mechanism or implicitly, e.g. using routing metrics as is the case with > the FA-LSP solution. MA> You are right. However, the reason for using the same address space is a direct consequence of the fact that PWs can only ride inside a tunnel of some sort. > > 2. State how routing of PW control messages are performed once the > > stitching nodes have been discovered. It seems to me that a solution > > that mandates the use of FA-LSPs is too restrictive. > > I agree that mandating FA-LSPs is too restrictive and that a common PW > routing solution should be specified. > > > 3. Avoid if possible making the PW label routable. Not that I have > > anything against that but if a solution turns PWs into routable > > entities on their own, then we should discuss it in that wider > > context. In that case, the use of tunnel LSPs becomes a convenience > > as opposed to a requirement of the architecture. > > I'm not sure I understand your last point; it appears to me to be a > contradiction. In 2 you state that routing of PW control messages must > be addressed but then in 3 state that making PWs routable should be > avoided. I think there are two issues here, a) routing at the PW layer > where LSPs tunnels are used (resulting in a two layer LSP hierarchy), b) > routing where tunnel LSPs are not used (resulting in a single LSP > layer). MA> I mean that we do not want to have a separate addressing and routing for PWs in the current PWE3 architecture. I make the following argument: as long as PWs are confined inside tunnels, it does not make sense to make them routable (network wide) and have their own address space. > Regarding a), in the control plane, routing is required at the PW layer > to calculate/select the PW path from ingress PE to egress PE across > intermediate PW switching points and therefore the PE IP addresses must > be routable. In the (PW) data plane the PW label needs to be used at > each hop to make a forwarding decision. However, even though PWs need to > be routable at the PW level, they are not routable at the tunnel LSP > level, i.e. forwarding at the LSP tunnel level is based on tunnel LSP > labels not PW labels, just like VP switching in ATM is based on VPIs not > VCIs. MA> You describe it very well. My point is that the PW dataplane forwarding decision should be local to a stitching node and not network wide. In other words, we do not want to advertize PW reachability. > Regarding b), if tunnel LSPs are not used then PWs must still be > routable at the PW layer, but as this is the only layer each hop must > belong to the PW layer, i.e. each hop must support PW switching. For > scaling reasons its highly unlikely that a single LSP layer would be > used in the core, but I think using a single LSP layer would make sense > for spoke connections in the hierarchical LDP model. MA> Correct. And this is where I think Peter and I disagree. I do not belive that we want to solve the general problem where any node can be used as a stitching node because this degenerates into the case where you will be forced to have a separate routing and addressing for the PWs. The case of the spoke connections is different. I assume that a static PW may be just fine if the access network is simple. In complex access and aggregation networks, one can have build a separate PSN for this network and perform switching at some well idnetified edge nodes. > Regards, > Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "David Allan" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Wed, 4 Aug 2004 23:32:06 -0400 Lines: 32 Sender: pwe3-bounces@ietf.org Cc: "'l2vpn@ietf.org'" , "'busschbach@lucent.com'" , "'pwe3@ietf.org'" , "'mustapha.aissaoui@alcatel.com'" , "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Thu Aug 05 05:41:48 2004 Return-path: To: "'dimitri.papadimitriou@alcatel.be'" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Dimitri: > > you speak about an issue which is independent to the use of > FA LSPs it > just depend on the TE metric setup for the links subsequently used > during the MH-PW establishment (note that LSP-HIER proposes a default > setup for the FA link metric but this may be overridden) - would you > also be more accurate when you mention "routing may change > over time" in > the present context Not quite sure why it would be independent, fiddling metrics to impose policy such that traffic transits a particular node or set of nodes IMO is not a tractable solution unless you are only carrying tandemed PW traffic....further it does not imply the requisite semantics for transiting a PW switch My interpretation of use of FA-LSPs (in that they are advertised into the PSN routing system) is that they would not adequately reflect the PW layer topology and would distort the PSN..... More specifically, the PE needs a PSN FEC for the PW switch and not a distant PE if the PW layer is to transit and be switched by a PSN switch, which is completely orthogonal to the use of FA-LSPs. Use of FA-LSPs would simply affect the routing of the PSN FEC, not what the PSN FEC was. rgds Dave From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Thu, 5 Aug 2004 10:52:41 +0100 Lines: 55 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, busschbach@lucent.com, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Thu Aug 05 11:55:36 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR6nlYTzFRn+UelQwyYvLO7pvtQ1gAMGR5w To: , X-OriginalArrivalTime: 05 Aug 2004 09:52:41.0588 (UTC) FILETIME=[F2F17340:01C47AD1] X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Dave.... >=20 > Hi Dimitri: >=20 > > >=20 > > you speak about an issue which is independent to the use of=20 > FA LSPs it > > just depend on the TE metric setup for the links subsequently used=20 > > during the MH-PW establishment (note that LSP-HIER proposes=20 > a default=20 > > setup for the FA link metric but this may be overridden) -=20 > would you=20 > > also be more accurate when you mention "routing may change=20 > > over time" in=20 > > the present context >=20 > Not quite sure why it would be independent, fiddling metrics=20 > to impose policy such that traffic transits a particular node=20 > or set of nodes IMO is not a tractable solution unless you=20 > are only carrying tandemed PW traffic....further it does not=20 > imply the requisite semantics for transiting a PW switch >=20 > My interpretation of use of FA-LSPs (in that they are=20 > advertised into the PSN routing system) is that they would=20 > not adequately reflect the PW layer topology and would=20 > distort the PSN..... >=20 > More specifically, the PE needs a PSN FEC for the PW switch=20 > and not a distant PE if the PW layer is to transit and be=20 > switched by a PSN switch, which is completely orthogonal to=20 > the use of FA-LSPs. Use of FA-LSPs would simply affect the=20 > routing of the PSN FEC, not what the PSN FEC was.=20 >=20 NH=3D> The concept and value of FAs is very limited IMO. When one has a set of nested layer networks the general requirement is that the trail holding time and topology stability *must* increase as one approaches the duct. I can't get my head round how this '1 routing instance over all layer networks' behaves under routing protocol anomalies and all failure scenarios. But of even more fundamantal importance is this: When we have a client/server relationships between layer networks which are owned by different parties then the whole concept of FAs is a non-starter anyway.....and even this is not sufficient, one must have full functional independence between the layer networks involved. These are *very* common requirements....they are certainly not the exceptions. A key issue for a large operator is security/stability of the control/management plane. It should be a no-brainer that wherever possible the internal sensitive control/management plane protocols are run OOB wrt to the traffic. This is required in the co-cs mode (and GMPLS now does indeed address this) and it is also required in the co-ps mode. This has very important implications for the arch/solutions, and the PWE3 stuff has simply failed to take this into account so far. Regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: UDP questions Date: Thu, 5 Aug 2004 11:01:00 +0100 Lines: 254 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Aug 05 12:02:35 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] UDP questions Thread-Index: AcR5Z1iAqPxaRZieRTKtidel7UyeFwADaxigACDNlbAAHDwB4AACGLGA To: , X-OriginalArrivalTime: 05 Aug 2004 10:01:00.0069 (UTC) FILETIME=[1C0F9D50:01C47AD3] X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Yaakov, >=20 > Neil, >=20 > The use of UDP/IP is one of the two methods for CE to CE PWs > (the other being the "naked inner label" method I described=20 > in the past). So, yes, this is for the enterprise space. NH=3D> That's my take. Which is fine, but this is not a solution for = the operator community IMO, nor I think the Internet community (but I'll let others ponder on that one). And the operator community should think long and hard on what this might mean for their current services that operate in this space (but its bigger than this, and the efficiency illusion of QoS and that '1 technology/mode can do it all' is also wrapped up in this). We should be careful of what the longer-term implications of bad arch will be on future investment......take care not to kill the industry on religious grounds or too much short-termism. >=20 > Regarding the "voice" vs TDM argument. > If your problem is OAM and timing recovery, > I am willing to discuss these issues. NH=3D> Well only partially....as I have maintained for a long time now, from an operator's viewpoint it makes a great deal of sense to manage the trails of a layer network in a consistent manner irrespective of the client.....one does not want a plethora of solutions here that are client specific. (Your stuff is for sure operating in this space....but I don't blame you for that, you are constrained by the foundations of what you have been given...and it is these foundations that are the real problem) Rather obvious I think, but as soon as the BW squeezing mind-set appears things start going pear-shaped here.....and again as I have maintained, in any clinet/server layer network relationship client layer transparency must be the default, not the special case. > I don't see that the OAM issues are that much different > than for LDP MPLS PSNs, as these presently stand > (and you yourself have discussed this at great length=20 > in the past on this very list). NH=3D> But are the messages taken on board or are they ignored? It sure feels like the latter. Maybe the messages will have more clarity/relevance once the commercial realities bite a bit harder. The key technical issue for this particular facet is that the management of LSPs in MPLS is not the same as the management of a cl-ps layer network like IP, and neither is it the same as the management of a co-cs layer network like SDH. The transport defects in each mode are different for a start (though they are generic per mode), and yes I have tried to explain this as you note....and to summarise: Mode Defects cl-ps Breaks co-cs Breaks Swaps, but only between exactly alike entities co-ps Breaks Swaps between any entities Mismerges, with the following subcases - A1->A2 mismerging into B1->B2, with A1->A2 traffic seemingly unaffected - A1->A2 mismerging into B1->B2, with A1->A2 traffic broken - A1->A2 self-mismerging back into A1->A2 So I'd like to be able to manage the MPLS layer network in a consistent manner irrespective of its clients.....ditto the IP layer and ditto the main SDH co-cs transport networks (though these are well-sorted already as I am sure any operator will understand). But its far bigger than just the OAM functional component of each mode. Here, for example, are a set of high-level (largely commercially driven) requirements I'd like to see any proposed arch tested against: 1. For many reasons real networks will run at low loads over most of their life. It is therefore essential that we can create consistently meaningful services (both public and private) over a large range of load points, ie a customer gets what they have paid for, not what someone else has paid for. Further, the 'perceived value' and pricing of a service must be decoupled from the network resource (ie bandwidth) used. 2. The sensitive internal control/management-plane protocols must be completely secure from attack, and the network must remain secure and stable under situations of extreme stress, ie serious failures. It is therefore almost a no-brainer requirement that such protocols must be run OOB (Out-Of-Band) in relation to customer traffic wherever possible. A key corollary of this is that the OAM used to monitor the integrity of the traffic and detect/handle defects must be run In-Band. 3. We must be able to differentiate 'urgency' from 'importance' over all load points for both public and private traffic. For example, voice traffic is always 'urgent' (ie cannot tolerate large delay impairments) but it may or may not be 'important'. Indeed, a similar argument can be applied to any application. 4. The network must be 'designed for uncertainty', ie it must be able to accommodate unforeseen traffic types/vectors. 5. We need to stop doing stovepipes, ie selling a specific technology (and its functions/features) as 'the service'. The target architecture must factor-in migration of current legacy networks, and, by inference, requires a clear architectural understanding of both client/server layer network interworking and peer-partition layer network interworking (this is not the same as what some folks call 'service i/w' for good reasons). If the proposed architecture cannot deleiver against these then I think we are creating problems for the whole community over the long-term. Well, that's my view anyway. > The timing recovery problem depends on packet-loss > rates and PDV, these are not directly dependent on > whether we have UDP/IP or MPLS (unless we have > some TE in the MPLS case, or RSVP in the UDP/IP case). NH=3D> This is also a function of network load. If we have to run a = given mode at rather low loads (the uncertainty increases as one moves from co-cs->co-ps->cl-ps, but don't necssarily read this as a 'bad thing', its the mapping of the right mode to the appropriate public/private application service case that is key) *and* if we have not ensured the above requirements can be met (esp item 1) we have some serious problems looming IMO. At some point SLAs will enter the equation....now we need some agreed HRXs with both end-end and apportionment rules on objective Net Perf metrics (not some woolly hand-waving notion of 'QoS' I see mentioned from time to time). Well, seems we can't even get the basic stuff like the defects sorted here....so what chance this? Another message I am sure folks are sick of me saying now is that the client layer inherits both the disjoint connectivity (2-dim entity) and network performance (1-dim entity) of its server layer....and this recurses to the duct. I have some ideas for a next generation network architecture that could work and meet the requirements noted above (and almost as a by-product will probably give lowest capex/opex too).....but it requires letting go of modal/technology religion and seeing how each mode can work in concert. I do not believe we are quite ready to embrace this.....maybe the commercials need to hurt some more. Keep going the way we currently are, and this is not a question of 'if' IMO but 'when'.....for some 'when' has already arrived of course. So Yaakov, I for sure don't want to beat-up on your particular patch here......this is a symptom IMO and not the cause. Its no good keep addressing symptoms however, we need stand back and look at the total picture to see what are the real problems. The world is changing and its no longer the old Telco world nor is it the pioneering/experimental world that spawned the Internet. We need to find solutions that recognise this. There are some 'discovered truths' about networking, some folks might not like them, but we can't alter that. What we can do however, is look for the optimum way of marrying all the best bits from what we have collectively learned to date. Not to do so would be just plain daft IMO. Regards, Neil=20 >=20 > Y(J)S=20 >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Wednesday, August 04, 2004 11:14 > > To: Yaakov Stein; yakov@juniper.net > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] UDP questions=20 > >=20 > > Yaakov, > >=20 > > With all due respect I don't find your arguments > > compelling....in 1-5 below only 3 offers an 'argument', the=20 > > rest are simply statements of 'this is what we are doing'=20 > > (whether right or wrong). > >=20 > > Let me briefly re-state my take on this topic: > > - UDP (and TCP) are application adaptation functions, ie they > > adapt applications to the layer network they will run on, here IP. > > - This is quite different to 'inter-layer client/server > > adaptation' between 2 layer networks.....and the nature of > > the adaptation required varies as a function of the=20 > > mode/technology of both the client and the server. 1 size=20 > > does not fit all here. > > - Voice (or video) say is an application. It is not a PDH E1 > > layer network entity. It is not an SDH VC4 layer network=20 > > enity. Voice is not 'TDM' either....in fact its pretty=20 > > bursty. Sure it has timing requirements that must be=20 > > satisfied, but these are not the same as those for a proper=20 > > TDM layer network. TDM layer networks also require fault=20 > > management and performance management that is not the same=20 > > (obviously!) to a voice application. I therefore conclude=20 > > that the AVT argument is not appropriate either. > >=20 > > So I don't regard UDP as an appropriate inter-layer > > adaptation function for the carriage of co-cs mode layer=20 > > networks (or indeed any mode layer networks). > >=20 > > And I assume you would not be advocating this as a 'solution' > > anyway for large operators or the Internet.....I guess this=20 > > is targeted at enterprises right? > >=20 > > Regards, Neil > >=20 > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On Behalf > > > Of Yaakov Stein > > > Sent: 03 August 2004 17:19 > > > To: Yakov Rekhter > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] UDP questions > > >=20 > > >=20 > > > Yakov, > > >=20 > > > We have already had this discussion, > > > with Eric asking this question. > > >=20 > > > The main reasons for allowing this are: > > >=20 > > > 1) it is already widely employed for TDM PWs > > > 2) it is arguably the first PW technique > > > 3) it aligns with avt work > > > 4) it is in the charter > > > 5) it is in the arcitecture document. > > >=20 > > > So if we find strong reasons AGAINST its use, then I can=20 > understand > > > our considering prohibiting it. > > > But wouldn't any such reason would impact avt work as well? > > >=20 > > > Y(J)S > > >=20 > > > > -----Original Message----- > > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > > Sent: Tuesday, August 03, 2004 17:38 > > > > To: Yaakov Stein > > > > Cc: pwe3@ietf.org > > > > Subject: Re: [PWE3] UDP questions > > > >=20 > > > > Yaakov, > > > >=20 > > > > > Following my presentation today, > > > > > I would like to solicit responses to the 2 questions I raised. > > > > >=20 > > > > > 1) Should the PW label be placed in > > > > > A) destination UDP port field (has NAT/firewall issues) > > > > > B) source UDP port ? > > > >=20 > > > > Should the PW label be placed in the UDP header in the > > first place ? > > > >=20 > > > > Yakov. > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >=20 > >=20 > >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Cheng-Yin Lee Subject: Re: Scaling hierarchical LDP/PW stitching Date: Thu, 05 Aug 2004 11:58:04 -0400 Lines: 92 Sender: pwe3-bounces@ietf.org References: <41119049.68CCE76F@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, busschbach@lucent.com, pwe3@ietf.org, dpapadimitriou@psg.com X-From: pwe3-bounces@ietf.org Thu Aug 05 18:02:57 2004 Return-path: X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Mustapha Aissaoui , richard.spencer@bt.com X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Mustapha, Richard, Mustapha Aissaoui wrote: > richard.spencer@bt.com wrote: > > > > 2. State how routing of PW control messages are performed once the > > > stitching nodes have been discovered. It seems to me that a solution > > > that mandates the use of FA-LSPs is too restrictive. > > > > I agree that mandating FA-LSPs is too restrictive and that a common PW > > routing solution should be specified. Agree that mandating FA-LSPs is too restrictive, unless some of these types of "TE" are acceptable: - only "shortest paths" are used for all services or - a separate network is used for PW services or - others? > > > 3. Avoid if possible making the PW label routable. Not that I have > > > anything against that but if a solution turns PWs into routable > > > entities on their own, then we should discuss it in that wider > > > context. In that case, the use of tunnel LSPs becomes a convenience > > > as opposed to a requirement of the architecture. > > > > I'm not sure I understand your last point; it appears to me to be a > > contradiction. In 2 you state that routing of PW control messages must > > be addressed but then in 3 state that making PWs routable should be > > avoided. I think there are two issues here, a) routing at the PW layer > > where LSPs tunnels are used (resulting in a two layer LSP hierarchy), b) > > routing where tunnel LSPs are not used (resulting in a single LSP > > layer). > > MA> I mean that we do not want to have a separate addressing and > routing for PWs in the current PWE3 architecture. > I make the following argument: as long as PWs are confined inside > tunnels, it does not make sense to make them routable (network wide) > and have their own address space. I believe PWs could be routable but not have their own address space. > > Regarding a), in the control plane, routing is required at the PW layer > > to calculate/select the PW path from ingress PE to egress PE across > > intermediate PW switching points and therefore the PE IP addresses must > > be routable. In the (PW) data plane the PW label needs to be used at > > each hop to make a forwarding decision. However, even though PWs need to > > be routable at the PW level, they are not routable at the tunnel LSP > > level, i.e. forwarding at the LSP tunnel level is based on tunnel LSP > > labels not PW labels, just like VP switching in ATM is based on VPIs not > > VCIs. > > MA> You describe it very well. My point is that the PW dataplane > forwarding decision should be local to a stitching node and not > network wide. In other words, we do not want to advertize PW > reachability. In (a) when PWs are not tunneled , I believe there is more provisioning work required if PW stitching nodes are not advertised. This may be acceptable or not acceptable to some operators? > > Regarding b), if tunnel LSPs are not used then PWs must still be > > routable at the PW layer, but as this is the only layer each hop must > > belong to the PW layer, i.e. each hop must support PW switching. For > > scaling reasons its highly unlikely that a single LSP layer would be > > used in the core, but I think using a single LSP layer would make sense > > for spoke connections in the hierarchical LDP model. > > MA> Correct. And this is where I think Peter and I disagree. I do > not belive that we want to solve the general problem where any node > can be used as a stitching node because this degenerates into the > case where you will be forced to have a separate routing and > addressing for the PWs. The case of the spoke connections is > different. I assume that a static PW may be just fine if the access > network is simple. In complex access and aggregation networks, one > can have build a separate PSN for this network and perform switching > at some well idnetified edge nodes. In the last sentence, are you still referring to (b) when PWs are tunneled? Are there congruent nodes in the separate PSN and the other PSN? Thanks Cheng-Yin > > > > Regards, > > Richard > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Shah, Himanshu" Subject: arp-mediation Date: Thu, 5 Aug 2004 13:50:05 -0400 Lines: 10 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-bounces@ietf.org Thu Aug 05 20:00:22 2004 Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Dear chairs, Given that we observed a wide support for the arp-mediation draft in the WG at the IETF meeting, I request the chairs to make a call on the WG mailing list to accept the document as the WG Doc. http://www.ietf.org/internet-drafts/draft-shah-l2vpn-arp-mediation-01.txt thanks, Himanshu From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Shah, Himanshu" Subject: RE: arp-mediation Date: Thu, 5 Aug 2004 15:52:11 -0400 Lines: 27 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-bounces@ietf.org Thu Aug 05 21:53:34 2004 Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Oops! wrong group! Goes to l2vpn group. sorry. -----Original Message----- From: Shah, Himanshu Sent: Thursday, August 05, 2004 1:50 PM To: 'pwe3@ietf.org' Subject: [PWE3] arp-mediation Dear chairs, Given that we observed a wide support for the arp-mediation draft in the WG at the IETF meeting, I request the chairs to make a call on the WG mailing list to accept the document as the WG Doc. http://www.ietf.org/internet-drafts/draft-shah-l2vpn-arp-mediation-01.txt thanks, Himanshu _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: UDP questions Date: Thu, 5 Aug 2004 19:36:42 +0300 Lines: 32 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sat Aug 07 17:24:22 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] UDP questions Thread-Index: AcR6eh5hJwBi8OAOS/GhbSaJCZhwMQAj5Ncg To: "Sasha Vainshtein" X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > [Sasha] The following text is quoted verbatim (with only Q: and A:=20 > inserted for clarity)from the official Skype FAQ/Technical page > (http://www.skype.com/help_faq.html#Technical) >=20 > > Q: I can't connect to Skype from work or due to a restrictive=20 > firewall. Which ports need to be opened in order to use Skype?=20 This is some strange case. Quoting from the Skype site : *Works with all firewall, NAT and routers - nothing to configure!=20 and from the FAQ: Several new techniques were also developed in order to avoid end-user configuration=20 of gateways and firewalls, whose non-intuitive configuration settings typically prohibit=20 the majority of users from communicating successfully.=20 In short, Skype works behind the majority of firewalls and gateways with no special configuration. >From personal experience this is true. In my organization I can get SIP-based VoIP=20 to work from my desk, bur Skype works fine. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: UDP questions Date: Thu, 5 Aug 2004 19:40:09 +0300 Lines: 18 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, Sasha Vainshtein X-From: pwe3-bounces@ietf.org Sat Aug 07 17:26:06 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] UDP questions Thread-Index: AcR6h4YrvqQ3slPVSwyFUlQH8dF2MAAgxZuw To: "Tony Li" X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org =20 > It may well be easier to get a different protocol that does=20 > NOT use ports through a NAT/firewall device. If nothing=20 > else, you will be quite certain that the NAT is not messing=20 > with your demuxing. As I have said before, there is no problem with using UDP ports, just with using the DESTINATION port. > p.s. A de-facto standard that solves no problems is an=20 > oxymoron. A de-facto standard becomes established precisely=20 > because it is solving real world problems, usually because=20 > the SDO is not doing so as rapidly as the market would like. Well, my presentation here at San Diego and my email to the list were precisely to speed things up. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Sat, 7 Aug 2004 22:15:14 -0400 Lines: 173 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, dpapadimitriou@psg.com X-From: pwe3-bounces@ietf.org Sun Aug 08 04:27:12 2004 Return-path: To: "'Mustapha Aissaoui'" , richard.spencer@bt.com X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Mustapha, I am surprised by your insistence that PWs should not be routable. I understand that the proposals I made in this email exchange have pros and cons. Within the scope of the requirements (which we will document, as we discussed in San Diego), it is very well possible that the cons outweight the pros. Or vice versa. We will see. However, you seem to have decided already that routable PWs are forbidden under any circumstances. You write: "My point is that the PW dataplane forwarding decision should be local to a stitching node and not network wide." I have no idea what you mean by that. The dataplane forwarding decision is always local. The stitching node receives a packet with PW Label A, swaps it with PW Label B and forwards it over the appropriate tunnel. The issue is how the stitching node supports signaling. It receives a PW setup request (in the current model, an LDP label mapping message) and somehow has to determine what the next node on the Multi-hop Path is. In all likelyhood, that next hop will be derived from one or more identifiers that identify the end point of the MH-PW. There are two options: a) identify the end point by the IP address of the destination PE b) identify the end point by a specific AGI/AII combination. Since every node in the network already IP routing and already has (a prefix of) the PE's IP address in its routing table, it seems to me that a) is more straightforward than b). Not only that. Solution b) requires a topology discovery protocol based on AGIs and AIIs. However, in your email, you also write that: "... we do not want to have a separate addressing and routing for PWs in the current PWE3 architecture". I am not sure how to interpret this statement. It sounds as if you agree with me that a) is the better solution. However, you are arguing vehemently against my position. Therefore, the only thing I can imagine is that you believe that any form of automated MH-PW setup is undesirable and that Service Providers will be perfectly happy to manually provision MH-PWs. You may be right, but let's wait for the requirements ... Peter > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, August 04, 2004 9:41 PM > To: richard.spencer@bt.com > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > Richard, > see below. > > Regards, > Mustapha. > ----------- > richard.spencer@bt.com wrote: > > > > Mustapha, > > > > > Richard and Dimitri, > > > this issue is in my view one of the critical issues. I believe a > > > workable solution should have the following characteristics: > > > > > > 1. State how stitching nodes are discovered. I do not agree with > > > Peter that a stiching node is just another LSP switching > node. There > > > are PW specific operations to be performed in the data, > control, and > > > management (OAM) planes on a PW segment. > > > > I agree that a PW stitching node is not just another (tunnel) LSP > > switching node. The data plane behaviour (i.e. MPLS label > switching) may > > be the same but the tunnel LSP control protocols needs to > be modified > > (or separate control protocols/instances used) in order to support > > single sided provisioning of switched PWs. > > MA> Add to that OAM on the PW segment. > > > I think discovery can be > > split up into two aspects, i) discovery of ingress/egress > PEs, and ii) > > discovery of PW switching nodes. > > Regarding i) this is required to support single sided provisioning. > > MA> I think single sided signaling is a separate issue. You can > still configure the AC and PW information at both PEs but have one > side trigger the PW setup (master PE) and the other reply only when > it receives it (slave PW). This is the dominant mode of operation of > SPVCs in ATM networks today. > > > Regarding ii), this is only required if routers use the same address > > space (i.e. same loopback addresses) at the PW layer that > they use at > > the MPLS tunnel layer. If a different address space was used then > > support for PW switching would be explicit. The consequence > of using the > > same addresses is that PW switching capable nodes must be > distinguish > > from non PW switching capable nodes explicitly using a discovery > > mechanism or implicitly, e.g. using routing metrics as is > the case with > > the FA-LSP solution. > > MA> You are right. However, the reason for using the same address > space is a direct consequence of the fact that PWs can only ride > inside a tunnel of some sort. > > > > 2. State how routing of PW control messages are performed once the > > > stitching nodes have been discovered. It seems to me that > a solution > > > that mandates the use of FA-LSPs is too restrictive. > > > > I agree that mandating FA-LSPs is too restrictive and that > a common PW > > routing solution should be specified. > > > > > 3. Avoid if possible making the PW label routable. Not that I have > > > anything against that but if a solution turns PWs into routable > > > entities on their own, then we should discuss it in that wider > > > context. In that case, the use of tunnel LSPs becomes a > convenience > > > as opposed to a requirement of the architecture. > > > > I'm not sure I understand your last point; it appears to me to be a > > contradiction. In 2 you state that routing of PW control > messages must > > be addressed but then in 3 state that making PWs routable should be > > avoided. I think there are two issues here, a) routing at > the PW layer > > where LSPs tunnels are used (resulting in a two layer LSP > hierarchy), b) > > routing where tunnel LSPs are not used (resulting in a single LSP > > layer). > > MA> I mean that we do not want to have a separate addressing and > routing for PWs in the current PWE3 architecture. > I make the following argument: as long as PWs are confined inside > tunnels, it does not make sense to make them routable (network wide) > and have their own address space. > > > Regarding a), in the control plane, routing is required at > the PW layer > > to calculate/select the PW path from ingress PE to egress PE across > > intermediate PW switching points and therefore the PE IP > addresses must > > be routable. In the (PW) data plane the PW label needs to be used at > > each hop to make a forwarding decision. However, even > though PWs need to > > be routable at the PW level, they are not routable at the tunnel LSP > > level, i.e. forwarding at the LSP tunnel level is based on > tunnel LSP > > labels not PW labels, just like VP switching in ATM is > based on VPIs not > > VCIs. > > MA> You describe it very well. My point is that the PW dataplane > forwarding decision should be local to a stitching node and not > network wide. In other words, we do not want to advertize PW > reachability. > > > Regarding b), if tunnel LSPs are not used then PWs must still be > > routable at the PW layer, but as this is the only layer > each hop must > > belong to the PW layer, i.e. each hop must support PW switching. For > > scaling reasons its highly unlikely that a single LSP layer would be > > used in the core, but I think using a single LSP layer > would make sense > > for spoke connections in the hierarchical LDP model. > > MA> Correct. And this is where I think Peter and I disagree. I do > not belive that we want to solve the general problem where any node > can be used as a stitching node because this degenerates into the > case where you will be forced to have a separate routing and > addressing for the PWs. The case of the spoke connections is > different. I assume that a static PW may be just fine if the access > network is simple. In complex access and aggregation networks, one > can have build a separate PSN for this network and perform switching > at some well idnetified edge nodes. > > > Regards, > > Richard > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "cagatay koc" Subject: Requirements + Date: Mon, 9 Aug 2004 22:45:16 -0400 Lines: 22 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Mon Aug 09 04:50:11 2004 Return-path: To: X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcR+hBELwuv3ajogTFCiH1rt+rNQdg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org WG, In the PWE3 session of the IETF meeting on last monday, after I presented Du Ke's draft we had a discussion with Peter Busschbach and Mark Townsley and it became clear that the 'switching/stiching' solutions (functionality/location), are a bit premature given the fact that a detailed requirement document is missing which should also iron out terminology and other critical issues. It would make sense to quickly put down a draft on intra-AS, inter-AS requirements relevant to PW switching points, taking into account operator needs as well as requirements already implied in the existing documents. These points are made several times here but it would make sense to form a group of volunteers to draft a common document. I also talked with Luka Martini and he thinks there might be a requirement document (which I could not find) and Nabil Bitar also agrees with this 'soft concensus', obviously Neil from his mails agrees with this assessment. Latest exchange between Mustafa and Peter also can be resolved with a requirement document. I am willing to work on this as long as we have a few other volunteers (at least 1 from operator side). Best regards, Cagatay Buyukkoc From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Mon, 09 Aug 2004 12:54:04 +0100 Lines: 9 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Mon Aug 09 14:01:45 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: pwe3@ietf.org X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The authors request that http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt be adopted as a WG item with its title changed to PWE3 MPLS Control Word - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Mon, 9 Aug 2004 15:12:54 +0200 Lines: 40 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-bounces@ietf.org Mon Aug 09 14:29:30 2004 Return-path: To: "'Stewart Bryant'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I support this. 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: Monday, August 09, 2004 1:54 PM > To: pwe3@ietf.org > Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request > > > The authors request that > > http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe > 3-cw-00.txt > > be adopted as a WG item with its title changed to > > PWE3 MPLS Control Word > > - Stewart > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Prayson Pate" Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Mon, 9 Aug 2004 08:42:29 -0400 Lines: 63 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Mon Aug 09 14:56:01 2004 Return-path: To: "'Sasha Vainshtein'" , "'Stewart Bryant'" , X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR+DKqXJgRkmvCgRyCu4wpQJTYcMAAAGiJQ In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh3.wired-hub.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - overturenetworks.com X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org As do I. Prayson Pate 919-337-4102 (direct) 919-337-4149 (fax) prayson.pate@overturenetworks.com http://www.overturenetworks.com Research Triangle Park, NC, USA -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Sasha Vainshtein Sent: Monday, August 09, 2004 9:13 AM To: 'Stewart Bryant'; pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request I support this. 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: Monday, August 09, 2004 1:54 PM > To: pwe3@ietf.org > Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request > > > The authors request that > > http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe > 3-cw-00.txt > > be adopted as a WG item with its title changed to > > PWE3 MPLS Control Word > > - Stewart > > > > > > > > _______________________________________________ > 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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Mustapha Aissaoui Subject: Re: Scaling hierarchical LDP/PW stitching Date: Mon, 09 Aug 2004 10:31:45 -0400 Organization: Alcatel Networks Corporaton Lines: 194 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, richard.spencer@bt.com, dpapadimitriou@psg.com X-From: pwe3-bounces@ietf.org Mon Aug 09 16:46:52 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Busschbach, Peter B (Peter)" X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, see a couple of clarifications below. I agree that we need to work on the requirements and scope of MH-PWs. Regards, Mustapha. ------------ "Busschbach, Peter B (Peter)" wrote: > > Mustapha, > > I am surprised by your insistence that PWs should not be routable. MA> It seems to me we are debating terminology here. By PWs are routable, I mean there is a separate (from the PSN) routing instance which advertises PW reachability and which is used by the stitching nodes to forward the PW packets. This would be something like what option (b) you describe below which will be based on routable PW label and/or TAII. > I understand that the proposals I made in this email exchange have pros >and cons. Within the scope of the requirements (which we will document, >as we discussed in San Diego), it is very well possible that the cons >outweight the pros. Or vice versa. We will see. However, you seem to have >decided already that routable PWs are forbidden under any circumstances. > You write: "My point is that the PW dataplane forwarding decision should >be local to a stitching node and not network wide." > I have no idea what you mean by that. The dataplane forwarding decision >is always local. The stitching node receives a packet with PW Label A, >swaps it with PW Label B and forwards it over the appropriate tunnel. > The issue is how the stitching node supports signaling. It receives a PW >setup request (in the current model, an LDP label mapping message) and >somehow has to determine what the next node on the Multi-hop Path is. In >all likelyhood, that next hop will be derived from one or more >identifiers that identify the end point of the MH-PW. > > There are two options: > > a) identify the end point by the IP address of the destination PE > b) identify the end point by a specific AGI/AII combination. > > Since every node in the network already IP routing and already has (a >prefix of) the PE's IP address in its routing table, it seems to me that >a) is more straightforward than b). Not only that. Solution b) requires a >topology discovery protocol based on AGIs and AIIs. > > However, in your email, you also write that: > "... we do not want to have a separate addressing and routing for PWs in the current PWE3 architecture". > > I am not sure how to interpret this statement. It sounds as if you agree >with me that a) is the better solution. However, you are arguing >vehemently against my position. Therefore, the only thing I can imagine >is that you believe that any form of automated MH-PW setup is undesirable >and that Service Providers will be perfectly happy to manually provision >MH-PWs. MA> You are right, I agree with you on (a) because we want to stick to the current PWE3 architecture as much as possible. The point where I disagree is you want to make any LSR a stitching node. I think what Richard and I have comme to the conclusion that in this case you would need a solution like in (b). > You may be right, but let's wait for the requirements ... > > Peter > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Wednesday, August 04, 2004 9:41 PM > > To: richard.spencer@bt.com > > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > Richard, > > see below. > > > > Regards, > > Mustapha. > > ----------- > > richard.spencer@bt.com wrote: > > > > > > Mustapha, > > > > > > > Richard and Dimitri, > > > > this issue is in my view one of the critical issues. I believe a > > > > workable solution should have the following characteristics: > > > > > > > > 1. State how stitching nodes are discovered. I do not agree with > > > > Peter that a stiching node is just another LSP switching > > node. There > > > > are PW specific operations to be performed in the data, > > control, and > > > > management (OAM) planes on a PW segment. > > > > > > I agree that a PW stitching node is not just another (tunnel) LSP > > > switching node. The data plane behaviour (i.e. MPLS label > > switching) may > > > be the same but the tunnel LSP control protocols needs to > > be modified > > > (or separate control protocols/instances used) in order to support > > > single sided provisioning of switched PWs. > > > > MA> Add to that OAM on the PW segment. > > > > > I think discovery can be > > > split up into two aspects, i) discovery of ingress/egress > > PEs, and ii) > > > discovery of PW switching nodes. > > > Regarding i) this is required to support single sided provisioning. > > > > MA> I think single sided signaling is a separate issue. You can > > still configure the AC and PW information at both PEs but have one > > side trigger the PW setup (master PE) and the other reply only when > > it receives it (slave PW). This is the dominant mode of operation of > > SPVCs in ATM networks today. > > > > > Regarding ii), this is only required if routers use the same address > > > space (i.e. same loopback addresses) at the PW layer that > > they use at > > > the MPLS tunnel layer. If a different address space was used then > > > support for PW switching would be explicit. The consequence > > of using the > > > same addresses is that PW switching capable nodes must be > > distinguish > > > from non PW switching capable nodes explicitly using a discovery > > > mechanism or implicitly, e.g. using routing metrics as is > > the case with > > > the FA-LSP solution. > > > > MA> You are right. However, the reason for using the same address > > space is a direct consequence of the fact that PWs can only ride > > inside a tunnel of some sort. > > > > > > 2. State how routing of PW control messages are performed once the > > > > stitching nodes have been discovered. It seems to me that > > a solution > > > > that mandates the use of FA-LSPs is too restrictive. > > > > > > I agree that mandating FA-LSPs is too restrictive and that > > a common PW > > > routing solution should be specified. > > > > > > > 3. Avoid if possible making the PW label routable. Not that I have > > > > anything against that but if a solution turns PWs into routable > > > > entities on their own, then we should discuss it in that wider > > > > context. In that case, the use of tunnel LSPs becomes a > > convenience > > > > as opposed to a requirement of the architecture. > > > > > > I'm not sure I understand your last point; it appears to me to be a > > > contradiction. In 2 you state that routing of PW control > > messages must > > > be addressed but then in 3 state that making PWs routable should be > > > avoided. I think there are two issues here, a) routing at > > the PW layer > > > where LSPs tunnels are used (resulting in a two layer LSP > > hierarchy), b) > > > routing where tunnel LSPs are not used (resulting in a single LSP > > > layer). > > > > MA> I mean that we do not want to have a separate addressing and > > routing for PWs in the current PWE3 architecture. > > I make the following argument: as long as PWs are confined inside > > tunnels, it does not make sense to make them routable (network wide) > > and have their own address space. > > > > > Regarding a), in the control plane, routing is required at > > the PW layer > > > to calculate/select the PW path from ingress PE to egress PE across > > > intermediate PW switching points and therefore the PE IP > > addresses must > > > be routable. In the (PW) data plane the PW label needs to be used at > > > each hop to make a forwarding decision. However, even > > though PWs need to > > > be routable at the PW level, they are not routable at the tunnel LSP > > > level, i.e. forwarding at the LSP tunnel level is based on > > tunnel LSP > > > labels not PW labels, just like VP switching in ATM is > > based on VPIs not > > > VCIs. > > > > MA> You describe it very well. My point is that the PW dataplane > > forwarding decision should be local to a stitching node and not > > network wide. In other words, we do not want to advertize PW > > reachability. > > > > > Regarding b), if tunnel LSPs are not used then PWs must still be > > > routable at the PW layer, but as this is the only layer > > each hop must > > > belong to the PW layer, i.e. each hop must support PW switching. For > > > scaling reasons its highly unlikely that a single LSP layer would be > > > used in the core, but I think using a single LSP layer > > would make sense > > > for spoke connections in the hierarchical LDP model. > > > > MA> Correct. And this is where I think Peter and I disagree. I do > > not belive that we want to solve the general problem where any node > > can be used as a stitching node because this degenerates into the > > case where you will be forced to have a separate routing and > > addressing for the PWs. The case of the spoke connections is > > different. I assume that a static PW may be just fine if the access > > network is simple. In complex access and aggregation networks, one > > can have build a separate PSN for this network and perform switching > > at some well idnetified edge nodes. > > > > > Regards, > > > Richard > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Thomas D. Nadeau" Subject: Re: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Mon, 9 Aug 2004 14:37:49 -0400 Lines: 53 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Mon Aug 09 21:06:57 2004 Return-path: X-BrightmailFiltered: true In-Reply-To: To: Sasha Vainshtein X-Mailer: Apple Mail (2.618) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Agreed based on having the changes made that were requested at the meeting. --Tom > I support this. > > 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: Monday, August 09, 2004 1:54 PM >> To: pwe3@ietf.org >> Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request >> >> >> The authors request that >> >> http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe >> 3-cw-00.txt >> >> be adopted as a WG item with its title changed to >> >> PWE3 MPLS Control Word >> >> - Stewart >> >> >> >> >> >> >> >> _______________________________________________ >> 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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Scaling hierarchical LDP/PW stitching Date: Mon, 09 Aug 2004 15:39:35 -0600 Organization: Cisco Systems Lines: 313 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, 'Mustapha Aissaoui' , dpapadimitriou@psg.com, richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Tue Aug 10 00:14:26 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: "Busschbach, Peter B (Peter)" In-Reply-To: X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, I would like to make a distinction between autodiscovery , and PW switching. What you are proposing is an autodiscovery system that automatically provisions the PW switching point to switch an incoming PW into a specific outgoing one. I believe that there is a requirement for this functionality, but this is an L2VPN and PW autodiscovery discussion. I purposely kept away from this in the pw-switching draft, as provisioning of L2VPNs is not in scope here. ( this does not mean it is not required by somebody ). Also keep in mind that today I only know about L2 peering points that are statically provisioned. Unlike L3 peering, I have not seen PNNI peering or Frame-Relay SPVC peering. Luca Busschbach, Peter B (Peter) wrote: >Mustapha, > >I am surprised by your insistence that PWs should not be routable. > >I understand that the proposals I made in this email exchange have pros and cons. Within the scope of the requirements (which we will document, as we discussed in San Diego), it is very well possible that the cons outweight the pros. Or vice versa. We will see. However, you seem to have decided already that routable PWs are forbidden under any circumstances. > >You write: "My point is that the PW dataplane forwarding decision should be local to a stitching node and not network wide." > >I have no idea what you mean by that. The dataplane forwarding decision is always local. The stitching node receives a packet with PW Label A, swaps it with PW Label B and forwards it over the appropriate tunnel. > >The issue is how the stitching node supports signaling. It receives a PW setup request (in the current model, an LDP label mapping message) and somehow has to determine what the next node on the Multi-hop Path is. In all likelyhood, that next hop will be derived from one or more identifiers that identify the end point of the MH-PW. > >There are two options: > >a) identify the end point by the IP address of the destination PE >b) identify the end point by a specific AGI/AII combination. > >Since every node in the network already IP routing and already has (a prefix of) the PE's IP address in its routing table, it seems to me that a) is more straightforward than b). Not only that. Solution b) requires a topology discovery protocol based on AGIs and AIIs. > >However, in your email, you also write that: >"... we do not want to have a separate addressing and routing for PWs in the current PWE3 architecture". > >I am not sure how to interpret this statement. It sounds as if you agree with me that a) is the better solution. However, you are arguing vehemently against my position. Therefore, the only thing I can imagine is that you believe that any form of automated MH-PW setup is undesirable and that Service Providers will be perfectly happy to manually provision MH-PWs. > >You may be right, but let's wait for the requirements ... > >Peter > > > > >>-----Original Message----- >>From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] >>Sent: Wednesday, August 04, 2004 9:41 PM >>To: richard.spencer@bt.com >>Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; >>busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org >>Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching >> >> >>Richard, >>see below. >> >>Regards, >>Mustapha. >>----------- >>richard.spencer@bt.com wrote: >> >> >>>Mustapha, >>> >>> >>> >>>>Richard and Dimitri, >>>>this issue is in my view one of the critical issues. I believe a >>>>workable solution should have the following characteristics: >>>> >>>>1. State how stitching nodes are discovered. I do not agree with >>>>Peter that a stiching node is just another LSP switching >>>> >>>> >>node. There >> >> >>>>are PW specific operations to be performed in the data, >>>> >>>> >>control, and >> >> >>>>management (OAM) planes on a PW segment. >>>> >>>> >>>I agree that a PW stitching node is not just another (tunnel) LSP >>>switching node. The data plane behaviour (i.e. MPLS label >>> >>> >>switching) may >> >> >>>be the same but the tunnel LSP control protocols needs to >>> >>> >>be modified >> >> >>>(or separate control protocols/instances used) in order to support >>>single sided provisioning of switched PWs. >>> >>> >>MA> Add to that OAM on the PW segment. >> >> >> >>>I think discovery can be >>>split up into two aspects, i) discovery of ingress/egress >>> >>> >>PEs, and ii) >> >> >>>discovery of PW switching nodes. >>>Regarding i) this is required to support single sided provisioning. >>> >>> >>MA> I think single sided signaling is a separate issue. You can >>still configure the AC and PW information at both PEs but have one >>side trigger the PW setup (master PE) and the other reply only when >>it receives it (slave PW). This is the dominant mode of operation of >>SPVCs in ATM networks today. >> >> >> >>>Regarding ii), this is only required if routers use the same address >>>space (i.e. same loopback addresses) at the PW layer that >>> >>> >>they use at >> >> >>>the MPLS tunnel layer. If a different address space was used then >>>support for PW switching would be explicit. The consequence >>> >>> >>of using the >> >> >>>same addresses is that PW switching capable nodes must be >>> >>> >>distinguish >> >> >>>from non PW switching capable nodes explicitly using a discovery >>>mechanism or implicitly, e.g. using routing metrics as is >>> >>> >>the case with >> >> >>>the FA-LSP solution. >>> >>> >>MA> You are right. However, the reason for using the same address >>space is a direct consequence of the fact that PWs can only ride >>inside a tunnel of some sort. >> >> >> >>>>2. State how routing of PW control messages are performed once the >>>>stitching nodes have been discovered. It seems to me that >>>> >>>> >>a solution >> >> >>>>that mandates the use of FA-LSPs is too restrictive. >>>> >>>> >>>I agree that mandating FA-LSPs is too restrictive and that >>> >>> >>a common PW >> >> >>>routing solution should be specified. >>> >>> >>> >>>>3. Avoid if possible making the PW label routable. Not that I have >>>>anything against that but if a solution turns PWs into routable >>>>entities on their own, then we should discuss it in that wider >>>>context. In that case, the use of tunnel LSPs becomes a >>>> >>>> >>convenience >> >> >>>>as opposed to a requirement of the architecture. >>>> >>>> >>>I'm not sure I understand your last point; it appears to me to be a >>>contradiction. In 2 you state that routing of PW control >>> >>> >>messages must >> >> >>>be addressed but then in 3 state that making PWs routable should be >>>avoided. I think there are two issues here, a) routing at >>> >>> >>the PW layer >> >> >>>where LSPs tunnels are used (resulting in a two layer LSP >>> >>> >>hierarchy), b) >> >> >>>routing where tunnel LSPs are not used (resulting in a single LSP >>>layer). >>> >>> >>MA> I mean that we do not want to have a separate addressing and >>routing for PWs in the current PWE3 architecture. >>I make the following argument: as long as PWs are confined inside >>tunnels, it does not make sense to make them routable (network wide) >>and have their own address space. >> >> >> >>>Regarding a), in the control plane, routing is required at >>> >>> >>the PW layer >> >> >>>to calculate/select the PW path from ingress PE to egress PE across >>>intermediate PW switching points and therefore the PE IP >>> >>> >>addresses must >> >> >>>be routable. In the (PW) data plane the PW label needs to be used at >>>each hop to make a forwarding decision. However, even >>> >>> >>though PWs need to >> >> >>>be routable at the PW level, they are not routable at the tunnel LSP >>>level, i.e. forwarding at the LSP tunnel level is based on >>> >>> >>tunnel LSP >> >> >>>labels not PW labels, just like VP switching in ATM is >>> >>> >>based on VPIs not >> >> >>>VCIs. >>> >>> >>MA> You describe it very well. My point is that the PW dataplane >>forwarding decision should be local to a stitching node and not >>network wide. In other words, we do not want to advertize PW >>reachability. >> >> >> >>>Regarding b), if tunnel LSPs are not used then PWs must still be >>>routable at the PW layer, but as this is the only layer >>> >>> >>each hop must >> >> >>>belong to the PW layer, i.e. each hop must support PW switching. For >>>scaling reasons its highly unlikely that a single LSP layer would be >>>used in the core, but I think using a single LSP layer >>> >>> >>would make sense >> >> >>>for spoke connections in the hierarchical LDP model. >>> >>> >>MA> Correct. And this is where I think Peter and I disagree. I do >>not belive that we want to solve the general problem where any node >>can be used as a stitching node because this degenerates into the >>case where you will be forced to have a separate routing and >>addressing for the PWs. The case of the spoke connections is >>different. I assume that a static PW may be just fine if the access >>network is simple. In complex access and aggregation networks, one >>can have build a separate PSN for this network and perform switching >>at some well idnetified edge nodes. >> >> >> >>>Regards, >>>Richard >>> >>> > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Scaling hierarchical LDP/PW stitching Date: Mon, 09 Aug 2004 15:50:18 -0600 Organization: Cisco Systems Lines: 80 Sender: pwe3-bounces@ietf.org References: <085091CB2CA14E4B8B163FFC37C84E9DCCE2BC@zcarhxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, "Busschbach, Peter B \(Peter\)" , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Tue Aug 10 00:17:39 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: Hamid Ould-Brahim In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9DCCE2BC@zcarhxm0.corp.nortel.com> X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hamid Ould-Brahim wrote: >Peter, > >[clipped...] > > > >>In yesterday's WG meeting we decided that we need to >>establish the requirements for PW switching first, before we >>discuss solutions. Based on the requirements it is well >>possible that we end up doing 1). However, in the long rung, >>2) might be more useful as it could apply to other problems >>than PWE as well. >> >> >> > >In addition to requirements I think in light of this >discussion and proposed solution drafts we need to clarify >maybe as new sections to existing framework draft the >following: > >a) The terminology: PW switching/stitching/multihop PW, > PW switching points and PW demultiplexor > allocation points (suggest stick with one or two terms). > > > This is defined in the draft-martini-pwe3-pw-switching-00.txt Do you need me to add anything ? >b) Deployment scenarios of multihop/switching in terms of > - an inter-as/domain > - single/inter-providers > - a PW-enabled access network to an PW-MPLS core network > - A PW "private" segment stitched to another "provider-based" > PW (not sure this is needed?). > > > This would be more suited for a requirement draft. >c) switching point determination (dynamic -routing, pre-configured) > > Automatic provisioning is part of L2VPN , we probably need to expand on the current autodiscovery/provisioning drafts to include the pw-switching cases. >d) mp-pw path determination (implicit/explicit -ERO). > > Not sure what you mean. Is this regarding the pw switching TLV we defined ? or regarding autodiscovery ? >e) switching node being PW aware or not > > If it's switching PW it must be PW aware otherwise it is only a P router in a PSN. >f) end-to-end MP-PW signaling versus no end-to-end signaling > (just switching per config). >etc... > > > Again this is another provisioning scheme requirement. Luca >Hamid. > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Mon, 9 Aug 2004 17:55:46 -0400 Lines: 44 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-bounces@ietf.org Tue Aug 10 00:19:10 2004 Return-path: To: "'Stewart Bryant'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, I agree that we need a WG document that defines how Control Words must be used. I do have concerns about the proposed solution, though: 1) The document proposes a solution to the hypothetical situation in which a PW Control Word could be mistaken for an IP packet. However, as far as I can tell, all encapsulation drafts define a CW that starts with 0000. 2) The document introduces a Payload Type identifier. Why? In the past, Mustapha Aissaoui and Dave Allan submitted drafts that argued that there was a need for a Payload Type Identifier. However, I don't think we ever accepted the underlying rationale. E.g. Mustapha's point was that a PTI was required for Service Interworking, but recent work in Service Interworking in the MPLS Forum has resulted in solutions that don't require a PTI. The general PWE architecture does not require a PTI. The PW Type is established as part of PW set up. Therefore, carrying a PW Type in the PTI only complicates matters. If the type established during PW setup is not the same as the type carried in the PTI, what should a PE do? 3) The only application that really needs a new CW is VCCV. Ironically, VCCV is not covered by the draft, as VCCV is not one of the PW Types mentioned in the IANA registry. If VCCV is indeed the only application that requires a new CW, would it not make more sense to use the MPLS Preferred CW with 0001 instead of 0000, rather than introducing the PTI? Peter > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, August 09, 2004 7:54 AM > To: pwe3@ietf.org > Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request > > > The authors request that > > http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe > 3-cw-00.txt > > be adopted as a WG item with its title changed to > > PWE3 MPLS Control Word > > - Stewart > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Requirements + Date: Mon, 09 Aug 2004 16:30:23 -0600 Organization: Cisco Systems Lines: 79 Sender: pwe3-bounces@ietf.org References: <200408090245.WAA10749@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, Chris Metz X-From: pwe3-bounces@ietf.org Tue Aug 10 00:42:56 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: cagatay koc In-Reply-To: <200408090245.WAA10749@ietf.org> X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Cagatay, I believe that we should have a short draft to spell out the requirements, but we should be careful to avoid any autoprovisioning/autodiscovery requirements for PWE3. A separate draft addressing autodiscovery requirements, for PWs needs to be submitted in L2VPN. We also need a draft in L2VPN to expand the existing solution of BGP autodiscovery, and Radius autodiscovery to include intraAS/Interprovider requirements. The requirement document I was talking about is : http://www.ietf.org/internet-drafts/draft-ietf-pwe3-requirements-08.txt In particular the section : 10 Inter-domain Issues PWE is a matter between the PW end-points and is transparent to the network devices between the PW end-points. Therefore, inter-domain PWE is fundamentally similar to intra-domain PWE. As long as PW end-points use the same PWE approach, they can communicate effectively, regardless of whether they are in the same domain. Security may become more important in the inter-domain case and some security measure such as end-point authentication MAY be applied. QoS may become more difficult to deliver too, as one service provider has no control over another service provider's provisioning and traffic management policy. To solve the inter-domain QoS problem, service providers have to cooperate. Once they agree at a contractual level to provider high quality of service to certain traffic (e.g. PWE traffic), the mechanisms defined in other working groups, e.g. Diffserv WG, can be used. Inter-domain PSN tunnels are generally more difficult to set up, tear down and maintain than intra-domain ones. But that is an issue for PSN tunneling protocols such as MPLS and L2TPv3 and is outside the scope of PWE3. Obviously this is not adequate. I think we need to be careful to focus a requirement document in on this particular topic only. We can start working on the PWE3 requirement document if you want. Luca cagatay koc wrote: >WG, >In the PWE3 session of the IETF meeting on last monday, after I presented Du >Ke's draft we had a discussion with Peter Busschbach and Mark Townsley and >it became clear that the >'switching/stiching' solutions (functionality/location), are a bit premature >given the fact that a detailed requirement document is missing which should >also iron out terminology and other critical issues. It would make sense to >quickly put down a draft on intra-AS, inter-AS requirements relevant to PW >switching points, taking into account operator needs as well >as requirements already implied in the existing documents. These points are >made several times here but it would make sense to form a group of >volunteers to draft a common document. I also talked with Luka Martini and >he thinks there might be a requirement document (which I could not find) and >Nabil Bitar also agrees with this >'soft concensus', obviously Neil from his mails agrees with this assessment. >Latest exchange between Mustafa and Peter also can be resolved with a >requirement document. >I am willing to work on this as long as we have a few other volunteers (at >least 1 from operator side). >Best regards, >Cagatay Buyukkoc > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Mon, 09 Aug 2004 16:34:56 -0600 Organization: Cisco Systems Lines: 68 Sender: pwe3-bounces@ietf.org References: <37326264-EA33-11D8-A180-000D93AD480A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Tue Aug 10 00:46:47 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: "Thomas D. Nadeau" In-Reply-To: <37326264-EA33-11D8-A180-000D93AD480A@cisco.com> X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Agreed, Please fix the name , and the x, y ,v variables in the Iana text ;-) Luca Thomas D. Nadeau wrote: > > Agreed based on having the changes > made that were requested at the meeting. > > --Tom > > >> I support this. >> >> 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: Monday, August 09, 2004 1:54 PM >>> To: pwe3@ietf.org >>> Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request >>> >>> >>> The authors request that >>> >>> http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe >>> 3-cw-00.txt >>> >>> be adopted as a WG item with its title changed to >>> >>> PWE3 MPLS Control Word >>> >>> - Stewart >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Mon, 9 Aug 2004 18:39:25 -0400 Lines: 370 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, 'Mustapha Aissaoui' , dpapadimitriou@psg.com, richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Tue Aug 10 00:49:32 2004 Return-path: To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Monday, August 09, 2004 5:40 PM > To: Busschbach, Peter B (Peter) > Cc: 'Mustapha Aissaoui'; richard.spencer@bt.com; l2vpn@ietf.org; > dimitri.papadimitriou@alcatel.be; pwe3@ietf.org; > dpapadimitriou@psg.com > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > Peter, > > I would like to make a distinction between autodiscovery , > and PW switching. > What you are proposing is an autodiscovery system that automatically > provisions the PW switching point to switch an incoming PW into a > specific outgoing one. I believe that there is a requirement for this > functionality, but this is an L2VPN and PW autodiscovery discussion. > I purposely kept away from this in the pw-switching draft, as > provisioning of L2VPNs is not in scope here. I agree that autodiscovery belongs in L2VPN and not in PWE3. However, the consequence of accepting draft-martini-pwe3-pw-switching-00.txt is that autodiscovery must be based on the LDP identifiers defined in the control draft (i.e. PWids, AGIs and AIIs). Is that the right approach? In fact, in the case of Multi-hop PWs, the autodiscovery mechanism used between PEs does not necessarily extend to PW Switching Nodes. PEs need to exchange information about Attachment Circuits, but PW Switching Nodes only need to have enough knowledge to establish end-to-end PWs. Draft-martini-pwe3-pw-switching-00.txt does not allow one to make that distinction. It assumes that every node (both PEs and PW Switching Nodes) maintain AC-related information. In summary, I don't think we can define MH-PW setup without looking at the impact it has on autodiscovery. > ( this does not mean it is > not required by somebody ). > Also keep in mind that today I only know about L2 peering points that > are statically provisioned. Unlike L3 peering, I have not seen PNNI > peering or Frame-Relay SPVC peering. I agree. On the other hand, there is telephony peering. > > Luca > > > Busschbach, Peter B (Peter) wrote: > > >Mustapha, > > > >I am surprised by your insistence that PWs should not be routable. > > > >I understand that the proposals I made in this email > exchange have pros and cons. Within the scope of the > requirements (which we will document, as we discussed in San > Diego), it is very well possible that the cons outweight the > pros. Or vice versa. We will see. However, you seem to have > decided already that routable PWs are forbidden under any > circumstances. > > > >You write: "My point is that the PW dataplane forwarding > decision should be local to a stitching node and not network wide." > > > >I have no idea what you mean by that. The dataplane > forwarding decision is always local. The stitching node > receives a packet with PW Label A, swaps it with PW Label B > and forwards it over the appropriate tunnel. > > > >The issue is how the stitching node supports signaling. It > receives a PW setup request (in the current model, an LDP > label mapping message) and somehow has to determine what the > next node on the Multi-hop Path is. In all likelyhood, that > next hop will be derived from one or more identifiers that > identify the end point of the MH-PW. > > > >There are two options: > > > >a) identify the end point by the IP address of the destination PE > >b) identify the end point by a specific AGI/AII combination. > > > >Since every node in the network already IP routing and > already has (a prefix of) the PE's IP address in its routing > table, it seems to me that a) is more straightforward than > b). Not only that. Solution b) requires a topology discovery > protocol based on AGIs and AIIs. > > > >However, in your email, you also write that: > >"... we do not want to have a separate addressing and > routing for PWs in the current PWE3 architecture". > > > >I am not sure how to interpret this statement. It sounds as > if you agree with me that a) is the better solution. However, > you are arguing vehemently against my position. Therefore, > the only thing I can imagine is that you believe that any > form of automated MH-PW setup is undesirable and that Service > Providers will be perfectly happy to manually provision MH-PWs. > > > >You may be right, but let's wait for the requirements ... > > > >Peter > > > > > > > > > >>-----Original Message----- > >>From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > >>Sent: Wednesday, August 04, 2004 9:41 PM > >>To: richard.spencer@bt.com > >>Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > >>busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org > >>Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > >> > >> > >>Richard, > >>see below. > >> > >>Regards, > >>Mustapha. > >>----------- > >>richard.spencer@bt.com wrote: > >> > >> > >>>Mustapha, > >>> > >>> > >>> > >>>>Richard and Dimitri, > >>>>this issue is in my view one of the critical issues. I believe a > >>>>workable solution should have the following characteristics: > >>>> > >>>>1. State how stitching nodes are discovered. I do not agree with > >>>>Peter that a stiching node is just another LSP switching > >>>> > >>>> > >>node. There > >> > >> > >>>>are PW specific operations to be performed in the data, > >>>> > >>>> > >>control, and > >> > >> > >>>>management (OAM) planes on a PW segment. > >>>> > >>>> > >>>I agree that a PW stitching node is not just another (tunnel) LSP > >>>switching node. The data plane behaviour (i.e. MPLS label > >>> > >>> > >>switching) may > >> > >> > >>>be the same but the tunnel LSP control protocols needs to > >>> > >>> > >>be modified > >> > >> > >>>(or separate control protocols/instances used) in order to support > >>>single sided provisioning of switched PWs. > >>> > >>> > >>MA> Add to that OAM on the PW segment. > >> > >> > >> > >>>I think discovery can be > >>>split up into two aspects, i) discovery of ingress/egress > >>> > >>> > >>PEs, and ii) > >> > >> > >>>discovery of PW switching nodes. > >>>Regarding i) this is required to support single sided provisioning. > >>> > >>> > >>MA> I think single sided signaling is a separate issue. You can > >>still configure the AC and PW information at both PEs but have one > >>side trigger the PW setup (master PE) and the other reply only when > >>it receives it (slave PW). This is the dominant mode of operation of > >>SPVCs in ATM networks today. > >> > >> > >> > >>>Regarding ii), this is only required if routers use the > same address > >>>space (i.e. same loopback addresses) at the PW layer that > >>> > >>> > >>they use at > >> > >> > >>>the MPLS tunnel layer. If a different address space was used then > >>>support for PW switching would be explicit. The consequence > >>> > >>> > >>of using the > >> > >> > >>>same addresses is that PW switching capable nodes must be > >>> > >>> > >>distinguish > >> > >> > >>>from non PW switching capable nodes explicitly using a discovery > >>>mechanism or implicitly, e.g. using routing metrics as is > >>> > >>> > >>the case with > >> > >> > >>>the FA-LSP solution. > >>> > >>> > >>MA> You are right. However, the reason for using the same address > >>space is a direct consequence of the fact that PWs can only ride > >>inside a tunnel of some sort. > >> > >> > >> > >>>>2. State how routing of PW control messages are performed once the > >>>>stitching nodes have been discovered. It seems to me that > >>>> > >>>> > >>a solution > >> > >> > >>>>that mandates the use of FA-LSPs is too restrictive. > >>>> > >>>> > >>>I agree that mandating FA-LSPs is too restrictive and that > >>> > >>> > >>a common PW > >> > >> > >>>routing solution should be specified. > >>> > >>> > >>> > >>>>3. Avoid if possible making the PW label routable. Not that I have > >>>>anything against that but if a solution turns PWs into routable > >>>>entities on their own, then we should discuss it in that wider > >>>>context. In that case, the use of tunnel LSPs becomes a > >>>> > >>>> > >>convenience > >> > >> > >>>>as opposed to a requirement of the architecture. > >>>> > >>>> > >>>I'm not sure I understand your last point; it appears to me to be a > >>>contradiction. In 2 you state that routing of PW control > >>> > >>> > >>messages must > >> > >> > >>>be addressed but then in 3 state that making PWs routable should be > >>>avoided. I think there are two issues here, a) routing at > >>> > >>> > >>the PW layer > >> > >> > >>>where LSPs tunnels are used (resulting in a two layer LSP > >>> > >>> > >>hierarchy), b) > >> > >> > >>>routing where tunnel LSPs are not used (resulting in a single LSP > >>>layer). > >>> > >>> > >>MA> I mean that we do not want to have a separate addressing and > >>routing for PWs in the current PWE3 architecture. > >>I make the following argument: as long as PWs are confined inside > >>tunnels, it does not make sense to make them routable (network wide) > >>and have their own address space. > >> > >> > >> > >>>Regarding a), in the control plane, routing is required at > >>> > >>> > >>the PW layer > >> > >> > >>>to calculate/select the PW path from ingress PE to egress PE across > >>>intermediate PW switching points and therefore the PE IP > >>> > >>> > >>addresses must > >> > >> > >>>be routable. In the (PW) data plane the PW label needs to > be used at > >>>each hop to make a forwarding decision. However, even > >>> > >>> > >>though PWs need to > >> > >> > >>>be routable at the PW level, they are not routable at the > tunnel LSP > >>>level, i.e. forwarding at the LSP tunnel level is based on > >>> > >>> > >>tunnel LSP > >> > >> > >>>labels not PW labels, just like VP switching in ATM is > >>> > >>> > >>based on VPIs not > >> > >> > >>>VCIs. > >>> > >>> > >>MA> You describe it very well. My point is that the PW dataplane > >>forwarding decision should be local to a stitching node and not > >>network wide. In other words, we do not want to advertize PW > >>reachability. > >> > >> > >> > >>>Regarding b), if tunnel LSPs are not used then PWs must still be > >>>routable at the PW layer, but as this is the only layer > >>> > >>> > >>each hop must > >> > >> > >>>belong to the PW layer, i.e. each hop must support PW > switching. For > >>>scaling reasons its highly unlikely that a single LSP > layer would be > >>>used in the core, but I think using a single LSP layer > >>> > >>> > >>would make sense > >> > >> > >>>for spoke connections in the hierarchical LDP model. > >>> > >>> > >>MA> Correct. And this is where I think Peter and I disagree. I do > >>not belive that we want to solve the general problem where any node > >>can be used as a stitching node because this degenerates into the > >>case where you will be forced to have a separate routing and > >>addressing for the PWs. The case of the spoke connections is > >>different. I assume that a static PW may be just fine if the access > >>network is simple. In complex access and aggregation networks, one > >>can have build a separate PSN for this network and perform switching > >>at some well idnetified edge nodes. > >> > >> > >> > >>>Regards, > >>>Richard > >>> > >>> > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 00:14:21 +0100 Lines: 291 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, dpapadimitriou@psg.com X-From: pwe3-bounces@ietf.org Tue Aug 10 01:26:31 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR87aVgz3Xupa/USsSM+7PDGUp+hQA8jsAw To: , X-OriginalArrivalTime: 09 Aug 2004 23:14:23.0066 (UTC) FILETIME=[9B4F83A0:01C47E66] X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, I agree with all the comments you make below. Regarding the distribution of PW layer reachability information for = MH-PWs, I would argue that this information must always be distributed = (or collected) whether manual or dynamic provisioning methods are used. = To set up a path across multiple hops where alternative paths exist, = routing must be performed, there is no getting away from this. If a = human operator manually configures a MH-PW then the routing function is = performed by the human operator and the human operator collects the = reachability information by analysing the network topology information. = If OSS systems are used then the OSS system must perform the routing = function and discover the topology of the network by requesting or = collecting reachability/switching node capability information. If = dynamic routing protocols are used to perform the routing function then = reachability/switching node capability information must be = distributed/collected by PEs and PW switching nodes via the routing = protocol. As provisioning by a human operator obviously doesn't scale, = provisioning for MH-PWs must be carried out either by OSS or dynamic = protocols, which means that the PEs and PW switching nodes must = advertise (or respond to requests for) reachability/switching node = capability information. Regarding PW end point identifiers for routing purposes, as things stand = today I think out of the two options below, routing based on PE IP = addresses (option a) is preferable to using AGI/AII combinations (option = b). The main reasons being: (1) From the PWE3 control draft: "The Attachment Identifier must be = unique in the context of the PE router in which the Forwarder resides. = The combination must be globally unique." So, even if = the AGI/AII are used, the PE IP addresses must be used as well anyway.=20 (2) Reachability information based on [AGI/AII/PE IP address] = destination identifiers would need to be advertised and stored in a = routing table (if a dynamic routing protocol is used) on each PE and PW = switching node. This does not seem desirable looking at things from a = vendors perspective because the PW routing table implementation would = need to support variable/unknown length identifiers as destinations. Saying that, in theory, using AGI/AIIs would make sense because AGI/AIIs = belong to the PW layer and therefore routing would be based on = address/naming information pertinent only to the PW layer. The problem = is that the naming method used to identify a PW access point (forwarder) = is based on the PE IP address (which exists at the MPLS tunnel layer) = plus a locally unique AI (which exists at the PW layer). Having thought = about it, I think option (a) could be made to work if a globally unique = identifier (e.g. an IPv6 address) was used to identify a PW access = point. The AGI could still be used to identify a PW VPN, but the AII = would uniquely identify a PW access point (on a global PW layer network = basis). This would solve problem (1) because the AII would be globally = unique and therefore the PE IP addresses (belonging to the MPLS tunnel = layer) would not be required, and problem (2) would be solved because = the destination would be a fixed length IPv6 address. The idea of using = IPv6 addresses for identifying forwarders could be taken a step further = by making a forwarder a manageable logical entity, i.e. a logical PW = interface that could be managed just like any other interface. This = would also be an advantage from an OAM perspective as the PW endpoint = identifiers would uniquely identify the PW layer source and sink access = points. Of course there is nothing stopping a provider using IPv6 addresses for = AIs (PW access points) today. The problem is that because using IPv6 = addresses for AIs is not mandatory, to fully support option (a) vendors = would still need to address problem (2) by implementing a PW routing = table that supports unknown/variable length destination identifiers, and = address problem (1) by at least having an option for using AGI/AII + PE = IP address identifiers, rather than just AIIs. Regards, Richard > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: 08 August 2004 03:15 > To: 'Mustapha Aissaoui'; Spencer,R,Richard,XGH5 R > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > l2vpn@ietf.org; pwe3@ietf.org > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching >=20 >=20 > Mustapha, >=20 > I am surprised by your insistence that PWs should not be routable.=20 >=20 > I understand that the proposals I made in this email exchange=20 > have pros and cons. Within the scope of the requirements=20 > (which we will document, as we discussed in San Diego), it is=20 > very well possible that the cons outweight the pros. Or vice=20 > versa. We will see. However, you seem to have decided already=20 > that routable PWs are forbidden under any circumstances.=20 >=20 > You write: "My point is that the PW dataplane forwarding=20 > decision should be local to a stitching node and not network wide." >=20 > I have no idea what you mean by that. The dataplane=20 > forwarding decision is always local. The stitching node=20 > receives a packet with PW Label A, swaps it with PW Label B=20 > and forwards it over the appropriate tunnel. >=20 > The issue is how the stitching node supports signaling. It=20 > receives a PW setup request (in the current model, an LDP=20 > label mapping message) and somehow has to determine what the=20 > next node on the Multi-hop Path is. In all likelyhood, that=20 > next hop will be derived from one or more identifiers that=20 > identify the end point of the MH-PW. >=20 > There are two options: >=20 > a) identify the end point by the IP address of the destination PE > b) identify the end point by a specific AGI/AII combination. >=20 > Since every node in the network already IP routing and=20 > already has (a prefix of) the PE's IP address in its routing=20 > table, it seems to me that a) is more straightforward than=20 > b). Not only that. Solution b) requires a topology discovery=20 > protocol based on AGIs and AIIs. >=20 > However, in your email, you also write that: > "... we do not want to have a separate addressing and routing=20 > for PWs in the current PWE3 architecture".=20 >=20 > I am not sure how to interpret this statement. It sounds as=20 > if you agree with me that a) is the better solution. However,=20 > you are arguing vehemently against my position. Therefore,=20 > the only thing I can imagine is that you believe that any=20 > form of automated MH-PW setup is undesirable and that Service=20 > Providers will be perfectly happy to manually provision MH-PWs. >=20 > You may be right, but let's wait for the requirements ... >=20 > Peter >=20 >=20 > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Wednesday, August 04, 2004 9:41 PM > > To: richard.spencer@bt.com > > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > >=20 > >=20 > > Richard, > > see below. > >=20 > > Regards, > > Mustapha. > > ----------- > > richard.spencer@bt.com wrote: > > >=20 > > > Mustapha, > > >=20 > > > > Richard and Dimitri, > > > > this issue is in my view one of the critical issues. I believe a > > > > workable solution should have the following characteristics: > > > > > > > > 1. State how stitching nodes are discovered. I do not agree with > > > > Peter that a stiching node is just another LSP switching=20 > > node. There > > > > are PW specific operations to be performed in the data,=20 > > control, and > > > > management (OAM) planes on a PW segment. > > >=20 > > > I agree that a PW stitching node is not just another (tunnel) LSP > > > switching node. The data plane behaviour (i.e. MPLS label=20 > > switching) may > > > be the same but the tunnel LSP control protocols needs to=20 > > be modified > > > (or separate control protocols/instances used) in order to support > > > single sided provisioning of switched PWs.=20 > >=20 > > MA> Add to that OAM on the PW segment. > >=20 > > > I think discovery can be > > > split up into two aspects, i) discovery of ingress/egress=20 > > PEs, and ii) > > > discovery of PW switching nodes. > > > Regarding i) this is required to support single sided=20 > provisioning. > >=20 > > MA> I think single sided signaling is a separate issue. You can > > still configure the AC and PW information at both PEs but have one > > side trigger the PW setup (master PE) and the other reply only when > > it receives it (slave PW). This is the dominant mode of operation of > > SPVCs in ATM networks today. > >=20 > > > Regarding ii), this is only required if routers use the=20 > same address > > > space (i.e. same loopback addresses) at the PW layer that=20 > > they use at > > > the MPLS tunnel layer. If a different address space was used then > > > support for PW switching would be explicit. The consequence=20 > > of using the > > > same addresses is that PW switching capable nodes must be=20 > > distinguish > > > from non PW switching capable nodes explicitly using a discovery > > > mechanism or implicitly, e.g. using routing metrics as is=20 > > the case with > > > the FA-LSP solution. > >=20 > > MA> You are right. However, the reason for using the same address > > space is a direct consequence of the fact that PWs can only ride > > inside a tunnel of some sort.=20 > > =20 > > > > 2. State how routing of PW control messages are=20 > performed once the > > > > stitching nodes have been discovered. It seems to me that=20 > > a solution > > > > that mandates the use of FA-LSPs is too restrictive. > > >=20 > > > I agree that mandating FA-LSPs is too restrictive and that=20 > > a common PW > > > routing solution should be specified. > > >=20 > > > > 3. Avoid if possible making the PW label routable. Not=20 > that I have > > > > anything against that but if a solution turns PWs into routable > > > > entities on their own, then we should discuss it in that wider > > > > context. In that case, the use of tunnel LSPs becomes a=20 > > convenience > > > > as opposed to a requirement of the architecture. > > >=20 > > > I'm not sure I understand your last point; it appears to=20 > me to be a > > > contradiction. In 2 you state that routing of PW control=20 > > messages must > > > be addressed but then in 3 state that making PWs routable=20 > should be > > > avoided. I think there are two issues here, a) routing at=20 > > the PW layer > > > where LSPs tunnels are used (resulting in a two layer LSP=20 > > hierarchy), b) > > > routing where tunnel LSPs are not used (resulting in a single LSP > > > layer). > >=20 > > MA> I mean that we do not want to have a separate addressing and > > routing for PWs in the current PWE3 architecture. =20 > > I make the following argument: as long as PWs are confined inside > > tunnels, it does not make sense to make them routable (network wide) > > and have their own address space. > >=20 > > > Regarding a), in the control plane, routing is required at=20 > > the PW layer > > > to calculate/select the PW path from ingress PE to egress=20 > PE across > > > intermediate PW switching points and therefore the PE IP=20 > > addresses must > > > be routable. In the (PW) data plane the PW label needs to=20 > be used at > > > each hop to make a forwarding decision. However, even=20 > > though PWs need to > > > be routable at the PW level, they are not routable at the=20 > tunnel LSP > > > level, i.e. forwarding at the LSP tunnel level is based on=20 > > tunnel LSP > > > labels not PW labels, just like VP switching in ATM is=20 > > based on VPIs not > > > VCIs. > >=20 > > MA> You describe it very well. My point is that the PW dataplane > > forwarding decision should be local to a stitching node and not > > network wide. In other words, we do not want to advertize PW > > reachability. > > =20 > > > Regarding b), if tunnel LSPs are not used then PWs must still be > > > routable at the PW layer, but as this is the only layer=20 > > each hop must > > > belong to the PW layer, i.e. each hop must support PW=20 > switching. For > > > scaling reasons its highly unlikely that a single LSP=20 > layer would be > > > used in the core, but I think using a single LSP layer=20 > > would make sense > > > for spoke connections in the hierarchical LDP model. > >=20 > > MA> Correct. And this is where I think Peter and I disagree. I do > > not belive that we want to solve the general problem where any node > > can be used as a stitching node because this degenerates into the > > case where you will be forced to have a separate routing and > > addressing for the PWs. The case of the spoke connections is > > different. I assume that a static PW may be just fine if the access > > network is simple. In complex access and aggregation networks, one > > can have build a separate PSN for this network and perform switching > > at some well idnetified edge nodes. > > =20 > > > Regards, > > > Richard > >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Scaling hierarchical LDP/PW stitching Date: Mon, 09 Aug 2004 17:22:32 -0600 Organization: Cisco Systems Lines: 580 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, 'Mustapha Aissaoui' , dpapadimitriou@psg.com, richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Tue Aug 10 01:41:31 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: "Busschbach, Peter B (Peter)" In-Reply-To: X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Busschbach, Peter B (Peter) wrote: > >>Peter, >> >>I would like to make a distinction between autodiscovery , >>and PW switching. >>What you are proposing is an autodiscovery system that automatically >>provisions the PW switching point to switch an incoming PW into a >>specific outgoing one. I believe that there is a requirement for this >>functionality, but this is an L2VPN and PW autodiscovery discussion. >>I purposely kept away from this in the pw-switching draft, as >>provisioning of L2VPNs is not in scope here. >> >> > > >I agree that autodiscovery belongs in L2VPN and not in PWE3. However, the consequence of accepting draft-martini-pwe3-pw-switching-00.txt is that autodiscovery must be based on the LDP identifiers defined in the control draft (i.e. PWids, AGIs and AIIs). Is that the right approach? > > > Since we have accepted the control protocol draft we do not have much choice on what parameters identify a PW. This is already defined. >In fact, in the case of Multi-hop PWs, the autodiscovery mechanism used between PEs does not necessarily extend to PW Switching Nodes. PEs need to exchange information about Attachment > I see this from a different point of view. Current autodiscovery does not take into consideration pw-switching nodes , but I cannot see why we have to merge the auto provisioning of PW , and the signaling protocol ? >Circuits, but PW Switching Nodes only need to have enough knowledge to establish end-to-end PWs. Draft-martini-pwe3-pw-switching-00.txt does not allow one to make that distinction. It assumes that every node (both PEs and PW Switching Nodes) maintain AC-related information. > > > The pw-switching draft does not address autodiscovery, and it does not assume that PW switching point have to maintain AC-related information either ( excluding the static PW case ). The interface parameters are received , and relayed along in most cases unchanged. It is certain that in many interAS application the PW-switching point will have to enforce the local AS policy, but that should be a general dataplane policy similar to MTU, or source routing in the IP peering case. I envision the PW-switching point to be able to receive specific PW provisioning information via some autodiscovery protocol. Why is this not possible ? >In summary, I don't think we can define MH-PW setup without looking at the impact it has on autodiscovery. > > > I agree that we have to look at autodiscovery as well, but I do not see why we have to merge the autodiscovery with the maintenance and signaling protocol. Currently we have done well by having a PW maintenance and signaling protocol separate from autodiscovery. Also please keep in mind L2TPV3 as well ... This is not just an MPLS to MPLS case. Thanks. Luca > > >>( this does not mean it is >>not required by somebody ). >>Also keep in mind that today I only know about L2 peering points that >>are statically provisioned. Unlike L3 peering, I have not seen PNNI >>peering or Frame-Relay SPVC peering. >> >> > >I agree. On the other hand, there is telephony peering. > > > >>Luca >> >> >>Busschbach, Peter B (Peter) wrote: >> >> >> >>>Mustapha, >>> >>>I am surprised by your insistence that PWs should not be routable. >>> >>>I understand that the proposals I made in this email >>> >>> >>exchange have pros and cons. Within the scope of the >>requirements (which we will document, as we discussed in San >>Diego), it is very well possible that the cons outweight the >>pros. Or vice versa. We will see. However, you seem to have >>decided already that routable PWs are forbidden under any >>circumstances. >> >> >>>You write: "My point is that the PW dataplane forwarding >>> >>> >>decision should be local to a stitching node and not network wide." >> >> >>>I have no idea what you mean by that. The dataplane >>> >>> >>forwarding decision is always local. The stitching node >>receives a packet with PW Label A, swaps it with PW Label B >>and forwards it over the appropriate tunnel. >> >> >>>The issue is how the stitching node supports signaling. It >>> >>> >>receives a PW setup request (in the current model, an LDP >>label mapping message) and somehow has to determine what the >>next node on the Multi-hop Path is. In all likelyhood, that >>next hop will be derived from one or more identifiers that >>identify the end point of the MH-PW. >> >> >>>There are two options: >>> >>>a) identify the end point by the IP address of the destination PE >>>b) identify the end point by a specific AGI/AII combination. >>> >>>Since every node in the network already IP routing and >>> >>> >>already has (a prefix of) the PE's IP address in its routing >>table, it seems to me that a) is more straightforward than >>b). Not only that. Solution b) requires a topology discovery >>protocol based on AGIs and AIIs. >> >> >>>However, in your email, you also write that: >>>"... we do not want to have a separate addressing and >>> >>> >>routing for PWs in the current PWE3 architecture". >> >> >>>I am not sure how to interpret this statement. It sounds as >>> >>> >>if you agree with me that a) is the better solution. However, >>you are arguing vehemently against my position. Therefore, >>the only thing I can imagine is that you believe that any >>form of automated MH-PW setup is undesirable and that Service >>Providers will be perfectly happy to manually provision MH-PWs. >> >> >>>You may be right, but let's wait for the requirements ... >>> >>>Peter >>> >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] >>>>Sent: Wednesday, August 04, 2004 9:41 PM >>>>To: richard.spencer@bt.com >>>>Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; >>>>busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org >>>>Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching >>>> >>>> >>>>Richard, >>>>see below. >>>> >>>>Regards, >>>>Mustapha. >>>>----------- >>>>richard.spencer@bt.com wrote: >>>> >>>> >>>> >>>> >>>>>Mustapha, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Richard and Dimitri, >>>>>>this issue is in my view one of the critical issues. I believe a >>>>>>workable solution should have the following characteristics: >>>>>> >>>>>>1. State how stitching nodes are discovered. I do not agree with >>>>>>Peter that a stiching node is just another LSP switching >>>>>> >>>>>> >>>>>> >>>>>> >>>>node. There >>>> >>>> >>>> >>>> >>>>>>are PW specific operations to be performed in the data, >>>>>> >>>>>> >>>>>> >>>>>> >>>>control, and >>>> >>>> >>>> >>>> >>>>>>management (OAM) planes on a PW segment. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I agree that a PW stitching node is not just another (tunnel) LSP >>>>>switching node. The data plane behaviour (i.e. MPLS label >>>>> >>>>> >>>>> >>>>> >>>>switching) may >>>> >>>> >>>> >>>> >>>>>be the same but the tunnel LSP control protocols needs to >>>>> >>>>> >>>>> >>>>> >>>>be modified >>>> >>>> >>>> >>>> >>>>>(or separate control protocols/instances used) in order to support >>>>>single sided provisioning of switched PWs. >>>>> >>>>> >>>>> >>>>> >>>>MA> Add to that OAM on the PW segment. >>>> >>>> >>>> >>>> >>>> >>>>>I think discovery can be >>>>>split up into two aspects, i) discovery of ingress/egress >>>>> >>>>> >>>>> >>>>> >>>>PEs, and ii) >>>> >>>> >>>> >>>> >>>>>discovery of PW switching nodes. >>>>>Regarding i) this is required to support single sided provisioning. >>>>> >>>>> >>>>> >>>>> >>>>MA> I think single sided signaling is a separate issue. You can >>>>still configure the AC and PW information at both PEs but have one >>>>side trigger the PW setup (master PE) and the other reply only when >>>>it receives it (slave PW). This is the dominant mode of operation of >>>>SPVCs in ATM networks today. >>>> >>>> >>>> >>>> >>>> >>>>>Regarding ii), this is only required if routers use the >>>>> >>>>> >>same address >> >> >>>>>space (i.e. same loopback addresses) at the PW layer that >>>>> >>>>> >>>>> >>>>> >>>>they use at >>>> >>>> >>>> >>>> >>>>>the MPLS tunnel layer. If a different address space was used then >>>>>support for PW switching would be explicit. The consequence >>>>> >>>>> >>>>> >>>>> >>>>of using the >>>> >>>> >>>> >>>> >>>>>same addresses is that PW switching capable nodes must be >>>>> >>>>> >>>>> >>>>> >>>>distinguish >>>> >>>> >>>>>from non PW switching capable nodes explicitly using a discovery >>>> >>>> >>>>>mechanism or implicitly, e.g. using routing metrics as is >>>>> >>>>> >>>>> >>>>> >>>>the case with >>>> >>>> >>>> >>>> >>>>>the FA-LSP solution. >>>>> >>>>> >>>>> >>>>> >>>>MA> You are right. However, the reason for using the same address >>>>space is a direct consequence of the fact that PWs can only ride >>>>inside a tunnel of some sort. >>>> >>>> >>>> >>>> >>>> >>>>>>2. State how routing of PW control messages are performed once the >>>>>>stitching nodes have been discovered. It seems to me that >>>>>> >>>>>> >>>>>> >>>>>> >>>>a solution >>>> >>>> >>>> >>>> >>>>>>that mandates the use of FA-LSPs is too restrictive. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I agree that mandating FA-LSPs is too restrictive and that >>>>> >>>>> >>>>> >>>>> >>>>a common PW >>>> >>>> >>>> >>>> >>>>>routing solution should be specified. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>3. Avoid if possible making the PW label routable. Not that I have >>>>>>anything against that but if a solution turns PWs into routable >>>>>>entities on their own, then we should discuss it in that wider >>>>>>context. In that case, the use of tunnel LSPs becomes a >>>>>> >>>>>> >>>>>> >>>>>> >>>>convenience >>>> >>>> >>>> >>>> >>>>>>as opposed to a requirement of the architecture. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I'm not sure I understand your last point; it appears to me to be a >>>>>contradiction. In 2 you state that routing of PW control >>>>> >>>>> >>>>> >>>>> >>>>messages must >>>> >>>> >>>> >>>> >>>>>be addressed but then in 3 state that making PWs routable should be >>>>>avoided. I think there are two issues here, a) routing at >>>>> >>>>> >>>>> >>>>> >>>>the PW layer >>>> >>>> >>>> >>>> >>>>>where LSPs tunnels are used (resulting in a two layer LSP >>>>> >>>>> >>>>> >>>>> >>>>hierarchy), b) >>>> >>>> >>>> >>>> >>>>>routing where tunnel LSPs are not used (resulting in a single LSP >>>>>layer). >>>>> >>>>> >>>>> >>>>> >>>>MA> I mean that we do not want to have a separate addressing and >>>>routing for PWs in the current PWE3 architecture. >>>>I make the following argument: as long as PWs are confined inside >>>>tunnels, it does not make sense to make them routable (network wide) >>>>and have their own address space. >>>> >>>> >>>> >>>> >>>> >>>>>Regarding a), in the control plane, routing is required at >>>>> >>>>> >>>>> >>>>> >>>>the PW layer >>>> >>>> >>>> >>>> >>>>>to calculate/select the PW path from ingress PE to egress PE across >>>>>intermediate PW switching points and therefore the PE IP >>>>> >>>>> >>>>> >>>>> >>>>addresses must >>>> >>>> >>>> >>>> >>>>>be routable. In the (PW) data plane the PW label needs to >>>>> >>>>> >>be used at >> >> >>>>>each hop to make a forwarding decision. However, even >>>>> >>>>> >>>>> >>>>> >>>>though PWs need to >>>> >>>> >>>> >>>> >>>>>be routable at the PW level, they are not routable at the >>>>> >>>>> >>tunnel LSP >> >> >>>>>level, i.e. forwarding at the LSP tunnel level is based on >>>>> >>>>> >>>>> >>>>> >>>>tunnel LSP >>>> >>>> >>>> >>>> >>>>>labels not PW labels, just like VP switching in ATM is >>>>> >>>>> >>>>> >>>>> >>>>based on VPIs not >>>> >>>> >>>> >>>> >>>>>VCIs. >>>>> >>>>> >>>>> >>>>> >>>>MA> You describe it very well. My point is that the PW dataplane >>>>forwarding decision should be local to a stitching node and not >>>>network wide. In other words, we do not want to advertize PW >>>>reachability. >>>> >>>> >>>> >>>> >>>> >>>>>Regarding b), if tunnel LSPs are not used then PWs must still be >>>>>routable at the PW layer, but as this is the only layer >>>>> >>>>> >>>>> >>>>> >>>>each hop must >>>> >>>> >>>> >>>> >>>>>belong to the PW layer, i.e. each hop must support PW >>>>> >>>>> >>switching. For >> >> >>>>>scaling reasons its highly unlikely that a single LSP >>>>> >>>>> >>layer would be >> >> >>>>>used in the core, but I think using a single LSP layer >>>>> >>>>> >>>>> >>>>> >>>>would make sense >>>> >>>> >>>> >>>> >>>>>for spoke connections in the hierarchical LDP model. >>>>> >>>>> >>>>> >>>>> >>>>MA> Correct. And this is where I think Peter and I disagree. I do >>>>not belive that we want to solve the general problem where any node >>>>can be used as a stitching node because this degenerates into the >>>>case where you will be forced to have a separate routing and >>>>addressing for the PWs. The case of the spoke connections is >>>>different. I assume that a static PW may be just fine if the access >>>>network is simple. In complex access and aggregation networks, one >>>>can have build a separate PSN for this network and perform switching >>>>at some well idnetified edge nodes. >>>> >>>> >>>> >>>> >>>> >>>>>Regards, >>>>>Richard >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: Requirements + Date: Tue, 10 Aug 2004 08:53:04 +0200 Lines: 130 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org, Chris Metz X-From: pwe3-bounces@ietf.org Tue Aug 10 08:03:01 2004 Return-path: To: "'Luca Martini'" , cagatay koc X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Cagatay, Luca and all, I agree that the present requirements document does not address fully thie issues associated with multi-hop PWs. I also agree that some issues should rather be addressed in the L2VPN WG, but I think that there is quite a sunstantial amount of work to be done in the PWE3. I am interested in participating in the requirements effort. 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: Luca Martini [mailto:lmartini@cisco.com] > Sent: Tuesday, August 10, 2004 12:30 AM > To: cagatay koc > Cc: pwe3@ietf.org; Chris Metz > Subject: Re: [PWE3] Requirements + > > > Cagatay, > > I believe that we should have a short draft to spell out the > requirements, but we should be careful to avoid any > autoprovisioning/autodiscovery requirements for PWE3. > A separate draft addressing autodiscovery requirements, for > PWs needs to > be submitted in L2VPN. > We also need a draft in L2VPN to expand the existing solution of BGP > autodiscovery, and Radius autodiscovery to include > intraAS/Interprovider > requirements. > > The requirement document I was talking about is : > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-requiremen > ts-08.txt > > In particular the section : > > 10 Inter-domain Issues > PWE is a matter between the PW end-points and is transparent to the > network devices between the PW end-points. Therefore, inter-domain > PWE is fundamentally similar to intra-domain PWE. As long as PW > end-points use the same PWE approach, they can communicate > effectively, regardless of whether they are in the same domain. > Security may become more important in the inter-domain > case and some > security measure such as end-point authentication MAY be applied. > QoS may become more difficult to deliver too, as one > service provider > has no control over another service provider's provisioning and > traffic management policy. To solve the inter-domain QoS problem, > service providers have to cooperate. Once they agree at a > contractual > level to provider high quality of service to certain traffic (e.g. > PWE traffic), the mechanisms defined in other working groups, e.g. > Diffserv WG, can be used. > > Inter-domain PSN tunnels are generally more difficult to > set up, tear > down and maintain than intra-domain ones. But that is an issue for > PSN tunneling protocols such as MPLS and L2TPv3 and is outside the > scope of PWE3. > > Obviously this is not adequate. I think we need to be careful > to focus a > requirement document in on this particular topic only. > > We can start working on the PWE3 requirement document if you want. > > Luca > > > > cagatay koc wrote: > > >WG, > >In the PWE3 session of the IETF meeting on last monday, > after I presented Du > >Ke's draft we had a discussion with Peter Busschbach and > Mark Townsley and > >it became clear that the > >'switching/stiching' solutions (functionality/location), are > a bit premature > >given the fact that a detailed requirement document is > missing which should > >also iron out terminology and other critical issues. It > would make sense to > >quickly put down a draft on intra-AS, inter-AS requirements > relevant to PW > >switching points, taking into account operator needs as well > >as requirements already implied in the existing documents. > These points are > >made several times here but it would make sense to form a group of > >volunteers to draft a common document. I also talked with > Luka Martini and > >he thinks there might be a requirement document (which I > could not find) and > >Nabil Bitar also agrees with this > >'soft concensus', obviously Neil from his mails agrees with > this assessment. > >Latest exchange between Mustafa and Peter also can be resolved with a > >requirement document. > >I am willing to work on this as long as we have a few other > volunteers (at > >least 1 from operator side). > >Best regards, > >Cagatay Buyukkoc > > > > > > > >_______________________________________________ > >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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Tue, 10 Aug 2004 07:15:18 +0100 Lines: 108 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Tue Aug 10 08:37:44 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Thread-Index: AcR+XwUKqzSS390uSGepebh7JDNTMQAP5Agg To: , , X-OriginalArrivalTime: 10 Aug 2004 06:15:19.0177 (UTC) FILETIME=[69203790:01C47EA1] X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter... > Stewart, >=20 > I agree that we need a WG document that defines how Control=20 > Words must be used. I do have concerns about the proposed=20 > solution, though: >=20 > 1) The document proposes a solution to the hypothetical=20 > situation in which a PW Control Word could be mistaken for an=20 > IP packet. However, as far as I can tell, all encapsulation=20 > drafts define a CW that starts with 0000. NH=3D> Yes, I have noticed that. I have also noted that: - adaptation between different client/server modal pairs is not identical either....so a common CW is not a good thing anyway. - the default client/server relationship must be layer independence....one consequence of which is client transparency. ....these obviously true requirements seem to fall on deaf ears though. >=20 > 2) The document introduces a Payload Type identifier. Why? In=20 > the past, Mustapha Aissaoui and Dave Allan submitted drafts=20 > that argued that there was a need for a Payload Type=20 > Identifier. However, I don't think we ever accepted the=20 > underlying rationale. E.g. Mustapha's point was that a PTI=20 > was required for Service Interworking, but recent work in=20 > Service Interworking in the MPLS Forum has resulted in=20 > solutions that don't require a PTI. >=20 > The general PWE architecture does not require a PTI. The PW=20 > Type is established as part of PW set up. Therefore, carrying=20 > a PW Type in the PTI only complicates matters. If the type=20 > established during PW setup is not the same as the type=20 > carried in the PTI, what should a PE do? NH=3D> I would but agree with you but for one point: ....the need to add OAM (which BTW must be inserted/extracted at the trail termination points of the LSP, not the PW) was drop-off in MPLS protocol design, and a PTI seems a good way to 'recover' from this design error. >=20 > 3) The only application that really needs a new CW is VCCV. NH=3D> Not IMO. VCCV seems an amalgam of several things. Having a = simple way to differentiate traffic and OAM payloads on the other hand is not mixed of purpose, and is the correct way to sort this issue. > Ironically, VCCV is not covered by the draft, as VCCV is not=20 > one of the PW Types mentioned in the IANA registry. If VCCV=20 > is indeed the only application that requires a new CW, would=20 > it not make more sense to use the MPLS Preferred CW with 0001=20 > instead of 0000, rather than introducing the PTI? NH=3D> The only thing that really matters here (I ignore fixing the = other problems of MPLS for now, but these too need addressing) is to differentiate traffic (whatever that might be) from OAM as the (MPLS) payload. This has nothing to do with PWs (at least regarding the view (which is not right IMO) of treating XoverMPLS =3D XoverIP).....the OAM needs to be at the LSP level and clinet agnostic. This is so obvious I find it very puzzling why there is so much reluctance to get it right. Folks......this is not hard to sort, but for some reason it is being made so. I really don't know why folks don't bite the bullet and propertly sort out MPLS and stop this silly charade that IP=3D=3DMPLS = and therefore we must have identical treatment (it isn't like that and this is kidding no one). This is especially true given MPLS (not PWs!) is important to most operators wrt to their convergence plans. Is this WG ever going to do the right thing I wonder? Regards, Neil >=20 >=20 > Peter =20 >=20 > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Monday, August 09, 2004 7:54 AM > > To: pwe3@ietf.org > > Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request > >=20 > >=20 > > The authors request that > >=20 > > http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe > > 3-cw-00.txt > >=20 > > be adopted as a WG item with its title changed to > >=20 > > PWE3 MPLS Control Word > >=20 > > - Stewart > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 08:32:52 +0100 Lines: 433 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Tue Aug 10 09:44:08 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR+YzPYyiXPoWO5Qku80IHBsYGXrwARhpMw To: , X-OriginalArrivalTime: 10 Aug 2004 07:32:53.0019 (UTC) FILETIME=[3F0826B0:01C47EAC] X-Scan-Signature: 94962611154c8404498b19f744990308 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, Of all the voices out there (and ignoring my colleagues in BT) yours is the closest I have heard to making any sense and realising what is going on here. =20 PW switching is creating a new layer network (though I am not convinced some folks understand that remark, even though Richard (Spencer) tried hard to explain it a while back). And if this WG continues to go here then *all* the functional components need specifying for this up-front....else we are very likely to see continued kludges. However, the base problem is that PWs are starting from a flawed assumption that MPLS =3D=3D IP. The real problem is therefore being masked. I can only speak for BT as an operator....we want to see MPLS sorted and we do not need/want a new PW layer network defined as its wrong and unnecessary. XoverMPLS is a client/server relationship for which additional requirements must be met. XoverIP (or XoverSDH say) is *not* the same problem even though some seem to think it is. And none of this is actually difficult/complex if its done right. Put bluntly.....a problem has been created (and is now growing) that simply should not exist, and because some folks are so far down a certain road it is my opinion that they cannot see what the real issues are any longer. Luca.....given you stated some 'requirements' in a recent mail, let me ask you the question I posed earlier....who do *you* think you are writing this stuff for now: - the public Internet?.....I really think not.....the Internet does not have legacy networks and does not need a convergence story - Alnets?....not from a convergence perspective as they probably don't have (any or significant) legacy networks either.....so maybe from a 'we want a slice of the L2 action' perspective, but I'd have to question the longer-term sanity of this even for them - enterprises?.....probably the closest fit in some cases - trad operators?....I really don't don't think so as-is, even though its these folks that most need the convergence story sorted (and its also what the opening lines of the proposed revised PWE3 charter seem to imply is the target audience). Regards, Neil > >=20 > > Peter, > >=20 > > I would like to make a distinction between autodiscovery , > > and PW switching. > > What you are proposing is an autodiscovery system that=20 > automatically=20 > > provisions the PW switching point to switch an incoming PW into a=20 > > specific outgoing one. I believe that there is a=20 > requirement for this=20 > > functionality, but this is an L2VPN and PW autodiscovery discussion. > > I purposely kept away from this in the pw-switching draft, as=20 > > provisioning of L2VPNs is not in scope here. >=20 >=20 > I agree that autodiscovery belongs in L2VPN and not in PWE3.=20 > However, the consequence of accepting=20 > draft-martini-pwe3-pw-switching-00.txt is that autodiscovery=20 > must be based on the LDP identifiers defined in the control=20 > draft (i.e. PWids, AGIs and AIIs). Is that the right approach? >=20 > In fact, in the case of Multi-hop PWs, the autodiscovery=20 > mechanism used between PEs does not necessarily extend to PW=20 > Switching Nodes. PEs need to exchange information about=20 > Attachment Circuits, but PW Switching Nodes only need to have=20 > enough knowledge to establish end-to-end PWs.=20 > Draft-martini-pwe3-pw-switching-00.txt does not allow one to=20 > make that distinction. It assumes that every node (both PEs=20 > and PW Switching Nodes) maintain AC-related information. >=20 > In summary, I don't think we can define MH-PW setup without=20 > looking at the impact it has on autodiscovery. >=20 >=20 > > ( this does not mean it is=20 > > not required by somebody ). > > Also keep in mind that today I only know about L2 peering=20 > points that=20 > > are statically provisioned. Unlike L3 peering, I have not seen PNNI=20 > > peering or Frame-Relay SPVC peering. >=20 > I agree. On the other hand, there is telephony peering.=20 >=20 > >=20 > > Luca > >=20 > >=20 > > Busschbach, Peter B (Peter) wrote: > >=20 > > >Mustapha, > > > > > >I am surprised by your insistence that PWs should not be routable.=20 > > > > > >I understand that the proposals I made in this email=20 > > exchange have pros and cons. Within the scope of the=20 > > requirements (which we will document, as we discussed in San=20 > > Diego), it is very well possible that the cons outweight the=20 > > pros. Or vice versa. We will see. However, you seem to have=20 > > decided already that routable PWs are forbidden under any=20 > > circumstances.=20 > > > > > >You write: "My point is that the PW dataplane forwarding=20 > > decision should be local to a stitching node and not network wide." > > > > > >I have no idea what you mean by that. The dataplane=20 > > forwarding decision is always local. The stitching node=20 > > receives a packet with PW Label A, swaps it with PW Label B=20 > > and forwards it over the appropriate tunnel. > > > > > >The issue is how the stitching node supports signaling. It=20 > > receives a PW setup request (in the current model, an LDP=20 > > label mapping message) and somehow has to determine what the=20 > > next node on the Multi-hop Path is. In all likelyhood, that=20 > > next hop will be derived from one or more identifiers that=20 > > identify the end point of the MH-PW. > > > > > >There are two options: > > > > > >a) identify the end point by the IP address of the destination PE > > >b) identify the end point by a specific AGI/AII combination. > > > > > >Since every node in the network already IP routing and=20 > > already has (a prefix of) the PE's IP address in its routing=20 > > table, it seems to me that a) is more straightforward than=20 > > b). Not only that. Solution b) requires a topology discovery=20 > > protocol based on AGIs and AIIs. > > > > > >However, in your email, you also write that: > > >"... we do not want to have a separate addressing and=20 > > routing for PWs in the current PWE3 architecture".=20 > > > > > >I am not sure how to interpret this statement. It sounds as=20 > > if you agree with me that a) is the better solution. However,=20 > > you are arguing vehemently against my position. Therefore,=20 > > the only thing I can imagine is that you believe that any=20 > > form of automated MH-PW setup is undesirable and that Service=20 > > Providers will be perfectly happy to manually provision MH-PWs. > > > > > >You may be right, but let's wait for the requirements ... > > > > > >Peter > > > > > > > > > =20 > > > > > >>-----Original Message----- > > >>From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > >>Sent: Wednesday, August 04, 2004 9:41 PM > > >>To: richard.spencer@bt.com > > >>Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > >>busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org > > >>Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > >> > > >> > > >>Richard, > > >>see below. > > >> > > >>Regards, > > >>Mustapha. > > >>----------- > > >>richard.spencer@bt.com wrote: > > >> =20 > > >> > > >>>Mustapha, > > >>> > > >>> =20 > > >>> > > >>>>Richard and Dimitri, > > >>>>this issue is in my view one of the critical issues. I believe a > > >>>>workable solution should have the following characteristics: > > >>>> > > >>>>1. State how stitching nodes are discovered. I do not agree with > > >>>>Peter that a stiching node is just another LSP switching=20 > > >>>> =20 > > >>>> > > >>node. There > > >> =20 > > >> > > >>>>are PW specific operations to be performed in the data,=20 > > >>>> =20 > > >>>> > > >>control, and > > >> =20 > > >> > > >>>>management (OAM) planes on a PW segment. > > >>>> =20 > > >>>> > > >>>I agree that a PW stitching node is not just another (tunnel) LSP > > >>>switching node. The data plane behaviour (i.e. MPLS label=20 > > >>> =20 > > >>> > > >>switching) may > > >> =20 > > >> > > >>>be the same but the tunnel LSP control protocols needs to=20 > > >>> =20 > > >>> > > >>be modified > > >> =20 > > >> > > >>>(or separate control protocols/instances used) in order=20 > to support > > >>>single sided provisioning of switched PWs.=20 > > >>> =20 > > >>> > > >>MA> Add to that OAM on the PW segment. > > >> > > >> =20 > > >> > > >>>I think discovery can be > > >>>split up into two aspects, i) discovery of ingress/egress=20 > > >>> =20 > > >>> > > >>PEs, and ii) > > >> =20 > > >> > > >>>discovery of PW switching nodes. > > >>>Regarding i) this is required to support single sided=20 > provisioning. > > >>> =20 > > >>> > > >>MA> I think single sided signaling is a separate issue. You can > > >>still configure the AC and PW information at both PEs but have one > > >>side trigger the PW setup (master PE) and the other reply=20 > only when > > >>it receives it (slave PW). This is the dominant mode of=20 > operation of > > >>SPVCs in ATM networks today. > > >> > > >> =20 > > >> > > >>>Regarding ii), this is only required if routers use the=20 > > same address > > >>>space (i.e. same loopback addresses) at the PW layer that=20 > > >>> =20 > > >>> > > >>they use at > > >> =20 > > >> > > >>>the MPLS tunnel layer. If a different address space was used then > > >>>support for PW switching would be explicit. The consequence=20 > > >>> =20 > > >>> > > >>of using the > > >> =20 > > >> > > >>>same addresses is that PW switching capable nodes must be=20 > > >>> =20 > > >>> > > >>distinguish > > >> =20 > > >> > > >>>from non PW switching capable nodes explicitly using a discovery > > >>>mechanism or implicitly, e.g. using routing metrics as is=20 > > >>> =20 > > >>> > > >>the case with > > >> =20 > > >> > > >>>the FA-LSP solution. > > >>> =20 > > >>> > > >>MA> You are right. However, the reason for using the same address > > >>space is a direct consequence of the fact that PWs can only ride > > >>inside a tunnel of some sort.=20 > > >>=20 > > >> =20 > > >> > > >>>>2. State how routing of PW control messages are=20 > performed once the > > >>>>stitching nodes have been discovered. It seems to me that=20 > > >>>> =20 > > >>>> > > >>a solution > > >> =20 > > >> > > >>>>that mandates the use of FA-LSPs is too restrictive. > > >>>> =20 > > >>>> > > >>>I agree that mandating FA-LSPs is too restrictive and that=20 > > >>> =20 > > >>> > > >>a common PW > > >> =20 > > >> > > >>>routing solution should be specified. > > >>> > > >>> =20 > > >>> > > >>>>3. Avoid if possible making the PW label routable. Not=20 > that I have > > >>>>anything against that but if a solution turns PWs into routable > > >>>>entities on their own, then we should discuss it in that wider > > >>>>context. In that case, the use of tunnel LSPs becomes a=20 > > >>>> =20 > > >>>> > > >>convenience > > >> =20 > > >> > > >>>>as opposed to a requirement of the architecture. > > >>>> =20 > > >>>> > > >>>I'm not sure I understand your last point; it appears to=20 > me to be a > > >>>contradiction. In 2 you state that routing of PW control=20 > > >>> =20 > > >>> > > >>messages must > > >> =20 > > >> > > >>>be addressed but then in 3 state that making PWs=20 > routable should be > > >>>avoided. I think there are two issues here, a) routing at=20 > > >>> =20 > > >>> > > >>the PW layer > > >> =20 > > >> > > >>>where LSPs tunnels are used (resulting in a two layer LSP=20 > > >>> =20 > > >>> > > >>hierarchy), b) > > >> =20 > > >> > > >>>routing where tunnel LSPs are not used (resulting in a single LSP > > >>>layer). > > >>> =20 > > >>> > > >>MA> I mean that we do not want to have a separate addressing and > > >>routing for PWs in the current PWE3 architecture. =20 > > >>I make the following argument: as long as PWs are confined inside > > >>tunnels, it does not make sense to make them routable=20 > (network wide) > > >>and have their own address space. > > >> > > >> =20 > > >> > > >>>Regarding a), in the control plane, routing is required at=20 > > >>> =20 > > >>> > > >>the PW layer > > >> =20 > > >> > > >>>to calculate/select the PW path from ingress PE to=20 > egress PE across > > >>>intermediate PW switching points and therefore the PE IP=20 > > >>> =20 > > >>> > > >>addresses must > > >> =20 > > >> > > >>>be routable. In the (PW) data plane the PW label needs to=20 > > be used at > > >>>each hop to make a forwarding decision. However, even=20 > > >>> =20 > > >>> > > >>though PWs need to > > >> =20 > > >> > > >>>be routable at the PW level, they are not routable at the=20 > > tunnel LSP > > >>>level, i.e. forwarding at the LSP tunnel level is based on=20 > > >>> =20 > > >>> > > >>tunnel LSP > > >> =20 > > >> > > >>>labels not PW labels, just like VP switching in ATM is=20 > > >>> =20 > > >>> > > >>based on VPIs not > > >> =20 > > >> > > >>>VCIs. > > >>> =20 > > >>> > > >>MA> You describe it very well. My point is that the PW dataplane > > >>forwarding decision should be local to a stitching node and not > > >>network wide. In other words, we do not want to advertize PW > > >>reachability. > > >>=20 > > >> =20 > > >> > > >>>Regarding b), if tunnel LSPs are not used then PWs must still be > > >>>routable at the PW layer, but as this is the only layer=20 > > >>> =20 > > >>> > > >>each hop must > > >> =20 > > >> > > >>>belong to the PW layer, i.e. each hop must support PW=20 > > switching. For > > >>>scaling reasons its highly unlikely that a single LSP=20 > > layer would be > > >>>used in the core, but I think using a single LSP layer=20 > > >>> =20 > > >>> > > >>would make sense > > >> =20 > > >> > > >>>for spoke connections in the hierarchical LDP model. > > >>> =20 > > >>> > > >>MA> Correct. And this is where I think Peter and I disagree. I do > > >>not belive that we want to solve the general problem=20 > where any node > > >>can be used as a stitching node because this degenerates into the > > >>case where you will be forced to have a separate routing and > > >>addressing for the PWs. The case of the spoke connections is > > >>different. I assume that a static PW may be just fine if=20 > the access > > >>network is simple. In complex access and aggregation networks, one > > >>can have build a separate PSN for this network and=20 > perform switching > > >>at some well idnetified edge nodes. > > >>=20 > > >> =20 > > >> > > >>>Regards, > > >>>Richard > > >>> =20 > > >>> > > > > > > > > > =20 > > > > >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 08:44:21 +0100 Lines: 32 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Tue Aug 10 09:58:46 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR+WX1APIDx6xylSwGV3DS9jnb/4AARsgVw To: , X-OriginalArrivalTime: 10 Aug 2004 07:44:22.0038 (UTC) FILETIME=[D9B81B60:01C47EAD] X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca, > Also keep in mind that today I only know about L2 peering points that=20 > are statically provisioned. Unlike L3 peering, I have not seen PNNI=20 > peering or Frame-Relay SPVC peering. I'm not sure what you mean by this. If you are suggesting that stitching = together PWs to make MH-PWs is akin to ATM/FR SPVC peering then I = disagree. At the PW layer, each MH-PW has a source, destination and one = or more switching points. Connectivity between these is provided by = multiple server layer partitions that appear to the PW client layer as 1 = hop p2p links. Therefore, a MH-PW can be described as being akin to a = single ATM or FR SPVC, not the peering of ATM/FR SPVCs. If you are specifically referring to the inter-provider/AS case, then I = still don't see the relevance. Are you suggesting that because providers = use static provisioning at peering points today for their existing = connection-orientated packet switching technologies (i.e. ATM/FR), that = they should continue to do the same for MPLS? I think the question comes = down to scaling, MPLS has been selected as the convergence technology by = many providers for all services (i.e. voice, broadband, mobile, leased = line, etc.) and therefore must be highly scalable. Due to the number of = different services that MPLS will need to support and the (global) = coverage that will be expected, the inter-provider/AS peering = requirements are likely to be very different for MPLS than for ATM/FR = today. Static provisioning may be used for MPLS inter-provider/AS = peering in the short term, but one would expect that a secure, scalable, = dynamic solution would need to be developed in the long term if MPLS is = to succeed as the global convergence technology of the future. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 08:51:43 +0100 Lines: 358 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 10 10:07:03 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR87aVgz3Xupa/USsSM+7PDGUp+hQA8jsAwADM4hTA= To: , , X-OriginalArrivalTime: 10 Aug 2004 07:51:44.0023 (UTC) FILETIME=[E129AA70:01C47EAE] X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thanks Richard, and of course I generally agree with you....but some small remarks below. > Peter, >=20 > I agree with all the comments you make below. >=20 > Regarding the distribution of PW layer reachability=20 > information for MH-PWs, I would argue that this information=20 > must always be distributed (or collected) whether manual or=20 > dynamic provisioning methods are used. To set up a path=20 > across multiple hops where alternative paths exist, routing=20 > must be performed, there is no getting away from this. If a=20 > human operator manually configures a MH-PW then the routing=20 > function is performed by the human operator and the human=20 > operator collects the reachability information by analysing=20 > the network topology information. If OSS systems are used=20 > then the OSS system must perform the routing function and=20 > discover the topology of the network by requesting or=20 > collecting reachability/switching node capability=20 > information. If dynamic routing protocols are used to perform=20 > the routing function then reachability/switching node=20 > capability information must be distributed/collected by PEs=20 > and PW switching nodes via the routing protocol. As=20 > provisioning by a human operator obviously doesn't scale,=20 > provisioning for MH-PWs must be carried out either by OSS or=20 > dynamic protocols, which means that the PEs and PW switching=20 > nodes must advertise (or respond to requests for)=20 > reachability/switching node capability information. >=20 > Regarding PW end point identifiers for routing purposes, as=20 > things stand today I think out of the two options below,=20 > routing based on PE IP addresses (option a) is preferable to=20 > using AGI/AII combinations (option b). The main reasons being: >=20 > (1) From the PWE3 control draft: "The Attachment Identifier=20 > must be unique in the context of the PE router in which the=20 > Forwarder resides. The combination must be=20 > globally unique." So, even if the AGI/AII are used, the PE IP=20 > addresses must be used as well anyway.=20 >=20 > (2) Reachability information based on [AGI/AII/PE IP address]=20 > destination identifiers would need to be advertised and=20 > stored in a routing table (if a dynamic routing protocol is=20 > used) on each PE and PW switching node. This does not seem=20 > desirable looking at things from a vendors perspective=20 > because the PW routing table implementation would need to=20 > support variable/unknown length identifiers as destinations. NH=3D> OK, but the really important point to get from any of this is = that we need PW addressing. This is not IP layer network addressing. This is not MPLS layer network addressing (this also needs sorting BTW). I wonder if folks really grasp this point? I sometimes think now. But a plea.....the addressing of a layer network is one of its most important functional attributes. You should think very carefully before defining an addressing structure. If you screw this up at t=3D0 its almost impossible to change (easily anyway) later. For example, IPv6 is not IPv4 'with some enhancements' its a completely different layer network. A VC4 layer network in SDH does *not* have the same addressing space as the SDH VC12 layer network. It does not matter that addressing structures might look similar, they reside is a completely different space. And when/if folks finally realise we need an OOB control/management plane for MPLS then they will also have to come to terms with the fact that the addressing of the traffic and control/management plane networks also reside in disjoint spaces. Security is very important....why on earth would one make the internal/sensitive control/management protocols a target for hacking when there is no need to? Go learn from the GMPLS folks what they had to do here for SDH and OTNs. >=20 > Saying that, in theory, using AGI/AIIs would make sense=20 > because AGI/AIIs belong to the PW layer and therefore routing=20 > would be based on address/naming information pertinent only=20 > to the PW layer. NH=3D> Bang on.....but is this a *good* addressing structure? > The problem is that the naming method used=20 > to identify a PW access point (forwarder) is based on the PE=20 > IP address (which exists at the MPLS tunnel layer) plus a=20 > locally unique AI (which exists at the PW layer). Having=20 > thought about it, I think option (a) could be made to work if=20 > a globally unique identifier (e.g. an IPv6 address) was used=20 > to identify a PW access point. NH=3D> What a novel idea, ie use a good structure up-front.....not = saying PWs is the right place to do this of course, but I can think of a network layer that could make good use of this right now ;-) Regards, Neil > The AGI could still be used to=20 > identify a PW VPN, but the AII would uniquely identify a PW=20 > access point (on a global PW layer network basis). This would=20 > solve problem (1) because the AII would be globally unique=20 > and therefore the PE IP addresses (belonging to the MPLS=20 > tunnel layer) would not be required, and problem (2) would be=20 > solved because the destination would be a fixed length IPv6=20 > address. The idea of using IPv6 addresses for identifying=20 > forwarders could be taken a step further by making a=20 > forwarder a manageable logical entity, i.e. a logical PW=20 > interface that could be managed just like any other=20 > interface. This would also be an advantage from an OAM=20 > perspective as the PW endpoint identifiers would uniquely=20 > identify the PW layer source and sink access points. >=20 > Of course there is nothing stopping a provider using IPv6=20 > addresses for AIs (PW access points) today. The problem is=20 > that because using IPv6 addresses for AIs is not mandatory,=20 > to fully support option (a) vendors would still need to=20 > address problem (2) by implementing a PW routing table that=20 > supports unknown/variable length destination identifiers, and=20 > address problem (1) by at least having an option for using=20 > AGI/AII + PE IP address identifiers, rather than just AIIs. >=20 > Regards, > Richard >=20 > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: 08 August 2004 03:15 > > To: 'Mustapha Aissaoui'; Spencer,R,Richard,XGH5 R > > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be;=20 > > l2vpn@ietf.org; pwe3@ietf.org > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > >=20 > >=20 > > Mustapha, > >=20 > > I am surprised by your insistence that PWs should not be routable. > >=20 > > I understand that the proposals I made in this email exchange > > have pros and cons. Within the scope of the requirements=20 > > (which we will document, as we discussed in San Diego), it is=20 > > very well possible that the cons outweight the pros. Or vice=20 > > versa. We will see. However, you seem to have decided already=20 > > that routable PWs are forbidden under any circumstances.=20 > >=20 > > You write: "My point is that the PW dataplane forwarding > > decision should be local to a stitching node and not network wide." > >=20 > > I have no idea what you mean by that. The dataplane > > forwarding decision is always local. The stitching node=20 > > receives a packet with PW Label A, swaps it with PW Label B=20 > > and forwards it over the appropriate tunnel. > >=20 > > The issue is how the stitching node supports signaling. It > > receives a PW setup request (in the current model, an LDP=20 > > label mapping message) and somehow has to determine what the=20 > > next node on the Multi-hop Path is. In all likelyhood, that=20 > > next hop will be derived from one or more identifiers that=20 > > identify the end point of the MH-PW. > >=20 > > There are two options: > >=20 > > a) identify the end point by the IP address of the destination PE > > b) identify the end point by a specific AGI/AII combination. > >=20 > > Since every node in the network already IP routing and > > already has (a prefix of) the PE's IP address in its routing=20 > > table, it seems to me that a) is more straightforward than=20 > > b). Not only that. Solution b) requires a topology discovery=20 > > protocol based on AGIs and AIIs. > >=20 > > However, in your email, you also write that: > > "... we do not want to have a separate addressing and routing > > for PWs in the current PWE3 architecture".=20 > >=20 > > I am not sure how to interpret this statement. It sounds as > > if you agree with me that a) is the better solution. However,=20 > > you are arguing vehemently against my position. Therefore,=20 > > the only thing I can imagine is that you believe that any=20 > > form of automated MH-PW setup is undesirable and that Service=20 > > Providers will be perfectly happy to manually provision MH-PWs. > >=20 > > You may be right, but let's wait for the requirements ... > >=20 > > Peter > >=20 > >=20 > > > -----Original Message----- > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > Sent: Wednesday, August 04, 2004 9:41 PM > > > To: richard.spencer@bt.com > > > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be;=20 > > > busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > >=20 > > >=20 > > > Richard, > > > see below. > > >=20 > > > Regards, > > > Mustapha. > > > ----------- > > > richard.spencer@bt.com wrote: > > > >=20 > > > > Mustapha, > > > >=20 > > > > > Richard and Dimitri, > > > > > this issue is in my view one of the critical issues.=20 > I believe a=20 > > > > > workable solution should have the following characteristics: > > > > > > > > > > 1. State how stitching nodes are discovered. I do not=20 > agree with=20 > > > > > Peter that a stiching node is just another LSP switching > > > node. There > > > > > are PW specific operations to be performed in the data, > > > control, and > > > > > management (OAM) planes on a PW segment. > > > >=20 > > > > I agree that a PW stitching node is not just another=20 > (tunnel) LSP=20 > > > > switching node. The data plane behaviour (i.e. MPLS label > > > switching) may > > > > be the same but the tunnel LSP control protocols needs to > > > be modified > > > > (or separate control protocols/instances used) in order=20 > to support=20 > > > > single sided provisioning of switched PWs. > > >=20 > > > MA> Add to that OAM on the PW segment. > > >=20 > > > > I think discovery can be > > > > split up into two aspects, i) discovery of ingress/egress > > > PEs, and ii) > > > > discovery of PW switching nodes. > > > > Regarding i) this is required to support single sided > > provisioning. > > >=20 > > > MA> I think single sided signaling is a separate issue. You can > > > still configure the AC and PW information at both PEs but=20 > have one=20 > > > side trigger the PW setup (master PE) and the other reply=20 > only when=20 > > > it receives it (slave PW). This is the dominant mode of=20 > operation of=20 > > > SPVCs in ATM networks today. > > >=20 > > > > Regarding ii), this is only required if routers use the > > same address > > > > space (i.e. same loopback addresses) at the PW layer that > > > they use at > > > > the MPLS tunnel layer. If a different address space was=20 > used then=20 > > > > support for PW switching would be explicit. The consequence > > > of using the > > > > same addresses is that PW switching capable nodes must be > > > distinguish > > > > from non PW switching capable nodes explicitly using a=20 > discovery=20 > > > > mechanism or implicitly, e.g. using routing metrics as is > > > the case with > > > > the FA-LSP solution. > > >=20 > > > MA> You are right. However, the reason for using the same address > > > space is a direct consequence of the fact that PWs can only ride=20 > > > inside a tunnel of some sort. > > > =20 > > > > > 2. State how routing of PW control messages are > > performed once the > > > > > stitching nodes have been discovered. It seems to me that > > > a solution > > > > > that mandates the use of FA-LSPs is too restrictive. > > > >=20 > > > > I agree that mandating FA-LSPs is too restrictive and that > > > a common PW > > > > routing solution should be specified. > > > >=20 > > > > > 3. Avoid if possible making the PW label routable. Not > > that I have > > > > > anything against that but if a solution turns PWs=20 > into routable=20 > > > > > entities on their own, then we should discuss it in=20 > that wider=20 > > > > > context. In that case, the use of tunnel LSPs becomes a > > > convenience > > > > > as opposed to a requirement of the architecture. > > > >=20 > > > > I'm not sure I understand your last point; it appears to > > me to be a > > > > contradiction. In 2 you state that routing of PW control > > > messages must > > > > be addressed but then in 3 state that making PWs routable > > should be > > > > avoided. I think there are two issues here, a) routing at > > > the PW layer > > > > where LSPs tunnels are used (resulting in a two layer LSP > > > hierarchy), b) > > > > routing where tunnel LSPs are not used (resulting in a=20 > single LSP=20 > > > > layer). > > >=20 > > > MA> I mean that we do not want to have a separate addressing and > > > routing for PWs in the current PWE3 architecture. > > > I make the following argument: as long as PWs are confined inside > > > tunnels, it does not make sense to make them routable=20 > (network wide) > > > and have their own address space. > > >=20 > > > > Regarding a), in the control plane, routing is required at > > > the PW layer > > > > to calculate/select the PW path from ingress PE to egress > > PE across > > > > intermediate PW switching points and therefore the PE IP > > > addresses must > > > > be routable. In the (PW) data plane the PW label needs to > > be used at > > > > each hop to make a forwarding decision. However, even > > > though PWs need to > > > > be routable at the PW level, they are not routable at the > > tunnel LSP > > > > level, i.e. forwarding at the LSP tunnel level is based on > > > tunnel LSP > > > > labels not PW labels, just like VP switching in ATM is > > > based on VPIs not > > > > VCIs. > > >=20 > > > MA> You describe it very well. My point is that the PW dataplane > > > forwarding decision should be local to a stitching node and not=20 > > > network wide. In other words, we do not want to advertize PW=20 > > > reachability. > > > =20 > > > > Regarding b), if tunnel LSPs are not used then PWs must=20 > still be=20 > > > > routable at the PW layer, but as this is the only layer > > > each hop must > > > > belong to the PW layer, i.e. each hop must support PW > > switching. For > > > > scaling reasons its highly unlikely that a single LSP > > layer would be > > > > used in the core, but I think using a single LSP layer > > > would make sense > > > > for spoke connections in the hierarchical LDP model. > > >=20 > > > MA> Correct. And this is where I think Peter and I disagree. I do > > > not belive that we want to solve the general problem=20 > where any node=20 > > > can be used as a stitching node because this degenerates into the=20 > > > case where you will be forced to have a separate routing and=20 > > > addressing for the PWs. The case of the spoke connections is=20 > > > different. I assume that a static PW may be just fine if=20 > the access=20 > > > network is simple. In complex access and aggregation=20 > networks, one=20 > > > can have build a separate PSN for this network and=20 > perform switching=20 > > > at some well idnetified edge nodes. > > > =20 > > > > Regards, > > > > Richard > > >=20 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Rahul Aggarwal Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 01:23:57 -0700 (PDT) Lines: 50 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: pwe3-bounces@ietf.org Tue Aug 10 10:27:41 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: hbrahim@nortelnetworks.com, "" , "" X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Hamid, > Peter, > [clipped...] > > > > In yesterday's WG meeting we decided that we need to > > establish the requirements for PW switching first, before we > > discuss solutions. Based on the requirements it is well > > possible that we end up doing 1). However, in the long rung, > > 2) might be more useful as it could apply to other problems > > than PWE as well. > > > In addition to requirements I think in light of this > discussion and proposed solution drafts we need to clarify > maybe as new sections to existing framework draft the > following: > a) The terminology: PW switching/stitching/multihop PW, > PW switching points and PW demultiplexor > allocation points (suggest stick with one or two terms). draft-raggarwa-rsvpte-pw-00.txt propopses definitions for some of the above. Once the WG settles on the terminology, we should certainly include it in a single document. > > b) Deployment scenarios of multihop/switching in terms of > > - an inter-as/domain > > - single/inter-providers > > - a PW-enabled access network to an PW-MPLS core network > > - A PW "private" segment stitched to another "provider-based" > > PW (not sure this is needed?). > > c) switching point determination (dynamic -routing, pre-configured) > > d) mp-pw path determination (implicit/explicit -ERO). > > e) switching node being PW aware or not > > f) end-to-end MP-PW signaling versus no end-to-end signaling > > (just switching per config). > >etc... The above should probably be captured in a PW-Requirements2 document. I would add the following to the list: - PW QoS - PW Redundancy rahul From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Rahul Aggarwal Subject: Re: Requirements + Date: Tue, 10 Aug 2004 01:37:01 -0700 (PDT) Lines: 55 Sender: pwe3-bounces@ietf.org References: <200408090245.WAA10749@ietf.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 10 10:48:43 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: cagatay koc In-Reply-To: <200408090245.WAA10749@ietf.org> X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Cagatay, On Mon, 9 Aug 2004, cagatay koc wrote: > > WG, > In the PWE3 session of the IETF meeting on last monday, after I presented Du > Ke's draft we had a discussion with Peter Busschbach and Mark Townsley and > it became clear that the > 'switching/stiching' solutions (functionality/location), are a bit premature > given the fact that a detailed requirement document is missing which should > also iron out terminology and other critical issues. Agreed. > It would make sense to > quickly put down a draft on intra-AS, inter-AS requirements relevant to PW > switching points, taking into account operator needs as well > as requirements already implied in the existing documents. This requirements effort should be viewed as the next set of requirements to evolve MPLS PWs, being driven by the natural curve of technology evolution. It should not be viewed as a narrow effort focussing on PW stitching. More specifically the following issues should also be part of this effort: - Multi-hop PW traffic engineering - PW QoS - PW Redundancy draft-raggarwa-rsvpte-pw-00.txt has a discussion on some of this. Auto-discovery/routing issues should also be part of this (beaten to death in another thread). If it so happens that some of these requirements need to be handed off to another group (l2vpn for example) that is fine. But let us start with the big picture in mind. > I am willing to work on this as long as we have a few other volunteers (at > least 1 from operator side). I would be open to participating. Thanks, rahul > Best regards, > Cagatay Buyukkoc > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 09:59:11 +0100 Lines: 38 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Tue Aug 10 11:08:27 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR+Z9+aoAHoWQI/QuCavCfQ7G8i1wAP8IBQ To: , X-OriginalArrivalTime: 10 Aug 2004 08:59:12.0430 (UTC) FILETIME=[4E338CE0:01C47EB8] X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca, > Since we have accepted the control protocol draft we do not have much=20 > choice on what parameters identify a PW. > This is already defined. I disagree, this implies that the WG does not have the power to change = or make amendments to decisions that have already been made. If WG = consensus was reached that the parameters currently defined for = identifying PWs were not suitable for MH-PWs, then there is no reason = why alternative parameters couldn't be added (at least as optional) in = separate/revised drafts. Especially considering the draft(s) in question = are not even RFCs yet. > I see this from a different point of view. Current autodiscovery does=20 > not take into consideration pw-switching nodes , but I cannot=20 > see why we=20 > have to merge the auto provisioning of PW , and the signaling=20 > protocol ? I don't think Peter is suggesting that auto-provisioning and signalling = should be merged or described in the same document. I think he is just = pointing out that if auto-discovery was to be based on PW endpoint = identifiers, because of the way PW end/mid points (or access points) are = currently identified, autodiscovery would be dependant on the signalling = mechanism used. For example, PW end points established using FEC 128 are = identified by the PWid+PE IP address, whereas PW end points established = using FEC 129 are identified by the AGI/AII+PE IP address, i.e. endpoint = identification is dependent on the signalling mechanism used. If PWs = were identified using the same identifier regardless of the signalling = protocol used, then in turn auto-discovery would not be dependent on the = signalling protocol used. A further improvement would be to use a unique = identifier that is only pertinent to the PW layer, e.g. an IPv6 address, = which would be a significant advantage from a management and OAM = perspective. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Requirements + Date: Tue, 10 Aug 2004 10:15:10 +0100 Lines: 108 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 10 11:19:56 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Requirements + Thread-Index: AcR+txDIQabIfdtFRbelKLDcYgkA0QAANdCw To: , X-OriginalArrivalTime: 10 Aug 2004 09:15:11.0565 (UTC) FILETIME=[89E3EFD0:01C47EBA] X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Rahul.... > >=20 > Hi Cagatay, >=20 > On Mon, 9 Aug 2004, cagatay koc wrote: >=20 > > > > WG, > > In the PWE3 session of the IETF meeting on last monday, after I=20 > > presented Du Ke's draft we had a discussion with Peter=20 > Busschbach and=20 > > Mark Townsley and it became clear that the 'switching/stiching'=20 > > solutions (functionality/location), are a bit premature=20 > given the fact=20 > > that a detailed requirement document is missing which=20 > should also iron=20 > > out terminology and other critical issues. >=20 > Agreed. >=20 > > It would make sense to > > quickly put down a draft on intra-AS, inter-AS requirements=20 > relevant=20 > > to PW switching points, taking into account operator needs=20 > as well as=20 > > requirements already implied in the existing documents. >=20 > This requirements effort should be viewed as the next set of=20 > requirements to evolve MPLS PWs, being driven by the natural=20 > curve of technology evolution. NH=3D> I think agree with what you are hinting at here....and I note you also seem to differentiate 'MPLS PWs' from 'IP PWs' (explicit or subconscious?). And when you realise this, the key objective to make sure MPLS is properly specified both per se and wrt to a client/server relationship. > It should not be viewed as a=20 > narrow effort focussing on PW stitching. NH=3D> Absolutely.....this is creating a new layer network which is unnecessary and is not addressing the real requirements of operators like BT. > More specifically=20 > the following issues should also be part of this effort: > - Multi-hop PW traffic engineering > - PW QoS NH=3D> Careful.....QoS tends to crop-up as a throw-way line all the = time. There is a specific ordering: Valid mode arch=3D>Defects=3D>(un)availability=3D>PM. Qos is not an objective = metric, it is subjective and varies from application to application for a fixed level of network performance impairment. > - PW Redundancy NH=3D> If you change 'PW' to 'MPLS' in the above bullets I am with you. Also need to add: - consistent access point IDs of LSPs - OOB control/management to provide increased security and stability (of these key protocols).....note that the GMPLS folks had to make RSVP-TE work with an OOB control network, so folks have already been here with this signalling protocol - the right in-band OAM that can do the ordering noted above, and with activation/deactivation that is tightly coupled with (signalling) LSP set-up/tear-down. Do this and we would have a solution that would be very good. >=20 > draft-raggarwa-rsvpte-pw-00.txt has a discussion on some of this. NH=3D> I'd like RSVP-TE for sure to be considered. Not sure how close = you are to what I am driving at above...I'll go look. >=20 > Auto-discovery/routing issues should also be part of this=20 > (beaten to death in another thread). If it so happens that=20 > some of these requirements need to be handed off to another=20 > group (l2vpn for example) that is fine. But let us start with=20 > the big picture in mind. >=20 > > I am willing to work on this as long as we have a few other=20 > volunteers=20 > > (at least 1 from operator side). NH=3D> We for sure would want some input on this. But IMO its operators who should largely set the requirements here. >=20 > I would be open to participating. >=20 > Thanks, > rahul >=20 > > Best regards, > > Cagatay Buyukkoc > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 10:27:25 +0100 Lines: 62 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Tue Aug 10 11:29:39 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR+Z9+aoAHoWQI/QuCavCfQ7G8i1wAP8IBQAAUB98A= To: , , X-OriginalArrivalTime: 10 Aug 2004 09:27:26.0598 (UTC) FILETIME=[40011260:01C47EBC] X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard....spot on....1 additional remark where I want to reinforce something important. > Luca, >=20 > > Since we have accepted the control protocol draft we do not=20 > have much > > choice on what parameters identify a PW. > > This is already defined. >=20 > I disagree, this implies that the WG does not have the power=20 > to change or make amendments to decisions that have already=20 > been made. If WG consensus was reached that the parameters=20 > currently defined for identifying PWs were not suitable for=20 > MH-PWs, then there is no reason why alternative parameters=20 > couldn't be added (at least as optional) in separate/revised=20 > drafts. Especially considering the draft(s) in question are=20 > not even RFCs yet. >=20 > > I see this from a different point of view. Current=20 > autodiscovery does > > not take into consideration pw-switching nodes , but I cannot=20 > > see why we=20 > > have to merge the auto provisioning of PW , and the signaling=20 > > protocol ? >=20 > I don't think Peter is suggesting that auto-provisioning and=20 > signalling should be merged or described in the same=20 > document. I think he is just pointing out that if=20 > auto-discovery was to be based on PW endpoint identifiers,=20 > because of the way PW end/mid points (or access points) are=20 > currently identified, autodiscovery would be dependant on the=20 > signalling mechanism used. For example, PW end points=20 > established using FEC 128 are identified by the PWid+PE IP=20 > address, whereas PW end points established using FEC 129 are=20 > identified by the AGI/AII+PE IP address, i.e. endpoint=20 > identification is dependent on the signalling mechanism used.=20 NH=3D> And this is one thing that is clearly wrong....and its happened before with MPLS. An address is an attribute of an access point in the data-plane. It has nothing to do with signalling (nor routing for that matter). And specifically signalling should not determine addressing. What happens if we decide to change the signalling? What happens if we use the NMS/OSS to set-up the trail? Regards, Neil > If PWs were identified using the same identifier regardless=20 > of the signalling protocol used, then in turn auto-discovery=20 > would not be dependent on the signalling protocol used. A=20 > further improvement would be to use a unique identifier that=20 > is only pertinent to the PW layer, e.g. an IPv6 address,=20 > which would be a significant advantage from a management and=20 > OAM perspective. >=20 > Regards, > Richard >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 14:43:42 +0100 Lines: 119 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Tue Aug 10 15:50:17 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR+Z9+aoAHoWQI/QuCavCfQ7G8i1wAP8IBQAAUB98AACJ8RcA== To: , , X-OriginalArrivalTime: 10 Aug 2004 13:43:42.0647 (UTC) FILETIME=[0CD7F470:01C47EE0] X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Folks, I have had a few private mails asking me to explain something I noted below.....so just in case other folks are having problems with my terse and/or poor explanation let me spell it out: I said (extracted from below): "An address is an attribute of an access point in the data-plane. It has nothing to do with signalling (nor routing for that matter)." So to better explain what I meant here: An address defines an access point of a network or subnetwork (this is a G.805 func arch term, it's not an IP subnet). It is an attribute of the data-plane of some layer network (this can be any mode, ie cl-ps, co-ps or co-cs). Signalling and routing are 2 additional functional components (there are more than this, but this is all that is relevant here).=20 Depending on the mode the signalling and routing (and other management) components can operate in-band or out-of-band wrt to the data-plane that will be carrying the traffic. In fact, when we take these components OOB (for important security/stability/resilience reasons) the mode of the control/management data-plane network can be cl-ps whilst that of the traffic data-plane network co-ps or co-cs (cf GMPLS which is exactly like this for SDH or OTN say). Note also that the addressing of these 2 layer networks (ie 1 for traffic and 1 for control/management) operate in quite different spaces. So, whilst routing and signalling protocols carry addressing (of the traffic data-plane) they should be agnostic to the nature of that addressing. However, there is further key point regarding the relationship between addressing and topology (and thus the impact on routing advertisements)........ Addressing and topology are coupled. The tighter the coupling the more efficient can be the address aggregation (ie summarisation in routing advertisements), and vice versa (ethernet is an extreme example of the latter case.....and here the address has completely degenerated into a 'name' since it carries no topological information of 'where'). However, the coupling must not be too tight or else changes in topology impact addressing schemes...and that is not a good idea either. Hope that clarifies. =20 Regards, Neil > -----Original Message----- > From: Harrison,N,Neil,IKR2 R=20 > Sent: 10 August 2004 10:27 > To: Spencer,R,Richard,XGH5 R; 'lmartini@cisco.com';=20 > 'busschbach@lucent.com' > Cc: 'l2vpn@ietf.org'; 'dimitri.papadimitriou@alcatel.be';=20 > 'pwe3@ietf.org'; 'mustapha.aissaoui@alcatel.com' > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching >=20 >=20 > Richard....spot on....1 additional remark where I want to=20 > reinforce something important. >=20 > > Luca, > >=20 > > > Since we have accepted the control protocol draft we do not > > have much > > > choice on what parameters identify a PW. > > > This is already defined. > >=20 > > I disagree, this implies that the WG does not have the power > > to change or make amendments to decisions that have already=20 > > been made. If WG consensus was reached that the parameters=20 > > currently defined for identifying PWs were not suitable for=20 > > MH-PWs, then there is no reason why alternative parameters=20 > > couldn't be added (at least as optional) in separate/revised=20 > > drafts. Especially considering the draft(s) in question are=20 > > not even RFCs yet. > >=20 > > > I see this from a different point of view. Current > > autodiscovery does > > > not take into consideration pw-switching nodes , but I cannot > > > see why we=20 > > > have to merge the auto provisioning of PW , and the signaling=20 > > > protocol ? > >=20 > > I don't think Peter is suggesting that auto-provisioning and > > signalling should be merged or described in the same=20 > > document. I think he is just pointing out that if=20 > > auto-discovery was to be based on PW endpoint identifiers,=20 > > because of the way PW end/mid points (or access points) are=20 > > currently identified, autodiscovery would be dependant on the=20 > > signalling mechanism used. For example, PW end points=20 > > established using FEC 128 are identified by the PWid+PE IP=20 > > address, whereas PW end points established using FEC 129 are=20 > > identified by the AGI/AII+PE IP address, i.e. endpoint=20 > > identification is dependent on the signalling mechanism used.=20 > NH=3D> And this is one thing that is clearly wrong....and its=20 > happened before with MPLS. An address is an attribute of an=20 > access point in the data-plane. It has nothing to do with=20 > signalling (nor routing for that matter). And specifically=20 > signalling should not determine addressing. What happens if=20 > we decide to change the signalling? What happens if we use=20 > the NMS/OSS to set-up the trail? >=20 > Regards, Neil >=20 > > If PWs were identified using the same identifier regardless=20 > > of the signalling protocol used, then in turn auto-discovery=20 > > would not be dependent on the signalling protocol used. A=20 > > further improvement would be to use a unique identifier that=20 > > is only pertinent to the PW layer, e.g. an IPv6 address,=20 > > which would be a significant advantage from a management and=20 > > OAM perspective. > >=20 > > Regards, > > Richard > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: John Drake Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 07:23:43 -0700 Lines: 390 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, 'Mustapha Aissaoui' , richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Tue Aug 10 16:53:48 2004 Return-path: To: "Busschbach, Peter B (Peter)" , "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: da41e01217ab11ad82db577473e913ae X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I think Peter raises some very valid points > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Monday, August 09, 2004 3:39 PM > To: 'Luca Martini' > Cc: l2vpn@ietf.org; dimitri.papadimitriou@alcatel.be; pwe3@ietf.org; > 'Mustapha Aissaoui'; dpapadimitriou@psg.com; richard.spencer@bt.com > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > -----Original Message----- > > From: Luca Martini [mailto:lmartini@cisco.com] > > Sent: Monday, August 09, 2004 5:40 PM > > To: Busschbach, Peter B (Peter) > > Cc: 'Mustapha Aissaoui'; richard.spencer@bt.com; l2vpn@ietf.org; > > dimitri.papadimitriou@alcatel.be; pwe3@ietf.org; > > dpapadimitriou@psg.com > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > Peter, > > > > I would like to make a distinction between autodiscovery , > > and PW switching. > > What you are proposing is an autodiscovery system that automatically > > provisions the PW switching point to switch an incoming PW into a > > specific outgoing one. I believe that there is a requirement for this > > functionality, but this is an L2VPN and PW autodiscovery discussion. > > I purposely kept away from this in the pw-switching draft, as > > provisioning of L2VPNs is not in scope here. > > > I agree that autodiscovery belongs in L2VPN and not in PWE3. However, the > consequence of accepting draft-martini-pwe3-pw-switching-00.txt is that > autodiscovery must be based on the LDP identifiers defined in the control > draft (i.e. PWids, AGIs and AIIs). Is that the right approach? > > In fact, in the case of Multi-hop PWs, the autodiscovery mechanism used > between PEs does not necessarily extend to PW Switching Nodes. PEs need to > exchange information about Attachment Circuits, but PW Switching Nodes > only need to have enough knowledge to establish end-to-end PWs. Draft- > martini-pwe3-pw-switching-00.txt does not allow one to make that > distinction. It assumes that every node (both PEs and PW Switching Nodes) > maintain AC-related information. > > In summary, I don't think we can define MH-PW setup without looking at the > impact it has on autodiscovery. > > > > ( this does not mean it is > > not required by somebody ). > > Also keep in mind that today I only know about L2 peering points that > > are statically provisioned. Unlike L3 peering, I have not seen PNNI > > peering or Frame-Relay SPVC peering. > > I agree. On the other hand, there is telephony peering. > > > > > Luca > > > > > > Busschbach, Peter B (Peter) wrote: > > > > >Mustapha, > > > > > >I am surprised by your insistence that PWs should not be routable. > > > > > >I understand that the proposals I made in this email > > exchange have pros and cons. Within the scope of the > > requirements (which we will document, as we discussed in San > > Diego), it is very well possible that the cons outweight the > > pros. Or vice versa. We will see. However, you seem to have > > decided already that routable PWs are forbidden under any > > circumstances. > > > > > >You write: "My point is that the PW dataplane forwarding > > decision should be local to a stitching node and not network wide." > > > > > >I have no idea what you mean by that. The dataplane > > forwarding decision is always local. The stitching node > > receives a packet with PW Label A, swaps it with PW Label B > > and forwards it over the appropriate tunnel. > > > > > >The issue is how the stitching node supports signaling. It > > receives a PW setup request (in the current model, an LDP > > label mapping message) and somehow has to determine what the > > next node on the Multi-hop Path is. In all likelyhood, that > > next hop will be derived from one or more identifiers that > > identify the end point of the MH-PW. > > > > > >There are two options: > > > > > >a) identify the end point by the IP address of the destination PE > > >b) identify the end point by a specific AGI/AII combination. > > > > > >Since every node in the network already IP routing and > > already has (a prefix of) the PE's IP address in its routing > > table, it seems to me that a) is more straightforward than > > b). Not only that. Solution b) requires a topology discovery > > protocol based on AGIs and AIIs. > > > > > >However, in your email, you also write that: > > >"... we do not want to have a separate addressing and > > routing for PWs in the current PWE3 architecture". > > > > > >I am not sure how to interpret this statement. It sounds as > > if you agree with me that a) is the better solution. However, > > you are arguing vehemently against my position. Therefore, > > the only thing I can imagine is that you believe that any > > form of automated MH-PW setup is undesirable and that Service > > Providers will be perfectly happy to manually provision MH-PWs. > > > > > >You may be right, but let's wait for the requirements ... > > > > > >Peter > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > >>Sent: Wednesday, August 04, 2004 9:41 PM > > >>To: richard.spencer@bt.com > > >>Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > >>busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org > > >>Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > >> > > >> > > >>Richard, > > >>see below. > > >> > > >>Regards, > > >>Mustapha. > > >>----------- > > >>richard.spencer@bt.com wrote: > > >> > > >> > > >>>Mustapha, > > >>> > > >>> > > >>> > > >>>>Richard and Dimitri, > > >>>>this issue is in my view one of the critical issues. I believe a > > >>>>workable solution should have the following characteristics: > > >>>> > > >>>>1. State how stitching nodes are discovered. I do not agree with > > >>>>Peter that a stiching node is just another LSP switching > > >>>> > > >>>> > > >>node. There > > >> > > >> > > >>>>are PW specific operations to be performed in the data, > > >>>> > > >>>> > > >>control, and > > >> > > >> > > >>>>management (OAM) planes on a PW segment. > > >>>> > > >>>> > > >>>I agree that a PW stitching node is not just another (tunnel) LSP > > >>>switching node. The data plane behaviour (i.e. MPLS label > > >>> > > >>> > > >>switching) may > > >> > > >> > > >>>be the same but the tunnel LSP control protocols needs to > > >>> > > >>> > > >>be modified > > >> > > >> > > >>>(or separate control protocols/instances used) in order to support > > >>>single sided provisioning of switched PWs. > > >>> > > >>> > > >>MA> Add to that OAM on the PW segment. > > >> > > >> > > >> > > >>>I think discovery can be > > >>>split up into two aspects, i) discovery of ingress/egress > > >>> > > >>> > > >>PEs, and ii) > > >> > > >> > > >>>discovery of PW switching nodes. > > >>>Regarding i) this is required to support single sided provisioning. > > >>> > > >>> > > >>MA> I think single sided signaling is a separate issue. You can > > >>still configure the AC and PW information at both PEs but have one > > >>side trigger the PW setup (master PE) and the other reply only when > > >>it receives it (slave PW). This is the dominant mode of operation of > > >>SPVCs in ATM networks today. > > >> > > >> > > >> > > >>>Regarding ii), this is only required if routers use the > > same address > > >>>space (i.e. same loopback addresses) at the PW layer that > > >>> > > >>> > > >>they use at > > >> > > >> > > >>>the MPLS tunnel layer. If a different address space was used then > > >>>support for PW switching would be explicit. The consequence > > >>> > > >>> > > >>of using the > > >> > > >> > > >>>same addresses is that PW switching capable nodes must be > > >>> > > >>> > > >>distinguish > > >> > > >> > > >>>from non PW switching capable nodes explicitly using a discovery > > >>>mechanism or implicitly, e.g. using routing metrics as is > > >>> > > >>> > > >>the case with > > >> > > >> > > >>>the FA-LSP solution. > > >>> > > >>> > > >>MA> You are right. However, the reason for using the same address > > >>space is a direct consequence of the fact that PWs can only ride > > >>inside a tunnel of some sort. > > >> > > >> > > >> > > >>>>2. State how routing of PW control messages are performed once the > > >>>>stitching nodes have been discovered. It seems to me that > > >>>> > > >>>> > > >>a solution > > >> > > >> > > >>>>that mandates the use of FA-LSPs is too restrictive. > > >>>> > > >>>> > > >>>I agree that mandating FA-LSPs is too restrictive and that > > >>> > > >>> > > >>a common PW > > >> > > >> > > >>>routing solution should be specified. > > >>> > > >>> > > >>> > > >>>>3. Avoid if possible making the PW label routable. Not that I have > > >>>>anything against that but if a solution turns PWs into routable > > >>>>entities on their own, then we should discuss it in that wider > > >>>>context. In that case, the use of tunnel LSPs becomes a > > >>>> > > >>>> > > >>convenience > > >> > > >> > > >>>>as opposed to a requirement of the architecture. > > >>>> > > >>>> > > >>>I'm not sure I understand your last point; it appears to me to be a > > >>>contradiction. In 2 you state that routing of PW control > > >>> > > >>> > > >>messages must > > >> > > >> > > >>>be addressed but then in 3 state that making PWs routable should be > > >>>avoided. I think there are two issues here, a) routing at > > >>> > > >>> > > >>the PW layer > > >> > > >> > > >>>where LSPs tunnels are used (resulting in a two layer LSP > > >>> > > >>> > > >>hierarchy), b) > > >> > > >> > > >>>routing where tunnel LSPs are not used (resulting in a single LSP > > >>>layer). > > >>> > > >>> > > >>MA> I mean that we do not want to have a separate addressing and > > >>routing for PWs in the current PWE3 architecture. > > >>I make the following argument: as long as PWs are confined inside > > >>tunnels, it does not make sense to make them routable (network wide) > > >>and have their own address space. > > >> > > >> > > >> > > >>>Regarding a), in the control plane, routing is required at > > >>> > > >>> > > >>the PW layer > > >> > > >> > > >>>to calculate/select the PW path from ingress PE to egress PE across > > >>>intermediate PW switching points and therefore the PE IP > > >>> > > >>> > > >>addresses must > > >> > > >> > > >>>be routable. In the (PW) data plane the PW label needs to > > be used at > > >>>each hop to make a forwarding decision. However, even > > >>> > > >>> > > >>though PWs need to > > >> > > >> > > >>>be routable at the PW level, they are not routable at the > > tunnel LSP > > >>>level, i.e. forwarding at the LSP tunnel level is based on > > >>> > > >>> > > >>tunnel LSP > > >> > > >> > > >>>labels not PW labels, just like VP switching in ATM is > > >>> > > >>> > > >>based on VPIs not > > >> > > >> > > >>>VCIs. > > >>> > > >>> > > >>MA> You describe it very well. My point is that the PW dataplane > > >>forwarding decision should be local to a stitching node and not > > >>network wide. In other words, we do not want to advertize PW > > >>reachability. > > >> > > >> > > >> > > >>>Regarding b), if tunnel LSPs are not used then PWs must still be > > >>>routable at the PW layer, but as this is the only layer > > >>> > > >>> > > >>each hop must > > >> > > >> > > >>>belong to the PW layer, i.e. each hop must support PW > > switching. For > > >>>scaling reasons its highly unlikely that a single LSP > > layer would be > > >>>used in the core, but I think using a single LSP layer > > >>> > > >>> > > >>would make sense > > >> > > >> > > >>>for spoke connections in the hierarchical LDP model. > > >>> > > >>> > > >>MA> Correct. And this is where I think Peter and I disagree. I do > > >>not belive that we want to solve the general problem where any node > > >>can be used as a stitching node because this degenerates into the > > >>case where you will be forced to have a separate routing and > > >>addressing for the PWs. The case of the spoke connections is > > >>different. I assume that a static PW may be just fine if the access > > >>network is simple. In complex access and aggregation networks, one > > >>can have build a separate PSN for this network and perform switching > > >>at some well idnetified edge nodes. > > >> > > >> > > >> > > >>>Regards, > > >>>Richard > > >>> > > >>> > > > > > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Hamid Ould-Brahim" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 10 Aug 2004 12:58:31 -0400 Lines: 124 Sender: pwe3-bounces@ietf.org Cc: l2vpn@ietf.org, "Busschbach, Peter B \(Peter\)" , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Tue Aug 10 19:35:46 2004 Return-path: To: Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca, I think the framework sections/draft will help clarifying the terminology and convey a common understanding of the problem that is being solved (I don't see requirements to be that much useful if people have different understanding and interpretation of the objectives and problem being solved). Anyway, as long as all this is clarified in the requirement draft I am perfectly fine with that. See some comments inline... > > > >a) The terminology: PW switching/stitching/multihop PW, > > PW switching points and PW demultiplexor > > allocation points (suggest stick with one or two terms). > > > > > > > This is defined in the draft-martini-pwe3-pw-switching-00.txt Do you > need me to add anything ? > Sounds a good start. I have one comment though. It seems that multihop PW has been defined in terms of switching a set of PWs. What it doesn't specify is whether the ingress and egress PE (ultimate PEs) are aware this is in fact a MH-PW and not an independent single hop pseudowire that is being switched to other pseudowires. PW switching can happen even if the originating PE is not aware (for example at the control plane) that its PW is being switched to other pseudowires. Take for example the VPLS case when used in the context of distributed/hierarchical scenario. The U-PE (low end Ethernet bridge) is not required to know that its pseudowire that lead to the N-PE is being switched/spliced to a set of N-PEs and then to other remote PE or U-PE, nor it needs to know about the "switching point TLVs". Though the end to end is a spliced pseudowire (here is another term for "PW switching" being already used in l2vpn signaling ;-)), the originating PE didn't specify in terms of control any information that indicates the intent is to establish a MH-PW instead of an "independent" PW. In other words "PW switching" does not necessarily implies a MH-PW (while MH-PW implies somewhere PW switching is performed). In the context of MH-PW, the originating PE knows apriori that it wants to establish a MH-PW or the PW segment being established is member of a MH-PW. Note that in this definition of MH-PW, a given MH-PW can as well be "PW switched" to other MH-PWs (not just SH-PWs). It looks to me we need to disambiguate between these cases in the requirements/framework doc: a) PW switching/splicing b) MH-PW where a PE that explicitly indicates its intent to establish a Multihop Pseudowire instead of independent PW. c) Independent PW (lets call it the I-PW who is a single hop BUT not part of any MH-PW) versus PW segment member of MH-PW (the one you cal SH-PW). d) an independent PW that is being PW switched (an ingress PE is not aware of the PW switching function taking place). d) a PW segment that is member of MH-PW. e) a MH-PW that is composed of only PW segments. f) a MH-PW that is composed of PWs and possibly other native l2 circuits. For MH-PW I would have assumed that the originating PE somehow needs to indicate (for example at the control plane) or it needs at least to know that the intent is to establish a MH-PW instead of "independent" PW to a given remote forwarder (or remote PE) with no possibility of establishing an end-to-end signaling adjacency to the ultimate PE. That remote forwarder can be located at a given switching point or at the ultimate PE. > >b) Deployment scenarios of multihop/switching in terms of > > - an inter-as/domain > > - single/inter-providers > > - a PW-enabled access network to an PW-MPLS core network > > - A PW "private" segment stitched to another "provider-based" > > PW (not sure this is needed?). > > > > > > > This would be more suited for a requirement draft. > Sure. [clipped...] > >d) mp-pw path determination (implicit/explicit -ERO). > > > > > Not sure what you mean. Is this regarding the pw switching TLV we > defined ? or regarding autodiscovery ? > For MH-PW, the ingress PE may indicate a set of information such as identification of the forwarder on the ultimate PE and can as well indicate (if it has that information) the "PW path" to be used. The switching TLVs you mentioned are just used to indicate to the originating PE the actual path of MH-PW and as indicated in the draft the TLVs are used for troubleshooting purposes. In this scenario the MH-PW path is implicit done through configuration. That path can be explicitly signaled by the ingress PE (that's what I referred to implicit/explicit without indicating what mechanism can be used to determine that path -i.e., discovery, routing, provisioning, etc). Hamid. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Mustapha Aissaoui Subject: Re: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Tue, 10 Aug 2004 17:30:57 -0400 Organization: Alcatel Networks Corporaton Lines: 45 Sender: pwe3-bounces@ietf.org References: <411765DC.80802@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 10 23:50:03 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Stewart Bryant X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, I support making this draft a WG document. One issue I raised in the meeting was the use of the PTI for control versus its use for data plane payload identification. As Peter said, all the existing PWE3 encapsulations make use of some sort of 32-bit word (in some cases it is actually the Generic or Preferred CW) starting with an all zero nibble. Thus, there is no need to indicate the PW type with a PTI. I think we should encourage future PW applications to do the same. The other application we have is to carry PW OAM messages such as VCCV-ping and VCCV-BFD. Both of these are actually IP control messages (UDP to be more specific). However, we should have the flexibility to carry non-IP control messages. Example of these are Y.1711 OAM messages and future BFD messages that are control plane independent. This is where the PTI is useful. Finally, I proposed the use of the PTI for user protocol payload identification in draft-aissaoui-extended-pid-01.txt (expired now). This is useful if one is going to carry multiple user protocols under the same PW label. As Peter pointed out, it looks like the type of interworking we are dealing with at this point in time does not require it. Though, the PTI concept can be extended as required in the future. Regards, Mustapha. ---------- Stewart Bryant wrote: > > The authors request that > > http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt > > be adopted as a WG item with its title changed to > > PWE3 MPLS Control Word > > - Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 11 Aug 2004 08:37:07 -0600 Organization: Cisco Systems Lines: 70 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, busschbach@lucent.com X-From: pwe3-bounces@ietf.org Wed Aug 11 16:54:58 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: richard.spencer@bt.com In-Reply-To: X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org richard.spencer@bt.com wrote: >Luca, > > =20 > >>Since we have accepted the control protocol draft we do not have much=20 >>choice on what parameters identify a PW. >>This is already defined. >> =20 >> > >I disagree, this implies that the WG does not have the power to change o= r make amendments to decisions that have already been made. If WG consens= us was reached that the parameters currently defined for identifying PWs = were not suitable for MH-PWs, then there is no reason why alternative par= ameters couldn't be added (at least as optional) in separate/revised draf= ts. Especially considering the draft(s) in question are not even RFCs yet= =2E > > =20 > This is true , and I do not have any issue with adding some kind of new=20 autodiscovery parameter. I am not sure what we are discussing here .... I have no problem in=20 doing any of the things you are describing. All I was pointing out is to keep in mind that we have to make a=20 differentiation between autodiscovery , and signaling/maintenance=20 protocols. Both still have to be considered together, and should be=20 designed to meet the requirements. This might give rise to more then one draft , and certainly not all=20 drafts will be part of PWE3. >>I see this from a different point of view. Current autodiscovery does=20 >>not take into consideration pw-switching nodes , but I cannot=20 >>see why we=20 >>have to merge the auto provisioning of PW , and the signaling=20 >>protocol ? >> =20 >> > >I don't think Peter is suggesting that auto-provisioning and signalling = should be merged or described in the same document. I think he is just po= inting out that if auto-discovery was to be based on PW endpoint identifi= ers, because of the way PW end/mid points (or access points) are currentl= y identified, autodiscovery would be dependant on the signalling mechanis= m used. For example, PW end points established using FEC 128 are identifi= ed by the PWid+PE IP address, whereas PW end points established using FEC= 129 are identified by the AGI/AII+PE IP address, i.e. endpoint identific= ation is dependent on the signalling mechanism used. If PWs were identifi= ed using the same identifier regardless of the signalling protocol used, = then in turn auto-discovery would not be dependent on the signalling prot= ocol used. A further improvement would be to use a unique identifier that= is only pertinent to the PW layer, e.g. an IPv6 address, which would be = a significant advantage from a management and OAM perspective. > > =20 > I fully Agree. Luca >Regards, >Richard > > > =20 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 11 Aug 2004 08:43:29 -0600 Organization: Cisco Systems Lines: 38 Sender: pwe3-bounces@ietf.org References: <0536FC9B908BEC4597EE721BE6A353890A1EA388@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, busschbach@lucent.com, richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Wed Aug 11 16:58:40 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A1EA388@i2km07-ukbr.domain1.systemhost.net> X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org neil.2.harrison@bt.com wrote: >Richard....spot on....1 additional remark where I want to reinforce >something important. > > > >> >>I don't think Peter is suggesting that auto-provisioning and >>signalling should be merged or described in the same >>document. I think he is just pointing out that if >>auto-discovery was to be based on PW endpoint identifiers, >>because of the way PW end/mid points (or access points) are >>currently identified, autodiscovery would be dependant on the >>signalling mechanism used. For example, PW end points >>established using FEC 128 are identified by the PWid+PE IP >>address, whereas PW end points established using FEC 129 are >>identified by the AGI/AII+PE IP address, i.e. endpoint >>identification is dependent on the signalling mechanism used. >> >> > <>NH=> And this is one thing that is clearly wrong....and its happened > before with MPLS. An address is an attribute of an access point in the > data-plane. It has nothing to do with signalling (nor routing for that > matter). And specifically signalling should not determine addressing. > What happens if we decide to change the signalling? What happens if we > use the NMS/OSS to set-up the trail? > > Regards, Neil > Neil, So what you are saying is that the addressing is independent of the signaling ? I agree with this point. Luca From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 11 Aug 2004 09:09:42 -0600 Organization: Cisco Systems Lines: 192 Sender: pwe3-bounces@ietf.org References: <085091CB2CA14E4B8B163FFC37C84E9DDDAA32@zcarhxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, "Busschbach, Peter B \(Peter\)" , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Wed Aug 11 17:23:45 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: Hamid Ould-Brahim In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9DDDAA32@zcarhxm0.corp.nortel.com> X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hamid, See comments in line... Hamid Ould-Brahim wrote: >Luca, > >I think the framework sections/draft will help clarifying >the terminology and convey a common understanding of the >problem that is being solved (I don't see requirements >to be that much useful if people have different understanding >and interpretation of the objectives and problem being solved). >Anyway, as long as all this is clarified in the >requirement draft I am perfectly fine with that. > >See some comments inline... > > > >>>a) The terminology: PW switching/stitching/multihop PW, >>> PW switching points and PW demultiplexor >>> allocation points (suggest stick with one or two terms). >>> >>> >>> >>> >>> >>This is defined in the draft-martini-pwe3-pw-switching-00.txt Do you >>need me to add anything ? >> >> >> > >Sounds a good start. I have one comment though. > >It seems that multihop PW has been defined in terms of >switching a set of PWs. What it doesn't specify is whether >the ingress and egress PE (ultimate PEs) are aware this is >in fact a MH-PW and not an independent single hop >pseudowire that is being switched to other pseudowires. > > > The ultimate PEs do not have to be aware that the PW is being switched. >PW switching can happen even if the originating PE is >not aware (for example at the control plane) >that its PW is being switched to other pseudowires. > >Take for example the VPLS case when used in >the context of distributed/hierarchical scenario. >The U-PE (low end Ethernet bridge) is not required to know >that its pseudowire that lead to the N-PE is being >switched/spliced to a set of N-PEs >and then to other remote PE or U-PE, nor it needs to >know about the "switching point TLVs". > >Though the end to end is a spliced pseudowire (here is another >term for "PW switching" being already used in l2vpn >signaling ;-)), the originating PE didn't specify >in terms of control any information that indicates the >intent is to establish a MH-PW instead of an >"independent" PW. > > > This is exactly the pw-switching draft model. We added a pw switching TLV, ( added by the pw switching point ) for management and debugging purposes. It is not used to control singnalling. >In other words "PW switching" does not necessarily implies >a MH-PW (while MH-PW implies somewhere PW switching >is performed). In the context of MH-PW, the originating PE >knows apriori that it wants to establish a MH-PW or the >PW segment being established is member of a MH-PW. > >Note that in this definition of MH-PW, a given MH-PW >can as well be "PW switched" to other MH-PWs >(not just SH-PWs). > >It looks to me we need to disambiguate between these cases >in the requirements/framework doc: > >a) PW switching/splicing >b) MH-PW where a PE that explicitly indicates its intent > to establish a Multihop Pseudowire instead of independent > PW. >c) Independent PW (lets call it the I-PW who is a single hop > BUT not part of any MH-PW) versus PW segment member of > MH-PW (the one you cal SH-PW). >d) an independent PW that is being PW switched > (an ingress PE is not aware of the PW switching function > taking place). >d) a PW segment that is member of MH-PW. >e) a MH-PW that is composed of only PW segments. >f) a MH-PW that is composed of PWs and possibly > other native l2 circuits. > > > basically , you want a lot nore terms defined ;-) b) could be called a inter-domain PW. c) is a SH-PW d) is a PW e) is == b) I'm not sure why the difference would be useful f) is not a PW. If it includes native ACs then it is more a VC, or an ethernet vlan ...... >For MH-PW I would have assumed that the originating PE somehow >needs to indicate (for example at the control plane) or it needs >at least to know that the intent is to establish a MH-PW instead of >"independent" PW to a given remote forwarder (or remote PE) >with no possibility of establishing an end-to-end signaling >adjacency to the ultimate PE. That remote forwarder can >be located at a given switching point or at the ultimate PE. > > > why would the originating PE "need" to know the intent to establish an MH-PW ? ( the operator might need to know , but why the PE ? ) >>>b) Deployment scenarios of multihop/switching in terms of >>> - an inter-as/domain >>> - single/inter-providers >>> - a PW-enabled access network to an PW-MPLS core network >>> - A PW "private" segment stitched to another "provider-based" >>> PW (not sure this is needed?). >>> >>> >>> So goen the fact that AS# seem to be a BGP concept , we should stick with the inter-domain term. ( one AS can have many PW domains as the two are not related ) >>> >>> >>> >>> >>This would be more suited for a requirement draft. >> >> >> > >Sure. > >[clipped...] > > > >>>d) mp-pw path determination (implicit/explicit -ERO). >>> >>> >>> >>> >>Not sure what you mean. Is this regarding the pw switching TLV we >>defined ? or regarding autodiscovery ? >> >> >> > >For MH-PW, the ingress PE may indicate a set of information >such as identification of the forwarder on the ultimate PE and >can as well indicate (if it has that information) the "PW path" >to be used. > >The switching TLVs you mentioned are just used >to indicate to the originating PE the actual path of MH-PW and >as indicated in the draft the TLVs are used for troubleshooting >purposes. In this scenario the MH-PW path is implicit done >through configuration. That path can be explicitly signaled by >the ingress PE (that's what I referred to implicit/explicit >without indicating what mechanism can be used to determine >that path -i.e., discovery, routing, provisioning, etc). > > > The idea here was not to preclude this functionality. PW source routing , and PW routing can still be acheived with an autodiscovery/PW routing protocol. This pw-switching design did not intend to preclude it at all. So, if a ultimate PE needs to setup a PW to another U-PE in a different domain it becomes a provisioning exercise that can be done by NMS, BGP, Radius , or any other protocol you can think of. Luca >Hamid. > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Florin Balus" Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Wed, 11 Aug 2004 14:17:16 -0400 Lines: 218 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0295140152==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 11 20:29:01 2004 Return-path: To: Stewart Bryant X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org 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. --===============0295140152== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47FCF.6F25D642" 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_01C47FCF.6F25D642 Content-Type: text/plain Stewart, We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid. I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts. Assuming we have in the same network PEs that support both formats: - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))] - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?). In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format? Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)? Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001 PTI)(0000 CW stuff)(data)? Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload? Thanks for clarifying the above points. Regards, Florin -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Monday, August 09, 2004 7:54 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request The authors request that http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt be adopted as a WG item with its title changed to PWE3 MPLS Control Word - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C47FCF.6F25D642 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG = request

Stewart,

We did promote the idea of a PID/PTI - see Dave = Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the = explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and = the overall proposed solution are valid.

I just wanted to clarify some technicalities to make = sure we clearly identify where we are headed to - i.e. what changes are = required in other PWE3 drafts.

Assuming we have in the same network PEs that support = both formats:
 - the CW [(0000 CW stuff)(data) & the = current VCCV format (0001 PA PPP_DLL)(OAM payload))]
 - and the newly defined PTI (0001 = PTI)(data/VCCV payload/?whatever?).
In the same time let's assume other PEs will accept = just the PTI - being part of those implementations that do not support = 0000. How are we going to ensure the 2 sets of PEs will be able to = negotiate in the control plane the right format?

 
Currently we do have in each of the 2 L2 FECs (PWID = and Generalized ID) just one bit to determine whether or not the CW = should be used - see draft-ietf-pwe3-control-protocol-07.txt section = 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we = differentiate the other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: there = are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell = Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt = section 4.3.2). For a PE that will implement the PTI format are we = saying the PW frames (after the 2 labels) will look like this: = (0001  PTI)(0000 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the same = way, just re-using what is already defined: i.e. (0001  PTI)(0001 = PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the = PTI code points that are going to be used for VCCV/OAM payload? =

Thanks for clarifying the above points.
Regards,
Florin


-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = On Behalf Of Stewart Bryant
Sent: Monday, August 09, 2004 7:54 AM
To: pwe3@ietf.org
Subject: [PWE3] = draft-bryant-mcpherson-pwe3-cw-00.txt WG request


The authors request that

http://www.ietf.org/internet-drafts/draft-bryant-mcphe= rson-pwe3-cw-00.txt

be adopted as a WG item with its title changed = to

PWE3 MPLS Control Word

- Stewart







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

------_=_NextPart_001_01C47FCF.6F25D642-- --===============0295140152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0295140152==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Wed, 11 Aug 2004 14:41:28 -0400 Lines: 189 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0288175263==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 11 20:58:36 2004 Return-path: To: "'Florin Balus'" , Stewart Bryant X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org 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. --===============0288175263== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47FD2.532C5310" 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_01C47FD2.532C5310 Content-Type: text/plain Florus, Draft-allan-mpls-pid-00.txt is not accessible anymore. I don't recall what rationale it gave for the need for a PTI. Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI. Peter -----Original Message----- From: Florin Balus [mailto:balus@nortelnetworks.com] Sent: Wednesday, August 11, 2004 2:17 PM To: Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Stewart, We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid. I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts. Assuming we have in the same network PEs that support both formats: - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))] - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?). In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format? Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)? Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001 PTI)(0000 CW stuff)(data)? Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload? Thanks for clarifying the above points. Regards, Florin -----Original Message----- From: pwe3-bounces@ietf.org [ mailto:pwe3-bounces@ietf.org ] On Behalf Of Stewart Bryant Sent: Monday, August 09, 2004 7:54 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request The authors request that http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt be adopted as a WG item with its title changed to PWE3 MPLS Control Word - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C47FD2.532C5310 Content-Type: text/html RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request
Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible anymore. I don't recall what rationale it gave for the need for a PTI.
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI.
 
Peter 
-----Original Message-----
From: Florin Balus [mailto:balus@nortelnetworks.com]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: pwe3@ietf.org
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request


Stewart,

We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid.

I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts.

Assuming we have in the same network PEs that support both formats:
 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))]
 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?).
In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format?


Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001  PTI)(0000 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001  PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload?

Thanks for clarifying the above points.
Regards,
Florin


-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, August 09, 2004 7:54 AM
To: pwe3@ietf.org
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request


The authors request that

http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt

be adopted as a WG item with its title changed to

PWE3 MPLS Control Word

- Stewart







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

------_=_NextPart_001_01C47FD2.532C5310-- --===============0288175263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0288175263==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Wed, 11 Aug 2004 22:08:08 +0100 Lines: 297 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1308373535==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 11 23:56:10 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Thread-Index: AcR/1WhP3RjaYAr2RayHfs6eTYwEAQAD+tAw To: X-OriginalArrivalTime: 11 Aug 2004 21:08:08.0838 (UTC) FILETIME=[4D8B8A60:01C47FE7] X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1308373535== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47FE7.4D183D67" This is a multi-part message in MIME format. ------_=_NextPart_001_01C47FE7.4D183D67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter, I always regarded this as a good way to differentiate traffic from OAM (though the right/ideal solution would have had this designed into the 'normal' header). regards, Neil -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Busschbach, Peter B (Peter) Sent: 11 August 2004 19:41 To: 'Florin Balus'; Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Florus, =20 Draft-allan-mpls-pid-00.txt is not accessible anymore. I don't recall what rationale it gave for the need for a PTI. =20 Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI. =20 Peter=20 -----Original Message----- From: Florin Balus [mailto:balus@nortelnetworks.com] Sent: Wednesday, August 11, 2004 2:17 PM To: Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Stewart,=20 We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid. I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts. Assuming we have in the same network PEs that support both formats:=20 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))]=20 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?).=20 In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format? Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)? Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001 PTI)(0000 CW stuff)(data)? Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload?=20 Thanks for clarifying the above points.=20 Regards,=20 Florin=20 -----Original Message-----=20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant=20 Sent: Monday, August 09, 2004 7:54 AM=20 To: pwe3@ietf.org=20 Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request=20 The authors request that=20 http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.tx t=20 be adopted as a WG item with its title changed to=20 PWE3 MPLS Control Word=20 - Stewart=20 _______________________________________________=20 pwe3 mailing list=20 pwe3@ietf.org=20 https://www1.ietf.org/mailman/listinfo/pwe3=20 ------_=_NextPart_001_01C47FE7.4D183D67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Peter, I always regarded this as a good way to differentiate = traffic from=20 OAM (though the right/ideal solution would have had this designed into = the=20 'normal' header).  regards, Neil
-----Original Message-----
From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of=20 Busschbach, Peter B (Peter)
Sent: 11 August 2004=20 19:41
To: 'Florin Balus'; Stewart Bryant
Cc:=20 pwe3@ietf.org
Subject: RE: [PWE3]=20 draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible anymore. = I don't=20 recall what rationale it gave for the need for a = PTI.
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the = sole reason=20 for an additional control word. However, introducing PTI to=20 solve the issues related to ECMP seems overkill. It would be good = if we=20 can clearly state why we need a PTI.
 
Peter 
-----Original Message-----
From: Florin Balus=20 [mailto:balus@nortelnetworks.com]
Sent: Wednesday, August = 11, 2004=20 2:17 PM
To: Stewart Bryant
Cc:=20 pwe3@ietf.org
Subject: RE: [PWE3]=20 draft-bryant-mcpherson-pwe3-cw-00.txt WG = request


Stewart,

We did promote the idea of a PID/PTI - see Dave = Allan's=20 draft-allan-mpls-pid-00.txt on the subject. Also I think the = explanation of=20 ECMP issue (disambiguate from IP/MPLS packets etc) and the overall = proposed=20 solution are valid.

I just wanted to clarify some technicalities to = make sure we=20 clearly identify where we are headed to - i.e. what changes are = required in=20 other PWE3 drafts.

Assuming we have in the same network PEs that = support both=20 formats:
 - the CW [(0000 CW = stuff)(data) &=20 the current VCCV format (0001 PA PPP_DLL)(OAM payload))] =
 - and the newly defined PTI (0001 PTI)(data/VCCV=20 payload/?whatever?).
In the same time = let's assume=20 other PEs will accept just the PTI - being part of those = implementations=20 that do not support 0000. How are we going to ensure the 2 sets of = PEs will=20 be able to negotiate in the control plane the right = format?


Currently we do have in = each of the=20 2 L2 FECs (PWID and Generalized ID) just one bit to determine = whether or not=20 the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt = section=20 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do = we=20 differentiate the other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: = there are=20 some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell = Mode and=20 AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section = 4.3.2).=20 For a PE that will implement the PTI format are we saying the PW = frames=20 (after the 2 labels) will look like this: (0001  PTI)(0000 CW=20 stuff)(data)?

Is VCCV/OAM going to be differentiated in the same = way, just=20 re-using what is already defined: i.e. (0001  PTI)(0001 PA = PPP_DLL)(OAM=20 payload)? If not I assume we will need to clarify the PTI code = points that=20 are going to be used for VCCV/OAM payload?

Thanks for clarifying the above points. =
Regards,
Florin


-----Original Message-----
From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = On=20 Behalf Of Stewart Bryant
Sent: Monday, = August 09,=20 2004 7:54 AM
To: pwe3@ietf.org =
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG=20 request


The authors request that

http://www.ietf.org/internet-drafts/draft-bryant-mcpherso= n-pwe3-cw-00.txt=20

be adopted as a WG item with its title changed = to=20

PWE3 MPLS Control Word

- Stewart







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

------_=_NextPart_001_01C47FE7.4D183D67-- --===============1308373535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1308373535==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Wed, 11 Aug 2004 17:13:36 -0400 Lines: 256 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1274630194==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 11 23:56:55 2004 Return-path: To: "'neil.2.harrison@bt.com'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org 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. --===============1274630194== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47FE7.5BC6F056" 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_01C47FE7.5BC6F056 Content-Type: text/plain "though the right/ideal solution would have had this designed into the 'normal' header" If you consider the Control Word to be the normal header, we can still do that. At one point, the plan was to use a CW starting with 0000 for traffic and a CW starting with 0001 for OAM. It is still not clear to me why we moved away from that plan. -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Wednesday, August 11, 2004 5:08 PM To: busschbach@lucent.com Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Peter, I always regarded this as a good way to differentiate traffic from OAM (though the right/ideal solution would have had this designed into the 'normal' header). regards, Neil -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Busschbach, Peter B (Peter) Sent: 11 August 2004 19:41 To: 'Florin Balus'; Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Florus, Draft-allan-mpls-pid-00.txt is not accessible anymore. I don't recall what rationale it gave for the need for a PTI. Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI. Peter -----Original Message----- From: Florin Balus [mailto:balus@nortelnetworks.com] Sent: Wednesday, August 11, 2004 2:17 PM To: Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Stewart, We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid. I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts. Assuming we have in the same network PEs that support both formats: - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))] - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?). In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format? Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)? Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001 PTI)(0000 CW stuff)(data)? Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload? Thanks for clarifying the above points. Regards, Florin -----Original Message----- From: pwe3-bounces@ietf.org [ mailto:pwe3-bounces@ietf.org ] On Behalf Of Stewart Bryant Sent: Monday, August 09, 2004 7:54 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request The authors request that http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt be adopted as a WG item with its title changed to PWE3 MPLS Control Word - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C47FE7.5BC6F056 Content-Type: text/html Message
"though the right/ideal solution would have had this designed into the 'normal' header"
 
If you consider the Control Word to be the normal header, we can still do that. At one point, the plan was to use a CW starting with 0000 for  traffic and a CW starting with 0001 for OAM. It is still not clear to me why we moved away from that plan.
 
 
 
 -----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Wednesday, August 11, 2004 5:08 PM
To: busschbach@lucent.com
Cc: pwe3@ietf.org
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Peter, I always regarded this as a good way to differentiate traffic from OAM (though the right/ideal solution would have had this designed into the 'normal' header).  regards, Neil
-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Busschbach, Peter B (Peter)
Sent: 11 August 2004 19:41
To: 'Florin Balus'; Stewart Bryant
Cc: pwe3@ietf.org
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible anymore. I don't recall what rationale it gave for the need for a PTI.
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI.
 
Peter 
-----Original Message-----
From: Florin Balus [mailto:balus@nortelnetworks.com]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: pwe3@ietf.org
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request


Stewart,

We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid.

I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts.

Assuming we have in the same network PEs that support both formats:
 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))]
 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?).
In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format?


Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001  PTI)(0000 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001  PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload?

Thanks for clarifying the above points.
Regards,
Florin


-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, August 09, 2004 7:54 AM
To: pwe3@ietf.org
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request


The authors request that

http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt

be adopted as a WG item with its title changed to

PWE3 MPLS Control Word

- Stewart







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

------_=_NextPart_001_01C47FE7.5BC6F056-- --===============1274630194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1274630194==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Cheng-Yin Lee Subject: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 11 Aug 2004 17:14:18 -0400 Lines: 319 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, busschbach@lucent.com X-From: pwe3-bounces@ietf.org Wed Aug 11 23:58:08 2004 Return-path: X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en To: richard.spencer@bt.com X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard, richard.spencer@bt.com wrote: > Peter, > > I agree with all the comments you make below. > > Regarding the distribution of PW layer reachability information for MH-= PWs, I would argue that this information must always be distributed (or c= ollected) whether manual or dynamic provisioning methods are used. To set= up a path across multiple hops where alternative paths exist, routing mu= st be performed, there is no getting away from this. If a human operator = manually configures a MH-PW then the routing function is performed by the= human operator and the human operator collects the reachability informat= ion by analysing the network topology information. If OSS systems are use= d then the OSS system must perform the routing function and discover the = topology of the network by requesting or collecting reachability/switchin= g node capability information. If dynamic routing protocols are used to p= erform the routing function then reachability/switching node capability i= nformation must be distributed/collected by PEs and PW switching nodes vi= a the routing protocol. Very much in agreement with the above > As provisioning by a human > operator obviously doesn't scale, provisioning for MH-PWs must be carri= ed out either by OSS or dynamic protocols, which means that the PEs and P= W switching nodes must advertise (or respond to requests for) reachabilit= y/switching node capability information. as well as the above > Regarding PW end point identifiers for routing purposes, as things stan= d today I think out of the two options below, routing based on PE IP addr= esses (option a) is preferable to using AGI/AII combinations (option b). = The main reasons being: > > (1) From the PWE3 control draft: "The Attachment Identifier must be uni= que in the context of the PE router in which the Forwarder resides. The = combination must be globally unique." So, even if the AGI= /AII are used, the PE IP addresses must be used as well anyway. > > (2) Reachability information based on [AGI/AII/PE IP address] destinati= on identifiers would need to be advertised and stored in a routing table = (if a dynamic routing protocol is used) on each PE and PW switching node.= This does not seem desirable looking at things from a vendors perspectiv= e because the PW routing table implementation would need to support varia= ble/unknown length identifiers as destinations. Could we not decouple VPN membership discovery from routing ? Thanks Cheng-Yin > > > Saying that, in theory, using AGI/AIIs would make sense because AGI/AII= s belong to the PW layer and therefore routing would be based on address/= naming information pertinent only to the PW layer. The problem is that th= e naming method used to identify a PW access point (forwarder) is based o= n the PE IP address (which exists at the MPLS tunnel layer) plus a locall= y unique AI (which exists at the PW layer). Having thought about it, I th= ink option (a) could be made to work if a globally unique identifier (e.g= =2E an IPv6 address) was used to identify a PW access point. The AGI coul= d still be used to identify a PW VPN, but the AII would uniquely identify= a PW access point (on a global PW layer network basis). This would solve= problem (1) because the AII would be globally unique and therefore the P= E IP addresses (belonging to the MPLS tunnel layer) would not be required= , and problem (2) would be solved because the destination would be a fixe= d length IPv6 address. The idea of using IPv6 > addresses for identifying forwarders could be taken a step further by m= aking a forwarder a manageable logical entity, i.e. a logical PW interfac= e that could be managed just like any other interface. This would also be= an advantage from an OAM perspective as the PW endpoint identifiers woul= d uniquely identify the PW layer source and sink access points. > > Of course there is nothing stopping a provider using IPv6 addresses for= AIs (PW access points) today. The problem is that because using IPv6 add= resses for AIs is not mandatory, to fully support option (a) vendors woul= d still need to address problem (2) by implementing a PW routing table th= at supports unknown/variable length destination identifiers, and address = problem (1) by at least having an option for using AGI/AII + PE IP addres= s identifiers, rather than just AIIs. > > Regards, > Richard > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: 08 August 2004 03:15 > > To: 'Mustapha Aissaoui'; Spencer,R,Richard,XGH5 R > > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > l2vpn@ietf.org; pwe3@ietf.org > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > Mustapha, > > > > I am surprised by your insistence that PWs should not be routable. > > > > I understand that the proposals I made in this email exchange > > have pros and cons. Within the scope of the requirements > > (which we will document, as we discussed in San Diego), it is > > very well possible that the cons outweight the pros. Or vice > > versa. We will see. However, you seem to have decided already > > that routable PWs are forbidden under any circumstances. > > > > You write: "My point is that the PW dataplane forwarding > > decision should be local to a stitching node and not network wide." > > > > I have no idea what you mean by that. The dataplane > > forwarding decision is always local. The stitching node > > receives a packet with PW Label A, swaps it with PW Label B > > and forwards it over the appropriate tunnel. > > > > The issue is how the stitching node supports signaling. It > > receives a PW setup request (in the current model, an LDP > > label mapping message) and somehow has to determine what the > > next node on the Multi-hop Path is. In all likelyhood, that > > next hop will be derived from one or more identifiers that > > identify the end point of the MH-PW. > > > > There are two options: > > > > a) identify the end point by the IP address of the destination PE > > b) identify the end point by a specific AGI/AII combination. > > > > Since every node in the network already IP routing and > > already has (a prefix of) the PE's IP address in its routing > > table, it seems to me that a) is more straightforward than > > b). Not only that. Solution b) requires a topology discovery > > protocol based on AGIs and AIIs. > > > > However, in your email, you also write that: > > "... we do not want to have a separate addressing and routing > > for PWs in the current PWE3 architecture". > > > > I am not sure how to interpret this statement. It sounds as > > if you agree with me that a) is the better solution. However, > > you are arguing vehemently against my position. Therefore, > > the only thing I can imagine is that you believe that any > > form of automated MH-PW setup is undesirable and that Service > > Providers will be perfectly happy to manually provision MH-PWs. > > > > You may be right, but let's wait for the requirements ... > > > > Peter > > > > > > > -----Original Message----- > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > Sent: Wednesday, August 04, 2004 9:41 PM > > > To: richard.spencer@bt.com > > > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > > Richard, > > > see below. > > > > > > Regards, > > > Mustapha. > > > ----------- > > > richard.spencer@bt.com wrote: > > > > > > > > Mustapha, > > > > > > > > > Richard and Dimitri, > > > > > this issue is in my view one of the critical issues. I believe = a > > > > > workable solution should have the following characteristics: > > > > > > > > > > 1. State how stitching nodes are discovered. I do not agree wit= h > > > > > Peter that a stiching node is just another LSP switching > > > node. There > > > > > are PW specific operations to be performed in the data, > > > control, and > > > > > management (OAM) planes on a PW segment. > > > > > > > > I agree that a PW stitching node is not just another (tunnel) LSP= > > > > switching node. The data plane behaviour (i.e. MPLS label > > > switching) may > > > > be the same but the tunnel LSP control protocols needs to > > > be modified > > > > (or separate control protocols/instances used) in order to suppor= t > > > > single sided provisioning of switched PWs. > > > > > > MA> Add to that OAM on the PW segment. > > > > > > > I think discovery can be > > > > split up into two aspects, i) discovery of ingress/egress > > > PEs, and ii) > > > > discovery of PW switching nodes. > > > > Regarding i) this is required to support single sided > > provisioning. > > > > > > MA> I think single sided signaling is a separate issue. You can > > > still configure the AC and PW information at both PEs but have one > > > side trigger the PW setup (master PE) and the other reply only when= > > > it receives it (slave PW). This is the dominant mode of operation o= f > > > SPVCs in ATM networks today. > > > > > > > Regarding ii), this is only required if routers use the > > same address > > > > space (i.e. same loopback addresses) at the PW layer that > > > they use at > > > > the MPLS tunnel layer. If a different address space was used then= > > > > support for PW switching would be explicit. The consequence > > > of using the > > > > same addresses is that PW switching capable nodes must be > > > distinguish > > > > from non PW switching capable nodes explicitly using a discovery > > > > mechanism or implicitly, e.g. using routing metrics as is > > > the case with > > > > the FA-LSP solution. > > > > > > MA> You are right. However, the reason for using the same address > > > space is a direct consequence of the fact that PWs can only ride > > > inside a tunnel of some sort. > > > > > > > > 2. State how routing of PW control messages are > > performed once the > > > > > stitching nodes have been discovered. It seems to me that > > > a solution > > > > > that mandates the use of FA-LSPs is too restrictive. > > > > > > > > I agree that mandating FA-LSPs is too restrictive and that > > > a common PW > > > > routing solution should be specified. > > > > > > > > > 3. Avoid if possible making the PW label routable. Not > > that I have > > > > > anything against that but if a solution turns PWs into routable= > > > > > entities on their own, then we should discuss it in that wider > > > > > context. In that case, the use of tunnel LSPs becomes a > > > convenience > > > > > as opposed to a requirement of the architecture. > > > > > > > > I'm not sure I understand your last point; it appears to > > me to be a > > > > contradiction. In 2 you state that routing of PW control > > > messages must > > > > be addressed but then in 3 state that making PWs routable > > should be > > > > avoided. I think there are two issues here, a) routing at > > > the PW layer > > > > where LSPs tunnels are used (resulting in a two layer LSP > > > hierarchy), b) > > > > routing where tunnel LSPs are not used (resulting in a single LSP= > > > > layer). > > > > > > MA> I mean that we do not want to have a separate addressing and > > > routing for PWs in the current PWE3 architecture. > > > I make the following argument: as long as PWs are confined inside > > > tunnels, it does not make sense to make them routable (network wide= ) > > > and have their own address space. > > > > > > > Regarding a), in the control plane, routing is required at > > > the PW layer > > > > to calculate/select the PW path from ingress PE to egress > > PE across > > > > intermediate PW switching points and therefore the PE IP > > > addresses must > > > > be routable. In the (PW) data plane the PW label needs to > > be used at > > > > each hop to make a forwarding decision. However, even > > > though PWs need to > > > > be routable at the PW level, they are not routable at the > > tunnel LSP > > > > level, i.e. forwarding at the LSP tunnel level is based on > > > tunnel LSP > > > > labels not PW labels, just like VP switching in ATM is > > > based on VPIs not > > > > VCIs. > > > > > > MA> You describe it very well. My point is that the PW dataplane > > > forwarding decision should be local to a stitching node and not > > > network wide. In other words, we do not want to advertize PW > > > reachability. > > > > > > > Regarding b), if tunnel LSPs are not used then PWs must still be > > > > routable at the PW layer, but as this is the only layer > > > each hop must > > > > belong to the PW layer, i.e. each hop must support PW > > switching. For > > > > scaling reasons its highly unlikely that a single LSP > > layer would be > > > > used in the core, but I think using a single LSP layer > > > would make sense > > > > for spoke connections in the hierarchical LDP model. > > > > > > MA> Correct. And this is where I think Peter and I disagree. I do > > > not belive that we want to solve the general problem where any node= > > > can be used as a stitching node because this degenerates into the > > > case where you will be forced to have a separate routing and > > > addressing for the PWs. The case of the spoke connections is > > > different. I assume that a static PW may be just fine if the access= > > > network is simple. In complex access and aggregation networks, one > > > can have build a separate PSN for this network and perform switchin= g > > > at some well idnetified edge nodes. > > > > > > > Regards, > > > > Richard > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Wed, 11 Aug 2004 22:28:44 +0100 Lines: 403 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0260035761==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Aug 12 00:03:00 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Thread-Index: AcR/6CtTCUQDW2UZQr+wxrfJMdXtlwAAbP9Q To: X-OriginalArrivalTime: 11 Aug 2004 21:28:45.0165 (UTC) FILETIME=[2E7411D0:01C47FEA] X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0260035761== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47FEA.2E092D7B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C47FEA.2E092D7B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, its not the normal header. The normal header (of MPLS) is the shim header........the CW is (was?) some (optional) adaptation function above that....now bizarrely taking on a life of its own as a layer network. =20 regards Neil -----Original Message----- From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]=20 Sent: 11 August 2004 22:14 To: Harrison,N,Neil,IKR2 R Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request "though the right/ideal solution would have had this designed into the 'normal' header" =20 If you consider the Control Word to be the normal header, we can still do that. At one point, the plan was to use a CW starting with 0000 for traffic and a CW starting with 0001 for OAM. It is still not clear to me why we moved away from that plan. =20 =20 =20 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Wednesday, August 11, 2004 5:08 PM To: busschbach@lucent.com Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Peter, I always regarded this as a good way to differentiate traffic from OAM (though the right/ideal solution would have had this designed into the 'normal' header). regards, Neil -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Busschbach, Peter B (Peter) Sent: 11 August 2004 19:41 To: 'Florin Balus'; Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Florus, =20 Draft-allan-mpls-pid-00.txt is not accessible anymore. I don't recall what rationale it gave for the need for a PTI. =20 Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI. =20 Peter=20 -----Original Message----- From: Florin Balus [mailto:balus@nortelnetworks.com] Sent: Wednesday, August 11, 2004 2:17 PM To: Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Stewart,=20 We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid. I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts. Assuming we have in the same network PEs that support both formats:=20 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))]=20 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?).=20 In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format? Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)? Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001 PTI)(0000 CW stuff)(data)? Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload?=20 Thanks for clarifying the above points.=20 Regards,=20 Florin=20 -----Original Message-----=20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant=20 Sent: Monday, August 09, 2004 7:54 AM=20 To: pwe3@ietf.org=20 Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request=20 The authors request that=20 http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.tx t=20 be adopted as a WG item with its title changed to=20 PWE3 MPLS Control Word=20 - Stewart=20 _______________________________________________=20 pwe3 mailing list=20 pwe3@ietf.org=20 https://www1.ietf.org/mailman/listinfo/pwe3=20 ------_=_NextPart_001_01C47FEA.2E092D7B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
No, its not the normal header.  The normal header (of = MPLS) is the=20 shim header........the CW is (was?) some (optional) adaptation function = above=20 that....now bizarrely taking on a life of its own as a layer=20 network.
 
regards Neil
-----Original = Message-----
From:=20 Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] =
Sent: 11=20 August 2004 22:14
To: Harrison,N,Neil,IKR2 R
Cc:=20 pwe3@ietf.org
Subject: RE: [PWE3]=20 draft-bryant-mcpherson-pwe3-cw-00.txt WG request

"though the right/ideal solution = would have=20 had this designed into the 'normal' header"
 
If = you consider=20 the Control Word to be the normal header, we can still do that. At one = point,=20 the plan was to use a CW starting with 0000 for  traffic and a CW = starting with 0001 for OAM. It is still not clear to me why we moved = away from=20 that plan.
 
 
 
 -----Original=20 Message-----
From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com]
Sent: Wednesday, August 11, = 2004=20 5:08 PM
To: busschbach@lucent.com
Cc:=20 pwe3@ietf.org
Subject: RE: [PWE3]=20 draft-bryant-mcpherson-pwe3-cw-00.txt WG = request

Peter, I always regarded this as a good way to = differentiate traffic=20 from OAM (though the right/ideal solution would have had this = designed into=20 the 'normal' header).  regards, Neil
-----Original Message-----
From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of=20 Busschbach, Peter B (Peter)
Sent: 11 August 2004=20 19:41
To: 'Florin Balus'; Stewart Bryant
Cc:=20 pwe3@ietf.org
Subject: RE: [PWE3]=20 draft-bryant-mcpherson-pwe3-cw-00.txt WG = request

Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible = anymore. I=20 don't recall what rationale it gave for the need for a=20 PTI.
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as = the sole=20 reason for an additional control word. However, introducing = PTI to=20 solve the issues related to ECMP seems overkill. It would be = good if=20 we can clearly state why we need a PTI.
 
Peter 
-----Original Message-----
From: Florin Balus = [mailto:balus@nortelnetworks.com]
Sent: Wednesday, = August 11,=20 2004 2:17 PM
To: Stewart Bryant
Cc:=20 pwe3@ietf.org
Subject: RE: [PWE3]=20 draft-bryant-mcpherson-pwe3-cw-00.txt WG=20 request


Stewart,

We did promote the idea of a PID/PTI - see = Dave Allan's=20 draft-allan-mpls-pid-00.txt on the subject. Also I think the = explanation=20 of ECMP issue (disambiguate from IP/MPLS packets etc) and the = overall=20 proposed solution are valid.

I just wanted to clarify some technicalities = to make=20 sure we clearly identify where we are headed to - i.e. what = changes are=20 required in other PWE3 drafts.

Assuming we have in the same network PEs that = support=20 both formats:
 - the CW [(0000 CW = stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM = payload))]
 - and the newly = defined PTI=20 (0001 PTI)(data/VCCV payload/?whatever?).
In the=20 same time let's assume other PEs will accept just the PTI - = being part=20 of those implementations that do not support 0000. How are we = going to=20 ensure the 2 sets of PEs will be able to negotiate in the = control plane=20 the right format?


Currently we do have = in each of=20 the 2 L2 FECs (PWID and Generalized ID) just one bit to = determine=20 whether or not the CW should be used - see=20 draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. = 0001=20 implicitly meant up to now VCCV format. How do we differentiate = the=20 other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: = there are=20 some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell = Mode=20 and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt = section=20 4.3.2). For a PE that will implement the PTI format are we = saying the PW=20 frames (after the 2 labels) will look like this: (0001  = PTI)(0000=20 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the = same way,=20 just re-using what is already defined: i.e. (0001  = PTI)(0001 PA=20 PPP_DLL)(OAM payload)? If not I assume we will need to clarify = the PTI=20 code points that are going to be used for VCCV/OAM payload? =

Thanks for clarifying the above points. =
Regards,
Florin =


-----Original Message-----
From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = On=20 Behalf Of Stewart Bryant
Sent: Monday, = August=20 09, 2004 7:54 AM
To: = pwe3@ietf.org=20
Subject: [PWE3] = draft-bryant-mcpherson-pwe3-cw-00.txt=20 WG request


The authors request that

http://www.ietf.org/internet-drafts/draft-bryant-mcpherso= n-pwe3-cw-00.txt=20

be adopted as a WG item with its title changed = to=20

PWE3 MPLS Control Word

- Stewart







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

------_=_NextPart_001_01C47FEA.2E092D7B-- --===============0260035761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0260035761==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Thu, 12 Aug 2004 07:08:34 +0100 Lines: 32 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, dimitri.papadimitriou@alcatel.be, pwe3@ietf.org, mustapha.aissaoui@alcatel.com, busschbach@lucent.com X-From: pwe3-bounces@ietf.org Thu Aug 12 08:12:14 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching thread-index: AcR/6EdQYDVVC9xUTaywGGNzkjEH9QAABR+g To: X-OriginalArrivalTime: 12 Aug 2004 06:08:34.0844 (UTC) FILETIME=[CCF365C0:01C48032] X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Cheng-Yin, > Could we not decouple VPN membership discovery from routing ? VPN membership discovery is already decoupled from routing. In the MH-PW = case there are two aspects to discovery, i) discovery of PW endpoints = and ii) discovery of PW switching capable nodes. Discovery of VPN = endpoints is always required as these are not known prior to PW = provisioning, i.e. the endpoints are not known until a provider receives = the customer request for the VPN.=20 However, discovery of PW switching points is only required because the = same (IP loopback) address space is used at the client PW layer that is = used at the MPLS tunnel server layer. A MH-PW next hop must always be a = PW switching capable node (or the destination endpoint PE), and = therefore non PW switching nodes must be distinguished from those that = do support PW switching. As discussed on the list, one way to solve the problem and keep the same = addressing would be to use a discovery mechanism along with a separate = PW routing table that only contains routing information for MH-PW = source/destination PEs and PW-switching capable nodes, i.e. routing = information pertinent only to the PW layer. Another way to solve the = problem and keep the same addressing would be to use FA-LSPs and routing = metrics to ensure that FA-LSPs are always the best next hop. Discovery = of PW switching capable nodes in this solution is implicit, i.e. the = best next hop to a PW endpoint by implication should be PW switching = capable. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Thu, 12 Aug 2004 08:28:02 +0100 Lines: 480 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Aug 12 09:36:55 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcR/7mpA0XDZ/oLDQBqXFZJnubmDhgARCrdA To: , X-OriginalArrivalTime: 12 Aug 2004 07:28:03.0412 (UTC) FILETIME=[E73D2140:01C4803D] X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Cheng-Yin... > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Cheng-Yin Lee > Sent: 11 August 2004 22:14 > To: Spencer,R,Richard,XGH5 R > Cc: l2vpn@ietf.org; dimitri.papadimitriou@alcatel.be;=20 > pwe3@ietf.org; mustapha.aissaoui@alcatel.com;=20 > dpapadimitriou@psg.com; busschbach@lucent.com > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching >=20 >=20 > Richard, >=20 > richard.spencer@bt.com wrote: >=20 > > Peter, > > > > I agree with all the comments you make below. > > > > Regarding the distribution of PW layer reachability information for=20 > > MH-PWs, I would argue that this information must always be=20 > distributed=20 > > (or collected) whether manual or dynamic provisioning methods are=20 > > used. To set up a path across multiple hops where alternative paths=20 > > exist, routing must be performed, there is no getting away=20 > from this.=20 > > If a human operator manually configures a MH-PW then the routing=20 > > function is performed by the human operator and the human operator=20 > > collects the reachability information by analysing the network=20 > > topology information. If OSS systems are used then the OSS=20 > system must=20 > > perform the routing function and discover the topology of=20 > the network=20 > > by requesting or collecting reachability/switching node capability=20 > > information. If dynamic routing protocols are used to perform the=20 > > routing function then reachability/switching node capability=20 > > information must be distributed/collected by PEs and PW switching=20 > > nodes via the routing protocol. >=20 > Very much in agreement with the above >=20 > > As provisioning by a human > > operator obviously doesn't scale, provisioning for MH-PWs must be=20 > > carried out either by OSS or dynamic protocols, which means=20 > that the=20 > > PEs and PW switching nodes must advertise (or respond to=20 > requests for)=20 > > reachability/switching node capability information. >=20 > as well as the above >=20 > > Regarding PW end point identifiers for routing purposes, as things=20 > > stand today I think out of the two options below, routing=20 > based on PE=20 > > IP addresses (option a) is preferable to using AGI/AII combinations=20 > > (option b). The main reasons being: > > > > (1) From the PWE3 control draft: "The Attachment Identifier must be=20 > > unique in the context of the PE router in which the=20 > Forwarder resides. =20 > > The combination must be globally unique."=20 > So, even if=20 > > the AGI/AII are used, the PE IP addresses must be used as=20 > well anyway. > > > > (2) Reachability information based on [AGI/AII/PE IP address]=20 > > destination identifiers would need to be advertised and stored in a=20 > > routing table (if a dynamic routing protocol is used) on=20 > each PE and=20 > > PW switching node. This does not seem desirable looking at=20 > things from=20 > > a vendors perspective because the PW routing table implementation=20 > > would need to support variable/unknown length identifiers as=20 > > destinations. >=20 > Could we not decouple VPN membership discovery from routing ? NH=3D> Yes of course, but one needs to look at the overall VPN service problem to put these functions in their correct context....let me try and explain. Knowing the membership of a 'club' does not tell you where the members live or how to get/connect between them......but clearly all of these are required functions and part of the VPN service problem (route-calculation is but 1 facet here). IMO there are 2 quite disjoint layer network tasks when considering VPNs (any)....the 1st is common to all VPNs (and has 3 subtasks that require different behaviour) whilst the 2nd is a possible value-add function, viz: A there is the task of server layer topology creation B there is the optional value-add task of client layer reachability distribution These tasks are orthogonal and should not be lumped together. Task A is the biggest and most important one and contains 3 subtasks: 1 Discover *who* belongs to the VPN.....so this is all about learning the sites (read as 'server layer addresses') in *whatever* the mode/technology is being used for the server layer network. 2 Calculate *routes* between the server layer addresses, ie how to establish paths across the server layer network.....so this is the route-calculation bit. 3 Create *paths* within the server layer network (the nature of the 'paths' and the management of them is mode/technology dependent.....and it is specifically *not* the same across the cl-ps, co-ps and co-cs modes). Now one could lump sub-tasks 1 and 2 above together in some server layer routing process, but certainly not sub-task 3.....this is either a NMS provisioning job or (better) it is done via a signalling agent under the control of the NMS. Note carefully that task A is all about server layer topology creation, and if we stop here we have merely automated the creation of what I would call 'a simple managed BW service'.....something folks sometimes call (wrongly) a 'L1 or L2 VPN'. It can apply to *any* mode/technology, but for commercial VPNs where one requires both client layer reachabililty isolation and strong traffic/performance isolation it really only makes sense to use either co-cs or co-ps mode technologies IMO. I know folks can use cl-ps here (well this is the IETF!) but I am trying to be precise about understanding the real differences across each of the modes.....they are not alike and we can do things smarter as long as we properly understand this and what is going on functionally here. Now let's look at the functional behaviour required in each of these tasks/sub-tasks: Task A - Sub-task 1 - this lends itself to a centralized query/response behaviour. So a solution like radius is ideal. Other solutions such as BGP-based say are not ideal as they are broadcast in nature. - Sub-task 2 is a computation issue about route calculation......this can be done in either a distributed or centralised manner in the *server* layer mode/technology (this has nothing to do with the client layer please note) - Sub-task 3 is a path creation task. It is best carried out IMO by a proper signalling protocol/agent in the server, working closely under the (ultimate) control of the NMS. So this could be RSVP-TE say for server layer when this is based on either the co-ps or co-cs mode. The subsequent operational fault/performance management of the server layer varies depending on its mode.....1 size does not fit all here. As noted, if we stop here this creates a simple managed BW VPN in the server layer. If we want to add-value as a SP we can add client layer reachability.....so this is: Task B Here a 'broadcast' behaviour (ideally limited to between same-member sites of a given VPN only) is required to distribute client layer reachability across VPN member sites.....so its here that MP-BGP finds a good role. Note that this function has nothing to do with the server layer stuff under task A. Now that's breaking the VPN service problem back into its logical components IMO. Clearly the functional solution should not be the same for all tasks as the required behaviours are different. Speaking as a SP I like looking at the VPN service creation problem like this, as: - it clearly shows me that there is a common theme across all modes/technologies, which is important for NMS/OSS and functional re-use; - it points us at the right functional solutions for the given task/sub-task....and clearly these are not the same, so a '1 protocol fits all' solution is not a good idea IMO. Richard has been working on precisely the above issues in some R&D work I have been running in BT because I got rather disillusioned with seeing folks argue that 'my protocol is better than yours'. There is a generic way to do VPNs IMO across all modes, and its looking at the problem as above that is key. So I not surprised that you find much of what Richard says as making sense. Regards, Neil =09 >=20 > Thanks > Cheng-Yin >=20 > > > > > > Saying that, in theory, using AGI/AIIs would make sense because=20 > > AGI/AIIs belong to the PW layer and therefore routing would=20 > be based=20 > > on address/naming information pertinent only to the PW layer. The=20 > > problem is that the naming method used to identify a PW=20 > access point=20 > > (forwarder) is based on the PE IP address (which exists at the MPLS=20 > > tunnel layer) plus a locally unique AI (which exists at the=20 > PW layer).=20 > > Having thought about it, I think option (a) could be made=20 > to work if a=20 > > globally unique identifier (e.g. an IPv6 address) was used=20 > to identify=20 > > a PW access point. The AGI could still be used to identify=20 > a PW VPN,=20 > > but the AII would uniquely identify a PW access point (on a=20 > global PW=20 > > layer network basis). This would solve problem (1) because the AII=20 > > would be globally unique and therefore the PE IP addresses=20 > (belonging=20 > > to the MPLS tunnel layer) would not be required, and=20 > problem (2) would=20 > > be solved because the destination would be a fixed length IPv6=20 > > address. The idea of using IPv6 addresses for identifying=20 > forwarders=20 > > could be taken a step further by making a forwarder a manageable=20 > > logical entity, i.e. a logical PW interface that could be=20 > managed just=20 > > like any other interface. This would also be an advantage=20 > from an OAM=20 > > perspective as the PW endpoint identifiers would uniquely=20 > identify the=20 > > PW layer source and sink access points. > > > > Of course there is nothing stopping a provider using IPv6 addresses=20 > > for AIs (PW access points) today. The problem is that because using=20 > > IPv6 addresses for AIs is not mandatory, to fully support=20 > option (a)=20 > > vendors would still need to address problem (2) by=20 > implementing a PW=20 > > routing table that supports unknown/variable length destination=20 > > identifiers, and address problem (1) by at least having an=20 > option for=20 > > using AGI/AII + PE IP address identifiers, rather than just AIIs. > > > > Regards, > > Richard > > > > > -----Original Message----- > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > Sent: 08 August 2004 03:15 > > > To: 'Mustapha Aissaoui'; Spencer,R,Richard,XGH5 R > > > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be;=20 > > > l2vpn@ietf.org; pwe3@ietf.org > > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > > Mustapha, > > > > > > I am surprised by your insistence that PWs should not be routable. > > > > > > I understand that the proposals I made in this email=20 > exchange have=20 > > > pros and cons. Within the scope of the requirements=20 > (which we will=20 > > > document, as we discussed in San Diego), it is very well possible=20 > > > that the cons outweight the pros. Or vice versa. We will see.=20 > > > However, you seem to have decided already that routable PWs are=20 > > > forbidden under any circumstances. > > > > > > You write: "My point is that the PW dataplane forwarding decision=20 > > > should be local to a stitching node and not network wide." > > > > > > I have no idea what you mean by that. The dataplane forwarding=20 > > > decision is always local. The stitching node receives a=20 > packet with=20 > > > PW Label A, swaps it with PW Label B and forwards it over the=20 > > > appropriate tunnel. > > > > > > The issue is how the stitching node supports signaling.=20 > It receives=20 > > > a PW setup request (in the current model, an LDP label mapping=20 > > > message) and somehow has to determine what the next node on the=20 > > > Multi-hop Path is. In all likelyhood, that next hop will=20 > be derived=20 > > > from one or more identifiers that identify the end point of the=20 > > > MH-PW. > > > > > > There are two options: > > > > > > a) identify the end point by the IP address of the destination PE > > > b) identify the end point by a specific AGI/AII combination. > > > > > > Since every node in the network already IP routing and=20 > already has=20 > > > (a prefix of) the PE's IP address in its routing table,=20 > it seems to=20 > > > me that a) is more straightforward than b). Not only=20 > that. Solution=20 > > > b) requires a topology discovery protocol based on AGIs and AIIs. > > > > > > However, in your email, you also write that: > > > "... we do not want to have a separate addressing and routing for=20 > > > PWs in the current PWE3 architecture". > > > > > > I am not sure how to interpret this statement. It sounds=20 > as if you=20 > > > agree with me that a) is the better solution. However, you are=20 > > > arguing vehemently against my position. Therefore, the=20 > only thing I=20 > > > can imagine is that you believe that any form of automated MH-PW=20 > > > setup is undesirable and that Service Providers will be perfectly=20 > > > happy to manually provision MH-PWs. > > > > > > You may be right, but let's wait for the requirements ... > > > > > > Peter > > > > > > > > > > -----Original Message----- > > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > > Sent: Wednesday, August 04, 2004 9:41 PM > > > > To: richard.spencer@bt.com > > > > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be;=20 > > > > busschbach@lucent.com; l2vpn@ietf.org; pwe3@ietf.org > > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > > > > > Richard, > > > > see below. > > > > > > > > Regards, > > > > Mustapha. > > > > ----------- > > > > richard.spencer@bt.com wrote: > > > > > > > > > > Mustapha, > > > > > > > > > > > Richard and Dimitri, > > > > > > this issue is in my view one of the critical=20 > issues. I believe=20 > > > > > > a workable solution should have the following=20 > characteristics: > > > > > > > > > > > > 1. State how stitching nodes are discovered. I do not agree=20 > > > > > > with Peter that a stiching node is just another LSP=20 > switching > > > > node. There > > > > > > are PW specific operations to be performed in the data, > > > > control, and > > > > > > management (OAM) planes on a PW segment. > > > > > > > > > > I agree that a PW stitching node is not just another (tunnel)=20 > > > > > LSP switching node. The data plane behaviour (i.e. MPLS label > > > > switching) may > > > > > be the same but the tunnel LSP control protocols needs to > > > > be modified > > > > > (or separate control protocols/instances used) in order to=20 > > > > > support single sided provisioning of switched PWs. > > > > > > > > MA> Add to that OAM on the PW segment. > > > > > > > > > I think discovery can be > > > > > split up into two aspects, i) discovery of ingress/egress > > > > PEs, and ii) > > > > > discovery of PW switching nodes. > > > > > Regarding i) this is required to support single sided > > > provisioning. > > > > > > > > MA> I think single sided signaling is a separate issue. You can > > > > still configure the AC and PW information at both PEs=20 > but have one=20 > > > > side trigger the PW setup (master PE) and the other reply only=20 > > > > when it receives it (slave PW). This is the dominant mode of=20 > > > > operation of SPVCs in ATM networks today. > > > > > > > > > Regarding ii), this is only required if routers use the > > > same address > > > > > space (i.e. same loopback addresses) at the PW layer that > > > > they use at > > > > > the MPLS tunnel layer. If a different address space was used=20 > > > > > then support for PW switching would be explicit. The=20 > consequence > > > > of using the > > > > > same addresses is that PW switching capable nodes must be > > > > distinguish > > > > > from non PW switching capable nodes explicitly using=20 > a discovery=20 > > > > > mechanism or implicitly, e.g. using routing metrics as is > > > > the case with > > > > > the FA-LSP solution. > > > > > > > > MA> You are right. However, the reason for using the=20 > same address > > > > space is a direct consequence of the fact that PWs can=20 > only ride=20 > > > > inside a tunnel of some sort. > > > > > > > > > > 2. State how routing of PW control messages are > > > performed once the > > > > > > stitching nodes have been discovered. It seems to me that > > > > a solution > > > > > > that mandates the use of FA-LSPs is too restrictive. > > > > > > > > > > I agree that mandating FA-LSPs is too restrictive and that > > > > a common PW > > > > > routing solution should be specified. > > > > > > > > > > > 3. Avoid if possible making the PW label routable. Not > > > that I have > > > > > > anything against that but if a solution turns PWs into=20 > > > > > > routable entities on their own, then we should=20 > discuss it in=20 > > > > > > that wider context. In that case, the use of tunnel LSPs=20 > > > > > > becomes a > > > > convenience > > > > > > as opposed to a requirement of the architecture. > > > > > > > > > > I'm not sure I understand your last point; it appears to > > > me to be a > > > > > contradiction. In 2 you state that routing of PW control > > > > messages must > > > > > be addressed but then in 3 state that making PWs routable > > > should be > > > > > avoided. I think there are two issues here, a) routing at > > > > the PW layer > > > > > where LSPs tunnels are used (resulting in a two layer LSP > > > > hierarchy), b) > > > > > routing where tunnel LSPs are not used (resulting in a single=20 > > > > > LSP layer). > > > > > > > > MA> I mean that we do not want to have a separate addressing and > > > > routing for PWs in the current PWE3 architecture. > > > > I make the following argument: as long as PWs are=20 > confined inside=20 > > > > tunnels, it does not make sense to make them routable (network=20 > > > > wide) and have their own address space. > > > > > > > > > Regarding a), in the control plane, routing is required at > > > > the PW layer > > > > > to calculate/select the PW path from ingress PE to egress > > > PE across > > > > > intermediate PW switching points and therefore the PE IP > > > > addresses must > > > > > be routable. In the (PW) data plane the PW label needs to > > > be used at > > > > > each hop to make a forwarding decision. However, even > > > > though PWs need to > > > > > be routable at the PW level, they are not routable at the > > > tunnel LSP > > > > > level, i.e. forwarding at the LSP tunnel level is based on > > > > tunnel LSP > > > > > labels not PW labels, just like VP switching in ATM is > > > > based on VPIs not > > > > > VCIs. > > > > > > > > MA> You describe it very well. My point is that the PW dataplane > > > > forwarding decision should be local to a stitching node and not=20 > > > > network wide. In other words, we do not want to advertize PW=20 > > > > reachability. > > > > > > > > > Regarding b), if tunnel LSPs are not used then PWs=20 > must still be=20 > > > > > routable at the PW layer, but as this is the only layer > > > > each hop must > > > > > belong to the PW layer, i.e. each hop must support PW > > > switching. For > > > > > scaling reasons its highly unlikely that a single LSP > > > layer would be > > > > > used in the core, but I think using a single LSP layer > > > > would make sense > > > > > for spoke connections in the hierarchical LDP model. > > > > > > > > MA> Correct. And this is where I think Peter and I=20 > disagree. I do > > > > not belive that we want to solve the general problem where any=20 > > > > node can be used as a stitching node because this=20 > degenerates into=20 > > > > the case where you will be forced to have a separate=20 > routing and=20 > > > > addressing for the PWs. The case of the spoke connections is=20 > > > > different. I assume that a static PW may be just fine if the=20 > > > > access network is simple. In complex access and aggregation=20 > > > > networks, one can have build a separate PSN for this=20 > network and=20 > > > > perform switching at some well idnetified edge nodes. > > > > > > > > > Regards, > > > > > Richard > > > > > > > >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Florin Balus" Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Thu, 12 Aug 2004 12:42:14 -0400 Lines: 302 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0124187570==" Cc: pwe3@ietf.org, Jeffrey Sugimoto X-From: pwe3-bounces@ietf.org Thu Aug 12 19:12:03 2004 Return-path: To: "Busschbach, Peter B (Peter)" , Stewart Bryant X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org 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. --===============0124187570== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4808B.5361F822" 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_01C4808B.5361F822 Content-Type: text/plain Peter, See in-line... Stewart, There might be another motivator for a mandatory CW/consolidation under PTI: assuming we have a PW type that does not mandate a CW (ATM N to one cell mode) couldn't we get payloads that are mistaken also for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could be interpreted by the receiving PE as 0001? (thanks Jeff for bringing this up) Regards, Florin -----Original Message----- From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] Sent: Wednesday, August 11, 2004 2:41 PM To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Florus, Draft-allan-mpls-pid-00.txt is not accessible anymore. I don't recall what rationale it gave for the need for a PTI. FB: Dave addressed the need for an MPLS PID one year ago from an overall MPLS perspective: e.g. issues arisen from loadsharing on TE link bundles or ECMP in LDP network, OAM extensibility, Multiprotocol over MPLS... Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI. FB I agree with you that the justification in section 4 for PTI versus CW + VCCV could be improved. On the other hand we need the extensibility provided by a PTI/PID: VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned. Whether or not is a good idea to move the PW user data to 0001 format is to be debated. We need to make sure though the 2 formats could coexist in a network in the mean time. Peter -----Original Message----- From: Florin Balus [mailto:balus@nortelnetworks.com] Sent: Wednesday, August 11, 2004 2:17 PM To: Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Stewart, We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid. I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts. Assuming we have in the same network PEs that support both formats: - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))] - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?). In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format? Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)? Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001 PTI)(0000 CW stuff)(data)? Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload? Thanks for clarifying the above points. Regards, Florin -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org ] On Behalf Of Stewart Bryant Sent: Monday, August 09, 2004 7:54 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request The authors request that http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt be adopted as a WG item with its title changed to PWE3 MPLS Control Word - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C4808B.5361F822 Content-Type: text/html Message
Peter,
See in-line...
 
Stewart,
There might be another motivator for a mandatory CW/consolidation under PTI: assuming we have a PW type that does not mandate a CW (ATM N to one cell mode) couldn't we get payloads that are mistaken also for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could be interpreted by the receiving PE as 0001? (thanks Jeff for bringing this up)
 
Regards,
Florin
-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
Sent: Wednesday, August 11, 2004 2:41 PM
To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant
Cc: pwe3@ietf.org
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible anymore. I don't recall what rationale it gave for the need for a PTI.
FB: Dave addressed the need for an MPLS PID one year ago from an overall MPLS perspective: e.g. issues arisen from loadsharing on TE link bundles or ECMP in LDP network,  OAM extensibility, Multiprotocol over MPLS...
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI.
FB I agree with you that the justification in section 4 for PTI versus CW + VCCV could be improved. On the other hand we need the extensibility provided by a PTI/PID:  VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned.
Whether or not is a good idea to move the PW user data to 0001 format is to be debated. We need to make sure though the 2 formats could coexist in a network in the mean time.
 
Peter 
-----Original Message-----
From: Florin Balus [mailto:balus@nortelnetworks.com]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: pwe3@ietf.org
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request


Stewart,

We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid.

I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts.

Assuming we have in the same network PEs that support both formats:
 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))]
 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?).
In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format?


Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001  PTI)(0000 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001  PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload?

Thanks for clarifying the above points.
Regards,
Florin


-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, August 09, 2004 7:54 AM
To: pwe3@ietf.org
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request


The authors request that

http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt

be adopted as a WG item with its title changed to

PWE3 MPLS Control Word

- Stewart







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

------_=_NextPart_001_01C4808B.5361F822-- --===============0124187570== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0124187570==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Mustapha Aissaoui Subject: Re: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Thu, 12 Aug 2004 13:29:56 -0400 Organization: Alcatel Networks Corporaton Lines: 159 Sender: pwe3-bounces@ietf.org References: <9671A92C3C8B5744BC97F855F7CB6465E72E5D@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Busschbach, Peter B \(Peter\)" , pwe3@ietf.org, Jeffrey Sugimoto , Stewart Bryant X-From: pwe3-bounces@ietf.org Thu Aug 12 19:51:37 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Florin Balus X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Florin, I think the intent is that if you want to use the VCCV CW (0001 nibble) on OAM packets, then you are required to use the regular CW (000 nibble) on the user packets. Otherwise, you will have to use the alert label option for OAM packets but this may not work with ECMP. Mustapha. ------------ > Florin Balus wrote: > > Peter, > See in-line... > > Stewart, > There might be another motivator for a mandatory CW/consolidation > under PTI: assuming we have a PW type that does not mandate a > CW (ATM N to one cell mode) couldn't we get payloads that are > mistaken also for 0001/VCCV packets - e.g. VPI 64 in an ATM cell > could be interpreted by the receiving PE as 0001? (thanks Jeff for > bringing this up) > > Regards, > Florin > > -----Original Message----- > From: Busschbach, Peter B (Peter) > [mailto:busschbach@lucent.com] > Sent: Wednesday, August 11, 2004 2:41 PM > To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant > Cc: pwe3@ietf.org > Subject: RE: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt WG request > > Florus, > > Draft-allan-mpls-pid-00.txt is not accessible anymore. > I don't recall what rationale it gave for the need for a > PTI. > FB: Dave addressed the need for an MPLS PID one year ago > from an overall MPLS perspective: e.g. issues arisen > from loadsharing on TE link bundles or ECMP in LDP > network, OAM extensibility, Multiprotocol over MPLS... > > Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as > the sole reason for an additional control word. However, > introducing PTI to solve the issues related to ECMP > seems overkill. It would be good if we can clearly state > why we need a PTI. > FB I agree with you that the justification in section 4 > for PTI versus CW + VCCV could be improved. On the other > hand we need the extensibility provided by a PTI/PID: > VCCV is just an instantiation of a PTI if you think > about it, just the formats need to be aligned. > Whether or not is a good idea to move the PW user data > to 0001 format is to be debated. We need to make sure > though the 2 formats could coexist in a network in the > mean time. > > Peter > > -----Original Message----- > From: Florin Balus > [mailto:balus@nortelnetworks.com] > Sent: Wednesday, August 11, 2004 2:17 PM > To: Stewart Bryant > Cc: pwe3@ietf.org > Subject: RE: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt WG > request > > Stewart, > > We did promote the idea of a PID/PTI - see > Dave Allan's draft-allan-mpls-pid-00.txt on > the subject. Also I think the explanation of > ECMP issue (disambiguate from IP/MPLS packets > etc) and the overall proposed solution are > valid. > > I just wanted to clarify some technicalities > to make sure we clearly identify where we are > headed to - i.e. what changes are required in > other PWE3 drafts. > > Assuming we have in the same network PEs that > support both formats: > - the CW [(0000 CW stuff)(data) & the current > VCCV format (0001 PA PPP_DLL)(OAM payload))] > - and the newly defined PTI (0001 > PTI)(data/VCCV payload/?whatever?). > In the same time let's assume other PEs will > accept just the PTI - being part of those > implementations that do not support 0000. How > are we going to ensure the 2 sets of PEs will > be able to negotiate in the control plane the > right format? > > Currently we do have in each of the 2 L2 FECs > (PWID and Generalized ID) just one bit to > determine whether or not the CW should be used > - see draft-ietf-pwe3-control-protocol-07.txt > section 5.1 and 5.2.2. 0001 implicitly meant > up to now VCCV format. How do we differentiate > the other 2 possibilities (PTI yes/no)? > > Also just to make sure I understood correctly: > there are some PW types for which the CW is > REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 > SDU Frame Mode - see > draft-ietf-pwe3-atm-encap-05.txt section > 4.3.2). For a PE that will implement the PTI > format are we saying the PW frames (after the > 2 labels) will look like this: (0001 > PTI)(0000 CW stuff)(data)? > > Is VCCV/OAM going to be differentiated in the > same way, just re-using what is already > defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM > payload)? If not I assume we will need to > clarify the PTI code points that are going to > be used for VCCV/OAM payload? > > Thanks for clarifying the above points. > Regards, > Florin > > -----Original Message----- > From: pwe3-bounces@ietf.org > [mailto:pwe3-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Monday, August 09, 2004 7:54 AM > To: pwe3@ietf.org > Subject: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt WG > request > > The authors request that > > http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt > > be adopted as a WG item with its title changed > to > > PWE3 MPLS Control Word > > - Stewart > > _______________________________________________ > > 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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Florin Balus" Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Thu, 12 Aug 2004 13:42:16 -0400 Lines: 603 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1625025067==" Cc: "Busschbach, Peter B \(Peter\)" , pwe3@ietf.org, Jeffrey Sugimoto , Stewart Bryant X-From: pwe3-bounces@ietf.org Thu Aug 12 20:01:05 2004 Return-path: To: Mustapha Aissaoui X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org 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. --===============1625025067== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48093.B5469F59" 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_01C48093.B5469F59 Content-Type: text/plain Right. I was just saying that could be added to draft-bryant-mcpherson-pwe3-cw-00.txt as another motivator. -----Original Message----- From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] Sent: Thursday, August 12, 2004 1:30 PM To: Balus, Florin [CAR:6955:EXCH] Cc: Busschbach, Peter B (Peter); Stewart Bryant; pwe3@ietf.org; Sugimoto, Jeffrey [CAR:6955:EXCH] Subject: Re: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Florin, I think the intent is that if you want to use the VCCV CW (0001 nibble) on OAM packets, then you are required to use the regular CW (000 nibble) on the user packets. Otherwise, you will have to use the alert label option for OAM packets but this may not work with ECMP. Mustapha. ------------ > Florin Balus wrote: > > Peter, > See in-line... > > Stewart, > There might be another motivator for a mandatory CW/consolidation > under PTI: assuming we have a PW type that does not mandate a CW (ATM > N to one cell mode) couldn't we get payloads that are mistaken also > for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could be > interpreted by the receiving PE as 0001? (thanks Jeff for bringing > this up) > > Regards, > Florin > > -----Original Message----- > From: Busschbach, Peter B (Peter) > [mailto:busschbach@lucent.com] > Sent: Wednesday, August 11, 2004 2:41 PM > To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant > Cc: pwe3@ietf.org > Subject: RE: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt WG request > > Florus, > > Draft-allan-mpls-pid-00.txt is not accessible anymore. > I don't recall what rationale it gave for the need for a > PTI. > FB: Dave addressed the need for an MPLS PID one year ago > from an overall MPLS perspective: e.g. issues arisen > from loadsharing on TE link bundles or ECMP in LDP > network, OAM extensibility, Multiprotocol over MPLS... > > Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as > the sole reason for an additional control word. However, > introducing PTI to solve the issues related to ECMP > seems overkill. It would be good if we can clearly state > why we need a PTI. > FB I agree with you that the justification in section 4 > for PTI versus CW + VCCV could be improved. On the other > hand we need the extensibility provided by a PTI/PID: > VCCV is just an instantiation of a PTI if you think > about it, just the formats need to be aligned. > Whether or not is a good idea to move the PW user data > to 0001 format is to be debated. We need to make sure > though the 2 formats could coexist in a network in the > mean time. > > Peter > > -----Original Message----- > From: Florin Balus > [mailto:balus@nortelnetworks.com] > Sent: Wednesday, August 11, 2004 2:17 PM > To: Stewart Bryant > Cc: pwe3@ietf.org > Subject: RE: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt WG > request > > Stewart, > > We did promote the idea of a PID/PTI - see > Dave Allan's draft-allan-mpls-pid-00.txt on > the subject. Also I think the explanation of > ECMP issue (disambiguate from IP/MPLS packets > etc) and the overall proposed solution are > valid. > > I just wanted to clarify some technicalities > to make sure we clearly identify where we are > headed to - i.e. what changes are required in > other PWE3 drafts. > > Assuming we have in the same network PEs that > support both formats: > - the CW [(0000 CW stuff)(data) & the current > VCCV format (0001 PA PPP_DLL)(OAM payload))] > - and the newly defined PTI (0001 > PTI)(data/VCCV payload/?whatever?). > In the same time let's assume other PEs will > accept just the PTI - being part of those > implementations that do not support 0000. How > are we going to ensure the 2 sets of PEs will > be able to negotiate in the control plane the > right format? > > Currently we do have in each of the 2 L2 FECs > (PWID and Generalized ID) just one bit to > determine whether or not the CW should be used > - see draft-ietf-pwe3-control-protocol-07.txt > section 5.1 and 5.2.2. 0001 implicitly meant > up to now VCCV format. How do we differentiate > the other 2 possibilities (PTI yes/no)? > > Also just to make sure I understood correctly: > there are some PW types for which the CW is > REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 > SDU Frame Mode - see > draft-ietf-pwe3-atm-encap-05.txt section > 4.3.2). For a PE that will implement the PTI > format are we saying the PW frames (after the > 2 labels) will look like this: (0001 > PTI)(0000 CW stuff)(data)? > > Is VCCV/OAM going to be differentiated in the > same way, just re-using what is already > defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM > payload)? If not I assume we will need to > clarify the PTI code points that are going to > be used for VCCV/OAM payload? > > Thanks for clarifying the above points. > Regards, > Florin > > -----Original Message----- > From: pwe3-bounces@ietf.org > [mailto:pwe3-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Monday, August 09, 2004 7:54 AM > To: pwe3@ietf.org > Subject: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt WG > request > > The authors request that > > > http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00. > txt > > be adopted as a WG item with its title changed > to > > PWE3 MPLS Control Word > > - Stewart > > _______________________________________________ > > 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 ------_=_NextPart_001_01C48093.B5469F59 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG = request

Right. I was just saying that could be added to = draft-bryant-mcpherson-pwe3-cw-00.txt as another motivator.

-----Original Message-----
From: Mustapha Aissaoui [mailto:mustapha.aissaoui@a= lcatel.com]
Sent: Thursday, August 12, 2004 1:30 PM
To: Balus, Florin [CAR:6955:EXCH]
Cc: Busschbach, Peter B (Peter); Stewart Bryant; = pwe3@ietf.org; Sugimoto, Jeffrey [CAR:6955:EXCH]
Subject: Re: [PWE3] = draft-bryant-mcpherson-pwe3-cw-00.txt WG request


Florin,
I think the intent is that if you want to use the = VCCV CW (0001
nibble) on OAM packets, then you are required to use = the regular CW (000 nibble) on the user packets. Otherwise, you will = have to use the alert label option for OAM packets but this may not = work with ECMP.

Mustapha.
------------
> Florin Balus wrote:
>
> Peter,
> See in-line...
>
> Stewart,
> There might be another motivator for a = mandatory CW/consolidation
> under PTI: assuming we have a PW type that does = not mandate a CW (ATM
> N to one cell mode) couldn't we get payloads = that are mistaken also
> for 0001/VCCV packets - e.g. VPI 64 in an ATM = cell could be
> interpreted by the receiving PE as 0001? = (thanks Jeff for bringing
> this up)
>
> Regards,
> Florin
>
>      -----Original = Message-----
>      From: Busschbach, = Peter B (Peter)
>      [mailto:busschbach@lucent.com]<= /FONT>
>      Sent: Wednesday, = August 11, 2004 2:41 PM
>      To: Balus, Florin = [CAR:6955:EXCH]; Stewart Bryant
>      Cc: = pwe3@ietf.org
>      Subject: RE: = [PWE3]
>      = draft-bryant-mcpherson-pwe3-cw-00.txt WG request
>
>      Florus,
>
>      = Draft-allan-mpls-pid-00.txt  is not accessible anymore.
>      I don't recall = what rationale it gave for the need for a
>      PTI.
>      FB: Dave = addressed the need for an MPLS PID one year ago
>      from an overall = MPLS perspective: e.g. issues arisen
>      from loadsharing = on TE link bundles or ECMP in LDP
>      network,  = OAM extensibility, Multiprotocol over MPLS...
>
>      = Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as
>      the sole reason = for an additional control word. However,
>      introducing PTI = to solve the issues related to ECMP
>      seems overkill. = It would be good if we can clearly state
>      why we need a = PTI.
>      FB I agree with = you that the justification in section 4
>      for PTI versus CW = + VCCV could be improved. On the other
>      hand we need the = extensibility provided by a PTI/PID:
>      VCCV is just an = instantiation of a PTI if you think
>      about it, just = the formats need to be aligned.
>      Whether or not is = a good idea to move the PW user data
>      to 0001 format is = to be debated. We need to make sure
>      though the 2 = formats could coexist in a network in the
>      mean time.
>
>      Peter
>
>          = ; -----Original Message-----
>          = ; From: Florin Balus
>          = ; [mailto:balus@nortelnetworks.com= ]
>          = ; Sent: Wednesday, August 11, 2004 2:17 PM
>          = ; To: Stewart Bryant
>          = ; Cc: pwe3@ietf.org
>          = ; Subject: RE: [PWE3]
>          = ; draft-bryant-mcpherson-pwe3-cw-00.txt WG
>          = ; request
>
>          = ; Stewart,
>
>          = ; We did promote the idea of a PID/PTI - see
>          = ; Dave Allan's draft-allan-mpls-pid-00.txt on
>          = ; the subject. Also I think the explanation of
>          = ; ECMP issue (disambiguate from IP/MPLS packets
>          = ; etc) and the overall proposed solution are
>          = ; valid.
>
>          = ; I just wanted to clarify some technicalities
>        &= nbsp;  to make sure we clearly identify where we are
>          = ; headed to - i.e. what changes are required in
>          = ; other PWE3 drafts.
>
>          = ; Assuming we have in the same network PEs that
>          = ; support both formats:
>          = ;  - the CW [(0000 CW stuff)(data) & the current
>          = ; VCCV format (0001 PA PPP_DLL)(OAM payload))]
>          = ;  - and the newly defined PTI (0001
>          = ; PTI)(data/VCCV payload/?whatever?).
>          = ; In the same time let's assume other PEs will
>          = ; accept just the PTI - being part of those
>          = ; implementations that do not support 0000. How
>          = ; are we going to ensure the 2 sets of PEs will
>          = ; be able to negotiate in the control plane the
>          = ; right format?
>
>          = ; Currently we do have in each of the 2 L2 FECs
>          = ; (PWID and Generalized ID) just one bit to
>          = ; determine whether or not the CW should be used
>          = ; - see draft-ietf-pwe3-control-protocol-07.txt
>          = ; section 5.1 and 5.2.2. 0001 implicitly meant
>          = ; up to now VCCV format. How do we differentiate
>          = ; the other 2 possibilities (PTI yes/no)?
>
>          = ; Also just to make sure I understood correctly:
>          = ; there are some PW types for which the CW is
>          = ; REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5
>          = ; SDU Frame Mode - see
>          = ; draft-ietf-pwe3-atm-encap-05.txt section
>          = ; 4.3.2). For a PE that will implement the PTI
>          = ; format are we saying the PW frames (after the
>          = ; 2 labels) will look like this: (0001
>          = ; PTI)(0000 CW stuff)(data)?
>
>          = ; Is VCCV/OAM going to be differentiated in the
>          = ; same way, just re-using what is already
>          = ; defined: i.e. (0001  PTI)(0001 PA PPP_DLL)(OAM
>          = ; payload)? If not I assume we will need to
>          = ; clarify the PTI code points that are going to
>          = ; be used for VCCV/OAM payload?
>
>          = ; Thanks for clarifying the above points.
>          = ; Regards,
>          = ; Florin
>
>          = ; -----Original Message-----
>          = ; From: pwe3-bounces@ietf.org
>          = ; [mailto:pwe3-bounces@ietf.org] = On Behalf Of
>          = ; Stewart Bryant
>          = ; Sent: Monday, August 09, 2004 7:54 AM
>          = ; To: pwe3@ietf.org
>          = ; Subject: [PWE3]
>          = ; draft-bryant-mcpherson-pwe3-cw-00.txt WG
>          = ; request
>
>          = ; The authors request that
>
>          = ;
> http://www.ietf.org/internet-drafts/draft-bryant-mcphe= rson-pwe3-cw-00.
> txt
>
>          = ; be adopted as a WG item with its title changed
>          = ; to
>
>          = ; PWE3 MPLS Control Word
>
>          = ; - Stewart
>
>          = ; _______________________________________________
>
>          = ; 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=

------_=_NextPart_001_01C48093.B5469F59-- --===============1625025067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1625025067==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-cell-transport-00.txt Date: Thu, 12 Aug 2004 15:31:09 -0400 Lines: 97 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Aug 12 22:36:46 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 ATM Transparent Cell Transport Service Author(s) : A. Malis, et al. Filename : draft-ietf-pwe3-cell-transport-00.txt Pages : 3 Date : 2004-8-12 The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for PWE3 ATM cell encapsulation described in [ATM-ENCAPS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cell-transport-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-pwe3-cell-transport-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-ietf-pwe3-cell-transport-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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Cheng-Yin Lee Subject: Re: Scaling hierarchical LDP/PW stitching Date: Thu, 12 Aug 2004 16:14:39 -0400 Lines: 46 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, busschbach@lucent.com, pwe3@ietf.org, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Aug 12 22:56:41 2004 Return-path: X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en To: richard.spencer@bt.com X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard, > Regarding PW end point identifiers for routing purposes, as things stand today I think out of the two > options below, routing based on PE IP addresses (option a) is preferable to using AGI/AII combinations > (option b). The main reasons being: > > (1) From the PWE3 control draft: "The Attachment Identifier must be unique in the context of the PE > router in which the Forwarder resides. The combination must be globally unique." So, > even if the AGI/AII are used, the PE IP addresses must be used as well anyway. > > (2) Reachability information based on [AGI/AII/PE IP address] destination identifiers would need to be > advertised and stored in a routing table (if a dynamic routing protocol is used) on each PE and PW > switching node. This does not seem desirable looking at things from a vendors perspective because the > PW routing table implementation would need to support variable/unknown length identifiers as > destinations. > > I agree routing based on PE IP addresses is preferable. But I have doubts with the need to store [AGI/AII/PE IP address] or the PW endpoint identifiers in routing tables at PW switching nodes. For e.g. assume there is a routing protocol which advertises PW switching nodes (and capability) and PE links/routes.. Then routing at PE-X knows the next-hop to PE-Y for a PW (to PE-Y, AIY) is PW-SW1 (PW Switching node). Similarly routing at PW-SW1 knows the next-hop to PE-Y is PW-SW2. There is no need to store PEY+AIY information in the routing table. [The PEY+AIY information can be stored by signaling]. AIX---PE-X----PW-SW1---PW-SW2----PE-Y---AIY As you suggest using IPv6 for PW endpoint identifier may be convenient from OAM perspective, for e.g. to be able to identify at each PW switching hop where the PW is routed, but the PW could also be identified by the PE+AI address ( stored by signaling in either case). It is possible to route PW based on PE+AI, but is it necessary? What am I missing? Thanks Cheng-Yin richard.spencer@bt.com wrote: > Cheng-Yin, > > > Could we not decouple VPN membership discovery from routing ? > > VPN membership discovery is already decoupled from routing. In the MH-PW case there are two aspects to discovery, i) discovery of PW endpoints and ii) discovery of PW switching capable nodes. Discovery of VPN endpoints is always required as these are not known prior to PW provisioning, i.e. the endpoints are not known until a provider receives the customer request for the VPN. > > However, discovery of PW switching points is only required because the same (IP loopback) address space is used at the client PW layer that is used at the MPLS tunnel server layer. A MH-PW next hop must always be a PW switching capable node (or the destination endpoint PE), and therefore non PW switching nodes must be distinguished from those that do support PW switching. > > As discussed on the list, one way to solve the problem and keep the same addressing would be to use a discovery mechanism along with a separate PW routing table that only contains routing information for MH-PW source/destination PEs and PW-switching capable nodes, i.e. routing information pertinent only to the PW layer. Another way to solve the problem and keep the same addressing would be to use FA-LSPs and routing metrics to ensure that FA-LSPs are always the best next hop. Discovery of PW switching capable nodes in this solution is implicit, i.e. the best next hop to a PW endpoint by implication should be PW switching capable. > > Regards, > Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Fri, 13 Aug 2004 15:16:11 -0400 Lines: 417 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0199388123==" Cc: pwe3@ietf.org, Jeffrey Sugimoto X-From: pwe3-bounces@ietf.org Fri Aug 13 21:27:22 2004 Return-path: To: "'Florin Balus'" , Stewart Bryant X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org 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. --===============0199388123== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48169.FE754E0A" 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_01C48169.FE754E0A Content-Type: text/plain Florin, You write: "On the other hand we need the extensibility provided by a PTI/PID: VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned". I agree that VCCV is one instantiation of a protocol that could be carried over a PW. However, the point I raised in an earlier email is whether there are other instantiations. Because, if VCCV is the *only* instantation, you don't need a PID, but just a way to differentate VCCV traffic from the PW payload traffic. That said, this email thread has made a few things clear: 1) As Mustapha observed, even if you don't need to identify the PW payload traffic, you might still need to differentiate between different types of OAM traffic 2) As you observed, if you run VCCV traffic over a Pseudo Wire, then a Control Word , be it CW or PTI, must necessarily preceed all payload and OAM traffic. 3) draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical considerations result in a PW Control Word that could be mistaken for an IP packet, the Control Word SHOULD be preceded by a PWE3 PTI." However, as we all seem to agree on, a CW will never be mistaken for an IP packet. Therefore, rather than proposing a PTI that preceded a CW, I think the following solution would be sufficient and more elegant: If the PW does not carry VCCV traffic, a CW is only mandatory if specified in the relevant encapsulation draft If the PW carries VCCV traffic, then: a) all payload traffic MUST be preceded by a Control Word that starts with 0000 b) all VCCV traffic MUSTbe preceded by an "OAM Protocol Identifier" (OPI), which has the following format: [0001 | resv | protocol id], where protocol id identifies one of the following protocols: LSP Ping, ICMP, BFD, Y.1711, other(?). Peter -----Original Message----- From: Florin Balus [mailto:balus@nortelnetworks.com] Sent: Thursday, August 12, 2004 12:42 PM To: Busschbach, Peter B (Peter); Stewart Bryant Cc: pwe3@ietf.org; Jeffrey Sugimoto Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Peter, See in-line... Stewart, There might be another motivator for a mandatory CW/consolidation under PTI: assuming we have a PW type that does not mandate a CW (ATM N to one cell mode) couldn't we get payloads that are mistaken also for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could be interpreted by the receiving PE as 0001? (thanks Jeff for bringing this up) Regards, Florin -----Original Message----- From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] Sent: Wednesday, August 11, 2004 2:41 PM To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Florus, Draft-allan-mpls-pid-00.txt is not accessible anymore. I don't recall what rationale it gave for the need for a PTI. FB: Dave addressed the need for an MPLS PID one year ago from an overall MPLS perspective: e.g. issues arisen from loadsharing on TE link bundles or ECMP in LDP network, OAM extensibility, Multiprotocol over MPLS... Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI. FB I agree with you that the justification in section 4 for PTI versus CW + VCCV could be improved. On the other hand we need the extensibility provided by a PTI/PID: VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned. Whether or not is a good idea to move the PW user data to 0001 format is to be debated. We need to make sure though the 2 formats could coexist in a network in the mean time. Peter -----Original Message----- From: Florin Balus [mailto:balus@nortelnetworks.com] Sent: Wednesday, August 11, 2004 2:17 PM To: Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Stewart, We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid. I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts. Assuming we have in the same network PEs that support both formats: - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))] - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?). In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format? Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)? Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001 PTI)(0000 CW stuff)(data)? Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload? Thanks for clarifying the above points. Regards, Florin -----Original Message----- From: pwe3-bounces@ietf.org [ mailto:pwe3-bounces@ietf.org ] On Behalf Of Stewart Bryant Sent: Monday, August 09, 2004 7:54 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request The authors request that http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt be adopted as a WG item with its title changed to PWE3 MPLS Control Word - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C48169.FE754E0A Content-Type: text/html Message
Florin,
 
You write: "On the other hand we need the extensibility provided by a PTI/PID:  VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned".
 
I agree that VCCV is one instantiation of a protocol that could be carried over a PW. However, the point I raised in an earlier email is whether there are other instantiations. Because, if VCCV is the *only* instantation, you don't need a PID, but just a way to differentate VCCV traffic from the PW payload traffic.
 
That said, this email thread has made a few things clear:
 
1) As Mustapha observed, even if you don't need to identify the PW payload traffic, you might still need to differentiate between different types of OAM traffic
 
2) As you observed, if you run VCCV traffic over a Pseudo Wire, then a Control Word , be it CW or PTI, must necessarily preceed all payload and OAM traffic.
 
3)  draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical considerations result in a PW Control Word that could be mistaken for an IP packet, the Control Word SHOULD be preceded by a PWE3 PTI." However, as we all seem to agree on, a CW will never be mistaken for an IP packet.
 
Therefore, rather than proposing a PTI that preceded a CW, I think the following solution would be sufficient and more elegant:
 
If the PW does not carry VCCV traffic, a CW is only mandatory if specified in the relevant encapsulation draft
 
If the PW carries VCCV traffic, then:
 
a) all payload traffic MUST be preceded by a Control Word that starts with 0000
 
b) all VCCV traffic MUSTbe preceded by an "OAM Protocol Identifier" (OPI), which has the following format:
 
    [0001 | resv | protocol id],
 
where protocol id identifies one of the following protocols: LSP Ping, ICMP, BFD, Y.1711, other(?).
 
Peter
-----Original Message-----
From: Florin Balus [mailto:balus@nortelnetworks.com]
Sent: Thursday, August 12, 2004 12:42 PM
To: Busschbach, Peter B (Peter); Stewart Bryant
Cc: pwe3@ietf.org; Jeffrey Sugimoto
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Peter,
See in-line...
 
Stewart,
There might be another motivator for a mandatory CW/consolidation under PTI: assuming we have a PW type that does not mandate a CW (ATM N to one cell mode) couldn't we get payloads that are mistaken also for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could be interpreted by the receiving PE as 0001? (thanks Jeff for bringing this up)
 
Regards,
Florin
-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
Sent: Wednesday, August 11, 2004 2:41 PM
To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant
Cc: pwe3@ietf.org
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible anymore. I don't recall what rationale it gave for the need for a PTI.
FB: Dave addressed the need for an MPLS PID one year ago from an overall MPLS perspective: e.g. issues arisen from loadsharing on TE link bundles or ECMP in LDP network,  OAM extensibility, Multiprotocol over MPLS...
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI.
FB I agree with you that the justification in section 4 for PTI versus CW + VCCV could be improved. On the other hand we need the extensibility provided by a PTI/PID:  VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned.
Whether or not is a good idea to move the PW user data to 0001 format is to be debated. We need to make sure though the 2 formats could coexist in a network in the mean time.
 
Peter 
-----Original Message-----
From: Florin Balus [mailto:balus@nortelnetworks.com]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: pwe3@ietf.org
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request


Stewart,

We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid.

I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts.

Assuming we have in the same network PEs that support both formats:
 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))]
 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?).
In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format?


Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001  PTI)(0000 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001  PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload?

Thanks for clarifying the above points.
Regards,
Florin


-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, August 09, 2004 7:54 AM
To: pwe3@ietf.org
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request


The authors request that

http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt

be adopted as a WG item with its title changed to

PWE3 MPLS Control Word

- Stewart







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

------_=_NextPart_001_01C48169.FE754E0A-- --===============0199388123== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0199388123==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Andrew G. Malis" Subject: Fwd: I-D ACTION:draft-ietf-pwe3-cell-transport-00.txt Date: Fri, 13 Aug 2004 07:18:36 -0400 Lines: 83 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-bounces@ietf.org Fri Aug 13 22:42:55 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: "PWE3 (IETF)" X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org To change the email topic for a minute away from PW stitching, the authors believe that this draft is ready for WG last call, and would like to request same. It documents an application for ATM N-to-1 cell encapsulation that is already in operational use. Thanks, Andy ------- Begin of Forwarded Message ------- To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 12 Aug 2004 15:31:09 -0400 Cc: pwe3@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-cell-transport-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 ATM Transparent Cell Transport Service Author(s) : A. Malis, et al. Filename : draft-ietf-pwe3-cell-transport-00.txt Pages : 3 Date : 2004-8-12 The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for PWE3 ATM cell encapsulation described in [ATM-ENCAPS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cell-transport-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-pwe3-cell-transport-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-ietf-pwe3-cell-transport-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. Content-Type: text/plain Content-ID: <2004-8-12143911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-cell-transport-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------- End of Forwarded Message ------- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Mon, 16 Aug 2004 11:05:19 +0100 Lines: 799 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1244914625==" Cc: pwe3@ietf.org, sugimoto@nortelnetworks.com X-From: pwe3-bounces@ietf.org Mon Aug 16 12:13:47 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Thread-Index: AcSBa8eGg/kw19A3SaKjpwUfqDrZewCANJQg To: , , X-OriginalArrivalTime: 16 Aug 2004 10:05:20.0557 (UTC) FILETIME=[89DE2DD0:01C48378] X-Scan-Signature: 69fdda0fad34612ba96c69ba1eef6423 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1244914625== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48378.89878B00" This is a multi-part message in MIME format. ------_=_NextPart_001_01C48378.89878B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter, =20 The point made by Mustapha is conceptually right but should be stated like this: "In a layer network the traffic and OAM must be able to be differentiated." =20 So this ought to be a design consideration for the layer network technology right from the outset. But please also note that the nature of the data-plane behaviour (including the defects it can experience) is different in each of the 3 networking modes. =20 =20 The OAM required for IP is therefore not the same as the OAM required for MPLS....and neither is the same as the OAM required for SDH (as an example of a co-cs technology). =20 I do wish this could be understood/accepted as its simply a fact. =20 Now if folks want to create OAM for PWs then please be under no illusion that PWs will need to be considered as a layer network in their own right.....indeed, the notion of 'PW switching' is a clear confirmation of this direction. Note that the OAM required for the server IP or MPLS networks is something else. So one is now creating a client/server relationship between 3 layer networks that looks like either: - X/PW/IP, or - X/PW/MPLS, or - if folks embraced Ping's ideas for 'PWs over anything' X/PW/SDH (other)' =20 This is where the WG is now heading. I don't think we need to go here as I do not believe it is required, and certainly not from our perspective. There is no need for PW switching IMO for a large operator like BT seeking convergence on MPLS, nor do I beleive this is warranted for the Internet either. We do however, want the right sort of OAM for MPLS and all we need for XoverMPLS is a simple client/server adaptation relationship. IMO folks are creating complexities where they are simply not required and I am completely unclear *who* this stuff is being written for. =20 regards, Neil =20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Busschbach, Peter B (Peter) Sent: 13 August 2004 20:16 To: 'Florin Balus'; Stewart Bryant Cc: pwe3@ietf.org; Jeffrey Sugimoto Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Florin, =20 You write: "On the other hand we need the extensibility provided by a PTI/PID: VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned". =20 I agree that VCCV is one instantiation of a protocol that could be carried over a PW. However, the point I raised in an earlier email is whether there are other instantiations. Because, if VCCV is the *only* instantation, you don't need a PID, but just a way to differentate VCCV traffic from the PW payload traffic. =20 That said, this email thread has made a few things clear: =20 1) As Mustapha observed, even if you don't need to identify the PW payload traffic, you might still need to differentiate between different types of OAM traffic =20 2) As you observed, if you run VCCV traffic over a Pseudo Wire, then a Control Word , be it CW or PTI, must necessarily preceed all payload and OAM traffic. =20 3) draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical considerations result in a PW Control Word that could be mistaken for an IP packet, the Control Word SHOULD be preceded by a PWE3 PTI." However, as we all seem to agree on, a CW will never be mistaken for an IP packet. =20 Therefore, rather than proposing a PTI that preceded a CW, I think the following solution would be sufficient and more elegant: =20 If the PW does not carry VCCV traffic, a CW is only mandatory if specified in the relevant encapsulation draft =20 If the PW carries VCCV traffic, then: =20 a) all payload traffic MUST be preceded by a Control Word that starts with 0000 =20 b) all VCCV traffic MUSTbe preceded by an "OAM Protocol Identifier" (OPI), which has the following format: =20 [0001 | resv | protocol id], =20 where protocol id identifies one of the following protocols: LSP Ping, ICMP, BFD, Y.1711, other(?). =20 Peter -----Original Message----- From: Florin Balus [mailto:balus@nortelnetworks.com] Sent: Thursday, August 12, 2004 12:42 PM To: Busschbach, Peter B (Peter); Stewart Bryant Cc: pwe3@ietf.org; Jeffrey Sugimoto Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Peter, See in-line... =20 Stewart, There might be another motivator for a mandatory CW/consolidation under PTI: assuming we have a PW type that does not mandate a CW (ATM N to one cell mode) couldn't we get payloads that are mistaken also for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could be interpreted by the receiving PE as 0001? (thanks Jeff for bringing this up) =20 Regards, Florin -----Original Message----- From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]=20 Sent: Wednesday, August 11, 2004 2:41 PM To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Florus, =20 Draft-allan-mpls-pid-00.txt is not accessible anymore. I don't recall what rationale it gave for the need for a PTI. FB: Dave addressed the need for an MPLS PID one year ago from an overall MPLS perspective: e.g. issues arisen from loadsharing on TE link bundles or ECMP in LDP network, OAM extensibility, Multiprotocol over MPLS... =20 Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI. FB I agree with you that the justification in section 4 for PTI versus CW + VCCV could be improved. On the other hand we need the extensibility provided by a PTI/PID: VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned.=20 Whether or not is a good idea to move the PW user data to 0001 format is to be debated. We need to make sure though the 2 formats could coexist in a network in the mean time. =20 Peter=20 -----Original Message----- From: Florin Balus [mailto:balus@nortelnetworks.com] Sent: Wednesday, August 11, 2004 2:17 PM To: Stewart Bryant Cc: pwe3@ietf.org Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Stewart,=20 We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid. I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts. Assuming we have in the same network PEs that support both formats:=20 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))]=20 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?).=20 In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format? Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)? Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001 PTI)(0000 CW stuff)(data)? Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001 PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload?=20 Thanks for clarifying the above points.=20 Regards,=20 Florin=20 -----Original Message-----=20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant=20 Sent: Monday, August 09, 2004 7:54 AM=20 To: pwe3@ietf.org=20 Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request=20 The authors request that=20 http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.tx t=20 be adopted as a WG item with its title changed to=20 PWE3 MPLS Control Word=20 - Stewart=20 _______________________________________________=20 pwe3 mailing list=20 pwe3@ietf.org=20 https://www1.ietf.org/mailman/listinfo/pwe3=20 ------_=_NextPart_001_01C48378.89878B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Peter,
 
The point made by Mustapha is conceptually right but should be = stated=20 like this:  "In a layer network the traffic and OAM must be able to = be=20 differentiated."
 
So this ought to be a design consideration for the layer = network=20 technology right from the outset.  But please also note that the = nature of=20 the data-plane behaviour (including the defects it can experience) is = different=20 in each of the 3 networking modes.   
 
The OAM required for IP is therefore not the same as the OAM = required for=20 MPLS....and neither is the same as the OAM required for SDH (as an = example of a=20 co-cs technology).
 
I do wish this could be understood/accepted as its simply a=20 fact.
 
Now if folks want to create OAM for PWs then please be = under no=20 illusion that PWs will need to be considered as a layer network in their = own=20 right.....indeed, the notion of 'PW switching' is a clear confirmation = of this=20 direction.  Note that the OAM required for the server IP or MPLS = networks=20 is something else.  So one is now creating a client/server = relationship=20 between 3 layer networks that looks like either:
-    X/PW/IP, or
-    X/PW/MPLS, or
-    if folks embraced Ping's ideas for 'PWs = over=20 anything' X/PW/SDH (other)'
 
This is where the WG is now heading.  I don't think we = need to go=20 here as I do not believe it is required, and certainly not from our=20 perspective.  There is no need for PW = switching IMO=20 for a large operator like BT seeking convergence on MPLS, nor do I = beleive=20 this is warranted for the Internet either.  We do however, = want the=20 right sort of OAM for MPLS and all we need for XoverMPLS is a simple=20 client/server adaptation relationship.  IMO folks are creating = complexities=20 where they are simply not required and I am completely unclear *who* = this stuff=20 is being written for.
 
regards, Neil
 
-----Original Message-----
From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of=20 Busschbach, Peter B (Peter)
Sent: 13 August 2004=20 20:16
To: 'Florin Balus'; Stewart Bryant
Cc:=20 pwe3@ietf.org; Jeffrey Sugimoto
Subject: RE: [PWE3]=20 draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florin,
 
You = write: "On the other=20 hand we need the extensibility provided by a PTI/PID:  VCCV = is just=20 an instantiation of a PTI if you think about it, just the formats need = to be=20 aligned".
=
 
I agree that VCCV is one instantiation of a = protocol=20 that could be carried over a PW. However, the point I raised in an = earlier=20 email is whether there are other instantiations. Because, if VCCV is = the=20 *only* instantation, you don't need a PID, but just a way to = differentate VCCV=20 traffic from the PW payload = traffic.
 
That said, this email thread has made a few = things=20 clear:
 
1) As Mustapha observed, even if you don't = need to=20 identify the PW payload traffic, you might still need to differentiate = between=20 different types of OAM = traffic
 
2) As you observed, if you run VCCV traffic = over a=20 Pseudo Wire, then a Control Word , be it CW or PTI, must necessarily = preceed=20 all payload and OAM traffic.
 
3)  draft-bryant-mcpherson-pwe3-cw-00.txt states: = "If=20 technical considerations result in a PW Control Word that = could be=20 mistaken for an IP packet, the Control Word SHOULD be preceded = by a PWE3=20 PTI." However, as we all seem to agree on, a CW will never be mistaken = for an=20 IP packet.
 
Therefore, rather than proposing a PTI that = preceded=20 a CW, I think the following solution would be sufficient and more=20 elegant:
 
If the PW does not carry VCCV traffic, a CW = is only=20 mandatory if specified in the relevant encapsulation=20 draft
 
If the PW carries VCCV traffic,=20 then:
 
a) all payload traffic MUST be preceded by = a Control=20 Word that starts with 0000
 
b) all VCCV traffic MUSTbe preceded by an "OAM Protocol = Identifier"=20 (OPI), which has the following=20 format:
 
    [0001 | resv | protocol=20 id],
 
where protocol id=20 identifies one of the following protocols: LSP Ping, ICMP, BFD, = Y.1711,=20 other(?).
 
Peter
-----Original Message-----
From: Florin Balus=20 [mailto:balus@nortelnetworks.com]
Sent: Thursday, August = 12, 2004=20 12:42 PM
To: Busschbach, Peter B (Peter); Stewart=20 Bryant
Cc: pwe3@ietf.org; Jeffrey = Sugimoto
Subject: RE:=20 [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG = request

Peter,
See in-line...
 
Stewart,
There might be another motivator for a = mandatory=20 CW/consolidation under PTI: assuming we have a PW type that does not = mandate=20 a CW (ATM N to one cell mode) couldn't we get payloads=20 that are mistaken also for 0001/VCCV packets - e.g. VPI 64 = in an=20 ATM cell could be interpreted by the receiving PE as 0001? (thanks Jeff for bringing this=20 up)
 
Regards,
Florin
-----Original Message-----
From: = Busschbach,=20 Peter B (Peter) [mailto:busschbach@lucent.com]
Sent: = Wednesday,=20 August 11, 2004 2:41 PM
To: Balus, Florin = [CAR:6955:EXCH];=20 Stewart Bryant
Cc: pwe3@ietf.org
Subject: RE: = [PWE3]=20 draft-bryant-mcpherson-pwe3-cw-00.txt WG = request

Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible = anymore. I=20 don't recall what rationale it gave for the need for a=20 PTI.
FB: Dave addressed the need for an MPLS PID one year ago = from an=20 overall MPLS perspective: e.g. issues arisen from loadsharing on = TE link=20 bundles or ECMP in LDP network,  OAM extensibility, = Multiprotocol=20 over MPLS...
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as = the sole=20 reason for an additional control word. However, introducing = PTI to=20 solve the issues related to ECMP seems overkill. It would be = good if=20 we can clearly state why we need a PTI.
FB I agree with you that the justification in = section 4 for=20 PTI versus CW + VCCV could be improved.=20 On the other hand we = need the=20 extensibility provided by a PTI/PID:  VCCV is just an = instantiation=20 of a PTI if you think about it, just the formats need to be = aligned.=20
Whether or not is a good idea to move the PW user data to = 0001=20 format is to be debated. We need to make sure though the 2 formats = could=20 coexist in a network in the mean = time.
 
Peter 
-----Original Message-----
From: Florin Balus = [mailto:balus@nortelnetworks.com]
Sent: Wednesday, = August 11,=20 2004 2:17 PM
To: Stewart Bryant
Cc:=20 pwe3@ietf.org
Subject: RE: [PWE3]=20 draft-bryant-mcpherson-pwe3-cw-00.txt WG=20 request


Stewart,

We did promote the idea of a PID/PTI - see = Dave Allan's=20 draft-allan-mpls-pid-00.txt on the subject. Also I think the = explanation=20 of ECMP issue (disambiguate from IP/MPLS packets etc) and the = overall=20 proposed solution are valid.

I just wanted to clarify some technicalities = to make=20 sure we clearly identify where we are headed to - i.e. what = changes are=20 required in other PWE3 drafts.

Assuming we have in the same network PEs that = support=20 both formats:
 - the CW [(0000 CW = stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM = payload))]
 - and the newly = defined PTI=20 (0001 PTI)(data/VCCV payload/?whatever?).
In the=20 same time let's assume other PEs will accept just the PTI - = being part=20 of those implementations that do not support 0000. How are we = going to=20 ensure the 2 sets of PEs will be able to negotiate in the = control plane=20 the right format?


Currently we do have = in each of=20 the 2 L2 FECs (PWID and Generalized ID) just one bit to = determine=20 whether or not the CW should be used - see=20 draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. = 0001=20 implicitly meant up to now VCCV format. How do we differentiate = the=20 other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: = there are=20 some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell = Mode=20 and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt = section=20 4.3.2). For a PE that will implement the PTI format are we = saying the PW=20 frames (after the 2 labels) will look like this: (0001  = PTI)(0000=20 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the = same way,=20 just re-using what is already defined: i.e. (0001  = PTI)(0001 PA=20 PPP_DLL)(OAM payload)? If not I assume we will need to clarify = the PTI=20 code points that are going to be used for VCCV/OAM payload? =

Thanks for clarifying the above points. =
Regards,
Florin =


-----Original Message-----
From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = On=20 Behalf Of Stewart Bryant
Sent: Monday, = August=20 09, 2004 7:54 AM
To: = pwe3@ietf.org=20
Subject: [PWE3] = draft-bryant-mcpherson-pwe3-cw-00.txt=20 WG request


The authors request that

http://www.ietf.org/internet-drafts/draft-bryant-mcpherso= n-pwe3-cw-00.txt=20

be adopted as a WG item with its title changed = to=20

PWE3 MPLS Control Word

- Stewart







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

------_=_NextPart_001_01C48378.89878B00-- --===============1244914625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1244914625==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: Scaling hierarchical LDP/PW stitching Date: Mon, 16 Aug 2004 11:05:21 +0100 Lines: 227 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Mon Aug 16 12:15:46 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Scaling hierarchical LDP/PW stitching Thread-Index: AcSBdXQ4R5B8rISCTROuaG7qeBMHDwB/dYCQ To: , , X-OriginalArrivalTime: 16 Aug 2004 10:05:22.0644 (UTC) FILETIME=[8B1CA140:01C48378] X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thanks Adrian......a few additional remarks in-line..... > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Adrian Farrel > Sent: 13 August 2004 21:25 > To: pwe3@ietf.org; l2vpn@ietf.org > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching >=20 >=20 > Hi, >=20 > PMFJI (and slightly off topic). >=20 > Thanks, Neil, for your mail which does help to clarify several things. >=20 > I particularly support your note that GMPLS supports an=20 > out-of-band control plane. This is fundamental to the design=20 > and operation of GMPLS. NH=3D> To be accurate here it is actually a consequence of the co-cs = mode. However, an OOB approach can also be applied to the co-ps mode....and there are good reasons (like security, stability and resilence design) why this ought to be seriously considered. >=20 > Can I just throw a couple of other points into the melting pot? >=20 > Since GMPLS was developed within the IETF there is an=20 > assumption of IP addressing (or naming). This means that not=20 > only is IP addressing used in the control plane, but IP=20 > naming is used in the data plane. There is, of course, also=20 > the facility for unnumbering. NH=3D> Couple of points: - Both data-plane networks require addressing, but they exist in disjoint spaces....the fact that the traffic data-plane is co-cs (here) and the control (management?) data-plane is cl-ps ought to make this rather obvious IMO. =20 - these addresses are completely disjoint from IP addresses used in the public Internet (obviously so for the traffic data-plane as the mode is completely different)....in fact, the control/management data-plane addresses *must not* be reachable from the Internet as security is a key reason/benefit from using an OOB approach. >=20 > It should be noted that the TEDB used to compute paths=20 > through a GMPLS network is emphatically not the routing=20 > database used to route packets (especially control plane > packets) within the network. NH=3D> Sorry if I sound pedantic, but there is not a *single* network here, and there are at least 2 data-plane networks....and what you state above is really just saying this a different way. > This is true despite the fact=20 > that the same routing protocol may be used to distribute the=20 > information used to build the two databases. NH=3D> Agreed. >=20 > Now, since there is a commonality of address formats between=20 > control and data planes in GMPLS, some optimisations and=20 > sharing of address spaces MAY be used, but these are not=20 > compulsory. NH=3D> Very much so. I can recall BT stating 4 years ago or so when = GMPLS started-off that it would probably be very sensible not to use v4 structures for the traffic data-plane but start with v6 structures. I mean, why not learn from history given the traffic data-plane here is co-cs and has nothing to do with the IP-based public Internet? =20 Regards, Neil > In the packet capable switching world (Note well=20 > that GMPLS fully supports the PCS world) where control and=20 > data packets traverse the same links, this optimization may=20 > be used heavily (cf. MPLS). >=20 > However, (note again that GMPLS supports PCS and out-of-band=20 > signalling), there is no reason to require the control and=20 > data planes to share address spaces or even to share physical=20 > resources. >=20 > Cheers, > Adrian >=20 > =3D=3D >=20 > Folks, I have had a few private mails asking me to explain=20 > something I noted below.....so just in case other folks are=20 > having problems with my terse and/or poor explanation let me=20 > spell it out: >=20 > I said (extracted from below): > "An address is an attribute of an access point in the=20 > data-plane. It has nothing to do with signalling (nor=20 > routing for that matter)." >=20 > So to better explain what I meant here: >=20 > An address defines an access point of a network or subnetwork=20 > (this is a G.805 func arch term, it's not an IP subnet). It=20 > is an attribute of the data-plane of some layer network (this=20 > can be any mode, ie cl-ps, co-ps or co-cs). Signalling and=20 > routing are 2 additional functional components (there are=20 > more than this, but this is all that is relevant here). >=20 > Depending on the mode the signalling and routing (and other=20 > management) components can operate in-band or out-of-band wrt=20 > to the data-plane that will be carrying the traffic. In=20 > fact, when we take these components OOB (for important=20 > security/stability/resilience reasons) the mode of the=20 > control/management data-plane network can be cl-ps whilst=20 > that of the traffic data-plane network co-ps or co-cs (cf=20 > GMPLS which is exactly like this for SDH or OTN say). Note=20 > also that the addressing of these 2 layer networks (ie 1 for=20 > traffic and 1 for control/management) operate in quite=20 > different spaces. >=20 > So, whilst routing and signalling protocols carry addressing=20 > (of the traffic data-plane) they should be agnostic to the=20 > nature of that addressing. However, there is further key=20 > point regarding the relationship between addressing and=20 > topology (and thus the impact on routing advertisements)........ >=20 > Addressing and topology are coupled. The tighter the=20 > coupling the more efficient can be the address aggregation=20 > (ie summarisation in routing advertisements), and vice versa=20 > (ethernet is an extreme example of the latter case.....and=20 > here the address has completely degenerated into a 'name'=20 > since it carries no topological information of 'where').=20 > However, the coupling must not be too tight or else changes=20 > in topology impact addressing schemes...and that is not a=20 > good idea either. >=20 > Hope that clarifies. >=20 > Regards, Neil >=20 > > -----Original Message----- > > From: Harrison,N,Neil,IKR2 R > > Sent: 10 August 2004 10:27 > > To: Spencer,R,Richard,XGH5 R; 'lmartini@cisco.com';=20 > > 'busschbach@lucent.com' > > Cc: 'l2vpn@ietf.org'; 'dimitri.papadimitriou@alcatel.be'; > > 'pwe3@ietf.org'; 'mustapha.aissaoui@alcatel.com' > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > Richard....spot on....1 additional remark where I want to reinforce=20 > > something important. > > > > > Luca, > > > > > > > Since we have accepted the control protocol draft we do not > > > have much > > > > choice on what parameters identify a PW. > > > > This is already defined. > > > > > > I disagree, this implies that the WG does not have the power to=20 > > > change or make amendments to decisions that have already=20 > been made.=20 > > > If WG consensus was reached that the parameters currently defined=20 > > > for identifying PWs were not suitable for MH-PWs, then=20 > there is no=20 > > > reason why alternative parameters couldn't be added (at least as=20 > > > optional) in separate/revised drafts. Especially considering the=20 > > > draft(s) in question are not even RFCs yet. > > > > > > > I see this from a different point of view. Current > > > autodiscovery does > > > > not take into consideration pw-switching nodes , but I=20 > cannot see=20 > > > > why we have to merge the auto provisioning of PW , and the=20 > > > > signaling protocol ? > > > > > > I don't think Peter is suggesting that auto-provisioning and=20 > > > signalling should be merged or described in the same document. I=20 > > > think he is just pointing out that if auto-discovery was=20 > to be based=20 > > > on PW endpoint identifiers, because of the way PW end/mid=20 > points (or=20 > > > access points) are currently identified, autodiscovery would be=20 > > > dependant on the signalling mechanism used. For example, PW end=20 > > > points established using FEC 128 are identified by the PWid+PE IP > > > address, whereas PW end points established using FEC 129 are > > > identified by the AGI/AII+PE IP address, i.e. endpoint > > > identification is dependent on the signalling mechanism used. > > NH=3D> And this is one thing that is clearly wrong....and its=20 > happened=20 > > before with MPLS. An address is an attribute of an access point in=20 > > the data-plane. It has nothing to do with signalling (nor=20 > routing for=20 > > that matter). And specifically signalling should not determine=20 > > addressing. What happens if we decide to change the=20 > signalling? What=20 > > happens if we use the NMS/OSS to set-up the trail? > > > > Regards, Neil > > > > > If PWs were identified using the same identifier=20 > regardless of the=20 > > > signalling protocol used, then in turn auto-discovery=20 > would not be=20 > > > dependent on the signalling protocol used. A further improvement=20 > > > would be to use a unique identifier that is only=20 > pertinent to the PW=20 > > > layer, e.g. an IPv6 address, which would be a significant=20 > advantage=20 > > > from a management and OAM perspective. > > > > > > Regards, > > > Richard > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 >=20 >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Andrew G. Malis" Subject: Fwd: I-D ACTION:draft-ietf-pwe3-cell-transport-00.txt Date: Mon, 16 Aug 2004 10:46:39 -0400 Lines: 86 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Danny McPherson , Stewart Bryant X-From: pwe3-bounces@ietf.org Mon Aug 16 16:55:54 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: "PWE3 (IETF)" X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org (resending - I never saw this come out on the list - sorry if you received it twice). To change the email topic for a minute away from PW stitching, the authors believe that this draft is ready for WG last call, and would like to request same. It documents an application for ATM N-to-1 cell encapsulation that is already in operational use. Thanks, Andy ------- Begin of Forwarded Message ------- To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 12 Aug 2004 15:31:09 -0400 Cc: pwe3@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-cell-transport-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 ATM Transparent Cell Transport Service Author(s) : A. Malis, et al. Filename : draft-ietf-pwe3-cell-transport-00.txt Pages : 3 Date : 2004-8-12 The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for PWE3 ATM cell encapsulation described in [ATM-ENCAPS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cell-transport-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-pwe3-cell-transport-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-ietf-pwe3-cell-transport-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. Content-Type: text/plain Content-ID: <2004-8-12143911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-cell-transport-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------- End of Forwarded Message ------- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Linda Dunbar Subject: Different between Pseudowire demultiplexor and Tunnel encapsulation Date: Mon, 16 Aug 2004 15:39:38 -0500 Lines: 10 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-From: pwe3-bounces@ietf.org Mon Aug 16 22:59:24 2004 Return-path: To: pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:49.03085 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:4 R:4 (0.0000 0.0000) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7BIT X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The Section 4.1.1 of "draft-ietf-pwe3-ethernet-encap-07.txt" (Generic Procedures) indicate that NSP/Forwarder needs to prepend "Proper Pseudowire demultiplexor" and "proper Tunnel encapsulation". Could anyone tell me what is the difference between the Pseudowire demultiplexor and Tunnel encapsulation, and the function of each? Thanks, Linda Dunbar From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: =?iso-8859-1?Q?Benny_Ammitzb=F8ll?= Subject: PW to PSN tunnel mapping Date: Tue, 17 Aug 2004 10:13:33 +0200 Lines: 88 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007B_01C48442.DA32D950" X-From: pwe3-bounces@ietf.org Tue Aug 17 10:25:03 2004 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-MS-TNEF-Correlator: X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_007B_01C48442.DA32D950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA29692 > The draft-ietf-pwe3-control-protocol-08.txt mentions that the PW are se= t > up to run inside a "PSN tunnel" and there is some talk about how this c= an > happen by pushing an extra MPLS label etc. But there is nothing that sa= ys > how a PE knows which PSN tunnel a PW belongs to? Is this supposed to be > static configuration? Or is the assumption that there is only one PSN > tunnel between two PEs - this would be a bad assumption since there wou= ld > most likely be more than one PSN tunnel, with different QoS parameters. >=20 >=20 > Benny L=F8nstrup Ammitzb=F8ll, M.Sc.E.E. > T|Pack A/S > Lautrupbjerg 7-11 > DK-2750 Ballerup, Denmark > Phone: (+45) 44732100 > Direct: (+45) 44732140 > mailto:bla@tpack.net - www.tpack.net >=20 ------=_NextPart_000_007B_01C48442.DA32D950 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiEIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEIAAUABAAAAAAAAAAAAAEJAAQAAgAAAAAA AAABBoADAA4AAADUBwgAEQAKAA0AAAACAA0BAQOQBgAsBwAAKAAAAAsAAgABAAAACwAjAAAAAAAD ACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAB4ATQABAAAAAQAAAAAAAAAeAHAAAQAAABkA AABQVyB0byBQU04gdHVubmVsIG1hcHBpbmcAAAAAAgFxAAEAAAAbAAAAAcSELq6gIJT83M6VSlOZ EuzCw3b6tgAA1l5gAAsAFwwAAAAAAgEdDAEAAAAhAAAAU01UUDpCRU5OWS5BTU1JVFpCT0VMTEBU UEFDSy5ORVQAAAAACwABDgAAAABAAAYOAI6YAjKExAECAQoOAQAAABgAAAAAAAAAVsy5Gmxg10yM LozAi7UUUMKAAAALAB8OAQAAAAIBCRABAAAAzAIAAMgCAABlAwAATFpGdb3r/6QDAAoAcmNwZzEy NRYyAPgLYG4OEDAzM08B9wKkA+MCAGNoCsBzsGV0MCAHEwKAfQqBknYIkHdrC4BkNAxgrmMAUAsE A2B0BZB0C6YAIFRoZSBkcmENAYAtCJAAMC1wd2XcMy0FoAIwA2BsFTATYcJvCOEtMDguDNAFQNsH gAIwaQIgBCB0EPAFQOMXoBRwUFcgCsAUcBEhCCB1cBeQbyBydR8DoAuAAJABABhQICJQDFNOF5AZ UG5lbCL/GFASgBfiGHEEABiQA3AUcFkBkGxrGFAG4HUFQGhubwfgF6AbgWMDkRDwcAJwCfAgYnkg cHXOcx0ADyAa0SBlFuAUoNkF0FBMBfALYGIaoB7AYHRjLiBCHIEbJ27HE3AeUxejc2F5BCAcsqEZ 8FBFIGshAHcEIP53HQAQ4BggGjciUhhAH6GFAiBnF4FvPyBJF4LzG4IY4HBvESAbARkgH6A3GJAB kBdAYx0wAiBmad5nCHAmwQIgJRBPBcAbgeUX8mEEEHVtBTAXUReX+xtUAiBsHgACIBgRI4gfoH50 FVAdwSuQGSAigAQgLXMc5CwAdWwbACZxGfBizmEbACipAJBuYxvhGzPPLOQEYCagH3BpaxqgHgC/ JnEEYBhxF6EDoCqMLCMAbmkXoBSABpBmG0ECMCDsUW8F8AqxYQeAE4AREK4uCqIKhDRWQgnwbh4A 4ExcJ2Y4AIAVwBjhaEFtbTJAegwwNbFs0TIBTS5TIABFN4E0FBhUfFAA0BwwQS9TmTQUTGEcgDYR YmoEkDEegDctMRLjCoBES1AtMjc1EVBCB0BsNwSQGOAyEEQJ8ADAcmsNNBRQHLAakDogKCsANDUp IDQ0NzPuMg9AAUA6VGkJcBOgPOxeND3VAMADEBZAOgJgYexAdAqwOHAuGpAFQCxwvndBcBbAQMY0 GhHhAENACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAA RgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAnagEAHgAJgAggBgAAAAAA wAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAAB AAAAAQAAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAMgAgg BgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsADYAIIAYAAAAAAMAAAAAAAABGAAAA AIKFAAABAAAACwA6gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADyACCAGAAAAAADAAAAA AAAARgAAAAARhQAAAAAAAAMAPYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAACwBSgAggBgAA AAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAFOACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAIB +A8BAAAAEAAAAFbMuRpsYNdMjC6MwIu1FFACAfoPAQAAABAAAABWzLkabGDXTIwujMCLtRRQAgH7 DwEAAABYAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gB AKoAN9luAAAAXFxCbHVlXGJsYVxPdXRsb29rXG91dGxvb2sucHN0AAMA/g8FAAAAAwANNP03AAAC AX8AAQAAADsAAAA8TkhFTUlNQ09OS0FNRENLUEhJREFNRUJPQ0ZBQS5CZW5ueS5BbW1pdHpib2Vs bEB0cGFjay5uZXQ+AAADAAYQTB1w3gMABxAwAgAAAwAQEAEAAAADABEQAQAAAB4ACBABAAAAZQAA AFRIRURSQUZULUlFVEYtUFdFMy1DT05UUk9MLVBST1RPQ09MLTA4VFhUTUVOVElPTlNUSEFUVEhF UFdBUkVTRVRVUFRPUlVOSU5TSURFQSJQU05UVU5ORUwiQU5EVEhFUkVJU1MAAAAATY4= ------=_NextPart_000_007B_01C48442.DA32D950 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------=_NextPart_000_007B_01C48442.DA32D950-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: =?iso-8859-1?Q?Benny_Ammitzb=F8ll?= Subject: AGI, SAII, TAII types? Date: Tue, 17 Aug 2004 10:14:08 +0200 Lines: 79 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007E_01C48442.EEE1CD20" X-From: pwe3-bounces@ietf.org Tue Aug 17 10:26:44 2004 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-MS-TNEF-Correlator: X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_007E_01C48442.EEE1CD20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA29716 > The draft-ietf-pwe3-control-protocol-08.txt does not define type field > values for AGI, SAII and TAII fields in the Generalized ID FEC Element: > "IANA will assign these values based on IETF consensus". Have any value= s > been defined so far? If not, what values do current implementations use= ? >=20 > Benny L=F8nstrup Ammitzb=F8ll, M.Sc.E.E. > T|Pack A/S > Lautrupbjerg 7-11 > DK-2750 Ballerup, Denmark > Phone: (+45) 44732100 > Direct: (+45) 44732140 > mailto:bla@tpack.net - www.tpack.net >=20 ------=_NextPart_000_007E_01C48442.EEE1CD20 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IggIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEIAAUABAAAAAAAAAAAAAEJAAQAAgAAAAAA AAABBoADAA4AAADUBwgAEQAKAA4AAAACAA4BAQOQBgCABgAAKAAAAAsAAgABAAAACwAjAAAAAAAD ACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAB4ATQABAAAAAQAAAAAAAAAeAHAAAQAAABcA AABBR0ksIFNBSUksIFRBSUkgdHlwZXM/AAACAXEAAQAAABsAAAABxIQt7V7SiomnEQFCF7pztpPK wa2XAAELWLAACwAXDAAAAAACAR0MAQAAACEAAABTTVRQOkJFTk5ZLkFNTUlUWkJPRUxMQFRQQUNL Lk5FVAAAAAALAAEOAAAAAEAABg4A1FsmMoTEAQIBCg4BAAAAGAAAAAAAAABWzLkabGDXTIwujMCL tRRQwoAAAAsAHw4BAAAAAgEJEAEAAAAjAgAAHwIAAIMCAABMWkZ1Exr4vgMACgByY3BnMTI1FjIA +Atgbg4QMDMzTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0DGCuYwBQCwQDYHQF kHQLpgAgVGhlIGRyYQ0BgC0IkAAwLXB3ZdwzLQWgAjADYGwVMBNhwm8I4S0wOC4M0AVA9GRvB5Fu E3AUgAEQC4AxFHB0eXAUcBfAZWz4ZCB2B0AKUAQgAhAFwBBBR0ksBgBBSUn2IABwGKBUGdIYYwQg C4A7GAAUYUcJ8ASQB0BpegEJgCBJRCBGRUMwIEVsZQeAAjA6IEAiSUFOQSAD8GzlAyBhBBBpZxsj ESAYth5iHfAcEQIgHDBFVEYOIBWRESAAgHVzIi6wIEhhdhRwAHB5HrdnCeEXlRigc28YUArAP+0c MGYXUhmgdxDwBUAYxb8XECAACHAJcAIwGwBtC1ArHNMjwGkgISAggGU/NwqiCoQKgEIJ8CExTFyY J2Y4AIAVwHVwEWDgbW1pdHoMMCeRHcCBGaBNLlNjLkUpYVEmVFR8UADQaxFgLyJTJlRMYXUn4mJq wQSQZyA3LTES4wqAQERLLTI3NRFQQm8HQBzAJ/EZoEQJ8ADAclJrJlRQaAIgZR0gKAArNDUpIDQ0 N9wzMg9AAUAsNGkJcBOgvS7MNC+1AMADEBZAOgJg2GFAdAqwKlAuF+AFQH4tHZAzUBbAMqYmWhHh AAE1IAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAAAABG AAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAACdqAQAeAAmACCAGAAAAAADA AAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEA AAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAyACCAG AAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwANgAggBgAAAAAAwAAAAAAAAEYAAAAA goUAAAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAAAMAAAAAA AABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFKACCAGAAAA AADAAAAAAAAARgAAAAAGhQAAAAAAAAMAU4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAgH4 DwEAAAAQAAAAVsy5Gmxg10yMLozAi7UUUAIB+g8BAAAAEAAAAFbMuRpsYNdMjC6MwIu1FFACAfsP AQAAAFgAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEA qgA32W4AAABcXEJsdWVcYmxhXE91dGxvb2tcb3V0bG9vay5wc3QAAwD+DwUAAAADAA00/TcAAAIB fwABAAAAOwAAADxOSEVNSU1DT05LQU1EQ0tQSElEQUFFQlBDRkFBLkJlbm55LkFtbWl0emJvZWxs QHRwYWNrLm5ldD4AAAMABhCAB0aqAwAHEIUBAAADABAQAQAAAAMAERABAAAAHgAIEAEAAABlAAAA VEhFRFJBRlQtSUVURi1QV0UzLUNPTlRST0wtUFJPVE9DT0wtMDhUWFRET0VTTk9UREVGSU5FVFlQ RUZJRUxEVkFMVUVTRk9SQUdJLFNBSUlBTkRUQUlJRklFTERTSU5USEVHRQAAAABjTw== ------=_NextPart_000_007E_01C48442.EEE1CD20 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------=_NextPart_000_007E_01C48442.EEE1CD20-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: du.ke@zte.com.cn Subject: Re: PW to PSN tunnel mapping Date: Tue, 17 Aug 2004 18:06:23 +0800 Lines: 124 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; Boundary="0__=C7BBE460DFA603918f9e8a93df938690918cC7BBE460DFA60391" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Aug 17 11:57:22 2004 Return-path: To: Benny =?iso-8859-1?Q?Ammitzb=F8ll?= X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.10 |March 22, 2002) at 2004-08-17 17:54:04 Content-Disposition: inline X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --0__=C7BBE460DFA603918f9e8a93df938690918cC7BBE460DFA60391 Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 DQpIb3cgdG8gYXNzaWduIGEgcGFydGljdWxhciBQVyB0byBhIHBhcnRpY3VsYXIgdHVubmVsIGlz IGEgbG9jYWwgcG9saWN5IG9mDQpQRS4NCg0KeW91IGNhbiByZWZlciB0byB0aGUgc2VjdGlvbiAz LjIuNCBvZg0KImRyYWZ0LWlldGYtbDJ2cG4tbDItZnJhbWV3b3JrLTA1LnR4dCINCg0KMy4yLjQu IFR1bm5lbHMNCg0KICAgQSBQVyBpcyBjYXJyaWVkIGluIGEgInR1bm5lbCIgZnJvbSBQRTEgdG8g UEUyLiAgV2UgYXNzdW1lIHRoYXQgYW4NCiAgIGFyYml0cmFyeSBudW1iZXIgb2YgUFdzIG1heSBi ZSBjYXJyaWVkIGluIGEgc2luZ2xlIHR1bm5lbDsgdGhlIG9ubHkNCiAgIHJlcXVpcmVtZW50IGlz IHRoYXQgdGhlIFBXcyBhbGwgdGVybWluYXRlIGF0IFBFMi4NCg0KICAgV2UgZG8gbm90IGV2ZW4g cmVxdWlyZSB0aGF0IGFsbCB0aGUgUFdzIGluIHRoZSB0dW5uZWwgb3JpZ2luYXRlIGF0DQogICBQ RTE7IHRoZSB0dW5uZWxzIG1heSBiZSBtdWx0aXBvaW50LXRvLXBvaW50IHR1bm5lbHMuICBOb3Ig ZG8gd2UNCiAgIHJlcXVpcmUgdGhhdCBhbGwgUFdzIGJldHdlZW4gdGhlIHNhbWUgcGFpciBvZiBQ RXMgdHJhdmVsIGluIHRoZSBzYW1lDQogICB0dW5uZWwuICBBbGwgd2UgcmVxdWlyZSBpcyB0aGF0 IHdoZW4gYSBmcmFtZSB0cmF2ZWxpbmcgdGhyb3VnaCBzdWNoIGENCiAgIHR1bm5lbCBhcnJpdmVz IGF0IFBFMiwgUEUyIHdpbGwgYmUgYWJsZSB0byBhc3NvY2lhdGUgaXQgd2l0aCBhDQogICBwYXJ0 aWN1bGFyIFBXLg0KDQogICAoV2hpbGUgb25lIGNhbiBpbWFnaW5lIHR1bm5lbGluZyB0ZWNobmlx dWVzIHRoYXQgb25seSBhbGxvdyBvbmUgUFcNCiAgIHBlciB0dW5uZWwsIHRoZXkgaGF2ZSBldmlk ZW50IHNjYWxhYmlsaXR5IHByb2JsZW1zLCBhbmQgd2UgZG8gbm90DQogICBjb25zaWRlciB0aGVt IGZ1cnRoZXIuKQ0KDQogICBUaGVyZSBhcmUgYSB2YXJpZXR5IG9mIGRpZmZlcmVudCB0dW5uZWxp bmcgdGVjaG5vbG9naWVzIHdoaWNoIG1heSBiZQ0KICAgdXNlZCBmb3IgdGhlIFBFLVBFIHR1bm5l bHMuICBBbGwgdGhhdCBpcyByZWFsbHkgcmVxdWlyZWQgaXMgdGhhdCB0aGUNCiAgIHR1bm5lbGlu ZyB0ZWNobm9sb2dpZXMgYWxsb3cgdGhlIHByb3BlciBkZW11bHRpcGxleGluZyBvZiB0aGUNCiAg IGNvbnRhaW5lZCBQV3MuICBUaGUgdHVubmVscyBtaWdodCBiZSBNUExTIExTUHMsIEwyVFAgdHVu bmVscywgSVBzZWMNCiAgIHR1bm5lbHMsIE1QTFMtaW4tSVAgdHVubmVscywgZXRjLiAgR2VuZXJh bGx5IHRoZSB0dW5uZWxpbmcgdGVjaG5vbG9neQ0KICAgd2lsbCByZXF1aXJlIHRoZSB1c2Ugb2Yg YW4gZW5jYXBzdWxhdGlvbiB0aGF0IGNvbnRhaW5zIGENCiAgIGRlbXVsdGlwbGV4b3IgZmllbGQs IHdoZXJlIHRoZSBkZW11bHRpcGxleG9yIGZpZWxkIGlzIHVzZWQgdG8NCiAgIGlkZW50aWZ5IGEg cGFydGljdWxhciBQVy4gUHJvY2VkdXJlcyBmb3Igc2V0dGluZyB1cCBhbmQgbWFpbnRhaW5pbmcN CiAgIHRoZSB0dW5uZWxzIGFyZSBub3Qgd2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIGZyYW1ld29y ay4gKEJ1dCBzZWUNCiAgIHNlY3Rpb24gMy4yLjYsICJQc2V1ZG93aXJlIFNpZ25hbGluZyIuKQ0K DQogICBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgdHVubmVscyBmcm9tIFBFMSB0byBQRTIsIGl0IG1h eSBiZSBkZXNpcmFibGUgdG8NCiAgIGFzc2lnbiBhIHBhcnRpY3VsYXIgUEUxLVBFMiBQVyB0byBh IHBhcnRpY3VsYXIgdHVubmVsIGJhc2VkIG9uIHNvbWUNCiAgIHBhcnRpY3VsYXIgY2hhcmFjdGVy aXN0aWNzIG9mIHRoZSBQVyBhbmQvb3IgdGhlIHR1bm5lbC4gRm9yIGV4YW1wbGUsDQogICBwZXJo YXBzIGRpZmZlcmVudCB0dW5uZWxzIGFyZSBhc3NvY2lhdGVkIHdpdGggZGlmZmVyZW50IFFvUw0K ICAgY2hhcmFjdGVyaXN0aWNzLCBhbmQgZGlmZmVyZW50IFBXcyByZXF1aXJlIGRpZmZlcmVudCBR b1MuIFByb2NlZHVyZXMNCiAgIGZvciBzcGVjaWZ5aW5nIGhvdyB0byBhc3NpZ24gUFdzIHRvIHR1 bm5lbHMgYXJlIG91dCBvZiBzY29wZSBvZiB0aGUNCiAgIGN1cnJlbnQgZnJhbWV3b3JrLg0KDQog ICBUaG91Z2ggcG9pbnQtdG8tcG9pbnQgUFdzIGFyZSBiaWRpcmVjdGlvbmFsLCB0aGUgdHVubmVs cyBpbiB3aGljaA0KICAgdGhleSB0cmF2ZWwgbmVlZCBub3QgYmUgZWl0aGVyIGJpZGlyZWN0aW9u YWwgb3IgcG9pbnQtdG8tcG9pbnQuIEZvcg0KICAgZXhhbXBsZSwgYSBwb2ludC10by1wb2ludCBQ VyBtYXkgdHJhdmVsIHdpdGhpbiBhIHVuaWRpcmVjdGlvbmFsDQogICBtdWx0aXBvaW50LXRvLXBv aW50IE1QTFMgTFNQLg0KDQoNCg0KDQoNCj4gVGhlIGRyYWZ0LWlldGYtcHdlMy1jb250cm9sLXBy b3RvY29sLTA4LnR4dCBtZW50aW9ucyB0aGF0IHRoZSBQVyBhcmUgc2V0DQo+IHVwIHRvIHJ1biBp bnNpZGUgYSAiUFNOIHR1bm5lbCIgYW5kIHRoZXJlIGlzIHNvbWUgdGFsayBhYm91dCBob3cgdGhp cyBjYW4NCj4gaGFwcGVuIGJ5IHB1c2hpbmcgYW4gZXh0cmEgTVBMUyBsYWJlbCBldGMuIEJ1dCB0 aGVyZSBpcyBub3RoaW5nIHRoYXQgc2F5cw0KPiBob3cgYSBQRSBrbm93cyB3aGljaCBQU04gdHVu bmVsIGEgUFcgYmVsb25ncyB0bz8gSXMgdGhpcyBzdXBwb3NlZCB0byBiZQ0KPiBzdGF0aWMgY29u ZmlndXJhdGlvbj8gT3IgaXMgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGVyZSBpcyBvbmx5IG9uZSBQ U04NCj4gdHVubmVsIGJldHdlZW4gdHdvIFBFcyAtIHRoaXMgd291bGQgYmUgYSBiYWQgYXNzdW1w dGlvbiBzaW5jZSB0aGVyZSB3b3VsZA0KPiBtb3N0IGxpa2VseSBiZSBtb3JlIHRoYW4gb25lIFBT TiB0dW5uZWwsIHdpdGggZGlmZmVyZW50IFFvUyBwYXJhbWV0ZXJzLg0KPg0KPg0KPiBCZW5ueSBM +G5zdHJ1cCBBbW1pdHpi+GxsLCBNLlNjLkUuRS4NCj4gVHxQYWNrIEEvUw0KPiBMYXV0cnVwYmpl cmcgNy0xMQ0KPiBESy0yNzUwIEJhbGxlcnVwLCBEZW5tYXJrDQo+IFBob25lOiAoKzQ1KSA0NDcz MjEwMA0KPiBEaXJlY3Q6ICgrNDUpIDQ0NzMyMTQwDQo+IG1haWx0bzpibGFAdHBhY2submV0IC0g d3d3LnRwYWNrLm5ldA0KPg0KKFNlZSBhdHRhY2hlZCBmaWxlOiB3aW5tYWlsLmRhdCkNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcg bGlzdA0KcHdlM0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcHdlMw0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0K5pys6YKu5Lu25bey57uP6L+H5Z6D5Zy+6YKu5Lu26L+H5ruk77yM5aaC5Y+R546w5Z6D5Zy+ DQrpgq7ku7bvvIzor7fovazlj5Hoh7PvvJpoZWxwZGVza0B6dGUuY29tLmNuDQoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoNCg0KCgoKKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgqxvtPKvP7S0b6tuf3ArLv408q8/rn9wsuj rMjnt6LP1sCsu/gK08q8/qOsx+vXqrei1sGjumhlbHBkZXNrQHp0ZS5jb20uY24KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK --0__=C7BBE460DFA603918f9e8a93df938690918cC7BBE460DFA60391 Content-type: application/ms-tnef; name="=?gb2312?B?d2lubWFpbC5kYXQ=?=" Content-Disposition: attachment; filename="=?gb2312?B?d2lubWFpbC5kYXQ=?=" Content-Transfer-Encoding: base64 eJ8+IiEIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEIAAUABAAAAAAAAAAAAAEJAAQAAgAAAAAA AAABBoADAA4AAADUBwgAEQAKAA0AAAACAA0BAQOQBgAsBwAAKAAAAAsAAgABAAAACwAjAAAAAAAD ACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAB4ATQABAAAAAQAAAAAAAAAeAHAAAQAAABkA AABQVyB0byBQU04gdHVubmVsIG1hcHBpbmcAAAAAAgFxAAEAAAAbAAAAAcSELq6gIJT83M6VSlOZ EuzCw3b6tgAA1l5gAAsAFwwAAAAAAgEdDAEAAAAhAAAAU01UUDpCRU5OWS5BTU1JVFpCT0VMTEBU UEFDSy5ORVQAAAAACwABDgAAAABAAAYOAI6YAjKExAECAQoOAQAAABgAAAAAAAAAVsy5Gmxg10yM LozAi7UUUMKAAAALAB8OAQAAAAIBCRABAAAAzAIAAMgCAABlAwAATFpGdb3r/6QDAAoAcmNwZzEy NRYyAPgLYG4OEDAzM08B9wKkA+MCAGNoCsBzsGV0MCAHEwKAfQqBknYIkHdrC4BkNAxgrmMAUAsE A2B0BZB0C6YAIFRoZSBkcmENAYAtCJAAMC1wd2XcMy0FoAIwA2BsFTATYcJvCOEtMDguDNAFQNsH gAIwaQIgBCB0EPAFQOMXoBRwUFcgCsAUcBEhCCB1cBeQbyBydR8DoAuAAJABABhQICJQDFNOF5AZ UG5lbCL/GFASgBfiGHEEABiQA3AUcFkBkGxrGFAG4HUFQGhubwfgF6AbgWMDkRDwcAJwCfAgYnkg cHXOcx0ADyAa0SBlFuAUoNkF0FBMBfALYGIaoB7AYHRjLiBCHIEbJ27HE3AeUxejc2F5BCAcsqEZ 8FBFIGshAHcEIP53HQAQ4BggGjciUhhAH6GFAiBnF4FvPyBJF4LzG4IY4HBvESAbARkgH6A3GJAB kBdAYx0wAiBmad5nCHAmwQIgJRBPBcAbgeUX8mEEEHVtBTAXUReX+xtUAiBsHgACIBgRI4gfoH50 FVAdwSuQGSAigAQgLXMc5CwAdWwbACZxGfBizmEbACipAJBuYxvhGzPPLOQEYCagH3BpaxqgHgC/ JnEEYBhxF6EDoCqMLCMAbmkXoBSABpBmG0ECMCDsUW8F8AqxYQeAE4AREK4uCqIKhDRWQgnwbh4A 4ExcJ2Y4AIAVwBjhaEFtbTJAegwwNbFs0TIBTS5TIABFN4E0FBhUfFAA0BwwQS9TmTQUTGEcgDYR YmoEkDEegDctMRLjCoBES1AtMjc1EVBCB0BsNwSQGOAyEEQJ8ADAcmsNNBRQHLAakDogKCsANDUp IDQ0NzPuMg9AAUA6VGkJcBOgPOxeND3VAMADEBZAOgJgYexAdAqwOHAuGpAFQCxwvndBcBbAQMY0 GhHhAENACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAA RgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAnagEAHgAJgAggBgAAAAAA wAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAAB AAAAAQAAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAMgAgg BgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsADYAIIAYAAAAAAMAAAAAAAABGAAAA AIKFAAABAAAACwA6gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADyACCAGAAAAAADAAAAA AAAARgAAAAARhQAAAAAAAAMAPYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAACwBSgAggBgAA AAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAFOACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAIB +A8BAAAAEAAAAFbMuRpsYNdMjC6MwIu1FFACAfoPAQAAABAAAABWzLkabGDXTIwujMCLtRRQAgH7 DwEAAABYAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gB AKoAN9luAAAAXFxCbHVlXGJsYVxPdXRsb29rXG91dGxvb2sucHN0AAMA/g8FAAAAAwANNP03AAAC AX8AAQAAADsAAAA8TkhFTUlNQ09OS0FNRENLUEhJREFNRUJPQ0ZBQS5CZW5ueS5BbW1pdHpib2Vs bEB0cGFjay5uZXQ+AAADAAYQTB1w3gMABxAwAgAAAwAQEAEAAAADABEQAQAAAB4ACBABAAAAZQAA AFRIRURSQUZULUlFVEYtUFdFMy1DT05UUk9MLVBST1RPQ09MLTA4VFhUTUVOVElPTlNUSEFUVEhF UFdBUkVTRVRVUFRPUlVOSU5TSURFQSJQU05UVU5ORUwiQU5EVEhFUkVJU1MAAAAATY4= --0__=C7BBE460DFA603918f9e8a93df938690918cC7BBE460DFA60391 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --0__=C7BBE460DFA603918f9e8a93df938690918cC7BBE460DFA60391-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: AGI, SAII, TAII types? Date: Tue, 17 Aug 2004 15:49:49 -0600 Organization: Cisco Systems Lines: 26 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 18 00:03:28 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: =?ISO-8859-1?Q?Benny_Ammitzb=F8ll?= In-Reply-To: X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA16971 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Benny Ammitzb=F8ll wrote: >The draft-ietf-pwe3-control-protocol-08.txt does not define type field >values for AGI, SAII and TAII fields in the Generalized ID FEC Element: >"IANA will assign these values based on IETF consensus". Have any values >been defined so far? If not, what values do current implementations use? > > =20 > No, Nothing has been assighed so far , and as far as I know there are=20 no implementations of this particular mode yet. Luca >Benny L=F8nstrup Ammitzb=F8ll, M.Sc.E.E. >T|Pack A/S >Lautrupbjerg 7-11 >DK-2750 Ballerup, Denmark >Phone: (+45) 44732100 >Direct: (+45) 44732140 >mailto:bla@tpack.net - www.tpack.net > > =20 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: PW to PSN tunnel mapping Date: Tue, 17 Aug 2004 15:53:41 -0600 Organization: Cisco Systems Lines: 35 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 18 00:05:37 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: =?ISO-8859-1?Q?Benny_Ammitzb=F8ll?= In-Reply-To: X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA17181 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Benny Ammitzb=F8ll wrote: >The draft-ietf-pwe3-control-protocol-08.txt mentions that the PW are set= up >to run inside a "PSN tunnel" and there is some talk about how this can >happen by pushing an extra MPLS label etc. But there is nothing that say= s >how a PE knows which PSN tunnel a PW belongs to? Is this supposed to be >static configuration? Or is the assumption that there is only one PSN tu= nnel >between two PEs - this would be a bad assumption since there would most >likely be more than one PSN tunnel, with different QoS parameters. > > > =20 > In general this is done by static local configuration. The more popular=20 implemetations use the MPLS EXP bit to mark QoS class , and only one PSN=20 tunnel. There are implementations that can use a separate RSVP tunnel=20 for each PW if needed. PW are then configured locally to use a specific PSN tunnel. Luca >Benny L=F8nstrup Ammitzb=F8ll, M.Sc.E.E. >T|Pack A/S >Lautrupbjerg 7-11 >DK-2750 Ballerup, Denmark >Phone: (+45) 44732100 >Direct: (+45) 44732140 >mailto:bla@tpack.net - www.tpack.net > > =20 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: =?iso-8859-1?Q?Benny_Ammitzb=F8ll?= Subject: QoS - Was: Re: PW to PSN tunnel mapping Date: Wed, 18 Aug 2004 14:42:28 +0200 Lines: 56 Sender: pwe3-bounces@ietf.org References: <41227E65.2080408@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Wed Aug 18 14:57:24 2004 Return-path: To: "Luca Martini" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <41227E65.2080408@cisco.com> X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA02276 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca, When you say "QoS class", does that also imply bandwidth and burst parameters? The only reason I operate with more than one PSN tunnel is because of QoS. There seems to be no QoS considerations for PW's, except = - I assume - static setup? It would make obvious sense to do policing on the = PW in the PE's since the PW service is what you sell to the end customer. /Benny -----Original Message----- From: Luca Martini [mailto:lmartini@cisco.com] Sent: 17. august 2004 23:54 To: Benny Ammitzb=F8ll Cc: pwe3@ietf.org; l2vpn@ietf.org Subject: Re: PW to PSN tunnel mapping Benny Ammitzb=F8ll wrote: >The draft-ietf-pwe3-control-protocol-08.txt mentions that the PW are set= up >to run inside a "PSN tunnel" and there is some talk about how this can >happen by pushing an extra MPLS label etc. But there is nothing that say= s >how a PE knows which PSN tunnel a PW belongs to? Is this supposed to be >static configuration? Or is the assumption that there is only one PSN tunnel >between two PEs - this would be a bad assumption since there would most >likely be more than one PSN tunnel, with different QoS parameters. > > > > In general this is done by static local configuration. The more popular implemetations use the MPLS EXP bit to mark QoS class , and only one PSN tunnel. There are implementations that can use a separate RSVP tunnel for each PW if needed. PW are then configured locally to use a specific PSN tunnel. Luca >Benny L=F8nstrup Ammitzb=F8ll, M.Sc.E.E. >T|Pack A/S >Lautrupbjerg 7-11 >DK-2750 Ballerup, Denmark >Phone: (+45) 44732100 >Direct: (+45) 44732140 >mailto:bla@tpack.net - www.tpack.net > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Mustapha Aissaoui Subject: Re: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Wed, 18 Aug 2004 10:52:03 -0400 Organization: Alcatel Networks Corporaton Lines: 249 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 18 16:57:18 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Busschbach, Peter B (Peter)" X-Scan-Signature: 850245b51c39701e2700a112f3032caa Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, I agree with your proposal. One clarification though: strictly speaking the PTI on OAM packets is only required when ECMP or other load balancing schemes could split the OAM and data packets over different paths. Otherwise, the router alert label should be sufficient and this will not require the use of the control word on data packets if not required by the encapsulation. Thus, we have the following two options: 1. If PTI is used on OAM packets, CW is mandatory on data packets. 2. Otherwise, use router alert label on OAM packets and data packets will just follow the encapsulaiton requirements, i.e., CW may or may not be required. Also, I would like to have draft-bryant-mcpherson-pwe3-cw-00.txt add a statement to encourage future PW encapsulations to continue using the all zero nibble immediately following the bottom of the label stack for data packets. Mustapha. --------- > "Busschbach, Peter B (Peter)" wrote: > > Florin, > > You write: "On the other hand we need the extensibility provided > by a PTI/PID: VCCV is just an instantiation of a PTI if you think > about it, just the formats need to be aligned". > > I agree that VCCV is one instantiation of a protocol that could be > carried over a PW. However, the point I raised in an earlier email > is whether there are other instantiations. Because, if VCCV is the > *only* instantation, you don't need a PID, but just a way to > differentate VCCV traffic from the PW payload traffic. > > That said, this email thread has made a few things clear: > > 1) As Mustapha observed, even if you don't need to identify the PW > payload traffic, you might still need to differentiate between > different types of OAM traffic > > 2) As you observed, if you run VCCV traffic over a Pseudo Wire, > then a Control Word , be it CW or PTI, must necessarily preceed > all payload and OAM traffic. > > 3) draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical > considerations result in a PW Control Word that could be mistaken > for an IP packet, the Control Word SHOULD be preceded by a PWE3 > PTI." However, as we all seem to agree on, a CW will never be > mistaken for an IP packet. > > Therefore, rather than proposing a PTI that preceded a CW, I think > the following solution would be sufficient and more elegant: > > If the PW does not carry VCCV traffic, a CW is only mandatory if > specified in the relevant encapsulation draft > > If the PW carries VCCV traffic, then: > > a) all payload traffic MUST be preceded by a Control Word that > starts with 0000 > > b) all VCCV traffic MUSTbe preceded by an "OAM Protocol > Identifier" (OPI), which has the following format: > > [0001 | resv | protocol id], > > where protocol id identifies one of the following protocols: LSP > Ping, ICMP, BFD, Y.1711, other(?). > > Peter > > -----Original Message----- > From: Florin Balus [mailto:balus@nortelnetworks.com] > Sent: Thursday, August 12, 2004 12:42 PM > To: Busschbach, Peter B (Peter); Stewart Bryant > Cc: pwe3@ietf.org; Jeffrey Sugimoto > Subject: RE: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt WG request > > Peter, > See in-line... > > Stewart, > There might be another motivator for a mandatory > CW/consolidation under PTI: assuming we have a PW type > that does not mandate a CW (ATM N to one cell > mode) couldn't we get payloads that are mistaken also > for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could > be interpreted by the receiving PE as 0001? (thanks Jeff > for bringing this up) > > Regards, > Florin > > -----Original Message----- > From: Busschbach, Peter B (Peter) > [mailto:busschbach@lucent.com] > Sent: Wednesday, August 11, 2004 2:41 PM > To: Balus, Florin [CAR:6955:EXCH]; Stewart > Bryant > Cc: pwe3@ietf.org > Subject: RE: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt WG > request > > Florus, > > Draft-allan-mpls-pid-00.txt is not accessible > anymore. I don't recall what rationale it gave > for the need for a PTI. > FB: Dave addressed the need for an MPLS PID > one year ago from an overall MPLS perspective: > e.g. issues arisen from loadsharing on TE link > bundles or ECMP in LDP network, OAM > extensibility, Multiprotocol over MPLS... > > Draft-bryant-mcpherson-pwe3-cw-00.txt mentions > ECMP as the sole reason for an additional > control word. However, introducing PTI to > solve the issues related to ECMP seems > overkill. It would be good if we can clearly > state why we need a PTI. > FB I agree with you that the justification in > section 4 for PTI versus CW + VCCV could be > improved. On the other hand we need the > extensibility provided by a PTI/PID: VCCV is > just an instantiation of a PTI if you think > about it, just the formats need to be aligned. > Whether or not is a good idea to move the PW > user data to 0001 format is to be debated. We > need to make sure though the 2 formats could > coexist in a network in the mean time. > > Peter > > -----Original Message----- > From: Florin Balus > [mailto:balus@nortelnetworks.com] > Sent: Wednesday, August 11, 2004 > 2:17 PM > To: Stewart Bryant > Cc: pwe3@ietf.org > Subject: RE: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt > WG request > > Stewart, > > We did promote the idea of a PID/PTI > - see Dave Allan's > draft-allan-mpls-pid-00.txt on the > subject. Also I think the > explanation of ECMP issue > (disambiguate from IP/MPLS packets > etc) and the overall proposed > solution are valid. > > I just wanted to clarify some > technicalities to make sure we > clearly identify where we are headed > to - i.e. what changes are required > in other PWE3 drafts. > > Assuming we have in the same network > PEs that support both formats: > - the CW [(0000 CW stuff)(data) & > the current VCCV format (0001 PA > PPP_DLL)(OAM payload))] > - and the newly defined PTI (0001 > PTI)(data/VCCV payload/?whatever?). > In the same time let's assume other > PEs will accept just the PTI - being > part of those implementations that > do not support 0000. How are we > going to ensure the 2 sets of PEs > will be able to negotiate in the > control plane the right format? > > Currently we do have in each of the > 2 L2 FECs (PWID and Generalized ID) > just one bit to determine whether or > not the CW should be used - see > draft-ietf-pwe3-control-protocol-07.txt > section 5.1 and 5.2.2. 0001 > implicitly meant up to now VCCV > format. How do we differentiate the > other 2 possibilities (PTI yes/no)? > > Also just to make sure I understood > correctly: there are some PW types > for which the CW is REQUIRED (e.g. > ATM N to 1 Cell Mode and AAL5 SDU > Frame Mode - see > draft-ietf-pwe3-atm-encap-05.txt > section 4.3.2). For a PE that will > implement the PTI format are we > saying the PW frames (after the 2 > labels) will look like this: (0001 > PTI)(0000 CW stuff)(data)? > > Is VCCV/OAM going to be > differentiated in the same way, just > re-using what is already defined: > i.e. (0001 PTI)(0001 PA > PPP_DLL)(OAM payload)? If not I > assume we will need to clarify the > PTI code points that are going to be > used for VCCV/OAM payload? > > Thanks for clarifying the above > points. > Regards, > Florin > > -----Original Message----- > From: pwe3-bounces@ietf.org > [mailto:pwe3-bounces@ietf.org] On > Behalf Of Stewart Bryant > Sent: Monday, August 09, 2004 7:54 > AM > To: pwe3@ietf.org > Subject: [PWE3] > draft-bryant-mcpherson-pwe3-cw-00.txt > WG request > > The authors request that > > http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt > > be adopted as a WG item with its > title changed to > > PWE3 MPLS Control Word > > - Stewart > > _______________________________________________ > > 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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Shah, Himanshu" Subject: RE: QoS - Was: Re: PW to PSN tunnel mapping Date: Wed, 18 Aug 2004 11:29:15 -0400 Lines: 84 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Wed Aug 18 17:54:19 2004 Return-path: To: =?iso-8859-1?Q?=27Benny_Ammitzb=F8ll=27?= , Luca Martini , l2vpn@ietf.org, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I discussed PW QOS signaling in the last IETF meeting at San Diego. You may want to checkout -=20 http://www.ietf.org/internet-drafts/draft-shah-pwe3-pw-qos-signaling-00.= txt /himanshu > -----Original Message----- > From: Benny Ammitzb=F8ll [mailto:Benny.Ammitzboell@tpack.net] > Sent: Wednesday, August 18, 2004 8:42 AM > To: Luca Martini; l2vpn@ietf.org; pwe3@ietf.org > Subject: QoS - Was: Re: PW to PSN tunnel mapping >=20 >=20 > Luca, >=20 > When you say "QoS class", does that also imply bandwidth and burst > parameters? The only reason I operate with more than one PSN tunnel = is > because of QoS. There seems to be no QoS considerations for=20 > PW's, except - I > assume - static setup? It would make obvious sense to do=20 > policing on the PW > in the PE's since the PW service is what you sell to the end = customer. >=20 > /Benny >=20 >=20 > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: 17. august 2004 23:54 > To: Benny Ammitzb=F8ll > Cc: pwe3@ietf.org; l2vpn@ietf.org > Subject: Re: PW to PSN tunnel mapping >=20 >=20 >=20 >=20 > Benny Ammitzb=F8ll wrote: >=20 > >The draft-ietf-pwe3-control-protocol-08.txt mentions that=20 > the PW are set up > >to run inside a "PSN tunnel" and there is some talk about=20 > how this can > >happen by pushing an extra MPLS label etc. But there is=20 > nothing that says > >how a PE knows which PSN tunnel a PW belongs to? Is this=20 > supposed to be > >static configuration? Or is the assumption that there is only one = PSN > tunnel > >between two PEs - this would be a bad assumption since there=20 > would most > >likely be more than one PSN tunnel, with different QoS parameters. > > > > > > > > > In general this is done by static local configuration. The=20 > more popular > implemetations use the MPLS EXP bit to mark QoS class , and=20 > only one PSN > tunnel. There are implementations that can use a separate RSVP tunnel > for each PW if needed. > PW are then configured locally to use a specific PSN tunnel. > Luca >=20 > >Benny L=F8nstrup Ammitzb=F8ll, M.Sc.E.E. > >T|Pack A/S > >Lautrupbjerg 7-11 > >DK-2750 Ballerup, Denmark > >Phone: (+45) 44732100 > >Direct: (+45) 44732140 > >mailto:bla@tpack.net - www.tpack.net > > > > > > >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Thomas D. Nadeau" Subject: Re: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Wed, 18 Aug 2004 11:45:03 -0400 Lines: 266 Sender: pwe3-bounces@ietf.org References: <41236D13.BCB9C3B8@alcatel.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: "Busschbach, Peter B \(Peter\)" , pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 18 18:22:33 2004 Return-path: X-BrightmailFiltered: true In-Reply-To: <41236D13.BCB9C3B8@alcatel.com> To: Mustapha Aissaoui X-Mailer: Apple Mail (2.619) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > Peter, > I agree with your proposal. One clarification though: strictly > speaking the PTI on OAM packets is only required when ECMP or other > load balancing schemes could split the OAM and data packets over > different paths. Otherwise, the router alert label should be > sufficient and this will not require the use of the control word on > data packets if not required by the encapsulation. Thus, we have the > following two options: > > 1. If PTI is used on OAM packets, CW is mandatory on data packets. I am not sure if you need to explicitly make it mandatory, but it probably will not hurt. This has been the implicit assumption all along that those of us working on VCCV have told people. There is no free lunch -- if you want OAM, turn on the CW on that PW. --Tom > 2. Otherwise, use router alert label on OAM packets and data packets > will just follow the encapsulaiton requirements, i.e., CW may or may > not be required. > > Also, I would like to have draft-bryant-mcpherson-pwe3-cw-00.txt add > a statement to encourage future PW encapsulations to continue using > the all zero nibble immediately following the bottom of the label > stack for data packets. > > Mustapha. > --------- >> "Busschbach, Peter B (Peter)" wrote: >> >> Florin, >> >> You write: "On the other hand we need the extensibility provided >> by a PTI/PID: VCCV is just an instantiation of a PTI if you think >> about it, just the formats need to be aligned". >> >> I agree that VCCV is one instantiation of a protocol that could be >> carried over a PW. However, the point I raised in an earlier email >> is whether there are other instantiations. Because, if VCCV is the >> *only* instantation, you don't need a PID, but just a way to >> differentate VCCV traffic from the PW payload traffic. >> >> That said, this email thread has made a few things clear: >> >> 1) As Mustapha observed, even if you don't need to identify the PW >> payload traffic, you might still need to differentiate between >> different types of OAM traffic >> >> 2) As you observed, if you run VCCV traffic over a Pseudo Wire, >> then a Control Word , be it CW or PTI, must necessarily preceed >> all payload and OAM traffic. >> >> 3) draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical >> considerations result in a PW Control Word that could be mistaken >> for an IP packet, the Control Word SHOULD be preceded by a PWE3 >> PTI." However, as we all seem to agree on, a CW will never be >> mistaken for an IP packet. >> >> Therefore, rather than proposing a PTI that preceded a CW, I think >> the following solution would be sufficient and more elegant: >> >> If the PW does not carry VCCV traffic, a CW is only mandatory if >> specified in the relevant encapsulation draft >> >> If the PW carries VCCV traffic, then: >> >> a) all payload traffic MUST be preceded by a Control Word that >> starts with 0000 >> >> b) all VCCV traffic MUSTbe preceded by an "OAM Protocol >> Identifier" (OPI), which has the following format: >> >> [0001 | resv | protocol id], >> >> where protocol id identifies one of the following protocols: LSP >> Ping, ICMP, BFD, Y.1711, other(?). >> >> Peter >> >> -----Original Message----- >> From: Florin Balus [mailto:balus@nortelnetworks.com] >> Sent: Thursday, August 12, 2004 12:42 PM >> To: Busschbach, Peter B (Peter); Stewart Bryant >> Cc: pwe3@ietf.org; Jeffrey Sugimoto >> Subject: RE: [PWE3] >> draft-bryant-mcpherson-pwe3-cw-00.txt WG request >> >> Peter, >> See in-line... >> >> Stewart, >> There might be another motivator for a mandatory >> CW/consolidation under PTI: assuming we have a PW type >> that does not mandate a CW (ATM N to one cell >> mode) couldn't we get payloads that are mistaken also >> for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could >> be interpreted by the receiving PE as 0001? (thanks Jeff >> for bringing this up) >> >> Regards, >> Florin >> >> -----Original Message----- >> From: Busschbach, Peter B (Peter) >> [mailto:busschbach@lucent.com] >> Sent: Wednesday, August 11, 2004 2:41 PM >> To: Balus, Florin [CAR:6955:EXCH]; Stewart >> Bryant >> Cc: pwe3@ietf.org >> Subject: RE: [PWE3] >> draft-bryant-mcpherson-pwe3-cw-00.txt WG >> request >> >> Florus, >> >> Draft-allan-mpls-pid-00.txt is not accessible >> anymore. I don't recall what rationale it gave >> for the need for a PTI. >> FB: Dave addressed the need for an MPLS PID >> one year ago from an overall MPLS perspective: >> e.g. issues arisen from loadsharing on TE link >> bundles or ECMP in LDP network, OAM >> extensibility, Multiprotocol over MPLS... >> >> Draft-bryant-mcpherson-pwe3-cw-00.txt mentions >> ECMP as the sole reason for an additional >> control word. However, introducing PTI to >> solve the issues related to ECMP seems >> overkill. It would be good if we can clearly >> state why we need a PTI. >> FB I agree with you that the justification in >> section 4 for PTI versus CW + VCCV could be >> improved. On the other hand we need the >> extensibility provided by a PTI/PID: VCCV is >> just an instantiation of a PTI if you think >> about it, just the formats need to be aligned. >> Whether or not is a good idea to move the PW >> user data to 0001 format is to be debated. We >> need to make sure though the 2 formats could >> coexist in a network in the mean time. >> >> Peter >> >> -----Original Message----- >> From: Florin Balus >> [mailto:balus@nortelnetworks.com] >> Sent: Wednesday, August 11, 2004 >> 2:17 PM >> To: Stewart Bryant >> Cc: pwe3@ietf.org >> Subject: RE: [PWE3] >> draft-bryant-mcpherson-pwe3-cw-00.txt >> WG request >> >> Stewart, >> >> We did promote the idea of a PID/PTI >> - see Dave Allan's >> draft-allan-mpls-pid-00.txt on the >> subject. Also I think the >> explanation of ECMP issue >> (disambiguate from IP/MPLS packets >> etc) and the overall proposed >> solution are valid. >> >> I just wanted to clarify some >> technicalities to make sure we >> clearly identify where we are headed >> to - i.e. what changes are required >> in other PWE3 drafts. >> >> Assuming we have in the same network >> PEs that support both formats: >> - the CW [(0000 CW stuff)(data) & >> the current VCCV format (0001 PA >> PPP_DLL)(OAM payload))] >> - and the newly defined PTI (0001 >> PTI)(data/VCCV payload/?whatever?). >> In the same time let's assume other >> PEs will accept just the PTI - being >> part of those implementations that >> do not support 0000. How are we >> going to ensure the 2 sets of PEs >> will be able to negotiate in the >> control plane the right format? >> >> Currently we do have in each of the >> 2 L2 FECs (PWID and Generalized ID) >> just one bit to determine whether or >> not the CW should be used - see >> draft-ietf-pwe3-control-protocol-07.txt >> section 5.1 and 5.2.2. 0001 >> implicitly meant up to now VCCV >> format. How do we differentiate the >> other 2 possibilities (PTI yes/no)? >> >> Also just to make sure I understood >> correctly: there are some PW types >> for which the CW is REQUIRED (e.g. >> ATM N to 1 Cell Mode and AAL5 SDU >> Frame Mode - see >> draft-ietf-pwe3-atm-encap-05.txt >> section 4.3.2). For a PE that will >> implement the PTI format are we >> saying the PW frames (after the 2 >> labels) will look like this: (0001 >> PTI)(0000 CW stuff)(data)? >> >> Is VCCV/OAM going to be >> differentiated in the same way, just >> re-using what is already defined: >> i.e. (0001 PTI)(0001 PA >> PPP_DLL)(OAM payload)? If not I >> assume we will need to clarify the >> PTI code points that are going to be >> used for VCCV/OAM payload? >> >> Thanks for clarifying the above >> points. >> Regards, >> Florin >> >> -----Original Message----- >> From: pwe3-bounces@ietf.org >> [mailto:pwe3-bounces@ietf.org] On >> Behalf Of Stewart Bryant >> Sent: Monday, August 09, 2004 7:54 >> AM >> To: pwe3@ietf.org >> Subject: [PWE3] >> draft-bryant-mcpherson-pwe3-cw-00.txt >> WG request >> >> The authors request that >> >> >> http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw >> -00.txt >> >> be adopted as a WG item with its >> title changed to >> >> PWE3 MPLS Control Word >> >> - Stewart >> >> _______________________________________________ >> >> 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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: QoS - Was: Re: PW to PSN tunnel mapping Date: Wed, 18 Aug 2004 09:57:54 -0600 Organization: Cisco Systems Lines: 86 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 18 18:25:46 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: =?ISO-8859-1?Q?Benny_Ammitzb=F8ll?= In-Reply-To: X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA16564 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Benny Ammitzb=F8ll wrote: >Luca, > >When you say "QoS class", does that also imply bandwidth and burst >parameters? The only reason I operate with more than one PSN tunnel is > =20 > >because of QoS. There seems to be no QoS considerations for PW's, except= - I >assume - static setup? It would make obvious sense to do policing on the= PW >in the PE's since the PW service is what you sell to the end customer. > > =20 > Yes policing in the PE only. Then for traffic engineering , and=20 appropriate QoS treatment in the core different PSN tunnels might be used. Luca >/Benny > > >-----Original Message----- >From: Luca Martini [mailto:lmartini@cisco.com] >Sent: 17. august 2004 23:54 >To: Benny Ammitzb=F8ll >Cc: pwe3@ietf.org; l2vpn@ietf.org >Subject: Re: PW to PSN tunnel mapping > > > > >Benny Ammitzb=F8ll wrote: > > =20 > >>The draft-ietf-pwe3-control-protocol-08.txt mentions that the PW are se= t up >>to run inside a "PSN tunnel" and there is some talk about how this can >>happen by pushing an extra MPLS label etc. But there is nothing that sa= ys >>how a PE knows which PSN tunnel a PW belongs to? Is this supposed to be >>static configuration? Or is the assumption that there is only one PSN >> =20 >> >tunnel > =20 > >>between two PEs - this would be a bad assumption since there would most >>likely be more than one PSN tunnel, with different QoS parameters. >> >> >> >> >> =20 >> >In general this is done by static local configuration. The more popular >implemetations use the MPLS EXP bit to mark QoS class , and only one PSN >tunnel. There are implementations that can use a separate RSVP tunnel >for each PW if needed. >PW are then configured locally to use a specific PSN tunnel. >Luca > > =20 > >>Benny L=F8nstrup Ammitzb=F8ll, M.Sc.E.E. >>T|Pack A/S >>Lautrupbjerg 7-11 >>DK-2750 Ballerup, Denmark >>Phone: (+45) 44732100 >>Direct: (+45) 44732140 >>mailto:bla@tpack.net - www.tpack.net >> >> >> >> =20 >> > > > > =20 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Wed, 18 Aug 2004 19:39:35 +0100 Lines: 298 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: busschbach@lucent.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Aug 18 20:46:57 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request Thread-Index: AcSFP7U3Pe4+iR2eSWiyhDWvA1G+rAAESghg To: , X-OriginalArrivalTime: 18 Aug 2004 18:39:36.0116 (UTC) FILETIME=[B60A5740:01C48552] X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Tom.... > > Peter, > > I agree with your proposal. One clarification though: strictly=20 > > speaking the PTI on OAM packets is only required when ECMP or other=20 > > load balancing schemes could split the OAM and data packets over=20 > > different paths. Otherwise, the router alert label should be=20 > > sufficient and this will not require the use of the control word on=20 > > data packets if not required by the encapsulation. Thus, we=20 > have the=20 > > following two options: > > > > 1. If PTI is used on OAM packets, CW is mandatory on data packets. >=20 > I am not sure if you need to explicitly make it=20 > mandatory, but it probably will not hurt. This has been the=20 > implicit assumption all along that those of us working on=20 > VCCV have told people. There is no free lunch -- if you want=20 > OAM, turn on the CW on that PW. >=20 > --Tom NH=3D> OAM should always be designed into the data-plane *traffic* structures of layer networks from day-1.....just like OAM is designed into the various internal session/control/management protocols themselves (whatever their function) to check they are working OK per se (might not call it 'OAM' here but that is what it is, eg timers, exception handling, etc). The OAM required in the data-plane is a function of the mode.....and it is not the same for all modes. The 'lunch' starts getting expensive however when it is not properly factored-in from day-1. regards, Neil >=20 >=20 > > 2. Otherwise, use router alert label on OAM packets and=20 > data packets=20 > > will just follow the encapsulaiton requirements, i.e., CW=20 > may or may=20 > > not be required. > > > > Also, I would like to have=20 > draft-bryant-mcpherson-pwe3-cw-00.txt add a=20 > > statement to encourage future PW encapsulations to continue=20 > using the=20 > > all zero nibble immediately following the bottom of the label stack=20 > > for data packets. > > > > Mustapha. > > --------- > >> "Busschbach, Peter B (Peter)" wrote: > >> > >> Florin, > >> > >> You write: "On the other hand we need the extensibility=20 > provided by a=20 > >> PTI/PID: VCCV is just an instantiation of a PTI if you=20 > think about=20 > >> it, just the formats need to be aligned". > >> > >> I agree that VCCV is one instantiation of a protocol that could be=20 > >> carried over a PW. However, the point I raised in an=20 > earlier email is=20 > >> whether there are other instantiations. Because, if VCCV is the > >> *only* instantation, you don't need a PID, but just a way to=20 > >> differentate VCCV traffic from the PW payload traffic. > >> > >> That said, this email thread has made a few things clear: > >> > >> 1) As Mustapha observed, even if you don't need to identify the PW=20 > >> payload traffic, you might still need to differentiate between=20 > >> different types of OAM traffic > >> > >> 2) As you observed, if you run VCCV traffic over a Pseudo=20 > Wire, then=20 > >> a Control Word , be it CW or PTI, must necessarily preceed all=20 > >> payload and OAM traffic. > >> > >> 3) draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical=20 > >> considerations result in a PW Control Word that could be=20 > mistaken for=20 > >> an IP packet, the Control Word SHOULD be preceded by a PWE3 PTI."=20 > >> However, as we all seem to agree on, a CW will never be=20 > mistaken for=20 > >> an IP packet. > >> > >> Therefore, rather than proposing a PTI that preceded a CW, I think=20 > >> the following solution would be sufficient and more elegant: > >> > >> If the PW does not carry VCCV traffic, a CW is only mandatory if=20 > >> specified in the relevant encapsulation draft > >> > >> If the PW carries VCCV traffic, then: > >> > >> a) all payload traffic MUST be preceded by a Control Word=20 > that starts=20 > >> with 0000 > >> > >> b) all VCCV traffic MUSTbe preceded by an "OAM Protocol=20 > Identifier"=20 > >> (OPI), which has the following format: > >> > >> [0001 | resv | protocol id], > >> > >> where protocol id identifies one of the following protocols: LSP=20 > >> Ping, ICMP, BFD, Y.1711, other(?). > >> > >> Peter > >> > >> -----Original Message----- > >> From: Florin Balus [mailto:balus@nortelnetworks.com] > >> Sent: Thursday, August 12, 2004 12:42 PM > >> To: Busschbach, Peter B (Peter); Stewart Bryant > >> Cc: pwe3@ietf.org; Jeffrey Sugimoto > >> Subject: RE: [PWE3] > >> draft-bryant-mcpherson-pwe3-cw-00.txt WG request > >> > >> Peter, > >> See in-line... > >> > >> Stewart, > >> There might be another motivator for a mandatory > >> CW/consolidation under PTI: assuming we have a PW type > >> that does not mandate a CW (ATM N to one cell > >> mode) couldn't we get payloads that are mistaken also > >> for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could > >> be interpreted by the receiving PE as 0001? (thanks Jeff > >> for bringing this up) > >> > >> Regards, > >> Florin > >> > >> -----Original Message----- > >> From: Busschbach, Peter B (Peter) > >> [mailto:busschbach@lucent.com] > >> Sent: Wednesday, August 11, 2004 2:41 PM > >> To: Balus, Florin [CAR:6955:EXCH]; Stewart > >> Bryant > >> Cc: pwe3@ietf.org > >> Subject: RE: [PWE3] > >> draft-bryant-mcpherson-pwe3-cw-00.txt WG > >> request > >> > >> Florus, > >> > >> Draft-allan-mpls-pid-00.txt is not accessible > >> anymore. I don't recall what rationale it gave > >> for the need for a PTI. > >> FB: Dave addressed the need for an MPLS PID > >> one year ago from an overall MPLS perspective: > >> e.g. issues arisen from loadsharing on TE link > >> bundles or ECMP in LDP network, OAM > >> extensibility, Multiprotocol over MPLS... > >> > >> Draft-bryant-mcpherson-pwe3-cw-00.txt mentions > >> ECMP as the sole reason for an additional > >> control word. However, introducing PTI to > >> solve the issues related to ECMP seems > >> overkill. It would be good if we can clearly > >> state why we need a PTI. > >> FB I agree with you that the justification in > >> section 4 for PTI versus CW + VCCV could be > >> improved. On the other hand we need the > >> extensibility provided by a PTI/PID: VCCV is > >> just an instantiation of a PTI if you think > >> about it, just the formats need to be aligned. > >> Whether or not is a good idea to move the PW > >> user data to 0001 format is to be debated. We > >> need to make sure though the 2 formats could > >> coexist in a network in the mean time. > >> > >> Peter > >> > >> -----Original Message----- > >> From: Florin Balus > >> [mailto:balus@nortelnetworks.com] > >> Sent: Wednesday, August 11, 2004 > >> 2:17 PM > >> To: Stewart Bryant > >> Cc: pwe3@ietf.org > >> Subject: RE: [PWE3] > >> draft-bryant-mcpherson-pwe3-cw-00.txt > >> WG request > >> > >> Stewart, > >> > >> We did promote the idea of a PID/PTI > >> - see Dave Allan's > >> draft-allan-mpls-pid-00.txt on the > >> subject. Also I think the > >> explanation of ECMP issue > >> (disambiguate from IP/MPLS packets > >> etc) and the overall proposed > >> solution are valid. > >> > >> I just wanted to clarify some > >> technicalities to make sure we > >> clearly identify where we are headed > >> to - i.e. what changes are required > >> in other PWE3 drafts. > >> > >> Assuming we have in the same network > >> PEs that support both formats: > >> - the CW [(0000 CW stuff)(data) & > >> the current VCCV format (0001 PA > >> PPP_DLL)(OAM payload))] > >> - and the newly defined PTI (0001 > >> PTI)(data/VCCV payload/?whatever?). > >> In the same time let's assume other > >> PEs will accept just the PTI - being > >> part of those implementations that > >> do not support 0000. How are we > >> going to ensure the 2 sets of PEs > >> will be able to negotiate in the > >> control plane the right format? > >> > >> Currently we do have in each of the > >> 2 L2 FECs (PWID and Generalized ID) > >> just one bit to determine whether or > >> not the CW should be used - see > >> draft-ietf-pwe3-control-protocol-07.txt > >> section 5.1 and 5.2.2. 0001 > >> implicitly meant up to now VCCV > >> format. How do we differentiate the > >> other 2 possibilities (PTI yes/no)? > >> > >> Also just to make sure I understood > >> correctly: there are some PW types > >> for which the CW is REQUIRED (e.g. > >> ATM N to 1 Cell Mode and AAL5 SDU > >> Frame Mode - see > >> draft-ietf-pwe3-atm-encap-05.txt > >> section 4.3.2). For a PE that will > >> implement the PTI format are we > >> saying the PW frames (after the 2 > >> labels) will look like this: (0001 > >> PTI)(0000 CW stuff)(data)? > >> > >> Is VCCV/OAM going to be > >> differentiated in the same way, just > >> re-using what is already defined: > >> i.e. (0001 PTI)(0001 PA > >> PPP_DLL)(OAM payload)? If not I > >> assume we will need to clarify the > >> PTI code points that are going to be > >> used for VCCV/OAM payload? > >> > >> Thanks for clarifying the above > >> points. > >> Regards, > >> Florin > >> > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org > >> [mailto:pwe3-bounces@ietf.org] On > >> Behalf Of Stewart Bryant > >> Sent: Monday, August 09, 2004 7:54 > >> AM > >> To: pwe3@ietf.org > >> Subject: [PWE3] > >> draft-bryant-mcpherson-pwe3-cw-00.txt > >> WG request > >> > >> The authors request that > >> > >> =20 > >> http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw > >> -00.txt > >> > >> be adopted as a WG item with its > >> title changed to > >> > >> PWE3 MPLS Control Word > >> > >> - Stewart > >> > >> _______________________________________________ > >> > >> 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 > > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Florin Balus" Subject: RE: draft-bryant-mcpherson-pwe3-cw-00.txt WG request Date: Fri, 20 Aug 2004 12:03:32 -0400 Lines: 970 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0268129405==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Aug 20 20:35:55 2004 Return-path: To: Mustapha Aissaoui , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: e19fe12a2b60f5c397f73b74149e8776 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org 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. --===============0268129405== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C486CF.3EA2B211" 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_01C486CF.3EA2B211 Content-Type: text/plain Mustapha, Peter, I would add to the points you made below that in an ECMP environment (implementations where for any IP payload, the IP addresses are used for loadsharing decision) the CW becomes mandatory even if no VCCV is used. Otherwise you might always have some payloads (e.g. IP, ATM, Ethernet PW) that could be interpreted as IP (certain ATM VPI or dest MAC - same as for VCCV). Regards, Florin > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, August 18, 2004 10:52 AM > To: Busschbach, Peter B (Peter) > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request > > > Peter, > I agree with your proposal. One clarification though: > strictly speaking the PTI on OAM packets is only required > when ECMP or other load balancing schemes could split the OAM > and data packets over different paths. Otherwise, the router > alert label should be sufficient and this will not require > the use of the control word on data packets if not required > by the encapsulation. Thus, we have the following two options: > > 1. If PTI is used on OAM packets, CW is mandatory on data packets. > > 2. Otherwise, use router alert label on OAM packets and data > packets will just follow the encapsulaiton requirements, > i.e., CW may or may not be required. > > Also, I would like to have > draft-bryant-mcpherson-pwe3-cw-00.txt add a statement to > encourage future PW encapsulations to continue using the all > zero nibble immediately following the bottom of the label > stack for data packets. > > Mustapha. > --------- > > "Busschbach, Peter B (Peter)" wrote: > > > > Florin, > > > > You write: "On the other hand we need the extensibility > provided by a > > PTI/PID: VCCV is just an instantiation of a PTI if you think about > > it, just the formats need to be aligned". > > > > I agree that VCCV is one instantiation of a protocol that could be > > carried over a PW. However, the point I raised in an > earlier email is > > whether there are other instantiations. Because, if VCCV is the > > *only* instantation, you don't need a PID, but just a way to > > differentate VCCV traffic from the PW payload traffic. > > > > That said, this email thread has made a few things clear: > > > > 1) As Mustapha observed, even if you don't need to identify the PW > > payload traffic, you might still need to differentiate between > > different types of OAM traffic > > > > 2) As you observed, if you run VCCV traffic over a Pseudo > Wire, then a > > Control Word , be it CW or PTI, must necessarily preceed > all payload > > and OAM traffic. > > > > 3) draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical > > considerations result in a PW Control Word that could be > mistaken for > > an IP packet, the Control Word SHOULD be preceded by a PWE3 PTI." > > However, as we all seem to agree on, a CW will never be > mistaken for > > an IP packet. > > > > Therefore, rather than proposing a PTI that preceded a CW, > I think the > > following solution would be sufficient and more elegant: > > > > If the PW does not carry VCCV traffic, a CW is only mandatory if > > specified in the relevant encapsulation draft > > > > If the PW carries VCCV traffic, then: > > > > a) all payload traffic MUST be preceded by a Control Word > that starts > > with 0000 > > > > b) all VCCV traffic MUSTbe preceded by an "OAM Protocol Identifier" > > (OPI), which has the following format: > > > > [0001 | resv | protocol id], > > > > where protocol id identifies one of the following > protocols: LSP Ping, > > ICMP, BFD, Y.1711, other(?). > > > > Peter > > > > -----Original Message----- > > From: Florin Balus [mailto:balus@nortelnetworks.com] > > Sent: Thursday, August 12, 2004 12:42 PM > > To: Busschbach, Peter B (Peter); Stewart Bryant > > Cc: pwe3@ietf.org; Jeffrey Sugimoto > > Subject: RE: [PWE3] > > draft-bryant-mcpherson-pwe3-cw-00.txt WG request > > > > Peter, > > See in-line... > > > > Stewart, > > There might be another motivator for a mandatory > > CW/consolidation under PTI: assuming we have a PW type > > that does not mandate a CW (ATM N to one cell > > mode) couldn't we get payloads that are mistaken also > > for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could > > be interpreted by the receiving PE as 0001? (thanks Jeff > > for bringing this up) > > > > Regards, > > Florin > > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) > > [mailto:busschbach@lucent.com] > > Sent: Wednesday, August 11, 2004 2:41 PM > > To: Balus, Florin [CAR:6955:EXCH]; Stewart > > Bryant > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] > > draft-bryant-mcpherson-pwe3-cw-00.txt WG > > request > > > > Florus, > > > > Draft-allan-mpls-pid-00.txt is not accessible > > anymore. I don't recall what rationale it gave > > for the need for a PTI. > > FB: Dave addressed the need for an MPLS PID > > one year ago from an overall MPLS perspective: > > e.g. issues arisen from loadsharing on TE link > > bundles or ECMP in LDP network, OAM > > extensibility, Multiprotocol over MPLS... > > > > Draft-bryant-mcpherson-pwe3-cw-00.txt mentions > > ECMP as the sole reason for an additional > > control word. However, introducing PTI to > > solve the issues related to ECMP seems > > overkill. It would be good if we can clearly > > state why we need a PTI. > > FB I agree with you that the justification in > > section 4 for PTI versus CW + VCCV could be > > improved. On the other hand we need the > > extensibility provided by a PTI/PID: VCCV is > > just an instantiation of a PTI if you think > > about it, just the formats need to be aligned. > > Whether or not is a good idea to move the PW > > user data to 0001 format is to be debated. We > > need to make sure though the 2 formats could > > coexist in a network in the mean time. > > > > Peter > > > > -----Original Message----- > > From: Florin Balus > > [mailto:balus@nortelnetworks.com] > > Sent: Wednesday, August 11, 2004 > > 2:17 PM > > To: Stewart Bryant > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] > > draft-bryant-mcpherson-pwe3-cw-00.txt > > WG request > > > > Stewart, > > > > We did promote the idea of a PID/PTI > > - see Dave Allan's > > draft-allan-mpls-pid-00.txt on the > > subject. Also I think the > > explanation of ECMP issue > > (disambiguate from IP/MPLS packets > > etc) and the overall proposed > > solution are valid. > > > > I just wanted to clarify some > > technicalities to make sure we > > clearly identify where we are headed > > to - i.e. what changes are required > > in other PWE3 drafts. > > > > Assuming we have in the same network > > PEs that support both formats: > > - the CW [(0000 CW stuff)(data) & > > the current VCCV format (0001 PA > > PPP_DLL)(OAM payload))] > > - and the newly defined PTI (0001 > > PTI)(data/VCCV payload/?whatever?). > > In the same time let's assume other > > PEs will accept just the PTI - being > > part of those implementations that > > do not support 0000. How are we > > going to ensure the 2 sets of PEs > > will be able to negotiate in the > > control plane the right format? > > > > Currently we do have in each of the > > 2 L2 FECs (PWID and Generalized ID) > > just one bit to determine whether or > > not the CW should be used - see > > draft-ietf-pwe3-control-protocol-07.txt > > section 5.1 and 5.2.2. 0001 > > implicitly meant up to now VCCV > > format. How do we differentiate the > > other 2 possibilities (PTI yes/no)? > > > > Also just to make sure I understood > > correctly: there are some PW types > > for which the CW is REQUIRED (e.g. > > ATM N to 1 Cell Mode and AAL5 SDU > > Frame Mode - see > > draft-ietf-pwe3-atm-encap-05.txt > > section 4.3.2). For a PE that will > > implement the PTI format are we > > saying the PW frames (after the 2 > > labels) will look like this: (0001 > > PTI)(0000 CW stuff)(data)? > > > > Is VCCV/OAM going to be > > differentiated in the same way, just > > re-using what is already defined: > > i.e. (0001 PTI)(0001 PA > > PPP_DLL)(OAM payload)? If not I > > assume we will need to clarify the > > PTI code points that are going to be > > used for VCCV/OAM payload? > > > > Thanks for clarifying the above > > points. > > Regards, > > Florin > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org > > [mailto:pwe3-bounces@ietf.org] On > > Behalf Of Stewart Bryant > > Sent: Monday, August 09, 2004 7:54 > > AM > > To: pwe3@ietf.org > > Subject: [PWE3] > > draft-bryant-mcpherson-pwe3-cw-00.txt > > WG request > > > > The authors request that > > > > > > > http://www.ietf.org/internet-drafts/draft-> bryant-mcpherson-pwe3-cw-00. > > txt > > > > be adopted as a WG item with its > > title changed to > > > > PWE3 MPLS Control Word > > > > - Stewart > > > > _______________________________________________ > > > > 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 > ------_=_NextPart_001_01C486CF.3EA2B211 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG = request

Mustapha, Peter,
I would add to the points you made below that in an = ECMP environment (implementations where for any IP payload, the IP = addresses are used for loadsharing decision) the CW becomes mandatory = even if no VCCV is  used.

Otherwise you might always have some payloads (e.g. = IP, ATM, Ethernet PW) that could be interpreted as IP (certain ATM VPI = or dest MAC - same as for VCCV).

Regards,
Florin

> -----Original Message-----
> From: Mustapha Aissaoui [mailto:mustapha.aissaoui@a= lcatel.com]
> Sent: Wednesday, August 18, 2004 10:52 = AM
> To: Busschbach, Peter B (Peter)
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] = draft-bryant-mcpherson-pwe3-cw-00.txt WG request
>
>
> Peter,
> I agree with your proposal. One clarification = though:
> strictly speaking the PTI on OAM packets is = only required
> when ECMP or other load balancing schemes could = split the OAM
> and data packets over different paths. = Otherwise, the router
> alert label should be sufficient and this will = not require
> the use of the control word on data packets if = not required
> by the encapsulation. Thus, we have the = following two options:
>
> 1. If PTI is used on OAM packets, CW is = mandatory on data packets.
>
> 2. Otherwise, use router alert label on OAM = packets and data
> packets will just follow the encapsulaiton = requirements,
> i.e., CW may or may not be required.
>
> Also, I would like to have
> draft-bryant-mcpherson-pwe3-cw-00.txt add a = statement to
> encourage future PW encapsulations to continue = using the all
> zero nibble immediately following the bottom of = the label
> stack for data packets.
>
> Mustapha.
> ---------
> > "Busschbach, Peter B (Peter)" = wrote:
> >
> > Florin,
> >
> > You write: "On the other hand we need = the extensibility
> provided by a
> > PTI/PID:  VCCV is just an = instantiation of a PTI if you think about
> > it, just the formats need to be = aligned".
> >
> > I agree that VCCV is one instantiation of = a protocol that could be
> > carried over a PW. However, the point I = raised in an
> earlier email is
> > whether there are other instantiations. = Because, if VCCV is the
> > *only* instantation, you don't need a PID, = but just a way to
> > differentate VCCV traffic from the PW = payload traffic.
> >
> > That said, this email thread has made a = few things clear:
> >
> > 1) As Mustapha observed, even if you don't = need to identify the PW
> > payload traffic, you might still need to = differentiate between
> > different types of OAM traffic
> >
> > 2) As you observed, if you run VCCV = traffic over a Pseudo
> Wire, then a
> > Control Word , be it CW or PTI, must = necessarily preceed
> all payload
> > and OAM traffic.
> >
> > 3)  = draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical =
> > considerations result in a PW Control Word = that could be
> mistaken for
> > an IP packet, the Control Word SHOULD be = preceded by a PWE3 PTI."
> > However, as we all seem to agree on, a CW = will never be
> mistaken for
> > an IP packet.
> >
> > Therefore, rather than proposing a PTI = that preceded a CW,
> I think the
> > following solution would be sufficient and = more elegant:
> >
> > If the PW does not carry VCCV traffic, a = CW is only mandatory if
> > specified in the relevant encapsulation = draft
> >
> > If the PW carries VCCV traffic, = then:
> >
> > a) all payload traffic MUST be preceded by = a Control Word
> that starts
> > with 0000
> >
> > b) all VCCV traffic MUSTbe preceded by an = "OAM Protocol Identifier"
> > (OPI), which has the following = format:
> >
> >     [0001 | resv | = protocol id],
> >
> > where protocol id identifies one of the = following
> protocols: LSP Ping,
> > ICMP, BFD, Y.1711, other(?).
> >
> > Peter
> >
> >      = -----Original Message-----
> >      From: Florin = Balus [mailto:balus@nortelnetworks.com= ]
> >      Sent: = Thursday, August 12, 2004 12:42 PM
> >      To: = Busschbach, Peter B (Peter); Stewart Bryant
> >      Cc: = pwe3@ietf.org; Jeffrey Sugimoto
> >      Subject: RE: = [PWE3]
> >      = draft-bryant-mcpherson-pwe3-cw-00.txt WG request
> >
> >      = Peter,
> >      See = in-line...
> >
> >      = Stewart,
> >      There might = be another motivator for a mandatory
> >      = CW/consolidation under PTI: assuming we have a PW type
> >      that does = not mandate a CW (ATM N to one cell
> >      mode) = couldn't we get payloads that are mistaken also
> >      for = 0001/VCCV packets - e.g. VPI 64 in an ATM cell could
> >      be = interpreted by the receiving PE as 0001? (thanks Jeff
> >      for bringing = this up)
> >
> >      = Regards,
> >      = Florin
> >
> = >           = -----Original Message-----
> = >           From: = Busschbach, Peter B (Peter)
> = >           [mailto:busschbach@lucent.com]<= /FONT>
> = >           Sent: = Wednesday, August 11, 2004 2:41 PM
> = >           To: = Balus, Florin [CAR:6955:EXCH]; Stewart
> = >           = Bryant
> = >           Cc: = pwe3@ietf.org
> = >           = Subject: RE: [PWE3]
> = >           = draft-bryant-mcpherson-pwe3-cw-00.txt WG
> = >           = request
> >
> = >           = Florus,
> >
> = >           = Draft-allan-mpls-pid-00.txt  is not accessible
> = >           = anymore. I don't recall what rationale it gave
> = >           for = the need for a PTI.
> = >           FB: = Dave addressed the need for an MPLS PID
> = >           one = year ago from an overall MPLS perspective:
> = >           e.g. = issues arisen from loadsharing on TE link
> = >           = bundles or ECMP in LDP network,  OAM
> = >           = extensibility, Multiprotocol over MPLS...
> >
> = >           = Draft-bryant-mcpherson-pwe3-cw-00.txt mentions
> = >           ECMP = as the sole reason for an additional
> = >           = control word. However, introducing PTI to
> = >           solve = the issues related to ECMP seems
> = >           = overkill. It would be good if we can clearly
> = >           state = why we need a PTI.
> = >           FB I = agree with you that the justification in
> = >           = section 4 for PTI versus CW + VCCV could be
> = >           = improved. On the other hand we need the
> = >           = extensibility provided by a PTI/PID:  VCCV is
> = >           just = an instantiation of a PTI if you think
> = >           about = it, just the formats need to be aligned.
> = >           = Whether or not is a good idea to move the PW
> = >           user = data to 0001 format is to be debated. We
> = >           need = to make sure though the 2 formats could
> = >           = coexist in a network in the mean time.
> >
> = >           = Peter
> >
> = >           &n= bsp;    -----Original Message-----
> = >           &n= bsp;    From: Florin Balus
> = >           &n= bsp;    [mailto:balus@nortelnetworks.com= ]
> = >           &n= bsp;    Sent: Wednesday, August 11, 2004
> = >           &n= bsp;    2:17 PM
> = >           &n= bsp;    To: Stewart Bryant
> = >           &n= bsp;    Cc: pwe3@ietf.org
> = >           &n= bsp;    Subject: RE: [PWE3]
> = >           &n= bsp;    draft-bryant-mcpherson-pwe3-cw-00.txt
> = >           &n= bsp;    WG request
> >
> = >           &n= bsp;    Stewart,
> >
> = >           &n= bsp;    We did promote the idea of a PID/PTI
> = >           &n= bsp;    - see Dave Allan's
> = >           &n= bsp;    draft-allan-mpls-pid-00.txt on the
> = >           &n= bsp;    subject. Also I think the
> = >           &n= bsp;    explanation of ECMP issue
> = >           &n= bsp;    (disambiguate from IP/MPLS packets
> = >           &n= bsp;    etc) and the overall proposed
> = >           &n= bsp;    solution are valid.
> >
> = >           &n= bsp;    I just wanted to clarify some
> = >           &n= bsp;    technicalities to make sure we
> = >           &n= bsp;    clearly identify where we are headed
> = >           &n= bsp;    to - i.e. what changes are required
> = >           &n= bsp;    in other PWE3 drafts.
> >
> = >           &n= bsp;    Assuming we have in the same network
> = >           &n= bsp;    PEs that support both formats:
> = >           &n= bsp;     - the CW [(0000 CW stuff)(data) = &
> = >           &n= bsp;    the current VCCV format (0001 PA
> = >           &n= bsp;    PPP_DLL)(OAM payload))]
> = >           &n= bsp;     - and the newly defined PTI (0001
> = >           &n= bsp;    PTI)(data/VCCV payload/?whatever?).
> = >           &n= bsp;    In the same time let's assume other
> = >           &n= bsp;    PEs will accept just the PTI - being
> = >           &n= bsp;    part of those implementations that
> = >           &n= bsp;    do not support 0000. How are we
> = >           &n= bsp;    going to ensure the 2 sets of PEs
> = >           &n= bsp;    will be able to negotiate in the
> = >           &n= bsp;    control plane the right format?
> >
> = >           &n= bsp;    Currently we do have in each of the
> = >           &n= bsp;    2 L2 FECs (PWID and Generalized ID)
> = >           &n= bsp;    just one bit to determine whether or
> = >           &n= bsp;    not the CW should be used - see
> = >           &n= bsp;    draft-ietf-pwe3-control-protocol-07.txt
> = >           &n= bsp;    section 5.1 and 5.2.2. 0001
> = >           &n= bsp;    implicitly meant up to now VCCV
> = >           &n= bsp;    format. How do we differentiate the
> = >           &n= bsp;    other 2 possibilities (PTI yes/no)?
> >
> = >           &n= bsp;    Also just to make sure I understood
> = >           &n= bsp;    correctly: there are some PW types
> = >           &n= bsp;    for which the CW is REQUIRED (e.g.
> = >           &n= bsp;    ATM N to 1 Cell Mode and AAL5 SDU
> = >           &n= bsp;    Frame Mode - see
> = >           &n= bsp;    draft-ietf-pwe3-atm-encap-05.txt
> = >           &n= bsp;    section 4.3.2). For a PE that will
> = >           &n= bsp;    implement the PTI format are we
> = >           &n= bsp;    saying the PW frames (after the 2
> = >           &n= bsp;    labels) will look like this: (0001
> = >           &n= bsp;    PTI)(0000 CW stuff)(data)?
> >
> = >           &n= bsp;    Is VCCV/OAM going to be
> = >           &n= bsp;    differentiated in the same way, just
> = >           &n= bsp;    re-using what is already defined:
> = >           &n= bsp;    i.e. (0001  PTI)(0001 PA
> = >           &n= bsp;    PPP_DLL)(OAM payload)? If not I
> >       &n= bsp;        assume we will need to = clarify the
> = >           &n= bsp;    PTI code points that are going to be
> = >           &n= bsp;    used for VCCV/OAM payload?
> >
> = >           &n= bsp;    Thanks for clarifying the above
> = >           &n= bsp;    points.
> = >           &n= bsp;    Regards,
> = >           &n= bsp;    Florin
> >
> = >           &n= bsp;    -----Original Message-----
> = >           &n= bsp;    From: pwe3-bounces@ietf.org
> = >           &n= bsp;    [mailto:pwe3-bounces@ietf.org] = On
> = >           &n= bsp;    Behalf Of Stewart Bryant
> = >           &n= bsp;    Sent: Monday, August 09, 2004 7:54
> = >           &n= bsp;    AM
> = >           &n= bsp;    To: pwe3@ietf.org
> = >           &n= bsp;    Subject: [PWE3]
> = >           &n= bsp;    draft-bryant-mcpherson-pwe3-cw-00.txt
> = >           &n= bsp;    WG request
> >
> = >           &n= bsp;    The authors request that
> >
> = >           &n= bsp;   
> >
> http://www.ietf.org/internet-drafts/draft-> = bryant-mcpherson-pwe3-cw-00.
> > txt
> >
> = >           &n= bsp;    be adopted as a WG item with its
> = >           &n= bsp;    title changed to
> >
> = >           &n= bsp;    PWE3 MPLS Control Word
> >
> = >           &n= bsp;    - Stewart
> >
> = >           &n= bsp;    _______________________________________________
> >
> = >           &n= bsp;    pwe3 mailing list
> = >           &n= bsp;    pwe3@ietf.org
> = >           &n= bsp;    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=
>

------_=_NextPart_001_01C486CF.3EA2B211-- --===============0268129405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0268129405==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-cell-transport-01.txt Date: Mon, 23 Aug 2004 15:21:58 -0400 Lines: 97 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Mon Aug 23 23:16:22 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 ATM Transparent Cell Transport Service Author(s) : A. Malis, et al. Filename : draft-ietf-pwe3-cell-transport-01.txt Pages : 4 Date : 2004-8-23 The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for PWE3 ATM cell encapsulation described in [ATM-ENCAPS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cell-transport-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-pwe3-cell-transport-01.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-ietf-pwe3-cell-transport-01.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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Linda Dunbar Subject: What is the difference between EthernetOverPseudowire and Ethernet over MPLS Date: Tue, 24 Aug 2004 15:20:25 -0500 Lines: 13 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-From: pwe3-bounces@ietf.org Tue Aug 24 23:03:59 2004 Return-path: To: pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:50.12833 C:19 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:4 R:4 (0.0000 0.0000) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7BIT X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The " draft-martini-l2circuit-encap-mpls-14.txt" describes the mechanism of mapping Ethernet (and ATM or others ) over MPLS. The "draft-ietf-pwe3-ethernet-encap-07.txt" describes the mechanism of how to map Ethernet to MPLS. Could anyone tell me what is the relationship between those two drafts? Are they conflict with each other? or compliment each other ? and How? Thank you very much for the help. Regards, Linda Dunbar From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-frame-relay-03.txt Date: Mon, 30 Aug 2004 15:52:33 -0400 Lines: 100 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Mon Aug 30 22:42:33 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Frame Relay over Pseudo-Wires Author(s) : C. Kawa, et al. Filename : draft-ietf-pwe3-frame-relay-03.txt Pages : 28 Date : 2004-8-30 This document defines frame relay pseudo-wire emulation edge-to-edge. A frame relay pseudo-wire is a mechanism that exists between a provider's edge network nodes and support as faithfully as possible frame relay services over IP and MPLS packet switched network (PSN). Two mapping modes are defined. The first, one-to-one mapping mode, is characterized by a one to one relationship between a frame relay VC and a pair of MPLS LSPs, and is defined for MPLS PSN only. The second mode is known as port mode or many-to-one mapping mode and is defined for both MPLS PSNs and IP PSNs with L2TPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-pwe3-frame-relay-03.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-ietf-pwe3-frame-relay-03.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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-fragmentation-06.txt Date: Mon, 30 Aug 2004 15:52:38 -0400 Lines: 95 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Mon Aug 30 22:47:31 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Fragmentation and Reassembly Author(s) : A. Malis, M. Townsley Filename : draft-ietf-pwe3-fragmentation-06.txt Pages : 14 Date : 2004-8-30 This document defines a generalized method of performing fragmentation for use by PWE3 protocols and services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-pwe3-fragmentation-06.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-ietf-pwe3-fragmentation-06.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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-fcs-retention-02.txt Date: Mon, 30 Aug 2004 15:52:43 -0400 Lines: 95 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Mon Aug 30 22:49:55 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Frame Check Sequence Retention Author(s) : A. Malis, et al. Filename : draft-ietf-pwe3-fcs-retention-02.txt Pages : 8 Date : 2004-8-30 This document defines a mechanism for preserving frame FCS through Ethernet, Frame Relay, and HDLC pseudowires. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fcs-retention-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-pwe3-fcs-retention-02.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-ietf-pwe3-fcs-retention-02.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-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Ron Cohen" Subject: Minor fix to CEP/TDM bit rate in draft-ietf-pwe3-control-protocol-08.txt Date: Mon, 30 Aug 2004 13:13:48 -0700 Lines: 27 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Mon Aug 30 23:13:38 2004 Return-path: To: "PWE3 \(IETF\)" , "Luca Martini" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi, I believe the the value of CEP/TDM bit rate parameter for CEP VT6 SPE should be changed: "CEP/TDM bit rate: .... 99 - for VT6 SPE...." 99 should be replaced by 107 Regards Ron Ron Cohen CTO Lycium Networks Mobile: 650.823.7672 Mobile: +972.55.245.104 Tel: 650.234.4010 Fax: 650.854.8183 ===================================================== This email message and any files transmitted with it contain confidential information intended only for its addressee(s). If you are not the addressee of this message, any reading, disclosure, copying, printing, distribution or forwarding by you of this message or its content or attachments is strictly forbidden. In such case, please notify us immediately by replying to this message or by calling 650.234.4010 and delete the message from your computer. Thank you.