From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Heiles Juergen Subject: AW: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Date: Thu, 1 Jul 2004 09:13:05 +0200 Lines: 42 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jul 01 09:20:41 2004 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2657.72) 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, see my comments below. Regards Juergen ..... > > BTW MPLS over PW > > would also be needed in order to have a common mapping for > > all L2 clients. > > > [Sasha] Sorry, I do not understand why this is needed. Can > you elaborate? > > MPLS can be a L2 signal like ATM and Ethernet and has to be supported over Sonet/SDH and OTN (see the MPLS GFP mapping above). In case the PW is used as a common encapsulation and multiplexing mechanism for all L2 signals it should also support MPLS like it supports ATM or Ethernet. > > GFP allows for multiplexing of 256 client signals/flows with > > the Channel ID field of the linear extension header. 256 > > seems not to be much, but how often will you have 256 > > different client signals/flows/services between the same two > > end points? > > > [Sasha] This is correct even if I do not know whether linear extension > headers are supported by the existing implementation and deployed. > But I am not sure your remark about 256 different cliets between > the same two end points is justified: G.7041 is not very clear > about the CID space (per trail or global). > And, IMHO, the strong side of draft-pan is about ONE demultiplexing > mechanism > for all kinds of server-client relationships. > > Demultiplexing is only a small part of the overall functionality at the PE. You need frame delineation, supervision and native service processing which will always be client signal specific. GFP has some functions which are missing in a PW and the PW has some functions which are not supported by GFP (e.g. signaling). May be we can combine them if needed. .... From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luis Aguirre Subject: RE: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Date: Thu, 1 Jul 2004 00:24:34 -0800 Lines: 73 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jul 01 09:34:15 2004 Return-path: To: "'Ping Pan'" , neil.2.harrison@bt.com X-Mailer: Internet Mail Service (5.5.2657.72) 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 agree we should be careful in how we present things: Martini PWs are a good method for aggregating and transporting L3/L2 and L2 services across the metro and core transport networks (CPE to MSE or between MSEs across an optical core.) However, PW technology by itself is not enough to provide an economic incentive for service providers to move in this direction and change their service definition. Remember that some of the reasons some large service providers (according to different sources such as Light Reading) are actively looking into this is, among other things, to reduce the cost structure of the Metro/access network and move a step closer towards the integration of the metro and core data networks. The existing metro transport network infrastructure, primarily SONET/SDH, has been optimized to carry private line and conventional voice - transport of data services, in any form, is sub-optimal. A flexible frame delineation mechanism (i.e. GFP) to map data services (e.g. HDLC or Ethernet frames as MPLS packets) into SONET, as well as service adaptation and possibly inverse multiplexing techniques are definitively required to fully realize the benefits of aggregating and transporting data services in the direction of and between network service edge NEs. Aggregating data flows using PWs will remain an academic exercise unless service providers are presented with the economic incentive and a complete architecture, including OAM and end-to-end CoS differentiation to comply with service and customer specific SLAs. Luis -----Original Message----- From: Ping Pan [mailto:pingpan@cs.columbia.edu] Sent: Thursday, July 01, 2004 4:50 AM To: neil.2.harrison@bt.com Cc: pwe3@ietf.org Subject: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Hi, The way this thread is going, I think we need to be careful: First, dry-martini is a proposal to aggregate flow over ANY media types, not for SONET/SDH only. I do aware of the ITU attempt to support GFP/MPLS/PW switching in the core. But our idea is much generic and flexible here. As far as I am concerned, we can aggregate a bunch of Ethernet or ATM flows over a WiMax connection using martini-encapsulation, and target LDP. :-) In terms of OAM, it has been a touchy issue for a long time. At the end of the day, we need to provide a combination of LSP-ping, VCCV, BFD, SONET PM, ATM OAM, Ethernet Mibs, AAA, billing... to the carriers, a.k.a. a clean OSS solution (or get HeavyReading to run another survey on the topic :-)). To avoid getting side-tracked, we intentionally avoided OAM discussion in the draft. If people like to work on it, let's talk off-line. All we are proposing here is to re-use draft-martini to transport data over packet/circuit networks! (By the way, I have no problem with GFP itself. I am just not sure why I need it for traffic aggregation at edge. In fact, I have the GFP-F, VCAT, LCAS, the whole nine-yard running in my lab. The only useful GFP application I can see so far is the function of sending EFFI as client frame to notification link outage when I pull a client port. Other than that, GFP is a simpler version of GRE to me, IMHO. :-) From packet encapsulation point of view, I can find a half dozen vendors that can support draft-martini on the MAC/Mapper/Framer chips today, but not a single one that would allow me to modify GFP extension headers. :-() 2 cents, - Ping _______________________________________________ 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: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Date: Thu, 1 Jul 2004 10:22:40 +0100 Lines: 136 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: anthony.flavin@bt.com, pwe3@ietf.org, alan.mcguire@bt.com X-From: pwe3-bounces@ietf.org Thu Jul 01 16:14:29 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Thread-Index: AcRfPIv9b8ovtIQgTIiIVE4cVtOZNAABLttg To: , X-OriginalArrivalTime: 01 Jul 2004 09:22:41.0878 (UTC) FILETIME=[F5C63F60:01C45F4C] 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 Bang on the money Luis. If we do not see a sound commercial reason = (backed up by technical correctness/efficacy) then why should we do it? And OAM should not be an afterthought either.....do folks remember the = BOF we ran a couple of years ago and were told by a few vendors that = MPLS OAM was not required (I seem to recall we were told to = (paraphrased) 'go buy kit from vendors who don't have problems....don't = add OAM to fix problems') Seems there has been a significant change of = heart now......but of course only to OAM that suits ;-) Irrespective of the protocols we finally decide on here, the functions = (and order of processing) are the same. And I also wish folks would = stop pushing this notion of 'PWs' here.....this has nothing to do with = 'PWs' or the so-called Martini CW (which is effectively redundant for a = well-behaved co-ps or co-cs server layer network). This is all to do = with: - adopting LDP signalling - using the shim header for muxing/demuxing So its a limited case of MPLS deployment and the notion of PWs is a = misleading issue IMO, eg suppose we wanted to carry ATM over SDH = say....do you really think we would do ATM->Martini_CW(set to = null)->LDP_shim-header->GFP->VC4 etc....I think you might find we would = do ATM->VC4 in this case. Same goes for ethernet over SDH, but here GFP = would be used as eth->GFP->VC4 and not eth->Martini_CW(set to = null)->LDP_shim-header->GFP->VC4. regards, Neil > -----Original Message----- > From: Luis Aguirre [mailto:Luis@Corrigent.com] > Sent: 01 July 2004 09:25 > To: 'Ping Pan'; Harrison,N,Neil,IKR2 R > Cc: pwe3@ietf.org > Subject: RE: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt >=20 >=20 > I agree we should be careful in how we present things: >=20 > Martini PWs are a good method for aggregating and=20 > transporting L3/L2 and L2 > services across the metro and core transport networks (CPE to=20 > MSE or between > MSEs across an optical core.) However, PW technology by=20 > itself is not enough > to provide an economic incentive for service providers to move in this > direction and change their service definition. Remember that=20 > some of the > reasons some large service providers (according to different=20 > sources such as > Light Reading) are actively looking into this is, among other=20 > things, to > reduce the cost structure of the Metro/access network and=20 > move a step closer > towards the integration of the metro and core data networks.=20 > The existing > metro transport network infrastructure, primarily SONET/SDH, has been > optimized to carry private line and conventional voice -=20 > transport of data > services, in any form, is sub-optimal. A flexible frame delineation > mechanism (i.e. GFP) to map data services (e.g. HDLC or=20 > Ethernet frames as > MPLS packets) into SONET, as well as service adaptation and=20 > possibly inverse > multiplexing techniques are definitively required to fully realize the > benefits of aggregating and transporting data services in the=20 > direction of > and between network service edge NEs. Aggregating data flows=20 > using PWs will > remain an academic exercise unless service providers are=20 > presented with the > economic incentive and a complete architecture, including OAM=20 > and end-to-end > CoS differentiation to comply with service and customer=20 > specific SLAs. =20 >=20 > Luis >=20 > -----Original Message----- > From: Ping Pan [mailto:pingpan@cs.columbia.edu]=20 > Sent: Thursday, July 01, 2004 4:50 AM > To: neil.2.harrison@bt.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt >=20 > Hi, >=20 > The way this thread is going, I think we need to be careful: >=20 > First, dry-martini is a proposal to aggregate flow over ANY=20 > media types,=20 > not for SONET/SDH only. I do aware of the ITU attempt to support=20 > GFP/MPLS/PW switching in the core. But our idea is much generic and=20 > flexible here. As far as I am concerned, we can aggregate a bunch of=20 > Ethernet or ATM flows over a WiMax connection using=20 > martini-encapsulation, and target LDP. :-) >=20 > In terms of OAM, it has been a touchy issue for a long time.=20 > At the end=20 > of the day, we need to provide a combination of LSP-ping, VCCV, BFD,=20 > SONET PM, ATM OAM, Ethernet Mibs, AAA, billing... to the carriers,=20 > a.k.a. a clean OSS solution (or get HeavyReading to run=20 > another survey=20 > on the topic :-)). To avoid getting side-tracked, we intentionally=20 > avoided OAM discussion in the draft. If people like to work=20 > on it, let's=20 > talk off-line. >=20 > All we are proposing here is to re-use draft-martini to=20 > transport data=20 > over packet/circuit networks! >=20 > (By the way, I have no problem with GFP itself. I am just not=20 > sure why I=20 > need it for traffic aggregation at edge. In fact, I have the GFP-F,=20 > VCAT, LCAS, the whole nine-yard running in my lab. The only=20 > useful GFP=20 > application I can see so far is the function of sending EFFI=20 > as client=20 > frame to notification link outage when I pull a client port.=20 > Other than=20 > that, GFP is a simpler version of GRE to me, IMHO. :-) From packet=20 > encapsulation point of view, I can find a half dozen vendors that can=20 > support draft-martini on the MAC/Mapper/Framer chips today, but not a=20 > single one that would allow me to modify GFP extension headers. :-() >=20 > 2 cents, >=20 > - Ping >=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: "Thomas D. Nadeau" Subject: Re: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Date: Thu, 1 Jul 2004 10:42:51 -0400 Lines: 153 Sender: pwe3-bounces@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF37E0@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: anthony.flavin@bt.com, pingpan@cs.columbia.edu, pwe3@ietf.org, alan.mcguire@bt.com, Luis@Corrigent.com X-From: pwe3-bounces@ietf.org Thu Jul 01 18:01:09 2004 Return-path: X-BrightmailFiltered: true In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF37E0@i2km07-ukbr.domain1.systemhost.net> To: neil.2.harrison@bt.com X-Mailer: Apple Mail (2.618) 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 This is definitely one of those rare occasions where Neil and I agree completely. *) In addition to the MIB support which is generally mandatory, we should make it a requirement to build OAM functionality into new solutions like this one from the get-go. --Tom > Bang on the money Luis. If we do not see a sound commercial reason > (backed up by technical correctness/efficacy) then why should we do > it? > > And OAM should not be an afterthought either.....do folks remember the > BOF we ran a couple of years ago and were told by a few vendors that > MPLS OAM was not required (I seem to recall we were told to > (paraphrased) 'go buy kit from vendors who don't have > problems....don't add OAM to fix problems') Seems there has been a > significant change of heart now......but of course only to OAM that > suits ;-) > > Irrespective of the protocols we finally decide on here, the functions > (and order of processing) are the same. And I also wish folks would > stop pushing this notion of 'PWs' here.....this has nothing to do with > 'PWs' or the so-called Martini CW (which is effectively redundant for > a well-behaved co-ps or co-cs server layer network). This is all to > do with: > - adopting LDP signalling > - using the shim header for muxing/demuxing > > So its a limited case of MPLS deployment and the notion of PWs is a > misleading issue IMO, eg suppose we wanted to carry ATM over SDH > say....do you really think we would do ATM->Martini_CW(set to > null)->LDP_shim-header->GFP->VC4 etc....I think you might find we > would do ATM->VC4 in this case. Same goes for ethernet over SDH, but > here GFP would be used as eth->GFP->VC4 and not eth->Martini_CW(set to > null)->LDP_shim-header->GFP->VC4. > > regards, Neil > >> -----Original Message----- >> From: Luis Aguirre [mailto:Luis@Corrigent.com] >> Sent: 01 July 2004 09:25 >> To: 'Ping Pan'; Harrison,N,Neil,IKR2 R >> Cc: pwe3@ietf.org >> Subject: RE: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt >> >> >> I agree we should be careful in how we present things: >> >> Martini PWs are a good method for aggregating and >> transporting L3/L2 and L2 >> services across the metro and core transport networks (CPE to >> MSE or between >> MSEs across an optical core.) However, PW technology by >> itself is not enough >> to provide an economic incentive for service providers to move in this >> direction and change their service definition. Remember that >> some of the >> reasons some large service providers (according to different >> sources such as >> Light Reading) are actively looking into this is, among other >> things, to >> reduce the cost structure of the Metro/access network and >> move a step closer >> towards the integration of the metro and core data networks. >> The existing >> metro transport network infrastructure, primarily SONET/SDH, has been >> optimized to carry private line and conventional voice - >> transport of data >> services, in any form, is sub-optimal. A flexible frame delineation >> mechanism (i.e. GFP) to map data services (e.g. HDLC or >> Ethernet frames as >> MPLS packets) into SONET, as well as service adaptation and >> possibly inverse >> multiplexing techniques are definitively required to fully realize the >> benefits of aggregating and transporting data services in the >> direction of >> and between network service edge NEs. Aggregating data flows >> using PWs will >> remain an academic exercise unless service providers are >> presented with the >> economic incentive and a complete architecture, including OAM >> and end-to-end >> CoS differentiation to comply with service and customer >> specific SLAs. >> >> Luis >> >> -----Original Message----- >> From: Ping Pan [mailto:pingpan@cs.columbia.edu] >> Sent: Thursday, July 01, 2004 4:50 AM >> To: neil.2.harrison@bt.com >> Cc: pwe3@ietf.org >> Subject: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt >> >> Hi, >> >> The way this thread is going, I think we need to be careful: >> >> First, dry-martini is a proposal to aggregate flow over ANY >> media types, >> not for SONET/SDH only. I do aware of the ITU attempt to support >> GFP/MPLS/PW switching in the core. But our idea is much generic and >> flexible here. As far as I am concerned, we can aggregate a bunch of >> Ethernet or ATM flows over a WiMax connection using >> martini-encapsulation, and target LDP. :-) >> >> In terms of OAM, it has been a touchy issue for a long time. >> At the end >> of the day, we need to provide a combination of LSP-ping, VCCV, BFD, >> SONET PM, ATM OAM, Ethernet Mibs, AAA, billing... to the carriers, >> a.k.a. a clean OSS solution (or get HeavyReading to run >> another survey >> on the topic :-)). To avoid getting side-tracked, we intentionally >> avoided OAM discussion in the draft. If people like to work >> on it, let's >> talk off-line. >> >> All we are proposing here is to re-use draft-martini to >> transport data >> over packet/circuit networks! >> >> (By the way, I have no problem with GFP itself. I am just not >> sure why I >> need it for traffic aggregation at edge. In fact, I have the GFP-F, >> VCAT, LCAS, the whole nine-yard running in my lab. The only >> useful GFP >> application I can see so far is the function of sending EFFI >> as client >> frame to notification link outage when I pull a client port. >> Other than >> that, GFP is a simpler version of GRE to me, IMHO. :-) From packet >> encapsulation point of view, I can find a half dozen vendors that can >> support draft-martini on the MAC/Mapper/Framer chips today, but not a >> single one that would allow me to modify GFP extension headers. :-() >> >> 2 cents, >> >> - Ping >> >> >> _______________________________________________ >> 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: Ping Pan Subject: Re: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Date: Thu, 01 Jul 2004 07:45:13 -0700 Lines: 16 Sender: pwe3-bounces@ietf.org References: <871D2505A985CB4697DFAECC11CAD46E4A472D@MXSJ> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jul 01 18:01:52 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, zh-cn, zh, zh-tw, zh-hk To: Luis Aguirre In-Reply-To: <871D2505A985CB4697DFAECC11CAD46E4A472D@MXSJ> 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 Luis Aguirre wrote: > Aggregating data flows using PWs will > remain an academic exercise unless service providers are presented with the > economic incentive and a complete architecture, including OAM and end-to-end > CoS differentiation to comply with service and customer specific SLAs. > Good comment. Does this statement hold for both PW-over-MPLS and PW-over-sub-ip? It sounds it applies to both. Regards, - Ping > Luis > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Thu, 1 Jul 2004 20:26:49 +0300 Lines: 10 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , pwe3@ietf.org, "Peterson, Jon" , Danny McPherson , Scott Bradner , stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Jul 01 19:52:07 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRdG6QBFNVqepXkRleMqDMP12Qn6QCdKy9g To: 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 =20 > So, now I see why you want to pursue this! Are you=20 > submitting a draft specifying the signaling procedures?=20 I could. But the obvious solution is to use standard PWE signaling based on targeted LDP. Y(J)S =20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: ITU-T Q5/13 Liason re PW over UDP Date: Thu, 01 Jul 2004 13:39:57 -0400 Lines: 7 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202BC3DDF@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: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jul 01 20:21:27 2004 Return-path: X-BrightmailFiltered: true To: "Yaakov Stein" In-reply-to: Your message of Thu, 01 Jul 2004 20:26:49 +0300. <27A0F290348F8E45AEF79889DDE65A5202BC3DDF@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-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 obvious solution is to use standard PWE signaling based on targeted > LDP That results in an exchange of MPLS labels for the pseudowire, while you seem to be asking for something which results in an exchange of UDP port numbers. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Thu, 1 Jul 2004 20:50:00 +0300 Lines: 22 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 Jul 01 20:28:07 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRfkmQHgu7nY67cSZ6VSBfWsBefOgAAQHTQ To: 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 > > the obvious solution is to use standard PWE signaling based on=20 > > targeted LDP >=20 > That results in an exchange of MPLS labels for the=20 > pseudowire, while you seem to be asking for something=20 > which results in an exchange of UDP port numbers.=20 Precisely. Of course we need to remember that UDP port numbers have fewer bits than MPLS labels, but there is no other major difference. Similarly, PWE signaling could be used for exchanging VLAN tags (which we aren't handling here at the IETF, but other forums are). This would result in a single label distribution protocol no matter where the demux labels are in the PSN headers. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: ITU-T Q5/13 Liason re PW over UDP Date: Thu, 01 Jul 2004 14:11:22 -0400 Lines: 8 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202BC3DE0@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: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jul 01 20:52:00 2004 Return-path: X-BrightmailFiltered: true To: "Yaakov Stein" In-reply-to: Your message of Thu, 01 Jul 2004 20:50:00 +0300. <27A0F290348F8E45AEF79889DDE65A5202BC3DE0@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-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 > Of course we need to remember that UDP port numbers > have fewer bits than MPLS labels, but there is no other > major difference. Are you suggesting that UDP port numbers should be encoded into LDP's label TLVs? Since a UDP port number and an MPLS label can have the same numeric value, that seems severely broken. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Thu, 1 Jul 2004 14:40:00 -0400 Lines: 47 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jul 01 21:19:28 2004 Return-path: To: "'Yaakov Stein'" , erosen@cisco.com X-Mailer: Internet Mail Service (5.5.2657.72) 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: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, July 01, 2004 1:50 PM > To: erosen@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] ITU-T Q5/13 Liason re PW over UDP > > > > > > the obvious solution is to use standard PWE signaling based on > > > targeted LDP > > > > That results in an exchange of MPLS labels for the > > pseudowire, while you seem to be asking for something > > which results in an exchange of UDP port numbers. > > Precisely. > > Of course we need to remember that UDP port numbers > have fewer bits than MPLS labels, but there is no other > major difference. > > Similarly, PWE signaling could be used for exchanging > VLAN tags (which we aren't handling here at the IETF, > but other forums are). > > This would result in a single label distribution protocol > no matter where the demux labels are in the PSN headers. > Yaakov, I would turn your argument around. If, as you say, a label id is just a number, why not standardize on one specific format, i.e. MPLS labels. For the encapsulation function the label format may not have major implications, but for packet switches in the middle it does. Therefore, don't extend the label distribution protocol to support additional label formats, but standardize all packet switching applications on one single label format. Peter > 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: neil.2.harrison@bt.com Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Fri, 2 Jul 2004 07:38:05 +0100 Lines: 66 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Jul 02 08:54:47 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRfoI13hm4/BYDsRludB0SzxyM1QwAWorZA To: , , X-OriginalArrivalTime: 02 Jul 2004 06:38:05.0615 (UTC) FILETIME=[2179DBF0:01C45FFF] 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, > > > > the obvious solution is to use standard PWE signaling=20 > based on=20 > > > > targeted LDP > > >=20 > > > That results in an exchange of MPLS labels for the=20 > > > pseudowire, while you seem to be asking for something=20 > > > which results in an exchange of UDP port numbers.=20 > >=20 > > Precisely. > >=20 > > Of course we need to remember that UDP port numbers > > have fewer bits than MPLS labels, but there is no other > > major difference. > >=20 > > Similarly, PWE signaling could be used for exchanging > > VLAN tags (which we aren't handling here at the IETF, > > but other forums are). > >=20 > > This would result in a single label distribution protocol > > no matter where the demux labels are in the PSN headers. > >=20 >=20 > Yaakov, >=20 > I would turn your argument around. If, as you say, a label id=20 > is just a number, why not standardize on one specific format,=20 > i.e. MPLS labels. For the encapsulation function the label=20 > format may not have major implications, but for packet=20 > switches in the middle it does.=20 >=20 > Therefore, don't extend the label distribution protocol to=20 > support additional label formats, but standardize all packet=20 > switching applications on one single label format. >=20 > Peter NH=3D> I tend to agree with you and Eric, but I have additional reasons: As you know, I have some serious reservations about the whole PW = concept. Further, I am a strong believer in understanding/respecting = the functional architecture of transport networks and the constraints = this imposes on the mode considered. We did not develop G.805/G.809 for = fun.....these are very powerful modelling techniques that are important = for the development of management information models. The efficacy of a layer network is largely determined by the = completeness of its functional specification (eg see Tom Nadeaus's = remark to me the other day agreeing that OAM should not be an = afterthought....this is an example of what I mean here), and whether it = respects the connectivity constraints of the mode considered (some = types/features on MPLS break these principles and, as a consequence, = create operational problems.....however, that is a seperate issue which = I do not want to open up here as it is not relevant to this topic). IP is a cl-ps mode technology and MPLS is a co-ps mode technology. = These are different despite protestations to the contrary (if this was = not true then there would be no need for MPLS to exist). However, both = IP and MPLS are layer networks. UDP is *not* a layer network. UDP and = TCP are the key application adaptation functions of IP (in principle, = however, they could be used with other layer networks). Speaking as an operator I do not see the requirement for carrying = (other) layer networks over an application adaptation function (here = UDP). This makes no sense at all to me. regards, Neil=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Italo.Busi@alcatel.it Subject: RE: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Date: Fri, 2 Jul 2004 09:38:19 +0200 Lines: 186 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, anthony.flavin@bt.com, pingpan@cs.columbia.edu, alan.mcguire@bt.com, Luis@Corrigent.com X-From: pwe3-bounces@ietf.org Fri Jul 02 09:50:49 2004 Return-path: To: "Thomas D. Nadeau" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/02/2004 09:38:07, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/02/2004 09:38:09, Serialize complete at 07/02/2004 09:38:09 X-Alcanet-MTA-scanned-and-authorized: yes 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 I am a little bit lost in this discussion. IMO, if we have a sub-IP tunnel like an SDH VC4 trail, between two PEs (let's call them PE1 and PE2) and MPLS on top of it, then from the MPLS perpective the two PEs are adjacent PE. This case of adjacent PE seems to me already covered by the current Martini draft: the tunnel label is not used and only the PW label is used. In this scenario, I can apply whatever PW OAM tool I have for the more general case addressed by the Martini draft. Am I missing something? Thanks, Italo > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of > Thomas D. Nadeau > Sent: Thursday, July 01, 2004 16:43 > To: neil.2.harrison@bt.com > Cc: anthony.flavin@bt.com; pingpan@cs.columbia.edu; pwe3@ietf.org; > alan.mcguire@bt.com; Luis@Corrigent.com > Subject: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt > > > > This is definitely one of those rare occasions where Neil and > I agree completely. *) In addition to the MIB support which is > generally mandatory, we should make it a requirement to build OAM > functionality into new solutions like this one from the get-go. > > --Tom > > > > Bang on the money Luis. If we do not see a sound commercial reason > > (backed up by technical correctness/efficacy) then why should we do > > it? > > > > And OAM should not be an afterthought either.....do folks remember the > > BOF we ran a couple of years ago and were told by a few vendors that > > MPLS OAM was not required (I seem to recall we were told to > > (paraphrased) 'go buy kit from vendors who don't have > > problems....don't add OAM to fix problems') Seems there has been a > > significant change of heart now......but of course only to OAM that > > suits ;-) > > > > Irrespective of the protocols we finally decide on here, the functions > > (and order of processing) are the same. And I also wish folks would > > stop pushing this notion of 'PWs' here.....this has nothing to do with > > 'PWs' or the so-called Martini CW (which is effectively redundant for > > a well-behaved co-ps or co-cs server layer network). This is all to > > do with: > > - adopting LDP signalling > > - using the shim header for muxing/demuxing > > > > So its a limited case of MPLS deployment and the notion of PWs is a > > misleading issue IMO, eg suppose we wanted to carry ATM over SDH > > say....do you really think we would do ATM->Martini_CW(set to > > null)->LDP_shim-header->GFP->VC4 etc....I think you might find we > > would do ATM->VC4 in this case. Same goes for ethernet over SDH, but > > here GFP would be used as eth->GFP->VC4 and not eth->Martini_CW(set to > > null)->LDP_shim-header->GFP->VC4. > > > > regards, Neil > > > >> -----Original Message----- > >> From: Luis Aguirre [mailto:Luis@Corrigent.com] > >> Sent: 01 July 2004 09:25 > >> To: 'Ping Pan'; Harrison,N,Neil,IKR2 R > >> Cc: pwe3@ietf.org > >> Subject: RE: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt > >> > >> > >> I agree we should be careful in how we present things: > >> > >> Martini PWs are a good method for aggregating and > >> transporting L3/L2 and L2 > >> services across the metro and core transport networks (CPE to > >> MSE or between > >> MSEs across an optical core.) However, PW technology by > >> itself is not enough > >> to provide an economic incentive for service providers to move in this > >> direction and change their service definition. Remember that > >> some of the > >> reasons some large service providers (according to different > >> sources such as > >> Light Reading) are actively looking into this is, among other > >> things, to > >> reduce the cost structure of the Metro/access network and > >> move a step closer > >> towards the integration of the metro and core data networks. > >> The existing > >> metro transport network infrastructure, primarily SONET/SDH, has been > >> optimized to carry private line and conventional voice - > >> transport of data > >> services, in any form, is sub-optimal. A flexible frame delineation > >> mechanism (i.e. GFP) to map data services (e.g. HDLC or > >> Ethernet frames as > >> MPLS packets) into SONET, as well as service adaptation and > >> possibly inverse > >> multiplexing techniques are definitively required to fully realize the > >> benefits of aggregating and transporting data services in the > >> direction of > >> and between network service edge NEs. Aggregating data flows > >> using PWs will > >> remain an academic exercise unless service providers are > >> presented with the > >> economic incentive and a complete architecture, including OAM > >> and end-to-end > >> CoS differentiation to comply with service and customer > >> specific SLAs. > >> > >> Luis > >> > >> -----Original Message----- > >> From: Ping Pan [mailto:pingpan@cs.columbia.edu] > >> Sent: Thursday, July 01, 2004 4:50 AM > >> To: neil.2.harrison@bt.com > >> Cc: pwe3@ietf.org > >> Subject: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt > >> > >> Hi, > >> > >> The way this thread is going, I think we need to be careful: > >> > >> First, dry-martini is a proposal to aggregate flow over ANY > >> media types, > >> not for SONET/SDH only. I do aware of the ITU attempt to support > >> GFP/MPLS/PW switching in the core. But our idea is much generic and > >> flexible here. As far as I am concerned, we can aggregate a bunch of > >> Ethernet or ATM flows over a WiMax connection using > >> martini-encapsulation, and target LDP. :-) > >> > >> In terms of OAM, it has been a touchy issue for a long time. > >> At the end > >> of the day, we need to provide a combination of LSP-ping, VCCV, BFD, > >> SONET PM, ATM OAM, Ethernet Mibs, AAA, billing... to the carriers, > >> a.k.a. a clean OSS solution (or get HeavyReading to run > >> another survey > >> on the topic :-)). To avoid getting side-tracked, we intentionally > >> avoided OAM discussion in the draft. If people like to work > >> on it, let's > >> talk off-line. > >> > >> All we are proposing here is to re-use draft-martini to > >> transport data > >> over packet/circuit networks! > >> > >> (By the way, I have no problem with GFP itself. I am just not > >> sure why I > >> need it for traffic aggregation at edge. In fact, I have the GFP-F, > >> VCAT, LCAS, the whole nine-yard running in my lab. The only > >> useful GFP > >> application I can see so far is the function of sending EFFI > >> as client > >> frame to notification link outage when I pull a client port. > >> Other than > >> that, GFP is a simpler version of GRE to me, IMHO. :-) From packet > >> encapsulation point of view, I can find a half dozen vendors that can > >> support draft-martini on the MAC/Mapper/Framer chips today, but not a > >> single one that would allow me to modify GFP extension headers. :-() > >> > >> 2 cents, > >> > >> - Ping > >> > >> > >> _______________________________________________ > >> 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: neil.2.harrison@bt.com Subject: RE: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Date: Fri, 2 Jul 2004 11:46:42 +0100 Lines: 279 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, anthony.flavin@bt.com, pingpan@cs.columbia.edu, alan.mcguire@bt.com, Luis@Corrigent.com X-From: pwe3-bounces@ietf.org Fri Jul 02 13:08:18 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Thread-Index: AcRgB50YOj3QVsNqQ+iEldV3gos1sQAFo2lg To: , X-OriginalArrivalTime: 02 Jul 2004 10:46:42.0616 (UTC) FILETIME=[DCB39380:01C46021] 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 Are you familar with G.805 Italo? If not, then may I suggest a look at = G.805 might help (or better, a read of chapter 3 of Reid/Sexton 'BB = networking' or even go talk to Maarten Vissers of your company). The = key issue Tom is now raising (and I have since forever it seems) is that = when we create a layer network, the OAM for that layer network is an = important intrinsic functional component that *must* be incorporated = into the design (of the data-plane) from t=3D0....not addded later as an = afterthought. Further, when the layer network concerned belongs to either the co-cs or = co-ps modes the control (and management) plane protocols can exist OOB = wrt to the traffic data-plane (and there are actually very good reasons = for doing this, security being one reason). This makes the (taffic) = data-plane OAM absolutely essential. Now G.805 defines the concepts of layering (ie vertical client/server = relationships between layer networks) and partitioning (where we can = break down a layer network horizontally into various levels of detail in = terms of subnetworks (these are not IP subnetworks), links, = connection-points, adaptation functions, and trail termination functions = amongst others). This is all quite important for defining equipment = specifications and in particular the network management information = models (if you know any TMF folks or SG15 folks go talk to them and they = will reinforce this point). In a client/server relationship the client and server layer networks are = often not owned by the same party.....so a golden rule here is layer = independence. From the fault management perspective each layer network = therefore must have its own OAM. Now there are 3 networks modes, viz: cl-ps, co-ps and co-cs and all = technologies map to one of these modes. The 'goodness' of the = technology is determined by how complete its functional specification is = (inc OAM) and whether it respects the connectivity constraints of the = mode it belongs to. The behaviour of each mode is quite different, and = this includes the types of defects that can occur in each mode....they = are for sure not the same. The are 9 possible client/server relationships between the 3 = modes....some make more sense than others (you can figure that one out = yourself), but the principle I mentioned above still holds, ie each = layer network must be independent and have its own OAM. Hope that helps paints (some of) the bigger picture here for you. regards, Neil > -----Original Message----- > From: Italo.Busi@alcatel.it [mailto:Italo.Busi@alcatel.it] > Sent: 02 July 2004 08:38 > To: Thomas D. Nadeau; Harrison,N,Neil,IKR2 R > Cc: Flavin,AJ,Tony,XGH6 FLAVINAJ R; pingpan@cs.columbia.edu; > pwe3@ietf.org; Mcguire,A,Alan,XGH6 MCGUIRA R; Luis@Corrigent.com > Subject: RE: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt >=20 >=20 > I am a little bit lost in this discussion. >=20 > IMO, if we have a sub-IP tunnel like an SDH VC4 trail,=20 > between two PEs (let's > call them PE1 and PE2) and MPLS on top of it, then from the=20 > MPLS perpective the > two PEs are adjacent PE. >=20 > This case of adjacent PE seems to me already covered by the=20 > current Martini > draft: the tunnel label is not used and only the PW label is used. >=20 > In this scenario, I can apply whatever PW OAM tool I have for=20 > the more general > case addressed by the Martini draft. >=20 > Am I missing something? >=20 > Thanks, Italo >=20 > > -----Original Message----- > > From: pwe3-bounces@ietf.org=20 > [mailto:pwe3-bounces@ietf.org]On Behalf Of > > Thomas D. Nadeau > > Sent: Thursday, July 01, 2004 16:43 > > To: neil.2.harrison@bt.com > > Cc: anthony.flavin@bt.com; pingpan@cs.columbia.edu; pwe3@ietf.org; > > alan.mcguire@bt.com; Luis@Corrigent.com > > Subject: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt > > > > > > > > This is definitely one of those rare occasions where Neil and > > I agree completely. *) In addition to the MIB support which is > > generally mandatory, we should make it a requirement to build OAM > > functionality into new solutions like this one from the get-go. > > > > --Tom > > > > > > > Bang on the money Luis. If we do not see a sound=20 > commercial reason > > > (backed up by technical correctness/efficacy) then why=20 > should we do > > > it? > > > > > > And OAM should not be an afterthought either.....do folks=20 > remember the > > > BOF we ran a couple of years ago and were told by a few=20 > vendors that > > > MPLS OAM was not required (I seem to recall we were told to > > > (paraphrased) 'go buy kit from vendors who don't have > > > problems....don't add OAM to fix problems') Seems there=20 > has been a > > > significant change of heart now......but of course only=20 > to OAM that > > > suits ;-) > > > > > > Irrespective of the protocols we finally decide on here,=20 > the functions > > > (and order of processing) are the same. And I also wish=20 > folks would > > > stop pushing this notion of 'PWs' here.....this has=20 > nothing to do with > > > 'PWs' or the so-called Martini CW (which is effectively=20 > redundant for > > > a well-behaved co-ps or co-cs server layer network). =20 > This is all to > > > do with: > > > - adopting LDP signalling > > > - using the shim header for muxing/demuxing > > > > > > So its a limited case of MPLS deployment and the notion=20 > of PWs is a > > > misleading issue IMO, eg suppose we wanted to carry ATM over SDH > > > say....do you really think we would do ATM->Martini_CW(set to > > > null)->LDP_shim-header->GFP->VC4 etc....I think you might find we > > > would do ATM->VC4 in this case. Same goes for ethernet=20 > over SDH, but > > > here GFP would be used as eth->GFP->VC4 and not=20 > eth->Martini_CW(set to > > > null)->LDP_shim-header->GFP->VC4. > > > > > > regards, Neil > > > > > >> -----Original Message----- > > >> From: Luis Aguirre [mailto:Luis@Corrigent.com] > > >> Sent: 01 July 2004 09:25 > > >> To: 'Ping Pan'; Harrison,N,Neil,IKR2 R > > >> Cc: pwe3@ietf.org > > >> Subject: RE: [PWE3] FW: I-D=20 > ACTION:draft-pan-pwe3-over-sub-ip-00.txt > > >> > > >> > > >> I agree we should be careful in how we present things: > > >> > > >> Martini PWs are a good method for aggregating and > > >> transporting L3/L2 and L2 > > >> services across the metro and core transport networks (CPE to > > >> MSE or between > > >> MSEs across an optical core.) However, PW technology by > > >> itself is not enough > > >> to provide an economic incentive for service providers=20 > to move in this > > >> direction and change their service definition. Remember that > > >> some of the > > >> reasons some large service providers (according to different > > >> sources such as > > >> Light Reading) are actively looking into this is, among other > > >> things, to > > >> reduce the cost structure of the Metro/access network and > > >> move a step closer > > >> towards the integration of the metro and core data networks. > > >> The existing > > >> metro transport network infrastructure, primarily=20 > SONET/SDH, has been > > >> optimized to carry private line and conventional voice - > > >> transport of data > > >> services, in any form, is sub-optimal. A flexible frame=20 > delineation > > >> mechanism (i.e. GFP) to map data services (e.g. HDLC or > > >> Ethernet frames as > > >> MPLS packets) into SONET, as well as service adaptation and > > >> possibly inverse > > >> multiplexing techniques are definitively required to=20 > fully realize the > > >> benefits of aggregating and transporting data services in the > > >> direction of > > >> and between network service edge NEs. Aggregating data flows > > >> using PWs will > > >> remain an academic exercise unless service providers are > > >> presented with the > > >> economic incentive and a complete architecture, including OAM > > >> and end-to-end > > >> CoS differentiation to comply with service and customer > > >> specific SLAs. > > >> > > >> Luis > > >> > > >> -----Original Message----- > > >> From: Ping Pan [mailto:pingpan@cs.columbia.edu] > > >> Sent: Thursday, July 01, 2004 4:50 AM > > >> To: neil.2.harrison@bt.com > > >> Cc: pwe3@ietf.org > > >> Subject: Re: [PWE3] FW: I-D=20 > ACTION:draft-pan-pwe3-over-sub-ip-00.txt > > >> > > >> Hi, > > >> > > >> The way this thread is going, I think we need to be careful: > > >> > > >> First, dry-martini is a proposal to aggregate flow over ANY > > >> media types, > > >> not for SONET/SDH only. I do aware of the ITU attempt to support > > >> GFP/MPLS/PW switching in the core. But our idea is much=20 > generic and > > >> flexible here. As far as I am concerned, we can=20 > aggregate a bunch of > > >> Ethernet or ATM flows over a WiMax connection using > > >> martini-encapsulation, and target LDP. :-) > > >> > > >> In terms of OAM, it has been a touchy issue for a long time. > > >> At the end > > >> of the day, we need to provide a combination of=20 > LSP-ping, VCCV, BFD, > > >> SONET PM, ATM OAM, Ethernet Mibs, AAA, billing... to the=20 > carriers, > > >> a.k.a. a clean OSS solution (or get HeavyReading to run > > >> another survey > > >> on the topic :-)). To avoid getting side-tracked, we=20 > intentionally > > >> avoided OAM discussion in the draft. If people like to work > > >> on it, let's > > >> talk off-line. > > >> > > >> All we are proposing here is to re-use draft-martini to > > >> transport data > > >> over packet/circuit networks! > > >> > > >> (By the way, I have no problem with GFP itself. I am just not > > >> sure why I > > >> need it for traffic aggregation at edge. In fact, I have=20 > the GFP-F, > > >> VCAT, LCAS, the whole nine-yard running in my lab. The only > > >> useful GFP > > >> application I can see so far is the function of sending EFFI > > >> as client > > >> frame to notification link outage when I pull a client port. > > >> Other than > > >> that, GFP is a simpler version of GRE to me, IMHO. :-)=20 > From packet > > >> encapsulation point of view, I can find a half dozen=20 > vendors that can > > >> support draft-martini on the MAC/Mapper/Framer chips=20 > today, but not a > > >> single one that would allow me to modify GFP extension=20 > headers. :-() > > >> > > >> 2 cents, > > >> > > >> - Ping > > >> > > >> > > >> _______________________________________________ > > >> 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 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Ping Pan Subject: Re: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt Date: Fri, 02 Jul 2004 06:48:19 -0700 Lines: 211 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , pwe3@ietf.org, Luis@Corrigent.com, neil.2.harrison@bt.com, anthony.flavin@bt.com, alan.mcguire@bt.com X-From: pwe3-bounces@ietf.org Fri Jul 02 16:09:13 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, zh-cn, zh, zh-tw, zh-hk To: Italo.Busi@alcatel.it In-Reply-To: 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 Italo.Busi@alcatel.it wrote: > I am a little bit lost in this discussion. > > IMO, if we have a sub-IP tunnel like an SDH VC4 trail, between two PEs (let's > call them PE1 and PE2) and MPLS on top of it, then from the MPLS perpective the > two PEs are adjacent PE. > > This case of adjacent PE seems to me already covered by the current Martini > draft: the tunnel label is not used and only the PW label is used. > Yeap! In which case, the PE's do not need to be MPLS LER's. > In this scenario, I can apply whatever PW OAM tool I have for the more general > case addressed by the Martini draft. > If everything is MPLS LER and LSR, then the entire suite of MPLS and IP tools would apply to the problem. However, in this case, it is a sub-IP network connecting the PE's. We may need to interface the sub-IP OAM to the PW OAM IF/WHEN NECESSARY. In your example of SDH VC4 trail, yes, we need to interface SONET/SDH PM and alarms to PW layer. If the sub-IP tunnel is an ATM connection, we will have more things to interface with, unfortunately. :-) But if the sub-IP tunnel is a Gigabit Ethernet tunnel, unless ITU defines Ethernet PM and alarms, the life is good. :-) Hope this has explained it. Thanks! - Ping > Am I missing something? > > Thanks, Italo > > >>-----Original Message----- >>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of >>Thomas D. Nadeau >>Sent: Thursday, July 01, 2004 16:43 >>To: neil.2.harrison@bt.com >>Cc: anthony.flavin@bt.com; pingpan@cs.columbia.edu; pwe3@ietf.org; >>alan.mcguire@bt.com; Luis@Corrigent.com >>Subject: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt >> >> >> >> This is definitely one of those rare occasions where Neil and >>I agree completely. *) In addition to the MIB support which is >>generally mandatory, we should make it a requirement to build OAM >>functionality into new solutions like this one from the get-go. >> >> --Tom >> >> >> >>>Bang on the money Luis. If we do not see a sound commercial reason >>>(backed up by technical correctness/efficacy) then why should we do >>>it? >>> >>>And OAM should not be an afterthought either.....do folks remember the >>>BOF we ran a couple of years ago and were told by a few vendors that >>>MPLS OAM was not required (I seem to recall we were told to >>>(paraphrased) 'go buy kit from vendors who don't have >>>problems....don't add OAM to fix problems') Seems there has been a >>>significant change of heart now......but of course only to OAM that >>>suits ;-) >>> >>>Irrespective of the protocols we finally decide on here, the functions >>>(and order of processing) are the same. And I also wish folks would >>>stop pushing this notion of 'PWs' here.....this has nothing to do with >>>'PWs' or the so-called Martini CW (which is effectively redundant for >>>a well-behaved co-ps or co-cs server layer network). This is all to >>>do with: >>>- adopting LDP signalling >>>- using the shim header for muxing/demuxing >>> >>>So its a limited case of MPLS deployment and the notion of PWs is a >>>misleading issue IMO, eg suppose we wanted to carry ATM over SDH >>>say....do you really think we would do ATM->Martini_CW(set to >>>null)->LDP_shim-header->GFP->VC4 etc....I think you might find we >>>would do ATM->VC4 in this case. Same goes for ethernet over SDH, but >>>here GFP would be used as eth->GFP->VC4 and not eth->Martini_CW(set to >>>null)->LDP_shim-header->GFP->VC4. >>> >>>regards, Neil >>> >>> >>>>-----Original Message----- >>>>From: Luis Aguirre [mailto:Luis@Corrigent.com] >>>>Sent: 01 July 2004 09:25 >>>>To: 'Ping Pan'; Harrison,N,Neil,IKR2 R >>>>Cc: pwe3@ietf.org >>>>Subject: RE: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt >>>> >>>> >>>>I agree we should be careful in how we present things: >>>> >>>>Martini PWs are a good method for aggregating and >>>>transporting L3/L2 and L2 >>>>services across the metro and core transport networks (CPE to >>>>MSE or between >>>>MSEs across an optical core.) However, PW technology by >>>>itself is not enough >>>>to provide an economic incentive for service providers to move in this >>>>direction and change their service definition. Remember that >>>>some of the >>>>reasons some large service providers (according to different >>>>sources such as >>>>Light Reading) are actively looking into this is, among other >>>>things, to >>>>reduce the cost structure of the Metro/access network and >>>>move a step closer >>>>towards the integration of the metro and core data networks. >>>>The existing >>>>metro transport network infrastructure, primarily SONET/SDH, has been >>>>optimized to carry private line and conventional voice - >>>>transport of data >>>>services, in any form, is sub-optimal. A flexible frame delineation >>>>mechanism (i.e. GFP) to map data services (e.g. HDLC or >>>>Ethernet frames as >>>>MPLS packets) into SONET, as well as service adaptation and >>>>possibly inverse >>>>multiplexing techniques are definitively required to fully realize the >>>>benefits of aggregating and transporting data services in the >>>>direction of >>>>and between network service edge NEs. Aggregating data flows >>>>using PWs will >>>>remain an academic exercise unless service providers are >>>>presented with the >>>>economic incentive and a complete architecture, including OAM >>>>and end-to-end >>>>CoS differentiation to comply with service and customer >>>>specific SLAs. >>>> >>>>Luis >>>> >>>>-----Original Message----- >>>>From: Ping Pan [mailto:pingpan@cs.columbia.edu] >>>>Sent: Thursday, July 01, 2004 4:50 AM >>>>To: neil.2.harrison@bt.com >>>>Cc: pwe3@ietf.org >>>>Subject: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt >>>> >>>>Hi, >>>> >>>>The way this thread is going, I think we need to be careful: >>>> >>>>First, dry-martini is a proposal to aggregate flow over ANY >>>>media types, >>>>not for SONET/SDH only. I do aware of the ITU attempt to support >>>>GFP/MPLS/PW switching in the core. But our idea is much generic and >>>>flexible here. As far as I am concerned, we can aggregate a bunch of >>>>Ethernet or ATM flows over a WiMax connection using >>>>martini-encapsulation, and target LDP. :-) >>>> >>>>In terms of OAM, it has been a touchy issue for a long time. >>>>At the end >>>>of the day, we need to provide a combination of LSP-ping, VCCV, BFD, >>>>SONET PM, ATM OAM, Ethernet Mibs, AAA, billing... to the carriers, >>>>a.k.a. a clean OSS solution (or get HeavyReading to run >>>>another survey >>>>on the topic :-)). To avoid getting side-tracked, we intentionally >>>>avoided OAM discussion in the draft. If people like to work >>>>on it, let's >>>>talk off-line. >>>> >>>>All we are proposing here is to re-use draft-martini to >>>>transport data >>>>over packet/circuit networks! >>>> >>>>(By the way, I have no problem with GFP itself. I am just not >>>>sure why I >>>>need it for traffic aggregation at edge. In fact, I have the GFP-F, >>>>VCAT, LCAS, the whole nine-yard running in my lab. The only >>>>useful GFP >>>>application I can see so far is the function of sending EFFI >>>>as client >>>>frame to notification link outage when I pull a client port. >>>>Other than >>>>that, GFP is a simpler version of GRE to me, IMHO. :-) From packet >>>>encapsulation point of view, I can find a half dozen vendors that can >>>>support draft-martini on the MAC/Mapper/Framer chips today, but not a >>>>single one that would allow me to modify GFP extension headers. :-() >>>> >>>>2 cents, >>>> >>>>- Ping >>>> >>>> >>>>_______________________________________________ >>>>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: Sasha Vainshtein Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Fri, 2 Jul 2004 17:44:52 +0200 Lines: 36 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'pwe3@ietf.org '" X-From: pwe3-bounces@ietf.org Fri Jul 02 17:34:27 2004 Return-path: To: "'Eric Rosen '" , "'Yaakov Stein '" X-Mailer: Internet Mail Service (5.5.2653.19) 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 Eric,Yaakov and all, I agree that LDP is not a good method for distributing UDP ports as PW demultiplexers because LDP distributes labels and not UDP ports. I am also not sure that incorporation of LDP into existing low-end devices using UDP for demultiplexing of PWs is a good idea. A simpler method would probably suffice. My 2 c. Regards, Sasha -----Original Message----- From: Eric Rosen To: Yaakov Stein Cc: pwe3@ietf.org Sent: 7/1/2004 8:11 PM Subject: Re: [PWE3] ITU-T Q5/13 Liason re PW over UDP > Of course we need to remember that UDP port numbers > have fewer bits than MPLS labels, but there is no other > major difference. Are you suggesting that UDP port numbers should be encoded into LDP's label TLVs? Since a UDP port number and an MPLS label can have the same numeric value, that seems severely broken. _______________________________________________ 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: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 08:36:53 +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 X-From: pwe3-bounces@ietf.org Sun Jul 04 08:14:43 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRfltEhbxZZyhNVR1CoQGRnecr/4AB8Tpcg To: 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 > Are you suggesting that UDP port numbers should be encoded=20 > into LDP's label TLVs? Since a UDP port number and an MPLS=20 > label can have the same numeric value, that seems severely broken. I am not sure that we are talking about the same deployment scenario. The gateways that use UDP port numbers do not use MPLS-like inner labels. There are no MLPS labels with which to get confused. Of course there could be, in principle, a gateway that interfaces to both PWs using UDP port numbers and to PWs using MPLS labels (and to a further set of PWs using VLAN tags) in which case it will either have a label space per interface type, or will have to divide up a single label space. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 08:40:50 +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: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 08:17:44 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRfmsZKEDoJnaHfRqqsGnG3AUgXlQB7i2Ww To: "Busschbach, Peter B \(Peter\)" , 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 > I would turn your argument around. If, as you say, a label id=20 > is just a number, why not standardize on one specific format,=20 > i.e. MPLS labels. For the encapsulation function the label=20 > format may not have major implications, but for packet=20 > switches in the middle it does.=20 >=20 > Therefore, don't extend the label distribution protocol to=20 > support additional label formats, but standardize all packet=20 > switching applications on one single label format. Peter We already have more than one single label format, namely both MPLS labels and L2TP session IDs. This use of UDP port numbers predated both of these formats, and is very widely deployed. If we want to remove a format my vote is to leave UDP and remove the L2TP. Furthermore, the packet switch in the middle shouldn't care about inner labels of UDP port numbers. It should only care about the top of the MPLS stack, or the IP address. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 08:43:58 +0300 Lines: 12 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 Sun Jul 04 08:27:45 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRfoI13hm4/BYDsRludB0SzxyM1QwAWorZAAGOaH4A= To: , , 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 >From what I read in your email, you are simply re-iterating=20 your feelings about the advisability of PWs in general. I didn't see that you have any specific problem with the use of UDP port numbers. Do you believe that using UDP port numbers rather than, say, L2TP session IDs, is more of a architectural problem for carriers? Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 10:12:51 +0200 Lines: 62 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 10:02:17 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) 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, AFAIK the MPLS labelspace is already partitioned according to RFC 3031.Thispartictioning includes reserved labels, per-interface label space and global label space. The requirement to allocate the PWE3 label from the global label space is,IMHO, substantial for normal operarion of MPLS PWs. Inventing a new partitioning of the MPLS label space is, IMHO not a good idea, neither is it within the scope of the PWE3 Charter. If you want to use an "LDP-like" protocol to distribute UDP ports, you can do so, but this protocol MUST be ditinct from LDP, i.e. it cannot use LDP Label Mapping message "as is" to distribute UDP ports. IMHO it would be also better not to call it LDP to avoid mis-understanding... My 2 c. ---------------------------------------------------------------------------- -------- 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: Sunday, July 04, 2004 7:37 AM > To: erosen@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] ITU-T Q5/13 Liason re PW over UDP > > > > > Are you suggesting that UDP port numbers should be encoded > > into LDP's label TLVs? Since a UDP port number and an MPLS > > label can have the same numeric value, that seems severely broken. > > I am not sure that we are talking about the same deployment scenario. > > The gateways that use UDP port numbers do not use MPLS-like inner > labels. > There are no MLPS labels with which to get confused. > > Of course there could be, in principle, a gateway that interfaces > to both PWs using UDP port numbers and to PWs using MPLS labels > (and to a further set of PWs using VLAN tags) > in which case it will either have a label space per interface type, > or will have to divide up a single label space. > > 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: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 11:11:53 +0300 Lines: 41 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 10:45:21 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRhlsAp3EE0yGDIT6CtmUoc0wZyawABxOog To: "Sasha Vainshtein" 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 > AFAIK the MPLS labelspace is already partitioned according to=20 > RFC 3031.Thispartictioning includes reserved labels,=20 > per-interface label space and global label space. How is this relevant for PW labels? =20 > The requirement to allocate the PWE3 label from the global=20 > label space is,IMHO, substantial for normal operarion of MPLS PWs. Are you saying that the PW labels must be distinct from MPLS labels used above them? Not only don't I understand the reasoning for this requirement, it is also not in the spirit of MPLS. What you are saying is that all labels in the label stack must be allocated from the same label space. This would require a single label registry throughout the network, something we don't have or want. > Inventing a new partitioning of the MPLS label space is, IMHO=20 > not a good idea, neither is it within the scope of the PWE3 Charter. I never suggested a new partitioning of MPLS label space. In fact I said that in almost all cases there is no problem, and even if we have the unusual case of a gateway connected to various types of PWs, standard mechanisms could be used. =20 > If you want to use an "LDP-like" protocol to distribute UDP=20 > ports, you can do so, but this protocol MUST be ditinct from=20 > LDP, i.e. it cannot use LDP Label Mapping message "as is" > to distribute UDP ports. IMHO it would be also better not to=20 > call it LDP to avoid mis-understanding... It should be used "as-is". I agree it should not be called LDP, it should be called the PWE control (or signaling) protocol. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 11:52:59 +0200 Lines: 85 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 11:33:10 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) 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 answers inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Sunday, July 04, 2004 10:12 AM > To: Sasha Vainshtein > Cc: pwe3@ietf.org; erosen@cisco.com > Subject: RE: [PWE3] ITU-T Q5/13 Liason re PW over UDP > > > > > AFAIK the MPLS label space is already partitioned according to > > RFC 3031.Thispartictioning includes reserved labels, > > per-interface label space and global label space. > > How is this relevant for PW labels? > [Sasha] This is explained in the next para. > > > The requirement to allocate the PWE3 label from the global > > label space is,IMHO, substantial for normal operarion of MPLS PWs. > > Are you saying that the PW labels must be distinct > from MPLS labels used above them? > Not only don't I understand the reasoning for this requirement, > it is also not in the spirit of MPLS. > [Sasha] I suggest you read carefully Section 3.9 thru 3.15 of RFC 3031 which specifies if not exactly "the spirit of the MPLS" then, at leat, its architecture. When a PW packet arrives to the egress PW with several labels, these labels will be processed one by one according to the corresponding entries in the ILM of this PE. Presumably the entries corresponding to all the "transport" labels will require the label to be popped and the packet sent to the loopback i/f. The transport labels may be global or per i/f (at least the top one). The ILM entry corresponding to the PW label would point to the PW IFW (or something like that). Since the ILM entry for the PW label is different from the entries for the transport labels, *at this point* the PW label MUST be different from all the transport labels. > > What you are saying is that all labels in the label stack > must be allocated from the same label space. > This would require a single label registry throughout the network, > something we don't have or want. > [Sasha] I do not understand what in my message could be interpreted in such a way. Can you please elaborate? > > > Inventing a new partitioning of the MPLS label space is, IMHO > > not a good idea, neither is it within the scope of the PWE3 Charter. > > I never suggested a new partitioning of MPLS label space. > In fact I said that in almost all cases there is no problem, > and even if we have the unusual case of a gateway connected > to various types of PWs, standard mechanisms could be used. > > > > If you want to use an "LDP-like" protocol to distribute UDP > > ports, you can do so, but this protocol MUST be ditinct from > > LDP, i.e. it cannot use LDP Label Mapping message "as is" > > to distribute UDP ports. IMHO it would be also better not to > > call it LDP to avoid mis-understanding... > > It should be used "as-is". > I agree it should not be called LDP, > it should be called the PWE control (or signaling) protocol. > > Y(J)S > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 13:51:28 +0300 Lines: 43 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 13:27:53 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRhsAR9ySHC7yLPTVCf74C5o322jgAAyF+w To: "Sasha Vainshtein" 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, See below.=20 > When a PW packet arrives to the egress PW with several=20 > labels, these labels will be processed one by one according=20 > to the corresponding entries in the ILM of this PE.=20 > Presumably the entries corresponding to all the "transport"=20 > labels will require the label to be popped and the packet=20 > sent to the loopback i/f. The transport labels may be global=20 > or per i/f (at least the top one).=20 > The ILM entry corresponding to the PW label would point to=20 > the PW IFW (or something like that).=20 >=20 > Since the ILM entry for the PW label is different from the=20 > entries for the transport labels, *at this point* the PW=20 > label MUST be different from all the transport labels.=20 OK, now I understand what you mean, but even for this unusual case (i.e. a gateway that supports two different kinds of PW) this is not the only way it can work. When the edge router processes the last of the MPLS forwarding labels, it performs a PHP and sends the packet with only an inner label to the IWF. In this case the IWF needn't (shouldn't) know any of the transport labels, and the router needn't (shouldn't) know any of the interworking labels. Even if we assume that the IWF is inextricably coupled to the forwarding function (perhaps not disallowed by the PWE architecture document, but certainly not the ideal solution in many cases) and maintains a single label space for PW labels and MPLS forwarding labels,=20 this simply means that it must know to allocate labels of the appropriate size to the PWs that use UDP port numbers. This is what I meant by requiring a label range TLV for this case. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 14:39:14 +0200 Lines: 84 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 14:15:34 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) 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 below. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Sunday, July 04, 2004 12:51 PM > To: Sasha Vainshtein > Cc: erosen@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] ITU-T Q5/13 Liason re PW over UDP > > > Sasha, > > See below. > > > When a PW packet arrives to the egress PW with several > > labels, these labels will be processed one by one according > > to the corresponding entries in the ILM of this PE. > > Presumably the entries corresponding to all the "transport" > > labels will require the label to be popped and the packet > > sent to the loopback i/f. The transport labels may be global > > or per i/f (at least the top one). > > The ILM entry corresponding to the PW label would point to > > the PW IFW (or something like that). > > > > Since the ILM entry for the PW label is different from the > > entries for the transport labels, *at this point* the PW > > label MUST be different from all the transport labels. > > OK, now I understand what you mean, but even for this unusual case > (i.e. a gateway that supports two different kinds of PW) this > is not the only way it can work. > [Sasha] What is so unusual about it? Consider a hub-and-spokes application where the hub is a full-fledged LSR and, in addition, has to handle UDP-demultiplexed PWs coming from legacy low-end spokes. > > When the edge router processes the last of the MPLS forwarding labels, > it performs a PHP and sends the packet with only an inner label to the > IWF. > [Sasha] PHP is not a mandatory function, just an option. It is only applied if the "ultimate" LSR (i.e., the egress PE) has explicitly requested the penultimate LSR to perform it. Some routers I'm aware of never request PHP. So building on EVERY PE requesting PHP does not look right. > > In this case the IWF needn't (shouldn't) know any of the transport > labels, > and the router needn't (shouldn't) know any of the > interworking labels. > > Even if we assume that the IWF is inextricably coupled to the > forwarding function (perhaps not disallowed by the PWE architecture > document, but certainly not the ideal solution in many cases) > [Sasha] I do not understand which "forwadring function" you refer to. The demultiplexer (which presumably applies here) surely supports a data plane binding between IWF instances and incoming PW labels. > > and maintains a single label space for PW labels and MPLS forwarding > labels, > [Sasha] The IWF does not maintain a label space, IMO. The PE does. > > this simply means that it must know to allocate labels of the > appropriate size > to the PWs that use UDP port numbers. This is what I meant by > requiring > a label range TLV for this case. > [Sasha]AFAIK, the label range only applies to per-i/f labels for label-controlled cell (ATM) and frame (FR) interfaces. > > Y(J)S > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 13:15:50 +0100 Lines: 63 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 14:48:28 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRfmsZKEDoJnaHfRqqsGnG3AUgXlQB7i2WwAAzIjyA= To: , , X-OriginalArrivalTime: 04 Jul 2004 12:15:51.0264 (UTC) FILETIME=[A591FE00:01C461C0] 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, Please see below. > We already have more than one single label format, > namely both MPLS labels and L2TP session IDs. >=20 > This use of UDP port numbers predated both of these formats, > and is very widely deployed. NH=3D> By whom? Which carriers are using this, if you are at liberty to = disclose this of course. > If we want to remove a format > my vote is to leave UDP and remove the L2TP. NH=3D> Well, I would tend to agree with you but for completely different = reasons, ie I'd like to have all 3 network modes available (though I for = sure don't want lots of different technologies per mode in the = long-term) and I can see far smarter ways of using all 3 modes in = harmony (to solve the QoS (sic) issues) than trying to force 1 mode to = do everything (across the range of both public and private = services).....this will simply not be optimal. So I would like MPLS to = be both functionally complete and not violate the co-ps mode. However, = to get to this state we simply have to accept that MPLS is not IP, and = treat it accordingly. This is not a technical issue at all IMO, it is = simply one of political/religious barriers. regards, Neil >=20 > Furthermore, the packet switch in the middle shouldn't > care about inner labels of UDP port numbers. > It should only care about the top of the MPLS stack, > or the IP address. NH=3D> As I said in my previous mail, UDP is an application adaptation = function. It was never designed to be an inter-layer network adaptation = function. It does not carry all the functions required for inter-layer = network adaptation, eg alignment to arbitrary server layers. Further, = one can easily make the jump (at least in one's mind) from 'adaptation = function' to 'layer network'......and then we end up not only having to = augment what was previously just an adaptation function (to make it a = layer network) but we recurse the problem by now requiring further = application adaptation functions to this new layer network. You can see (and I have seen) folks mulling over the above points wrt = GFP and PWs. IMO we currently have anarchy in the industry as some folks are = proposing what I consider to be far from optimal solutions.....and I can = also see the interworking problem-space exploding. I have some ideas on = how to stop this madness, but it does require a bit of re-set on how = folks think about the 3 modes, and how we should be mapping public and = private services to these modes. I do not believe a 1 mode solution = (with loads of QoS classes per mode) is the right answer. And a (if not = 'the') critical problem to solve for operators is this: "(Given real = networks will run at low loads over the vast majority of their operating = life) how can we create consistently meaningful services (both public = and private), and where the 'service price' is decoupled from the BW = used, over a large range of load points". If we (as a collective body of engineers) cannot provide a network arch = that delivers against the above (and this assumes no modal violations = and functional completeness) then we are going to slowly bankrupt the = industry IMO. And currently I see us smack on course for doing this. regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 13:15:52 +0100 Lines: 77 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 14:48:57 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRfoI13hm4/BYDsRludB0SzxyM1QwAWorZAAGOaH4AACr8/gA== To: , , X-OriginalArrivalTime: 04 Jul 2004 12:15:52.0718 (UTC) FILETIME=[A66FDAE0:01C461C0] 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, > Neil,=20 >=20 > From what I read in your email, you are simply re-iterating=20 > your feelings about the advisability of PWs in general. NH=3D> Not really....the issues I have with PWs are actually nothing do = to with PWs per se, but stem from deeper and more fundamental = architectural aspects, viz: - one should respect the connectivity constraints of the 3 modes (else = it will cause operational problems)....and here I am specifically = referring to the co-ps mode and what is/is-not allowed. In the co-ps = mode you can break its connectivity rules of course (ie mp2p) due to the = nature of the link-connection ID in the traffic unit. In the co-cs mode = this is simply not possible (even if you try). And in the cl-ps mode = 'merging' is a non-issue since, by definition of the traffic unit of = this mode having a DA/SA pair, one can only ever have 'muxing'. A = corollary of this observation is that the native transport defects of = the 3 modes are all different....and hence require different OAM. - the functional completeness of the technology for the mode concerned. - respecting layer independence between the client and server layer = networks. - whether arbitrary combinations of client/server relationships are = sensible or not (there are 9 possible combinations between the 3 = modes)....noting that the adaptation function required is a function of = the nature (ie mode) of both the client and the server, ie just like = OAM, I do not think a '1 size fits all' adaptation solution is sensible = here. Example: Alignment adaptation (eg rate decoupling and traffic = unit delineation) is quite different if the server technology belongs to = the co-cs mode from the other modes. I could now go through specific examples of the above and explain why = breaking the connectivity rules of the mode and a lack of functional = completeness causes operational problems, but I think you understand = very clearly what I am driving at here. =20 IMO PWs are simply some form of client/server adaptation relationship = and nothing more. However, it is the underpinning = correctness/completeness of the network architecture that is my major = gripe here. >=20 > I didn't see that you have any specific problem with the use=20 > of UDP port > numbers. NH=3D> I thought I expressed a clear reason why I find proposing using = these strange. However, let me have a another quick go: We have adaptation functions between layer networks.....the nature of = this adaptation function varies depending on the modes of the client and = server layer concerned (as I tried to explain above a little). We also have adaptation functions between applications and the 1st layer = network they encounter. Now IMO UDP, and also TCP, are the primary = 'application to 1st layer network adaptation functions' for an IP layer = network (they could be used with other layer networks in theory of = course) to cater for the 3 major application traffic types, viz: = messages, files and streams. So, it seems very bizarre (to me anyway) to want to have a client layer = network running over UDP.....and I wonder what functional changes might = suddenly becomes required in UDP? Maybe others don't think this is = strange but I do. But hey, in world where some folks think SDHoverIP = makes sense then what do I know! >=20 > Do you believe that using UDP port numbers rather than, say, L2TP > session IDs, is more of a architectural problem for carriers? NH=3D> I think many things that are being done/proposed are going to = create problems for carriers, and I'd rather not keep adding to this = list ;-). All I am stating here is that I think it quite odd to run = some arbitrary client layer network over UDP. If some folks want this = then so be it, I just don't think its very sensible....esp for a = carrier. regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 15:37:15 +0300 Lines: 9 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 15:16:06 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRhu/md+ggx3D4QTA2/C32uoQAKMAAB31rg To: "Sasha Vainshtein" 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 > [Sasha]AFAIK, the label range only applies to per-i/f labels=20 > for label-controlled cell (ATM) and frame (FR) interfaces. Yes, that is what I have been saying all along! For the scheme to work we will have to add a label range option for this case. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 15:54:27 +0200 Lines: 31 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 04 15:33:43 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) 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, IMHO a scheme that requires so many changes to the MPLS and PWE3 architecture simply is not justified. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Sunday, July 04, 2004 2:37 PM > To: Sasha Vainshtein > Cc: erosen@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] ITU-T Q5/13 Liason re PW over UDP > > > > > [Sasha]AFAIK, the label range only applies to per-i/f labels > > for label-controlled cell (ATM) and frame (FR) interfaces. > > Yes, that is what I have been saying all along! > For the scheme to work we will have to add a label range option > for this case. > > Y(J)S > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Sun, 4 Jul 2004 17:07:13 +0300 Lines: 15 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 Sun Jul 04 16:41:46 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRhxn/NtCQvz8uYRo6THhb9a54tSAACX+eg To: "Sasha Vainshtein" 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 > Yaakov and all, > IMHO a scheme that requires so many changes to the MPLS and > PWE3 architecture simply is not justified. Sasha,=20 As I have been saying from the beginning,=20 the only thing we need to add is the label range command to the PWE signaling protocol initialization phase. This doesn't seem to be "so many changes" ... Y(J)S=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Shahram Davari Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Mon, 5 Jul 2004 12:24:47 -0700 Lines: 11 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Mon Jul 05 21:51:58 2004 Return-path: To: "'Sasha Vainshtein'" , "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2656.59) 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, >Since the ILM entry for the PW label is different from the >entries for the transport labels, *at this point* the PW label MUST >be different from all the transport labels. Correct. And that is easy to do. The downstream node is in full control of the label distribution. It can easily exclude the labels used for UDP from the Transport LSP labels. -Shahram From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: ITU-T Q5/13 Liason re PW over UDP Date: Tue, 06 Jul 2004 10:19:30 -0400 Lines: 36 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202BC3E33@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: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Jul 06 18:54:44 2004 Return-path: X-BrightmailFiltered: true To: "Yaakov Stein" In-reply-to: Your message of Sun, 04 Jul 2004 08:36:53 +0300. <27A0F290348F8E45AEF79889DDE65A5202BC3E33@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-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 gateways that use UDP port numbers do not use MPLS-like inner labels. > There are no MPLS labels with which to get confused. This is exactly the kind of assumption one must never make when doing protocol (or even program) design. ("Well, my protocol/program would have worked if only the users had used it in the way I intended! Bad, bad users!") > Of course there could be, in principle, a gateway that interfaces to both > PWs using UDP port numbers and to PWs using MPLS labels (and to a further > set of PWs using VLAN tags) in which case it will either have a label > space per interface type, I don't see what "interface types" have to do with anything. > or will have to divide up a single label space. This "dividing up" is bad enough on a single node, as (a) it gets into the guts of the label allocation/deallocation routines, and (b) you now need LDP's service interface to understand what kind of application is calling it, and what kind of label is needed by that application. But even worse, you'd need to do this dividing up on a network-wide basis (world-wide, to accommodate multi-provider PWs), so that when you receive a label binding you know which kind of "label" it is. So I believe your suggestion would be a very poor design. > If we want to remove a format my vote is to leave UDP and remove the > L2TP. Well, we can't "remove" UDP in this WG because we don't have it to begin with. Removing L2TP would require a charter change. I do not favor adding UDP to our charter because MPLS-in-IP is already available, but if we did add UDP we'd have to do proper signaling for it. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Wed, 7 Jul 2004 14:46:40 +0300 Lines: 21 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 Jul 07 15:54:42 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRjZDefM7gNRh+zQYylEwa9VTTykQAs03hg To: 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 > Well, we can't "remove" UDP in this WG because we don't=20 > have it to begin with. Removing L2TP would require a=20 > charter change. =20 Sorry, but UDP has been in there from the beginning. Quote from the charter : Tunnels for PWE3 encapsulations will use IP (both versions), L2TP, or MPLS. =20 Please note IP COMMA L2TP, and NOT IP WITH L2TP. The reason we didn't say UDP/IP is that someone may want TCP/IP (there is that option for RTP as well, although it is rarely used). Also please note that the original Anavi drafts from had ONLY UDP/IP (no MPLS or L2TP at all).=20 This was never considered out-of-scope for PWE3. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Wed, 7 Jul 2004 14:53:01 +0300 Lines: 56 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 Jul 07 15:55:12 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRjZDefM7gNRh+zQYylEwa9VTTykQAs9wjQ To: 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 > > The gateways that use UDP port numbers do not use MPLS-like inner labels. > > There are no MPLS labels with which to get confused.=20 >=20 > This is exactly the kind of assumption one must never =20 > make when doing protocol (or even program) design. ("Well,=20 > my protocol/program would have worked if only the users had used it in the way I=20 > intended! Bad, bad users!") Quite the opposite. Communications protocols should be designed for the scenarios where they will be used, and not over-designed for special cases that will never be important. (I have seen far too many over-designed protocols in the ITU which ended up never being implemented.) Our cousins in the AVT WG use UDP port numbers=20 as session demuxes all the time. Does anyone ever complain that they shouldn't because we want to simplify a =20 box that can handle both VoIP and VoMPLS sessions? > > Of course there could be, in principle, a gateway that interfaces to=20 > > both PWs using UDP port numbers and to PWs using MPLS labels (and to=20 > > a further set of PWs using VLAN tags) in which case it will either=20 > > have a label space per interface type, >=20 > I don't see what "interface types" have to do with anything. By "interface types" I meant UDP/IP vs. MPLS interfaces. If someone really wants to build a box that does both PWoIP and PWoMPLS, it would simply have to remember which interface feeds which. > > or will have to divide up a single label space.=20 >=20 > This "dividing up" is bad enough on a single node, as (a)=20 > it gets into the guts of the label allocation/deallocation=20 > routines, and (b) you now need LDP's service interface to=20 > understand what kind of application is calling it, and =20 > what kind of label is needed by that application. But even=20 > worse, you'd need to do this dividing up on a network-wide =20 > basis (world-wide, to accommodate multi-provider PWs), so=20 > that when you receive a label binding you know which kind=20 > of "label" it is.=20 >=20 > So I believe your suggestion would be a very poor design.=20 That suggestion was for completeness. I didn't like it either. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: ITU-T Q5/13 Liason re PW over UDP Date: Wed, 07 Jul 2004 10:36:10 -0400 Lines: 11 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202BC44BE@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: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Jul 07 18:49:50 2004 Return-path: X-BrightmailFiltered: true To: "Yaakov Stein" In-reply-to: Your message of Wed, 07 Jul 2004 14:46:40 +0300. <27A0F290348F8E45AEF79889DDE65A5202BC44BE@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-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 Eric> Well, we can't "remove" UDP in this WG because we don't Eric> have it to begin with. > Sorry, but UDP has been in there from the beginning. I didn't mean to suggest that use of UDP is necessarily out of the charter, just that the WG hasn't done the work for it. Since the WG hasn't done the work for it, so there is nothing to remove. However, your interpretation of the charter as REQUIRING an IP-based solution other than L2TP strikes me as very far-fetched. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: ITU-T Q5/13 Liason re PW over UDP Date: Wed, 07 Jul 2004 10:45:21 -0400 Lines: 25 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202BC44C4@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: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Jul 07 19:40:43 2004 Return-path: X-BrightmailFiltered: true To: "Yaakov Stein" In-reply-to: Your message of Wed, 07 Jul 2004 14:53:01 +0300. <27A0F290348F8E45AEF79889DDE65A5202BC44C4@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-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 > Communications protocols should be designed > for the scenarios where they will be used, and not over-designed > for special cases that will never be important. I assume you mean they should be designed for the scenarios where you plan to use them, and not "over designed" to work in scenarios that you don't happen to be planning to support. I don't think so. > Our cousins in the AVT WG use UDP port numbers as session demuxes all the > time. I hope you're not going to tell me that they use LDP to signal the port numbers! (If they don't, then this point is of course irrelevant.) > If someone really wants to build a box that does both > PWoIP and PWoMPLS, If both methodologies get deployed, this is inevitable. > it would simply have to remember which interface feeds which. Any interface could feed both. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Tim.Frost@Zarlink.Com Subject: signaling packets in CESoPSN Date: Fri, 9 Jul 2004 16:03:27 +0100 Lines: 54 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: pwe3-bounces@ietf.org Fri Jul 09 17:56:38 2004 Return-path: To: pwe3@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Zarlink(Release 6.5.1|January 21, 2004) at 07/09/2004 11:03:27 AM, Serialize complete at 07/09/2004 11:03:27 AM X-Scanned-By: MIMEDefang 2.38 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 Recently the CESoPSN draft attracted some criticism on its last call over the use of application signaling (e.g. telephony CAS) in separately sequenced packets within the same PW (which incidentally has been part of this particular draft since February 2002). I'd like to canvas opinions on the best way forward here. There are (at least) three potential ways of handling the issue: 1. Separate sequenced signaling stream in the same PW (as in the current draft) 2. Use a separate PW for the signaling channel 3. Use VCCV to create a channel to send the signaling packets down I've outlined some of the pros and cons of each as I see it below. I'd welcome opinions on this, to try and build a satisfactory way forward and enable us to get the draft through last call. 1. Separate sequenced signaling stream in the same PW (as in the current draft) ----------------------------------------------------- For: - simplest to setup, needs no additional PW setup or label distribution Against - multiple sequenced streams in the same pseudo-wire (but note this is no different from VCCV, which may also contain an additional sequenced stream) - two stage control word processing - examine L, M bits, then process sequence no. (but we are already forced into a two stage process to check for VCCV packets) - does this constitute a separate layer? 2. Use a separate PW for the signaling channel ---------------------------------------------- For: - solves the issue of separate sequences in the same PW Against: - more complex, requires extra label distribution - both PWs need to share the same fate - what happens if one is successfully set up, but the other fails? - how can we ensure both PWs are setup and torn down together? 3. Use VCCV to create a channel to send the signaling packets down ------------------------------------------------------------------ For: - signaling still shares the same PW, so setup issues are minimised Against: - still have multiple sequenced flows in the same PW - signaling packets have much more complex format, and hence harder to both generate and parse From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Bill_Maguire@3com.com Subject: IOS software for PWE Date: Fri, 9 Jul 2004 14:54:10 -0400 Lines: 44 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1629136740==" X-From: pwe3-bounces@ietf.org Fri Jul 09 22:53:47 2004 Return-path: To: pwe3@ietf.org X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 07/09/2004 11:54:14 AM, Serialize complete at 07/09/2004 11:54:14 AM 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 multipart message in MIME format. --===============1629136740== Content-Type: multipart/alternative; boundary="=_alternative 0067BF3D85256ECC_=" This is a multipart message in MIME format. --=_alternative 0067BF3D85256ECC_= Content-Type: text/plain; charset="US-ASCII" Hello, Does anyone know which IOS version I need to run AToM on a Cisco 3640-A acting as a PE router? Thanks, Bill --=_alternative 0067BF3D85256ECC_= Content-Type: text/html; charset="US-ASCII"
Hello,

Does anyone know which IOS version I need to run AToM on a Cisco 3640-A acting as a PE router?

Thanks,
Bill --=_alternative 0067BF3D85256ECC_=-- --===============1629136740== 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 --===============1629136740==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-control-protocol-08.txt Date: Fri, 09 Jul 2004 15:35:47 -0400 Lines: 102 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 Sat Jul 10 02:24:53 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 : Pseudowire Setup and Maintenance using LDP Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-control-protocol-08.txt Pages : 39 Date : 2004-7-9 Layer 2 services (such as Frame Relay, ATM, ethernet) can be 'emulated' over an IP and/or MPLS backbone by encapsulating the layer 2 PDUs and then transmitting them over 'pseudowires'. It is also possible to use pseudowires to provide SONET circuit emulation over an IP and/or MPLS network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to LDP. Procedures for encapsulating layer 2 PDUs are specified in a set of companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-08.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-control-protocol-08.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-control-protocol-08.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: Rik Wade Subject: Re: IOS software for PWE Date: Sat, 10 Jul 2004 09:13:44 +0100 Lines: 14 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 Sat Jul 10 10:25:32 2004 Return-path: To: "bill_maguire@3com.com" In-Reply-To: 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 >----- Original Message ----- >From: bill_maguire@3com.com >Date: Fri, 9 Jul 2004 14:54:10 -0400 >Subject: [PWE3] IOS software for PWE >To: pwe3@ietf.org > >Does anyone know which IOS version I >need to run AToM on a Cisco 3640-A acting as a PE router? Looking on the IOS Feature Navigator on CCO, there appear to be no AToM-capable IOS releases for anything smaller than a 3750-Metro or a 7200. -- rik From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Bill_Maguire@3com.com Subject: Re: IOS software for PWE Date: Sat, 10 Jul 2004 10:44:05 -0400 Lines: 41 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sat Jul 10 16:50:34 2004 Return-path: In-Reply-To: To: Rik Wade X-Mailer: Lotus Notes Release 6.0 September 26, 2002 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 07/10/2004 07:44:07 AM 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 Rik, I came to the same conclusion, but I have been running 12.2.(15)T10 utilizing MPLS/BGP VPNs. Cisco does not want to support MPLS in the 3640, going forward, but that does not mean one cannot find and old version of software for it. The problem is finding... Rik Wade on 07/10/2004 04:13:44 AM Sent by: Rik Wade From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Richard Sugarman Subject: : Restarting sequence numbers in draft-ietf-pwe3-control-pr otocol Date: Mon, 12 Jul 2004 11:40:47 +0100 Lines: 186 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: 'Luca Martini' X-From: pwe3-bounces@ietf.org Mon Jul 12 12:54:46 2004 Return-path: To: "'pwe3@ietf.org'" Deferred-Delivery: Mon, 12 Jul 2004 11:41:00 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) 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'd like to suggest a minor amendment to section 5.6.2 Label Mapping Release. (This follows up an old conversation previously titled "Section 5.6.2 of pwe3-control-protocol-07 not required?"). This amendment - makes the sending of LDP Label Request and Label Release messages optional if there is an alternative way to restart the sequence number - makes it clear that receipt and correct handling of these messages is mandatory. The aim is to allow implementations to not send LDP Label Requests in DU/Liberal mode if they wish to support an alternative method of restarting sequence numbers. Some existing implementations do not seem to handle LDP Label Requests gracefully, and so for the sake of interoperability an alternative method should be allowed. Changed lines are marked >> below. Thanks, Rich ------------------ New section 5.6.2: In situations where the imposition router wants to restart forwarding >> of packets with sequence number 1, the router MAY 1) Send to disposition router a label mapping release, and 2) Send to disposition router a label mapping request. >> If an alternative method of re-setting the sequence number to 1 is >> supported, the sending of a label mapping release and label mapping >> request is OPTIONAL. However, handling receipt these messages as >> specified in [1] is always MANDATORY. When sequencing is supported, advertisement of a PW label in response to a label mapping request MUST also consider the issues discussed in the section on Label Mapping Advertisements. Old section 5.6.2: In situations where the imposition router wants to restart forwarding of packets with sequence number 1, the router shall 1) Send to disposition router a label mapping release, and 2) Send to disposition router a label mapping request. When sequencing is supported, advertisement of a PW label in response to a label mapping request MUST also consider the issues discussed in the section on Label Mapping Advertisements. -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of Luca Martini Sent: 15 June 2004 18:58 To: Richard Sugarman Cc: 'pwe3@ietf.org' Subject: Re: [PWE3] Section 5.6.2 of pwe3-control-protocol-07 not required? Richard Sugarman wrote: >I have some concerns about section 5.6.2 of >draft-ietf-pwe3-control-protocol-07. I suspect that this section of the >draft has not been widely implemented, but am open to being proved wrong. > >It describes the situation where a router wishes restart forwarding of >packets with sequence number 1. It suggests > > - sending an LDP Label Release for the PW in question > - sending a corresponding LDP Label Request. > >This seems non-ideal for a couple of reasons. > >1) For plain LDP signalling in DU/Liberal mode, most (all?) existing >implementations do not send Label Requests at all. This has lead to an >undesirable situation where > > - some implementations do not respond to Label Requests > > that violates rfc3036 , those implementations need to be fixed. > - some implementations just do not cope with receipt of a Label Request (in >a service impacting way). > > > again that is not behavior that agrees with rfc3036. >Whilst broken implementations should of course be fixed, this situation does >suggest that sending Label Requests can lead to severe interop problems that >will not go away in a hurry. I suspect that these problems will exist for >PW LSPs as much as for normal LDP LSPs. > >2) In the absence of Label Request support, sending a Label Release in >Liberal mode should be avoided as far as possible. The downstream node that >receives the Label Release will never retry sending the Label Mapping >without operator intervention. Without a Label Request, the LSP will stay >broken. > > > correct. >[The other places in pwe3-control-protocol that specify sending Label >Release messages, sections 5.2.3 and 5.4.1, do so for specific reasons >reflected in the Label Release status code - these are unexpected >misconfigurations that I believe will _always_ require operator intervention >to resolve]. > >3) At the Seoul IETF meeting, Luca Martini described an alternative way to >re-set the sequence number that does not involve LDP signalling at all, but >instead utilizes standard sequence number algorithms (see >http://www.ietf.org/proceedings/04mar/index.html, section 2.8.10, under >"Luca - PWE3 sequencing"). This seems like a better way to go forward. > > > I agree , it works much better, but we cannot prevent the label release/request method as it is part of the rfc3036 already. >So unless anyone knows of an implementation of section 5.6.2 of >pwe3-control-protocol-07, I would suggest either removing the section >entirely, or instead changing it to comment that re-setting the sequence >number is outside of the scope of the signalling protocol. > > > Actually as far as I can remember most of the implementations of the draft-martini version did answer the label request messages. Since we are almost ready to LC this draft ( I am missing the security section which will be posted shortly ) I think that we cannot introduce the methodology that I presented at the last PWE3 meeting. But I still have an item on my list of to do things to write a draft about that CW synchronization methodology. I do not think that removing this section will make things easier, as the LDP specification still requires that label request response be implemented. So we can still have implementations attempting to use this methodology. What is the issue here ? Do you not want to implement answering label request messages ? Luca >Thoughts welcome! > >Rich > >Richard Sugarman >Network Protocols Group >Data Connection Ltd (DCL) >Tel: +44 20 8366 1177 >Fax: +44 20 8363 1039 >Email: mailto:richard.sugarman@dataconnection.com >Web: http://www.dataconnection.com > > > > > > >_______________________________________________ >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: Nick Weeds Subject: Parameter ID in PW Grouping TLV Date: Mon, 12 Jul 2004 14:48:57 +0100 Lines: 30 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "pwe3@ietf.org \(E-mail\)" X-From: pwe3-bounces@ietf.org Mon Jul 12 16:35:17 2004 Return-path: To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2653.19) 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 see that the new PW Grouping TLV contains both an LDP TLV header and a parameter ID+length header. The LDP TLV header alone is sufficient to identify the TLV contents, so it's unclear why the parameter ID+length header is also present. Is this a deliberate choice, perhaps for historical reasons or for similarity with the Interface Parameters TLV? Or could this perhaps be an artefact left from merging previous suggestions, better addressed by removing the parameter ID and parameter length from the PW Grouping TLV? If the parameter ID is kept, is the intention that the PW Grouping TLV could be extended to contain other parameters in future? Also, has a parameter ID value been assigned? Thanks, Nick. > Nick Weeds > Software Developer > Network Protocols Group > Data Connection Ltd > Tel: +44 1244 305200 > Fax: +44 1244 312422 > Email: Nick.Weeds@dataconnection.com > Web: http://www.dataconnection.com From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] Date: Mon, 12 Jul 2004 19:23:01 +0100 Lines: 170 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------090903050401080008060902" X-From: pwe3-bounces@ietf.org Mon Jul 12 20:56:05 2004 Return-path: X-BrightmailFiltered: true 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-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. --------------090903050401080008060902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This draft replaces the control word text removed from the architecture draft. The matching MPLS draft is http://www.ietf.org/internet-drafts/draft-swallow-mpls-ecmp-bcp-00.txt which was submitted over the weekend, but which has not yet got to the server. - Stewart -------- Original Message -------- Subject: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt Date: Fri, 09 Jul 2004 15:28:31 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PWE3 Control Word Author(s) : S. Bryant, D. McPherson Filename : draft-bryant-mcpherson-pwe3-cw-00.txt Pages : 7 Date : 2004-7-9 This document describes the preferred designs of the PWE3 Control Word, and the PWE3 Payload Type Identifier. The design of these fields is chosen so that an MPLS LSR performing deep packet inspection will not confuse a PWE3 payload with an IP payload. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-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-bryant-mcpherson-pwe3-cw-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-bryant-mcpherson-pwe3-cw-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. ------------------------------------------------------------------------- In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. ------------------------------------------------------------------------- For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: i69MjiSc015971 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc --------------090903050401080008060902 Content-Type: text/plain; name="file:///D|/DOCUME%7E1/STBRYANT/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///D|/DOCUME%7E1/STBRYANT/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------090903050401080008060902 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 --------------090903050401080008060902-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] Date: Tue, 13 Jul 2004 09:40:30 +0300 Lines: 46 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 Jul 13 08:54:39 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] Thread-Index: AcRoQePYFVltvwnMS5CZChd7AUgV5gAX70pg To: "Stewart Bryant" , 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 Stewart,=20 I am sure we are all glad that both of these drafts were written, and the issue of avoiding problems with ECMP mechanisms that peek at the MPLS payload is out in the open. However, the PWE3 draft seems to leave one issue open. The use of the control word is optional and negotiated. If it is not used with a MPLS PSN, what are we to do? If neither CW or PTI is used, then we have potential problems with ECMP mechanisms. But the draft says: A PW SHOULD employ either the generic PW Control Word described in=20 Section 3, or the PWE3 Payload Type Identifier (PWE3-PTI) described=20 in Section 4. These fields MUST immediately follow the bottom of the=20 MPLS label stack.=20 In other words, we only SHOULD use one of the other, but MUST put them in the right place. Later, when discussing the PTI the draft says: If technical considerations result in a PW Control Word that could=20 be mistaken for an IP packet, the Control Word SHOULD be preceded by=20 a PWE3 Payload Type Identifier (PWE3-PTI).=20 This implies that PTIs are only used BEFORE nonstandard CWs (e.g. CEP headers), but not for packets with no CW at all. So, are we saying that we from now on, all PWs over MPLS MUST use CWs or risk being mistreated by ECMP mechanisms? BTW - I have another question relating to the statement in the draft : The use of any other first nibble value for a PWE3 packet is deprecated.=20 Does the disapproval of values not equal to 0, 1, 4, or 6 result from some further mechanism of which we are unaware? Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] - OAM considerations Date: Tue, 13 Jul 2004 11:48:43 +0100 Lines: 48 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 Tue Jul 13 13:01:41 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] Thread-Index: AcRoQhZZ9bKOUOhdRzeTWDn9ohkY0QAfaZ6w To: , X-OriginalArrivalTime: 13 Jul 2004 10:48:44.0083 (UTC) FILETIME=[F7A53830:01C468C6] 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, I note Yaakov has already posted remarks on this draft regarding = ambiguity in the use/ordering of the CW and/or PID (which I agree with). = However, I see a further problem. If I am reading the draft correctly = it seems there are potentially many options: - CW only; - PID only; - PID and CW (must appear in this order); - ...and when the CW is used the various fields therein are optional or = vary, eg Seq Nos are optional, flags vary on client; - the above only applies to PW LSPs, IP LSPs have none of this, ie this = is essentially the case of 'no CW and no PID'; - ....and the above can be with/without OAM. So the further problem I see is when we have misconnectivity defects = between LSPs that are not identically specified wrt above (which of = course is currently a given anyway for the case of mixed PW LSPs and IP = LSPs even if all the PW LSPs are identically coded). Perhaps a good generic solution would have been to make the PID = mandatory on all LSPs (any client case, including IP). This appears to = give: - give a consistent solution (for the ECMP hack) in all cases - and allows correct identification of payload as OAM or traffic The CW is always going to be a problem IMO......both from the fact that = it is optional per se, and that even when present some of the fields = therein are optional or variable dependent on the client. I don't see = any easy way out of this now.....though I suspect you know my view on = why this all such a problem now, ie MPLS is not IP, and for forms of = MPLS that do not violate the connectivity constraints of the co-ps mode = one does not need the CW IMO, nor does one need it if the server layer = technology belongs to the co-cs mode, ie Ping's recent proposals for = such. Furthermore, I also believe that client layer transparency should = always be the default behaviour, ie any minute savings from client BW = squeezing is not a major issue, complexity however is. Could the best compromise be to make PID+CW the mandatory = case?.....where the PID still identifies the payload as traffic or OAM, = but we now know that there is always a CW interposed here (and for folks = who think it of little value they can just effectively set it to = 'null'). The other alternative is to code the PID for every possible CW = case.....though this would only seem important if varying CW structures = could exist in the same MPLS network. regards, Neil =20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt ] - OAM considerations Date: Tue, 13 Jul 2004 14:35:52 +0200 Lines: 62 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: pwe3@ietf.org, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Tue Jul 13 13:54:18 2004 Return-path: To: "'neil.2.harrison@bt.com'" X-Mailer: Internet Mail Service (5.5.2653.19) 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 and all, Please see a brief comment inline. (I have taken the liberty to snip the parts of your response that are not related to this specific comment.) Hopefully it would be helpful. 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, July 13, 2004 12:49 PM > To: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] [Fwd: I-D > ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] - OAM considerations > > > Hi Stewart, > ... nipped .. >for forms of MPLS that do not violate the connectivity constraints > of the co-ps mode one does not need the CW IMO, nor does > one need it if the server layer technology belongs to the co-cs mode, ie > Ping's recent proposals for such. > [Sasha] Here is one example where server being co-ps does NOT eliminate the need for sequence numbers. It is (unsurprisingly) the case of TDM clients, where the need to detect (and compensate for) LOST packets requires sequence numbers. I think that you recognize ATM as a compliant co-ps server layer (even if cells are not exactly packets), but AAL1 and ATM-CES use sequence numbers (even if limited to 3 bits only). (I assume that your definition of co-ps includes zero packet loss:-) > >Furthermore, I also > believe that client layer transparency should always be the > default behaviour, ie any minute savings from client BW > squeezing is not a major issue, complexity however is. > > Could the best compromise be to make PID+CW the mandatory > case?.....where the PID still identifies the payload as > traffic or OAM, but we now know that there is always a CW > interposed here (and for folks who think it of little value > they can just effectively set it to 'null'). The other > alternative is to code the PID for every possible CW > case.....though this would only seem important if varying CW > structures could exist in the same MPLS network. > > regards, Neil > > > _______________________________________________ > 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: Sasha Vainshtein Subject: RE: signaling packets in CESoPSN Date: Tue, 13 Jul 2004 15:53:05 +0200 Lines: 105 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'Tim.Frost@Zarlink.Com'" X-From: pwe3-bounces@ietf.org Tue Jul 13 15:09:54 2004 Return-path: To: pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) 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, I want to join Tim in soliciting opinion on the issue of signaling packets in CESoPSN especially wrt interpretation of section 5.1.2 of the Architecture draft dealing with PWE3 Channel types. Just to remind you, the proposal described in the draft seems to me aligned with Type 2 channel defined in this section, while option 3 mentioned by Tim re-uses the VCCV mechanism to implement such a channel in a generic way. My interpretation of the Architecture draft has been disputed by some of the WG participants during the Last Call. Authoritative opinion of the Editors of the Architecture draft (now actually an RFC) on this issue would be, IMO, most helpful. But all opinion is, of course, welcome. 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: Tim.Frost@Zarlink.Com [mailto:Tim.Frost@Zarlink.Com] > Sent: Friday, July 09, 2004 5:03 PM > To: pwe3@ietf.org > Subject: [PWE3] signaling packets in CESoPSN > > > Recently the CESoPSN draft attracted some criticism on its > last call over > the use of application signaling (e.g. telephony CAS) in separately > sequenced packets within the same PW (which incidentally has > been part of > this particular draft since February 2002). > > I'd like to canvas opinions on the best way forward here. > There are (at > least) three potential ways of handling the issue: > 1. Separate sequenced signaling stream in the same PW (as in > the current > draft) > 2. Use a separate PW for the signaling channel > 3. Use VCCV to create a channel to send the signaling packets down > > I've outlined some of the pros and cons of each as I see it > below. I'd > welcome opinions on this, to try and build a satisfactory way > forward and > enable us to get the draft through last call. > > 1. Separate sequenced signaling stream in the same PW (as in > the current > draft) > ----------------------------------------------------- > For: > - simplest to setup, needs no additional PW setup or label > distribution > > Against > - multiple sequenced streams in the same pseudo-wire > (but note this is no different from VCCV, which may also contain an > additional sequenced stream) > - two stage control word processing - examine L, M bits, then process > sequence no. > (but we are already forced into a two stage process to > check for VCCV > packets) > - does this constitute a separate layer? > > > 2. Use a separate PW for the signaling channel > ---------------------------------------------- > For: > - solves the issue of separate sequences in the same PW > > Against: > - more complex, requires extra label distribution > - both PWs need to share the same fate > - what happens if one is successfully set up, but the other fails? > - how can we ensure both PWs are setup and torn down together? > > > 3. Use VCCV to create a channel to send the signaling packets down > ------------------------------------------------------------------ > For: > - signaling still shares the same PW, so setup issues are minimised > > Against: > - still have multiple sequenced flows in the same PW > - signaling packets have much more complex format, and hence > harder to > both generate and parse > > > _______________________________________________ > 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: Sasha Vainshtein Subject: Issues raised during the WG Last Call on draft-ietf-pwe3-cesopsn- 00.txt Date: Tue, 13 Jul 2004 16:55:11 +0200 Lines: 68 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-From: pwe3-bounces@ietf.org Tue Jul 13 16:26:10 2004 Return-path: To: "PWE3 WG (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) 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, I'd like to present a brief summary of issues raised during the WG Last Call on draft-ietf-pwe3-cesopsn-00.txt, indicating the issue and proposed resolution or status (where possible). Feedback on the proposals is welcome. 1. Issue: Default packet latencies (in ms) should be power of 2 - Reasoning: Simplifies HW implementations - Proposed resolution: use the following set of defaults for NxDS0 o N=1 ==> 8 ms o N=2,3,4 ==> 4 ms o N>=5 ==> 1 ms 2. Issue: Two methods for carrying CAS (signaling packets and superframes with appended signaling sub-structure) - Reasoning: No need in two methods implementing same functionality - Proposed resolution: Leave only the method based on signaling packets o This was the original proposal o The superframe with the signaling sub-structure has been added for interworking with ATM-CES, this is now taken care of in the TDMoIP draft o No interest found among the CESoPSN implementers 3. Issue: The sequencing method used in CESoPSN differs from the method used in Layer 2 encapsulations (the sequence number does not skip 0) - Reasoning: obvious - Proposed resolution: no changes o Common for all the TDM-related drafts (CEP, SAToP, CESoPSN, TDMoIP) o Aligned with RFC 3550 and ITU-T Recommendation Y.1413 4. Issue: Downstream trunk conditioning (defined in Bellcore TR NWT 170) MUST be applied by the ingress PE upon detecting AIS or RDI condition of the local AC. Bi-directional (both downstream and upstream) trunk conditioning must be applied by the egress PE if it enters the Packet Loss state. - Reasoning: This is the defined behavior of ATM-CES - Proposed resolution: place this functionality in the NSP of the egress PE: o Only downstream trunk conditioning in the egress PE is required (the necessary indications are always carried across the PW in teh CESoPSN CW - something ATM-CES does not provide for!) o Within the PE, relegate this functionality (which is "native TDM") to the appropriate NSP o Make the actual handling of the conditions described above locally configurable. - Detailed explanation will be presented in a separate email message and updated CESoPSN draft 5. Issue: Data and signaling packets form two independent sequenced sub-flows within the same PW - Tim has initiated a separate thead on this list to discuss this issue 6. Issue: Propagation of RDI and AIS from client to server layer contradicts basic architecture of layered networks - Explanation will be presented in a separate email. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] - OAM considerations Date: Tue, 13 Jul 2004 15:00:35 +0100 Lines: 94 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Tue Jul 13 16:38:58 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] - OAM considerations Thread-Index: AcRoziw7tRX6sYsaRVWLdOo6R/D5/QAApXxw To: X-OriginalArrivalTime: 13 Jul 2004 14:00:36.0354 (UTC) FILETIME=[C57E5E20:01C468E1] 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 Sasha, Please see below. regards, Neil > ... nipped .. > >for forms of MPLS that do not violate the connectivity constraints=20 > > of the co-ps mode one does not need the CW IMO, nor does=20 > > one need it if the server layer technology belongs to the=20 > co-cs mode, ie=20 > > Ping's recent proposals for such. =20 > > > [Sasha] Here is one example where server being co-ps does NOT=20 > eliminate > the need for sequence numbers. It is (unsurprisingly) the case of > TDM clients, where the need to detect (and compensate for) > LOST packets requires sequence numbers. I think that you=20 > recognize ATM as a compliant co-ps server layer (even if cells > are not exactly packets), but AAL1 and ATM-CES use sequence > numbers (even if limited to 3 bits only). > (I assume that your definition of co-ps includes zero packet loss:-) NH=3D> This does not address the problem I raised.....but since you = brought this up..... The key question here is this: Given the traffic from all applications = will be either message, file or stream in nature then just how many = technologies and QoS/traffic classes does one need to support this? = Answer is a heck of lot less than some folks think. However, every time = a new technology arrives its advocates try and solve everything in that = technology/mode. This gives us many problems....stovepipes and the = downstream i/w issues created are examples of these. We don't need = loads of technologies per mode......but we do need the 3 modes as they = do different jobs. I can postulate a rather simple target network arch where the cl-ps and = co-ps modes work in harness, we have sensible client/server = relationships of each of these (service-level) modes to the lower = (transport/aggregate) co-cs mode, and where one simply does not need = lots of QoS/traffic classes in each (service-level) mode to address the = full public/private service vista most optimally. {Aside - real = networks run lightly loaded (many reasons), and the real challenge is to = do with creating consistently meaningful services over all load points, = where service_price and BW_used are independent parameters. Having lots = of QoS/traffic classes is a BW squeezing optimisation that is not worth = it....we should use BW wisely to remove complexity. But the trick is = seeing how to use the different modes in harness to do this.} However, = I'll leave that one here as I think this vision could be considered = counter-culture......though it is important to be aware of this to = understand *why* we keep causing a mess with the '1 technology/mode can = do it all' view. ATM was a classic example of falling for this 1-mode-can-do-it-all = flawed thinking. ATM has several AALs for different clients, 5 of them = at one stage......this is far too many QoS/traffic classes IMO, and = harks back to (i) the notion that BW is scarce resource that must be = conserved at all costs and (ii) some folks think they can get something = for nothing. AAL5 does not have Seq Nos as it was designed for message = and file traffic.....AAL1 does have Seq Nos however as it was designed = for stream traffic. So the issue you raise has nothing to do with ATM = per say as the common networking co-ps layer technology (ie cell level), = the issue is all to do with the adaptation function, and specifically = here AAL1. So, given you need Seq No.s for the TDM client case and you quote the = AAL1 example, then why don't you just use AAL1 and be done with = it?.......there is no need to make the network always carry this = function for every other client case. Indeed, I understand most folks = don't even use the Seq Nos. {Further aside - IP has 2 major application adaptation functions UDP and = TCP for the message and file traffic respectively....UDP does not = natively carry sequence numbers, but one can add RTP to UDP for the real = time stream case if one thinks that is a good solution. I also think we have to distinguish 'application->1st layer network = adaptation' (ie the message/file/stream issues) from 'client/server = adaptation' between different layer networks. One size does not fit all = here in the latter case. 2 key adaptation functions are muxing and = alignment. However, the precise nature of the adaptation function = required is dependent on the client and server modes concerned. For = example, if we adapt a co-ps or cl-ps client into a co-cs server we have = an alignment function that must cater for rate-decoupling (ie idle-fill) = and client traffic unit delination....GFP say could do this job, and = indeed will do for (say) ethernet over SDH. These adaptation function = alignment requirements don't exist for other client/server mode = pairs......and instead we might have a padding requirement or (less = nice) a fragmentation requirement (ie client traffic unit > server = traffic unit payload). A special muxing function is never needed with a = cl-ps client to any mode as the server......the cl-ps mode inherently = does muxing (never merging) because each/every traffic unit carries a = network-wide DA/SA semantic. Not true for the co-ps and co-cs modes = when we have >1 client into a single server as link-connection IDs are = not network-wide unique, and need to be controlled/configured when a = parent trail entity is brought into being.} regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Ron Cohen" Subject: RE: signaling packets in CESoPSN Date: Tue, 13 Jul 2004 10:05:27 -0700 Lines: 92 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 Tue Jul 13 19:30:08 2004 Return-path: To: , 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.1409 Importance: Normal In-Reply-To: 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 Tim, all, I would rather have a separate signaling channel (~option 2). I would go a step further and say that the signaling channel MAY be sent on a separate PW channel but can also be sent in another form (i.e. using IP packets when the PW run directly over MPLS). There is no need to have a separate signaling channel for each PW but rather the signaling information between two PEs may use a single signaling channel to transport information for multiple PWs running between the PEs. In addition, I believe that TDM emulation in general does not require/need VCCV. Connectivity and alarms propagation are built-in into the control word and the nature of the service (continuous packet stream). Regards Ron > > Recently the CESoPSN draft attracted some criticism on its > last call over > the use of application signaling (e.g. telephony CAS) in separately > sequenced packets within the same PW (which incidentally has > been part of > this particular draft since February 2002). > > I'd like to canvas opinions on the best way forward here. > There are (at > least) three potential ways of handling the issue: > 1. Separate sequenced signaling stream in the same PW (as in > the current > draft) > 2. Use a separate PW for the signaling channel > 3. Use VCCV to create a channel to send the signaling packets down > > I've outlined some of the pros and cons of each as I see it > below. I'd > welcome opinions on this, to try and build a satisfactory way > forward and > enable us to get the draft through last call. > > 1. Separate sequenced signaling stream in the same PW (as in > the current > draft) > ----------------------------------------------------- > For: > - simplest to setup, needs no additional PW setup or label > distribution > > Against > - multiple sequenced streams in the same pseudo-wire > (but note this is no different from VCCV, which may also contain an > additional sequenced stream) > - two stage control word processing - examine L, M bits, then process > sequence no. > (but we are already forced into a two stage process to > check for VCCV > packets) > - does this constitute a separate layer? > > > 2. Use a separate PW for the signaling channel > ---------------------------------------------- > For: > - solves the issue of separate sequences in the same PW > > Against: > - more complex, requires extra label distribution > - both PWs need to share the same fate > - what happens if one is successfully set up, but the other fails? > - how can we ensure both PWs are setup and torn down together? > > > 3. Use VCCV to create a channel to send the signaling packets down > ------------------------------------------------------------------ > For: > - signaling still shares the same PW, so setup issues are minimised > > Against: > - still have multiple sequenced flows in the same PW > - signaling packets have much more complex format, and hence > harder to > both generate and parse > > > _______________________________________________ > 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: signaling packets in CESoPSN Date: Tue, 13 Jul 2004 23:06:26 +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 X-From: pwe3-bounces@ietf.org Wed Jul 14 05:49:38 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] signaling packets in CESoPSN Thread-Index: AcRo/0u0LkIgL91VSUmikss6AITezgAH6niQ To: , , X-OriginalArrivalTime: 13 Jul 2004 22:06:26.0801 (UTC) FILETIME=[A4839610:01C46925] 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 Ron, > Sent: 13 July 2004 18:05 > In addition, I believe that TDM emulation in general does not > require/need VCCV. Connectivity and alarms propagation are=20 > built-in into > the control word and the nature of the service (continuous packet > stream).=20 This may be workable due to the nature of this particular client and the = adaptation used/deemed-necessary here......but even saying this I not = sure you are right, because if there is any client compression (which I = don't agree with as a default case) I beleive one is proxying for the = integrity checking behaviour (that should only occur at the proper = client layer trail termination point) at an intermediate point. As a general rule we ought to have OAM solutions for each layer network = (appropriate to the mode) that are independent.......so that any viable = client/server relationship can exist and we don't have specific pairwise = client/server dependencies. The whole problem here (IMO) stems from the = fact that MPLS was never envisaged/designed as a layer network in its = own right (despite the *MP* name) at t=3D0, and OAM was an afterthought = for many. If operator X owns a given layer network (any technology) and folks = lease capacity off this then operator X should be able to manage that = layer network irrespective of what other client layer networks run on = it....where those clients may of course be owned by many other parties. This is not a specific issue for MPLS or SDH or whatever......it applies = to all client/server layer network cases, and should be a general = starting point requirement of any sensible architecture. The integrity = of managing a network connection in some server layer network falls = squarely on the shoulders of the (server layer) trail termination point = which is below, and agnostic of, any specific client layer adaptation = function above this (please see G.805). Server layer defects = (detected/handled at the server layer trail termination point) should be = mapped (in the server->client layer adaption function) to the = appropriate FDI syntax that is appropriate for the technology/mode of = the client layer network(s) affected. regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Thomas D. Nadeau" Subject: Re: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] - OAM considerations Date: Tue, 13 Jul 2004 16:26:11 -0400 Lines: 68 Sender: pwe3-bounces@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF3878@i2km07-ukbr.domain1.systemhost.net> 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, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Wed Jul 14 07:48:30 2004 Return-path: X-BrightmailFiltered: true In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF3878@i2km07-ukbr.domain1.systemhost.net> To: neil.2.harrison@bt.com X-Mailer: Apple Mail (2.618) 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 On Jul 13, 2004, at 6:48 AM, neil.2.harrison@bt.com wrote: > Hi Stewart, > > I note Yaakov has already posted remarks on this draft regarding > ambiguity in the use/ordering of the CW and/or PID (which I agree > with). However, I see a further problem. If I am reading the draft > correctly it seems there are potentially many options: > - CW only; > - PID only; > - PID and CW (must appear in this order); > - ...and when the CW is used the various fields therein are optional > or vary, eg Seq Nos are optional, flags vary on client; > - the above only applies to PW LSPs, IP LSPs have none of this, ie > this is essentially the case of 'no CW and no PID'; > - ....and the above can be with/without OAM. > > So the further problem I see is when we have misconnectivity defects > between LSPs that are not identically specified wrt above (which of > course is currently a given anyway for the case of mixed PW LSPs and > IP LSPs even if all the PW LSPs are identically coded). > > Perhaps a good generic solution would have been to make the PID > mandatory on all LSPs (any client case, including IP). This appears > to give: > - give a consistent solution (for the ECMP hack) in all cases > - and allows correct identification of payload as OAM or traffic I personally agree with making the CW mandatory. The reasons you give are precisely why it makes sense; however, I think that there is some subset of providers that will object. There is also the issue of deployed hardware that cannot recognize the CW. --Tom > > The CW is always going to be a problem IMO......both from the fact > that it is optional per se, and that even when present some of the > fields therein are optional or variable dependent on the client. I > don't see any easy way out of this now.....though I suspect you know > my view on why this all such a problem now, ie MPLS is not IP, and for > forms of MPLS that do not violate the connectivity constraints of the > co-ps mode one does not need the CW IMO, nor does one need it if the > server layer technology belongs to the co-cs mode, ie Ping's recent > proposals for such. Furthermore, I also believe that client layer > transparency should always be the default behaviour, ie any minute > savings from client BW squeezing is not a major issue, complexity > however is. > > Could the best compromise be to make PID+CW the mandatory > case?.....where the PID still identifies the payload as traffic or > OAM, but we now know that there is always a CW interposed here (and > for folks who think it of little value they can just effectively set > it to 'null'). The other alternative is to code the PID for every > possible CW case.....though this would only seem important if varying > CW structures could exist in the same MPLS network. > > regards, Neil > > > _______________________________________________ > 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: signaling packets in CESoPSN Date: Wed, 14 Jul 2004 08:57:20 +0300 Lines: 65 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 Wed Jul 14 08:27:49 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] signaling packets in CESoPSN Thread-Index: AcRo/xvRU2MwcVEOS82iCJ0xGOiyqQAZe5aA To: "Ron Cohen" , , "Alexander Vainshtein" , 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 Ron, Tim, Sasha, and everyone,=20 > I would rather have a separate signaling channel (~option 2).=20 > I would go a step further and say that the signaling channel=20 > MAY be sent on a separate PW channel but can also be sent in=20 > another form=20 So far, I completely agree. If you want to separate the CAS into separate packets, then send them in a dedicated CAS PW. (and while you are at it, do the same for CCS !!! see the TDMoIP draft or Y.1413 Appendix II). If you don't want to use a separate PW, then the original method of placing the signaling substructure at the end of the last packet in the multiframe can be used. > (i.e. using IP packets when the PW run directly=20 > over MPLS). There is no need to have a separate signaling=20 > channel for each PW but rather the signaling information=20 > between two PEs may use a single signaling channel to=20 > transport information for multiple PWs running between the PEs. While it is possible to concatenation the signaling bits of multiple E1/T1s, I am not sure this is a great idea. The two sides would have to agree on the order of the substructures, and of course we would have to have some protocol to handling the bringing up and taking down of one of the trunks. In addition, we would have to consider fractional trunks=20 (do you pad each separate substructure to an even number of bytes?, etc). >=20 > In addition, I believe that TDM emulation in general does=20 > not require/need VCCV. Connectivity and alarms propagation=20 > are built-in into the control word and the nature of the=20 > service (continuous packet stream).=20 Here I disagree somewhat. I agree that we don't need VCCV for defect handling, but we DO need it for performance monitoring. I will discuss this in the next version of the TDMoIP draft. But, in any case, I don't see what the connection is=20 between CAS bits and VCCV. Not only would we have to define a new payload format for VCCV,=20 we would be somewhat abusing the draft-bryant-mcpherson-pwe3-cw-00.txt meaning of the first nibble. This should universally indicate a OAM flow, and not be overloaded with service-specific semantics. Finally, I would like to reiterate my dislike of option 1 (multiple sequenced flows in a PW)! So we are basically left with three acceptable options for CAS: 1) zero-overhead option - keep the CAS in place (for E1s leaving timeslot 16) and structure-lock on the multiframe using the FRG field. 2) the 1 PW option - CAS substructures and use of the FRG bits 3) the 2 PWs option - a separate CAS (or CCS) PW. =20 Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Date: Wed, 14 Jul 2004 09:04:01 +0300 Lines: 27 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, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Wed Jul 14 08:30:35 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Thread-Index: AcRpZjYNhSWOkG62SuCOK5krvAQmoQAAUp/g To: "Thomas D. Nadeau" , 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 > I personally agree with making the CW mandatory.=20 So do I. > The reasons you give are precisely why it makes sense;=20 I think something was lost here. I understood Neil to be arguing AGAINST using a CW. > however, I=20 > think that there is some subset of providers that will=20 > object. There is also the issue of deployed hardware that=20 > cannot recognize the CW. I think these two issues are really one. The providers who will object are those who have already deployed hardware that doesn't support the CW. But that is the risk early adopters take upon themselves. I believe that implementations could ease a migration from pre-standard to standard CW formats by supporting both options in the near term. But after that we should settle on the correct solution. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: signaling packets in CESoPSN Date: Wed, 14 Jul 2004 10:37:01 +0200 Lines: 86 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Tim.Frost@Zarlink.Com, Alik Shimelmits X-From: pwe3-bounces@ietf.org Wed Jul 14 09:56:08 2004 Return-path: To: "'Yaakov Stein'" , Ron Cohen , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) 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, Ron and all, Please see a couple of brief comments inline. I have snipped the text that does not deal directly with these comments. ---------------------------------------------------------------------------- -------- 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: Wednesday, July 14, 2004 7:57 AM > To: Ron Cohen; Tim.Frost@Zarlink.Com; Alexander Vainshtein; > pwe3@ietf.org > Subject: RE: [PWE3] signaling packets in CESoPSN > > > Ron, Tim, Sasha, and everyone, > ... snipped ... > > > (i.e. using IP packets when the PW run directly > > over MPLS). There is no need to have a separate signaling > > channel for each PW but rather the signaling information > > between two PEs may use a single signaling channel to > > transport information for multiple PWs running between the PEs. > > While it is possible to concatenation the signaling bits > of multiple E1/T1s, I am not sure this is a great idea. [Sasha] I must say I agree with Yaakov on this. ... snipped ... > > In addition, I believe that TDM emulation in general does > > not require/need VCCV. Connectivity and alarms propagation > > are built-in into the control word and the nature of the > > service (continuous packet stream). > > Here I disagree somewhat. > I agree that we don't need VCCV for defect handling, > but we DO need it for performance monitoring. > > I will discuss this in the next version of the TDMoIP draft. > [Sasha]I am not sure I understand that, but let's wait for the promised next revision. > > But, in any case, I don't see what the connection is > between CAS bits and VCCV. Not only would we have > to define a new payload format for VCCV, > we would be somewhat abusing the draft-bryant-mcpherson-pwe3-cw-00.txt > meaning of the first nibble. > This should universally indicate a OAM flow, > and not be overloaded with service-specific semantics. > [Sasha] I think that the latest CW draft defines a generic control/OAM channel within a PW using the 1st nibble of the CW and that this is fully aligned with the PWE3 Architecture. What's more, it EXPLICITLY provides for running multiprotocol over this channel. > > Finally, I would like to reiterate my dislike of option 1 > (multiple sequenced flows in a PW)! > > So we are basically left with three acceptable options for CAS: > > 1) zero-overhead option - keep the CAS in place (for E1s leaving > timeslot 16) > [Sasha] This option has not been defined in any draft and, just for the reference, explicitly FORBIDDEN in ATM-CES. > and structure-lock on the multiframe using the FRG field. > 2) the 1 PW option - CAS substructures and use of the FRG bits > 3) the 2 PWs option - a separate CAS (or CCS) PW. > > > 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: "Yaakov Stein" Subject: RE: signaling packets in CESoPSN Date: Wed, 14 Jul 2004 11:26:07 +0300 Lines: 31 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 Wed Jul 14 10:41:26 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] signaling packets in CESoPSN Thread-Index: AcRpdcOe4TaBBbN2S+mN31Rcw/4y1AABKFrw To: "Sasha Vainshtein" , 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 > > But, in any case, I don't see what the connection is between CAS bits=20 > > and VCCV. Not only would we have to define a new payload format for=20 > > VCCV, we would be somewhat abusing the=20 > > draft-bryant-mcpherson-pwe3-cw-00.txt > > meaning of the first nibble. > > This should universally indicate a OAM flow, and not be overloaded=20 > > with service-specific semantics. > > > [Sasha] I think that the latest CW draft defines a generic=20 > control/OAM channel within a PW using the 1st nibble of the=20 > CW and that this is fully aligned with the PWE3 Architecture.=20 > What's more, it EXPLICITLY provides for running multiprotocol=20 > over this channel. OK, now I understand what you mean. You are claiming thatit is legitimate to use VCCV for CAS signaling, since it is a "control/signaling" channel. But VCCV is a PW-layer OAM channel, not a TDM-layer control channel. If we accept your view we could overload VCCV with numerous client layer control protocols. I could imagine sending ATM OAM cells, or perhaps audio from technician's channels as VCCV with some appropriate payload format. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: signaling packets in CESoPSN Date: Wed, 14 Jul 2004 11:40:44 +0200 Lines: 67 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Jul 14 10:59:13 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) 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 inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Wednesday, July 14, 2004 10:26 AM > To: Sasha Vainshtein; pwe3@ietf.org > Subject: RE: [PWE3] signaling packets in CESoPSN > > > > > > But, in any case, I don't see what the connection is between CAS > bits > > > and VCCV. Not only would we have to define a new payload > format for > > > VCCV, we would be somewhat abusing the > > > draft-bryant-mcpherson-pwe3-cw-00.txt > > > meaning of the first nibble. > > > This should universally indicate a OAM flow, and not be > overloaded > > > with service-specific semantics. > > > > > [Sasha] I think that the latest CW draft defines a generic > > control/OAM channel within a PW using the 1st nibble of the > > CW and that this is fully aligned with the PWE3 Architecture. > > What's more, it EXPLICITLY provides for running multiprotocol > > over this channel. > > OK, now I understand what you mean. > [Sasha] So far, so good. > > You are claiming that it is legitimate to use VCCV for > CAS signaling, since it is a "control/signaling" channel. > > But VCCV is a PW-layer OAM channel, > not a TDM-layer control channel. > > If we accept your view we could overload VCCV > with numerous client layer control protocols. > I could imagine sending ATM OAM cells, > or perhaps audio from technician's channels > as VCCV with some appropriate payload format. > [Sasha] Please read carefully the description of "Type 2 PW Channel" in Section 5.1.2 of the Architecture document. It mentions a "sequenced, non-reliable channel" and its typical use is defined as "CE-CE signaling". CAS definitely comes under this category. ATM OAM cells need additional consideration (see dratfs on OAM mapping) and "orderwire" technician channels do not look suitable to me. > > Y(J)S > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: signaling packets in CESoPSN Date: Wed, 14 Jul 2004 12:22:17 +0300 Lines: 19 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 Jul 14 11:46:36 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] signaling packets in CESoPSN Thread-Index: AcRpfqkTSBwyKlYhQHi2d1lI9ShtAgABLtrw To: "Sasha Vainshtein" 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 > [Sasha] Please read carefully the description of "Type 2 PW=20 > Channel" in Section 5.1.2 of the Architecture document.=20 >=20 > It mentions a "sequenced, non-reliable channel" and its=20 > typical use is defined as "CE-CE signaling". > CAS definitely comes under this category. > ATM OAM cells need additional consideration (see dratfs on=20 > OAM mapping) and "orderwire" > technician channels do not look suitable to me. I AM familiar with Section 5.1.2. I agree that the CAS signaling should be put into a SEPARATE Type 2 PW (that's what a PW channel means). It should certainly not be in VCCV running inside the TDM Type 3 PW. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: signaling packets in CESoPSN Date: Wed, 14 Jul 2004 12:21:54 +0200 Lines: 47 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "Prayson Pate \(E-mail\)" , pwe3@ietf.org, "Stewart Bryant \(E-mail\)" X-From: pwe3-bounces@ietf.org Wed Jul 14 11:52:14 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) 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 inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Wednesday, July 14, 2004 11:22 AM > To: Sasha Vainshtein > Cc: pwe3@ietf.org > Subject: RE: [PWE3] signaling packets in CESoPSN > > > > > [Sasha] Please read carefully the description of "Type 2 PW > > Channel" in Section 5.1.2 of the Architecture document. > > > > It mentions a "sequenced, non-reliable channel" and its > > typical use is defined as "CE-CE signaling". > > CAS definitely comes under this category. > > ATM OAM cells need additional consideration (see dratfs on > > OAM mapping) and "orderwire" > > technician channels do not look suitable to me. > > I AM familiar with Section 5.1.2. > > I agree that the CAS signaling should be put into > a SEPARATE Type 2 PW (that's what a PW channel means). > [Sasha] This is your interpretation. IMO it is incompatible, e.g., with the rest of channel types (starting from the Channel Type 1) associated with the PW. I'd be happy to hear from the editors/co-authors of the Architecture document (sorry for repeating myself). > > It should certainly not be in VCCV running inside the TDM Type 3 PW. > > Y(J)S > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Torben Rasmussen" Subject: draft-ietf-pwe3-cesopsn-00.txt settings of L,M bits Date: Wed, 14 Jul 2004 13:17:37 +0200 Lines: 12 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 Jul 14 13:26:17 2004 Return-path: To: "'Sasha Vainshtein'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal 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 Sasha Reading through draft-ietf-pwe3-cesopsn-00.txt page 11, the 3rd = paragraph in sub clause 5.3 regarding signaling packaged the L and M bits shall be = set to "010". This seams to be wrong compared to table 1. This should be L,M = "011" correct or? The "010" code indicates an RDI condition of the AC. Best regards Torben Rasmussen T|pack A/S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: UDP PWs (was ITU-T Q5/13 Liason re PW over UDP) Date: Wed, 14 Jul 2004 15:28:29 +0300 Lines: 22 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 Wed Jul 14 14:45:16 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: UDP PWs (was ITU-T Q5/13 Liason re PW over UDP) Thread-Index: AcRfltEhbxZZyhNVR1CoQGRnecr/4AB8TpcgAgVo6DA= To: 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 A New Internet-Draft is available from the on-line Internet-Drafts directories. http://www.ietf.org/internet-drafts/draft-stein-pwe3-udp-00.txt Title : UDP based PWs Author(s) : Y(J) Stein Filename : draft-stein-pwe3-udp-00.txt Pages : 9 Date : July 11, 2004 Abstract The PWE3 charter permits three PSN types, namely "IP (both versions), L2TP, or MPLS". The majority of drafts submitted to the working group have focused on MPLS PSNs, and lesser attention has been given to L2TPv3. Only the TDMoIP drafts have explicitly specified UDP/IP as PSN, and only they stipulate the use of UDP port numbers as PW labels. This draft discusses PWs based on UDP/IP, concentrating on three issues, namely 1) the advisability of using UDP port numbers as PW labels, 2) which UDP port number to use, and 3) what label distribution protocol should be employed. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt settings of L,M bits Date: Wed, 14 Jul 2004 15:29:40 +0200 Lines: 34 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Jul 14 15:12:48 2004 Return-path: To: "'Torben Rasmussen'" X-Mailer: Internet Mail Service (5.5.2653.19) 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 Torben, Thank you for pointing to a bug. Will fix it in the next revision. 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: Torben Rasmussen [mailto:tra@tpack.net] > Sent: Wednesday, July 14, 2004 1:18 PM > To: Sasha Vainshtein > Cc: pwe3@ietf.org > Subject: draft-ietf-pwe3-cesopsn-00.txt settings of L,M bits > > > Hi Sasha > Reading through draft-ietf-pwe3-cesopsn-00.txt page 11, the > 3rd paragraph in > sub clause 5.3 regarding signaling packaged the L and M bits > shall be set to > "010". This seams to be wrong compared to table 1. This > should be L,M "011" > correct or? The "010" code indicates an RDI condition of the AC. > > Best regards > Torben Rasmussen > T|pack A/S > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Tim.Frost@Zarlink.Com Subject: RE: signaling packets in CESoPSN Date: Wed, 14 Jul 2004 17:11:20 +0100 Lines: 57 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, Sasha Vainshtein X-From: pwe3-bounces@ietf.org Wed Jul 14 18:43:46 2004 Return-path: To: "Yaakov Stein" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Zarlink(Release 6.5.1|January 21, 2004) at 07/14/2004 12:11:23 PM, Serialize complete at 07/14/2004 12:11:23 PM X-Scanned-By: MIMEDefang 2.38 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, I too am coming to the conclusion that we should use a separate PW. I think VCCV adds unecessary complexity to the signaling packets, even if one accepts Sasha's view that it is a legitmate use of the VCCV. Further, we still have separate sequenced streams running within the same PW, which is the original objection. Lastly, in the egress PE, VCCV packets may be diverted on classification to the entity responsible for OAM, and hence never reach the IWF. Use a separate PW does give the problem that there are 2 PWs that need to be associated. For example, what happens if one PW fails, but the other stays up? However, linking of associated PWs is a generic problem that shouldn't be solved by this draft. There must be other cases where this is required, hence a common solution to this issue should be found. In the meantime, I don't see any reason why it needs to hold up this draft. Tim "Yaakov Stein" Sent by: pwe3-bounces@ietf.org 14-Jul-2004 10:22 AM To: "Sasha Vainshtein" cc: pwe3@ietf.org Subject: RE: [PWE3] signaling packets in CESoPSN > [Sasha] Please read carefully the description of "Type 2 PW > Channel" in Section 5.1.2 of the Architecture document. > > It mentions a "sequenced, non-reliable channel" and its > typical use is defined as "CE-CE signaling". > CAS definitely comes under this category. > ATM OAM cells need additional consideration (see dratfs on > OAM mapping) and "orderwire" > technician channels do not look suitable to me. I AM familiar with Section 5.1.2. I agree that the CAS signaling should be put into a SEPARATE Type 2 PW (that's what a PW channel means). It should certainly not be in VCCV running inside the TDM Type 3 PW. 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: neil.2.harrison@bt.com Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Date: Wed, 14 Jul 2004 17:16:04 +0100 Lines: 101 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Wed Jul 14 18:44:39 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Thread-Index: AcRpZjYNhSWOkG62SuCOK5krvAQmoQAAUp/gAAfV7lA= To: , X-OriginalArrivalTime: 14 Jul 2004 16:16:05.0006 (UTC) FILETIME=[DCF5FAE0:01C469BD] 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 Yaakov...well spotted, and you are essentially correct (I think = Tom may have perhaps misinterpreted what I said)....please see below. Yaakov noted 14 July 2004 07:04 > > I personally agree with making the CW mandatory.=20 >=20 > So do I. >=20 > > The reasons you give are precisely why it makes sense;=20 >=20 > I think something was lost here. > I understood Neil to be arguing AGAINST using a CW. NH=3D> I was making a couple of points: - one wants a consistent method of fault management of trails = irrespective of the client(s) they are carrying.....this applies to all = technologies (I think that should be obvious/agreeable) - however, if we have varying CI (Characteristic Information) = constructs.....as seems possible with the CW and PID options, and some = CW fields are also variable (some of which are client = dependent).....then this looks like it will complicate defect = detection/handling if there are misconnectivity defects between = different structured LSPs. So I was arguing for at least the PID to always be present......mainly = to provide a consistent method of traffic vs OAM payload differentiation = *irrespective* of the client (and also address the ECMP issue in the = process). I also said we can make the CW 'always present' too, but then = tried to explain that inter-layer client/server adaptation is not the = same for all the 3 networking modes (there are 9 combinations here). = So, for example, if I take Pings' propsal for 'PWs_over_co-cs' say, we = don't need any of the CW fields at all....however, we do need: - a muxing adaptation function (and here the key point of the proposal = is to standardise on the shim header and LDP for config for this = particular function) and - when the server is co-cs we also need an alignment adaptation, ie = client/server rate decoupling (eg idle fill) and delination. For other clinet/server mode combinations the adaptation required is = different. So, in summary, the key point I am trying to get across here is that: - the CI (which includes the OAM) that goes between trail termination = points of some server layer network should be consistent/generic across = *all* client cases. - the inter-layer adaptation is *not* be consistent/generic across all = pairs of client/server cases.....it depends on the mode of both the = client and the server. So my point about making the PID mandatory is all about the 1st item = above wrt ensuring consistent/generic trail CI. >=20 > > however, I=20 > > think that there is some subset of providers that will=20 > > object. There is also the issue of deployed hardware that=20 > > cannot recognize the CW. >=20 > I think these two issues are really one. > The providers who will object are those who have already deployed > hardware that doesn't support the CW. >=20 > But that is the risk early adopters take upon themselves. NH=3D> Correct. I don't like the idea of forcing stds to comply with = what someone has 'gone early' with. This is a very dangerous precedent = IMO and it does worry me that the IETF continues to work on this basis, = ie rough consensus and running code (before RFC status). Don't get me = wrong, I think the philosophy has some merit....its just that I worry = that things that have been done badly might stop us doing things right. >=20 > I believe that implementations could ease a migration from > pre-standard to standard CW formats by supporting both > options in the near term. But after that we should settle > on the correct solution. NH=3D> I agree Yaakov.....but to be 'correct' there are several things = that need consisderation here....I can't list everything I'd perhaps = like to, but in the context of this thread topic: - the 3 modes are not the same......a 1 size fits all approach is = therefore not a good idea for many aspects of networking....and one must = respect the connectivity constraints of the mode and try and ensure that = the particular technology is functionally complete, eg don't miss out = the right sort of OAM up front (its quite different in all 3 modes), use = an OOB control/management plane for the co modes to make more secure, = ensure consistent access point addressing of trails however they are = instantiated, etc. I'd say we have not got all this right in the base = MPLS technology yet. - client/server and peer-partition i/w are not the same. The key rule = for client/server is layer independence. However, as I tried to show = above, the client/server inter-layer adaptation is not the same between = all modal cases. Further, the precendent set by FRF.8 for FR/ATM = 'service i/w' cannot be generalised to any pair of technologies....esp = if they belong to different modes. There will be significant function = and feature mismatch. So the key rule here is to terminate all the = server layer CI at the i/w point......though I note this requires = careful consideration of the 'thing' that is now the common client of = the peer server layers (defect mapping is one consisderation here). IMO = we are some way from having got either of these i/w cases 'correct' as = yet. regards, Neil >=20 > Y(J)S >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: signaling packets in CESoPSN Date: Wed, 14 Jul 2004 17:16:06 +0100 Lines: 75 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 Jul 14 18:45:00 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] signaling packets in CESoPSN Thread-Index: AcRo/xvRU2MwcVEOS82iCJ0xGOiyqQAZe5aAABGHOLA= To: , , , , X-OriginalArrivalTime: 14 Jul 2004 16:16:07.0679 (UTC) FILETIME=[DE8DD8F0:01C469BD] 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, A few additional points here... Yaakov wrote 14 July 2004 06:57 =20 RC=3D> In addition, I believe that TDM emulation in general does=20 > > not require/need VCCV. Connectivity and alarms propagation=20 > > are built-in into the control word and the nature of the=20 > > service (continuous packet stream).=20 >=20 YS=3D> Here I disagree somewhat. > I agree that we don't need VCCV for defect handling, > but we DO need it for performance monitoring. > I will discuss this in the next version of the TDMoIP draft. And I disgree with both of you on this. The defect handling (ie OAM) = should be an intrinsic part of the trail's CI, ie the same irrespective = of the client it carries. So whilst you may take the view 'we are OK = for our particular TDM client case' this does not satisfy me (and I = assume other operators) because I want the same/consistent fault = management irrespective of the client being carried. And further..... I can see where you are heading with the above remark Yaakov, but let me = just remind folks of what ought to be the ordering of processing here. = This is important for the NE/MIB behaviour and subsequent NMS/OSS = processing....and this ultimately impacts stuff like service/SLA = specifications, inter-operator performance apportionment rules, = operational effectiveness, etc: - be clear on the network mode considered....the base transport defects = are *not* the same in each mode, ie cl-ps reduces to simple breaks of = flows, co-cs can only have breaks of trails and swapped trails (and then = only between exactly alike trails), co-ps can have trail breaks, swaps = and mismering (with/without affecting the offending trail). So the = specification of the defects in terms of entry/exit criteria and = consequent actions is not the same in all cases. This also means the = OAM required is not the same. {Note: if you also don't respect the = connectivity constraints required of the co-ps mode then the defect = situation can significantly increase in complexity......and IMO can = become almost impossible to specify/measure.} - persistent defects should be used as basis for defining = unavailability.....(un)availability is a key SLA topic in its own right. - 'available time' is the only time when it is valid to collect network = performance (NP) metrics (ie delay/lost/errored traffic units) for use = in a NP SLA. NP measurements (at least wrt aggregation against the NP = SLA) should be suspended during unavailability periods. Note also that = for some technologies/applications if one direction fails then both = directions must be considered to be unavailable from a NP SLA viewpoint. {Aside - Although I see it all the time, folks should not be sloppy and = talk of 'QoS' as it has no objective meaning at the network level....QoS = is a subjective issue, based on a given application's perception of some = degree of NP metric(s) impairment. We should strictly talk of NP = parameters and their objectives.} So, to recap, the correct ordering is: - define defects of mode in terms of entry/exit criteria and consequent = actions - define (un)availability entry/exit criteria based on defect = persistence - define NP metrics and their end-end objectives (metrics vary with mode = obviously) for the available state for some HRX......then consider fair = apportionment to operator domains. We are not at some of the latter stages I noted above yet (eg HRX and = apportionment rules), but if we don't get the basics right then we won't = be able to easily/meaningfully get the later stuff right either. regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: du.ke@zte.com.cn Subject: Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Date: Thu, 15 Jul 2004 14:11:30 +0800 Lines: 106 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2138620468==" X-From: pwe3-bounces@ietf.org Thu Jul 15 08:17:21 2004 Return-path: To: pwe3@ietf.org 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-07-15 14:15:54 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 --===============2138620468== Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 VGhpcyBkcmFmdCBsZWFkcyByZWZsZWN0b3IgY29uY2VwdCwgd2hpY2ggY29tZXMgZnJvbSBCR1As IGludG8gUFdFMyBjb250cm9sDQpwcm90b2NvbC4gV2Ugd2FudCB0byB3ZWFrZW4gdGhlIHJlcXVl c3Qgb2YgZnVsbCBtZXNoIExEUCBzZXNzaW9uIGJldHdlZW4NClBFcy4NCg0KV2UgYXNrIGZvciBh ZHZpc2UuDQoNClRoYW5rcy4NCg0KRHUgS2UNCg0KDQpBZGQ6ICAgTm8uNjggWmlqaW5naHVhIFJk LFl1aHVhdGFpIERpc3RyaWN0LA0KICAgICAgIE5hbmppbmcuIFAuUi5DaGluYS4NClppcDogICAy MTAwMTINClRlbDogICAwMDg2LTI1LTUyODcxODA5DQpGYXg6ICAgMDA4Ni0yNS01Mjg3MTAwMA0K RS1NYWlsOiBkdS5rZUBtYWlsLnp0ZS5jb20uY24NCg0KLS0tLS0g16q3osjLILa85+YxMTEwNTkv dXNlci96dGVfbHRkIMqxvOQgMjAwNC0wNy0xNSAxMzo0OSAtLS0tLQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgSW50ZXJuZXQtRHJhZnRzQGllICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICB0 Zi5vcmcgICAgICAgICAgICAgICAgICAgIMrVvP7Iy6O6ICBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgILeivP7I y6O6ICAgICAgICAgICAgICAgICAgs63LzaO6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgaS1kLWFubm91 bmNlLWJvdW5jICAgICAgICDW98zio7ogICAgSS1EICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICBlc0BpZXRmLm9yZyAg ICAgICAgICAgICAgICBBQ1RJT046ZHJhZnQteXVkb25nLXB3ZTMtY29udHJvbC1wcm90b2NvbC1l eHQtMDAudHh0ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAyMDA0LTA3LTE1IDAzOjMzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgIMfrtPC4tCC4+CAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgICAgICAgICAgICAgICAgICAgaW50ZXJuZXQtZHJhZnRzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KDQoNCkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cw0KZGlyZWN0b3JpZXMuDQoNCg0KICAgICAgICAgICAgIFRpdGxlICAgICAgICAgICAg ICAgICAgICAgICAgIDogU2NhbGFibGUgVlBXUyBOZXR3b3JrDQogICAgICAgICAgICAgQXV0aG9y KHMpICAgICAgICAgOiBDLiBZdWRvbmcsIGV0IGFsLg0KICAgICAgICAgICAgIEZpbGVuYW1lICAg ICAgICAgIDoNCmRyYWZ0LXl1ZG9uZy1wd2UzLWNvbnRyb2wtcHJvdG9jb2wtZXh0LTAwLnR4dA0K ICAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICAgICAgICAgICAgICAgIDogMTUNCiAgICAgICAg ICAgICBEYXRlICAgICAgICAgICAgICAgICAgICA6IDIwMDQtNy0xNA0KDQpJbiB0aGUgcHdlMyBm cmFtZXdvcmssIFBXIGlzIHByb3ZpZGVkIGJldHdlZW4gdGhlIGVncmVlIG5vZGVzLiBJbg0KICAg IHRoaXMgY2FzZSwgZnVsbC1tZXNoIFBTTiB0dW5uZWwgYW5kIHNpZ25hbGluZyBzZXNzaW9uIGNv bm5lY3Rpb25zDQogICAgbXVzdCBiZSBlc3RhYmxpc2hlZCBiZXR3ZWVuIHB3ZTMgUEVzLCB3aGlj aCBsZWFkcyB0byB0aGUgaXNzdWUgb2YNCiAgICBzY2FsYWJpbGl0eSwgZXNwZWNpYWxseSB0aGUg ZGlmZmljdWx0eSBvZiBjcm9zcy1BUyBQVyBzZXJ2aWNlcy4NCiAgICBUaGlzIGRvY3VtZW50IHBy b3ZpZGVzIGEgcmVmbGVjdG9yLWJhc2VkIFZQV1MgbmV0d29yayBmcmFtZXdvcmssDQogICAgYW5k IHByZXNlbnRzIGEgc29sdXRpb24gdGhhdCBwcm92aWRlcyBjcm9zcy1BUyBwd2UzLg0KDQpBIFVS TCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXl1ZG9uZy1wd2UzLWNvbnRyb2wtcHJvdG9jb2wtZXh0LTAwLnR4dA0K DQoNClRvIHJlbW92ZSB5b3Vyc2VsZiBmcm9tIHRoZSBJLUQgQW5ub3VuY2VtZW50IGxpc3QsIHNl bmQgYSBtZXNzYWdlIHRvDQppLWQtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZyB3aXRoIHRoZSB3 b3JkIHVuc3Vic2NyaWJlIGluIHRoZSBib2R5IG9mIHRoZQ0KbWVzc2FnZS4NCllvdSBjYW4gYWxz byB2aXNpdCBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9JLUQtYW5ub3Vu Y2UNCnRvIGNoYW5nZSB5b3VyIHN1YnNjcmlwdGlvbiBzZXR0aW5ncy4NCg0KDQpJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExvZ2luIHdpdGggdGhl DQp1c2VybmFtZQ0KImFub255bW91cyIgYW5kIGEgcGFzc3dvcmQgb2YgeW91ciBlLW1haWwgYWRk cmVzcy4gQWZ0ZXIgbG9nZ2luZyBpbiwNCnR5cGUgImNkIGludGVybmV0LWRyYWZ0cyIgYW5kIHRo ZW4NCiAgICAgICAgICAgICAiZ2V0IGRyYWZ0LXl1ZG9uZy1wd2UzLWNvbnRyb2wtcHJvdG9jb2wt ZXh0LTAwLnR4dCIuDQoNCkEgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMgY2Fu IGJlIGZvdW5kIGluDQpodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9m dHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQoNCkludGVybmV0LURyYWZ0cyBj YW4gYWxzbyBiZSBvYnRhaW5lZCBieSBlLW1haWwuDQoNClNlbmQgYSBtZXNzYWdlIHRvOg0KICAg ICAgICAgICAgIG1haWxzZXJ2QGlldGYub3JnLg0KSW4gdGhlIGJvZHkgdHlwZToNCiAgICAgICAg ICAgICAiRklMRQ0KL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15dWRvbmctcHdlMy1jb250cm9sLXBy b3RvY29sLWV4dC0wMC50eHQiLg0KDQpOT1RFOiAgICAgICAgVGhlIG1haWwgc2VydmVyIGF0IGll dGYub3JnIGNhbiByZXR1cm4gdGhlIGRvY3VtZW50IGluDQogICAgICAgICAgICAgTUlNRS1lbmNv ZGVkIGZvcm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlzDQogICAg ICAgICAgICAgZmVhdHVyZSwgaW5zZXJ0IHRoZSBjb21tYW5kICJFTkNPRElORyBtaW1lIiBiZWZv cmUgdGhlICJGSUxFIg0KICAgICAgICAgICAgIGNvbW1hbmQuICBUbyBkZWNvZGUgdGhlIHJlc3Bv bnNlKHMpLCB5b3Ugd2lsbCBuZWVkICJtdW5wYWNrIg0Kb3INCiAgICAgICAgICAgICBhIE1JTUUt Y29tcGxpYW50IG1haWwgcmVhZGVyLiAgRGlmZmVyZW50IE1JTUUtY29tcGxpYW50IG1haWwNCnJl YWRlcnMNCiAgICAgICAgICAgICBleGhpYml0IGRpZmZlcmVudCBiZWhhdmlvciwgZXNwZWNpYWxs eSB3aGVuIGRlYWxpbmcgd2l0aA0KICAgICAgICAgICAgICJtdWx0aXBhcnQiIE1JTUUgbWVzc2Fn ZXMgKGkuZS4gZG9jdW1lbnRzIHdoaWNoIGhhdmUgYmVlbg0Kc3BsaXQNCiAgICAgICAgICAgICB1 cCBpbnRvIG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91ciBsb2NhbCBkb2N1bWVudGF0 aW9uDQpvbg0KICAgICAgICAgICAgIGhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3NhZ2VzLg0K DQoNCkJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQg bWFpbCByZWFkZXINCmltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhl IEFTQ0lJIHZlcnNpb24gb2YgdGhlDQpJbnRlcm5ldC1EcmFmdC4NCmZ0cDovL2Fub255bW91c0Bm dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXl1ZG9uZy1wd2UzLWNvbnRyb2wtcHJv dG9jb2wtZXh0LTAwLnR4dA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQoN Cg0K --===============2138620468== 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 --===============2138620468==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: signaling packets in CESoPSN Date: Thu, 15 Jul 2004 12:45:30 +0300 Lines: 41 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 Thu Jul 15 11:57:40 2004 Return-path: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [PWE3] signaling packets in CESoPSN Thread-Index: AcRo/xvRU2MwcVEOS82iCJ0xGOiyqQAZe5aAABGHOLAAKPV6YA== To: , , , 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 > And I disgree with both of you on this. The defect handling=20 > (ie OAM) should be an intrinsic part of the trail's CI, ie=20 > the same irrespective of the client it carries. So whilst=20 > you may take the view 'we are OK for our particular TDM=20 > client case' this does not satisfy me (and I assume other=20 > operators) because I want the same/consistent fault=20 > management irrespective of the client being carried. Neil,=20 Thanks for the review of defect modes for the various cases. However, I stand by my original statement. The VCCV provides PW-layer OAM functionality, and as such needs to supply functionality needed for a CO layer, mainly detection of breaks. For certain clients we also need performance monitoring, mainly one-way and round-trip delay, a bit of info on the PDV and packet loss distributions, etc. Not all PW types have the same OAM requirements, so it would be severe overkill to demand that precisely the same functionality be provided for e.g. ATM and TDM PWs. In particular, for constant rate real-time streams we don't need keep-alives for connectivity checking, since the data itself arrives at a constant predictable rate. Any adding of heartbeats here is senseless BW increase (although needed for monitoring of idle backup paths).=20 This difference in handling would be objectionable were there to really be such a thing as a "generic PW". But there isn't. TDM PWs, Ethernet PWs and ATM PWs are different creatures with different needs. We grouped them together in order to combine underlying architecture as much as possible, but the service-specific parts are still significant. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Date: Thu, 15 Jul 2004 12:59:35 +0300 Lines: 49 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 Jul 15 12:12:18 2004 Return-path: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [PWE3] [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Thread-Index: AcRpZjYNhSWOkG62SuCOK5krvAQmoQAAUp/gAAfV7lAAMmn2UA== To: , 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 > Thanks Yaakov...well spotted, and you are essentially correct=20 > (I think Tom may have perhaps misinterpreted what I=20 > said)....please see below. > NH=3D> I was making a couple of points: > - one wants a consistent method of fault management of=20 > trails irrespective of the client(s) they are=20 > carrying.....this applies to all technologies (I think that=20 > should be obvious/agreeable) As I mentioned in the previous email, I am not sure this is required or even a good idea. > - however, if we have varying CI (Characteristic=20 > Information) constructs.....as seems possible with the CW and=20 > PID options, and some CW fields are also variable (some of=20 > which are client dependent).....then this looks like it will=20 > complicate defect detection/handling if there are=20 > misconnectivity defects between different structured LSPs. OK, now I see your problem. If transport LSPs get swapped, we depend on the PW label for=20 detecting misconnections (stray packets) and you would like=20 another field to help differentiation in case they happen to overlap. Of course, this assumes that the particular network really has many=20 different PW types in it, else the probability of having the same PW type is high. I think cookies or source IDs are much stronger for this purpose, and you could get these by using L2TP or RTP. > So I was arguing for at least the PID to always be=20 > present......mainly to provide a consistent method of traffic=20 > vs OAM payload differentiation *irrespective* of the client=20 > (and also address the ECMP issue in the process). I also=20 > said we can make the CW 'always present' too, but then tried=20 > to explain that inter-layer client/server adaptation is not=20 > the same for all the 3 networking modes (there are 9=20 > combinations here). So, for example, if I take Pings'=20 > propsal for 'PWs_over_co-cs' say, we don't need any of the CW=20 > fields at all we still need flags and perhaps FRG=20 Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: signaling packets in CESoPSN Date: Thu, 15 Jul 2004 16:32:59 +0100 Lines: 87 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 Thu Jul 15 17:48:54 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] signaling packets in CESoPSN Thread-Index: AcRo/xvRU2MwcVEOS82iCJ0xGOiyqQAZe5aAABGHOLAAKPV6YAAK2bLw To: , , , X-OriginalArrivalTime: 15 Jul 2004 15:32:59.0455 (UTC) FILETIME=[0243F4F0:01C46A81] 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, > > And I disgree with both of you on this. The defect handling=20 > > (ie OAM) should be an intrinsic part of the trail's CI, ie=20 > > the same irrespective of the client it carries. So whilst=20 > > you may take the view 'we are OK for our particular TDM=20 > > client case' this does not satisfy me (and I assume other=20 > > operators) because I want the same/consistent fault=20 > > management irrespective of the client being carried. >=20 > Neil,=20 >=20 > Thanks for the review of defect modes for the various cases. >=20 > However, I stand by my original statement. NH=3D> Likewise. >=20 > The VCCV provides PW-layer OAM functionality, > and as such needs to supply functionality > needed for a CO layer, mainly detection of breaks. NH=3D> Its more than this. > For certain clients we also need performance monitoring, > mainly one-way and round-trip delay, a bit of info on the PDV > and packet loss distributions, etc. NH=3D> Not as an 'always on' function across the population you don't. = PM is different to (and dependent on) fault-management. >=20 > Not all PW types have the same OAM requirements, NH=3D> Don't get this. The client type should be irrelevant for the = integrity management of the server trail.....this is a pretty = fundamantal requirement. We don't manage SDH or ATM trails in terms of = the client they are carrying.....for a given type of trail they are all = managed the same. > so it would be severe overkill to demand that precisely > the same functionality be provided for e.g. ATM and TDM PWs. NH=3D> And in a world where there can be = SDHoverIPoverSDHoverEthernet....or any other permutations you like = .....which is the client and which is the server, ie so which layer sets = the (inheritiance) rules for the other layers? But you are right in one = sense.....PM is something to be decoupled from basic fault-management. = Former should be on-demand (and could vary in type), latter should be = consistent, simple and 'always on' for all trails (irrespective of = client). >=20 > In particular, for constant rate real-time streams we don't need > keep-alives for connectivity checking, since the data itself > arrives at a constant predictable rate. Any adding of heartbeats > here is senseless BW increase (although needed for monitoring > of idle backup paths).=20 NH=3D> Well of course I understand this. But what if you have a case of = TDMoverATMoverMPLS or whatever.....where the various layer networks here = can be owned by different parties? One won't always know what the = ultimate client/application is. As I noted earlier, we do not change = how we fault-manage SDH VC4 trails (say) in terms of what client they = may be carrying.......nor may we even own that client layer network. >=20 > This difference in handling would be objectionable were there=20 > to really > be such a thing as a "generic PW". But there isn't. NH=3D> And therein lies the real gripe I have had here from day 1. The = layer network we should be managing consistently is MPLS......ditto IP, = but this is a different layer network/mode, has different defects and = requires different OAM......ditto SDH. PWs seem to be some political = sop to keep up the illusion that MPLS=3DIP......this simply is not true, = and therein lies the start of the rot. > Ethernet > PWs > and ATM PWs are different creatures with different needs. > We grouped them together in order to combine underlying architecture > as much as possible, but the service-specific parts are still > significant. NH=3D> This is where one should be differentiatiing 'client specific' = and 'clinet generic' adaptation functions (some folks call these = 'convergence layers'). However, OAM should be common to the server = layer for all client cases. I am rapidly losing sight of just what = exactly a PW is.....it seems its different things to different folks = depending of what they want to sell and to what audience. I think this = whole area is a bit of a mess (understatement). regards, Neil >=20 > Y(J)S >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: neil.2.harrison@bt.com Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Date: Thu, 15 Jul 2004 16:33:00 +0100 Lines: 85 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jul 15 17:49:38 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Thread-Index: AcRpZjYNhSWOkG62SuCOK5krvAQmoQAAUp/gAAfV7lAAMmn2UAALXoZQ To: , X-OriginalArrivalTime: 15 Jul 2004 15:33:00.0949 (UTC) FILETIME=[0327EC50:01C46A81] 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 Another go Yaakov then I give up...... > =20 > > Thanks Yaakov...well spotted, and you are essentially correct=20 > > (I think Tom may have perhaps misinterpreted what I=20 > > said)....please see below. >=20 >=20 > > NH=3D> I was making a couple of points: > > - one wants a consistent method of fault management of=20 > > trails irrespective of the client(s) they are=20 > > carrying.....this applies to all technologies (I think that=20 > > should be obvious/agreeable) >=20 > As I mentioned in the previous email, I am not sure this is > required or even a good idea. NH=3D> Blimey! Are you seriously telling me that my ops folks should = manage our transport network trails differently as a function of the = clients they carry....and when such networks are nested and we don't = even own the higher layer networks this is still true? This is crazy. = We must have consistent fault management of server layers trails. Your = views sound like someone addressing an enterprise market, not a major = operator market. >=20 > > - however, if we have varying CI (Characteristic=20 > > Information) constructs.....as seems possible with the CW and=20 > > PID options, and some CW fields are also variable (some of=20 > > which are client dependent).....then this looks like it will=20 > > complicate defect detection/handling if there are=20 > > misconnectivity defects between different structured LSPs. >=20 > OK, now I see your problem. NH=3D> It only becomes a problem (for us) when the stuff I am stating = gets ignored. > If transport LSPs get swapped, we depend on the PW label for=20 > detecting misconnections (stray packets) and you would like=20 > another field to help differentiation in case they happen to overlap. NH=3D> Not exactly. We must have the basic trail CI (which includes = OAM) completely client agnostic.......this seems so very obvious (from = an ops perspective) that I can't understand the difficulty in getting = this. Now different clients may require different adaptations to the = (common lower) server parts......these are client specific adaptations = (but we for sure don't needs loads of these....this is the QoS illusion = of efficiency). Example: UDP and TCP are different client adaptations to the common IP = network. But IP has common parts that apply irrespective of the client, = eg its ICMP fault-management. Now try out ATM. I.610 OAM is common to = all clients, but different clients use AAL1 or AAL2 or AAL5 adaptations. = SDH is the same. =20 > Of course, this assumes that the particular network really has many=20 > different PW types in it, else the probability of having the same PW > type > is high. I think cookies or source IDs are much stronger for this > purpose, > and you could get these by using L2TP or RTP. NH=3D> The best solution is to use the access point address of the layer = network in question (which is why its importnat these are consistent = irrespective of how the trail was instantiated....noting these belong to = the data-plane and not the control-plane). >=20 > > So I was arguing for at least the PID to always be=20 > > present......mainly to provide a consistent method of traffic=20 > > vs OAM payload differentiation *irrespective* of the client=20 > > (and also address the ECMP issue in the process). I also=20 > > said we can make the CW 'always present' too, but then tried=20 > > to explain that inter-layer client/server adaptation is not=20 > > the same for all the 3 networking modes (there are 9=20 > > combinations here). So, for example, if I take Pings'=20 > > propsal for 'PWs_over_co-cs' say, we don't need any of the CW=20 > > fields at all >=20 > we still need flags and perhaps FRG=20 NH=3D> The problem with PWs they are different things to different = folks.....they look like a camel, but that is probably being rather = disrepectful to camels ;-) regards, Neil >=20 > >=20 > Y(J)S >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Date: Thu, 15 Jul 2004 18:55:16 +0300 Lines: 35 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 Jul 15 18:21:26 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Thread-Index: AcRpZjYNhSWOkG62SuCOK5krvAQmoQAAUp/gAAfV7lAAMmn2UAALXoZQAAFOEVA= To: , 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 > NH=3D> Blimey! =20 Sorry, but that term doesn't appear in my (admittedly US English) dictionary. Could you please explain? > Example: UDP and TCP are different client adaptations to the=20 > common IP network. But IP has common parts that apply=20 > irrespective of the client, eg its ICMP fault-management. =20 > Now try out ATM. I.610 OAM is common to all clients, but=20 > different clients use AAL1 or AAL2 or AAL5 adaptations. SDH=20 > is the same. Once again, I think we are talking at right angles. Your argument is completely cogent for the MPLS-layer MPLS (e.g. Y.1711), but we have been discussing VCCV and other PW-layer OAM mechanisms. I completely agree that the MPLS-layer OAM should not care about the PW type (assuming that the PW is over MPLS). > NH=3D> The problem with PWs they are different things to=20 > different folks.....they look like a camel, but that is=20 > probably being rather disrepectful to camels ;-) The advantage of PWs is that they solve a lot of problems for a lot of different folks. ... and they look more like a zebra=20 (which is a horse developed by a standards organization). Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt ] -OAM considerations Date: Thu, 15 Jul 2004 19:39:02 +0200 Lines: 46 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: neil.2.harrison@bt.com, pwe3@ietf.org, tnadeau@cisco.com X-From: pwe3-bounces@ietf.org Thu Jul 15 19:08:31 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) 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, Neil and all, Please see a breif and not very essential comment. I've snipped the part of the text that is not related. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, July 15, 2004 5:55 PM > To: neil.2.harrison@bt.com; tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] [Fwd: I-D > ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations > > > > > NH=> Blimey! > ...snipped ... > > > NH=> The problem with PWs they are different things to > > different folks.....they look like a camel, but that is > > probably being rather disrepectful to camels ;-) > > The advantage of PWs is that they solve a lot > of problems for a lot of different folks. > ... and they look more like a zebra > (which is a horse developed by a standards organization). > > Y(J)S > [Sasha] Last time I've hader this, the camel - and not zebra! - has been defined as a horse developed by an SDO. In this respect I think Neil got it right. > _______________________________________________ > 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: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Date: Thu, 15 Jul 2004 17:31:03 +0100 Lines: 7 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jul 15 20:34:14 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations Thread-Index: AcRpZjYNhSWOkG62SuCOK5krvAQmoQAAUp/gAAfV7lAAMmn2UAALXoZQAAFOEVAAAOcz0A== To: , X-OriginalArrivalTime: 15 Jul 2004 16:31:03.0782 (UTC) FILETIME=[1F161060:01C46A89] 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 > > NH=3D> Blimey! =20 >=20 > Sorry, but that term doesn't appear in my (admittedly US English) > dictionary. > Could you please explain? surprise/astonishment/disbelief. regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Parameter ID in PW Grouping TLV Date: Thu, 15 Jul 2004 14:35:37 -0600 Organization: Cisco Systems Lines: 61 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: "pwe3@ietf.org \(E-mail\)" X-From: pwe3-bounces@ietf.org Fri Jul 16 00:29:51 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: Nick Weeds In-Reply-To: X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] 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 Nick, It looks like the picture is a victim of cut and paste. The picture is wrong , I will correct it to look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|PW Grouping ID TLV (0x096C)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks ! Luca Nick Weeds wrote: >Luca, > >I see that the new PW Grouping TLV contains both an LDP TLV header and a >parameter ID+length header. The LDP TLV header alone is sufficient to >identify the TLV contents, so it's unclear why the parameter ID+length >header is also present. > >Is this a deliberate choice, perhaps for historical reasons or for >similarity with the Interface Parameters TLV? > >Or could this perhaps be an artefact left from merging previous suggestions, >better addressed by removing the parameter ID and parameter length from the >PW Grouping TLV? > >If the parameter ID is kept, is the intention that the PW Grouping TLV could >be extended to contain other parameters in future? Also, has a parameter ID >value been assigned? > >Thanks, > > Nick. > > > >>Nick Weeds >>Software Developer >>Network Protocols Group >>Data Connection Ltd >>Tel: +44 1244 305200 >>Fax: +44 1244 312422 >>Email: Nick.Weeds@dataconnection.com >>Web: http://www.dataconnection.com >> >> > >_______________________________________________ >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: Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Date: Fri, 16 Jul 2004 00:47:41 +0100 Lines: 234 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Fri Jul 16 01:54:29 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Thread-Index: AcRqM59RjcI7JZsmQyisos6OgNTgmAAj6PuQ To: , X-OriginalArrivalTime: 15 Jul 2004 23:47:42.0682 (UTC) FILETIME=[1ED8F3A0:01C46AC6] 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 Du Ke, As I understand it, your proposal addresses two different issues. 1) Reduce the number of LDP sessions in the core Reading through the draft, at first glance the proposal for "Simple = Trunk Mode" appears to offer a feasible method for reducing the number = of LDP sessions in the core. In this approach PEs only need establish = targeted LDP sessions with "LDP reflectors". The LDP reflectors act as = relays and forward label messages received from source PEs onto = remote/target PEs, similar to the way in which BGP route reflectors = forward NLRIs onto clients. For this proposal to work the main change = required is the adding of extra fields to the LDP label message to = identify the source and destination PEs. Obviously for routers to be = used as LDP reflectors they would need to be modified so that they can = inspect the remote/target PE field in LDP messages and forward them on = accordingly. LDP reflectors would also need to be able to generate and = forward LDP error/notification messages onto effected PEs when targeted = LDP sessions go down. I think the concept of using LDP reflectors in the same way that BGP = route reflectors are used to improve scalability is an attractive = proposition to service providers. As well as reducing the number of = targeted LDP sessions required in the core, it also means that the = targeted LDP control traffic could be taken out-of-band, i.e. PW control = packets do not need to follow the same path as PW data packets. One can = envisage a converged IP/MPLS network with centralised LDP and BGP = reflectors, where targeted LDP and BGP control traffic could be carried = using a separate control/management overlay network with high = availability/reliability. Of course forwarding in the data plane would = still be dependent on inband LDP/RSVP-TE/IGP control. 2.) Extend LDP signalling to support PW stitching The "next hop self" mode describes a method for setting up and stitching = together multiple PWs end-to-end between two endpoints. At first pass, = adding a next hop TLV to provide the ability to set up multiple PWs = across intermediate routers between endpoints seems viable. However, I = have some concerns regarding the priority/pref TLV. Section 6 states: "When the target PE of the PW label mapping receives the PW label = message from the reflector or the downstream PEs, it can select the best = egress labels according to the priority or the default priority carried = in the label mapping message, or can adopt a certain load equalization = strategy to perform load sharing of the L2 PDU received from the L2 VPN = on different PWs." For VPWS there is a 1-to-1 mapping between an AI and a forwarder/PW. For = stitched PWs there is a 1-to-1 mapping between an ingress PW and an = egress PW. Therefore, only one label should be received from a remote PE = (or intermediate router for stitched PWs) for any given VPWS. I cannot = think of an application for which setting up multiple PWs between VPWS = forwarders would be required/beneficial. Multihomed MTU-s devices for = hierarchical VPLS use two PWs (one active, one backup), but they connect = to different PE-rs devices and therefore PE-rs devices only receive one = label from a MTU-s for any given forwarder (VSI in this case). If it is agreed that PEs should not receive multiple labels from a PE = for any given VPWS, then there is no need for the pref/priority TLV and = loops that might have been caused by having multiple PWs will be = avoided. Looking at section 7, which describes the intra-AS operation of the = proposed method for signalling stitched PWs, I think this section needs = further clarification. I find it difficult to understand but from what I = can make out it describes two intra-AS PW stitching methods from a data = plane perspective. These two methods appear to be the same except one = method uses a PSN tunnel between the ASBRs whereas the other one = doesn't. Perhaps some diagrams would provide some clarification, = although I think it would also be useful to describe what happens in the = control plane. As a general comment, the draft uses the term "LDP reflector" to = describe routers that reflect/relay LDP messages (referred to as simple = trunk mode), and to describe routers that act as intermediate nodes for = stitched PWs (referred to as next hop self mode). A router that is only = used for the latter is not performing LDP message reflecting/relaying = and therefore I do not think it should be called a LDP reflector. One = can imagine that LDP route reflectors could be dedicated devices (not = necessarily routers) that are used just for reflecting/relaying LDP = messages. One can also imagine that to support PW stitching it would be = necessary to make PE-rs devices in a hierarchical VPWS/VPLS network "PW = stitching & signalling" capable. The point being that a device may = support PW stitching/signalling but may not support (or be used for) LDP = message reflecting. Regards, Richard > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On=20 > Behalf Of du.ke@zte.com.cn > Sent: 15 July 2004 07:12 > To: pwe3@ietf.org > Subject: [PWE3] Fwd: I-D=20 > ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt >=20 >=20 > This draft leads reflector concept, which comes from BGP,=20 > into PWE3 control > protocol. We want to weaken the request of full mesh LDP=20 > session between > PEs. >=20 > We ask for advise. >=20 > Thanks. >=20 > Du Ke >=20 >=20 > Add: No.68 Zijinghua Rd,Yuhuatai District, > Nanjing. P.R.China. > Zip: 210012 > Tel: 0086-25-52871809 > Fax: 0086-25-52871000 > E-Mail: du.ke@mail.zte.com.cn >=20 > ----- =D7=AA=B7=A2=C8=CB =B6=BC=E7=E6111059/user/zte_ltd =CA=B1=BC=E4 = 2004-07-15 13:49 ----- > =20 > =20 > Internet-Drafts@ie =20 > =20 > tf.org = =CA=D5=BC=FE=C8=CB=A3=BA =20 > i-d-announce@ietf.org =20 > =B7=A2=BC=FE=C8=CB=A3=BA = =B3=AD=CB=CD=A3=BA =20 > =20 > i-d-announce-bounc =D6=F7=CC=E2=A3=BA = I-D =20 > =20 > es@ietf.org =20 > ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt =20 > =20 > =20 > =20 > =20 > 2004-07-15 03:33 =20 > =20 > =C7=EB=B4=F0=B8=B4 =B8=F8 = =20 > =20 > internet-drafts =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Scalable VPWS Network > Author(s) : C. Yudong, et al. > Filename : > draft-yudong-pwe3-control-protocol-ext-00.txt > Pages : 15 > Date : 2004-7-14 >=20 > In the pwe3 framework, PW is provided between the egree nodes. In > this case, full-mesh PSN tunnel and signaling session connections > must be established between pwe3 PEs, which leads to the issue of > scalability, especially the difficulty of cross-AS PW services. > This document provides a reflector-based VPWS network framework, > and presents a solution that provides cross-AS pwe3. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yudong-pwe3-control- protocol-ext-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-yudong-pwe3-control-protocol-ext-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-yudong-pwe3-control-protocol-ext-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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-yudong-pwe3-control-pr= otocol-ext-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: du.ke@zte.com.cn Subject: RE: Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Date: Fri, 16 Jul 2004 13:46:51 +0800 Lines: 191 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Fri Jul 16 10:30:03 2004 Return-path: To: richard.spencer@bt.com, pwe3@ietf.org 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-07-16 16:24:25 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 Thank Richard very much. You are right, 1) The term "LDP reflector" isn't appropriate to describe routers that act as intermediate nodes for stitched PWs. Perhaps we can call it "reflector" or "PW reflector". 2) Section 7, which describes the intra-AS operation of the proposed method for signalling stitched PWs, needs further clarification. "These two methods appear to be the same except one method uses a PSN tunnel between the ASBRs whereas the other one doesn't." It's true. But when use MPLS tunnel as the PSN tunnel, the MPLS PSN tunnel between the ASBRs may degrade, and the upstream ASBR can use PW label transmit payload to the downstream ASBR without a "PSN tunnel label", It seemed that no inter-AS PSN tunnel is needed. I see, we'd better combine the "two methods", and discribe "the tiny difference" as special case. 3)I'm agree with you that an application for which setting up multiple PWs between VPWS forwarders would be not required/beneficial. Maybe, we should not mention "load-balance". the purpose of "priority/pref TLV" is to solve the problem issued by multiple reflectors. When the network has multiple reflectors, PE may receive multiple PW label mappings. If one or more reflectors adopt the "nexthop self" mode, the nexthop values of the mapping messages received by the PE are different. R2 / \ PE1 PE2 \ / R1 for example, source PE2 send mapping to reflectors R1 and R2, It's assumed that both R1 and R2 send mapping to target PE1 simultaneously, R1 says nexthop itself, and so does R2, then PE1 will receive two differet mapping of the PW in discussing, it can select a best out label according to the priority, the PW(in one direction) will be PE1->R1->PE2 or PE1->R2->PE2. We will study the feasibility of load-balance between PE1->R1->PE2 and PE1->R2->PE2 more deeply. It make things more complex, and make the network more difficultly to be controlled. Regards, Du Ke > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On > Behalf Of richard.spencer@bt.com > Sent: 16 July 2004 07:47 > To: pwe3@ietf.org > Subject: RE: [PWE3] Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Du Ke, As I understand it, your proposal addresses two different issues. 1) Reduce the number of LDP sessions in the core Reading through the draft, at first glance the proposal for "Simple Trunk Mode" appears to offer a feasible method for reducing the number of LDP sessions in the core. In this approach PEs only need establish targeted LDP sessions with "LDP reflectors". The LDP reflectors act as relays and forward label messages received from source PEs onto remote/target PEs, similar to the way in which BGP route reflectors forward NLRIs onto clients. For this proposal to work the main change required is the adding of extra fields to the LDP label message to identify the source and destination PEs. Obviously for routers to be used as LDP reflectors they would need to be modified so that they can inspect the remote/target PE field in LDP messages and forward them on accordingly. LDP reflectors would also need to be able to generate and forward LDP error/notification messages onto effected PEs when targeted LDP sessions go down. I think the concept of using LDP reflectors in the same way that BGP route reflectors are used to improve scalability is an attractive proposition to service providers. As well as reducing the number of targeted LDP sessions required in the core, it also means that the targeted LDP control traffic could be taken out-of-band, i.e. PW control packets do not need to follow the same path as PW data packets. One can envisage a converged IP/MPLS network with centralised LDP and BGP reflectors, where targeted LDP and BGP control traffic could be carried using a separate control/management overlay network with high availability/reliability. Of course forwarding in the data plane would still be dependent on inband LDP/RSVP-TE/IGP control. 2.) Extend LDP signalling to support PW stitching The "next hop self" mode describes a method for setting up and stitching together multiple PWs end-to-end between two endpoints. At first pass, adding a next hop TLV to provide the ability to set up multiple PWs across intermediate routers between endpoints seems viable. However, I have some concerns regarding the priority/pref TLV. Section 6 states: "When the target PE of the PW label mapping receives the PW label message from the reflector or the downstream PEs, it can select the best egress labels according to the priority or the default priority carried in the label mapping message, or can adopt a certain load equalization strategy to perform load sharing of the L2 PDU received from the L2 VPN on different PWs." For VPWS there is a 1-to-1 mapping between an AI and a forwarder/PW. For stitched PWs there is a 1-to-1 mapping between an ingress PW and an egress PW. Therefore, only one label should be received from a remote PE (or intermediate router for stitched PWs) for any given VPWS. I cannot think of an application for which setting up multiple PWs between VPWS forwarders would be required/beneficial. Multihomed MTU-s devices for hierarchical VPLS use two PWs (one active, one backup), but they connect to different PE-rs devices and therefore PE-rs devices only receive one label from a MTU-s for any given forwarder (VSI in this case). If it is agreed that PEs should not receive multiple labels from a PE for any given VPWS, then there is no need for the pref/priority TLV and loops that might have been caused by having multiple PWs will be avoided. Looking at section 7, which describes the intra-AS operation of the proposed method for signalling stitched PWs, I think this section needs further clarification. I find it difficult to understand but from what I can make out it describes two intra-AS PW stitching methods from a data plane perspective. These two methods appear to be the same except one method uses a PSN tunnel between the ASBRs whereas the other one doesn't. Perhaps some diagrams would provide some clarification, although I think it would also be useful to describe what happens in the control plane. As a general comment, the draft uses the term "LDP reflector" to describe routers that reflect/relay LDP messages (referred to as simple trunk mode), and to describe routers that act as intermediate nodes for stitched PWs (referred to as next hop self mode). A router that is only used for the latter is not performing LDP message reflecting/relaying and therefore I do not think it should be called a LDP reflector. One can imagine that LDP route reflectors could be dedicated devices (not necessarily routers) that are used just for reflecting/relaying LDP messages. One can also imagine that to support PW stitching it would be necessary to make PE-rs devices in a hierarchical VPWS/VPLS network "PW stitching & signalling" capable. The point being that a device may support PW stitching/signalling but may not support (or be used for) LDP message reflecting. Regards, Richard > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On > Behalf Of du.ke@zte.com.cn > Sent: 15 July 2004 07:12 > To: pwe3@ietf.org > Subject: [PWE3] Fwd: I-D > ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt > > > This draft leads reflector concept, which comes from BGP, > into PWE3 control > protocol. We want to weaken the request of full mesh LDP > session between > PEs. > > We ask for advise. > > Thanks. > > Du Ke > > > Add: No.68 Zijinghua Rd,Yuhuatai District, > Nanjing. P.R.China. > Zip: 210012 > Tel: 0086-25-52871809 > Fax: 0086-25-52871000 > E-Mail: du.ke@mail.zte.com.cn > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Scalable VPWS Network > Author(s) : C. Yudong, et al. > Filename : > draft-yudong-pwe3-control-protocol-ext-00.txt > Pages : 15 > Date : 2004-7-14 > > In the pwe3 framework, PW is provided between the egree nodes. In > this case, full-mesh PSN tunnel and signaling session connections > must be established between pwe3 PEs, which leads to the issue of > scalability, especially the difficulty of cross-AS PW services. > This document provides a reflector-based VPWS network framework, > and presents a solution that provides cross-AS pwe3. > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Date: Fri, 16 Jul 2004 14:55:42 +0100 Lines: 127 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 Fri Jul 16 16:06:56 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Thread-Index: AcRrDduarsnSUFj+Q6WyFE2aOhuFLQAAAdRw To: , X-OriginalArrivalTime: 16 Jul 2004 13:55:42.0823 (UTC) FILETIME=[95C65770:01C46B3C] 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 Du Ke, > the purpose of "priority/pref TLV" is to solve the problem issued by > multiple reflectors. >=20 > When the network has multiple reflectors, PE may receive=20 > multiple PW label > mappings. If one or more reflectors adopt the "nexthop self" mode, the > nexthop values of the mapping messages received by the PE are=20 > different. A practical example for using routers in next hop self mode would be for = establishing a VPWS path between two LDP spoke sites across a core. = Spoke sites do not have targeted LDP sessions with each other, they only = have a targeted session with the PE that they attach to. The diagram = below shows a network with three PE-rs devices connected in a full mesh, = each with a single spoke MTUs device hanging off it.=20 |------PErs3-----MTUs3 | | | | MTUs1----PErs1-----PErs2-----MTUs2 To establish a VPWS from MTUs1 to MTUs2 three PWs must be stitched = together to form the end-to-end VPWS, i.e. PW1 between MTU-s1 and = PE-rs1, PW2 between PE-rs1 and PE-rs2, and PW3 between PE-rs2 and = MTU-s1. If standard LDP signalling is used, MTUs1 and PErs1 exchange targeted = LDP label messages to establish PW1, PErs1 and PErs2 exchange targeted = LDP label messages to establish PW2, and PErs2 and MTUs2 exchange = targeted LDP label messages to establish PW3. In this approach PW1, PW2 = and PW3 are set up independently using single or double sided = provisioning for each. The three separate PWs must then be associated = with each other and stitched together at midpoints (PErs1 and PErs2) = either by manual configuration or by NMS. The difference between this and your proposal is that your proposal = defines a method for setting up PW1, PW2, and PW3 dynamically without = having to configure the PW midpoints, and using single sided = provisioning only one endpoint (MTUs1/MTUs2) needs to be configured. However, having thought about your proposal further I don't think it = offers a scalable solution. To set up the 3 PWs in the above example for = a VPWS between MTUs1 and MTUs2 using your proposal would require the = following: 1. First, all PErs devices must support PW stitching/signalling (i.e. = next hop self mode). 2. MTUs1 is configured with or discovers the IP address of MTUs2. 3. MTUs1 sends a label message with MTUs2 as the target/remote IP = address to PErs1 (as it only has a targeted LDP session with PErs1). 4. PErs1 receives the label message, and allocates a label to reach its = own IP address. 5. PErs1 checks the remote/target IP address and determines that it = doesn't have a targeted LDP session with MTUs2. As it does not know = which (if any) PErs device does have a targeted LDP session with MTUs2, = the only option is for PErs1 to forward the label message (modified with = a PW label to reach its own IP address) onto PErs2 and PErs3. Note: = split horizon should be enforced to ensure that PErs devices do not = forward label messages received from PErs devices onto other PE-rs = devices. 6. PErs3 does not have a targeted LDP session with MTUs2 and although = the draft doesn't specify what happens in this case, I assume that PErs3 = looks at the remote/target IP address, determines that it doesn't have a = targeted session with MTUs2 and either i) sends a label release message = back to PErs1, or ii) allocates a label to reach its own IP address and = forwards the label message onto MTUs3, which in turn sends a label = release message back to PErs3 as it is not the target/remote PE and does = not have any other LDP peers to send the label message to. 7. PErs2 does have a targeted LDP session with MTUs2 and therefore = allocates a label to reach its own IP address and forwards the label = message onto MTUs2. 8. To establish bi-directional connectivity the same then needs to occur = in the opposite direction The problem with this approach is that every time a stitched PW path = needs to be set up across the core, PErs devices need to forward label = messages received from connected MTUs devices onto every PErs peer in = the full mesh, and in turn, all receiving PErs and MTUs devices that do = not form the switched PW path must send label release messages back to = the originating PErs. So for a full mesh LDP core with say 500 PErs = devices, a PErs needs to allocate and send out 499 labels, 498 of which = are not needed and will result in receiving 498 label withdraw messages. Regarding a PE receiving multiple labels, the only application I can = think of for this is a dual homed MTUs device for a VPLS. Referring back = to the previous example, if MTUs2 was dual homed to PErs2 and PErs3, = then it would receive label messages from PErs2 and PErs3 for the same = VPLS instance. Rather than perform load balancing across the two PWs, = one PW would become active and the other would be used as a backup = (which avoids looping problems). However, this scenario is not = applicable to VPWS. For a PErs device providing a VPWS there is a 1-to-1 = mapping between a MTUs facing PW and a PErs facing PW, but for a PErs = device providing a VPLS service there is a one-to many relationship = between a MTUs facing PW and PErs facing PWs. The point being that a = PErs forwarder (VSI) for a VPLS service is capable of = switching/forwarding traffic across multiple PWs, whereas as a VPWS = forwarder is only capable of forwarding traffic across one PW, i.e. a = VPWS forwarder does not have the capability to switch traffic from an = active PW to a backup PW.=20 > R2 > / \ > PE1 PE2 > \ / > R1 > for example, source PE2 send mapping to reflectors R1 and R2,=20 > It's assumed > that both R1 and R2 send mapping to target PE1 simultaneously, R1 says > nexthop itself, and so does R2, then PE1 will receive two=20 > different mapping > of the PW in discussing, it can select a best out label=20 > according to the > priority, the PW(in one direction) will be PE1->R1->PE2 or=20 > PE1->R2->PE2. I cannot think of any practical examples where the above example makes = sense. Why don't the PE routers have a targeted LDP session between = them? What is the reason/benefit for establishing a stitched PW path = between PE1 and PE2 via R1 or R2 rather than establishing a targeted LDP = session between PE1 and PE2 using a single PW? Stitching PWs is only = required where there isn't a full mesh of LDP sessions, i.e. for setting = up VPWS/VPLS between spoke sites across the core.=20 Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: du.ke@zte.com.cn Subject: RE: Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Date: Sat, 17 Jul 2004 15:01:48 +0800 Lines: 225 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Sat Jul 17 09:08:41 2004 Return-path: To: richard.spencer@bt.com, pwe3@ietf.org 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-07-17 15:05:52 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, In this draft, there are two type of devices, one is PE, the other is reflector. The reflector have the capability to reflect/relay LDP messages and/or act as intermediate nodes for stitched PWs. While compared with standard PE, The PE in this draft should be able to cooperate with reflector, i.e, PE should be able to send/receive PW label message with extended GID FEC element described in this draft, and recognise reflector from all target peers by "negotiation of capability", and we ask PE should send mapping to target PE and all reflector-neighbor initiatively. Reflector can recognise reflector-neighbor by "negotiation of capability" too. We ask reflector send mapping to target PE(only PE-neighbor that is target of PW mapping) and all reflector-neighbor(include the one which send mapping to it if the mapping is sent from a reflector) after it receive a mapping. that is, mapping flood among source PE, reflector(s), and target PE. In the schedule, no mapping release intervene. In network example followed: |------PErs3-----MTUs3 | | | | MTUs1----PErs1-----PErs2-----MTUs2 I think that MTUs1/MTUs2/MTUs3 are Provider Edges(PEs), and PErs1/PErs2/PErs3 are intermediate nodes for stitched PWs, i.e, reflector. Before all, by negotiation of capability, they all learn capability of each other. To set up the 3 PWs in the above example for a VPWS between MTUs1 and MTUs2 would require the following: 1. First, all PErs devices must support PW stitching/signalling (i.e. next hop self mode).//Yes, they are reflector. 2. MTUs1(PE device) sends mapping to PErs1(reflector-neighbor). 3. While the target of PW mapping is not PErs1 itself, PErs1 send the mapping message to PErs2 and PErs3(all reflector-neighbors) with PW label modified and a nexthop tlv added. 4. PErs3 send mapping to PErs2 & PErs1(maybe, if path vector loop detection is adopted, PErs3 can know not to send mapping to PErs1). Because MTUs3 isn't the target of mapping message, PErs3 doesn't send mapping to it. 5. PErs2 send mapping to MTUs2(PE), because it is the target of mapping message on the beam. 6. PErs1 knows to use label from MTUs1 as out label of PW, but PEr2 must choose a label from which are sent from PEr1 and PEr3, so we design an priority machine. maybe path vector tlv or hop count tlv can solve the problem too. In the flooding process, MTUs1 and MTUs2 need maintain the status of PW, but MTUs3 needn't, because MTUs3 have no business with the PW. But all reflector must maintain the status of PW, i.e, adopt the Liberal Label Retention Mode to keep the PW label. no release should be sent, except any policy is configurated. Of cause, it maybe a problem for reflector to maintain too many status of PWs. Some policy must be inducted. for example, maybe PErs1 knows that MTUs2 is behind of PErs2(similarly to MSDP, Peer-RPF Forwarding technology is used, but the derection is reverse), it can send mapping whose target peer is MTUs2 to PErs2 only. Instead of "split horizon", we consider that the "Loop Detection Mechine(see RFC 3036)" of LDP is much better. both "Hop Count" and "Path Vector" seem to do work, especially "Path Vector". Regarding a PE receiving multiple labels, the application I think of for this is following. reflector-1 reflector-2(backup) | \ \ / / | | \ \/ / | | \ / /\ | | /\ / \ | | / \ / \ | PE1 PE2 ...... PEn PE1, PE2,..., and PEn (up to 20 or more PEs)all have target sessions with reflection-1 and reflection-2, while reflector-2 is a backup. and PE1, PE2,..., PEn need no target session with each other. Regards, Du Ke > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On > Behalf Of richard.spencer@bt.com > Sent: 2004-07-16 21:55 > To: pwe3@ietf.org > Subject: RE: [PWE3] Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Du Ke, > the purpose of "priority/pref TLV" is to solve the problem issued by > multiple reflectors. > > When the network has multiple reflectors, PE may receive > multiple PW label > mappings. If one or more reflectors adopt the "nexthop self" mode, the > nexthop values of the mapping messages received by the PE are > different. A practical example for using routers in next hop self mode would be for establishing a VPWS path between two LDP spoke sites across a core. Spoke sites do not have targeted LDP sessions with each other, they only have a targeted session with the PE that they attach to. The diagram below shows a network with three PE-rs devices connected in a full mesh, each with a single spoke MTUs device hanging off it. |------PErs3-----MTUs3 | | | | MTUs1----PErs1-----PErs2-----MTUs2 To establish a VPWS from MTUs1 to MTUs2 three PWs must be stitched together to form the end-to-end VPWS, i.e. PW1 between MTU-s1 and PE-rs1, PW2 between PE-rs1 and PE-rs2, and PW3 between PE-rs2 and MTU-s1. If standard LDP signalling is used, MTUs1 and PErs1 exchange targeted LDP label messages to establish PW1, PErs1 and PErs2 exchange targeted LDP label messages to establish PW2, and PErs2 and MTUs2 exchange targeted LDP label messages to establish PW3. In this approach PW1, PW2 and PW3 are set up independently using single or double sided provisioning for each. The three separate PWs must then be associated with each other and stitched together at midpoints (PErs1 and PErs2) either by manual configuration or by NMS. The difference between this and your proposal is that your proposal defines a method for setting up PW1, PW2, and PW3 dynamically without having to configure the PW midpoints, and using single sided provisioning only one endpoint (MTUs1/MTUs2) needs to be configured. However, having thought about your proposal further I don't think it offers a scalable solution. To set up the 3 PWs in the above example for a VPWS between MTUs1 and MTUs2 using your proposal would require the following: 1. First, all PErs devices must support PW stitching/signalling (i.e. next hop self mode). 2. MTUs1 is configured with or discovers the IP address of MTUs2. 3. MTUs1 sends a label message with MTUs2 as the target/remote IP address to PErs1 (as it only has a targeted LDP session with PErs1). 4. PErs1 receives the label message, and allocates a label to reach its own IP address. 5. PErs1 checks the remote/target IP address and determines that it doesn't have a targeted LDP session with MTUs2. As it does not know which (if any) PErs device does have a targeted LDP session with MTUs2, the only option is for PErs1 to forward the label message (modified with a PW label to reach its own IP address) onto PErs2 and PErs3. Note: split horizon should be enforced to ensure that PErs devices do not forward label messages received from PErs devices onto other PE-rs devices. 6. PErs3 does not have a targeted LDP session with MTUs2 and although the draft doesn't specify what happens in this case, I assume that PErs3 looks at the remote/target IP address, determines that it doesn't have a targeted session with MTUs2 and either i) sends a label release message back to PErs1, or ii) allocates a label to reach its own IP address and forwards the label message onto MTUs3, which in turn sends a label release message back to PErs3 as it is not the target/remote PE and does not have any other LDP peers to send the label message to. 7. PErs2 does have a targeted LDP session with MTUs2 and therefore allocates a label to reach its own IP address and forwards the label message onto MTUs2. 8. To establish bi-directional connectivity the same then needs to occur in the opposite direction The problem with this approach is that every time a stitched PW path needs to be set up across the core, PErs devices need to forward label messages received from connected MTUs devices onto every PErs peer in the full mesh, and in turn, all receiving PErs and MTUs devices that do not form the switched PW path must send label release messages back to the originating PErs. So for a full mesh LDP core with say 500 PErs devices, a PErs needs to allocate and send out 499 labels, 498 of which are not needed and will result in receiving 498 label withdraw messages. Regarding a PE receiving multiple labels, the only application I can think of for this is a dual homed MTUs device for a VPLS. Referring back to the previous example, if MTUs2 was dual homed to PErs2 and PErs3, then it would receive label messages from PErs2 and PErs3 for the same VPLS instance. Rather than perform load balancing across the two PWs, one PW would become active and the other would be used as a backup (which avoids looping problems). However, this scenario is not applicable to VPWS. For a PErs device providing a VPWS there is a 1-to-1 mapping between a MTUs facing PW and a PErs facing PW, but for a PErs device providing a VPLS service there is a one-to many relationship between a MTUs facing PW and PErs facing PWs. The point being that a PErs forwarder (VSI) for a VPLS service is capable of switching/forwarding traffic across multiple PWs, whereas as a VPWS forwarder is only capable of forwarding traffic across one PW, i.e. a VPWS forwarder does not have the capability to switch traffic from an active PW to a backup PW. > R2 > / \ > PE1 PE2 > \ / > R1 > for example, source PE2 send mapping to reflectors R1 and R2, > It's assumed > that both R1 and R2 send mapping to target PE1 simultaneously, R1 says > nexthop itself, and so does R2, then PE1 will receive two > different mapping > of the PW in discussing, it can select a best out label > according to the > priority, the PW(in one direction) will be PE1->R1->PE2 or > PE1->R2->PE2. I cannot think of any practical examples where the above example makes sense. Why don't the PE routers have a targeted LDP session between them? What is the reason/benefit for establishing a stitched PW path between PE1 and PE2 via R1 or R2 rather than establishing a targeted LDP session between PE1 and PE2 using a single PW? Stitching PWs is only required where there isn't a full mesh of LDP sessions, i.e. for setting up VPWS/VPLS between spoke sites across the core. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: zebras vs camels (was Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt -OAM considerations) Date: Sun, 18 Jul 2004 18:19:45 +0300 Lines: 21 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 18 17:29:51 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: zebras vs camels (was Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt -OAM considerations) Thread-Index: AcRqiqTGEHIX+Wt2Rt+ygEH6C9dKVACTs7OA To: "Sasha Vainshtein" 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 > [Sasha] Last time I've hader this, the camel - and not zebra!=20 > - has been defined as a horse developed by an SDO. > In this respect I think Neil got it right. Camels have a truly useful additional function to horses -=20 the hump stores water that allows it to travel long distances in the desert. Zebras are a political compromise between proponents who wanted white colored horses and those who wanted black. There is no additional functionality as compared to a horse (actually, I believe that the stripes make them stand out even more, and is a disadvantage). Nevertheless, on google =20 zebra "designed by committee" gets 18 hits while camel "designed by committee) gets 582. Perhaps the Internet is a network designed by a committee :-) Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: zebras vs camels (was Fwd: I-D ACTION:draft-bryant-mcpherson- pwe3-cw-00.txt -OAM considerations) Date: Sun, 18 Jul 2004 18:31:53 +0200 Lines: 43 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sun Jul 18 17:47:08 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) 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, Lots of thanks for exhaustive coverage of the issue raised. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Sunday, July 18, 2004 5:20 PM > To: Sasha Vainshtein > Cc: pwe3@ietf.org; neil.2.harrison@bt.com > Subject: RE: zebras vs camels (was Fwd: I-D > ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt -OAM considerations) > > > > > [Sasha] Last time I've heard this, the camel - and not zebra! > > - has been defined as a horse developed by an SDO. > > In this respect I think Neil got it right. > > Camels have a truly useful additional function to horses - > the hump stores water that allows it to travel long distances > in the desert. > > Zebras are a political compromise between proponents who wanted white > colored horses and those who wanted black. There is no additional > functionality as compared to a horse (actually, I believe that > the stripes make them stand out even more, and is a disadvantage). > > Nevertheless, on google > zebra "designed by committee" gets 18 hits > while camel "designed by committee) gets 582. > > Perhaps the Internet is a network designed by a committee :-) > > Y(J)S > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Vishal Sharma" Subject: "Inter-Provider Service Quality on the Internet": IEEE Comm. Mag. CFP Date: Sun, 18 Jul 2004 16:21:32 -0700 Lines: 136 Sender: pwe3-bounces@ietf.org Reply-To: v.sharma@ieee.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Loa Andersson , Thomas Nadeau , "Monique J. Morrow" X-From: pwe3-bounces@ietf.org Mon Jul 19 01:36:03 2004 Return-path: To: "PWE3" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 IEEE Communications Magazine has just approved the publication of a Feature Topic issue on "Challenges in Enabling Inter-Provider Service Quality on the Internet." The CFP is attached below. We invite those working in this area to consider sending in their contributions. If you intend to submit a paper for this special issue, please do drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your participation! Thanks, -Vishal **************************************************************** Vishal Sharma, Ph.D. Metanoia, Inc. Email: v.sharma@ieee.org. http://www.metanoia-inc.com **************************************************************** ========================================================================= CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "Challenges in Enabling Inter-Provider Service Quality on the Internet" ************************************************************************* As carriers and service providers build multi-services networks based on IP/MPLS- enabled infrastructures that are able to meet evermore stringent service level agreements (SLAs) and quality-of-service (QoS) requirements, it becomes a key issue to extend the ability to deliver these services across carrier and service provider domain boundaries, while at the same time preserving the same SLAs and QoS assurances as those provided within a given provider's network. The advent of new end-user applications, as well as new services based on MPLS technology, such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs), also means the emergence of added service quality requirements from operators deploying and interoperating these networks and the end-users themselves. As a result, providers and vendors require efficient means to enable inter-provider service quality, which comprises of several key elements including quality of service, class of service, security, OAM, and restoration and repair. This will is lead to the emergence of improved or novel tools and techniques to address these aspects, with the goal of guaranteeing service quality end-to-end, improving security and billing/accounting, and reducing operating costs. Standards organizations such as the IETF and the ITU are taking on significant work in this area, and various aspects of this subject are also being investigated by bodies such as the OIF, the MSF, the MPLS/Frame Relay Alliance, the IEEE, and the Metro Ethernet Forum, and are the themes for numerous upcoming conferences. This feature topic issue of the IEEE Communications Magazine has a multi-pronged focus on the delivery of inter-provider service quality: * Highlight operator and end-user concerns and requirements. * Feature current and/or planned deployment experiences. * Survey modern research and engineering developments. * Spotlight contemporary standards activity. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but certainly not limited to) the following topics: * Carrier requirements for efficient inter-provider service quality: Current operational needs, bottlenecks, future demands * Deployment experience with inter-provider service quality on IP/MPLS- based networks: comparative analysis, case studies * QoS management in an inter-provider environment: interconnection architectures using MPLS, Diffserv, QoS performance, path characterization, routing policies * Service assurance in inter-provider infrastructures: End-to-end SLA management, service billing/reporting, admission control * Failure and restoration requirements/challenges in inter-provider contexts * Interoperability and inter-working of diverse equipment types and technologies (ATM, FR, Ethernet) * Current engineering and research developments: E.g. Passive and active performance measurement and monitoring, TE, modelling and simulation * Standards activities and initiatives: new services and network architectures On-line CFP with submission instructions can be found at: http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided there is consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at http://www.comsoc.org/pubs/commag/sub_guidelines.html. ** Please submit no later than 30 October 2004.** Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due: 30 October 2004 Acceptance Notification: 15 January 2004 Final Manuscript Due: 28 February 2005 Publication Date: June 2005 Guest Editors Monique J. Morrow, Cisco Systems, (mmorrow@cisco.com) Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Thomas D.Nadeau, Cisco Systems (tnadeau@cisco.com) Loa Andersson, Acreo (loa@pi.se) From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: Submission of the updated CESoPSN and TDM control protocol extens ion drafts Date: Mon, 19 Jul 2004 14:51:04 +0200 Lines: 127 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-0600ff12-8826-427c-bf45-f54ee2b6c960" X-From: pwe3-bounces@ietf.org Mon Jul 19 14:11:31 2004 Return-path: To: "PWE3 WG (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) 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. ------=_NextPartTM-000-0600ff12-8826-427c-bf45-f54ee2b6c960 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46D8F.0D50DA50" ------_=_NextPart_001_01C46D8F.0D50DA50 Content-Type: text/plain; charset="windows-1255" Hi all, I've just submitted updates to the following drafts: CESoPSN - draft-ietf-pwe3-cesopsn-01.txt has been submitted. The draft has addressed all the issues raised during the WG last call TDM control protocol extensions - draft-vainshtein-pwe3-tdm-control-protocol-extensions-01.txt has been submitted. The update reflects the recent changes in the IANA allocations and changes in the CESoPSN draft (where the need to carry CE application sinaling in a separate PW has been identified during the last call). While the drafts are being processed, you can retrieve them from the following location: ftp://ftp.axerra.com/sasha With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) ------_=_NextPart_001_01C46D8F.0D50DA50 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
I've = just submitted=20 updates to the following drafts:
CESoPSN -=20 draft-ietf-pwe3-cesopsn-01.txt has been submitted.
The = draft has=20 addressed all the issues raised during the WG last = call
TDM = control protocol=20 extensions - = draft-vainshtein-pwe3-tdm-control-protocol-extensions-01.txt has=20 been submitted.
The = update reflects=20 the recent changes in the IANA allocations and changes in the = CESoPSN draft=20 (where the need to carry CE application sinaling in a separate PW = has been=20 identified during the last call).
 
While the=20 drafts are being processed,  you can retrieve them from the = following=20 location:
 
ftp://ftp.axerra.com/sasha
 
With best regards,
          &nb= sp;           &nb= sp;           =20 Sasha = Vainshtein
email:     sasha@axerra.com
tel:       +972-3-7659993=20 (office)
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
 
 
------_=_NextPart_001_01C46D8F.0D50DA50-- ------=_NextPartTM-000-0600ff12-8826-427c-bf45-f54ee2b6c960 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 ------=_NextPartTM-000-0600ff12-8826-427c-bf45-f54ee2b6c960-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-atm-encap-06.txt Date: Mon, 19 Jul 2004 15:57:12 -0400 Lines: 98 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 Tue Jul 20 00:39:26 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 : Encapsulation Methods for Transport of ATM Over IP and MPLS Networks Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-atm-encap-06.txt Pages : 36 Date : 2004-7-19 A framework for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [3]. This draft provides encapsulation formats and guidelines for transporting a variety of ATM services over a PSN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-atm-encap-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-atm-encap-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-atm-encap-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-ethernet-encap-07.txt Date: Mon, 19 Jul 2004 15:58:21 -0400 Lines: 101 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 Tue Jul 20 00:42:54 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 : Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-ethernet-encap-07.txt Pages : 1921 Date : 2004-7-19 An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units over an IP or MPLS network. This enables service providers to offer 'emulated' ethernet services over existing IP or MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a 'point-to-point ethernet' service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-07.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-ethernet-encap-07.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-ethernet-encap-07.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-iana-allocation-05.txt Date: Mon, 19 Jul 2004 15:58:32 -0400 Lines: 99 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 Tue Jul 20 00:45:59 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 : IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) Author(s) : L. Martini, M. Townsley Filename : draft-ietf-pwe3-iana-allocation-05.txt Pages : 6 Date : 2004-7-19 The Control and maintenance protocol for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [2]. This document pre-allocates the fixed Pseudo-wire identifier , and other fixed protocol values that are to be assigned by IANA using the 'IETF Consensus' policy defined in RFC2434 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-05.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-iana-allocation-05.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-iana-allocation-05.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: Danny McPherson Subject: IETF60 Agenda Slots Date: Mon, 19 Jul 2004 22:05:28 -0600 Lines: 14 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 Tue Jul 20 19:50:47 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.618) 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 I've received PWE3 @IETF60 slot requests from the following folks. If I've missed you please send me a request ASAP. Sasha Vainshtein Thomas Walsh Luca Martini Himanshu Shah Rahul Aggarwal Yaakov Stein Thanks! -danny From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: richard.spencer@bt.com Subject: RE: Fwd:I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Date: Wed, 21 Jul 2004 00:13:24 +0100 Lines: 470 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 Jul 21 05:06:30 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Thread-Index: AcRrzAK1rCXqHOZ7SESZ+uJ2J2dRhAC2if2Q To: , X-OriginalArrivalTime: 20 Jul 2004 23:13:25.0841 (UTC) FILETIME=[28F0AC10:01C46EAF] X-Scan-Signature: 2c6813ed945e40b4b5bea39da243c669 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 Du Ke, Scaling LDP signalling to potentially tens of thousands of PEs is a = problem that as yet (as far as I am aware) there is no complete solution = for. Using a hierarchical model improves scalability significantly but = introduces the issue of how to signal and stitch together large numbers = of PWs. The problem stems from the fact that stitching together multiple = PWs is effectively creating a new layer network. LDP has been proposed = for signalling the individual PWs that form a stitched PW path, but the = fundamental routing element required to calculate and select the best = path across multiple hops is missing. In practical terms this means that = PWs can be signalled individually, but not end-to-end from one side of = the stitched PW path. If a provider has a full mesh of tunnels between PEs then PW stitching = is not needed. Using LDP reflectors in 'simple trunk' mode could be used = here to reduce the number of LDP sessions in the core. However, using = 'next hop self' mode in an existing full mesh does not make sense as it = will result in sub-optimal routing and uneven network loading, i.e. the = optimal route for any given PE-PE path is the PE-PE tunnel, the path for = which has been calculated via a dynamic routing protocol (e.g. OSPF) or = via OSS. I think it would only make sense to use 'next hop self' mode when a = provider does not have a full mesh of tunnels between PEs. The problem = with your proposed 'next hop self' mode solution is that it does not = scale if large numbers of reflectors are required and is highly = inefficient, even for relatively low numbers of reflectors. This is = because it relies on a reflector sending a label to every other = reflector it's connected to, for every label mapping message it receives = from a PE. No learning takes place (as there is no routing) and = therefore LDP messages are effectively always broadcast to all reflector = peers and never unicast. Increasing the number or reflectors in the previous example by 1, and = connecting them together in a full mesh illustrates this best: MTUs4----PErs4--PErs3-----MTUs3 | \ / | | X | | / \ | MTUs1----PErs1--PErs2-----MTUs2 To establish a stitched PW path between MTUs1 and MTUs2 would involve = the following (if vector loop detection is used as you suggest): 1. MTUs1(PE device) sends a label mapping to PErs1(reflector-neighbor). = [1 label message sent] 2. PErs1 sends a mapping message to PErs2, PErs3, and PErs4 (all = reflector-neighbors) with the PW label modified and a nexthop tlv added. [4 label messages sent] Now lets just follow the ordered label distribution that occurs after = PErs3 receives a label mapping message from PErs1... 3. PErs3 sends a mapping message to PErs2 and PErs4 (not to PErs1 as = vector loop detection is used). [6 label messages sent] 4. PErs2 sends a label mapping message to MTUs2(PE) as it is the target. = [7 label messages sent] 5. PErs4 sends a label mapping message to PErs2 (not to PErs1 or PE rs3 = as vector loop detection is used). [8 label messages sent] 6. PErs2 sends a label mapping message to MTUs2(PE) as it is the target. = [9 label messages sent] At this point there are two stitched PW paths that have been signalled = between MTUs1 and MTUs2: PW path 1: MTUs1 -> PErs1 -> PErs3 -> PErs2 -> MTUs2 PW path 2: MTUs1 -> PErs1 -> PErs3 -> PErs4 -> PErs2 -> MTUs2 The above just followed the ordered label distribution that occurred = after PErs3 received a label mapping message from PErs1. The label = message from PErs1 to PErs2 will result in another label message being = sent [10 in total] and another PW path being signalled: PW path 3: MTUs1 -> PErs1 -> PErs2 -> MTUs2 The label message from PErs1 to PErs4 will result in another 5 label = messages being sent [15 in total] and two more PW paths being signalled: PW path 4: MTUs1 -> PErs1 -> PErs4 -> PErs2 -> MTUs2 PW path 5: MTUs1 -> PErs1 -> PErs4 -> PErs3 -> PErs2 -> MTUs2 MTUs2 receives 5 different label messages belonging to 5 different = stitched PW paths. As there is a 1-to-1 mapping between a VPWS forwarder = and an outbound PW, somehow MTUs2 must decide which path to accept and = send label release messages for the other four paths. You suggest using = a next hop pref/priority TLV. This mechanism will not work for this = scenario. The next hop for all 5 labels that MTUs2 receives will be the = same (i.e. PErs2) and therefore will have the same next hop = pref/priority. In addition, for cases where labels are received with = different next hops (e.g. PErs2 will receive 5 labels with 3 different = next hops), how can a provider allocate next hop/pref values for a = router when the values need to be destination/topology dependant, i.e. = the best next hop for a particular destination is not necessarily the = best next hop for another destination. This takes us back to the root of = the problem, i.e. LDP is being used for signalling but there is no = routing protocol/functionality. Routing selects the best path based on = some metric(s) via advertisement of route information. One way to add an = element of routing to select the best path would be to use the hop = count. However, this in itself does not make the solution scale as = routing state information is not maintained and therefore route = selection would need to take place every time a PW path needs to be set = up (as opposed to once when the routing protocol is activated and then = only when the topology changes).=20 Now consider the above example but with say 400 PErs routers (LDP = reflectors) in a full mesh. This is a realistic scenario for a large = service provider with a full mesh of PErs routers each with multiple = MTUs devices hanging off them. If 5 paths are signalled using 15 label = mapping messages in a network with just 4 PErs devices, obviously the = number of paths signalled and number of label mapping messages in a = network with 400 PErs devices will too large to make this a viable = solution, especially if liberal label retention is used. The LDP hop count could be set to 3 to reduce the number of PW paths set = up to 1. However, in a network of 400 PErs devices this would still = result in 398 LDP messages being sent to PErs devices that are not = connected to the target MTUs, and then another 397 LDP messages being = sent by those PErs devices, for which receiving PErs devices must drop = the label mapping messages and signal loop detected status to the source = of the label mapping message. Obviously sending ~800 Label mapping = messages and signalled loop detected messages to set up just 1 PW path = between two MTUs devices obviously doesn't scale and isn't viable. The proposal could be improved further by using split horizon, but again = this still results in 398 LDP messages being sent to reflectors that are = not attached to the MTUs and corresponding label withdraw messages being = received just to set up 1 PW path between two MTUs devices. I think that the 'simple trunk' mode of operation has the potential for = aiding LDP scaling for existing full meshes, but I do not think the = 'next hop self' mode is a viable solution to solve PW stitching = signalling (at least in its current state) due to its inefficiency and = the lack of scalability of its broadcast based operation. The next hop = self mode may not be intended to address PW stitching in hierarchical = LDP topologies, however, if not then I would like to understand better = exactly what practical problems the next hop self mode addresses = (bearing in mind that using next hop self in an existing full mesh = introduces sub-optimal routing and uneven network loading).=20 Regards, Richard > -----Original Message----- > From: du.ke@zte.com.cn [mailto:du.ke@zte.com.cn] > Sent: 17 July 2004 08:02 > To: Spencer,R,Richard,XGH5 R; pwe3@ietf.org > Subject: RE: [PWE3] Fwd: I-D > ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt >=20 >=20 > Richard, >=20 > In this draft, there are two type of devices, one is PE, the other is > reflector. > The reflector have the capability to reflect/relay LDP=20 > messages and/or act > as intermediate nodes for stitched PWs. >=20 > While compared with standard PE, The PE in this draft should=20 > be able to > cooperate with reflector, i.e, PE should be able to=20 > send/receive PW label > message with extended GID FEC element described in this draft, and > recognise reflector from all target peers by "negotiation of=20 > capability", > and we ask PE should send mapping to target PE and all=20 > reflector-neighbor > initiatively. >=20 > Reflector can recognise reflector-neighbor by "negotiation of=20 > capability" > too. We ask reflector send mapping to target PE(only=20 > PE-neighbor that is > target of PW mapping) and all reflector-neighbor(include the=20 > one which send > mapping to it if the mapping is sent from a reflector) after=20 > it receive a > mapping. >=20 > that is, mapping flood among source PE, reflector(s), and=20 > target PE. In the > schedule, no mapping release intervene. >=20 > In network example followed: >=20 > |------PErs3-----MTUs3 > | | > | | > MTUs1----PErs1-----PErs2-----MTUs2 >=20 > I think that MTUs1/MTUs2/MTUs3 are Provider Edges(PEs), and > PErs1/PErs2/PErs3 are intermediate nodes for stitched PWs,=20 > i.e, reflector. >=20 > Before all, by negotiation of capability, they all learn=20 > capability of each > other. >=20 > To set up the 3 PWs in the above example for a VPWS between=20 > MTUs1 and MTUs2 > would require the following: > 1. First, all PErs devices must support PW=20 > stitching/signalling (i.e. next > hop self mode).//Yes, they are reflector. >=20 > 2. MTUs1(PE device) sends mapping to PErs1(reflector-neighbor). >=20 > 3. While the target of PW mapping is not PErs1 itself, PErs1 send the > mapping message to PErs2 and PErs3(all reflector-neighbors)=20 > with PW label > modified and a nexthop tlv added. >=20 > 4. PErs3 send mapping to PErs2 & PErs1(maybe, if path vector=20 > loop detection > is adopted, PErs3 can know not to send mapping to PErs1).=20 > Because MTUs3 > isn't the target of mapping message, PErs3 doesn't send mapping to it. >=20 > 5. PErs2 send mapping to MTUs2(PE), because it is the target=20 > of mapping > message on the beam. >=20 > 6. PErs1 knows to use label from MTUs1 as out label of PW,=20 > but PEr2 must > choose a label from which are sent from PEr1 and PEr3, so we design an > priority machine. maybe path vector tlv or hop count tlv can solve the > problem too. >=20 > In the flooding process, MTUs1 and MTUs2 need maintain the=20 > status of PW, > but MTUs3 needn't, because MTUs3 have no business with the PW. >=20 > But all reflector must maintain the status of PW, i.e, adopt=20 > the Liberal > Label Retention Mode to keep the PW label. no release should be sent, > except any policy is configurated. >=20 > Of cause, it maybe a problem for reflector to maintain too=20 > many status of > PWs. Some policy must be inducted. for example, maybe PErs1 knows that > MTUs2 is behind of PErs2(similarly to MSDP, Peer-RPF=20 > Forwarding technology > is used, but the derection is reverse), it can send mapping=20 > whose target > peer is MTUs2 to PErs2 only. >=20 > Instead of "split horizon", we consider that the "Loop Detection > Mechine(see RFC 3036)" of LDP is much better. both "Hop=20 > Count" and "Path > Vector" seem to do work, especially "Path Vector". >=20 > Regarding a PE receiving multiple labels, the application I=20 > think of for > this is following. >=20 > reflector-1 reflector-2(backup) > | \ \ / / | > | \ \/ / | > | \ / /\ | > | /\ / \ | > | / \ / \ | > PE1 PE2 ...... PEn >=20 > PE1, PE2,..., and PEn (up to 20 or more PEs)all have target=20 > sessions with > reflection-1 and reflection-2, while reflector-2 is a backup. and PE1, > PE2,..., PEn need no target session with each other. >=20 > Regards, > Du Ke >=20 > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On > > Behalf Of richard.spencer@bt.com > > Sent: 2004-07-16 21:55 > > To: pwe3@ietf.org > > Subject: RE: [PWE3] Fwd: I-D > ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt >=20 > Du Ke, >=20 > > the purpose of "priority/pref TLV" is to solve the problem issued by > > multiple reflectors. > > > > When the network has multiple reflectors, PE may receive > > multiple PW label > > mappings. If one or more reflectors adopt the "nexthop=20 > self" mode, the > > nexthop values of the mapping messages received by the PE are > > different. >=20 > A practical example for using routers in next hop self mode=20 > would be for > establishing a VPWS path between two LDP spoke sites across a=20 > core. Spoke > sites do not have targeted LDP sessions with each other, they=20 > only have a > targeted session with the PE that they attach to. The diagram=20 > below shows a > network with three PE-rs devices connected in a full mesh, each with a > single spoke MTUs device hanging off it. >=20 > |------PErs3-----MTUs3 > | | > | | > MTUs1----PErs1-----PErs2-----MTUs2 >=20 > To establish a VPWS from MTUs1 to MTUs2 three PWs must be=20 > stitched together > to form the end-to-end VPWS, i.e. PW1 between MTU-s1 and PE-rs1, PW2 > between PE-rs1 and PE-rs2, and PW3 between PE-rs2 and MTU-s1. >=20 > If standard LDP signalling is used, MTUs1 and PErs1 exchange=20 > targeted LDP > label messages to establish PW1, PErs1 and PErs2 exchange targeted LDP > label messages to establish PW2, and PErs2 and MTUs2 exchange=20 > targeted LDP > label messages to establish PW3. In this approach PW1, PW2=20 > and PW3 are set > up independently using single or double sided provisioning=20 > for each. The > three separate PWs must then be associated with each other=20 > and stitched > together at midpoints (PErs1 and PErs2) either by manual=20 > configuration or > by NMS. >=20 > The difference between this and your proposal is that your=20 > proposal defines > a method for setting up PW1, PW2, and PW3 dynamically without=20 > having to > configure the PW midpoints, and using single sided=20 > provisioning only one > endpoint (MTUs1/MTUs2) needs to be configured. >=20 > However, having thought about your proposal further I don't=20 > think it offers > a scalable solution. To set up the 3 PWs in the above example=20 > for a VPWS > between MTUs1 and MTUs2 using your proposal would require the=20 > following: >=20 > 1. First, all PErs devices must support PW=20 > stitching/signalling (i.e. next > hop self mode). > 2. MTUs1 is configured with or discovers the IP address of MTUs2. > 3. MTUs1 sends a label message with MTUs2 as the=20 > target/remote IP address > to PErs1 (as it only has a targeted LDP session with PErs1). > 4. PErs1 receives the label message, and allocates a label to=20 > reach its own > IP address. > 5. PErs1 checks the remote/target IP address and determines=20 > that it doesn't > have a targeted LDP session with MTUs2. As it does not know=20 > which (if any) > PErs device does have a targeted LDP session with MTUs2, the=20 > only option is > for PErs1 to forward the label message (modified with a PW=20 > label to reach > its own IP address) onto PErs2 and PErs3. Note: split horizon=20 > should be > enforced to ensure that PErs devices do not forward label=20 > messages received > from PErs devices onto other PE-rs devices. > 6. PErs3 does not have a targeted LDP session with MTUs2 and=20 > although the > draft doesn't specify what happens in this case, I assume=20 > that PErs3 looks > at the remote/target IP address, determines that it doesn't=20 > have a targeted > session with MTUs2 and either i) sends a label release message back to > PErs1, or ii) allocates a label to reach its own IP address=20 > and forwards > the label message onto MTUs3, which in turn sends a label=20 > release message > back to PErs3 as it is not the target/remote PE and does not=20 > have any other > LDP peers to send the label message to. > 7. PErs2 does have a targeted LDP session with MTUs2 and therefore > allocates a label to reach its own IP address and forwards the label > message onto MTUs2. > 8. To establish bi-directional connectivity the same then=20 > needs to occur in > the opposite direction >=20 > The problem with this approach is that every time a stitched=20 > PW path needs > to be set up across the core, PErs devices need to forward=20 > label messages > received from connected MTUs devices onto every PErs peer in=20 > the full mesh, > and in turn, all receiving PErs and MTUs devices that do not form the > switched PW path must send label release messages back to the=20 > originating > PErs. So for a full mesh LDP core with say 500 PErs devices,=20 > a PErs needs > to allocate and send out 499 labels, 498 of which are not=20 > needed and will > result in receiving 498 label withdraw messages. >=20 > Regarding a PE receiving multiple labels, the only=20 > application I can think > of for this is a dual homed MTUs device for a VPLS. Referring=20 > back to the > previous example, if MTUs2 was dual homed to PErs2 and PErs3,=20 > then it would > receive label messages from PErs2 and PErs3 for the same VPLS=20 > instance. > Rather than perform load balancing across the two PWs, one PW=20 > would become > active and the other would be used as a backup (which avoids looping > problems). However, this scenario is not applicable to VPWS.=20 > For a PErs > device providing a VPWS there is a 1-to-1 mapping between a=20 > MTUs facing PW > and a PErs facing PW, but for a PErs device providing a VPLS=20 > service there > is a one-to many relationship between a MTUs facing PW and=20 > PErs facing PWs. > The point being that a PErs forwarder (VSI) for a VPLS=20 > service is capable > of switching/forwarding traffic across multiple PWs, whereas as a VPWS > forwarder is only capable of forwarding traffic across one=20 > PW, i.e. a VPWS > forwarder does not have the capability to switch traffic from=20 > an active PW > to a backup PW. >=20 > > R2 > > / \ > > PE1 PE2 > > \ / > > R1 > > for example, source PE2 send mapping to reflectors R1 and R2, > > It's assumed > > that both R1 and R2 send mapping to target PE1=20 > simultaneously, R1 says > > nexthop itself, and so does R2, then PE1 will receive two > > different mapping > > of the PW in discussing, it can select a best out label > > according to the > > priority, the PW(in one direction) will be PE1->R1->PE2 or > > PE1->R2->PE2. >=20 > I cannot think of any practical examples where the above example makes > sense. Why don't the PE routers have a targeted LDP session=20 > between them? > What is the reason/benefit for establishing a stitched PW=20 > path between PE1 > and PE2 via R1 or R2 rather than establishing a targeted LDP session > between PE1 and PE2 using a single PW? Stitching PWs is only=20 > required where > there isn't a full mesh of LDP sessions, i.e. for setting up VPWS/VPLS > between spoke sites across the core. >=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: Scaling hierarchical LDP/PW stitching Date: Wed, 21 Jul 2004 08:18:49 +0100 Lines: 100 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 Jul 21 09:29:19 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: Scaling hierarchical LDP/PW stitching Thread-Index: AcRu8oAj7cTJ2SjWQZ2nEbbbkkoqMw== To: , X-OriginalArrivalTime: 21 Jul 2004 07:18:50.0312 (UTC) FILETIME=[F87A4480:01C46EF2] 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 To address LDP scaling (and VPLS packet replication) a hierarchical LDP = model is proposed (in draft-ietf-l2vpn-signaling-01.txt) where hubs = (PErs routers) are connected via a full mesh of LDP sessions, but spokes = (PEr/MTUs routers) only establish LDP sessions with the hub(s) that they = connect to. This reduces the number of LDP sessions required and also = reduces the number of packet replications that hub (PErs) routers must = perform. However, as yet I don't believe there are any drafts that discuss = exactly how the hub and spoke PWs are signalled and stitched/bound = together. Likewise for VPWS PW paths that are established by stitching = multiple PWs together between endpoints. I believe this is an important = area as one can imagine large service providers having hundreds of PErs = routers connected via a full mesh of LDP sessions with tens of thousands = of MTUs/PEr devices hanging off them. To support hundreds of thousands = of PWs between tens of thousands of MTUs/PEr routers obviously requires = a highly scalable provisioning solution. The example below shows an example of a hierarchical VPLS/VPWS network = with 4 PErs devices each connected to a single MTUs device: MTUs4----PErs4--PErs3-----MTUs3 | \ / | | X | | / \ | MTUs1----PErs1--PErs2-----MTUs2=20 =20 I assume that to provision a stitched VPWS PW path from MTUs1 to MTUs2, = the individual PWs that form the path need to be established = individually and then stitched together. Although the individual PWs can = be established using single sided provisioning, the signalling for each = PW must be initiated at one side for each PW either through manual = configuration or via OSS. OSS (or some manual method) must also be used = to keep track of and bind the different PWs together. To do this OSS = needs to learn or be configured with information about which MTUs = devices sit behind which PErs devices. For VPLS, the point-to-multipoint PWs between the hubs (PErs devices) = can be provisioned using singled sided provisioning, but the spoke PWs = need to be signalled and associated with the relevant VPLS separately. = Again, the signalling needs to be initiated at one side and the spokes = need to be associated with the correct VPLS via manual configuration or = via OSS. The drawback with the above approach is that intermediate routers along = the stitched PW path (i.e. PErs routers) must each be configured via OSS = or via a manual method, and OSS must be also be used to bind and keep = track of the individual PWs. The ideal solution would be to use a = dynamic protocol(s) to establish the end-to-end PW path using single = sided provisioning initiated from one end of the path.=20 However, to establish and end-to-end path across multiple hops requires = a path to be calculated and selected (if multiple paths exist) before = the path can be signalled. Stitching PWs together to from a path between = two endpoints is effectively creating a new layer network. Although = targeted LDP has been proposed as the signalling mechanism to signal = individual PWs, there is no routing at the PW layer to calculate/select = an end-to-end path. Route/path calculation/selection is fairly simple for the hierarchical = LDP model using a centralised OSS approach, each MTUs is connected to = one PErs (except where dual homing is used), and each PErs has a = targeted LDP session with each other. Therefore, if the OSS knows that = MTUsX sits behind PErsX, and MTUsY sits behind PErsY, then to establish = a PW path between MTUsX and MTUsY requires stitching/signalling of 3 = PWs, i.e. MTUsX<->PErsX, PErsX<->PErsY, and PErsY<->MTUsY. Obtaining = information about which MTUs devices sit behind which PErs devices is = straightforward in the OSS approach because the information is gathered, = maintained, and processed using a centralised mechanism. Using a = distributed approach however using dynamic protocols requires = reachability information to be distributed, at least between the PErs = devices, i.e. PErs devices need to advertise to each other which MTUs = devices they are connected to. As yet a mechanism has not been defined = to distribute this information, or to select primary/secondary paths = where MTUs devices are multihomed. Du Ke has submitted a draft recently = () to address LDP scaling that proposes a solution with two = different modes: i) A mode called 'simple trunk' that reflects LDP messages to clients = similar to the way in which BGP route reflectors distribute routes to = clients. This potentially could be used to reduce the number of LDP = sessions in an existing full mesh. ii) A mode called 'next hop self' that describes a solution for PW = stitching but does not scale as it relies on broadcasting labels to = every PErs in the full mesh for every VPWS/VPLS (the route of the = problem being that there is no routing functionality at the 'PW layer' = which the draft does not address). I would like to establish consensus as to whether a) a dynamic protocol = based end-to-end single sided provisioning solution is required to aid = scaling for stitched PWs, or if b) PW stitching is best handled via OSS. Any comments/thoughts are welcomed. Thanks, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 21 Jul 2004 09:58:17 -0600 Lines: 151 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 Jul 21 17:34:50 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: richard.spencer@bt.com In-Reply-To: X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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, First I would like to point out that we are looking at solving a problem = that does not really exist ! LDP should scale very well to many thousands of sessions. TCP/IP has=20 been shown to scale to millions of sessions, and LDP uses TCP/IP as a=20 transport, with a light session initialization message protocol on top. We have to keep in mind that this is not BGP , with hundred of thousands = routes , each requiring complex policy filtering procedures. So you are bundling several issues together: -VPLS packet replication - LDP scaling - VPLS Autodiscovery So I believe that LDP scaling is not an issue, but VPLS autodiscovery ,=20 and packet replications certainly are. VPLS autodiscovery can be done in several ways , by using BGP (=20 draft-ietf-l2vpn-signaling-01.txt ), LDP ( defunct draft from Olen=20 Stokes ), or radius ( something like =20 draft-ietf-l2vpn-radius-pe-discovery-00.txt ). I believe that single sided signaling of PW is needed to help scaling of = autodiscovery. ( this way only the VPLS instance ID is needed , not=20 information about every link ). This seems to be a common requirement=20 of all the autodiscovery solutions. As far as PW stitching , or as I call it "switching", it is addressed in = draft-martini-pwe3-pw-switching-00.txt. Note that in this draft we switch PDUs from one PW to another PW,=20 running separate LDP control planes. This can be used to reduce the number of LDP sessions, but that only=20 makes LDP MD5 key management a little easier. It does not improve=20 scaling. The other application is to use a PW switching point PE as a=20 peering point between different administrative domains. ( note that this = does not require a new protocol, which makes peering easier ) Luca richard.spencer@bt.com wrote: >To address LDP scaling (and VPLS packet replication) a hierarchical LDP = model is proposed (in draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs= routers) are connected via a full mesh of LDP sessions, but spokes (PEr/= MTUs routers) only establish LDP sessions with the hub(s) that they conne= ct to. This reduces the number of LDP sessions required and also reduces = the number of packet replications that hub (PErs) routers must perform. > >However, as yet I don't believe there are any drafts that discuss exactl= y how the hub and spoke PWs are signalled and stitched/bound together. Li= kewise for VPWS PW paths that are established by stitching multiple PWs t= ogether between endpoints. I believe this is an important area as one can= imagine large service providers having hundreds of PErs routers connecte= d via a full mesh of LDP sessions with tens of thousands of MTUs/PEr devi= ces hanging off them. To support hundreds of thousands of PWs between ten= s of thousands of MTUs/PEr routers obviously requires a highly scalable p= rovisioning solution. > >The example below shows an example of a hierarchical VPLS/VPWS network w= ith 4 PErs devices each connected to a single MTUs device: > >MTUs4----PErs4--PErs3-----MTUs3 > | \ / | > | X | > | / \ | >MTUs1----PErs1--PErs2-----MTUs2=20 >=20 >I assume that to provision a stitched VPWS PW path from MTUs1 to MTUs2, = the individual PWs that form the path need to be established individually= and then stitched together. Although the individual PWs can be establish= ed using single sided provisioning, the signalling for each PW must be in= itiated at one side for each PW either through manual configuration or vi= a OSS. OSS (or some manual method) must also be used to keep track of and= bind the different PWs together. To do this OSS needs to learn or be con= figured with information about which MTUs devices sit behind which PErs d= evices. > >For VPLS, the point-to-multipoint PWs between the hubs (PErs devices) ca= n be provisioned using singled sided provisioning, but the spoke PWs need= to be signalled and associated with the relevant VPLS separately. Again,= the signalling needs to be initiated at one side and the spokes need to = be associated with the correct VPLS via manual configuration or via OSS. > >The drawback with the above approach is that intermediate routers along = the stitched PW path (i.e. PErs routers) must each be configured via OSS = or via a manual method, and OSS must be also be used to bind and keep tra= ck of the individual PWs. The ideal solution would be to use a dynamic pr= otocol(s) to establish the end-to-end PW path using single sided provisio= ning initiated from one end of the path.=20 > >However, to establish and end-to-end path across multiple hops requires = a path to be calculated and selected (if multiple paths exist) before the= path can be signalled. Stitching PWs together to from a path between two= endpoints is effectively creating a new layer network. Although targeted= LDP has been proposed as the signalling mechanism to signal individual P= Ws, there is no routing at the PW layer to calculate/select an end-to-end= path. > >Route/path calculation/selection is fairly simple for the hierarchical L= DP model using a centralised OSS approach, each MTUs is connected to one = PErs (except where dual homing is used), and each PErs has a targeted LDP= session with each other. Therefore, if the OSS knows that MTUsX sits beh= ind PErsX, and MTUsY sits behind PErsY, then to establish a PW path betwe= en MTUsX and MTUsY requires stitching/signalling of 3 PWs, i.e. MTUsX<->P= ErsX, PErsX<->PErsY, and PErsY<->MTUsY. Obtaining information about which= MTUs devices sit behind which PErs devices is straightforward in the OSS= approach because the information is gathered, maintained, and processed = using a centralised mechanism. Using a distributed approach however using= dynamic protocols requires reachability information to be distributed, a= t least between the PErs devices, i.e. PErs devices need to advertise to = each other which MTUs devices they are connected to. As yet a mechanism h= as not been defined to distribute this information, or to select primary/= secondary paths where MTUs devices are multihomed. > >Du Ke has submitted a draft recently () to address LDP scaling= that proposes a solution with two different modes: > >i) A mode called 'simple trunk' that reflects LDP messages to clients si= milar to the way in which BGP route reflectors distribute routes to clien= ts. This potentially could be used to reduce the number of LDP sessions i= n an existing full mesh. > >ii) A mode called 'next hop self' that describes a solution for PW stitc= hing but does not scale as it relies on broadcasting labels to every PErs= in the full mesh for every VPWS/VPLS (the route of the problem being tha= t there is no routing functionality at the 'PW layer' which the draft doe= s not address). > >I would like to establish consensus as to whether a) a dynamic protocol = based end-to-end single sided provisioning solution is required to aid sc= aling for stitched PWs, or if b) PW stitching is best handled via OSS. > >Any comments/thoughts are welcomed. > >Thanks, >Richard > > > > =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, 21 Jul 2004 18:15:19 +0100 Lines: 187 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 Jul 21 19:31:31 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: Scaling hierarchical LDP/PW stitching Thread-Index: AcRvNa7p8JA9Rd/wSA25Y1/hzEm6JwABpqqw To: X-OriginalArrivalTime: 21 Jul 2004 17:15:20.0533 (UTC) FILETIME=[4D1C9850:01C46F46] X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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, > First I would like to point out that we are looking at=20 > solving a problem=20 > that does not really exist ! I disagree, I think that scaling stitched PW provisioning to hundreds of = thousands of stitched PW paths between tens of thousands of edge devices = is a problem that exists today. > LDP should scale very well to many thousands of sessions. TCP/IP has=20 > been shown to scale to millions of sessions, and LDP uses TCP/IP as a=20 > transport, with a light session initialization message=20 > protocol on top. > We have to keep in mind that this is not BGP , with hundred=20 > of thousands=20 > routes , each requiring complex policy filtering procedures. I didn't state that scaling LDP sessions was the problem. I said that = the one of the reasons hierarchical VPLS was introduced was to reduce = the number of LDP sessions in the core. > So you are bundling several issues together: > -VPLS packet replication > - LDP scaling > - VPLS Autodiscovery No, I did not bundle several issues together, I asked specifically about = stitched PW provisioning scaling. I didn't mention autodiscovery and = only mentioned VPLS packet replication and LDP scaling to explain why = the hierarchical VPLS model was introduced. > As far as PW stitching , or as I call it "switching", it is=20 > addressed in=20 > draft-martini-pwe3-pw-switching-00.txt. > Note that in this draft we switch PDUs from one PW to another PW,=20 > running separate LDP control planes. > This can be used to reduce the number of LDP sessions, but that only=20 > makes LDP MD5 key management a little easier. It does not improve=20 > scaling. The other application is to use a PW switching point PE as a=20 > peering point between different administrative domains. (=20 > note that this=20 > does not require a new protocol, which makes peering easier ) >=20 > Luca >From your PW stitching or "switching" draft "The pseudowire switching = methodology described in this document assumes manual configuration of = the switching point" and "the PW switching point is configured to switch = a SH-PW from a specific peer to another SH-PW destined for a different = peer. This does not address the problem I raised, quoting from my original = email: "The drawback with the above (existing) approach is that intermediate = routers along the stitched PW path (i.e. PErs routers) must each be = configured via OSS or via a manual method, and OSS must be also be used = to bind and keep track of the individual PWs. The ideal solution would = be to use a dynamic protocol(s) to establish the end-to-end PW path = using single sided provisioning initiated from one end of the path." Just to be clear, the question I asked was "I would like to establish = consensus as to whether a) a dynamic protocol-based end-to-end single = sided provisioning solution is required to aid scaling for stitched PWs, = or if b) PW stitching is best handled via OSS." Richard >=20 > richard.spencer@bt.com wrote: >=20 > >To address LDP scaling (and VPLS packet replication) a=20 > hierarchical LDP model is proposed (in=20 > draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs routers)=20 > are connected via a full mesh of LDP sessions, but spokes=20 > (PEr/MTUs routers) only establish LDP sessions with the=20 > hub(s) that they connect to. This reduces the number of LDP=20 > sessions required and also reduces the number of packet=20 > replications that hub (PErs) routers must perform. > > > >However, as yet I don't believe there are any drafts that=20 > discuss exactly how the hub and spoke PWs are signalled and=20 > stitched/bound together. Likewise for VPWS PW paths that are=20 > established by stitching multiple PWs together between=20 > endpoints. I believe this is an important area as one can=20 > imagine large service providers having hundreds of PErs=20 > routers connected via a full mesh of LDP sessions with tens=20 > of thousands of MTUs/PEr devices hanging off them. To support=20 > hundreds of thousands of PWs between tens of thousands of=20 > MTUs/PEr routers obviously requires a highly scalable=20 > provisioning solution. > > > >The example below shows an example of a hierarchical=20 > VPLS/VPWS network with 4 PErs devices each connected to a=20 > single MTUs device: > > > >MTUs4----PErs4--PErs3-----MTUs3 > > | \ / | > > | X | > > | / \ | > >MTUs1----PErs1--PErs2-----MTUs2=20 > >=20 > >I assume that to provision a stitched VPWS PW path from=20 > MTUs1 to MTUs2, the individual PWs that form the path need to=20 > be established individually and then stitched together.=20 > Although the individual PWs can be established using single=20 > sided provisioning, the signalling for each PW must be=20 > initiated at one side for each PW either through manual=20 > configuration or via OSS. OSS (or some manual method) must=20 > also be used to keep track of and bind the different PWs=20 > together. To do this OSS needs to learn or be configured with=20 > information about which MTUs devices sit behind which PErs devices. > > > >For VPLS, the point-to-multipoint PWs between the hubs (PErs=20 > devices) can be provisioned using singled sided provisioning,=20 > but the spoke PWs need to be signalled and associated with=20 > the relevant VPLS separately. Again, the signalling needs to=20 > be initiated at one side and the spokes need to be associated=20 > with the correct VPLS via manual configuration or via OSS. > > > >The drawback with the above approach is that intermediate=20 > routers along the stitched PW path (i.e. PErs routers) must=20 > each be configured via OSS or via a manual method, and OSS=20 > must be also be used to bind and keep track of the individual=20 > PWs. The ideal solution would be to use a dynamic protocol(s)=20 > to establish the end-to-end PW path using single sided=20 > provisioning initiated from one end of the path.=20 > > > >However, to establish and end-to-end path across multiple=20 > hops requires a path to be calculated and selected (if=20 > multiple paths exist) before the path can be signalled.=20 > Stitching PWs together to from a path between two endpoints=20 > is effectively creating a new layer network. Although=20 > targeted LDP has been proposed as the signalling mechanism to=20 > signal individual PWs, there is no routing at the PW layer to=20 > calculate/select an end-to-end path. > > > >Route/path calculation/selection is fairly simple for the=20 > hierarchical LDP model using a centralised OSS approach, each=20 > MTUs is connected to one PErs (except where dual homing is=20 > used), and each PErs has a targeted LDP session with each=20 > other. Therefore, if the OSS knows that MTUsX sits behind=20 > PErsX, and MTUsY sits behind PErsY, then to establish a PW=20 > path between MTUsX and MTUsY requires stitching/signalling of=20 > 3 PWs, i.e. MTUsX<->PErsX, PErsX<->PErsY, and PErsY<->MTUsY.=20 > Obtaining information about which MTUs devices sit behind=20 > which PErs devices is straightforward in the OSS approach=20 > because the information is gathered, maintained, and=20 > processed using a centralised mechanism. Using a distributed=20 > approach however using dynamic protocols requires=20 > reachability information to be distributed, at least between=20 > the PErs devices, i.e. PErs devices need to advertise to each=20 > other which MTUs devices they are connected to. As yet a=20 > mechanism has not been defined to distribute this=20 > information, or to select primary/secondary paths where MTUs=20 > devices are multihomed. > > > >Du Ke has submitted a draft recently=20 () to address LDP scaling that proposes a solution with two = different modes: > >i) A mode called 'simple trunk' that reflects LDP messages to clients = similar to the way in which BGP route reflectors distribute routes to = clients. This potentially could be used to reduce the number of LDP = sessions in an existing full mesh. > >ii) A mode called 'next hop self' that describes a solution for PW = stitching but does not scale as it relies on broadcasting labels to = every PErs in the full mesh for every VPWS/VPLS (the route of the = problem being that there is no routing functionality at the 'PW layer' = which the draft does not address). > >I would like to establish consensus as to whether a) a dynamic protocol = based end-to-end single sided provisioning solution is required to aid = scaling for stitched PWs, or if b) PW stitching is best handled via OSS. > >Any comments/thoughts are welcomed. > >Thanks, >Richard > > > > =20 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Vach Kompella" Subject: RE: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 21 Jul 2004 10:19:48 -0700 Organization: Alcatel USA Lines: 240 Sender: pwe3-bounces@ietf.org References: <40FE9299.8070600@cisco.com> Reply-To: vach.kompella@alcatel.com 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 Jul 21 19:38:25 2004 Return-path: To: "'Luca Martini'" , 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.1409 In-Reply-To: <40FE9299.8070600@cisco.com> Importance: Normal X-OriginalArrivalTime: 21 Jul 2004 17:19:54.0071 (UTC) FILETIME=[F0272E70:01C46F46] X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 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 agree that scaling the number of LDP sessions is very similar to the problem of how many concurrent TCP sessions you can handle. It's not equivalent to the issue in BGP where the route reflector was useful because you basically flood BGP NLRIs to all neighbors (classical i-BGP mesh topology). LDP in the context of PWE3/VPLS has a very constrained distribution. In some **implementations**, there may be scaling limits, but those are implementation issues. Getting back to the question: PW stitching via discovery would be great, but that is the second step after Luca's draft which provides the mechanism for creating stitched PWs. As far as auto-discovery goes, I have a proposal, which I didn't get in before the deadline, which I will present, given there's time. The basic idea is: - send a "register" message for a FEC to a centralized discovery server - receive a "membership list" message containing members of the FEC back - set up targeted LDP sessions to members in the membership list - exchange FECs over sessions - discovery server also sends new membership list to all current members on the list The rest of the draft deals with packet formats and redundant discovery servers. If I get time between now and SD, I will post a URL to the list. -Vach=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Luca Martini > Sent: Wednesday, July 21, 2004 8:58 AM > To: richard.spencer@bt.com > Cc: l2vpn@ietf.org; pwe3@ietf.org > Subject: [PWE3] Re: Scaling hierarchical LDP/PW stitching >=20 >=20 > Richard, >=20 > First I would like to point out that we are looking at=20 > solving a problem=20 > that does not really exist ! > LDP should scale very well to many thousands of sessions. TCP/IP has=20 > been shown to scale to millions of sessions, and LDP uses TCP/IP as a=20 > transport, with a light session initialization message=20 > protocol on top. We have to keep in mind that this is not BGP=20 > , with hundred of thousands=20 > routes , each requiring complex policy filtering procedures. >=20 > So you are bundling several issues together: > -VPLS packet replication > - LDP scaling > - VPLS Autodiscovery >=20 > So I believe that LDP scaling is not an issue, but VPLS=20 > autodiscovery ,=20 > and packet replications certainly are. >=20 > VPLS autodiscovery can be done in several ways , by using BGP (=20 > draft-ietf-l2vpn-signaling-01.txt ), LDP ( defunct draft from Olen=20 > Stokes ), or radius ( something like =20 > draft-ietf-l2vpn-radius-pe-discovery-00.txt ). >=20 > I believe that single sided signaling of PW is needed to help=20 > scaling of=20 > autodiscovery. ( this way only the VPLS instance ID is needed , not=20 > information about every link ). This seems to be a common=20 > requirement=20 > of all the autodiscovery solutions. >=20 > As far as PW stitching , or as I call it "switching", it is=20 > addressed in=20 > draft-martini-pwe3-pw-switching-00.txt. > Note that in this draft we switch PDUs from one PW to another PW,=20 > running separate LDP control planes. > This can be used to reduce the number of LDP sessions, but that only=20 > makes LDP MD5 key management a little easier. It does not improve=20 > scaling. The other application is to use a PW switching point PE as a=20 > peering point between different administrative domains. (=20 > note that this=20 > does not require a new protocol, which makes peering easier ) >=20 > Luca >=20 >=20 >=20 >=20 > richard.spencer@bt.com wrote: >=20 > >To address LDP scaling (and VPLS packet replication) a=20 > hierarchical LDP=20 > >model is proposed (in draft-ietf-l2vpn-signaling-01.txt) where hubs=20 > >(PErs routers) are connected via a full mesh of LDP sessions, but=20 > >spokes (PEr/MTUs routers) only establish LDP sessions with=20 > the hub(s)=20 > >that they connect to. This reduces the number of LDP=20 > sessions required=20 > >and also reduces the number of packet replications that hub (PErs)=20 > >routers must perform. > > > >However, as yet I don't believe there are any drafts that discuss=20 > >exactly how the hub and spoke PWs are signalled and stitched/bound=20 > >together. Likewise for VPWS PW paths that are established by=20 > stitching=20 > >multiple PWs together between endpoints. I believe this is=20 > an important=20 > >area as one can imagine large service providers having=20 > hundreds of PErs=20 > >routers connected via a full mesh of LDP sessions with tens of=20 > >thousands of MTUs/PEr devices hanging off them. To support=20 > hundreds of=20 > >thousands of PWs between tens of thousands of MTUs/PEr routers=20 > >obviously requires a highly scalable provisioning solution. > > > >The example below shows an example of a hierarchical=20 > VPLS/VPWS network=20 > >with 4 PErs devices each connected to a single MTUs device: > > > >MTUs4----PErs4--PErs3-----MTUs3 > > | \ / | > > | X | > > | / \ | > >MTUs1----PErs1--PErs2-----MTUs2 > >=20 > >I assume that to provision a stitched VPWS PW path from=20 > MTUs1 to MTUs2,=20 > >the individual PWs that form the path need to be established=20 > >individually and then stitched together. Although the individual PWs=20 > >can be established using single sided provisioning, the=20 > signalling for=20 > >each PW must be initiated at one side for each PW either=20 > through manual=20 > >configuration or via OSS. OSS (or some manual method) must=20 > also be used=20 > >to keep track of and bind the different PWs together. To do this OSS=20 > >needs to learn or be configured with information about which MTUs=20 > >devices sit behind which PErs devices. > > > >For VPLS, the point-to-multipoint PWs between the hubs (PErs=20 > devices)=20 > >can be provisioned using singled sided provisioning, but the=20 > spoke PWs=20 > >need to be signalled and associated with the relevant VPLS=20 > separately.=20 > >Again, the signalling needs to be initiated at one side and=20 > the spokes=20 > >need to be associated with the correct VPLS via manual=20 > configuration or=20 > >via OSS. > > > >The drawback with the above approach is that intermediate=20 > routers along=20 > >the stitched PW path (i.e. PErs routers) must each be=20 > configured via OSS or via a manual method, and OSS must be=20 > also be used to bind and keep track of the individual PWs.=20 > The ideal solution would be to use a dynamic protocol(s) to=20 > establish the end-to-end PW path using single sided=20 > provisioning initiated from one end of the path. > > > >However, to establish and end-to-end path across multiple=20 > hops requires=20 > >a path to be calculated and selected (if multiple paths=20 > exist) before=20 > >the path can be signalled. Stitching PWs together to from a path=20 > >between two endpoints is effectively creating a new layer network.=20 > >Although targeted LDP has been proposed as the signalling=20 > mechanism to=20 > >signal individual PWs, there is no routing at the PW layer to=20 > >calculate/select an end-to-end path. > > > >Route/path calculation/selection is fairly simple for the=20 > hierarchical=20 > >LDP model using a centralised OSS approach, each MTUs is=20 > connected to=20 > >one PErs (except where dual homing is used), and each PErs has a=20 > >targeted LDP session with each other. Therefore, if the OSS=20 > knows that=20 > >MTUsX sits behind PErsX, and MTUsY sits behind PErsY, then=20 > to establish=20 > >a PW path between MTUsX and MTUsY requires stitching/signalling of 3=20 > >PWs, i.e. MTUsX<->PErsX, PErsX<->PErsY, and PErsY<->MTUsY. Obtaining=20 > >information about which MTUs devices sit behind which PErs=20 > devices is=20 > >straightforward in the OSS approach because the information is=20 > >gathered, maintained, and processed using a centralised mechanism.=20 > >Using a distributed approach however using dynamic protocols=20 > requires=20 > >reachability information to be distributed, at least between=20 > the PErs=20 > >devices, i.e. PErs devices need to advertise to each other=20 > which MTUs=20 > >devices they are connected to. As yet a mechanism has not=20 > been defined=20 > >to distribute this information, or to select primary/secondary paths=20 > >where MTUs devices are multihomed. > > > >Du Ke has submitted a draft recently=20 > >(l-ext-00.txt>) to address LDP scaling that proposes a solution with two >different modes: > >i) A mode called 'simple trunk' that reflects LDP messages to clients=20 >similar to the way in which BGP route reflectors distribute routes to=20 >clients. This potentially could be used to reduce the number of LDP=20 >sessions in an existing full mesh. > >ii) A mode called 'next hop self' that describes a solution for PW=20 >stitching but does not scale as it relies on broadcasting labels to=20 >every PErs in the full mesh for every VPWS/VPLS (the route of the=20 >problem being that there is no routing functionality at the 'PW layer'=20 >which the draft does not address). > >I would like to establish consensus as to whether a) a dynamic protocol >based end-to-end single sided provisioning solution is required to aid=20 >scaling for stitched PWs, or if b) PW stitching is best handled via=20 >OSS. > >Any comments/thoughts are welcomed. > >Thanks, >Richard > > > > =20 > _______________________________________________ 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: Eric Rosen Subject: Re: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 21 Jul 2004 15:02:28 -0400 Lines: 3 Sender: pwe3-bounces@ietf.org References: <047a01c46f46$f0b51690$0101010a@eng.timetra.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: l2vpn@ietf.org, pwe3@ietf.org, 'Luca Martini' , richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Wed Jul 21 21:20:26 2004 Return-path: X-BrightmailFiltered: true To: vach.kompella@alcatel.com In-reply-to: Your message of Wed, 21 Jul 2004 10:19:48 -0700. <047a01c46f46$f0b51690$0101010a@eng.timetra.com> 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: 01485d64dfa90b45a74269b3ca9d5574 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 Vach, how does your auto-discovery proposal differ from a scheme which uses BGP for auto-discovery and then sets up targeted LDP sessions based on the results of the auto-discovery? From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Mustapha Aissaoui Subject: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 21 Jul 2004 15:36:52 -0400 Organization: Alcatel Networks Corporaton Lines: 141 Sender: pwe3-bounces@ietf.org References: <6204FDDE129D364D8040A98BCCB290EF08E90874@zbl6c004.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, pwe3@ietf.org, "'l3vpn@ietf.org'" , "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Wed Jul 21 23:25:24 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: RAJESH SALUJA X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 Rajesh, in this case, there is no stitching of any sort. All what you need to do is to treat the incoming PW as a Attachement Circuit (AC) terminating on a L3 entity (VRF). Not very different from terminating a FR VC or ATM VC on a VRF. The major difference with a traditional PW is that it is provisioned or signaled from the access network side and does not terminate on a specific AC endpoint in the PE. Regards, Mustapha. ---------- > RAJESH SALUJA wrote: > > I have a similar question about hybrid networks where from MTU, a > PW starts and terminates at a PE router which uses L3VPN (2547) > mechanism to reach remote PE. In this case also, what is the best > interoperable way to stitch a PW to L3VPN endpoint. Is there any > document which describes this mechanism? > > I believe that for your case also, a dynamic protocol is required > otherwise provisioning will be nightmare. > > Thanks, > Rajesh > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf Of richard.spencer@bt.com > Sent: Wednesday, July 21, 2004 3:19 AM > To: pwe3@ietf.org; l2vpn@ietf.org > Subject: Scaling hierarchical LDP/PW stitching > > To address LDP scaling (and VPLS packet replication) a > hierarchical LDP model is proposed (in > draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs routers) are > connected via a full mesh of LDP sessions, but spokes (PEr/MTUs > routers) only establish LDP sessions with the hub(s) that they > connect to. This reduces the number of LDP sessions required and > also reduces the number of packet replications that hub (PErs) > routers must perform. > > However, as yet I don't believe there are any drafts that discuss > exactly how the hub and spoke PWs are signalled and stitched/bound > together. Likewise for VPWS PW paths that are established by > stitching multiple PWs together between endpoints. I believe this > is an important area as one can imagine large service providers > having hundreds of PErs routers connected via a full mesh of LDP > sessions with tens of thousands of MTUs/PEr devices hanging off > them. To support hundreds of thousands of PWs between tens of > thousands of MTUs/PEr routers obviously requires a highly scalable > provisioning solution. > > The example below shows an example of a hierarchical VPLS/VPWS > network with 4 PErs devices each connected to a single MTUs > device: > > MTUs4----PErs4--PErs3-----MTUs3 > | \ / | > | X | > | / \ | > MTUs1----PErs1--PErs2-----MTUs2 > > I assume that to provision a stitched VPWS PW path from MTUs1 to > MTUs2, the individual PWs that form the path need to be > established individually and then stitched together. Although the > individual PWs can be established using single sided provisioning, > the signalling for each PW must be initiated at one side for each > PW either through manual configuration or via OSS. OSS (or some > manual method) must also be used to keep track of and bind the > different PWs together. To do this OSS needs to learn or be > configured with information about which MTUs devices sit behind > which PErs devices. > > For VPLS, the point-to-multipoint PWs between the hubs (PErs > devices) can be provisioned using singled sided provisioning, but > the spoke PWs need to be signalled and associated with the > relevant VPLS separately. Again, the signalling needs to be > initiated at one side and the spokes need to be associated with > the correct VPLS via manual configuration or via OSS. > > The drawback with the above approach is that intermediate routers > along the stitched PW path (i.e. PErs routers) must each be > configured via OSS or via a manual method, and OSS must be also be > used to bind and keep track of the individual PWs. The ideal > solution would be to use a dynamic protocol(s) to establish the > end-to-end PW path using single sided provisioning initiated from > one end of the path. > > However, to establish and end-to-end path across multiple hops > requires a path to be calculated and selected (if multiple paths > exist) before the path can be signalled. Stitching PWs together to > from a path between two endpoints is effectively creating a new > layer network. Although targeted LDP has been proposed as the > signalling mechanism to signal individual PWs, there is no routing > at the PW layer to calculate/select an end-to-end path. > > Route/path calculation/selection is fairly simple for the > hierarchical LDP model using a centralised OSS approach, each MTUs > is connected to one PErs (except where dual homing is used), and > each PErs has a targeted LDP session with each other. Therefore, > if the OSS knows that MTUsX sits behind PErsX, and MTUsY sits > behind PErsY, then to establish a PW path between MTUsX and MTUsY > requires stitching/signalling of 3 PWs, i.e. MTUsX<->PErsX, > PErsX<->PErsY, and PErsY<->MTUsY. Obtaining information about > which MTUs devices sit behind which PErs devices is > straightforward in the OSS approach because the information is > gathered, maintained, and processed using a centralised mechanism. > Using a distributed approach however using dynamic protocols > requires reachability information to be distributed, at least > between the PErs devices, i.e. PErs devices need to advertise to > each other which MTUs devices they are connected to. As yet a > mechanism has not been defined to distribute this information, or > to select primary/secondary paths where MTUs devices are > multihomed. > > Du Ke has submitted a draft recently > () > to address LDP scaling that proposes a solution with two different > modes: > > i) A mode called 'simple trunk' that reflects LDP messages to > clients similar to the way in which BGP route reflectors > distribute routes to clients. This potentially could be used to > reduce the number of LDP sessions in an existing full mesh. > > ii) A mode called 'next hop self' that describes a solution for PW > stitching but does not scale as it relies on broadcasting labels > to every PErs in the full mesh for every VPWS/VPLS (the route of > the problem being that there is no routing functionality at the > 'PW layer' which the draft does not address). > > I would like to establish consensus as to whether a) a dynamic > protocol based end-to-end single sided provisioning solution is > required to aid scaling for stitched PWs, or if b) PW stitching is > best handled via OSS. > > Any comments/thoughts are welcomed. > > Thanks, > Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Vach Kompella" Subject: RE: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 21 Jul 2004 12:43:11 -0700 Organization: Alcatel USA Lines: 17 Sender: pwe3-bounces@ietf.org References: <200407211802.i6LI2RP9022454@rtp-core-2.cisco.com> Reply-To: vach.kompella@alcatel.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, pwe3@ietf.org, 'Luca Martini' , richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Thu Jul 22 00:51:36 2004 Return-path: To: , 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.1409 In-Reply-To: <200407211802.i6LI2RP9022454@rtp-core-2.cisco.com> Importance: Normal X-OriginalArrivalTime: 21 Jul 2004 19:43:12.0772 (UTC) FILETIME=[F560D440:01C46F5A] X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 uses LDP for the discovery. -Vach > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, July 21, 2004 12:02 PM > To: vach.kompella@alcatel.com > Cc: 'Luca Martini'; richard.spencer@bt.com; l2vpn@ietf.org; > pwe3@ietf.org > Subject: Re: [PWE3] Re: Scaling hierarchical LDP/PW stitching > > > Vach, how does your auto-discovery proposal differ from a > scheme which uses BGP for auto-discovery and then sets up > targeted LDP sessions based on the results of the auto-discovery? > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-satop-mib-01.txt Date: Wed, 21 Jul 2004 15:50:49 -0400 Lines: 98 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 Jul 22 01:38:26 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 : Managed Objects for Structure-Agnostic TDM over Packet Network Author(s) : O. Nicklass Filename : draft-ietf-pwe3-satop-mib-01.txt Pages : 20 Date : 2004-7-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for TDM (T1, E1, T3, E3) bit-streams circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-mib-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-satop-mib-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-satop-mib-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: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-tdm-mib-01.txt Date: Wed, 21 Jul 2004 15:50:58 -0400 Lines: 98 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 Jul 22 01:41:54 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 : Managed Objects for TDM over Packet Switched Network (PSN) Author(s) : O. Nicklass Filename : draft-ietf-pwe3-tdm-mib-01.txt Pages : 37 Date : 2004-7-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-mib-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-tdm-mib-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-tdm-mib-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: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-cesopsn-01.txt Date: Wed, 21 Jul 2004 15:51:27 -0400 Lines: 98 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 Jul 22 01:45:39 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 : Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) Author(s) : S. Vainshtein, et al. Filename : draft-ietf-pwe3-cesopsn-01.txt Pages : 28 Date : 2004-7-21 This document describes a method for encapsulating structured (NxDS0) TDM signals as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams [PWE3-SAToP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-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-cesopsn-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-cesopsn-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: Eric Rosen Subject: Re: Re: Scaling hierarchical LDP/PW stitching Date: Wed, 21 Jul 2004 21:42:22 -0400 Lines: 5 Sender: pwe3-bounces@ietf.org References: <049501c46f5a$f6021d50$0101010a@eng.timetra.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: l2vpn@ietf.org, pwe3@ietf.org, 'Luca Martini' , richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Thu Jul 22 03:57:12 2004 Return-path: X-BrightmailFiltered: true To: vach.kompella@alcatel.com In-reply-to: Your message of Wed, 21 Jul 2004 12:43:11 -0700. <049501c46f5a$f6021d50$0101010a@eng.timetra.com> 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: 7aefe408d50e9c7c47615841cb314bed 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 did realize that your proposal differs from a BGP-based solution in that it doesn't use BGP, the question is whether there are any other technical differences of note that might make it more or less preferable to a BGP-based solution. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: du.ke@zte.com.cn Subject: RE: Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Date: Thu, 22 Jul 2004 16:10:24 +0800 Lines: 46 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Thu Jul 22 10:23:00 2004 Return-path: To: richard.spencer@bt.com, pwe3@ietf.org 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-07-22 16:14:25 X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Excuse me, This mail is delayed too many time. I need time to study your advice, I think I have got very big inspire from your suggestion. MTUs4----PErs4--PErs3-----MTUs3 | \ / | | X | | / \ | MTUs1----PErs1--PErs2-----MTUs2 I'm agree with you, if we can find a way, in which source PE and reflector can send only one PW mapping toward the direction to target PE, i.e, PErs1 can know to send PW mapping to PErs2, but not send to PErs3 & PErs4, then the solution in dicussing will be more nice. we will improve our draft on this problem. Of cause, we can rely on OSS to get the next-hop-peer on the path to destination PE(MTUs2), but we want find a dynamic machine. As far as I am aware, many other protocol need (and work out) the way to know the nexthop NE to a special IP destination, such as DVMRP, PIM, RSVP-TE, and MSDP. I am willing to design a machine similar to MSDP(see http://www.ietf.org/rfc/rfc3618.txt) to find out peer to PW target peer. we can define the rule: PE and reflector send PW mapping only to peer if: 1) the peer is the target of PW mapping; 2) the peer is the eBGP NEXT_HOP to the target of PW mapping. (e.g., the peer is the e-BGP advertiser of the route for the target of PW mapping) 3) the peer is the is the IGP next hop for the target of PW mapping. 4) the peer resides in the closest AS in the best path towards the target of PW mapping. If multiple LDP peers reside in the closest AS, the peer with the highest IP address is the one that PW mapping should be sent. 5) the peer is configured as the static next-hop peer for the target of PW mapping. and, if no peer satisfies the request mentioned, the PW mapping should be sent to all reflector-neighbor. Regards, Du Ke From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "RAJESH SALUJA" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Wed, 21 Jul 2004 10:33:18 -0400 Lines: 306 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0704988308==" X-From: pwe3-bounces@ietf.org Thu Jul 22 15:34:14 2004 Return-path: To: "'richard.spencer@bt.com'" , pwe3@ietf.org, l2vpn@ietf.org, "'l3vpn@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e X-Mailman-Approved-At: Thu, 22 Jul 2004 09:23:10 -0400 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. --===============0704988308== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46F2F.AA570FF8" 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_01C46F2F.AA570FF8 Content-Type: text/plain I have a similar question about hybrid networks where from MTU, a PW starts and terminates at a PE router which uses L3VPN (2547) mechanism to reach remote PE. In this case also, what is the best interoperable way to stitch a PW to L3VPN endpoint. Is there any document which describes this mechanism? I believe that for your case also, a dynamic protocol is required otherwise provisioning will be nightmare. Thanks, Rajesh -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of richard.spencer@bt.com Sent: Wednesday, July 21, 2004 3:19 AM To: pwe3@ietf.org; l2vpn@ietf.org Subject: Scaling hierarchical LDP/PW stitching To address LDP scaling (and VPLS packet replication) a hierarchical LDP model is proposed (in draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs routers) are connected via a full mesh of LDP sessions, but spokes (PEr/MTUs routers) only establish LDP sessions with the hub(s) that they connect to. This reduces the number of LDP sessions required and also reduces the number of packet replications that hub (PErs) routers must perform. However, as yet I don't believe there are any drafts that discuss exactly how the hub and spoke PWs are signalled and stitched/bound together. Likewise for VPWS PW paths that are established by stitching multiple PWs together between endpoints. I believe this is an important area as one can imagine large service providers having hundreds of PErs routers connected via a full mesh of LDP sessions with tens of thousands of MTUs/PEr devices hanging off them. To support hundreds of thousands of PWs between tens of thousands of MTUs/PEr routers obviously requires a highly scalable provisioning solution. The example below shows an example of a hierarchical VPLS/VPWS network with 4 PErs devices each connected to a single MTUs device: MTUs4----PErs4--PErs3-----MTUs3 | \ / | | X | | / \ | MTUs1----PErs1--PErs2-----MTUs2 I assume that to provision a stitched VPWS PW path from MTUs1 to MTUs2, the individual PWs that form the path need to be established individually and then stitched together. Although the individual PWs can be established using single sided provisioning, the signalling for each PW must be initiated at one side for each PW either through manual configuration or via OSS. OSS (or some manual method) must also be used to keep track of and bind the different PWs together. To do this OSS needs to learn or be configured with information about which MTUs devices sit behind which PErs devices. For VPLS, the point-to-multipoint PWs between the hubs (PErs devices) can be provisioned using singled sided provisioning, but the spoke PWs need to be signalled and associated with the relevant VPLS separately. Again, the signalling needs to be initiated at one side and the spokes need to be associated with the correct VPLS via manual configuration or via OSS. The drawback with the above approach is that intermediate routers along the stitched PW path (i.e. PErs routers) must each be configured via OSS or via a manual method, and OSS must be also be used to bind and keep track of the individual PWs. The ideal solution would be to use a dynamic protocol(s) to establish the end-to-end PW path using single sided provisioning initiated from one end of the path. However, to establish and end-to-end path across multiple hops requires a path to be calculated and selected (if multiple paths exist) before the path can be signalled. Stitching PWs together to from a path between two endpoints is effectively creating a new layer network. Although targeted LDP has been proposed as the signalling mechanism to signal individual PWs, there is no routing at the PW layer to calculate/select an end-to-end path. Route/path calculation/selection is fairly simple for the hierarchical LDP model using a centralised OSS approach, each MTUs is connected to one PErs (except where dual homing is used), and each PErs has a targeted LDP session with each other. Therefore, if the OSS knows that MTUsX sits behind PErsX, and MTUsY sits behind PErsY, then to establish a PW path between MTUsX and MTUsY requires stitching/signalling of 3 PWs, i.e. MTUsX<->PErsX, PErsX<->PErsY, and PErsY<->MTUsY. Obtaining information about which MTUs devices sit behind which PErs devices is straightforward in the OSS approach because the information is gathered, maintained, and processed using a centralised mechanism. Using a distributed approach however using dynamic protocols requires reachability information to be distributed, at least between the PErs devices, i.e. PErs devices need to advertise to each other which MTUs devices they are connected to. As yet a mechanism has not been defined to distribute this information, or to select primary/secondary paths where MTUs devices are multihomed. Du Ke has submitted a draft recently () to address LDP scaling that proposes a solution with two different modes: i) A mode called 'simple trunk' that reflects LDP messages to clients similar to the way in which BGP route reflectors distribute routes to clients. This potentially could be used to reduce the number of LDP sessions in an existing full mesh. ii) A mode called 'next hop self' that describes a solution for PW stitching but does not scale as it relies on broadcasting labels to every PErs in the full mesh for every VPWS/VPLS (the route of the problem being that there is no routing functionality at the 'PW layer' which the draft does not address). I would like to establish consensus as to whether a) a dynamic protocol based end-to-end single sided provisioning solution is required to aid scaling for stitched PWs, or if b) PW stitching is best handled via OSS. Any comments/thoughts are welcomed. Thanks, Richard ------_=_NextPart_001_01C46F2F.AA570FF8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Scaling hierarchical LDP/PW stitching

I have a similar question about hybrid networks where = from MTU, a PW starts and terminates at a PE router which uses L3VPN = (2547) mechanism to reach remote PE. In this case also, what is the = best interoperable way to stitch a PW to L3VPN endpoint. Is there any = document which describes this mechanism?

I believe that for your case also, a dynamic protocol = is required otherwise provisioning will be nightmare.

Thanks,
Rajesh


-----Original Message-----
From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of richard.spencer@bt.com
Sent: Wednesday, July 21, 2004 3:19 AM
To: pwe3@ietf.org; l2vpn@ietf.org
Subject: Scaling hierarchical LDP/PW = stitching


To address LDP scaling (and VPLS packet replication) = a hierarchical LDP model is proposed (in = draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs routers) are = connected via a full mesh of LDP sessions, but spokes (PEr/MTUs = routers) only establish LDP sessions with the hub(s) that they connect = to. This reduces the number of LDP sessions required and also reduces = the number of packet replications that hub (PErs) routers must = perform.

However, as yet I don't believe there are any drafts = that discuss exactly how the hub and spoke PWs are signalled and = stitched/bound together. Likewise for VPWS PW paths that are = established by stitching multiple PWs together between endpoints. I = believe this is an important area as one can imagine large service = providers having hundreds of PErs routers connected via a full mesh of = LDP sessions with tens of thousands of MTUs/PEr devices hanging off = them. To support hundreds of thousands of PWs between tens of thousands = of MTUs/PEr routers obviously requires a highly scalable provisioning = solution.

The example below shows an example of a hierarchical = VPLS/VPWS network with 4 PErs devices each connected to a single MTUs = device:

MTUs4----PErs4--PErs3-----MTUs3
           = |  \ /  |
           = |   X   |
           = |  / \  |
MTUs1----PErs1--PErs2-----MTUs2
 
I assume that to provision a stitched VPWS PW path = from MTUs1 to MTUs2, the individual PWs that form the path need to be = established individually and then stitched together. Although the = individual PWs can be established using single sided provisioning, the = signalling for each PW must be initiated at one side for each PW either = through manual configuration or via OSS. OSS (or some manual method) = must also be used to keep track of and bind the different PWs together. = To do this OSS needs to learn or be configured with information about = which MTUs devices sit behind which PErs devices.

For VPLS, the point-to-multipoint PWs between the = hubs (PErs devices) can be provisioned using singled sided = provisioning, but the spoke PWs need to be signalled and associated = with the relevant VPLS separately. Again, the signalling needs to be = initiated at one side and the spokes need to be associated with the = correct VPLS via manual configuration or via OSS.

The drawback with the above approach is that = intermediate routers along the stitched PW path (i.e. PErs routers) = must each be configured via OSS or via a manual method, and OSS must be = also be used to bind and keep track of the individual PWs. The ideal = solution would be to use a dynamic protocol(s) to establish the = end-to-end PW path using single sided provisioning initiated from one = end of the path.

However, to establish and end-to-end path across = multiple hops requires a path to be calculated and selected (if = multiple paths exist) before the path can be signalled. Stitching PWs = together to from a path between two endpoints is effectively creating a = new layer network. Although targeted LDP has been proposed as the = signalling mechanism to signal individual PWs, there is no routing at = the PW layer to calculate/select an end-to-end path.

Route/path calculation/selection is fairly simple for = the hierarchical LDP model using a centralised OSS approach, each MTUs = is connected to one PErs (except where dual homing is used), and each = PErs has a targeted LDP session with each other. Therefore, if the OSS = knows that MTUsX sits behind PErsX, and MTUsY sits behind PErsY, then = to establish a PW path between MTUsX and MTUsY requires = stitching/signalling of 3 PWs, i.e. MTUsX<->PErsX, = PErsX<->PErsY, and PErsY<->MTUsY. Obtaining information = about which MTUs devices sit behind which PErs devices is = straightforward in the OSS approach because the information is = gathered, maintained, and processed using a centralised mechanism. = Using a distributed approach however using dynamic protocols requires = reachability information to be distributed, at least between the PErs = devices, i.e. PErs devices need to advertise to each other which MTUs = devices they are connected to. As yet a mechanism has not been defined = to distribute this information, or to select primary/secondary paths = where MTUs devices are multihomed.

Du Ke has submitted a draft recently (<http://www.ietf.org/internet-drafts/draft-yudong-pwe3-= control-protocol-ext-00.txt>) to address LDP scaling that = proposes a solution with two different modes:

i) A mode called 'simple trunk' that reflects LDP = messages to clients similar to the way in which BGP route reflectors = distribute routes to clients. This potentially could be used to reduce = the number of LDP sessions in an existing full mesh.

ii) A mode called 'next hop self' that describes a = solution for PW stitching but does not scale as it relies on = broadcasting labels to every PErs in the full mesh for every VPWS/VPLS = (the route of the problem being that there is no routing functionality = at the 'PW layer' which the draft does not address).

I would like to establish consensus as to whether a) = a dynamic protocol based end-to-end single sided provisioning solution = is required to aid scaling for stitched PWs, or if b) PW stitching is = best handled via OSS.

Any comments/thoughts are welcomed.

Thanks,
Richard

------_=_NextPart_001_01C46F2F.AA570FF8-- --===============0704988308== 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 --===============0704988308==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-tdmoip-02.txt Date: Thu, 22 Jul 2004 15:49:06 -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 Fri Jul 23 00:26:53 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 : TDM over IP Author(s) : Y. Stein, et al. Filename : draft-ietf-pwe3-tdmoip-02.txt Pages : 42 Date : 2004-7-22 This document describes methods for structure-aware transport of TDM traffic over packet switched networks using pseudowires. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-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-tdmoip-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-tdmoip-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: du.ke@zte.com.cn Subject: Re: Re: Scaling hierarchical LDP/PW stitching Date: Fri, 23 Jul 2004 14:43:36 +0800 Lines: 67 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: l2vpn@ietf.org, pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com X-From: pwe3-bounces@ietf.org Fri Jul 23 08:53:30 2004 Return-path: To: Luca Martini 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-07-23 14:49:19 X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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, At first, as a mewcomer on this forum, I must mean my warmest regards for you, Eric Rosen, Vach Kompella, and other active people in the pwe3 WG & l2vpn WG. I admire you for your creative work. But I don't consider it nonsensical to solve the problem of LDP scaling. Given a network, in which there are 20 or more PW PEs. If the provider has a alternate solution, no one is willing to maintain full mesh LDP session among all PEs. The more session, The more expensive and difficult for previder to maintain them. So we suggest that, a reflector can be intriduced in, every PE established session to the reflector, and avoid to establish session with each other. In other word, the problem of LDP scaling is issued not only by how many session LDP can support, but also by total LDP session in the network the previder must maintain. as far as PW stitching, or as you call it "switching", (see & , both published in Jul 14, 2004), I'm glad to see that there are many common ground between them. first, both two draft address Multi-hop PW(as you call it). i.e, two or more contiguous PW segments (SH-PW) that behave and function as a single point-to-point PW. although, the motives of the two draft's author are somedeal different. you want Multi-hop PW to come into play in two(three,this maybe a clerical error, Luca?) general cases: -i. When it is not possible, desirable or feasible to establish a PW control channel between the ultimate source and destination PEs. -ii. PWE3 signaling and encapsulation protocols are different. -iii. Where MPLS is deployed in the access network and User Facing Provider Devices (UFPE) do not have capability to maintain multiple End to End LDP sessions. and I, want to solve the problem of "full mesh PSN tunnel", I think it is a scaling-problem. in any case, they are all reasonable excuse to introduce Multi-hop PW in. On the other hand, these solution do not conflict at all. they can be deployed in one network. The only thing to be done is a consensus to be established, that the optional SPE-LSRID & TPE-LSRID TLV can be carrried by GID FEC Element and VCID FEC Element, then the provider can choose a Static or dynamical Multi-hop PW solution freely. After all, you will agree that a solution to dynamically configure Multi-hop PW should be found, your draft has implied such a solution may be discussed, you wrote: "Multi-hop PW (MH-PW). Static or dynamically configured set of two or more contiguous PW segments (SH-PW) that behave and function as a single point-to-point PW." although you hasn't discussed such a solution detailly, as you wrote: "The pseudowire switching methodology described in this document assumes manual configuration of the switching point at PE2. " we are working on such a solution, I'm expecting you and other friends on this forum to give me some advise, thanks. regards, Du Ke From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-control-protocol-08.txt - partial last call Date: Fri, 23 Jul 2004 12:01:10 +0100 Lines: 8 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Fri Jul 23 13:15:32 2004 Return-path: X-BrightmailFiltered: true 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: 68c8cc8a64a9d0402e43b8eee9fc4199 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 This is the start of last call for sections 5.2, 5.3, and 7 of Pseudowire Setup and Maintenance using LDP http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-08.txt Last call will end Monday 9th August 2004 - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: [Fwd: draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt] Date: Fri, 23 Jul 2004 13:44:10 +0100 Lines: 33 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 Fri Jul 23 15:09:34 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Last call has long expired and I have seen no comments. We will send this to the IESG. Stewart -------- Original Message -------- Subject: [PWE3] draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt Date: Fri, 21 May 2004 10:53:09 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. To: pwe3@ietf.org CC: Danny McPherson This the two week Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt Last Call will end Monday 7th June 2004 - 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: richard.spencer@bt.com Subject: RE: Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Date: Fri, 23 Jul 2004 14:10:00 +0100 Lines: 131 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 Fri Jul 23 15:23:31 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt Thread-Index: AcRvw3FldIGneMQpS+mt6IMNFSpWWwAArQaw To: , X-OriginalArrivalTime: 23 Jul 2004 13:10:00.0197 (UTC) FILETIME=[5BEF1350:01C470B6] X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 Du Ke, I welcome any thoughts/solutions on stitched/switched PW provisioning, = but think you going in the wrong direction by looking at MSDP. To get to the root of the problem I think its best to look at things = from a high-level functional perspective. Layer networks used as server = layers to support VPNs require two fundamental functional components: = routing and signalling, e.g. OSPF routing and LDP signalling for MPLS, = PNNI routing/signalling for ATM. In addition, they also need to support = multiplexing/de-multiplexing or tunnelling to separate one customers = traffic from another, and to bind a multiplexing field/tunnel to a VPN = instance a signalling/tunnelling protocol must be used. For example, L2 = MPLS VPNs use PWs for multiplexing with targeted LDP or BGP signalling, = ATM uses VPI/VCIs for multiplexing with PNNI signalling, and IP can use = IPsec tunnelling. The routing and signalling functions in the examples = above are performed by dynamic protocols, but equally they could be = performed using manual methods or OSS.=20 To ease provisioning, an auto-discovery function can be used to learn = remote VPN endpoints, e.g. BGP or RADIUS discovery for MPLS VPNs, and in = addition to routing in the server layer network, routing information can = also be distributed for the VPN client layer, e.g. MP-BGP is used to = distribute IP routing information for RFC2547 IP VPNs, and could also be = used to distribute ATM address information for ATM VPNs. PWs are one hop point-to-point flows that only exist between two = endpoints (PEs). They are supported by a server layer via what is = effectively a point-to-point link between two PEs (e.g. an MPLS = LDP/RSVP-TE tunnel LSP) and therefore can PWs in this case can be = thought of as an adaptation function, where the PW label just provides = VPN traffic separation across a point-to-point link.=20 Stitched/switched or multi-hop PWs (MH-PWs), as described in = draft-martini-pwe3-pw-switching-00.txt, on the other hand contain = multiple hops and do not just exist between two PEs. Using MH-PWs is = effectively creating a new 'PW' layer network containing multiple 'PW = aware' nodes with point-to-point links between them. As MH-PW contain = multiple hops, and a path/route must be calculated between the ingress = and egress PEs or ultimate PEs (U-PEs). The current draft describes how = the individual single-hop PWs (SH-PWs) are established and stitched = together at PW switching points(S-PEs), but this requires S-PEs to be = manually configured and route/path calculation between U-PEs must be = performed manually (or via OSS). The capability to provision MH-PWs = using single sided provisioning from one U-PE, in the same way that = SH-PWs can be provisioned from one PE would be the ideal solution from a = provisioning perspective. The reason being that OSS (or manual methods) = would not have to be used to configure intermediate routers (PW = stitching points), and calculate/keep track of MH-PW paths. MSDP will not address this issue as its purpose is to *discover* RPs = using a flooding mechanism. It relies on a routing protocol to populate = a multicast routing information base (MRIB) in order to determine what = RPF-peer is the next hop to reach the originating RP. Discovery is = already covered (e.g. BGP/LDP/RADIUS), its the routing function that is = missing. Regards, Richard > -----Original Message----- > From: du.ke@zte.com.cn [mailto:du.ke@zte.com.cn] > Sent: 22 July 2004 09:10 > To: Spencer,R,Richard,XGH5 R; pwe3@ietf.org > Subject: RE: [PWE3] Fwd: I-D > ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt >=20 >=20 > Richard >=20 > Excuse me, This mail is delayed too many time. > I need time to study your advice, I think I have got very big=20 > inspire from > your suggestion. >=20 > MTUs4----PErs4--PErs3-----MTUs3 > | \ / | > | X | > | / \ | > MTUs1----PErs1--PErs2-----MTUs2 >=20 > I'm agree with you, if we can find a way, in which source PE=20 > and reflector > can send only one PW mapping toward the direction to target=20 > PE, i.e, PErs1 > can know to send PW mapping to PErs2, but not send to PErs3 &=20 > PErs4, then > the solution in dicussing will be more nice. >=20 > we will improve our draft on this problem. >=20 > Of cause, we can rely on OSS to get the next-hop-peer on the path to > destination PE(MTUs2), but we want find a dynamic machine. >=20 > As far as I am aware, many other protocol need (and work out)=20 > the way to > know the nexthop NE to a special IP destination, such as DVMRP, PIM, > RSVP-TE, and MSDP. >=20 > I am willing to design a machine similar to MSDP(see > http://www.ietf.org/rfc/rfc3618.txt) to find out peer to PW=20 > target peer. > we can define the rule: > PE and reflector send PW mapping only to peer if: > 1) the peer is the target of PW mapping; > 2) the peer is the eBGP NEXT_HOP to the target of PW mapping.=20 > (e.g., the > peer is the e-BGP advertiser of the route for the target of=20 > PW mapping) > 3) the peer is the is the IGP next hop for the target of PW mapping. > 4) the peer resides in the closest AS in the best path=20 > towards the target > of PW mapping. If multiple LDP peers reside in the closest=20 > AS, the peer > with the highest IP address is the one that PW mapping should be sent. > 5) the peer is configured as the static next-hop peer for the=20 > target of PW > mapping. >=20 > and, if no peer satisfies the request mentioned, the PW=20 > mapping should be > sent to all reflector-neighbor. >=20 >=20 > Regards, > Du Ke >=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: Fri, 23 Jul 2004 16:45:19 +0100 Lines: 163 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 Fri Jul 23 17:58:50 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: Scaling hierarchical LDP/PW stitching Thread-Index: AcRwgLz4I4Kj0QzoRuazDd/IpFkPjAAM3uDQ To: , X-OriginalArrivalTime: 23 Jul 2004 15:45:20.0176 (UTC) FILETIME=[0F130300:01C470CC] X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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 Du Ke, Although routing is the function missing from the 'PW layer', in solving = the problem it will also be important to overcome the consequence of = access points (i.e. router loopback IP addresses) in the PW layer = network sharing the same address space as access points in the = server/tunnel layer network. To illustrate why this is an issue, please consider the example below: UPE1----SPE1----P1----P2----SPE2----UPE2 To set up a PW from UPE1 to UPE2 using single sided provisioning: 1. UPE1 needs to know the address of UPE2 (which it can learn via = discovery). 2. UPE1 needs to know what the next hop to reach UPE2 is. As UPE1 is = only connected to SPE1, the IGP will tell UPE1 that the next hop to = reach UPE2 is SPE1. This is fine as SPE1 is the next hop in the MH-PW to = reach UPE2.=20 3. UPE1 establishes a targeted LDP session with SPE1 (if it doesn't = already have one) and sends a label mapping message to SPE1. 4. SPE1 receives the label mapping message from UPE1 and needs to know = what the next hop to reach UPE2 is. This is where the problem lies, the = IGP next hop to reach UPE2 will be P1, but the MH-PW next hop should be = SPE2.=20 The P routers do not belong to the PW layer and therefore they should be = transparent to the PW layer network, i.e. the topology of the network at = the PW layer should be: UPE1----SPE1----SPE2----UPE2 One way to solve the problem might be to use IGP extensions (or a = separate mechanism) to distinguish between MH-PW capable routers (UPEs = and SPEs) and non MH-PW capable routers (P routers), in order to = populate a separate PW layer routing table (e.g. PWRIB) with routing = information that is only pertinent to the PW layer network. An = alternative solution that supports layer independence/separation might = be to use a second loopback address (a MH-PW address) on each MH-PW = capable router and a separate IGP instance to distribute PW layer = reachability information just to MH-PW capable routers and populate the = PWRIB. Whilst traditional IP networks are flat from a transport (or data plane) = perspective, the introduction of PW switching/stitching makes IP/MPLS a = multilayer network like SDH/SONET. Therefore, in solving the problem I = would encourage you to take a look at ITU-T recommendations G.805 and = G.809 which describe the functional architecture of = connection-orientated and connectionless networks respectively. Although = the terminology takes some getting used to, once you understand the = basic concepts/components these will prove to be invaluable in = developing an understanding the functional components and inter-layer = relationships of layer networks, as well being extremely important for = network management/inventory.=20 Regards, Richard > -----Original Message----- > From: du.ke@zte.com.cn [mailto:du.ke@zte.com.cn] > Sent: 23 July 2004 07:44 > To: Luca Martini > Cc: l2vpn@ietf.org; pwe3@ietf.org; pwe3-bounces@ietf.org; > Spencer,R,Richard,XGH5 R > Subject: Re: [PWE3] Re: Scaling hierarchical LDP/PW stitching >=20 >=20 >=20 > Luca, >=20 > At first, as a mewcomer on this forum, I must mean my warmest=20 > regards for > you, Eric Rosen, Vach Kompella, and other active people in=20 > the pwe3 WG & > l2vpn WG. I admire you for your creative work. >=20 > But I don't consider it nonsensical to solve the problem of=20 > LDP scaling. >=20 > Given a network, in which there are 20 or more PW PEs. If the=20 > provider has > a alternate solution, no one is willing to maintain full mesh=20 > LDP session > among all PEs. The more session, The more expensive and difficult for > previder to maintain them. > So we suggest that, a reflector can be intriduced in, every=20 > PE established > session to the reflector, and avoid to establish session with=20 > each other. >=20 > In other word, the problem of LDP scaling is issued not only=20 > by how many > session LDP can support, but also by total LDP session in the=20 > network the > previder must maintain. >=20 > as far as PW stitching, or as you call it "switching", (see > -protocol-ext-00.txt> >=20 > & > tching-00.txt>, >=20 > both published in Jul 14, 2004), I'm glad to see that there=20 > are many common > ground between them. >=20 > first, both two draft address Multi-hop PW(as you call it).=20 > i.e, two or > more contiguous PW segments (SH-PW) that behave and function=20 > as a single > point-to-point PW. although, the motives of the two draft's author are > somedeal different. > you want Multi-hop PW to come into play in two(three,this=20 > maybe a clerical > error, Luca?) general cases: > -i. When it is not possible, desirable or feasible to establish a PW > control channel between the ultimate source and destination PEs. > -ii. PWE3 signaling and encapsulation protocols are different. > -iii. Where MPLS is deployed in the access network and User Facing > Provider Devices (UFPE) do not have capability to maintain=20 > multiple End to > End LDP sessions. > and I, want to solve the problem of "full mesh PSN tunnel", I=20 > think it is a > scaling-problem. > in any case, they are all reasonable excuse to introduce=20 > Multi-hop PW in. >=20 > On the other hand, these solution do not conflict at all. they can be > deployed in one network. The only thing to be done is a=20 > consensus to be > established, that the optional SPE-LSRID & TPE-LSRID TLV can=20 > be carrried by > GID FEC Element and VCID FEC Element, then the provider can=20 > choose a Static > or dynamical Multi-hop PW solution freely. >=20 > After all, you will agree that a solution to dynamically configure > Multi-hop PW should be found, your draft has implied such a=20 > solution may be > discussed, > you wrote: > "Multi-hop PW (MH-PW). Static or dynamically configured set=20 > of two or more > contiguous PW segments (SH-PW) that behave and function as a single > point-to-point PW." > although you hasn't discussed such a solution detailly, as you wrote: > "The pseudowire switching methodology described in this=20 > document assumes > manual configuration of the switching point at PE2. " >=20 > we are working on such a solution, I'm expecting you and=20 > other friends on > this forum to give me some advise, thanks. >=20 > regards, > Du Ke >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-vccv-03.txt - Last Call Date: Fri, 23 Jul 2004 16:47:29 +0100 Lines: 160 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010404020405040704030200" X-From: pwe3-bounces@ietf.org Fri Jul 23 18:01:13 2004 Return-path: X-BrightmailFiltered: true 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: 200d029292fbb60d25b263122ced50fc 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. --------------010404020405040704030200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is the start of 2 week last call on draft-ietf-pwe3-vccv-03.txt Last call will finish Monday 9th August - Stewart 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 : Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) Author(s) : T. Nadeau, R. Aggarwal Filename : draft-ietf-pwe3-vccv-03.txt Pages : 16 Date : 2004-6-30 This document describes Virtual Circuit Connection Verification (VCCV) procedures for use with psuedowire connections. VCCV supports connection verification applications for pseudowire VCs regardless of the underlying MPLS or IP tunnel technology. VCCV makes use of IP based protocols such as Ping and MPLS-Ping to perform operations and maintenance functions. A network operator may use the VCCV procedures to test the network's forwarding plane liveliness. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-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-vccv-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-vccv-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. ------------------------------------------------------------------------- In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. ------------------------------------------------------------------------- For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: i5UKStgI003056 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc --------------010404020405040704030200 Content-Type: text/plain; name="file:///D|/DOCUME%7E1/STBRYANT/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///D|/DOCUME%7E1/STBRYANT/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------010404020405040704030200 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 --------------010404020405040704030200-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: The SAToP -01 MIB draft Date: Sun, 25 Jul 2004 13:31:22 +0200 Lines: 19 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: "PWE3 WG \(E-mail\)" X-From: pwe3-bounces@ietf.org Sun Jul 25 12:37:59 2004 Return-path: To: "Orly Niklass (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Orly and all, I have received announcement of draft-ietf-pwe3-satop-mib-01.txt, being posted, but the draft does not apear at the IETF Web site, and the pointer in the PWE3 WG page leads to a message "The draft you are looking for cannot be found". Since the draft that has been posted a few days ago should not expire, I believe this is an IETF Web site problem, hopefully to be fixed soon. Meanwhile, can you provide a pointer to some alternative location for this draft? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Orly Nicklass" Subject: RE: The SAToP -01 MIB draft Date: Sun, 25 Jul 2004 16:01:27 +0300 Lines: 33 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "PWE3 WG \(E-mail\)" , Sasha Vainshtein X-From: pwe3-bounces@ietf.org Sun Jul 25 15:05:06 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: The SAToP -01 MIB draft Thread-Index: AcRyMuhiyRnSaDb9Qi6kPv6JU6YANwAFFqkQ To: "Yaakov Stein" X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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, Can you post it where you put yours in such cases? If yes, I will send it to you. Thanks Orly -----Original Message----- From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 Sent: Sunday, July 25, 2004 14:31 To: Orly Nicklass Cc: PWE3 WG (E-mail) Subject: The SAToP -01 MIB draft Orly and all, I have received announcement of draft-ietf-pwe3-satop-mib-01.txt, being posted, but the draft does not apear at the IETF Web site, and the pointer in the PWE3 WG page leads to a message "The draft you are looking for cannot be found". Since the draft that has been posted a few days ago should not expire, I believe this is an IETF Web site problem, hopefully to be fixed soon. Meanwhile, can you provide a pointer to some alternative location for this draft? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: The SAToP -01 MIB draft Date: Sun, 25 Jul 2004 17:19:11 +0300 Lines: 51 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "PWE3 WG \(E-mail\)" , Sasha Vainshtein X-From: pwe3-bounces@ietf.org Sun Jul 25 16:27:55 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: The SAToP -01 MIB draft Thread-Index: AcRyMuhiyRnSaDb9Qi6kPv6JU6YANwAFFqkQAALC8WA= To: "Orly Nicklass" X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Interesting - http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-mib-01.txt appears but SAToP doesn't. Y(J)S=20 > -----Original Message----- > From: Orly Nicklass=20 > Sent: Sunday, July 25, 2004 16:01 > To: Yaakov Stein > Cc: PWE3 WG (E-mail); Sasha Vainshtein > Subject: RE: The SAToP -01 MIB draft >=20 > Yaakov, >=20 > Can you post it where you put yours in such cases? If yes, I=20 > will send it to you. > Thanks > Orly >=20 > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Sunday, July 25, 2004 14:31 > To: Orly Nicklass > Cc: PWE3 WG (E-mail) > Subject: The SAToP -01 MIB draft >=20 > Orly and all, >=20 > I have received announcement of=20 > draft-ietf-pwe3-satop-mib-01.txt, being posted, but the draft=20 > does not apear at the IETF Web site, and the pointer in the=20 > PWE3 WG page leads to a message "The draft you are looking=20 > for cannot be found". >=20 > Since the draft that has been posted a few days ago should=20 > not expire, I believe this is an IETF Web site problem,=20 > hopefully to be fixed soon. >=20 > Meanwhile, can you provide a pointer to some alternative=20 > location for this draft? >=20 > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) >=20 >=20 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: Sun, 25 Jul 2004 15:53:41 -0400 Lines: 141 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-bounces@ietf.org Sun Jul 25 21:56:10 2004 Return-path: To: "'richard.spencer@bt.com'" , pwe3@ietf.org, l2vpn@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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, I am glad you took the initiative to discuss the architectural aspects of PW stitching. With several recent drafts that address this issue, it is the right time to look at the fundamentals. I think we need to look at this problem from a slightly different perspective. One of the fundamental misconceptions is that there is anything special about nodes the form the intermediate hops in a multi-hop PW. Stitching PWs is nothing more than PW label switching and every LSR is capable of doing that. 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? It is important to realize than any LSP could be considered a MH-PW. In one of your emails you show the following scenario: UPE1----SPE1----P1----P2----SPE2----UPE2 Suppose an MH-PW is established that consists of five segments: UPE1-SPE1, SPE1 - P1, P1 - P2, etc. Since on each link the PW segment is established between adjacent nodes, there is no need to add an additional label on top of the PW label (see e.g. section 2 of the control draft). Hence, the MH-PW is just a regular LSP between UPE1 and UPE2. From a scaleability perspective it may make sense to tunnel all PWs that pass through SPE1 and SPE2 through a Transport LSP that connects those two nodes, but whether to do that or not should be based on operator policies. The problem with this argument is that it may be true from a data plane perspective, but that it doesn't work from a control plane perspective. After all, in the data plane, a MH-capable router does nothing more than PW label switching, but in the control plane it has to tie together two targeted LSP sessions, or does it? IMO, the appropriate conclusion is that Targeted LDP is really not the right tool to set up MH PWs. Draft-raggarwa-rsvpte-pw-00.txt describes how RSVP-TE can be used to set up MH-PWs. It is totally straightforward. The only thing different from regular RSVP is a TLV that is used by the PW end-points to identify the PW. (The current draft only shows PW-id, but a subsequent draft will include GID as well.) I realize that the introduction of RSVP-TE for PW set up is a departure from earlier decisions to use LDP. However, if you compare it with the alternatives, I think it is clear that this the way to go. draft-yudong-pwe3-control-protocol-ext-00.txt recognizes that intermediate hops need the LSP ids of the two PW end points. It also recognizes that in some cases there may be a need to carry the address of an intermediate hop. This contribution essentially recreates CR-LDP, but with a new and incomplete form of Explicit Route Object. CR-LDP would obviously be equivalent to using RSVP-TE for MH-PW setup, but since the decision has been made to abondon CR-LDP, RSVP-TE is the better choice at this point in time. draft-martini-pwe3-pw-switching-00.txt remains closer to the control draft. It sticks with targeted LDP. The problem is, as you wrote in an earlier email, that this mechanism seems to rely on manual provisioning by the operator. Another problem, IMO, is that it leads to proliferation of PW-specific identifiers (AGI and AII) throughput the network. Therefore, it turns the PW switching Points in specialized nodes that need to deal with non-routable identifiers. Architecturally, that is not the way to go. Just to be clear: draft-martini-pwe3-pw-switching-00.txt contains information that is useful and that should become part of PW switching standards. E.g. if a provider would want to mix and match L2TP-based PWs with MPLS-based PWs, there is a need for the procedures defined in the draft. However, I believe that there is a need for only a few of such L2TP-MPLS interworking nodes. We should not accept a definition MH-PWs that assumes that this is functionality that is required in each and every PW Switching point. And we should not accept a signaling protocol for MH-PW setup that uses non-routable identifiers. Peter > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: Wednesday, July 21, 2004 3:19 AM > To: pwe3@ietf.org; l2vpn@ietf.org > Subject: [PWE3] Scaling hierarchical LDP/PW stitching > > > To address LDP scaling (and VPLS packet replication) a > hierarchical LDP model is proposed (in > draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs routers) > are connected via a full mesh of LDP sessions, but spokes > (PEr/MTUs routers) only establish LDP sessions with the > hub(s) that they connect to. This reduces the number of LDP > sessions required and also reduces the number of packet > replications that hub (PErs) routers must perform. > > However, as yet I don't believe there are any drafts that > discuss exactly how the hub and spoke PWs are signalled and > stitched/bound together. Likewise for VPWS PW paths that are > established by stitching multiple PWs together between > endpoints. I believe this is an important area as one can > imagine large service providers having hundreds of PErs > routers connected via a full mesh of LDP sessions with tens > of thousands of MTUs/PEr devices hanging off them. To support > hundreds of thousands of PWs between tens of thousands of > MTUs/PEr routers obviously requires a highly scalable > provisioning solution. > > The example below shows an example of a hierarchical > VPLS/VPWS network with 4 PErs devices each connected to a > single MTUs device: > > MTUs4----PErs4--PErs3-----MTUs3 > | \ / | > | X | > | / \ | > MTUs1----PErs1--PErs2-----MTUs2 > > I assume that to provision a stitched VPWS PW path from MTUs1 > to MTUs2, the individual PWs that form the path need to be > established individually and then stitched together. Although > the individual PWs can be established using single sided > provisioning, the signalling for each PW must be initiated at > one side for each PW either through manual configuration or > via OSS. OSS (or some manual method) must also be used to > keep track of and bind the different PWs together. To do this > OSS needs to learn or be configured with information about > which MTUs devices sit behind which PErs devices. > > For VPLS, the point-to-multipoint PWs between the hubs (PErs > devices) can be provisioned using singled sided provisioning, > but the spoke PWs need to be signalled and associated with > the relevant VPLS separately. Again, the signalling needs to > be initiated at one side and the spokes need to be associated > with the correct VPLS via manual configuration or via OSS. > > The drawback with the above approach is that intermediate > routers along the stitched PW path (i.e. PErs routers) must > each be configured via OSS or via a manual method, and OSS > must be also be used to bind and keep track of the individual > PWs. The ideal solution would be to use a dynamic protocol(s) > to establish the end-to-end PW path using single sided > provisioning initiated from one end of the path. > > However, to establish and end-to-end path across multiple > hops requires a path to be calculated and selected (if > multiple paths exist) before the path can be signalled. > Stitching PWs together to from a path between two endpoints > is effectively creating a new layer network. Although > targeted LDP has been proposed as the signalling mechanism to > signal individual PWs, there is no routing at the PW layer to > calculate/select an end-to-end path. > > Route/path calculation/selection is fairly simple for the > hierarchical LDP model using a centralised OSS approach, each > MTUs is connected to one PErs (except where dual homing is > used), and each PErs has a targeted LDP session with each > other. Therefore, if the OSS knows that MTUsX sits behind > PErsX, and MTUsY sits behind PErsY, then to establish a PW > path between MTUsX and MTUsY requires stitching/signalling of > 3 PWs, i.e. MTUsX<->PErsX, PErsX<->PErsY, and PErsY<->MTUsY. > Obtaining information about which MTUs devices sit behind > which PErs devices is straightforward in the OSS approach > because the information is gathered, maintained, and > processed using a centralised mechanism. Using a distributed > approach however using dynamic protocols requires > reachability information to be distributed, at least between > the PErs devices, i.e. PErs devices need to advertise to each > other which MTUs devices they are connected to. As yet a > mechanism has not been defined to distribute this > information, or to select primary/secondary paths where MTUs > devices are multihomed. > > Du Ke has submitted a draft recently > () to address LDP scaling that proposes a solution with two different modes: i) A mode called 'simple trunk' that reflects LDP messages to clients similar to the way in which BGP route reflectors distribute routes to clients. This potentially could be used to reduce the number of LDP sessions in an existing full mesh. ii) A mode called 'next hop self' that describes a solution for PW stitching but does not scale as it relies on broadcasting labels to every PErs in the full mesh for every VPWS/VPLS (the route of the problem being that there is no routing functionality at the 'PW layer' which the draft does not address). I would like to establish consensus as to whether a) a dynamic protocol based end-to-end single sided provisioning solution is required to aid scaling for stitched PWs, or if b) PW stitching is best handled via OSS. Any comments/thoughts are welcomed. Thanks, 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: Danny McPherson Subject: PWE3 Moved to Internet Area Date: Sun, 25 Jul 2004 23:05:57 -0600 Lines: 13 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 Cc: margaret@thingmagic.com, Thomas Narten , Stewart Bryant X-From: pwe3-bounces@ietf.org Mon Jul 26 07:07:56 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.618) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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, Subject says it all. The PWE3 WG has officially been relocated to the Internet Area. Thomas Narten & Margaret Wasserman are our new ADs, Thomas is our Area Advisor. The IETF web pages already reflect the change, and the move should be mostly transparent given that Thomas has been quite involved in assisting the WG for quite some time - a tidbit with which many of you are intimately familiar :-) -danny & stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Danny McPherson Subject: PWE3 @IETF 60 - DRAFT AGENDA Date: Mon, 26 Jul 2004 00:17:28 -0600 Lines: 110 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 Mon Jul 26 08:21:43 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.618) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Draft Agenda for PWE3 WG meeting at IETF 60. Please pass along corrections and comments ASAP. As usual, look for presentations and updated agenda data to be available at the following URL: http://pwe3.tcb.net/meetings/ietf60 Thanks! -danny & stewart [snip] Pseudo Wire Emulation Edge to Edge (pwe3) ========================================= MONDAY, August 2, 2004 (1530-1730) CHAIR: "Danny McPherson" "Stewart Bryant" AGENDA: 5 min Administrivia Chairs (Stewart & Danny) Agenda Bashing Minutes Blue Sheets 10 min WG Document Status & Charter Update Danny McPherson Stewart Bryant 5 min PW Control Word & MPLS BCP Stewart Bryant & Danny McPherson http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw -00.txt Discussion: PW Control Word Draft and request to make WG doc. 10 min PWE3 OAM Message Map Thomas D. Nadeau http://www.ietf.org/internet-drafts/ draft-ietf-pwe3-oam-msg-map-00 Discussion: *** 5 min ITU-T Update Thomas Walsh Discussion: ITU-T approves X.84 Frame Relay Service over MPLS based on PWE3 work. Also, sent liaison to PWE3. 10 min RSVP-TE for Multi-hop PWs Rahul Aggarwal http://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-00.txt Discussion: The draft explains how RSVP-TE can be used for setting up multi-hop PWs with QoS. Its directly applicable to PWE3. Hence the request for the slot. The intention would be to introduce the concept and have a discussion on this. 10 min PW Switching (Inter-provider/AS PWs) Luca Martini http://www.ietf.org/internet-drafts/draft-martini-pwe3-pw-switching -00.txt Discussion: PW switching ID. Draft describes how to switch pseudo wires (PW) between two distinct control planes or PSN domains. The PW control planes may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. 10 min PWE3 QOS Signaling Himanshu Shah http://www.ietf.org/internet-drafts/draft-shah-pwe3-qos-signaling -00.txt Discussion: Plan to discuss the requirement, the mechanism and applicability (such as congestion avoidence) for QOS signagling over Pseudowire. I may discuss how proposed mechanism contrasts with other alternatives. 10 min Dry-Martini Ping Pan http://www.ietf.org/internet-drafts/draft-pan-pwe3-over-sub-ip-00.txt Discussion: *** 15 min CESoPSN and WG LC (10 mins) Sasha Vainshtein http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-01.txt Discussion: Summary and proposed resolution of open issues following the CESoPSN WG LC. TDM Extensions to PWE3 (5 mins) http://www.ietf.org/internet-drafts/draft-vainshtein-pwe3-tdm-control- protocol-extensi-01.txt Discussion: Update on the TDM Extensions to the PWE3 control protocol. Would like to ask WG to make WG item. 15 min TDMoIP Updates (10 mins) Yaakov Stein http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-02.txt Discussion: TDMoIP Updates, including use of flags and OAM/VCCV PWE3 and UDP/IP Issues (5 mins) http://www.ietf.org/internet-drafts/draft-stein-pwe3-udp-00.txt Discussion: *** 5 min IP Pseudowire Encapsulation Florin Balus http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt Discussion: *** 10 min Wrap-up Chairs From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: du.ke@zte.com.cn Subject: =?gb2312?B?tPC4tDogUkU6IFtQV0UzXSBTY2FsaW5nIGhpZXJhcmNoaWNhbCBMRFAvUFc=?= stitching Date: Mon, 26 Jul 2004 14:43:12 +0800 Lines: 278 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1018733086==" Cc: l2vpn@ietf.org, pwe3-bounces@ietf.org, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Mon Jul 26 09:06:15 2004 Return-path: To: "Busschbach, Peter B (Peter)" 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-07-26 15:04:59 X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 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 --===============1018733086== Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 DQpJIGFncmVlIHdpdGggUmljaGFyZCB3aXRoIHRoZSB0ZXJtICJQVyBsYXllciBuZXR3b3JrIi4N CkkgdGhpbmssIHdoaWNoIFJpY2hhcmQgY2xhaW1lZCBpcyB0aGF0LCBQVyBsYXllciBuZXR3b3Jr IGlzIGEgb3ZlcmxheQ0KbmV0d29yayBvdmVyIElQIG5ldHdvcmssIGFuZCBpdCBoYXMgaXRzIG93 biByb3V0aW5nIGluZm9ybWF0aW9uIGFuZA0KdG9wb2xvZ3kuDQoNClRvIGlsbHVzdHJhdGUgd2h5 IHRoaXMgaXMgYW4gaXNzdWUsIHBsZWFzZSBjb25zaWRlciB0aGUgZXhhbXBsZSBiZWxvdzoNClVQ RTEtLS0tU1BFMS0tLS1QMS0tLS1QMi0tLS1TUEUyLS0tLVVQRTINClRoaXMgaXMgYSBJUCBsYXll ciB0b3BvbG9neSBvZiBuZXR3b3JrLiBJbiB0aGlzIG5ldHdvcmssIFVQRTEgJiBVUEUyIGFyZQ0K dWx0aW1hdGUgUEVzIHdoZXJlIHRoZSBjdXN0b21lci1mYWNpbmcgQUNzIGFyZSBib3VuZCB0byBh IFBXIGZvcndhcmRlci4NClNQRTEgJiBTUEUyIGFyZSBQVyBTd2l0Y2hpbmcgUG9pbnRzIHdoZXJl IHR3byBQVyBzZWdtZW50cyBhcmUgYm91bmQNCnRvZ2V0aGVyLiBhbmQgUDEgJiBQMiBhcmUgY29t bW9uIExTUiwgd2hpY2ggaGF2ZSBubyBzZW5zZSBvZiB0aGUNCmVzdGFibGlzaGluZy9leGlzdGlu ZyBvZiBQV3MsIGFuZCBwYXJ0aWNpcGF0ZSBvbmx5IGluIHRoZSBQU04gdHVubmVsDQpiZXR3ZWVu IFNQRTEgYW5kIFNQRTIuIFNvIFAxICYgUDIgcm91dGVycyBkbyBub3QgYmVsb25nIHRvIHRoZSBQ VyBsYXllciBhbmQNCnRoZXJlZm9yZSB0aGV5IHNob3VsZCBiZSB0cmFuc3BhcmVudCB0byB0aGUg UFcgbGF5ZXIgbmV0d29yay4NClRoZSB0b3BvbG9neSBvZiBvdmVybGF5IG5ldHdvcmsoUFcgbGF5 ZXIgbmV0d29yaykgaXM6DQpVUEUxLS0tLS0tLS0tLS0tLS0tLS1TUEUxLS0tLS0tLS0tLS0tLS0t LS1TUEUyLS0tLS0tLS0tLS0tLS0tLS1VUEUyDQogICAgIChQU04gdHVubmVsIC0xKSAgICAgIChQ U04gdHVubmVsIC0yKSAgICAgIChQU04gdHVubmVsIC0zKQ0KDQpSaWNoYXJkIHN1Z2dlc3RzIHRo YXQsIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGJhc2Ugb2YgdGhlIG92ZXJsYXkgbmV0d29yaywN CmksZS4gYSBzZXBhcmF0ZSBQVyBsYXllciByb3V0aW5nIHRhYmxlIChQV1JJQikgd2l0aCByb3V0 aW5nIGluZm9ybWF0aW9uDQp0aGF0IGlzIG9ubHkgcGVydGluZW50IHRvIHRoZSBQVyBsYXllciBu ZXR3b3JrLCBzaG91bGQgYmUgbWFpbnRhaW5lZC4NCg0KVGhpcyByb3V0aW5nIGluZm9ybWF0aW9u IGJhc2UgKFBXUklCKSBhcmUgaW1wb3J0YW50IHRvIGV2ZXJ5IHNpbmdsZSBzaWRlZA0Kc2lnbmFs aW5nIHByb3RvY29sIGZvciBNSC1QVyBzZXR1cC4NCg0KQXMgUlNWUC1URSBmb3IgTUgtUFcgc2V0 dXAgaXMgY29uc2lkZXJlZChhcyBQZXRlciBzdWdnZXN0ZWQpLCBVUEUxIHNob3VsZA0Ka25vdyB0 aGUgcGF0aCBmcm9tIFVQRTEgdG8gVVBFMiwgd2hpY2ggY2FuIGJlIGdldCBmcm9tIFBXUklCLiAo T2YgY2F1c2UsDQp3aGV0aGVyIHdlIHNob3VsZCB1c2UgUlNWUC1URSBhcyBwcm90b2NvbCB0byBz ZXR1cCBhbmQgbWFpbnRhaW4gUEUgaXMgYW4NCm90aGVyIHF1ZXN0aW9uLCBJJ2xsIGRpc2N1c3Mg aXQgaW4gYW4gb3RoZXIgbWFpbC4pDQoNCkluIGZhY3QsIFBXUklCIGNhbiBiZSBtYWludGFpbmVk IGluIHNldmVyYWwgc3R5bGUuDQpTdWNoIGFzLCBpdCBjYW4gYmUgbWFpbnRhaW5lZCBpbiBhIGNl bnRyYWxpemVkIGF1dG9kaXNjb3ZlcnkvcmFkaXVzIHNlcnZlcg0Kb3IgT1NTLCBXaGVuIFVQRTEg bGF1bmNoZXMgdG8gZXN0YWJsaXNoIHRoZSBQVyB0byBVUEUyLCBpdCBzZW5kIGENCiJyZWdpc3Rl ciIgbWVzc2FnZSBmb3IgdGhlIEZFQyB0byB0aGUgZGlzY292ZXJ5IHNlcnZlciBhbmQgcmVjZWl2 ZSBhDQpleHBsaWNpdCByb3V0ZSBpbmZvcm1hdGlvbiwgdGhlbiBpdCBjYW4gc2VuZCBwYXRoIG1l c3NhZ2UgdG8gVVBFMiBvciBQVw0KTGFiZWwgbWFwcGluZyB0byBTUEUxLg0KT3IsIFBXUklCIGNh biBiZSBtYWl0YWluZWQgYnkgVVBFcyAmIFNQRXMgd2l0aCBhIGRpc3RyaWJ1dGVkIHN0eWxlLCB1 c2luZw0KYW4gSUdQIGV4dGVuc2lvbihzKSAob3IgYSBzZXBhcmF0ZSBtZWNoYW5pc20pIG9yIGEg c2VwYXJhdGUgSUdQIGluc3RhbmNlLg0KVGhlbiBVUEUxIGtub3dzIHRvIHNlbmQgbWFwcGluZywg d2hvc2UgdGFyZ2V0IFBFIGlzIFVQRTIsIHRvIFNQRTEuIGFuZCBTUEUxDQprbm93cyB0byBmb3J3 YXJkIHRoZSBtYXBwaW5nIHRvIFNQRTIsIGFuZCBzbyBvbi4NCk9yLCBQV1JJQiBjYW4gYmUgbWFp bnRhaW5lZCBpbiB0aGUgYnJhaW4gb2Ygb3BlcmF0b3IsIHdoaWxzdCwgdGhlIFVQRXMgJg0KU1BF cyBhcmUgbWFudWFsbHkgY29uZmlndXJhdGVkLg0KDQoNCg0KDQpSZWdhcmQsDQpEdSBLZQ0KPi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uFg0KPkFkZDogICBO by42OCBaaWppbmdodWEgUmQsWXVodWF0YWkgRGlzdHJpY3QsDQo+ICAgICAgICBOYW5qaW5nLiBQ LlIuQ2hpbmEuDQo+WmlwOiAgIDIxMDAxMg0KPlRlbDogICAwMDg2LTI1LTUyODcxODA5DQo+RmF4 OiAgIDAwODYtMjUtNTI4NzEwMDANCj5NYWlsOiAgZHUua2VAenRlLmNvbS5jbg0KPi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLg0KDQoNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgIkJ1c3NjaGJhY2gsICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICBQ ZXRlciBCIChQZXRlcikiICAgICAgICAgytW8/sjLo7ogICIncmljaGFyZC5zcGVuY2VyQGJ0LmNv bSciIDxyaWNoYXJkLnNwZW5jZXJAYnQuY29tPiwgcHdlM0BpZXRmLm9yZywgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgIDxidXNzY2hiYWNoQGx1Y2VuICAgICAgICAgbDJ2cG5AaWV0 Zi5vcmcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgdC5jb20+ICAgICAg ICAgICAgICAgICAgILOty82juiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAg ICAgICAgICAgICC3orz+yMujuiAgICAgICAgICAgICAgICAg1vfM4qO6ICAgIFJFOiBbUFdFM10g U2NhbGluZyBoaWVyYXJjaGljYWwgTERQL1BXIHN0aXRjaGluZyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIHB3ZTMtYm91bmNlc0BpZXRmICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg Lm9yZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgICAgMjAwNC0wNy0yNiAwMzo1MyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KDQoNClJpY2hhcmQsDQoNCkkgYW0gZ2xhZCB5b3UgdG9vayB0aGUgaW5pdGlhdGl2ZSB0 byBkaXNjdXNzIHRoZSBhcmNoaXRlY3R1cmFsIGFzcGVjdHMgb2YNClBXIHN0aXRjaGluZy4gV2l0 aCBzZXZlcmFsIHJlY2VudCBkcmFmdHMgdGhhdCBhZGRyZXNzIHRoaXMgaXNzdWUsIGl0IGlzIHRo ZQ0KcmlnaHQgdGltZSB0byBsb29rIGF0IHRoZSBmdW5kYW1lbnRhbHMuDQoNCkkgdGhpbmsgd2Ug bmVlZCB0byBsb29rIGF0IHRoaXMgcHJvYmxlbSBmcm9tIGEgc2xpZ2h0bHkgZGlmZmVyZW50DQpw ZXJzcGVjdGl2ZS4gT25lIG9mIHRoZSBmdW5kYW1lbnRhbCBtaXNjb25jZXB0aW9ucyBpcyB0aGF0 IHRoZXJlIGlzDQphbnl0aGluZyBzcGVjaWFsIGFib3V0IG5vZGVzIHRoZSBmb3JtIHRoZSBpbnRl cm1lZGlhdGUgaG9wcyBpbiBhIG11bHRpLWhvcA0KUFcuIFN0aXRjaGluZyBQV3MgaXMgbm90aGlu ZyBtb3JlIHRoYW4gUFcgbGFiZWwgc3dpdGNoaW5nIGFuZCBldmVyeSBMU1IgaXMNCmNhcGFibGUg b2YgZG9pbmcgdGhhdC4gVGhlIHF1ZXN0aW9uIGlzIHRoZXJlZm9yZSBub3Q6IHdoYXQgcm91dGlu Zw0KcHJvdG9jb2xzIGRvIHdlIG5lZWQgdG8gZmluZCBtdWx0aS1ob3AgY2FwYWJsZSByb3V0ZXJz PzsgYnV0OiB3aGF0IGFyZSB0aGUNCnBvbGljaWVzIHRoYXQgZHJpdmUgYW4gTFNSIHRvIGJ1bmRs ZSBtdWx0aXBsZSBQVy1MU1BzIGludG8gYSBzaW5nbGUNCnRyYW5zcG9ydCBMU1A/DQoNCkl0IGlz IGltcG9ydGFudCB0byByZWFsaXplIHRoYW4gYW55IExTUCBjb3VsZCBiZSBjb25zaWRlcmVkIGEg TUgtUFcuIEluIG9uZQ0Kb2YgeW91ciBlbWFpbHMgeW91IHNob3cgdGhlIGZvbGxvd2luZyBzY2Vu YXJpbzoNCg0KVVBFMS0tLS1TUEUxLS0tLVAxLS0tLVAyLS0tLVNQRTItLS0tVVBFMg0KDQpTdXBw b3NlIGFuIE1ILVBXIGlzIGVzdGFibGlzaGVkIHRoYXQgY29uc2lzdHMgb2YgZml2ZSBzZWdtZW50 czogVVBFMS1TUEUxLA0KU1BFMSAtIFAxLCBQMSAtIFAyLCBldGMuIFNpbmNlIG9uIGVhY2ggbGlu ayB0aGUgUFcgc2VnbWVudCBpcyBlc3RhYmxpc2hlZA0KYmV0d2VlbiBhZGphY2VudCBub2Rlcywg dGhlcmUgaXMgbm8gbmVlZCB0byBhZGQgYW4gYWRkaXRpb25hbCBsYWJlbCBvbiB0b3ANCm9mIHRo ZSBQVyBsYWJlbCAoc2VlIGUuZy4gc2VjdGlvbiAyIG9mIHRoZSBjb250cm9sIGRyYWZ0KS4gSGVu Y2UsIHRoZSBNSC1QVw0KaXMganVzdCBhIHJlZ3VsYXIgTFNQIGJldHdlZW4gVVBFMSBhbmQgVVBF Mi4gRnJvbSBhIHNjYWxlYWJpbGl0eQ0KcGVyc3BlY3RpdmUgaXQgbWF5IG1ha2Ugc2Vuc2UgdG8g dHVubmVsIGFsbCBQV3MgdGhhdCBwYXNzIHRocm91Z2ggU1BFMSBhbmQNClNQRTIgdGhyb3VnaCBh IFRyYW5zcG9ydCBMU1AgdGhhdCBjb25uZWN0cyB0aG9zZSB0d28gbm9kZXMsIGJ1dCAgd2hldGhl ciB0bw0KZG8gdGhhdCBvciBub3Qgc2hvdWxkIGJlIGJhc2VkIG9uIG9wZXJhdG9yIHBvbGljaWVz Lg0KDQpUaGUgcHJvYmxlbSB3aXRoIHRoaXMgYXJndW1lbnQgaXMgdGhhdCBpdCBtYXkgYmUgdHJ1 ZSBmcm9tIGEgZGF0YSBwbGFuZQ0KcGVyc3BlY3RpdmUsIGJ1dCB0aGF0IGl0IGRvZXNuJ3Qgd29y ayBmcm9tIGEgY29udHJvbCBwbGFuZSBwZXJzcGVjdGl2ZS4NCkFmdGVyIGFsbCwgaW4gdGhlIGRh dGEgcGxhbmUsIGEgTUgtY2FwYWJsZSByb3V0ZXIgZG9lcyBub3RoaW5nIG1vcmUgdGhhbiBQVw0K bGFiZWwgc3dpdGNoaW5nLCBidXQgaW4gdGhlIGNvbnRyb2wgcGxhbmUgaXQgaGFzIHRvIHRpZSB0 b2dldGhlciB0d28NCnRhcmdldGVkIExTUCBzZXNzaW9ucywgb3IgZG9lcyBpdD8NCg0KSU1PLCB0 aGUgYXBwcm9wcmlhdGUgY29uY2x1c2lvbiBpcyB0aGF0IFRhcmdldGVkIExEUCBpcyByZWFsbHkg bm90IHRoZQ0KcmlnaHQgdG9vbCB0byBzZXQgdXAgTUggUFdzLiBEcmFmdC1yYWdnYXJ3YS1yc3Zw dGUtcHctMDAudHh0IGRlc2NyaWJlcyBob3cNClJTVlAtVEUgY2FuIGJlIHVzZWQgdG8gc2V0IHVw IE1ILVBXcy4gSXQgaXMgdG90YWxseSBzdHJhaWdodGZvcndhcmQuIFRoZQ0Kb25seSB0aGluZyBk aWZmZXJlbnQgZnJvbSByZWd1bGFyIFJTVlAgaXMgYSBUTFYgdGhhdCBpcyB1c2VkIGJ5IHRoZSBQ Vw0KZW5kLXBvaW50cyB0byBpZGVudGlmeSB0aGUgUFcuIChUaGUgY3VycmVudCBkcmFmdCBvbmx5 IHNob3dzIFBXLWlkLCBidXQgYQ0Kc3Vic2VxdWVudCBkcmFmdCB3aWxsIGluY2x1ZGUgR0lEIGFz IHdlbGwuKQ0KDQpJIHJlYWxpemUgdGhhdCB0aGUgaW50cm9kdWN0aW9uIG9mIFJTVlAtVEUgZm9y IFBXIHNldCB1cCBpcyBhIGRlcGFydHVyZQ0KZnJvbSBlYXJsaWVyIGRlY2lzaW9ucyB0byB1c2Ug TERQLiBIb3dldmVyLCBpZiB5b3UgY29tcGFyZSBpdCB3aXRoIHRoZQ0KYWx0ZXJuYXRpdmVzLCBJ IHRoaW5rIGl0IGlzIGNsZWFyIHRoYXQgdGhpcyB0aGUgd2F5IHRvIGdvLg0KDQpkcmFmdC15dWRv bmctcHdlMy1jb250cm9sLXByb3RvY29sLWV4dC0wMC50eHQgcmVjb2duaXplcyB0aGF0IGludGVy bWVkaWF0ZQ0KaG9wcyBuZWVkIHRoZSBMU1AgaWRzIG9mIHRoZSB0d28gUFcgZW5kIHBvaW50cy4g SXQgYWxzbyByZWNvZ25pemVzIHRoYXQgaW4NCnNvbWUgY2FzZXMgdGhlcmUgbWF5IGJlIGEgbmVl ZCB0byBjYXJyeSB0aGUgYWRkcmVzcyBvZiBhbiBpbnRlcm1lZGlhdGUgaG9wLg0KVGhpcyBjb250 cmlidXRpb24gZXNzZW50aWFsbHkgcmVjcmVhdGVzIENSLUxEUCwgYnV0IHdpdGggYSBuZXcgYW5k DQppbmNvbXBsZXRlIGZvcm0gb2YgRXhwbGljaXQgUm91dGUgT2JqZWN0LiBDUi1MRFAgd291bGQg b2J2aW91c2x5IGJlDQplcXVpdmFsZW50IHRvIHVzaW5nIFJTVlAtVEUgZm9yIE1ILVBXIHNldHVw LCBidXQgc2luY2UgdGhlIGRlY2lzaW9uIGhhcw0KYmVlbiBtYWRlIHRvIGFib25kb24gQ1ItTERQ LCBSU1ZQLVRFIGlzIHRoZSBiZXR0ZXIgY2hvaWNlIGF0IHRoaXMgcG9pbnQgaW4NCnRpbWUuDQoN CmRyYWZ0LW1hcnRpbmktcHdlMy1wdy1zd2l0Y2hpbmctMDAudHh0IHJlbWFpbnMgY2xvc2VyIHRv IHRoZSBjb250cm9sIGRyYWZ0Lg0KSXQgc3RpY2tzIHdpdGggdGFyZ2V0ZWQgTERQLiBUaGUgcHJv YmxlbSBpcywgYXMgeW91IHdyb3RlIGluIGFuIGVhcmxpZXINCmVtYWlsLCB0aGF0IHRoaXMgbWVj aGFuaXNtIHNlZW1zIHRvIHJlbHkgb24gbWFudWFsIHByb3Zpc2lvbmluZyBieSB0aGUNCm9wZXJh dG9yLiBBbm90aGVyIHByb2JsZW0sIElNTywgaXMgdGhhdCBpdCBsZWFkcyB0byBwcm9saWZlcmF0 aW9uIG9mDQpQVy1zcGVjaWZpYyBpZGVudGlmaWVycyAoQUdJIGFuZCBBSUkpIHRocm91Z2hwdXQg dGhlIG5ldHdvcmsuIFRoZXJlZm9yZSwgaXQNCnR1cm5zIHRoZSBQVyBzd2l0Y2hpbmcgUG9pbnRz IGluIHNwZWNpYWxpemVkIG5vZGVzIHRoYXQgbmVlZCB0byBkZWFsIHdpdGgNCm5vbi1yb3V0YWJs ZSBpZGVudGlmaWVycy4gQXJjaGl0ZWN0dXJhbGx5LCB0aGF0IGlzIG5vdCB0aGUgd2F5IHRvIGdv Lg0KDQpKdXN0IHRvIGJlIGNsZWFyOiBkcmFmdC1tYXJ0aW5pLXB3ZTMtcHctc3dpdGNoaW5nLTAw LnR4dCBjb250YWlucw0KaW5mb3JtYXRpb24gdGhhdCBpcyB1c2VmdWwgYW5kIHRoYXQgc2hvdWxk IGJlY29tZSBwYXJ0IG9mIFBXIHN3aXRjaGluZw0Kc3RhbmRhcmRzLiBFLmcuIGlmIGEgcHJvdmlk ZXIgd291bGQgd2FudCB0byBtaXggYW5kIG1hdGNoIEwyVFAtYmFzZWQgUFdzDQp3aXRoIE1QTFMt YmFzZWQgUFdzLCB0aGVyZSBpcyBhIG5lZWQgZm9yIHRoZSBwcm9jZWR1cmVzIGRlZmluZWQgaW4g dGhlDQpkcmFmdC4gSG93ZXZlciwgSSBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgYSBuZWVkIGZvciBv bmx5IGEgZmV3IG9mIHN1Y2gNCkwyVFAtTVBMUyBpbnRlcndvcmtpbmcgbm9kZXMuIFdlIHNob3Vs ZCBub3QgYWNjZXB0IGEgZGVmaW5pdGlvbiBNSC1QV3MgdGhhdA0KYXNzdW1lcyB0aGF0IHRoaXMg aXMgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIHJlcXVpcmVkIGluIGVhY2ggYW5kIGV2ZXJ5IFBXDQpT d2l0Y2hpbmcgcG9pbnQuIEFuZCB3ZSBzaG91bGQgbm90IGFjY2VwdCBhIHNpZ25hbGluZyBwcm90 b2NvbCBmb3IgTUgtUFcNCnNldHVwIHRoYXQgdXNlcyBub24tcm91dGFibGUgaWRlbnRpZmllcnMu DQoNClBldGVyDQoNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog cmljaGFyZC5zcGVuY2VyQGJ0LmNvbSBbbWFpbHRvOnJpY2hhcmQuc3BlbmNlckBidC5jb21dDQo+ IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMSwgMjAwNCAzOjE5IEFNDQo+IFRvOiBwd2UzQGlldGYu b3JnOyBsMnZwbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbUFdFM10gU2NhbGluZyBoaWVyYXJjaGlj YWwgTERQL1BXIHN0aXRjaGluZw0KPg0KPg0KPiBUbyBhZGRyZXNzIExEUCBzY2FsaW5nIChhbmQg VlBMUyBwYWNrZXQgcmVwbGljYXRpb24pIGENCj4gaGllcmFyY2hpY2FsIExEUCBtb2RlbCBpcyBw cm9wb3NlZCAoaW4NCj4gZHJhZnQtaWV0Zi1sMnZwbi1zaWduYWxpbmctMDEudHh0KSB3aGVyZSBo dWJzIChQRXJzIHJvdXRlcnMpDQo+IGFyZSBjb25uZWN0ZWQgdmlhIGEgZnVsbCBtZXNoIG9mIExE UCBzZXNzaW9ucywgYnV0IHNwb2tlcw0KPiAoUEVyL01UVXMgcm91dGVycykgb25seSBlc3RhYmxp c2ggTERQIHNlc3Npb25zIHdpdGggdGhlDQo+IGh1YihzKSB0aGF0IHRoZXkgY29ubmVjdCB0by4g VGhpcyByZWR1Y2VzIHRoZSBudW1iZXIgb2YgTERQDQo+IHNlc3Npb25zIHJlcXVpcmVkIGFuZCBh bHNvIHJlZHVjZXMgdGhlIG51bWJlciBvZiBwYWNrZXQNCj4gcmVwbGljYXRpb25zIHRoYXQgaHVi IChQRXJzKSByb3V0ZXJzIG11c3QgcGVyZm9ybS4NCj4NCj4gSG93ZXZlciwgYXMgeWV0IEkgZG9u J3QgYmVsaWV2ZSB0aGVyZSBhcmUgYW55IGRyYWZ0cyB0aGF0DQo+IGRpc2N1c3MgZXhhY3RseSBo b3cgdGhlIGh1YiBhbmQgc3Bva2UgUFdzIGFyZSBzaWduYWxsZWQgYW5kDQo+IHN0aXRjaGVkL2Jv dW5kIHRvZ2V0aGVyLiBMaWtld2lzZSBmb3IgVlBXUyBQVyBwYXRocyB0aGF0IGFyZQ0KPiBlc3Rh Ymxpc2hlZCBieSBzdGl0Y2hpbmcgbXVsdGlwbGUgUFdzIHRvZ2V0aGVyIGJldHdlZW4NCj4gZW5k cG9pbnRzLiBJIGJlbGlldmUgdGhpcyBpcyBhbiBpbXBvcnRhbnQgYXJlYSBhcyBvbmUgY2FuDQo+ IGltYWdpbmUgbGFyZ2Ugc2VydmljZSBwcm92aWRlcnMgaGF2aW5nIGh1bmRyZWRzIG9mIFBFcnMN Cj4gcm91dGVycyBjb25uZWN0ZWQgdmlhIGEgZnVsbCBtZXNoIG9mIExEUCBzZXNzaW9ucyB3aXRo IHRlbnMNCj4gb2YgdGhvdXNhbmRzIG9mIE1UVXMvUEVyIGRldmljZXMgaGFuZ2luZyBvZmYgdGhl bS4gVG8gc3VwcG9ydA0KPiBodW5kcmVkcyBvZiB0aG91c2FuZHMgb2YgUFdzIGJldHdlZW4gdGVu cyBvZiB0aG91c2FuZHMgb2YNCj4gTVRVcy9QRXIgcm91dGVycyBvYnZpb3VzbHkgcmVxdWlyZXMg YSBoaWdobHkgc2NhbGFibGUNCj4gcHJvdmlzaW9uaW5nIHNvbHV0aW9uLg0KPg0KPiBUaGUgZXhh bXBsZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlIG9mIGEgaGllcmFyY2hpY2FsDQo+IFZQTFMvVlBX UyBuZXR3b3JrIHdpdGggNCBQRXJzIGRldmljZXMgZWFjaCBjb25uZWN0ZWQgdG8gYQ0KPiBzaW5n bGUgTVRVcyBkZXZpY2U6DQo+DQo+IE1UVXM0LS0tLVBFcnM0LS1QRXJzMy0tLS0tTVRVczMNCj4g ICAgICAgICAgICB8ICBcIC8gIHwNCj4gICAgICAgICAgICB8ICAgWCAgIHwNCj4gICAgICAgICAg ICB8ICAvIFwgIHwNCj4gTVRVczEtLS0tUEVyczEtLVBFcnMyLS0tLS1NVFVzMg0KPg0KPiBJIGFz c3VtZSB0aGF0IHRvIHByb3Zpc2lvbiBhIHN0aXRjaGVkIFZQV1MgUFcgcGF0aCBmcm9tIE1UVXMx DQo+IHRvIE1UVXMyLCB0aGUgaW5kaXZpZHVhbCBQV3MgdGhhdCBmb3JtIHRoZSBwYXRoIG5lZWQg dG8gYmUNCj4gZXN0YWJsaXNoZWQgaW5kaXZpZHVhbGx5IGFuZCB0aGVuIHN0aXRjaGVkIHRvZ2V0 aGVyLiBBbHRob3VnaA0KPiB0aGUgaW5kaXZpZHVhbCBQV3MgY2FuIGJlIGVzdGFibGlzaGVkIHVz aW5nIHNpbmdsZSBzaWRlZA0KPiBwcm92aXNpb25pbmcsIHRoZSBzaWduYWxsaW5nIGZvciBlYWNo IFBXIG11c3QgYmUgaW5pdGlhdGVkIGF0DQo+IG9uZSBzaWRlIGZvciBlYWNoIFBXIGVpdGhlciB0 aHJvdWdoIG1hbnVhbCBjb25maWd1cmF0aW9uIG9yDQo+IHZpYSBPU1MuIE9TUyAob3Igc29tZSBt YW51YWwgbWV0aG9kKSBtdXN0IGFsc28gYmUgdXNlZCB0bw0KPiBrZWVwIHRyYWNrIG9mIGFuZCBi aW5kIHRoZSBkaWZmZXJlbnQgUFdzIHRvZ2V0aGVyLiBUbyBkbyB0aGlzDQo+IE9TUyBuZWVkcyB0 byBsZWFybiBvciBiZSBjb25maWd1cmVkIHdpdGggaW5mb3JtYXRpb24gYWJvdXQNCj4gd2hpY2gg TVRVcyBkZXZpY2VzIHNpdCBiZWhpbmQgd2hpY2ggUEVycyBkZXZpY2VzLg0KPg0KPiBGb3IgVlBM UywgdGhlIHBvaW50LXRvLW11bHRpcG9pbnQgUFdzIGJldHdlZW4gdGhlIGh1YnMgKFBFcnMNCj4g ZGV2aWNlcykgY2FuIGJlIHByb3Zpc2lvbmVkIHVzaW5nIHNpbmdsZWQgc2lkZWQgcHJvdmlzaW9u aW5nLA0KPiBidXQgdGhlIHNwb2tlIFBXcyBuZWVkIHRvIGJlIHNpZ25hbGxlZCBhbmQgYXNzb2Np YXRlZCB3aXRoDQo+IHRoZSByZWxldmFudCBWUExTIHNlcGFyYXRlbHkuIEFnYWluLCB0aGUgc2ln bmFsbGluZyBuZWVkcyB0bw0KPiBiZSBpbml0aWF0ZWQgYXQgb25lIHNpZGUgYW5kIHRoZSBzcG9r ZXMgbmVlZCB0byBiZSBhc3NvY2lhdGVkDQo+IHdpdGggdGhlIGNvcnJlY3QgVlBMUyB2aWEgbWFu dWFsIGNvbmZpZ3VyYXRpb24gb3IgdmlhIE9TUy4NCj4NCj4gVGhlIGRyYXdiYWNrIHdpdGggdGhl IGFib3ZlIGFwcHJvYWNoIGlzIHRoYXQgaW50ZXJtZWRpYXRlDQo+IHJvdXRlcnMgYWxvbmcgdGhl IHN0aXRjaGVkIFBXIHBhdGggKGkuZS4gUEVycyByb3V0ZXJzKSBtdXN0DQo+IGVhY2ggYmUgY29u ZmlndXJlZCB2aWEgT1NTIG9yIHZpYSBhIG1hbnVhbCBtZXRob2QsIGFuZCBPU1MNCj4gbXVzdCBi ZSBhbHNvIGJlIHVzZWQgdG8gYmluZCBhbmQga2VlcCB0cmFjayBvZiB0aGUgaW5kaXZpZHVhbA0K PiBQV3MuIFRoZSBpZGVhbCBzb2x1dGlvbiB3b3VsZCBiZSB0byB1c2UgYSBkeW5hbWljIHByb3Rv Y29sKHMpDQo+IHRvIGVzdGFibGlzaCB0aGUgZW5kLXRvLWVuZCBQVyBwYXRoIHVzaW5nIHNpbmds ZSBzaWRlZA0KPiBwcm92aXNpb25pbmcgaW5pdGlhdGVkIGZyb20gb25lIGVuZCBvZiB0aGUgcGF0 aC4NCj4NCj4gSG93ZXZlciwgdG8gZXN0YWJsaXNoIGFuZCBlbmQtdG8tZW5kIHBhdGggYWNyb3Nz IG11bHRpcGxlDQo+IGhvcHMgcmVxdWlyZXMgYSBwYXRoIHRvIGJlIGNhbGN1bGF0ZWQgYW5kIHNl bGVjdGVkIChpZg0KPiBtdWx0aXBsZSBwYXRocyBleGlzdCkgYmVmb3JlIHRoZSBwYXRoIGNhbiBi ZSBzaWduYWxsZWQuDQo+IFN0aXRjaGluZyBQV3MgdG9nZXRoZXIgdG8gZnJvbSBhIHBhdGggYmV0 d2VlbiB0d28gZW5kcG9pbnRzDQo+IGlzIGVmZmVjdGl2ZWx5IGNyZWF0aW5nIGEgbmV3IGxheWVy IG5ldHdvcmsuIEFsdGhvdWdoDQo+IHRhcmdldGVkIExEUCBoYXMgYmVlbiBwcm9wb3NlZCBhcyB0 aGUgc2lnbmFsbGluZyBtZWNoYW5pc20gdG8NCj4gc2lnbmFsIGluZGl2aWR1YWwgUFdzLCB0aGVy ZSBpcyBubyByb3V0aW5nIGF0IHRoZSBQVyBsYXllciB0bw0KPiBjYWxjdWxhdGUvc2VsZWN0IGFu IGVuZC10by1lbmQgcGF0aC4NCj4NCj4gUm91dGUvcGF0aCBjYWxjdWxhdGlvbi9zZWxlY3Rpb24g aXMgZmFpcmx5IHNpbXBsZSBmb3IgdGhlDQo+IGhpZXJhcmNoaWNhbCBMRFAgbW9kZWwgdXNpbmcg YSBjZW50cmFsaXNlZCBPU1MgYXBwcm9hY2gsIGVhY2gNCj4gTVRVcyBpcyBjb25uZWN0ZWQgdG8g b25lIFBFcnMgKGV4Y2VwdCB3aGVyZSBkdWFsIGhvbWluZyBpcw0KPiB1c2VkKSwgYW5kIGVhY2gg UEVycyBoYXMgYSB0YXJnZXRlZCBMRFAgc2Vzc2lvbiB3aXRoIGVhY2gNCj4gb3RoZXIuIFRoZXJl Zm9yZSwgaWYgdGhlIE9TUyBrbm93cyB0aGF0IE1UVXNYIHNpdHMgYmVoaW5kDQo+IFBFcnNYLCBh bmQgTVRVc1kgc2l0cyBiZWhpbmQgUEVyc1ksIHRoZW4gdG8gZXN0YWJsaXNoIGEgUFcNCj4gcGF0 aCBiZXR3ZWVuIE1UVXNYIGFuZCBNVFVzWSByZXF1aXJlcyBzdGl0Y2hpbmcvc2lnbmFsbGluZyBv Zg0KPiAzIFBXcywgaS5lLiBNVFVzWDwtPlBFcnNYLCBQRXJzWDwtPlBFcnNZLCBhbmQgUEVyc1k8 LT5NVFVzWS4NCj4gT2J0YWluaW5nIGluZm9ybWF0aW9uIGFib3V0IHdoaWNoIE1UVXMgZGV2aWNl cyBzaXQgYmVoaW5kDQo+IHdoaWNoIFBFcnMgZGV2aWNlcyBpcyBzdHJhaWdodGZvcndhcmQgaW4g dGhlIE9TUyBhcHByb2FjaA0KPiBiZWNhdXNlIHRoZSBpbmZvcm1hdGlvbiBpcyBnYXRoZXJlZCwg bWFpbnRhaW5lZCwgYW5kDQo+IHByb2Nlc3NlZCB1c2luZyBhIGNlbnRyYWxpc2VkIG1lY2hhbmlz bS4gVXNpbmcgYSBkaXN0cmlidXRlZA0KPiBhcHByb2FjaCBob3dldmVyIHVzaW5nIGR5bmFtaWMg cHJvdG9jb2xzIHJlcXVpcmVzDQo+IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiB0byBiZSBkaXN0 cmlidXRlZCwgYXQgbGVhc3QgYmV0d2Vlbg0KPiB0aGUgUEVycyBkZXZpY2VzLCBpLmUuIFBFcnMg ZGV2aWNlcyBuZWVkIHRvIGFkdmVydGlzZSB0byBlYWNoDQo+IG90aGVyIHdoaWNoIE1UVXMgZGV2 aWNlcyB0aGV5IGFyZSBjb25uZWN0ZWQgdG8uIEFzIHlldCBhDQo+IG1lY2hhbmlzbSBoYXMgbm90 IGJlZW4gZGVmaW5lZCB0byBkaXN0cmlidXRlIHRoaXMNCj4gaW5mb3JtYXRpb24sIG9yIHRvIHNl bGVjdCBwcmltYXJ5L3NlY29uZGFyeSBwYXRocyB3aGVyZSBNVFVzDQo+IGRldmljZXMgYXJlIG11 bHRpaG9tZWQuDQo+DQo+IER1IEtlIGhhcyBzdWJtaXR0ZWQgYSBkcmFmdCByZWNlbnRseQ0KPiAo PGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXl1ZG9uZy1wd2UzLWNv bnRybw0KbC1wcm90b2NvbC1leHQtMDAudHh0PikgdG8gYWRkcmVzcyBMRFAgc2NhbGluZyB0aGF0 IHByb3Bvc2VzIGEgc29sdXRpb24NCndpdGggdHdvIGRpZmZlcmVudCBtb2RlczoNCg0KaSkgQSBt b2RlIGNhbGxlZCAnc2ltcGxlIHRydW5rJyB0aGF0IHJlZmxlY3RzIExEUCBtZXNzYWdlcyB0byBj bGllbnRzDQpzaW1pbGFyIHRvIHRoZSB3YXkgaW4gd2hpY2ggQkdQIHJvdXRlIHJlZmxlY3RvcnMg ZGlzdHJpYnV0ZSByb3V0ZXMgdG8NCmNsaWVudHMuIFRoaXMgcG90ZW50aWFsbHkgY291bGQgYmUg dXNlZCB0byByZWR1Y2UgdGhlIG51bWJlciBvZiBMRFANCnNlc3Npb25zIGluIGFuIGV4aXN0aW5n IGZ1bGwgbWVzaC4NCg0KaWkpIEEgbW9kZSBjYWxsZWQgJ25leHQgaG9wIHNlbGYnIHRoYXQgZGVz Y3JpYmVzIGEgc29sdXRpb24gZm9yIFBXDQpzdGl0Y2hpbmcgYnV0IGRvZXMgbm90IHNjYWxlIGFz IGl0IHJlbGllcyBvbiBicm9hZGNhc3RpbmcgbGFiZWxzIHRvIGV2ZXJ5DQpQRXJzIGluIHRoZSBm dWxsIG1lc2ggZm9yIGV2ZXJ5IFZQV1MvVlBMUyAodGhlIHJvdXRlIG9mIHRoZSBwcm9ibGVtIGJl aW5nDQp0aGF0IHRoZXJlIGlzIG5vIHJvdXRpbmcgZnVuY3Rpb25hbGl0eSBhdCB0aGUgJ1BXIGxh eWVyJyB3aGljaCB0aGUgZHJhZnQNCmRvZXMgbm90IGFkZHJlc3MpLg0KDQpJIHdvdWxkIGxpa2Ug dG8gZXN0YWJsaXNoIGNvbnNlbnN1cyBhcyB0byB3aGV0aGVyIGEpIGEgZHluYW1pYyBwcm90b2Nv bA0KYmFzZWQgZW5kLXRvLWVuZCBzaW5nbGUgc2lkZWQgcHJvdmlzaW9uaW5nIHNvbHV0aW9uIGlz IHJlcXVpcmVkIHRvIGFpZA0Kc2NhbGluZyBmb3Igc3RpdGNoZWQgUFdzLCBvciBpZiBiKSBQVyBz dGl0Y2hpbmcgaXMgYmVzdCBoYW5kbGVkIHZpYSBPU1MuDQoNCkFueSBjb21tZW50cy90aG91Z2h0 cyBhcmUgd2VsY29tZWQuDQoNClRoYW5rcywNClJpY2hhcmQNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnB3ZTMgbWFpbGluZyBsaXN0DQpwd2UzQGll dGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxp bmcgbGlzdA0KcHdlM0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcHdlMw0KDQoNCg0K --===============1018733086== 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 --===============1018733086==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Tim.Frost@Zarlink.Com Subject: Re: RE: The SAToP -01 MIB draft Date: Mon, 26 Jul 2004 09:39:07 +0100 Lines: 196 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0257895452==" Cc: pwe3-bounces@ietf.org, "PWE3 WG \(E-mail\)" , Sasha Vainshtein , Orly Nicklass X-From: pwe3-bounces@ietf.org Mon Jul 26 10:44:49 2004 Return-path: To: "Yaakov Stein" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Zarlink(Release 6.5.1|January 21, 2004) at 07/26/2004 04:39:10 AM, Serialize complete at 07/26/2004 04:39:10 AM X-Scanned-By: MIMEDefang 2.38 X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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 multipart message in MIME format. --===============0257895452== Content-Type: multipart/alternative; boundary="=_alternative 002F871B80256EDD_=" This is a multipart message in MIME format. --=_alternative 002F871B80256EDD_= Content-Type: text/plain; charset="us-ascii" Yaakov, Orly, I did manage to download draft-ietf-pwe3-satop-mib-01.txt last week when the ID announcement first came through. Interestingly when I did a search this morning for "satop", I came across draft-ietf-pwe3-satop-mib-02.txt. Same date, same everything - a quick "compare documents" in Word revealed that the only change was the title, the text was otherwise identical. A little confusing, maybe it got entered twice somehow? Regards, Tim "Yaakov Stein" Sent by: pwe3-bounces@ietf.org 25-Jul-2004 03:19 PM To: "Orly Nicklass" cc: "PWE3 WG \(E-mail\)" , Sasha Vainshtein Subject: [PWE3] RE: The SAToP -01 MIB draft Interesting - http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-mib-01.txt appears but SAToP doesn't. Y(J)S > -----Original Message----- > From: Orly Nicklass > Sent: Sunday, July 25, 2004 16:01 > To: Yaakov Stein > Cc: PWE3 WG (E-mail); Sasha Vainshtein > Subject: RE: The SAToP -01 MIB draft > > Yaakov, > > Can you post it where you put yours in such cases? If yes, I > will send it to you. > Thanks > Orly > > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Sunday, July 25, 2004 14:31 > To: Orly Nicklass > Cc: PWE3 WG (E-mail) > Subject: The SAToP -01 MIB draft > > Orly and all, > > I have received announcement of > draft-ietf-pwe3-satop-mib-01.txt, being posted, but the draft > does not apear at the IETF Web site, and the pointer in the > PWE3 WG page leads to a message "The draft you are looking > for cannot be found". > > Since the draft that has been posted a few days ago should > not expire, I believe this is an IETF Web site problem, > hopefully to be fixed soon. > > Meanwhile, can you provide a pointer to some alternative > location for this draft? > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --=_alternative 002F871B80256EDD_= Content-Type: text/html; charset="us-ascii"
Yaakov, Orly,
I did manage to download draft-ietf-pwe3-satop-mib-01.txt last week when the ID announcement first came through. Interestingly when I did a search this morning for "satop", I came across draft-ietf-pwe3-satop-mib-02.txt. Same date, same everything - a quick "compare documents" in Word revealed that the only change was the title, the text was otherwise identical.
A little confusing, maybe it got entered twice somehow?
Regards,
Tim



"Yaakov Stein" <yaakov_s@rad.com>
Sent by: pwe3-bounces@ietf.org

25-Jul-2004 03:19 PM

       
        To:        "Orly Nicklass" <orly_n@rad.com>
        cc:        "PWE3 WG \(E-mail\)" <pwe3@ietf.org>, Sasha Vainshtein <Sasha@AXERRA.com>
        Subject:        [PWE3] RE: The SAToP -01 MIB draft



Interesting -
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-mib-01.txt
appears
but SAToP doesn't.

Y(J)S

> -----Original Message-----
> From: Orly Nicklass
> Sent: Sunday, July 25, 2004 16:01
> To: Yaakov Stein
> Cc: PWE3 WG (E-mail); Sasha Vainshtein
> Subject: RE: The SAToP -01 MIB draft
>
>  Yaakov,
>
> Can you post it where you  put yours in such cases? If yes, I
> will send it to you.
> Thanks
> Orly
>
> -----Original Message-----
> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]
> Sent: Sunday, July 25, 2004 14:31
> To: Orly Nicklass
> Cc: PWE3 WG (E-mail)
> Subject: The SAToP -01 MIB draft
>
> Orly and all,
>
> I have received announcement of
> draft-ietf-pwe3-satop-mib-01.txt, being posted, but the draft
> does not apear at the IETF Web site, and the pointer in the
> PWE3 WG page leads to a message "The draft you are looking
> for cannot be found".
>
> Since the draft that has been posted a few days ago should
> not expire, I believe this is an IETF Web site problem,
> hopefully to be fixed soon.
>
> Meanwhile, can you provide a pointer to some alternative
> location for this draft?
>
> With best regards,
>                                    Sasha Vainshtein
> email:     sasha@axerra.com
> tel:       +972-3-7659993 (office)
>            +972-8-9254948 (res.)
>            +972-58-674833 (cell.)
>
>

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

--=_alternative 002F871B80256EDD_=-- --===============0257895452== 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 --===============0257895452==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: du.ke@zte.com.cn Subject: RE: Scaling hierarchical LDP/PW stitching Date: Mon, 26 Jul 2004 17:37:54 +0800 Lines: 68 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: l2vpn@ietf.org, pwe3-bounces@ietf.org, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Mon Jul 26 11:41:52 2004 Return-path: To: "Busschbach, Peter B (Peter)" 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-07-26 17:42:08 X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 have studied your contribution, "draft-raggarwa-rsvpte-pw-00.txt". It's really good production. I'm glad we all work on the signaling protocol for MH-PW setup, and we have many similar idea. First, we all belive that, MH-PW is useful, and a MH-PW can be automatically established by signaling. Second, we all belive that, the signaling protocol for MH-PW setup should use routable identifiers. third, we all belive that, intermediate hops need the LSP ids of the two PW end points, and, in some cases there may be a need to carry the address of an intermediate hop. Although, you think RSVP-TE protocol is more better for carrying PW setup/maintenance information, and my work sticks with targeted LDP. But I don't think there is much difference between our idea, after all, both our fundamental starts are to automatically establish MH-PW launched by UPE(ultimate PE), and without SPE(switching/stitching PE) being specially configurated as to PW, except any control policy. I think you have a misconception about my contribution (draft-yudong-pwe3-control-protocol-ext-00.txt). No "Explicit Route" will appeare in the PW label mapping message. UPE needn't know path information about intermediate hops, for example, in the following scenario: UPE1----SPE1----P1----P2----SPE2----UPE2 LDP targeted hello(es) are established between UPE1 and SPE1, SPE1 and SPE2, SPE2 and UPE2. UPE1 send PW mapping to SPE1, SPE1 knows to forward mapping to SPE2 from PWRIB, i,e. the routing information of the overlay network. so does SPE2, then the mapping comes to the target, UPE2. In the procedure mentioned above, if SPE1 or/and SPE2 take(s) the "next hop self" mode as a result of a local policy, it addes or modifies a/the "next-hop LSR-ID TLV"(the address of an intermediate hop), and will work as a stitching point. otherwise, it takes the "simple trunk" mode, it forward the mapping simplely without any change of it, and it will not work as a stitching point, i,e. PSN tunnel needs to be established between UPE1 and UPE2(or SPE2). This will be one of the slight differeces among us, that we think whether a signal intermediate hop work as a stitching point is a result of local policy of itself, and you think it is a decision of upstream UPE, but it isn't a essential discrepancy. after all the policy and configuration are decided by operator. An other of the slight differeces among us is that, your solution adopt the technology of "explicit routing", and my solution work in the style of "hop-to-hop", the next signal intermediate hop(i,e. reflector, may or may not be a stitching point) is dicided by Source UPE and SPE locally (So, I disagree that this contribution essentially recreates CR-LDP). besides working in the MH-PW scenario, the PW reflector can be used to solve the scaling problem of LDP session. I'm glad to see any solutions on signaling protocol for MH-PW setup. all members cooperate on the forum, and we shall adress all possible solution(s) to the problem in discussing, then we can decide which is the better, or which is the better in which scenario. I think RSVP-TE will work in the scenario where Qos of MH-PW is required. I think RSVP-TE will work in the scenario where Qos of MH-PW is required. But, maybe, the complexity and non-compatibility will restrict it from wide application. Regard, Du Ke From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: draft-martini-pwe3-pw-switching-00.txt announcement missing Date: Mon, 26 Jul 2004 08:48:26 -0600 Organization: Cisco Systems Lines: 19 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Mon Jul 26 17:06:18 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: "PWE3 WG (E-mail)" X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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, I have not seen any announcement for this draft: http://www.ietf.org/internet-drafts/draft-martini-pwe3-pw-switching-00.txt I have sent this out a few weeks ago. Abstract This document describes how to switch pseudo wires (PW) between two distinct control planes or PSN domains. The PW control planes may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. Luca From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: Re: LDP signaling in draft-ietf-pwe3-sonet-07.txt Date: Mon, 26 Jul 2004 17:56:29 +0100 Lines: 167 Sender: pwe3-bounces@ietf.org References: <000d01c45a09$22339d70$68db4dd1@lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, Nick.Weeds@dataconnection.com, 'David Zelig' X-From: pwe3-bounces@ietf.org Mon Jul 26 19:32:11 2004 Return-path: X-BrightmailFiltered: true 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: Ron Cohen In-Reply-To: <000d01c45a09$22339d70$68db4dd1@lycium.net> X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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 Ron Danny and I suggest that you incorporate this change, and when you release -09 we will send it to the IESG. - Stewart Ron Cohen wrote: >David, Nick, > >This is fine by me. Version 08 of the draft was just released (RTP >optional). > >I'll follow the WG chairs advise as to when to add this change. > >Thanks >Ron > > > > >>-----Original Message----- >>From: David Zelig [mailto:Davidz@corrigent.com] >>Sent: Thursday, June 24, 2004 1:52 AM >>To: 'Nick.Weeds@dataconnection.com' >>Cc: 'pwe3@ietf.org'; Ron Cohen (E-mail) >>Subject: RE: [PWE3] LDP signaling in draft-ietf-pwe3-sonet-07.txt >> >> >>(sending again since first time had not arrived to the list) >>Nick, >>If we wish to make it more consistent with existing >>procedures I suggest to >>change the paragraph to: >> >>"The setting of the CEP type, RTP, EBM and MAH bits MUST be >> consistent between peers. If a peer receives a >>label-mapping message >> with inconsistent setting compared with the local configuration, it >> MUST send a label-release message with status code of CEP/TDM >> mis-configuration [IANA], report to the operator and wait for a new >> (consistent) label mapping. A PE MUST send a new label-mapping >> message once it is re-configured or has received a >>label-mapping from >> the peer with a consistent configuration." >> >>David >> >> >> >>>-----Original Message----- >>>From: Nick Weeds [mailto:Nick.Weeds@dataconnection.com] >>>Sent: Tuesday, June 22, 2004 3:47 PM >>>To: 'ronc@lyciumnetworks.com' >>>Cc: pwe3@ietf.org (E-mail) >>>Subject: [PWE3] LDP signaling in draft-ietf-pwe3-sonet-07.txt >>> >>> >>> >>> >>>>draft-ietf-pwe3-sonet-07.txt section 11.3 states that a >>>> >>>> >>>Label Mapping >>> >>> >>>>message with inconsistent interface parameters should be >>>> >>>> >>rejected by >> >> >>>>sending a Label Withdraw message: >>>> >>>> ... If a peer receives a label-mapping message >>>> with inconsistent setting compared with the local >>>> >>>> >>>configuration, it >>> >>> >>>> should send a label-withdraw message with status code >>>> >>>> >>of CEP/TDM >> >> >>>> mis-configuration [IANA], report to the operator and >>>> >>>> >>>wait for a new >>> >>> >>>> (consistent) label mapping. >>>> >>>>Use of Label Withdraw rather than Label Release seems unusual. >>>>* RFC 3036 (LDP) uses Label Release to reject invalid >>>> >>>> >>>Label Mappings >>> >>> >>>>(eg loop-detected). >>>>* draft-ietf-pwe3-control-protocol-07.txt uses Label >>>> >>>> >>>Release to reject >>> >>> >>>>invalid Label Mappings (eg "illegal C-bit", "invalid TAI"). >>>>* L2VPN drafts also use Label Release to reject invalid Label >>>>Mappings. >>>> >>>>I do understand that it's possible to send Label Withdraw >>>> >>>> >>>for the local >>> >>> >>>>label mapping rather than Label Release for the received >>>> >>>> >>>label mapping, >>> >>> >>>>but wouldn't it be simpler and more consistent with RFC >>>> >>>> >>>3036 to use Label >>> >>> >>>>Release in this case? >>>> >>>> Nick. >>>> >>>>Nick Weeds >>>>Software Developer >>>>Network Protocols Group >>>>Data Connection Ltd >>>>Tel: +44 1244 305200 >>>>Fax: +44 1244 312422 >>>>Email: Nick.Weeds@dataconnection.com >>>>Web: http://www.dataconnection.com >>>> >>>> >>>> >>>_______________________________________________ >>>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: Stewart Bryant Subject: draft-ietf-pwe3-cesopsn-01.txt Date: Mon, 26 Jul 2004 18:01:00 +0100 Lines: 7 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 Jul 26 20:05:33 2004 Return-path: X-BrightmailFiltered: true 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: 08e48e05374109708c00c6208b534009 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 This mail starts a two weekl last call on: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-01.txt Last call will end 10th August 2004 - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-vccv-03.txt Last Call Date: Mon, 26 Jul 2004 18:45:08 +0100 Lines: 7 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 Jul 26 20:31:55 2004 Return-path: X-BrightmailFiltered: true 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: 08e48e05374109708c00c6208b534009 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 This is the start of Last Call on http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-03.txt Last Call will end 10th August 2004 - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: ??: RE: Scaling hierarchical LDP/PWstitching Date: Mon, 26 Jul 2004 14:35:03 -0400 Lines: 416 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3-bounces@ietf.org, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Mon Jul 26 21:08:01 2004 Return-path: To: "'du.ke@zte.com.cn'" X-Mailer: Internet Mail Service (5.5.2657.72) X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail2.lucent.com id i6QIZJXk008302 X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c 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 Du Ke, I have included a few comments below. Peter > -----Original Message----- > From: du.ke@zte.com.cn [mailto:du.ke@zte.com.cn] > Sent: Monday, July 26, 2004 2:43 AM > To: Busschbach, Peter B (Peter) > Cc: l2vpn@ietf.org; pwe3@ietf.org; pwe3-bounces@ietf.org;=20 > 'richard.spencer@bt.com' > Subject: ??: RE: [PWE3] Scaling hierarchical LDP/PWstitching >=20 >=20 >=20 > I agree with Richard with the term "PW layer network". > I think, which Richard claimed is that, PW layer network is a overlay > network over IP network, and it has its own routing information and > topology. Creating an overlay network with its own routing and addressing is one so= lution. It would turn the PW layer into an IP VPN. However, I don't think= that such an approach is necessary. draft-ietf-mpls-lsp-hierarchy-08.txt describes how a hierarchy of LSPs ca= n be created. It assumes that lower-layer LSPs (in PW terms: the Transpor= t LSP) use the same instance of a control plane as the higher-layer LSPs = (the PWs). E.g. assume that in the scenario below all nodes use the same = routing protocol. Further, assume that there is a Transport LSP between S= PE1 and SPE2. Based on its link state data base, SPE1 would be aware that= it could reach SPE2 via P1 and P2, or directly via the Transport LSP. Th= e decision which path to use would be based on traffic engineering metric= s. >=20 > To illustrate why this is an issue, please consider the example below: > UPE1----SPE1----P1----P2----SPE2----UPE2 > This is a IP layer topology of network. In this network, UPE1=20 > & UPE2 are > ultimate PEs where the customer-facing ACs are bound to a PW=20 > forwarder. > SPE1 & SPE2 are PW Switching Points where two PW segments are bound > together. and P1 & P2 are common LSR, which have no sense of the > establishing/existing of PWs, and participate only in the PSN tunnel > between SPE1 and SPE2. So P1 & P2 routers do not belong to=20 > the PW layer and > therefore they should be transparent to the PW layer network. > The topology of overlay network(PW layer network) is: > UPE1-----------------SPE1-----------------SPE2-----------------UPE2 > (PSN tunnel -1) (PSN tunnel -2) (PSN tunnel -3) >=20 > Richard suggests that, the routing information base of the=20 > overlay network, > i,e. a separate PW layer routing table (PWRIB) with routing=20 > information > that is only pertinent to the PW layer network, should be maintained. As I said above, I don't think it is necessary to maintain routing inform= ation that is only pertinent to the PW Layer network. There is nothing sp= ecial about PW Switching Points. They just do (PW) label switching. SPE1 = and SPE2 are not different from P1 and P2. Or, in other words, P1 and P2 = could serve as PW Switching Points as well. Therefore, from an architectu= ral perspective, a five-segment MH-PW (UPE1-SPE1-P1-P2-SPE2-UPE2) is equa= lly valid as a three-segment MH-PW (UPE1-SPE1-SPE2-UPE2). The use of a Tr= ansport LSP to tunnel traffic between SPE1 and SPE2 is optional and at th= e operator's discretion. >=20 > This routing information base (PWRIB) are important to every=20 > single sided > signaling protocol for MH-PW setup. >=20 > As RSVP-TE for MH-PW setup is considered(as Peter suggested),=20 > UPE1 should > know the path from UPE1 to UPE2, which can be get from PWRIB.=20 > (Of cause, > whether we should use RSVP-TE as protocol to setup and=20 > maintain PE is an > other question, I'll discuss it in an other mail.) >=20 > In fact, PWRIB can be maintained in several style. > Such as, it can be maintained in a centralized=20 > autodiscovery/radius server > or OSS, When UPE1 launches to establish the PW to UPE2, it send a > "register" message for the FEC to the discovery server and receive a > explicit route information, then it can send path message to=20 > UPE2 or PW > Label mapping to SPE1. > Or, PWRIB can be maitained by UPEs & SPEs with a distributed=20 > style, using > an IGP extension(s) (or a separate mechanism) or a separate=20 > IGP instance. > Then UPE1 knows to send mapping, whose target PE is UPE2, to=20 > SPE1. and SPE1 > knows to forward the mapping to SPE2, and so on. > Or, PWRIB can be maintained in the brain of operator I don't think that is a scaleable solution :-) >, whilst, the UPEs & > SPEs are manually configurated. >=20 >=20 >=20 >=20 > Regard, > Du Ke > >...............................................=16 > >Add: No.68 Zijinghua Rd,Yuhuatai District, > > Nanjing. P.R.China. > >Zip: 210012 > >Tel: 0086-25-52871809 > >Fax: 0086-25-52871000 > >Mail: du.ke@zte.com.cn > >............................................. >=20 >=20 >=20 > =20 > =20 > =20 > "Busschbach, =20 > =20 > =20 > Peter B (Peter)" =CA=D5=BC=FE=C8=CB=A3=BA= =20 > "'richard.spencer@bt.com'" ,=20 > pwe3@ietf.org, =20 > l2vpn@ietf.org =20 > =20 > t.com> =B3=AD=CB=CD=A3=BA = =20 > =20 > =B7=A2=BC=FE=C8=CB=A3=BA =D6=F7=CC= =E2=A3=BA RE: [PWE3]=20 > Scaling hierarchical LDP/PW stitching =20 > pwe3-bounces@ietf =20 > =20 > =20 > .org =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > 2004-07-26 03:53 =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 > Richard, >=20 > I am glad you took the initiative to discuss the=20 > architectural aspects of > PW stitching. With several recent drafts that address this=20 > issue, it is the > right time to look at the fundamentals. >=20 > I think we need to look at this problem from a slightly different > perspective. One of the fundamental misconceptions is that there is > anything special about nodes the form the intermediate hops=20 > in a multi-hop > PW. Stitching PWs is nothing more than PW label switching and=20 > every LSR is > capable of doing that. The question is therefore not: what routing > protocols do we need to find multi-hop capable routers?; but:=20 > what are the > policies that drive an LSR to bundle multiple PW-LSPs into a single > transport LSP? >=20 > It is important to realize than any LSP could be considered a=20 > MH-PW. In one > of your emails you show the following scenario: >=20 > UPE1----SPE1----P1----P2----SPE2----UPE2 >=20 > Suppose an MH-PW is established that consists of five=20 > segments: UPE1-SPE1, > SPE1 - P1, P1 - P2, etc. Since on each link the PW segment is=20 > established > between adjacent nodes, there is no need to add an additional=20 > label on top > of the PW label (see e.g. section 2 of the control draft).=20 > Hence, the MH-PW > is just a regular LSP between UPE1 and UPE2. From a scaleability > perspective it may make sense to tunnel all PWs that pass=20 > through SPE1 and > SPE2 through a Transport LSP that connects those two nodes,=20 > but whether to > do that or not should be based on operator policies. >=20 > The problem with this argument is that it may be true from a=20 > data plane > perspective, but that it doesn't work from a control plane=20 > perspective. > After all, in the data plane, a MH-capable router does=20 > nothing more than PW > label switching, but in the control plane it has to tie together two > targeted LSP sessions, or does it? >=20 > IMO, the appropriate conclusion is that Targeted LDP is really not the > right tool to set up MH PWs. Draft-raggarwa-rsvpte-pw-00.txt=20 > describes how > RSVP-TE can be used to set up MH-PWs. It is totally=20 > straightforward. The > only thing different from regular RSVP is a TLV that is used by the PW > end-points to identify the PW. (The current draft only shows=20 > PW-id, but a > subsequent draft will include GID as well.) >=20 > I realize that the introduction of RSVP-TE for PW set up is a=20 > departure > from earlier decisions to use LDP. However, if you compare it with the > alternatives, I think it is clear that this the way to go. >=20 > draft-yudong-pwe3-control-protocol-ext-00.txt recognizes that=20 > intermediate > hops need the LSP ids of the two PW end points. It also=20 > recognizes that in > some cases there may be a need to carry the address of an=20 > intermediate hop. > This contribution essentially recreates CR-LDP, but with a new and > incomplete form of Explicit Route Object. CR-LDP would obviously be > equivalent to using RSVP-TE for MH-PW setup, but since the=20 > decision has > been made to abondon CR-LDP, RSVP-TE is the better choice at=20 > this point in > time. >=20 > draft-martini-pwe3-pw-switching-00.txt remains closer to the=20 > control draft. > It sticks with targeted LDP. The problem is, as you wrote in=20 > an earlier > email, that this mechanism seems to rely on manual provisioning by the > operator. Another problem, IMO, is that it leads to proliferation of > PW-specific identifiers (AGI and AII) throughput the network.=20 > Therefore, it > turns the PW switching Points in specialized nodes that need=20 > to deal with > non-routable identifiers. Architecturally, that is not the way to go. >=20 > Just to be clear: draft-martini-pwe3-pw-switching-00.txt contains > information that is useful and that should become part of PW switching > standards. E.g. if a provider would want to mix and match=20 > L2TP-based PWs > with MPLS-based PWs, there is a need for the procedures defined in the > draft. However, I believe that there is a need for only a few of such > L2TP-MPLS interworking nodes. We should not accept a=20 > definition MH-PWs that > assumes that this is functionality that is required in each=20 > and every PW > Switching point. And we should not accept a signaling=20 > protocol for MH-PW > setup that uses non-routable identifiers. >=20 > Peter >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > Sent: Wednesday, July 21, 2004 3:19 AM > > To: pwe3@ietf.org; l2vpn@ietf.org > > Subject: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > To address LDP scaling (and VPLS packet replication) a > > hierarchical LDP model is proposed (in > > draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs routers) > > are connected via a full mesh of LDP sessions, but spokes > > (PEr/MTUs routers) only establish LDP sessions with the > > hub(s) that they connect to. This reduces the number of LDP > > sessions required and also reduces the number of packet > > replications that hub (PErs) routers must perform. > > > > However, as yet I don't believe there are any drafts that > > discuss exactly how the hub and spoke PWs are signalled and > > stitched/bound together. Likewise for VPWS PW paths that are > > established by stitching multiple PWs together between > > endpoints. I believe this is an important area as one can > > imagine large service providers having hundreds of PErs > > routers connected via a full mesh of LDP sessions with tens > > of thousands of MTUs/PEr devices hanging off them. To support > > hundreds of thousands of PWs between tens of thousands of > > MTUs/PEr routers obviously requires a highly scalable > > provisioning solution. > > > > The example below shows an example of a hierarchical > > VPLS/VPWS network with 4 PErs devices each connected to a > > single MTUs device: > > > > MTUs4----PErs4--PErs3-----MTUs3 > > | \ / | > > | X | > > | / \ | > > MTUs1----PErs1--PErs2-----MTUs2 > > > > I assume that to provision a stitched VPWS PW path from MTUs1 > > to MTUs2, the individual PWs that form the path need to be > > established individually and then stitched together. Although > > the individual PWs can be established using single sided > > provisioning, the signalling for each PW must be initiated at > > one side for each PW either through manual configuration or > > via OSS. OSS (or some manual method) must also be used to > > keep track of and bind the different PWs together. To do this > > OSS needs to learn or be configured with information about > > which MTUs devices sit behind which PErs devices. > > > > For VPLS, the point-to-multipoint PWs between the hubs (PErs > > devices) can be provisioned using singled sided provisioning, > > but the spoke PWs need to be signalled and associated with > > the relevant VPLS separately. Again, the signalling needs to > > be initiated at one side and the spokes need to be associated > > with the correct VPLS via manual configuration or via OSS. > > > > The drawback with the above approach is that intermediate > > routers along the stitched PW path (i.e. PErs routers) must > > each be configured via OSS or via a manual method, and OSS > > must be also be used to bind and keep track of the individual > > PWs. The ideal solution would be to use a dynamic protocol(s) > > to establish the end-to-end PW path using single sided > > provisioning initiated from one end of the path. > > > > However, to establish and end-to-end path across multiple > > hops requires a path to be calculated and selected (if > > multiple paths exist) before the path can be signalled. > > Stitching PWs together to from a path between two endpoints > > is effectively creating a new layer network. Although > > targeted LDP has been proposed as the signalling mechanism to > > signal individual PWs, there is no routing at the PW layer to > > calculate/select an end-to-end path. > > > > Route/path calculation/selection is fairly simple for the > > hierarchical LDP model using a centralised OSS approach, each > > MTUs is connected to one PErs (except where dual homing is > > used), and each PErs has a targeted LDP session with each > > other. Therefore, if the OSS knows that MTUsX sits behind > > PErsX, and MTUsY sits behind PErsY, then to establish a PW > > path between MTUsX and MTUsY requires stitching/signalling of > > 3 PWs, i.e. MTUsX<->PErsX, PErsX<->PErsY, and PErsY<->MTUsY. > > Obtaining information about which MTUs devices sit behind > > which PErs devices is straightforward in the OSS approach > > because the information is gathered, maintained, and > > processed using a centralised mechanism. Using a distributed > > approach however using dynamic protocols requires > > reachability information to be distributed, at least between > > the PErs devices, i.e. PErs devices need to advertise to each > > other which MTUs devices they are connected to. As yet a > > mechanism has not been defined to distribute this > > information, or to select primary/secondary paths where MTUs > > devices are multihomed. > > > > Du Ke has submitted a draft recently > > ( l-protocol-ext-00.txt>) to address LDP scaling that proposes=20 > a solution > with two different modes: >=20 > i) A mode called 'simple trunk' that reflects LDP messages to clients > similar to the way in which BGP route reflectors distribute routes to > clients. This potentially could be used to reduce the number of LDP > sessions in an existing full mesh. >=20 > ii) A mode called 'next hop self' that describes a solution for PW > stitching but does not scale as it relies on broadcasting=20 > labels to every > PErs in the full mesh for every VPWS/VPLS (the route of the=20 > problem being > that there is no routing functionality at the 'PW layer'=20 > which the draft > does not address). >=20 > I would like to establish consensus as to whether a) a=20 > dynamic protocol > based end-to-end single sided provisioning solution is required to aid > scaling for stitched PWs, or if b) PW stitching is best=20 > handled via OSS. >=20 > Any comments/thoughts are welcomed. >=20 > Thanks, > Richard >=20 > _______________________________________________ > 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 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, 26 Jul 2004 15:03:49 -0400 Lines: 128 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: l2vpn@ietf.org, pwe3-bounces@ietf.org, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Mon Jul 26 21:44:24 2004 Return-path: To: "'du.ke@zte.com.cn'" X-Mailer: Internet Mail Service (5.5.2657.72) 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 Hi Du Ke, I agree that the two solutions overlap significantly. It might be best to first agree on the fundamental architectural concepts and decide on the appropriate protocol later. Regarding your solution, you may not have the intention to recreate CR-LDP, but you end up doing something that looks like it: - you require ordered label distribution, as in CR-LDP - you use certain TLVs (in your case the Extended FEC TLV) from which intermediate nodes infer that this is a special LSP, as in CR-LDP - you define an optional TLV to identify intermediate nodes, as in CR-LDP Add to this the QoS TLV proposed in draft-shah-pwe3-pw-qos-signaling-00.txt, and you have all the elements of CR-LDP. Personally, I don't have anything against CR-LDP, but since the IETF made a firm decision to suspend work on CR-LDP and use RSVP-TE instead, I don't think we should create something that resembles CR-LDP in all aspects except for its name. One additional comment. You write that the RSVP-TE solution requires explicit routing. That is actually not true. An ingress needs to know the address of the egress PE. It may or may not know the addresses of intermediate hops. If the ingress PE's policies do not prescribe PWs to be routed through specific intermediate hops, the ingress PE will simply send the RSVP-TE message to the next node on the path to the egress PE. And so forth. Therefore, it can be as much "hop-to-hop" as the solution that you propose. Peter > -----Original Message----- > From: du.ke@zte.com.cn [mailto:du.ke@zte.com.cn] > Sent: Monday, July 26, 2004 5:38 AM > To: Busschbach, Peter B (Peter) > Cc: l2vpn@ietf.org; pwe3@ietf.org; pwe3-bounces@ietf.org; > 'richard.spencer@bt.com' > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > > Peter, > > I have studied your contribution, > "draft-raggarwa-rsvpte-pw-00.txt". It's > really good production. > > I'm glad we all work on the signaling protocol for MH-PW > setup, and we have > many similar idea. > First, we all belive that, MH-PW is useful, and a MH-PW can be > automatically established by signaling. > Second, we all belive that, the signaling protocol for MH-PW > setup should > use routable identifiers. > third, we all belive that, intermediate hops need the LSP ids > of the two PW > end points, and, in some cases there may be a need to carry > the address of > an intermediate hop. > > Although, you think RSVP-TE protocol is more better for carrying PW > setup/maintenance information, and my work sticks with > targeted LDP. But I > don't think there is much difference between our idea, after > all, both our > fundamental starts are to automatically establish MH-PW launched by > UPE(ultimate PE), and without SPE(switching/stitching PE) > being specially > configurated as to PW, except any control policy. > > I think you have a misconception about my contribution > (draft-yudong-pwe3-control-protocol-ext-00.txt). > No "Explicit Route" will appeare in the PW label mapping message. UPE > needn't know path information about intermediate hops, for > example, in the > following scenario: > UPE1----SPE1----P1----P2----SPE2----UPE2 > LDP targeted hello(es) are established between UPE1 and SPE1, SPE1 and > SPE2, SPE2 and UPE2. > UPE1 send PW mapping to SPE1, SPE1 knows to forward mapping > to SPE2 from > PWRIB, i,e. the routing information of the overlay network. > so does SPE2, > then the mapping comes to the target, UPE2. > In the procedure mentioned above, if SPE1 or/and SPE2 take(s) > the "next hop > self" mode as a result of a local policy, it addes or modifies a/the > "next-hop LSR-ID TLV"(the address of an intermediate hop), > and will work as > a stitching point. otherwise, it takes the "simple trunk" > mode, it forward > the mapping simplely without any change of it, and it will > not work as a > stitching point, i,e. PSN tunnel needs to be established > between UPE1 and > UPE2(or SPE2). > > This will be one of the slight differeces among us, that we > think whether a > signal intermediate hop work as a stitching point is a result of local > policy of itself, and you think it is a decision of upstream > UPE, but it > isn't a essential discrepancy. after all the policy and > configuration are > decided by operator. > > An other of the slight differeces among us is that, your > solution adopt the > technology of "explicit routing", and my solution work in the style of > "hop-to-hop", the next signal intermediate hop(i,e. > reflector, may or may > not be a stitching point) is dicided by Source UPE and SPE > locally (So, I > disagree that this contribution essentially recreates CR-LDP). > > besides working in the MH-PW scenario, the PW reflector can be used to > solve the scaling problem of LDP session. > > I'm glad to see any solutions on signaling protocol for MH-PW > setup. all > members cooperate on the forum, and we shall adress all possible > solution(s) to the problem in discussing, then we can decide > which is the > better, or which is the better in which scenario. > I think RSVP-TE will work in the scenario where Qos of MH-PW > is required. > I think RSVP-TE will work in the scenario where Qos of MH-PW > is required. > But, maybe, the complexity and non-compatibility will > restrict it from wide > application. > > Regard, > Du Ke > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: John Drake Subject: RE: Scaling hierarchical LDP/PW stitching Date: Mon, 26 Jul 2004 13:09:40 -0700 Lines: 219 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-bounces@ietf.org Mon Jul 26 22:26:05 2004 Return-path: To: "Busschbach, Peter B (Peter)" , "'richard.spencer@bt.com'" , pwe3@ietf.org, l2vpn@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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, A very sensible analysis. Thanks, John > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Sunday, July 25, 2004 12:54 PM > To: 'richard.spencer@bt.com'; pwe3@ietf.org; l2vpn@ietf.org > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > Richard, > > I am glad you took the initiative to discuss the architectural aspects of > PW stitching. With several recent drafts that address this issue, it is > the right time to look at the fundamentals. > > I think we need to look at this problem from a slightly different > perspective. One of the fundamental misconceptions is that there is > anything special about nodes the form the intermediate hops in a multi-hop > PW. Stitching PWs is nothing more than PW label switching and every LSR is > capable of doing that. 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? > > It is important to realize than any LSP could be considered a MH-PW. In > one of your emails you show the following scenario: > > UPE1----SPE1----P1----P2----SPE2----UPE2 > > Suppose an MH-PW is established that consists of five segments: UPE1-SPE1, > SPE1 - P1, P1 - P2, etc. Since on each link the PW segment is established > between adjacent nodes, there is no need to add an additional label on top > of the PW label (see e.g. section 2 of the control draft). Hence, the MH- > PW is just a regular LSP between UPE1 and UPE2. From a scaleability > perspective it may make sense to tunnel all PWs that pass through SPE1 and > SPE2 through a Transport LSP that connects those two nodes, but whether > to do that or not should be based on operator policies. > > The problem with this argument is that it may be true from a data plane > perspective, but that it doesn't work from a control plane perspective. > After all, in the data plane, a MH-capable router does nothing more than > PW label switching, but in the control plane it has to tie together two > targeted LSP sessions, or does it? > > IMO, the appropriate conclusion is that Targeted LDP is really not the > right tool to set up MH PWs. Draft-raggarwa-rsvpte-pw-00.txt describes how > RSVP-TE can be used to set up MH-PWs. It is totally straightforward. The > only thing different from regular RSVP is a TLV that is used by the PW > end-points to identify the PW. (The current draft only shows PW-id, but a > subsequent draft will include GID as well.) > > I realize that the introduction of RSVP-TE for PW set up is a departure > from earlier decisions to use LDP. However, if you compare it with the > alternatives, I think it is clear that this the way to go. > > draft-yudong-pwe3-control-protocol-ext-00.txt recognizes that intermediate > hops need the LSP ids of the two PW end points. It also recognizes that in > some cases there may be a need to carry the address of an intermediate > hop. This contribution essentially recreates CR-LDP, but with a new and > incomplete form of Explicit Route Object. CR-LDP would obviously be > equivalent to using RSVP-TE for MH-PW setup, but since the decision has > been made to abondon CR-LDP, RSVP-TE is the better choice at this point in > time. > > draft-martini-pwe3-pw-switching-00.txt remains closer to the control > draft. It sticks with targeted LDP. The problem is, as you wrote in an > earlier email, that this mechanism seems to rely on manual provisioning by > the operator. Another problem, IMO, is that it leads to proliferation of > PW-specific identifiers (AGI and AII) throughput the network. Therefore, > it turns the PW switching Points in specialized nodes that need to deal > with non-routable identifiers. Architecturally, that is not the way to go. > > Just to be clear: draft-martini-pwe3-pw-switching-00.txt contains > information that is useful and that should become part of PW switching > standards. E.g. if a provider would want to mix and match L2TP-based PWs > with MPLS-based PWs, there is a need for the procedures defined in the > draft. However, I believe that there is a need for only a few of such > L2TP-MPLS interworking nodes. We should not accept a definition MH-PWs > that assumes that this is functionality that is required in each and every > PW Switching point. And we should not accept a signaling protocol for MH- > PW setup that uses non-routable identifiers. > > Peter > > > > > > -----Original Message----- > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > Sent: Wednesday, July 21, 2004 3:19 AM > > To: pwe3@ietf.org; l2vpn@ietf.org > > Subject: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > To address LDP scaling (and VPLS packet replication) a > > hierarchical LDP model is proposed (in > > draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs routers) > > are connected via a full mesh of LDP sessions, but spokes > > (PEr/MTUs routers) only establish LDP sessions with the > > hub(s) that they connect to. This reduces the number of LDP > > sessions required and also reduces the number of packet > > replications that hub (PErs) routers must perform. > > > > However, as yet I don't believe there are any drafts that > > discuss exactly how the hub and spoke PWs are signalled and > > stitched/bound together. Likewise for VPWS PW paths that are > > established by stitching multiple PWs together between > > endpoints. I believe this is an important area as one can > > imagine large service providers having hundreds of PErs > > routers connected via a full mesh of LDP sessions with tens > > of thousands of MTUs/PEr devices hanging off them. To support > > hundreds of thousands of PWs between tens of thousands of > > MTUs/PEr routers obviously requires a highly scalable > > provisioning solution. > > > > The example below shows an example of a hierarchical > > VPLS/VPWS network with 4 PErs devices each connected to a > > single MTUs device: > > > > MTUs4----PErs4--PErs3-----MTUs3 > > | \ / | > > | X | > > | / \ | > > MTUs1----PErs1--PErs2-----MTUs2 > > > > I assume that to provision a stitched VPWS PW path from MTUs1 > > to MTUs2, the individual PWs that form the path need to be > > established individually and then stitched together. Although > > the individual PWs can be established using single sided > > provisioning, the signalling for each PW must be initiated at > > one side for each PW either through manual configuration or > > via OSS. OSS (or some manual method) must also be used to > > keep track of and bind the different PWs together. To do this > > OSS needs to learn or be configured with information about > > which MTUs devices sit behind which PErs devices. > > > > For VPLS, the point-to-multipoint PWs between the hubs (PErs > > devices) can be provisioned using singled sided provisioning, > > but the spoke PWs need to be signalled and associated with > > the relevant VPLS separately. Again, the signalling needs to > > be initiated at one side and the spokes need to be associated > > with the correct VPLS via manual configuration or via OSS. > > > > The drawback with the above approach is that intermediate > > routers along the stitched PW path (i.e. PErs routers) must > > each be configured via OSS or via a manual method, and OSS > > must be also be used to bind and keep track of the individual > > PWs. The ideal solution would be to use a dynamic protocol(s) > > to establish the end-to-end PW path using single sided > > provisioning initiated from one end of the path. > > > > However, to establish and end-to-end path across multiple > > hops requires a path to be calculated and selected (if > > multiple paths exist) before the path can be signalled. > > Stitching PWs together to from a path between two endpoints > > is effectively creating a new layer network. Although > > targeted LDP has been proposed as the signalling mechanism to > > signal individual PWs, there is no routing at the PW layer to > > calculate/select an end-to-end path. > > > > Route/path calculation/selection is fairly simple for the > > hierarchical LDP model using a centralised OSS approach, each > > MTUs is connected to one PErs (except where dual homing is > > used), and each PErs has a targeted LDP session with each > > other. Therefore, if the OSS knows that MTUsX sits behind > > PErsX, and MTUsY sits behind PErsY, then to establish a PW > > path between MTUsX and MTUsY requires stitching/signalling of > > 3 PWs, i.e. MTUsX<->PErsX, PErsX<->PErsY, and PErsY<->MTUsY. > > Obtaining information about which MTUs devices sit behind > > which PErs devices is straightforward in the OSS approach > > because the information is gathered, maintained, and > > processed using a centralised mechanism. Using a distributed > > approach however using dynamic protocols requires > > reachability information to be distributed, at least between > > the PErs devices, i.e. PErs devices need to advertise to each > > other which MTUs devices they are connected to. As yet a > > mechanism has not been defined to distribute this > > information, or to select primary/secondary paths where MTUs > > devices are multihomed. > > > > Du Ke has submitted a draft recently > > ( l-protocol-ext-00.txt>) to address LDP scaling that proposes a solution > with two different modes: > > i) A mode called 'simple trunk' that reflects LDP messages to clients > similar to the way in which BGP route reflectors distribute routes to > clients. This potentially could be used to reduce the number of LDP > sessions in an existing full mesh. > > ii) A mode called 'next hop self' that describes a solution for PW > stitching but does not scale as it relies on broadcasting labels to every > PErs in the full mesh for every VPWS/VPLS (the route of the problem being > that there is no routing functionality at the 'PW layer' which the draft > does not address). > > I would like to establish consensus as to whether a) a dynamic protocol > based end-to-end single sided provisioning solution is required to aid > scaling for stitched PWs, or if b) PW stitching is best handled via OSS. > > Any comments/thoughts are welcomed. > > Thanks, > Richard > > _______________________________________________ > 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: John Drake Subject: RE: ??: RE: Scaling hierarchical LDP/PWstitching Date: Mon, 26 Jul 2004 13:13:05 -0700 Lines: 448 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pwe3-bounces@ietf.org, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Mon Jul 26 22:35:15 2004 Return-path: To: "Busschbach, Peter B (Peter)" , "'du.ke@zte.com.cn'" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA07060 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 have always wondered why the PWE3 group didn't consider LSP hierarchy. = I definitely agree that you don't want to invent a PWE3 specific control plane. Thanks, John > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Monday, July 26, 2004 11:35 AM > To: 'du.ke@zte.com.cn' > Cc: l2vpn@ietf.org; pwe3-bounces@ietf.org; pwe3@ietf.org; > 'richard.spencer@bt.com' > Subject: RE: ??: RE: [PWE3] Scaling hierarchical LDP/PWstitching >=20 > Hi Du Ke, >=20 > I have included a few comments below. >=20 > Peter >=20 > > -----Original Message----- > > From: du.ke@zte.com.cn [mailto:du.ke@zte.com.cn] > > Sent: Monday, July 26, 2004 2:43 AM > > To: Busschbach, Peter B (Peter) > > Cc: l2vpn@ietf.org; pwe3@ietf.org; pwe3-bounces@ietf.org; > > 'richard.spencer@bt.com' > > Subject: ??: RE: [PWE3] Scaling hierarchical LDP/PWstitching > > > > > > > > I agree with Richard with the term "PW layer network". > > I think, which Richard claimed is that, PW layer network is a overlay > > network over IP network, and it has its own routing information and > > topology. >=20 >=20 > Creating an overlay network with its own routing and addressing is one > solution. It would turn the PW layer into an IP VPN. However, I don't > think that such an approach is necessary. >=20 > draft-ietf-mpls-lsp-hierarchy-08.txt describes how a hierarchy of LSPs = can > be created. It assumes that lower-layer LSPs (in PW terms: the Transpor= t > LSP) use the same instance of a control plane as the higher-layer LSPs > (the PWs). E.g. assume that in the scenario below all nodes use the sam= e > routing protocol. Further, assume that there is a Transport LSP between > SPE1 and SPE2. Based on its link state data base, SPE1 would be aware t= hat > it could reach SPE2 via P1 and P2, or directly via the Transport LSP. T= he > decision which path to use would be based on traffic engineering metric= s. >=20 >=20 > > > > To illustrate why this is an issue, please consider the example below= : > > UPE1----SPE1----P1----P2----SPE2----UPE2 > > This is a IP layer topology of network. In this network, UPE1 > > & UPE2 are > > ultimate PEs where the customer-facing ACs are bound to a PW > > forwarder. > > SPE1 & SPE2 are PW Switching Points where two PW segments are bound > > together. and P1 & P2 are common LSR, which have no sense of the > > establishing/existing of PWs, and participate only in the PSN tunnel > > between SPE1 and SPE2. So P1 & P2 routers do not belong to > > the PW layer and > > therefore they should be transparent to the PW layer network. > > The topology of overlay network(PW layer network) is: > > UPE1-----------------SPE1-----------------SPE2-----------------UPE2 > > (PSN tunnel -1) (PSN tunnel -2) (PSN tunnel -3) > > > > Richard suggests that, the routing information base of the > > overlay network, > > i,e. a separate PW layer routing table (PWRIB) with routing > > information > > that is only pertinent to the PW layer network, should be maintained. >=20 >=20 > As I said above, I don't think it is necessary to maintain routing > information that is only pertinent to the PW Layer network. There is > nothing special about PW Switching Points. They just do (PW) label > switching. SPE1 and SPE2 are not different from P1 and P2. Or, in other > words, P1 and P2 could serve as PW Switching Points as well. Therefore, > from an architectural perspective, a five-segment MH-PW (UPE1-SPE1-P1-P= 2- > SPE2-UPE2) is equally valid as a three-segment MH-PW (UPE1-SPE1-SPE2- > UPE2). The use of a Transport LSP to tunnel traffic between SPE1 and SP= E2 > is optional and at the operator's discretion. >=20 >=20 > > > > This routing information base (PWRIB) are important to every > > single sided > > signaling protocol for MH-PW setup. > > > > As RSVP-TE for MH-PW setup is considered(as Peter suggested), > > UPE1 should > > know the path from UPE1 to UPE2, which can be get from PWRIB. > > (Of cause, > > whether we should use RSVP-TE as protocol to setup and > > maintain PE is an > > other question, I'll discuss it in an other mail.) > > > > In fact, PWRIB can be maintained in several style. > > Such as, it can be maintained in a centralized > > autodiscovery/radius server > > or OSS, When UPE1 launches to establish the PW to UPE2, it send a > > "register" message for the FEC to the discovery server and receive a > > explicit route information, then it can send path message to > > UPE2 or PW > > Label mapping to SPE1. > > Or, PWRIB can be maitained by UPEs & SPEs with a distributed > > style, using > > an IGP extension(s) (or a separate mechanism) or a separate > > IGP instance. > > Then UPE1 knows to send mapping, whose target PE is UPE2, to > > SPE1. and SPE1 > > knows to forward the mapping to SPE2, and so on. > > Or, PWRIB can be maintained in the brain of operator >=20 >=20 > I don't think that is a scaleable solution :-) >=20 >=20 > >, whilst, the UPEs & > > SPEs are manually configurated. > > > > > > > > > > Regard, > > Du Ke > > >...............................................=16 > > >Add: No.68 Zijinghua Rd,Yuhuatai District, > > > Nanjing. P.R.China. > > >Zip: 210012 > > >Tel: 0086-25-52871809 > > >Fax: 0086-25-52871000 > > >Mail: du.ke@zte.com.cn > > >............................................. > > > > > > > > > > > > > > "Busschbach, > > > > > > Peter B (Peter)" =CA=D5=BC=FE=C8=CB=A3=BA > > "'richard.spencer@bt.com'" , > > pwe3@ietf.org, > > > l2vpn@ietf.org > > > > t.com> =B3=AD=CB=CD=A3=BA > > > > =B7=A2=BC=FE=C8=CB=A3=BA =D6=F7= =CC=E2=A3=BA RE: [PWE3] > > Scaling hierarchical LDP/PW stitching > > pwe3-bounces@ietf > > > > > > .org > > > > > > > > > > > > > > > > > > 2004-07-26 03:53 > > > > > > > > > > > > > > > > > > > > > > > > > > Richard, > > > > I am glad you took the initiative to discuss the > > architectural aspects of > > PW stitching. With several recent drafts that address this > > issue, it is the > > right time to look at the fundamentals. > > > > I think we need to look at this problem from a slightly different > > perspective. One of the fundamental misconceptions is that there is > > anything special about nodes the form the intermediate hops > > in a multi-hop > > PW. Stitching PWs is nothing more than PW label switching and > > every LSR is > > capable of doing that. 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? > > > > It is important to realize than any LSP could be considered a > > MH-PW. In one > > of your emails you show the following scenario: > > > > UPE1----SPE1----P1----P2----SPE2----UPE2 > > > > Suppose an MH-PW is established that consists of five > > segments: UPE1-SPE1, > > SPE1 - P1, P1 - P2, etc. Since on each link the PW segment is > > established > > between adjacent nodes, there is no need to add an additional > > label on top > > of the PW label (see e.g. section 2 of the control draft). > > Hence, the MH-PW > > is just a regular LSP between UPE1 and UPE2. From a scaleability > > perspective it may make sense to tunnel all PWs that pass > > through SPE1 and > > SPE2 through a Transport LSP that connects those two nodes, > > but whether to > > do that or not should be based on operator policies. > > > > The problem with this argument is that it may be true from a > > data plane > > perspective, but that it doesn't work from a control plane > > perspective. > > After all, in the data plane, a MH-capable router does > > nothing more than PW > > label switching, but in the control plane it has to tie together two > > targeted LSP sessions, or does it? > > > > IMO, the appropriate conclusion is that Targeted LDP is really not th= e > > right tool to set up MH PWs. Draft-raggarwa-rsvpte-pw-00.txt > > describes how > > RSVP-TE can be used to set up MH-PWs. It is totally > > straightforward. The > > only thing different from regular RSVP is a TLV that is used by the P= W > > end-points to identify the PW. (The current draft only shows > > PW-id, but a > > subsequent draft will include GID as well.) > > > > I realize that the introduction of RSVP-TE for PW set up is a > > departure > > from earlier decisions to use LDP. However, if you compare it with th= e > > alternatives, I think it is clear that this the way to go. > > > > draft-yudong-pwe3-control-protocol-ext-00.txt recognizes that > > intermediate > > hops need the LSP ids of the two PW end points. It also > > recognizes that in > > some cases there may be a need to carry the address of an > > intermediate hop. > > This contribution essentially recreates CR-LDP, but with a new and > > incomplete form of Explicit Route Object. CR-LDP would obviously be > > equivalent to using RSVP-TE for MH-PW setup, but since the > > decision has > > been made to abondon CR-LDP, RSVP-TE is the better choice at > > this point in > > time. > > > > draft-martini-pwe3-pw-switching-00.txt remains closer to the > > control draft. > > It sticks with targeted LDP. The problem is, as you wrote in > > an earlier > > email, that this mechanism seems to rely on manual provisioning by th= e > > operator. Another problem, IMO, is that it leads to proliferation of > > PW-specific identifiers (AGI and AII) throughput the network. > > Therefore, it > > turns the PW switching Points in specialized nodes that need > > to deal with > > non-routable identifiers. Architecturally, that is not the way to go. > > > > Just to be clear: draft-martini-pwe3-pw-switching-00.txt contains > > information that is useful and that should become part of PW switchin= g > > standards. E.g. if a provider would want to mix and match > > L2TP-based PWs > > with MPLS-based PWs, there is a need for the procedures defined in th= e > > draft. However, I believe that there is a need for only a few of such > > L2TP-MPLS interworking nodes. We should not accept a > > definition MH-PWs that > > assumes that this is functionality that is required in each > > and every PW > > Switching point. And we should not accept a signaling > > protocol for MH-PW > > setup that uses non-routable identifiers. > > > > Peter > > > > > > > > > > > -----Original Message----- > > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > > Sent: Wednesday, July 21, 2004 3:19 AM > > > To: pwe3@ietf.org; l2vpn@ietf.org > > > Subject: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > > To address LDP scaling (and VPLS packet replication) a > > > hierarchical LDP model is proposed (in > > > draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs routers) > > > are connected via a full mesh of LDP sessions, but spokes > > > (PEr/MTUs routers) only establish LDP sessions with the > > > hub(s) that they connect to. This reduces the number of LDP > > > sessions required and also reduces the number of packet > > > replications that hub (PErs) routers must perform. > > > > > > However, as yet I don't believe there are any drafts that > > > discuss exactly how the hub and spoke PWs are signalled and > > > stitched/bound together. Likewise for VPWS PW paths that are > > > established by stitching multiple PWs together between > > > endpoints. I believe this is an important area as one can > > > imagine large service providers having hundreds of PErs > > > routers connected via a full mesh of LDP sessions with tens > > > of thousands of MTUs/PEr devices hanging off them. To support > > > hundreds of thousands of PWs between tens of thousands of > > > MTUs/PEr routers obviously requires a highly scalable > > > provisioning solution. > > > > > > The example below shows an example of a hierarchical > > > VPLS/VPWS network with 4 PErs devices each connected to a > > > single MTUs device: > > > > > > MTUs4----PErs4--PErs3-----MTUs3 > > > | \ / | > > > | X | > > > | / \ | > > > MTUs1----PErs1--PErs2-----MTUs2 > > > > > > I assume that to provision a stitched VPWS PW path from MTUs1 > > > to MTUs2, the individual PWs that form the path need to be > > > established individually and then stitched together. Although > > > the individual PWs can be established using single sided > > > provisioning, the signalling for each PW must be initiated at > > > one side for each PW either through manual configuration or > > > via OSS. OSS (or some manual method) must also be used to > > > keep track of and bind the different PWs together. To do this > > > OSS needs to learn or be configured with information about > > > which MTUs devices sit behind which PErs devices. > > > > > > For VPLS, the point-to-multipoint PWs between the hubs (PErs > > > devices) can be provisioned using singled sided provisioning, > > > but the spoke PWs need to be signalled and associated with > > > the relevant VPLS separately. Again, the signalling needs to > > > be initiated at one side and the spokes need to be associated > > > with the correct VPLS via manual configuration or via OSS. > > > > > > The drawback with the above approach is that intermediate > > > routers along the stitched PW path (i.e. PErs routers) must > > > each be configured via OSS or via a manual method, and OSS > > > must be also be used to bind and keep track of the individual > > > PWs. The ideal solution would be to use a dynamic protocol(s) > > > to establish the end-to-end PW path using single sided > > > provisioning initiated from one end of the path. > > > > > > However, to establish and end-to-end path across multiple > > > hops requires a path to be calculated and selected (if > > > multiple paths exist) before the path can be signalled. > > > Stitching PWs together to from a path between two endpoints > > > is effectively creating a new layer network. Although > > > targeted LDP has been proposed as the signalling mechanism to > > > signal individual PWs, there is no routing at the PW layer to > > > calculate/select an end-to-end path. > > > > > > Route/path calculation/selection is fairly simple for the > > > hierarchical LDP model using a centralised OSS approach, each > > > MTUs is connected to one PErs (except where dual homing is > > > used), and each PErs has a targeted LDP session with each > > > other. Therefore, if the OSS knows that MTUsX sits behind > > > PErsX, and MTUsY sits behind PErsY, then to establish a PW > > > path between MTUsX and MTUsY requires stitching/signalling of > > > 3 PWs, i.e. MTUsX<->PErsX, PErsX<->PErsY, and PErsY<->MTUsY. > > > Obtaining information about which MTUs devices sit behind > > > which PErs devices is straightforward in the OSS approach > > > because the information is gathered, maintained, and > > > processed using a centralised mechanism. Using a distributed > > > approach however using dynamic protocols requires > > > reachability information to be distributed, at least between > > > the PErs devices, i.e. PErs devices need to advertise to each > > > other which MTUs devices they are connected to. As yet a > > > mechanism has not been defined to distribute this > > > information, or to select primary/secondary paths where MTUs > > > devices are multihomed. > > > > > > Du Ke has submitted a draft recently > > > ( > l-protocol-ext-00.txt>) to address LDP scaling that proposes > > a solution > > with two different modes: > > > > i) A mode called 'simple trunk' that reflects LDP messages to clients > > similar to the way in which BGP route reflectors distribute routes to > > clients. This potentially could be used to reduce the number of LDP > > sessions in an existing full mesh. > > > > ii) A mode called 'next hop self' that describes a solution for PW > > stitching but does not scale as it relies on broadcasting > > labels to every > > PErs in the full mesh for every VPWS/VPLS (the route of the > > problem being > > that there is no routing functionality at the 'PW layer' > > which the draft > > does not address). > > > > I would like to establish consensus as to whether a) a > > dynamic protocol > > based end-to-end single sided provisioning solution is required to ai= d > > scaling for stitched PWs, or if b) PW stitching is best > > handled via OSS. > > > > Any comments/thoughts are welcomed. > > > > Thanks, > > Richard > > > > _______________________________________________ > > 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, 26 Jul 2004 17:20:14 -0400 Organization: Alcatel Networks Corporaton Lines: 152 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, pwe3-bounces@ietf.org, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Mon Jul 26 23:33:00 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: 21bf7a2f1643ae0bf20c1e010766eb78 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, 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. However, in many cases this will not be a requirement. There will be a few stiching nodes which are known a priori. 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. 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. ----------- "Busschbach, Peter B (Peter)" wrote: > > Hi Du Ke, > > I agree that the two solutions overlap significantly. It might be best to first agree on the fundamental architectural concepts and decide on the appropriate protocol later. > > Regarding your solution, you may not have the intention to recreate CR-LDP, but you end up doing something that looks like it: > > - you require ordered label distribution, as in CR-LDP > > - you use certain TLVs (in your case the Extended FEC TLV) from which intermediate nodes infer that this is a special LSP, as in CR-LDP > > - you define an optional TLV to identify intermediate nodes, as in CR-LDP > > Add to this the QoS TLV proposed in draft-shah-pwe3-pw-qos-signaling-00.txt, and you have all the elements of CR-LDP. > > Personally, I don't have anything against CR-LDP, but since the IETF made a firm decision to suspend work on CR-LDP and use RSVP-TE instead, I don't think we should create something that resembles CR-LDP in all aspects except for its name. > > One additional comment. You write that the RSVP-TE solution requires explicit routing. That is actually not true. An ingress needs to know the address of the egress PE. It may or may not know the addresses of intermediate hops. If the ingress PE's policies do not prescribe PWs to be routed through specific intermediate hops, the ingress PE will simply send the RSVP-TE message to the next node on the path to the egress PE. And so forth. Therefore, it can be as much "hop-to-hop" as the solution that you propose. > > Peter > > > -----Original Message----- > > From: du.ke@zte.com.cn [mailto:du.ke@zte.com.cn] > > Sent: Monday, July 26, 2004 5:38 AM > > To: Busschbach, Peter B (Peter) > > Cc: l2vpn@ietf.org; pwe3@ietf.org; pwe3-bounces@ietf.org; > > 'richard.spencer@bt.com' > > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching > > > > > > > > Peter, > > > > I have studied your contribution, > > "draft-raggarwa-rsvpte-pw-00.txt". It's > > really good production. > > > > I'm glad we all work on the signaling protocol for MH-PW > > setup, and we have > > many similar idea. > > First, we all belive that, MH-PW is useful, and a MH-PW can be > > automatically established by signaling. > > Second, we all belive that, the signaling protocol for MH-PW > > setup should > > use routable identifiers. > > third, we all belive that, intermediate hops need the LSP ids > > of the two PW > > end points, and, in some cases there may be a need to carry > > the address of > > an intermediate hop. > > > > Although, you think RSVP-TE protocol is more better for carrying PW > > setup/maintenance information, and my work sticks with > > targeted LDP. But I > > don't think there is much difference between our idea, after > > all, both our > > fundamental starts are to automatically establish MH-PW launched by > > UPE(ultimate PE), and without SPE(switching/stitching PE) > > being specially > > configurated as to PW, except any control policy. > > > > I think you have a misconception about my contribution > > (draft-yudong-pwe3-control-protocol-ext-00.txt). > > No "Explicit Route" will appeare in the PW label mapping message. UPE > > needn't know path information about intermediate hops, for > > example, in the > > following scenario: > > UPE1----SPE1----P1----P2----SPE2----UPE2 > > LDP targeted hello(es) are established between UPE1 and SPE1, SPE1 and > > SPE2, SPE2 and UPE2. > > UPE1 send PW mapping to SPE1, SPE1 knows to forward mapping > > to SPE2 from > > PWRIB, i,e. the routing information of the overlay network. > > so does SPE2, > > then the mapping comes to the target, UPE2. > > In the procedure mentioned above, if SPE1 or/and SPE2 take(s) > > the "next hop > > self" mode as a result of a local policy, it addes or modifies a/the > > "next-hop LSR-ID TLV"(the address of an intermediate hop), > > and will work as > > a stitching point. otherwise, it takes the "simple trunk" > > mode, it forward > > the mapping simplely without any change of it, and it will > > not work as a > > stitching point, i,e. PSN tunnel needs to be established > > between UPE1 and > > UPE2(or SPE2). > > > > This will be one of the slight differeces among us, that we > > think whether a > > signal intermediate hop work as a stitching point is a result of local > > policy of itself, and you think it is a decision of upstream > > UPE, but it > > isn't a essential discrepancy. after all the policy and > > configuration are > > decided by operator. > > > > An other of the slight differeces among us is that, your > > solution adopt the > > technology of "explicit routing", and my solution work in the style of > > "hop-to-hop", the next signal intermediate hop(i,e. > > reflector, may or may > > not be a stitching point) is dicided by Source UPE and SPE > > locally (So, I > > disagree that this contribution essentially recreates CR-LDP). > > > > besides working in the MH-PW scenario, the PW reflector can be used to > > solve the scaling problem of LDP session. > > > > I'm glad to see any solutions on signaling protocol for MH-PW > > setup. all > > members cooperate on the forum, and we shall adress all possible > > solution(s) to the problem in discussing, then we can decide > > which is the > > better, or which is the better in which scenario. > > I think RSVP-TE will work in the scenario where Qos of MH-PW > > is required. > > I think RSVP-TE will work in the scenario where Qos of MH-PW > > is required. > > But, maybe, the complexity and non-compatibility will > > restrict it from wide > > application. > > > > Regard, > > Du Ke > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: du.ke@zte.com.cn Subject: =?gb2312?B?tPC4tDogW1BXRTNdIFBXRTMgQElFVEYgNjAgLSBEUkFGVCBBR0VOREE=?= Date: Tue, 27 Jul 2004 15:37:59 +0800 Lines: 151 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3-bounces@ietf.org, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Jul 27 09:47:32 2004 Return-path: To: Danny McPherson 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-07-27 15:42:41 X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 Excuse me, sir. would you kind to arrange a time slot of 5 or 10 min for discussing "draft-yudong-pwe3-control-protocol-ext-00.txt"? Sorry, I should put the requisition forward several days ago, but, you see, the American visa is very difficult to be acquired, I wasn't sure whether I can present at the meeting several days ago. Now, one of my cooperator, Mr. cagatay buyukkoc is willing to join the meeting and make a discussion. do you have a free slot yet? thanks. Discussion: The draft explains how a reflection can work as a signal intermediate hop or data plan intermediate hop of PW to adress the scaling problem issued by full mesh of LDP sessions and PSN tunnel. Draft Agenda for PWE3 WG meeting at IETF 60. Please pass along corrections and comments ASAP. As usual, look for presentations and updated agenda data to be available at the following URL: http://pwe3.tcb.net/meetings/ietf60 Thanks! -danny & stewart [snip] Pseudo Wire Emulation Edge to Edge (pwe3) ========================================= MONDAY, August 2, 2004 (1530-1730) CHAIR: "Danny McPherson" "Stewart Bryant" AGENDA: 5 min Administrivia Chairs (Stewart & Danny) Agenda Bashing Minutes Blue Sheets 10 min WG Document Status & Charter Update Danny McPherson Stewart Bryant 5 min PW Control Word & MPLS BCP Stewart Bryant & Danny McPherson http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw -00.txt Discussion: PW Control Word Draft and request to make WG doc. 10 min PWE3 OAM Message Map Thomas D. Nadeau http://www.ietf.org/internet-drafts/ draft-ietf-pwe3-oam-msg-map-00 Discussion: *** 5 min ITU-T Update Thomas Walsh Discussion: ITU-T approves X.84 Frame Relay Service over MPLS based on PWE3 work. Also, sent liaison to PWE3. 10 min RSVP-TE for Multi-hop PWs Rahul Aggarwal http://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-00.txt Discussion: The draft explains how RSVP-TE can be used for setting up multi-hop PWs with QoS. Its directly applicable to PWE3. Hence the request for the slot. The intention would be to introduce the concept and have a discussion on this. 10 min PW Switching (Inter-provider/AS PWs) Luca Martini http://www.ietf.org/internet-drafts/draft-martini-pwe3-pw-switching -00.txt Discussion: PW switching ID. Draft describes how to switch pseudo wires (PW) between two distinct control planes or PSN domains. The PW control planes may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. 10 min PWE3 QOS Signaling Himanshu Shah http://www.ietf.org/internet-drafts/draft-shah-pwe3-qos-signaling -00.txt Discussion: Plan to discuss the requirement, the mechanism and applicability (such as congestion avoidence) for QOS signagling over Pseudowire. I may discuss how proposed mechanism contrasts with other alternatives. 10 min Dry-Martini Ping Pan http://www.ietf.org/internet-drafts/draft-pan-pwe3-over-sub-ip-00.txt Discussion: *** 15 min CESoPSN and WG LC (10 mins) Sasha Vainshtein http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-01.txt Discussion: Summary and proposed resolution of open issues following the CESoPSN WG LC. TDM Extensions to PWE3 (5 mins) http://www.ietf.org/internet-drafts/draft-vainshtein-pwe3-tdm-control- protocol-extensi-01.txt Discussion: Update on the TDM Extensions to the PWE3 control protocol. Would like to ask WG to make WG item. 15 min TDMoIP Updates (10 mins) Yaakov Stein http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-02.txt Discussion: TDMoIP Updates, including use of flags and OAM/VCCV PWE3 and UDP/IP Issues (5 mins) http://www.ietf.org/internet-drafts/draft-stein-pwe3-udp-00.txt Discussion: *** 5 min IP Pseudowire Encapsulation Florin Balus http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt Discussion: *** 10 min Wrap-up Chairs _______________________________________________ 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: claude.kawa@sympatico.ca Subject: PWE3 new frame relay/PW draft Date: Tue, 27 Jul 2004 13:44:40 -0400 Lines: 1248 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=____1090950280715_W+SM0CH2OK" X-From: pwe3-bounces@ietf.org Tue Jul 27 19:50:31 2004 Return-path: X-Mailer: Openwave WebEngine, version 2.8.6.6 (webedge20-101-174-112-20020617)" To: X-Scan-Signature: 8eea8f4473ae4de7baa9fae348a439c7 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. ------=____1090950280715_W+SM0CH2OK Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Attached is the latest version of the frame relay/PWE3 draft. It was also submitted for upload to the Internet-draft directories. claude kawa ------=____1090950280715_W+SM0CH2OK Content-Type: text/plain; name="draft-ietf-pwe3-frame-relay-03.txt" Content-Disposition: inline; filename="draft-ietf-pwe3-frame-relay-03.txt" Content-Transfer-Encoding: base64 UFdFMyBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIENsYXVkZSBLYXdhIA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgyWNvbGUgUG9seXRlY2huaXF1ZQ0KRXhwaXJlczogSmFudWFyeSAy MDA1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmFvIENoZXJ1a3VyaQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENp c2NvIFN5c3RlbXMsIEluYy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKEVkaXRvcnMpDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZHJldyBH LiBNYWxpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGVsbGFicw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEx1Y2EgTWFydGluaQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMsIEluYy4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IERhdmlkIFNpbmljcm9wZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBFcmljc3Nvbg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDQNCg0KDQogICAgICAgICAg ICAgICAgICAgICAgRnJhbWUgUmVsYXkgb3ZlciBQc2V1ZG8tV2lyZXMNCg0KICAgICAgICAg ICAgICAgICAgIGRyYWZ0LWlldGYtcHdlMy1mcmFtZS1yZWxheS0wMy50eHQNCg0KDQoNClN0 YXR1cyBvZiB0aGlzIE1lbW8NCg0KVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFm dCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZQ0Kd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBT ZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBk b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sNCkZvcmNlIChJRVRG KSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IG90aGVy IGdyb3Vwcw0KbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC1EcmFmdHMuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCnRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJl bmNlIG1hdGVyaWFsDQpvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iDQoNCg0KDQpUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBj YW4gYmUgYWNjZXNzZWQgYXQNCiAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1h YnN0cmFjdHMudHh0DQpUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0 b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KQ29weXJpZ2h0KEMpIFRoZSBJbnRl cm5ldCBTb2NpZXR5ICgyMDA0KS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KDQoNCg0KDQpL YXdhLCBldCBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAxXQ0KDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgIGRyYWZ0LWlldGYt cHdlMy1mcmFtZS1yZWxheS0wMy50eHQgICAgICAgQXVndXN0IDIwMDQNCg0KQWJzdHJhY3QN Cg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGZyYW1lIHJlbGF5IHBzZXVkby13aXJlIGVt dWxhdGlvbiBlZGdlLXRvLWVkZ2UuDQogICBBIGZyYW1lIHJlbGF5IHBzZXVkby13aXJlIGlz IGEgbWVjaGFuaXNtIHRoYXQgZXhpc3RzIGJldHdlZW4gYSANCiAgIHByb3ZpZGVyJ3MgZWRn ZSBuZXR3b3JrIG5vZGVzIGFuZCBzdXBwb3J0IGFzIGZhaXRoZnVsbHkgYXMgcG9zc2libGUN CiAgIGZyYW1lIHJlbGF5IHNlcnZpY2VzIG92ZXIgSVAgYW5kIE1QTFMgcGFja2V0IHN3aXRj aGVkIG5ldHdvcmsgKFBTTikuDQogICBUd28gbWFwcGluZyBtb2RlcyBhcmUgZGVmaW5lZC4g VGhlIGZpcnN0LCBvbmUtdG8tb25lIG1hcHBpbmcgbW9kZSwgaXMgDQogICBjaGFyYWN0ZXJp emVkIGJ5IGEgb25lIHRvIG9uZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIGZyYW1lIHJlbGF5 IFZDIGFuZCANCiAgIGEgcGFpciAgIG9mIE1QTFMgTFNQcywgYW5kICBpcyBkZWZpbmVkIGZv ciBNUExTIFBTTiBvbmx5LiBUaGUgc2Vjb25kIG1vZGUgDQogICBpcyBrbm93biBhcyBwb3J0 IG1vZGUgb3IgbWFueS10by1vbmUgbWFwcGluZyBtb2RlIGFuZCBpcyBkZWZpbmVkIGZvciBi b3RoIA0KICAgTVBMUyBQU05zIGFuZCBJUCBQU05zIHdpdGggTDJUUHYzLg0KDQoNCkNvLWF1 dGhvcnMNCg0KIFRoZSBmb2xsb3dpbmcgYXJlIGNvLWF1dGhvcnMgb2YgdGhpcyBkb2N1bWVu dDoNCg0KICAgICAgIEVyaWMgQy4gUm9zZW4gICAgICAgICAgICAgQ2lzY28gU3lzdGVtcw0K ICAgICAgIERhbmllbCBUYXBwYW4gICAgICAgICAgICAgQ2lzY28gU3lzdGVtcw0KICAgICAg IFRob21hcyBLLiBKb2huc29uICAgICAgICAgTGl0Y2hmaWVsZCBDb21tdW5pY2F0aW9ucw0K ICAgICAgIEtpcmVldGkgS29tcGVsbGEgICAgICAgICAgSnVuaXBlciBOZXR3b3JrcywgSW5j Lg0KICAgICAgIFN0ZXZlIFZvZ2Vsc2FuZyAgICAgICAgICAgTGF1cmVsIE5ldHdvcmtzLCBJ bmMuDQogICAgICAgVmluYWkgU2lya2F5ICAgICAgICAgICAgICBSZWxpYW5jZSBJbmZvY29t bQ0KICAgICAgIFJhdmkgQmhhdCAgICAgICAgICAgICAgICAgTm9raWENCiAgICAgICBOaXNo aXQgVmFzYXZhZGEgICAgICAgICAgIE5va2lhDQogICAgICAgR2lsZXMgSGVyb24gICAgICAg ICAgICAgICBUZWxsYWJzIA0KICAgICAgIERpbWl0cmkgU3RyYXR0b24gVmxhY2hvcyAgTWF6 dSBOZXR3b3JrcyxJbmMuDQogICAgICAgQ2hyaXMgTGlsamVuc3RvbHBlICAgICAgICBDYWJs ZSAmIFdpcmVsZXNzIA0KICAgICAgIFByYXlzb24gUGF0ZSAgICAgICAgICAgICAgT3ZlcnR1 cmUgTmV0d29ya3MsIEluYw0KICAgICAgIE5hc3NlciBFbC1BYXdhciAgICAgICAgICAgTGV2 ZWwgMyBDb21tdW5pY2F0aW9ucywgTExDDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgIA0KICAgICAgIA0KDQogICAgICAgDQoNCg0KVGFibGUgb2YgQ29udGVu dHMNCg0KMS4gSW50cm9kdWN0aW9uLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDMNCjIuIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQozLiBBY3JvbnltcyBhbmQg QWJicmV2aWF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0K NC4gUmVxdWlyZW1lbnRzIGZvciBGcmFtZSBSZWxheSBPdmVyIFBzZXVkby13aXJlcy4gLiAu IC4gIC4gLiAuIC4gIDUNCjUuIFJlZmVyZW5jZSBtb2RlbCBhbmQgUFdFMyBwcm90b2NvbCBs YXllcmluZyAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQo2LiBHZW5lcmFsIGVuY2Fwc3VsYXRp b24gZm9yIHRoZSB0d28gbWFwcGluZyBtb2RlcyAgIC4gLiAuIC4gLiAuICAgNw0KNy4gRnJh bWUgUmVsYXkgb3ZlciBNUExTIFBTTiBmb3IgdGhlIG9uZS10by1vbmUgbWFwcGluZyBtb2Rl LiAuICAuIDgNCjguIEZSIFBWQyBwcm92aXNpb25pbmcuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQo5LiBUcmFmZmljIG1hbmFnZW1lbnQgYXNwZWN0 cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxNg0KMTAuIEZyYW1lIHJl bGF5IHBvcnQgbW9kZSAuIC4gLiAuIC4gLiAuIC4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MTcNCjExLiBGcmFtZSByZWxheSBzZXJ2aWNlIG92ZXIgcHNldWRvLXdpcmVzLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLjIyDQoxMi4gSUFOQSBjb25zaWRlcmF0aW9ucy4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4yNA0KMTMuIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjQNCjE0 LiBTdXBwbGVtZW50IG9uIGZyYW1lIHJlbGF5IGZyYW1lIGZvcm1hdHMuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLjI0DQoxNS4gUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNQ0KMTYuIEF1dGhvcidzIEFkZHJlc3NlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjcNCg0KS2F3YSwg ZXQgYWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgMl0NCg0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICBkcmFmdC1pZXRmLXB3ZTMt ZnJhbWUtcmVsYXktMDMudHh0ICAgICAgIEF1Z3VzdCAyMDA0DQoNCkNvbnZlbnRpb25zIHVz ZWQgaW4gdGhpcyBkb2N1bWVudA0KDQpUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQoiU0hPVUxEIiwgIlNIT1VM RCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMN CmRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIx MTkuDQoNCjEuIEludHJvZHVjdGlvbg0KDQogIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBmcmFt ZSByZWxheSBwc2V1ZG8td2lyZSBlbXVsYXRpb24gZWRnZS10by1lZGdlLg0KICBBIGZyYW1l IHJlbGF5IHBzZXVkby13aXJlIChQVykgaXMgYSBtZWNoYW5pc20gdGhhdCBleGlzdHMgYmV0 d2Vlbg0KICBwcm92aWRlcidzIGVkZ2UgbmV0d29yayBub2RlcyAoUEVzKSBhbmQgc3VwcG9y dHMgYXMgZmFpdGhmdWxseSBhcw0KICAgcG9zc2libGUgZnJhbWUgcmVsYXkgc2VydmljZXMg b3ZlciBJUCBhbmQgTVBMUyBwYWNrZXQgc3dpdGNoZWQNCiAgIG5ldHdvcmsgKFBTTikgdXNp bmcgTVBMUyBMU1AgW1JGQzMwMzEsIFJGQzMwMzJdIGFuZCBMMlRQdjMgW0wyVFB2M10NCiAg IHR1bm5lbHMgZm9yIG11bHRpcGxleGluZyBwdXJwb3Nlcy4gTDJUUHYzIGlzIHVzZWQgb25s eSB3aXRoIElQIFBTTiBpbg0KICAgdGhpcyBkb2N1bWVudC4NCg0KICAgVGhlIG1haW4gZnVu Y3Rpb25zIHJlcXVpcmVkIHRvIHN1cHBvcnQgZnJhbWUgcmVsYXkgUFcgYnkgYSBQRQ0KICAg aW5jbHVkZToNCg0KICAgICAgLSBFbmNhcHN1bGF0aW9uIG9mIGZyYW1lIHJlbGF5IHNwZWNp ZmljIGluZm9ybWF0aW9uIGluIGEgc3VpdGFibGUNCiAgICAgICAgZnJhbWUgcmVsYXkgb3Zl ciBwc2V1ZG8gd2lyZSAoRlJvUFcpIHBhY2tldCwNCg0KICAgICAgLSBUcmFuc2ZlciBvZiBh IEZSb1BXIHBhY2tldCBhY3Jvc3MgYSBQU04gZm9yIGRlbGl2ZXJ5IHRvIGEgcGVlcg0KICAg ICAgICBQRSwNCg0KICAgICAgLSBFeHRyYWN0aW9uIG9mIGZyYW1lIHJlbGF5IHNwZWNpZmlj IGluZm9ybWF0aW9uIGZyb20gYSBGUm9QVw0KICAgICAgICBwYWNrZXQgYnkgdGhlIHJlbW90 ZSBlZGdlIG5vZGUsDQoNCiAgICAgIC0gR2VuZXJhdGlvbiBvZiBuYXRpdmUgZnJhbWUgcmVs YXkgZnJhbWVzIGZvciBmb3J3YXJkaW5nIGFjcm9zcyBhbg0KICAgICAgICBlZ3Jlc3MgcG9y dCBvZiB0aGUgcmVtb3RlIGVkZ2Ugbm9kZSwNCg0KICAgICAgLSBFeGVjdXRpb24gb2YgYW55 IG90aGVyIG9wZXJhdGlvbnMgcmVxdWlyZWQgdG8gc3VwcG9ydCBmcmFtZQ0KICAgICAgICBy ZWxheSBzZXJ2aWNlLg0KDQogICBUaGUgbWFpbiBzdHJ1Y3R1cmUgb2YgdGhpcyBkb2N1bWVu dCBpcyBhcyBmb2xsb3dzOiBTZWN0aW9uIDQgbGlzdHMNCiAgIHNvbWUgaW1wb3J0YW50IGZy YW1lIHJlbGF5IHJlcXVpcmVtZW50cyB0byBiZSBtZXQgaW4gYSBQV0UzDQogICBlbnZpcm9u bWVudC4gU2VjdGlvbiA1IGlzIGFuIG92ZXJ2aWV3IG9mIFBXRTMgcmVmZXJlbmNlIG1vZGVs IGFuZCBQV0UzDQogICBwcm90b2NvbCBsYXllcnMgZGVzY3JpYmVkIGluIFtQV0UzQVJDXS4g U2VjdGlvbiA2IGRlc2NyaWJlcyB0aGUgZ2VuZXJpYw0KICAgZnJhbWUgcmVsYXkgb3ZlciBw c2V1ZG8td2lyZSAoRlJvUFcpIHBhY2tldCBmb3JtYXQuIFNlY3Rpb24gNw0KICAgc3BlY2lm aWVzIGZyYW1lIHJlbGF5IG92ZXIgTVBMUyBQU04gZm9yIHRoZSBvbmUtdG8tb25lIG1hcHBp bmcuDQogICBTZWN0aW9uIDggYWRkcmVzc2VzIEZSIFBWQyBwcm92aXNpb25pbmcuIFNlY3Rp b24gOSBjb3ZlcnMgdGhlIHRyYWZmaWMgDQogICBtYW5hZ2VtZW50IGFzcGVjdHMuIFNlY3Rp b24gMTAgZGVzY3JpYmVzIEZSIHBvcnQgbW9kZSBmb3IgTVBMUyBQU04gYW5kIA0KICAgSVAg UFNOIHdpdGggTDJUUHYzLiBTZWN0aW9uIDExIGRpc2N1c3NlcyB0aGUgbWVhbmluZyBvZiBw cm92aWRpbmcgZnJhbWUgcmVsYXkgDQogICBzZXJ2aWNlcyBpbiB0aGUgbmF0aXZlIGFuZCBQ V0UzIGVudmlyb25tZW50cyBhbmQgaG93IGZhaXRoZnVsbHkvcGVyZmVjdGx5IEZSDQogICBz ZXJ2aWNlIHNob3VsZCBiZSBwcm92aWRlZC4gQSBzdXBwbGVtZW50IG9uIGZyYW1lIHJlbGF5 IGZyYW1lIGZvcm1hdHMNCiAgIGFwcGVhcnMgaW4gU2VjdGlvbiAxNC4NCg0KDQoNCkthd2Es IGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgM10NCg0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICBkcmFmdC1pZXRmLXB3ZTMt ZnJhbWUtcmVsYXktMDMudHh0ICAgICBBdWd1c3QgMjAwNA0KDQoyLiBUZXJtaW5vbG9neQ0K DQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNI QUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01N RU5ERUQiLCAgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFy ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkuICBCZWxvdyBh cmUNCiAgIHRoZSBkZWZpbml0aW9ucyBmb3IgdGhlIHRlcm1zIHVzZWQgdGhyb3VnaG91dCB0 aGUgZG9jdW1lbnQuDQogICBQV0UzIGRlZmluaXRpb25zIGNhbiBiZSBmb3VuZCBpbiBbUFdF M1JFUSwgUFdFM0FSQ10uIFRoaXMgc2VjdGlvbg0KICAgZGVmaW5lcyB0ZXJtcyBzcGVjaWZp YyB0byBmcmFtZSByZWxheS4NCg0KDQogICBCYWNrd2FyZCBkaXJlY3Rpb246ICAgSW4gZnJh bWUgcmVsYXkgaXQgaXMgdGhlIGRpcmVjdGlvbiBvcHBvc2l0ZSB0bw0KICAgICAgICAgICAg ICAgICAgICAgICAgIHRoZSBkaXJlY3Rpb24gdGFrZW4gYnkgYSBmcmFtZSBiZWluZyBmb3J3 YXJkZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAoc2VlIGFsc28gZm9yd2FyZCBkaXJl Y3Rpb24pLg0KDQogICBGb3J3YXJkIGRpcmVjdGlvbjogICAgSW4gZnJhbWUgcmVsYXkgdGhl IHJlZmVyZW5jZSB1c2VkIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgZGV0ZXJtaW5l IHdoZXRoZXIgdGhlIGRpcmVjdGlvbiBvZiB0aGUgdHJhZmZpYw0KICAgICAgICAgICAgICAg ICAgICAgICAgIGlzIHRoZSBmb3J3YXJkIG9yIGJhY2t3YXJkIGRpcmVjdGlvbiBpcyB0aGUN CiAgICAgICAgICAgICAgICAgICAgICAgICBmcmFtZSBiZWluZyBmb3J3YXJkZWQuIFRoZSBm b3J3YXJkIGRpcmVjdGlvbiBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBkaXJl Y3Rpb24gdGFrZW4gYnkgdGhlIGZyYW1lIGJlaW5nDQogICAgICAgICAgICAgICAgICAgICAg ICAgZm9yd2FyZGVkLg0KDQoNCjMuIEFjcm9ueW1zIGFuZCBBYmJyZXZpYXRpb25zDQoNCiAg IEJjICAgICAgQ29tbWl0dGVkIGJ1cnN0IHNpemUNCiAgIEJlICAgICAgRXhjZXNzIGJ1cnN0 IHNpemUNCiAgIEJFQ04gICAgQmFja3dhcmQgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmlj YXRpb24NCiAgIENFICAgICAgQ3VzdG9tZXIgRWRnZQ0KICAgQ0lSICAgICBDb21taXR0ZWQg SW5mb3JtYXRpb24gUmF0ZQ0KICAgQy9SICAgICBDb21tYW5kL1Jlc3BvbnNlDQogICBERSAg ICAgIERpc2NhcmQgRWxpZ2liaWxpdHkNCiAgIERMQ0kgICAgRGF0YSBMaW5rIENvbm5lY3Rp b24gaWRlbnRpZmllcg0KICAgRkNTICAgICBGcmFtZSBDaGVjayBTZXF1ZW5jZQ0KICAgRkVD TiAgICBGb3J3YXJkIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uDQogICBGUiAg ICAgIEZyYW1lIFJlbGF5DQogICBGUm9QVyAgIEZyYW1lIFJlbGF5IG92ZXIgUHNldWRvIFdp cmUNCiAgIEwyVFAgICAgTGF5ZXIgMiBUdW5uZWxpbmcgUHJvdG9jb2wNCiAgIEZSUyAgICAg RnJhbWUgUmVsYXkgU2VydmljZQ0KICAgTFNQICAgICBMYWJlbCBTd2l0Y2hlZCBQYXRoDQog ICBMU1IgICAgIExhYmVsIFN3aXRjaGluZyBSb3V0ZXINCiAgIE1QTFMgICAgTXVsdGlwcm90 b2NvbCBMYWJlbCBTd2l0Y2hpbmcNCiAgIE1UVSAgICAgTWF4aW11bSBUcmFuc2ZlciBVbml0 DQogICBOTkkgICAgIE5ldHdvcmstTmV0d29yayBJbnRlcmZhY2UNCiAgIFBFICAgICAgUHJv dmlkZXIgRWRnZQ0KICAgUFNOICAgICBQYWNrZXQgU3dpdGNoZWQgTmV0d29yaw0KICAgUFcg ICAgICBQc2V1ZG8tV2lyZQ0KICAgUFdFMyAgICBQc2V1ZG8tV2lyZSBFbXVsYXRpb24gRWRn ZSB0byBFZGdlDQogICBQT1MgICAgIFBhY2tldCBvdmVyIFNPTkVUL1NESA0KICAgUFZDICAg ICBQZXJtYW5lbnQgVmlydHVhbCBDaXJjdWl0DQogICBRb1MgICAgIFF1YWxpdHkgb2YgU2Vy dmljZQ0KICAgU0xBICAgICBTZXJ2aWNlIExldmVsIEFncmVlbWVudA0KICAgU1BWQyAgICBT d2l0Y2hlZC9Tb2Z0IHBlcm1hbmVudCB2aXJ0dWFsIGNpcmN1aXQNCiAgIFNWQyAgICAgU3dp dGNoZWQgVmlydHVhbCBDaXJjdWl0DQogICBVTkkgICAgIFVzZXItTmV0d29yayBJbnRlcmZh Y2UNCiAgIFZDICAgICAgVmlydHVhbCBDaXJjdWl0DQoNCkthd2EsIGV0IGFsLiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoN CgwNCkludGVybmV0IERyYWZ0ICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAz LnR4dCAgICAgIEF1Z3VzdCAyMDA0DQoNCjQuIFJlcXVpcmVtZW50cyBmb3IgRnJhbWUgUmVs YXkgT3ZlciBQc2V1ZG8tV2lyZXMNCg0KICAgVGhlIHNlY3Rpb24gbGlzdHMgdGhlIG1haW4g ZnJhbWUgcmVsYXkgcHNldWRvLXdpcmUgcmVxdWlyZW1lbnRzIHRvDQogICBiZSBtZXQgYnkg YSBQRToNCg0KMS4gRnJhbWUgTGVuZ3RoOiBNVVNUIGJlIGFibGUgdG8gdHJhbnNwb3J0IHZh cmlhYmxlIGxlbmd0aCBGUiANCiAgIGZyYW1lcyBhbmQgU0hPVUxEIGJlIGFibGUgdG8gdHJh bnNwb3J0IEZSIGZyYW1lcyB3aXRob3V0IGJlaW5nDQogICBsaW1pdGVkIGJ5IHRoZSBQU04g TVRVIHRocm91Z2ggdGhlIHVzZSBvZiBQVyBmcmFnbWVudGF0aW9uIFtGUkFHXS4gDQogICAg IA0KICAgICAgICAyLiBCaWRpcmVjdGlvbmFsIHRyYWZmaWM6IE1VU1Qgc3VwcG9ydCBiaWRp cmVjdGlvbmFsIHRyYWZmaWMuDQogICAgIA0KICAgICAgICAzLiBGcmFtZSBvcmRlcmluZzog TVVTVCBkZWxpdmVyIGZyYW1lIHJlbGF5IGZyYW1lcyBpbiB0aGUgb3JkZXIuDQogICAgICAg ICAgIGFzIHRoZXkgd2VyZSB0cmFuc21pdHRlZC4NCiAgICAgDQogICAgICAgIDQuIENvbnRy b2wgYml0czogTVVTVCBzdXBwb3J0IHRoZSB0cmFuc3BvcnQgb2YgRlIgRGlzY2FyZA0KICAg ICAgICAgICBFbGlnaWJpbGl0eSAoREUpLCBGb3J3YXJkIEV4cGxpY2l0IENvbmdlc3Rpb24g Tm90aWZpY2F0aW9uDQogICAgICAgICAgIChGRUNOKSwgQmFja3dhcmQgRXhwbGljaXQgQ29u Z2VzdGlvbiBOb3RpZmljYXRpb24gKEJFQ04pIGFuZA0KICAgICAgICAgICBDb21tYW5kL1Jl c3BvbnNlIChDL1IpIGJpdHMgW1gzNiwgWDc2XS4NCiAgICAgDQogICAgICAgIDUuIFBWQyBT dGF0dXMgTWFpbnRlbmFuY2U6IE1VU1Qgc3VwcG9ydCB0aGUgbWFwcGluZyBhbmQgdHJhbnNw b3J0DQogICAgICAgICAgIG9mIGZyYW1lIHJlbGF5IFBWQyBzdGF0dXMgaW5kaWNhdGlvbnMg ZGVmaW5lZCBpbiBJVFUtVCANCiAgICAgICAgICAgUmVjb21tZW5kYXRpb24gWC4zNiBbWDM2 XS4gIE5vdGUgUFZDIHN0YXR1cyBzaWduYWxpbmcgd2lsbCBiZSANCiAgICAgICAgICAgYWRk cmVzc2VkIGluIGFub3RoZXIgSUVURiBkcmFmdC4NCiAgICAgDQogICAgICAgIDYuIFRyYWZm aWMgTWFuYWdlbWVudDogU0hPVUxEIGJlIGFibGUgdG8gbWFwIHRoZSBmb2xsb3dpbmcgRlIN CiAgICAgICAgICAgdHJhZmZpYyBtYW5hZ2VtZW50IHBhcmFtZXRlcnMgdG8gUFdzIGFuZCB0 dW5uZWwgdHJhZmZpYw0KICAgICAgICAgICBwYXJhbWV0ZXJzOg0KICAgICANCiAgICAgICAg ICAgICAgYSkgQ29tbWl0dGVkIEluZm9ybWF0aW9uIFJhdGUgKENJUikgb3IgdGhyb3VnaHB1 dCwNCiAgICAgICAgICAgICAgYikgQ29tbWl0dGVkIGJ1cnN0IHNpemUgKEJjKSwNCiAgICAg ICAgICAgICAgYykgRXhjZXNzIEJ1cnN0IFNpemUgKEJlKSwNCiAgICAgICAgICAgICAgZCkg TWF4aW11bSBmcmFtZSBzaXplLg0KICAgICANCiAgICAgICAgIDcuIEZyYW1lIFByaW9yaXR5 IGFuZCBRb1M6IFNIT1VMRCBzdXBwb3J0IHRoZSBhYmlsaXR5IHRvIG1hcCBGUg0KICAgICAg ICAgICAgdHJhbnNmZXIgYW5kIGRpc2NhcmQgcHJpb3JpdGllcyBvciBRb1Mgc2VydmljZSBj bGFzc2VzIGRlZmluZWQNCiAgICAgICAgICAgIGluIFtYMzYsIFg3Nl0gdG8gYXBwcm9wcmlh dGVseSBlbmdpbmVlcmVkIFBXcyBhbmQgUFNOIHR1bm5lbHMuDQoNCg0KNS4gUmVmZXJlbmNl IG1vZGVsIGFuZCBQV0UzIHByb3RvY29sIGxheWVyaW5nDQoNCiAgIDUuMS4gUmVmZXJlbmNl IG1vZGVsDQoNCiAgICAgIEZpZ3VyZSAxIHNob3dzIFBXRTMgcmVmZXJlbmNlIG1vZGVsIHdp dGggYWRkaXRpb25hbCBmcmFtZSByZWxheQ0KICAgICAgY29uY2VwdHMuIE1vcmUgZGV0YWls cyBvbiB0aGUgcmVmZXJlbmNlIG1vZGVsIGNhbiBiZSBmb3VuZCBpbg0KICAgICAgW1BXRTNS RVEsIFBXRTNBUkNdLg0KDQoNCg0KDQpLYXdhLCBldCBhbC4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDQoMDQpJbnRlcm5l dCBEcmFmdCAgICAgIGRyYWZ0LWlldGYtcHdlMy1mcmFtZS1yZWxheS0wMy50eHQgICAgICBB dWd1c3QgMjAwNA0KDQoNCiAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0gRW11bGF0ZWQg U2VydmljZSAtLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgIHwg ICAgICAgICAgfDwtLS0tLS0tIFBzZXVkbyBXaXJlIC0tLS0tLT58ICAgICAgICAgIHwNCiAg ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgIHwNCiAgICAgICAgICAgIHwgICAgICAgICAgfCAgICB8PC0tIFBTTiBUdW5uZWwg LS0+fCAgICB8ICAgICAgICAgIHwNCiAgICAgICAgICAgIHwgICAgICAgICAgViAgICBWICAg ICAgICAgICAgICAgICAgViAgICBWICAgICAgICAgIHwNCiAgICAgICAgICAgIFYgICAgQUMg ICAgKy0tLS0rICAgICAgICAgICAgICAgICAgKy0tLS0rICAgICBBQyAgIFYNCiAgICAgICst LS0tLSsgICAgfCAgICAgfCBQRTF8PT09PT09PT09PT09PT09PT09fCBQRTJ8ICAgICB8ICAg ICstLS0tLSsNCiAgICAgIHwgICAgIHwtLS0tLS0tLS0tfC4uLi4uLi4uLi4uLlBXMS4uLi4u Li4uLi4uLi58LS0tLS0tLS0tLXwgICAgIHwNCiAgICAgIHwgQ0UxIHwgICAgfCAgICAgfCAg ICB8ICAgICAgICAgICAgICAgICAgfCAgICB8ICAgICB8ICAgIHwgQ0UyIHwNCiAgICAgIHwg ICAgIHwtLS0tLS0tLS0tfC4uLi4uLi4uLi4uLlBXMi4uLi4uLi4uLi4uLi58LS0tLS0tLS0t LXwgICAgIHwNCiAgICAgICstLS0tLSsgIF4gfCAgICAgfCAgICB8PT09PT09PT09PT09PT09 PT09fCAgICB8ICAgICB8IF4gICstLS0tLSsNCiAgICAgICAgICAgIF4gIHwgICAgICAgKy0t LS0rICAgICAgICAgICAgICAgICAgKy0tLS0rICAgICB8IHwgIF4NCiAgICAgICAgICAgIHwg IHwgICBQcm92aWRlciBFZGdlIDEgICAgICAgICBQcm92aWRlciBFZGdlIDIgIHwgIHwNCiAg ICAgICAgICAgIHwgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgIHwNCiAgICAgIEN1c3RvbWVyIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgQ3VzdG9tZXINCiAgICAgIEVkZ2UgMSAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgRWRnZSAyDQogICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgICBuYXRpdmUgc2VydmljZSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBuYXRpdmUgc2VydmljZSANCg0KICAgICAgICAgICAgICAgICAgICAgRmlndXJl IDEgLSBQV0UzIFJlZmVyZW5jZSBNb2RlbA0KDQogICAgVHdvICBtYXBwaW5nIG1vZGVzIGFy ZSBkZWZpbmVkIGJldHdlZW4gRlIgVkNzIGFuZCBwc2V1ZG8td2lyZXM6IA0KICAgIFRoZSBm aXJzdCBvbmUgaXMgY2FsbGVkICJvbmUtdG8tb25lIiBtYXBwaW5nLCBiZWNhdXNlIHRoZXJl IGlzIGEgDQogICAgb25lLXRvLW9uZSBjb3JyZXNwb25kZW5jZSBiZXR3ZWVuIGEgRlIgVkMg YW5kIG9uZSBQc2V1ZG8gV2lyZS4gDQogICAgVGhlIHNlY29uZCBtYXBwaW5nIGlzIGNhbGxl ZCAibWFueS10by1vbmUiIG1hcHBpbmcgb3IgInBvcnQgbW9kZSIgDQogICAgQmVjYXVzZSBt dWx0aXBsZSBGUiBWQ3MgYXNzaWduZWQgdG8gYSBwb3J0IGFyZSBtYXBwZWQgdG8gb25lIFBz ZXVkbyBXaXJlLg0KICAgIE9uZS10by1vbmUgbWFwcGluZyBtb2RlIGlzIGRlZmluZWQgZm9y IE1QTFMgUFNOcyBvbmx5IGFuZCBwb3J0IG1vZGUgaXMNCiAgICBkZWZpbmVkIGZvciBib3Ro IE1QTFMgUFNOIGFuZCBJUCBQU04gd2l0aCBMMlRQdjMuDQoNCiAgICBBcyBzcGVjaWZpZWQg bGF0ZXIgaW4gdGhpcyBkb2N1bWVudCwgdGhlIGVuY2Fwc3VsYXRpb24gb2YgZnJhbWUNCiAg ICByZWxheSBpbmZvcm1hdGlvbiBpcyBzbGlnaHRseSBkaWZmZXJlbnQgYmV0d2VlbiB0aGUg dHdvIG1hcHBpbmcNCiAgICBtb2Rlcy4NCg0KDQogICA1LjIuIEZyYW1lIHJlbGF5IG92ZXIg UFcgYW5kIFBXRTMgcHJvdG9jb2wgbGF5ZXJpbmcNCiAgIA0KICAgICAgICAgVGhpcyBkb2N1 bWVudCBzdXBwb3J0cyBNUExTIFBTTnMgYW5kIElQIFBTTnMuIFdpdGggSVAgUFNOcywgTDJU UFYzDQogICAgICAgICBbTDJUUHYzXSBpcyB1c2VkIGZvciBtdWx0aXBsZXhpbmcgcHVycG9z ZXMgb2YgYSBudW1iZXIgb2YgRlIgVkNzDQogICAgICAgICBpbnRvIG9uZSBMMlRQdjMgdHVu bmVsLiBJbiBhZGRpdGlvbiwgdGhlIG9uZS10by1vbmUgbWFwcGluZyBtb2RlDQogICAgICAg ICBhcHBsaWVzIHRvIGZyYW1lIHJlbGF5IG92ZXIgTVBMUyBQU04gb25seSBhbmQgdGhlIG1h bnktdG8tb25lDQogICAgICAgICBtYXBwaW5nIG1vZGUgYXBwbGllcyB0byBib3RoIGZyYW1l IHJlbGF5IG92ZXIgTVBMUyBQU05zIGFuZCBJUCBQU05zDQogICAgICAgICB3aXRoIEwyVFB2 My4gSW4gdGVybXMgb2YgUFdFMyBwcm90b2NvbCBsYXllcmluZyBkZWZpbmVkIGluIFtQV0Uz QVJDXSwNCiAgICAgICAgIHRoaXMgc3BlY2lmaWNhdGlvbiB1dGlsaXplcyB0aGUgcHJvdG9j b2wgc3RhY2sgc2hvd24gaW4gRmlndXJlIDIuDQogICANCiAgDQogIA0KICAgDQogICANCiAg IA0KS2F3YSwgZXQgYWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgNl0NCgwgICANCiAgIA0KSW50ZXJuZXQgRHJhZnQgICAgICBk cmFmdC1pZXRmLXB3ZTMtZnJhbWUtcmVsYXktMDMudHh0ICAgICAgQXVndXN0IDIwMDQNCiAg IA0KICAgDQogICANCiAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQogICAgICB8ICBFbXVsYXRlZCAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIEVtdWxhdGVkICAgfA0KICAgICAgfCBG cmFtZSBSZWxheSB8ICAgICAgICAgRW11bGF0ZWQgU2VydmljZSAgICAgICB8IEZyYW1lIFJl bGF5IHwNCiAgICAgIHwgIFNlcnZpY2VzICAgfDw9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0+fCAgU2VydmljZXMgICB8DQogICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfA0KICAgICAgKy0tLS0tLS0t LS0tLS0rICAgICAgICAgICBQc2V1ZG8gV2lyZSAgICAgICAgICArLS0tLS0tLS0tLS0tLSsN CiAgICAgIHxEZW11bHRpcGxleGVyfDw9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0+ fERlbXVsdGlwbGV4ZXJ8DQogICAgICArLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKw0KICAgICAgfCAgICBQU04gICAgICB8 ICAgICAgICAgICAgUFNOIFR1bm5lbCAgICAgICAgICB8ICAgIFBTTiAgICAgIHwNCiAgICAg IHwgTVBMUyBvciBJUCAgfDw9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0+fCBNUExT IG9yIElQICB8DQogICAgICArLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tKw0KICAgICAgfCAgUGh5c2ljYWwgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBQaHlzaWNhbCAgIHwNCiAgICAgICstLS0t LSstLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tKy0tLS0t LS0rDQogICANCiAgICAgICAgICAgIFBFMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUEUyDQogICANCiAgICAgICAgIEZpZ3VyZSAyOiBGcmFtZSBSZWxh eSBQV0UzIFByb3RvY29sIFN0YWNrIFJlZmVyZW5jZSBNb2RlbA0KICAgDQogICANCiAgICAg IEZvciB0aGUgcHVycG9zZSBvZiB0aGlzIGRvY3VtZW50LCBQRTEgaXMgZGVmaW5lZCBhcyB0 aGUgaW5ncmVzcw0KICAgICAgcm91dGVyLCBhbmQgUEUyIGFzIHRoZSBlZ3Jlc3Mgcm91dGVy LiBBIGxheWVyIDIgUERVIHJlY2VpdmVkDQogICAgICBhdCBQRTEsIHdpbGwgYmUgZW5jYXBz dWxhdGVkIGF0IFBFMSwgdHJhbnNwb3J0ZWQsIGRlY2Fwc3VsYXRlZCBhdCBQRTIsIA0KICAg ICAgYW5kIHRyYW5zbWl0dGVkIG91dCBvZiBQRTIuDQogICANCg0KDQo2LiBHZW5lcmFsIGVu Y2Fwc3VsYXRpb24gZm9yIHRoZSB0d28gbWFwcGluZyBtb2Rlcw0KDQogICBUaGUgZ2VuZXJh bCBmcmFtZSByZWxheSBvdmVyIHBzZXVkby13aXJlcyAoRlJvUFcpIHBhY2tldCBmb3JtYXQN CiAgIGZvciBjYXJyeWluZyBmcmFtZSByZWxheSBpbmZvcm1hdGlvbiAodXNlcidzIHBheWxv YWQgYW5kIGZyYW1lDQogICByZWxheSBjb250cm9sIGluZm9ybWF0aW9uKSBiZXR3ZWVuIHR3 byBQRXMgaXMgc2hvd24gaW4gRmlndXJlIDMuDQoNCg0KICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgIHwgIFBTTiBUcmFuc3BvcnQgaGVhZGVyICAgICAg ICAgfA0KICAgICAgICAgIHwgICAgICAgKEFzIHJlcXVpcmVkKSAgICAgICAgICAgfA0KICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgIHwg ICBQc2V1ZG8gV2lyZSAoUFcpIEhlYWRlciAgICAgfA0KICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgIHwgICAgICAgIENvbnRyb2wgV29y ZCAgICAgICAgICAgfA0KICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KICAgICAgICAgIHwgICAgICAgICAgRlIgU2VydmljZSAgICAgICAgICAgfA0KICAg ICAgICAgIHwgICAgICAgICAgIFBheWxvYWQgICAgICAgICAgICAgfA0KICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgIHwgICAgICAgICBQ YWQgKGlmIHJlcXVpcmVkKSAgICAgfA0KICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KDQogICAgIEZpZ3VyZSAzIC0gR2VuZXJhbCBmb3JtYXQgb2YgRlIg ZW5jYXBzdWxhdGlvbiBvdmVyIFBTTg0KDQoNCkthd2EsIGV0IGFsLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMICAgDQog ICANCkludGVybmV0IERyYWZ0ICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAz LnR4dCAgICAgIEF1Z3VzdCAyMDA0DQoNClRoZSBGUm9QVyBwYWNrZXQgY29uc2lzdHMgb2Yg dGhlIGZvbGxvd2luZyBmaWVsZHM6IENvbnRyb2wgd29yZCwgDQpQYXlsb2FkIGFuZCBQYWQg KGlmIHJlcXVpcmVkKSBwcmVjZWRlZCBieSBQU04gVHJhbnNwb3J0IGFuZCBwc2V1ZG8td2ly ZQ0KaGVhZGVyLg0KDQpUaGUgbWVhbmluZyBvZiB0aGUgZGlmZmVyZW50IGZpZWxkcyBpcyBh cyBmb2xsb3dzOg0KDQogICAgICAxLiBQU04gVHJhbnNwb3J0IGhlYWRlciBpcyBzcGVjaWZp YyB0byB0aGUgUFNOIGFuZCB0aGUgdHVubmVsaW5nDQogICAgICAgICB0ZWNobm9sb2d5IHVz ZWQgKEwyVFAgb3IgTVBMUykgVGhpcyBoZWFkZXIgaXMgdXNlZCB0byBzd2l0Y2ggDQogICAg ICAgICB0aGUgRlJvUFcgcGFja2V0IHRocm91Z2ggdGhlIHBhY2tldCBzd2l0Y2hlZCBjb3Jl LiBJdCBpcyBkZXNjcmliZWQNCiAgICAgICAgIGluIHRoZSBmb2xsb3dpbmcgc3ViLXNlY3Rp b25zIGFkZHJlc3NpbmcgZWFjaCB0eXBlIG9mIFBTTiBhbmQNCiAgICAgICAgIHR1bm5lbGlu ZyB0ZWNobm9sb2d5Lg0KDQogICAgICAyLiBQVyBoZWFkZXIgY29udGFpbnMgYW4gaWRlbnRp ZmllciBmb3IgbXVsdGlwbGV4aW5nIFBXcyB3aXRoaW4gYSANCiAgICAgICAgIFBTTiB0dW5u ZWwuDQoNCiAgICAgIDMuIENvbnRyb2wgV29yZCBjb250YWlucyBwcm90b2NvbCBjb250cm9s IGluZm9ybWF0aW9uIGZvcg0KICAgICAgICAgcHJvdmlkaW5nIGEgZnJhbWUgcmVsYXkgc2Vy dmljZS4gSXRzIHN0cnVjdHVyZSBpcyBwcm92aWRlZCBpbg0KICAgICAgICAgdGhlIGZvbGxv d2luZyBzZWN0aW9ucyBhZGRyZXNzaW5nIGVhY2ggbWFwcGluZyBtb2RlLg0KDQogICAgICA0 LiBUaGUgY29udGVudHMgb2YgdGhlIEZSIHNlcnZpY2UgcGF5bG9hZCBmaWVsZCBkZXBlbmRz IG9uIHRoZSBtYXBwaW5nDQogICAgICAgICBtb2RlLiAgVGhlIGRldGFpbHMgYXJlIHByb3Zp ZGVkIGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMgYWRkcmVzc2luZw0KICAgICAgICAgZWFj aCBtYXBwaW5nIG1vZGUuDQoNCiAgICAgICAgIFRoZSBQYWQgaXMgdXNlZCBmb3IgdGhlIGZv bGxvd2luZyByZWFzb246IFdoZW4gYSBwc2V1ZG8td2lyZQ0KICAgICAgICAgdHJhdmVyc2Vz IGEgbGluayB0aGF0IHJlcXVpcmVzIGEgbWluaW11bSBMYXllciAyIGZyYW1lIGxlbmd0aA0K ICAgICAgICAgKGZvciBleGFtcGxlLCBFdGhlcm5ldCksIHBhZGRpbmcgb2N0ZXRzIGFyZSBh ZGRlZCBhdCB0aGUNCiAgICAgICAgIGVuZCBvZiB0aGUgRlJvUFcgcGFja2V0IChpLmUuIGFm dGVyIHRoZSBwYXlsb2FkIGZpZWxkKSB0bw0KICAgICAgICAgcHJvZHVjZSB0aGUgcmVxdWly ZWQgbWluaW11bSBsZW5ndGguDQoNCg0KNy4gRnJhbWUgUmVsYXkgb3ZlciBNUExTIFBTTiBm b3IgdGhlIE9uZS10by1PbmUgTWFwcGluZyBNb2RlDQoNCiAgIDcuMS4gTVBMUyBUdW5uZWwg YW5kIFZDIExTUHMNCg0KICAgICAgTVBMUyBsYWJlbCBzd2l0Y2hlZCBwYXRocyAoTFNQcykg Y2FsbGVkICJUdW5uZWwgTFNQcyIgYXJlIHVzZWQNCiAgICAgIGJldHdlZW4gUEVzIGFuZCB3 aXRoaW4gdGhlIE1QTFMgUFNOIGNvcmUgbmV0d29yayBmb3IgZm9yd2FyZGluZyBwdXJwb3Nl cw0KICAgICAgb2YgRlJvUFcgcGFja2V0cy4gQSB0dW5uZWwgTFNQIGNvcnJlc3BvbmRzIHRv ICJQU04gdHJhbnNwb3J0IiBvZg0KICAgICAgRmlndXJlIDEuDQoNCiAgICAgIFNldmVyYWwg ICJWaXJ0dWFsIENpcmN1aXQgTFNQcyIgKFZDIExTUHMpIG1heSBiZSBuZXN0ZWQgaW5zaWRl IG9uZQ0KICAgICAgVHVubmVsIExTUC4gRWFjaCBWQyBMU1AgY2FycmllcyB0aGUgdHJhZmZp YyBvZiBhIGZyYW1lIHJlbGF5IFZDIGluDQogICAgICBvbmUgZGlyZWN0aW9uLiBTaW5jZSBM U1BzIGFyZSB1bmlkaXJlY3Rpb25hbCwgYW5kIGZyYW1lIHJlbGF5IFZDcyBhcmUNCiAgICAg IGJpZGlyZWN0aW9uYWwsIGEgcGFpciBvZiBWQyBMU1BzIGFuZCBjb3JyZXNwb25kaW5nIHR1 bm5lbCBMU1BzIGNhcnJ5aW5nDQogICAgICB0cmFmZmljIGluIG9wcG9zaXRlIGRpcmVjdGlv bnMgd2lsbCBiZSByZXF1aXJlZC4NCg0KDQoNCg0KDQoNCg0KS2F3YSwgZXQgYWwuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0N Cg0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICBkcmFmdC1pZXRmLXB3ZTMtZnJhbWUtcmVsYXkt MDMudHh0ICAgICAgQXVndXN0IDIwMDQNCg0KDQoNCiAgICAgIEluIHRoZSBQRTEgdG8gUEUy IGRpcmVjdGlvbiBhIHR1bm5lbCBMU1AgaXMgdXNlZCBmb3IgZm9yd2FyZGluZyBGUm9QVw0K ICAgICAgcGFja2V0cyBmcm9tIFBFMSB0byBQRTIsIGFuZCB0aGUgdHVubmVsIExTUCBsYWJl bCBpcyBub3QgcmVsYXRlZA0KICAgICAgdG8gYW55IHBhcnRpY3VsYXIgZnJhbWUgcmVsYXkg VkMuIFdoZW4gUEUxIGhhcyB0byBmb3J3YXJkIGEgRlJvUFcgcGFja2V0DQogICAgICB0byBQ RTIsIGl0IGZpcnN0IHB1c2hlcyBhIFZDIGxhYmVsIG9uIGl0cyBsYWJlbCBzdGFjaywgYW5k IHRoZW4NCiAgICAgIHB1c2hlcyBvbiBhIHR1bm5lbCBMU1AgbGFiZWwuIFRoZSBWQyBsYWJl bCBpcyBhdCB0aGUgYm90dG9tIG9mDQogICAgICB0aGUgbGFiZWwgc3RhY2suIEFzIHdpdGgg dGhlIG90aGVyIFBXRTMgZW5jYXBzdWxhdGlvbnMsIHRoZSANCiAgICAgIFZDIGxhYmVsIGlz IG5vdCB2aXNpYmxlIGluIHRoZSBjb3JlIFBTTiwgb25seSB0aGUgdHVubmVsIExTUCBsYWJl bCBhbmQgDQogICAgICBwb3NzaWJseSBvdGhlciBsYWJlbHMgdXNlZCBpbiB0aGUgY29yZSBQ U04gZm9yIGZvcndhcmRpbmcgcHVycG9zZXMgdW50aWwgDQogICAgICB0aGUgRlJvUFcgcGFj a2V0IHJlYWNoZXMgUEUyLiBXaGlsZSB0aGUgRlJvUFcgcGFja2V0IHRyYXZlbHMgYWNyb3Nz IHRoZQ0KICAgICAgTVBMUyBuZXR3b3JrLCBhZGRpdGlvbmFsIGxhYmVscyBtYXkgYmUgcHVz aGVkIG9uIChhbmQgdGhlbiBwb3BwZWQgb2ZmKQ0KICAgICAgYXMgbmVlZGVkLiBXaGVuIFBF MiByZWNlaXZlcyBhIEZSb1BXIHBhY2tldCwgaXQgZm9yd2FyZHMgdGhlDQogICAgICBwYWNr ZXQgdG8gdGhlIGxvY2FsIENFIGJhc2VkIG9uIHRoZSBMU1AgVkMgbGFiZWwuIFRoZSBwcm9j ZXNzaW5nDQogICAgICBpcyBzaW1pbGFyIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24gZnJv bSBQRTIgdG8gUEUxIHdpdGggdGhlDQogICAgICBjb3JyZXNwb25kaW5nIExTUCB1c2VkIGlu IHRoZSBQRTIgdG8gUEUxIGZvcndhcmRpbmcgZGlyZWN0aW9uLg0KDQoNCiAgIDcuMi4gUmVs YXRpb25zaGlwIGJldHdlZW4gRlIgVkNzIGFuZCBNUExTIFZDIExTUHMNCg0KICAgICAgRnJh bWUgcmVsYXkgVkNzIGFyZSBjb25zaWRlcmVkIHRvIGJlIGJpZGlyZWN0aW9uYWwgb2JqZWN0 cyBtYWlubHkgDQogICAgICBiZWNhdXNlIG9mIHRoZSB3YXkgdGhleSBhcmUgY3JlYXRlZCBh bmQgaWRlbnRpZmllZC4gQSBzaW5nbGUgZnJhbWUNCiAgICAgIHJlbGF5IGlkZW50aWZpZXIg KERMQ0kpIHJlZmVycyB0byB0aGUgdHdvIGRpcmVjdGlvbnMgb2YgYSBmcmFtZQ0KICAgICAg cmVsYXkgVkMgYW5kIGZyYW1lIHJlbGF5IHNpZ25hbGluZyBlc3RhYmxpc2hlcyB0aGUgdHdv IGRpcmVjdGlvbnMNCiAgICAgIHNpbXVsdGFuZW91c2x5IHdpdGggYSBzaW5nbGUgc2V0IG9m IGNvbnRyb2wgbWVzc2FnZXMgZmxvd3MuIA0KICAgICAgSW4gZ2VuZXJhbCBlYWNoIGRpcmVj dGlvbiBvZiBhIGZyYW1lIHJlbGF5IFZDIG1heSBoYXZlIGRpZmZlcmVudCANCiAgICAgIHRy YWZmaWMgYW5kIFFvUyBjaGFyYWN0ZXJpc3RpY3MuIFRoZSByZXNvdXJjZSBtYW5hZ2VtZW50 IG9mIGEgZnJhbWUgDQogICAgICByZWxheSBpbXBsZW1lbnRhdGlvbiB0cmVhdHMgZWFjaCBk aXJlY3Rpb24gc2VwYXJhdGVseSBhbmQgaW5kZXBlbmRlbnRseS4NCiAgICAgIE1QTFMgTFNQ cywgb24gdGhlIG90aGVyIGhhbmQgYXJlIHVuaWRpcmVjdGlvbmFsIGFuZCBhcmUNCiAgICAg IGVzdGFibGlzaGVkIHNlcGFyYXRlbHkuIFRoZXJlZm9yZSBmb3IgZWFjaCBGUiBWQyB0aGVy ZSB3aWxsIGJlLCBpbg0KICAgICAgZ2VuZXJhbCwgdHdvIFZDIExTUHMgc3VjaCB0aGF0IGVh Y2ggb25lIHdpbGwgYmUgYXNzaWduZWQgdG8gY2FycnkNCiAgICAgIHRoZSB0cmFmZmljIGlu IGEgc2luZ2xlIGRpcmVjdGlvbi4NCg0KICAgICAgRHVyaW5nIHRoZSBjcmVhdGlvbiBvZiBh IGZyYW1lIHJlbGF5IFZDLCBhIHBhaXIgb2YgVkMgTFNQcyB3aWxsDQogICAgICBoYXZlIHRv IGJlIGVzdGFibGlzaGVkIGJldHdlZW4gdHdvIFBFcy4gRm9yIG9uZSBlbmQtdG8tZW5kIGZy YW1lDQogICAgICByZWxheSBWQyB0d28gVkMgTFNQcyBleGlzdDogT25lIFZDIExTUCB0byB0 cmFuc3BvcnQgdGhlIHRyYWZmaWMNCiAgICAgIGZyb20gUEUxIHRvIFBFMiBhbmQgdGhlIG90 aGVyIHRvIHRyYW5zcG9ydCB0aGUgdHJhZmZpYyBpbiB0aGUNCiAgICAgIG9wcG9zaXRlIGRp cmVjdGlvbi4gSW4gdGhlIGZyYW1lIHJlbGF5IGRvbWFpbiwgYSBETENJIGlkZW50aWZpZXMg YQ0KICAgICAgZnJhbWUgcmVsYXkgVkMgYW5kIGluIHRoZSBNUExTIGRvbWFpbiwgVkMgTFNQ IGxhYmVscyB3aXRoIHBvc3NpYmxlDQogICAgICBkaWZmZXJlbnQgdmFsdWVzIGlkZW50aWZ5 IGVhY2ggVkMgTFNQLiBUaGlzIG1hcHBpbmcgYmV0d2VlbiBhIEZSDQogICAgICBWQyBhbmQg YSBwYWlyIG9mIE1QTFMgTFNQcyBjb3JyZXNwb25kcyB0byB0aGUgb25lLXRvLW9uZSBtYXBw aW5nDQogICAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiA1Lg0KDQoNCiAgIDcuMy4gT25lLXRv LU9uZSBNYXBwaW5nIGFuZCBGUm9QVyBQYWNrZXQgRm9ybWF0IG92ZXIgTVBMUyBQU04NCg0K ICAgICAgRm9yIHRoZSBvbmUtdG8tb25lIG1hcHBpbmcgbW9kZSBmb3IgZnJhbWUgcmVsYXkg b3ZlciBNUExTIFBTTiwgdGhlDQogICAgICBGUm9QVyBwYWNrZXQgZm9ybWF0IGlzIHNob3du IGluIEZpZ3VyZSA0Lg0KDQoNCg0KDQoNCg0KDQoNCkthd2EsIGV0IGFsLiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgIDldDQoNCgwN CkludGVybmV0IERyYWZ0ICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAzLnR4 dCAgICAgICBBdWd1c3QgMjAwNA0KDQoNCg0KICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KICAgICAgIHwgICAgICBUdW5uZWwgTFNQIGxhYmVsKHMpICAgICAg fCBuKjQgb2N0ZXRzIChmb3VyIG9jdGV0cyBwZXIgbGFiZWwpDQogICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgfCAgICAgIFZDIExTUCBsYWJlbCAg ICAgICAgICAgICB8ICA0IG9jdGV0cyANCiAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCiAgICAgICB8ICAgICAgIENvbnRyb2wgV29yZCAgICAgICAgICAgIHwN CiAgICAgICB8ICAgICAgKFNlZSBGaWd1cmUgNSkgICAgICAgICAgIHwgNCBvY3RldHMgDQog ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgfCAgICAg ICAgICAgICBQYXlsb2FkICAgICAgICAgICB8DQogICAgICAgfCAgICAgICAoRnJhbWUgcmVs YXkgZnJhbWUgICAgICB8DQogICAgICAgfCAgICAgICAgaW5mb3JtYXRpb24gZmllbGQpICAg ICB8IG4gb2N0ZXRzDQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgfCAg ICAgICAgUGFkIChpZiByZXF1aXJlZCkgICAgICB8DQogICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICBGaWd1cmUgNCAtIEZSIE92ZXIgTVBMUyBQYWNr ZXQgRm9ybWF0IGZvciB0aGUgT25lLXRvLU9uZSBNYXBwaW5nDQoNClRoZSBlbmNhcHN1bGF0 aW9uIGNvbnNpc3RzIG9mIHRoZSBmb2xsb3dpbmcgZmllbGRzOiBDb250cm9sIFdvcmQsDQpQ YXlsb2FkIGFuZCBQYWQgKGlmIHJlcXVpcmVkKSwgcHJlY2VkZWQgYnkgdGhlIFR1bm5lbCBM U1AgbGFiZWwocykgYW5kIA0KVkMgTFNQIGxhYmVsLg0KDQpUaGUgbWVhbmluZyBvZiB0aGUg ZGlmZmVyZW50IGZpZWxkcyBpcyBhcyBmb2xsb3dzOg0KDQogICAgICBUdW5uZWwgTFNQIGxh YmVsKHMpOg0KICAgICAgICAgVGhlIFR1bm5lbCBMU1AgbGFiZWwocykgY29ycmVzcG9uZHMg dG8gdGhlIFBTTiB0cmFuc3BvcnQgaGVhZGVyDQogICAgICAgICBvZiBGaWd1cmUgMy4gVGhl IGxhYmVsKHMpIGlzL2FyZSB1c2VkIGJ5IE1QTFMgUFNOIG5vZGVzIHRvDQogICAgICAgICBm b3J3YXJkIGEgRlJvUFcgcGFja2V0IGZyb20gb25lIFBFIHRvIHRoZSBvdGhlci4NCg0KICAg ICAgVkMgTFNQIExhYmVsOg0KICAgICAgICAgVGhlIFZDIExTUCBsYWJlbCBpZGVudGlmaWVz IG9uZSBQVyAoaS5lLiBvbmUgTFNQKSBhc3NpZ25lZCB0byBhDQogICAgICAgICBGUiBWQyBp biBvbmUgZGlyZWN0aW9uLiBJdCBjb3JyZXNwb25kcyB0byB0aGUgUFcgDQogICAgICAgICBo ZWFkZXIgb2YgRmlndXJlIDMuIFRvZ2V0aGVyIHRoZSBUdW5uZWwgTFNQIGxhYmVsKHMpIGFu ZCBWQw0KICAgICAgICAgTFNQIGxhYmVsIGZvcm0gYW4gTVBMUyBsYWJlbCBzdGFjayBbUkZD MzAzMl0uDQoNCiAgICAgIENvbnRyb2wgV29yZDoNCiAgICAgICAgIENvbnRyb2wgV29yZCBj b250YWlucyBwcm90b2NvbCBjb250cm9sIGluZm9ybWF0aW9uLiBJdHMNCiAgICAgICAgIHN0 cnVjdHVyZSBpcyBzaG93biBpbiBGaWd1cmUgNS4NCg0KDQogICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgIE1CWiAgfEZ8QnxEfEN8SXxMfCAgTGVu Z3RoICAgfCBTZXF1ZW5jZSBOdW1iZXIgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KDQogICAgIEZpZ3VyZSA1IC0gQ29udHJvbCBXb3JkIHN0cnVjdHVyZSBmb3IgdGhlIG9u ZS10by1vbmUgbWFwcGluZyBtb2RlDQoNCg0KS2F3YSwgZXQgYWwuICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAgMTBdDQoNCgwNCklu dGVybmV0IERyYWZ0ICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAzLnR4dCAg ICAgICBBdWd1c3QgMjAwNA0KDQogICAgICBUaGUgbWVhbmluZyBvZiB0aGUgQ29udHJvbCBX b3JkIGZpZWxkcyAoRmlndXJlIDUpIGlzIGFzDQogICAgICBmb2xsb3dzIChzZWUgYWxzbyBb WDM2IGFuZCBYNzZdIGZvciBmcmFtZSByZWxheSBiaXRzKToNCg0KICAgICAgICAgTUJaIChi aXRzIDAgdG8gMyk6DQogICAgICAgICAgICBSZXNlcnZlZCBiaXRzLiBUaGV5IGFyZSBzZXQg dG8gemVybyBvbiB0cmFuc21pc3Npb24gYW5kDQogICAgICAgICAgICBpZ25vcmVkIG9uIHJl Y2VwdGlvbi4NCg0KICAgICAgICAgRiAoYml0IDQpOg0KICAgICAgICAgICAgRlIgRkVDTiAo Rm9yd2FyZCBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbikgYml0Lg0KDQogICAg ICAgICBCIChiaXQgNSk6DQogICAgICAgICAgICBGUiBCRUNOIChCYWNrd2FyZCBFeHBsaWNp dCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbikgYml0Lg0KDQogICAgICAgICBEIChiaXQgNik6 DQogICAgICAgICAgICBGUiBERSBiaXQgKERpc2NhcmQgRWxpZ2liaWxpdHkpIGJpdC4NCg0K ICAgICAgICAgQyAoYml0IDcpDQogICAgICAgICAgICBGUiBmcmFtZSBDL1IgKENvbW1hbmQv UmVzcG9uc2UpIGJpdC4NCg0KICAgICAgICAgSSwgTCAoYml0cyA4IGFuZCA5KToNCiAgICAg ICAgICAgIEkgYW5kIEwgYXJlIHRoZSBJbml0aWFsIGFuZCBMYXN0IGZyYWdtZW50YXRpb24g Yml0cyBhbmQgdGhlaXINCiAgICAgICAgICAgIGZ1bmN0aW9uYWxpdHkgaXMgc3BlY2lmaWVk IGluIFtGUkFHXS4NCiAgICAgICAgICAgIA0KICAgICAgICAgTGVuZ3RoIChiaXRzIDEwIHRv IDE1KToNCiAgICAgICAgICBJZiB0aGUgUHNldWRvIFdpcmUgdHJhdmVyc2VzIGEgbmV0d29y ayBsaW5rIHRoYXQgcmVxdWlyZXMgYSBtaW5pbXVtDQoJICAgIGZyYW1lIHNpemUgKGEgbm90 YWJsZSBleGFtcGxlIGlzIEV0aGVybmV0KSwgcGFkZGluZyBpcyByZXF1aXJlZCB0byANCgkg ICAgcmVhY2ggaXRzIG1pbmltdW0gZnJhbWUgc2l6ZS4NCgkgICAgDQoJICAgIElmIHRoZSB0 b3RhbCBsZW5ndGggb2YgRlJvUFcgcGF5bG9hZCwgd2hpY2ggaXMgdGhlIHN1bSBvZiB0aGUN CgkgICAgbGVuZ3RocyBvZiB0aGUgY29udHJvbCB3b3JkIGFuZCBQYXlsb2FkIGZpZWxkcyBp cyBsZXNzIHRoYW4gNjQgb2N0ZXRzLA0KCSAgICB0aGVuIHBhZGRpbmcgaGFzIHRvIGJlIHBl cmZvcm1lZC4gSW4gdGhpcyBjYXNlIGxlbmd0aCBmaWVsZCBNVVNUIGJlDQoJICAgIHNldCB0 byB0aGUgRlJvUFcgcGF5bG9hZCBsZW5ndGguICBPdGhlcndpc2UgdGhlIGxlbmd0aCBmaWVs ZCBNVVNUIGJlDQoJICAgIHNldCB0byB6ZXJvLiANCgkgICAgDQoJICAgIFRoZSB2YWx1ZSBv ZiB0aGUgbGVuZ3RoIGZpZWxkLCBpZiBub24temVybywgaXMgdXNlZCB0byByZW1vdmUgdGhl IA0KICAgICAgICAgIHBhZGRpbmcgY2hhcmFjdGVycyBieSB0aGUgaW5ncmVzcyBQRS4NCg0K ICAgICAgICAgU2VxdWVuY2UgbnVtYmVyIChCaXQgMTYgdG8gMzEpOg0KCSAgICAgU2VxdWVu Y2UgbnVtYmVycyBwcm92aWRlIG9uZSBwb3NzaWJsZSBtZWNoYW5pc20gdG8gZW5zdXJlIHRo ZQ0KCSAgICAgb3JkZXJlZCBkZWxpdmVyeSBvZiBGUm9QVyBwYWNrZXRzLiBBIGNpcmN1bGFy IGxpc3QNCgkgICAgIG9mIHNlcXVlbmNlIG51bWJlcnMgaXMgdXNlZCwgc2tpcHBpbmcgdGhl IHZhbHVlIHplcm8uIFRoZSB2YWx1ZSBvZg0KICAgICAgICAgICB6ZXJvIGluZGljYXRlcyB0 aGF0IHRoZSBzZXF1ZW5jZSBudW1iZXIgZmllbGQgaXMgbm90IHVzZWQuIFNlZSANCiAgICAg ICAgICAgc2VjdGlvbiA3LjQgZm9yIHRoZSBzZXF1ZW5jZSBudW1iZXIgZ2VuZXJhdGlvbiBh bmQgY2hlY2tpbmcNCiAgICAgICAgICAgYWxnb3JpdGhtcy4NCg0KS2F3YSwgZXQgYWwuICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MTFdDQoMDQoNCkludGVybmV0IERyYWZ0ICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJl bGF5LTAzLnR4dCAgICAgICAgQXVndXN0IDIwMDQNCgkgICAgTm90ZTogVGhlIHVzZSBvZiBz ZXF1ZW5jZSBudW1iZXJzIG1heSBub3QgYmUgcmVxdWlyZWQgaWYgdGhlIG5ldHdvcmsNCiAg ICAgICAgICBpdHNlbGYgZW5zdXJlcyBvcmRlcmVkIGRlbGl2ZXJ5IG9mIEZSb1BXIHBhY2tl dHMuDQoNCiAgICAgICAgIFBheWxvYWQ6DQogICAgICAgICAgICBUaGUgcGF5bG9hZCBmaWVs ZCBjb3JyZXNwb25kcyB0byBYLjM2L1guNzYgZnJhbWUgcmVsYXkgZnJhbWUNCiAgICAgICAg ICAgIGluZm9ybWF0aW9uIGZpZWxkIHdpdGggYml0L2J5dGUgc3R1ZmZpbmcgYW5kIGZyYW1l IHJlbGF5IGhlYWRlcg0KICAgICAgICAgICAoRExDSSlyZW1vdmVkLiANCg0KICAgICAgICAg ICAgSXQgaXMgUkVDT01NRU5ERUQgdG8gc3VwcG9ydCBhIGZyYW1lIHNpemUgb2YgYXQgbGVh c3QgMTYwMCBieXRlcy4NCiAgICAgICAgICAgIFRoZSBtYXhpbXVtIGxlbmd0aCBvZiB0aGUg cGF5bG9hZCBmaWVsZCBNVVNUIGJlIGFncmVlZCBieSB0aGUgdHdvDQogICAgICAgICAgICBQ RXMgd2hlbiB0aGUgVkMgTFNQIGlzIGVzdGFibGlzaGVkLg0KDQogICAgICAgICBQYWQ6DQog ICAgICAgICAgICBUaGUgUGFkIGNvbnNpc3RzIG9mIGEgbnVtYmVyIG9mIG9jdGV0cyAoaW5j bHVkaW5nIHplcm8gDQogICAgICAgICAgICBvY3RldCkgcmVxdWlyZWQgdG8gZ3VhcmFudGVl IHRoYXQgdGhlIEZSb1BXIHBhY2tldCBzaXplIA0KICAgICAgICAgICAgaXMgbm90IGxlc3Mg dGhhbiA2NCBwYWNrZXRzLiAgQW55IG9jdGV0IHdpdGggYSBkZWNpbWFsIA0KICAgICAgICAg ICAgdmFsdWUgZnJvbSAwIHRvIDI1NSBtYXkgYmUgdXNlZCBhcyBhIHBhZGRpbmcgY2hhcmFj dGVyLg0KDQogICAgICAgICBOb3RlOiBUaGUgbGltaXQgb2YgNjQgb2N0ZXRzIGZvciB0aGUg cGFja2V0IGxlbmd0aCBiZWxvdyB3aGljaCANCiAgICAgICAgICAgICAgIHBhZGRpbmcgaXMg cmVxdWlyZWQsIGFsaWducyB3aXRoIHRoZSBtaW5pbXVtIEV0aGVybmV0IA0KICAgICAgICAg ICAgICAgZnJhbWUgc2l6ZS4NCg0KICAgNy40LiBGUm9QVyBwYWNrZXQgcHJvY2Vzc2luZw0K DQogICAgICA3LjQuMS4gR2VuZXJhdGlvbiBvZiBGUm9QVyBwYWNrZXRzDQoNCiAgICAgICAg IFRoZSBnZW5lcmF0aW9uIHByb2Nlc3Mgb2YgYSBGUm9QVyBwYWNrZXQgaXMgaW5pdGlhdGVk IHdoZW4gYSBQRQ0KICAgICAgICAgcmVjZWl2ZXMgYSBmcmFtZSByZWxheSBmcmFtZSBmcm9t IG9uZSBvZiBpdHMgZnJhbWUgcmVsYXkgVU5JIG9yDQogICAgICAgICBOTkkgaW50ZXJmYWNl cy4gVGhlIFBFIHRha2VzIHRoZSBmb2xsb3dpbmcgYWN0aW9ucyAobm90IG5lY2Vzc2FyaWx5 IA0KICAgICAgICAgaW4gdGhlIG9yZGVyIHNob3duKToNCg0KICAgICAgICAgICAgLSBJdCBn ZW5lcmF0ZXMgdGhlIGZvbGxvd2luZyBmaWVsZHMgb2YgdGhlIENvbnRyb2wgd29yZCAgZnJv bSB0aGUNCiAgICAgICAgICAgICAgY29ycmVzcG9uZGluZyBmaWVsZHMgb2YgdGhlIGZyYW1l IHJlbGF5IGZyYW1lIGFzIGZvbGxvd3M6DQoNCiAgICAgICAgICAgICAgIC0gQ29tbWFuZC9S ZXNwb25zZSAoQy9SIG9yIEMpIGJpdDogVGhlIEMgYml0IGlzIGNvcGllZA0KICAgICAgICAg ICAgICAgdW5jaGFuZ2VkIGluIHRoZSBGUm9QVyBDb250cm9sIFdvcmQuDQoNCiAgICAgICAg ICAgICAgIC0gRGlzY2FyZCBlbGlnaWJpbGl0eSBpbmRpY2F0b3IgKERFIG9yIEQpOiBUaGUg RCBiaXQgaXMNCiAgICAgICAgICAgICAgICAgc2V0IGFzIGZvbGxvd3MgaW4gdGhlIENvbnRy b2wgV29yZDogVGhpcyBiaXQsIGlmIHVzZWQsDQogICAgICAgICAgICAgICAgIGlzIHNldCB0 byAxIHRvIGluZGljYXRlIGEgcmVxdWVzdCB0aGF0IGEgZnJhbWUgc2hvdWxkDQogICAgICAg ICAgICAgICAgIGJlIGRpc2NhcmRlZCBpbiBwcmVmZXJlbmNlIHRvIG90aGVyIGZyYW1lcyBp biBhDQogICAgICAgICAgICAgICAgIGNvbmdlc3Rpb24gc2l0dWF0aW9uLiBUaGlzIGJpdCBp cyBvZnRlbiBzZXQgYXMgYSByZXN1bHQgb2YgDQogICAgICAgICAgICAgICAgIGluZ3Jlc3Mg ZnJhbWUgcG9saWNpbmcuDQoNCiAgICAgICAgICAgICAgICAgU2V0dGluZyBvZiB0aGlzIGJp dCBieSBhIFBFIGlzIE9QVElPTkFMLiBIb3dldmVyLCBubyBQRQ0KICAgICAgICAgICAgICAg ICBTSEFMTCBldmVyIGNsZWFyIHRoaXMgYml0IChzZXQgaXQgdG8gMCBpZiBpdCB3YXMgcmVj ZWl2ZWQNCiAgICAgICAgICAgICAgICAgd2l0aCB0aGUgdmFsdWUgb2YgMSkuIEEgUEUgdGhh dCBkb2VzIG5vdCBwcm92aWRlDQogICAgICAgICAgICAgICAgIGRpc2NhcmQgZWxpZ2liaWxp dHkgbm90aWZpY2F0aW9uIHNoYWxsIHBhc3MgdGhpcyBiaXQNCiAgICAgICAgICAgICAgICAg dW5jaGFuZ2VkLiANCg0KICAgICAgICAgICAgICAgLSBGb3J3YXJkIGV4cGxpY2l0IGNvbmdl c3Rpb24gbm90aWZpY2F0aW9uIChGRUNOIG9yIEYNCiAgICAgICAgICAgICAgICAgYml0KTog RkVDTiBtYXkgYmUgc2V0IGJ5IGEgY29uZ2VzdGVkIFBFIHRvIG5vdGlmeSB0aGUNCiAgICAg ICAgICAgICAgICAgdXNlciB0aGF0IGNvbmdlc3Rpb24gYXZvaWRhbmNlIHByb2NlZHVyZXMg c2hvdWxkIGJlDQogICAgICAgICAgICAgICAgIGluaXRpYXRlZCB3aGVyZSBhcHBsaWNhYmxl IGZvciB0cmFmZmljIGluIHRoZSBkaXJlY3Rpb24NCiAgICAgICAgICAgICAgICAgb2YgdGhl IENvbnRyb2wgV29yZCBjYXJyeWluZyB0aGUgRkVDTi4NCg0KDQpLYXdhLCBldCBhbC4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEy XQ0KDA0KDQpJbnRlcm5ldCBEcmFmdCAgICAgIGRyYWZ0LWlldGYtcHdlMy1mcmFtZS1yZWxh eS0wMy50eHQgICAgICAgQXVndXN0IDIwMDQNCg0KICAgICAgICAgICAgICAgICBXaGlsZSBz ZXR0aW5nIHRoaXMgYml0IGJ5IGEgUEUgaXMgT1BUSU9OQUwsIFBFIE1VU1Qgbm90DQogICAg ICAgICAgICAgICAgIGNsZWFyIHRoaXMgYml0IChzZXQgaXQgdG8gMCBpZiBpdCB3YXMgcmVj ZWl2ZWQgd2l0aCB0aGUNCiAgICAgICAgICAgICAgICAgdmFsdWUgb2YgMSkuIFBFcyB0aGF0 IGRvIG5vdCBwcm92aWRlIEZFQ04gc2hhbGwgcGFzcw0KICAgICAgICAgICAgICAgICB0aGlz IGJpdCB1bmNoYW5nZWQuDQoNCiAgICAgICAgICAgICAgIC0gQmFja3dhcmQgZXhwbGljaXQg Y29uZ2VzdGlvbiBub3RpZmljYXRpb24gKEJFQ04gb3IgQg0KICAgICAgICAgICAgICAgICBi aXQpOiBCRUNOIGZvbGxvd3MgdGhlIHNhbWUgcHJvY2Vzc2luZyBydWxlcyBhcyBGRUNOLA0K ICAgICAgICAgICAgICAgICBleGNlcHQgdGhhdCBpdCBhcHBsaWVzIHRvIHRoZSBiYWNrd2Fy ZCBkaXJlY3Rpb24uDQoNCiAgICAgICAgICAgICAgIC0gTGVuZ3RoOiBJZiB0aGUgRlJvUFcg cGFja2V0IGxlbmd0aCAoZGVmaW5lZCBhcyB0aGUgbGVuZ3RoIG9mIA0KICAgICAgICAgICAg ICAgICB0aGUgcGF5bG9hZCAgcGx1cyB0aGUgbGVuZ3RoIG9mIHRoZSBjb250cm9sIHdvcmQp IGlzIGxlc3MgdGhhbiANCiAgICAgICAgICAgICAgICAgNjQgb2N0ZXRzLCB0aGUgbGVuZ3Ro IGZpZWxkIE1VU1QgYmUgc2V0IHRvIHRoZSBwYWNrZXQncyBsZW5ndGggDQogICAgICAgICAg ICAgICAgIGFuZCBwYWRkaW5nIGhhcyB0byBiZSBwZXJmb3JtZWQuIE90aGVyd2lzZSB0aGUg bGVuZ3RoIGZpZWxkIA0KICAgICAgICAgICAgICAgICBNVVNUIGJlIHNldCB0byB6ZXJvLg0K DQogICAgICAgICAgICAgICAtIFNlcXVlbmNlIG51bWJlcjogVGhlIHNlcXVlbmNlIG51bWJl ciBmaWVsZCBpcyBzZXQgaWYgdGhlIEZSIFBXDQogICAgICAgICAgICAgICAgIHVzZXMgc2Vx dWVuY2UgbnVtYmVycy4NCiAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIElm IHRoZSBpbmdyZXNzIFBFIHN1cHBvcnRzIHRoZSBzZXF1ZW5jZSBudW1iZXIgY2FwYWJpbGl0 eSB0aGVuIA0KICAgICAgICAgICAgICAgICB0aGUgZm9sbG93aW5nIHByb2NlZHVyZSB0byBu dW1iZXIgRlJvUFcgcGFja2V0cyBpcyB1c2VkOg0KDQogICAgICAgICAgICAgICAgICAgIC0g VGhlIGluaXRpYWwgRlJvUFcgcGFja2V0IHRyYW5zbWl0dGVkIE1VU1QgdXNlIHNlcXVlbmNl IA0KICAgICAgICAgICAgICAgICAgICAgIG51bWJlciAxLCANCiAgICAgICAgICAgICAgICAg ICAgLSBGb3IgYSBzdWJzZXF1ZW50IGZyYW1lLCB0aGUgc2VxdWVuY2UgbnVtYmVyIGNvcnJl c3BvbmRzIA0KICAgICAgICAgICAgICAgICAgICAgIHRvIHRoZSBzZXF1ZW5jZSBudW1iZXIg b2YgdGhlIHByZWNlZGluZyBmcmFtZSBpbmNyZW1lbnRlZCANCiAgICAgICAgICAgICAgICAg ICAgICBieSAxIHVwIHRvIHRoZSBtYXhpbXVtIHZhbHVlIG9mIDY1NTM1LCANCiAgICAgICAg ICAgICAgICAgICAgLSBXaGVuIHRoZSBzZXF1ZW5jZSBudW1iZXIgcmVhY2hlcyB0aGUgbWF4 aW11bSAxNiBiaXQgdmFsdWUgDQogICAgICAgICAgICAgICAgICAgICAgKDY1NTM1KSB0aGUg bmV4dCBzZXF1ZW5jZSBudW1iZXIgd3JhcHMgdG8gMSAodGhlIHZhbHVlIG9mIA0KICAgICAg ICAgICAgICAgICAgICAgIDAgaXMgc2tpcHBlZCkuDQoNCiAgICAgICAgICAgICAgICAgSWYg dGhlIEZSIFBXIHVzZXMgc2VxdWVuY2UgbnVtYmVycyBkbyBub3Qgc3VwcG9ydCBzZXF1ZW5j ZQ0KICAgICAgICAgICAgICAgICBudW1iZXIgcHJvY2Vzc2luZywgdGhlbiB0aGUgc2VxdWVu Y2UgbnVtYmVyIGZpZWxkIG11c3QgYmUgc2V0DQogICAgICAgICAgICAgICAgIHRvIDAuDQog ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgLSBQYXlsb2FkIGFuZCBQYWQ6IFRo ZSBwYXlsb2FkIG9mIHRoZSBGUm9QVyBwYWNrZXQgaXMgdGhlIA0KICAgICAgICAgICAgICAg ICBjb250ZW50cyBvZiBJVFUtVCBSZWNvbW1lbmRhdGlvbnMgWC4zNi9YLjc2IFtYMzYsIFg3 Nl0gZnJhbWUgDQogICAgICAgICAgICAgICAgIHJlbGF5IGZyYW1lIGluZm9ybWF0aW9uIGZp ZWxkIHN0cmlwcGVkIGZyb20gYW55IGJpdCBvciBieXRlIA0KICAgICAgICAgICAgICAgICBz dHVmZmluZy4gUGFkZGluZyBjaGFyYWN0ZXJzIG1heSBmb2xsb3cgdGhlIHBheWxvYWQgZmll bGQuDQoNCiAgICAgICAgIEFkZGl0aW9uYWwgcHJvY2Vzc2luZyBpcyBwZXJmb3JtZWQgYnkg dGhlIGxvd2VyIHByb3RvY29sIGxheWVycyBpbiANCiAgICAgICAgIG9yZGVyIHRvIHRyYW5z bWl0IHRoZSBGUm9QVyBwYWNrZXQgdG8gaXRzIG5leHQgZGVzdGluYXRpb24uDQoNCg0KDQpL YXdhLCBldCBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDEzXQ0KDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgIGRyYWZ0LWlldGYt cHdlMy1mcmFtZS1yZWxheS0wMy50eHQgICAgICAgQXVndXN0IDIwMDQNCg0KDQoNCiAgICAg IDcuNC4yLiBSZWNlcHRpb24gb2YgRlJvUFcgcGFja2V0cw0KICAgICAgDQogICAgICAgICAg ICAgICBXaGVuIGEgUEUgcmVjZWl2ZXMgYSBGUm9QVyBwYWNrZXQsIGl0IHByb2Nlc3NlcyB0 aGUgZGlmZmVyZW50DQogICAgICAgICAgICAgICBmaWVsZHMgb2YgdGhlIGNvbnRyb2wgd29y ZCBpbiBvcmRlciB0byBzeW50aGVzaXplIGEgbmV3IGZyYW1lDQogICAgICAgICAgICAgICBy ZWxheSBmcmFtZSBmb3IgdHJhbnNtaXNzaW9uIHRvIGEgQ0Ugb24gYSBGUiBVTkkgb3IgTk5J LiBUaGUgUEUNCiAgICAgICAgICAgICAgIHBlcmZvcm1zIHRoZSBmb2xsb3dpbmcgYWN0aW9u cyAobm90IG5lY2Vzc2FyaWx5IGluIHRoZSBvcmRlcg0KICAgICAgICAgICAgICAgc2hvd24p Og0KICAgICAgDQogICAgICAgICAgICAgICAgICAtIEl0IGdlbmVyYXRlcyB0aGUgZm9sbG93 aW5nIEZSIGZyYW1lIGhlYWRlciBmaWVsZHMgZnJvbSB0aGUNCiAgICAgICAgICAgICAgICAg ICAgY29ycmVzcG9uZGluZyBmaWVsZHMgb2YgdGhlIEZSb1BXIHBhY2tldCBhcyBmb2xsb3dz Og0KICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgIC0gQy9SIGJpdCBpcyBjb3BpZWQg dW5jaGFuZ2VkIGluIHRoZSBmcmFtZSByZWxheQ0KICAgICAgICAgICAgICAgICAgICAgICAg IGhlYWRlci4NCiAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAtIEQgYml0IGlzIGNv cGllZCB1bmNoYW5nZWQgaW50byB0aGUgZnJhbWUgcmVsYXkNCiAgICAgICAgICAgICAgICAg ICAgICAgICBoZWFkZXIgREUgYml0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgIC0gVGhl IEYgYml0IGlzIHByb2Nlc3NlZCBhcyBmb2xsb3dzOiBJZiBpdCB3YXMgc2V0IA0KICAgICAg ICAgICAgICAgICAgICAgICAgIHRvIG9uZSBpbiB0aGUgaW5jb21pbmcgRlJvUFcgcGFja2V0 LCBpdCBtdXN0IGJlIA0KICAgICAgICAgICAgICAgICAgICAgICAgIGNvcGllZCB1bmNoYW5n ZWQgaW50byB0aGUgRkVDTiBiaXQgaW4gdGhlIGZyYW1lIHJlbGF5IA0KICAgICAgICAgICAg ICAgICAgICAgICAgIGhlYWRlci4gDQogICAgICAgICAgICAgICAgICAgICAgICAgT3RoZXJ3 aXNlIGlmIGl0IHdhcyBzZXQgdG8gemVybywgdGhlIEZFQ04gYml0IG1heSBiZQ0KICAgICAg ICAgICAgICAgICAgICAgICAgIHNldCB0byBvbmUsIGRlcGVuZGluZyBvbiB0aGUgY29uZ2Vz dGlvbiBzdGF0ZSBvZiB0aGUgUEUNCiAgICAgICAgICAgICAgICAgICAgICAgICBkZXZpY2Ug aW4gdGhlIGZvcndhcmQgZGlyZWN0aW9uLiBTZXR0aW5nIHRoaXMgYml0IGJ5IGENCiAgICAg ICAgICAgICAgICAgICAgICAgICBQRSBpcyBPUFRJT05BTC4NCiAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAtIEJFQ04gZm9sbG93cyB0aGUgc2FtZSBwcm9jZXNzaW5nIHJ1bGVz IGFzIEZFQ04sDQogICAgICAgICAgICAgICAgICAgICAgICAgZXhjZXB0IHRoYXQgaXQgYXBw bGllcyB0byB0aGUgYmFja3dhcmQgZGlyZWN0aW9uLg0KICAgICAgDQogICAgICAgICAgICAg ICAgICAgICAgIC0gSXQgcHJvY2Vzc2VzIHRoZSBsZW5ndGggYW5kIHNlcXVlbmNlIGZpZWxk LCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICBkZXRhaWxzIG9mIHdoaWNoIGFyZSBp biB0aGUgc3Vic2VxdWVudCBzdWItc2VjdGlvbnMuDQogICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgLSBJdCBnZW5lcmF0ZXMgdGhlIGZyYW1lIHJlbGF5IGluZm9ybWF0aW9uIGZp ZWxkIGZyb20NCiAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgY29udGVudHMgb2YgdGhl IEZSb1BXIHBhY2tldCBwYXlsb2FkIGFmdGVyDQogICAgICAgICAgICAgICAgICAgICAgICAg cmVtb3ZpbmcgYW55IHBhZGRpbmcuDQogICAgICANCiAgICAgICAgICAgICAgT25jZSB0aGUg YWJvdmUgZmllbGRzIG9mIGEgRlIgZnJhbWUgaGF2ZSBiZWVuIGdlbmVyYXRlZCwgdGhlIEZD Uw0KICAgICAgICAgICAgICBoYXMgdG8gYmUgY29tcHV0ZWQsIEhETEMgZmxhZ3MgaGF2ZSB0 byBiZSBhZGRlZCBhbmQgYW55IGJpdCBvcg0KICAgICAgICAgICAgICBieXRlIHN0dWZmaW5n IGhhcyBiZWVuIHBlcmZvcm1lZCAodGhlc2UgZmluYWwgYWN0aW9ucyB0eXBpY2FsbHkgDQog ICAgICAgICAgICAgIHRha2UgcGxhY2UgaW4gYSBoYXJkd2FyZSBmcmFtZXIpLiBUaGUgRlIg ZnJhbWUgaXMgcXVldWVkIGZvcg0KICAgICAgICAgICAgICB0cmFuc21pc3Npb24gb24gdGhl IHNlbGVjdGVkIGZyYW1lIHJlbGF5IFVOSSBvciBOTkkgaW50ZXJmYWNlLg0KDQoNCiAgICAg ICAgNy40LjIuMS4gQ2hlY2tpbmcgdGhlIFNlcXVlbmNlIE51bWJlciBieSB0aGUgUmVjZWl2 aW5nIFBFDQoNCiAgICAgICAgICAgICAgV2hlbiBhbiBlbXVsYXRlZCBWQyBpcyBpbml0aWFs bHkgc2V0IHVwLCB0aGUgImV4cGVjdGVkIHNlcXVlbmNlDQogICAgICAgICAgICAgIG51bWJl ciIgYXNzb2NpYXRlZCB3aXRoIGl0IE1VU1QgYmUgaW5pdGlhbGl6ZWQgdG8gMS4NCg0KICAg ICAgICAgICAgICBXaGVuIGEgRlJvUFcgcGFja2V0IGlzIHJlY2VpdmVkIHRoZSBzZXF1ZW5j ZSBudW1iZXIgaXMgcHJvY2Vzc2VkIA0KICAgICAgICAgICAgICBhcyBmb2xsb3dzOg0KDQog ICANCkthd2EsIGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQogICAgICANCkludGVybmV0IERyYWZ0ICAgICAg ZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAzLnR4dCAgICAgIEF1Z3VzdCAyMDA0DQoN CiAgICAgICAgICAgICAgICAtIElmIHRoZSBzZXF1ZW5jZSBudW1iZXIgb2YgdGhlIHBhY2tl dCBpcyAwLCB0aGVuIHRoZSBwYWNrZXQNCiAgICAgICAgICAgICAgICAgIHBhc3NlcyB0aGUg c2VxdWVuY2UgbnVtYmVyIGNoZWNrLg0KDQogICAgICAgICAgICAgICAgICBOb3RlOiAgQSBz ZXF1ZW5jZSBudW1iZXIgZXF1YWwgdG8gMCBtZWFucyB0aGF0IHNlcXVlbmNlIA0KICAgICAg ICAgICAgICAgICAgICAgICBudW1iZXJzIGFyZSBub3QgdXNlZC4gVGhyb3VnaCBtYW5hZ2Vt ZW50IG9yIHNpZ25hbGluZywNCiAgICAgICAgICAgICAgICAgICAgICAgdGhlIHR3byBQRXMg ZGV0ZXJtaW5lIHdoZXRoZXIgc2VxdWVuY2UgbnVtYmVycyBhcmUgdXNlZCANCiAgICAgICAg ICAgICAgICAgICAgICAgb3Igbm90LiANCg0KICAgICAgICAgICAgICAgIC0gT3RoZXJ3aXNl IGlmIHRoZSBwYWNrZXQgc2VxdWVuY2UgbnVtYmVyID49IHRoZSBleHBlY3RlZA0KICAgICAg ICAgICAgICAgICAgc2VxdWVuY2UgbnVtYmVyIGFuZCB0aGUgcGFja2V0IHNlcXVlbmNlIG51 bWJlciAtIHRoZSBleHBlY3RlZA0KICAgICAgICAgICAgICAgICAgc2VxdWVuY2UgbnVtYmVy IDwgMzI3NjgsIHRoZW4gdGhlIHBhY2tldCBpcyBpbiBvcmRlci4gDQoNCiAgICAgICAgICAg ICAgICAtIE90aGVyd2lzZSBpZiB0aGUgcGFja2V0IHNlcXVlbmNlIG51bWJlciA8IHRoZSBl eHBlY3RlZA0KICAgICAgICAgICAgICAgICAgc2VxdWVuY2UgbnVtYmVyIGFuZCB0aGUgZXhw ZWN0ZWQgc2VxdWVuY2UgbnVtYmVyIC0gdGhlIHBhY2tldA0KICAgICAgICAgICAgICAgICAg c2VxdWVuY2UgbnVtYmVyID49IDMyNzY4LCB0aGVuIHRoZSBwYWNrZXQgaXMgaW4gb3JkZXIu IA0KDQogICAgICAgICAgICAgICAgLSBPdGhlcndpc2UgdGhlIHBhY2tldCBpcyBvdXQgb2Yg b3JkZXIuDQoNCiAgICAgICAgICAgICAgSWYgdGhlIHBhY2tldCBpcyBpbiBvcmRlciwgdGhl biBpdCBwYXNzZXMgdGhlIHNlcXVlbmNlIG51bWJlciANCiAgICAgICAgICAgICAgY2hlY2sg YW5kIHRoZSBleHBlY3RlZCBzZXF1ZW5jZSBudW1iZXIgaXMgc2V0IGFzIHBlciB0aGUgZm9s bG93aW5nIA0KICAgICAgICAgICAgICBhc3NpZ25tZW50Og0KDQogICAgICAgICAgICAgICBl eHBlY3RlZF9zZXF1ZW5jZV9udW1iZXIgOj0gcGFja2V0X3NlcXVlbmNlX251bWJlciArIDEs IHVwIHRvIGEgDQogICAgICAgICAgICAgICBtYXhpbXVtIG9mIDY1NTM1IGFmdGVyIHdoaWNo IGl0IHNraXBzIHplcm8gYW5kIHdyYXBzIGZyb20gNjU1MyB0byANCiAgICAgICAgICAgICAg IDEuIA0KDQogICAgICAgICAgICAgIElmIChleHBlY3RlZF9zZXF1ZW5jZV9udW1iZXIgPSAw KSB0aGVuIGV4cGVjdGVkX3NlcXVlbmNlX251bWJlciANCiAgICAgICAgICAgICAgICA6PSAx Lg0KDQogICAgICAgICAgICAgIEZSb1BXICBwYWNrZXRzIHRoYXQgYXJlIHJlY2VpdmVkIG91 dCBvZiBvcmRlciBzaG91bGQgYmUgZHJvcHBlZA0KICAgICAgICAgICAgICB1bmxlc3MgdGhl eSBjYW4gYmUgcmUtb3JkZXJlZCB3aXRob3V0IGludHJvZHVjaW5nIHNpZ25pZmljYW50DQog ICAgICAgICAgICAgIGRlbGF5cy4NCg0KICAgICAgICAgICAgICBJZiBhbiBlZ3Jlc3MgUEUg cmVjZWl2ZXMgYW4gZXhjZXNzaXZlIG51bWJlciBvZiBvdXQtb2Ytc2VxdWVuY2UgDQogICAg ICAgICAgICAgIEZyb1BXIHBhY2tldHMsIGl0IFNIT1VMRCBpbmZvcm0gdGhlIG1hbmFnZW1l bnQgcGxhbmUgcmVzcG9uc2libGUNCiAgICAgICAgICAgICAgZm9yIEZSb1BXIGluIHRoZSBQ RSBhbmQgdGFrZSB0aGUgYXBwcm9wcmlhdGUgYWN0aW9ucy4gVGhlIA0KICAgICAgICAgICAg ICB0aHJlc2hvbGQgZm9yIGRlY2xhcmluZyB0aGF0IG91dC1vZi1zZXF1ZW5jZSBGUm9QVyBw YWNrZXRzIGFyZQ0KICAgICAgICAgICAgICBleGNlc3NpdmUgaXMgbm90IGRlZmluZWQgaW4g dGhpcyBkb2N1bWVudC4NCg0KICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgTm90ZTog RXhjZXNzaXZlIG91dC1vZi1zZXF1ZW5jZSBGUm9QVyBwYWNrZXRzIGhhcyBhbiBlZmZlY3Qg DQogICAgICAgICAgICAgICBzaW1pbGFyIHRvIGV4Y2Vzc2l2ZSBwYWNrZXQgbG9zcyBvbiBh IGZyYW1lIHJlbGF5IFZDLg0KDQoNCiAgICAgICAgICAgICAgIDcuNC4yLjIuIFByb2Nlc3Np bmcgb2YgdGhlIExlbmd0aCBGaWVsZCBieSB0aGUgUmVjZWl2ZXINCg0KICAgICAgICAgICAg ICAgIEFueSBwYWRkaW5nIG9jdGV0LCBpZiBwcmVzZW50LCBpbiB0aGUgcGF5bG9hZCBmaWVs ZCBvZiBhDQogICAgICAgICAgICAgICAgRnJvUFcgcGFja2V0IHJlY2VpdmVkIE1VU1QgYmUg cmVtb3ZlZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUNCiAgICAgICAgICAgICAgICBkYXRhLg0K DQpLYXdhLCBldCBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDE1XQ0KDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgIGRyYWZ0LWll dGYtcHdlMy1mcmFtZS1yZWxheS0wMy50eHQgICAgICBBdWd1c3QgMjAwNA0KDQoNCiAgICAg ICAgICAgICAgICBUaGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBoZXJlIGlzIHVzZWQgdG8gcmVt b3ZlIHBhZGRpbmcNCiAgICAgICAgICAgICAgICBjaGFyYWN0ZXJzLg0KDQogICAgICAgICAg ICAgICAgSWYgdGhlIExlbmd0aCBmaWVsZCBpcyBzZXQgdG8gemVybyB0aGVuIHRoZXJlIGFy ZSBubyBwYWRkaW5nDQogICAgICAgICAgICAgICAgQ2hhcmFjdGVycyBmb2xsb3dpbmcgdGhl IHBheWxvYWQgZmllbGQuDQoNCiAgICAgICAgICAgICAgICBFbHNlIHBhZGRpbmcgY2hhcmFj dGVycyBhcmUgcmVtb3ZlZCBiYXNlZCBvbiB0aGUgTGVuZ3RoIGZpZWxkLg0KDQoNCiAgICAg ICAgICAgNy41LiBIYW5kbGluZyBvZiBlcnJvciBjb25kaXRpb25zDQoNCiAgICAgICAgICAg IElmIGEgUEUgcmVjZWl2ZXMgYSBGUm9QVyBwYWNrZXQgd2l0aCBhIGhlYWRlciBjb250YWlu aW5nIGludmFsaWQgDQogICAgICAgICAgICBjb250ZW50cywgaXQgc2hhbGwgYmUgZGlzY2Fy ZGVkLiBGb3IgZXhhbXBsZToNCg0KICAgICAgICAgICAgLSBBbiBpbnZhbGlkIG9yIHVuYXNz aWduZWQgdHVubmVsIG9yIFZDIGxhYmVsLA0KICAgICAgICAgICAgLSBBIHZhbHVlIGRpZmZl cmVudCB0aGFuIHplcm8gZm9yIHRoZSBmaXJzdCBmb3VyIGJpdHMgb2YgdGhlIA0KICAgICAg ICAgICAgICBDb250cm9sIFdvcmQsDQogICAgICAgICAgICAtIEEgbGVuZ3RoIGZpZWxkIHdp dGggYSBjb250ZW50IGdyZWF0ZXIgb3IgZXF1YWwgdG8gNjQsDQogICAgICAgICAgICAtIElu Y29uc2lzdGVuY2llcyBiZXR3ZWVuIHRoZSBjb250ZW50IG9mIHRoZSBsZW5ndGggZmllbGQg YW5kIHRoZQ0KICAgICAgICAgICAgICBhY3R1YWwgc2l6ZSBvZiB0aGUgRlJvUFcgcGFja2V0 Lg0KICAgICAgICAgICAgLSBJZiBmcmFnbWVudGF0aW9uIGlzIG5vdCB1c2VkIGEgdmFsdWUg ZGlmZmVyZW50IHRoYW4gemVybyBmb3IgdGhlIA0KICAgICAgICAgICAgICB0d28gZnJhZ21l bnRhdGlvbiBiaXRzKGJpdHMgOCBhbmQgOSBvZiB0aGUgRlJvUFcgaGVhZGVyKS4NCg0KDQo4 LiBGUiBQVkMgcHJvdmlzaW9uaW5nDQoNCiAgIFByb3Zpc2lvbmluZyBvZiBGUiBQVkNzIHJl cXVpcmVzIHRoZSBmb2xsb3dpbmcgYWN0aW9uczogVGhlIFBFcyBhbmQNCiAgIENFcyBhcmUg Y29uZmlndXJlZCBpbmRlcGVuZGVudGx5IGZvciBlYWNoIEZSIFVOSSBvciBOTkkgUFZDIHNl Z21lbnRzLg0KICAgU29tZSBvZiB0aGUgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIG1heSBp bmNsdWRlOg0KDQogICAgICAtIE91dGdvaW5nIGFuZCBpbmNvbWluZyB0aHJvdWdocHV0cyAo Q0lSKSwNCiAgICAgIC0gT3V0Z29pbmcgYW5kIGluY29taW5nIGNvbW1pdHRlZCBidXJzdCBz aXplcyAoQmMpLA0KuCAgICAgLSBPdXRnb2luZyBhbmQgaW5jb21pbmcgZXhjZXNzIGJ1cnN0 IHNpemVzIChCZSksDQogICAgICAtIE91dGdvaW5nIGFuZCBpbmNvbWluZyBtYXhpbXVtIGZy YW1lIGxlbmd0aHMsDQogICAgICAtIFRoZSBETENJIGFzc2lnbmVkIHRvIHRoZSBGUiBQVkMg bG9jYWxseSwNCiAgICAgIC0gSWYgdXNlZCwgRlIgdHJhbnNmZXIgYW5kIGRpc2NhcmQgcHJp b3JpdHkgY2xhc3Mgb3IgRlIgc2VydmljZQ0KICAgICAgICBjbGFzcyBbWDM2LCBYNzZdIGFz c2lnbmVkIHRvIHRoZSBGUiBWQy4NCg0KICAgVG8gY29tcGxldGUgdGhlIEZSIFZDLCBhIFBX IChpLmUuIGEgcGFpciBWQyBMU1ApIGlzIGVzdGFibGlzaGVkDQogICBiZXR3ZWVuIHRoZSB0 d28gUEVzLiBFc3RhYmxpc2htZW50IG9mIHRoZSBGUiBQVyBpcyBhZGRyZXNzZWQgaW4gW0NP TlRST0xdLg0KDQoNCg0KOS4gVHJhZmZpYyBtYW5hZ2VtZW50IGFzcGVjdHMNCg0KICAgICBJ biBJVFUtVCBSZWNvbW1lbmRhdGlvbnMgWC4zNiBhbmQgWC4xNDYsIGEgbnVtYmVyIG9mIGRp ZmZlcmVudCB0cmFmZmljDQogICAgIHBhcmFtZXRlcnMgYW5kIFF1YWxpdHkgb2YgU2Vydmlj ZSAoUW9TKSBjbGFzc2VzIGFyZSBkZWZpbmVkLiBXaGVuIGEgDQogICAgIHR1bm5lbCBMU1Ag aXMgdXNlZCB0byBjYXJyeSBlaXRoZXIgYSBzaW5nbGUgZnJhbWUgcmVsYXkgVkMgb3IgDQog ICAgIG11bHRpcGxlIGZyYW1lIHJlbGF5IFZDcyB3aXRoIGRpZmZlcmVudCBjb21iaW5hdGlv bnMgb2YgdHJhZmZpYyANCiAgICAgcGFyYW1ldGVycyBhbmQgUW9TIGNsYXNzZXMsIHRoZSB0 dW5uZWwgTFNQIHNoYWxsIGJlIGNhcGFibGUgb2YgDQogICAgIHByb3ZpZGluZyB0aGUgcmVx dWlyZWQgUW9TIGZvciB0aGUgZW5jYXBzdWxhdGVkIGZyYW1lIHJlbGF5IFZDcy4gDQogICAg IEluIGFuIE1QTFMgbmV0d29yayB0aGF0IGRvZXMgb25seSBzdXBwb3J0IFFvUyBkaWZmZXJl bnRpYXRpb24gb24gYSANCiAgICAgcGVyIExTUCBiYXNpcywgdGhlIHR1bm5lbCBMU1Agc2hh bGwgbWVldCB0aGUgbW9zdCBzdHJpbmdlbnQgUW9TIA0KICAgICByZXF1aXJlbWVudHMgb2Yg dGhlIGZyYW1lIHJlbGF5IFZDcyBjYXJyaWVkIGJ5IHRoYXQgdHVubmVsIExTUC4gDQoNCg0K S2F3YSwgZXQgYWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAxNl0NCg0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICBkcmFmdC1pZXRm LXB3ZTMtZnJhbWUtcmVsYXktMDMudHh0ICAgICAgQXVndXN0IDIwMDQNCiAgIA0KICAgOS4x LiBVc2Ugb2YgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgZm9yIEZyYW1lIHJlbGF5IG92ZXIg TVBMUzogDQoNCiAgICAgIElmIHRoZSBNUExTIG5ldHdvcmsgc3VwcG9ydHMgRGlmZmVyZW50 aWF0ZWQgU2VydmljZXMgKERpZmZTZXJ2KQ0KICAgICAgQmVoYXZpb3IgQWdncmVnYXRlcyBk ZWZpbmVkIGluIGluZm9ybWF0aW9uYWwgUkZDcyAyNDc1IGFuZCAzMjYwLCANCiAgICAgIE1Q TFMgcGFja2V0cyBjYW4gYmUgdHJlYXRlZCB3aXRoIGRpZmZlcmVudCBwcmlvcml0aWVzIG9u IGEgUGVyIEhvcCANCiAgICAgIEJlaGF2aW9yIChQSEIpLiBJbiB0aGlzIGNhc2UsIHR3byBk aWZmZXJlbnQgdHlwZXMgb2YgTFNQcyBhcmUgZGVmaW5lZCANCiAgICAgIGluIFJGQyAzMjcw IHdoaWNoIGNhbiBib3RoIGJlIHVzZWQgZm9yIHRoZSB0dW5uZWwgTFNQOg0KICAgICAgDQog ICAgICAgIC0gTGFiZWwtT25seS1JbmZlcnJlZC1QU0MgTFNQcyAoTC1MU1ApOw0KICAgICAg ICAtIEVYUC1JbmZlcnJlZC1QU0MgTFNQcyAoRS1MU1ApLg0KICANCiAgICAgIElmIGEgTC1M U1AgaXMgdXNlZCBhcyBhIHR1bm5lbCBMU1AsIHRoZSBQSEIgc2NoZWR1bGluZyBjbGFzcyBv ZiBlYWNoDQogICAgICBwYWNrZXQgaXMgaW5mZXJyZWQgZnJvbSB0aGUgbGFiZWwgd2l0aG91 dCBhbnkgb3RoZXIgaW5mb3JtYXRpb24gDQogICAgICAoZS5nLiwgcmVnYXJkbGVzcyBvZiB0 aGUgRVhQIGZpZWxkIHZhbHVlKS4gSW4gdGhhdCBjYXNlLCB0aGUgTFNQIHNoYWxsDQogICAg ICBtZWV0IHRoZSBtb3N0IHN0cmluZ2VudCBRb1MgcmVxdWlyZW1lbnRzIG9mIHRoZSBmcmFt ZSByZWxheSBWQ3MgdHVubmVsZWQNCiAgICAgIGJ5IHRoZSBMU1AuIA0KDQogICAgICBJZiBh biBFLUxTUCBpcyB1c2VkIGFzIGEgdHVubmVsIExTUCwgdGhlIEVYUCBmaWVsZCBvZiB0aGUg dHVubmVsIGxhYmVsDQogICAgICBpcyB1c2VkIHRvIGRldGVybWluZSB0aGUgUEhCIHRvIGJl IGFwcGxpZWQgdG8gZWFjaCBwYWNrZXQsIGkuZS4sIA0KICAgICAgZGlmZmVyZW50IHBhY2tl dHMgaW4gb25lIExTUCBtYXkgcmVjZWl2ZSBhIGRpZmZlcmVudCBRb1MuIFRoZSAzLWJpdCBF WFANCiAgICAgIGZpZWxkIG9mIHRoZSB0dW5uZWwgbGFiZWwgY2FuIHJlcHJlc2VudCBlaWdo dCBkaWZmZXJlbnQgY29tYmluYXRpb25zIG9mIA0KICAgICAgUGVyIEhvcCBCZWhhdmlvdXIg KFBIQikgYW5kIGRyb3AgcHJlY2VkZW5jZSBsZXZlbHMuIFRoZSBtYXBwaW5nIG9mIHRoZSAN CiAgICAgIFBIQiB0byBFWFAgZmllbGRzIGlzIGVpdGhlciBleHBsaWNpdGx5IHNpZ25hbGVk IGF0IGxhYmVsIHNldC11cCBvciANCiAgICAgIHJlbGllcyBvbiBhIHByZS1jb25maWd1cmVk IG1hcHBpbmcuDQoNCg0KMTAuIEZyYW1lIFJlbGF5IFBvcnQgTW9kZQ0KDQogICAxMC4xLiBH ZW5lcmFsDQoNCiAgICAgIEZyYW1lIHJlbGF5IHBvcnQgbW9kZSBvciBtYW55LXRvLW9uZSBt YXBwaW5nIGlzIGFuIE9QVElPTkFMDQogICAgICBjYXBhYmlsaXR5LiBJdCBhcHBsaWVzIHRv IGJvdGggTVBMUyBhbmQgTDJUUHYzIHBzZXVkby13aXJlcy4NCiAgICAgIEZpZ3VyZSA2IGls bHVzdHJhdGVzIHRoZSBjb25jZXB0IG9mIGZyYW1lIHJlbGF5IHBvcnQgbW9kZS4NCg0KICAg ICAgRmlndXJlIDYgKGEpIHNob3dzIHR3byBmcmFtZSByZWxheSBkZXZpY2VzIHBoeXNpY2Fs bHkgY29ubmVjdGVkDQogICAgICB3aXRoIGEgZnJhbWUgcmVsYXkgVU5JIG9yIE5OSS4gQmV0 d2VlbiB0aGVpciB0d28gcG9ydHMgUDEgYW5kIFAyLA0KICAgICAgbiBmcmFtZSByZWxheSBW Q3MgYXJlIGNvbmZpZ3VyZWQuIA0KDQogICAgICBGaWd1cmUgNiAoYikgc2hvd3MgdGhlIHJl cGxhY2VtZW50IG9mIHRoZSBwaHlzaWNhbCBmcmFtZSByZWxheSBpbnRlcmZhY2UNCiAgICAg IHdpdGggYSBwYWlyIG9mIFBFcyBhbmQgYSBQVyBiZXR3ZWVuIHRoZW0uIEEgUFcgbWF5IGJl IGFuIE1QTFMgVkMgTFNQIG9yIGENCiAgICAgIEwyVFB2MyB0dW5uZWwuIFRoZSBpbnRlcmZh Y2UgYmV0d2VlbiBhIEZSIGRldmljZSBhbmQgYSBQRSBpcyBlaXRoZXIgYSBGUg0KICAgICAg VU5JIG9yIE5OSS4gVGhlIHNldCBvZiBuIEZSIFZDcyBiZXR3ZWVuIHRoZSB0d28gRlIgcG9y dHMgUDEgYW5kIFAyIHdoaWNoDQogICAgICBhcmUgY29udHJvbGxlZCBieSB0aGUgc2FtZSBz aWduYWxpbmcgY2hhbm5lbCB1c2luZyBETENJPTAgKGNmLiBGaWd1cmUNCiAgICAgIDcgKGEp KSwgYXJlIG1hcHBlZCBpbnRvIG9uZSBQVy4gSGVuY2Ugd2l0aCBwb3J0IG1vZGUgd2UgaGF2 ZSBtYW55LXRvLW9uZQ0KICAgICAgbWFwcGluZyBiZXR3ZWVuIEZSIFZDcyBhbmQgYSBQVy4N Cg0KDQoNCg0KDQoNCkthd2EsIGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTddDQoNCgwNCkludGVybmV0IERyYWZ0ICAg ICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAzLnR4dCAgICAgICBBdWd1c3QgMjAw NA0KDQogICAgICAgICAgICAgICstLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLSsNCiAgICAgICAgICAgICAgfCBGUiAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICBGUiAgfA0KICAgICAgICAgICAgICB8ZGV2aWNlfCAgICAgICAgIEZSIFVOSS9O TkkgICAgICAgfCBkZXZpY2V8DQogICAgICAgICAgICAgIHwgICAgW1AxXS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLVtQMl0gICAgIHwNCiAgICAgICAgICAgICAgfCAgICAgIHwgICAgICBj YXJyeWluZyBuIEZSIFZDcyAgIHwgICAgICAgfA0KICAgICAgICAgICAgICArLS0tLS0tKyAg ICAgICAgICAgIHwgICAgICAgICAgICAgKy0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICBbUG5dOiBBIHBvcnQgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IChhKSBGUiBpbnRlcmZhY2Ug YmV0d2VlbiB0d28NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBG UiBkZXZpY2VzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFYNCiAgICAgICAgICAgICAgICAgICAgfDwt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICst LS0tKyAgICAgICAgICAgICAgICAgICstLS0tKw0KICAgKy0tLS0tLSsgICAgICAgICAgfCAg ICB8ICAgT25lIFBXIHBhaXIgICAgfCAgICB8ICAgICAgICAgKy0tLS0tLSsNCiAgIHwgICAg ICB8ICAgICAgICAgIHwgICAgfD09PT09PT09PT09PT09PT09PXwgICAgfCAgICAgICAgIHwg ICAgICB8DQogICB8ICBGUiAgfCAgICBGUiAgICB8IFBFMXwgY2FycnlpbmcgbiBGUiBWQ3N8 IFBFMnwgICAgRlIgICB8ICBGUiAgfA0KICAgfGRldmljZXwtLS0tLS0tLS0tfCAgICB8ICAg ICAgICAgICAgICAgICAgfCAgICB8LS0tLS0tLS0tfGRldmljZXwNCiAgIHwgQ0UxICB8IFVO SS9OTkkgIHwgICAgfCAgICAgICAgICAgICAgICAgIHwgICAgfCBVTkkvTk5JIHwgQ0UyICB8 DQogICArLS0tLS0tKyAgICAgICAgICArLS0tLSsgICAgICAgICAgICAgICAgICArLS0tLSsg ICAgICAgICArLS0tLS0tKw0KICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG4gRlIgVkNzDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIChi KSBQc2V1ZG8td2lyZXMgcmVwbGFjaW5nIHRoZSBGUiBpbnRlcmZhY2UNCg0KICAgICAgICAg ICAgICAgICBGaWd1cmUgNiAtIENvbmNlcHQgb2YgZnJhbWUgcmVsYXkgcG9ydC10by1wb3J0 IG1vZGUNCg0KDQogICAgICBGUiBWQ3MgYXJlIG5vdCB2aXNpYmxlIGluZGl2aWR1YWxseSB0 byBhIFBFOyB0aGVyZSBpcyBubw0KICAgICAgY29uZmlndXJhdGlvbiBvZiBpbmRpdmlkdWFs IEZSIFZDIGluIGEgUEUuIEEgUEUgcHJvY2Vzc2VzIHRoZSBzZXQNCiAgICAgIG9mIEZSIFZD cyBhc3NpZ25lZCB0byBhIHBvcnQgYXMgYW4gYWdncmVnYXRlLiBGUiB0cmFmZmljIGFuZCBR b1MNCiAgICAgIHBhcmFtZXRlcnMgbGlzdGVkIGluIFNlY3Rpb24gOCBtYXkgYmUgYXNzaWdu ZWQgdG8gdGhlIGFnZ3JlZ2F0ZQ0KICAgICAgdHJhZmZpYyBmbG93aW5nIG9uIGFuIGludGVy ZmFjZSBiZXR3ZWVuIGEgQ0UgYW5kIGEgUEUgYW5kIG5vdCB0bw0KICAgICAgaW5kaXZpZHVh bCBGUiBWQ3MgYW5kIHBvbGljaW5nIG1heSBiZSBwZXJmb3JtZWQgb24gdGhlIGFnZ3JlZ2F0 ZS4NCg0KICAgICAgRlIgcG9ydCBtb2RlIHByb3ZpZGVzIHRyYW5zcG9ydCBiZXR3ZWVuIHR3 byBQRXMgb2YgYSBjb21wbGV0ZSBGUg0KICAgICAgZnJhbWUgZXhjbHVkaW5nIHRoZSBvcGVu aW5nIGFuZCBjbG9zaW5nIGZsYWdzIGFuZCB0aGUgRnJhbWUgQ2hlY2sNCg0KICAgICAgU2Vx dWVuY2UgKEZDUykgYW5kIHdpdGggYml0L2J5dGUgc3R1ZmZpbmcgdW5kb25lLg0KICAgICAg Rm9yIG1vcmUgaW5mb3JtYXRpb24gb24gRlIgZnJhbWUgZm9ybWF0cyB0aGUgcmVhZGVyIHNo b3VsZA0KICAgICAgY29uc3VsdCBTZWN0aW9uIDE0IGFuZCBbWDM2LCBYNzZdLg0KDQoNCg0K DQoNCkthd2EsIGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgMThdDQoNCgwNCkludGVybmV0IERyYWZ0ICAgICAgZHJhZnQt aWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAzLnR4dCAgICAgIEF1Z3VzdCAyMDA0DQogICANCiAg IDEwLjIuIEZSb1BXIHBhY2tldCBmb3JtYXQgZm9yIE1QTFMgcG9ydCBtb2RlDQoNCiAgICAg ICAgIFdoZW4gTVBMUyBQVyBpcyB1c2VkIHdpdGggcG9ydCBtb2RlLCB0aGUgRlJvUFcgcGFj a2V0IGZvcm1hdCBpcw0KICAgICAgICAgc2hvd24gaW4gRmlndXJlIDcuDQoNCg0KICAgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgIHwgICAgICBUdW5u ZWwgTFNQIGxhYmVsKHMpICAgICAgfCBuKjQgb2N0ZXRzIChmb3VyIG9jdGV0cyBwZXIgbGFi ZWwpDQogICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAg fCAgICAgIFZDIExTUCBsYWJlbCAgICAgICAgICAgICB8IDQgb2N0ZXRzDQogICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgfCAgICAgICBDb250cm9s IFdvcmQgICAgICAgICAgICB8DQogICAgICAgfCAgICAgICAgKHNlZSBGaWd1cmUgOCkgICAg ICAgICB8IDQgb2N0ZXRzDQogICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQogICAgICAgfCAgICAgICAgICAgICBQYXlsb2FkICAgICAgICAgICB8DQogICAgICAg fCAgICAoRlIgQWRkcmVzcyBwbHVzICAgICAgICAgICB8DQogICAgICAgfCAgICAgIGluZm9y bWF0aW9uIGZpZWxkKSAgICAgICB8IE4gb2N0ZXRzDQogICAgICAgfCAgICAgIGFuZCBhIFBh ZCAoaWYgbmVlZGVkKSAgICB8DQogICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQoNCiAgICBGaWd1cmUgNy0gRlIgb3ZlciBNUExTIHBhY2tldCBmb3JtYXQgZm9y IHRoZSBwb3J0IG1vZGUgbWFwcGluZw0KDQogICAgICAgICBUdW5uZWwgTFNQIGxhYmVsKHMp IHJvbGUgaXMgYXMgc3BlY2lmaWVkIGZvciB0aGUgb25lLXRvLW9uZQ0KICAgICAgICAgbWFw cGluZy4NCg0KICAgICAgICAgVGhlIFZDIExTUCBsYWJlbCBpZGVudGlmaWVzIHRoZSBQVyBh c3NpZ25lZCB0byB0aGUgcG9ydCBmb3IgYSBzZXQgDQogICAgICAgICBvZiBGUiBWQ3MgdXNp bmcgdGhhdCBwb3J0LiBUaGVyZSBpcyBhIHBhaXIgb2YgVkMgTFNQcyBmb3IgdGhlIHR3bw0K ICAgICAgICAgdHJhZmZpYyBkaXJlY3Rpb25zLg0KDQoNCiAgICAgICAgIENvbnRyb2wgV29y ZDogVGhlIENvbnRyb2wgV29yZCBjb250YWlucyBwcm90b2NvbCBjb250cm9sDQogICAgICAg ICBpbmZvcm1hdGlvbi4gSXRzIHN0cnVjdHVyZSBpcyBzaG93biBpbiBGaWd1cmUgOC4gRnJh bWUgcmVsYXkNCiAgICAgICAgIGNvbnRyb2wgYml0cyA0IHRvIDcgKEYsIEIsIEQgYW5kIEMp IGFyZSBub3QgdXNlZCBhbmQgYXJlIHNldCB0byB6ZXJvLg0KICAgICAgICAgDQoNCiAgICAg ICAgIFRoZSB1c2Ugb2YgdGhlIGZyYWdtZW50YXRpb24gYml0cyAoSSBhbmQgTCkgaXMgdGhl IHNhbWUgYXMgZm9yIA0KICAgICAgICAgdGhlIG9uZS10by1vbmUgbWFwcGluZy4gVGhlIHVz ZSBvZiB0aGUgbGVuZ3RoIGFuZCBzZXF1ZW5jZSBudW1iZXIgDQogICAgICAgICBmaWVsZHMg aXMgdGhlIHNhbWUgYXMgZm9yIHRoZSBvbmUtdG8tb25lIG1hcHBpbmcsIHdpdGggdGhlIGZv bGxvd2luZyANCiAgICAgICAgIGV4Y2VwdGlvbnM6IFRoZXJlIGlzIG9uZSBzZXF1ZW5jZSBu dW1iZXIgY291bnRlciBmb3IgdGhlIHNldCBvZiBGUiBWQ3MgDQogICAgICAgICBhbmQgbm90 IG9uZSBmb3IgZWFjaCBpbmRpdmlkdWFsIEZSIFZDLiBUbyBjb21wdXRlIHRoZSBGUm9QVyBw YWNrZXQgDQogICAgICAgICBzaXplIHRvIGRldGVybWluZSB3aGV0aGVyIHBhZGRpbmcgaXMg bmVlZGVkIG9yIG5vdCwgdGhlIGZvcm1hdCBvZg0KICAgICAgICAgRmlndXJlIDggaXMgdXNl ZC4NCg0KDQogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIg ICAgICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg IHwgIFJlcyAgfDB8MHwwfDB8SXxMfCAgTGVuZ3RoICAgfCBTZXF1ZW5jZSBOdW1iZXIgICAg ICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgIEZpZ3VyZSA4IC0gQ29udHJv bCBXb3JkIHN0cnVjdHVyZSBmb3IgdGhlIHBvcnQgbW9kZSBtYXBwaW5nDQoNCg0KS2F3YSwg ZXQgYWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAxOV0NCg0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICBkcmFmdC1pZXRmLXB3ZTMt ZnJhbWUtcmVsYXktMDMudHh0ICAgICAgQXVndXN0IDIwMDQNCiAgICAgICAgIA0KICAgICAg ICAgVGhlIHBheWxvYWQgZmllbGQgY29udGFpbnMgYSBGUiBmcmFtZSByZWNlaXZlZCBmcm9t IGEgQ0UgY29uc2lzdHMgb2YNCiAgICAgICAgIHRoZSBhZGRyZXNzIGZpZWxkIChpbmNsdWRp bmcgdGhlIERMQ0kgYW5kIHRoZSBjb250cm9sIGJpdHMpIGFuZA0KICAgICAgICAgaW5mb3Jt YXRpb24gZmllbGQsIHdpdGggdGhlIG9wZW5pbmcgYW5kIGNsb3NpbmcgZmxhZ3MsIGJpdC9i eXRlDQogICAgICAgICBzdHVmZmluZyBhbmQgRkNTIHJlbW92ZWQuDQoNCiAgICAgICAgIFRo ZSB0d28gcGVlciBQRXMgbXVzdCBhZ3JlZSBvbiB0aGUgbGVuZ3RoIG9mIHRoZSBETENJIGZp ZWxkICgyDQogICAgICAgICBvciA0IG9jdGV0cykgYW5kIHRoZSBtYXhpbXVtIGxlbmd0aCBv ZiBGUiBmcmFtZSBpbmZvcm1hdGlvbg0KICAgICAgICAgZmllbGQuICBUaGVzZSBhcmUgc2ln bmFsZWQgZHVyaW5nIFBzZXVkby1XaXJlIHNldHVwIHVzaW5nIHR3bw0KICAgICAgICAgaW50 ZXJmYWNlIHBhcmFtZXRlcnMgW0NPTlRST0wsIFBXRTNJQU5BXTogDQogICAgICAgICANCg0K DQogICAxMC4zLiBGUm9QVyBwYWNrZXQgZm9ybWF0IGZvciBMMlRQdjMgcG9ydCBtb2RlDQoN CiAgICAgICAgIFdoZW4gYW4gTDJUUHYzIFBXIGlzIHVzZWQgd2l0aCBwb3J0IG1vZGUsIHRo ZSBGUm9QVyBwYWNrZXQgZm9ybWF0DQogICAgICAgICBpcyBzaG93biBpbiBGaWd1cmUgOS4g VGhpcyBmb3JtYXQgaXMgaW1wb3J0ZWQgZnJvbSBbTDJUUHYzDQogICAgICAgICBGaWd1cmUg My4yLjJdIGFuZCBpcyB2ZXJ5IHNpbWlsYXIgdG8gdGhlIHBhY2tldCBmb3JtYXQgb2YgRmln dXJlIDMuDQoNCg0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgUFNOIHRyYW5zcG9ydCBIZWFkZXIgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgTDJUUCBUdW5uZWwgSGVhZGVyICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAg ICAgICAgICAgIEwyLVNwZWNpZmljIFN1YmxheWVyICAgICAgICAgICAgICAgICAgICAgfA0K ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgIFR1bm5lbGVkIEwy IEZyYW1lICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAg RmlndXJlIDkgLSBGUiBvdmVyIEwyVFB2MyBwYWNrZXQgZm9ybWF0IGZvciB0aGUgcG9ydCBt b2RlIG1hcHBpbmcNCg0KICAgICAgICAgUFNOIHRyYW5zcG9ydCBoZWFkZXI6DQogICAgICAg ICAgICBUaGUgUFNOIHRyYW5zcG9ydCBoZWFkZXIgaXMgdGhlIFBTTiB0cmFuc3BvcnQgaGVh ZGVyIG9mIEZpZ3VyZSAzLg0KICAgICAgICAgICAgV2hlbiB0aGUgUFNOIGlzIGFuIElQIG5l dHdvcmssIHRoaXMgaGVhZGVyIGlzIGFuIElQIHY0IG9yIHY2IA0KICAgICAgICAgICAgZGF0 YWdyYW0gaGVhZGVyLg0KDQogICAgICAgICBMMlRQIFR1bm5lbCBoZWFkZXI6DQogICAgICAg ICAgICBMMlRQIFR1bm5lbCBoZWFkZXIgY29ycmVzcG9uZHMgdG8gdGhlIFBXIGhlYWRlcg0K ICAgICAgICAgICAgb2YgRmlndXJlIDMuIFRoZXJlIGFyZSB0d28gZm9ybWF0cyBmb3IgTDJU UCBUdW5uZWwgaGVhZGVyDQogICAgICAgICAgICBkZWZpbmVkIGluIFtMMlRQdjNdOiBPbmUg d2hlbiBMMlRQdjMgcnVucyBvdmVyIElQIGRpcmVjdGx5DQogICAgICAgICAgICBhbmQgYW5v dGhlciBvbmUgZm9yIEwyVFB2MyBvdmVyIFVEUC4gVGhlIHR3byBmb3JtYXRzIGFyZQ0KICAg ICAgICAgICAgc2hvd24gaW4gRmlndXJlIDkgKGEpIGFuZCAoYikuIFRoZSBkZXNjcmlwdGlv biBvZiB0aGUNCiAgICAgICAgICAgIHZhcmlvdXMgZmllbGRzIGNhbiBiZSBmb3VuZCBpbiBb TDJUUHYzXS4NCg0KDQoNCkthd2EsIGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjBdDQoMDQoNCkludGVybmV0IERyYWZ0 ICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAzLnR4dCAgICAgIEF1Z3VzdCAy MDA0DQogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICBTZXNzaW9uIElEICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICA6ICAgICAgICAgICAgICBDb29raWUgKG9wdGlvbmFsLCBtYXhpbXVtIDY0IGJp dHMpICAgICAgICAgICAgICAgOg0KICAgOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDoNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQogICAgICAgICAgICAgICAgICAoYSkgTDJUUHYzIG92ZXIgSVAg VHVubmVsIEhlYWRlcg0KDQoNCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAg ICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgfFR8eHx4fHh8eHx4fHh8eHx4fHh8eHx4fCAgVmVyICB8ICAgICAgICAg IFJlc2VydmVkICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2Vzc2lvbiBJRCAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAg ICBDb29raWUgKG9wdGlvbmFsLCBtYXhpbXVtIDY0IGJpdHMpLi4uICAgICAgICAgOg0KICAg OiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDoNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICAg ICAgICAgICAgICAoYikgTDJUUHYzIG92ZXIgVURQIFR1bm5lbCBIZWFkZXINCg0KICAgICAg ICAgICAgIEZpZ3VyZSAxMCAtIEwyVFB2MyBvdmVyIElQIGFuZCBVRFAgVHVubmVsIEhlYWRl cg0KDQoNCg0KDQogICAgICAgICBMMi1TcGVjaWZpYyBTdWJsYXllcjoNCiAgICAgICAgICAg IEwyLVNwZWNpZmljIFN1YmxheWVyIGhlYWRlciBzaG93biBpbiBGaWd1cmUgOSBpcyBhbmFs b2dvdXMNCiAgICAgICAgICAgIHRvIHRoZSBDb250cm9sIFdvcmQgb2YgRmlndXJlIDMuIFdp dGggTDJUUHYzIHRoZSBzYW1lIENvbnRyb2wgV29yZA0KICAgICAgICAgICAgZGVmaW5lZCBp biBGaWd1cmUgOCBmb3IgTVBMUyBwb3J0IG1vZGUgaXMgdXNlZCBhbHNvDQogICAgICAgICAg ICB3aXRoIEwyVFB2My4NCg0KDQogICAgICAgICBUdW5uZWxlZCBMMiBGcmFtZToNCiAgICAg ICAgICAgIFRoZSBUdW5uZWxlZCBMMiBGcmFtZSBvZiBGaWd1cmUgOSBjb3JyZXNwb25kcyB0 byB0aGUNCiAgICAgICAgICAgIHBheWxvYWQgb2YgdGhlIGdlbmVyYWwgRlJvUFcgZm9ybWF0 IHNob3duIGluIEZpZ3VyZSAzLiBUaGlzDQogICAgICAgICAgICBmaWVsZCBpcyB1c2VkIHRv IGNhcnJ5IGEgRlIgZnJhbWUgYXMgc2hvd24gaW4gRmlndXJlIDguDQogICAgICAgICAgICBU aGVyZWZvcmUgZm9yIGJvdGggTVBMUyBhbmQgTDJUUHYzIHVzZWQgd2l0aCBGUiBwb3J0IG1v ZGUsDQogICAgICAgICAgICB0aGUgcGF5bG9hZCBvZiB0aGUgRlJvUFcgcGFja2V0IGlzIHRo ZSBzYW1lIGFuZCBjb25zaXN0cyBvZg0KICAgICAgICAgICAgYSBmcmFtZSByZWxheSBmcmFt ZSwgZXhjbHVkaW5nIHRoZSBmbGFncyBhbmQgdGhlIEZDUywgd2l0aA0KICAgICAgICAgICAg Yml0L2J5dGUgc3R1ZmZpbmcgdW5kb25lLg0KDQpLYXdhLCBldCBhbC4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDIxXQ0KDA0KDQpJ bnRlcm5ldCBEcmFmdCAgICAgIGRyYWZ0LWlldGYtcHdlMy1mcmFtZS1yZWxheS0wMy50eHQg ICAgICBBdWd1c3QgMjAwNA0KICAgMTAuNC4gRlJvUFcgcHJvY2Vzc2luZyBmb3IgcG9ydCBt b2RlDQoNCiAgICAgICAgIFdoZW4gYSBQRSByZWNlaXZlcyBhIEZSIGZyYW1lIGZyb20gYSBG UiBkZXZpY2UgKGEgQ0UpLCBpdCBzaGFsbA0KICAgICAgICAgcmVtb3ZlIHRoZSBmbGFncywg dW5kbyBiaXQvYnl0ZSBzdHVmZmluZyBhbmQgY2hlY2sgdGhlIEZDUw0KICAgICAgICAgZmll bGQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdHJhbnNtaXNzaW9uIGVycm9ycyBvY2N1cnJlZCBv ciBub3QuDQogICAgICAgICBJZiB0cmFuc21pc3Npb24gZXJyb3JzIG9jY3VycmVkLCB0aGUg ZnJhbWUgaXMgZGlzY2FyZGVkLg0KICAgICAgICAgT3RoZXJ3aXNlLCB0aGUgRlIgZnJhbWUg KGV4Y2x1ZGluZyB0aGUgZmxhZ3MgYW5kIHRoZSBGQ1MpIGlzIA0KICAgICAgICAgZW5jYXBz dWxhdGVkIGluIGEgRlJvUFcgcGFja2V0IHBheWxvYWQgdG8gYmUgZm9yd2FyZGVkIHRvIHRo ZSANCiAgICAgICAgIHJlbW90ZSBQRS4gIA0KICAgICAgICAgDQogICAgICAgICBUaGUgcHJv Y2Vzc2luZyBvZiB0aGUgbGVuZ3RoIGFuZCBzZXF1ZW5jZSBudW1iZXIgZmllbGRzIGlzIHRo ZQ0KICAgICAgICAgc2FtZSBhcyBmb3IgdGhlIG9uZS10by1vbmUgbWFwcGluZywgd2l0aCB0 aGUgZm9sbG93aW5nDQogICAgICAgICBleGNlcHRpb25zIG1lbnRpb25lZCBlYXJsaWVyOiBU aGVyZSBpcyBvbmUgc2VxdWVuY2UgbnVtYmVyDQogICAgICAgICBjb3VudGVyIGZvciB0aGUg c2V0IG9mIEZSIFZDcyBhbmQgbm90IG9uZSBmb3IgZWFjaCBpbmRpdmlkdWFsDQogICAgICAg ICBGUiBWQy4gIA0KICAgICAgICAgDQogICAgICAgICBVcG9uIHJlY2VpdmluZyBhIEZSb1BX IHBhY2tldCwgdGhlIHJlbW90ZSBQRSBzaGFsbCBleHRyYWN0IHRoZQ0KICAgICAgICAgRlJv UFcgcGF5bG9hZCBmaWVsZCwgZW5jYXBzdWxhdGUgdGhlIHJlc3VsdCBpbiBhIEZSIGZyYW1l IGZvcg0KICAgICAgICAgdHJhbnNtaXNzaW9uIHRvIHRoZSBsb2NhbCBGUiBkZXZpY2UuDQoN CjExLiBGcmFtZSByZWxheSBzZXJ2aWNlIG92ZXIgcHNldWRvLXdpcmVzDQoNCiAgIEZyYW1l IHJlbGF5IHNlcnZpY2UgKEZSUykgaXMgZGVmaW5lZCBpbiB0ZXJtcyBvZiBhIG51bWJlciBv Zg0KICAgYXR0cmlidXRlcyBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBbWDM2XS4gVGhlIG1v c3QgdHdvIGZ1bmRhbWVudGFsIGFzcGVjdHMgDQogICBvZiBGUlMgYXJlOg0KDQogICAgICAx LVRoZSByZXF1aXJlbWVudCB0byBkZWxpdmVyIGluIG9yZGVyIHRoZSB1c2VyJ3MgZGF0YSBi ZXR3ZWVuDQogICAgICAgIHR3byBmcmFtZSByZWxheSBzZXJ2aWNlIGFjY2VzcyBwb2ludCwN Cg0KICAgICAgMi1UaGUgZGV0ZWN0aW9uIG9mIHRyYW5zbWlzc2lvbiBlcnJvcnMuDQoNCg0K ICAgQmVzaWRlcyB0aGUgYWJvdmUgdHdvIHNlcnZpY2UgYXR0cmlidXRlcywgRlJTIGlzIGRl ZmluZWQgYnkgYSBudW1iZXINCiAgIG9mIHRyYWZmaWMgYW5kIFFvUyBhdHRyaWJ1dGVzIGlu IElUVS1UIFJlY29tbWVuZGF0aW9ucw0KICAgW1gzNiBhbmQgWDc2XSBhbmQgaW4gdGhlIEZy YW1lIFJlbGF5IEZvcnVtIEltcGxlbWVudGF0aW9uDQogICBBZ3JlZW1lbnQgRlJGLjEzIFtG UkYxM10uIFRoZSBmb2xsb3dpbmcgaXMgYSBwYXJ0aWFsIGxpc3QNCiAgIGlsbHVzdHJhdGlu ZyBzb21lIG9mIGZyYW1lIHJlbGF5IHNlcnZpY2UgYXR0cmlidXRlczoNCg0KICAgICAgLSBD b21taXR0ZWQgaW5mb3JtYXRpb24gcmF0ZQ0KICAgICAgLSBFeGNlc3MgaW5mb3JtYXRpb24g cmF0ZQ0KICAgICAgLSBDb21taXR0ZWQgYnVyc3Qgc2l6ZQ0KICAgICAgLSBFeGNlc3MgYnVy c3Qgc2l6ZQ0KICAgICAgLSB0cmFuc2l0IGRlbGF5DQogICAgICAtIEZyYW1lIGRlbGl2ZXJ5 IHJhdGlvDQogICAgICAtIFNlcnZpY2UgYXZhaWxhYmlsaXR5DQoNCiAgIEZSIHNlcnZpY2Ug cHJvdmlkZXJzIHVzZSBGUlMgYXR0cmlidXRlcyB0byBkZWZpbmUgU2VydmljZSBMZXZlbA0K ICAgQWdyZWVtZW50cyAoU0xBKS4gQSBmcmFtZSByZWxheSBTTEEgYXJlIGNvbnRyYWN0dWFs IGFuZCBiaW5kaW5nDQogICBhZ3JlZW1lbnQgZGVzY3JpYmluZyB0aGUgRlJTIHNlcnZpY2Ug cHJvdmlkZXJzIG9mZmVyIHRvIHRoZWlyDQogICBjdXN0b21lcnMuDQoNCg0KS2F3YSwgZXQg YWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSAyMl0NCgwNCg0KSW50ZXJuZXQgRHJhZnQgICAgICBkcmFmdC1pZXRmLXB3ZTMtZnJh bWUtcmVsYXktMDMudHh0ICAgICAgQXVndXN0IDIwMDQNCiAgIEFuIGltcG9ydGFudCBxdWVz dGlvbiB0byBhc2sgaXM6IFdoYXQgZG9lcyBpdCBtZWFuIHRvIG9mZmVyIGEgZnJhbWUNCiAg IHJlbGF5IHNlcnZpY2U/IEl0IG1lYW5zIHRoYXQgdGhlIHR3byBmdW5kYW1lbnRhbCBhdHRy aWJ1dGVzIG9mIEZSUw0KICAgYWJvdXQgaW4tc2VxdWVuY2UgZGVsaXZlcnkgYW5kIGVycm9y IGRldGVjdGlvbiBtdXN0IGJlIHNhdGlzZmllZCBieQ0KICAgYSBuZXR3b3JrIHByb3ZpZGlu ZyBhIGZyYW1lIHJlbGF5IHNlcnZpY2UuDQoNCiAgIFRoZSBvdGhlciBGUlMgYXR0cmlidXRl cyByZWxhdGVkIHRvIFFvUyBhbmQgdHJhZmZpYyBhcmUgYSBtYXR0ZXIgb2YNCiAgIGJ1c2lu ZXNzIGRlY2lzaW9ucyBiZWNhdXNlIGEgbXVsdGl0dWRlIG9mIHBvc3NpYmlsaXRpZXMgYXJl IGF2YWlsYWJsZQ0KICAgdG8gc2VydmljZSBwcm92aWRlcnMuIEluIG9uZSBleHRyZW1lLCBh IHNlcnZpY2UgcHJvdmlkZXIgbWF5IG9mZmVyIGENCiAgIEZSUyB3aXRoIHZlcnkgc3RyaW5n ZW50IGNoYXJhY3RlcmlzdGljcyBhbmQgaW4gdGhlIG9wcG9zaXRlIGNhc2UsIGl0DQogICB3 aWxsIG5vdCBwcm92aWRlIGFueSBndWFyYW50ZWUgYW5kIHByb3ZpZGVzIGp1c3QgYSBiZXN0 IGVmZm9ydA0KICAgc2VydmljZS4NCg0KICAgSWYgd2UgYXNrIHRoZSBwcmV2aW91cyBxdWVz dGlvbiBpbiB0aGUgY29udGV4dCBvZiBQV0UzLCB3ZSBtdXN0IGZpcnN0DQogICBvYnNlcnZl IHRoYXQgUFdFMyBkb2VzIG5vdCByZXF1aXJlIHRoYXQgcHNldWRvLXdpcmVzIGVtdWxhdGUN CiAgIHBlcmZlY3RseSBvciBmYWl0aGZ1bGx5IHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhl IG5hdGl2ZSBzZXJ2aWNlLiBJbg0KICAgdGhlIGNhc2Ugb2YgRlJTIHRoaXMgbWVhbnMgdGhh dCB0aGUgcmVxdWlyZW1lbnRzIHRvIGRlbGl2ZXIgaW4NCiAgIHNlcXVlbmNlIHRoZSB1c2Vy J3MgZGF0YSBhbmQgdG8gZGV0ZWN0IHRyYW5zbWlzc2lvbiBlcnJvcnMgbWF5IGJlDQogICBy ZWxheGVkLg0KDQogICBGb3IgYm90aCB0aGUgb25lLXRvLW9uZSBtYXBwaW5nIG1vZGUgYW5k IG1hbnktdG8tb25lIG1hcHBpbmcvcG9ydA0KICAgbW9kZSwgd2UgaGF2ZSB0aGUgZm9sbG93 aW5nIGVtdWxhdGlvbiBwb3NzaWJpbGl0aWVzIHdpdGggcmVnYXJkIHRvDQogICB0aGUgdHdv IG1haW4gYXR0cmlidXRlcyBvZiBGUlM6DQoNCiAgICAgIC0gSW4tc2VxdWVuY2UgZGVsaXZl cnkgb2YgdXNlcidzIGRhdGE6DQoNCiAgICAgICAgIDEtSXQgaXMgcG9zc2libGUgdG8gZW11 bGF0ZSBwZXJmZWN0bHkvZmFpdGhmdWxseSB0aGlzDQogICAgICAgICAgIHJlcXVpcmVtZW50 LiBJZiB0aGUgUFNOIGRvZXMgbm90IGd1YXJhbnRlZSBpbiBzZXF1ZW5jZQ0KICAgICAgICAg ICBkZWxpdmVyeSwgdGhlIFBFcyBTSE9VTEQgdXNlIHRoZSBzZXF1ZW5jZSBudW1iZXIgY2Fw YWJpbGl0eQ0KICAgICAgICAgICBpbmNsdWRlZCBpbiBGUm9QVyBwYWNrZXRzIHRvIG51bWJl ciB0aGUgcGFja2V0cyBhbmQgY2hlY2sNCiAgICAgICAgICAgd2hldGhlciB0aGV5IGFyZSBy ZWNlaXZlZCBpbiBzZXF1ZW5jZSBvciBub3QuDQoNCiAgICAgICAgIDItQWx0ZXJuYXRpdmVs eSBhIHNlcnZpY2UgcHJvdmlkZXIgTUFZIGVsZWN0IHRvIGRyb3AgdGhlDQogICAgICAgICAg cmVxdWlyZW1lbnQgdG8gZGVsaXZlciBpbi1zZXF1ZW5jZSBGUm9QVyBwYWNrZXRzLiBJbiBn ZW5lcmFsLCANCiAgICAgICAgICB0aGlzIHByYWN0aWNlIGlzIE5PVCBSRUNPTU1FTkRFRCwg c2luY2UgaXQgbWF5IGFkdmVyc2VseSBhZmZlY3QgDQogICAgICAgICAgdGhlIGFwcGxpY2F0 aW9ucyBpbiB0aGUgQ0VzIA0KDQogICAgICAtIERldGVjdGlvbiBvZiB0cmFuc21pc3Npb24g ZXJyb3JzOg0KDQogICAgICAgICAgVGhpcyByZXF1aXJlbWVudCBNVVNUIGJlIHN1cHBvcnRl ZC4gVGhlIFBXIGxheWVyIGRvZXMgbm90IGhhdmUNCiAgICAgICAgICB0aGUgY2FwYWJpbGl0 eSB0byBkZXRlY3QgdHJhbnNtaXNzaW9uIGVycm9ycyBidXQgcmVsaWVzIG9uIHRoZQ0KICAg ICAgICAgIHVuZGVybHlpbmcgbGluayBsYXllciBwcm90b2NvbCBmb3IgdHJhbnNtaXNzaW9u IGVycm9yDQogICAgICAgICAgZGV0ZWN0aW9uLg0KDQogICBSZWdhcmRpbmcgRlJTIHRyYWZm aWMgYW5kIFFvUyBwYXJhbWV0ZXJzLCB0aGVyZSBpcyBubyBzdHJpY3QgcmVxdWlyZW1lbnRz DQogICB0byBtZWV0LiBGcmFtZSByZWxheSB0cmFmZmljIGFuZCBRb1MgYXR0cmlidXRlcyBk ZWZpbmVkIGluIHRoZQ0KICAgcmVsZXZhbnQgRlIgZG9jdW1lbnRzIGFsbG93IHNlcnZpY2Ug cHJvdmlkZXJzIHRvIG9mZmVyIHZhcmlvdXMNCiAgIGNvbWJpbmF0aW9ucyBvZiB0cmFmZmlj IGFuZCBRb1MgcGFyYW1ldGVycyB3aXRob3V0IGltcG9zaW5nIGFueQ0KICAgc3RyaWN0IHBl cmZvcm1hbmNlIG9iamVjdGl2ZXMuIFRoZSBzYW1lIHRoaW5nIHNob3VsZCBiZSBwb3NzaWJs ZSBpbiBhDQogICANCiAgIFBXRTMgbmV0d29yayBlbnZpcm9ubWVudCBhbmQgaXQgaXMgbm90 IHJlbGV2YW50IHRvIHJlZmVyIHRvIGhvdw0KICAgZmFpdGhmdWwvcGVyZmVjdCBGUlMgdHJh ZmZpYyBhbmQgUW9TIGF0dHJpYnV0ZXMgYXJlIHByb3ZpZGVkIGJlY2F1c2UNCiAgIG9mIHRo ZSB3aWRlIHNwZWN0cnVtIG9mIHBvc3NpYmlsaXRpZXMuDQogICANCkthd2EsIGV0IGFsLiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MjNdDQoNCgwNCkludGVybmV0IERyYWZ0ICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJl bGF5LTAzLnR4dCAgICAgIEF1Z3VzdCAyMDA0DQogICANCiAgIFRoZXJlIGlzIG9uZSBhZGRp dGlvbmFsIG5vdGUgdG8gYWRkIGFib3V0IEZSIHBvcnQgbW9kZS4gU2luY2UgdGhlDQogICBp bmRpdmlkdWFsIEZSIFZDcyBhcmUgbm90IHZpc2libGUgdG8gdGhlIFBFcyBpbmRpdmlkdWFs bHkgYnV0IG9ubHkgYXMNCiAgIGFuIGFnZ3JlZ2F0ZSwgdGhlIGZyYW1lIHJlbGF5IHNlcnZp Y2UsIGFuZCBpbiBwYXJ0aWN1bGFyLCB0aGUgdHJhZmZpYw0KICAgYW5kIFFvUyBwYXJhbWV0 ZXJzLCBwcm92aWRlZCB0byB0aGUgQ0VzIGRvZXMgbm90IGFwcGx5IHRvIHRoZQ0KICAgaW5k aXZpZHVhbCBGUiBWQ3MgYXNzaWduZWQgdG8gYSBwb3J0IGJ1dCB0byB0aGVpciBhZ2dyZWdh dGUuDQoNCg0KMTIuIElBTkEgY29uc2lkZXJhdGlvbnMNCg0KICAgTm8gSUFOQSBhY3Rpb25z IGFyZSByZXF1aXJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCjEzLiBTZWN1cml0eSBjb25z aWRlcmF0aW9ucw0KDQogICBQV0UzIHByb3ZpZGVzIG5vIG1lYW5zIG9mIHByb3RlY3Rpbmcg dGhlIGNvbnRlbnRzIG9yIGRlbGl2ZXJ5IG9mIHRoZQ0KICAgRlJvUFcgcGFja2V0cyBvbiBi ZWhhbGYgb2YgdGhlIG5hdGl2ZSBzZXJ2aWNlLiBQV0UzIG1heSwgaG93ZXZlciwNCiAgIGxl dmVyYWdlIHNlY3VyaXR5IG1lY2hhbmlzbXMgcHJvdmlkZWQgYnkgdGhlIFBTTiBUdW5uZWwg TGF5ZXIuIEEgbW9yZQ0KICAgZGV0YWlsZWQgZGlzY3Vzc2lvbiBvZiBQVyBzZWN1cml0eSBp cyBnaXZlIGluIFtQV0UzQVJDLCBQV0UzUkVRXS4NCg0KDQoxNC4gU3VwcGxlbWVudCBvbiBm cmFtZSByZWxheSBmcmFtZSBmb3JtYXRzDQoNCiAgICBGUiBmcmFtZSBmb3JtYXRzIGFyZSBk ZWZpbmVkIGluIElUVS1UIFJlY29tbWVuZGF0aW9uIFguMzYgW1gzNl0uDQogICAgVHdvIGZv cm1hdHMgYXJlIHVzZWQgaW4gdGhpcyBkb2N1bWVudC4gVGhlIGZpcnN0IG9uZSB1c2VzIDEw IGJpdHMNCiAgICBmb3IgdGhlIERMQ0kgKEZpZ3VyZSAxMS1hKSBhbmQgdGhlIHNlY29uZCBv bmUgdXNlcyAyMyBiaXRzIGZvciB0aGUNCiAgICBETENJIChGaWd1cmUgMTEtYikuDQoNCiAg ICBUaGUgZmlyc3QgYW5kIGxhc3Qgb2N0ZXRzIGFyZSBIRExDIG9wZW5pbmcgYW5kIGNsb3Np bmcgZmxhZ3MuIFRoZQ0KICAgIERMQ0kgb2NjdXBpZXMgdGhlIHNlY29uZCBhbmQgdGhpcmQg b2N0ZXRzIG9yIHRoZSBzZWNvbmQsIHRoaXJkLA0KICAgIGZvdXJ0aCBhbmQgZmlmdGggb2N0 ZXRzIGFzIHNob3duIGluIEZpZ3VyZSAxMS4gVGhlcmUgYXJlIHZhcmlvdXMNCiAgICBjb250 cm9sIGZpZWxkczoNCg0KICAgICAgQy9SIGlzIEhETEMgY29tbWFuZCBhbmQgcmVzcG9uc2Ug Yml0Lg0KICAgICAgRiBhbmQgQiBhcmUgcmVzcGVjdGl2ZWx5IHRoZSBmb3J3YXJkIGFuZCBi YWNrd2FyZCBjb25nZXN0aW9uDQogICAgICBub3RpZmljYXRpb24gYml0cy4NCiAgICAgIERF IGlzIHRoZSBkaXNjYXJkIGVsaWdpYmlsaXR5IGJpdC4NCiAgICAgIEZDUyBpcyB0aGUgZnJh bWUgY2hlY2sgc2VxdWVuY2UuIFR3byBnZW5lcmF0b3IgcG9seW5vbWlhbHMgYXJlDQogICAg ICB1c2VkLiBPbmUgcHJvZHVjZXMgYSAxNi1iaXQgc2VxdWVuY2UgW1gzNl0gYW5kIHRoZSBv dGhlciBhIDMyLWJpdA0KICAgICAgc2VxdWVuY2UgW0ZSRjE0XS4NCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCkthd2EsIGV0IGFsLiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjRdDQoNCgwNCkludGVybmV0 IERyYWZ0ICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAzLnR4dCAgICAgIEF1 Z3VzdCAyMDA0DQoNCiBiaXQgOCAgNyAgIDYgICA1ICAgNCAgIDMgICAyICAgMSAgICBiaXQg ICA4ICA3ICAgNiAgIDUgICA0ICAgMyAgIDIgICAxDQoNCiAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKyAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICB8ICAgICAgICAgICAgIEZsYWcgICAgICAgICAgICAgIHwgIHwgICAgICAgICAgICBGbGFn ICAgICAgICAgICAgICAgfA0KICAgfCAwICAxICAgMSAgIDEgICAgMSAgIDEgICAxICAgMCB8 ICB8IDAgIDEgICAxICAgMSAgICAxICAgMSAgIDEgICAwIHwNCiAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKyAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICB8ICAgVXBwZXIgRExDSSAgICAgICAgICB8Qy9SfCAwIHwgIHwgICBVcHBlciBETENJ ICAgICAgICAgIHxDL1J8IDAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0gICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgIExvd2VyIERM Q0kgICB8IEYgfCBCIHwgREV8IDEgfCAgfCAgIERMQ0kgICAgICAgIHwgRiB8IEIgfCBERXwg MCB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICB8ICAgICAgICAgICBETENJICAgICAgICAgICAgfCAwIHwNCiAgIDpGcmFtZSBy ZWxheSBpbmZvcm1hdGlvbiBmaWVsZCAgOiAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQogICA6ICAgICAgIChpLmUucGF5bG9hZCkgICAgICAgICAgIDogIHwgICAgICAg ICAgTG93ZXIgRExDSSAgIHwgMCB8IDEgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgfCBGcmFtZSByZWxheSBpbmZvcm1hdGlv biBmaWVsZCB8DQogICB8ICAgRkNTICgyIG9yIDQgb2N0ZXRzKSAgICAgICAgIHwgIDogICAg ICAoaS5lLiBwYXlsb2FkKSAgICAgICAgICAgOg0KICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOg0KICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgRmxhZyAgICAgICAgICAgICAgfCAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IDAgIDEgICAxICAgMSAgICAx ICAgMSAgIDEgICAwIHwgIHwgICAgICAgIEZDUyAoMiBvciA0IG9jdGV0cykgICAgfA0KICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICA6ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICBGbGFnICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IDAgIDEgICAxICAgMSAg ICAxICAgMSAgIDEgICAwIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCg0KICAgICBhLVdpdGgg MTAgYml0cyBmb3IgdGhlIERMQ0kgICAgICBiLVdpdGggMjMgYml0cyBmb3IgdGhlIERMQ0kN Cg0KDQogICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDExIC0gRnJhbWUgcmVsYXkgZnJh bWUgZm9ybWF0cw0KDQoNCjE1LiBSZWZlcmVuY2VzDQoNCltDT05UUk9MXSAgICAgICBMdWNh IE1hcnRpbmksIGV0IGFsLiwgUHNldWRvd2lyZSBTZXR1cCBhbmQgTWFpbnRlbmFuY2UNCiAg ICAgICAgICAgICAgICB1c2luZyBMRFAsIGRkcmFmdC1pZXRmLXB3ZTMtY29udHJvbC1wcm90 b2NvbC0wNS50eHQsIA0KICAgICAgICAgICAgICAgIEp1bmUgMjAwNCwgd29yayBpbiBwcm9n cmVzcy4NCg0KW0RJWF0gICAgICAgICAgIERpZ2l0YWwsIEludGVsIGFuZCBYZXJveCwgVGhl IEV0aGVybmV0LCBhIGxvY2FsIEFyZWENCiAgICAgICAgICAgICAgICBOZXR3b3JrIERhdGEg TGluayBhbmQgUGh5c2ljYWwgbGF5ZXIgU3BlY2lmaWNhdGlvbnMNCiAgICAgICAgICAgICAg ICB2ZXJzaW9ucyAxIGFuZCAyLg0KDQpbSTIzM10gICAgICAgICAgSVRVLVQgUmVjb21tZW5k YXRpb24gSS4yMzMuMSwgSVNETiBmcmFtZSByZWxheSBiZWFyZXINCiAgICAgICAgICAgICAg ICBzZXJ2aWNlLCBHZW5ldmEsIE9jdG9iZXIgMTk5MS4NCg0KW0ZSRjFdICAgICAgICAgIEZS Ri4xLjIsIEZyYW1lIHJlbGF5IFBWQyBVTkkgSW1wbGVtZW50YXRpb24gQWdyZWVtZW50LA0K ICAgICAgICAgICAgICAgIEZyYW1lIFJlbGF5IEZvcnVtLCBBcHJpbCAyMDAwLg0KDQpbRlJG Ml0gICAgICAgICAgRlJGLjIuMiwgRnJhbWUgcmVsYXkgUFZDIFVOSSBJbXBsZW1lbnRhdGlv biBBZ3JlZW1lbnQsDQogICAgICAgICAgICAgICAgRnJhbWUgUmVsYXkgRm9ydW0sIEFwcmls IDIwMDINCg0KW0ZSRjRdICAgICAgICAgIEZSRi40LjEsIEZyYW1lIHJlbGF5IFNWQyBVTkkg SW1wbGVtZW50YXRpb24gQWdyZWVtZW50LA0KICAgICAgICAgICAgICAgIEZyYW1lIFJlbGF5 IEZvcnVtLCBKYW51YXJ5IDIwMDAuDQoNCkthd2EsIGV0IGFsLiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjVdDQoNCgwNCkludGVy bmV0IERyYWZ0ICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZyYW1lLXJlbGF5LTAzLnR4dCAgICAg IEF1Z3VzdCAyMDA0DQoNCg0KW0ZSRjEwXSAgICAgICAgIEZSRi4xMC4xLCBGcmFtZSByZWxh eSBTVkMgTk5JIEltcGxlbWVudGF0aW9uIEFncmVlbWVudCwNCiAgICAgICAgICAgICAgICBG cmFtZSBSZWxheSBGb3J1bSwgSmFudWFyeSAyMDAwLg0KDQpbRlJGMTNdICAgICAgICAgRlJG LjEzLCBTZXJ2aWNlIExldmVsIERlZmluaXRpb24gSW1wbGVtZW50YXRpb24NCiAgICAgICAg ICAgICAgICBBZ3JlZW1lbnQsIEZyYW1lIFJlbGF5IEZvcnVtLCBBdWd1c3QgMTk5OC4NCg0K W0ZSRjE0XSAgICAgICAgIEZSRi4xNCwgUGh5c2ljYWwgbGF5ZXIgSW1wbGVtZW50YXRpb24g QWdyZWVtZW50LCBGcmFtZQ0KICAgICAgICAgICAgICAgIFJlbGF5IEZvcnVtLCBEZWNlbWJl ciAxOTk4Lg0KICAgICAgICAgICAgICAgIA0KW0ZSQUddICAgICAgICAgIEFuZHJldyBHLiBN YWxpcywgZXQgYWwuLCBQV0UzIEZyYWdtZW50YXRpb24gYW5kDQogICAgICAgICAgICAgICAg UmVhc3NlbWJseSwgZHJhZnQtaWV0Zi1wd2UzLWZyYWdtZW50YXRpb24tMDQudHh0LA0KICAg ICAgICAgICAgICAgIE9jdG9iZXIgMjAwMywgd29yayBpbiBwcm9ncmVzcy4NCg0KDQpbTDJU UFYzXSAgICAgICAgTS4gVG93bnNsZXksIGV0IGFsLiwgTGF5ZXIgVHdvIFR1bm5lbGluZyBQ cm90b2NvbA0KICAgICAgICAgICAgICAgIChWZXJzaW9uIDMpICJMMlRQdjMiLCBkcmFmdC1p ZXRmLWwydHBleHQtbDJ0cC1iYXNlLTExLnR4dCwNCiAgICAgICAgICAgICAgICBPY3RvYmVy IDIwMDMsIHdvcmsgaW4gcHJvZ3Jlc3MuLg0KDQpbUDgwMjFRXSAgICAgICBJRUVFIFN0ZCA4 MDIuMVEsIFZpcnR1YWwgYnJpZGdlZCBsb2NhbCBhcmVhIG5ldHdvcmtzLg0KDQpbUDgwMjNd ICAgICAgICBJRUVFIFN0ZCA4MDIuMywgUGFydCAzIENhcnJpZXIgc2Vuc2UgbXVsdGlwbGUg YWNjZXNzIHdpdGgNCiAgICAgICAgICAgICAgIGNvbGxpc2lvbiBkZXRlY3Rpb24gKENTTUEv Q0QpIGFjY2VzcyBtZXRob2QgYW5kIHBoeXNpY2FsDQogICAgICAgICAgICAgICBsYXllciBz cGVjaWZpY2F0aW9ucy4NCiAgICAgICAgICAgICAgIA0KW1BXRTNJQU5BXSAgICAgIEx1Y2Eg TWFydGluaSwgZXQgYWwuLCBJQU5BIEFsbG9jYXRpb25zIGZvciBwc2V1ZG8NCiAgICAgICAg ICAgICAgICBXaXJlIEVkZ2UgdG8gRWRnZSBFbXVsYXRpb24gKFBXRTMpLCANCiAgICAgICAg ICAgICAgICBkcmFmdC1pZXRmLXB3ZTMtaWFuYS1hbGxvY2F0aW9uLTAyLnR4dCwgT2N0b2Jl ciAyMDAzLCANCiAgICAgICAgICAgICAgICB3b3JrIGluIHByb2dyZXNzLg0KDQpbUFdFM1JF UV0gICAgICAgWGlQZW5nIFhpYW8sIGV0IGFsLiwgSW50ZXJuZXQgZHJhZnQsIGRyYWZ0LWll dGYtcHdlMy0NCiAgICAgICAgICAgICAgICByZXF1aXJlbWVudHMtMDgudHh0LCB3b3JrIGlu IHByb2dyZXNzLg0KDQpbUFdFM0FSQ10gICAgICAgU3Rld2FydCBCcnlhbnQsIGV0IGFsLixJ bnRlcm5ldCBkcmFmdCwgUFdFMyBBcmNoaXRlY3R1cmUsIA0KICAgICAgICAgICAgICAgIGRy YWZ0LWlldGYtcHdlMy1hcmNoLTA3LnR4dCwgd29yayBpbiBwcm9ncmVzcy4NCg0KW1JGQzMw MzJdICAgICAgIEUuIFJvc2VuLCBldCBhbC4sIFJGQyAzMDMyLCBNUExTIExhYmVsIFN0YWNr IGVuY29kaW5nLA0KICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwMS4NCg0KW1JGQzMwMzFd ICAgICAgIEUuIFJvc2VuLCBldCBhbC4sIFJGQyAzMDMxLCBNUExTIEFyY2hpdGVjdHVyZSwg SmFudWFyeQ0KICAgICAgICAgICAgICAgIDIwMDEuDQoNCg0KW1gzNl0gICAgICAgICAgIElU VS1UIFJlY29tbWVuZGF0aW9uIFguMzYsIEludGVyZmFjZSBiZXR3ZWVuIGEgRFRFIGFuZA0K ICAgICAgICAgICAgICAgIERDRSBmb3IgcHVibGljIGRhdGEgbmV0d29ya3MgcHJvdmlkaW5n IGZyYW1lIHJlbGF5LA0KICAgICAgICAgICAgICAgIEdlbmV2YSwgMjAwMC4NCg0KW1g3Nl0g ICAgICAgICAgIElUVS1UIFJlY29tbWVuZGF0aW9uIFguNzYsIE5ldHdvcmstdG8tbmV0d29y ayBpbnRlcmZhY2UNCiAgICAgICAgICAgICAgICBiZXR3ZWVuIHB1YmxpYyBkYXRhIG5ldHdv cmtzIHByb3ZpZGluZyBmcmFtZSByZWxheQ0KICAgICAgICAgICAgICAgIHNlcnZpY2VzLCBH ZW5ldmEsMjAwMC4NCg0KS2F3YSwgZXQgYWwuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyNl0NCg0KDA0KSW50ZXJuZXQgRHJhZnQg ICAgICBkcmFmdC1pZXRmLXB3ZTMtZnJhbWUtcmVsYXktMDMudHh0ICAgICAgQXVndXN0IDIw MDQNCg0KDQoNCjE2LiBBdXRob3IncyBBZGRyZXNzZXMNCg0KICAgQ2xhdWRlIEthd2ENCiAg IEVjb2xlIFBvbHl0ZWNobmlxdWUgIE1vbnRyZWFsDQogICBjbGF1ZGUua2F3YUBzeW1wYXRp Y28uY2ENCg0KICAgQW5kcmV3IEcuIE1hbGlzDQogICBUZWxsYWJzDQogICBhbmR5Lm1hbGlz QHRlbGxhYnMuY29tDQoNCiAgIFJhbyBDaGVydWt1cmkgDQogICBDaXNjbyBTeXN0ZW1zDQog ICByY2hlcnVrdUBjaXNjby5jb20gDQogICANCiAgIA0KICAgRGF2aWQgU2luaWNyb3BlDQog ICBFcmljc3NvbiBJUEkNCiAgIGRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20NCg0KICAg DQogICBQcmF5c29uIFBhdGUNCiAgIE92ZXJ0dXJlIE5ldHdvcmtzDQogICBwcmF5c29uLnBh dGVAb3ZlcnR1cmVuZXR3b3Jrcy5jb20NCg0KICAgUmF2aSBCaGF0DQogICBOb2tpYQ0KICAg cmF2aS5iaGF0QG5va2lhLmNvbQ0KDQogICBOaXNoaXQgVmFzYXZhZGENCiAgIE5va2lhDQog ICBuaXNoaXQudmFzYXZhZGFAbm9raWEuY29tDQogICANCiAgIEx1Y2EgTWFydGluaQ0KICAg Q2lzY28gU3lzdGVtcyBJbmMuDQogICBsbWFydGluaUBjaXNjby5jb20NCiAgIA0KICAgTmFz c2VyIEVsLUFhd2FyDQogICBMZXZlbCAzIENvbW11bmljYXRpb25zLCBMTEMuDQogICBubmFA bGV2ZWwzLm5ldA0KDQogICBHaWxlcyBIZXJvbg0KICAgVGVsbGFicw0KICAgZ2lsZXMuaGVy b25AdGVsbGFicy5jb20NCiANCiAgICBEaW1pdHJpIFN0cmF0dG9uIFZsYWNob3MNCiAgICBN YXp1IE5ldHdvcmtzLCBJbmMuDQogICAgZEBtYXp1bmV0d29ya3MuY29tDQogDQogICAgRGFu IFRhcHBhbg0KICAgIENpc2NvIFN5c3RlbXMsIEluYy4NCiAgIHRhcHBhbkBjaXNjby5jb20N CiAgIA0KIEthd2EsIGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgMjddDQogDQoMIA0KSW50ZXJuZXQgRHJhZnQgICAgICBk cmFmdC1pZXRmLXB3ZTMtZnJhbWUtcmVsYXktMDMudHh0ICAgICAgQXVndXN0IDIwMDQNCiAg IA0KDQogICBFcmljIFJvc2VuDQogICBDaXNjbyBTeXN0ZW1zLCBJbmMuDQogICBlcm9zZW5A Y2lzY28uY29tDQoNCiAgIFN0ZXZlIFZvZ2Vsc2FuZw0KICAgTGF1cmVsIE5ldHdvcmtzLCBJ bmMuDQogICBzanZAbGF1cmVsbmV0d29ya3MuY29tDQoNCiAgIFZpbmFpIFNpcmtheQ0KICAg UmVsaWFuY2UgSW5mb2NvbW0NCiAgIHZpbmFpQHNpcmtheS5jb20NCg0KDQogICBDaHJpcyBM aWxqZW5zdG9scGUNCiAgIENhYmxlICYgV2lyZWxlc3MNCiAgIGNocmlzQGN3Lm5ldA0KDQog ICBLaXJlZXRpIEtvbXBlbGxhDQogICBKdW5pcGVyIE5ldHdvcmtzDQogICBraXJlZXRpQGp1 bmlwZXIubmV0DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCkthd2EsIGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjhdDQoNCg0KDQo= ------=____1090950280715_W+SM0CH2OK 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 ------=____1090950280715_W+SM0CH2OK-- 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, 27 Jul 2004 13:52:25 -0400 Lines: 66 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 Jul 27 20:04:52 2004 Return-path: To: "'Mustapha Aissaoui'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 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. 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. > 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? 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. 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. 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. > > 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: Mustapha Aissaoui Subject: Re: Scaling hierarchical LDP/PW stitching Date: Tue, 27 Jul 2004 15:26:11 -0400 Organization: Alcatel Networks Corporaton Lines: 106 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, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Tue Jul 27 21:30:38 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: 9a2be21919e71dc6faef12b370c4ecf5 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 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: "Busschbach, Peter B (Peter)" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Tue, 27 Jul 2004 16:49:43 -0400 Lines: 181 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 Jul 27 22:56:44 2004 Return-path: To: "'Mustapha Aissaoui'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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 > 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: Mustapha Aissaoui Subject: Re: draft-ietf-pwe3-control-protocol-08.txt - partial last call Date: Wed, 28 Jul 2004 16:07:35 -0400 Organization: Alcatel Networks Corporaton Lines: 81 Sender: pwe3-bounces@ietf.org References: <4100EFF6.3050601@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Wed Jul 28 22:25:37 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Luca Martini , pwe3@ietf.org X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Luca, below are my comments on the latest revision of this draft. I took the liberty to also provide comments on sections other than those listed below. I believe the proposed changes are minor. Regards, Mustapha. ------------------------------------------------------------------------- 1. Section 4: remove details of OAM behaviour for each PW type, e.g., the whole section 4.2.4.1, section 4.2.5, and some text in section 4.3. The latter are covered in great details in draft-ietf-pwe3-oam-msg-map-00.txt. This section should only summarize the encapsulation for each PW type. 2. Section 4.6: remove last sentence. The PW control word may be required for the purpose of proper operation of inband PW OAM in a ECMP network. There is now a draft which puts together the encapsulation details for a IP PW, http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt. 3. Section 5.1: add a forward reference to Section 5.4 at the end of the section where the Interface Parameter field is defined. 4. Section 5.2: suggest to rename the title, and other occurences troughout the document, to "Generalized PW ID FEC ELEMENT". 5. Section 5.2.1: 5th paragraph states that the construction of the AGI and AII fields is application specific. What if two applications running on the same pair of PEs end up using the same contruction rules? Is the only way to prevent this from happening to encourage specific applications to request a codepoint type field from IANA? 6. Section 5.2.2: please provide a definition for the "PW info Length" field. If it does include the AGI/SAII/TAAI fields, then the minimum size of this will be 6 octets since the AGI, SAII, and TAAI type and length are always included when their length is zero. 7. Section 5.2.2.2: add the following sentence in the beginning of the section: "This TLV MUST only be used when sending the Generalized PW ID FEC.". 8. Section 5.2.2.2: the third paragraph describing the wildcard command is contradictory to the text in the last praragraph of Section 5.3.2. The former states that the "PW info Length" field must be set to zero and the AGI/SAII/TAII fields should not be included in the PW FEC element. The latter states that the AGI/SAII/TAII fields should be included but have their length field set to zero. This means that the "PW info Length" should be set to 6 octets. I propose we keep the latter behaviour which is consistent with the procedure described in 5.2.2 of always including the AGI, SAII, and TAII fields and zeroing the length of those identifiers which are not used by an application. 9. Sections 5.4.1 and 5.4.2 should be moved to a separate section titled "Handling of Control Word". 10. Section 5.4.3 should be removed as it is redundant with 6.4 and 6.5. 11. Section 5.5: this is specific to the PW ID FEC and should be moved into Section 5.1 under the description of the Group ID field. 12. Appendix B: can we remove this and fold the details into the second diagram in Section 5.3.2? ------------------------------------------------------------------------- Stewart Bryant wrote: > > This is the start of last call for sections 5.2, 5.3, and 7 of > > Pseudowire Setup and Maintenance using LDP > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-08.txt > > Last call will end Monday 9th August 2004 > > - 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: draft-ietf-pwe3-control-protocol-08.txt - partial last call Date: Wed, 28 Jul 2004 15:56:01 -0600 Organization: Cisco Systems Lines: 180 Sender: pwe3-bounces@ietf.org References: <4100EFF6.3050601@cisco.com> <41080787.9C7C1D01@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jul 29 00:09:32 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: Mustapha Aissaoui In-Reply-To: <41080787.9C7C1D01@alcatel.com> X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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 Aissaoui wrote: >Luca, >below are my comments on the latest revision of this draft. I took >the liberty to also provide comments on sections other than those >listed below. I believe the proposed changes are minor. > >Regards, >Mustapha. >------------------------------------------------------------------------- >1. Section 4: remove details of OAM behaviour for each PW type, >e.g., the whole section 4.2.4.1, section 4.2.5, and some text in >section 4.3. The latter are covered in great details in >draft-ietf-pwe3-oam-msg-map-00.txt. This section should only >summarize the encapsulation for each PW type. > > > not in last call - cannot change it. ( besides I do not want this document to depend on the msg mapping one. ) >2. Section 4.6: remove last sentence. The PW control word may be >required for the purpose of proper operation of inband PW OAM in a >ECMP network. There is now a draft which puts together the >encapsulation details for a IP PW, >http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt. > > > not in last call - cannot change it. ( The current design has been final for a long time. ) Also there is no encapsulation document describing this application. The encapsulation is in RFC3032, and there is no mention of control word there. >3. Section 5.1: add a forward reference to Section 5.4 at the end of >the section where the Interface Parameter field is defined. > > > ??? I'm not sure this is necessary , The index clearly states which page section 5.4 is .... >4. Section 5.2: suggest to rename the title, and other occurences >troughout the document, to "Generalized PW ID FEC ELEMENT". > > > Ok, Changed. >5. Section 5.2.1: 5th paragraph states that the construction of the >AGI and AII fields is application specific. What if two applications >running on the same pair of PEs end up using the same contruction >rules? Is the only way to prevent this from happening to encourage >specific applications to request a codepoint type field from IANA? > > > Yes. I believe that we need another separate document to actually bite the bullet and specify these fields. >6. Section 5.2.2: please provide a definition for the "PW info >Length" field. If it does include the AGI/SAII/TAAI fields, then the >minimum size of this will be 6 octets since the AGI, SAII, and TAAI >type and length are always included when their length is zero. > > > Yes, for some reason this text got dropped in one of the revisions : The PW information length field, contains the length of the SAII, TAII, AGI combined, and the interface parameters field in octets. If this value is 0, then it references all PWs using the specified grouping ID. In this case there are no other FEC element fields (AGI,SAII, etc. ) present, nor any interface parameters. I will add it back. I 'm not sure we need to mention then the minimum is 6 , since that is implied. >7. Section 5.2.2.2: add the following sentence in the beginning of >the section: "This TLV MUST only be used when sending the >Generalized PW ID FEC.". > > > Yes, that is definitely the intention. I had to change the MUST to MAY , as we do not want to make the TLV required , we just want to say it MAY only be used with the generalized FEC. >8. Section 5.2.2.2: the third paragraph describing the wildcard >command is contradictory to the text in the last praragraph of >Section 5.3.2. The former states that the "PW info Length" field >must be set to zero and the AGI/SAII/TAII fields should not be >included in the PW FEC element. The latter states that the >AGI/SAII/TAII fields should be included but have their length field >set to zero. This means that the "PW info Length" should be set to 6 >octets. >I propose we keep the latter behaviour which is consistent with the >procedure described in 5.2.2 of always including the AGI, SAII, and >TAII fields and zeroing the length of those identifiers which are >not used by an application. > > > Actually the intention was to use the former behavior to be the same as the PWID FEC. This text was written at a different time when the pw info field was removed for a short time. Unless you have a strong objection I made the text consistent, with no AGI/SAII/TAII present in the wild card withdraw message. >9. Sections 5.4.1 and 5.4.2 should be moved to a separate section >titled "Handling of Control Word". > > > you want me to renumber them ? Yes I will create a section for these. >10. Section 5.4.3 should be removed as it is redundant with 6.4 and >6.5. > > > Haa yes ... Eric ;-) added these to comply with the latest ID requirements. ( He evidently missed the existing section above ) Fixed. >11. Section 5.5: this is specific to the PW ID FEC and should be >moved into Section 5.1 under the description of the Group ID field. > > > Actually I think that this section is missing a mention of the grouping TLV in the first paragraph. The second paragraph is already "interface parameter TLV aware " I fixed the hole section to apply to both FECs as intended. >12. Appendix B: can we remove this and fold the details into the >second diagram in Section 5.3.2? >------------------------------------------------------------------------- > > Actually the reason this is in the appendix is that it is too specific to be used in section 5.3.2 . Yet I wanted to make sure there is no misunderstanding about the TLV encoding, so I picked a specific example and put it in the appendix. If this is really a problem we can delete it , but I would like to leave it as it can be useful. Thanks! Luca >Stewart Bryant wrote: > > >>This is the start of last call for sections 5.2, 5.3, and 7 of >> >>Pseudowire Setup and Maintenance using LDP >>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-08.txt >> >>Last call will end Monday 9th August 2004 >> >>- 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: "Yael Dayan" Subject: RE: I-D ACTION:draft-ietf-pwe3-ethernet-encap-07.txt Date: Thu, 29 Jul 2004 12:52:46 +0300 Lines: 87 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 Thu Jul 29 16:52:22 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-ethernet-encap-07.txt Thread-Index: AcRt4cXaPx2aj5RnTnutLps3JxJDIQHanYOA To: 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 Section 4 says: 'In tagged mode, each frame MUST contain an 802.1Q VLAN = tag, and the tag value is meaningful to the NSPs at the two PW endpoints.' Section 4.1.2 says: 'The tag is "service-delimiting". This means that = the tag was placed on the frame by some piece of provider-operated = equipment, and the tag is used by the provider to distinguish the = traffic.....If an ethernet PW is operating in tagged mode, every frame = sent on the PW MUST have a service-delimiting VLAN tag.' My questions is about tags that are placed by user equipment and are = meaningful to the operator's NSP. Obviously these tags need to be = coordinated between the user and the provider. Is this option out of = scope? If not, would one use raw mode or tagged mode? -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, July 19, 2004 10:58 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-ethernet-encap-07.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 : Encapsulation Methods for Transport of=20 Ethernet Frames Over IP/MPLS Networks Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-ethernet-encap-07.txt Pages : 1921 Date : 2004-7-19 =09 An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units over an IP or MPLS network. This enables service providers to offer 'emulated' ethernet services over existing IP or MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a 'point-to-point ethernet' service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-07.txt= To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-ethernet-encap-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-ethernet-encap-07.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Matthew.Bocci@alcatel.co.uk Subject: Comments on draft-shah-pwe3-PW-Qos_Signalling-00 Date: Thu, 29 Jul 2004 17:25:52 +0100 Lines: 28 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Thu Jul 29 20:14:20 2004 Return-path: To: pwe3@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/29/2004 17:27:04 X-Alcanet-MTA-scanned-and-authorized: yes X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Himanshu, I read your draft with interest, and have some initial comments as follows: The QoS TLV contains traffic parameters (traffic rates and associated tolerances), not QoS requirements (loss, delay etc), so I think it should be called Traffic Parameters or Traffic Descriptor TLV. The uses stated in section 6 for this TLV are unclear. The draft states that it is to signal tail end (egress) AC traffic parameters to the head end (ingress) PE. In the case of ATM ACs, the TLV does not convey service category or conformace definition information, so it cannot be used for policing by the head end PE, or selection of the appropriate PSN tunnel (it is not clear how this helps anyway as there is a N:1 relationship between ACs and PWs, not 1:N). If it could be used to configure the policer at the head end PE, this would not guarantee that traffic would pass a policer at a downstream AC because cell concatenation on the PW could cause the burst tolerance stated in the traffic contract for the ATM connection to be exceeded. Traffic may still need to be shaped from the PW to the tail AC. In general, I think this might be useful a configuration check between the 2 ACs, but it is not to me clear if it enables the other stated uses to be achieved. Thanks, Matthew From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Mustapha Aissaoui Subject: Re: draft-ietf-pwe3-control-protocol-08.txt - partial lastcall Date: Thu, 29 Jul 2004 13:18:37 -0400 Organization: Alcatel Networks Corporaton Lines: 207 Sender: pwe3-bounces@ietf.org References: <4100EFF6.3050601@cisco.com> <41080787.9C7C1D01@alcatel.com> <410820F1.5060700@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 Thu Jul 29 20:35:18 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Luca Martini X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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 Luca, Luca Martini wrote: > > Mustapha Aissaoui wrote: > > >Luca, > >below are my comments on the latest revision of this draft. I took > >the liberty to also provide comments on sections other than those > >listed below. I believe the proposed changes are minor. > > > >Regards, > >Mustapha. > >------------------------------------------------------------------------- > >1. Section 4: remove details of OAM behaviour for each PW type, > >e.g., the whole section 4.2.4.1, section 4.2.5, and some text in > >section 4.3. The latter are covered in great details in > >draft-ietf-pwe3-oam-msg-map-00.txt. This section should only > >summarize the encapsulation for each PW type. > > > > > > > not in last call - cannot change it. ( besides I do not want this > document to depend on the msg mapping one. ) MA> I am suggesting not to make any reference to OAM behaviour or OAM draft in this document. Each encapsulation draft has some text on OAM and the details are in draft-ietf-pwe3-oam-msg-map-00.txt. I would prefer that we do not have many documents with inconsistent procedures. > >2. Section 4.6: remove last sentence. The PW control word may be > >required for the purpose of proper operation of inband PW OAM in a > >ECMP network. There is now a draft which puts together the > >encapsulation details for a IP PW, > >http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt. > > > > > > > not in last call - cannot change it. ( The current design has been final > for a long time. ) > Also there is no encapsulation document describing this application. The > encapsulation is in RFC3032, and there is no mention of control word there. MA> I understand your concern but I am still uncomfortable with this. I rather have the option to signal it than not to. Maybe, the last sentence should be the default behavior instead of the only behavior. > >3. Section 5.1: add a forward reference to Section 5.4 at the end of > >the section where the Interface Parameter field is defined. > > > > > > > ??? I'm not sure this is necessary , The index clearly states which page > section 5.4 is .... > > >4. Section 5.2: suggest to rename the title, and other occurences > >troughout the document, to "Generalized PW ID FEC ELEMENT". > > > > > > > Ok, Changed. > > >5. Section 5.2.1: 5th paragraph states that the construction of the > >AGI and AII fields is application specific. What if two applications > >running on the same pair of PEs end up using the same contruction > >rules? Is the only way to prevent this from happening to encourage > >specific applications to request a codepoint type field from IANA? > > > > > > > Yes. I believe that we need another separate document to actually bite > the bullet and specify these fields. > > >6. Section 5.2.2: please provide a definition for the "PW info > >Length" field. If it does include the AGI/SAII/TAAI fields, then the > >minimum size of this will be 6 octets since the AGI, SAII, and TAAI > >type and length are always included when their length is zero. > > > > > > > Yes, for some reason this text got dropped in one of the revisions : > > The PW information length field, contains the length of the SAII, TAII, > AGI combined, and the interface parameters field in octets. If this > value is 0, then it references all PWs using the specified grouping ID. > In this case there are no other FEC element fields (AGI,SAII, etc. ) > present, nor any interface > parameters. > > I will add it back. I 'm not sure we need to mention then the minimum is > 6 , since that is implied. MA> OK. > >7. Section 5.2.2.2: add the following sentence in the beginning of > >the section: "This TLV MUST only be used when sending the > >Generalized PW ID FEC.". > > > > > > > Yes, that is definitely the intention. I had to change the MUST to MAY > , as we do not want to make the TLV required , we just want to say it > MAY only be used with the generalized FEC. > > >8. Section 5.2.2.2: the third paragraph describing the wildcard > >command is contradictory to the text in the last praragraph of > >Section 5.3.2. The former states that the "PW info Length" field > >must be set to zero and the AGI/SAII/TAII fields should not be > >included in the PW FEC element. The latter states that the > >AGI/SAII/TAII fields should be included but have their length field > >set to zero. This means that the "PW info Length" should be set to 6 > >octets. > >I propose we keep the latter behaviour which is consistent with the > >procedure described in 5.2.2 of always including the AGI, SAII, and > >TAII fields and zeroing the length of those identifiers which are > >not used by an application. > > > > > > > Actually the intention was to use the former behavior to be the same as > the PWID FEC. > This text was written at a different time when the pw info field was > removed for a short time. > Unless you have a strong objection I made the text consistent, with no > AGI/SAII/TAII present in the wild card withdraw message. MA> I am OK with this proposal. Thus, you are going to correct the text in Section 5.3.2 in the case of the wildcard status message to state that AGI/SAII/TAII must not be included. > >9. Sections 5.4.1 and 5.4.2 should be moved to a separate section > >titled "Handling of Control Word". > > > > > > > you want me to renumber them ? Yes I will create a section for these. MA> Yes. They are currently sitting in Section 5.4 "Interface Parameter Field" :-) > >10. Section 5.4.3 should be removed as it is redundant with 6.4 and > >6.5. > > > > > > > Haa yes ... Eric ;-) added these to comply with the latest ID > requirements. ( He evidently missed the existing section above ) > Fixed. > > >11. Section 5.5: this is specific to the PW ID FEC and should be > >moved into Section 5.1 under the description of the Group ID field. > > > > > > > Actually I think that this section is missing a mention of the grouping > TLV in the first paragraph. > The second paragraph is already "interface parameter TLV aware " > I fixed the hole section to apply to both FECs as intended. > > >12. Appendix B: can we remove this and fold the details into the > >second diagram in Section 5.3.2? > >------------------------------------------------------------------------- > > > > > Actually the reason this is in the appendix is that it is too specific > to be used in section 5.3.2 . Yet I wanted to make sure there is no > misunderstanding about the TLV encoding, so I picked a specific example > and put it in the appendix. > If this is really a problem we can delete it , but I would like to leave > it as it can be useful. MA> What is so specific about the diagram in Appendix B that makes it an example? Besides, I think there is an extra field "PWID FEC" which should be removed (probably left from an older revision which did not include the GID FEC). > Thanks! > Luca > > >Stewart Bryant wrote: > > > > > >>This is the start of last call for sections 5.2, 5.3, and 7 of > >> > >>Pseudowire Setup and Maintenance using LDP > >>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-08.txt > >> > >>Last call will end Monday 9th August 2004 > >> > >>- 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: neil.2.harrison@bt.com Subject: RE: Comments on draft-shah-pwe3-PW-Qos_Signalling-00 Date: Fri, 30 Jul 2004 08:53:21 +0100 Lines: 122 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 Fri Jul 30 16:18:13 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Comments on draft-shah-pwe3-PW-Qos_Signalling-00 Thread-Index: AcR1nyPnuUIFLi3gQpiGtUsoQbsAYQAWtzsw To: , X-OriginalArrivalTime: 30 Jul 2004 07:53:21.0472 (UTC) FILETIME=[48B3F400:01C4760A] X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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 Matthew...please see below.....but let me make it clear these comments are not specifically aimed at you....my hope is folks take note of them and do think seriously about. > Himanshu, >=20 > I read your draft with interest, and have some initial=20 > comments as follows: >=20 > The QoS TLV contains traffic parameters (traffic rates and=20 > associated tolerances), not QoS requirements (loss, delay=20 > etc), so I think it should be called Traffic Parameters or=20 > Traffic Descriptor TLV. NH=3D> {Preface - What follows may sound initially picky, but we are getting very concerned at the amount of flawed/poor network architecture we are seeing and the use of vague/loose terminology. This is already causing us operational problems with the limited stuff deployed and we don't see things improving given the current direction.....in fact its my view things are actually going to get worse. For example, if/when we ever get to the stage of trying to interwork layer networks owned by different operators using some of the technologies being discussed here (both in a vertical client/server sense and a horizontal same-layer sense, ie across an E-NNI) then we will require a precise specification that may have contractual obligations. So there are not only technical considerations but also commercial considerations (and for some operators possibly even regulatory considerations) here......however, the former needs to be right to enable the latter.} QoS is a subjective concept. It represents a particular application's/user's perception of 'quality' for a given set of (objective) Network Performance (NP) impairments. For a fixed level of NP impairments (across loss/error/delay metrics) different applications/users can have very different perceptions of 'quality'. So it is the NP parameters that must be specified. However, this alone is not sufficient....... Operators will need to be able to unambiguously measure the NP parameters at key points, eg NNIs and trail termination points, to be sure they are meeting contractual SLAs. So this immediately means there is a requirement for the following: - specification of a HRX (Hypothetical Reference Connection) with end-end objectives and their apportionment to partitions of this HRX, ie the impairment allowance an operator has to stay within over some agreed measurement period. - NP measurements are only meaningful in the up-state and their measurement against NP SLAs must be suspended in the down-state.....this means we need a clear specification of the (un)availability metric (before we can even consider the NP measurement) and this also requires its own SLA; - (un)availability is, in turn, predicated on the specification of defects. These are *different* for each network mode as I have tried to point out in past mails (though they should be consistent within each mode, *provided* the arch constraints of the mode are not violated). Defects per mode need defining with clear entry/exit criteria and consequent actions. This is a must-have requirement anyway simply for day-day operational management. None of the above is being properly addressed in this WG....and I am not sure it ever will/can be. So there is no basis to even start to talk about 'QoS' or more accurately NP. Its quite clear IMO that there will be downstream problems arising when operators want to interwork and have to meet contractual SLAs. =20 >=20 > The uses stated in section 6 for this TLV are unclear. The=20 > draft states that it is to signal tail end (egress) AC=20 > traffic parameters to the head end > (ingress) PE. In the case of ATM ACs, the TLV does not convey=20 > service category or conformace definition information, so it=20 > cannot be used for policing by the head end PE, or selection=20 > of the appropriate PSN tunnel NH=3D> Quite. But where is the NP/(un)availability/defect = specifications of the PSN technologies defined anyway? If you don't have this then how on earth do you think one can make meaningful 'mappings' here? None of this stuff stands-up to any critical examination. > (it is not clear how this helps=20 > anyway as there is a N:1 relationship between ACs and PWs,=20 > not 1:N). NH=3D> Right again. This also gives one a big hint that a server = layer's transfer NP must be meet/exceed the client's NP transfer NP requirements. However, there are no rules for this between the 3 modes as yet, nor indeed how many such client/server transitions between different modes can be allowed in some HRX. > If it could be used to configure the policer at the=20 > head end PE, this would not guarantee that traffic would pass=20 > a policer at a downstream AC because cell concatenation on=20 > the PW could cause the burst tolerance stated in the traffic=20 > contract for the ATM connection to be exceeded. NH=3D> Right again.....and this is exactly the point above, ie the = server layer's transfer performance must be better than the client's......and none of this is specified. Note - I am not saying any of the above is easy. The key point I am making however is this: If the technology/architecture has not specified (or cannot specify) its defects up-front then the rest (ie availability/NP SLAs) have no chance of being properly addressed later. Regards, Neil > Traffic may=20 > still need to be shaped from the PW to the tail AC. >=20 > In general, I think this might be useful a configuration=20 > check between the 2 ACs, but it is not to me clear if it=20 > enables the other stated uses to be achieved. >=20 > Thanks, >=20 > Matthew >=20 >=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: neil.2.harrison@bt.com Subject: RE: draft-ietf-pwe3-control-protocol-08.txt - partial lastcall Date: Fri, 30 Jul 2004 08:53:19 +0100 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 Fri Jul 30 16:26:57 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-control-protocol-08.txt - partial lastcall Thread-Index: AcR1oFbWapF8Tok7S4WcRznF6L0MIgAZdvQQ To: , X-OriginalArrivalTime: 30 Jul 2004 07:53:20.0160 (UTC) FILETIME=[47EBC200:01C4760A] 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 Mustapha, Luca, > > >1. Section 4: remove details of OAM behaviour for each PW type, > > >e.g., the whole section 4.2.4.1, section 4.2.5, and some text in > > >section 4.3. The latter are covered in great details in > > >draft-ietf-pwe3-oam-msg-map-00.txt. This section should only > > >summarize the encapsulation for each PW type. > > > > > > > > > > > not in last call - cannot change it. ( besides I do not want this=20 > > document to depend on the msg mapping one. ) NH=3D> You are wise to do this IMO, though I am not sure your (alternative) intentions may be sound either.....I could hazard a guess you are looking for the signalling protocol (LDP perhaps?) to convey fault-notifications. From what I have seen so far there is a poor understanding of what is required (from both technical and commercial considerations) when we interwork layer networks in a client/server sense and a peer-partition sense (esp when the layer networks involved belong to different modes). >=20 > MA> I am suggesting not to make any reference to OAM behaviour or > OAM draft in this document. Each encapsulation draft has some=20 > text on OAM and the details are in=20 > draft-ietf-pwe3-oam-msg-map-00.txt. I would prefer that we do=20 > not have many documents with inconsistent procedures. > =20 > > >2. Section 4.6: remove last sentence. The PW control word may be=20 > > >required for the purpose of proper operation of inband PW OAM in a=20 > > >ECMP network. There is now a draft which puts together the=20 > > >encapsulation details for a IP PW,=20 > > >http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt. NH=3D> I've just read this. I have some problems with this draft, and = IMO it also demonstrates a lack of understanding of interworking requirements between different technologies/modes. If I get chance later today I'll drop the principle author a note on this. Regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: Draft PWE3 Charter Date: Fri, 30 Jul 2004 15:22:32 +0100 Lines: 97 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Danny McPherson X-From: pwe3-bounces@ietf.org Fri Jul 30 16:52:34 2004 Return-path: X-BrightmailFiltered: true 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: 5011df3e2a27abcc044eaa15befcaa87 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 Here is the proposed updated PWE3 Charter that Danny and I sent to Thomas a little while ago. We will be working on this at the meeting next week, but comments ahead of time would be appreciated. - Stewart Description of Working Group: Network operators and their subscribers are seeking to rationalize their networks by migrating to a single, IP or MPLS based packet switched network. This migration requires communications services that can emulate the essential properties of traditional communications links over a packet switched network (PSN). Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF specified packet switched networks. A pseudowire emulates a point-to-point link, and provides a service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree cost-performance trade-off. In some cases it may necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions will provide an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless needed as part of the emulation is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the two ends of the PW. PWE3 will use RTP where necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and payloads will follow RFC 2736. WG Objectives (in order of priority): Specify the following PW types: Ethernet, Frame Relay, PPP, HDLC, ATM, TDM and SONET Specify the control and management of the PW types identified above. 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. 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. Define mechanisms to permit the operation of a PW over a PSN that deploys equal cost multiple path packet (ECMP) switching. Specify the encapsulation, control and management of an IP PW type. A PW operating over a shared PSN does not have the same intrinsic security as a dedicated purpose built network. In some cases this is perfectly satisfactory. In other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. Whilst a service provider may traffic engineer their network is such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Define mechanisms to allow the interconnection of PWs. Define mechanisms to allow the inter-domain operation of PWs. Define the mechanisms needed to allow the operation of switched virtual circuits over a PSN. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Chris Metz Subject: RE: Scaling hierarchical LDP/PW stitching Date: Fri, 30 Jul 2004 10:12:16 -0700 Lines: 194 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: l2vpn@ietf.org, pwe3@ietf.org, 'Mustapha Aissaoui' , "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Fri Jul 30 19:24:02 2004 Return-path: X-BrightmailFiltered: true X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Busschbach, Peter B (Peter)" In-Reply-To: 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 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: "Busschbach, Peter B (Peter)" Subject: RE: Scaling hierarchical LDP/PW stitching Date: Fri, 30 Jul 2004 14:36:52 -0400 Lines: 242 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: l2vpn@ietf.org, pwe3@ietf.org, 'Mustapha Aissaoui' , "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Fri Jul 30 20:51:05 2004 Return-path: To: "'Chris Metz'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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 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. 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. 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: "Busschbach, Peter B (Peter)" Subject: RE: Draft PWE3 Charter Date: Fri, 30 Jul 2004 14:46:47 -0400 Lines: 130 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Thomas Narten , Danny McPherson X-From: pwe3-bounces@ietf.org Fri Jul 30 21:02:25 2004 Return-path: To: "'Stewart Bryant'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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 Hi Stewant, Two comments: 1) "Define mechanisms to allow the interconnection of PWs" I propose that we formulate this as "define mechanisms to create multi-hop PWs". A PW that consists of multiple segments is from a user's perspective still a single emulated point-to-point link, i.e. a single PW. A PW segment by itself is nothing. So, the issue is not interconnecting PWs, but interconnecting PW segments to create a PW. 2) "Define the mechanisms needed to allow the operation of switched virtual circuits over a PSN." Could this be clarified? To me this seems to be primarily as issue related to the control plane protocol of the emulated service (e.g. PNNI). Why would the IETF work on that? PWE3 provides the tools for PW setup. How they are used is outside the scope of the WG. Peter > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, July 30, 2004 10:23 AM > To: pwe3@ietf.org > Cc: Thomas Narten; Danny McPherson > Subject: [PWE3] Draft PWE3 Charter > > > Here is the proposed updated PWE3 Charter that Danny and I sent > to Thomas a little while ago. > > We will be working on this at the meeting next week, but comments > ahead of time would be appreciated. > > - Stewart > > > Description of Working Group: > > Network operators and their subscribers are seeking to rationalize > their networks by migrating to a single, IP or MPLS based packet > switched network. This migration requires communications > services that can emulate the essential properties of traditional > communications links over a packet switched network (PSN). > > Pseudowire Emulation Edge to Edge (PWE3) will specify the > encapsulation, > transport, control, management, interworking and security of > services emulated over IETF specified packet switched networks. > > A pseudowire emulates a point-to-point link, and provides a > service which is perceived by its user as an unshared link > or circuit of the chosen service. > > It is not intended that an emulated service will be > indistinguishable from the service that is being emulated. > The emulation need only be sufficient for the satisfactory > operation of the service. Emulation necessarily involves > a degree cost-performance trade-off. In some cases it may > necessary to design more than one emulation mechanism in > order to resolve these design conflicts. All emulated > service definitions will provide an applicability statement > describing the faithfulness of the emulation. > > Switching, multiplexing, modification or other operation on > the traditional service, unless needed as part of the emulation > is out of the scope of the PWE3 WG. > > PWE3 will make use of existing IETF specified mechanisms > unless there are technical reasons why the existing mechanisms > are insufficient or unnecessary. > > PWE3 will not exert control on the underlying PSN, other than > to use any existing QoS or path control mechanism to provide > the required connectivity between the two ends of the PW. > > PWE3 will use RTP where necessary to perform clock recovery and > other real-time signaling functions. This work will be > coordinated with the AVT WG and payloads will follow RFC 2736. > > > WG Objectives (in order of priority): > > Specify the following PW types: > Ethernet, Frame Relay, PPP, HDLC, ATM, TDM and SONET > > Specify the control and management of the PW types > identified above. > > 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. > > 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. > > Define mechanisms to permit the operation of a PW over > a PSN that deploys equal cost multiple path packet (ECMP) > switching. > > Specify the encapsulation, control and management of an > IP PW type. > > A PW operating over a shared PSN does not have the same > intrinsic security as a dedicated purpose built network. > In some cases this is perfectly satisfactory. In other > cases it will be necessary to enhance the security of > the PW to emulate the intrinsic security of the > emulated service. > > Whilst a service provider may traffic engineer their network > is such a way that PW traffic will not cause significant > congestion, a PW deployed by an end-user may cause > congestion of the underlying PSN. Suitable congestion > mechanisms are therefore needed to protect the Internet > from the unconstrained deployment of PWs. > > Define mechanisms to allow the interconnection of PWs. > > Define mechanisms to allow the inter-domain operation of PWs. > > Define the mechanisms needed to allow the operation of switched > virtual circuits over a PSN. > > > > _______________________________________________ > 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: Fri, 30 Jul 2004 18:02:44 -0400 Organization: Alcatel Networks Corporaton Lines: 250 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, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Sat Jul 31 00:07:35 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: 6907f330301e69261fa73bed91449a20 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, 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. 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: dimitri papadimitriou Subject: Re: Scaling hierarchical LDP/PW stitching Date: Sat, 31 Jul 2004 01:24:00 +0200 Lines: 319 Sender: pwe3-bounces@ietf.org References: <410AC584.1C0BB129@alcatel.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, "Busschbach, Peter B \(Peter\)" , pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Sat Jul 31 01:31:06 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: Mustapha Aissaoui In-Reply-To: <410AC584.1C0BB129@alcatel.com> X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 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, see in-line Mustapha Aissaoui wrote: > 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. > > 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. PW labels are keeping a (FA link) local scope (using the figure PE1-SN1 or SN1-SN3 for instance) > 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. one assigns a specific SC for the inherited FA link, this can be couple to the discovery of this capability beforehand through advertisement of the stitching node interface capability > 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 > 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 > > > > . >