From ben@niven-jenkins.co.uk Sun Apr 3 11:37:49 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E83028C0F2 for ; Sun, 3 Apr 2011 11:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njpPVKGbMvkr for ; Sun, 3 Apr 2011 11:37:48 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 4B97E28C0EE for ; Sun, 3 Apr 2011 11:37:47 -0700 (PDT) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.202]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Q6SCu-0000Jj-Jr; Sun, 03 Apr 2011 19:39:28 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit From: Benjamin Niven-Jenkins Date: Sun, 3 Apr 2011 19:39:26 +0100 To: Giles Heron X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 18:37:49 -0000 On 31 Mar 2011, at 12:27, Giles Heron wrote: > On 31/03/2011 09:20, "Stewart Bryant" wrote: > >> On 30/03/2011 14:55, Greg Mirsky wrote: >>> Dear Sasha, >>> I believe that there should not be MS-PW that crosses TP and non-TP >>> domains. >> That diminishes the generality of the design, which would in my view be >> a bad thing. > > Agreed. I'd expect the most common use case for TP is in the > access/aggregation. So you might have an MS-PW with 3 segments: > > MPLS TP <-> IP/MPLS <-> MPLS-TP. That was certainly the use case I was looking at using TP for when I wrote http://tools.ietf.org/html/draft-jenkins-mpls-tp-bt-requirements-00 Ben From neil.2.harrison@bt.com Mon Apr 4 01:46:38 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0DD3A694F for ; Mon, 4 Apr 2011 01:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl95Mcq4yLw3 for ; Mon, 4 Apr 2011 01:46:31 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 1C2DA3A6946 for ; Mon, 4 Apr 2011 01:46:30 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 4 Apr 2011 09:48:11 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.160]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 4 Apr 2011 09:48:11 +0100 From: To: , Date: Mon, 4 Apr 2011 09:48:10 +0100 Thread-Topic: [PWE3] GAL above and below the PW label Thread-Index: AcvyLnvGjRQiY4M7SjGLVFaojeTC9gAbFjKA Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4401C557849@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 08:46:38 -0000 Hi Ben, > Benjamin Niven-Jenkins wrote 03 April 2011 19:39 >=20 > On 31 Mar 2011, at 12:27, Giles Heron wrote: >=20 > > On 31/03/2011 09:20, "Stewart Bryant" wrote: > > > >> On 30/03/2011 14:55, Greg Mirsky wrote: > >>> Dear Sasha, > >>> I believe that there should not be MS-PW that crosses TP and non-TP > >>> domains. > >> That diminishes the generality of the design, which would in my view > be > >> a bad thing. > > > > Agreed. I'd expect the most common use case for TP is in the > > access/aggregation. So you might have an MS-PW with 3 segments: > > > > MPLS TP <-> IP/MPLS <-> MPLS-TP. >=20 > That was certainly the use case I was looking at using TP for when I > wrote >=20 > http://tools.ietf.org/html/draft-jenkins-mpls-tp-bt-requirements-00 >=20 > Ben To be clear Ben, I assume: 1 You are implying that there is a proper client/server relationship betwee= n each of the 3 MPLS server layer network partitions you identify above, wh= ere the PW layer network is transparently carried across each of the 3 inde= pendent server MPLS domains (which of course can belong to different operat= ing parties). Aside=3D> There is of course an even higher layer network X link connection= carried transparently by the E2E PW layer network path connection. 2 There is no 'peering' between logically adjacent server layer MPLS layer = networks.....noting that non-TOS layer networks never need to peer in any c= ase. Note that an immediate corollary of the above is that the routing instance = of the PW layer network must be obviously disjoint from any of the 3 server= MPLS layer networks. Am I reading you correct here? regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 =09 From curtis@occnc.com Mon Apr 4 16:46:38 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500F63A6821 for ; Mon, 4 Apr 2011 16:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3mJvWVtcpVa for ; Mon, 4 Apr 2011 16:46:37 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 9CC953A6767 for ; Mon, 4 Apr 2011 16:46:37 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p34NmEt9026908; Mon, 4 Apr 2011 19:48:14 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104042348.p34NmEt9026908@harbor.orleans.occnc.com> To: venkatesan mahalingam From: Curtis Villamizar In-reply-to: Your message of "Thu, 31 Mar 2011 15:45:31 EDT." Date: Mon, 04 Apr 2011 19:48:14 -0400 Sender: curtis@occnc.com Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 23:46:38 -0000 In message venkatesan mahalingam writes: > > Hi, > > >> > You don't want ECMP to hash on PW payload. With CW and without > >> > fat-pw, you don't get ECMP on a PW but you do get ECMP on an LSP > >> > containing many PW. > >> > >> When the PW payload is IP, the hashing it for ECMP is useful (If the > >> payload is not IP then use CW). FAT-PW may not be present in all > >> deployments. > > > > I really don't know that any PW are carrying IP. That was not in the > > survey. L3VPN would be carrying IP. > > Why are we very much concerned about the ECMP in MPLS-TP networks? Because some of us are realists. > I think, as per the RFC-5960, > > Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on > an MPLS-TP LSP. That is all fine and well. The case that is being discussed is an expected common case with an MS-PW where a MPLS-TP LSP in the access tier on one side, one or more MPLS LSP is traversed in the regional or core tier, and an MPLS-TP may be traversed in the access tier on the other side. In both MPLS-TP LSP there may be no need for multipath (for example LAG or link bundle). In the core LAG or link bundle may be essential, but there LSP are MPLS, not MPLS-TP. > Thanks, > Venkat. > Re: [PWE3] GAL above and below the PW label Curtis From neil.2.harrison@bt.com Tue Apr 5 00:35:32 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77153A68DC for ; Tue, 5 Apr 2011 00:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CgAC8+Ok3e6 for ; Tue, 5 Apr 2011 00:35:25 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 8932B3A68D0 for ; Tue, 5 Apr 2011 00:35:25 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 5 Apr 2011 08:37:07 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Tue, 5 Apr 2011 08:37:07 +0100 From: To: , Date: Tue, 5 Apr 2011 08:37:01 +0100 Thread-Topic: [PWE3] GAL above and below the PW label Thread-Index: AcvzIspvttU0feXGT/iN127OG4E6jgAPI+Ew Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4401CF7D4BB@EMV62-UKRD.domain1.systemhost.net> References: Your message of "Thu, 31 Mar 2011 15:45:31 EDT." <201104042348.p34NmEt9026908@harbor.orleans.occnc.com> In-Reply-To: <201104042348.p34NmEt9026908@harbor.orleans.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 07:35:32 -0000 Curtis, You wrote 05 April 2011 00:48 to Venkat: > To: venkatesan mahalingam > Cc: pwe3@ietf.org > Subject: Re: [PWE3] GAL above and below the PW label >=20 >=20 > In message X8aT1uxMGThO@mail.gmail.com> > venkatesan mahalingam writes: > > > > Hi, > > > > >> > You don't want ECMP to hash on PW payload. With CW and without > > >> > fat-pw, you don't get ECMP on a PW but you do get ECMP on an LSP > > >> > containing many PW. > > >> > > >> When the PW payload is IP, the hashing it for ECMP is useful (If > the > > >> payload is not IP then use CW). FAT-PW may not be present in all > > >> deployments. > > > > > > I really don't know that any PW are carrying IP. That was not in > the > > > survey. L3VPN would be carrying IP. > > > > Why are we very much concerned about the ECMP in MPLS-TP networks? >=20 > Because some of us are realists. >=20 > > I think, as per the RFC-5960, > > > > Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed > on > > an MPLS-TP LSP. >=20 > That is all fine and well. The case that is being discussed is an > expected common case with an MS-PW where a MPLS-TP LSP in the access > tier on one side, one or more MPLS LSP is traversed in the regional or > core tier, and an MPLS-TP may be traversed in the access tier on the > other side. >=20 > In both MPLS-TP LSP there may be no need for multipath (for example > LAG or link bundle). In the core LAG or link bundle may be essential, > but there LSP are MPLS, not MPLS-TP. I don't understand your point here and why you are saying Venkat is wrong a= nd (in particular) 'not being realistic'. =20 The key point is this: Why should the 2 outer MPLS-TP layer network partit= ions care (or even know) what is happening in the core MPLS layer partition= wrt ECMP (or any other transparency violation) behaviour?=20 If you don't get this instantly try this architecturally identical alternat= ive case: Consider an IP layer network where each link connection is serve= d by a different server layer network technology X, Y, Z, etc, and in the m= ost general case each may be owned by a different party. Why should the se= rver layer technology partition X care (or even know about) what any other = server layer technology partition Y, Z, etc is doing here across the whole = span of the client IP layer network? Hopefully it should be quite clear that: (i) each server layer technology partition must be independent of any other= server layer technology partition,=20 (ii) they all must form a pukka client/server relationship with the common = IP layer client, and (in particular) (ii) carry it transparently..else the owner of the IP layer client would no= t be very happy ;-) regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 >=20 > > Thanks, > > Venkat. > > Re: [PWE3] GAL above and below the PW label >=20 > Curtis > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From curtis@occnc.com Tue Apr 5 13:19:16 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C693A67A3 for ; Tue, 5 Apr 2011 13:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRrsX0yPQ5jW for ; Tue, 5 Apr 2011 13:19:15 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id D3EBD3A63D3 for ; Tue, 5 Apr 2011 13:19:14 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p35KKrbl060636; Tue, 5 Apr 2011 16:20:53 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104052020.p35KKrbl060636@harbor.orleans.occnc.com> To: neil.2.harrison@bt.com From: Curtis Villamizar In-reply-to: Your message of "Tue, 05 Apr 2011 08:37:01 BST." <6D3D47CB84BDE349BC23BF1C94E316E4401CF7D4BB@EMV62-UKRD.domain1.systemhost.net> Date: Tue, 05 Apr 2011 16:20:53 -0400 Sender: curtis@occnc.com Cc: venkatflex@gmail.com, pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 20:19:16 -0000 Neil, draft-villamizar-mpls-tp-multipath describes how an underlying MPLS layer using multipath (LAG or link bundle) can carry MPLS-TP LSPs without a "transparency violation" as you put it. Curtis In message <6D3D47CB84BDE349BC23BF1C94E316E4401CF7D4BB@EMV62-UKRD.domain1.systemhost.net> neil.2.harrison@bt.com writes: Curtis, You wrote 05 April 2011 00:48 to Venkat: > To: venkatesan mahalingam > Cc: pwe3@ietf.org > Subject: Re: [PWE3] GAL above and below the PW label > > > In message X8aT1uxMGThO@mail.gmail.com> > venkatesan mahalingam writes: > > > > Hi, > > > > >> > You don't want ECMP to hash on PW payload. With CW and without > > >> > fat-pw, you don't get ECMP on a PW but you do get ECMP on an LSP > > >> > containing many PW. > > >> > > >> When the PW payload is IP, the hashing it for ECMP is useful (If > the > > >> payload is not IP then use CW). FAT-PW may not be present in all > > >> deployments. > > > > > > I really don't know that any PW are carrying IP. That was not in > the > > > survey. L3VPN would be carrying IP. > > > > Why are we very much concerned about the ECMP in MPLS-TP networks? > > Because some of us are realists. > > > I think, as per the RFC-5960, > > > > Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed > on > > an MPLS-TP LSP. > > That is all fine and well. The case that is being discussed is an > expected common case with an MS-PW where a MPLS-TP LSP in the access > tier on one side, one or more MPLS LSP is traversed in the regional or > core tier, and an MPLS-TP may be traversed in the access tier on the > other side. > > In both MPLS-TP LSP there may be no need for multipath (for example > LAG or link bundle). In the core LAG or link bundle may be essential, > but there LSP are MPLS, not MPLS-TP. I don't understand your point here and why you are saying Venkat is wrong and (in particular) 'not being realistic'. The key point is this: Why should the 2 outer MPLS-TP layer network partitions care (or even know) what is happening in the core MPLS layer partition wrt ECMP (or any other transparency violation) behaviour? If you don't get this instantly try this architecturally identical alternative case: Consider an IP layer network where each link connection is served by a different server layer network technology X, Y, Z, etc, and in the most general case each may be owned by a different party. Why should the server layer technology partition X care (or even know about) what any other server layer technology partition Y, Z, etc is doing here across the whole span of the client IP layer network? Hopefully it should be quite clear that: (i) each server layer technology partition must be independent of any other server layer technology partition, (ii) they all must form a pukka client/server relationship with the common IP layer client, and (in particular) (ii) carry it transparently..else the owner of the IP layer client would not be very happy ;-) regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > > > Thanks, > > Venkat. > > Re: [PWE3] GAL above and below the PW label > > Curtis > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From neil.2.harrison@bt.com Wed Apr 6 00:02:07 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158A53A68BA for ; Wed, 6 Apr 2011 00:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.808 X-Spam-Level: X-Spam-Status: No, score=-0.808 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou5ytaNUT6Fb for ; Wed, 6 Apr 2011 00:02:05 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id 6314A3A68AF for ; Wed, 6 Apr 2011 00:02:05 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 6 Apr 2011 08:03:48 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.40]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 6 Apr 2011 08:03:47 +0100 From: To: Date: Wed, 6 Apr 2011 08:03:42 +0100 Thread-Topic: [PWE3] GAL above and below the PW label Thread-Index: AcvzzvickT7+Q9LOQNmrMS8fUy4mVQAVYUkw Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4401DA19A5F@EMV62-UKRD.domain1.systemhost.net> References: Your message of "Tue, 05 Apr 2011 08:37:01 BST." <6D3D47CB84BDE349BC23BF1C94E316E4401CF7D4BB@EMV62-UKRD.domain1.systemhost.net> <201104052020.p35KKrbl060636@harbor.orleans.occnc.com> In-Reply-To: <201104052020.p35KKrbl060636@harbor.orleans.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pwe3@ietf.org, venkatflex@gmail.com Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 07:02:07 -0000 Thanks Curtis, You said 05 April 2011 21:21: > To: Harrison,N,Neil,DKQ7 R > Cc: curtis@occnc.com; venkatflex@gmail.com; pwe3@ietf.org > Subject: Re: [PWE3] GAL above and below the PW label >=20 >=20 > Neil, >=20 > draft-villamizar-mpls-tp-multipath describes how an underlying MPLS > layer using multipath (LAG or link bundle) can carry MPLS-TP LSPs > without a "transparency violation" as you put it. NH=3D> This is not relevant to the technical correction I provided. I was = making it clear that: - there must be a functionally decoupled relationship between the MS PW la= yer network and each of its of underlying MPLS server layer networks in the= example given (which becomes crystal clear in the case each of these MPLS = networks being owned by a different operating party)...also see my related = mail to Ben (Niven-Jenkins) of a day or so earlier that he has unfortunatel= y not been able to respond to yet.... and - an immediate consequence of this (though this is a quite general networki= ng case, as I showed with the IP layer network example in the mail below) i= s that there is no functional coupling/relationship (or even knowledge of e= xistence) between each of the MPLS server layer networks. You surely cannot disagree with any of the above. Aside=3D> If MPLS-TP is serious about assuming a transport service mantle i= t must be able to provide a pukka client/server case of MPLS-TP_over_MPLS-T= P. This is merely the above situation re-cast. And BTW this is (one reaso= n) why traditional LSP sublayering and proper LSP layering do not sit as ea= sy bedfellows and thus why one now has to take some action to make this dem= arc clear and efficient in the traffic DP (I am aware of one manufacturer w= ho has recognised this point). Also note that when we have proper layering= as we will need in a transport networking role then one will need to consi= der both intra-layer and inter-layer misconnectivity. I will try and find time to look at your draft (thanks for the pointer), bu= t as I hope you can see this is not relevant to the above. =20 regards, Neil BT Design This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 >=20 > Curtis >=20 >=20 > In message <6D3D47CB84BDE349BC23BF1C94E316E4401CF7D4BB@EMV62- > UKRD.domain1.systemhost.net> > neil.2.harrison@bt.com writes: >=20 > Curtis, >=20 > You wrote 05 April 2011 00:48 to Venkat: >=20 > > To: venkatesan mahalingam > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] GAL above and below the PW label > > > > > > In message > X8aT1uxMGThO@mail.gmail.com> > > venkatesan mahalingam writes: > > > > > > Hi, > > > > > > >> > You don't want ECMP to hash on PW payload. With CW and > without > > > >> > fat-pw, you don't get ECMP on a PW but you do get ECMP on an > LSP > > > >> > containing many PW. > > > >> > > > >> When the PW payload is IP, the hashing it for ECMP is useful (If > > the > > > >> payload is not IP then use CW). FAT-PW may not be present in all > > > >> deployments. > > > > > > > > I really don't know that any PW are carrying IP. That was not in > > the > > > > survey. L3VPN would be carrying IP. > > > > > > Why are we very much concerned about the ECMP in MPLS-TP networks? > > > > Because some of us are realists. > > > > > I think, as per the RFC-5960, > > > > > > Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be > performed > > on > > > an MPLS-TP LSP. > > > > That is all fine and well. The case that is being discussed is an > > expected common case with an MS-PW where a MPLS-TP LSP in the access > > tier on one side, one or more MPLS LSP is traversed in the regional > or > > core tier, and an MPLS-TP may be traversed in the access tier on the > > other side. > > > > In both MPLS-TP LSP there may be no need for multipath (for example > > LAG or link bundle). In the core LAG or link bundle may be > essential, > > but there LSP are MPLS, not MPLS-TP. >=20 > I don't understand your point here and why you are saying Venkat is > wrong and (in particular) 'not being realistic'. >=20 > The key point is this: Why should the 2 outer MPLS-TP layer network > partitions care (or even know) what is happening in the core MPLS layer > partition wrt ECMP (or any other transparency violation) behaviour? >=20 > If you don't get this instantly try this architecturally identical > alternative case: Consider an IP layer network where each link > connection is served by a different server layer network technology X, > Y, Z, etc, and in the most general case each may be owned by a > different party. Why should the server layer technology partition X > care (or even know about) what any other server layer technology > partition Y, Z, etc is doing here across the whole span of the client > IP layer network? >=20 > Hopefully it should be quite clear that: > (i) each server layer technology partition must be independent of any > other server layer technology partition, > (ii) they all must form a pukka client/server relationship with the > common IP layer client, and (in particular) > (ii) carry it transparently..else the owner of the IP layer client > would not be very happy ;-) >=20 > regards, Neil >=20 > This email contains BT information, which may be privileged or > confidential. > It's meant only for the individual(s) or entity named above. If you're > not the intended > recipient, note that disclosing, copying, distributing or using this > information > is prohibited. If you've received this email in error, please let me > know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 >=20 >=20 >=20 > > > > > Thanks, > > > Venkat. > > > Re: [PWE3] GAL above and below the PW label > > > > Curtis > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 >=20 From ben@niven-jenkins.co.uk Wed Apr 6 15:29:19 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B253A696F for ; Wed, 6 Apr 2011 15:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phidn0zXFI43 for ; Wed, 6 Apr 2011 15:29:18 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 0D2D03A6801 for ; Wed, 6 Apr 2011 15:29:18 -0700 (PDT) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.202]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Q7bFd-00012i-ID; Wed, 06 Apr 2011 23:31:01 +0100 References: <6D3D47CB84BDE349BC23BF1C94E316E4401C557849@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4401C557849@EMV62-UKRD.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Wed, 6 Apr 2011 23:31:00 +0100 To: X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 22:29:19 -0000 On 4 Apr 2011, at 09:48, = wrote: >> Benjamin Niven-Jenkins wrote 03 April 2011 19:39 >> On 31 Mar 2011, at 12:27, Giles Heron wrote: >>> Agreed. I'd expect the most common use case for TP is in the >>> access/aggregation. So you might have an MS-PW with 3 segments: >>>=20 >>> MPLS TP <-> IP/MPLS <-> MPLS-TP. >>=20 >> That was certainly the use case I was looking at using TP for when I >> wrote >>=20 >> http://tools.ietf.org/html/draft-jenkins-mpls-tp-bt-requirements-00 >=20 > To be clear Ben, I assume: >=20 > 1 You are implying that there is a proper client/server = relationship between each of the 3 MPLS server layer network partitions = you identify above, where the PW layer network is transparently carried = across each of the 3 independent server MPLS domains (which of course = can belong to different operating parties). Yes. Although the case I had in mind was MS-PW where there was a = separate PW segment for each of the MPLS server layers, the fact that = there would have been a 1:1 mapping between PW segments and MPLS server = layers was incidental. The driver for MS-PW was because I needed the = 'edge' PW segments to be statically configured to meet security = requirements but I didn't want to place the same restrictions on the = 'core' PW segment. > 2 There is no 'peering' between logically adjacent server layer = MPLS layer networks.....noting that non-TOS layer networks never need to = peer in any case. Correct. Ben= From neil.2.harrison@bt.com Wed Apr 6 22:59:11 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9EB83A685D for ; Wed, 6 Apr 2011 22:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vkbweuYH9S1 for ; Wed, 6 Apr 2011 22:59:09 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id 611DE3A67F3 for ; Wed, 6 Apr 2011 22:59:09 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 7 Apr 2011 07:00:53 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.40]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 7 Apr 2011 07:00:52 +0100 From: To: Date: Thu, 7 Apr 2011 07:00:48 +0100 Thread-Topic: [PWE3] GAL above and below the PW label Thread-Index: Acv0qlAFfqmDNnnwRXWECcWTgelMgAAPCZxA Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4401DA1A2C6@EMV62-UKRD.domain1.systemhost.net> References: <6D3D47CB84BDE349BC23BF1C94E316E4401C557849@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 05:59:12 -0000 Many thanks Ben for this important clarification. I am glad we see essenti= ally the same layered network architecture case/implications. A couple of = further remarks in-line only for completeness: You wrote 06 April 2011 23:31: > To: Harrison,N,Neil,DKQ7 R > Cc: giles.heron@gmail.com; pwe3@ietf.org; stbryant@cisco.com > Subject: Re: [PWE3] GAL above and below the PW label >=20 >=20 > On 4 Apr 2011, at 09:48, > wrote: > >> Benjamin Niven-Jenkins wrote 03 April 2011 19:39 > >> On 31 Mar 2011, at 12:27, Giles Heron wrote: > >>> Agreed. I'd expect the most common use case for TP is in the > >>> access/aggregation. So you might have an MS-PW with 3 segments: > >>> > >>> MPLS TP <-> IP/MPLS <-> MPLS-TP. > >> > >> That was certainly the use case I was looking at using TP for when I > >> wrote > >> > >> http://tools.ietf.org/html/draft-jenkins-mpls-tp-bt-requirements-00 > > > > To be clear Ben, I assume: > > > > 1 You are implying that there is a proper client/server relationship > between each of the 3 MPLS server layer network partitions you identify > above, where the PW layer network is transparently carried across each > of the 3 independent server MPLS domains (which of course can belong to > different operating parties). >=20 > Yes. Although the case I had in mind was MS-PW where there was a > separate PW segment for each of the MPLS server layers, the fact that > there would have been a 1:1 mapping between PW segments and MPLS server > layers was incidental.=20 NH=3D> This is the same as having some number N of consecutive link connect= ions (that form a 'segment') of the MS PW LSP provided by the same serving = MPLS layer network. Of course, each individual PW link connection is an E2= E MPLS LSP in its own right, they just happen to come from the same parent = serving MPLS layer network. > The driver for MS-PW was because I needed the > 'edge' PW segments to be statically configured to meet security > requirements but I didn't want to place the same restrictions on the > 'core' PW segment. >=20 > > 2 There is no 'peering' between logically adjacent server layer MPLS > layer networks.....noting that non-TOS layer networks never need to > peer in any case. >=20 > Correct. NH=3D> This is a vital point (though it is quite general to all client/serv= er networking cases, not simply this case). A couple of immediate (and per= fectly correct/required) consequences of this are: - there is no need for E-NNIs between the serving MPLS layer networks....th= is is a logically obvious conclusion in any case simply from the observatio= n that E-NNIs are technically unnecessary in any layer network technology t= hat is not TOS (and thus external application interfacing). This avoids mu= ch unnecessary complexity/costs. - the routing function of each and the serving MPLS layer networks must be = independent of each other (stems directly from the above) and also independ= ent of that of the E2E PW layer network that spans all the MPLS server laye= r networks. Note - I've only picked on the routing function here to illust= rate the fact that there cannot be a common instance of CP between all thes= e layer networks, but this observation applies to all the functionality nee= ded to specify/operate a layer network. regards, Neil=20 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 >=20 > Ben From curtis@occnc.com Thu Apr 7 08:52:05 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA3B28C0DB for ; Thu, 7 Apr 2011 08:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCGn0MzTLJwf for ; Thu, 7 Apr 2011 08:52:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 0820028C0D7 for ; Thu, 7 Apr 2011 08:52:02 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p37Frgko099786; Thu, 7 Apr 2011 11:53:43 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104071553.p37Frgko099786@harbor.orleans.occnc.com> To: neil.2.harrison@bt.com From: Curtis Villamizar In-reply-to: Your message of "Wed, 06 Apr 2011 08:03:42 BST." <6D3D47CB84BDE349BC23BF1C94E316E4401DA19A5F@EMV62-UKRD.domain1.systemhost.net> Date: Thu, 07 Apr 2011 11:53:42 -0400 Sender: curtis@occnc.com Cc: venkatflex@gmail.com, pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 15:52:05 -0000 Neil, Going back to the example. If each network is owned by a separate party we have: PW - fat-pw is used, therefore owner of PW label is OK with load split and indicates how to do so. MPLS-TP segment carrying MS-PW segment: ignores label stack except top lagel and uses no multipath of any kind and does no hash and no load balance. MPLS segment carrying MS-PW segment: may make use of information provided in fat-pw label to distribute traffic among components of a multipath where it is necessary or convenient to use multipath. There is no layering problem here. There is no violation of MPLS-TP fate sharing. Things work as each owner of a given layer intends it to work. Use of MPLS-TP on the edge/access has no issues. Aside in response to your aside => a case for MPLS over MPLS can be found in RFC 5439 "An Analysis of Scaling Issues in MPLS-TE Core Networks". The two recommendations to acheive scalability are LDP (to make use of multipoint to point LSP) and hierarchy. With hierarchy the LSP become greater than 100Gb/s in large networks and that requires multipath. Both recommendations for scalability are therefore not applicable to MPLS-TP in large networks. Conclusion: MPLS-TP won't scale; use MPLS in the core. Now back to our previous discussion about whether we can relax the requirement to have GAL at the bottom of stack (which is the part of the stack that PWE people draw on top :). Curtis In message <6D3D47CB84BDE349BC23BF1C94E316E4401DA19A5F@EMV62-UKRD.domain1.systemhost.net> neil.2.harrison@bt.com writes: Thanks Curtis, You said 05 April 2011 21:21: > To: Harrison,N,Neil,DKQ7 R > Cc: curtis@occnc.com; venkatflex@gmail.com; pwe3@ietf.org > Subject: Re: [PWE3] GAL above and below the PW label > > > Neil, > > draft-villamizar-mpls-tp-multipath describes how an underlying MPLS > layer using multipath (LAG or link bundle) can carry MPLS-TP LSPs > without a "transparency violation" as you put it. NH=> This is not relevant to the technical correction I provided. I was making it clear that: - there must be a functionally decoupled relationship between the MS PW layer network and each of its of underlying MPLS server layer networks in the example given (which becomes crystal clear in the case each of these MPLS networks being owned by a different operating party)...also see my related mail to Ben (Niven-Jenkins) of a day or so earlier that he has unfortunately not been able to respond to yet.... and - an immediate consequence of this (though this is a quite general networking case, as I showed with the IP layer network example in the mail below) is that there is no functional coupling/relationship (or even knowledge of existence) between each of the MPLS server layer networks. You surely cannot disagree with any of the above. Aside=> If MPLS-TP is serious about assuming a transport service mantle it must be able to provide a pukka client/server case of MPLS-TP_over_MPLS-TP. This is merely the above situation re-cast. And BTW this is (one reason) why traditional LSP sublayering and proper LSP layering do not sit as easy bedfellows and thus why one now has to take some action to make this demarc clear and efficient in the traffic DP (I am aware of one manufacturer who has recognised this point). Also note that when we have proper layering as we will need in a transport networking role then one will need to consider both intra-layer and inter-layer misconnectivity. I will try and find time to look at your draft (thanks for the pointer), but as I hope you can see this is not relevant to the above. regards, Neil BT Design This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > > Curtis > > > In message <6D3D47CB84BDE349BC23BF1C94E316E4401CF7D4BB@EMV62- > UKRD.domain1.systemhost.net> > neil.2.harrison@bt.com writes: > > Curtis, > > You wrote 05 April 2011 00:48 to Venkat: > > > To: venkatesan mahalingam > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] GAL above and below the PW label > > > > > > In message > X8aT1uxMGThO@mail.gmail.com> > > venkatesan mahalingam writes: > > > > > > Hi, > > > > > > >> > You don't want ECMP to hash on PW payload. With CW and > without > > > >> > fat-pw, you don't get ECMP on a PW but you do get ECMP on an > LSP > > > >> > containing many PW. > > > >> > > > >> When the PW payload is IP, the hashing it for ECMP is useful (If > > the > > > >> payload is not IP then use CW). FAT-PW may not be present in all > > > >> deployments. > > > > > > > > I really don't know that any PW are carrying IP. That was not in > > the > > > > survey. L3VPN would be carrying IP. > > > > > > Why are we very much concerned about the ECMP in MPLS-TP networks? > > > > Because some of us are realists. > > > > > I think, as per the RFC-5960, > > > > > > Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be > performed > > on > > > an MPLS-TP LSP. > > > > That is all fine and well. The case that is being discussed is an > > expected common case with an MS-PW where a MPLS-TP LSP in the access > > tier on one side, one or more MPLS LSP is traversed in the regional > or > > core tier, and an MPLS-TP may be traversed in the access tier on the > > other side. > > > > In both MPLS-TP LSP there may be no need for multipath (for example > > LAG or link bundle). In the core LAG or link bundle may be > essential, > > but there LSP are MPLS, not MPLS-TP. > > I don't understand your point here and why you are saying Venkat is > wrong and (in particular) 'not being realistic'. > > The key point is this: Why should the 2 outer MPLS-TP layer network > partitions care (or even know) what is happening in the core MPLS layer > partition wrt ECMP (or any other transparency violation) behaviour? > > If you don't get this instantly try this architecturally identical > alternative case: Consider an IP layer network where each link > connection is served by a different server layer network technology X, > Y, Z, etc, and in the most general case each may be owned by a > different party. Why should the server layer technology partition X > care (or even know about) what any other server layer technology > partition Y, Z, etc is doing here across the whole span of the client > IP layer network? > > Hopefully it should be quite clear that: > (i) each server layer technology partition must be independent of any > other server layer technology partition, > (ii) they all must form a pukka client/server relationship with the > common IP layer client, and (in particular) > (ii) carry it transparently..else the owner of the IP layer client > would not be very happy ;-) > > regards, Neil > > This email contains BT information, which may be privileged or > confidential. > It's meant only for the individual(s) or entity named above. If you're > not the intended > recipient, note that disclosing, copying, distributing or using this > information > is prohibited. If you've received this email in error, please let me > know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > > > > > > Thanks, > > > Venkat. > > > Re: [PWE3] GAL above and below the PW label > > > > Curtis > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > From stbryant@cisco.com Thu Apr 7 11:55:21 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33313A69EA for ; Thu, 7 Apr 2011 11:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptrL8G8U1bsd for ; Thu, 7 Apr 2011 11:55:19 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3B1C33A69D1 for ; Thu, 7 Apr 2011 11:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=29144; q=dns/txt; s=iport; t=1302202623; x=1303412223; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zdYT144UXleKA2PBuCGw2Ou1niWHcYyhOG4uSjD9ggI=; b=CEu5UH/N8riwrOAy84S9voN4iK3rM8jG++8RNFWpKguj3+PnXVtyK7X/ w4HMbxSfL7u3pC+vP801dyxE3+Eb+4KEGYIvCdtlulE0i2Ecd0S1Pj5b2 j4QrZYrHTqycStdThKS5dYDR2rVrMwXlB73dKsoaRbSsI/i84a2NwHHq1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8EAOsHnk2Q/khMgWdsb2JhbACmCBQBARYmJYh5nECCcw4BmViFbQSNRQ X-IronPort-AV: E=Sophos;i="4.63,317,1299456000"; d="scan'208";a="24875794" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 07 Apr 2011 18:57:01 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37Iv1sW026818; Thu, 7 Apr 2011 18:57:01 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p37IuxU29432; Thu, 7 Apr 2011 19:56:59 +0100 (BST) Message-ID: <4D9E08FA.7090000@cisco.com> Date: Thu, 07 Apr 2011 19:56:58 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Adrian.Farrel@huawei.com References: <031001cbbfb4$ef961500$cec23f00$@huawei.com> In-Reply-To: <031001cbbfb4$ef961500$cec23f00$@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org, pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-fat-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 18:55:21 -0000 Adrian Here are the actions I have taken/reply to your points. Lets see where we agree and if we are close to agreement I will upload a new version Stewart > --- > > I found the use of language a little relaxed. You use the same word, > "label", to refer to a label value and to an entry in the shim header. > It would probably be helpful to use the term "label" to refer to the > label itself, and "label entry" to indicate the label, TC bits, and TTL. > I have changed this to use label for the value and label stack entry (LSE) as per RFC3032 for the entry in the label stack. Hopefully I have caught all instances and disposed of them correctly. > --- > > It seems to me that the description of what can be in the additional > label entry is conflicted. > > On receipt of the > pseudowire packet at the egress PE (which knows this additional label > is present) the flow label is discarded without processing. > > This means that the label will not be used for any purpose in the packet > processing except in the DPI of ECMP hashing. > > The flow label can never become the top label in > normal operation > > That is, you will never pop a label to discover the flow label except at > the egress where it is expected and ignored. > > Note that the flow label MUST NOT be an MPLS reserved label (values > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > protocol. > > And why is that restriction required given the two previous points? MPLS has an architectural assumption that a label value with a reserved value has special meaning - always -. Its safer to always assume that to be the case even if we "can get away with it." > > The flow label can never become the top label in > normal operation, and hence the TTL in the flow label is never used > to determine whether the packet should be discarded due to TTL > expiry. Therefore there are no lower restrictions on the TTL value. > > Why do you call out "lower"? How about saying "there are no restrictions" Changed. There was some discussion in the early PW days with, as I recall, Eric Rosen convincing me that bad things would happen in some implementations when a PW had TTL=1. This is a carry over from that. > The use of the TC bits (formerly known as the EXP bits) in the flow > label is outside the scope of this document. Unless otherwise agreed > by the ingress and egress PEs these bits MUST be set to zero by the > ingress PE and MUST be ignored by the egress PE. > > "Out of scope" seems to be different from the subsequent statement about > how he TC field must be treated. I am also not clear why the TTL > discussion is different from the TC discussion. Ah, there was a lot of discussion about this is the WG, with some proposals to use them for signaling of state along the LSP. I was pushing back on this on MPSL architectural grounds and the text here was the result of some discussion in WG LC. > --- > > Document title: please spell out PSN done - but note that PSN is a well known term in PWE3 > > > --- > > Abstract: yuck! :-O > > Suggestion... > > OLD > Where the payload carried over a pseudowire carries a number of > identifiable flows it can in some circumstances be desirable to carry > those flows over the equal cost multiple paths (ECMPs) that exist in > the packet switched network. Most forwarding engines are able to > hash based on label stacks and use this to balance flows over ECMPs. > This draft describes a method of identifying the flows, or flow > groups, to the label switched routers by including an additional > label in the label stack. > NEW > Where the payload of a pseudowire comprises a number of distinct > flows, it can be desirable to carry those flows over the equal cost > multiple paths (ECMPs) that exist in the packet switched network. > Most forwarding engines are able to hash based on MPLS label stacks > and use this mechanism to balance MPLS flows over ECMPs. > > This document describes a method of identifying the flows, or flow > groups, within pseudowires such that Label Switching Routers can > balance flows at a finer granularity than individual pseudowires. > The mechanism uses an additional label in the MPLS label stack. > END > done > --- > > Try to avoid "ECMP paths" (or ECMPP as we call them ;-) I use ECMP and ECMPs for the plural > --- > > Section 1 para 1 > > the use of ECMP paths for is known to be > beneficial (and not harmful) to the operation of the PW. > > ?? The (and not harmful) was a heads up to the reader that in some cases it is harmful, and that it is assumed that the reader would know when this was the case and use the mechanism. We could delete the parenthetical remark, but it is harmless other than perhaps as an offense to the English. > --- > > Throughout... > > The plural of "pseudowire" is "pseudowires", not "pseudowire's". > You may safely use "PWs" in your document. > > You have a number of other plurals formed as apostrophe-s. Please > search for "'s" and fix as necessary. > Done > --- > > Section 1 > > Some pseudowires are used to transport large volumes of IP traffic > between routers at two locations. > > I assume that, for some definition of "location" this is also true for > routers at the same location. So how about... > > Some pseudowires are used to transport large volumes of IP traffic > between routers. > Indeed > --- > > Section 1 > > Such pseudowire's do not require strict ordering to > be preserved between packets of the pseudowire. They only require > ordering to be preserved within the context of each individual > transported IP flow. > > I see where this is going, but the first sentence is massively more > relaxed than the second! How about turning it around... > > Such pseudowires only require packet ordering to be preserved within > the context of each individual transported IP flow. They do not > require packet ordering to be preserved between all packets of the > across all IP flows within the pseudowire. > Changed to These PWs only require packet ordering to be preserved within the context of each individual transported IP flow. They do not require packet ordering to be preserved between all packets of across all IP flows within the pseudowire. > --- > > Section 1 > > Some operators have requested the ability to > explicitly configure such a pseudowire to leverage the availability > of multiple ECMP paths. > > I wish you did not feel the need to include this assertion. Why not just > get on and describe the benefits (as you do in the next sentence). > > Currently it really sounds like this is an idea that is strongly opposed > and you are trying to justify it to the rest of the community. In fact, > the community will judge according to the technical merits. Traditionally this is an an anathema in PWs which try hard to look like a "wire" and when we first mooted the idea we got pushback from the ITU-T MPLS-TP community. The reason that we say "Some operators" is because this was an operator initiated, not a vendor initiated project. I have changed this to OLD Some operators have requested the ability to explicitly configure such a PW to leverage the availability of multiple ECMPs. This allows for better capacity planning as the statistical multiplexing of a larger number of smaller flows is more efficient than with a smaller set of larger flows. Although Ethernet is used as an example above, the mechanisms described in this draft are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows. NEW The ability to explicitly configure such a PW to leverage the availability of multiple ECMPs allows for better capacity planning as the statistical multiplexing of a larger number of smaller flows is more efficient than with a smaller set of larger flows. Although Ethernet is used as an example above, the mechanisms described in this draft are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows. END > --- > > > Please don't use the word "draft" in the text as it creates work for the > RFC Editor and might get missed in the publication process. Obviously, by > the time this is published as an RFC it will no longer be a draft. Best > thing to do is search and replace "draft" with "document". > Done. It was an error. Tutorial not required :) > --- > > Section 1 > > Typically, forwarding hardware can deduce that an IP payload is being > directly carried by an MPLS label stack, and is capable of looking at > some fields in packets to construct hash buckets for conversations or > flows. However, an intermediate node has no information on the type > pseudowire being carried in the packet. > > Is the first sentence relevant to this document? I don't think so, but if > you believe it is, I think you will need to add a statement about how > this deduction is made. I have changed the second sentence to " However, when the MPLS payload is a PW, an intermediate node has..." The point of this is to note that routers have been in the habit of doing DPI and ECMP on MPLS LSPs based on deducing that the packet is an IP packet, but PWs provide information hiding that prevents this. I am not sure that a tutorial on how they do it is appropriate, particularly as it's not strictly in conformance with the MPLS architecture, but noting that de facto it happens to readers not familiar with LSR design is I believe useful. > --- > > Section 1 > > In the case of a pseudowire emulating > a high bandwidth trunk, the granularity obtained by hashing the > default label stack is inadequate for satisfactory load-balancing. > > Is "the default label stack" intended to convey some special meaning? > I suspect you are trying to say "the label stack that would be > constructed if this I-D hasn't been implemented". You will simply have > to go down the path of saying... > > In the case of a pseudowire emulating > a high bandwidth trunk, the granularity obtained by hashing the > label stack is inadequate for satisfactory load-balancing. > Changed > --- > > Section 1 > > > This draft proposes a method to introduce granularity on the hashing > of traffic running over pseudowires by introducing an additional > label, chosen by the ingress node, and placed at the bottom of the > label stack. > > As above: s/draft/document/ > Also, please be less timid. Your document defines a method. Changed Of course individual-00 did only propose it. > --- > > Section 1.1 > > s/1.1. ECMP in Label Switched Routers/1.1. ECMP in Label Switching Routers/ > > s/Label switched routers/Label Switching Routers (LSRs)/ > None > --- > > Section 1.1 > > been proposed [I-D.kompella-mpls-entropy-label], however that is > > Reading would be significantly enhanced by forward reference to section > 8. > I put in the forward reference and removed the OOS wich seemed a bit strange given we have a section introducing the issue. > --- > > Section 3 > > It is recommended > > > RECOMMENDED ? Done > --- > > Section 3 > > It is recommended that the method chosen to > generate the load balancing labels introduces a high degree of > entropy in their values, to maximise the entropy presented to the > ECMP path selection mechanism in the LSRs in the PSN, and hence > distribute the flows as evenly as possible over the available PSN > ECMP paths. > > It isn't clear to me that entropy is necessarily a good thing. It > depends on the hash algorithm, doesn't it. Entropy is a good thing (TM) in this application .. and the quality of the entropy is a function of the quality of the hash algorithm. > --- > > Figure 2 > > Those four-octet things are not actually labels are they. The fig now says LSE | Flow LSE | 4 octets +---------------------------+ | PW LSE | 4 octets +---------------------------+ | MPLS Tunnel LSE (s) | n*4 octets (four octets per LSE) The rest are not labels > --- > > What is the purpose of the T bit? Why would an implementation go to > the trouble of including the flow-label TLV only to set T=0? It may wish to send T=0, R=1, i.e. I do not propose to send a FAT label, but I can process (discard) one if you send it to me. > --- > > Section 4 > > If PWE3 signalling [RFC4447] is not in use for a pseudowire, then > whether the flow label is used MUST be identically provisioned in > both PEs at the pseudowire endpoints. If there is no provisioning > support for this option, the default behaviour is not to include the > flow label. > > This paragraph is misplaced in the section on signaling. Please put it > elsewhere. Added new section Static Pseudowires and moved the text there. > I am not convinced by the 2119 language in this paragraph since an > implementation cannot control the behavior. It could be interpreted as an instruction to the NMS system and therefore a mandatory implementation instruction at that level. > --- > > Section 4 > > Do you not think that you should say that the new sub-TLV is carried in > the Interface Parameters TLV, and on which messages? The text is consistent with the other PW definitions and the reader has already been referred to RFC4447. > --- > > Section 4.1 > > o FL is the flow label sub-TLV identifier assigned by IANA. > > Can you either put in a [TBD] flag so the RFC Editor will catch this, > or a forward pointer to section 10. I put in the value 0x17 since it's already been allocated. I change the IANA section to say: "IANA is requested to amend the PW Interface Parameters Sub-TLV type Registry value 0x17 (Flow Label indicator) to refer to this RFC." > --- > > Section 5 > > Consider an egress that doesn't support flow label, but previous S-PEs > that do. In this case you are content to throw the baby out with the > bath water? The fix would require a change to the S-PE behavior to remove the FAT label. That is an operation that is more complex than a simple label swap and therefore undesirable. --- > Section 6 > > We believe that this > problem is addressed by the following two methods > > I would like you to be more definitive, please. How about This problem is mitigated by the following two considerations: > But, that said, the subsequent bullets do not provide methods of > addressing OAM in this case. Rather, the text attempts to say why > the problem is not important. In my opinion it fails since, although > ECMP is out of scope for MPLS-TP, a user has reasonable expectations > that some of the flows on their PW will not be wiped out for the IGP > convergence period, when (for example) rapid notification followed > by change of the flow label could cause the traffic to be balanced > differently and avoid the failure, I have added Note that this period may be reduced if a fast re-route or fast convergence technology is deployed in the network [RFC4090],[RFC5286]. > or when a partial failure of a PW > could trigger a switch to a different PW. Well there are two problems here: 1) The whole point is that it's difficult to constantly monitor all paths. 2) It's not clear that the new PW would be diverse when the FL is taken into a/c. > --- > > Section 6 > > s/corruption of an/corruption of a/ Done > --- > > You need to get rid of the reference to I-D.ietf-mpls-lsr-self-test > This work has clearly been abandoned. The reference is replaced by such as an LSP self test technology. With no reference. > --- > > s/Figure 4: Use of Router Alert LAbel/Figure 4: Use of Router Alert Label/ > > --- > > Figure 4 > > Shouldn't "payload" actually read "VCCV message"? > > Shouldn't you include the warning (from 5085) that inserting the router > alert label probably breaks the ECMP hashing such that the packets will > go another way. Added Note that, depending on the number of labels hashed by the LSR, the inclusion of the Router Alert label may cause the OAM packet to be load balanced to a different path from that taken by the data packets with identical Flow and PW labels. > --- > > How funny that labels that are conventionally described as being "above" > on the label stack are shown in your diagrams as below. > Yes, but the mistake is consistent though out all PWE3 docs going back to RFC3985. > --- > > Section 7 > > s/The methods describe/The methods described/ > s/The method proposed/The method defined/ > s/in those cased/in those cases/ > s/The methods describe/The methods described/ Can't find it > --- > > Section 7 > > order is not maintained amongst packets of different > flows. > > I know what you mean, but you have actually said something subtly > different. OLD order is not maintained amongst packets of different flows NEW order is no longer maintained for all packets sent over the PW. > --- > > Section 7 > > Ethernet may have this property, and for that reason > this document focuses on Ethernet. Applications for other high- > access-bandwidth PW's (e.g. Fibre Channel) may be defined in the > future. > > Does the document really *focus* on Ethernet? There are a couple of > places where Ethernet is cited as an example (but where the text says > equally applicable, blah, blah) and two paragraphs a little below this > statement that say "the Ethernet PW". Nothing else. > > Can't you generalise? Section 1 says Although Ethernet is used as an example above, the mechanisms described in this document are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows. I have removed that text and added this note to the bottom of Section 1 NOTE: Although Ethernet is frequently referenced as a use case in this RFC, the mechanisms described in this document are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows. > --- > > Section 7 > > If sequence number support is required this > mechanism is not applicable. > > It's stronger than that, isn't it? > You need to prohibit the mechanism. > But shouldn't you also prohibit ECMP? Now says: If sequence number support is required the flow label mechanism MUST NOT be used. > --- > > Section 7 > > Where it is known that the traffic carried by the Ethernet pseudowire > is IP the method of identifying the flows are well known and can be > applied. Such methods typically include hashing on the source and > destination addresses, the protocol ID and higher-layer flow- > dependent fields such as TCP/UDP ports, L2TPv3 Session ID's etc. > > Either s/method/methods/ or s/are/is/ done > If these methods are so well known, you will have no difficulty in > supplying a reference or two. I am fairly sure that there is no IETF reference to this. It something that all the vendors do (differently), but there has always been strong resistance to the publication of a standard. > > I think you have mixed the method of identifying the flows with the > method of hashing the flows into buckets. The text now says: Where it is known that the traffic carried by the Ethernet PW is IP the method of identifying the flows and mapping them to an ECMP are well known and can be applied. Such methods are typically include hashing on the source and destination addresses, the protocol ID and higher-layer flow-dependent fields such as TCP/UDP ports, L2TPv3 Session ID’s etc. > --- > > Section 7.1 > > In the ECMP case and the link bundling case the NSP may attempt to > take bandwidth into consideration when allocating groups of flows to > a common path. That is permitted, but it must be borne in mind that > the semantics of a label stack entry (LSE) as defined by [RFC3032] > cannot be modified, the value of the flow label cannot be modified at > any point on the LSP, and the interpretation of bit patterns in, or > values of, the flow label by an LSR are undefined. > > If you have something to say, you should say it. Otherwise your paragraph > is lost on your readers. > I think you are trying to say "There is no mechanism currently defined > to indicate the bandwidths in use by specific flows using the fields of > the MPLS shim header. Furthermore, since the semantics of the MPLS shim > header are fully defined in [RFC3032] and [RFC5462], those fields cannot > be assigned semantics to carry this information. This document does not > define any semantic for use in the TTL or TC fields of the label entry > that carries the flow label, but requires that the flow label itself > be selected with a high degree of entropy suggesting that the label > value should not be overloaded with additional meaning in any subsequent > specification." OK works for me, but the WG should note the change of wording. > --- > > Section 7.1 > > A different type of load balancing is the desire to carry a > pseudowire over a set of PSN links in which the bandwidth of members > of the link set is less than the bandwidth of the pseudowire. This > problem is addressed in [I-D.stein-pwe3-pwbonding]. Such a mechanism > can be considered complementary to this mechanism. > > > The referenced I-D seems to be dead. I'm not quite sure why you need to > reference it here. How about just taking out the paragraph? It's in there as a result of WG discussion > --- > > Section 7.2 appears to describe exactly the link bundling case that you > discussed in section 7. I have recently noticed considerable confusion > between link bundles and LAG and suggest you restrict LAG to be a data > link function that is below the level of an "interface" in the IP/MPLS > world. That does not mean that an individual node, knowing (by > unspecified means) that it is about to use an interface that is > constructed from a LAG, can't hash the traffic across the LAG. > > Ultimately, you should consider ECMP (i.e. multiple IGP paths) where > each hop on each path may be made a link bundle, and where each > component link of a bundle may be supported by LAG. > > Can you go back and check that you have used the language precisely. The text was added as a result of WG discussion where it was proposed that LAG might use the FL as a key in member selection. > --- > > Section 7.4 > > If the payload on a PW is made of a single inner flow (i.e. an > encrypted connection between two routers), or the flow identifiers > are too deeply buried in the packet, then the functionality described > in this document does not give any benefits, though neither does it > cause harm relative to the existing situation. > > Is that s/i.e./e.g./? Changed > "Too deeply buried" meaning "If the NSP cannot access sufficient > information to distinguish flows, perhaps because the protocol stack > is too deep for its capabilities..."? > > Is the statement about "no harm" necessary? After all, the mechanism > will simply not be used in this case. Text was added as a result of WG discussion on benefits and usage of the mechanism. > --- > > Section 7.4 > > The most common case > where a single flow dominated the traffic on a PW is when it is used > to transport enterprise traffic. Enterprise traffic may well consist > of a large single TCP flows, or encrypted flows that cannot be > handled by the methods described in this document. > > s/dominated/dominates/ yes > s/a large single TCP flows/large TCP flows/ > Again this was WG agreed text > Note that this second half of the paragraph is a non-sequitur from the > first half. You probably need to wrap the whole paragraph with a thought > about single or dominant large flows. That is the title of the section > --- > > Section 7.4 > > 1. The operator can do nothing and the system will work as it does > without the flow label. > > s/can do nothing/can choose to do nothing/ done > --- > > Section 7.4 > > An operator has six options under these circumstances: > > :-) You tease! > > There are only five listed. :) I wonder if I deleted one at some time in the past > --- > > Section 7.4 > > s/an single flow/a single flow/ done > --- > > Section 7.4 > > 5. The operator could configure the ingress to assign a label of > special significance (such as a reserved label) to all high > bandwidth flows so that some other action (not specified in this > document) could be taken on the flow. > > I think you need to delete this as it contradicts two specific > statements made elsewhere... > > 1. MUST NOT use a reserved label as the flow label > 2. MUST NOT assign semantics to the flow label I have deleted (such as a reserved label). This was added as a result of WG discussion. I think that the idea was to use a label from the per platform space. > --- > > 8. Applicability to MPLS > > While I see where you are coming from, I must point out that the whole > of your document is about MPLS. Could you come up with a better title? Now says Applicability to MPLS LSPs > --- > > Section 9 > > The ingress PE SHOULD take steps to ensure that the load-balance > label is not used as a covert channel. > > Again, you are saying something between the lines :-( No, just warning that a badly implemented hash could have side effects. > Since the ingress PE allocates the label (isn't it called the flow label > not the load-balance label?) the "SHOULD take steps" is very odd! And > why is this a security requirement? How would security be compromised? Yes - LB label was an older name for it. I can take it out, or we can leave it to SECdir to advise. > --- > > Section 9 > > This document has signaling extensions in it, so you should reference > RFC 4447 from this section. You should also reference RFC 5920. Added: The security considerations in [RFC5920] also apply. > --- > > Section 9 > > The flow label TTL should therefore never be considered > by the forwarder, and hence SHOULD be set to a value of 1. This will > prevent the packet being inadvertently forwarded based on the value > of the flow label. Note that this may be a departure from > considerations that apply to the general MPLS case. > > But you have previously said that the flow label TTL is never used to > discard a packet based on TTL expiry [section 1.2]. You need to make > your mind up. And, if there are rules you wish to apply for setting > fields, you need to put them in the main part of the protocol spec, > not buried in the security section. > > And (while I'm at it) how is this a security feature? The point is that there is no protocol reason for it to have any particular value. There is a security reason (stopping the packet going some bad place) for stopping it going anywhere, but this is only a recommendation not a requirement. > Oh, and another thing... > > The sequence of your logic is broken. It would be fine to say: > If the flow label is inadvertently examined as if it were a normal > label, the packet might be forwarded. This can be prevented by setting > the associated TTL to 1. > But I don't think that "should never be considered" leads to "should be > set to 1". > > Finally, the note at the end is at best unhelpful. What are you trying > to say, and why? The text now says: The flow LSE is at the bottom of label stack, therefore, even when penultimate hop popping is employed, it will always be will preceded by the PW label on arrival at the PE. If the flow label is inadvertently examined as if it were a normal label, the packet might be forwarded. This can be prevented by setting the associated TTL to 1. Note that this may be a departure from considerations that apply to the general MPLS case. > --- > > Section 10 > > Please change this text to reference early allocation that has been > made for you. Note that the value 17 has NOT been assigned (although > the value 0x17 has). Changed - it's actually ER - and has been allocated. Stewart From curtis@occnc.com Thu Apr 7 20:19:27 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BFA3A683E for ; Thu, 7 Apr 2011 20:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+8yuTPjeeCQ for ; Thu, 7 Apr 2011 20:19:05 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id B9CC73A6838 for ; Thu, 7 Apr 2011 20:19:04 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p383KiY0000715; Thu, 7 Apr 2011 23:20:44 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104080320.p383KiY0000715@harbor.orleans.occnc.com> To: Benjamin Niven-Jenkins From: Curtis Villamizar In-reply-to: Your message of "Wed, 06 Apr 2011 23:31:00 BST." Date: Thu, 07 Apr 2011 23:20:44 -0400 Sender: curtis@occnc.com Cc: "" , pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 03:19:27 -0000 In message Benjamin Niven-Jenkins writes: > > > On 4 Apr 2011, at 09:48, wrote: > >> Benjamin Niven-Jenkins wrote 03 April 2011 19:39 > >> On 31 Mar 2011, at 12:27, Giles Heron wrote: > >>> Agreed. I'd expect the most common use case for TP is in the > >>> access/aggregation. So you might have an MS-PW with 3 segments: > >>> > >>> MPLS TP <-> IP/MPLS <-> MPLS-TP. > >> > >> That was certainly the use case I was looking at using TP for when I > >> wrote > >> > >> http://tools.ietf.org/html/draft-jenkins-mpls-tp-bt-requirements-00 > > > > To be clear Ben, I assume: > > > > 1 You are implying that there is a proper client/server > > relationship between each of the 3 MPLS server layer network > > partitions you identify above, where the PW layer network is > > transparently carried across each of the 3 independent server MPLS > > domains (which of course can belong to different operating parties). > > Yes. Although the case I had in mind was MS-PW where there was a > separate PW segment for each of the MPLS server layers, the fact that > there would have been a 1:1 mapping between PW segments and MPLS > server layers was incidental. The driver for MS-PW was because I > needed the 'edge' PW segments to be statically configured to meet > security requirements but I didn't want to place the same restrictions > on the 'core' PW segment. This is off topic a bit but ... Statically configuring each hop along a path does not in itself support a security requirement. Or maybe I should say, support a security requirement that couldn't be supported by admission control. For example, if an untrusted node such as a customer edge was doing the signaling, the PE could reject anything that didn't have a loose hop and the PE could dictate the rest of the path making it equivalent to static. Of course if the path is only the one hop from CE to PE, then this is a moot point. Also TP is not defined to be static. MPLS can be static. MPLS-TP can use a control plane. It may be that you are using MPLS-TP as static in this usage and that is what you meant. > > 2 There is no 'peering' between logically adjacent server layer > > MPLS layer networks.....noting that non-TOS layer networks never > > need to peer in any case. > > Correct. > > Ben Anyway, the point of the MPLS-TP <-> IP/MPLS <-> MPLS-TP example is that the TP segments would see a GAL above a fat-pw where the fat-pw would be needed in the MPLS segment only. Doing a traceroute would expose this use of GAL above another label at each TP hop. If your point was that you envisioned using a MPLS-TP <-> IP/MPLS <-> MPLS-TP case for a different reason than the normally cited "because it does OAM quite nicely", then point taken. Regards, Curtis From Alexander.Vainshtein@ecitele.com Thu Apr 7 21:56:08 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590A53A690B for ; Thu, 7 Apr 2011 21:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr4R1K07aQgF for ; Thu, 7 Apr 2011 21:56:05 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 6EA0B3A67E6 for ; Thu, 7 Apr 2011 21:56:02 -0700 (PDT) X-AuditID: 93eaf2e8-b7bb7ae0000044d8-5f-4d9e95643b2c Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id 76.9C.17624.4659E9D4; Fri, 8 Apr 2011 07:56:04 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 8 Apr 2011 07:57:46 +0300 From: Alexander Vainshtein To: "stbryant@cisco.com" , "Adrian.Farrel@huawei.com" Date: Fri, 8 Apr 2011 07:57:45 +0300 Thread-Topic: [PWE3] AD review of draft-ietf-pwe3-fat-pw Thread-Index: Acv1VZxPF6mxu2ONSx6dRSWta+4NjQAUSXah Message-ID: References: <031001cbbfb4$ef961500$cec23f00$@huawei.com>, <4D9E08FA.7090000@cisco.com> In-Reply-To: <4D9E08FA.7090000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "pwe3@ietf.org" Subject: Re: [PWE3] AD review of draft-ietf-pwe3-fat-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 04:56:08 -0000 Stewart, Adrian and all, I would like to point (again!) to an (implicit) linkage between this draft = and draft-ietf-pwe3-mpls-tp-gal-in-pw-00 Both drafts allow the PW label stack entry not to be at the bottom of the l= abel stack. The caveat in draft-ietf-pwe3-fat-pw ("the flow label MUST NOT be an MPLS r= eserved label") discussed in this thread actually allows (at a price!) to differentiate bet= ween GAL and fat PW labels. Whether the price is acceptable or not is a matter of opinion and depends o= n implementation. Implementations that assume that the PW label is not special in any way and= that its associated action in the ILM is "Pop and forward to the specific PW forwarder (regardless of the BOS bit)" = would be fully compliant with RFC 3031, RFC 3985 and draft-ietf-pwe3-fat-pw. But they would not natively accommodat= e draft-ietf-pwe3-mpls-tp-gal-in-pw-00. Implementations that always check for the PW label being BOS and doing the = ILM lookup of the next label if it is not BOS would natively accommodate draft-ietf-pwe3-mpls-tp-gal-in-pw-00 but wou= ld not support draft-ietf-pwe3-fat-pw. IMHO it would be useful to re-examine the architectural implications of com= bining these two drafts. That said, I support draft-ietf-pwe3-fat-pw "as is". Regards, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Stewart Br= yant [stbryant@cisco.com] Sent: Thursday, April 07, 2011 9:56 PM To: Adrian.Farrel@huawei.com Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org; pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-fat-pw Adrian Here are the actions I have taken/reply to your points. Lets see where we agree and if we are close to agreement I will upload a new version Stewart > --- > > I found the use of language a little relaxed. You use the same word, > "label", to refer to a label value and to an entry in the shim header. > It would probably be helpful to use the term "label" to refer to the > label itself, and "label entry" to indicate the label, TC bits, and TTL. > I have changed this to use label for the value and label stack entry (LSE) as per RFC3032 for the entry in the label stack. Hopefully I have caught all instances and disposed of them correctly. > --- > > It seems to me that the description of what can be in the additional > label entry is conflicted. > > On receipt of the > pseudowire packet at the egress PE (which knows this additional label > is present) the flow label is discarded without processing. > > This means that the label will not be used for any purpose in the packet > processing except in the DPI of ECMP hashing. > > The flow label can never become the top label in > normal operation > > That is, you will never pop a label to discover the flow label except at > the egress where it is expected and ignored. > > Note that the flow label MUST NOT be an MPLS reserved label (values > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > protocol. > > And why is that restriction required given the two previous points? MPLS has an architectural assumption that a label value with a reserved value has special meaning - always -. Its safer to always assume that to be the case even if we "can get away with it." > > The flow label can never become the top label in > normal operation, and hence the TTL in the flow label is never used > to determine whether the packet should be discarded due to TTL > expiry. Therefore there are no lower restrictions on the TTL value. > > Why do you call out "lower"? How about saying "there are no restrictions" Changed. There was some discussion in the early PW days with, as I recall, Eric Rosen convincing me that bad things would happen in some implementations when a PW had TTL=3D1. This is a carry over from that. > The use of the TC bits (formerly known as the EXP bits) in the flow > label is outside the scope of this document. Unless otherwise agreed > by the ingress and egress PEs these bits MUST be set to zero by the > ingress PE and MUST be ignored by the egress PE. > > "Out of scope" seems to be different from the subsequent statement about > how he TC field must be treated. I am also not clear why the TTL > discussion is different from the TC discussion. Ah, there was a lot of discussion about this is the WG, with some proposals to use them for signaling of state along the LSP. I was pushing back on this on MPSL architectural grounds and the text here was the result of some discussion in WG LC. > --- > > Document title: please spell out PSN done - but note that PSN is a well known term in PWE3 > > > --- > > Abstract: yuck! :-O > > Suggestion... > > OLD > Where the payload carried over a pseudowire carries a number of > identifiable flows it can in some circumstances be desirable to carry > those flows over the equal cost multiple paths (ECMPs) that exist in > the packet switched network. Most forwarding engines are able to > hash based on label stacks and use this to balance flows over ECMPs. > This draft describes a method of identifying the flows, or flow > groups, to the label switched routers by including an additional > label in the label stack. > NEW > Where the payload of a pseudowire comprises a number of distinct > flows, it can be desirable to carry those flows over the equal cost > multiple paths (ECMPs) that exist in the packet switched network. > Most forwarding engines are able to hash based on MPLS label stacks > and use this mechanism to balance MPLS flows over ECMPs. > > This document describes a method of identifying the flows, or flow > groups, within pseudowires such that Label Switching Routers can > balance flows at a finer granularity than individual pseudowires. > The mechanism uses an additional label in the MPLS label stack. > END > done > --- > > Try to avoid "ECMP paths" (or ECMPP as we call them ;-) I use ECMP and ECMPs for the plural > --- > > Section 1 para 1 > > the use of ECMP paths for is known to be > beneficial (and not harmful) to the operation of the PW. > > ?? The (and not harmful) was a heads up to the reader that in some cases it is harmful, and that it is assumed that the reader would know when this was the case and use the mechanism. We could delete the parenthetical remark, but it is harmless other than perhaps as an offense to the English. > --- > > Throughout... > > The plural of "pseudowire" is "pseudowires", not "pseudowire's". > You may safely use "PWs" in your document. > > You have a number of other plurals formed as apostrophe-s. Please > search for "'s" and fix as necessary. > Done > --- > > Section 1 > > Some pseudowires are used to transport large volumes of IP traffic > between routers at two locations. > > I assume that, for some definition of "location" this is also true for > routers at the same location. So how about... > > Some pseudowires are used to transport large volumes of IP traffic > between routers. > Indeed > --- > > Section 1 > > Such pseudowire's do not require strict ordering to > be preserved between packets of the pseudowire. They only require > ordering to be preserved within the context of each individual > transported IP flow. > > I see where this is going, but the first sentence is massively more > relaxed than the second! How about turning it around... > > Such pseudowires only require packet ordering to be preserved within > the context of each individual transported IP flow. They do not > require packet ordering to be preserved between all packets of the > across all IP flows within the pseudowire. > Changed to These PWs only require packet ordering to be preserved within the context of each individual transported IP flow. They do not require packet ordering to be preserved between all packets of across all IP flows within the pseudowire. > --- > > Section 1 > > Some operators have requested the ability to > explicitly configure such a pseudowire to leverage the availability > of multiple ECMP paths. > > I wish you did not feel the need to include this assertion. Why not just > get on and describe the benefits (as you do in the next sentence). > > Currently it really sounds like this is an idea that is strongly opposed > and you are trying to justify it to the rest of the community. In fact, > the community will judge according to the technical merits. Traditionally this is an an anathema in PWs which try hard to look like a "wire" and when we first mooted the idea we got pushback from the ITU-T MPLS-TP community. The reason that we say "Some operators" is because this was an operator initiated, not a vendor initiated project. I have changed this to OLD Some operators have requested the ability to explicitly configure such a PW to leverage the availability of multiple ECMPs. This allows for better capacity planning as the statistical multiplexing of a larger number of smaller flows is more efficient than with a smaller set of larger flows. Although Ethernet is used as an example above, the mechanisms described in this draft are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows. NEW The ability to explicitly configure such a PW to leverage the availability of multiple ECMPs allows for better capacity planning as the statistical multiplexing of a larger number of smaller flows is more efficient than with a smaller set of larger flows. Although Ethernet is used as an example above, the mechanisms described in this draft are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows. END > --- > > > Please don't use the word "draft" in the text as it creates work for the > RFC Editor and might get missed in the publication process. Obviously, by > the time this is published as an RFC it will no longer be a draft. Best > thing to do is search and replace "draft" with "document". > Done. It was an error. Tutorial not required :) > --- > > Section 1 > > Typically, forwarding hardware can deduce that an IP payload is being > directly carried by an MPLS label stack, and is capable of looking at > some fields in packets to construct hash buckets for conversations or > flows. However, an intermediate node has no information on the type > pseudowire being carried in the packet. > > Is the first sentence relevant to this document? I don't think so, but if > you believe it is, I think you will need to add a statement about how > this deduction is made. I have changed the second sentence to " However, when the MPLS payload is a PW, an intermediate node has..." The point of this is to note that routers have been in the habit of doing DPI and ECMP on MPLS LSPs based on deducing that the packet is an IP packet, but PWs provide information hiding that prevents this. I am not sure that a tutorial on how they do it is appropriate, particularl= y as it's not strictly in conformance with the MPLS architecture, but noting that de facto it happens to readers not familiar with LSR design is I believe useful. > --- > > Section 1 > > In the case of a pseudowire emulating > a high bandwidth trunk, the granularity obtained by hashing the > default label stack is inadequate for satisfactory load-balancing. > > Is "the default label stack" intended to convey some special meaning? > I suspect you are trying to say "the label stack that would be > constructed if this I-D hasn't been implemented". You will simply have > to go down the path of saying... > > In the case of a pseudowire emulating > a high bandwidth trunk, the granularity obtained by hashing the > label stack is inadequate for satisfactory load-balancing. > Changed > --- > > Section 1 > > > This draft proposes a method to introduce granularity on the hashing > of traffic running over pseudowires by introducing an additional > label, chosen by the ingress node, and placed at the bottom of the > label stack. > > As above: s/draft/document/ > Also, please be less timid. Your document defines a method. Changed Of course individual-00 did only propose it. > --- > > Section 1.1 > > s/1.1. ECMP in Label Switched Routers/1.1. ECMP in Label Switching Rout= ers/ > > s/Label switched routers/Label Switching Routers (LSRs)/ > None > --- > > Section 1.1 > > been proposed [I-D.kompella-mpls-entropy-label], however that is > > Reading would be significantly enhanced by forward reference to section > 8. > I put in the forward reference and removed the OOS wich seemed a bit strange given we have a section introducing the issue. > --- > > Section 3 > > It is recommended > > > RECOMMENDED ? Done > --- > > Section 3 > > It is recommended that the method chosen to > generate the load balancing labels introduces a high degree of > entropy in their values, to maximise the entropy presented to the > ECMP path selection mechanism in the LSRs in the PSN, and hence > distribute the flows as evenly as possible over the available PSN > ECMP paths. > > It isn't clear to me that entropy is necessarily a good thing. It > depends on the hash algorithm, doesn't it. Entropy is a good thing (TM) in this application .. and the quality of the entropy is a function of the quality of the hash algorithm. > --- > > Figure 2 > > Those four-octet things are not actually labels are they. The fig now says LSE | Flow LSE | 4 octets +---------------------------+ | PW LSE | 4 octets +---------------------------+ | MPLS Tunnel LSE (s) | n*4 octets (four octets per LSE) The rest are not labels > --- > > What is the purpose of the T bit? Why would an implementation go to > the trouble of including the flow-label TLV only to set T=3D0? It may wish to send T=3D0, R=3D1, i.e. I do not propose to send a FAT label, but I can process (discard) one if you send it to me. > --- > > Section 4 > > If PWE3 signalling [RFC4447] is not in use for a pseudowire, then > whether the flow label is used MUST be identically provisioned in > both PEs at the pseudowire endpoints. If there is no provisioning > support for this option, the default behaviour is not to include the > flow label. > > This paragraph is misplaced in the section on signaling. Please put it > elsewhere. Added new section Static Pseudowires and moved the text there. > I am not convinced by the 2119 language in this paragraph since an > implementation cannot control the behavior. It could be interpreted as an instruction to the NMS system and therefore a mandatory implementation instruction at that level. > --- > > Section 4 > > Do you not think that you should say that the new sub-TLV is carried in > the Interface Parameters TLV, and on which messages? The text is consistent with the other PW definitions and the reader has already been referred to RFC4447. > --- > > Section 4.1 > > o FL is the flow label sub-TLV identifier assigned by IANA. > > Can you either put in a [TBD] flag so the RFC Editor will catch this, > or a forward pointer to section 10. I put in the value 0x17 since it's already been allocated. I change the IANA section to say: "IANA is requested to amend the PW Interface Parameters Sub-TLV type Registry value 0x17 (Flow Label indicator) to refer to this RFC." > --- > > Section 5 > > Consider an egress that doesn't support flow label, but previous S-PEs > that do. In this case you are content to throw the baby out with the > bath water? The fix would require a change to the S-PE behavior to remove the FAT label. That is an operation that is more complex than a simple label swap and therefore undesirable. --- > Section 6 > > We believe that this > problem is addressed by the following two methods > > I would like you to be more definitive, please. How about This problem is mitigated by the following two considerations: > But, that said, the subsequent bullets do not provide methods of > addressing OAM in this case. Rather, the text attempts to say why > the problem is not important. In my opinion it fails since, although > ECMP is out of scope for MPLS-TP, a user has reasonable expectations > that some of the flows on their PW will not be wiped out for the IGP > convergence period, when (for example) rapid notification followed > by change of the flow label could cause the traffic to be balanced > differently and avoid the failure, I have added Note that this period may be reduced if a fast re-route or fast convergence technology is deployed in the network [RFC4090],[RFC5286]. > or when a partial failure of a PW > could trigger a switch to a different PW. Well there are two problems here: 1) The whole point is that it's difficult to constantly monitor all paths. 2) It's not clear that the new PW would be diverse when the FL is taken into a/c. > --- > > Section 6 > > s/corruption of an/corruption of a/ Done > --- > > You need to get rid of the reference to I-D.ietf-mpls-lsr-self-test > This work has clearly been abandoned. The reference is replaced by such as an LSP self test technology. With no reference. > --- > > s/Figure 4: Use of Router Alert LAbel/Figure 4: Use of Router Alert Label= / > > --- > > Figure 4 > > Shouldn't "payload" actually read "VCCV message"? > > Shouldn't you include the warning (from 5085) that inserting the router > alert label probably breaks the ECMP hashing such that the packets will > go another way. Added Note that, depending on the number of labels hashed by the LSR, the inclusion of the Router Alert label may cause the OAM packet to be load balanced to a different path from that taken by the data packets with identical Flow and PW labels. > --- > > How funny that labels that are conventionally described as being "above" > on the label stack are shown in your diagrams as below. > Yes, but the mistake is consistent though out all PWE3 docs going back to RFC3985. > --- > > Section 7 > > s/The methods describe/The methods described/ > s/The method proposed/The method defined/ > s/in those cased/in those cases/ > s/The methods describe/The methods described/ Can't find it > --- > > Section 7 > > order is not maintained amongst packets of different > flows. > > I know what you mean, but you have actually said something subtly > different. OLD order is not maintained amongst packets of different flows NEW order is no longer maintained for all packets sent over the PW. > --- > > Section 7 > > Ethernet may have this property, and for that reason > this document focuses on Ethernet. Applications for other high- > access-bandwidth PW's (e.g. Fibre Channel) may be defined in the > future. > > Does the document really *focus* on Ethernet? There are a couple of > places where Ethernet is cited as an example (but where the text says > equally applicable, blah, blah) and two paragraphs a little below this > statement that say "the Ethernet PW". Nothing else. > > Can't you generalise? Section 1 says Although Ethernet is used as an example above, the mechanisms described in this document are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows. I have removed that text and added this note to the bottom of Section 1 NOTE: Although Ethernet is frequently referenced as a use case in this RFC, the mechanisms described in this document are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows. > --- > > Section 7 > > If sequence number support is required this > mechanism is not applicable. > > It's stronger than that, isn't it? > You need to prohibit the mechanism. > But shouldn't you also prohibit ECMP? Now says: If sequence number support is required the flow label mechanism MUST NOT be used. > --- > > Section 7 > > Where it is known that the traffic carried by the Ethernet pseudowire > is IP the method of identifying the flows are well known and can be > applied. Such methods typically include hashing on the source and > destination addresses, the protocol ID and higher-layer flow- > dependent fields such as TCP/UDP ports, L2TPv3 Session ID's etc. > > Either s/method/methods/ or s/are/is/ done > If these methods are so well known, you will have no difficulty in > supplying a reference or two. I am fairly sure that there is no IETF reference to this. It something that all the vendors do (differently), but there has always been strong resistance to the publication of a standard. > > I think you have mixed the method of identifying the flows with the > method of hashing the flows into buckets. The text now says: Where it is known that the traffic carried by the Ethernet PW is IP the method of identifying the flows and mapping them to an ECMP are well known and can be applied. Such methods are typically include hashing on the source and destination addresses, the protocol ID and higher-layer flow-dependent fields such as TCP/UDP ports, L2TPv3 Session ID's etc. > --- > > Section 7.1 > > In the ECMP case and the link bundling case the NSP may attempt to > take bandwidth into consideration when allocating groups of flows to > a common path. That is permitted, but it must be borne in mind that > the semantics of a label stack entry (LSE) as defined by [RFC3032] > cannot be modified, the value of the flow label cannot be modified at > any point on the LSP, and the interpretation of bit patterns in, or > values of, the flow label by an LSR are undefined. > > If you have something to say, you should say it. Otherwise your paragraph > is lost on your readers. > I think you are trying to say "There is no mechanism currently defined > to indicate the bandwidths in use by specific flows using the fields of > the MPLS shim header. Furthermore, since the semantics of the MPLS shim > header are fully defined in [RFC3032] and [RFC5462], those fields cannot > be assigned semantics to carry this information. This document does not > define any semantic for use in the TTL or TC fields of the label entry > that carries the flow label, but requires that the flow label itself > be selected with a high degree of entropy suggesting that the label > value should not be overloaded with additional meaning in any subsequent > specification." OK works for me, but the WG should note the change of wording. > --- > > Section 7.1 > > A different type of load balancing is the desire to carry a > pseudowire over a set of PSN links in which the bandwidth of members > of the link set is less than the bandwidth of the pseudowire. This > problem is addressed in [I-D.stein-pwe3-pwbonding]. Such a mechanism > can be considered complementary to this mechanism. > > > The referenced I-D seems to be dead. I'm not quite sure why you need to > reference it here. How about just taking out the paragraph? It's in there as a result of WG discussion > --- > > Section 7.2 appears to describe exactly the link bundling case that you > discussed in section 7. I have recently noticed considerable confusion > between link bundles and LAG and suggest you restrict LAG to be a data > link function that is below the level of an "interface" in the IP/MPLS > world. That does not mean that an individual node, knowing (by > unspecified means) that it is about to use an interface that is > constructed from a LAG, can't hash the traffic across the LAG. > > Ultimately, you should consider ECMP (i.e. multiple IGP paths) where > each hop on each path may be made a link bundle, and where each > component link of a bundle may be supported by LAG. > > Can you go back and check that you have used the language precisely. The text was added as a result of WG discussion where it was proposed that LAG might use the FL as a key in member selection. > --- > > Section 7.4 > > If the payload on a PW is made of a single inner flow (i.e. an > encrypted connection between two routers), or the flow identifiers > are too deeply buried in the packet, then the functionality described > in this document does not give any benefits, though neither does it > cause harm relative to the existing situation. > > Is that s/i.e./e.g./? Changed > "Too deeply buried" meaning "If the NSP cannot access sufficient > information to distinguish flows, perhaps because the protocol stack > is too deep for its capabilities..."? > > Is the statement about "no harm" necessary? After all, the mechanism > will simply not be used in this case. Text was added as a result of WG discussion on benefits and usage of the mechanism. > --- > > Section 7.4 > > The most common case > where a single flow dominated the traffic on a PW is when it is used > to transport enterprise traffic. Enterprise traffic may well consist > of a large single TCP flows, or encrypted flows that cannot be > handled by the methods described in this document. > > s/dominated/dominates/ yes > s/a large single TCP flows/large TCP flows/ > Again this was WG agreed text > Note that this second half of the paragraph is a non-sequitur from the > first half. You probably need to wrap the whole paragraph with a thought > about single or dominant large flows. That is the title of the section > --- > > Section 7.4 > > 1. The operator can do nothing and the system will work as it does > without the flow label. > > s/can do nothing/can choose to do nothing/ done > --- > > Section 7.4 > > An operator has six options under these circumstances: > > :-) You tease! > > There are only five listed. :) I wonder if I deleted one at some time in the past > --- > > Section 7.4 > > s/an single flow/a single flow/ done > --- > > Section 7.4 > > 5. The operator could configure the ingress to assign a label of > special significance (such as a reserved label) to all high > bandwidth flows so that some other action (not specified in this > document) could be taken on the flow. > > I think you need to delete this as it contradicts two specific > statements made elsewhere... > > 1. MUST NOT use a reserved label as the flow label > 2. MUST NOT assign semantics to the flow label I have deleted (such as a reserved label). This was added as a result of WG discussion. I think that the idea was to use a label from the per platform space. > --- > > 8. Applicability to MPLS > > While I see where you are coming from, I must point out that the whole > of your document is about MPLS. Could you come up with a better title? Now says Applicability to MPLS LSPs > --- > > Section 9 > > The ingress PE SHOULD take steps to ensure that the load-balance > label is not used as a covert channel. > > Again, you are saying something between the lines :-( No, just warning that a badly implemented hash could have side effects. > Since the ingress PE allocates the label (isn't it called the flow label > not the load-balance label?) the "SHOULD take steps" is very odd! And > why is this a security requirement? How would security be compromised? Yes - LB label was an older name for it. I can take it out, or we can leave it to SECdir to advise. > --- > > Section 9 > > This document has signaling extensions in it, so you should reference > RFC 4447 from this section. You should also reference RFC 5920. Added: The security considerations in [RFC5920] also apply. > --- > > Section 9 > > The flow label TTL should therefore never be considered > by the forwarder, and hence SHOULD be set to a value of 1. This will > prevent the packet being inadvertently forwarded based on the value > of the flow label. Note that this may be a departure from > considerations that apply to the general MPLS case. > > But you have previously said that the flow label TTL is never used to > discard a packet based on TTL expiry [section 1.2]. You need to make > your mind up. And, if there are rules you wish to apply for setting > fields, you need to put them in the main part of the protocol spec, > not buried in the security section. > > And (while I'm at it) how is this a security feature? The point is that there is no protocol reason for it to have any particular value. There is a security reason (stopping the packet going some bad place) for stopping it going anywhere, but this is only a recommendation not a requirement. > Oh, and another thing... > > The sequence of your logic is broken. It would be fine to say: > If the flow label is inadvertently examined as if it were a normal > label, the packet might be forwarded. This can be prevented by setting > the associated TTL to 1. > But I don't think that "should never be considered" leads to "should be > set to 1". > > Finally, the note at the end is at best unhelpful. What are you trying > to say, and why? The text now says: The flow LSE is at the bottom of label stack, therefore, even when penultimate hop popping is employed, it will always be will preceded by the PW label on arrival at the PE. If the flow label is inadvertently examined as if it were a normal label, the packet might be forwarded. This can be prevented by setting the associated TTL to 1. Note that this may be a departure from considerations that apply to the general MPLS case. > --- > > Section 10 > > Please change this text to reference early allocation that has been > made for you. Note that the value 17 has NOT been assigned (although > the value 0x17 has). Changed - it's actually ER - and has been allocated. Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From stbryant@cisco.com Fri Apr 8 00:23:47 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6FD3A681B for ; Fri, 8 Apr 2011 00:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRMsGJr4Wn6U for ; Fri, 8 Apr 2011 00:23:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3C9853A69F8 for ; Fri, 8 Apr 2011 00:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2955; q=dns/txt; s=iport; t=1302247531; x=1303457131; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MYDOZaiCBLq64LCF0Vbx1xJyBgohcj8RPPkfP+/gZjQ=; b=L+YU1+Z6yLeJ3sAryTmnFDCR0HaIcSe7zptdBq2Vbm36HLColDBO2xGD H5UD5+pdOYPOe+T6Oi3xn5kHA4MIXhd97xhHGZ720xNCMCWPrFarH/kCc EljWfxr6u82r7JrS7UKvGZKUsIeb7hikEFPZHY6YV8a5JjcTKFMLettFx 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowDADK4nk2Q/khLgWdsb2JhbACmEhQBARYmJYh6mhSCcw4BmUWCfoJvBI1O X-IronPort-AV: E=Sophos;i="4.63,322,1299456000"; d="scan'208";a="82733438" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2011 07:25:30 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p387PU2Y009794; Fri, 8 Apr 2011 07:25:30 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p387PRU05779; Fri, 8 Apr 2011 08:25:28 +0100 (BST) Message-ID: <4D9EB867.9000505@cisco.com> Date: Fri, 08 Apr 2011 08:25:27 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexander Vainshtein References: <031001cbbfb4$ef961500$cec23f00$@huawei.com>, <4D9E08FA.7090000@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" , "Adrian.Farrel@huawei.com" Subject: Re: [PWE3] AD review of draft-ietf-pwe3-fat-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 07:23:48 -0000 Hi Sasha Thanks for the comments > The caveat in draft-ietf-pwe3-fat-pw ("the flow label MUST NOT be an MPLS reserved label") > discussed in this thread actually allows (at a price!) to differentiate between GAL and fat PW labels. This was not included explicitly to support PW/GAL (although it does). It was included because the reserved labels are a general purpose escape mechanism which should always be trapped. However as you note the text omits to say that. > Whether the price is acceptable or not is a matter of opinion and depends on implementation. > > Implementations that assume that the PW label is not special in any way and that its associated action in the ILM is > "Pop and forward to the specific PW forwarder (regardless of the BOS bit)" would be fully compliant with RFC 3031, > RFC 3985 and draft-ietf-pwe3-fat-pw. But they would not natively accommodate draft-ietf-pwe3-mpls-tp-gal-in-pw-00. An interesting point. The implication here is that implementations MUST check that a system receiving a flow label MUST check that it is not a reserved label. The text at the moment (-5 pre Adrian's comments) says: The forwarder at the egress PE uses the pseudowire label to identify the pseudowire. From the context associated with the pseudowire label, the egress PE can determine whether a flow label is present. If a flow label is present, the label is discarded. It should really say: The forwarder at the egress PE uses the pseudowire label to identify the pseudowire. From the context associated with the pseudowire label, the egress PE can determine whether a flow LSE is present. If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If it is a reserved label the packet is processed according to the rules associated with that reserved label, otherwise the LSE is discarded. I have changed the text in candidate -06. Of course the conflict with the GAL mechanism cannot occur because a system that was no trapping GALs would not agree to the use of a GAL based OAM, so I think the original text is safe. However it is bad practice not to note that an MPLS system MUST process the reserved label set when they are ToS. A side note, a pre-standards implementation will not be broken by this late change, since it will have not negotiated use of GAL, and an ingress PE will not have been sending a reserved label as a flow label. So simple discarding the flow label is backwards compatible but not future proof. > Implementations that always check for the PW label being BOS and doing the ILM lookup of the next label if it is not > BOS would natively accommodate draft-ietf-pwe3-mpls-tp-gal-in-pw-00 but would not support draft-ietf-pwe3-fat-pw. > Such implementations would not advertise that they could receive the flow label and hence would never be sent one, so I can't see how the case applies. - Stewart From Alexander.Vainshtein@ecitele.com Fri Apr 8 08:02:10 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA9E3A6938 for ; Fri, 8 Apr 2011 08:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbbGjLWdUXMW for ; Fri, 8 Apr 2011 08:02:10 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id BD1653A67CF for ; Fri, 8 Apr 2011 08:02:09 -0700 (PDT) X-AuditID: 93eaf2e8-b7bb7ae0000044d8-0a-4d9f23729f69 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id 12.A2.17624.2732F9D4; Fri, 8 Apr 2011 18:02:11 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 8 Apr 2011 18:03:53 +0300 From: Alexander Vainshtein To: "stbryant@cisco.com" Date: Fri, 8 Apr 2011 18:00:37 +0300 Thread-Topic: [PWE3] AD review of draft-ietf-pwe3-fat-pw Thread-Index: Acv1viUtZpoTs0JBRAuLuLXjDVo/1gAP5K7n Message-ID: References: <031001cbbfb4$ef961500$cec23f00$@huawei.com>, <4D9E08FA.7090000@cisco.com> , <4D9EB867.9000505@cisco.com> In-Reply-To: <4D9EB867.9000505@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "pwe3@ietf.org" , "Adrian.Farrel@huawei.com" Subject: Re: [PWE3] AD review of draft-ietf-pwe3-fat-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:02:11 -0000 Stewart, Lots of thanks for a prompt and very detailed response.. One additional point (based on these responses) I'd like to make is that ab= ility to negotiate GAL below the PW label exists (or will exit) for signaled PWs, but not for static PWs - which seem= to be the prime target application for using GAL IMHO. Hence I am not sure that relying on the negotiation mechanisms would suffic= e. This is less important for the fat PW label IMO. My 2c, Sasha ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: Friday, April 08, 2011 10:25 AM To: Alexander Vainshtein Cc: Adrian.Farrel@huawei.com; pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-fat-pw Hi Sasha Thanks for the comments > The caveat in draft-ietf-pwe3-fat-pw ("the flow label MUST NOT be an MPLS= reserved label") > discussed in this thread actually allows (at a price!) to differentiate b= etween GAL and fat PW labels. This was not included explicitly to support PW/GAL (although it does). It was included because the reserved labels are a general purpose escape mechanism which should always be trapped. However as you note the text omits to say that. > Whether the price is acceptable or not is a matter of opinion and depends= on implementation. > > Implementations that assume that the PW label is not special in any way a= nd that its associated action in the ILM is > "Pop and forward to the specific PW forwarder (regardless of the BOS bit)= " would be fully compliant with RFC 3031, > RFC 3985 and draft-ietf-pwe3-fat-pw. But they would not natively accommod= ate draft-ietf-pwe3-mpls-tp-gal-in-pw-00. An interesting point. The implication here is that implementations MUST check that a system receiving a flow label MUST check that it is not a reserved label. The text at the moment (-5 pre Adrian's comments) says: The forwarder at the egress PE uses the pseudowire label to identify the pseudowire. From the context associated with the pseudowire label, the egress PE can determine whether a flow label is present. If a flow label is present, the label is discarded. It should really say: The forwarder at the egress PE uses the pseudowire label to identify the pseudowire. From the context associated with the pseudowire label, the egress PE can determine whether a flow LSE is present. If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If it is a reserved label the packet is processed according to the rules associated with that reserved label, otherwise the LSE is discarded. I have changed the text in candidate -06. Of course the conflict with the GAL mechanism cannot occur because a system that was no trapping GALs would not agree to the use of a GAL based OAM, so I think the original text is safe. However it is bad practice not to note that an MPLS system MUST process the reserved label set when they are ToS. A side note, a pre-standards implementation will not be broken by this late change, since it will have not negotiated use of GAL, and an ingress PE will not have been sending a reserved label as a flow label. So simple discarding the flow label is backwards compatible but not future proof. > Implementations that always check for the PW label being BOS and doing th= e ILM lookup of the next label if it is not > BOS would natively accommodate draft-ietf-pwe3-mpls-tp-gal-in-pw-00 but w= ould not support draft-ietf-pwe3-fat-pw. > Such implementations would not advertise that they could receive the flow label and hence would never be sent one, so I can't see how the case applies. - Stewart= From Internet-Drafts@ietf.org Wed Apr 13 00:45:03 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5DD38E06E5; Wed, 13 Apr 2011 00:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cPmz2Ue6zrI; Wed, 13 Apr 2011 00:45:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6EE91E0702; Wed, 13 Apr 2011 00:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.50 Message-ID: <20110413074502.25076.27647.idtracker@ietfc.amsl.com> Date: Wed, 13 Apr 2011 00:45:02 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-oam-msg-map-15.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 07:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Pseudowire (PW) OAM Message Mapping Author(s) : M. Aissaoui, et al. Filename : draft-ietf-pwe3-oam-msg-map-15.txt Pages : 40 Date : 2011-04-12 This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects. It addresses ATM, frame relay, TDM, and SONET/SDH PW services, carried over MPLS, MPLS/IP and L2TPv3/IP Packet Switched Networks (PSNs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pwe3-oam-msg-map-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-13003557.I-D@ietf.org> --NextPart-- From amalis@gmail.com Wed Apr 13 04:50:20 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFEF8E0763 for ; Wed, 13 Apr 2011 04:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT3KFxvqptsw for ; Wed, 13 Apr 2011 04:50:20 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id 11C01E075A for ; Wed, 13 Apr 2011 04:50:19 -0700 (PDT) Received: by ewy19 with SMTP id 19so183099ewy.31 for ; Wed, 13 Apr 2011 04:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=ruVHsUjWCPf0qpk8qyZyn1ejfibNcxq8MysPBSQXNak=; b=MXOeS9csCKJdvasxr+8fUV7LxragYL4FrhQrzAPE5cUm1cpwQMULcmzXkbsHonwkAJ GDf5BxOkcyI/rDzhvVk15t+naW9hbtiXykPn/yPZGm5ZHm+MKWqASMuNqX5BQusY0g8a Xpe8zELkTZOeRP9PQivZtKj8gAp0Se89MaPi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=RXZTvPTj4A8GP00yWiRHxtnov/Iav3pJjHLLafqHAP7HIvRTb5MCZG8VcOr++74wcz UPiEJkLsnM93dQcC/FaphEXd6hhP6POQEc1+zLBBLJnml2Ufw/5hFgPck7pZzg4Xsf3q t52tB4wbY9e53iIne4iMTEZIIqDWhfxXjzhoY= Received: by 10.14.124.133 with SMTP id x5mr3132432eeh.41.1302695419203; Wed, 13 Apr 2011 04:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.53.68 with HTTP; Wed, 13 Apr 2011 04:49:59 -0700 (PDT) From: "Andrew G. Malis" Date: Wed, 13 Apr 2011 07:49:59 -0400 Message-ID: To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:50:20 -0000 The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have asked that this draft be made a PWE3 working group draft. This email starts a two week poll, closing Tuesday April 26, to help judge consensus on this. Please send your responses to the PWE3 list. Thanks, Andy and Matthew From yaakov_s@rad.com Wed Apr 13 06:17:32 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 39931E06C6 for ; Wed, 13 Apr 2011 06:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbbEh6oXnAox for ; Wed, 13 Apr 2011 06:17:31 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by ietfc.amsl.com (Postfix) with ESMTP id 493BBE06B8 for ; Wed, 13 Apr 2011 06:17:30 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 13 Apr 2011 16:17:29 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 13 Apr 2011 16:14:58 +0300 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Wed, 13 Apr 2011 16:14:58 +0300 From: Yaakov Stein To: "Andrew G. Malis" , "pwe3@ietf.org" Thread-Topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-Index: AQHL+dCxlDoxWoYytkSH+9yQfn3hHpRbwXug Date: Wed, 13 Apr 2011 13:14:55 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 13:17:32 -0000 I am sure that we need a way to generate co-routed bidirectional PWs, and thus believe that we need a solution to the problem. BTW, in TICTOC we have a document draft-ietf-tictoc-1588overmpls that accomplishes this for timing over IP over MPLS, using RSVP-TE. There are two questions : 1) is the solution in the scope of PWE3 ? 2) is the solution the right one ? The PWE3 charter states : PWE3 operates "edge to edge" and 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 endpoints of the PW. So we seem to be covered by the "other than" exception. GMPLS provides a mechanism for co-routing LSPs, while PWE3 mechanisms (and certainly the LDP-based PWE3 control protocol) do not provide such mechanisms. However, as the draft shows, by ensuring that a PW is placed in the correct= LSP we get co-routing essentially free of charge. So I support adoption as a WG draft. Y(J)S -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of And= rew G. Malis Sent: Wednesday, April 13, 2011 14:50 To: pwe3@ietf.org Subject: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-= bidir-lsp-02.txt The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have asked that this draft be made a PWE3 working group draft. This email starts a two week poll, closing Tuesday April 26, to help judge consensus on this. Please send your responses to the PWE3 list. Thanks, Andy and Matthew _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From ping@pingpan.org Wed Apr 13 08:37:31 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B2B32E06BB for ; Wed, 13 Apr 2011 08:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-b+JnUWTErm for ; Wed, 13 Apr 2011 08:37:30 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfc.amsl.com (Postfix) with SMTP id 74086E07B0 for ; Wed, 13 Apr 2011 08:37:30 -0700 (PDT) Received: from mail-pw0-f51.google.com ([209.85.160.51]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTaXDOtRGSh8XUhf3H1h04EBmCjd7k/Oj@postini.com; Wed, 13 Apr 2011 08:37:30 PDT Received: by pwi9 with SMTP id 9so372892pwi.24 for ; Wed, 13 Apr 2011 08:37:29 -0700 (PDT) Received: by 10.142.232.9 with SMTP id e9mr2033603wfh.272.1302709049241; Wed, 13 Apr 2011 08:37:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.50.164 with HTTP; Wed, 13 Apr 2011 08:30:40 -0700 (PDT) In-Reply-To: References: From: Ping Pan Date: Wed, 13 Apr 2011 08:30:40 -0700 Message-ID: To: "Andrew G. Malis" Content-Type: multipart/alternative; boundary=000e0cd29e0220313004a0ce9636 Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:37:31 -0000 --000e0cd29e0220313004a0ce9636 Content-Type: text/plain; charset=ISO-8859-1 This is a good solution solving a real problem. Support to make it as a WG draft. Thanks! - Ping On Wed, Apr 13, 2011 at 4:49 AM, Andrew G. Malis wrote: > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > asked that this draft be made a PWE3 working group draft. > > This email starts a two week poll, closing Tuesday April 26, to help > judge consensus on this. > > Please send your responses to the PWE3 list. > > Thanks, > Andy and Matthew > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --000e0cd29e0220313004a0ce9636 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a good solution solving a real problem. Support to make it as a WG = draft.

Thanks!

- Ping

On Wed, Apr 13, 2011 at 4:49 AM, Andrew = G. Malis <amalis@g= mail.com> wrote:
The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have
asked that this draft be made a PWE3 working group draft.

This email starts a two week poll, closing Tuesday April 26, to help
judge consensus on this.

Please send your responses to the PWE3 list.

Thanks,
Andy and Matthew
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--000e0cd29e0220313004a0ce9636-- From tnadeau@lucidvision.com Wed Apr 13 11:18:42 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 487D3E067B for ; Wed, 13 Apr 2011 11:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G5DjJ+KXTBy for ; Wed, 13 Apr 2011 11:18:41 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfc.amsl.com (Postfix) with ESMTP id 8A6D2E0660 for ; Wed, 13 Apr 2011 11:18:41 -0700 (PDT) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id D0C691AEBDB2; Wed, 13 Apr 2011 14:18:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> Date: Wed, 13 Apr 2011 14:18:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8DAA1719-1596-4170-A706-EE86CC0988B4@lucidvision.com> References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> To: Yaakov Stein X-Mailer: Apple Mail (2.1084) Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 18:18:42 -0000 > I am sure that we need a way to generate co-routed bidirectional PWs, > and thus believe that we need a solution to the problem. > BTW, in TICTOC we have a document draft-ietf-tictoc-1588overmpls > that accomplishes this for timing over IP over MPLS, using RSVP-TE. >=20 > There are two questions : > 1) is the solution in the scope of PWE3 ? > 2) is the solution the right one ? >=20 > The PWE3 charter states : > PWE3 operates "edge to edge" and 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 endpoints of the PW. >=20 > So we seem to be covered by the "other than" exception. >=20 > GMPLS provides a mechanism for co-routing LSPs, > while PWE3 mechanisms (and certainly the LDP-based PWE3 control = protocol) > do not provide such mechanisms. > However, as the draft shows, by ensuring that a PW is placed in the = correct LSP > we get co-routing essentially free of charge. Is it possible to adapt the GMPLS approach to solve this problem = rather than reinventing the wheel? --Tom > So I support adoption as a WG draft. >=20 > Y(J)S >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Andrew G. Malis > Sent: Wednesday, April 13, 2011 14:50 > To: pwe3@ietf.org > Subject: [PWE3] PWE3 working group poll for = draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt >=20 > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > asked that this draft be made a PWE3 working group draft. >=20 > This email starts a two week poll, closing Tuesday April 26, to help > judge consensus on this. >=20 > Please send your responses to the PWE3 list. >=20 > Thanks, > Andy and Matthew > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 From curtis@occnc.com Wed Apr 13 12:23:09 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DBE71E07A4 for ; Wed, 13 Apr 2011 12:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jndrv-u4NP4 for ; Wed, 13 Apr 2011 12:23:09 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id F3880E07AA for ; Wed, 13 Apr 2011 12:23:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3DJN4ih018904; Wed, 13 Apr 2011 15:23:04 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104131923.p3DJN4ih018904@harbor.orleans.occnc.com> To: "Andrew G. Malis" From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 07:49:59 EDT." Date: Wed, 13 Apr 2011 15:23:04 -0400 Sender: curtis@occnc.com Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:23:10 -0000 In message "Andrew G. Malis" writes: > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > asked that this draft be made a PWE3 working group draft. > > This email starts a two week poll, closing Tuesday April 26, to help > judge consensus on this. > > Please send your responses to the PWE3 list. > > Thanks, > Andy and Matthew No - not in its current form - maybe with some significant issues resolved. The draft as it now stands identifies the underlying tunnel by endpoint ID, 16 bit tunnel index, and 16 bit LSP ID. The LSP ID may be a transient value in the general MPLS case. In the general MPLS case, the LSP ID is a transient value according to RFC 3209 while the tunnel ID in the SESSION object remains constant. For example, if RFC 3209 make-before-break is used, the LSP-ID changes but the Extended Tunnel ID remains the same. See RFC 3209 section 2.5. Specifically "To effect a reroute, the ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE." This also has to be done to increase the bandwidth on an LSP using make-before-break. An LSP (or more correctly a tunnel) may carry many PW. IF a PW is added, the bandwidth may have to be increased. If the bandwidth is increased using make-before-creak semantics, then the LSP-ID is changed and all of the other PW in the LSP would have to be resignaled with the new LSP-ID. Also if a working an protect LSP were selected with GMPLS style path protections, the LSP-ID delivering traffic is different when protection is enabled. This could be ignored, but if so needs to be mentioned. If both paths go down and a new path has to be created with a reroute, then the LSP-ID changes. If a better path becomes available or some optimization is made changing the working path, then a new LSP-ID is created. I would rather see these problems resolved *before* making this a WG document. Curtis From venkatflex@gmail.com Wed Apr 13 17:54:13 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A3BEE0775 for ; Wed, 13 Apr 2011 17:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSj6r8WS0xmJ for ; Wed, 13 Apr 2011 17:54:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 4283EE05F5 for ; Wed, 13 Apr 2011 17:54:12 -0700 (PDT) Received: by vxg33 with SMTP id 33so1144375vxg.31 for ; Wed, 13 Apr 2011 17:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=7xHWuopkafGWcfjfXpmE904X11xwVGo1p4z7wxacGek=; b=e6oIfo6S9H3iS4zcgpoBcHV4PjxmxRS16Ahkm4KGGMtEqF8wtEk/hhsbWE55Tq07lA DCTaJZTEyVdlHiRvfC3vNbn4CcuksCoSj6ZQkI20oyGzHGqS18caxYCA6NbCs1v1firl GwsIgtzhQ88WiOaIIXEl00ARCFxLLmS7se8os= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OJa02Pp1gyeJNuDNRgSG3H+gC94x8nr9nspgIM4mN/detSuQae4Kc/Uv3+SvK5Z/F8 WinuBsRXg6Q3+4u07Y3FDPZIb5qkAqidb8pLe/CdSBdgdllGnoPQTsNwS7jK2PPaPmsK 0jBHXeZq2Elpf0WvaF8xXDjGzXvy9DGpLJjPI= MIME-Version: 1.0 Received: by 10.52.77.33 with SMTP id p1mr190376vdw.135.1302742451864; Wed, 13 Apr 2011 17:54:11 -0700 (PDT) Received: by 10.52.168.73 with HTTP; Wed, 13 Apr 2011 17:54:11 -0700 (PDT) Date: Wed, 13 Apr 2011 20:54:11 -0400 Message-ID: From: venkatesan mahalingam To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=20cf3063e0fb13c2b304a0d65dd0 Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 00:54:13 -0000 --20cf3063e0fb13c2b304a0d65dd0 Content-Type: text/plain; charset=ISO-8859-1 I agree with Curtis. We may have to dynamically notify the LSP-id change from local PE to the Remote PE when there is a change in LSP. I support this draft for WG adoption before or after solving the LSP-id change related notification. Cheers, Venkat. Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt ------------------------------ - *To*: "Andrew G. Malis" > - *Subject*: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt - *From*: Curtis Villamizar > - *Date*: Wed, 13 Apr 2011 15:23:04 -0400 - *Cc*: pwe3 at ietf.org - *Delivered-to*: pwe3 at ietfc.amsl.com - *In-reply-to*: Your message of "Wed, 13 Apr 2011 07:49:59 EDT." > - *List-archive*: - *List-help*: > - *List-id*: Pseudo Wires Edge to Edge - *List-post*: > - *List-subscribe*: , < mailto:pwe3-request@ietf.org?subject=subscribe > - *List-unsubscribe*: , < mailto:pwe3-request@ietf.org?subject=unsubscribe > - *Reply-to*: curtis at occnc.com - *Sender*: curtis at occnc.com ------------------------------ In message "Andrew G. Malis" writes: > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > asked that this draft be made a PWE3 working group draft. > > This email starts a two week poll, closing Tuesday April 26, to help > judge consensus on this. > > Please send your responses to the PWE3 list. > > Thanks, > Andy and Matthew No - not in its current form - maybe with some significant issues resolved. The draft as it now stands identifies the underlying tunnel by endpoint ID, 16 bit tunnel index, and 16 bit LSP ID. The LSP ID may be a transient value in the general MPLS case. In the general MPLS case, the LSP ID is a transient value according to RFC 3209 while the tunnel ID in the SESSION object remains constant. For example, if RFC 3209 make-before-break is used, the LSP-ID changes but the Extended Tunnel ID remains the same. See RFC 3209 section 2.5. Specifically "To effect a reroute, the ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE." This also has to be done to increase the bandwidth on an LSP using make-before-break. An LSP (or more correctly a tunnel) may carry many PW. IF a PW is added, the bandwidth may have to be increased. If the bandwidth is increased using make-before-creak semantics, then the LSP-ID is changed and all of the other PW in the LSP would have to be resignaled with the new LSP-ID. Also if a working an protect LSP were selected with GMPLS style path protections, the LSP-ID delivering traffic is different when protection is enabled. This could be ignored, but if so needs to be mentioned. If both paths go down and a new path has to be created with a reroute, then the LSP-ID changes. If a better path becomes available or some optimization is made changing the working path, then a new LSP-ID is created. I would rather see these problems resolved *before* making this a WG document. Curtis --20cf3063e0fb13c2b304a0d65dd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

<= span class=3D"Apple-style-span" style=3D"font-weight: normal;">I agree with= Curtis. We may have to dynamically notify the LSP-id change from local PE = to the Remote PE when there is a change in LSP.

I support this draft for WG adoption before or after solving the LSP-i= d change related notification.

Cheers,
V= enkat.

Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir= -lsp-02.txt

In message <BANLkTi=3DjMSCH37CkHhZfTY2Zoq9=
V_BxCzw at mail.gmail.com>
"Andrew G. Malis" writes:
> =20
> The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have
> asked that this draft be made a PWE3 working group draft.
> =20
> This email starts a two week poll, closing Tuesday April 26, to help
> judge consensus on this.
> =20
> Please send your responses to the PWE3 list.
> =20
> Thanks,
> Andy and Matthew



No - not in its current form - maybe with some significant issues
resolved.


The draft as it now stands identifies the underlying tunnel by
endpoint ID, 16 bit tunnel index, and 16 bit LSP ID.  The LSP ID may
be a transient value in the general MPLS case.

In the general MPLS case, the LSP ID is a transient value according to
RFC 3209 while the tunnel ID in the SESSION object remains constant.
For example, if RFC 3209 make-before-break is used, the LSP-ID changes
but the Extended Tunnel ID remains the same.

See RFC 3209 section 2.5.  Specifically "To effect a reroute, the
ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE."

This also has to be done to increase the bandwidth on an LSP using
make-before-break.

An LSP (or more correctly a tunnel) may carry many PW.  IF a PW is
added, the bandwidth may have to be increased.  If the bandwidth is
increased using make-before-creak semantics, then the LSP-ID is
changed and all of the other PW in the LSP would have to be resignaled
with the new LSP-ID.

Also if a working an protect LSP were selected with GMPLS style path
protections, the LSP-ID delivering traffic is different when
protection is enabled.  This could be ignored, but if so needs to be
mentioned.  If both paths go down and a new path has to be created
with a reroute, then the LSP-ID changes.  If a better path becomes
available or some optimization is made changing the working path, then
a new LSP-ID is created.

I would rather see these problems resolved *before* making this a WG
document.

Curtis
--20cf3063e0fb13c2b304a0d65dd0-- From jie.dong@huawei.com Wed Apr 13 19:32:39 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 07689E07DC for ; Wed, 13 Apr 2011 19:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5GYgV4fROoL for ; Wed, 13 Apr 2011 19:32:37 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 53B59E07D8 for ; Wed, 13 Apr 2011 19:32:37 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00M3LF0CRU@szxga04-in.huawei.com> for pwe3@ietf.org; Thu, 14 Apr 2011 10:31:24 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00IPOF0C5J@szxga04-in.huawei.com> for pwe3@ietf.org; Thu, 14 Apr 2011 10:31:24 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Apr 2011 10:31:10 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.8.154]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 14 Apr 2011 10:31:23 +0800 Date: Thu, 14 Apr 2011 02:31:23 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [10.110.98.34] To: "Andrew G. Malis" , "pwe3@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927AFA37C@szxeml508-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL+dFWDrwVZz/FyE6YPA2sP2Ii/pRcorVw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 02:32:39 -0000 The requirement is clear and the solution is reasonable. Support the adoption. Regards, Jie > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Andrew G. Malis > Sent: Wednesday, April 13, 2011 7:50 PM > To: pwe3@ietf.org > Subject: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > asked that this draft be made a PWE3 working group draft. > > This email starts a two week poll, closing Tuesday April 26, to help > judge consensus on this. > > Please send your responses to the PWE3 list. > > Thanks, > Andy and Matthew > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From aldrin.ietf@gmail.com Wed Apr 13 20:31:08 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2BD46E0683 for ; Wed, 13 Apr 2011 20:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be9ZzzwFPXhF for ; Wed, 13 Apr 2011 20:31:07 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfc.amsl.com (Postfix) with ESMTP id A3668E0668 for ; Wed, 13 Apr 2011 20:31:07 -0700 (PDT) Received: by gwb20 with SMTP id 20so684908gwb.31 for ; Wed, 13 Apr 2011 20:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=xqrnjnR/eJXIMoHoOzjFgDnZAFll9FXCiubZx+xZF4M=; b=jfxWNXndW5O1rcXNo7jnYceS8g/QZG83saBFKFcXjcBCsJ0eYI5Vu6zzdxnlWjFnJ3 SxV0E5WzHt6L5XX8/Xe5lhjOPTiyOQe38px6g5cl7bQgQHnNuDcuvkG5Sx5rafmIar1B XcXqtTCaH791rvbyHoTS1d3rC8wAgUXKph4ck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=www0etXwd3bziU0xF7FUj96Xn+BQG/cQxtxOLo6d0sE7MiG575V3E3Weadc5IhIi2m usS0c9OlQ7thfLR6ozjqFR66RAWVP5B/j032eex2W5PXOkA3lW3d8mxKkyjAxQda67/d VzfJP3W/NWtgUcyu1CTGUnnZqGFxU8g9SVHJU= Received: by 10.101.208.8 with SMTP id k8mr132541anq.159.1302751866692; Wed, 13 Apr 2011 20:31:06 -0700 (PDT) Received: from [192.168.1.3] (c-107-3-156-34.hsd1.ca.comcast.net [107.3.156.34]) by mx.google.com with ESMTPS id b28sm1225492anb.22.2011.04.13.20.31.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 20:31:05 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <68D5C022-335F-4D85-BE26-0DF552E40657@gmail.com> X-Mailer: iPad Mail (8G4) From: Sam Aldrin Date: Wed, 13 Apr 2011 20:31:24 -0700 To: "Andrew G. Malis" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 03:31:08 -0000 This is very useful draft providing solution for a real problem. Hence, I su= pport it. -sam Sent from my iPad On Apr 13, 2011, at 4:49 AM, "Andrew G. Malis" wrote: > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > asked that this draft be made a PWE3 working group draft. >=20 > This email starts a two week poll, closing Tuesday April 26, to help > judge consensus on this. >=20 > Please send your responses to the PWE3 list. >=20 > Thanks, > Andy and Matthew > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lmartini@cisco.com Wed Apr 13 22:02:52 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6A377E07D8 for ; Wed, 13 Apr 2011 22:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq6kMedk2HbZ for ; Wed, 13 Apr 2011 22:02:51 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 93674E07A3 for ; Wed, 13 Apr 2011 22:02:51 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3E52jxP007480 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 23:02:46 -0600 (MDT) Message-ID: <4DA67FF5.4010802@cisco.com> Date: Wed, 13 Apr 2011 23:02:45 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: Yaakov Stein References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:02:52 -0000 On 04/13/11 07:14, Yaakov Stein wrote: > I am sure that we need a way to generate co-routed bidirectional PWs, > and thus believe that we need a solution to the problem. > BTW, in TICTOC we have a document draft-ietf-tictoc-1588overmpls > that accomplishes this for timing over IP over MPLS, using RSVP-TE. > > There are two questions : > 1) is the solution in the scope of PWE3 ? > 2) is the solution the right one ? > You did not answer question #2 ... Luca > The PWE3 charter states : > PWE3 operates "edge to edge" and 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 endpoints of the PW. > > So we seem to be covered by the "other than" exception. > > GMPLS provides a mechanism for co-routing LSPs, > while PWE3 mechanisms (and certainly the LDP-based PWE3 control protocol) > do not provide such mechanisms. > However, as the draft shows, by ensuring that a PW is placed in the correct LSP > we get co-routing essentially free of charge. > > So I support adoption as a WG draft. > > Y(J)S > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis > Sent: Wednesday, April 13, 2011 14:50 > To: pwe3@ietf.org > Subject: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > asked that this draft be made a PWE3 working group draft. > > This email starts a two week poll, closing Tuesday April 26, to help > judge consensus on this. > > Please send your responses to the PWE3 list. > > Thanks, > Andy and Matthew > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lmartini@cisco.com Wed Apr 13 22:27:19 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E068AE081F for ; Wed, 13 Apr 2011 22:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW70JqTwPy7J for ; Wed, 13 Apr 2011 22:27:19 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 37098E0812 for ; Wed, 13 Apr 2011 22:27:19 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3E5RGaQ009357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 23:27:16 -0600 (MDT) Message-ID: <4DA685B4.9080804@cisco.com> Date: Wed, 13 Apr 2011 23:27:16 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: "Andrew G. Malis" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:27:20 -0000 On 04/13/11 05:49, Andrew G. Malis wrote: > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > asked that this draft be made a PWE3 working group draft. > > This email starts a two week poll, closing Tuesday April 26, to help > judge consensus on this. > > Please send your responses to the PWE3 list. > > Thanks, > Andy and Matthew > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 No, Not in the current form. Although I agree that this problem is a real problem and needs a solution, this draft does not have enough information to actually build a protocol extension to LDP. In addition to the problems that Curtis mentions, there is no description on how to use the proposed TLVs in the LDP message. How would LDP , which is IP based , even run on an MPLS-TP network ? PW assume that a PSN tunnel is identified by an IP address, which is also used as the LDP target session IP address. How is this possible with an MPLS-TP LSP ? At the minimum we would need some way to identify the IP address at the other end of the mpls-tp tunnel. Also I strongly believe that this WG needs to stop attempting to extend FEC 128 to have similar functionality as FEC 129. Just define new extensions for FEC 129 only , unless they are minor , and can be supported by FEC 128 without changing any existing procedures... Luca From lmartini@cisco.com Wed Apr 13 22:31:41 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CBEE2E06C8 for ; Wed, 13 Apr 2011 22:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-ElQPujAyif for ; Wed, 13 Apr 2011 22:31:40 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 7DFC7E0670 for ; Wed, 13 Apr 2011 22:31:40 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3E5VbW5009725 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 23:31:37 -0600 (MDT) Message-ID: <4DA686B9.8020109@cisco.com> Date: Wed, 13 Apr 2011 23:31:37 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: Sam Aldrin References: <4D92ED69.1040204@pi.nu> <51C51C1B-906E-4108-98C8-D2D86B69D682@gmail.com> In-Reply-To: <51C51C1B-906E-4108-98C8-D2D86B69D682@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "pwe3@ietf.org" Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:31:41 -0000 On 03/30/11 02:51, Sam Aldrin wrote: > When ms-pw ping is performed, the packet should not be processed at S-PE, unless the PW label ttl is expired. With the proposed GAL label above PW label, how do you ensure the OAM packet take the same data path to reach far-end T-PE, without getting processed/punted at S-PE? Or for that matter go beyond first S-PE? > You do not. Either there is no ECMP deployed on the network , or you must use the CW. Luca > -sam > > Sent from my iPad > > On Mar 30, 2011, at 1:44 AM, Loa Andersson wrote: > >> Sasha, >> >> what do you mean with "exposed" I thought that what is gpoing on >> in an S-PE is normal MPLS label switching. >> >> /Loa >> >> On 2011-03-30 10:36, Alexander Vainshtein wrote: >>> Tom, Luca and all, >>> >>> I would like to clarify – again – my position regarding GAL above the PW >>> label. >>> >>> I think that, other issues notwithstanding, it would create an issue if >>> used with MS-PWs: >>> >>> ·GAL would be exposed at each S-PE (making a presumably end-to-end OAM >>> message to be intercepted) >>> >>> ·What is even worse, there is no rule for forwarding the packet that has >>> been intercepted due to an exposed GAL (until you count the statement in >>> 5586 requesting that a packet MUST NOT be ever forwarded based on GALJ). >>> Hence it would be perfectly valid just to drop such a packet at the >>> first S-PE it crosses… >>> >>> This said, I still do not think using GAL below the PW label is a good >>> idea either. But this is a different story… >>> >>> Regards, >>> >>> Sasha >>> >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From lmartini@cisco.com Wed Apr 13 22:41:58 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5ACA8E0810 for ; Wed, 13 Apr 2011 22:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXiW-uJ8nT9M for ; Wed, 13 Apr 2011 22:41:56 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id BA7F7E07FF for ; Wed, 13 Apr 2011 22:41:56 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3E5fogi010501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 23:41:50 -0600 (MDT) Message-ID: <4DA6891E.50504@cisco.com> Date: Wed, 13 Apr 2011 23:41:50 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: curtis@occnc.com References: <201103310910.p2V9AbZ5048623@harbor.orleans.occnc.com> In-Reply-To: <201103310910.p2V9AbZ5048623@harbor.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:41:58 -0000 Curtis, If we keep the GAL at the bottom of the stack to flag the fact that the packet is GACH format , and not IP format, what is the problem ? Surly FAT-PW would still work as most LSRs use the 2 bottom most labels to build a hash table. The gal = label 13 has a fixed binding to it. Do you propose that we change that ? or just the location of the label? Luca On 03/31/11 03:10, Curtis Villamizar wrote: > In message <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsson.se> > David Allan I writes: >> >> HI Curtis: >> >> My suggestion is to avoid the GAL for PWs if it is to be a >> homogenizing agent across TP and IP/MPLS domains in the form of >> MS-PWs. The scenarios in which it was broken was simply a statement of >> fact. >> >> As for the problem GAL was proposed to fix (lack of CW), there are >> solutions on the table, just not palatable... >> >> D > > Dave, > > I think we are in agreement. > > We either use a non-GAL mechanism, or we fix GAL by removing the > bottom of stack restriction and use GAL. > > I prefer the latter option, fix GAL. > > I support not using GAL at all in PW if GAL can't be fixed. > > Fixing GAL should really be an MPLS WG discussion. The result of that > discussion in MPLS should gate whether any PW proposal to use GAL can > be moved forward. > > Curtis > > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Curtis Villamizar >> Sent: Thursday, March 31, 2011 9:03 AM >> To: Loa Andersson >> Cc: pwe3@ietf.org >> Subject: Re: [PWE3] GAL above and below the PW label >> >> >> Loa, Dave, Sasha, >> >> I've snipped from various posts on the thread that Sasha started. See inline. >> >> In message <4D92F5D3.6080609@pi.nu> >> Loa Andersson writes: >>> >>> All, >>> >>> missed a nuance in Sasha subject line. >>> >>> We have two issues >>> >>> - where the GAL is placed relative to the PW label, I believe it is >>> necessary to have the GAL below the PW label. >>> >>> - whether the the GAL label needs to be bottom of stack or not, it >>> figure that this is really a discussion if it is possible to have >>> a FAT label below the GAL or not. I'm not sure about my preferences >>> but I think it is possible. >>> >>> /Loa >> >> I agree with Loa's summary. Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic. >> >> >> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericsson.se> >> David Allan I writes: >>> >>> It does become a new behavior, GAL with S=3D0. However the combination >>> of G= AL being top label at the S-PE and TTL being encoded in the PW >>> label means = that fate sharing is broken at every S-PE. Life only >>> gets a little more str= ange if there is a FAT label as well... >>> >>> That being said, GAL as bottom label is broken in any ECMP >>> environment, whi= ch is why GAL is a TP construct. >>> >>> my 2 cents >>> D >> >> Dave, >> >> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >> If all it takes to fix it is simple then lets just fix it. >> >> This is what we'd have to do. >> >> 1) Relax the requirement that GAL be at the bottom >> >> 2) Have the ingress insert GAL in the stack immediately below the >> label for which the measurement is made, keeping the rest of the >> label stack in place. >> >> The only thing the midpoing LSR at a multipath (LAG, link bundle for >> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there. That will yield the same hash value and it will preserve fate-sharing across multipath. >> >> I prefer that we fix things rather than complain that they are broken. >> >> Curtis >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From gregimirsky@gmail.com Wed Apr 13 23:09:25 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D7863E081C for ; Wed, 13 Apr 2011 23:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+ehfHsG-r-P for ; Wed, 13 Apr 2011 23:09:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 0050BE07A3 for ; Wed, 13 Apr 2011 23:09:24 -0700 (PDT) Received: by vws12 with SMTP id 12so1318844vws.31 for ; Wed, 13 Apr 2011 23:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=df4sdO9ksOyH3Y9551UMge4GUv8wGs/imG4aFFju9KI=; b=sexjYfGOfgduFW6pslNKhhJnjg/kOOvfQ+0I5+VS9Ye1gXFifbP4Ff/UV3G13kpAUo 64hM3v3Os4DUWNQ+gQSE9BaZpiymB0nuNaGt1y88Rg0p2//BFqSDcM/D38hsUUSvexyo 8IG6As9+ExurCqeRjTSRBo5Amfk+h3BAD0ev0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e5Ynj9VJiYuRh8YLSm0t3v6xSiG14w7sgaSuNU+QOgq5k+Hj5ptN+YdxaVrE3TrcDC //LgBn0q1HUb6CAmsrCQ9ql4fvutHF/r/7Tvu+XBqhoh3HU5aMpjBbzg4Qt6NyftyNCL CH9S8lfl1g4RhQbTg65pdRQoahRUp9okF0akg= MIME-Version: 1.0 Received: by 10.52.184.202 with SMTP id ew10mr96113vdc.188.1302761364302; Wed, 13 Apr 2011 23:09:24 -0700 (PDT) Received: by 10.52.159.38 with HTTP; Wed, 13 Apr 2011 23:09:24 -0700 (PDT) In-Reply-To: <4DA685B4.9080804@cisco.com> References: <4DA685B4.9080804@cisco.com> Date: Wed, 13 Apr 2011 23:09:24 -0700 Message-ID: From: Greg Mirsky To: Luca Martini Content-Type: multipart/alternative; boundary=bcaec548654058ad5304a0dac45d Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 06:09:26 -0000 --bcaec548654058ad5304a0dac45d Content-Type: text/plain; charset=ISO-8859-1 Luca, you've asked How would LDP , which is IP based , even run on an MPLS-TP network ? but isn't T-LDP part of MPLS-TP control plane? Control plane assumes IP addressing thus use of T-LDP is plausible. Regards, Greg On Wed, Apr 13, 2011 at 10:27 PM, Luca Martini wrote: > On 04/13/11 05:49, Andrew G. Malis wrote: > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > > asked that this draft be made a PWE3 working group draft. > > > > This email starts a two week poll, closing Tuesday April 26, to help > > judge consensus on this. > > > > Please send your responses to the PWE3 list. > > > > Thanks, > > Andy and Matthew > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > No, Not in the current form. > Although I agree that this problem is a real problem and needs a > solution, this draft does not have enough information to actually build > a protocol extension to LDP. > In addition to the problems that Curtis mentions, there is no > description on how to use the proposed TLVs in the LDP message. > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > PW assume that a PSN tunnel is identified by an IP address, which is > also used as the LDP target session IP address. > How is this possible with an MPLS-TP LSP ? > > At the minimum we would need some way to identify the IP address at the > other end of the mpls-tp tunnel. > > Also I strongly believe that this WG needs to stop attempting to extend > FEC 128 to have similar functionality as FEC 129. > Just define new extensions for FEC 129 only , unless they are minor , > and can be supported by FEC 128 without changing any existing procedures... > > > Luca > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --bcaec548654058ad5304a0dac45d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Luca,
you've asked
How would LDP , which is IP based , even run o= n an MPLS-TP network ?
but isn't T-LDP part of MPLS-TP control plane= ? Control plane assumes IP addressing thus use of T-LDP is plausible.

Regards,
Greg

On Wed, Apr 13, 2011= at 10:27 PM, Luca Martini <lmartini@cisco.com> wrote:
On 04/13/11 05:49, Andrew G. Malis wrote:
> The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > asked that this draft be made a PWE3 working group draft.
>
> This email starts a two week poll, closing Tuesday April 26, to help > judge consensus on this.
>
> Please send your responses to the PWE3 list.
>
> Thanks,
> Andy and Matthew
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
No, Not in the current form.
Although I agree that this problem is a real problem and needs a
solution, this draft does not have enough information to actually build
a protocol extension to LDP.
In addition to the problems that Curtis mentions, there is no
description on how to use the proposed TLVs in the LDP message.

How would LDP , which is IP based , even run on an MPLS-TP network ?

PW assume that a PSN tunnel is identified by an IP address, which is
also used as the LDP target session IP address.
How is this possible with an MPLS-TP LSP ?

At the minimum we would need some way to identify the IP address at the
other end of the mpls-tp tunnel.

Also I strongly believe that this WG needs to stop attempting to extend
FEC 128 to have similar functionality as FEC 129.
Just define new extensions for FEC 129 only , unless they are minor ,
and can be supported by FEC 128 without changing any existing procedures...=


Luca


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--bcaec548654058ad5304a0dac45d-- From mach.chen@huawei.com Thu Apr 14 02:12:00 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1FE0CE0698 for ; Thu, 14 Apr 2011 02:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLcCMRgEVdqL for ; Thu, 14 Apr 2011 02:11:59 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 66673E0664 for ; Thu, 14 Apr 2011 02:11:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM000GYXFWIW@szxga03-in.huawei.com> for pwe3@ietf.org; Thu, 14 Apr 2011 17:09:32 +0800 (CST) Received: from szxeml204-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM0074XXFWOO@szxga03-in.huawei.com> for pwe3@ietf.org; Thu, 14 Apr 2011 17:09:32 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Apr 2011 17:09:16 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 14 Apr 2011 17:09:31 +0800 Date: Thu, 14 Apr 2011 09:09:12 +0000 From: Mach Chen In-reply-to: <4DA685B4.9080804@cisco.com> X-Originating-IP: [10.110.98.37] To: Luca Martini , "Andrew G. Malis" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL+mT+JBB83glcf0eG+4p5eYOFWJRdA/BQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DA685B4.9080804@cisco.com> Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:12:00 -0000 Hi Luca, Thanks for your comments! > Although I agree that this problem is a real problem and needs a > solution, Great! > this draft does not have enough information to actually build > a protocol extension to LDP. Please note that this is not a WG last call :-) the draft is still working in progress, and we'd appreciate that could give suggestion and advice! > In addition to the problems that Curtis mentions, there is no > description on how to use the proposed TLVs in the LDP message. Section 3 of the draft does describe the usage of the PW to LSP Binding TLVs, they are carried in the LDP Mapping message for associating tunnel selection and binding when signaling a PW, the current version of this draft defines how to communicate tunnel LSP selection and binding at the initiation of a PW. Regarding Curtis's comments, it's about dynamic changing the tunnel LSP (whatever for FRR, reroute or protection switching) after a PW established, the authors are working on a revision to resolve the this. And suggestions are welcomed! > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > PW assume that a PSN tunnel is identified by an IP address, which is > also used as the LDP target session IP address. > How is this possible with an MPLS-TP LSP ? As Greg pointed out , this is about the extension to the control plane of PW and LDP is it, and MPLS-TP may run with control plane. In addition, this mechanisms defined in this document is not only for MPLS-TP network, but could be applied to any other scenarios where require both directions of a PW having congruent paths. Best regards, Mach From aldrin.ietf@gmail.com Thu Apr 14 07:43:06 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BE61DE0699 for ; Thu, 14 Apr 2011 07:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N52lzOvWT+dn for ; Thu, 14 Apr 2011 07:43:06 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 0342FE08B4 for ; Thu, 14 Apr 2011 07:43:05 -0700 (PDT) Received: by pxi20 with SMTP id 20so1055154pxi.27 for ; Thu, 14 Apr 2011 07:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=ZXWkTPBGGAweJdtwTr28FEl4zaU1MAePoVWIMNmtDRk=; b=tIns04v+xGw4pwV1fISipepZAxoALhMLl9gqA5nCefT40UdermFMT0ajIXKWie5mZV Y6dFD9Kz8gjq1OgK95WJig2YkZCY3IyeAF4jw1OgjuMFFUd+DFoQslAqsiYiUPTCRTzG DSm1RPEAOiIENPuc9zTDidEa8oYW+cd568tq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=lPAH7Kxyl8aRkOsLGKTjzzcs9RH+51w78LZsJphWv5rl/yuTYTVGwWMwX3XhQS8usQ SFpaLrFE6br8McIO53ylaSNXyXPpgU7/sEwwixmdy8eEIzMd2NFZAbEhIVyQtN0a1n0N yg6FB4zzdciMtMGlQbUIgOIcGDP5YQqwamgus= Received: by 10.68.60.98 with SMTP id g2mr557294pbr.491.1302792185397; Thu, 14 Apr 2011 07:43:05 -0700 (PDT) Received: from [192.168.1.3] (c-107-3-156-34.hsd1.ca.comcast.net [107.3.156.34]) by mx.google.com with ESMTPS id w11sm2393279wfh.6.2011.04.14.07.43.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2011 07:43:03 -0700 (PDT) References: <4D92ED69.1040204@pi.nu> <51C51C1B-906E-4108-98C8-D2D86B69D682@gmail.com> <4DA686B9.8020109@cisco.com> In-Reply-To: <4DA686B9.8020109@cisco.com> Mime-Version: 1.0 (iPad Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (8G4) From: Sam Aldrin Date: Thu, 14 Apr 2011 07:43:23 -0700 To: Luca Martini Cc: "pwe3@ietf.org" Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:43:06 -0000 Luca, This is not regarding the ecmp in the networks, rather the impact of GAL lab= el being present above PW label in ms-PW networks. With the proposed model o= f GAL label above PW label, the Ttl setting of PW label has no bearing, as i= t will get punted at the very next S-PE, due to GAL. Sam Sent from my iPad On Apr 13, 2011, at 10:31 PM, Luca Martini wrote: > On 03/30/11 02:51, Sam Aldrin wrote: >> When ms-pw ping is performed, the packet should not be processed at S-PE,= unless the PW label ttl is expired. With the proposed GAL label above PW la= bel, how do you ensure the OAM packet take the same data path to reach far-e= nd T-PE, without getting processed/punted at S-PE? Or for that matter go bey= ond first S-PE? >>=20 > You do not. > Either there is no ECMP deployed on the network , or you must use the CW. >=20 > Luca >=20 >> -sam >>=20 >> Sent from my iPad >>=20 >> On Mar 30, 2011, at 1:44 AM, Loa Andersson wrote: >>=20 >>> Sasha, >>>=20 >>> what do you mean with "exposed" I thought that what is gpoing on >>> in an S-PE is normal MPLS label switching. >>>=20 >>> /Loa >>>=20 >>> On 2011-03-30 10:36, Alexander Vainshtein wrote: >>>> Tom, Luca and all, >>>>=20 >>>> I would like to clarify =C3=A2=E2=82=AC=E2=80=9C again =C3=A2=E2=82=AC=E2= =80=9C my position regarding GAL above the PW >>>> label. >>>>=20 >>>> I think that, other issues notwithstanding, it would create an issue if= >>>> used with MS-PWs: >>>>=20 >>>> =C3=82=C2=B7GAL would be exposed at each S-PE (making a presumably end-= to-end OAM >>>> message to be intercepted) >>>>=20 >>>> =C3=82=C2=B7What is even worse, there is no rule for forwarding the pac= ket that has >>>> been intercepted due to an exposed GAL (until you count the statement i= n >>>> 5586 requesting that a packet MUST NOT be ever forwarded based on GALJ)= . >>>> Hence it would be perfectly valid just to drop such a packet at the >>>> first S-PE it crosses=C3=A2=E2=82=AC=C2=A6 >>>>=20 >>>> This said, I still do not think using GAL below the PW label is a good >>>> idea either. But this is a different story=C3=A2=E2=82=AC=C2=A6 >>>>=20 >>>> Regards, >>>>=20 >>>> Sasha >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> pwe3 mailing list >>>> pwe3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pwe3 >>> --=20 >>>=20 >>>=20 >>> Loa Andersson email: loa.andersson@ericsson.com >>> Sr Strategy and Standards Manager loa@pi.nu >>> Ericsson Inc phone: +46 10 717 52 13 >>> +46 767 72 92 13 >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >>=20 >=20 From yaakov_s@rad.com Thu Apr 14 08:01:21 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C484BE0765 for ; Thu, 14 Apr 2011 08:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sllPCXsTSjQW for ; Thu, 14 Apr 2011 08:01:19 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by ietfc.amsl.com (Postfix) with ESMTP id 3D701E073D for ; Thu, 14 Apr 2011 08:01:17 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 14 Apr 2011 18:01:12 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 14 Apr 2011 18:01:12 +0300 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Thu, 14 Apr 2011 17:58:38 +0300 From: Yaakov Stein To: Luca Martini Thread-Topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-Index: AQHL+mDc9yuRfczVkkWECBErxXOsrZRdc1cg Date: Thu, 14 Apr 2011 15:01:11 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> <4DA67FF5.4010802@cisco.com> In-Reply-To: <4DA67FF5.4010802@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:01:21 -0000 > You did not answer question #2 ... > Luca I answered it by saying that simply forcing placement of a PW into the appr= opriate LSP solves the problem. (Meaning that I do not want more complex PW-specific me= thods.) I purposely did not state whether the particular LDP mechanism proposed is = optimal or even correct. This is not a LC, it is just a motion to move this to WG status. Y(J)S From lmartini@cisco.com Thu Apr 14 08:48:56 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 19C66E06CA for ; Thu, 14 Apr 2011 08:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oQvzSwkSbdF for ; Thu, 14 Apr 2011 08:48:55 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 0D1E4E06A4 for ; Thu, 14 Apr 2011 08:48:54 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3EFmsK0027011 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 14 Apr 2011 09:48:54 -0600 (MDT) Message-ID: <4DA71765.4060504@cisco.com> Date: Thu, 14 Apr 2011 09:48:53 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: pwe3@ietf.org References: <201103310910.p2V9AbZ5048623@harbor.orleans.occnc.com> <4DA6891E.50504@cisco.com> In-Reply-To: <4DA6891E.50504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:48:56 -0000 hello! It appears to me that it might not be clear that I also believe that the GAL should be at the bottom of the stack. I know that that is not where we have it in the -00 version of the VCCV-2 draft , but that was only an initial suggestion and we really wanted a good discussion on this list. We will update that document shortly. Thanks. Luca On 04/13/11 23:41, Luca Martini wrote: > Curtis, > > If we keep the GAL at the bottom of the stack to flag the fact that the > packet is GACH format , and not IP format, what is the problem ? > Surly FAT-PW would still work as most LSRs use the 2 bottom most labels > to build a hash table. > > The gal = label 13 has a fixed binding to it. Do you propose that we > change that ? or just the location of the label? > > Luca > > > > On 03/31/11 03:10, Curtis Villamizar wrote: >> In message <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsson.se> >> David Allan I writes: >>> >>> HI Curtis: >>> >>> My suggestion is to avoid the GAL for PWs if it is to be a >>> homogenizing agent across TP and IP/MPLS domains in the form of >>> MS-PWs. The scenarios in which it was broken was simply a statement of >>> fact. >>> >>> As for the problem GAL was proposed to fix (lack of CW), there are >>> solutions on the table, just not palatable... >>> >>> D >> Dave, >> >> I think we are in agreement. >> >> We either use a non-GAL mechanism, or we fix GAL by removing the >> bottom of stack restriction and use GAL. >> >> I prefer the latter option, fix GAL. >> >> I support not using GAL at all in PW if GAL can't be fixed. >> >> Fixing GAL should really be an MPLS WG discussion. The result of that >> discussion in MPLS should gate whether any PW proposal to use GAL can >> be moved forward. >> >> Curtis >> >> >>> -----Original Message----- >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Curtis Villamizar >>> Sent: Thursday, March 31, 2011 9:03 AM >>> To: Loa Andersson >>> Cc: pwe3@ietf.org >>> Subject: Re: [PWE3] GAL above and below the PW label >>> >>> >>> Loa, Dave, Sasha, >>> >>> I've snipped from various posts on the thread that Sasha started. See inline. >>> >>> In message <4D92F5D3.6080609@pi.nu> >>> Loa Andersson writes: >>>> >>>> All, >>>> >>>> missed a nuance in Sasha subject line. >>>> >>>> We have two issues >>>> >>>> - where the GAL is placed relative to the PW label, I believe it is >>>> necessary to have the GAL below the PW label. >>>> >>>> - whether the the GAL label needs to be bottom of stack or not, it >>>> figure that this is really a discussion if it is possible to have >>>> a FAT label below the GAL or not. I'm not sure about my preferences >>>> but I think it is possible. >>>> >>>> /Loa >>> >>> I agree with Loa's summary. Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic. >>> >>> >>> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericsson.se> >>> David Allan I writes: >>>> >>>> It does become a new behavior, GAL with S=3D0. However the combination >>>> of G= AL being top label at the S-PE and TTL being encoded in the PW >>>> label means = that fate sharing is broken at every S-PE. Life only >>>> gets a little more str= ange if there is a FAT label as well... >>>> >>>> That being said, GAL as bottom label is broken in any ECMP >>>> environment, whi= ch is why GAL is a TP construct. >>>> >>>> my 2 cents >>>> D >>> >>> Dave, >>> >>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >>> If all it takes to fix it is simple then lets just fix it. >>> >>> This is what we'd have to do. >>> >>> 1) Relax the requirement that GAL be at the bottom >>> >>> 2) Have the ingress insert GAL in the stack immediately below the >>> label for which the measurement is made, keeping the rest of the >>> label stack in place. >>> >>> The only thing the midpoing LSR at a multipath (LAG, link bundle for >>> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there. That will yield the same hash value and it will preserve fate-sharing across multipath. >>> >>> I prefer that we fix things rather than complain that they are broken. >>> >>> Curtis >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lmartini@cisco.com Thu Apr 14 09:07:55 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70A02E06CD for ; Thu, 14 Apr 2011 09:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5ls5OkIcnV5 for ; Thu, 14 Apr 2011 09:07:54 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id C38AEE06A4 for ; Thu, 14 Apr 2011 09:07:54 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3EG7q9L028530 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 14 Apr 2011 10:07:52 -0600 (MDT) Message-ID: <4DA71BD8.4070402@cisco.com> Date: Thu, 14 Apr 2011 10:07:52 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: Yaakov Stein References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> <4DA67FF5.4010802@cisco.com> <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:07:55 -0000 On 04/14/11 09:01, Yaakov Stein wrote: >> You did not answer question #2 ... >> Luca > I answered it by saying that simply forcing placement of a PW into the appropriate LSP > solves the problem. (Meaning that I do not want more complex PW-specific methods.) > > I purposely did not state whether the particular LDP mechanism proposed is optimal or even correct. > This is not a LC, it is just a motion to move this to WG status. > > Y(J)S > > Yes , but historically we have always moved documents to wg status that where at least 80% there... This document is maybe 10% done. I do not think that there is any argument that we, as the PWE3 WG, want to work on this problem. Can you suggest something a bit more complete then ? Thanks. Luca > > From ben@niven-jenkins.co.uk Thu Apr 14 10:45:18 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2E025E07C9 for ; Thu, 14 Apr 2011 10:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.336 X-Spam-Level: X-Spam-Status: No, score=-103.336 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE9lPg6u3c-D for ; Thu, 14 Apr 2011 10:45:17 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfc.amsl.com (Postfix) with ESMTP id 840BBE0716 for ; Thu, 14 Apr 2011 10:45:17 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-108-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QAQbX-0000HK-2g; Thu, 14 Apr 2011 18:45:19 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <4DA71BD8.4070402@cisco.com> Date: Thu, 14 Apr 2011 18:45:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <518E39EC-9642-491B-8368-70481950C0E9@niven-jenkins.co.uk> References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> <4DA67FF5.4010802@cisco.com> <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> <4DA71BD8.4070402@cisco.com> To: Luca Martini X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:45:18 -0000 Luca, Yaakov, Colleagues, I'll admit I haven;t read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02 so = I won't express any specific opinion on that, however please see below. =20 On 14 Apr 2011, at 17:07, Luca Martini wrote: > On 04/14/11 09:01, Yaakov Stein wrote: >>> You did not answer question #2 ... >>> Luca >> I answered it by saying that simply forcing placement of a PW into = the appropriate LSP >> solves the problem. (Meaning that I do not want more complex = PW-specific methods.) >>=20 >> I purposely did not state whether the particular LDP mechanism = proposed is optimal or even correct. >> This is not a LC, it is just a motion to move this to WG status. >>=20 > Yes , but historically we have always moved documents to wg status = that > where at least 80% there... > This document is maybe 10% done. > I do not think that there is any argument that we, as the PWE3 WG, = want > to work on this problem. If the WG agrees to work on a problem then that's a milestone in the = charter IMO. If the WG has a reasonable idea of what the solution should be and a = reasonable enough description of that solution is documented in a draft = such that folks can stand behind it and say "yes that's the right = direction to take to solve the problem" then that's the right time to = "promote" it to a WG draft and bring it under WG change control in order = to finish it off IMO. Promoting a solution draft to a WG draft with a view of "once it's a WG = draft we'll figure out what actual solution to put in there later" seems = a bad idea to me. Ben From lmartini@cisco.com Thu Apr 14 11:10:50 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 61A76E0717 for ; Thu, 14 Apr 2011 11:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vfeg2jx0aMH for ; Thu, 14 Apr 2011 11:10:49 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 81370E065F for ; Thu, 14 Apr 2011 11:10:49 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3EIAini008260 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 14 Apr 2011 12:10:45 -0600 (MDT) Message-ID: <4DA738A4.8010904@cisco.com> Date: Thu, 14 Apr 2011 12:10:44 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: Greg Mirsky References: <4DA685B4.9080804@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 18:10:50 -0000 On 04/14/11 00:09, Greg Mirsky wrote: > Luca, > you've asked > How would LDP , which is IP based , even run on an MPLS-TP network ? > but isn't T-LDP part of MPLS-TP control plane? Control plane assumes > IP addressing thus use of T-LDP is plausible. > No T-LDP is not part of the MPLS-TP control plane. It could be , but i think folks are more leaning toward GMPLS instead. Note that the problem described in this document exists for MPLS. So in that case LDP is certainly used. But the document appears to only care about MPLS-TP. Luca > Regards, > Greg > > On Wed, Apr 13, 2011 at 10:27 PM, Luca Martini > wrote: > > On 04/13/11 05:49, Andrew G. Malis wrote: > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > > asked that this draft be made a PWE3 working group draft. > > > > This email starts a two week poll, closing Tuesday April 26, to help > > judge consensus on this. > > > > Please send your responses to the PWE3 list. > > > > Thanks, > > Andy and Matthew > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > No, Not in the current form. > Although I agree that this problem is a real problem and needs a > solution, this draft does not have enough information to actually > build > a protocol extension to LDP. > In addition to the problems that Curtis mentions, there is no > description on how to use the proposed TLVs in the LDP message. > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > PW assume that a PSN tunnel is identified by an IP address, which is > also used as the LDP target session IP address. > How is this possible with an MPLS-TP LSP ? > > At the minimum we would need some way to identify the IP address > at the > other end of the mpls-tp tunnel. > > Also I strongly believe that this WG needs to stop attempting to > extend > FEC 128 to have similar functionality as FEC 129. > Just define new extensions for FEC 129 only , unless they are minor , > and can be supported by FEC 128 without changing any existing > procedures... > > > Luca > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > From tnadeau@lucidvision.com Thu Apr 14 11:50:59 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 183DCE06E2 for ; Thu, 14 Apr 2011 11:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjDXjwtgwJbS for ; Thu, 14 Apr 2011 11:50:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfc.amsl.com (Postfix) with ESMTP id 6BED6E0693 for ; Thu, 14 Apr 2011 11:50:58 -0700 (PDT) Received: from [10.113.35.136] (mobile-166-137-138-075.mycingular.net [166.137.138.75]) by lucidvision.com (Postfix) with ESMTP id 734611AF031F; Thu, 14 Apr 2011 14:50:57 -0400 (EDT) References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> <4DA67FF5.4010802@cisco.com> <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> <4DA71BD8.4070402@cisco.com> In-Reply-To: <4DA71BD8.4070402@cisco.com> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8G4) From: Thomas Nadeau Date: Thu, 14 Apr 2011 14:50:50 -0400 To: Luca Martini Cc: Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 18:50:59 -0000 I'm with luca. As I said earlier I'd like more discussion as to whether or n= ot other existing solutions couldn't be leveraged before we go forward with t= his one as it is quite under specified. Tom=20 On Apr 14, 2011, at 12:07 PM, Luca Martini wrote: > On 04/14/11 09:01, Yaakov Stein wrote: >>> You did not answer question #2 ... >>> Luca >> I answered it by saying that simply forcing placement of a PW into the ap= propriate LSP >> solves the problem. (Meaning that I do not want more complex PW-specific m= ethods.) >>=20 >> I purposely did not state whether the particular LDP mechanism proposed i= s optimal or even correct. >> This is not a LC, it is just a motion to move this to WG status. >>=20 >> Y(J)S >>=20 >>=20 > Yes , but historically we have always moved documents to wg status that > where at least 80% there... > This document is maybe 10% done. > I do not think that there is any argument that we, as the PWE3 WG, want > to work on this problem. > Can you suggest something a bit more complete then ? >=20 > Thanks. > Luca >=20 >>=20 >>=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 From david.i.allan@ericsson.com Thu Apr 14 11:58:27 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D26D5E0693 for ; Thu, 14 Apr 2011 11:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.285 X-Spam-Level: X-Spam-Status: No, score=-5.285 tagged_above=-999 required=5 tests=[AWL=1.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaXzVH291dLG for ; Thu, 14 Apr 2011 11:58:26 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 93246E0682 for ; Thu, 14 Apr 2011 11:58:26 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3EIw22F008906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Apr 2011 13:58:25 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.159]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 14 Apr 2011 14:57:44 -0400 From: David Allan I To: Luca Martini , "curtis@occnc.com" Date: Thu, 14 Apr 2011 14:57:43 -0400 Thread-Topic: [PWE3] GAL above and below the PW label Thread-Index: Acv6ZqtrDgCMjlkUSdOHc09Xy2TqvgAbsuEw Message-ID: <60C093A41B5E45409A19D42CF7786DFD5219ECA275@EUSAACMS0703.eamcs.ericsson.se> References: <201103310910.p2V9AbZ5048623@harbor.orleans.occnc.com> <4DA6891E.50504@cisco.com> In-Reply-To: <4DA6891E.50504@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 18:58:28 -0000 Hi Luca: I don't think hashing two labels helps achieve consistency for OAM purposes= ... FAT label + GAL does not hash to same value as PW label + FAT label... Am I missing something? D=20 -----Original Message----- From: Luca Martini [mailto:lmartini@cisco.com]=20 Sent: Wednesday, April 13, 2011 10:42 PM To: curtis@occnc.com Cc: David Allan I; pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label Curtis, If we keep the GAL at the bottom of the stack to flag the fact that the pac= ket is GACH format , and not IP format, what is the problem ? Surly FAT-PW would still work as most LSRs use the 2 bottom most labels to = build a hash table. The gal =3D label 13 has a fixed binding to it. Do you propose that we chan= ge that ? or just the location of the label? Luca On 03/31/11 03:10, Curtis Villamizar wrote: > In message=20 > <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsso > n.se> > David Allan I writes: >> =20 >> HI Curtis: >> =20 >> My suggestion is to avoid the GAL for PWs if it is to be a=20 >> homogenizing agent across TP and IP/MPLS domains in the form of=20 >> MS-PWs. The scenarios in which it was broken was simply a statement=20 >> of fact. >> =20 >> As for the problem GAL was proposed to fix (lack of CW), there are=20 >> solutions on the table, just not palatable... >> =20 >> D > > Dave, > > I think we are in agreement. > > We either use a non-GAL mechanism, or we fix GAL by removing the=20 > bottom of stack restriction and use GAL. > > I prefer the latter option, fix GAL. > > I support not using GAL at all in PW if GAL can't be fixed. > > Fixing GAL should really be an MPLS WG discussion. The result of that=20 > discussion in MPLS should gate whether any PW proposal to use GAL can=20 > be moved forward. > > Curtis > > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf=20 >> Of Curtis Villamizar >> Sent: Thursday, March 31, 2011 9:03 AM >> To: Loa Andersson >> Cc: pwe3@ietf.org >> Subject: Re: [PWE3] GAL above and below the PW label >> =20 >> =20 >> Loa, Dave, Sasha, >> =20 >> I've snipped from various posts on the thread that Sasha started. See i= nline. >> =20 >> In message <4D92F5D3.6080609@pi.nu> >> Loa Andersson writes: >>> =20 >>> All, >>> =20 >>> missed a nuance in Sasha subject line. >>> =20 >>> We have two issues >>> =20 >>> - where the GAL is placed relative to the PW label, I believe it is >>> necessary to have the GAL below the PW label. >>> =20 >>> - whether the the GAL label needs to be bottom of stack or not, it >>> figure that this is really a discussion if it is possible to have >>> a FAT label below the GAL or not. I'm not sure about my preferences >>> but I think it is possible. >>> =20 >>> /Loa >> =20 >> I agree with Loa's summary. Not putting GAL at the bottom may confuse s= ome LSR, but putting it above the PW label is likely to be even more proble= matic. >> =20 >> =20 >> In message=20 >> <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericss >> on.se> >> David Allan I writes: >>> =20 >>> It does become a new behavior, GAL with S=3D3D0. However the=20 >>> combination of G=3D AL being top label at the S-PE and TTL being=20 >>> encoded in the PW label means =3D that fate sharing is broken at every= =20 >>> S-PE. Life only gets a little more str=3D ange if there is a FAT label = as well... >>> =20 >>> That being said, GAL as bottom label is broken in any ECMP=20 >>> environment, whi=3D ch is why GAL is a TP construct. >>> =20 >>> my 2 cents >>> D >> =20 >> Dave, >> =20 >> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >> If all it takes to fix it is simple then lets just fix it. >> =20 >> This is what we'd have to do. >> =20 >> 1) Relax the requirement that GAL be at the bottom >> =20 >> 2) Have the ingress insert GAL in the stack immediately below the >> label for which the measurement is made, keeping the rest of the >> label stack in place. >> =20 >> The only thing the midpoing LSR at a multipath (LAG, link bundle for >> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't = there. That will yield the same hash value and it will preserve fate-shari= ng across multipath. >> =20 >> I prefer that we fix things rather than complain that they are broken. >> =20 >> Curtis >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From mach.chen@huawei.com Thu Apr 14 19:35:55 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 55844E075D; Thu, 14 Apr 2011 19:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FBUUo8rgKdn; Thu, 14 Apr 2011 19:35:54 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 702E9E065C; Thu, 14 Apr 2011 19:35:54 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00F039VGSV@szxga04-in.huawei.com>; Fri, 15 Apr 2011 10:35:41 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00ION9VGSW@szxga04-in.huawei.com>; Fri, 15 Apr 2011 10:35:40 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 10:35:25 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 10:35:40 +0800 Date: Fri, 15 Apr 2011 02:35:17 +0000 From: Mach Chen In-reply-to: <4DA738A4.8010904@cisco.com> X-Originating-IP: [10.110.98.37] To: Luca Martini , Greg Mirsky Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Whether T-LDP is part of the MPLS-TP control plane Thread-index: AQHL+xXOuBRay31Jh0yRN2bvU9H63Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: [PWE3] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 02:35:55 -0000 Hi Luca, You said T-LDP is not part of the MPLS-TP control plane. IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is figure about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP layer. In addition, in the abstract of MPLS-TP control plane (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says: "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs)..." Best regards, Mach > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Luca Martini > Sent: Friday, April 15, 2011 2:11 AM > To: Greg Mirsky > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > On 04/14/11 00:09, Greg Mirsky wrote: > > Luca, > > you've asked > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > but isn't T-LDP part of MPLS-TP control plane? Control plane assumes > > IP addressing thus use of T-LDP is plausible. > > > No T-LDP is not part of the MPLS-TP control plane. > It could be , but i think folks are more leaning toward GMPLS instead. > > Note that the problem described in this document exists for MPLS. So in > that case LDP is certainly used. But the document appears to only care > about MPLS-TP. > > Luca > > > > > Regards, > > Greg > > From mach.chen@huawei.com Thu Apr 14 19:36:30 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70985E07B8 for ; Thu, 14 Apr 2011 19:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.459 X-Spam-Level: X-Spam-Status: No, score=-5.459 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE1eXLBO1+tR for ; Thu, 14 Apr 2011 19:36:29 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 56255E0715 for ; Thu, 14 Apr 2011 19:36:29 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00D159WRLH@szxga04-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 10:36:27 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00IZ89WRSW@szxga04-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 10:36:27 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 10:36:22 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 10:36:26 +0800 Date: Fri, 15 Apr 2011 02:36:03 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.37] To: Thomas Nadeau , Luca Martini Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL+mF7CC0OX2NXl0iWklzLN/QjE5Rc7rWAgAASogCAAC2IAIAA7Keg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> <4DA67FF5.4010802@cisco.com> <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> <4DA71BD8.4070402@cisco.com> Cc: Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 02:36:30 -0000 SGkgVG9to6wNCg0KT25lIGNhbmRpZGF0ZSBzb2x1dGlvbiBpcyBtYW51YWwgY29uZmlndXJhdGlv biwgYnV0IGl0IGlzIHByb25lIHRvIGNvbmZpZ3VyYXRpb24gZXJyb3IgYW5kIGluZWZmaWNpZW50 IHRvIG1hbmFnZSBsYXJnZSBudW1iZXIgb2YgUFdzLCBhbmQgZXZlbiB3b3JzZSB3aGVuIGRvIEZS UiwgcmVyb3V0ZSwgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIA0KDQpUaGF0IHdpbGwgYmUgaGVscGZ1 bCBpZiB5b3UgY291bGQgZW51bWVyYXRlIHNvbWUgb3RoZXIgY2FuZGlkYXRlcywgdGhlbiB0aGUg V0cgY291bGQgZGlzY3VzcyBpdCBtb3JlIHNwZWNpZmljYWxseS4NCg0KQmVzdCByZWdhcmRzLA0K TWFjaA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHB3ZTMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ IFRob21hcyBOYWRlYXUNCj4gU2VudDogRnJpZGF5LCBBcHJpbCAxNSwgMjAxMSAyOjUxIEFNDQo+ IFRvOiBMdWNhIE1hcnRpbmkNCj4gQ2M6IFlhYWtvdiBTdGVpbjsgcHdlM0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW1BXRTNdIFBXRTMgd29ya2luZyBncm91cCBwb2xsIGZvcg0KPiBkcmFmdC1j YW8tcHdlMy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTAyLnR4dA0KPiANCj4gSSdtIHdpdGgg bHVjYS4gQXMgSSBzYWlkIGVhcmxpZXIgSSdkIGxpa2UgbW9yZSBkaXNjdXNzaW9uIGFzIHRvIHdo ZXRoZXIgb3Igbm90DQo+IG90aGVyIGV4aXN0aW5nIHNvbHV0aW9ucyBjb3VsZG4ndCBiZSBsZXZl cmFnZWQgYmVmb3JlIHdlIGdvIGZvcndhcmQgd2l0aCB0aGlzDQo+IG9uZSBhcyBpdCBpcyBxdWl0 ZSB1bmRlciBzcGVjaWZpZWQuDQo+IA0KPiBUb20NCj4gDQo+IA0KPiANCj4gT24gQXByIDE0LCAy MDExLCBhdCAxMjowNyBQTSwgTHVjYSBNYXJ0aW5pIDxsbWFydGluaUBjaXNjby5jb20+IHdyb3Rl Og0KPiANCj4gPiBPbiAwNC8xNC8xMSAwOTowMSwgWWFha292IFN0ZWluIHdyb3RlOg0KPiA+Pj4g WW91IGRpZCBub3QgYW5zd2VyIHF1ZXN0aW9uICMyIC4uLg0KPiA+Pj4gTHVjYQ0KPiA+PiBJIGFu c3dlcmVkIGl0IGJ5IHNheWluZyB0aGF0IHNpbXBseSBmb3JjaW5nIHBsYWNlbWVudCBvZiBhIFBX IGludG8gdGhlDQo+IGFwcHJvcHJpYXRlIExTUA0KPiA+PiBzb2x2ZXMgdGhlIHByb2JsZW0uIChN ZWFuaW5nIHRoYXQgSSBkbyBub3Qgd2FudCBtb3JlIGNvbXBsZXggUFctc3BlY2lmaWMNCj4gbWV0 aG9kcy4pDQo+ID4+DQo+ID4+IEkgcHVycG9zZWx5IGRpZCBub3Qgc3RhdGUgd2hldGhlciB0aGUg cGFydGljdWxhciBMRFAgbWVjaGFuaXNtIHByb3Bvc2VkIGlzDQo+IG9wdGltYWwgb3IgZXZlbiBj b3JyZWN0Lg0KPiA+PiBUaGlzIGlzIG5vdCBhIExDLCBpdCBpcyBqdXN0IGEgbW90aW9uIHRvIG1v dmUgdGhpcyB0byBXRyBzdGF0dXMuDQo+ID4+DQo+ID4+IFkoSilTDQo+ID4+DQo+ID4+DQo+ID4g WWVzICwgYnV0IGhpc3RvcmljYWxseSB3ZSBoYXZlIGFsd2F5cyBtb3ZlZCBkb2N1bWVudHMgdG8g d2cgc3RhdHVzIHRoYXQNCj4gPiB3aGVyZSBhdCBsZWFzdCA4MCUgdGhlcmUuLi4NCj4gPiBUaGlz IGRvY3VtZW50IGlzIG1heWJlIDEwJSBkb25lLg0KPiA+IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhl cmUgaXMgYW55IGFyZ3VtZW50IHRoYXQgd2UsIGFzIHRoZSBQV0UzIFdHLCB3YW50DQo+ID4gdG8g d29yayBvbiB0aGlzIHByb2JsZW0uDQo+ID4gQ2FuIHlvdSBzdWdnZXN0IHNvbWV0aGluZyBhIGJp dCBtb3JlIGNvbXBsZXRlIHRoZW4gPw0KPiA+DQo+ID4gVGhhbmtzLg0KPiA+IEx1Y2ENCj4gPg0K PiA+Pg0KPiA+Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBwd2UzIG1haWxpbmcgbGlzdA0KPiA+IHB3ZTNAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMNCj4gPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwd2UzIG1haWxp bmcgbGlzdA0KPiBwd2UzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcHdlMw0K From mach.chen@huawei.com Thu Apr 14 19:42:06 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 269BDE07A9 for ; Thu, 14 Apr 2011 19:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMibwG1rqDza for ; Thu, 14 Apr 2011 19:42:05 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 43F25E079F for ; Thu, 14 Apr 2011 19:42:05 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00IFTA62Q0@szxga03-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 10:42:02 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO003F9A6237@szxga03-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 10:42:02 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 10:42:02 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 10:41:57 +0800 Date: Fri, 15 Apr 2011 02:41:34 +0000 From: Mach Chen In-reply-to: <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> X-Originating-IP: [10.110.98.37] To: Yaakov Stein , Luca Martini Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL+mF7CC0OX2NXl0iWklzLN/QjE5Rc7rWAgAFItKA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> <4DA67FF5.4010802@cisco.com> <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 02:42:06 -0000 Hi Yaakov and Luca, I think Section 5.3.2. "Support for Explicit Control of PW-to-LSP Binding" of http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06 could answer the question #2. Best regards, Mach > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Yaakov Stein > Sent: Thursday, April 14, 2011 11:01 PM > To: Luca Martini > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > > You did not answer question #2 ... > > > Luca > > I answered it by saying that simply forcing placement of a PW into the > appropriate LSP > solves the problem. (Meaning that I do not want more complex PW-specific > methods.) > > I purposely did not state whether the particular LDP mechanism proposed is > optimal or even correct. > This is not a LC, it is just a motion to move this to WG status. > > Y(J)S > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From mach.chen@huawei.com Thu Apr 14 19:58:00 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CFDECE07AF for ; Thu, 14 Apr 2011 19:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDxtbYCK1yjQ for ; Thu, 14 Apr 2011 19:58:00 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id DFDF8E07AE for ; Thu, 14 Apr 2011 19:57:59 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO000KVAWHYX@szxga04-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 10:57:54 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00IVRAWHSW@szxga04-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 10:57:53 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 10:57:37 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 10:57:53 +0800 Date: Fri, 15 Apr 2011 02:57:29 +0000 From: Mach Chen In-reply-to: <4DA71BD8.4070402@cisco.com> X-Originating-IP: [10.110.98.37] To: Luca Martini , Yaakov Stein Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL+mF7CC0OX2NXl0iWklzLN/QjE5Rc7rWAgAASogCAATdekA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> <4DA67FF5.4010802@cisco.com> <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> <4DA71BD8.4070402@cisco.com> Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 02:58:01 -0000 Hi Luca, I am not sure where is the 10% from, that will be helpful you could point out what are the other 90% :-) Until now, the only unresolved specific comments is from Cutris, so we'd appreciate more people to read the draft(http://tools.ietf.org/html/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02) and give your comments! Best regards, Mach > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Luca Martini > Sent: Friday, April 15, 2011 12:08 AM > To: Yaakov Stein > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > On 04/14/11 09:01, Yaakov Stein wrote: > >> You did not answer question #2 ... > >> Luca > > I answered it by saying that simply forcing placement of a PW into the > appropriate LSP > > solves the problem. (Meaning that I do not want more complex PW-specific > methods.) > > > > I purposely did not state whether the particular LDP mechanism proposed is > optimal or even correct. > > This is not a LC, it is just a motion to move this to WG status. > > > > Y(J)S > > > > > Yes , but historically we have always moved documents to wg status that > where at least 80% there... > This document is maybe 10% done. > I do not think that there is any argument that we, as the PWE3 WG, want > to work on this problem. > Can you suggest something a bit more complete then ? > > Thanks. > Luca > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From Alexander.Vainshtein@ecitele.com Thu Apr 14 21:40:29 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6FD1AE073E for ; Thu, 14 Apr 2011 21:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU4OQsQkTDFh for ; Thu, 14 Apr 2011 21:40:28 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfc.amsl.com (Postfix) with ESMTP id F2E01E06FC for ; Thu, 14 Apr 2011 21:40:27 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-3f-4da7cbd57146 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id AC.40.02691.5DBC7AD4; Fri, 15 Apr 2011 07:38:45 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 15 Apr 2011 07:40:25 +0300 From: Alexander Vainshtein To: Luca Martini Date: Fri, 15 Apr 2011 07:40:24 +0300 Thread-Topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-Index: Acv6z0xRnghKfQeNTVOqXep5its8xgAVp0YV Message-ID: References: <4DA685B4.9080804@cisco.com> , <4DA738A4.8010904@cisco.com> In-Reply-To: <4DA738A4.8010904@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTaUwTQRR2tktZkNWlUDsSg2UNJopoi5AUpeofDRpJSdTE4wcs7diutttm tyrVRPFIjMQDb200okFQUVBBRfGiHhE0HjEBb2PEqyiYalS86mxXEeP8+ua973vfm8l7lErT oU6ieMGLRIFzsupYcnMw9DG99XpVnmF7K2Eqv1mmNn3a9iLK9OrRj2jT+lA9OYHM3fLtWFTu af/j6NyKim4it7ttE8gnZ5eAHE4Q3F7Oi/Q2JFnNbL7IL+SsPlbP28yskdV7nJwVuZDgNbOc x4MEGzsuVv/fycE0XtAjweq28YLdzE6eZkk3mbKy043suKFDjKPHxk538JIepbs43ql3IUni 7EiPI4X1KsfRQKbn7uDik3uayBKwBZaCGAoymXDjqgBQ8AB4+0mtuhTEUhqmEcDSlpVAuWwD MHyoOVpmqRkzPF79WC3jRCYV1lz6FlGrmEWw++3pCCZx/MuFLlLGCQwHN3SdIRR+ETxxtBnH KYwzYGdlmhymGQu8fPBGRKph6gCsXeuQcQwzDO5q+hSJA9zc55bDhGKlgw/a9xBK0wysOHtL pWAtfPP8Z5TC18JHq2t/tzYCljeG1ApOg5V7O1SKbzxs3tlOKtqBsOnAPbIM6Py9LPy95P5e cn8veTkgDwEt7/R4i1x2Q8ZIZOW9yIlGWt2u40AZm9cN4OGNYQHAUICNoxtSq/I0UdxCyecK gIEUwWrpZ3iqNP2K3Dafg5McBeICJ5ICAFIqNpFeF6zM09A2zrcYie4/KRP+5I2qpL5WNx5Q wVsw2mD458Lq6M7CijwNY8czNx8hDxL/SAdRFAtpQXaMF5EdFc/lnd6/aYKKkZ3jsPP5Fsyh JQ/nkni7km8BKUk6ukEWM3LCsUDo0co7siwcDgeBDr8zgT4ls+LwBvWog7gwgQvfL4kUxvvQ k0oqAWkvM6hXosN/Jyt5x5W+ydmJtRNTua9iXTVTPqkzlfLMed5mt73ftyYxbsW50q1jx4ya GZ1ft3xqKDj72Mlwcs6s7JTPffov0140WNp3r+o0r/w+ZPGUd8VryiprLA+rWBAfnvf0iXvp B9eMMyu6+qkLySXj+xMP9hsHZV6zhI6su+pjScnBGYerRIn7BVEhUhD+AwAA Cc: "pwe3@ietf.org" , Ben Niven-Jenkins Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 04:40:29 -0000 Luca, and all, >From RFC 5718 "An In-Band Data Communication Network For the MPLS Transport= Profile": 2.1. Pseudowire Setup Provider Edge nodes (PEs) may wish to set up PWs using a signaling protocol that uses remote adjacencies (such as LDP [RFC5036]). In the absence of an IP-based control plane network, these PEs MUST first set up an LSP tunnel across the MPLS-TP network. This tunnel can be used both to carry the PW once it has been set up and to provide a G-ACh-based DCN for control plane communications between the PEs. I interpret this as accepting T-LDP as an element of the MPLS-TP control pla= ne for PWs. Please note also that MS-PWs may cross IP/MPLS and MPLS-TP domains, in which= case usage of T-LDP as the signaling protocol seems natural. To make it clear, this should not be taken as support (or lack thereof) for= draft-cao. My position with regard to this draft is similar to Ben's. Regards, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Luca Martin= i [lmartini@cisco.com] Sent: Thursday, April 14, 2011 9:10 PM To: Greg Mirsky Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-ov= er-bidir-lsp-02.txt On 04/14/11 00:09, Greg Mirsky wrote: > Luca, > you've asked > How would LDP , which is IP based , even run on an MPLS-TP network ? > but isn't T-LDP part of MPLS-TP control plane? Control plane assumes > IP addressing thus use of T-LDP is plausible. > No T-LDP is not part of the MPLS-TP control plane. It could be , but i think folks are more leaning toward GMPLS instead. Note that the problem described in this document exists for MPLS. So in that case LDP is certainly used. But the document appears to only care about MPLS-TP. Luca > Regards, > Greg > > On Wed, Apr 13, 2011 at 10:27 PM, Luca Martini > wrote: > > On 04/13/11 05:49, Andrew G. Malis wrote: > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > > asked that this draft be made a PWE3 working group draft. > > > > This email starts a two week poll, closing Tuesday April 26, to help > > judge consensus on this. > > > > Please send your responses to the PWE3 list. > > > > Thanks, > > Andy and Matthew > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > No, Not in the current form. > Although I agree that this problem is a real problem and needs a > solution, this draft does not have enough information to actually > build > a protocol extension to LDP. > In addition to the problems that Curtis mentions, there is no > description on how to use the proposed TLVs in the LDP message. > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > PW assume that a PSN tunnel is identified by an IP address, which is > also used as the LDP target session IP address. > How is this possible with an MPLS-TP LSP ? > > At the minimum we would need some way to identify the IP address > at the > other end of the mpls-tp tunnel. > > Also I strongly believe that this WG needs to stop attempting to > extend > FEC 128 to have similar functionality as FEC 129. > Just define new extensions for FEC 129 only , unless they are minor , > and can be supported by FEC 128 without changing any existing > procedures... > > > Luca > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Thu Apr 14 21:45:44 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DE054E0720; Thu, 14 Apr 2011 21:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk+t39hlc2Lo; Thu, 14 Apr 2011 21:45:44 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfc.amsl.com (Postfix) with ESMTP id 74D43E06E1; Thu, 14 Apr 2011 21:45:43 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-82-4da7cd12ba25 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 29.50.02691.21DC7AD4; Fri, 15 Apr 2011 07:44:02 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 15 Apr 2011 07:45:42 +0300 From: Alexander Vainshtein To: Mach Chen , Luca Martini , Greg Mirsky Date: Fri, 15 Apr 2011 07:45:10 +0300 Thread-Topic: Whether T-LDP is part of the MPLS-TP control plane Thread-Index: AQHL+xXOuBRay31Jh0yRN2bvU9H63ZReWaFt Message-ID: References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTbWxLURjO6b23vet2ubpVj0WkOTIJ02WbkYp1JvyYxGJii/GHqz3aG7e3 Te815o8RIZlYjG2oz0U3xsRHfA1pWIgYYxJZfOzDooaOkRKCUPf2xkycX8953+d5n/ecvC9N mH7p02lelHFA5ASkN5J7orHPNlPn8eLs0PAs+5eGV5T9dc9Pg73rdKr9WVMLZa+JXSALqaK6 H+eoorZgr6Fo6633VFEo9E1XQq6oAvmcKPpkTsZWF5acDlQS4Cs4ZyWy8i4HykFWv8A5sReL sgNxfj8WXajAaP3v5Cs0XrRi0elz8aLbgRYuXWyz22fOtuWggimTc2bMMZZ6eMmKbV6OF6xe LEmcG1uVyKoLhOdu+IDePzx2w0DrbVAFoinVIImGbB7cebiG0vB42NV3Rl8NjLSJbQOw8Ucd 0C51AD7Y1mtQWXrWAc+f6tWrOI0V4dmbg6SKCXYB7HvdkeCQbAbc9fF6omoqOxc+HKjXafxC GGmMERrOhUOXYgktwy6Gt09uM2hmPwG8+mhzgpTElsKavsEEBkp7XztadZqZBT6LHNFpbbMw dP0hoWEzfPvyF6XxzbBn+xmg8afDo9dieg1nwubGIUIzHgfv7o+QmnYCvHniCbkLWIKjLIKj 5MFR8uAo+VFAngRmXvDLq73u7Nws7ORlLOAsp897HmjT8+YKeH5/ajtgaYBSmCsZx4tNFFch VXrbwQRah8zMwD0lNGa1z1Xp4STPysA6AUvtANIESmN2RpuLTYyLq9yIA74/KbvyzbVEerLT p8ypKK+ckZ39zwVZmOFVoWIT61bGbi3Gfhz4I51I0wgy3fcVx3EB7MYb1vCC/Deto5NU5xTF +Y3aFSP5Oa/Eu7V8B7DR4cEPYWAiRZ+I0y3MC7UQq5I868SROurabIrH41FgUd6cyvSrrBRl qUYqRRUTnWLytCphoqzHSCq9CpRdHrqYuUTXcOPlqc6CZUL8+51Fke4t/Y+7UiPT6vdOXbGm rmWHuXwff+x9oaEeHXp7sMuR1pw3i/pk7Ky9Zk6uaIjO42ozm4R33e3r95X3EOXLM8Lzdx+5 NFDeRuVn5R370FxddiKyoH95xPctfqskOVr2OFragsIFk+YnO3PlVkRKHi5nGhGQuN86k4LV EQQAAA== Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 04:45:45 -0000 Mach, Luca, Greg and all, I concur with Mach on this point. Regards, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Mach Chen [= mach.chen@huawei.com] Sent: Friday, April 15, 2011 5:35 AM To: Luca Martini; Greg Mirsky Cc: mpls@ietf.org; pwe3@ietf.org Subject: [PWE3] Whether T-LDP is part of the MPLS-TP control plane Hi Luca, You said T-LDP is not part of the MPLS-TP control plane. IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is fig= ure about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP laye= r. In addition, in the abstract of MPLS-TP control plane (http://tools.ietf.org= /html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says: "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths= (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires= (PWs)..." Best regards, Mach > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Luca Martini > Sent: Friday, April 15, 2011 2:11 AM > To: Greg Mirsky > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > On 04/14/11 00:09, Greg Mirsky wrote: > > Luca, > > you've asked > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > but isn't T-LDP part of MPLS-TP control plane? Control plane assumes > > IP addressing thus use of T-LDP is plausible. > > > No T-LDP is not part of the MPLS-TP control plane. > It could be , but i think folks are more leaning toward GMPLS instead. > > Note that the problem described in this document exists for MPLS. So in > that case LDP is certainly used. But the document appears to only care > about MPLS-TP. > > Luca > > > > > Regards, > > Greg > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From lizhong.jin@zte.com.cn Fri Apr 15 00:05:53 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 702AEE06D6 for ; Fri, 15 Apr 2011 00:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHSQL3uVXQgg for ; Fri, 15 Apr 2011 00:05:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by ietfc.amsl.com (Postfix) with ESMTP id 9A601E06C8 for ; Fri, 15 Apr 2011 00:05:51 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101397396305; Fri, 15 Apr 2011 15:03:16 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 4886.3802715562; Fri, 15 Apr 2011 15:04:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3F74t5U090126; Fri, 15 Apr 2011 15:04:55 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: curtis@occnc.com, amalis@gmail.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Fri, 15 Apr 2011 15:04:56 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-15 03:04:53, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-15 03:04:53, Serialize complete at 2011-04-15 03:04:53, S/MIME Sign failed at 2011-04-15 03:04:53: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-15 15:04:56, Serialize complete at 2011-04-15 15:04:56 Content-Type: multipart/alternative; boundary="=_alternative 0026E66784257873_=" X-MAIL: mse01.zte.com.cn p3F74t5U090126 Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:05:53 -0000 This is a multipart message in MIME format. --=_alternative 0026E66784257873_= Content-Type: text/plain; charset="US-ASCII" I agree with Curtis, and I also raised similar comments before MIC during IETF79 in Beijing. Additional more comments as below: 1. section 2, what's the difference between figure2 and figure3 of the LSP encoding? If they are the same, can we use only one type of TLV? In draft-ietf-mpls-tp-identifiers-04, the node id is 32bit, why this document define node-id with IPv6 address? 2. Suggest to not include unidirectional LSPs in section 2, and only cover the co-routed and associated LSP. Unidirectional LSPs works fine currently. 3. I suggest to keep the PW signaling independent as much as possible, and each end-point just simply indicate its locally configured LSP to the remote end-point. For the co-routed LSP, each PE can check if the binding is correct, if not, just raise an alarm. Such kind of alarm can be cleared by the operator if it is not an issue. Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 13 Apr 2011 15:23:04 -0400 > From: Curtis Villamizar > To: "Andrew G. Malis" > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > Message-ID: <201104131923.p3DJN4ih018904@harbor.orleans.occnc.com> > > > In message > "Andrew G. Malis" writes: > > > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > > asked that this draft be made a PWE3 working group draft. > > > > This email starts a two week poll, closing Tuesday April 26, to help > > judge consensus on this. > > > > Please send your responses to the PWE3 list. > > > > Thanks, > > Andy and Matthew > > > > No - not in its current form - maybe with some significant issues > resolved. > > > The draft as it now stands identifies the underlying tunnel by > endpoint ID, 16 bit tunnel index, and 16 bit LSP ID. The LSP ID may > be a transient value in the general MPLS case. > > In the general MPLS case, the LSP ID is a transient value according to > RFC 3209 while the tunnel ID in the SESSION object remains constant. > For example, if RFC 3209 make-before-break is used, the LSP-ID changes > but the Extended Tunnel ID remains the same. > > See RFC 3209 section 2.5. Specifically "To effect a reroute, the > ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE." > > This also has to be done to increase the bandwidth on an LSP using > make-before-break. > > An LSP (or more correctly a tunnel) may carry many PW. IF a PW is > added, the bandwidth may have to be increased. If the bandwidth is > increased using make-before-creak semantics, then the LSP-ID is > changed and all of the other PW in the LSP would have to be resignaled > with the new LSP-ID. > > Also if a working an protect LSP were selected with GMPLS style path > protections, the LSP-ID delivering traffic is different when > protection is enabled. This could be ignored, but if so needs to be > mentioned. If both paths go down and a new path has to be created > with a reroute, then the LSP-ID changes. If a better path becomes > available or some optimization is made changing the working path, then > a new LSP-ID is created. > > I would rather see these problems resolved *before* making this a WG > document. > > Curtis > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0026E66784257873_= Content-Type: text/html; charset="US-ASCII"
I agree with Curtis, and I also raised similar comments before MIC during IETF79 in Beijing.

Additional more comments as below:
1. section 2, what's the difference between figure2 and figure3 of the LSP encoding? If they are the same, can we use only one type of TLV? In draft-ietf-mpls-tp-identifiers-04, the node id is 32bit, why this document define node-id with IPv6 address?
2. Suggest to not include unidirectional LSPs in section 2, and only cover the co-routed and associated LSP. Unidirectional LSPs works fine currently.
3. I suggest to keep the PW signaling independent as much as possible, and each end-point just simply indicate its locally configured LSP to the remote end-point. For the co-routed LSP, each PE can check if the binding is correct, if not, just raise an alarm. Such kind of alarm can be cleared by the operator if it is not an issue.

Regards
Lizhong


> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Apr 2011 15:23:04 -0400
> From: Curtis Villamizar <curtis@occnc.com>
> To: "Andrew G. Malis" <amalis@gmail.com>
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] PWE3 working group poll for
>    draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt
> Message-ID: <201104131923.p3DJN4ih018904@harbor.orleans.occnc.com>
>
>
> In message <BANLkTi=jMSCH37CkHhZfTY2Zoq9V_BxCzw@mail.gmail.com>
> "Andrew G. Malis" writes:
> >  
> > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have
> > asked that this draft be made a PWE3 working group draft.
> >  
> > This email starts a two week poll, closing Tuesday April 26, to help
> > judge consensus on this.
> >  
> > Please send your responses to the PWE3 list.
> >  
> > Thanks,
> > Andy and Matthew
>
>
>
> No - not in its current form - maybe with some significant issues
> resolved.
>
>
> The draft as it now stands identifies the underlying tunnel by
> endpoint ID, 16 bit tunnel index, and 16 bit LSP ID.  The LSP ID may
> be a transient value in the general MPLS case.
>
> In the general MPLS case, the LSP ID is a transient value according to
> RFC 3209 while the tunnel ID in the SESSION object remains constant.
> For example, if RFC 3209 make-before-break is used, the LSP-ID changes
> but the Extended Tunnel ID remains the same.
>
> See RFC 3209 section 2.5.  Specifically "To effect a reroute, the
> ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE."
>
> This also has to be done to increase the bandwidth on an LSP using
> make-before-break.
>
> An LSP (or more correctly a tunnel) may carry many PW.  IF a PW is
> added, the bandwidth may have to be increased.  If the bandwidth is
> increased using make-before-creak semantics, then the LSP-ID is
> changed and all of the other PW in the LSP would have to be resignaled
> with the new LSP-ID.
>
> Also if a working an protect LSP were selected with GMPLS style path
> protections, the LSP-ID delivering traffic is different when
> protection is enabled.  This could be ignored, but if so needs to be
> mentioned.  If both paths go down and a new path has to be created
> with a reroute, then the LSP-ID changes.  If a better path becomes
> available or some optimization is made changing the working path, then
> a new LSP-ID is created.
>
> I would rather see these problems resolved *before* making this a WG
> document.
>
> Curtis
>
>
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0026E66784257873_=-- From neil.2.harrison@bt.com Fri Apr 15 00:13:05 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 41AAFE06F1; Fri, 15 Apr 2011 00:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMrqd6eLsTKg; Fri, 15 Apr 2011 00:13:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfc.amsl.com (Postfix) with ESMTP id E2B58E06C8; Fri, 15 Apr 2011 00:13:03 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 15 Apr 2011 08:13:03 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.163]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 15 Apr 2011 08:13:02 +0100 From: To: , , , Date: Fri, 15 Apr 2011 08:12:59 +0100 Thread-Topic: Whether T-LDP is part of the MPLS-TP control plane Thread-Index: AQHL+xXOuBRay31Jh0yRN2bvU9H63ZReWaFtgAAk8JA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4401FD04381@EMV62-UKRD.domain1.systemhost.net> References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:13:05 -0000 Luca is actually correct in that PWs are NOT part of the MPLS-TP CP. This = follows from the simple (obvious?) observation that MS PWs represent a diff= erent layer network to MPLS-TP. The fact PWs should not exist in MPLS-TP i= s a different issue...but given they do then their functional layer network= specification has to be addressed. Aside=3D> I asked Stewart (Bryant) many months ago on a call (in the early = ITU/IETF discussion days) as to why we don't simply use the same GMPLS-base= d signalling protocol for setting up PW connections as we do for MPLS-TP co= nnections, ie why reinvent the wheel? I also had a secondary point that th= e PW layer CP/MP also needs to be logically OOB like the MPLS-TP CP/MP. I = was told for the 1st point that it was because RSVP-TE does not support the= specific type of addressing that PWs use. [Note that access point address= ing is probably THE most definitive component of defining a layer network a= nd one has to take great care with it. Get it wrong or do it badly at the = outset (I can think of some examples ;-)) and it is very hard to change lat= er.] Wrt to the 2nd point Stewart had already realised there was also an O= OB issue for the PW layer network CP/MP, but had no answer at that time. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: 15 April 2011 05:45 > To: Mach Chen; Luca Martini; Greg Mirsky > Cc: mpls@ietf.org; pwe3@ietf.org > Subject: Re: [PWE3] Whether T-LDP is part of the MPLS-TP control plane >=20 > Mach, Luca, Greg and all, > I concur with Mach on this point. >=20 > Regards, > Sasha >=20 > ________________________________________ > From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Mach > Chen [mach.chen@huawei.com] > Sent: Friday, April 15, 2011 5:35 AM > To: Luca Martini; Greg Mirsky > Cc: mpls@ietf.org; pwe3@ietf.org > Subject: [PWE3] Whether T-LDP is part of the MPLS-TP control plane >=20 > Hi Luca, >=20 > You said T-LDP is not part of the MPLS-TP control plane. >=20 > IMHO, this is not right, according to Section 4.4.1 of RFC5921, there > is figure about "MPLS-TP layer boundary", it shows that PW belongs to > MPLS-TP layer. >=20 > In addition, in the abstract of MPLS-TP control plane > (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), > it says: > "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched > Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for > Pseudowires (PWs)..." >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of > > Luca Martini > > Sent: Friday, April 15, 2011 2:11 AM > > To: Greg Mirsky > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] PWE3 working group poll for > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > > > On 04/14/11 00:09, Greg Mirsky wrote: > > > Luca, > > > you've asked > > > How would LDP , which is IP based , even run on an MPLS-TP network > ? > > > but isn't T-LDP part of MPLS-TP control plane? Control plane > assumes > > > IP addressing thus use of T-LDP is plausible. > > > > > No T-LDP is not part of the MPLS-TP control plane. > > It could be , but i think folks are more leaning toward GMPLS > instead. > > > > Note that the problem described in this document exists for MPLS. So > in > > that case LDP is certainly used. But the document appears to only > care > > about MPLS-TP. > > > > Luca > > > > > > > > > Regards, > > > Greg > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From mach.chen@huawei.com Fri Apr 15 02:14:32 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D888CE065A for ; Fri, 15 Apr 2011 02:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtkcfX08NgZQ for ; Fri, 15 Apr 2011 02:14:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 24BE3E0693 for ; Fri, 15 Apr 2011 02:14:24 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO009VCS9LUG@szxga03-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 17:12:57 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO002QAS9L0R@szxga03-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 17:12:57 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 17:12:41 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 17:12:56 +0800 Date: Fri, 15 Apr 2011 09:12:32 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.37] To: "lizhong.jin@zte.com.cn" , "curtis@occnc.com" , "amalis@gmail.com" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_KMQfuM2fWurksRPFNHdtyw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL+ztsdwKtphI3xUCmrLVJXx3cV5RegwOg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:14:33 -0000 --Boundary_(ID_KMQfuM2fWurksRPFNHdtyw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Lizhong, Thanks for your comments! Please see my reply inline... From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of lizhong.jin@zte.com.cn Sent: Friday, April 15, 2011 3:05 PM To: curtis@occnc.com; amalis@gmail.com Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt I agree with Curtis, and I also raised similar comments before MIC during IETF79 in Beijing. Additional more comments as below: 1. section 2, what's the difference between figure2 and figure3 of the LSP encoding? If they are the same, can we use only one type of TLV? In draft-ietf-mpls-tp-identifiers-04, the node id is 32bit, why this document define node-id with IPv6 address? [Mach] The difference is that one is for IPv4 and the other is for IPv6 scenario. The reason for IPv6 address based node-id is that: for a MPLS/GMPLS TE LSP(RFC3209, RFC3471), the Extended Tunnel ID, Tunnel end point address, and Tunnel sender address(which are used to identify a specific TE LSP) could be IPv6 addresses, and this draft is not only for MPLS-TP scenario, but for normal cases where require both directions of a PW to follow congruent path. 2. Suggest to not include unidirectional LSPs in section 2, and only cover the co-routed and associated LSP. Unidirectional LSPs works fine currently. [Mach] The key point is about how to guarantee a bidirectional PW to follow congruent path(no matter what the tunnel is uni- or bi-directional). Including unidirectional LSPs is for the cases where there are only unidirectional LSPs available. 3. I suggest to keep the PW signaling independent as much as possible, and each end-point just simply indicate its locally configured LSP to the remote end-point. For the co-routed LSP, each PE can check if the binding is correct, if not, just raise an alarm. Such kind of alarm can be cleared by the operator if it is not an issue. [Mach] Do you mean that the PW signaling of each end should be independent? If so, IMHO, this is not the practice of the existing PW signaling. With the current PW signaling, many attributes has to be negotiated when setup a PW(e.g., AC-ID, CW, PW Status, VCCV type, etc) between PEs. So, back to this PW-to-LSP binding, the tunnel LSP is just like another attribute that require to be negotiated between the both ends when setup a PW, hence to make sure that the both directions of the PW are over the desired congruent paths. Best regards, Mach Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 13 Apr 2011 15:23:04 -0400 > From: Curtis Villamizar > To: "Andrew G. Malis" > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > Message-ID: <201104131923.p3DJN4ih018904@harbor.orleans.occnc.com> > > > In message > "Andrew G. Malis" writes: > > > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > > asked that this draft be made a PWE3 working group draft. > > > > This email starts a two week poll, closing Tuesday April 26, to help > > judge consensus on this. > > > > Please send your responses to the PWE3 list. > > > > Thanks, > > Andy and Matthew > > > > No - not in its current form - maybe with some significant issues > resolved. > > > The draft as it now stands identifies the underlying tunnel by > endpoint ID, 16 bit tunnel index, and 16 bit LSP ID. The LSP ID may > be a transient value in the general MPLS case. > > In the general MPLS case, the LSP ID is a transient value according to > RFC 3209 while the tunnel ID in the SESSION object remains constant. > For example, if RFC 3209 make-before-break is used, the LSP-ID changes > but the Extended Tunnel ID remains the same. > > See RFC 3209 section 2.5. Specifically "To effect a reroute, the > ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE." > > This also has to be done to increase the bandwidth on an LSP using > make-before-break. > > An LSP (or more correctly a tunnel) may carry many PW. IF a PW is > added, the bandwidth may have to be increased. If the bandwidth is > increased using make-before-creak semantics, then the LSP-ID is > changed and all of the other PW in the LSP would have to be resignaled > with the new LSP-ID. > > Also if a working an protect LSP were selected with GMPLS style path > protections, the LSP-ID delivering traffic is different when > protection is enabled. This could be ignored, but if so needs to be > mentioned. If both paths go down and a new path has to be created > with a reroute, then the LSP-ID changes. If a better path becomes > available or some optimization is made changing the working path, then > a new LSP-ID is created. > > I would rather see these problems resolved *before* making this a WG > document. > > Curtis > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --Boundary_(ID_KMQfuM2fWurksRPFNHdtyw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Lizhong,

 

Thanks for your comments!

 

Please see my reply inline…

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of lizhong.jin@zte.com.cn
Sent: Friday, April 15, 2011 3:05 PM
To: curtis@occnc.com; amalis@gmail.com
Cc: pwe3@ietf.org
Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

 


I agree with Curtis, and I also raised similar comments before MIC during IETF79 in Beijing.

Additional more comments as below:
1. section 2, what's the difference between figure2 and figure3 of the LSP encoding? If they are the same, can we use only one type of TLV? In draft-ietf-mpls-tp-identifiers-04, the node id is 32bit, why this document define node-id with IPv6 address?

 

[Mach]  The difference is that one is for IPv4 and the other is for IPv6 scenario.  The reason for IPv6 address based node-id is that: for a MPLS/GMPLS TE LSP(RFC3209, RFC3471), the Extended Tunnel ID, Tunnel end point address, and Tunnel sender address(which are used to identify a specific TE LSP) could be IPv6 addresses, and this draft is not only for MPLS-TP scenario, but for normal cases where require both directions of a PW to follow congruent path.


2. Suggest to not include unidirectional LSPs in section 2, and only cover the co-routed and associated LSP. Unidirectional LSPs works fine currently.

 

[Mach] The key point is about how to guarantee a bidirectional PW to follow congruent path(no matter what the tunnel is uni- or bi-directional). Including unidirectional LSPs is for the cases where there are only unidirectional LSPs available.


3. I suggest to keep the PW signaling independent as much as possible, and each end-point just simply indicate its locally configured LSP to the remote end-point. For the co-routed LSP, each PE can check if the binding is correct, if not, just raise an alarm. Such kind of alarm can be cleared by the operator if it is not an issue.

 

[Mach] Do you mean that the PW signaling of each end should be independent? If so, IMHO, this is not the practice of the existing PW signaling. With the current PW signaling, many attributes has to be negotiated when setup a PW(e.g., AC-ID, CW, PW Status, VCCV type, etc) between PEs. So, back to this PW-to-LSP binding, the tunnel LSP is just like another attribute that require to be negotiated between the both ends when setup a PW, hence to make sure that the both directions of the PW are over the desired congruent paths.

 

Best regards,

Mach


Regards
Lizhong


> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Apr 2011 15:23:04 -0400
> From: Curtis Villamizar <curtis@occnc.com>
> To: "Andrew G. Malis" <amalis@gmail.com>
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] PWE3 working group poll for
>    draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt
> Message-ID: <201104131923.p3DJN4ih018904@harbor.orleans.occnc.com>
>
>
> In message <BANLkTi=jMSCH37CkHhZfTY2Zoq9V_BxCzw@mail.gmail.com>
> "Andrew G. Malis" writes:
> >  
> > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have
> > asked that this draft be made a PWE3 working group draft.
> >  
> > This email starts a two week poll, closing Tuesday April 26, to help
> > judge consensus on this.
> >  
> > Please send your responses to the PWE3 list.
> >  
> > Thanks,
> > Andy and Matthew
>
>
>
> No - not in its current form - maybe with some significant issues
> resolved.
>
>
> The draft as it now stands identifies the underlying tunnel by
> endpoint ID, 16 bit tunnel index, and 16 bit LSP ID.  The LSP ID may
> be a transient value in the general MPLS case.
>
> In the general MPLS case, the LSP ID is a transient value according to
> RFC 3209 while the tunnel ID in the SESSION object remains constant.
> For example, if RFC 3209 make-before-break is used, the LSP-ID changes
> but the Extended Tunnel ID remains the same.
>
> See RFC 3209 section 2.5.  Specifically "To effect a reroute, the
> ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE."
>
> This also has to be done to increase the bandwidth on an LSP using
> make-before-break.
>
> An LSP (or more correctly a tunnel) may carry many PW.  IF a PW is
> added, the bandwidth may have to be increased.  If the bandwidth is
> increased using make-before-creak semantics, then the LSP-ID is
> changed and all of the other PW in the LSP would have to be resignaled
> with the new LSP-ID.
>
> Also if a working an protect LSP were selected with GMPLS style path
> protections, the LSP-ID delivering traffic is different when
> protection is enabled.  This could be ignored, but if so needs to be
> mentioned.  If both paths go down and a new path has to be created
> with a reroute, then the LSP-ID changes.  If a better path becomes
> available or some optimization is made changing the working path, then
> a new LSP-ID is created.
>
> I would rather see these problems resolved *before* making this a WG
> document.
>
> Curtis
>
>
> 

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--Boundary_(ID_KMQfuM2fWurksRPFNHdtyw)-- From lizhong.jin@zte.com.cn Fri Apr 15 02:42:04 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 35832E066F for ; Fri, 15 Apr 2011 02:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.362 X-Spam-Level: X-Spam-Status: No, score=-100.362 tagged_above=-999 required=5 tests=[AWL=-1.477, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_75=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaCqtLoMqQZ9 for ; Fri, 15 Apr 2011 02:42:02 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by ietfc.amsl.com (Postfix) with ESMTP id E81B3E0664 for ; Fri, 15 Apr 2011 02:41:59 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101397396305; Fri, 15 Apr 2011 17:38:26 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 4886.5263586291; Fri, 15 Apr 2011 17:32:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3F9VoXM077364; Fri, 15 Apr 2011 17:31:51 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Mach Chen MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Fri, 15 Apr 2011 17:31:45 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-15 05:31:42, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-15 05:31:42, Serialize complete at 2011-04-15 05:31:42, S/MIME Sign failed at 2011-04-15 05:31:42: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-15 17:31:53, Serialize complete at 2011-04-15 17:31:53 Content-Type: multipart/alternative; boundary="=_alternative 0034576884257873_=" X-MAIL: mse02.zte.com.cn p3F9VoXM077364 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:42:04 -0000 This is a multipart message in MIME format. --=_alternative 0034576884257873_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTWFjaCwNClNlZSBjb21tZW50cyBpbiBsaW5lIGJlbG93Lg0KDQpSZWdhcmRzDQpMaXpob25n DQogDQoNCk1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+IHdyb3RlIG9uIDIwMTEtMDQt MTUgMDU6MTI6MzI6DQoNCj4gSGkgTGl6aG9uZywNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBjb21t ZW50cyENCj4gDQo+IFBsZWFzZSBzZWUgbXkgcmVwbHkgaW5saW5loa0NCj4gRnJvbTogcHdlMy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgDQo+IGxpemhvbmcuamluQHp0ZS5jb20uY24NCj4gU2VudDogRnJpZGF5LCBBcHJpbCAxNSwg MjAxMSAzOjA1IFBNDQo+IFRvOiBjdXJ0aXNAb2NjbmMuY29tOyBhbWFsaXNAZ21haWwuY29tDQo+ IENjOiBwd2UzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUFdFM10gUFdFMyB3b3JraW5nIGdy b3VwIHBvbGwgZm9yIGRyYWZ0LWNhby1wd2UzLW1wbHMtDQo+IHRwLXB3LW92ZXItYmlkaXItbHNw LTAyLnR4dA0KPiANCj4gDQo+IEkgYWdyZWUgd2l0aCBDdXJ0aXMsIGFuZCBJIGFsc28gcmFpc2Vk IHNpbWlsYXIgY29tbWVudHMgYmVmb3JlIE1JQyANCj4gZHVyaW5nIElFVEY3OSBpbiBCZWlqaW5n LiANCj4gDQo+IEFkZGl0aW9uYWwgbW9yZSBjb21tZW50cyBhcyBiZWxvdzogDQo+IDEuIHNlY3Rp b24gMiwgd2hhdCdzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gZmlndXJlMiBhbmQgZmlndXJlMyBv ZiANCj4gdGhlIExTUCBlbmNvZGluZz8gSWYgdGhleSBhcmUgdGhlIHNhbWUsIGNhbiB3ZSB1c2Ug b25seSBvbmUgdHlwZSBvZiANCj4gVExWPyBJbiBkcmFmdC1pZXRmLW1wbHMtdHAtaWRlbnRpZmll cnMtMDQsIHRoZSBub2RlIGlkIGlzIDMyYml0LCB3aHkNCj4gdGhpcyBkb2N1bWVudCBkZWZpbmUg bm9kZS1pZCB3aXRoIElQdjYgYWRkcmVzcz8gDQo+IA0KPiBbTWFjaF0gIFRoZSBkaWZmZXJlbmNl IGlzIHRoYXQgb25lIGlzIGZvciBJUHY0IGFuZCB0aGUgb3RoZXIgaXMgZm9yIA0KPiBJUHY2IHNj ZW5hcmlvLiAgVGhlIHJlYXNvbiBmb3IgSVB2NiBhZGRyZXNzIGJhc2VkIG5vZGUtaWQgaXMgdGhh dDogDQo+IGZvciBhIE1QTFMvR01QTFMgVEUgTFNQKFJGQzMyMDksIFJGQzM0NzEpLCB0aGUgRXh0 ZW5kZWQgVHVubmVsIElELCANCj4gVHVubmVsIGVuZCBwb2ludCBhZGRyZXNzLCBhbmQgVHVubmVs IHNlbmRlciBhZGRyZXNzKHdoaWNoIGFyZSB1c2VkIA0KPiB0byBpZGVudGlmeSBhIHNwZWNpZmlj IFRFIExTUCkgY291bGQgYmUgSVB2NiBhZGRyZXNzZXMsIGFuZCB0aGlzIA0KPiBkcmFmdCBpcyBu b3Qgb25seSBmb3IgTVBMUy1UUCBzY2VuYXJpbywgYnV0IGZvciBub3JtYWwgY2FzZXMgd2hlcmUg DQo+IHJlcXVpcmUgYm90aCBkaXJlY3Rpb25zIG9mIGEgUFcgdG8gZm9sbG93IGNvbmdydWVudCBw YXRoLg0KW0xpemhvbmddIGlmIHlvdSB1c2UgTERQdjYgYXMgdGhlIHNpZ25hbGluZyBwcm90b2Nv bCwgdGhlcmUgc2hvdWxkIGJlIGFsc28gDQphIDMyYml0IHZhbHVlIG9mIExEUC1JRCB0byBiZSB1 c2VkIGFzIG5vZGUgaWQuDQoNCj4gDQo+IDIuIFN1Z2dlc3QgdG8gbm90IGluY2x1ZGUgdW5pZGly ZWN0aW9uYWwgTFNQcyBpbiBzZWN0aW9uIDIsIGFuZCBvbmx5DQo+IGNvdmVyIHRoZSBjby1yb3V0 ZWQgYW5kIGFzc29jaWF0ZWQgTFNQLiBVbmlkaXJlY3Rpb25hbCBMU1BzIHdvcmtzIA0KPiBmaW5l IGN1cnJlbnRseS4gDQo+IA0KPiBbTWFjaF0gVGhlIGtleSBwb2ludCBpcyBhYm91dCBob3cgdG8g Z3VhcmFudGVlIGEgYmlkaXJlY3Rpb25hbCBQVyB0bw0KPiBmb2xsb3cgY29uZ3J1ZW50IHBhdGgo bm8gbWF0dGVyIHdoYXQgdGhlIHR1bm5lbCBpcyB1bmktIG9yIGJpLQ0KPiBkaXJlY3Rpb25hbCku IEluY2x1ZGluZyB1bmlkaXJlY3Rpb25hbCBMU1BzIGlzIGZvciB0aGUgY2FzZXMgd2hlcmUgDQo+ IHRoZXJlIGFyZSBvbmx5IHVuaWRpcmVjdGlvbmFsIExTUHMgYXZhaWxhYmxlLiANCltMaXpob25n XSBmb3IgdW5pZGlyZWN0aW9uYWwgTFNQIGNhc2UsIGp1c3QgbGVhdmUgaXQgYXMgaXQgaXMgbm93 LCBieSANCmNvbmZpZ3VyYXRpb24gYW5kIGFkbWluaXN0cmF0aW9uLiBJIHRoaW5rIHRoaXMgaXMg YSByYXJlIGNhc2UuDQoNCj4gDQo+IDMuIEkgc3VnZ2VzdCB0byBrZWVwIHRoZSBQVyBzaWduYWxp bmcgaW5kZXBlbmRlbnQgYXMgbXVjaCBhcyANCj4gcG9zc2libGUsIGFuZCBlYWNoIGVuZC1wb2lu dCBqdXN0IHNpbXBseSBpbmRpY2F0ZSBpdHMgbG9jYWxseSANCj4gY29uZmlndXJlZCBMU1AgdG8g dGhlIHJlbW90ZSBlbmQtcG9pbnQuIEZvciB0aGUgY28tcm91dGVkIExTUCwgZWFjaCANCj4gUEUg Y2FuIGNoZWNrIGlmIHRoZSBiaW5kaW5nIGlzIGNvcnJlY3QsIGlmIG5vdCwganVzdCByYWlzZSBh biBhbGFybS4NCj4gU3VjaCBraW5kIG9mIGFsYXJtIGNhbiBiZSBjbGVhcmVkIGJ5IHRoZSBvcGVy YXRvciBpZiBpdCBpcyBub3QgYW4gaXNzdWUuIA0KDQo+IA0KPiBbTWFjaF0gRG8geW91IG1lYW4g dGhhdCB0aGUgUFcgc2lnbmFsaW5nIG9mIGVhY2ggZW5kIHNob3VsZCBiZSANCj4gaW5kZXBlbmRl bnQ/IElmIHNvLCBJTUhPLCB0aGlzIGlzIG5vdCB0aGUgcHJhY3RpY2Ugb2YgdGhlIGV4aXN0aW5n IA0KPiBQVyBzaWduYWxpbmcuIFdpdGggdGhlIGN1cnJlbnQgUFcgc2lnbmFsaW5nLCBtYW55IGF0 dHJpYnV0ZXMgaGFzIHRvIA0KPiBiZSBuZWdvdGlhdGVkIHdoZW4gc2V0dXAgYSBQVyhlLmcuLCBB Qy1JRCwgQ1csIFBXIFN0YXR1cywgVkNDViB0eXBlLA0KPiBldGMpIGJldHdlZW4gUEVzLiBTbywg YmFjayB0byB0aGlzIFBXLXRvLUxTUCBiaW5kaW5nLCB0aGUgdHVubmVsIExTUA0KPiBpcyBqdXN0 IGxpa2UgYW5vdGhlciBhdHRyaWJ1dGUgdGhhdCByZXF1aXJlIHRvIGJlIG5lZ290aWF0ZWQgYmV0 d2Vlbg0KPiB0aGUgYm90aCBlbmRzIHdoZW4gc2V0dXAgYSBQVywgaGVuY2UgdG8gbWFrZSBzdXJl IHRoYXQgdGhlIGJvdGggDQo+IGRpcmVjdGlvbnMgb2YgdGhlIFBXIGFyZSBvdmVyIHRoZSBkZXNp cmVkIGNvbmdydWVudCBwYXRocy4gDQpbTGl6aG9uZ10gSSBtZWFuIG5vdCB0byBuZWdvdGlhdGVk IHRoZSBMU1AgYXV0b21hdGljYWxseSwganVzdCBpbmRpY2F0ZSBhbiANCmFsYXJtIHRvIHRoZSBv cGVyYXRvciBpZiBub3QgY29uZ3J1ZW50Lg0KDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IE1hY2gN Cj4gDQo+IFJlZ2FyZHMgDQo+IExpemhvbmcgDQo+IA0KPiANCj4gPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4gDQo+ID4gTWVzc2FnZTogMQ0KPiA+IERhdGU6IFdlZCwgMTMgQXByIDIwMTEgMTU6MjM6MDQg LTA0MDANCj4gPiBGcm9tOiBDdXJ0aXMgVmlsbGFtaXphciA8Y3VydGlzQG9jY25jLmNvbT4NCj4g PiBUbzogIkFuZHJldyBHLiBNYWxpcyIgPGFtYWxpc0BnbWFpbC5jb20+DQo+ID4gQ2M6IHB3ZTNA aWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW1BXRTNdIFBXRTMgd29ya2luZyBncm91cCBwb2xs IGZvcg0KPiA+ICAgIGRyYWZ0LWNhby1wd2UzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDIu dHh0DQo+ID4gTWVzc2FnZS1JRDogPDIwMTEwNDEzMTkyMy5wM0RKTjRpaDAxODkwNEBoYXJib3Iu b3JsZWFucy5vY2NuYy5jb20+DQo+ID4gDQo+ID4gDQo+ID4gSW4gbWVzc2FnZSA8QkFOTGtUaT1q TVNDSDM3Q2tIaFpmVFkyWm9xOVZfQnhDendAbWFpbC5nbWFpbC5jb20+DQo+ID4gIkFuZHJldyBH LiBNYWxpcyIgd3JpdGVzOg0KPiA+ID4gDQo+ID4gPiBUaGUgYXV0aG9ycyBvZiBkcmFmdC1jYW8t cHdlMy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTAyLnR4dCBoYXZlDQo+ID4gPiBhc2tlZCB0 aGF0IHRoaXMgZHJhZnQgYmUgbWFkZSBhIFBXRTMgd29ya2luZyBncm91cCBkcmFmdC4NCj4gPiA+ IA0KPiA+ID4gVGhpcyBlbWFpbCBzdGFydHMgYSB0d28gd2VlayBwb2xsLCBjbG9zaW5nIFR1ZXNk YXkgQXByaWwgMjYsIHRvIGhlbHANCj4gPiA+IGp1ZGdlIGNvbnNlbnN1cyBvbiB0aGlzLg0KPiA+ ID4gDQo+ID4gPiBQbGVhc2Ugc2VuZCB5b3VyIHJlc3BvbnNlcyB0byB0aGUgUFdFMyBsaXN0Lg0K PiA+ID4gDQo+ID4gPiBUaGFua3MsDQo+ID4gPiBBbmR5IGFuZCBNYXR0aGV3DQo+ID4gDQo+ID4g DQo+ID4gDQo+ID4gTm8gLSBub3QgaW4gaXRzIGN1cnJlbnQgZm9ybSAtIG1heWJlIHdpdGggc29t ZSBzaWduaWZpY2FudCBpc3N1ZXMNCj4gPiByZXNvbHZlZC4NCj4gPiANCj4gPiANCj4gPiBUaGUg ZHJhZnQgYXMgaXQgbm93IHN0YW5kcyBpZGVudGlmaWVzIHRoZSB1bmRlcmx5aW5nIHR1bm5lbCBi eQ0KPiA+IGVuZHBvaW50IElELCAxNiBiaXQgdHVubmVsIGluZGV4LCBhbmQgMTYgYml0IExTUCBJ RC4gIFRoZSBMU1AgSUQgbWF5DQo+ID4gYmUgYSB0cmFuc2llbnQgdmFsdWUgaW4gdGhlIGdlbmVy YWwgTVBMUyBjYXNlLg0KPiA+IA0KPiA+IEluIHRoZSBnZW5lcmFsIE1QTFMgY2FzZSwgdGhlIExT UCBJRCBpcyBhIHRyYW5zaWVudCB2YWx1ZSBhY2NvcmRpbmcgdG8NCj4gPiBSRkMgMzIwOSB3aGls ZSB0aGUgdHVubmVsIElEIGluIHRoZSBTRVNTSU9OIG9iamVjdCByZW1haW5zIGNvbnN0YW50Lg0K PiA+IEZvciBleGFtcGxlLCBpZiBSRkMgMzIwOSBtYWtlLWJlZm9yZS1icmVhayBpcyB1c2VkLCB0 aGUgTFNQLUlEIGNoYW5nZXMNCj4gPiBidXQgdGhlIEV4dGVuZGVkIFR1bm5lbCBJRCByZW1haW5z IHRoZSBzYW1lLg0KPiA+IA0KPiA+IFNlZSBSRkMgMzIwOSBzZWN0aW9uIDIuNS4gIFNwZWNpZmlj YWxseSAiVG8gZWZmZWN0IGEgcmVyb3V0ZSwgdGhlDQo+ID4gaW5ncmVzcyBub2RlIHBpY2tzIGEg bmV3IExTUCBJRCBhbmQgZm9ybXMgYSBuZXcgU0VOREVSX1RFTVBMQVRFLiINCj4gPiANCj4gPiBU aGlzIGFsc28gaGFzIHRvIGJlIGRvbmUgdG8gaW5jcmVhc2UgdGhlIGJhbmR3aWR0aCBvbiBhbiBM U1AgdXNpbmcNCj4gPiBtYWtlLWJlZm9yZS1icmVhay4NCj4gPiANCj4gPiBBbiBMU1AgKG9yIG1v cmUgY29ycmVjdGx5IGEgdHVubmVsKSBtYXkgY2FycnkgbWFueSBQVy4gIElGIGEgUFcgaXMNCj4g PiBhZGRlZCwgdGhlIGJhbmR3aWR0aCBtYXkgaGF2ZSB0byBiZSBpbmNyZWFzZWQuICBJZiB0aGUg YmFuZHdpZHRoIGlzDQo+ID4gaW5jcmVhc2VkIHVzaW5nIG1ha2UtYmVmb3JlLWNyZWFrIHNlbWFu dGljcywgdGhlbiB0aGUgTFNQLUlEIGlzDQo+ID4gY2hhbmdlZCBhbmQgYWxsIG9mIHRoZSBvdGhl ciBQVyBpbiB0aGUgTFNQIHdvdWxkIGhhdmUgdG8gYmUgcmVzaWduYWxlZA0KPiA+IHdpdGggdGhl IG5ldyBMU1AtSUQuDQo+ID4gDQo+ID4gQWxzbyBpZiBhIHdvcmtpbmcgYW4gcHJvdGVjdCBMU1Ag d2VyZSBzZWxlY3RlZCB3aXRoIEdNUExTIHN0eWxlIHBhdGgNCj4gPiBwcm90ZWN0aW9ucywgdGhl IExTUC1JRCBkZWxpdmVyaW5nIHRyYWZmaWMgaXMgZGlmZmVyZW50IHdoZW4NCj4gPiBwcm90ZWN0 aW9uIGlzIGVuYWJsZWQuICBUaGlzIGNvdWxkIGJlIGlnbm9yZWQsIGJ1dCBpZiBzbyBuZWVkcyB0 byBiZQ0KPiA+IG1lbnRpb25lZC4gIElmIGJvdGggcGF0aHMgZ28gZG93biBhbmQgYSBuZXcgcGF0 aCBoYXMgdG8gYmUgY3JlYXRlZA0KPiA+IHdpdGggYSByZXJvdXRlLCB0aGVuIHRoZSBMU1AtSUQg Y2hhbmdlcy4gIElmIGEgYmV0dGVyIHBhdGggYmVjb21lcw0KPiA+IGF2YWlsYWJsZSBvciBzb21l IG9wdGltaXphdGlvbiBpcyBtYWRlIGNoYW5naW5nIHRoZSB3b3JraW5nIHBhdGgsIHRoZW4NCj4g PiBhIG5ldyBMU1AtSUQgaXMgY3JlYXRlZC4NCj4gPiANCj4gPiBJIHdvdWxkIHJhdGhlciBzZWUg dGhlc2UgcHJvYmxlbXMgcmVzb2x2ZWQgKmJlZm9yZSogbWFraW5nIHRoaXMgYSBXRw0KPiA+IGRv Y3VtZW50Lg0KPiA+IA0KPiA+IEN1cnRpcw0KPiA+IA0KPiA+IA0KPiA+IA0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0034576884257873_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE1hY2gsPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TZWUgY29tbWVudHMgaW4gbGluZSBiZWxv dy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2Fy ZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxpemhvbmc8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5NYWNoIENoZW4gJmx0O21hY2guY2hlbkBodWF3ZWkuY29tJmd0 OyB3cm90ZSBvbiAyMDExLTA0LTE1DQowNToxMjozMjo8YnI+DQo8YnI+DQomZ3Q7IEhpIExpemhv bmcsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMh PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZaGt PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZyb206IHB3ZTMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZ10NCk9uIEJlaGFsZiBPZiA8 YnI+DQomZ3Q7IGxpemhvbmcuamluQHp0ZS5jb20uY248YnI+DQomZ3Q7IFNlbnQ6IEZyaWRheSwg QXByaWwgMTUsIDIwMTEgMzowNSBQTTxicj4NCiZndDsgVG86IGN1cnRpc0BvY2NuYy5jb207IGFt YWxpc0BnbWFpbC5jb208YnI+DQomZ3Q7IENjOiBwd2UzQGlldGYub3JnPGJyPg0KJmd0OyBTdWJq ZWN0OiBSZTogW1BXRTNdIFBXRTMgd29ya2luZyBncm91cCBwb2xsIGZvciBkcmFmdC1jYW8tcHdl My1tcGxzLTxicj4NCiZndDsgdHAtcHctb3Zlci1iaWRpci1sc3AtMDIudHh0PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEkgYWdyZWUgd2l0aCBDdXJ0aXMsIGFuZCBJIGFs c28gcmFpc2VkIHNpbWlsYXIgY29tbWVudHMgYmVmb3JlIE1JQw0KPGJyPg0KJmd0OyBkdXJpbmcg SUVURjc5IGluIEJlaWppbmcuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBBZGRpdGlvbmFsIG1vcmUg Y29tbWVudHMgYXMgYmVsb3c6IDxicj4NCiZndDsgMS4gc2VjdGlvbiAyLCB3aGF0J3MgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiBmaWd1cmUyIGFuZCBmaWd1cmUzIG9mDQo8YnI+DQomZ3Q7IHRoZSBM U1AgZW5jb2Rpbmc/IElmIHRoZXkgYXJlIHRoZSBzYW1lLCBjYW4gd2UgdXNlIG9ubHkgb25lIHR5 cGUgb2YNCjxicj4NCiZndDsgVExWPyBJbiBkcmFmdC1pZXRmLW1wbHMtdHAtaWRlbnRpZmllcnMt MDQsIHRoZSBub2RlIGlkIGlzIDMyYml0LCB3aHk8YnI+DQomZ3Q7IHRoaXMgZG9jdW1lbnQgZGVm aW5lIG5vZGUtaWQgd2l0aCBJUHY2IGFkZHJlc3M/IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgW01hY2hdICZuYnNwO1RoZSBkaWZmZXJlbmNlIGlzIHRoYXQgb25lIGlzIGZvcg0KSVB2NCBh bmQgdGhlIG90aGVyIGlzIGZvciA8YnI+DQomZ3Q7IElQdjYgc2NlbmFyaW8uICZuYnNwO1RoZSBy ZWFzb24gZm9yIElQdjYgYWRkcmVzcyBiYXNlZCBub2RlLWlkIGlzDQp0aGF0OiA8YnI+DQomZ3Q7 IGZvciBhIE1QTFMvR01QTFMgVEUgTFNQKFJGQzMyMDksIFJGQzM0NzEpLCB0aGUgRXh0ZW5kZWQg VHVubmVsIElELA0KPGJyPg0KJmd0OyBUdW5uZWwgZW5kIHBvaW50IGFkZHJlc3MsIGFuZCBUdW5u ZWwgc2VuZGVyIGFkZHJlc3Mod2hpY2ggYXJlIHVzZWQNCjxicj4NCiZndDsgdG8gaWRlbnRpZnkg YSBzcGVjaWZpYyBURSBMU1ApIGNvdWxkIGJlIElQdjYgYWRkcmVzc2VzLCBhbmQgdGhpcyA8YnI+ DQomZ3Q7IGRyYWZ0IGlzIG5vdCBvbmx5IGZvciBNUExTLVRQIHNjZW5hcmlvLCBidXQgZm9yIG5v cm1hbCBjYXNlcyB3aGVyZQ0KPGJyPg0KJmd0OyByZXF1aXJlIGJvdGggZGlyZWN0aW9ucyBvZiBh IFBXIHRvIGZvbGxvdyBjb25ncnVlbnQgcGF0aC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPltMaXpob25nXSBpZiB5b3UgdXNlIExEUHY2IGFzIHRoZSBzaWduYWxpbmcgcHJvdG9j b2wsDQp0aGVyZSBzaG91bGQgYmUgYWxzbyBhIDMyYml0IHZhbHVlIG9mIExEUC1JRCB0byBiZSB1 c2VkIGFzIG5vZGUgaWQuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IDxicj4NCiZndDsgMi4gU3VnZ2VzdCB0byBub3QgaW5jbHVkZSB1bmlkaXJlY3Rpb25hbCBM U1BzIGluIHNlY3Rpb24gMiwgYW5kIG9ubHk8YnI+DQomZ3Q7IGNvdmVyIHRoZSBjby1yb3V0ZWQg YW5kIGFzc29jaWF0ZWQgTFNQLiBVbmlkaXJlY3Rpb25hbCBMU1BzIHdvcmtzDQo8YnI+DQomZ3Q7 IGZpbmUgY3VycmVudGx5LiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg Jm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtNYWNoXSBUaGUg a2V5IHBvaW50IGlzIGFib3V0IGhvdyB0byBndWFyYW50ZWUNCmEgYmlkaXJlY3Rpb25hbCBQVyB0 bzxicj4NCiZndDsgZm9sbG93IGNvbmdydWVudCBwYXRoKG5vIG1hdHRlciB3aGF0IHRoZSB0dW5u ZWwgaXMgdW5pLSBvciBiaS08YnI+DQomZ3Q7IGRpcmVjdGlvbmFsKS4gSW5jbHVkaW5nIHVuaWRp cmVjdGlvbmFsIExTUHMgaXMgZm9yIHRoZSBjYXNlcyB3aGVyZQ0KPGJyPg0KJmd0OyB0aGVyZSBh cmUgb25seSB1bmlkaXJlY3Rpb25hbCBMU1BzIGF2YWlsYWJsZS4gPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5bTGl6aG9uZ10gZm9yIHVuaWRpcmVjdGlvbmFsIExTUCBjYXNlLCBq dXN0IGxlYXZlDQppdCBhcyBpdCBpcyBub3csIGJ5IGNvbmZpZ3VyYXRpb24gYW5kIGFkbWluaXN0 cmF0aW9uLiBJIHRoaW5rIHRoaXMgaXMgYQ0KcmFyZSBjYXNlLjwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDMuIEkgc3VnZ2VzdCB0byBrZWVw IHRoZSBQVyBzaWduYWxpbmcgaW5kZXBlbmRlbnQgYXMgbXVjaCBhcyA8YnI+DQomZ3Q7IHBvc3Np YmxlLCBhbmQgZWFjaCBlbmQtcG9pbnQganVzdCBzaW1wbHkgaW5kaWNhdGUgaXRzIGxvY2FsbHkg PGJyPg0KJmd0OyBjb25maWd1cmVkIExTUCB0byB0aGUgcmVtb3RlIGVuZC1wb2ludC4gRm9yIHRo ZSBjby1yb3V0ZWQgTFNQLCBlYWNoDQo8YnI+DQomZ3Q7IFBFIGNhbiBjaGVjayBpZiB0aGUgYmlu ZGluZyBpcyBjb3JyZWN0LCBpZiBub3QsIGp1c3QgcmFpc2UgYW4gYWxhcm0uPGJyPg0KJmd0OyBT dWNoIGtpbmQgb2YgYWxhcm0gY2FuIGJlIGNsZWFyZWQgYnkgdGhlIG9wZXJhdG9yIGlmIGl0IGlz IG5vdCBhbg0KaXNzdWUuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgW01hY2hdIERvIHlv dSBtZWFuIHRoYXQgdGhlIFBXIHNpZ25hbGluZyBvZiBlYWNoDQplbmQgc2hvdWxkIGJlIDxicj4N CiZndDsgaW5kZXBlbmRlbnQ/IElmIHNvLCBJTUhPLCB0aGlzIGlzIG5vdCB0aGUgcHJhY3RpY2Ug b2YgdGhlIGV4aXN0aW5nDQo8YnI+DQomZ3Q7IFBXIHNpZ25hbGluZy4gV2l0aCB0aGUgY3VycmVu dCBQVyBzaWduYWxpbmcsIG1hbnkgYXR0cmlidXRlcyBoYXMgdG8NCjxicj4NCiZndDsgYmUgbmVn b3RpYXRlZCB3aGVuIHNldHVwIGEgUFcoZS5nLiwgQUMtSUQsIENXLCBQVyBTdGF0dXMsIFZDQ1Yg dHlwZSw8YnI+DQomZ3Q7IGV0YykgYmV0d2VlbiBQRXMuIFNvLCBiYWNrIHRvIHRoaXMgUFctdG8t TFNQIGJpbmRpbmcsIHRoZSB0dW5uZWwgTFNQPGJyPg0KJmd0OyBpcyBqdXN0IGxpa2UgYW5vdGhl ciBhdHRyaWJ1dGUgdGhhdCByZXF1aXJlIHRvIGJlIG5lZ290aWF0ZWQgYmV0d2Vlbjxicj4NCiZn dDsgdGhlIGJvdGggZW5kcyB3aGVuIHNldHVwIGEgUFcsIGhlbmNlIHRvIG1ha2Ugc3VyZSB0aGF0 IHRoZSBib3RoIDxicj4NCiZndDsgZGlyZWN0aW9ucyBvZiB0aGUgUFcgYXJlIG92ZXIgdGhlIGRl c2lyZWQgY29uZ3J1ZW50IHBhdGhzLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PltMaXpob25nXSBJIG1lYW4gbm90IHRvIG5lZ290aWF0ZWQgdGhlIExTUCBhdXRvbWF0aWNhbGx5 LA0KanVzdCBpbmRpY2F0ZSBhbiBhbGFybSB0byB0aGUgb3BlcmF0b3IgaWYgbm90IGNvbmdydWVu dC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEJlc3QgcmVnYXJkcyw8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgTWFjaDwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMgPGJyPg0KJmd0OyBMaXpob25n IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTWVzc2FnZTogMTxicj4NCiZndDsgJmd0OyBEYXRl OiBXZWQsIDEzIEFwciAyMDExIDE1OjIzOjA0IC0wNDAwPGJyPg0KJmd0OyAmZ3Q7IEZyb206IEN1 cnRpcyBWaWxsYW1pemFyICZsdDtjdXJ0aXNAb2NjbmMuY29tJmd0Ozxicj4NCiZndDsgJmd0OyBU bzogJnF1b3Q7QW5kcmV3IEcuIE1hbGlzJnF1b3Q7ICZsdDthbWFsaXNAZ21haWwuY29tJmd0Ozxi cj4NCiZndDsgJmd0OyBDYzogcHdlM0BpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBS ZTogW1BXRTNdIFBXRTMgd29ya2luZyBncm91cCBwb2xsIGZvcjxicj4NCiZndDsgJmd0OyAmbmJz cDsgJm5ic3A7ZHJhZnQtY2FvLXB3ZTMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wMi50eHQ8 YnI+DQomZ3Q7ICZndDsgTWVzc2FnZS1JRDogJmx0OzIwMTEwNDEzMTkyMy5wM0RKTjRpaDAxODkw NEBoYXJib3Iub3JsZWFucy5vY2NuYy5jb20mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgSW4gbWVzc2FnZSAmbHQ7QkFOTGtUaT1qTVNDSDM3Q2tIaFpm VFkyWm9xOVZfQnhDendAbWFpbC5nbWFpbC5jb20mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZxdW90O0Fu ZHJldyBHLiBNYWxpcyZxdW90OyB3cml0ZXM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgVGhlIGF1dGhvcnMgb2YgZHJhZnQtY2FvLXB3ZTMtbXBscy10cC1w dy1vdmVyLWJpZGlyLWxzcC0wMi50eHQNCmhhdmU8YnI+DQomZ3Q7ICZndDsgJmd0OyBhc2tlZCB0 aGF0IHRoaXMgZHJhZnQgYmUgbWFkZSBhIFBXRTMgd29ya2luZyBncm91cCBkcmFmdC48YnI+DQom Z3Q7ICZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGlzIGVtYWlsIHN0YXJ0 cyBhIHR3byB3ZWVrIHBvbGwsIGNsb3NpbmcgVHVlc2RheSBBcHJpbA0KMjYsIHRvIGhlbHA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBqdWRnZSBjb25zZW5zdXMgb24gdGhpcy48YnI+DQomZ3Q7ICZndDsg Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBQbGVhc2Ugc2VuZCB5b3VyIHJlc3BvbnNl cyB0byB0aGUgUFdFMyBsaXN0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsg Jmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBBbmR5IGFuZCBNYXR0aGV3PGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IE5vIC0gbm90IGluIGl0cyBjdXJyZW50IGZvcm0gLSBtYXliZSB3aXRoIHNvbWUgc2lnbmlm aWNhbnQgaXNzdWVzPGJyPg0KJmd0OyAmZ3Q7IHJlc29sdmVkLjxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBkcmFmdCBhcyBpdCBub3cgc3RhbmRzIGlk ZW50aWZpZXMgdGhlIHVuZGVybHlpbmcgdHVubmVsIGJ5PGJyPg0KJmd0OyAmZ3Q7IGVuZHBvaW50 IElELCAxNiBiaXQgdHVubmVsIGluZGV4LCBhbmQgMTYgYml0IExTUCBJRC4gJm5ic3A7VGhlDQpM U1AgSUQgbWF5PGJyPg0KJmd0OyAmZ3Q7IGJlIGEgdHJhbnNpZW50IHZhbHVlIGluIHRoZSBnZW5l cmFsIE1QTFMgY2FzZS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEluIHRoZSBnZW5l cmFsIE1QTFMgY2FzZSwgdGhlIExTUCBJRCBpcyBhIHRyYW5zaWVudCB2YWx1ZSBhY2NvcmRpbmcN CnRvPGJyPg0KJmd0OyAmZ3Q7IFJGQyAzMjA5IHdoaWxlIHRoZSB0dW5uZWwgSUQgaW4gdGhlIFNF U1NJT04gb2JqZWN0IHJlbWFpbnMgY29uc3RhbnQuPGJyPg0KJmd0OyAmZ3Q7IEZvciBleGFtcGxl LCBpZiBSRkMgMzIwOSBtYWtlLWJlZm9yZS1icmVhayBpcyB1c2VkLCB0aGUgTFNQLUlEDQpjaGFu Z2VzPGJyPg0KJmd0OyAmZ3Q7IGJ1dCB0aGUgRXh0ZW5kZWQgVHVubmVsIElEIHJlbWFpbnMgdGhl IHNhbWUuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTZWUgUkZDIDMyMDkgc2VjdGlv biAyLjUuICZuYnNwO1NwZWNpZmljYWxseSAmcXVvdDtUbyBlZmZlY3QNCmEgcmVyb3V0ZSwgdGhl PGJyPg0KJmd0OyAmZ3Q7IGluZ3Jlc3Mgbm9kZSBwaWNrcyBhIG5ldyBMU1AgSUQgYW5kIGZvcm1z IGEgbmV3IFNFTkRFUl9URU1QTEFURS4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IFRoaXMgYWxzbyBoYXMgdG8gYmUgZG9uZSB0byBpbmNyZWFzZSB0aGUgYmFuZHdpZHRoIG9u IGFuIExTUA0KdXNpbmc8YnI+DQomZ3Q7ICZndDsgbWFrZS1iZWZvcmUtYnJlYWsuPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBbiBMU1AgKG9yIG1vcmUgY29ycmVjdGx5IGEgdHVubmVs KSBtYXkgY2FycnkgbWFueSBQVy4gJm5ic3A7SUYNCmEgUFcgaXM8YnI+DQomZ3Q7ICZndDsgYWRk ZWQsIHRoZSBiYW5kd2lkdGggbWF5IGhhdmUgdG8gYmUgaW5jcmVhc2VkLiAmbmJzcDtJZiB0aGUg YmFuZHdpZHRoDQppczxicj4NCiZndDsgJmd0OyBpbmNyZWFzZWQgdXNpbmcgbWFrZS1iZWZvcmUt Y3JlYWsgc2VtYW50aWNzLCB0aGVuIHRoZSBMU1AtSUQNCmlzPGJyPg0KJmd0OyAmZ3Q7IGNoYW5n ZWQgYW5kIGFsbCBvZiB0aGUgb3RoZXIgUFcgaW4gdGhlIExTUCB3b3VsZCBoYXZlIHRvIGJlIHJl c2lnbmFsZWQ8YnI+DQomZ3Q7ICZndDsgd2l0aCB0aGUgbmV3IExTUC1JRC48YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IEFsc28gaWYgYSB3b3JraW5nIGFuIHByb3RlY3QgTFNQIHdlcmUg c2VsZWN0ZWQgd2l0aCBHTVBMUyBzdHlsZQ0KcGF0aDxicj4NCiZndDsgJmd0OyBwcm90ZWN0aW9u cywgdGhlIExTUC1JRCBkZWxpdmVyaW5nIHRyYWZmaWMgaXMgZGlmZmVyZW50IHdoZW48YnI+DQom Z3Q7ICZndDsgcHJvdGVjdGlvbiBpcyBlbmFibGVkLiAmbmJzcDtUaGlzIGNvdWxkIGJlIGlnbm9y ZWQsIGJ1dCBpZiBzbw0KbmVlZHMgdG8gYmU8YnI+DQomZ3Q7ICZndDsgbWVudGlvbmVkLiAmbmJz cDtJZiBib3RoIHBhdGhzIGdvIGRvd24gYW5kIGEgbmV3IHBhdGggaGFzIHRvDQpiZSBjcmVhdGVk PGJyPg0KJmd0OyAmZ3Q7IHdpdGggYSByZXJvdXRlLCB0aGVuIHRoZSBMU1AtSUQgY2hhbmdlcy4g Jm5ic3A7SWYgYSBiZXR0ZXIgcGF0aA0KYmVjb21lczxicj4NCiZndDsgJmd0OyBhdmFpbGFibGUg b3Igc29tZSBvcHRpbWl6YXRpb24gaXMgbWFkZSBjaGFuZ2luZyB0aGUgd29ya2luZyBwYXRoLA0K dGhlbjxicj4NCiZndDsgJmd0OyBhIG5ldyBMU1AtSUQgaXMgY3JlYXRlZC48YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IEkgd291bGQgcmF0aGVyIHNlZSB0aGVzZSBwcm9ibGVtcyByZXNv bHZlZCAqYmVmb3JlKiBtYWtpbmcgdGhpcw0KYSBXRzxicj4NCiZndDsgJmd0OyBkb2N1bWVudC48 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEN1cnRpczxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjxwcmU+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF Jm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwm bmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz ZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7 bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFp bnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0 dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2Ym bmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZu YnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZu YnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNw O2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNw O3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91 Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJz cDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3Im bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtl eHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhv c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5i c3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7 dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3Bh bSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0034576884257873_=-- From matthew.bocci@alcatel-lucent.com Fri Apr 15 02:52:18 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D1B02E07BF for ; Fri, 15 Apr 2011 02:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.918 X-Spam-Level: X-Spam-Status: No, score=-105.918 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MaYrowEioyE for ; Fri, 15 Apr 2011 02:52:18 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfc.amsl.com (Postfix) with ESMTP id 11BA6E07B2 for ; Fri, 15 Apr 2011 02:52:17 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3F9q9cO008385 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 15 Apr 2011 11:52:16 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.36]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 15 Apr 2011 11:52:13 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Fri, 15 Apr 2011 11:52:11 +0200 Thread-Topic: Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: Acv7UsubNzUXHUv4SBOyP5s8BvEdxA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9CDD3DBCC61matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:52:19 -0000 --_000_C9CDD3DBCC61matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During the Prague PWE3 meeting, there was a discussion on whether draft-kin= i-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. = The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3= /minutes?item=3Dminutes80.html We would like to ask the same question on the list. Please post any comments before April 29th. Regards, Matthew & Andy --_000_C9CDD3DBCC61matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
During the Prague PWE3 m= eeting, there was a discussion on whether draft-kini-pwe3-pkt-encap-ef= ficient-ip-mpls-02.txt should be adopted as a WG draft. The minutes of this= discussion are posted at: http://tools.ietf.org/wg/pwe3/minutes?item=3Dm= inutes80.html

We would like to ask the same qu= estion on the list.

Please post any comments befor= e April 29th.

Regards,

Ma= tthew & Andy

--_000_C9CDD3DBCC61matthewboccialcatellucentcom_-- From tnadeau@lucidvision.com Fri Apr 15 04:54:26 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 428A7E066A for ; Fri, 15 Apr 2011 04:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsg145-24xfH for ; Fri, 15 Apr 2011 04:54:25 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfc.amsl.com (Postfix) with ESMTP id 7D58FE0669 for ; Fri, 15 Apr 2011 04:54:25 -0700 (PDT) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id D23631AF2B6A; Fri, 15 Apr 2011 07:54:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=GB2312 From: Thomas Nadeau In-Reply-To: Date: Fri, 15 Apr 2011 07:54:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <03A2DB5A-1246-46C1-9BBA-C0DAE5E5F371@lucidvision.com> References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> <4DA67FF5.4010802@cisco.com> <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> <4DA71BD8.4070402@cisco.com> To: Mach Chen X-Mailer: Apple Mail (2.1084) Cc: "pwe3@ietf.org" , Yaakov Stein , Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 11:54:26 -0000 On Apr 14, 2011, at 10:36 PM, Mach Chen wrote: > Hi Tom=A3=AC >=20 > One candidate solution is manual configuration, but it is prone to = configuration error and inefficient to manage large number of PWs, and = even worse when do FRR, reroute, protection switching.=20 >=20 > That will be helpful if you could enumerate some other candidates, = then the WG could discuss it more specifically. Take a look at the GMPLS area's bidir LSP solution. --Tom >=20 > Best regards, > Mach >=20 >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of >> Thomas Nadeau >> Sent: Friday, April 15, 2011 2:51 AM >> To: Luca Martini >> Cc: Yaakov Stein; pwe3@ietf.org >> Subject: Re: [PWE3] PWE3 working group poll for >> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt >>=20 >> I'm with luca. As I said earlier I'd like more discussion as to = whether or not >> other existing solutions couldn't be leveraged before we go forward = with this >> one as it is quite under specified. >>=20 >> Tom >>=20 >>=20 >>=20 >> On Apr 14, 2011, at 12:07 PM, Luca Martini = wrote: >>=20 >>> On 04/14/11 09:01, Yaakov Stein wrote: >>>>> You did not answer question #2 ... >>>>> Luca >>>> I answered it by saying that simply forcing placement of a PW into = the >> appropriate LSP >>>> solves the problem. (Meaning that I do not want more complex = PW-specific >> methods.) >>>>=20 >>>> I purposely did not state whether the particular LDP mechanism = proposed is >> optimal or even correct. >>>> This is not a LC, it is just a motion to move this to WG status. >>>>=20 >>>> Y(J)S >>>>=20 >>>>=20 >>> Yes , but historically we have always moved documents to wg status = that >>> where at least 80% there... >>> This document is maybe 10% done. >>> I do not think that there is any argument that we, as the PWE3 WG, = want >>> to work on this problem. >>> Can you suggest something a bit more complete then ? >>>=20 >>> Thanks. >>> Luca >>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>>=20 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 From francesco.fondelli@gmail.com Fri Apr 15 07:19:14 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6FC66E07BB for ; Fri, 15 Apr 2011 07:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vz+kMu5tZLMg for ; Fri, 15 Apr 2011 07:19:13 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 6F1E2E073B for ; Fri, 15 Apr 2011 07:19:13 -0700 (PDT) Received: by wyb29 with SMTP id 29so2570287wyb.31 for ; Fri, 15 Apr 2011 07:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qbEaMKNh13Z113dMMr3AX9p24dA2WHAjqJA4yewpXag=; b=sYi8eV1HJjELGJ016KMsJhdm3njgjSRHFzYrLa3g6J2vejb1wk7dAJXCOu7N4bKTWS XgE2QCr4NP9si9W4EroUP+AJbjFk8Gu6Gtfg7fFM/CuXKj1DPeH5KAOKGaopGzR2pr6j vJlxwn+oqERqUNo04Pw/L3EbaEdyFMXztw7Is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=abBpaQMQEsNhGbOw1rfFj4iDxvWlg3jBDCjnnb/Jx6jp6kWDTqhMoeTsBZLNrBOC79 oh0VVSww2Zb11vtaAtIPhFQ9hBAUePJX21SM4MZBJemil0ZKFN1r9dJpWgHrfaIRCRhw VmRxLEnUuVTsHDoBjw/ZBokQ9vVBjxehgPog0= MIME-Version: 1.0 Received: by 10.216.82.142 with SMTP id o14mr1963111wee.114.1302877152808; Fri, 15 Apr 2011 07:19:12 -0700 (PDT) Received: by 10.216.179.67 with HTTP; Fri, 15 Apr 2011 07:19:12 -0700 (PDT) In-Reply-To: <4DA738A4.8010904@cisco.com> References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com> Date: Fri, 15 Apr 2011 16:19:12 +0200 Message-ID: From: Francesco Fondelli To: Luca Martini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 14:19:14 -0000 Hi, hemmm D'oh :-) --- draft-ietf-ccamp-mpls-tp-cp-framework-06 --- 'Per the MPLS-TP framework [RFC5921], the MPLS-TP control plane is based on GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW signaling' and "How would LDP , which is IP based , even run on an MPLS-TP network ?" just fine ciao FF On Thu, Apr 14, 2011 at 8:10 PM, Luca Martini wrote: > On 04/14/11 00:09, Greg Mirsky wrote: >> Luca, >> you've asked >> How would LDP , which is IP based , even run on an MPLS-TP network ? >> but isn't T-LDP part of MPLS-TP control plane? Control plane assumes >> IP addressing thus use of T-LDP is plausible. >> > No T-LDP is not =A0part of the MPLS-TP control plane. > It could be , but i think folks are more leaning toward GMPLS instead. > > Note that the problem described in this document exists for MPLS. So in > that case LDP is certainly used. But the document appears to only care > about MPLS-TP. > > Luca > > > >> Regards, >> Greg >> >> On Wed, Apr 13, 2011 at 10:27 PM, Luca Martini > > wrote: >> >> =A0 =A0 On 04/13/11 05:49, Andrew G. Malis wrote: >> =A0 =A0 > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt= have >> =A0 =A0 > asked that this draft be made a PWE3 working group draft. >> =A0 =A0 > >> =A0 =A0 > This email starts a two week poll, closing Tuesday April 26, t= o help >> =A0 =A0 > judge consensus on this. >> =A0 =A0 > >> =A0 =A0 > Please send your responses to the PWE3 list. >> =A0 =A0 > >> =A0 =A0 > Thanks, >> =A0 =A0 > Andy and Matthew >> =A0 =A0 > _______________________________________________ >> =A0 =A0 > pwe3 mailing list >> =A0 =A0 > pwe3@ietf.org >> =A0 =A0 > https://www.ietf.org/mailman/listinfo/pwe3 >> =A0 =A0 No, Not in the current form. >> =A0 =A0 Although I agree that this problem is a real problem and needs a >> =A0 =A0 solution, this draft does not have enough information to actuall= y >> =A0 =A0 build >> =A0 =A0 a protocol extension to LDP. >> =A0 =A0 In addition to the problems that Curtis mentions, there is no >> =A0 =A0 description on how to use the proposed TLVs in the LDP message. >> >> =A0 =A0 How would LDP , which is IP based , even run on an MPLS-TP netwo= rk ? >> >> =A0 =A0 PW assume that a PSN tunnel is identified by an IP address, whic= h is >> =A0 =A0 also used as the LDP target session IP address. >> =A0 =A0 How is this possible with an MPLS-TP LSP ? >> >> =A0 =A0 At the minimum we would need some way to identify the IP address >> =A0 =A0 at the >> =A0 =A0 other end of the mpls-tp tunnel. >> >> =A0 =A0 Also I strongly believe that this WG needs to stop attempting to >> =A0 =A0 extend >> =A0 =A0 FEC 128 to have similar functionality as FEC 129. >> =A0 =A0 Just define new extensions for FEC 129 only , unless they are mi= nor , >> =A0 =A0 and can be supported by FEC 128 without changing any existing >> =A0 =A0 procedures... >> >> >> =A0 =A0 Luca >> >> >> =A0 =A0 _______________________________________________ >> =A0 =A0 pwe3 mailing list >> =A0 =A0 pwe3@ietf.org >> =A0 =A0 https://www.ietf.org/mailman/listinfo/pwe3 >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From Adrian.Farrel@huawei.com Fri Apr 15 09:48:37 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C58F130043 for ; Fri, 15 Apr 2011 09:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOeBCwy2pj2Z for ; Fri, 15 Apr 2011 09:48:33 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfc.amsl.com (Postfix) with ESMTP id D760C130044 for ; Fri, 15 Apr 2011 09:48:32 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJP009X4DCWVJ@usaga03-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 11:48:32 -0500 (CDT) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJP006U5DCT8Q@usaga03-in.huawei.com> for pwe3@ietf.org; Fri, 15 Apr 2011 11:48:32 -0500 (CDT) Date: Fri, 15 Apr 2011 17:48:28 +0100 From: Adrian Farrel In-reply-to: <4D9E08FA.7090000@cisco.com> To: stbryant@cisco.com Message-id: <032301cbfb8c$f31209f0$d9361dd0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQFOyl1ThQmdmDZJV0KSRRkc4ENlVgGSEJpOlUzDe+A= References: <031001cbbfb4$ef961500$cec23f00$@huawei.com> <4D9E08FA.7090000@cisco.com> Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org, pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-fat-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:48:37 -0000 Hi Stewart, Thanks for this. > Here are the actions I have taken/reply to your points. > > Lets see where we agree and if we are close to agreement I will > upload a new version > > > > I found the use of language a little relaxed. You use the same word, > > "label", to refer to a label value and to an entry in the shim header. > > It would probably be helpful to use the term "label" to refer to the > > label itself, and "label entry" to indicate the label, TC bits, and TTL. > > I have changed this to use label for the value and label stack entry (LSE) > as per RFC3032 for the entry in the label stack. > > Hopefully I have caught all instances and disposed of them correctly. OK > > It seems to me that the description of what can be in the additional > > label entry is conflicted. > > > > On receipt of the > > pseudowire packet at the egress PE (which knows this additional label > > is present) the flow label is discarded without processing. > > > > This means that the label will not be used for any purpose in the packet > > processing except in the DPI of ECMP hashing. > > > > The flow label can never become the top label in > > normal operation > > > > That is, you will never pop a label to discover the flow label except at > > the egress where it is expected and ignored. > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > protocol. > > > > And why is that restriction required given the two previous points? > > MPLS has an architectural assumption that a label value with a reserved > value has special meaning - always -. > > Its safer to always assume that to be the case even if we "can get away > with it." Well, OK. I don't object to this reason. I was only probing because it seems to me that the FAT label is not a label at all :-) > > The flow label can never become the top label in > > normal operation, and hence the TTL in the flow label is never used > > to determine whether the packet should be discarded due to TTL > > expiry. Therefore there are no lower restrictions on the TTL value. > > > > Why do you call out "lower"? How about saying "there are no restrictions" > > Changed. OK > There was some discussion in the early PW days with, as I recall, > Eric Rosen convincing me that bad things would happen in some > implementations when a PW had TTL=1. This is a carry over from that. Right. I can conceive of implementations that do TTL decrement and check before they do label examination. Thus, at an egress when the PW label is popped and the FAT label is uncovered, the TTL might have been examined. But this is not an issue since all FAT label processing at an egress is new function. > > The use of the TC bits (formerly known as the EXP bits) in the flow > > label is outside the scope of this document. Unless otherwise agreed > > by the ingress and egress PEs these bits MUST be set to zero by the > > ingress PE and MUST be ignored by the egress PE. > > > > "Out of scope" seems to be different from the subsequent statement about > > how he TC field must be treated. I am also not clear why the TTL > > discussion is different from the TC discussion. > > Ah, there was a lot of discussion about this is the WG, with some > proposals to use them for signaling of state along the LSP. I was > pushing back on this on MPLS architectural grounds and the text > here was the result of some discussion in WG LC. I hear you when you say that the WG consensus asked you to add text "against your better judgement" :-0 But the text you have added is conflicted. Can I suggest... This document does not define a use for the TC bits (formerly known as the EXP bits) in the flow label. Future documents may define a use for these bits, therefore implementations conforming to this specification MUST set the TC bits to zero at the ingress and MUST ignore them at the egress. > > Document title: please spell out PSN > > done - but note that PSN is a well known term in PWE3 Hmmm. Since I wrote this, PSN has been awarded an asterisk in http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > Abstract: yuck! :-O > > > > Suggestion... > > > > OLD > > Where the payload carried over a pseudowire carries a number of > > identifiable flows it can in some circumstances be desirable to carry > > those flows over the equal cost multiple paths (ECMPs) that exist in > > the packet switched network. Most forwarding engines are able to > > hash based on label stacks and use this to balance flows over ECMPs. > > This draft describes a method of identifying the flows, or flow > > groups, to the label switched routers by including an additional > > label in the label stack. > > NEW > > Where the payload of a pseudowire comprises a number of distinct > > flows, it can be desirable to carry those flows over the equal cost > > multiple paths (ECMPs) that exist in the packet switched network. > > Most forwarding engines are able to hash based on MPLS label stacks > > and use this mechanism to balance MPLS flows over ECMPs. > > > > This document describes a method of identifying the flows, or flow > > groups, within pseudowires such that Label Switching Routers can > > balance flows at a finer granularity than individual pseudowires. > > The mechanism uses an additional label in the MPLS label stack. > > END > > done Thanks > > Try to avoid "ECMP paths" (or ECMPP as we call them ;-) > > I use ECMP and ECMPs for the plural OK > > Section 1 para 1 > > > > the use of ECMP paths for is known to be > > beneficial (and not harmful) to the operation of the PW. > > > > ?? > > The (and not harmful) was a heads up to the reader that in > some cases it is harmful, and that it is assumed that the > reader would know when this was the case and use the > mechanism. > > We could delete the parenthetical remark, but it is harmless > other than perhaps as an offense to the English. It was "for is known" that puzzled me. > > Throughout... > > > > The plural of "pseudowire" is "pseudowires", not "pseudowire's". > > You may safely use "PWs" in your document. > > > > You have a number of other plurals formed as apostrophe-s. Please > > search for "'s" and fix as necessary. > > Done Thanks > > Section 1 > > > > Some pseudowires are used to transport large volumes of IP traffic > > between routers at two locations. > > > > I assume that, for some definition of "location" this is also true for > > routers at the same location. So how about... > > > > Some pseudowires are used to transport large volumes of IP traffic > > between routers. > > Indeed OK > > Section 1 > > > > Such pseudowire's do not require strict ordering to > > be preserved between packets of the pseudowire. They only require > > ordering to be preserved within the context of each individual > > transported IP flow. > > > > I see where this is going, but the first sentence is massively more > > relaxed than the second! How about turning it around... > > > > Such pseudowires only require packet ordering to be preserved within > > the context of each individual transported IP flow. They do not > > require packet ordering to be preserved between all packets of the > > across all IP flows within the pseudowire. > > Changed to > These PWs only require packet ordering to be preserved within > the context of each individual transported IP flow. They do not > require packet ordering to be preserved between all packets of > across all IP flows within the pseudowire. s/of across/of/ or s/of across/across/ > > Section 1 > > > > Some operators have requested the ability to > > explicitly configure such a pseudowire to leverage the availability > > of multiple ECMP paths. > > > > I wish you did not feel the need to include this assertion. Why not just > > get on and describe the benefits (as you do in the next sentence). > > > > Currently it really sounds like this is an idea that is strongly opposed > > and you are trying to justify it to the rest of the community. In fact, > > the community will judge according to the technical merits. > > Traditionally this is an an anathema in PWs which try hard to look like > a "wire" and when we first mooted the idea we got pushback from the > ITU-T MPLS-TP community. gawd blessem > The reason that we say "Some operators" is because this was an > operator initiated, not a vendor initiated project. > > I have changed this to > > OLD > Some operators have requested the ability to explicitly configure such a > PW to leverage the availability of multiple ECMPs. This allows for > better capacity planning as the statistical multiplexing of a larger > number of smaller flows is more efficient than with a smaller set of > larger flows. Although Ethernet is used as an example above, the > mechanisms described in this draft are general mechanisms that may be > applied to any PW type in which there are identifiable flows, and in > which there is no requirement to preserve the order between those flows. > NEW > The ability to explicitly configure such a PW to leverage the > availability of multiple ECMPs allows for better capacity planning as > the statistical multiplexing of a larger number of smaller flows is more > efficient than with a smaller set of larger flows. Although Ethernet is > used as an example above, the mechanisms described in this draft are > general mechanisms that may be applied to any PW type in which there are > identifiable flows, and in which there is no requirement to preserve the > order between those flows. > END Perfect (except see below) > > Please don't use the word "draft" in the text as it creates work for the > > RFC Editor and might get missed in the publication process. Obviously, by > > the time this is published as an RFC it will no longer be a draft. Best > > thing to do is search and replace "draft" with "document". > > > Done. It was an error. Tutorial not required :) Hmmm. Except... See the previous paragraph that you suggested }:-Z > > Section 1 > > > > Typically, forwarding hardware can deduce that an IP payload is being > > directly carried by an MPLS label stack, and is capable of looking at > > some fields in packets to construct hash buckets for conversations or > > flows. However, an intermediate node has no information on the type > > pseudowire being carried in the packet. > > > > Is the first sentence relevant to this document? I don't think so, but if > > you believe it is, I think you will need to add a statement about how > > this deduction is made. > > I have changed the second sentence to > > " However, when the MPLS payload is a PW, an intermediate node has..." > > The point of this is to note that routers have been in the habit of doing > DPI and ECMP on MPLS LSPs based on deducing that the packet is an IP > packet, but PWs provide information hiding that prevents this. > > I am not sure that a tutorial on how they do it is appropriate, particularly > as it's not strictly in conformance with the MPLS architecture, but > noting that de facto it happens to readers not familiar with LSR design > is I believe useful. I can live with it. > > Section 1 > > > > In the case of a pseudowire emulating > > a high bandwidth trunk, the granularity obtained by hashing the > > default label stack is inadequate for satisfactory load-balancing. > > > > Is "the default label stack" intended to convey some special meaning? > > I suspect you are trying to say "the label stack that would be > > constructed if this I-D hasn't been implemented". You will simply have > > to go down the path of saying... > > > > In the case of a pseudowire emulating > > a high bandwidth trunk, the granularity obtained by hashing the > > label stack is inadequate for satisfactory load-balancing. > > Changed OK > > Section 1 > > > > This draft proposes a method to introduce granularity on the hashing > > of traffic running over pseudowires by introducing an additional > > label, chosen by the ingress node, and placed at the bottom of the > > label stack. > > > > As above: s/draft/document/ > > Also, please be less timid. Your document defines a method. > > Changed > > Of course individual-00 did only propose it. Yup > > Section 1.1 > > > > s/1.1. ECMP in Label Switched Routers/1.1. ECMP in Label Switching Routers/ > > > > s/Label switched routers/Label Switching Routers (LSRs)/ > > None Or maybe "Done" > > Section 1.1 > > > > been proposed [I-D.kompella-mpls-entropy-label], however that is > > > > Reading would be significantly enhanced by forward reference to section > > 8. > > I put in the forward reference and removed the OOS wich seemed a bit > strange given we have a section introducing the issue. OK > > Section 3 > > > > It is recommended > > > > RECOMMENDED ? > > Done OK > > Section 3 > > > > It is recommended that the method chosen to > > generate the load balancing labels introduces a high degree of > > entropy in their values, to maximise the entropy presented to the > > ECMP path selection mechanism in the LSRs in the PSN, and hence > > distribute the flows as evenly as possible over the available PSN > > ECMP paths. > > > > It isn't clear to me that entropy is necessarily a good thing. It > > depends on the hash algorithm, doesn't it. > > Entropy is a good thing (TM) in this application .. and the quality of the > entropy is a function of the quality of the hash algorithm. Maybe the bad hash algorithms are so bad that we don't need to pursue this. But you could also add (not mandatory to add): "Although this document does not attempt to specify any hash algorithms, it is suggested that any such algorithm should be based on the assumption that there will be a high degree of entropy in the values assigned to the load balancing labels." > > Figure 2 > > > > Those four-octet things are not actually labels are they. > > The fig now says LSE > > | Flow LSE | 4 octets > +---------------------------+ > | PW LSE | 4 octets > +---------------------------+ > | MPLS Tunnel LSE (s) | n*4 octets (four octets per LSE) > > The rest are not labels OK > > What is the purpose of the T bit? Why would an implementation go to > > the trouble of including the flow-label TLV only to set T=0? > > It may wish to send T=0, R=1, i.e. I do not propose to > send a FAT label, but I can process (discard) one if you send it to me. I see that, but are you suggesting that an LSR will change the value of the R bit it sends depending on the value of the T bit it receives? Well, it doesn't matter. This is just me saying "I wouldn't have designed it like that." Nothing is broken, and there are plenty of spare bits. No need to change anything. > > Section 4 > > > > If PWE3 signalling [RFC4447] is not in use for a pseudowire, then > > whether the flow label is used MUST be identically provisioned in > > both PEs at the pseudowire endpoints. If there is no provisioning > > support for this option, the default behaviour is not to include the > > flow label. > > > > This paragraph is misplaced in the section on signaling. Please put it > > elsewhere. > > Added new section Static Pseudowires and moved the text there. Good > > I am not convinced by the 2119 language in this paragraph since an > > implementation cannot control the behavior. > > It could be interpreted as an instruction to the NMS system and > therefore a mandatory implementation instruction at that level. OK. Let it go. > > Section 4 > > > > Do you not think that you should say that the new sub-TLV is carried in > > the Interface Parameters TLV, and on which messages? > > The text is consistent with the other PW definitions and the reader > has already been referred to RFC4447. Well, I was confused :-) I would: OLD When using the signalling procedures in [RFC4447], a Pseudowire Interface Parameter Flow Label Sub-TLV (FL Sub-TLV) type is used to synchronise the flow label states between the ingress and egress PEs. NEW When using the signalling procedures in [RFC4447], a new Pseudowire Interface Parameter Sub-TLV, the Flow Label Sub-TLV (FL Sub-TLV), is used to synchronise the flow label states between the ingress and egress PEs. END That may look like a small change, but it would have made reading a lot easier. > > Section 4.1 > > > > o FL is the flow label sub-TLV identifier assigned by IANA. > > > > Can you either put in a [TBD] flag so the RFC Editor will catch this, > > or a forward pointer to section 10. > > I put in the value 0x17 since it's already been allocated. > > I change the IANA section to say: > > "IANA is requested to amend the PW Interface Parameters Sub-TLV type > Registry value 0x17 (Flow Label indicator) to refer to this RFC." OK about putting "17" in section 4.1 IANA discussed further under section 10. > > Section 5 > > > > Consider an egress that doesn't support flow label, but previous S-PEs > > that do. In this case you are content to throw the baby out with the > > bath water? > > The fix would require a change to the S-PE behavior to remove > the FAT label. That is an operation that is more complex than a > simple label swap and therefore undesirable. OK. Just checking that there is no desire to be able to do ECMP on a MSPW in this case. > > Section 6 > > > > We believe that this > > problem is addressed by the following two methods > > > > I would like you to be more definitive, please. > > How about > > This problem is mitigated by the following two considerations: Not really :-( The second bulletin particular is not a mitigation at all. See below for suggested text. > > But, that said, the subsequent bullets do not provide methods of > > addressing OAM in this case. Rather, the text attempts to say why > > the problem is not important. In my opinion it fails since, although > > ECMP is out of scope for MPLS-TP, a user has reasonable expectations > > that some of the flows on their PW will not be wiped out for the IGP > > convergence period, when (for example) rapid notification followed > > by change of the flow label could cause the traffic to be balanced > > differently and avoid the failure, > > I have added > Note that this period may be reduced if a fast re-route or fast > convergence technology is deployed in the network [RFC4090],[RFC5286]. OK > > or when a partial failure of a PW > > could trigger a switch to a different PW. > > Well there are two problems here: > > 1) The whole point is that it's difficult to constantly monitor > all paths. > > 2) It's not clear that the new PW would be diverse when the FL is > taken into a/c. So what you are saying is that "OAM cannot be used under all circumstances to verify that a pseudowire is fully functional" I think we can handle this through: OLD Where it is required to verify that a pseudowire is fully functional for all flows, VCCV [RFC5085] connection verification message MUST be sent over each ECMP path to the pseudowire egress PE. This problem is difficult to solve and scales poorly. We believe that this problem is addressed by the following two methods: 1. If a failure occurs within the PSN, this failure will normally be detected by the PSN's Interior Gateway protocol (IGP) link/node failure detection mechanism (loss of light, bidirectional forwarding detection [RFC5880] or IGP hello detection), and the IGP convergence will naturally modify the ECMP set of network paths between the Ingress and Egress PE's. Hence the PW is only impacted during the normal IGP convergence time. 2. If the failure is related to the individual corruption of an Label Forwarding Information database (LFIB) entry in a router, then only the network path using that specific entry is impacted. If the PW is load balanced over multiple network paths, then this failure can only be detected if, by chance, the transported OAM flow is mapped onto the impacted network path, or all paths are tested. This type of error may be better solved be solved by other means such as LSP self test [I-D.ietf-mpls-lsr-self-test]. YOURS Where it is required to verify that a pseudowire is fully functional for all flows, VCCV [RFC5085] connection verification message MUST be sent over each ECMP path to the pseudowire egress PE. This problem is difficult to solve and scales poorly. This problem is mitigated by the following two considerations: 1. If a failure occurs within the PSN, this failure will normally be detected by the PSN's Interior Gateway protocol (IGP) link/node failure detection mechanism (loss of light, bidirectional forwarding detection [RFC5880] or IGP hello detection), and the IGP convergence will naturally modify the ECMP set of network paths between the Ingress and Egress PE's. Hence the PW is only impacted during the normal IGP convergence time. Note that this period may be reduced if a fast re-route or fast convergence technology is deployed in the network [RFC4090],[RFC5286]. 2. If the failure is related to the individual corruption of an Label Forwarding Information database (LFIB) entry in a router, then only the network path using that specific entry is impacted. If the PW is load balanced over multiple network paths, then this failure can only be detected if, by chance, the transported OAM flow is mapped onto the impacted network path, or all paths are tested. This type of error may be better solved be solved by other means such as an LSP self test technology. NEW Where it is required to verify that a pseudowire is fully functional for all flows, VCCV [RFC5085] connection verification message MUST be sent over each ECMP path to the pseudowire egress PE. This solution may be difficult to achieve and scales poorly. Under these circumstances, it may be sufficient to send VCCV messages using any load balance pseudowire path because if a failure occurs within the PSN the failure will normally be detected and repaired by the PSN. That is, the PSN's Interior Gateway protocol (IGP) link/node failure detection mechanism (loss of light, bidirectional forwarding detection [RFC5880] or IGP hello detection), and the IGP convergence will naturally modify the ECMP set of network paths between the Ingress and Egress PE's. Hence the PW is only impacted during the normal IGP convergence time. Note that this period may be reduced if a fast re-route or fast convergence technology is deployed in the network [RFC4090],[RFC5286]. If the failure is related to the individual corruption of a Label Forwarding Information database (LFIB) entry in a router, then only the network path using that specific entry is impacted. If the PW is load balanced over multiple network paths, then this failure can only be detected if, by chance, the transported OAM flow is mapped onto the impacted network path, or if all paths are tested. Since testing all paths may present problems as noted above, other mechanisms to detect this type of error may need to be developed, such as an LSP self test technology. END > > s/Figure 4: Use of Router Alert LAbel/Figure 4: Use of Router Alert Label/ ?? > > Figure 4 > > > > Shouldn't "payload" actually read "VCCV message"? ?? > > Shouldn't you include the warning (from 5085) that inserting the router > > alert label probably breaks the ECMP hashing such that the packets will > > go another way. > > Added > > Note that, depending on the number of labels hashed by the LSR, the > inclusion of the Router Alert label may cause the OAM packet to be load > balanced to a different path from that taken by the data packets with > identical Flow and PW labels. Great > > How funny that labels that are conventionally described as being "above" > > on the label stack are shown in your diagrams as below. > > Yes, but the mistake is consistent though out all PWE3 docs going back > to RFC3985. Oooh, quick. Raise an erratum ;-) > > Section 7 > > > > s/The methods describe/The methods described/ > > s/The method proposed/The method defined/ > > s/in those cased/in those cases/ > > s/The methods describe/The methods described/ > Can't find it accidental duplication > > Section 7 > > > > order is not maintained amongst packets of different > > flows. > > > > I know what you mean, but you have actually said something subtly > > different. > > OLD > order is not maintained amongst packets of different flows > NEW > order is no longer maintained for all packets sent over the PW. OK > > Section 7 > > > > Ethernet may have this property, and for that reason > > this document focuses on Ethernet. Applications for other high- > > access-bandwidth PW's (e.g. Fibre Channel) may be defined in the > > future. > > > > Does the document really *focus* on Ethernet? There are a couple of > > places where Ethernet is cited as an example (but where the text says > > equally applicable, blah, blah) and two paragraphs a little below this > > statement that say "the Ethernet PW". Nothing else. > > > > Can't you generalise? > > Section 1 says > > Although Ethernet is used as an example above, the mechanisms described > in this document are general mechanisms that may be applied to any PW > type in which there are identifiable flows, and in which there is no > requirement to preserve the order between those flows. > > I have removed that text and added this note to the bottom of Section 1 > > NOTE: Although Ethernet is frequently referenced as a use case in this > RFC, the mechanisms described in this document are general mechanisms > that may be applied to any PW type in which there are identifiable > flows, and in which there is no requirement to preserve the order > between those flows. Good > > Section 7 > > > > If sequence number support is required this > > mechanism is not applicable. > > > > It's stronger than that, isn't it? > > You need to prohibit the mechanism. > > But shouldn't you also prohibit ECMP? > > Now says: > If sequence number support is required the flow label mechanism MUST NOT > be used. Perfect > > Section 7 > > > > Where it is known that the traffic carried by the Ethernet pseudowire > > is IP the method of identifying the flows are well known and can be > > applied. Such methods typically include hashing on the source and > > destination addresses, the protocol ID and higher-layer flow- > > dependent fields such as TCP/UDP ports, L2TPv3 Session ID's etc. > > > > Either s/method/methods/ or s/are/is/ > > done OK > > If these methods are so well known, you will have no difficulty in > > supplying a reference or two. > > I am fairly sure that there is no IETF reference to this. It something > that all the vendors do (differently), but there has always been strong > resistance to the publication of a standard. > > > > I think you have mixed the method of identifying the flows with the > > method of hashing the flows into buckets. > > The text now says: > > Where it is known that the traffic carried by the Ethernet PW is IP the > method of identifying the flows and mapping them to an ECMP are well > known and can be applied. Such methods are typically include hashing on > the source and destination addresses, the protocol ID and higher-layer > flow-dependent fields such as TCP/UDP ports, L2TPv3 Session ID's etc. Is OK, although I would prefer to remove the "well known" bit. NEW Where it is known that the traffic carried by the Ethernet PW is IP the flows can be identified and mapped to an ECMP. Such methods typically include hashing on the source and destination addresses, the protocol ID and higher-layer flow-dependent fields such as TCP/UDP ports, L2TPv3 Session ID's etc. END Not required that you take this change, but s/are typically/typically/ > > Section 7.1 > > > > In the ECMP case and the link bundling case the NSP may attempt to > > take bandwidth into consideration when allocating groups of flows to > > a common path. That is permitted, but it must be borne in mind that > > the semantics of a label stack entry (LSE) as defined by [RFC3032] > > cannot be modified, the value of the flow label cannot be modified at > > any point on the LSP, and the interpretation of bit patterns in, or > > values of, the flow label by an LSR are undefined. > > > > If you have something to say, you should say it. Otherwise your paragraph > > is lost on your readers. > > > I think you are trying to say "There is no mechanism currently defined > > to indicate the bandwidths in use by specific flows using the fields of > > the MPLS shim header. Furthermore, since the semantics of the MPLS shim > > header are fully defined in [RFC3032] and [RFC5462], those fields cannot > > be assigned semantics to carry this information. This document does not > > define any semantic for use in the TTL or TC fields of the label entry > > that carries the flow label, but requires that the flow label itself > > be selected with a high degree of entropy suggesting that the label > > value should not be overloaded with additional meaning in any subsequent > > specification." > > OK works for me, but the WG should note the change of wording. Yup > > Section 7.1 > > > > A different type of load balancing is the desire to carry a > > pseudowire over a set of PSN links in which the bandwidth of members > > of the link set is less than the bandwidth of the pseudowire. This > > problem is addressed in [I-D.stein-pwe3-pwbonding]. Such a mechanism > > can be considered complementary to this mechanism. > > > > The referenced I-D seems to be dead. I'm not quite sure why you need to > > reference it here. How about just taking out the paragraph? > > It's in there as a result of WG discussion If the WG intends to adopt the I-D and run with it, that is fine (provided in-charter, and they actually do it). Otherwise the reference is a problem. Maybe the sentence containing the reference can be removed? > > Section 7.2 appears to describe exactly the link bundling case that you > > discussed in section 7. I have recently noticed considerable confusion > > between link bundles and LAG and suggest you restrict LAG to be a data > > link function that is below the level of an "interface" in the IP/MPLS > > world. That does not mean that an individual node, knowing (by > > unspecified means) that it is about to use an interface that is > > constructed from a LAG, can't hash the traffic across the LAG. > > > > Ultimately, you should consider ECMP (i.e. multiple IGP paths) where > > each hop on each path may be made a link bundle, and where each > > component link of a bundle may be supported by LAG. > > > > Can you go back and check that you have used the language precisely. > > The text was added as a result of WG discussion where it was proposed > that LAG might use the FL as a key in member selection. Unclear whether you are saying that you think the language *is* precise, or that you have adopted text generated in the WG and are stuck with it. In the former case, I'm done. in the latter case my question is extended to the WG. [Perhaps we will need to extract a couple of questions from this I-D to go to the WG in a separate thread?] > > Section 7.4 > > > > If the payload on a PW is made of a single inner flow (i.e. an > > encrypted connection between two routers), or the flow identifiers > > are too deeply buried in the packet, then the functionality described > > in this document does not give any benefits, though neither does it > > cause harm relative to the existing situation. > > > > Is that s/i.e./e.g./? > > Changed OK > > "Too deeply buried" meaning "If the NSP cannot access sufficient > > information to distinguish flows, perhaps because the protocol stack > > is too deep for its capabilities..."? > > > > Is the statement about "no harm" necessary? After all, the mechanism > > will simply not be used in this case. > > Text was added as a result of WG discussion on benefits and usage of the > mechanism. OK. I still think some explanation of "too deeply buried" would be beneficial. > > Section 7.4 > > > > The most common case > > where a single flow dominated the traffic on a PW is when it is used > > to transport enterprise traffic. Enterprise traffic may well consist > > of a large single TCP flows, or encrypted flows that cannot be > > handled by the methods described in this document. > > > > s/dominated/dominates/ > > yes OK > > s/a large single TCP flows/large TCP flows/ > > Again this was WG agreed text Well, really. Does the WG insist on publishing stuff that is not in English? What will happen during RFC Editor processing? Please select from: - a single, large TCP flow - large TCP flows Ask the WG if you feel the need, although to me it is a typo that has introduced ambiguity. > > Note that this second half of the paragraph is a non-sequitur from the > > first half. You probably need to wrap the whole paragraph with a thought > > about single or dominant large flows. > > That is the title of the section Good point. > > Section 7.4 > > > > 1. The operator can do nothing and the system will work as it does > > without the flow label. > > > > s/can do nothing/can choose to do nothing/ > > done OK > > Section 7.4 > > > > An operator has six options under these circumstances: > > > > :-) You tease! > > > > There are only five listed. > > :) I wonder if I deleted one at some time in the past OK > > Section 7.4 > > > > s/an single flow/a single flow/ > > done OK > > Section 7.4 > > > > 5. The operator could configure the ingress to assign a label of > > special significance (such as a reserved label) to all high > > bandwidth flows so that some other action (not specified in this > > document) could be taken on the flow. > > > > I think you need to delete this as it contradicts two specific > > statements made elsewhere... > > > > 1. MUST NOT use a reserved label as the flow label > > 2. MUST NOT assign semantics to the flow label > > I have deleted (such as a reserved label). > > This was added as a result of WG discussion. I think that the idea > was to use a label from the per platform space. OK. Need to check back with the WG? > > 8. Applicability to MPLS > > > > While I see where you are coming from, I must point out that the whole > > of your document is about MPLS. Could you come up with a better title? > > Now says > > Applicability to MPLS LSPs OK > > Section 9 > > > > The ingress PE SHOULD take steps to ensure that the load-balance > > label is not used as a covert channel. > > > > Again, you are saying something between the lines :-( > No, just warning that a badly implemented hash could have side effects. > > Since the ingress PE allocates the label (isn't it called the flow label > > not the load-balance label?) the "SHOULD take steps" is very odd! And > > why is this a security requirement? How would security be compromised? > Yes - LB label was an older name for it. > > I can take it out, or we can leave it to SECdir to advise. I have been looking at covert channels a bit recently (not my favourite) and the problem with requesting that the ingress PE take steps to avoid the label being used as a covert channel is that there is not much that can be done by the ingress to protect the label being changed within the network. The same arguments will apply to the TTL and TC of the flow label. The TTL and TC can be enforced by the *egress* mandating that the received packets all have specific TTL and TC settings in the flow label. The flow label value can only be enforced by the ingress and egress negotiating which flow label values are in use. Maybe: NEW The flow label value and the TTL and TC of the flow label LSE provide the potential for the creation of a covert channel. An egress PE MAY monitor the values received and report fluctuations as potential symptoms of an attack. END > > Section 9 > > > > This document has signaling extensions in it, so you should reference > > RFC 4447 from this section. You should also reference RFC 5920. > Added: > The security considerations in [RFC5920] also apply. OK > > Section 9 > > > > The flow label TTL should therefore never be considered > > by the forwarder, and hence SHOULD be set to a value of 1. This will > > prevent the packet being inadvertently forwarded based on the value > > of the flow label. Note that this may be a departure from > > considerations that apply to the general MPLS case. > > > > But you have previously said that the flow label TTL is never used to > > discard a packet based on TTL expiry [section 1.2]. You need to make > > your mind up. And, if there are rules you wish to apply for setting > > fields, you need to put them in the main part of the protocol spec, > > not buried in the security section. > > > > And (while I'm at it) how is this a security feature? > > The point is that there is no protocol reason for it to have any particular > value. > > There is a security reason (stopping the packet going some bad place) > for stopping it going anywhere, but this is only a recommendation not > a requirement. > > > Oh, and another thing... > > > > The sequence of your logic is broken. It would be fine to say: > > If the flow label is inadvertently examined as if it were a normal > > label, the packet might be forwarded. This can be prevented by setting > > the associated TTL to 1. > > But I don't think that "should never be considered" leads to "should be > > set to 1". > > > > Finally, the note at the end is at best unhelpful. What are you trying > > to say, and why? > > The text now says: > > The flow LSE is at the bottom of label stack, therefore, even when > penultimate hop popping is employed, it will always be will preceded by > the PW label on arrival at the PE. If the flow label is inadvertently > examined as if it were a normal label, the packet might be forwarded. > This can be prevented by setting the associated TTL to 1. Note that this > may be a departure from considerations that apply to the general MPLS case. Works well. > > Section 10 > > > > Please change this text to reference early allocation that has been > > made for you. Note that the value 17 has NOT been assigned (although > > the value 0x17 has). > > Changed - it's actually ER - and has been allocated. So it would be helpful to tell IANA in this section that they have already made an allocation using whatever policy. Cheers, Adrian From Internet-Drafts@ietf.org Fri Apr 15 10:45:11 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 46205E0811; Fri, 15 Apr 2011 10:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.629 X-Spam-Level: X-Spam-Status: No, score=-102.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-tyx+jAM5gV; Fri, 15 Apr 2011 10:45:06 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C1EDE0801; Fri, 15 Apr 2011 10:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110415174502.28931.24336.idtracker@ietfc.amsl.com> Date: Fri, 15 Apr 2011 10:45:02 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-cbit-negotiation-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:45:11 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Pseudowire Control Word Negotiation Mechanism Update Author(s) : V. Manral, et al Filename : draft-ietf-pwe3-cbit-negotiation-00.txt Pages : 10 Date : 2011-04-15 This document describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, a message exchanging mechanism is introduced to solve this control word negotiation issue. This document is to update [RFC4447] control word negotiation mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cbit-negotiation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pwe3-cbit-negotiation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-15104319.I-D@ietf.org> --NextPart-- From mach.chen@huawei.com Fri Apr 15 11:06:38 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15BAAE0835 for ; Fri, 15 Apr 2011 11:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.206 X-Spam-Level: X-Spam-Status: No, score=0.206 tagged_above=-999 required=5 tests=[AWL=-6.243, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15v5dXrcu0YE for ; Fri, 15 Apr 2011 11:06:34 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 75456E0772 for ; Fri, 15 Apr 2011 11:06:33 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJP00815GYVM3@szxga05-in.huawei.com> for pwe3@ietf.org; Sat, 16 Apr 2011 02:06:31 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJP00LAXGYUHD@szxga05-in.huawei.com> for pwe3@ietf.org; Sat, 16 Apr 2011 02:06:31 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 16 Apr 2011 02:06:24 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Sat, 16 Apr 2011 02:06:29 +0800 Date: Fri, 15 Apr 2011 18:06:02 +0000 From: Mach Chen In-reply-to: <03A2DB5A-1246-46C1-9BBA-C0DAE5E5F371@lucidvision.com> X-Originating-IP: [172.24.2.40] To: Thomas Nadeau Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL+mF7CC0OX2NXl0iWklzLN/QjE5Rc7rWAgAASogCAAC2IAIAA7KeggAAxVACAAOZHrA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <07F7D7DED63154409F13298786A2ADC903D27E3F@EXRAD5.ad.rad.co.il> <4DA67FF5.4010802@cisco.com> <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> <4DA71BD8.4070402@cisco.com> <03A2DB5A-1246-46C1-9BBA-C0DAE5E5F371@lucidvision.com> Cc: Luca Martini , Yaakov Stein , "pwe3@ietf.org" Subject: [PWE3] =?gb2312?b?tPC4tDogIFBXRTMgd29ya2luZyBncm91cAlwb2xsCWZv?= =?gb2312?b?cglkcmFmdC1jYW8tcHdlMy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTAy?= =?gb2312?b?LnR4dA==?= X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 18:06:38 -0000 VG9tLA0KDQpJIGhhdmUgZmVlbGluZyB0aGF0IHlvdSBtYXkgbm90IHJlYWxseSB1bmRlcnN0YW5k IHRoZSBwcm9ibGVtIHRoYXQgdGhlIGRyYWZ0IHRyaWVzIHRvIHJlc29sdmUuIA0KDQpUaGUgcHJv YmxlbSBpcyB0aGF0IHRoZSBjdXJyZW50IG1lY2hhbmlzbSBjYW4gbm90IGd1YXJhbnRlZSBib3Ro IGRpcmVjdGlvbnMgb2YgYSAgUFcgc2VsZWN0IGFuZCBiaW5kIHRvIGNvbmdydWVudCB0dW5uZWwg IExTUCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBMU1BzIGV4aXN0cyBiZXR3ZWVuIHRoZSB0d28g UEVzLCBldmVuIGlmIHRoZXJlIGFyZSBHTVBMUyBiaWRpciBMU1BzIGV4aXN0LiAgVGhpcyBpcyBi ZWNhdXNlIHRoYXQgZWFjaCBlbmQgb2YgdGhlIFBXIHNlbGVjdHMgYW5kIGJpbmRzIHRvIFBTTiB0 dW5uZWwgTFNQIGluZGVwZW5kZW50bHkuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2ggIA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBwd2UzLWJvdW5jZXNA aWV0Zi5vcmcgW3B3ZTMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBUaG9tYXMgTmFkZWF1IFt0bmFk ZWF1QGx1Y2lkdmlzaW9uLmNvbV0NCreiy83KsbzkOiAyMDExxOo01MIxNcjVIDE5OjU0DQq1vTog TWFjaCBDaGVuDQpDYzogcHdlM0BpZXRmLm9yZzsgWWFha292IFN0ZWluOyBMdWNhIE1hcnRpbmkN Ctb3zOI6IFJlOiBbUFdFM10gUFdFMyB3b3JraW5nIGdyb3VwICAgICAgIHBvbGwgICAgZm9yICAg ICBkcmFmdC1jYW8tcHdlMy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTAyLnR4dA0KDQpPbiBB cHIgMTQsIDIwMTEsIGF0IDEwOjM2IFBNLCBNYWNoIENoZW4gd3JvdGU6DQoNCj4gSGkgVG9to6wN Cj4NCj4gT25lIGNhbmRpZGF0ZSBzb2x1dGlvbiBpcyBtYW51YWwgY29uZmlndXJhdGlvbiwgYnV0 IGl0IGlzIHByb25lIHRvIGNvbmZpZ3VyYXRpb24gZXJyb3IgYW5kIGluZWZmaWNpZW50IHRvIG1h bmFnZSBsYXJnZSBudW1iZXIgb2YgUFdzLCBhbmQgZXZlbiB3b3JzZSB3aGVuIGRvIEZSUiwgcmVy b3V0ZSwgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuDQo+DQo+IFRoYXQgd2lsbCBiZSBoZWxwZnVsIGlm IHlvdSBjb3VsZCBlbnVtZXJhdGUgc29tZSBvdGhlciBjYW5kaWRhdGVzLCB0aGVuIHRoZSBXRyBj b3VsZCBkaXNjdXNzIGl0IG1vcmUgc3BlY2lmaWNhbGx5Lg0KDQogICAgICAgIFRha2UgYSBsb29r IGF0IHRoZSBHTVBMUyBhcmVhJ3MgYmlkaXIgTFNQIHNvbHV0aW9uLg0KDQogICAgICAgIC0tVG9t DQoNCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBNYWNoDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gRnJvbTogcHdlMy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cHdlMy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+IFRob21hcyBOYWRlYXUNCj4+IFNlbnQ6IEZy aWRheSwgQXByaWwgMTUsIDIwMTEgMjo1MSBBTQ0KPj4gVG86IEx1Y2EgTWFydGluaQ0KPj4gQ2M6 IFlhYWtvdiBTdGVpbjsgcHdlM0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtQV0UzXSBQV0Uz IHdvcmtpbmcgZ3JvdXAgcG9sbCBmb3INCj4+IGRyYWZ0LWNhby1wd2UzLW1wbHMtdHAtcHctb3Zl ci1iaWRpci1sc3AtMDIudHh0DQo+Pg0KPj4gSSdtIHdpdGggbHVjYS4gQXMgSSBzYWlkIGVhcmxp ZXIgSSdkIGxpa2UgbW9yZSBkaXNjdXNzaW9uIGFzIHRvIHdoZXRoZXIgb3Igbm90DQo+PiBvdGhl ciBleGlzdGluZyBzb2x1dGlvbnMgY291bGRuJ3QgYmUgbGV2ZXJhZ2VkIGJlZm9yZSB3ZSBnbyBm b3J3YXJkIHdpdGggdGhpcw0KPj4gb25lIGFzIGl0IGlzIHF1aXRlIHVuZGVyIHNwZWNpZmllZC4N Cj4+DQo+PiBUb20NCj4+DQo+Pg0KPj4NCj4+IE9uIEFwciAxNCwgMjAxMSwgYXQgMTI6MDcgUE0s IEx1Y2EgTWFydGluaSA8bG1hcnRpbmlAY2lzY28uY29tPiB3cm90ZToNCj4+DQo+Pj4gT24gMDQv MTQvMTEgMDk6MDEsIFlhYWtvdiBTdGVpbiB3cm90ZToNCj4+Pj4+IFlvdSBkaWQgbm90IGFuc3dl ciBxdWVzdGlvbiAjMiAuLi4NCj4+Pj4+IEx1Y2ENCj4+Pj4gSSBhbnN3ZXJlZCBpdCBieSBzYXlp bmcgdGhhdCBzaW1wbHkgZm9yY2luZyBwbGFjZW1lbnQgb2YgYSBQVyBpbnRvIHRoZQ0KPj4gYXBw cm9wcmlhdGUgTFNQDQo+Pj4+IHNvbHZlcyB0aGUgcHJvYmxlbS4gKE1lYW5pbmcgdGhhdCBJIGRv IG5vdCB3YW50IG1vcmUgY29tcGxleCBQVy1zcGVjaWZpYw0KPj4gbWV0aG9kcy4pDQo+Pj4+DQo+ Pj4+IEkgcHVycG9zZWx5IGRpZCBub3Qgc3RhdGUgd2hldGhlciB0aGUgcGFydGljdWxhciBMRFAg bWVjaGFuaXNtIHByb3Bvc2VkIGlzDQo+PiBvcHRpbWFsIG9yIGV2ZW4gY29ycmVjdC4NCj4+Pj4g VGhpcyBpcyBub3QgYSBMQywgaXQgaXMganVzdCBhIG1vdGlvbiB0byBtb3ZlIHRoaXMgdG8gV0cg c3RhdHVzLg0KPj4+Pg0KPj4+PiBZKEopUw0KPj4+Pg0KPj4+Pg0KPj4+IFllcyAsIGJ1dCBoaXN0 b3JpY2FsbHkgd2UgaGF2ZSBhbHdheXMgbW92ZWQgZG9jdW1lbnRzIHRvIHdnIHN0YXR1cyB0aGF0 DQo+Pj4gd2hlcmUgYXQgbGVhc3QgODAlIHRoZXJlLi4uDQo+Pj4gVGhpcyBkb2N1bWVudCBpcyBt YXliZSAxMCUgZG9uZS4NCj4+PiBJIGRvIG5vdCB0aGluayB0aGF0IHRoZXJlIGlzIGFueSBhcmd1 bWVudCB0aGF0IHdlLCBhcyB0aGUgUFdFMyBXRywgd2FudA0KPj4+IHRvIHdvcmsgb24gdGhpcyBw cm9ibGVtLg0KPj4+IENhbiB5b3Ugc3VnZ2VzdCBzb21ldGhpbmcgYSBiaXQgbW9yZSBjb21wbGV0 ZSB0aGVuID8NCj4+Pg0KPj4+IFRoYW5rcy4NCj4+PiBMdWNhDQo+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gcHdlMyBtYWlsaW5nIGxpc3QNCj4+PiBwd2UzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQo+Pj4NCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBwd2UzIG1haWxpbmcgbGlzdA0KPj4g cHdlM0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w d2UzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpw d2UzIG1haWxpbmcgbGlzdA0KcHdlM0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wd2UzDQo= From curtis@occnc.com Fri Apr 15 13:46:59 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 40808E06B6 for ; Fri, 15 Apr 2011 13:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcUO-ygXZU7z for ; Fri, 15 Apr 2011 13:46:58 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 177A1E0674 for ; Fri, 15 Apr 2011 13:46:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FKkPTM075479; Fri, 15 Apr 2011 16:46:25 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104152046.p3FKkPTM075479@harbor.orleans.occnc.com> To: Luca Martini From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 23:41:50 MDT." <4DA6891E.50504@cisco.com> Date: Fri, 15 Apr 2011 16:46:25 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 20:46:59 -0000 In message <4DA6891E.50504@cisco.com> Luca Martini writes: > > Curtis, > > If we keep the GAL at the bottom of the stack to flag the fact that the > packet is GACH format , and not IP format, what is the problem ? > Surly FAT-PW would still work as most LSRs use the 2 bottom most labels > to build a hash table. > > The gal = label 13 has a fixed binding to it. Do you propose that we > change that ? or just the location of the label? > > Luca Right now as defined, GAL is below (after) the label for which OAM is applied and it is also at the bottom. I'm proposing we keep the restriction that GAL be below the label for which OAM is applied and we drop the restriction that it be at the bottom. The G-Ach is after the BOS. All labels after GAL and up to BOS are skipped. The value of GAL = 13 stays the same. Curtis > On 03/31/11 03:10, Curtis Villamizar wrote: > > In message <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsson.se> > > David Allan I writes: > >> > >> HI Curtis: > >> > >> My suggestion is to avoid the GAL for PWs if it is to be a > >> homogenizing agent across TP and IP/MPLS domains in the form of > >> MS-PWs. The scenarios in which it was broken was simply a statement of > >> fact. > >> > >> As for the problem GAL was proposed to fix (lack of CW), there are > >> solutions on the table, just not palatable... > >> > >> D > > > > Dave, > > > > I think we are in agreement. > > > > We either use a non-GAL mechanism, or we fix GAL by removing the > > bottom of stack restriction and use GAL. > > > > I prefer the latter option, fix GAL. > > > > I support not using GAL at all in PW if GAL can't be fixed. > > > > Fixing GAL should really be an MPLS WG discussion. The result of that > > discussion in MPLS should gate whether any PW proposal to use GAL can > > be moved forward. > > > > Curtis > > > > > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Curtis Villamizar > >> Sent: Thursday, March 31, 2011 9:03 AM > >> To: Loa Andersson > >> Cc: pwe3@ietf.org > >> Subject: Re: [PWE3] GAL above and below the PW label > >> > >> > >> Loa, Dave, Sasha, > >> > >> I've snipped from various posts on the thread that Sasha started. See inline. > >> > >> In message <4D92F5D3.6080609@pi.nu> > >> Loa Andersson writes: > >>> > >>> All, > >>> > >>> missed a nuance in Sasha subject line. > >>> > >>> We have two issues > >>> > >>> - where the GAL is placed relative to the PW label, I believe it is > >>> necessary to have the GAL below the PW label. > >>> > >>> - whether the the GAL label needs to be bottom of stack or not, it > >>> figure that this is really a discussion if it is possible to have > >>> a FAT label below the GAL or not. I'm not sure about my preferences > >>> but I think it is possible. > >>> > >>> /Loa > >> > >> I agree with Loa's summary. Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic. > >> > >> > >> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericsson.se> > >> David Allan I writes: > >>> > >>> It does become a new behavior, GAL with S=3D0. However the combination > >>> of G= AL being top label at the S-PE and TTL being encoded in the PW > >>> label means = that fate sharing is broken at every S-PE. Life only > >>> gets a little more str= ange if there is a FAT label as well... > >>> > >>> That being said, GAL as bottom label is broken in any ECMP > >>> environment, whi= ch is why GAL is a TP construct. > >>> > >>> my 2 cents > >>> D > >> > >> Dave, > >> > >> If GAL is broken for ECMP, which it is, then all TP OAM is broken. > >> If all it takes to fix it is simple then lets just fix it. > >> > >> This is what we'd have to do. > >> > >> 1) Relax the requirement that GAL be at the bottom > >> > >> 2) Have the ingress insert GAL in the stack immediately below the > >> label for which the measurement is made, keeping the rest of the > >> label stack in place. > >> > >> The only thing the midpoing LSR at a multipath (LAG, link bundle for > >> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there. That will yield the same hash value and it will preserve fate-sharing across multipath. > >> > >> I prefer that we fix things rather than complain that they are broken. > >> > >> Curtis > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 From curtis@occnc.com Fri Apr 15 14:29:17 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15102E0674 for ; Fri, 15 Apr 2011 14:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xKzjPFFRDqq for ; Fri, 15 Apr 2011 14:29:15 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 5265EE0673 for ; Fri, 15 Apr 2011 14:29:15 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FLTA16076010; Fri, 15 Apr 2011 17:29:10 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104152129.p3FLTA16076010@harbor.orleans.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 14:57:43 EDT." <60C093A41B5E45409A19D42CF7786DFD5219ECA275@EUSAACMS0703.eamcs.ericsson.se> Date: Fri, 15 Apr 2011 17:29:10 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , Luca Martini Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:29:17 -0000 In message <60C093A41B5E45409A19D42CF7786DFD5219ECA275@EUSAACMS0703.eamcs.ericsson.se> David Allan I writes: > > Hi Luca: > > I don't think hashing two labels helps achieve consistency for OAM > purposes... > > FAT label + GAL does not hash to same value as PW label + FAT label... > > Am I missing something? > D Yes I think you are missing something. Don't hash on reserved labels; skip over them. PW label + FAT label is on a payload packet. PW label + GAL + FAT label is on the OAM packet. The LSP labels above that would be the same. At egress to the PW, the next label is GAL so its G-Ach. On TTL expired on a MS-PW, the next label is GAL so it is G-Ach. Skip to the BOS and then look at the G-Ach header if G-Ach is indicated. As soon as OAM is indicated it is OK to go to slow(er) path processing (where slower may have hardware assist but is less than line rate). Then OAM and payload take exactly the same path given the same fat-pw label is used. If traffic is sprayed using fat-pw label, then randomizing the fat-pw label on OAM will check all of the paths (eventually). A single drop would need to be followed up by multiple packets using the same fat-pw label, but this is easily handled by a two way OAM such as LSP Ping. Curtis > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Wednesday, April 13, 2011 10:42 PM > To: curtis@occnc.com > Cc: David Allan I; pwe3@ietf.org > Subject: Re: [PWE3] GAL above and below the PW label > > Curtis, > > If we keep the GAL at the bottom of the stack to flag the fact that the packet is GACH format , and not IP format, what is the problem ? > Surly FAT-PW would still work as most LSRs use the 2 bottom most labels to build a hash table. > > The gal = label 13 has a fixed binding to it. Do you propose that we change that ? or just the location of the label? > > Luca > > > > On 03/31/11 03:10, Curtis Villamizar wrote: > > In message > > <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsso > > n.se> > > David Allan I writes: > >> > >> HI Curtis: > >> > >> My suggestion is to avoid the GAL for PWs if it is to be a > >> homogenizing agent across TP and IP/MPLS domains in the form of > >> MS-PWs. The scenarios in which it was broken was simply a statement > >> of fact. > >> > >> As for the problem GAL was proposed to fix (lack of CW), there are > >> solutions on the table, just not palatable... > >> > >> D > > > > Dave, > > > > I think we are in agreement. > > > > We either use a non-GAL mechanism, or we fix GAL by removing the > > bottom of stack restriction and use GAL. > > > > I prefer the latter option, fix GAL. > > > > I support not using GAL at all in PW if GAL can't be fixed. > > > > Fixing GAL should really be an MPLS WG discussion. The result of that > > discussion in MPLS should gate whether any PW proposal to use GAL can > > be moved forward. > > > > Curtis > > > > > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > >> Of Curtis Villamizar > >> Sent: Thursday, March 31, 2011 9:03 AM > >> To: Loa Andersson > >> Cc: pwe3@ietf.org > >> Subject: Re: [PWE3] GAL above and below the PW label > >> > >> > >> Loa, Dave, Sasha, > >> > >> I've snipped from various posts on the thread that Sasha started. See inline. > >> > >> In message <4D92F5D3.6080609@pi.nu> > >> Loa Andersson writes: > >>> > >>> All, > >>> > >>> missed a nuance in Sasha subject line. > >>> > >>> We have two issues > >>> > >>> - where the GAL is placed relative to the PW label, I believe it is > >>> necessary to have the GAL below the PW label. > >>> > >>> - whether the the GAL label needs to be bottom of stack or not, it > >>> figure that this is really a discussion if it is possible to have > >>> a FAT label below the GAL or not. I'm not sure about my preferences > >>> but I think it is possible. > >>> > >>> /Loa > >> > >> I agree with Loa's summary. Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic. > >> > >> > >> In message > >> <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericss > >> on.se> > >> David Allan I writes: > >>> > >>> It does become a new behavior, GAL with S=3D0. However the > >>> combination of G= AL being top label at the S-PE and TTL being > >>> encoded in the PW label means = that fate sharing is broken at every > >>> S-PE. Life only gets a little more str= ange if there is a FAT label as well... > >>> > >>> That being said, GAL as bottom label is broken in any ECMP > >>> environment, whi= ch is why GAL is a TP construct. > >>> > >>> my 2 cents > >>> D > >> > >> Dave, > >> > >> If GAL is broken for ECMP, which it is, then all TP OAM is broken. > >> If all it takes to fix it is simple then lets just fix it. > >> > >> This is what we'd have to do. > >> > >> 1) Relax the requirement that GAL be at the bottom > >> > >> 2) Have the ingress insert GAL in the stack immediately below the > >> label for which the measurement is made, keeping the rest of the > >> label stack in place. > >> > >> The only thing the midpoing LSR at a multipath (LAG, link bundle for > >> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there. That will yield the same hash value and it will preserve fate-sharing across multipath. > >> > >> I prefer that we fix things rather than complain that they are broken. > >> > >> Curtis From david.i.allan@ericsson.com Fri Apr 15 14:35:58 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1254FE06A9 for ; Fri, 15 Apr 2011 14:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.404 X-Spam-Level: X-Spam-Status: No, score=-5.404 tagged_above=-999 required=5 tests=[AWL=1.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFhDLcmoreKv for ; Fri, 15 Apr 2011 14:35:56 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id DCF9EE06AD for ; Fri, 15 Apr 2011 14:35:56 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3FLZE8V001529; Fri, 15 Apr 2011 16:35:56 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.159]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 15 Apr 2011 17:35:29 -0400 From: David Allan I To: "curtis@occnc.com" Date: Fri, 15 Apr 2011 17:35:29 -0400 Thread-Topic: [PWE3] GAL above and below the PW label Thread-Index: Acv7tCv0RhZt7nFVTYuVxEYEY+6bgAAADeUw Message-ID: <60C093A41B5E45409A19D42CF7786DFD521A14F1CB@EUSAACMS0703.eamcs.ericsson.se> References: Your message of "Thu, 14 Apr 2011 14:57:43 EDT." <60C093A41B5E45409A19D42CF7786DFD5219ECA275@EUSAACMS0703.eamcs.ericsson.se> <201104152129.p3FLTA16076010@harbor.orleans.occnc.com> In-Reply-To: <201104152129.p3FLTA16076010@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" , Luca Martini Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:35:58 -0000 OK I lost that element of the thread... But I'm not aware of implementations that do not hash reserved labels. We s= eemed to have gone around this buoy back in label 14 days... And I'm not aw= are that anything has changed.=20 If reserved labels are ignored then everything of course will fate share...= regardless of the number of labels one hashes... D -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com]=20 Sent: Friday, April 15, 2011 2:29 PM To: David Allan I Cc: Luca Martini; curtis@occnc.com; pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label=20 In message <60C093A41B5E45409A19D42CF7786DFD5219ECA275@EUSAACMS0703.eamcs.e= ricsson.se> David Allan I writes: > =20 > Hi Luca: > =20 > I don't think hashing two labels helps achieve consistency for OAM=20 > purposes... > =20 > FAT label + GAL does not hash to same value as PW label + FAT label... > =20 > Am I missing something? > D Yes I think you are missing something. Don't hash on reserved labels; skip over them. PW label + FAT label is on a payload packet. PW label + GAL + FAT label is on the OAM packet. The LSP labels above that would be the same. At egress to the PW, the next label is GAL so its G-Ach. On TTL expired on a MS-PW, the next label is GAL so it is G-Ach. Skip to the BOS and then look at the G-Ach header if G-Ach is indicated. As soon as OAM is indicated it is OK to go to slow(er) path processing (where slower may have hardware assist but is less than line rate). Then OAM and payload take exactly the same path given the same fat-pw label is used. If traffic is sprayed using fat-pw label, then randomizing the fat-pw label on OAM will check all of the paths (eventually). A single drop would need to be followed up by multiple packets using the same fat-pw label, but this is easily handled by a two way OAM such as LSP Ping. Curtis > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com]=20 > Sent: Wednesday, April 13, 2011 10:42 PM > To: curtis@occnc.com > Cc: David Allan I; pwe3@ietf.org > Subject: Re: [PWE3] GAL above and below the PW label > =20 > Curtis, > =20 > If we keep the GAL at the bottom of the stack to flag the fact that the p= acket is GACH format , and not IP format, what is the problem ? > Surly FAT-PW would still work as most LSRs use the 2 bottom most labels t= o build a hash table. > =20 > The gal =3D label 13 has a fixed binding to it. Do you propose that we ch= ange that ? or just the location of the label? > =20 > Luca > =20 > =20 > =20 > On 03/31/11 03:10, Curtis Villamizar wrote: > > In message=20 > > <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsso > > n.se> > > David Allan I writes: > >> =20 > >> HI Curtis: > >> =20 > >> My suggestion is to avoid the GAL for PWs if it is to be a=20 > >> homogenizing agent across TP and IP/MPLS domains in the form of=20 > >> MS-PWs. The scenarios in which it was broken was simply a statement=20 > >> of fact. > >> =20 > >> As for the problem GAL was proposed to fix (lack of CW), there are=20 > >> solutions on the table, just not palatable... > >> =20 > >> D > > > > Dave, > > > > I think we are in agreement. > > > > We either use a non-GAL mechanism, or we fix GAL by removing the=20 > > bottom of stack restriction and use GAL. > > > > I prefer the latter option, fix GAL. > > > > I support not using GAL at all in PW if GAL can't be fixed. > > > > Fixing GAL should really be an MPLS WG discussion. The result of that= =20 > > discussion in MPLS should gate whether any PW proposal to use GAL can=20 > > be moved forward. > > > > Curtis > > > > > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf=20 > >> Of Curtis Villamizar > >> Sent: Thursday, March 31, 2011 9:03 AM > >> To: Loa Andersson > >> Cc: pwe3@ietf.org > >> Subject: Re: [PWE3] GAL above and below the PW label > >> =20 > >> =20 > >> Loa, Dave, Sasha, > >> =20 > >> I've snipped from various posts on the thread that Sasha started. See= inline. > >> =20 > >> In message <4D92F5D3.6080609@pi.nu> > >> Loa Andersson writes: > >>> =20 > >>> All, > >>> =20 > >>> missed a nuance in Sasha subject line. > >>> =20 > >>> We have two issues > >>> =20 > >>> - where the GAL is placed relative to the PW label, I believe it is > >>> necessary to have the GAL below the PW label. > >>> =20 > >>> - whether the the GAL label needs to be bottom of stack or not, it > >>> figure that this is really a discussion if it is possible to have > >>> a FAT label below the GAL or not. I'm not sure about my preferenc= es > >>> but I think it is possible. > >>> =20 > >>> /Loa > >> =20 > >> I agree with Loa's summary. Not putting GAL at the bottom may confuse= some LSR, but putting it above the PW label is likely to be even more prob= lematic. > >> =20 > >> =20 > >> In message=20 > >> <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericss > >> on.se> > >> David Allan I writes: > >>> =20 > >>> It does become a new behavior, GAL with S=3D3D0. However the=20 > >>> combination of G=3D AL being top label at the S-PE and TTL being=20 > >>> encoded in the PW label means =3D that fate sharing is broken at ever= y=20 > >>> S-PE. Life only gets a little more str=3D ange if there is a FAT labe= l as well... > >>> =20 > >>> That being said, GAL as bottom label is broken in any ECMP=20 > >>> environment, whi=3D ch is why GAL is a TP construct. > >>> =20 > >>> my 2 cents > >>> D > >> =20 > >> Dave, > >> =20 > >> If GAL is broken for ECMP, which it is, then all TP OAM is broken. > >> If all it takes to fix it is simple then lets just fix it. > >> =20 > >> This is what we'd have to do. > >> =20 > >> 1) Relax the requirement that GAL be at the bottom > >> =20 > >> 2) Have the ingress insert GAL in the stack immediately below the > >> label for which the measurement is made, keeping the rest of the > >> label stack in place. > >> =20 > >> The only thing the midpoing LSR at a multipath (LAG, link bundle for > >> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn'= t there. That will yield the same hash value and it will preserve fate-sha= ring across multipath. > >> =20 > >> I prefer that we fix things rather than complain that they are broken. > >> =20 > >> Curtis From aldrin.ietf@gmail.com Fri Apr 15 15:16:49 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 088B3E0698 for ; Fri, 15 Apr 2011 15:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOxLdPH2YmBQ for ; Fri, 15 Apr 2011 15:16:32 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 3B176E0688 for ; Fri, 15 Apr 2011 15:16:32 -0700 (PDT) Received: by pzk30 with SMTP id 30so1466315pzk.31 for ; Fri, 15 Apr 2011 15:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=YgdSL1XQptf/VkTdu0XpB9GaNAqk6jJuzauUFVMg8fg=; b=e/Vq+oTdG2GiSzls3kqu93K44ELaTSOkMRoGllVxUSdJozPI2utJC7atOrAp/l26ws f3+b+QRBNkqhZWOOUb7LxhC4qI36VS9xDMvGB4VorSRRakkDkQkHzC/RR6ZAqL0e40/W aNxbBYSrMzpkuAp+0o1Il/InfnpHMlxfyNkxU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=L+0plSamU6QMu4+j3hryofAYfvXl1oEbuKXtpUTzCyay720fU341zidoawldr7Xp7n RHkbmJkH1Scjwu02TGO2j+J7ByI6/rRuhj/dFjyZTERmEtbIfkFunESUcM/q4Y/Ik453 Bf4k/A2efQVtHWZYtF0SnwdCXGf9rJgZlXmyA= Received: by 10.142.140.10 with SMTP id n10mr1080625wfd.72.1302905791570; Fri, 15 Apr 2011 15:16:31 -0700 (PDT) Received: from [192.168.1.127] ([12.133.183.34]) by mx.google.com with ESMTPS id p40sm4199379wfc.17.2011.04.15.15.16.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2011 15:16:30 -0700 (PDT) References: <201104152129.p3FLTA16076010@harbor.orleans.occnc.com> In-Reply-To: <201104152129.p3FLTA16076010@harbor.orleans.occnc.com> Mime-Version: 1.0 (iPad Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8H7) From: Sam Aldrin Date: Fri, 15 Apr 2011 15:16:49 -0700 To: "curtis@occnc.com" Cc: Luca Martini , "pwe3@ietf.org" Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:16:49 -0000 Curtis, Inline for my comments with %Sam. Sent from my iPad On Apr 15, 2011, at 2:29 PM, Curtis Villamizar wrote: >=20 > In message <60C093A41B5E45409A19D42CF7786DFD5219ECA275@EUSAACMS0703.eamcs.= ericsson.se> > David Allan I writes: >>=20 >> Hi Luca: >>=20 >> I don't think hashing two labels helps achieve consistency for OAM >> purposes... >>=20 >> FAT label + GAL does not hash to same value as PW label + FAT label... >>=20 >> Am I missing something? >> D=20 >=20 >=20 > Yes I think you are missing something. Don't hash on reserved labels; > skip over them. >=20 > PW label + FAT label is on a payload packet. PW label + GAL + FAT > label is on the OAM packet. The LSP labels above that would be the > same. At egress to the PW, the next label is GAL so its G-Ach. On > TTL expired on a MS-PW, the next label is GAL so it is G-Ach. Skip to > the BOS and then look at the G-Ach header if G-Ach is indicated. As > soon as OAM is indicated it is OK to go to slow(er) path processing > (where slower may have hardware assist but is less than line rate). >=20 > Then OAM and payload take exactly the same path given the same fat-pw > label is used. If traffic is sprayed using fat-pw label, then > randomizing the fat-pw label on OAM will check all of the paths > (eventually). A single drop would need to be followed up by multiple > packets using the same fat-pw label, but this is easily handled by a > two way OAM such as LSP Ping. %Sam - I am presuming here that OAM packet with GAL+fat-pw will take the sam= e path as the data packet, which is with only fat-pw but no GAL. Not sure if= the hashing could ignore the reserved label GAL. For example, even the pres= ence of explicit null label could change the hashing behavior. I haven't com= e across any implementation which ignores reserved label for hashing. Hope I= am wrong :D If randomizing the path selection with fat-PW is the need, is there a requir= ement that OAM packets should take the same path as data packet with the sam= e fat-PW label? Cheers Sam >=20 > Curtis >=20 >=20 >> -----Original Message----- >> From: Luca Martini [mailto:lmartini@cisco.com]=20 >> Sent: Wednesday, April 13, 2011 10:42 PM >> To: curtis@occnc.com >> Cc: David Allan I; pwe3@ietf.org >> Subject: Re: [PWE3] GAL above and below the PW label >>=20 >> Curtis, >>=20 >> If we keep the GAL at the bottom of the stack to flag the fact that the p= acket is GACH format , and not IP format, what is the problem ? >> Surly FAT-PW would still work as most LSRs use the 2 bottom most labels t= o build a hash table. >>=20 >> The gal =3D label 13 has a fixed binding to it. Do you propose that we ch= ange that ? or just the location of the label? >>=20 >> Luca >>=20 >>=20 >>=20 >> On 03/31/11 03:10, Curtis Villamizar wrote: >>> In message=20 >>> <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsso >>> n.se> >>> David Allan I writes: >>>>=20 >>>> HI Curtis: >>>>=20 >>>> My suggestion is to avoid the GAL for PWs if it is to be a=20 >>>> homogenizing agent across TP and IP/MPLS domains in the form of=20 >>>> MS-PWs. The scenarios in which it was broken was simply a statement=20 >>>> of fact. >>>>=20 >>>> As for the problem GAL was proposed to fix (lack of CW), there are=20 >>>> solutions on the table, just not palatable... >>>>=20 >>>> D >>>=20 >>> Dave, >>>=20 >>> I think we are in agreement. >>>=20 >>> We either use a non-GAL mechanism, or we fix GAL by removing the=20 >>> bottom of stack restriction and use GAL. >>>=20 >>> I prefer the latter option, fix GAL. >>>=20 >>> I support not using GAL at all in PW if GAL can't be fixed. >>>=20 >>> Fixing GAL should really be an MPLS WG discussion. The result of that=20= >>> discussion in MPLS should gate whether any PW proposal to use GAL can=20= >>> be moved forward. >>>=20 >>> Curtis >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf=20= >>>> Of Curtis Villamizar >>>> Sent: Thursday, March 31, 2011 9:03 AM >>>> To: Loa Andersson >>>> Cc: pwe3@ietf.org >>>> Subject: Re: [PWE3] GAL above and below the PW label >>>>=20 >>>>=20 >>>> Loa, Dave, Sasha, >>>>=20 >>>> I've snipped from various posts on the thread that Sasha started. See i= nline. >>>>=20 >>>> In message <4D92F5D3.6080609@pi.nu> >>>> Loa Andersson writes: >>>>>=20 >>>>> All, >>>>>=20 >>>>> missed a nuance in Sasha subject line. >>>>>=20 >>>>> We have two issues >>>>>=20 >>>>> - where the GAL is placed relative to the PW label, I believe it is >>>>> necessary to have the GAL below the PW label. >>>>>=20 >>>>> - whether the the GAL label needs to be bottom of stack or not, it >>>>> figure that this is really a discussion if it is possible to have >>>>> a FAT label below the GAL or not. I'm not sure about my preferences= >>>>> but I think it is possible. >>>>>=20 >>>>> /Loa >>>>=20 >>>> I agree with Loa's summary. Not putting GAL at the bottom may confuse s= ome LSR, but putting it above the PW label is likely to be even more problem= atic. >>>>=20 >>>>=20 >>>> In message=20 >>>> <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericss >>>> on.se> >>>> David Allan I writes: >>>>>=20 >>>>> It does become a new behavior, GAL with S=3D3D0. However the=20 >>>>> combination of G=3D AL being top label at the S-PE and TTL being=20 >>>>> encoded in the PW label means =3D that fate sharing is broken at every= =20 >>>>> S-PE. Life only gets a little more str=3D ange if there is a FAT label= as well... >>>>>=20 >>>>> That being said, GAL as bottom label is broken in any ECMP=20 >>>>> environment, whi=3D ch is why GAL is a TP construct. >>>>>=20 >>>>> my 2 cents >>>>> D >>>>=20 >>>> Dave, >>>>=20 >>>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >>>> If all it takes to fix it is simple then lets just fix it. >>>>=20 >>>> This is what we'd have to do. >>>>=20 >>>> 1) Relax the requirement that GAL be at the bottom >>>>=20 >>>> 2) Have the ingress insert GAL in the stack immediately below the >>>> label for which the measurement is made, keeping the rest of the >>>> label stack in place. >>>>=20 >>>> The only thing the midpoing LSR at a multipath (LAG, link bundle for >>>> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't= there. That will yield the same hash value and it will preserve fate-shari= ng across multipath. >>>>=20 >>>> I prefer that we fix things rather than complain that they are broken. >>>>=20 >>>> Curtis > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From curtis@occnc.com Fri Apr 15 17:01:24 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CB852E0698 for ; Fri, 15 Apr 2011 17:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EUR5281W++a for ; Fri, 15 Apr 2011 17:01:24 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 16ACDE0690 for ; Fri, 15 Apr 2011 17:01:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G01ITR078317; Fri, 15 Apr 2011 20:01:18 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160001.p3G01ITR078317@harbor.orleans.occnc.com> To: Luca Martini From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 23:31:37 MDT." <4DA686B9.8020109@cisco.com> Date: Fri, 15 Apr 2011 20:01:18 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:01:24 -0000 In message <4DA686B9.8020109@cisco.com> Luca Martini writes: > > On 03/30/11 02:51, Sam Aldrin wrote: > > When ms-pw ping is performed, the packet should not be processed at > > S-PE, unless the PW label ttl is expired. With the proposed GAL label > > above PW label, how do you ensure the OAM packet take the same data > > path to reach far-end T-PE, without getting processed/punted at S-PE? > > Or for that matter go beyond first S-PE? > > > You do not. > Either there is no ECMP deployed on the network , or you must use the CW. > > Luca Luca, This may be a valid concern. If there is multipath and there is CW, many existing implementations use the entire label stack, including reserved labels (GAL) in the hash. If so, the payload with a fixed label stack and the OAM, also with a fixed label stack but with GAL added, are very likely to take different paths (different multipath components, for example different LAG members). When using of GAL with multipath it is best to confirm that the LSR along the path do not use reserved labels in their hash. If they do, then the above condition can occur. While it is a valid concern, it should be fine to put a small warning in the document and move on. Curtis > > -sam > > > > Sent from my iPad > > > > On Mar 30, 2011, at 1:44 AM, Loa Andersson wrote: > > > >> Sasha, > >> > >> what do you mean with "exposed" I thought that what is gpoing on > >> in an S-PE is normal MPLS label switching. > >> > >> /Loa > >> > >> On 2011-03-30 10:36, Alexander Vainshtein wrote: > >>> Tom, Luca and all, > >>> > >>> I would like to clarify – again – my position regarding GAL above the PW > >>> label. > >>> > >>> I think that, other issues notwithstanding, it would create an issue if > >>> used with MS-PWs: > >>> > >>> ·GAL would be exposed at each S-PE (making a presumably end-to-end OAM > >>> message to be intercepted) > >>> > >>> ·What is even worse, there is no rule for forwarding the packet that has > >>> been intercepted due to an exposed GAL (until you count the statement in > >>> 5586 requesting that a packet MUST NOT be ever forwarded based on GALJ). > >>> Hence it would be perfectly valid just to drop such a packet at the > >>> first S-PE it crosses… > >>> > >>> This said, I still do not think using GAL below the PW label is a good > >>> idea either. But this is a different story… > >>> > >>> Regards, > >>> > >>> Sasha From curtis@occnc.com Fri Apr 15 17:13:49 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B37BE067F for ; Fri, 15 Apr 2011 17:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMaD0sTvMexB for ; Fri, 15 Apr 2011 17:13:48 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 34214E066C for ; Fri, 15 Apr 2011 17:13:48 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G0Dh3M078443; Fri, 15 Apr 2011 20:13:43 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160013.p3G0Dh3M078443@harbor.orleans.occnc.com> To: Greg Mirsky From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 23:09:24 PDT." Date: Fri, 15 Apr 2011 20:13:43 -0400 Sender: curtis@occnc.com Cc: pwe3@ietf.org, Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:13:49 -0000 In message Greg Mirsky writes: > > Luca, > you've asked > How would LDP , which is IP based , even run on an MPLS-TP network ? > but isn't T-LDP part of MPLS-TP control plane? Control plane assumes IP > addressing thus use of T-LDP is plausible. > > Regards, > Greg Greg, MPLS-TP when using a control plane uses OSPF with OSPF-TE extensions or ISIS with ISIS-TE extensions and uses RSVP-TE with many applicable GMPLS extensions to the base MPLS RSVP-TE. There is no such thing as PW-TP. The control plane for PW is always TCP over IP over something. It could be over the IP forwarding supported byt the plain old OSPF or ISIS link state IGP or it could be over a G-Ach reserved for control plane traffic. The IGP could also use the control plane G-Ach, even on sections where G-Ach would ride over a naked GAL - no pun intended. There could also be no MPLS-TP control plane but PW T-LDP control plane over this G-Ach. An assumption is that T-LDP can function somehow if PW are being signaled (are not static). Curtis > On Wed, Apr 13, 2011 at 10:27 PM, Luca Martini wrote: > > > On 04/13/11 05:49, Andrew G. Malis wrote: > > > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > > > asked that this draft be made a PWE3 working group draft. > > > > > > This email starts a two week poll, closing Tuesday April 26, to help > > > judge consensus on this. > > > > > > Please send your responses to the PWE3 list. > > > > > > Thanks, > > > Andy and Matthew > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > No, Not in the current form. > > Although I agree that this problem is a real problem and needs a > > solution, this draft does not have enough information to actually build > > a protocol extension to LDP. > > In addition to the problems that Curtis mentions, there is no > > description on how to use the proposed TLVs in the LDP message. > > > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > > > PW assume that a PSN tunnel is identified by an IP address, which is > > also used as the LDP target session IP address. > > How is this possible with an MPLS-TP LSP ? > > > > At the minimum we would need some way to identify the IP address at the > > other end of the mpls-tp tunnel. > > > > Also I strongly believe that this WG needs to stop attempting to extend > > FEC 128 to have similar functionality as FEC 129. > > Just define new extensions for FEC 129 only , unless they are minor , > > and can be supported by FEC 128 without changing any existing procedures... > > > > > > Luca > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > --bcaec548654058ad5304a0dac45d > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Luca,
you've asked
How would LDP , which is IP based , even run o= > n an MPLS-TP network ?
but isn't T-LDP part of MPLS-TP control plane= > ? Control plane assumes IP addressing thus use of T-LDP is plausible.
>
Regards,
Greg

On Wed, Apr 13, 2011= > at 10:27 PM, Luca Martini < @cisco.com">lmartini@cisco.com> wrote:
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= > rgb(204, 204, 204); padding-left: 1ex;"> >
On 04/13/11 05:49, Andrew G. Malis wrote:
> > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have > > > asked that this draft be made a PWE3 working group draft.
> >
> > This email starts a two week poll, closing Tuesday April 26, to help r> > > judge consensus on this.
> >
> > Please send your responses to the PWE3 list.
> >
> > Thanks,
> > Andy and Matthew
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > k">https://www.ietf.org/mailman/listinfo/pwe3
>
No, Not in the current form.
> Although I agree that this problem is a real problem and needs a
> solution, this draft does not have enough information to actually build
> a protocol extension to LDP.
> In addition to the problems that Curtis mentions, there is no
> description on how to use the proposed TLVs in the LDP message.
>
> How would LDP , which is IP based , even run on an MPLS-TP network ?
>
> PW assume that a PSN tunnel is identified by an IP address, which is
> also used as the LDP target session IP address.
> How is this possible with an MPLS-TP LSP ?
>
> At the minimum we would need some way to identify the IP address at the
> other end of the mpls-tp tunnel.
>
> Also I strongly believe that this WG needs to stop attempting to extend
> FEC 128 to have similar functionality as FEC 129.
> Just define new extensions for FEC 129 only , unless they are minor ,
> and can be supported by FEC 128 without changing any existing procedures...= >
>
>
> Luca
>

>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> ht= > tps://www.ietf.org/mailman/listinfo/pwe3
>

> > --bcaec548654058ad5304a0dac45d-- From curtis@occnc.com Fri Apr 15 17:21:29 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2DF03E0665 for ; Fri, 15 Apr 2011 17:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-4ZmK7SOWpE for ; Fri, 15 Apr 2011 17:21:28 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 655BBE0660 for ; Fri, 15 Apr 2011 17:21:28 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G0LKlQ078489; Fri, 15 Apr 2011 20:21:20 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160021.p3G0LKlQ078489@harbor.orleans.occnc.com> To: Mach Chen From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 09:09:12 -0000." Date: Fri, 15 Apr 2011 20:21:20 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:21:29 -0000 Mach, We welcome a new draft, but IMHO as-is this document is not ready to become a WG document. Having identified a real problem is not by itself sufficient to make something a standards track WG document. The discussion shows interest but also shows that the holes in the proposed solution are still too big for this to be a WG doc. Curtis In message Mach Chen writes: > > Hi Luca, > > Thanks for your comments! > > > Although I agree that this problem is a real problem and needs a > > solution, > > Great! > > > this draft does not have enough information to actually build > > a protocol extension to LDP. > > Please note that this is not a WG last call :-) the draft is still > working in progress, and we'd appreciate that could give suggestion > and advice! > > > In addition to the problems that Curtis mentions, there is no > > description on how to use the proposed TLVs in the LDP message. > > Section 3 of the draft does describe the usage of the PW to LSP > Binding TLVs, they are carried in the LDP Mapping message for > associating tunnel selection and binding when signaling a PW, the > current version of this draft defines how to communicate tunnel LSP > selection and binding at the initiation of a PW. Regarding Curtis's > comments, it's about dynamic changing the tunnel LSP (whatever for > FRR, reroute or protection switching) after a PW established, the > authors are working on a revision to resolve the this. And suggestions > are welcomed! > > > > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > > > > PW assume that a PSN tunnel is identified by an IP address, which is > > also used as the LDP target session IP address. > > How is this possible with an MPLS-TP LSP ? > > As Greg pointed out , this is about the extension to the control plane > of PW and LDP is it, and MPLS-TP may run with control plane. > > In addition, this mechanisms defined in this document is not only for > MPLS-TP network, but could be applied to any other scenarios where > require both directions of a PW having congruent paths. > > > Best regards, > Mach From curtis@occnc.com Fri Apr 15 17:23:32 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E90AEE0696 for ; Fri, 15 Apr 2011 17:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw1Dwsw32UDj for ; Fri, 15 Apr 2011 17:23:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 68B0BE066C for ; Fri, 15 Apr 2011 17:23:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G0NRVA078570; Fri, 15 Apr 2011 20:23:27 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160023.p3G0NRVA078570@harbor.orleans.occnc.com> To: Sam Aldrin From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 07:43:23 PDT." Date: Fri, 15 Apr 2011 20:23:27 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , Luca Martini Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:23:33 -0000 In message Sam Aldrin writes: > > Luca, > > This is not regarding the ecmp in the networks, rather the impact of > GAL label being present above PW label in ms-PW networks. With the > proposed model of GAL label above PW label, the Ttl setting of PW > label has no bearing, as it will get punted at the very next S-PE, due > to GAL. > > Sam Sam, I think the authors agreed that GAL would be below the PW label (closer to the BOS aka S=1 bit). Curtis > Sent from my iPad > > On Apr 13, 2011, at 10:31 PM, Luca Martini wrote: > > > On 03/30/11 02:51, Sam Aldrin wrote: > >> When ms-pw ping is performed, the packet should not be processed at > >S-PE, unless the PW label ttl is expired. With the proposed GAL label > >above PW label, how do you ensure the OAM packet take the same data > >path to reach far-end T-PE, without getting processed/punted at S-PE? > >Or for that matter go beyond first S-PE? > >> > > You do not. > > Either there is no ECMP deployed on the network , or you must use the CW. > > > > Luca > > > >> -sam > >> > >> Sent from my iPad > >> > >> On Mar 30, 2011, at 1:44 AM, Loa Andersson wrote: > >> > >>> Sasha, > >>> > >>> what do you mean with "exposed" I thought that what is gpoing on > >>> in an S-PE is normal MPLS label switching. > >>> > >>> /Loa > >>> > >>> On 2011-03-30 10:36, Alexander Vainshtein wrote: > >>>> Tom, Luca and all, > >>>> > >>>> I would like to clarify – again – my position regarding GAL above the PW > >>>> label. > >>>> > >>>> I think that, other issues notwithstanding, it would create an issue if > >>>> used with MS-PWs: > >>>> > >>>> ·GAL would be exposed at each S-PE (making a presumably end-to-end OAM > >>>> message to be intercepted) > >>>> > >>>> ·What is even worse, there is no rule for forwarding the packet that has > >>>> been intercepted due to an exposed GAL (until you count the statement in > >>>> 5586 requesting that a packet MUST NOT be ever forwarded based on GALJ). > >>>> Hence it would be perfectly valid just to drop such a packet at the > >>>> first S-PE it crosses… > >>>> > >>>> This said, I still do not think using GAL below the PW label is a good > >>>> idea either. But this is a different story… > >>>> > >>>> Regards, > >>>> > >>>> Sasha From curtis@occnc.com Fri Apr 15 17:29:43 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D3B0EE06A7 for ; Fri, 15 Apr 2011 17:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB+7fLXBmSKy for ; Fri, 15 Apr 2011 17:29:43 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 2BCAFE06A5 for ; Fri, 15 Apr 2011 17:29:43 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G0TeFw078601; Fri, 15 Apr 2011 20:29:40 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160029.p3G0TeFw078601@harbor.orleans.occnc.com> To: Yaakov Stein From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 15:01:11 -0000." <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> Date: Fri, 15 Apr 2011 20:29:40 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:29:44 -0000 In message <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> Yaakov Stein writes: > > > You did not answer question #2 ... > > Luca > > I answered it by saying that simply forcing placement of a PW into the > appropriate LSP solves the problem. (Meaning that I do not want more > complex PW-specific methods.) > > I purposely did not state whether the particular LDP mechanism > proposed is optimal or even correct. This is not a LC, it is just a > motion to move this to WG status. > > Y(J)S Yaakov, Putting the PW into the right LSP solves the problem for SS-PW and for the first hop of a MS-PW, but not for the middle hops of MS-PW. OTOH, this proposal also does not solve the mid-segment problem for MS-PW since it does not specify selection criteria to select a tunnel at the S-PE. The practical reality is that a PW needs configuration at both ends. At one end it needs at the very least an admission control statement of some sort and that could direct traffic to the right LSP. If you consider that this solves the far end problem and the draft doesn't solve the MS-PW problem, then the draft adds nothing of use in its current form. Curtis From aldrin.ietf@gmail.com Fri Apr 15 17:37:37 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E6EEAE0665 for ; Fri, 15 Apr 2011 17:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5DlAXUdyF2p for ; Fri, 15 Apr 2011 17:37:37 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 25FC4E061E for ; Fri, 15 Apr 2011 17:37:37 -0700 (PDT) Received: by pwi5 with SMTP id 5so1692760pwi.31 for ; Fri, 15 Apr 2011 17:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=9ZSGo9jH27utLXynh6VgiPUNuKGbgxhbwy1V5uURYc0=; b=t0GxQ7pbquonSqnP+fwCH1fbeTFFXNhP7p7sM8lHRaDcR22uY8Si1VI9MUFkyPCrOh zaxFjmoAYB1DDBJ5lmHJP7qLDMxgcXIqH66wQdzSazCKOjPl+QfcW/mpQ2X2UGDrwN8x ThzPwr885Z2jpuE6Fq4n5D3rs4Xd0I+r3eRV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=NIQZehEruwzDZ7RUlD6CQkZmAc4CznJOHH6yS6YVhQTKxkyWCZUO+C0X7Cl5EXbsMO LTPdFpXyynjew2LgvY3VAfDykLlw98yfsChwqnkycn1RG1aqK52rgzyLsIWBWP3HZVGe 7FypiGpRaiwksgv8UooYXeRe3fuggbx1OOdbg= Received: by 10.68.0.7 with SMTP id 7mr2848575pba.188.1302914256631; Fri, 15 Apr 2011 17:37:36 -0700 (PDT) Received: from [192.168.1.127] ([12.133.183.34]) by mx.google.com with ESMTPS id g6sm740397pbq.13.2011.04.15.17.37.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2011 17:37:35 -0700 (PDT) References: <201104160023.p3G0NRVA078570@harbor.orleans.occnc.com> In-Reply-To: <201104160023.p3G0NRVA078570@harbor.orleans.occnc.com> Mime-Version: 1.0 (iPad Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (8H7) From: Sam Aldrin Date: Fri, 15 Apr 2011 17:37:55 -0700 To: "curtis@occnc.com" Cc: "pwe3@ietf.org" , Luca Martini Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:37:38 -0000 Thanks, Curtis. Much appreciated. Cheers Sam Sent from my iPad On Apr 15, 2011, at 5:23 PM, Curtis Villamizar wrote: >=20 > In message > Sam Aldrin writes: >>=20 >> Luca, >>=20 >> This is not regarding the ecmp in the networks, rather the impact of >> GAL label being present above PW label in ms-PW networks. With the >> proposed model of GAL label above PW label, the Ttl setting of PW >> label has no bearing, as it will get punted at the very next S-PE, due >> to GAL. >>=20 >> Sam >=20 >=20 > Sam, >=20 > I think the authors agreed that GAL would be below the PW label > (closer to the BOS aka S=3D1 bit). >=20 > Curtis >=20 >=20 >> Sent from my iPad >>=20 >> On Apr 13, 2011, at 10:31 PM, Luca Martini wrote: >>=20 >>> On 03/30/11 02:51, Sam Aldrin wrote: >>>> When ms-pw ping is performed, the packet should not be processed at >>> S-PE, unless the PW label ttl is expired. With the proposed GAL label >>> above PW label, how do you ensure the OAM packet take the same data >>> path to reach far-end T-PE, without getting processed/punted at S-PE? >>> Or for that matter go beyond first S-PE? >>>>=20 >>> You do not. >>> Either there is no ECMP deployed on the network , or you must use the CW= . >>>=20 >>> Luca >>>=20 >>>> -sam >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On Mar 30, 2011, at 1:44 AM, Loa Andersson wrote: >>>>=20 >>>>> Sasha, >>>>>=20 >>>>> what do you mean with "exposed" I thought that what is gpoing on >>>>> in an S-PE is normal MPLS label switching. >>>>>=20 >>>>> /Loa >>>>>=20 >>>>> On 2011-03-30 10:36, Alexander Vainshtein wrote: >>>>>> Tom, Luca and all, >>>>>>=20 >>>>>> I would like to clarify =C3=A2=E2=82=AC=E2=80=9C again =C3=A2=E2=82=AC= =E2=80=9C my position regarding GAL above the PW >>>>>> label. >>>>>>=20 >>>>>> I think that, other issues notwithstanding, it would create an issue i= f >>>>>> used with MS-PWs: >>>>>>=20 >>>>>> =C3=82=C2=B7GAL would be exposed at each S-PE (making a presumably en= d-to-end OAM >>>>>> message to be intercepted) >>>>>>=20 >>>>>> =C3=82=C2=B7What is even worse, there is no rule for forwarding the p= acket that has >>>>>> been intercepted due to an exposed GAL (until you count the statement= in >>>>>> 5586 requesting that a packet MUST NOT be ever forwarded based on GAL= J). >>>>>> Hence it would be perfectly valid just to drop such a packet at the >>>>>> first S-PE it crosses=C3=A2=E2=82=AC=C2=A6 >>>>>>=20 >>>>>> This said, I still do not think using GAL below the PW label is a goo= d >>>>>> idea either. But this is a different story=C3=A2=E2=82=AC=C2=A6 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Sasha >=20 From curtis@occnc.com Fri Apr 15 17:38:03 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8BAFEE0665 for ; Fri, 15 Apr 2011 17:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-PHN3Acu0+z for ; Fri, 15 Apr 2011 17:38:02 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 85A49E061E for ; Fri, 15 Apr 2011 17:38:02 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G0bvuR078723; Fri, 15 Apr 2011 20:37:57 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160037.p3G0bvuR078723@harbor.orleans.occnc.com> To: Luca Martini From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 09:48:53 MDT." <4DA71765.4060504@cisco.com> Date: Fri, 15 Apr 2011 20:37:57 -0400 Sender: curtis@occnc.com Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:38:03 -0000 In message <4DA71765.4060504@cisco.com> Luca Martini writes: > > hello! > > It appears to me that it might not be clear that I also believe that > the GAL should be at the bottom of the stack. I know that that is not > where we have it in the -00 version of the VCCV-2 draft , but that was > only an initial suggestion and we really wanted a good discussion on > this list. > > We will update that document shortly. > Thanks. > Luca Luca, Please specify below the PW label (below in the MPLS sense of bottom) and not BOS. MPLS style stack orientation: LSP label PW label GAL <- this is for PW OAM optional fat-pw label (S=1) G-Ach LSP label GAL <- this is for LSP OAM PW label optional fat-pw label (S=1) G-Ach LSP label PW label optional fat-pw label (S=1) payload Therefore there can consistently be a rule where GAL is under the label for which the OAM is applied. If the hashing ignores reserved labels, then all three above take the same path in the absence of fat-pw or take the same path given the same value of the fat-pw label. Curtis > On 04/13/11 23:41, Luca Martini wrote: > > Curtis, > > > > If we keep the GAL at the bottom of the stack to flag the fact that the > > packet is GACH format , and not IP format, what is the problem ? > > Surly FAT-PW would still work as most LSRs use the 2 bottom most labels > > to build a hash table. > > > > The gal = label 13 has a fixed binding to it. Do you propose that we > > change that ? or just the location of the label? > > > > Luca > > > > > > > > On 03/31/11 03:10, Curtis Villamizar wrote: > >> In message <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsson.se> > >> David Allan I writes: > >>> > >>> HI Curtis: > >>> > >>> My suggestion is to avoid the GAL for PWs if it is to be a > >>> homogenizing agent across TP and IP/MPLS domains in the form of > >>> MS-PWs. The scenarios in which it was broken was simply a statement of > >>> fact. > >>> > >>> As for the problem GAL was proposed to fix (lack of CW), there are > >>> solutions on the table, just not palatable... > >>> > >>> D > >> Dave, > >> > >> I think we are in agreement. > >> > >> We either use a non-GAL mechanism, or we fix GAL by removing the > >> bottom of stack restriction and use GAL. > >> > >> I prefer the latter option, fix GAL. > >> > >> I support not using GAL at all in PW if GAL can't be fixed. > >> > >> Fixing GAL should really be an MPLS WG discussion. The result of that > >> discussion in MPLS should gate whether any PW proposal to use GAL can > >> be moved forward. > >> > >> Curtis > >> > >> > >>> -----Original Message----- > >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Curtis Villamizar > >>> Sent: Thursday, March 31, 2011 9:03 AM > >>> To: Loa Andersson > >>> Cc: pwe3@ietf.org > >>> Subject: Re: [PWE3] GAL above and below the PW label > >>> > >>> > >>> Loa, Dave, Sasha, > >>> > >>> I've snipped from various posts on the thread that Sasha started. See inline. > >>> > >>> In message <4D92F5D3.6080609@pi.nu> > >>> Loa Andersson writes: > >>>> > >>>> All, > >>>> > >>>> missed a nuance in Sasha subject line. > >>>> > >>>> We have two issues > >>>> > >>>> - where the GAL is placed relative to the PW label, I believe it is > >>>> necessary to have the GAL below the PW label. > >>>> > >>>> - whether the the GAL label needs to be bottom of stack or not, it > >>>> figure that this is really a discussion if it is possible to have > >>>> a FAT label below the GAL or not. I'm not sure about my preferences > >>>> but I think it is possible. > >>>> > >>>> /Loa > >>> > >>> I agree with Loa's summary. Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic. > >>> > >>> > >>> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericsson.se> > >>> David Allan I writes: > >>>> > >>>> It does become a new behavior, GAL with S=3D0. However the combination > >>>> of G= AL being top label at the S-PE and TTL being encoded in the PW > >>>> label means = that fate sharing is broken at every S-PE. Life only > >>>> gets a little more str= ange if there is a FAT label as well... > >>>> > >>>> That being said, GAL as bottom label is broken in any ECMP > >>>> environment, whi= ch is why GAL is a TP construct. > >>>> > >>>> my 2 cents > >>>> D > >>> > >>> Dave, > >>> > >>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. > >>> If all it takes to fix it is simple then lets just fix it. > >>> > >>> This is what we'd have to do. > >>> > >>> 1) Relax the requirement that GAL be at the bottom > >>> > >>> 2) Have the ingress insert GAL in the stack immediately below the > >>> label for which the measurement is made, keeping the rest of the > >>> label stack in place. > >>> > >>> The only thing the midpoing LSR at a multipath (LAG, link bundle for > >>> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there. That will yield the same hash value and it will preserve fate-sharing across multipath. > >>> > >>> I prefer that we fix things rather than complain that they are broken. > >>> > >>> Curtis From curtis@occnc.com Fri Apr 15 17:48:28 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F26EEE0683 for ; Fri, 15 Apr 2011 17:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMOhQhTD0w7m for ; Fri, 15 Apr 2011 17:48:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 59F6EE061E for ; Fri, 15 Apr 2011 17:48:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G0mMpm078893; Fri, 15 Apr 2011 20:48:22 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160048.p3G0mMpm078893@harbor.orleans.occnc.com> To: Mach Chen From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Apr 2011 02:41:34 -0000." Date: Fri, 15 Apr 2011 20:48:22 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , Yaakov Stein , Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:48:28 -0000 In message Mach Chen writes: > > Hi Yaakov and Luca, > > I think Section 5.3.2. "Support for Explicit Control of PW-to-LSP > Binding" of > http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06 > could answer the question #2. > > Best regards, > Mach Luca's question #2 was "is this the right solution?" So mpls-tp-cp-framework does not answer that question. Curtis > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Yaakov Stein > > Sent: Thursday, April 14, 2011 11:01 PM > > To: Luca Martini > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] PWE3 working group poll for > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > > > > You did not answer question #2 ... > > > > > Luca > > > > I answered it by saying that simply forcing placement of a PW into the > > appropriate LSP > > solves the problem. (Meaning that I do not want more complex PW-specific > > methods.) > > > > I purposely did not state whether the particular LDP mechanism proposed is > > optimal or even correct. > > This is not a LC, it is just a motion to move this to WG status. > > > > Y(J)S From curtis@occnc.com Fri Apr 15 19:00:34 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E2836E0683 for ; Fri, 15 Apr 2011 19:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCACcQCqaiBR for ; Fri, 15 Apr 2011 19:00:33 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 3F219E0682 for ; Fri, 15 Apr 2011 19:00:33 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G20PoE080441; Fri, 15 Apr 2011 22:00:25 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160200.p3G20PoE080441@harbor.orleans.occnc.com> To: Sam Aldrin From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Apr 2011 15:16:49 PDT." Date: Fri, 15 Apr 2011 22:00:25 -0400 Sender: curtis@occnc.com Cc: Luca Martini , "pwe3@ietf.org" Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 02:00:35 -0000 > I haven't come across any implementation which ignores reserved label > for hashing. Hope I am wrong :D Sam, I agree that hashing on reserved labels is common today and this requires that the hash not be done on reserved labels. For MPLS-TP at least at the high end, the high PPS rate and new requirements such as shutting off PHP and keeping counters for the POP labels force new chips (or recycling packets after POP operations and going well under line rate). At least a few new high end chips have this new functionality covered and the same chips also skip over reserved labels in doing the hash. Can't say much more on this topic. Curtis In message Sam Aldrin writes: > > Curtis, > > Inline for my comments with %Sam. > > Sent from my iPad > > On Apr 15, 2011, at 2:29 PM, Curtis Villamizar wrote: > > > > > In message <60C093A41B5E45409A19D42CF7786DFD5219ECA275@EUSAACMS0703.eamcs.ericsson.se> > > David Allan I writes: > >> > >> Hi Luca: > >> > >> I don't think hashing two labels helps achieve consistency for OAM > >> purposes... > >> > >> FAT label + GAL does not hash to same value as PW label + FAT label... > >> > >> Am I missing something? > >> D > > > > > > Yes I think you are missing something. Don't hash on reserved labels; > > skip over them. > > > > PW label + FAT label is on a payload packet. PW label + GAL + FAT > > label is on the OAM packet. The LSP labels above that would be the > > same. At egress to the PW, the next label is GAL so its G-Ach. On > > TTL expired on a MS-PW, the next label is GAL so it is G-Ach. Skip to > > the BOS and then look at the G-Ach header if G-Ach is indicated. As > > soon as OAM is indicated it is OK to go to slow(er) path processing > > (where slower may have hardware assist but is less than line rate). > > > > Then OAM and payload take exactly the same path given the same fat-pw > > label is used. If traffic is sprayed using fat-pw label, then > > randomizing the fat-pw label on OAM will check all of the paths > > (eventually). A single drop would need to be followed up by multiple > > packets using the same fat-pw label, but this is easily handled by a > > two way OAM such as LSP Ping. > %Sam - I am presuming here that OAM packet with GAL+fat-pw will take the same path as the data packet, which is with only fat-pw but no GAL. Not sure if the hashing could ignore the reserved label GAL. For example, even the presence of explicit null label could change the hashing behavior. I haven't come across any implementation which ignores reserved label for hashing. Hope I am wrong :D > > If randomizing the path selection with fat-PW is the need, is there a requirement that OAM packets should take the same path as data packet with the same fat-PW label? > > Cheers > Sam > > > > Curtis > > > > > >> -----Original Message----- > >> From: Luca Martini [mailto:lmartini@cisco.com] > >> Sent: Wednesday, April 13, 2011 10:42 PM > >> To: curtis@occnc.com > >> Cc: David Allan I; pwe3@ietf.org > >> Subject: Re: [PWE3] GAL above and below the PW label > >> > >> Curtis, > >> > >> If we keep the GAL at the bottom of the stack to flag the fact that the packet is GACH format , and not IP format, what is the problem ? > >> Surly FAT-PW would still work as most LSRs use the 2 bottom most labels to build a hash table. > >> > >> The gal = label 13 has a fixed binding to it. Do you propose that we change that ? or just the location of the label? > >> > >> Luca > >> > >> > >> > >> On 03/31/11 03:10, Curtis Villamizar wrote: > >>> In message > >>> <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsso > >>> n.se> > >>> David Allan I writes: > >>>> > >>>> HI Curtis: > >>>> > >>>> My suggestion is to avoid the GAL for PWs if it is to be a > >>>> homogenizing agent across TP and IP/MPLS domains in the form of > >>>> MS-PWs. The scenarios in which it was broken was simply a statement > >>>> of fact. > >>>> > >>>> As for the problem GAL was proposed to fix (lack of CW), there are > >>>> solutions on the table, just not palatable... > >>>> > >>>> D > >>> > >>> Dave, > >>> > >>> I think we are in agreement. > >>> > >>> We either use a non-GAL mechanism, or we fix GAL by removing the > >>> bottom of stack restriction and use GAL. > >>> > >>> I prefer the latter option, fix GAL. > >>> > >>> I support not using GAL at all in PW if GAL can't be fixed. > >>> > >>> Fixing GAL should really be an MPLS WG discussion. The result of that > >>> discussion in MPLS should gate whether any PW proposal to use GAL can > >>> be moved forward. > >>> > >>> Curtis > >>> > >>> > >>>> -----Original Message----- > >>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > >>>> Of Curtis Villamizar > >>>> Sent: Thursday, March 31, 2011 9:03 AM > >>>> To: Loa Andersson > >>>> Cc: pwe3@ietf.org > >>>> Subject: Re: [PWE3] GAL above and below the PW label > >>>> > >>>> > >>>> Loa, Dave, Sasha, > >>>> > >>>> I've snipped from various posts on the thread that Sasha started. See inline. > >>>> > >>>> In message <4D92F5D3.6080609@pi.nu> > >>>> Loa Andersson writes: > >>>>> > >>>>> All, > >>>>> > >>>>> missed a nuance in Sasha subject line. > >>>>> > >>>>> We have two issues > >>>>> > >>>>> - where the GAL is placed relative to the PW label, I believe it is > >>>>> necessary to have the GAL below the PW label. > >>>>> > >>>>> - whether the the GAL label needs to be bottom of stack or not, it > >>>>> figure that this is really a discussion if it is possible to have > >>>>> a FAT label below the GAL or not. I'm not sure about my preferences > >>>>> but I think it is possible. > >>>>> > >>>>> /Loa > >>>> > >>>> I agree with Loa's summary. Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic. > >>>> > >>>> > >>>> In message > >>>> <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericss > >>>> on.se> > >>>> David Allan I writes: > >>>>> > >>>>> It does become a new behavior, GAL with S=3D0. However the > >>>>> combination of G= AL being top label at the S-PE and TTL being > >>>>> encoded in the PW label means = that fate sharing is broken at every > >>>>> S-PE. Life only gets a little more str= ange if there is a FAT label as well... > >>>>> > >>>>> That being said, GAL as bottom label is broken in any ECMP > >>>>> environment, whi= ch is why GAL is a TP construct. > >>>>> > >>>>> my 2 cents > >>>>> D > >>>> > >>>> Dave, > >>>> > >>>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. > >>>> If all it takes to fix it is simple then lets just fix it. > >>>> > >>>> This is what we'd have to do. > >>>> > >>>> 1) Relax the requirement that GAL be at the bottom > >>>> > >>>> 2) Have the ingress insert GAL in the stack immediately below the > >>>> label for which the measurement is made, keeping the rest of the > >>>> label stack in place. > >>>> > >>>> The only thing the midpoing LSR at a multipath (LAG, link bundle for > >>>> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there. That will yield the same hash value and it will preserve fate-sharing across multipath. > >>>> > >>>> I prefer that we fix things rather than complain that they are broken. > >>>> > >>>> Curtis > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 From yaakov_s@rad.com Sat Apr 16 23:14:14 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 95971E06A8 for ; Sat, 16 Apr 2011 23:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjUKS10epGio for ; Sat, 16 Apr 2011 23:14:14 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by ietfc.amsl.com (Postfix) with ESMTP id A60F7E06A7 for ; Sat, 16 Apr 2011 23:14:12 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 17 Apr 2011 09:14:11 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sun, 17 Apr 2011 09:14:10 +0300 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Sun, 17 Apr 2011 09:12:26 +0300 From: Yaakov Stein To: "curtis@occnc.com" Thread-Topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-Index: AQHL+80FnpX7eUn6G0ucm2DFFYSuHJRhkGzQ Date: Sun, 17 Apr 2011 06:14:10 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D29381@EXRAD5.ad.rad.co.il> References: Your message of "Thu, 14 Apr 2011 15:01:11 -0000." <07F7D7DED63154409F13298786A2ADC903D288E2@EXRAD5.ad.rad.co.il> <201104160029.p3G0TeFw078601@harbor.orleans.occnc.com> In-Reply-To: <201104160029.p3G0TeFw078601@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" , Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 06:14:14 -0000 Curtis > Putting the PW into the right LSP solves the problem for SS-PW and for > the first hop of a MS-PW, but not for the middle hops of MS-PW. Yes, I agree. I must admit that I was not thinking about MS-PWs when I voi= ced my support. But how can the general MS-PW case be handled ? Assuming transit service providers to be reticent about revealing topology = information,=20 we need for the entity setting up the PW to request co-routed LSPs from eac= h transit domain. The problem then reduces to routing the PW through the S-PEs that terminate= these LSPs, and ensuring that at the S-PEs the PW is properly placed. An interesting problem arises if we want S-PE redundancy. We would need to trigger simultaneous switchovers in both directions. It would seem that the MS case would be more easily handled by management o= perations. Y(J)S From yaakov_s@rad.com Sat Apr 16 23:16:26 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A2BFBE06CD for ; Sat, 16 Apr 2011 23:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP2visLiwtxF for ; Sat, 16 Apr 2011 23:16:25 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by ietfc.amsl.com (Postfix) with ESMTP id E9821E0686 for ; Sat, 16 Apr 2011 23:16:24 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 17 Apr 2011 09:16:24 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sun, 17 Apr 2011 09:16:23 +0300 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Sun, 17 Apr 2011 09:14:39 +0300 From: Yaakov Stein To: "curtis@occnc.com" , Mach Chen Thread-Topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-Index: AQHL+8/8npX7eUn6G0ucm2DFFYSuHJRhlUkA Date: Sun, 17 Apr 2011 06:16:23 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D29395@EXRAD5.ad.rad.co.il> References: Your message of "Fri, 15 Apr 2011 02:41:34 -0000." <201104160048.p3G0mMpm078893@harbor.orleans.occnc.com> In-Reply-To: <201104160048.p3G0mMpm078893@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" , Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 06:16:26 -0000 and if the reference was to my question #1 (is it in the scope of PWE3?) I don't think a CCAMP document can provide an answer. Y(J)S -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com]=20 Sent: Saturday, April 16, 2011 03:48 To: Mach Chen Cc: Yaakov Stein; Luca Martini; pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-o= ver-bidir-lsp-02.txt=20 In message Mach Chen writes: > =20 > Hi Yaakov and Luca, > =20 > I think Section 5.3.2. "Support for Explicit Control of PW-to-LSP > Binding" of > http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06 > could answer the question #2. > =20 > Best regards, > Mach Luca's question #2 was "is this the right solution?" So mpls-tp-cp-framework does not answer that question. Curtis From yaakov_s@rad.com Sat Apr 16 23:38:54 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22B2FE06C7 for ; Sat, 16 Apr 2011 23:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3P5ISDzhfYO for ; Sat, 16 Apr 2011 23:38:53 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by ietfc.amsl.com (Postfix) with ESMTP id ED992E06A8 for ; Sat, 16 Apr 2011 23:38:52 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 17 Apr 2011 09:38:52 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sun, 17 Apr 2011 09:38:51 +0300 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Sun, 17 Apr 2011 09:37:06 +0300 From: Yaakov Stein To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: Acv7UsubNzUXHUv4SBOyP5s8BvEdxABdKXBA Date: Sun, 17 Apr 2011 06:38:51 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D293B1@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 06:38:54 -0000 > During the Prague PWE3 meeting, there was a discussion on whether=A0draft= -kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt=20 > should be adopted as a WG draft.=20 > The minutes of this discussion are posted at:=A0http://tools.ietf.org/wg/= pwe3/minutes?item=3Dminutes80.html > We would like to ask the same question on the list. I do not support making this a WG draft, as I do not believe that the effic= iency gained merits the added complexity. As an aside, the second PW device I worked on addressed bandwidth efficienc= y issues by performing speech compression on timeslots of TDM PWs, data compression on Ethernet frames for Ethernet PWs,=20 and protocol compression for various cellular framing schemes. This device once sold strongly (not surprising since ROI was less than 6 mo= nths),=20 but its sales are now limited to niche markets, such as satellite backup li= nks. Even with bandwidth reduction factors of 4 or greater,=20 the SP community no longer deems it worthwhile to perform bandwidth optimiz= ation. I remember that at the meeting Sasha proposed creating a new GRE PW type to= handle cases where the overhead of the present PPW is deemed excessive.=20 Perhaps this idea is worth discussing. Y(J)S From hejia@huawei.com Mon Apr 18 00:28:47 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9DBD7E06D3 for ; Mon, 18 Apr 2011 00:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdT8N+8Yzw+C for ; Mon, 18 Apr 2011 00:28:43 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id F188CE078D for ; Mon, 18 Apr 2011 00:28:42 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJU008Q27F9YX@szxga05-in.huawei.com> for pwe3@ietf.org; Mon, 18 Apr 2011 15:28:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJU008597F8II@szxga05-in.huawei.com> for pwe3@ietf.org; Mon, 18 Apr 2011 15:28:21 +0800 (CST) Received: from hejia ([10.70.77.134]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJU009N47F7B0@szxml06-in.huawei.com> for pwe3@ietf.org; Mon, 18 Apr 2011 15:28:20 +0800 (CST) Date: Mon, 18 Apr 2011 15:28:18 +0800 From: Jia He To: curtis@occnc.com, Luca Martini Message-id: <681080A6933146F2B1EA9033BB64B693@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <201104160037.p3G0bvuR078723@harbor.orleans.occnc.com> Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 07:28:47 -0000 Hi Cutis, > LSP label > GAL <- this is for LSP OAM > PW label > optional fat-pw label (S=1) > G-Ach If this is for LSP OAM, there is no PW label IMHO. B.R. Jia ----- Original Message ----- From: "Curtis Villamizar" To: "Luca Martini" Cc: Sent: Saturday, April 16, 2011 8:37 AM Subject: Re: [PWE3] GAL above and below the PW label > > In message <4DA71765.4060504@cisco.com> > Luca Martini writes: >> >> hello! >> >> It appears to me that it might not be clear that I also believe that >> the GAL should be at the bottom of the stack. I know that that is not >> where we have it in the -00 version of the VCCV-2 draft , but that was >> only an initial suggestion and we really wanted a good discussion on >> this list. >> >> We will update that document shortly. >> Thanks. >> Luca > > > Luca, > > Please specify below the PW label (below in the MPLS sense of bottom) > and not BOS. > > MPLS style stack orientation: > > LSP label > PW label > GAL <- this is for PW OAM > optional fat-pw label (S=1) > G-Ach > > LSP label > GAL <- this is for LSP OAM > PW label > optional fat-pw label (S=1) > G-Ach > > LSP label > PW label > optional fat-pw label (S=1) > payload > > Therefore there can consistently be a rule where GAL is under the > label for which the OAM is applied. > > If the hashing ignores reserved labels, then all three above take the > same path in the absence of fat-pw or take the same path given the > same value of the fat-pw label. > > Curtis > > >> On 04/13/11 23:41, Luca Martini wrote: >> > Curtis, >> > >> > If we keep the GAL at the bottom of the stack to flag the fact that the >> > packet is GACH format , and not IP format, what is the problem ? >> > Surly FAT-PW would still work as most LSRs use the 2 bottom most labels >> > to build a hash table. >> > >> > The gal = label 13 has a fixed binding to it. Do you propose that we >> > change that ? or just the location of the label? >> > >> > Luca >> > >> > >> > >> > On 03/31/11 03:10, Curtis Villamizar wrote: >> >> In message <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsson.se> >> >> David Allan I writes: >> >>> >> >>> HI Curtis: >> >>> >> >>> My suggestion is to avoid the GAL for PWs if it is to be a >> >>> homogenizing agent across TP and IP/MPLS domains in the form of >> >>> MS-PWs. The scenarios in which it was broken was simply a statement of >> >>> fact. >> >>> >> >>> As for the problem GAL was proposed to fix (lack of CW), there are >> >>> solutions on the table, just not palatable... >> >>> >> >>> D >> >> Dave, >> >> >> >> I think we are in agreement. >> >> >> >> We either use a non-GAL mechanism, or we fix GAL by removing the >> >> bottom of stack restriction and use GAL. >> >> >> >> I prefer the latter option, fix GAL. >> >> >> >> I support not using GAL at all in PW if GAL can't be fixed. >> >> >> >> Fixing GAL should really be an MPLS WG discussion. The result of that >> >> discussion in MPLS should gate whether any PW proposal to use GAL can >> >> be moved forward. >> >> >> >> Curtis >> >> >> >> >> >>> -----Original Message----- >> >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Curtis Villamizar >> >>> Sent: Thursday, March 31, 2011 9:03 AM >> >>> To: Loa Andersson >> >>> Cc: pwe3@ietf.org >> >>> Subject: Re: [PWE3] GAL above and below the PW label >> >>> >> >>> >> >>> Loa, Dave, Sasha, >> >>> >> >>> I've snipped from various posts on the thread that Sasha started. See inline. >> >>> >> >>> In message <4D92F5D3.6080609@pi.nu> >> >>> Loa Andersson writes: >> >>>> >> >>>> All, >> >>>> >> >>>> missed a nuance in Sasha subject line. >> >>>> >> >>>> We have two issues >> >>>> >> >>>> - where the GAL is placed relative to the PW label, I believe it is >> >>>> necessary to have the GAL below the PW label. >> >>>> >> >>>> - whether the the GAL label needs to be bottom of stack or not, it >> >>>> figure that this is really a discussion if it is possible to have >> >>>> a FAT label below the GAL or not. I'm not sure about my preferences >> >>>> but I think it is possible. >> >>>> >> >>>> /Loa >> >>> >> >>> I agree with Loa's summary. Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic. >> >>> >> >>> >> >>> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericsson.se> >> >>> David Allan I writes: >> >>>> >> >>>> It does become a new behavior, GAL with S=3D0. However the combination >> >>>> of G= AL being top label at the S-PE and TTL being encoded in the PW >> >>>> label means = that fate sharing is broken at every S-PE. Life only >> >>>> gets a little more str= ange if there is a FAT label as well... >> >>>> >> >>>> That being said, GAL as bottom label is broken in any ECMP >> >>>> environment, whi= ch is why GAL is a TP construct. >> >>>> >> >>>> my 2 cents >> >>>> D >> >>> >> >>> Dave, >> >>> >> >>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >> >>> If all it takes to fix it is simple then lets just fix it. >> >>> >> >>> This is what we'd have to do. >> >>> >> >>> 1) Relax the requirement that GAL be at the bottom >> >>> >> >>> 2) Have the ingress insert GAL in the stack immediately below the >> >>> label for which the measurement is made, keeping the rest of the >> >>> label stack in place. >> >>> >> >>> The only thing the midpoing LSR at a multipath (LAG, link bundle for >> >>> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there. That will yield the same hash value and it will preserve fate-sharing across multipath. >> >>> >> >>> I prefer that we fix things rather than complain that they are broken. >> >>> >> >>> Curtis > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From renwei.li@huawei.com Mon Apr 18 10:26:34 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4CC7E06F8 for ; Mon, 18 Apr 2011 10:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uP6bvta1uum for ; Mon, 18 Apr 2011 10:26:33 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfc.amsl.com (Postfix) with ESMTP id 22494E06E4 for ; Mon, 18 Apr 2011 10:26:33 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJU00GW2Z485N@usaga04-in.huawei.com> for pwe3@ietf.org; Mon, 18 Apr 2011 12:26:32 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LJU00GJMZ47DT@usaga04-in.huawei.com> for pwe3@ietf.org; Mon, 18 Apr 2011 12:26:32 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 10:26:31 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.75]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 10:26:31 -0700 Date: Mon, 18 Apr 2011 17:26:31 +0000 From: Renwei Li In-reply-to: X-Originating-IP: [10.193.34.55] To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_R1mDyBKX1IOzttu94gp78Q)" Content-language: en-US Accept-Language: en-US Thread-topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-index: Acv7UsubNzUXHUv4SBOyP5s8BvEdxACmZSig X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:26:35 -0000 --Boundary_(ID_R1mDyBKX1IOzttu94gp78Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I'd like to support it for multiple reasons: - It minimizes the chance of having an MPLS-encapsulated packet fragmented in the network due to the MTU limit, since the header is smaller and thus the whole packet size is smaller. - In addition to the bandwidth efficiency the author claims, I believe that it can be used to support heterogeneous ACs. For example, on one side the AC is Ethernet while the other side AC is ATM AAL5 (I would appreciate it if the authors could confirm it) - I have heard of some proprietary implementations for IP packet over PWE3 from different vendors. A spec like this could be used as a basis for inter-op. Thanks, Renwei ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Friday, April 15, 2011 2:52 AM To: pwe3@ietf.org Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt During the Prague PWE3 meeting, there was a discussion on whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3/minutes?item=minutes80.html We would like to ask the same question on the list. Please post any comments before April 29th. Regards, Matthew & Andy --Boundary_(ID_R1mDyBKX1IOzttu94gp78Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I’d like to support it for multiple reasons:

 

-          It minimizes the chance of having an MPLS-encapsulated packet fragmented in the network due to the MTU limit, since the header is smaller and thus the whole packet size is smaller.

-          In addition to the bandwidth efficiency the author claims, I believe that it can be used to support heterogeneous ACs. For example, on one side the AC is Ethernet while the other side AC is ATM AAL5 (I would appreciate it if the authors could confirm it)

-          I have heard of some proprietary implementations for IP packet over PWE3 from different vendors. A spec like this could be used as a basis for inter-op.

 

 

 Thanks,

 

Renwei

 

 

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, April 15, 2011 2:52 AM
To: pwe3@ietf.org
Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

 

During the Prague PWE3 meeting, there was a discussion on whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3/minutes?item=minutes80.html

 

We would like to ask the same question on the list.

 

Please post any comments before April 29th.

 

Regards,

 

Matthew & Andy

 

--Boundary_(ID_R1mDyBKX1IOzttu94gp78Q)-- From stbryant@cisco.com Mon Apr 18 10:43:27 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 551B4E07FA for ; Mon, 18 Apr 2011 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.662 X-Spam-Level: X-Spam-Status: No, score=-110.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykyYC10+9ncI for ; Mon, 18 Apr 2011 10:43:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 06637E07F7 for ; Mon, 18 Apr 2011 10:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=23732; q=dns/txt; s=iport; t=1303148603; x=1304358203; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kk/y19ueSjFsqlxfbUds3Qj7sT7qj7Isgz71vYbsF2g=; b=PSwK8SqgZ5LO0P2DSEjnwaeoud6HF/5D77rDRrnQ8QKZR+mdrFB6BdVY 9UGR+lZK0YqPeod+cZSwe+Tq5l9lL9pb8ozYxb8kpsOQAE+sx+nzClBWC 3Zgqy1AkH7ySTcBpF+w01sdUyHyPmwZC9ROSRNShj6Ko9sRAdSa+1G3oJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcEAJd3rE2Q/khMgWdsb2JhbAClNhQBARYmJYhvnniCdA4BmS6DLgKCQQSOAg X-IronPort-AV: E=Sophos;i="4.64,233,1301875200"; d="scan'208";a="84066448" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2011 17:43:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3IHhKxP030240; Mon, 18 Apr 2011 17:43:20 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p3IHhHU18971; Mon, 18 Apr 2011 18:43:18 +0100 (BST) Message-ID: <4DAC7835.20701@cisco.com> Date: Mon, 18 Apr 2011 18:43:17 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Adrian.Farrel@huawei.com References: <031001cbbfb4$ef961500$cec23f00$@huawei.com> <4D9E08FA.7090000@cisco.com> <032301cbfb8c$f31209f0$d9361dd0$@huawei.com> In-Reply-To: <032301cbfb8c$f31209f0$d9361dd0$@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org, pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-fat-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:43:27 -0000 >>> The use of the TC bits (formerly known as the EXP bits) in the flow >>> label is outside the scope of this document. Unless otherwise agreed >>> by the ingress and egress PEs these bits MUST be set to zero by the >>> ingress PE and MUST be ignored by the egress PE. >>> >>> "Out of scope" seems to be different from the subsequent statement about >>> how he TC field must be treated. I am also not clear why the TTL >>> discussion is different from the TC discussion. >> Ah, there was a lot of discussion about this is the WG, with some >> proposals to use them for signaling of state along the LSP. I was >> pushing back on this on MPLS architectural grounds and the text >> here was the result of some discussion in WG LC. > I hear you when you say that the WG consensus asked you to add text "against > your better judgement" :-0 > > But the text you have added is conflicted. Can I suggest... > > This document does not define a use for the TC bits (formerly known > as the EXP bits) in the flow label. Future documents may define a > use for these bits, therefore implementations conforming to this > specification MUST set the TC bits to zero at the ingress and MUST > ignore them at the egress. > Done > >>> Section 1 para 1 >>> >>> the use of ECMP paths for is known to be >>> beneficial (and not harmful) to the operation of the PW. >>> >>> ?? >> The (and not harmful) was a heads up to the reader that in >> some cases it is harmful, and that it is assumed that the >> reader would know when this was the case and use the >> mechanism. >> >> We could delete the parenthetical remark, but it is harmless >> other than perhaps as an offense to the English. > It was "for is known" that puzzled me. The text now says: "The new capability proposed in this document is an OPTIONAL mode which may be used when the use of ECMP is known to be beneficial (and not harmful) to the operation of the PW." > >>> Section 1 >>> >>> Such pseudowire's do not require strict ordering to >>> be preserved between packets of the pseudowire. They only require >>> ordering to be preserved within the context of each individual >>> transported IP flow. >>> >>> I see where this is going, but the first sentence is massively more >>> relaxed than the second! How about turning it around... >>> >>> Such pseudowires only require packet ordering to be preserved within >>> the context of each individual transported IP flow. They do not >>> require packet ordering to be preserved between all packets of the >>> across all IP flows within the pseudowire. >> Changed to >> These PWs only require packet ordering to be preserved within >> the context of each individual transported IP flow. They do not >> require packet ordering to be preserved between all packets of >> across all IP flows within the pseudowire. > s/of across/of/ > or > s/of across/across/ > Did the first of these > > >> The reason that we say "Some operators" is because this was an >> operator initiated, not a vendor initiated project. >> >> I have changed this to >> >> OLD >> Some operators have requested the ability to explicitly configure such a >> PW to leverage the availability of multiple ECMPs. This allows for >> better capacity planning as the statistical multiplexing of a larger >> number of smaller flows is more efficient than with a smaller set of >> larger flows. Although Ethernet is used as an example above, the >> mechanisms described in this draft are general mechanisms that may be >> applied to any PW type in which there are identifiable flows, and in >> which there is no requirement to preserve the order between those flows. >> NEW >> The ability to explicitly configure such a PW to leverage the >> availability of multiple ECMPs allows for better capacity planning as >> the statistical multiplexing of a larger number of smaller flows is more >> efficient than with a smaller set of larger flows. Although Ethernet is >> used as an example above, the mechanisms described in this draft are >> general mechanisms that may be applied to any PW type in which there are >> identifiable flows, and in which there is no requirement to preserve the >> order between those flows. >> END > Perfect (except see below) > >>> Please don't use the word "draft" in the text as it creates work for the >>> RFC Editor and might get missed in the publication process. Obviously, by >>> the time this is published as an RFC it will no longer be a draft. Best >>> thing to do is search and replace "draft" with "document". >>> >> Done. It was an error. Tutorial not required :) > Hmmm. > Except... > See the previous paragraph that you suggested }:-Z It's the order that you apply the edits that counts :) - Text is good. > > >>> Section 3 >>> >>> It is recommended that the method chosen to >>> generate the load balancing labels introduces a high degree of >>> entropy in their values, to maximise the entropy presented to the >>> ECMP path selection mechanism in the LSRs in the PSN, and hence >>> distribute the flows as evenly as possible over the available PSN >>> ECMP paths. >>> >>> It isn't clear to me that entropy is necessarily a good thing. It >>> depends on the hash algorithm, doesn't it. >> Entropy is a good thing (TM) in this application .. and the quality of the >> entropy is a function of the quality of the hash algorithm. > Maybe the bad hash algorithms are so bad that we don't need to pursue this. But > you could also add (not mandatory to add): > > "Although this document does not attempt to specify any hash algorithms, it is > suggested that any such algorithm should be based on the assumption that there > will be a high degree of entropy in the values assigned to the load balancing > labels." > Done. > > >>> Section 4 >>> >>> Do you not think that you should say that the new sub-TLV is carried in >>> the Interface Parameters TLV, and on which messages? >> The text is consistent with the other PW definitions and the reader >> has already been referred to RFC4447. > Well, I was confused :-) > > I would: > OLD > When using the signalling procedures in [RFC4447], a Pseudowire > Interface Parameter Flow Label Sub-TLV (FL Sub-TLV) type is used to > synchronise the flow label states between the ingress and egress PEs. > NEW > When using the signalling procedures in [RFC4447], a new Pseudowire > Interface Parameter Sub-TLV, the Flow Label Sub-TLV (FL Sub-TLV), is > used to synchronise the flow label states between the ingress and > egress PEs. > END > > That may look like a small change, but it would have made reading a lot easier. > Done >>> Section 4.1 >>> >>> o FL is the flow label sub-TLV identifier assigned by IANA. >>> >>> Can you either put in a [TBD] flag so the RFC Editor will catch this, >>> or a forward pointer to section 10. >> I put in the value 0x17 since it's already been allocated. >> >> I change the IANA section to say: >> >> "IANA is requested to amend the PW Interface Parameters Sub-TLV type >> Registry value 0x17 (Flow Label indicator) to refer to this RFC." > OK about putting "17" in section 4.1 > IANA discussed further under section 10. Added 0x17 to the figure and a ref to section 10 (now section 11) > > >>> Section 6 >>> >>> We believe that this >>> problem is addressed by the following two methods >>> >>> I would like you to be more definitive, please. >> How about >> >> This problem is mitigated by the following two considerations: > Not really :-( > The second bulletin particular is not a mitigation at all. > See below for suggested text. > >>> But, that said, the subsequent bullets do not provide methods of >>> addressing OAM in this case. Rather, the text attempts to say why >>> the problem is not important. In my opinion it fails since, although >>> ECMP is out of scope for MPLS-TP, a user has reasonable expectations >>> that some of the flows on their PW will not be wiped out for the IGP >>> convergence period, when (for example) rapid notification followed >>> by change of the flow label could cause the traffic to be balanced >>> differently and avoid the failure, >> I have added >> Note that this period may be reduced if a fast re-route or fast >> convergence technology is deployed in the network [RFC4090],[RFC5286]. > OK > >>> or when a partial failure of a PW >>> could trigger a switch to a different PW. >> Well there are two problems here: >> >> 1) The whole point is that it's difficult to constantly monitor >> all paths. >> >> 2) It's not clear that the new PW would be diverse when the FL is >> taken into a/c. > So what you are saying is that "OAM cannot be used under all circumstances to > verify that a pseudowire is fully functional" > > I think we can handle this through: > OLD > Where it is required to verify that a pseudowire is fully functional > for all flows, VCCV [RFC5085] connection verification message MUST be > sent over each ECMP path to the pseudowire egress PE. This problem > is difficult to solve and scales poorly. We believe that this > problem is addressed by the following two methods: > > 1. If a failure occurs within the PSN, this failure will normally be > detected by the PSN's Interior Gateway protocol (IGP) link/node > failure detection mechanism (loss of light, bidirectional > forwarding detection [RFC5880] or IGP hello detection), and the > IGP convergence will naturally modify the ECMP set of network > paths between the Ingress and Egress PE's. Hence the PW is only > impacted during the normal IGP convergence time. > > 2. If the failure is related to the individual corruption of an > Label Forwarding Information database (LFIB) entry in a router, > then only the network path using that specific entry is impacted. > If the PW is load balanced over multiple network paths, then this > failure can only be detected if, by chance, the transported OAM > flow is mapped onto the impacted network path, or all paths are > tested. This type of error may be better solved be solved by > other means such as LSP self test [I-D.ietf-mpls-lsr-self-test]. > YOURS > Where it is required to verify that a pseudowire is fully functional > for all flows, VCCV [RFC5085] connection verification message MUST be > sent over each ECMP path to the pseudowire egress PE. This problem > is difficult to solve and scales poorly. This problem is mitigated > by the following two considerations: > > 1. If a failure occurs within the PSN, this failure will normally be > detected by the PSN's Interior Gateway protocol (IGP) link/node > failure detection mechanism (loss of light, bidirectional > forwarding detection [RFC5880] or IGP hello detection), and the > IGP convergence will naturally modify the ECMP set of network > paths between the Ingress and Egress PE's. Hence the PW is only > impacted during the normal IGP convergence time. Note that this > period may be reduced if a fast re-route or fast convergence > technology is deployed in the network [RFC4090],[RFC5286]. > > 2. If the failure is related to the individual corruption of an > Label Forwarding Information database (LFIB) entry in a router, > then only the network path using that specific entry is impacted. > If the PW is load balanced over multiple network paths, then this > failure can only be detected if, by chance, the transported OAM > flow is mapped onto the impacted network path, or all paths are > tested. This type of error may be better solved be solved by > other means such as an LSP self test technology. > NEW > Where it is required to verify that a pseudowire is fully functional > for all flows, VCCV [RFC5085] connection verification message MUST be > sent over each ECMP path to the pseudowire egress PE. This solution > may be difficult to achieve and scales poorly. > > Under these circumstances, it may be sufficient to send VCCV messages > using any load balance pseudowire path because if a failure occurs > within the PSN the failure will normally be detected and repaired by > the PSN. That is, the PSN's Interior Gateway protocol (IGP) > link/node failure detection mechanism (loss of light, bidirectional > forwarding detection [RFC5880] or IGP hello detection), and the IGP > convergence will naturally modify the ECMP set of network paths > between the Ingress and Egress PE's. Hence the PW is only impacted > during the normal IGP convergence time. Note that this period may be > reduced if a fast re-route or fast convergence technology is deployed > in the network [RFC4090],[RFC5286]. > > If the failure is related to the individual corruption of a Label > Forwarding Information database (LFIB) entry in a router, then only > the network path using that specific entry is impacted. If the PW > is load balanced over multiple network paths, then this failure can > only be detected if, by chance, the transported OAM flow is mapped > onto the impacted network path, or if all paths are tested. Since > testing all paths may present problems as noted above, other > mechanisms to detect this type of error may need to be developed, > such as an LSP self test technology. > END > Done >>> s/Figure 4: Use of Router Alert LAbel/Figure 4: Use of Router Alert Label/ > ?? Done >>> Figure 4 >>> >>> Shouldn't "payload" actually read "VCCV message"? > ?? Done > >>> If these methods are so well known, you will have no difficulty in >>> supplying a reference or two. >> I am fairly sure that there is no IETF reference to this. It something >> that all the vendors do (differently), but there has always been strong >> resistance to the publication of a standard. >>> I think you have mixed the method of identifying the flows with the >>> method of hashing the flows into buckets. >> The text now says: >> >> Where it is known that the traffic carried by the Ethernet PW is IP the >> method of identifying the flows and mapping them to an ECMP are well >> known and can be applied. Such methods are typically include hashing on >> the source and destination addresses, the protocol ID and higher-layer >> flow-dependent fields such as TCP/UDP ports, L2TPv3 Session ID's etc. > Is OK, although I would prefer to remove the "well known" bit. > > NEW > Where it is known that the traffic carried by the Ethernet PW is IP the > flows can be identified and mapped to an ECMP. Such methods typically > include hashing on the source and destination addresses, the protocol > ID and higher-layer flow-dependent fields such as TCP/UDP ports, L2TPv3 > Session ID's etc. > END > > Not required that you take this change, but s/are typically/typically/ Done >>> Section 7.1 >>> >>> In the ECMP case and the link bundling case the NSP may attempt to >>> take bandwidth into consideration when allocating groups of flows to >>> a common path. That is permitted, but it must be borne in mind that >>> the semantics of a label stack entry (LSE) as defined by [RFC3032] >>> cannot be modified, the value of the flow label cannot be modified at >>> any point on the LSP, and the interpretation of bit patterns in, or >>> values of, the flow label by an LSR are undefined. >>> >>> If you have something to say, you should say it. Otherwise your paragraph >>> is lost on your readers. >>> I think you are trying to say "There is no mechanism currently defined >>> to indicate the bandwidths in use by specific flows using the fields of >>> the MPLS shim header. Furthermore, since the semantics of the MPLS shim >>> header are fully defined in [RFC3032] and [RFC5462], those fields cannot >>> be assigned semantics to carry this information. This document does not >>> define any semantic for use in the TTL or TC fields of the label entry >>> that carries the flow label, but requires that the flow label itself >>> be selected with a high degree of entropy suggesting that the label >>> value should not be overloaded with additional meaning in any subsequent >>> specification." >> OK works for me, but the WG should note the change of wording. > Yup WG please note. >>> Section 7.1 >>> >>> A different type of load balancing is the desire to carry a >>> pseudowire over a set of PSN links in which the bandwidth of members >>> of the link set is less than the bandwidth of the pseudowire. This >>> problem is addressed in [I-D.stein-pwe3-pwbonding]. Such a mechanism >>> can be considered complementary to this mechanism. >>> >>> The referenced I-D seems to be dead. I'm not quite sure why you need to >>> reference it here. How about just taking out the paragraph? >> It's in there as a result of WG discussion > If the WG intends to adopt the I-D and run with it, that is fine (provided > in-charter, and they actually do it). > Otherwise the reference is a problem. Maybe the sentence containing the > reference can be removed? It now says: Proposals to address this problem have been made in the past [I-D.stein-pwe3-pwbonding]. Such a mechanism can be considered complementary to this mechanism. The reference is info, so not blocking and anyone wishing to find the ref can do so even though it is more than 6mths old. >>> Section 7.2 appears to describe exactly the link bundling case that you >>> discussed in section 7. I have recently noticed considerable confusion >>> between link bundles and LAG and suggest you restrict LAG to be a data >>> link function that is below the level of an "interface" in the IP/MPLS >>> world. That does not mean that an individual node, knowing (by >>> unspecified means) that it is about to use an interface that is >>> constructed from a LAG, can't hash the traffic across the LAG. >>> >>> Ultimately, you should consider ECMP (i.e. multiple IGP paths) where >>> each hop on each path may be made a link bundle, and where each >>> component link of a bundle may be supported by LAG. >>> >>> Can you go back and check that you have used the language precisely. >> The text was added as a result of WG discussion where it was proposed >> that LAG might use the FL as a key in member selection. > Unclear whether you are saying that you think the language *is* precise, or that > you have adopted text generated in the WG and are stuck with it. In the former > case, I'm done. in the latter case my question is extended to the WG. > > [Perhaps we will need to extract a couple of questions from this I-D to go to > the WG in a separate thread?] OK. >>> "Too deeply buried" meaning "If the NSP cannot access sufficient >>> information to distinguish flows, perhaps because the protocol stack >>> is too deep for its capabilities..."? >>> >>> Is the statement about "no harm" necessary? After all, the mechanism >>> will simply not be used in this case. >> Text was added as a result of WG discussion on benefits and usage of the >> mechanism. > OK. > I still think some explanation of "too deeply buried" would be beneficial. Removed the harm statement, and changed words. It now says "If the NSP cannot access sufficient information to distinguish flows, perhaps because the protocol stack required parsing further into the packet than it is able, then the functionality described in this document does not give any benefits. " > > >>> s/a large single TCP flows/large TCP flows/ >> Again this was WG agreed text > Well, really. Does the WG insist on publishing stuff that is not in English? > What will happen during RFC Editor processing? > > Please select from: > - a single, large TCP flow > - large TCP flows > > Ask the WG if you feel the need, although to me it is a typo that has introduced > ambiguity. Used "a single, large TCP flow" > > >>> Section 7.4 >>> >>> 5. The operator could configure the ingress to assign a label of >>> special significance (such as a reserved label) to all high >>> bandwidth flows so that some other action (not specified in this >>> document) could be taken on the flow. >>> >>> I think you need to delete this as it contradicts two specific >>> statements made elsewhere... >>> >>> 1. MUST NOT use a reserved label as the flow label >>> 2. MUST NOT assign semantics to the flow label >> I have deleted (such as a reserved label). >> >> This was added as a result of WG discussion. I think that the idea >> was to use a label from the per platform space. > OK. > Need to check back with the WG? Given that the idea has not developed since it was initially proposed I have deleted it, but will put it back if the WG request me to do so. > > >>> Section 9 >>> >>> The ingress PE SHOULD take steps to ensure that the load-balance >>> label is not used as a covert channel. >>> >>> Again, you are saying something between the lines :-( >> No, just warning that a badly implemented hash could have side effects. >>> Since the ingress PE allocates the label (isn't it called the flow label >>> not the load-balance label?) the "SHOULD take steps" is very odd! And >>> why is this a security requirement? How would security be compromised? >> Yes - LB label was an older name for it. >> >> I can take it out, or we can leave it to SECdir to advise. > I have been looking at covert channels a bit recently (not my favourite) and the > problem with requesting that the ingress PE take steps to avoid the label being > used as a covert channel is that there is not much that can be done by the > ingress to protect the label being changed within the network. > > The same arguments will apply to the TTL and TC of the flow label. > > The TTL and TC can be enforced by the *egress* mandating that the received > packets all have specific TTL and TC settings in the flow label. > The flow label value can only be enforced by the ingress and egress negotiating > which flow label values are in use. > > Maybe: > > NEW > The flow label value and the TTL and TC of the flow label LSE provide the > potential for the creation of a covert channel. An egress PE MAY monitor the > values received and report fluctuations as potential symptoms of an attack. > END Ingress and egress may be in a pact. I will delete the sentence and see what the Security directorate say. > >>> Section 10 >>> >>> Please change this text to reference early allocation that has been >>> made for you. Note that the value 17 has NOT been assigned (although >>> the value 0x17 has). >> Changed - it's actually ER - and has been allocated. > So it would be helpful to tell IANA in this section that they have already made > an allocation using whatever policy. It now says IANA is requested to amend the PW Interface Parameters Sub-TLV type Registry value 0x17 (Flow Label indicator) to refer to this RFC. I will compile and post, then hand the draft back to Matthew to see what he wants to check with the WG. Thanks for the careful review. - Stewart From sriganeshkini@gmail.com Mon Apr 18 11:29:38 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DA3EFE070A for ; Mon, 18 Apr 2011 11:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrufoXr9w3oi for ; Mon, 18 Apr 2011 11:29:37 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfc.amsl.com (Postfix) with ESMTP id A8DC2E0684 for ; Mon, 18 Apr 2011 11:29:37 -0700 (PDT) Received: by qyk29 with SMTP id 29so1175819qyk.10 for ; Mon, 18 Apr 2011 11:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=fhDQ7H/tHaHhB3heC6CPvMOwxFBIfofSrOu5e7pi+Wk=; b=H88zG5KKSyLJXJG8rFeLcJrUZ6k4IZBkR8CNTGnQmkcW7tG8BEkvgUkXDb9VaIUAWU Fj3/h2Tk5nnnjF/IwAH/WKPqkr8E0IbQMOT4/I7ULWuI3doQbJLntlHSNGTkm6nTA6CF pvXpYX5Sienzbo/dHrgY1pcFo1HpfaeZKZRaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=BPMgWE+Fynbx1cWQBqPdsKc9L645iJFa+sgKuTald56VCmjcoDrFw/GuXej6EX8qHU rBYTsVU78RzRYlyReUhdA4TSAyUIty7a0wua25NFZtAxDPfqFtFO+XFMhHoJE50u56JT q60yvBBZJAHGTFiL+v8r2ax/pitvanHLP5n14= Received: by 10.224.184.1 with SMTP id ci1mr2931250qab.129.1303151377137; Mon, 18 Apr 2011 11:29:37 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.188.204 with HTTP; Mon, 18 Apr 2011 11:29:06 -0700 (PDT) In-Reply-To: References: From: Sriganesh Kini Date: Mon, 18 Apr 2011 11:29:06 -0700 X-Google-Sender-Auth: HhX3GoV_J1uT1edeuivj1FFJILc Message-ID: To: Renwei Li Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:29:39 -0000 Thanks Renwei. Correct that this encapsulation can be used for heterogeneous packet ACs such as ethernet and ATM-AAL5. On Mon, Apr 18, 2011 at 10:26 AM, Renwei Li wrote: > I=92d like to support it for multiple reasons: > > > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 It minimizes the chance of having an MPLS-en= capsulated packet > fragmented in the network due to the MTU limit, since the header is small= er > and thus the whole packet size is smaller. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 In addition to the bandwidth efficiency the = author claims, I > believe that it can be used to support heterogeneous ACs. For example, on > one side the AC is Ethernet while the other side AC is ATM AAL5 (I would > appreciate it if the authors could confirm it) > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 I have heard of some proprietary implementat= ions for IP packet > over PWE3 from different vendors. A spec like this could be used as a bas= is > for inter-op. > > > > > > =A0Thanks, > > > > Renwei > > > > > > > > ________________________________ > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Bocci, Matthew (Matthew) > Sent: Friday, April 15, 2011 2:52 AM > To: pwe3@ietf.org > Subject: [PWE3] Discussion on > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > > > > During the Prague PWE3 meeting, there was a discussion on > whether=A0draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be ad= opted > as a WG draft. The minutes of this discussion are posted > at:=A0http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html > > > > We would like to ask the same question on the list. > > > > Please post any comments before April 29th. > > > > Regards, > > > > Matthew & Andy > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --=20 - Sri From stbryant@cisco.com Mon Apr 18 12:15:26 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC0B0E0694 for ; Mon, 18 Apr 2011 12:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.659 X-Spam-Level: X-Spam-Status: No, score=-110.659 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQg0nIRG6lQ6 for ; Mon, 18 Apr 2011 12:15:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 07F9EE0670 for ; Mon, 18 Apr 2011 12:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=7961; q=dns/txt; s=iport; t=1303154125; x=1304363725; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=ZlazQnU3sNpMhVNVap8b3IZvJXYZr0X9H5YFfdgYc84=; b=eEB5GtgKNOYpTMj4P0We6nSevBL31vMG1scxTpbALL7pnyK1oGkUFcgL jmtJLZCnjYPOmZidLIXYycpxbiMbH0ZB+2yLTNB1sbo2PcxR5pWZVD3xn 6gVZJEcAUmRzXpGteRTkj1yao5O8oX8Qi3UADQxYMoQYhvGC5yxrLRJKX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugDAJ+MrE2Q/khLgWdsb2JhbACCYqJYFAEBFiYlqBSCdA4BmUCFcQSOAA X-IronPort-AV: E=Sophos;i="4.64,234,1301875200"; d="scan'208,217";a="84075209" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2011 19:15:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3IJFOe2012923; Mon, 18 Apr 2011 19:15:24 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p3IJFMU24929; Mon, 18 Apr 2011 20:15:22 +0100 (BST) Message-ID: <4DAC8DCA.9080003@cisco.com> Date: Mon, 18 Apr 2011 20:15:22 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Renwei Li References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030503050408020801080501" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:15:27 -0000 This is a multi-part message in MIME format. --------------030503050408020801080501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 18/04/2011 18:26, Renwei Li wrote: > > I'd like to support it for multiple reasons: > > -It minimizes the chance of having an MPLS-encapsulated packet > fragmented in the network due to the MTU limit, since the header is > smaller and thus the whole packet size is smaller. > There is no fragmentation of MPLS packets. > > -In addition to the bandwidth efficiency the author claims, I believe > that it can be used to support heterogeneous ACs. For example, on one > side the AC is Ethernet while the other side AC is ATM AAL5 (I would > appreciate it if the authors could confirm it) > Both pkt PW methods do that. That is one of their purposes. > > -I have heard of some proprietary implementations for IP packet over > PWE3 from different vendors. A spec like this could be used as a basis > for inter-op. > Both pkt PW methods do that. - Stewart --------------030503050408020801080501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 18/04/2011 18:26, Renwei Li wrote:

I’d like to support it for multiple reasons:

 

-          It minimizes the chance of having an MPLS-encapsulated packet fragmented in the network due to the MTU limit, since the header is smaller and thus the whole packet size is smaller.

There is no fragmentation of MPLS packets.

-          In addition to the bandwidth efficiency the author claims, I believe that it can be used to support heterogeneous ACs. For example, on one side the AC is Ethernet while the other side AC is ATM AAL5 (I would appreciate it if the authors could confirm it)

Both pkt PW methods do that. That is one of their purposes.

-          I have heard of some proprietary implementations for IP packet over PWE3 from different vendors. A spec like this could be used as a basis for inter-op.

 

Both pkt PW methods do that.

- Stewart
--------------030503050408020801080501-- From jdrake@juniper.net Mon Apr 18 13:17:47 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 878E4E0710 for ; Mon, 18 Apr 2011 13:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.259 X-Spam-Level: X-Spam-Status: No, score=-6.259 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9WCGoxkUOcy for ; Mon, 18 Apr 2011 13:17:46 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfc.amsl.com (Postfix) with ESMTP id E4C67E0708 for ; Mon, 18 Apr 2011 13:17:45 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTaycZrTnWFo61GSHXPcYzr9QtgPLyCoK@postini.com; Mon, 18 Apr 2011 13:17:46 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 18 Apr 2011 13:13:37 -0700 From: John E Drake To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Mon, 18 Apr 2011 13:15:40 -0700 Thread-Topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: Acv7UsubNzUXHUv4SBOyP5s8BvEdxACskrmg Message-ID: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A0968BF724EMBX01HQjnprn_" MIME-Version: 1.0 Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:17:47 -0000 --_000_5E893DB832F57341992548CDBB333163A0968BF724EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthew, I don't think this should adopted as a WG draft. The right way to do this = is to use the packet transport service described in section 3.4.5 of RFC592= 1. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Friday, April 15, 2011 2:52 AM To: pwe3@ietf.org Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-0= 2.txt During the Prague PWE3 meeting, there was a discussion on whether draft-kin= i-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. = The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3= /minutes?item=3Dminutes80.html We would like to ask the same question on the list. Please post any comments before April 29th. Regards, Matthew & Andy --_000_5E893DB832F57341992548CDBB333163A0968BF724EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthew,

 

I don’t think thi= s should adopted as a WG draft.  The right way to do this is to use th= e packet transport service described in section 3.4.5 of RFC5921.

 

Thanks,

 

John =

 

Sent from my iPhone

 

<= p class=3DMsoNormal>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org= ] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, Apri= l 15, 2011 2:52 AM
To: pwe3@ietf.org
Subject: [PWE3] Di= scussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

 

During the Prague PWE3 meeting, there was a discussion o= n whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be= adopted as a WG draft. The minutes of this discussion are posted at: = htt= p://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html

 

We would like to ask the same question on= the list.

&= nbsp;

Please post any = comments before April 29th.

 

Regards,

&= nbsp;

Matthew & An= dy

 

= --_000_5E893DB832F57341992548CDBB333163A0968BF724EMBX01HQjnprn_-- From wim.henderickx@alcatel-lucent.com Mon Apr 18 14:25:55 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5F22EE0761 for ; Mon, 18 Apr 2011 14:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfrIhwFLEA+T for ; Mon, 18 Apr 2011 14:25:53 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfc.amsl.com (Postfix) with ESMTP id 4A20FE0775 for ; Mon, 18 Apr 2011 14:25:50 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3ILPnbA029721 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Apr 2011 23:25:49 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 18 Apr 2011 23:25:49 +0200 From: "Henderickx, Wim (Wim)" To: John E Drake , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Mon, 18 Apr 2011 23:25:46 +0200 Thread-Topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: Acv7UsubNzUXHUv4SBOyP5s8BvEdxACskrmgAAJrNtA= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D671851810F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D671851810FFRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:25:55 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D671851810FFRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi *, I agree with John (No support for adopting this work). The slightly better = overhead does not pay off for the complexities introduced with this solutio= n. A packet transport service is a better solution for this problem. Cheers, Wim From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Joh= n E Drake Sent: maandag 18 april 2011 22:16 To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mp= ls-02.txt Matthew, I don't think this should adopted as a WG draft. The right way to do this = is to use the packet transport service described in section 3.4.5 of RFC592= 1. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Friday, April 15, 2011 2:52 AM To: pwe3@ietf.org Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-0= 2.txt During the Prague PWE3 meeting, there was a discussion on whether draft-kin= i-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. = The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3= /minutes?item=3Dminutes80.html We would like to ask the same question on the list. Please post any comments before April 29th. Regards, Matthew & Andy --_000_14C7F4F06DB5814AB0DE29716C4F6D671851810FFRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi *,

&nbs= p;

I agree with John (No suppor= t for adopting this work). The slightly better overhead does not pay off fo= r the complexities introduced with this solution. A packet transport servic= e is a better solution for this problem.

Cheers,

Wim

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] O= n Behalf Of John E Drake
Sent: maandag 18 april 2011 22:16To: Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: = [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

 

Matthew,

 

I don’= ;t think this should adopted as a WG draft.  The right way to do this = is to use the packet transport service described in section 3.4.5 of RFC592= 1.

 

Thanks,

 

John=

 =

Sent from my iPhone<= /p>

 

From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: = Friday, April 15, 2011 2:52 AM
To: pwe3@ietf.org
Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt<= o:p>

 

=

During the Prague PWE3 meeting, there was a = discussion on whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.t= xt should be adopted as a WG draft. The minutes of this discussion are post= ed at: http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html

 

We would like to ask the same= question on the list.

 

Plea= se post any comments before April 29th.

 

Regards,

=  

Matth= ew & Andy

 

= --_000_14C7F4F06DB5814AB0DE29716C4F6D671851810FFRMRSSXCHMBSB1d_-- From sriganeshkini@gmail.com Mon Apr 18 15:12:54 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4BC61E071D for ; Mon, 18 Apr 2011 15:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTwDlUmGTz7x for ; Mon, 18 Apr 2011 15:12:53 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfc.amsl.com (Postfix) with ESMTP id A2E56E0660 for ; Mon, 18 Apr 2011 15:12:53 -0700 (PDT) Received: by qyk29 with SMTP id 29so1280745qyk.10 for ; Mon, 18 Apr 2011 15:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ZRR/tes9liHMeH8XVkFWavyDj3zUDflXCNepxfcKzR8=; b=gwiqvMp1URjxmYrSTSz05O3HjS3kTn67Rkmdu+g1mg/9uIn/Vb+x6zmkGB54rkwY+G QoWS1Z5XOeJ9p4stxMr1Eb3rgZRCWMPqhTPn9c3Y4NHBj3rfbHqOC3VyHAAdHK5LETbB 938gaf4qd8zXNIUIrAI211yg9S3v/XtYJjU1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=ZF681u1CBIVMhB4UeNipj3E+yBV9IFzGH5PrpTVcOlEOam7zqZ77vWWOswIzdY5h/N VoVu+PPD6WUYnF4EFV4uZXVqTcnCZe/NOu+XA96Km9/su/x/uodhINxHAm5aMPH/W9ak jMpdpHHKv5IigVhX+LBPE3B5zBZ44bNxiRYnU= Received: by 10.229.29.129 with SMTP id q1mr3841950qcc.295.1303164773156; Mon, 18 Apr 2011 15:12:53 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.188.204 with HTTP; Mon, 18 Apr 2011 15:12:23 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> From: Sriganesh Kini Date: Mon, 18 Apr 2011 15:12:23 -0700 X-Google-Sender-Auth: hX44kefrsKTQPyt21u6uxfYHiTs Message-ID: To: John E Drake Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:12:54 -0000 John, Are you suggesting that instead of (packet) PW adaptation, the network layer adaptation of MPLS-TP be used ? What if the network does not support MPLS-TP ? The network-layer adaptation also brings additional encap-label and its associated signaling. So there is additional data and control plane overhead and the service is not transparently carried. E.g. if the service has to carry a layer-2 packet such as LLDP, I don't think it is straightforward. Thanks On Mon, Apr 18, 2011 at 1:15 PM, John E Drake wrote: > Matthew, > > > > I don=92t think this should adopted as a WG draft.=A0 The right way to do= this > is to use the packet transport service described in section 3.4.5 of > RFC5921. > > > > Thanks, > > > > John > > > > Sent from my iPhone > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Bocci, Matthew (Matthew) > > Sent: Friday, April 15, 2011 2:52 AM > To: pwe3@ietf.org > Subject: [PWE3] Discussion on > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > > > > During the Prague PWE3 meeting, there was a discussion on > whether=A0draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be ad= opted > as a WG draft. The minutes of this discussion are posted > at:=A0http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html > > > > We would like to ask the same question on the list. > > > > Please post any comments before April 29th. > > > > Regards, > > > > Matthew & Andy > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --=20 - Sri From tnadeau@lucidvision.com Mon Apr 18 15:20:21 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 306E3E06FE for ; Mon, 18 Apr 2011 15:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vJulwJHVQ+w for ; Mon, 18 Apr 2011 15:19:53 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfc.amsl.com (Postfix) with ESMTP id D0B30E066F for ; Mon, 18 Apr 2011 15:19:52 -0700 (PDT) Received: from [10.123.186.56] (mobile-166-137-137-011.mycingular.net [166.137.137.11]) by lucidvision.com (Postfix) with ESMTP id C182A1AFE32F; Mon, 18 Apr 2011 18:19:51 -0400 (EDT) References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> Mime-Version: 1.0 (iPhone Mail 8H7) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-29-587958773 Message-Id: <80A13E13-0107-4114-A218-3A9D1E1D51CD@lucidvision.com> X-Mailer: iPhone Mail (8H7) From: Thomas Nadeau Date: Mon, 18 Apr 2011 18:19:44 -0400 To: John E Drake Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:20:21 -0000 --Apple-Mail-29-587958773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am with John on this one; do not support. Tom On Apr 18, 2011, at 4:15 PM, John E Drake wrote: > Matthew, >=20 > =20 >=20 > I don=E2=80=99t think this should adopted as a WG draft. The right way to= do this is to use the packet transport service described in section 3.4.5 o= f RFC5921. >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > John >=20 > =20 >=20 > Sent from my iPhone >=20 > =20 >=20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bo= cci, Matthew (Matthew) > Sent: Friday, April 15, 2011 2:52 AM > To: pwe3@ietf.org > Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-= 02.txt >=20 > =20 >=20 > During the Prague PWE3 meeting, there was a discussion on whether draft-ki= ni-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. T= he minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3/m= inutes?item=3Dminutes80.html >=20 > =20 >=20 > We would like to ask the same question on the list. >=20 > =20 >=20 > Please post any comments before April 29th. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Matthew & Andy >=20 > =20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-29-587958773 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I am with John on this one; do not supp= ort.

Tom



On Apr 18= , 2011, at 4:15 PM, John E Drake <j= drake@juniper.net> wrote:

Matthew,

 

I don=E2=80=99t think this should adopted as a WG draft.&nbs= p; The right way to do this is to use the packet transport service described= in section 3.4.5 of RFC5921.

 

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-se= rif";color:#1F497D">Thanks,

 

John

 

Sent from my iPhone

<= /div>

 

From: pwe3-bounces@ietf.org= [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matt= hew)
Sent: Friday, April 15, 2011 2:52 AM
To: pwe3@ietf.org
Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficien= t-ip-mpls-02.txt

 

During= the Prague PWE3 meeting, there was a discussion on whether draft-kini-= pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. The= minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3/minute= s?item=3Dminutes80.html

 

We would like to ask the same q= uestion on the list.

=  

Please post any comments before April 29th= .

 

Regards,

 

Matthew & Andy

=

 <= /span>

_______________________________________________
pwe3= mailing list
pwe3@ietf.org=
= https://www.ietf.org/mailman/listinfo/pwe3
= = --Apple-Mail-29-587958773-- From renwei.li@huawei.com Mon Apr 18 15:38:42 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 670F4E081E for ; Mon, 18 Apr 2011 15:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byGC7nBvRIZx for ; Mon, 18 Apr 2011 15:38:38 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfc.amsl.com (Postfix) with ESMTP id 25075E0801 for ; Mon, 18 Apr 2011 15:38:38 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV00EH8DKCKQ@usaga02-in.huawei.com> for pwe3@ietf.org; Mon, 18 Apr 2011 15:38:37 -0700 (PDT) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LJV00FSGDKC3P@usaga02-in.huawei.com> for pwe3@ietf.org; Mon, 18 Apr 2011 15:38:36 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 15:38:36 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.75]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 15:38:36 -0700 Date: Mon, 18 Apr 2011 22:38:35 +0000 From: Renwei Li In-reply-to: <14C7F4F06DB5814AB0DE29716C4F6D671851810F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-Originating-IP: [10.193.34.55] To: "Henderickx, Wim (Wim)" , John E Drake , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/WDfGW4I+Mb8vcHzncTIdw)" Content-language: en-US Accept-Language: en-US Thread-topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-index: AQHL/g/SgWS+gwD6ikeaZPZfGLJxgZRkNQLg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> <14C7F4F06DB5814AB0DE29716C4F6D671851810F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:38:42 -0000 --Boundary_(ID_/WDfGW4I+Mb8vcHzncTIdw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Wim, If you use the packet transport service, you still have the complexity issue. It is my understanding the draft is not just about the header overhead. Actually I weigh more on supporting heterogeneous ACs than on reducing header overhead. Thanks, Renwei ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Monday, April 18, 2011 2:26 PM To: John E Drake; Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Hi *, I agree with John (No support for adopting this work). The slightly better overhead does not pay off for the complexities introduced with this solution. A packet transport service is a better solution for this problem. Cheers, Wim From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of John E Drake Sent: maandag 18 april 2011 22:16 To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Matthew, I don't think this should adopted as a WG draft. The right way to do this is to use the packet transport service described in section 3.4.5 of RFC5921. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Friday, April 15, 2011 2:52 AM To: pwe3@ietf.org Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt During the Prague PWE3 meeting, there was a discussion on whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3/minutes?item=minutes80.html We would like to ask the same question on the list. Please post any comments before April 29th. Regards, Matthew & Andy --Boundary_(ID_/WDfGW4I+Mb8vcHzncTIdw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Wim,

 

If you use the packet transport service, you still have the complexity issue.

 

It is my understanding the draft is not just about the header overhead. Actually I weigh more on supporting heterogeneous ACs than on reducing header overhead.

 

 

Thanks,

 

Renwei

 

 

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Monday, April 18, 2011 2:26 PM
To: John E Drake; Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

 

Hi *,

 

I agree with John (No support for adopting this work). The slightly better overhead does not pay off for the complexities introduced with this solution. A packet transport service is a better solution for this problem.

 

Cheers,

Wim

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of John E Drake
Sent: maandag 18 april 2011 22:16
To: Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

 

Matthew,

 

I don’t think this should adopted as a WG draft.  The right way to do this is to use the packet transport service described in section 3.4.5 of RFC5921.

 

Thanks,

 

John

 

Sent from my iPhone

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, April 15, 2011 2:52 AM
To: pwe3@ietf.org
Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

 

During the Prague PWE3 meeting, there was a discussion on whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3/minutes?item=minutes80.html

 

We would like to ask the same question on the list.

 

Please post any comments before April 29th.

 

Regards,

 

Matthew & Andy

 

--Boundary_(ID_/WDfGW4I+Mb8vcHzncTIdw)-- From wim.henderickx@alcatel-lucent.com Mon Apr 18 15:47:54 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8112BE083C for ; Mon, 18 Apr 2011 15:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.064 X-Spam-Level: X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQUh7yvkbx6f for ; Mon, 18 Apr 2011 15:47:52 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfc.amsl.com (Postfix) with ESMTP id B0F87E085A for ; Mon, 18 Apr 2011 15:47:51 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3IMllQl029377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2011 00:47:47 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 19 Apr 2011 00:47:47 +0200 From: "Henderickx, Wim (Wim)" To: Renwei Li , John E Drake , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Tue, 19 Apr 2011 00:47:44 +0200 Thread-Topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: AQHL/g/SgWS+gwD6ikeaZPZfGLJxgZRkNQLggAADgVA= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6718518122@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> <14C7F4F06DB5814AB0DE29716C4F6D671851810F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D6718518122FRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:47:54 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D6718518122FRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Renwei, Look at http://tools.ietf.org/html/draft-ietf-pwe3-packet-pw-00 We analyzed the different options and the decision is in there Cheers, Wim From: Renwei Li [mailto:renwei.li@huawei.com] Sent: dinsdag 19 april 2011 0:39 To: Henderickx, Wim (Wim); John E Drake; Bocci, Matthew (Matthew); pwe3@iet= f.org Subject: RE: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mp= ls-02.txt Hi Wim, If you use the packet transport service, you still have the complexity issu= e. It is my understanding the draft is not just about the header overhead. Act= ually I weigh more on supporting heterogeneous ACs than on reducing header = overhead. Thanks, Renwei ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Hen= derickx, Wim (Wim) Sent: Monday, April 18, 2011 2:26 PM To: John E Drake; Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mp= ls-02.txt Hi *, I agree with John (No support for adopting this work). The slightly better = overhead does not pay off for the complexities introduced with this solutio= n. A packet transport service is a better solution for this problem. Cheers, Wim From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Joh= n E Drake Sent: maandag 18 april 2011 22:16 To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mp= ls-02.txt Matthew, I don't think this should adopted as a WG draft. The right way to do this = is to use the packet transport service described in section 3.4.5 of RFC592= 1. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Friday, April 15, 2011 2:52 AM To: pwe3@ietf.org Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-0= 2.txt During the Prague PWE3 meeting, there was a discussion on whether draft-kin= i-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. = The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3= /minutes?item=3Dminutes80.html We would like to ask the same question on the list. Please post any comments before April 29th. Regards, Matthew & Andy --_000_14C7F4F06DB5814AB0DE29716C4F6D6718518122FRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Renwei,

 <= /o:p>

Look at http://tools.ietf.org/html/dra= ft-ietf-pwe3-packet-pw-00

We analyzed the different options and the decision is in there

 

Cheers,

Wim

 <= /span>

From: Renwei Li [mailto:renwei.l= i@huawei.com]
Sent: dinsdag 19 april 2011 0:39
To: Hen= derickx, Wim (Wim); John E Drake; Bocci, Matthew (Matthew); pwe3@ietf.orgSubject: RE: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-effici= ent-ip-mpls-02.txt

 

Hi Wim,

 

If yo= u use the packet transport service, you still have the complexity issue.

 

It is my understanding the draft is not just about the he= ader overhead. Actually I weigh more on supporting heterogeneous ACs than o= n reducing header overhead.

 

 

Thanks,

=  

Renwei

 

 

 

= From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Monday, April 18, 2011 2:26 PM
<= b>To: John E Drake; Bocci, Matthew (Matthew); pwe3@ietf.org
Subje= ct: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpl= s-02.txt

 <= /p>

Hi *,

 

I agree = with John (No support for adopting this work). The slightly better overhead= does not pay off for the complexities introduced with this solution. A pac= ket transport service is a better solution for this problem.

 

Cheers,

Wi= m

 =

From: pwe3-bounces@ietf.org [mailto:pw= e3-bounces@ietf.org] On Behalf Of John E Drake
Sent: maand= ag 18 april 2011 22:16
To: Bocci, Matthew (Matthew); pwe3@ietf.or= g
Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-eff= icient-ip-mpls-02.txt

 

Matthew,

 

I don’t think this should adopted as a WG draft.  = The right way to do this is to use the packet transport service described i= n section 3.4.5 of RFC5921.

 

Thanks,

 

John

 

Sent from my = iPhone

 

From: pwe3-bounces@i= etf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (= Matthew)
Sent: Friday, April 15, 2011 2:52 AM
To: pwe3@= ietf.org
Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-= efficient-ip-mpls-02.txt

 

During the Prague P= WE3 meeting, there was a discussion on whether draft-kini-pwe3-pkt-enc= ap-efficient-ip-mpls-02.txt should be adopted as a WG draft. The minutes of= this discussion are posted at: http://tools.ietf.org/wg/pwe3/minutes?ite= m=3Dminutes80.html

 

We w= ould like to ask the same question on the list.

=

 

Please post any comments before April 29th.=

 

Regards,

<= div>

 

Matthew & Andy

 

= = --_000_14C7F4F06DB5814AB0DE29716C4F6D6718518122FRMRSSXCHMBSB1d_-- From jdrake@juniper.net Mon Apr 18 15:58:41 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92BCBE088A for ; Mon, 18 Apr 2011 15:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bibogj4a6MIw for ; Mon, 18 Apr 2011 15:58:40 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfc.amsl.com (Postfix) with ESMTP id 7A6C9E082A for ; Mon, 18 Apr 2011 15:58:40 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTazCHXkk1uqzd833YRu7x1sCb/v/OjzT@postini.com; Mon, 18 Apr 2011 15:58:40 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 18 Apr 2011 15:55:21 -0700 From: John E Drake To: Sriganesh Kini Date: Mon, 18 Apr 2011 15:57:25 -0700 Thread-Topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: Acv+FcRHi2jKVo9eSCa6mxQ7pg4XgwABRFeQ Message-ID: <5E893DB832F57341992548CDBB333163A0968BFA5E@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:58:41 -0000 Sent from my iPhone > -----Original Message----- > From: sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] On > Behalf Of Sriganesh Kini > Sent: Monday, April 18, 2011 3:12 PM > To: John E Drake > Cc: Bocci, Matthew (Matthew); pwe3@ietf.org > Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient- > ip-mpls-02.txt >=20 > John, >=20 > Are you suggesting that instead of (packet) PW adaptation, the network > layer adaptation of MPLS-TP be used ? What if the network does not > support MPLS-TP ? JD: The packet transport service is defined in the context of the MPLS-TP = framework RFC but it is actually independent of MPLS-TP. > The network-layer adaptation also brings additional > encap-label and its associated signaling. JD: There is targeted signaling for each packet type (IP v4 and v6, MPLS (u= pstream/downstream labels), OSI) and an associated label. This is actually= already supported in RSVP-TE signaling, so there is an existence proof. > So there is additional data > and control plane overhead and the service is not transparently > carried. E.g. if the service has to carry a layer-2 packet such as > LLDP, I don't think it is straightforward. JD: It is a (network layer) packet transport service. L2 frames are not c= arried over it. Which also means, by definition, that the access circuits = are heterogeneous. >=20 > Thanks >=20 > On Mon, Apr 18, 2011 at 1:15 PM, John E Drake > wrote: > > Matthew, > > > > > > > > I don't think this should adopted as a WG draft.=A0 The right way to do > this > > is to use the packet transport service described in section 3.4.5 of > > RFC5921. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > Sent from my iPhone > > > > > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of > > Bocci, Matthew (Matthew) > > > > Sent: Friday, April 15, 2011 2:52 AM > > To: pwe3@ietf.org > > Subject: [PWE3] Discussion on > > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > > > > > > > > During the Prague PWE3 meeting, there was a discussion on > > whether=A0draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be > adopted > > as a WG draft. The minutes of this discussion are posted > > at:=A0http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html > > > > > > > > We would like to ask the same question on the list. > > > > > > > > Please post any comments before April 29th. > > > > > > > > Regards, > > > > > > > > Matthew & Andy > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > >=20 >=20 >=20 > -- > - Sri From tnadeau@lucidvision.com Mon Apr 18 16:24:03 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47AE1E071C for ; Mon, 18 Apr 2011 16:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlfOyRO8qdNs for ; Mon, 18 Apr 2011 16:24:02 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfc.amsl.com (Postfix) with ESMTP id EC5C2E067C for ; Mon, 18 Apr 2011 16:24:01 -0700 (PDT) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4BE081AFE6A6; Mon, 18 Apr 2011 19:24:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-591809917 From: Thomas Nadeau In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6718518122@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Mon, 18 Apr 2011 19:24:00 -0400 Message-Id: References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> <14C7F4F06DB5814AB0DE29716C4F6D671851810F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D6718518122@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1084) Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 23:24:03 -0000 --Apple-Mail-1-591809917 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes, the analysis is indeed there. FYI, from the Introduction: 1. Introduction There is a need to provide a method of carrying a packet service over an MPLS PSN in a way that provides isolation between the two networks. The server MPLS network may be an MPLS network or a network conforming to the MPLS-TP [RFC5317]. The client may also be either a MPLS network of a network conforming to the MPLS-TP. Considerations regarding the use of an MPLS network as a server for an MPLS-TP network are outside the scope of this document. > Renwei, > =20 > Look at http://tools.ietf.org/html/draft-ietf-pwe3-packet-pw-00 > We analyzed the different options and the decision is in there > =20 > Cheers, > Wim > =20 > From: Renwei Li [mailto:renwei.li@huawei.com]=20 > Sent: dinsdag 19 april 2011 0:39 > To: Henderickx, Wim (Wim); John E Drake; Bocci, Matthew (Matthew); = pwe3@ietf.org > Subject: RE: [PWE3] Discussion on = draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > =20 > Hi Wim, > =20 > If you use the packet transport service, you still have the complexity = issue. > =20 > It is my understanding the draft is not just about the header = overhead. Actually I weigh more on supporting heterogeneous ACs than on = reducing header overhead. > =20 > =20 > Thanks, > =20 > Renwei > =20 > =20 > =20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Henderickx, Wim (Wim) > Sent: Monday, April 18, 2011 2:26 PM > To: John E Drake; Bocci, Matthew (Matthew); pwe3@ietf.org > Subject: Re: [PWE3] Discussion on = draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > =20 > Hi *, > =20 > I agree with John (No support for adopting this work). The slightly = better overhead does not pay off for the complexities introduced with = this solution. A packet transport service is a better solution for this = problem. > =20 > Cheers, > Wim > =20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of John E Drake > Sent: maandag 18 april 2011 22:16 > To: Bocci, Matthew (Matthew); pwe3@ietf.org > Subject: Re: [PWE3] Discussion on = draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > =20 > Matthew, > =20 > I don=92t think this should adopted as a WG draft. The right way to = do this is to use the packet transport service described in section = 3.4.5 of RFC5921. > =20 > Thanks, > =20 > John > =20 > Sent from my iPhone > =20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Bocci, Matthew (Matthew) > Sent: Friday, April 15, 2011 2:52 AM > To: pwe3@ietf.org > Subject: [PWE3] Discussion on = draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > =20 > During the Prague PWE3 meeting, there was a discussion on whether = draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as = a WG draft. The minutes of this discussion are posted at: = http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html > =20 > We would like to ask the same question on the list. > =20 > Please post any comments before April 29th. > =20 > Regards, > =20 > Matthew & Andy > =20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-1-591809917 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Yes, the analysis is indeed = there. FYI, from the Introduction:

1.  Introduction


   There is a need to provide a method of carrying a packet service over
   an MPLS PSN in a way that provides isolation between the two
   networks.  The server MPLS network may be an MPLS network or a
   network conforming to the MPLS-TP [RFC5317].  The client may also be
   either a MPLS network of a network conforming to the MPLS-TP.
   Considerations regarding the use of an MPLS network as a server for
   an MPLS-TP network are outside the scope of this =
document.


Renwei,
 
Hi Wim,
If you use the = packet transport service, you still have the complexity = issue.
It is my = understanding the draft is not just about the header overhead. Actually = I weigh more on supporting heterogeneous ACs than on reducing header = overhead.
 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org= ] On Behalf Of Henderickx, Wim = (Wim)
Sent: Monday, April 18, 2011 2:26 = PM
To: John = E Drake; Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Discussion on = draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt
=
 
Hi = *,
I = agree with John (No support for adopting this work). The slightly better = overhead does not pay off for the complexities introduced with this = solution. A packet transport service is a better solution for this = problem.
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org= ] On Behalf Of John E = Drake
Sent: maandag 18 april 2011 = 22:16
To: Bocci, Matthew = (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Discussion on = draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt
=
 
I = don=92t think this should adopted as a WG draft.  The right way to = do this is to use the packet transport service described in section = 3.4.5 of RFC5921.
Sent = from my iPhone
 
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org= ] On Behalf Of Bocci, Matthew = (Matthew)
Sent: Friday, April 15, 2011 2:52 = AM
To: pwe3@ietf.org
Subject: [PWE3] Discussion on = draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt
=
 
During the Prague PWE3 meeting, there was a = discussion on = whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should = be adopted as a WG draft. The minutes of this discussion are posted = at: We would like to ask the same question on the = list.
pwe3@ietf.org
Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 23:24:33 -0000 inline @ [Sri] On Mon, Apr 18, 2011 at 3:57 PM, John E Drake wrote: > > > Sent from my iPhone > > >> -----Original Message----- >> From: sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] On >> Behalf Of Sriganesh Kini >> Sent: Monday, April 18, 2011 3:12 PM >> To: John E Drake >> Cc: Bocci, Matthew (Matthew); pwe3@ietf.org >> Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient- >> ip-mpls-02.txt >> >> John, >> >> Are you suggesting that instead of (packet) PW adaptation, the network >> layer adaptation of MPLS-TP be used ? What if the network does not >> support MPLS-TP ? > > JD: =A0The packet transport service is defined in the context of the MPLS= -TP framework RFC but it is actually independent of MPLS-TP. [Sri] So I take it that your comment applies to draft-ietf-pwe3-packet-pw-00. The network-layer adaptation is similar to the "Parallel PWs" approach in sec 6.3 of that doc and there is a listing of ".. serious downsides .." in that section as well. > >> The network-layer adaptation also brings additional >> encap-label and its associated signaling. > > JD: There is targeted signaling for each packet type (IP v4 and v6, MPLS = (upstream/downstream labels), OSI) and an associated label. =A0This is actu= ally already supported in RSVP-TE signaling, so there is an existence proof= . [Sri] Can you elaborate. Are you suggesting targeted RSVP-TE signalling to support network-layer adaptation ? > >> So there is additional data >> and control plane overhead and the service is not transparently >> carried. E.g. if the service has to carry a layer-2 packet such as >> LLDP, I don't think it is straightforward. > > JD: =A0It is a (network layer) packet transport service. =A0L2 frames are= not carried over it. =A0Which also means, by definition, that the access c= ircuits are heterogeneous. [Sri] See the intro section of draft-ietf-pwe3-packet-pw-00 sec 1 (Intro) that lists LLDP exchanged between clients (e.g. MPLS LSRs) and further "... two clients require an attachment mechanism that can be used to multiplex a number of protocols. In addition it is essential to the correct operation of the network layer that all of these protocols fate share." How can this requirement be met by a (network layer) packet transport servi= ce ? > >> >> Thanks >> >> On Mon, Apr 18, 2011 at 1:15 PM, John E Drake >> wrote: >> > Matthew, >> > >> > >> > >> > I don't think this should adopted as a WG draft.=A0 The right way to d= o >> this >> > is to use the packet transport service described in section 3.4.5 of >> > RFC5921. >> > >> > >> > >> > Thanks, >> > >> > >> > >> > John >> > >> > >> > >> > Sent from my iPhone >> > >> > >> > >> > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf >> Of >> > Bocci, Matthew (Matthew) >> > >> > Sent: Friday, April 15, 2011 2:52 AM >> > To: pwe3@ietf.org >> > Subject: [PWE3] Discussion on >> > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt >> > >> > >> > >> > During the Prague PWE3 meeting, there was a discussion on >> > whether=A0draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be >> adopted >> > as a WG draft. The minutes of this discussion are posted >> > at:=A0http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html >> > >> > >> > >> > We would like to ask the same question on the list. >> > >> > >> > >> > Please post any comments before April 29th. >> > >> > >> > >> > Regards, >> > >> > >> > >> > Matthew & Andy >> > >> > >> > >> > _______________________________________________ >> > pwe3 mailing list >> > pwe3@ietf.org >> > https://www.ietf.org/mailman/listinfo/pwe3 >> > >> > >> >> >> >> -- >> - Sri > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --=20 - Sri From jdrake@juniper.net Mon Apr 18 17:01:02 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 65A1FE070C for ; Mon, 18 Apr 2011 17:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgCux9XIFL2y for ; Mon, 18 Apr 2011 17:01:01 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfc.amsl.com (Postfix) with ESMTP id 5B916E0692 for ; Mon, 18 Apr 2011 17:01:01 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTazQu166bFm3ST76tst5f+nBcwTfcvIz@postini.com; Mon, 18 Apr 2011 17:01:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 18 Apr 2011 16:57:29 -0700 From: John E Drake To: Sriganesh Kini Date: Mon, 18 Apr 2011 16:59:32 -0700 Thread-Topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: Acv+H8Z6+PT/Ki4ZRriHiEJYRUbJlwAA7gVQ Message-ID: <5E893DB832F57341992548CDBB333163A0968BFB44@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A0968BFA5E@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 00:01:02 -0000 Snipped... Sent from my iPhone > >> Are you suggesting that instead of (packet) PW adaptation, the > network > >> layer adaptation of MPLS-TP be used ? What if the network does not > >> support MPLS-TP ? > > > > JD: =A0The packet transport service is defined in the context of the > MPLS-TP framework RFC but it is actually independent of MPLS-TP. >=20 > [Sri] So I take it that your comment applies to > draft-ietf-pwe3-packet-pw-00. The network-layer adaptation is similar > to the "Parallel PWs" approach in sec 6.3 of that doc and there is a > listing of ".. serious downsides .." in that section as well. JD: No, my comment has nothing to do with that draft. >=20 > > > >> The network-layer adaptation also brings additional > >> encap-label and its associated signaling. > > > > JD: There is targeted signaling for each packet type (IP v4 and v6, > MPLS (upstream/downstream labels), OSI) and an associated label. =A0This > is actually already supported in RSVP-TE signaling, so there is an > existence proof. >=20 > [Sri] Can you elaborate. Are you suggesting targeted RSVP-TE > signalling to support network-layer adaptation ? JD: No, I was merely pointing out that this is how RSVP-TE works.=20 >=20 > > > >> So there is additional data > >> and control plane overhead and the service is not transparently > >> carried. E.g. if the service has to carry a layer-2 packet such as > >> LLDP, I don't think it is straightforward. > > > > JD: =A0It is a (network layer) packet transport service. =A0L2 frames a= re > not carried over it. =A0Which also means, by definition, that the access > circuits are heterogeneous. >=20 > [Sri] See the intro section of draft-ietf-pwe3-packet-pw-00 sec 1 > (Intro) that lists LLDP exchanged between clients (e.g. MPLS LSRs) and > further "... two clients require an attachment mechanism that can be > used to multiplex a number of protocols. In addition it is essential > to the correct operation of the network layer that all of these > protocols fate share." >=20 > How can this requirement be met by a (network layer) packet transport > service ? JD: For a given link layer access circuit, there may need to be link layer= protocols between a (CE, PE) pair. =20 >=20 > > > >> > >> Thanks > >> > >> On Mon, Apr 18, 2011 at 1:15 PM, John E Drake > >> wrote: > >> > Matthew, > >> > > >> > > >> > > >> > I don't think this should adopted as a WG draft.=A0 The right way to > do > >> this > >> > is to use the packet transport service described in section 3.4.5 > of > >> > RFC5921. > >> > > >> > > >> > > >> > Thanks, > >> > > >> > > >> > > >> > John > >> > > >> > > >> > > >> > Sent from my iPhone > >> > > >> > > >> > > >> > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf > >> Of > >> > Bocci, Matthew (Matthew) > >> > > >> > Sent: Friday, April 15, 2011 2:52 AM > >> > To: pwe3@ietf.org > >> > Subject: [PWE3] Discussion on > >> > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > >> > > >> > > >> > > >> > During the Prague PWE3 meeting, there was a discussion on > >> > whether=A0draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should > be > >> adopted > >> > as a WG draft. The minutes of this discussion are posted > >> > at:=A0http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html > >> > > >> > > >> > > >> > We would like to ask the same question on the list. > >> > > >> > > >> > > >> > Please post any comments before April 29th. > >> > > >> > > >> > > >> > Regards, > >> > > >> > > >> > > >> > Matthew & Andy > >> > > >> > > >> > > >> > _______________________________________________ > >> > pwe3 mailing list > >> > pwe3@ietf.org > >> > https://www.ietf.org/mailman/listinfo/pwe3 > >> > > >> > > >> > >> > >> > >> -- > >> - Sri > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > >=20 >=20 >=20 > -- > - Sri From sriganeshkini@gmail.com Mon Apr 18 17:42:14 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8E19BE06B6 for ; Mon, 18 Apr 2011 17:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uLrUehw12by for ; Mon, 18 Apr 2011 17:42:12 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id D7565E067C for ; Mon, 18 Apr 2011 17:42:12 -0700 (PDT) Received: by qyk7 with SMTP id 7so3279184qyk.10 for ; Mon, 18 Apr 2011 17:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=MJwCl1e5bDYhq9hBTwoAizKjao04N/21tL3/e0pSXkA=; b=iLWp/Qyw25yJ4jOY2rxsByoygSgqXoIdo74J+qkrOx7F6RMx4lfd5NVRifON5+bY1D olvgy4WRXb/dcakK8AIGUpck4ZHXJTztDQY7jDxrrBqJrwsU/2uul5fq3QUyD/wcwf3w usvdaZikmY4+QjgUvYqhCxCzeKWmKpcByvRGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=XqaBniG0GWD4grOvj+MVFLiycF92FIfwwdeX7DO6wSrQDhFv7/aCoGbPEWrYTXkyWk 99e2Y4QZq2xxWvtthgXEjagtJMd6dIJKJAdfJpIQXLWLMmVJFOGWIH2K2q/r/XUzV7Uv k4mkv0TLy5MaVHxftpYyLatJ7HpqfCoiVimEY= Received: by 10.229.29.129 with SMTP id q1mr3906192qcc.295.1303173731240; Mon, 18 Apr 2011 17:42:11 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.188.204 with HTTP; Mon, 18 Apr 2011 17:41:41 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB333163A0968BFB44@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A0968BFA5E@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A0968BFB44@EMBX01-HQ.jnpr.net> From: Sriganesh Kini Date: Mon, 18 Apr 2011 17:41:41 -0700 X-Google-Sender-Auth: Oygqz-4X-AseJPh5ooj0EIy-J_g Message-ID: To: John E Drake Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 00:42:14 -0000 inline @ [Sri] On Mon, Apr 18, 2011 at 4:59 PM, John E Drake wrote: > > Snipped... > > Sent from my iPhone > >> >> Are you suggesting that instead of (packet) PW adaptation, the >> network >> >> layer adaptation of MPLS-TP be used ? What if the network does not >> >> support MPLS-TP ? >> > >> > JD: =A0The packet transport service is defined in the context of the >> MPLS-TP framework RFC but it is actually independent of MPLS-TP. >> >> [Sri] So I take it that your comment applies to >> draft-ietf-pwe3-packet-pw-00. The network-layer adaptation is similar >> to the "Parallel PWs" approach in sec 6.3 of that doc and there is a >> listing of ".. serious downsides .." in that section as well. > > JD: =A0No, my comment has nothing to do with that draft. [Sri] You had suggested that instead of packet PW, the network layer adaptation should be used. Is there any difference between the "Parallel PW" approach in the draft and the netw-layer adaptation and if so what are they ? If it is similar how does it address the issues listed in the draft ? > >> >> > >> >> The network-layer adaptation also brings additional >> >> encap-label and its associated signaling. >> > >> > JD: There is targeted signaling for each packet type (IP v4 and v6, >> MPLS (upstream/downstream labels), OSI) and an associated label. =A0This >> is actually already supported in RSVP-TE signaling, so there is an >> existence proof. >> >> [Sri] Can you elaborate. Are you suggesting targeted RSVP-TE >> signalling to support network-layer adaptation ? > > JD: =A0No, I was merely pointing out that this is how RSVP-TE works. > [Sri] But it still adds additional overhead (both data-plane and signaling)= . >> >> > >> >> So there is additional data >> >> and control plane overhead and the service is not transparently >> >> carried. E.g. if the service has to carry a layer-2 packet such as >> >> LLDP, I don't think it is straightforward. >> > >> > JD: =A0It is a (network layer) packet transport service. =A0L2 frames = are >> not carried over it. =A0Which also means, by definition, that the access >> circuits are heterogeneous. >> >> [Sri] See the intro section of draft-ietf-pwe3-packet-pw-00 sec 1 >> (Intro) that lists LLDP exchanged between clients (e.g. MPLS LSRs) and >> further "... two clients require an attachment mechanism that can be >> used to multiplex a number of protocols. In addition it is essential >> to the correct operation of the network layer that all of these >> protocols fate share." >> >> How can this requirement be met by a (network layer) packet transport >> service ? > > JD: =A0For a given link layer access circuit, there may need to be link l= ayer protocols between a (CE, PE) pair. [Sri] So it doesn't meet the requirements. Also, this adds more complexity in the PE to terminate every link-layer protocol. And what if that protocol needs info from the CE at the other end ? > >> >> > >> >> >> >> Thanks >> >> >> >> On Mon, Apr 18, 2011 at 1:15 PM, John E Drake >> >> wrote: >> >> > Matthew, >> >> > >> >> > >> >> > >> >> > I don't think this should adopted as a WG draft.=A0 The right way t= o >> do >> >> this >> >> > is to use the packet transport service described in section 3.4.5 >> of >> >> > RFC5921. >> >> > >> >> > >> >> > >> >> > Thanks, >> >> > >> >> > >> >> > >> >> > John >> >> > >> >> > >> >> > >> >> > Sent from my iPhone >> >> > >> >> > >> >> > >> >> > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >> Behalf >> >> Of >> >> > Bocci, Matthew (Matthew) >> >> > >> >> > Sent: Friday, April 15, 2011 2:52 AM >> >> > To: pwe3@ietf.org >> >> > Subject: [PWE3] Discussion on >> >> > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt >> >> > >> >> > >> >> > >> >> > During the Prague PWE3 meeting, there was a discussion on >> >> > whether=A0draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should >> be >> >> adopted >> >> > as a WG draft. The minutes of this discussion are posted >> >> > at:=A0http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html >> >> > >> >> > >> >> > >> >> > We would like to ask the same question on the list. >> >> > >> >> > >> >> > >> >> > Please post any comments before April 29th. >> >> > >> >> > >> >> > >> >> > Regards, >> >> > >> >> > >> >> > >> >> > Matthew & Andy >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > pwe3 mailing list >> >> > pwe3@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/pwe3 >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> - Sri >> > _______________________________________________ >> > pwe3 mailing list >> > pwe3@ietf.org >> > https://www.ietf.org/mailman/listinfo/pwe3 >> > >> >> >> >> -- >> - Sri > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --=20 - Sri From jdrake@juniper.net Mon Apr 18 17:56:21 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C295E0710 for ; Mon, 18 Apr 2011 17:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiPDIrifY46R for ; Mon, 18 Apr 2011 17:56:20 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfc.amsl.com (Postfix) with ESMTP id 5F745E06ED for ; Mon, 18 Apr 2011 17:56:20 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTazdslXEJ7CafyyEUJbYVn8PJGPZ88Qu@postini.com; Mon, 18 Apr 2011 17:56:20 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 18 Apr 2011 17:50:58 -0700 From: John E Drake To: Sriganesh Kini Date: Mon, 18 Apr 2011 17:52:55 -0700 Thread-Topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: Acv+LCLey1YEIZ5zTJC2zHvMm0Rw1g== Message-ID: <5C0821F3-931C-468E-89E4-F2F2A99B9AAA@juniper.net> References: <5E893DB832F57341992548CDBB333163A0968BF724@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A0968BFA5E@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A0968BFB44@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 00:56:21 -0000 W(hatever) Sent from my iPhone On Apr 18, 2011, at 8:42 PM, "Sriganesh Kini" wrote: > inline @ [Sri] > > On Mon, Apr 18, 2011 at 4:59 PM, John E Drake =20 > wrote: >> >> Snipped... >> >> Sent from my iPhone >> >>>>> Are you suggesting that instead of (packet) PW adaptation, the >>> network >>>>> layer adaptation of MPLS-TP be used ? What if the network does not >>>>> support MPLS-TP ? >>>> >>>> JD: The packet transport service is defined in the context of the >>> MPLS-TP framework RFC but it is actually independent of MPLS-TP. >>> >>> [Sri] So I take it that your comment applies to >>> draft-ietf-pwe3-packet-pw-00. The network-layer adaptation is =20 >>> similar >>> to the "Parallel PWs" approach in sec 6.3 of that doc and there is a >>> listing of ".. serious downsides .." in that section as well. >> >> JD: No, my comment has nothing to do with that draft. > > [Sri] You had suggested that instead of packet PW, the network layer > adaptation should be used. Is there any difference between the > "Parallel PW" approach in the draft and the netw-layer adaptation and > if so what are they ? If it is similar how does it address the issues > listed in the draft ? > >> >>> >>>> >>>>> The network-layer adaptation also brings additional >>>>> encap-label and its associated signaling. >>>> >>>> JD: There is targeted signaling for each packet type (IP v4 and v6, >>> MPLS (upstream/downstream labels), OSI) and an associated label. =20 >>> This >>> is actually already supported in RSVP-TE signaling, so there is an >>> existence proof. >>> >>> [Sri] Can you elaborate. Are you suggesting targeted RSVP-TE >>> signalling to support network-layer adaptation ? >> >> JD: No, I was merely pointing out that this is how RSVP-TE works. >> > > [Sri] But it still adds additional overhead (both data-plane and =20 > signaling). > >>> >>>> >>>>> So there is additional data >>>>> and control plane overhead and the service is not transparently >>>>> carried. E.g. if the service has to carry a layer-2 packet such as >>>>> LLDP, I don't think it is straightforward. >>>> >>>> JD: It is a (network layer) packet transport service. L2 frames =20 >>>> are >>> not carried over it. Which also means, by definition, that the =20 >>> access >>> circuits are heterogeneous. >>> >>> [Sri] See the intro section of draft-ietf-pwe3-packet-pw-00 sec 1 >>> (Intro) that lists LLDP exchanged between clients (e.g. MPLS LSRs) =20 >>> and >>> further "... two clients require an attachment mechanism that can be >>> used to multiplex a number of protocols. In addition it is essential >>> to the correct operation of the network layer that all of these >>> protocols fate share." >>> >>> How can this requirement be met by a (network layer) packet =20 >>> transport >>> service ? >> >> JD: For a given link layer access circuit, there may need to be =20 >> link layer protocols between a (CE, PE) pair. > > [Sri] So it doesn't meet the requirements. Also, this adds more > complexity in the PE to terminate every link-layer protocol. And what > if that protocol needs info from the CE at the other end ? > >> >>> >>>> >>>>> >>>>> Thanks >>>>> >>>>> On Mon, Apr 18, 2011 at 1:15 PM, John E Drake >>>>> wrote: >>>>>> Matthew, >>>>>> >>>>>> >>>>>> >>>>>> I don't think this should adopted as a WG draft. The right way =20 >>>>>> to >>> do >>>>> this >>>>>> is to use the packet transport service described in section 3.4.5 >>> of >>>>>> RFC5921. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> >>>>>> >>>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >>> Behalf >>>>> Of >>>>>> Bocci, Matthew (Matthew) >>>>>> >>>>>> Sent: Friday, April 15, 2011 2:52 AM >>>>>> To: pwe3@ietf.org >>>>>> Subject: [PWE3] Discussion on >>>>>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt >>>>>> >>>>>> >>>>>> >>>>>> During the Prague PWE3 meeting, there was a discussion on >>>>>> whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should >>> be >>>>> adopted >>>>>> as a WG draft. The minutes of this discussion are posted >>>>>> at: http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html >>>>>> >>>>>> >>>>>> >>>>>> We would like to ask the same question on the list. >>>>>> >>>>>> >>>>>> >>>>>> Please post any comments before April 29th. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> >>>>>> Matthew & Andy >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> pwe3 mailing list >>>>>> pwe3@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> - Sri >>>> _______________________________________________ >>>> pwe3 mailing list >>>> pwe3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>> >>> >>> >>> >>> -- >>> - Sri >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > > > --=20 > - Sri From curtis@occnc.com Mon Apr 18 22:20:23 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EE5CBE068E for ; Mon, 18 Apr 2011 22:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-PWoTia+ebI for ; Mon, 18 Apr 2011 22:20:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 40ACDE0661 for ; Mon, 18 Apr 2011 22:20:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3J5KKVT020136; Tue, 19 Apr 2011 01:20:20 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104190520.p3J5KKVT020136@harbor.orleans.occnc.com> To: Yaakov Stein From: Curtis Villamizar In-reply-to: Your message of "Sun, 17 Apr 2011 06:14:10 -0000." <07F7D7DED63154409F13298786A2ADC903D29381@EXRAD5.ad.rad.co.il> Date: Tue, 19 Apr 2011 01:20:20 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 05:20:24 -0000 In message <07F7D7DED63154409F13298786A2ADC903D29381@EXRAD5.ad.rad.co.il> Yaakov Stein writes: > > Curtis > > Putting the PW into the right LSP solves the problem for SS-PW and for > > the first hop of a MS-PW, but not for the middle hops of MS-PW. > > Yes, I agree. I must admit that I was not thinking about MS-PWs > when I voiced my support. > > But how can the general MS-PW case be handled ? Assuming transit > service providers to be reticent about revealing topology information, > we need for the entity setting up the PW to request co-routed LSPs > from each transit domain. The problem then reduces to routing the PW > through the S-PEs that terminate these LSPs, and ensuring that at the > S-PEs the PW is properly placed. > > An interesting problem arises if we want S-PE redundancy. We would > need to trigger simultaneous switchovers in both directions. > > It would seem that the MS case would be more easily handled by > management operations. > > Y(J)S Yaakov, Late response.. For the MS-PW case the only real solution is to either 1) put criteria for selection of a tunnel in the PW signaling, or 2) put in the tunnel ID (which is normally a configured tunnel identifier for a TE LSP) and use whatever LSP that tunnel is using. For dymanic routing the tunnel should be using the best route available at the time for the parameters configured on the tunnel. The second method is a lot simpler. If you needed dynamic PW switchover, you'd need to use something like the XRO object in the MS-PW signaling so that the working and protect PW did not take a common S-PE or LSP path through the network. My understanding is that MS-PW redundancy is T-PE to T-PE and is mostly to protect against failure on the AC side of the PW, with LSP protection dealing with a fault along the way. At some point you begin to duplicate IGP-TE and RSVP-TE in T-LDP. Sort of like duplicating some of it in TP OAM (for no good technical reason IMHO). Curtis From curtis@occnc.com Mon Apr 18 22:39:37 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A47B8E068E for ; Mon, 18 Apr 2011 22:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EquNCiBML3Co for ; Mon, 18 Apr 2011 22:39:36 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 83FBEE0661 for ; Mon, 18 Apr 2011 22:39:36 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3J5dPoE020389; Tue, 19 Apr 2011 01:39:25 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104190539.p3J5dPoE020389@harbor.orleans.occnc.com> To: Jia He From: Curtis Villamizar In-reply-to: Your message of "Mon, 18 Apr 2011 15:28:18 +0800." <681080A6933146F2B1EA9033BB64B693@china.huawei.com> Date: Tue, 19 Apr 2011 01:39:25 -0400 Sender: curtis@occnc.com Cc: pwe3@ietf.org, Luca Martini Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 05:39:37 -0000 In message <681080A6933146F2B1EA9033BB64B693@china.huawei.com> Jia He writes: > > Hi Cutis, > > > LSP label > > GAL <- this is for LSP OAM > > PW label > > optional fat-pw label (S=1) > > G-Ach > > If this is for LSP OAM, there is no PW label IMHO. > > B.R. > Jia If there is a multipath and you want the OAM to take the same path as the payload then, yes there is a PW label. If that PW isn't working you don't want to be testing some other path. Curtis > ----- Original Message ----- > From: "Curtis Villamizar" > To: "Luca Martini" > Cc: > Sent: Saturday, April 16, 2011 8:37 AM > Subject: Re: [PWE3] GAL above and below the PW label > > > > > > In message <4DA71765.4060504@cisco.com> > > Luca Martini writes: > >> > >> hello! > >> > >> It appears to me that it might not be clear that I also believe that > >> the GAL should be at the bottom of the stack. I know that that is not > >> where we have it in the -00 version of the VCCV-2 draft , but that was > >> only an initial suggestion and we really wanted a good discussion on > >> this list. > >> > >> We will update that document shortly. > >> Thanks. > >> Luca > > > > > > Luca, > > > > Please specify below the PW label (below in the MPLS sense of bottom) > > and not BOS. > > > > MPLS style stack orientation: > > > > LSP label > > PW label > > GAL <- this is for PW OAM > > optional fat-pw label (S=1) > > G-Ach > > > > LSP label > > GAL <- this is for LSP OAM > > PW label > > optional fat-pw label (S=1) > > G-Ach > > > > LSP label > > PW label > > optional fat-pw label (S=1) > > payload > > > > Therefore there can consistently be a rule where GAL is under the > > label for which the OAM is applied. > > > > If the hashing ignores reserved labels, then all three above take the > > same path in the absence of fat-pw or take the same path given the > > same value of the fat-pw label. > > > > Curtis > > > > > >> On 04/13/11 23:41, Luca Martini wrote: > >> > Curtis, > >> > > >> > If we keep the GAL at the bottom of the stack to flag the fact that the > >> > packet is GACH format , and not IP format, what is the problem ? > >> > Surly FAT-PW would still work as most LSRs use the 2 bottom most labels > >> > to build a hash table. > >> > > >> > The gal = label 13 has a fixed binding to it. Do you propose that we > >> > change that ? or just the location of the label? > >> > > >> > Luca > >> > > >> > > >> > > >> > On 03/31/11 03:10, Curtis Villamizar wrote: > >> >> In message <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsson.se> > >> >> David Allan I writes: > >> >>> > >> >>> HI Curtis: > >> >>> > >> >>> My suggestion is to avoid the GAL for PWs if it is to be a > >> >>> homogenizing agent across TP and IP/MPLS domains in the form of > >> >>> MS-PWs. The scenarios in which it was broken was simply a statement of > >> >>> fact. > >> >>> > >> >>> As for the problem GAL was proposed to fix (lack of CW), there are > >> >>> solutions on the table, just not palatable... > >> >>> > >> >>> D > >> >> Dave, > >> >> > >> >> I think we are in agreement. > >> >> > >> >> We either use a non-GAL mechanism, or we fix GAL by removing the > >> >> bottom of stack restriction and use GAL. > >> >> > >> >> I prefer the latter option, fix GAL. > >> >> > >> >> I support not using GAL at all in PW if GAL can't be fixed. > >> >> > >> >> Fixing GAL should really be an MPLS WG discussion. The result of that > >> >> discussion in MPLS should gate whether any PW proposal to use GAL can > >> >> be moved forward. > >> >> > >> >> Curtis > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Curtis Villamizar > >> >>> Sent: Thursday, March 31, 2011 9:03 AM > >> >>> To: Loa Andersson > >> >>> Cc: pwe3@ietf.org > >> >>> Subject: Re: [PWE3] GAL above and below the PW label > >> >>> > >> >>> > >> >>> Loa, Dave, Sasha, > >> >>> > >> >>> I've snipped from various posts on the thread that Sasha started. See inline. > >> >>> > >> >>> In message <4D92F5D3.6080609@pi.nu> > >> >>> Loa Andersson writes: > >> >>>> > >> >>>> All, > >> >>>> > >> >>>> missed a nuance in Sasha subject line. > >> >>>> > >> >>>> We have two issues > >> >>>> > >> >>>> - where the GAL is placed relative to the PW label, I believe it is > >> >>>> necessary to have the GAL below the PW label. > >> >>>> > >> >>>> - whether the the GAL label needs to be bottom of stack or not, it > >> >>>> figure that this is really a discussion if it is possible to have > >> >>>> a FAT label below the GAL or not. I'm not sure about my preferences > >> >>>> but I think it is possible. > >> >>>> > >> >>>> /Loa > >> >>> > >> >>> I agree with Loa's summary. Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic. > >> >>> > >> >>> > >> >>> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericsson.se> > >> >>> David Allan I writes: > >> >>>> > >> >>>> It does become a new behavior, GAL with S=3D0. However the combination > >> >>>> of G= AL being top label at the S-PE and TTL being encoded in the PW > >> >>>> label means = that fate sharing is broken at every S-PE. Life only > >> >>>> gets a little more str= ange if there is a FAT label as well... > >> >>>> > >> >>>> That being said, GAL as bottom label is broken in any ECMP > >> >>>> environment, whi= ch is why GAL is a TP construct. > >> >>>> > >> >>>> my 2 cents > >> >>>> D > >> >>> > >> >>> Dave, > >> >>> > >> >>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. > >> >>> If all it takes to fix it is simple then lets just fix it. > >> >>> > >> >>> This is what we'd have to do. > >> >>> > >> >>> 1) Relax the requirement that GAL be at the bottom > >> >>> > >> >>> 2) Have the ingress insert GAL in the stack immediately below the > >> >>> label for which the measurement is made, keeping the rest of the > >> >>> label stack in place. > >> >>> > >> >>> The only thing the midpoing LSR at a multipath (LAG, link bundle for > >> >>> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there. That will yield the same hash value and it will preserve fate-sharing across multipath. > >> >>> > >> >>> I prefer that we fix things rather than complain that they are broken. > >> >>> > >> >>> Curtis > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 From giles.heron@gmail.com Tue Apr 19 02:38:18 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5487AE06C4 for ; Tue, 19 Apr 2011 02:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc+WCdliisPM for ; Tue, 19 Apr 2011 02:38:16 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id E4B5FE0680 for ; Tue, 19 Apr 2011 02:38:15 -0700 (PDT) Received: by wyb29 with SMTP id 29so5263571wyb.31 for ; Tue, 19 Apr 2011 02:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type; bh=Xu349D9+bA04cgizRoyeQd7Jgi+OxyAKP4ZKAUFhxx8=; b=wTKPaxT+wt9bQddX+128EDUVgrtEYQidjr8CCEPvWW5jSzzm9HuT5/YQ27b37SsKFq Vmzxj1mbdD/fswIQFGi5SQpw79KVXrvLKGe9mz1pEPTHL8fQ+RXx8UnpFCI5czbUeWi6 jk1WotjlJR+fUFttikvJVB8/Xi24XuezT6n9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=JgLMlRgyRQ7hlJpSYlKxgNk3fJxJWi+rXj3uyPP9T2NjAn4g13F9zjpMsAEjqYIpaI 6Q+hP0qRpCSi1yvgQlVlNNzpYSZQ5BbeRhx6jl2c+wnXdN1BUrIBfOrj93UHC6ByZh8a HifMwZvU8alLFVO4xuLCetaM6bB8IBPbISE90= Received: by 10.216.168.67 with SMTP id j45mr11370549wel.101.1303205894938; Tue, 19 Apr 2011 02:38:14 -0700 (PDT) Received: from [64.103.85.91] (dhcp-64-103-85-91.cisco.com [64.103.85.91]) by mx.google.com with ESMTPS id j49sm2985362wer.38.2011.04.19.02.38.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 02:38:13 -0700 (PDT) User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 19 Apr 2011 10:39:07 +0100 From: Giles Heron To: Renwei Li , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-ID: Thread-Topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: Acv7UsubNzUXHUv4SBOyP5s8BvEdxACmZSigACJQGmA= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386054354_1492372" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 09:38:18 -0000 > 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. --B_3386054354_1492372 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Renwei, To your last point about =B3proprietary implementations for IP packet over PWE3=B2. There=B9s already a standard encapsulation for IP packet over PWE3. It is documented in section 4.1 of RFC4447. Giles On 18/04/2011 18:26, "Renwei Li" wrote: > I=B9d like to support it for multiple reasons: > =20 > - It minimizes the chance of having an MPLS-encapsulated packet > fragmented in the network due to the MTU limit, since the header is small= er > and thus the whole packet size is smaller. > - In addition to the bandwidth efficiency the author claims, I be= lieve > that it can be used to support heterogeneous ACs. For example, on one sid= e the > AC is Ethernet while the other side AC is ATM AAL5 (I would appreciate it= if > the authors could confirm it) > - I have heard of some proprietary implementations for IP packet = over > PWE3 from different vendors. A spec like this could be used as a basis fo= r > inter-op. > =20 > =20 > Thanks, > =20 > Renwei > =20 > =20 > =20 >=20 >=20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of B= occi, > Matthew (Matthew) > Sent: Friday, April 15, 2011 2:52 AM > To: pwe3@ietf.org > Subject: [PWE3] Discussion on > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > =20 >=20 > During the Prague PWE3 meeting, there was a discussion on whether > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a= WG > draft. The minutes of this discussion are posted at: > http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html >=20 > =20 >=20 > We would like to ask the same question on the list. >=20 > =20 >=20 > Please post any comments before April 29th. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Matthew & Andy >=20 > =20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --B_3386054354_1492372 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls= -02.txt Hi Renwei,

To your last point about “proprietary implementations for IP packet o= ver PWE3”.  There’s already a standard encapsulation for IP= packet over PWE3.  It is documented in section 4.1 of RFC4447.

Giles

On 18/04/2011 18:26, "Renwei Li" <renwei.li@huawei.com> wrote:

I’d like to support it for multipl= e reasons:
 
- &= nbsp;       It = minimizes the chance of having an MPLS-encapsulated packet fragmented in the= network due to the MTU limit, since the header is smaller and thus the whol= e packet size is smaller.
-       &= nbsp; In addition to the bandwidth efficiency= the author claims, I believe that it can be used to support heterogeneous A= Cs. For example, on one side the AC is Ethernet while the other side AC is A= TM AAL5 (I would appreciate it if the authors could confirm it)
-       &= nbsp; I have heard of some proprietary implem= entations for IP packet over PWE3 from different vendors. A spec like this c= ould be used as a basis for inter-op.
 
 
 Thanks,
 
Renwei
 
 
 

From: pwe3-bounces@ie= tf.org [mailto:pwe3-bounces@ietf.= org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, April 15, 2011 2:52 AM
To: pwe3@ietf.org
Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip= -mpls-02.txt

During the Prague PWE3 m= eeting, there was a discussion on whether draft-kini-pwe3-pkt-encap-efficien= t-ip-mpls-02.txt should be adopted as a WG draft. The minutes of this discus= sion are posted at: http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html


We would like to ask the= same question on the list.

Please post any comments= before April 29th.

Regards,

Matthew & Andy

___________= ____________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3
--B_3386054354_1492372-- From giles.heron@gmail.com Tue Apr 19 05:04:04 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2DE09E0674 for ; Tue, 19 Apr 2011 05:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t96vGa3Ozsqd for ; Tue, 19 Apr 2011 05:04:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 13618E00BE for ; Tue, 19 Apr 2011 05:04:00 -0700 (PDT) Received: by wyb29 with SMTP id 29so5375533wyb.31 for ; Tue, 19 Apr 2011 05:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type; bh=K3KQg+NeHUZxS4WkRjlQ6NwwOh30eCC3UAAcwQ5QG44=; b=GZgfI5H59RnBGatt+7M7691bihn9l1L8cLFxA2fOpWxvChKL7ct9s+ewaEkvCb/7ES dI6xUoHEMRIa81gMU35Ryz1p+bcdaD61Gpq5QuQY2e+vZx4rY1HvBXybMjuxj/naTci0 ZipQ7d6tmytMRJ58MPjqe2gr8FlgSsYW/HkNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=oF0yXHiyvyZdgJSX6Y8YIGB1aSSREc4/9eN9C2lREHw2SSDmQzpJS5S8c6zYCIPixY /+97aXs674pH4TDqLK0CZeIYff23rIdX/6pUReE2woD5aIfVyP1+d1PlgRVbBNkaPHrJ uOvsV2f2M1fbjtXaHvxTIJhsUQGhhAhMNIe7s= Received: by 10.227.10.149 with SMTP id p21mr6194776wbp.195.1303214640183; Tue, 19 Apr 2011 05:04:00 -0700 (PDT) Received: from [64.103.83.159] (dhcp-bdlk09-vlan250-wdata-64-103-83-159.cisco.com [64.103.83.159]) by mx.google.com with ESMTPS id l24sm3848245wbc.13.2011.04.19.05.03.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 05:03:58 -0700 (PDT) User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 19 Apr 2011 13:04:51 +0100 From: Giles Heron To: "Henderickx, Wim (Wim)" , Renwei Li , John E Drake , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-ID: Thread-Topic: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt Thread-Index: AQHL/g/SgWS+gwD6ikeaZPZfGLJxgZRkNQLggAADgVCAAN9WXA== In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6718518122@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386063100_1994942" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:04:04 -0000 > 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. --B_3386063100_1994942 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Right. On the basis that draft-ietf-pwe3-packet-pw looks like the right solution t= o the problem, I for one wouldn=B9t support draft-kini-pwe3-pkt-encap-efficient-ip-mpls. Giles On 18/04/2011 23:47, "Henderickx, Wim (Wim)" wrote: > Renwei, > =20 > Look at http://tools.ietf.org/html/draft-ietf-pwe3-packet-pw-00 > We analyzed the different options and the decision is in there > =20 > Cheers, > Wim > =20 >=20 > From: Renwei Li [mailto:renwei.li@huawei.com] > Sent: dinsdag 19 april 2011 0:39 > To: Henderickx, Wim (Wim); John E Drake; Bocci, Matthew (Matthew); > pwe3@ietf.org > Subject: RE: [PWE3] Discussion on > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > =20 > Hi Wim, > =20 > If you use the packet transport service, you still have the complexity is= sue. > =20 > It is my understanding the draft is not just about the header overhead. > Actually I weigh more on supporting heterogeneous ACs than on reducing he= ader > overhead.=20 > =20 > =20 > Thanks, > =20 > Renwei > =20 > =20 > =20 >=20 >=20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Henderickx, Wim (Wim) > Sent: Monday, April 18, 2011 2:26 PM > To: John E Drake; Bocci, Matthew (Matthew); pwe3@ietf.org > Subject: Re: [PWE3] Discussion on > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > =20 > Hi *, > =20 > I agree with John (No support for adopting this work). The slightly bette= r > overhead does not pay off for the complexities introduced with this solut= ion. > A packet transport service is a better solution for this problem. > =20 > Cheers, > Wim > =20 >=20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of J= ohn E > Drake > Sent: maandag 18 april 2011 22:16 > To: Bocci, Matthew (Matthew); pwe3@ietf.org > Subject: Re: [PWE3] Discussion on > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > =20 > Matthew, > =20 > I don=B9t think this should adopted as a WG draft. The right way to do thi= s is > to use the packet transport service described in section 3.4.5 of RFC5921= . > =20 > Thanks, > =20 > John=20 > =20 >=20 > Sent from my iPhone > =20 >=20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of B= occi, > Matthew (Matthew) > Sent: Friday, April 15, 2011 2:52 AM > To: pwe3@ietf.org > Subject: [PWE3] Discussion on > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt > =20 >=20 > During the Prague PWE3 meeting, there was a discussion on whether > draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a= WG > draft. The minutes of this discussion are posted at: > http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html >=20 > =20 >=20 > We would like to ask the same question on the list. >=20 > =20 >=20 > Please post any comments before April 29th. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Matthew & Andy >=20 > =20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --B_3386063100_1994942 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls= -02.txt Right.

On the basis that draft-ietf-pwe3-packet-pw looks like the right solution t= o the problem, I for one wouldn’t support draft-kini-pwe3-pkt-encap-ef= ficient-ip-mpls.

Giles

On 18/04/2011 23:47, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com> wrote:=

Renwei,
Look at h= ttp://tools.ietf.org/html/draft-ietf-pwe3-packet-pw-00
We analyzed the different options and the decision is in there
 
Cheers,
Wim
 

From: Renwei Li [mailto:renwei.li@huawei.com]
Sent: dinsdag 19 april 2011 0:39
To: Henderickx, Wim (Wim); John E Drake; Bocci, Matthew (Matthew); <= a href=3D"pwe3@ietf.org">pwe3@ietf.org
Subject: RE: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficien= t-ip-mpls-02.txt
Hi Wim,
 
If you use the packet transport service, you still have the complexity issu= e.
 
It is my understanding the draft is not just about the header overhead. Act= ually I weigh more on supporting heterogeneous ACs than on reducing header o= verhead.
 
 
Thanks,
 
Renwei
 
 
 

From: pwe3-bounces@ie= tf.org [mailto:pwe3-bounces@ietf.= org] On Behalf Of Henderickx, Wim (Wim)
Sent: Monday, April 18, 2011 2:26 PM
To: John E Drake; Bocci, Matthew (Matthew); = pwe3@ietf.org
Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficien= t-ip-mpls-02.txt
Hi *,
 
I agree with John (No support for adopting this work). The slightly better = overhead does not pay off for the complexities introduced with this solution= . A packet transport service is a better solution for this problem.
 
Cheers,
Wim
 

From: p= we3-bounces@ietf.org [mailto:pwe3= -bounces@ietf.org] On Behalf Of John E Drake
Sent: maandag 18 april 2011 22:16
To: Bocci, Matthew (Matthew); pwe3@ietf.org<= /a>
Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficien= t-ip-mpls-02.txt
Matthew,
 
I don’t think this should adopted as a WG draft.  The right way = to do this is to use the packet transport service described in section 3.4.5= of RFC5921.
 
Thanks,
 
John
 

Sent from my iPhone
 

From: p= we3-bounces@ietf.org [mailto:pwe3= -bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, April 15, 2011 2:52 AM
To: pwe3@ietf.org
Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip= -mpls-02.txt

During the Prague PWE3 m= eeting, there was a discussion on whether draft-kini-pwe3-pkt-encap-efficien= t-ip-mpls-02.txt should be adopted as a WG draft. The minutes of this discus= sion are posted at: http://tools.ietf.org/wg/pwe3/minutes?item=3Dminutes80.html


We would like to ask the= same question on the list.

Please post any comments= before April 29th.

Regards,

Matthew & Andy

___________= ____________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3
--B_3386063100_1994942-- From curtis@occnc.com Tue Apr 19 13:06:35 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D8B0E0811 for ; Tue, 19 Apr 2011 13:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bho2Dxfsuaa2 for ; Tue, 19 Apr 2011 13:06:34 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 665E3E0809 for ; Tue, 19 Apr 2011 13:06:34 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3JK6WWl051115; Tue, 19 Apr 2011 16:06:32 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104192006.p3JK6WWl051115@harbor.orleans.occnc.com> To: "Bocci, Matthew (Matthew)" From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Apr 2011 11:52:11 +0200." Date: Tue, 19 Apr 2011 16:06:32 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 20:06:35 -0000 In message "Bocci, Matthew (Matthew)" writes: > > During the Prague PWE3 meeting, there was a discussion on whether draft-kin= > i-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. = > The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3= > /minutes?item=3Dminutes80.html > > We would like to ask the same question on the list. > > Please post any comments before April 29th. > > Regards, > > Matthew & Andy I do not support this becoming a WG draft. From zhang.fei3@zte.com.cn Wed Apr 20 01:55:17 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BB3A7E065F; Wed, 20 Apr 2011 01:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvn-JUqFefrz; Wed, 20 Apr 2011 01:55:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by ietfc.amsl.com (Postfix) with ESMTP id 35837E0655; Wed, 20 Apr 2011 01:55:16 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35103491178658; Wed, 20 Apr 2011 16:52:31 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 95720.8036321864; Wed, 20 Apr 2011 16:42:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3K8sKRK003863; Wed, 20 Apr 2011 16:54:20 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <201104190520.p3J5KKVT020136@harbor.orleans.occnc.com> To: curtis@occnc.com MIME-Version: 1.0 X-KeepSent: FBDB6CFD:46051340-48257878:002EAC07; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 20 Apr 2011 16:54:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-20 16:54:21, Serialize complete at 2011-04-20 16:54:21 Content-Type: multipart/alternative; boundary="=_alternative 0030E92648257878_=" X-MAIL: mse01.zte.com.cn p3K8sKRK003863 Cc: pwe3-bounces@ietf.org, "pwe3@ietf.org" , Yaakov Stein , Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:55:17 -0000 This is a multipart message in MIME format. --=_alternative 0030E92648257878_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgY3VydGlzLCANCg0Kc2VlIGluIGxpbmVbRmVpXQ0KDQoNCg0KQ3VydGlzIFZpbGxhbWl6YXIg PGN1cnRpc0BvY2NuYy5jb20+IA0Kt6K8/sjLOiAgcHdlMy1ib3VuY2VzQGlldGYub3JnDQoyMDEx LTA0LTE5IDEzOjIwDQrH67TwuLQguPgNCmN1cnRpc0BvY2NuYy5jb20NCg0KDQrK1bz+yMsNCllh YWtvdiBTdGVpbiA8eWFha292X3NAcmFkLmNvbT4NCrOty80NCiJwd2UzQGlldGYub3JnIiA8cHdl M0BpZXRmLm9yZz4sIEx1Y2EgTWFydGluaSA8bG1hcnRpbmlAY2lzY28uY29tPg0K1vfM4g0KUmU6 IFtQV0UzXSBQV0UzIHdvcmtpbmcgZ3JvdXAgcG9sbCBmb3IgDQpkcmFmdC1jYW8tcHdlMy1tcGxz LXRwLXB3LW92ZXItYmlkaXItbHNwLTAyLnR4dA0KDQoNCg0KDQoNCg0KDQpJbiBtZXNzYWdlIDww N0Y3RDdERUQ2MzE1NDQwOUYxMzI5ODc4NkEyQURDOTAzRDI5MzgxQEVYUkFENS5hZC5yYWQuY28u aWw+DQpZYWFrb3YgU3RlaW4gd3JpdGVzOg0KPiANCj4gQ3VydGlzDQo+ID4gUHV0dGluZyB0aGUg UFcgaW50byB0aGUgcmlnaHQgTFNQIHNvbHZlcyB0aGUgcHJvYmxlbSBmb3IgU1MtUFcgYW5kIGZv cg0KPiA+IHRoZSBmaXJzdCBob3Agb2YgYSBNUy1QVywgYnV0IG5vdCBmb3IgdGhlIG1pZGRsZSBo b3BzIG9mIE1TLVBXLg0KPiANCj4gWWVzLCBJIGFncmVlLiAgSSBtdXN0IGFkbWl0IHRoYXQgSSB3 YXMgbm90IHRoaW5raW5nIGFib3V0IE1TLVBXcw0KPiB3aGVuIEkgdm9pY2VkIG15IHN1cHBvcnQu DQo+IA0KPiBCdXQgaG93IGNhbiB0aGUgZ2VuZXJhbCBNUy1QVyBjYXNlIGJlIGhhbmRsZWQgPyAg QXNzdW1pbmcgdHJhbnNpdA0KPiBzZXJ2aWNlIHByb3ZpZGVycyB0byBiZSByZXRpY2VudCBhYm91 dCByZXZlYWxpbmcgdG9wb2xvZ3kgaW5mb3JtYXRpb24sDQo+IHdlIG5lZWQgZm9yIHRoZSBlbnRp dHkgc2V0dGluZyB1cCB0aGUgUFcgdG8gcmVxdWVzdCBjby1yb3V0ZWQgTFNQcw0KPiBmcm9tIGVh Y2ggdHJhbnNpdCBkb21haW4uICBUaGUgcHJvYmxlbSB0aGVuIHJlZHVjZXMgdG8gcm91dGluZyB0 aGUgUFcNCj4gdGhyb3VnaCB0aGUgUy1QRXMgdGhhdCB0ZXJtaW5hdGUgdGhlc2UgTFNQcywgYW5k IGVuc3VyaW5nIHRoYXQgYXQgdGhlDQo+IFMtUEVzIHRoZSBQVyBpcyBwcm9wZXJseSBwbGFjZWQu DQo+IA0KPiBBbiBpbnRlcmVzdGluZyBwcm9ibGVtIGFyaXNlcyBpZiB3ZSB3YW50IFMtUEUgcmVk dW5kYW5jeS4gIFdlIHdvdWxkDQo+IG5lZWQgdG8gdHJpZ2dlciBzaW11bHRhbmVvdXMgc3dpdGNo b3ZlcnMgaW4gYm90aCBkaXJlY3Rpb25zLg0KPiANCj4gSXQgd291bGQgc2VlbSB0aGF0IHRoZSBN UyBjYXNlIHdvdWxkIGJlIG1vcmUgZWFzaWx5IGhhbmRsZWQgYnkNCj4gbWFuYWdlbWVudCBvcGVy YXRpb25zLg0KPiANCj4gWShKKVMNCg0KDQpZYWFrb3YsDQoNCkxhdGUgcmVzcG9uc2UuLg0KDQpG b3IgdGhlIE1TLVBXIGNhc2UgdGhlIG9ubHkgcmVhbCBzb2x1dGlvbiBpcyB0byBlaXRoZXIgMSkg cHV0IGNyaXRlcmlhDQpmb3Igc2VsZWN0aW9uIG9mIGEgdHVubmVsIGluIHRoZSBQVyBzaWduYWxp bmcsIG9yIDIpIHB1dCBpbiB0aGUgdHVubmVsDQpJRCAod2hpY2ggaXMgbm9ybWFsbHkgYSBjb25m aWd1cmVkIHR1bm5lbCBpZGVudGlmaWVyIGZvciBhIFRFIExTUCkgYW5kDQp1c2Ugd2hhdGV2ZXIg TFNQIHRoYXQgdHVubmVsIGlzIHVzaW5nLg0KDQpbRmVpXSBUaGlzIGxldCBtZSBjb25zaWRlciBh bm90aGVyIHJlbGF0ZWQgcXVlc3Rpb24sIHdoeSBub3QgaW50cm9kY3VlIHRoZSANClJlY29yZCBS b3V0ZSBUTFYNCmluIHRoZSBQVyBzaWduYWxpbmcgc2luY2UgdGhlIEV4cGxpY2l0IFJvdXRlIFRM ViBoYXMgYmVlbiBpbnRyb2R1Y2VkIGluIA0KdGhlDQpkb2N1bWVudCANCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcHdlMy1keW5hbWljLW1zLXB3LTEzI3NlY3Rpb24tNi4y LjQuDQoNCkFzIGRlc2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMjEy I3NlY3Rpb24tNC43LjQsIExTUCBJRCANCmNvdWxkIGJlIGEgc3ViLVRMVg0Kb2YgRXhwbGljaXQg Um91dGUgVExWLCB3aGljaCBjYW4gYmUgdXNlZCBpbiB0aGUgUmVjb3JkIFJvdXRlIFRMViBhbHNv Lg0KDQpJZiB0aGUgUmVjb3JkIFJvdXRlIFRMViBjYW4gYmUgcmV1c2VkIGluIFNTLVBXIG9yIE1T LVBXLCBQVy10by1MU1AgYmluZGluZyANCmNhbiBiZSByZWFsaXplZCANCmVhc2lseSBhbmQgdGhl IHNvbHV0aW9uIGlzIHNjYWxhYmxlIGFsc28uDQoNCg0KRm9yIGR5bWFuaWMgcm91dGluZyB0aGUg dHVubmVsIHNob3VsZCBiZSB1c2luZyB0aGUgYmVzdCByb3V0ZQ0KYXZhaWxhYmxlIGF0IHRoZSB0 aW1lIGZvciB0aGUgcGFyYW1ldGVycyBjb25maWd1cmVkIG9uIHRoZSB0dW5uZWwuDQpUaGUgc2Vj b25kIG1ldGhvZCBpcyBhIGxvdCBzaW1wbGVyLg0KDQpbRmVpXSBZZWFoLCBpdCBpcyBhIHNpbXBs ZXIgc29sdXRpb24sIGJ1dCBpZiB0d28gb3IgbW9yZSBMU1BzIGFyZSB3b3JraW5nIA0KTFNQcyB1 bmRlcg0KdGhlIHNhbWUgdHVubmVsIChmb3IgZXhhbXBsZSwgaW4gdGhlIHNjZW5hcmlvcyBvZiBF Q01QKSwgaG93IHRvIGd1YXJhbnRlZSANCnRoZSBzYW1lIA0Kc2VsZWN0aW9uIG9mIHRoZSBMU1Ag SUQ/IA0KDQpJZiB5b3UgbmVlZGVkIGR5bmFtaWMgUFcgc3dpdGNob3ZlciwgeW91J2QgbmVlZCB0 byB1c2Ugc29tZXRoaW5nIGxpa2UNCnRoZSBYUk8gb2JqZWN0IGluIHRoZSBNUy1QVyBzaWduYWxp bmcgc28gdGhhdCB0aGUgd29ya2luZyBhbmQgcHJvdGVjdA0KUFcgZGlkIG5vdCB0YWtlIGEgY29t bW9uIFMtUEUgb3IgTFNQIHBhdGggdGhyb3VnaCB0aGUgbmV0d29yay4NCg0KTXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IE1TLVBXIHJlZHVuZGFuY3kgaXMgVC1QRSB0byBULVBFIGFuZCBpcw0KbW9z dGx5IHRvIHByb3RlY3QgYWdhaW5zdCBmYWlsdXJlIG9uIHRoZSBBQyBzaWRlIG9mIHRoZSBQVywg d2l0aCBMU1ANCnByb3RlY3Rpb24gZGVhbGluZyB3aXRoIGEgZmF1bHQgYWxvbmcgdGhlIHdheS4N Cg0KQXQgc29tZSBwb2ludCB5b3UgYmVnaW4gdG8gZHVwbGljYXRlIElHUC1URSBhbmQgUlNWUC1U RSBpbiBULUxEUC4NClNvcnQgb2YgbGlrZSBkdXBsaWNhdGluZyBzb21lIG9mIGl0IGluIFRQIE9B TSAoZm9yIG5vIGdvb2QgdGVjaG5pY2FsDQpyZWFzb24gSU1ITykuDQoNCkN1cnRpcw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHdlMyBtYWlsaW5n IGxpc3QNCnB3ZTNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcHdlMw0KDQoNCg0K --=_alternative 0030E92648257878_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGN1cnRpcywgPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zZWUgaW4gbGluZTwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5bRmVpXTwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5DdXJ0aXMgVmls bGFtaXphciAmbHQ7Y3VydGlzQG9jY25jLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7cHdlMy1ib3VuY2VzQGlldGYu b3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDQtMTkg MTM6MjA8L2ZvbnQ+DQo8dGFibGUgYm9yZGVyPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgYmdjb2xv cj13aGl0ZT4NCjxkaXYgYWxpZ249Y2VudGVyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7H67TwuLQguPg8YnI+DQpjdXJ0aXNAb2NjbmMuY29tPC9mb250PjwvZGl2PjwvdGFibGU+DQo8 YnI+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+WWFh a292IFN0ZWluICZsdDt5YWFrb3Zfc0ByYWQuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1 b3Q7cHdlM0BpZXRmLm9yZyZxdW90OyAmbHQ7cHdlM0BpZXRmLm9yZyZndDssDQpMdWNhIE1hcnRp bmkgJmx0O2xtYXJ0aW5pQGNpc2NvLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbUFdF M10gUFdFMyB3b3JraW5nIGdyb3VwIHBvbGwgZm9yDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtkcmFmdC1jYW8tcHdlMy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTAyLnR4dDwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0K SW4gbWVzc2FnZSAmbHQ7MDdGN0Q3REVENjMxNTQ0MDlGMTMyOTg3ODZBMkFEQzkwM0QyOTM4MUBF WFJBRDUuYWQucmFkLmNvLmlsJmd0Ozxicj4NCllhYWtvdiBTdGVpbiB3cml0ZXM6PGJyPg0KJmd0 OyAmbmJzcDs8YnI+DQomZ3Q7IEN1cnRpczxicj4NCiZndDsgJmd0OyBQdXR0aW5nIHRoZSBQVyBp bnRvIHRoZSByaWdodCBMU1Agc29sdmVzIHRoZSBwcm9ibGVtIGZvciBTUy1QVw0KYW5kIGZvcjxi cj4NCiZndDsgJmd0OyB0aGUgZmlyc3QgaG9wIG9mIGEgTVMtUFcsIGJ1dCBub3QgZm9yIHRoZSBt aWRkbGUgaG9wcyBvZiBNUy1QVy48YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgWWVzLCBJIGFn cmVlLiAmbmJzcDtJIG11c3QgYWRtaXQgdGhhdCBJIHdhcyBub3QgdGhpbmtpbmcgYWJvdXQgTVMt UFdzPGJyPg0KJmd0OyB3aGVuIEkgdm9pY2VkIG15IHN1cHBvcnQuPGJyPg0KJmd0OyAmbmJzcDs8 YnI+DQomZ3Q7IEJ1dCBob3cgY2FuIHRoZSBnZW5lcmFsIE1TLVBXIGNhc2UgYmUgaGFuZGxlZCA/ ICZuYnNwO0Fzc3VtaW5nIHRyYW5zaXQ8YnI+DQomZ3Q7IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGJl IHJldGljZW50IGFib3V0IHJldmVhbGluZyB0b3BvbG9neSBpbmZvcm1hdGlvbiw8YnI+DQomZ3Q7 IHdlIG5lZWQgZm9yIHRoZSBlbnRpdHkgc2V0dGluZyB1cCB0aGUgUFcgdG8gcmVxdWVzdCBjby1y b3V0ZWQgTFNQczxicj4NCiZndDsgZnJvbSBlYWNoIHRyYW5zaXQgZG9tYWluLiAmbmJzcDtUaGUg cHJvYmxlbSB0aGVuIHJlZHVjZXMgdG8gcm91dGluZw0KdGhlIFBXPGJyPg0KJmd0OyB0aHJvdWdo IHRoZSBTLVBFcyB0aGF0IHRlcm1pbmF0ZSB0aGVzZSBMU1BzLCBhbmQgZW5zdXJpbmcgdGhhdCBh dA0KdGhlPGJyPg0KJmd0OyBTLVBFcyB0aGUgUFcgaXMgcHJvcGVybHkgcGxhY2VkLjxicj4NCiZn dDsgJm5ic3A7PGJyPg0KJmd0OyBBbiBpbnRlcmVzdGluZyBwcm9ibGVtIGFyaXNlcyBpZiB3ZSB3 YW50IFMtUEUgcmVkdW5kYW5jeS4gJm5ic3A7V2UNCndvdWxkPGJyPg0KJmd0OyBuZWVkIHRvIHRy aWdnZXIgc2ltdWx0YW5lb3VzIHN3aXRjaG92ZXJzIGluIGJvdGggZGlyZWN0aW9ucy48YnI+DQom Z3Q7ICZuYnNwOzxicj4NCiZndDsgSXQgd291bGQgc2VlbSB0aGF0IHRoZSBNUyBjYXNlIHdvdWxk IGJlIG1vcmUgZWFzaWx5IGhhbmRsZWQgYnk8YnI+DQomZ3Q7IG1hbmFnZW1lbnQgb3BlcmF0aW9u cy48YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgWShKKVM8YnI+DQo8YnI+DQo8YnI+DQpZYWFr b3YsPGJyPg0KPGJyPg0KTGF0ZSByZXNwb25zZS4uPGJyPg0KPGJyPg0KRm9yIHRoZSBNUy1QVyBj YXNlIHRoZSBvbmx5IHJlYWwgc29sdXRpb24gaXMgdG8gZWl0aGVyIDEpIHB1dCBjcml0ZXJpYTxi cj4NCmZvciBzZWxlY3Rpb24gb2YgYSB0dW5uZWwgaW4gdGhlIFBXIHNpZ25hbGluZywgb3IgMikg cHV0IGluIHRoZSB0dW5uZWw8YnI+DQpJRCAod2hpY2ggaXMgbm9ybWFsbHkgYSBjb25maWd1cmVk IHR1bm5lbCBpZGVudGlmaWVyIGZvciBhIFRFIExTUCkgYW5kPGJyPg0KdXNlIHdoYXRldmVyIExT UCB0aGF0IHR1bm5lbCBpcyB1c2luZy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5bRmVpXTwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+DQpUaGlzIGxldCBtZSBjb25zaWRlciBhbm90aGVyIHJlbGF0ZWQg cXVlc3Rpb24sIHdoeSBub3QgaW50cm9kY3VlIHRoZSBSZWNvcmQNClJvdXRlIFRMVjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5pbiB0aGUgUFcg c2lnbmFsaW5nIHNpbmNlDQp0aGUgRXhwbGljaXQgUm91dGUgVExWIGhhcyBiZWVuIGludHJvZHVj ZWQgaW4gdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMt c2VyaWYiPmRvY3VtZW50IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcHdl My1keW5hbWljLW1zLXB3LTEzI3NlY3Rpb24tNi4yLjQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPkFzIGRlc2NyaWJlZCBpbiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMjEyI3NlY3Rpb24tNC43LjQsDQpMU1AgSUQgY291 bGQgYmUgYSBzdWItVExWPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPm9mIEV4cGxpY2l0IFJvdXRlIFRMViwgd2hpY2gNCmNhbiBiZSB1c2VkIGlu IHRoZSBSZWNvcmQgUm91dGUgVExWIGFsc28uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPklmIHRoZSBSZWNvcmQgUm91dGUgVExWIGNh bg0KYmUgcmV1c2VkIGluIFNTLVBXIG9yIE1TLVBXLCBQVy10by1MU1AgYmluZGluZyBjYW4gYmUg cmVhbGl6ZWQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMt c2VyaWYiPmVhc2lseSBhbmQgdGhlIHNvbHV0aW9uIGlzDQpzY2FsYWJsZSBhbHNvLjwvZm9udD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NCkZvciBkeW1hbmljIHJvdXRpbmcgdGhl IHR1bm5lbCBzaG91bGQgYmUgdXNpbmcgdGhlIGJlc3Qgcm91dGU8YnI+DQphdmFpbGFibGUgYXQg dGhlIHRpbWUgZm9yIHRoZSBwYXJhbWV0ZXJzIGNvbmZpZ3VyZWQgb24gdGhlIHR1bm5lbC48L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlRoZSBzZWNvbmQgbWV0aG9kIGlzIGEgbG90 IHNpbXBsZXIuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0ic2Fucy1zZXJpZiI+W0ZlaV08L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPg0KWWVhaCwgaXQgaXMgYSBzaW1wbGVyIHNvbHV0aW9uLCBidXQgaWYgdHdvIG9yIG1vcmUg TFNQcyBhcmUgd29ya2luZyBMU1BzDQp1bmRlcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+dGhlIHNhbWUgdHVubmVsIChmb3IgZXhhbXBsZSwgaW4gdGhlDQpzY2Vu YXJpb3Mgb2YgRUNNUCksIGhvdyB0byBndWFyYW50ZWUgdGhlIHNhbWUgPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zZWxlY3Rpb24gb2YgdGhlIExTUCBJRD88L2Zv bnQ+PHR0Pjxmb250IHNpemU9Mj4NCiZuYnNwOyAmbmJzcDs8YnI+DQo8YnI+DQpJZiB5b3UgbmVl ZGVkIGR5bmFtaWMgUFcgc3dpdGNob3ZlciwgeW91J2QgbmVlZCB0byB1c2Ugc29tZXRoaW5nIGxp a2U8YnI+DQp0aGUgWFJPIG9iamVjdCBpbiB0aGUgTVMtUFcgc2lnbmFsaW5nIHNvIHRoYXQgdGhl IHdvcmtpbmcgYW5kIHByb3RlY3Q8YnI+DQpQVyBkaWQgbm90IHRha2UgYSBjb21tb24gUy1QRSBv ciBMU1AgcGF0aCB0aHJvdWdoIHRoZSBuZXR3b3JrLjxicj4NCjxicj4NCk15IHVuZGVyc3RhbmRp bmcgaXMgdGhhdCBNUy1QVyByZWR1bmRhbmN5IGlzIFQtUEUgdG8gVC1QRSBhbmQgaXM8YnI+DQpt b3N0bHkgdG8gcHJvdGVjdCBhZ2FpbnN0IGZhaWx1cmUgb24gdGhlIEFDIHNpZGUgb2YgdGhlIFBX LCB3aXRoIExTUDxicj4NCnByb3RlY3Rpb24gZGVhbGluZyB3aXRoIGEgZmF1bHQgYWxvbmcgdGhl IHdheS48YnI+DQo8YnI+DQpBdCBzb21lIHBvaW50IHlvdSBiZWdpbiB0byBkdXBsaWNhdGUgSUdQ LVRFIGFuZCBSU1ZQLVRFIGluIFQtTERQLjxicj4NClNvcnQgb2YgbGlrZSBkdXBsaWNhdGluZyBz b21lIG9mIGl0IGluIFRQIE9BTSAoZm9yIG5vIGdvb2QgdGVjaG5pY2FsPGJyPg0KcmVhc29uIElN SE8pLjxicj4NCjxicj4NCkN1cnRpczxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcHdlMyBtYWlsaW5nIGxpc3Q8YnI+DQpwd2Uz QGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2Uz PGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 0030E92648257878_=-- From mach.chen@huawei.com Wed Apr 20 03:04:04 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4725EE06B1; Wed, 20 Apr 2011 03:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.594 X-Spam-Level: X-Spam-Status: No, score=-5.594 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa33PT3p3n-1; Wed, 20 Apr 2011 03:04:03 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 5A3A9E0689; Wed, 20 Apr 2011 03:04:03 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJY004483SZGJ@szxga04-in.huawei.com>; Wed, 20 Apr 2011 18:00:35 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJY006QH3SQPK@szxga04-in.huawei.com>; Wed, 20 Apr 2011 18:00:35 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 20 Apr 2011 18:00:22 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Wed, 20 Apr 2011 18:00:26 +0800 Date: Wed, 20 Apr 2011 09:59:29 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.38] To: "zhang.fei3@zte.com.cn" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL/lHK73nHo264nEOurU5XIB5ZMZRl7lcAgACR4BCAAABOoA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <201104190520.p3J5KKVT020136@harbor.orleans.occnc.com> Cc: "pwe3-bounces@ietf.org" , Luca Martini , Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 10:04:04 -0000 SGkgRmVpLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4uLg0KDQo+ID4gQ3VydGlzDQo+ID4gPiBQdXR0 aW5nIHRoZSBQVyBpbnRvIHRoZSByaWdodCBMU1Agc29sdmVzIHRoZSBwcm9ibGVtIGZvciBTUy1Q VyBhbmQgZm9yDQo+ID4gPiB0aGUgZmlyc3QgaG9wIG9mIGEgTVMtUFcsIGJ1dCBub3QgZm9yIHRo ZSBtaWRkbGUgaG9wcyBvZiBNUy1QVy4NCj4gPg0KPiA+IFllcywgSSBhZ3JlZS4gwqBJIG11c3Qg YWRtaXQgdGhhdCBJIHdhcyBub3QgdGhpbmtpbmcgYWJvdXQgTVMtUFdzDQo+ID4gd2hlbiBJIHZv aWNlZCBteSBzdXBwb3J0Lg0KPiA+DQo+ID4gQnV0IGhvdyBjYW4gdGhlIGdlbmVyYWwgTVMtUFcg Y2FzZSBiZSBoYW5kbGVkID8gwqBBc3N1bWluZyB0cmFuc2l0DQo+ID4gc2VydmljZSBwcm92aWRl cnMgdG8gYmUgcmV0aWNlbnQgYWJvdXQgcmV2ZWFsaW5nIHRvcG9sb2d5IGluZm9ybWF0aW9uLA0K PiA+IHdlIG5lZWQgZm9yIHRoZSBlbnRpdHkgc2V0dGluZyB1cCB0aGUgUFcgdG8gcmVxdWVzdCBj by1yb3V0ZWQgTFNQcw0KPiA+IGZyb20gZWFjaCB0cmFuc2l0IGRvbWFpbi4gwqBUaGUgcHJvYmxl bSB0aGVuIHJlZHVjZXMgdG8gcm91dGluZyB0aGUgUFcNCj4gPiB0aHJvdWdoIHRoZSBTLVBFcyB0 aGF0IHRlcm1pbmF0ZSB0aGVzZSBMU1BzLCBhbmQgZW5zdXJpbmcgdGhhdCBhdCB0aGUNCj4gPiBT LVBFcyB0aGUgUFcgaXMgcHJvcGVybHkgcGxhY2VkLg0KPiA+DQo+ID4gQW4gaW50ZXJlc3Rpbmcg cHJvYmxlbSBhcmlzZXMgaWYgd2Ugd2FudCBTLVBFIHJlZHVuZGFuY3kuIMKgV2Ugd291bGQNCj4g PiBuZWVkIHRvIHRyaWdnZXIgc2ltdWx0YW5lb3VzIHN3aXRjaG92ZXJzIGluIGJvdGggZGlyZWN0 aW9ucy4NCj4gPg0KPiA+IEl0IHdvdWxkIHNlZW0gdGhhdCB0aGUgTVMgY2FzZSB3b3VsZCBiZSBt b3JlIGVhc2lseSBoYW5kbGVkIGJ5DQo+ID4gbWFuYWdlbWVudCBvcGVyYXRpb25zLg0KPiA+DQo+ ID4gWShKKVMNCj4gDQo+IA0KPiBZYWFrb3YsDQo+IA0KPiBMYXRlIHJlc3BvbnNlLi4NCj4gDQo+ IEZvciB0aGUgTVMtUFcgY2FzZSB0aGUgb25seSByZWFsIHNvbHV0aW9uIGlzIHRvIGVpdGhlciAx KSBwdXQgY3JpdGVyaWENCj4gZm9yIHNlbGVjdGlvbiBvZiBhIHR1bm5lbCBpbiB0aGUgUFcgc2ln bmFsaW5nLCBvciAyKSBwdXQgaW4gdGhlIHR1bm5lbA0KPiBJRCAod2hpY2ggaXMgbm9ybWFsbHkg YSBjb25maWd1cmVkIHR1bm5lbCBpZGVudGlmaWVyIGZvciBhIFRFIExTUCkgYW5kDQo+IHVzZSB3 aGF0ZXZlciBMU1AgdGhhdCB0dW5uZWwgaXMgdXNpbmcuDQo+IA0KPiBbRmVpXSBUaGlzIGxldCBt ZSBjb25zaWRlciBhbm90aGVyIHJlbGF0ZWQgcXVlc3Rpb24sIHdoeSBub3QgaW50cm9kY3VlIHRo ZQ0KPiBSZWNvcmQgUm91dGUgVExWDQo+IGluIHRoZSBQVyBzaWduYWxpbmcgc2luY2UgdGhlIEV4 cGxpY2l0IFJvdXRlIFRMViBoYXMgYmVlbiBpbnRyb2R1Y2VkIGluIHRoZQ0KPiBkb2N1bWVudA0K PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXB3ZTMtZHluYW1pYy1tcy1w dy0xMyNzZWN0aW9uLTYuMi40Lg0KPiANCj4gQXMgZGVzY3JpYmVkIGluIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzMyMTIjc2VjdGlvbi00LjcuNCwgTFNQIElEIGNvdWxkDQo+IGJlIGEg c3ViLVRMVg0KPiBvZiBFeHBsaWNpdCBSb3V0ZSBUTFYsIHdoaWNoIGNhbiBiZSB1c2VkIGluIHRo ZSBSZWNvcmQgUm91dGUgVExWIGFsc28uDQo+IA0KPiBJZiB0aGUgUmVjb3JkIFJvdXRlIFRMViBj YW4gYmUgcmV1c2VkIGluIFNTLVBXIG9yIE1TLVBXLCBQVy10by1MU1AgYmluZGluZw0KPiBjYW4g YmUgcmVhbGl6ZWQNCj4gZWFzaWx5IGFuZCB0aGUgc29sdXRpb24gaXMgc2NhbGFibGUgYWxzby4N Cg0KSWYgdGhlIG9yaWdpbmF0aW5nIFBFIG9yIHRoZSBvcGVyYXRvciBoYXZlIHRoZSB0dW5uZWxz IGluZm9ybWF0aW9uLCBleHBsaWNpdGx5IHNwZWNpZnlpbmcgdGhlIFR1bm5lbCBMU1BzIGlzIGEg Y2FuZGlkYXRlIHNvbHV0aW9uLCB0aGVyZSB3ZXJlIHNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbnMg YWJvdXQgdGhpcy4gRGVmaW5pbmcgYSBuZXcgVExWIG9yIHJldXNpbmcgdGhlIGV4aXN0aW5nIFRM ViBpcyBlYXN5LCB0aGUgZGlmZmljdWx0IGZvciB0aGlzIG1ldGhvZCBpcyB0aGF0IHRoZSBvcmln aW5hdGluZyBQRSBpcyBoYXJkIG9yIGV2ZW4gaW1wb3NzaWJsZSB0byBrbm93IHRoZSBpbmZvcm1h dGlvbiBvZiB0aGUgbWlkZGxlIHR1bm5lbCBMU1BzLiANCg0KQlRXLCBSRkMzMjEyIGhhcyBhbHJl YWR5IGJlZW4gYWJhbmRvbmVkIGJ5IElFVEYgZm9yIHllYXJzLg0KDQo+IA0KPiBGb3IgZHltYW5p YyByb3V0aW5nIHRoZSB0dW5uZWwgc2hvdWxkIGJlIHVzaW5nIHRoZSBiZXN0IHJvdXRlDQo+IGF2 YWlsYWJsZSBhdCB0aGUgdGltZSBmb3IgdGhlIHBhcmFtZXRlcnMgY29uZmlndXJlZCBvbiB0aGUg dHVubmVsLg0KPiBUaGUgc2Vjb25kIG1ldGhvZCBpcyBhIGxvdCBzaW1wbGVyLg0KPiANCj4gW0Zl aV0gWWVhaCwgaXQgaXMgYSBzaW1wbGVyIHNvbHV0aW9uLCBidXQgaWYgdHdvIG9yIG1vcmUgTFNQ cyBhcmUgd29ya2luZyBMU1BzDQo+IHVuZGVyDQo+IHRoZSBzYW1lIHR1bm5lbCAoZm9yIGV4YW1w bGUsIGluIHRoZSBzY2VuYXJpb3Mgb2YgRUNNUCksIGhvdyB0byBndWFyYW50ZWUgdGhlDQo+IHNh bWUNCj4gc2VsZWN0aW9uIG9mIHRoZSBMU1AgSUQ/DQoNClRoaXMgaXMgd2h5IHRoZSBjdXJyZW50 IGRyYWZ0IGluY2x1ZGVzIExTUCBJRCBpbiB0aGUgUFcgdG8gTFNQIEJpbmRpbmcgVExWLiANCg0K QWx0aG91Z2ggcHJpbWFyeS9zdGFuZGJ5IGlzIHRoZSBtb3N0IHVzYWdlLCBJIGFtIG5vdCBzdXJl IHdoZXRoZXIgdGhlcmUgYXJlIHJlcXVpcmVtZW50cyBvciBkZXBsb3ltZW50cyBhYm91dCBtdWx0 aXBsZSB3b3JraW5nIExTUHMgZm9yIGxvYWQgYmFsYW5jaW5nL0VDTVAuIA0KDQpCZXN0IHJlZ2Fy ZHMsDQpNYWNoDQo= From zhang.fei3@zte.com.cn Wed Apr 20 07:07:55 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A80F5E065A; Wed, 20 Apr 2011 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.977 X-Spam-Level: X-Spam-Status: No, score=-94.977 tagged_above=-999 required=5 tests=[AWL=-2.187, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GF3RlKSwfx3D; Wed, 20 Apr 2011 07:07:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by ietfc.amsl.com (Postfix) with ESMTP id D7B0FE0613; Wed, 20 Apr 2011 07:07:52 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35103491178658; Wed, 20 Apr 2011 22:05:16 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 95720.8583967037; Wed, 20 Apr 2011 21:56:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3KE7eMt052698; Wed, 20 Apr 2011 22:07:40 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Mach Chen MIME-Version: 1.0 X-KeepSent: A422426D:AC43F553-48257878:004D1597; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 20 Apr 2011 22:07:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-20 22:07:42, Serialize complete at 2011-04-20 22:07:42 Content-Type: multipart/alternative; boundary="=_alternative 004D98A948257878_=" X-MAIL: mse01.zte.com.cn p3KE7eMt052698 Cc: "pwe3-bounces@ietf.org" , "pwe3@ietf.org" , Yaakov Stein , Luca Martini Subject: [PWE3] =?gb2312?b?tPC4tDogUkU6ICBQV0UzIHdvcmtpbmcgZ3JvdXAgcG9s?= =?gb2312?b?bCBmb3IJZHJhZnQtY2FvLXB3ZTMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxz?= =?gb2312?b?cC0wMi50eHQ=?= X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 14:07:55 -0000 This is a multipart message in MIME format. --=_alternative 004D98A948257878_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTWFjaA0KDQpzZWUgaW4gbGluZSBbRmVpXQ0KDQpJZiB0aGUgb3JpZ2luYXRpbmcgUEUgb3Ig dGhlIG9wZXJhdG9yIGhhdmUgdGhlIHR1bm5lbHMgaW5mb3JtYXRpb24sIA0KZXhwbGljaXRseSBz cGVjaWZ5aW5nIHRoZSBUdW5uZWwgTFNQcyBpcyBhIGNhbmRpZGF0ZSBzb2x1dGlvbiwgdGhlcmUg d2VyZSANCnNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbnMgYWJvdXQgdGhpcy4gRGVmaW5pbmcgYSBu ZXcgVExWIG9yIHJldXNpbmcgdGhlIA0KZXhpc3RpbmcgVExWIGlzIGVhc3ksIHRoZSBkaWZmaWN1 bHQgZm9yIHRoaXMgbWV0aG9kIGlzIHRoYXQgdGhlIA0Kb3JpZ2luYXRpbmcgUEUgaXMgaGFyZCBv ciBldmVuIGltcG9zc2libGUgdG8ga25vdyB0aGUgaW5mb3JtYXRpb24gb2YgdGhlIA0KbWlkZGxl IHR1bm5lbCBMU1BzLg0KDQpbRmVpXSBJIHRoaW5rIHlvdSBkaWQgbm90IGNhdGNoIG15IGlkZWEg Y2xlYXJseS4gdGhlIFJlY29yZCBSb3V0ZSBUTFYgaXMgDQp1c2VkIHRvIHJlY29yZCB0aGUgTFNQ IElEIG9yIGludGVyZmFjZSBJRCB0aGF0IHRoZSBQVyBwYXNzZXM7IGxpa2UgdGhlIA0KdXNhZ2Ug b2YgUlJPIG9iamVjdCBpbiBSU1ZQLVRFLg0KICAgICAgU28sIHRoZXJlIGlzIG5vIG5lZWQgZm9y IHRoZSBvcmlnaW5hdGluZyBQRSB0byBrbm93IHRoZSBpbmZvcm1hdGlvbiANCm9mIHRoZSBtaWRk bGUgdHVubmVsIExTUHMgYXQgdGhlIHN0YXJ0aW5nIHRpbWUuIA0KDQpCVFcsIFJGQzMyMTIgaGFz IGFscmVhZHkgYmVlbiBhYmFuZG9uZWQgYnkgSUVURiBmb3IgeWVhcnMuDQoNCltGZWldIFllYWgs IGJ1dCBJTUhPLCB0aGUgZXhpc3RpbmcgVExWIGNhbiBiZSByZXVzZWQgaWYgaXQgaXMgcG9zc2li bGUuDQoNCkIuUi4NCg0KRmVpDQoNCg0KDQpNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29t PiANCjIwMTEtMDQtMjAgMTc6NTkNCg0KytW8/sjLDQoiemhhbmcuZmVpM0B6dGUuY29tLmNuIiA8 emhhbmcuZmVpM0B6dGUuY29tLmNuPg0Ks63LzQ0KInB3ZTMtYm91bmNlc0BpZXRmLm9yZyIgPHB3 ZTMtYm91bmNlc0BpZXRmLm9yZz4sICJwd2UzQGlldGYub3JnIiANCjxwd2UzQGlldGYub3JnPiwg WWFha292IFN0ZWluIDx5YWFrb3Zfc0ByYWQuY29tPiwgTHVjYSBNYXJ0aW5pIA0KPGxtYXJ0aW5p QGNpc2NvLmNvbT4sICJjdXJ0aXNAb2NjbmMuY29tIiA8Y3VydGlzQG9jY25jLmNvbT4NCtb3zOIN ClJFOiBbUFdFM10gUFdFMyB3b3JraW5nIGdyb3VwIHBvbGwgZm9yIA0KZHJhZnQtY2FvLXB3ZTMt bXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wMi50eHQNCg0KDQoNCg0KDQoNCkhpIEZlaSwNCg0K UGxlYXNlIHNlZSBpbmxpbmUuLi4NCg0KPiA+IEN1cnRpcw0KPiA+ID4gUHV0dGluZyB0aGUgUFcg aW50byB0aGUgcmlnaHQgTFNQIHNvbHZlcyB0aGUgcHJvYmxlbSBmb3IgU1MtUFcgYW5kIA0KZm9y DQo+ID4gPiB0aGUgZmlyc3QgaG9wIG9mIGEgTVMtUFcsIGJ1dCBub3QgZm9yIHRoZSBtaWRkbGUg aG9wcyBvZiBNUy1QVy4NCj4gPg0KPiA+IFllcywgSSBhZ3JlZS4gIEkgbXVzdCBhZG1pdCB0aGF0 IEkgd2FzIG5vdCB0aGlua2luZyBhYm91dCBNUy1QV3MNCj4gPiB3aGVuIEkgdm9pY2VkIG15IHN1 cHBvcnQuDQo+ID4NCj4gPiBCdXQgaG93IGNhbiB0aGUgZ2VuZXJhbCBNUy1QVyBjYXNlIGJlIGhh bmRsZWQgPyAgQXNzdW1pbmcgdHJhbnNpdA0KPiA+IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGJlIHJl dGljZW50IGFib3V0IHJldmVhbGluZyB0b3BvbG9neSBpbmZvcm1hdGlvbiwNCj4gPiB3ZSBuZWVk IGZvciB0aGUgZW50aXR5IHNldHRpbmcgdXAgdGhlIFBXIHRvIHJlcXVlc3QgY28tcm91dGVkIExT UHMNCj4gPiBmcm9tIGVhY2ggdHJhbnNpdCBkb21haW4uICBUaGUgcHJvYmxlbSB0aGVuIHJlZHVj ZXMgdG8gcm91dGluZyB0aGUgUFcNCj4gPiB0aHJvdWdoIHRoZSBTLVBFcyB0aGF0IHRlcm1pbmF0 ZSB0aGVzZSBMU1BzLCBhbmQgZW5zdXJpbmcgdGhhdCBhdCB0aGUNCj4gPiBTLVBFcyB0aGUgUFcg aXMgcHJvcGVybHkgcGxhY2VkLg0KPiA+DQo+ID4gQW4gaW50ZXJlc3RpbmcgcHJvYmxlbSBhcmlz ZXMgaWYgd2Ugd2FudCBTLVBFIHJlZHVuZGFuY3kuICBXZSB3b3VsZA0KPiA+IG5lZWQgdG8gdHJp Z2dlciBzaW11bHRhbmVvdXMgc3dpdGNob3ZlcnMgaW4gYm90aCBkaXJlY3Rpb25zLg0KPiA+DQo+ ID4gSXQgd291bGQgc2VlbSB0aGF0IHRoZSBNUyBjYXNlIHdvdWxkIGJlIG1vcmUgZWFzaWx5IGhh bmRsZWQgYnkNCj4gPiBtYW5hZ2VtZW50IG9wZXJhdGlvbnMuDQo+ID4NCj4gPiBZKEopUw0KPiAN Cj4gDQo+IFlhYWtvdiwNCj4gDQo+IExhdGUgcmVzcG9uc2UuLg0KPiANCj4gRm9yIHRoZSBNUy1Q VyBjYXNlIHRoZSBvbmx5IHJlYWwgc29sdXRpb24gaXMgdG8gZWl0aGVyIDEpIHB1dCBjcml0ZXJp YQ0KPiBmb3Igc2VsZWN0aW9uIG9mIGEgdHVubmVsIGluIHRoZSBQVyBzaWduYWxpbmcsIG9yIDIp IHB1dCBpbiB0aGUgdHVubmVsDQo+IElEICh3aGljaCBpcyBub3JtYWxseSBhIGNvbmZpZ3VyZWQg dHVubmVsIGlkZW50aWZpZXIgZm9yIGEgVEUgTFNQKSBhbmQNCj4gdXNlIHdoYXRldmVyIExTUCB0 aGF0IHR1bm5lbCBpcyB1c2luZy4NCj4gDQo+IFtGZWldIFRoaXMgbGV0IG1lIGNvbnNpZGVyIGFu b3RoZXIgcmVsYXRlZCBxdWVzdGlvbiwgd2h5IG5vdCBpbnRyb2RjdWUgDQp0aGUNCj4gUmVjb3Jk IFJvdXRlIFRMVg0KPiBpbiB0aGUgUFcgc2lnbmFsaW5nIHNpbmNlIHRoZSBFeHBsaWNpdCBSb3V0 ZSBUTFYgaGFzIGJlZW4gaW50cm9kdWNlZCBpbiANCnRoZQ0KPiBkb2N1bWVudA0KPiANCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcHdlMy1keW5hbWljLW1zLXB3LTEzI3Nl Y3Rpb24tNi4yLjQuDQo+IA0KPiBBcyBkZXNjcmliZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMzIxMiNzZWN0aW9uLTQuNy40LCBMU1AgSUQgDQpjb3VsZA0KPiBiZSBhIHN1Yi1U TFYNCj4gb2YgRXhwbGljaXQgUm91dGUgVExWLCB3aGljaCBjYW4gYmUgdXNlZCBpbiB0aGUgUmVj b3JkIFJvdXRlIFRMViBhbHNvLg0KPiANCj4gSWYgdGhlIFJlY29yZCBSb3V0ZSBUTFYgY2FuIGJl IHJldXNlZCBpbiBTUy1QVyBvciBNUy1QVywgUFctdG8tTFNQIA0KYmluZGluZw0KPiBjYW4gYmUg cmVhbGl6ZWQNCj4gZWFzaWx5IGFuZCB0aGUgc29sdXRpb24gaXMgc2NhbGFibGUgYWxzby4NCg0K SWYgdGhlIG9yaWdpbmF0aW5nIFBFIG9yIHRoZSBvcGVyYXRvciBoYXZlIHRoZSB0dW5uZWxzIGlu Zm9ybWF0aW9uLCANCmV4cGxpY2l0bHkgc3BlY2lmeWluZyB0aGUgVHVubmVsIExTUHMgaXMgYSBj YW5kaWRhdGUgc29sdXRpb24sIHRoZXJlIHdlcmUgDQpzb21lIG9mZi1saW5lIGRpc2N1c3Npb25z IGFib3V0IHRoaXMuIERlZmluaW5nIGEgbmV3IFRMViBvciByZXVzaW5nIHRoZSANCmV4aXN0aW5n IFRMViBpcyBlYXN5LCB0aGUgZGlmZmljdWx0IGZvciB0aGlzIG1ldGhvZCBpcyB0aGF0IHRoZSAN Cm9yaWdpbmF0aW5nIFBFIGlzIGhhcmQgb3IgZXZlbiBpbXBvc3NpYmxlIHRvIGtub3cgdGhlIGlu Zm9ybWF0aW9uIG9mIHRoZSANCm1pZGRsZSB0dW5uZWwgTFNQcy4gDQoNCkJUVywgUkZDMzIxMiBo YXMgYWxyZWFkeSBiZWVuIGFiYW5kb25lZCBieSBJRVRGIGZvciB5ZWFycy4NCg0KPiANCj4gRm9y IGR5bWFuaWMgcm91dGluZyB0aGUgdHVubmVsIHNob3VsZCBiZSB1c2luZyB0aGUgYmVzdCByb3V0 ZQ0KPiBhdmFpbGFibGUgYXQgdGhlIHRpbWUgZm9yIHRoZSBwYXJhbWV0ZXJzIGNvbmZpZ3VyZWQg b24gdGhlIHR1bm5lbC4NCj4gVGhlIHNlY29uZCBtZXRob2QgaXMgYSBsb3Qgc2ltcGxlci4NCj4g DQo+IFtGZWldIFllYWgsIGl0IGlzIGEgc2ltcGxlciBzb2x1dGlvbiwgYnV0IGlmIHR3byBvciBt b3JlIExTUHMgYXJlIA0Kd29ya2luZyBMU1BzDQo+IHVuZGVyDQo+IHRoZSBzYW1lIHR1bm5lbCAo Zm9yIGV4YW1wbGUsIGluIHRoZSBzY2VuYXJpb3Mgb2YgRUNNUCksIGhvdyB0byANCmd1YXJhbnRl ZSB0aGUNCj4gc2FtZQ0KPiBzZWxlY3Rpb24gb2YgdGhlIExTUCBJRD8NCg0KVGhpcyBpcyB3aHkg dGhlIGN1cnJlbnQgZHJhZnQgaW5jbHVkZXMgTFNQIElEIGluIHRoZSBQVyB0byBMU1AgQmluZGlu ZyANClRMVi4gDQoNCkFsdGhvdWdoIHByaW1hcnkvc3RhbmRieSBpcyB0aGUgbW9zdCB1c2FnZSwg SSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZXJlIA0KYXJlIHJlcXVpcmVtZW50cyBvciBkZXBsb3lt ZW50cyBhYm91dCBtdWx0aXBsZSB3b3JraW5nIExTUHMgZm9yIGxvYWQgDQpiYWxhbmNpbmcvRUNN UC4gDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KDQo= --=_alternative 004D98A948257878_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE1hY2g8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNlZSBpbiBsaW5lIDwvZm9udD48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5bRmVpXTwvZm9udD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPklmIHRoZSBvcmlnaW5hdGluZyBQRSBvciB0aGUgb3Bl cmF0b3IgaGF2ZSB0aGUgdHVubmVscw0KaW5mb3JtYXRpb24sIGV4cGxpY2l0bHkgc3BlY2lmeWlu ZyB0aGUgVHVubmVsIExTUHMgaXMgYSBjYW5kaWRhdGUgc29sdXRpb24sDQp0aGVyZSB3ZXJlIHNv bWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbnMgYWJvdXQgdGhpcy4gRGVmaW5pbmcgYSBuZXcgVExWIG9y DQpyZXVzaW5nIHRoZSBleGlzdGluZyBUTFYgaXMgZWFzeSwgdGhlIGRpZmZpY3VsdCBmb3IgdGhp cyBtZXRob2QgaXMgdGhhdA0KdGhlIG9yaWdpbmF0aW5nIFBFIGlzIGhhcmQgb3IgZXZlbiBpbXBv c3NpYmxlIHRvIGtub3cgdGhlIGluZm9ybWF0aW9uIG9mDQp0aGUgbWlkZGxlIHR1bm5lbCBMU1Bz LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5bRmVp XSBJIHRoaW5rIHlvdSBkaWQgbm90IGNhdGNoIG15IGlkZWENCmNsZWFybHkuIHRoZSBSZWNvcmQg Um91dGUgVExWIGlzIHVzZWQgdG8gcmVjb3JkIHRoZSBMU1AgSUQgb3IgaW50ZXJmYWNlDQpJRCB0 aGF0IHRoZSBQVyBwYXNzZXM7IGxpa2UgdGhlIHVzYWdlIG9mIFJSTyBvYmplY3QgaW4gUlNWUC1U RS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgU28sIHRoZXJlIGlzIG5vIG5lZWQNCmZvciB0aGUgb3JpZ2luYXRpbmcgUEUg dG8ga25vdyB0aGUgaW5mb3JtYXRpb24gb2YgdGhlIG1pZGRsZSB0dW5uZWwgTFNQcw0KYXQgdGhl IHN0YXJ0aW5nIHRpbWUuIDwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJyPg0K QlRXLCBSRkMzMjEyIGhhcyBhbHJlYWR5IGJlZW4gYWJhbmRvbmVkIGJ5IElFVEYgZm9yIHllYXJz LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5bRmVp XSBZZWFoLCBidXQgSU1ITywgdGhlIGV4aXN0aW5nIFRMVg0KY2FuIGJlIHJldXNlZCBpZiBpdCBp cyBwb3NzaWJsZS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkIuUi48 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkZlaTwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPk1hY2ggQ2hlbiAm bHQ7bWFjaC5jaGVuQGh1YXdlaS5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDQtMjAgMTc6NTk8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQl Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7emhhbmcuZmVpM0B6dGUu Y29tLmNuJnF1b3Q7ICZsdDt6aGFuZy5mZWkzQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4mcXVvdDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmcmcXVvdDsgJmx0O3B3ZTMtYm91bmNlc0Bp ZXRmLm9yZyZndDssDQomcXVvdDtwd2UzQGlldGYub3JnJnF1b3Q7ICZsdDtwd2UzQGlldGYub3Jn Jmd0OywgWWFha292IFN0ZWluICZsdDt5YWFrb3Zfc0ByYWQuY29tJmd0OywNCkx1Y2EgTWFydGlu aSAmbHQ7bG1hcnRpbmlAY2lzY28uY29tJmd0OywgJnF1b3Q7Y3VydGlzQG9jY25jLmNvbSZxdW90 OyAmbHQ7Y3VydGlzQG9jY25jLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbUFdFM10g UFdFMyB3b3JraW5nIGdyb3VwIHBvbGwgZm9yDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtk cmFmdC1jYW8tcHdlMy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTAyLnR4dDwvZm9udD48L3Rh YmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4N Cjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGkgRmVpLDxi cj4NCjxicj4NClBsZWFzZSBzZWUgaW5saW5lLi4uPGJyPg0KPGJyPg0KJmd0OyAmZ3Q7IEN1cnRp czxicj4NCiZndDsgJmd0OyAmZ3Q7IFB1dHRpbmcgdGhlIFBXIGludG8gdGhlIHJpZ2h0IExTUCBz b2x2ZXMgdGhlIHByb2JsZW0gZm9yDQpTUy1QVyBhbmQgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsg dGhlIGZpcnN0IGhvcCBvZiBhIE1TLVBXLCBidXQgbm90IGZvciB0aGUgbWlkZGxlIGhvcHMgb2YN Ck1TLVBXLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBZZXMsIEkgYWdyZWUuICZuYnNw O0kgbXVzdCBhZG1pdCB0aGF0IEkgd2FzIG5vdCB0aGlua2luZyBhYm91dA0KTVMtUFdzPGJyPg0K Jmd0OyAmZ3Q7IHdoZW4gSSB2b2ljZWQgbXkgc3VwcG9ydC48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgQnV0IGhvdyBjYW4gdGhlIGdlbmVyYWwgTVMtUFcgY2FzZSBiZSBoYW5kbGVkID8g Jm5ic3A7QXNzdW1pbmcNCnRyYW5zaXQ8YnI+DQomZ3Q7ICZndDsgc2VydmljZSBwcm92aWRlcnMg dG8gYmUgcmV0aWNlbnQgYWJvdXQgcmV2ZWFsaW5nIHRvcG9sb2d5IGluZm9ybWF0aW9uLDxicj4N CiZndDsgJmd0OyB3ZSBuZWVkIGZvciB0aGUgZW50aXR5IHNldHRpbmcgdXAgdGhlIFBXIHRvIHJl cXVlc3QgY28tcm91dGVkDQpMU1BzPGJyPg0KJmd0OyAmZ3Q7IGZyb20gZWFjaCB0cmFuc2l0IGRv bWFpbi4gJm5ic3A7VGhlIHByb2JsZW0gdGhlbiByZWR1Y2VzIHRvIHJvdXRpbmcNCnRoZSBQVzxi cj4NCiZndDsgJmd0OyB0aHJvdWdoIHRoZSBTLVBFcyB0aGF0IHRlcm1pbmF0ZSB0aGVzZSBMU1Bz LCBhbmQgZW5zdXJpbmcgdGhhdA0KYXQgdGhlPGJyPg0KJmd0OyAmZ3Q7IFMtUEVzIHRoZSBQVyBp cyBwcm9wZXJseSBwbGFjZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFuIGludGVy ZXN0aW5nIHByb2JsZW0gYXJpc2VzIGlmIHdlIHdhbnQgUy1QRSByZWR1bmRhbmN5LiAmbmJzcDtX ZQ0Kd291bGQ8YnI+DQomZ3Q7ICZndDsgbmVlZCB0byB0cmlnZ2VyIHNpbXVsdGFuZW91cyBzd2l0 Y2hvdmVycyBpbiBib3RoIGRpcmVjdGlvbnMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IEl0IHdvdWxkIHNlZW0gdGhhdCB0aGUgTVMgY2FzZSB3b3VsZCBiZSBtb3JlIGVhc2lseSBoYW5k bGVkIGJ5PGJyPg0KJmd0OyAmZ3Q7IG1hbmFnZW1lbnQgb3BlcmF0aW9ucy48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgWShKKVM8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBZ YWFrb3YsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExhdGUgcmVzcG9uc2UuLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBGb3IgdGhlIE1TLVBXIGNhc2UgdGhlIG9ubHkgcmVhbCBzb2x1dGlvbiBpcyB0byBl aXRoZXIgMSkgcHV0IGNyaXRlcmlhPGJyPg0KJmd0OyBmb3Igc2VsZWN0aW9uIG9mIGEgdHVubmVs IGluIHRoZSBQVyBzaWduYWxpbmcsIG9yIDIpIHB1dCBpbiB0aGUgdHVubmVsPGJyPg0KJmd0OyBJ RCAod2hpY2ggaXMgbm9ybWFsbHkgYSBjb25maWd1cmVkIHR1bm5lbCBpZGVudGlmaWVyIGZvciBh IFRFIExTUCkNCmFuZDxicj4NCiZndDsgdXNlIHdoYXRldmVyIExTUCB0aGF0IHR1bm5lbCBpcyB1 c2luZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgW0ZlaV0gVGhpcyBsZXQgbWUgY29uc2lkZXIgYW5v dGhlciByZWxhdGVkIHF1ZXN0aW9uLCB3aHkgbm90IGludHJvZGN1ZQ0KdGhlPGJyPg0KJmd0OyBS ZWNvcmQgUm91dGUgVExWPGJyPg0KJmd0OyBpbiB0aGUgUFcgc2lnbmFsaW5nIHNpbmNlIHRoZSBF eHBsaWNpdCBSb3V0ZSBUTFYgaGFzIGJlZW4gaW50cm9kdWNlZA0KaW4gdGhlPGJyPg0KJmd0OyBk b2N1bWVudDxicj4NCiZndDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1w d2UzLWR5bmFtaWMtbXMtcHctMTMjc2VjdGlvbi02LjIuNC48YnI+DQomZ3Q7IDxicj4NCiZndDsg QXMgZGVzY3JpYmVkIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMyMTIjc2VjdGlv bi00LjcuNCwNCkxTUCBJRCBjb3VsZDxicj4NCiZndDsgYmUgYSBzdWItVExWPGJyPg0KJmd0OyBv ZiBFeHBsaWNpdCBSb3V0ZSBUTFYsIHdoaWNoIGNhbiBiZSB1c2VkIGluIHRoZSBSZWNvcmQgUm91 dGUgVExWIGFsc28uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIHRoZSBSZWNvcmQgUm91dGUgVExW IGNhbiBiZSByZXVzZWQgaW4gU1MtUFcgb3IgTVMtUFcsIFBXLXRvLUxTUA0KYmluZGluZzxicj4N CiZndDsgY2FuIGJlIHJlYWxpemVkPGJyPg0KJmd0OyBlYXNpbHkgYW5kIHRoZSBzb2x1dGlvbiBp cyBzY2FsYWJsZSBhbHNvLjxicj4NCjxicj4NCklmIHRoZSBvcmlnaW5hdGluZyBQRSBvciB0aGUg b3BlcmF0b3IgaGF2ZSB0aGUgdHVubmVscyBpbmZvcm1hdGlvbiwgZXhwbGljaXRseQ0Kc3BlY2lm eWluZyB0aGUgVHVubmVsIExTUHMgaXMgYSBjYW5kaWRhdGUgc29sdXRpb24sIHRoZXJlIHdlcmUg c29tZSBvZmYtbGluZQ0KZGlzY3Vzc2lvbnMgYWJvdXQgdGhpcy4gRGVmaW5pbmcgYSBuZXcgVExW IG9yIHJldXNpbmcgdGhlIGV4aXN0aW5nIFRMVg0KaXMgZWFzeSwgdGhlIGRpZmZpY3VsdCBmb3Ig dGhpcyBtZXRob2QgaXMgdGhhdCB0aGUgb3JpZ2luYXRpbmcgUEUgaXMgaGFyZA0Kb3IgZXZlbiBp bXBvc3NpYmxlIHRvIGtub3cgdGhlIGluZm9ybWF0aW9uIG9mIHRoZSBtaWRkbGUgdHVubmVsIExT UHMuIDxicj4NCjxicj4NCkJUVywgUkZDMzIxMiBoYXMgYWxyZWFkeSBiZWVuIGFiYW5kb25lZCBi eSBJRVRGIGZvciB5ZWFycy48YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgRm9yIGR5bWFuaWMg cm91dGluZyB0aGUgdHVubmVsIHNob3VsZCBiZSB1c2luZyB0aGUgYmVzdCByb3V0ZTxicj4NCiZn dDsgYXZhaWxhYmxlIGF0IHRoZSB0aW1lIGZvciB0aGUgcGFyYW1ldGVycyBjb25maWd1cmVkIG9u IHRoZSB0dW5uZWwuPGJyPg0KJmd0OyBUaGUgc2Vjb25kIG1ldGhvZCBpcyBhIGxvdCBzaW1wbGVy Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBbRmVpXSBZZWFoLCBpdCBpcyBhIHNpbXBsZXIgc29sdXRp b24sIGJ1dCBpZiB0d28gb3IgbW9yZSBMU1BzIGFyZQ0Kd29ya2luZyBMU1BzPGJyPg0KJmd0OyB1 bmRlcjxicj4NCiZndDsgdGhlIHNhbWUgdHVubmVsIChmb3IgZXhhbXBsZSwgaW4gdGhlIHNjZW5h cmlvcyBvZiBFQ01QKSwgaG93IHRvIGd1YXJhbnRlZQ0KdGhlPGJyPg0KJmd0OyBzYW1lPGJyPg0K Jmd0OyBzZWxlY3Rpb24gb2YgdGhlIExTUCBJRD88YnI+DQo8YnI+DQpUaGlzIGlzIHdoeSB0aGUg Y3VycmVudCBkcmFmdCBpbmNsdWRlcyBMU1AgSUQgaW4gdGhlIFBXIHRvIExTUCBCaW5kaW5nDQpU TFYuIDxicj4NCjxicj4NCkFsdGhvdWdoIHByaW1hcnkvc3RhbmRieSBpcyB0aGUgbW9zdCB1c2Fn ZSwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZXJlDQphcmUgcmVxdWlyZW1lbnRzIG9yIGRlcGxv eW1lbnRzIGFib3V0IG11bHRpcGxlIHdvcmtpbmcgTFNQcyBmb3IgbG9hZCBiYWxhbmNpbmcvRUNN UC4NCjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpNYWNoPGJyPg0KPC9mb250PjwvdHQ+ DQo8YnI+DQo= --=_alternative 004D98A948257878_=-- From lmartini@cisco.com Wed Apr 20 09:37:52 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B50C1E07AB for ; Wed, 20 Apr 2011 09:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD+6GOkqUNdN for ; Wed, 20 Apr 2011 09:37:51 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 94A76E0799 for ; Wed, 20 Apr 2011 09:37:51 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3KGbmoL004906 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 10:37:49 -0600 (MDT) Message-ID: <4DAF0BDC.5050506@cisco.com> Date: Wed, 20 Apr 2011 10:37:48 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 16:37:52 -0000 On 04/20/11 02:54, zhang.fei3@zte.com.cn wrote: > > Hi curtis, > > see in line[Fei] > > > *Curtis Villamizar * > ·¢¼þÈË: pwe3-bounces@ietf.org > > 2011-04-19 13:20 > Çë´ð¸´ ¸ø > curtis@occnc.com > > > > ÊÕ¼þÈË > Yaakov Stein > ³­ËÍ > "pwe3@ietf.org" , Luca Martini > Ö÷Ìâ > Re: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > > > > > > > > > > In message <07F7D7DED63154409F13298786A2ADC903D29381@EXRAD5.ad.rad.co.il> > Yaakov Stein writes: > > > > Curtis > > > Putting the PW into the right LSP solves the problem for SS-PW and for > > > the first hop of a MS-PW, but not for the middle hops of MS-PW. > > > > Yes, I agree. I must admit that I was not thinking about MS-PWs > > when I voiced my support. > > > > But how can the general MS-PW case be handled ? Assuming transit > > service providers to be reticent about revealing topology information, > > we need for the entity setting up the PW to request co-routed LSPs > > from each transit domain. The problem then reduces to routing the PW > > through the S-PEs that terminate these LSPs, and ensuring that at the > > S-PEs the PW is properly placed. > > > > An interesting problem arises if we want S-PE redundancy. We would > > need to trigger simultaneous switchovers in both directions. > > > > It would seem that the MS case would be more easily handled by > > management operations. > > > > Y(J)S > > > Yaakov, > > Late response.. > > For the MS-PW case the only real solution is to either 1) put criteria > for selection of a tunnel in the PW signaling, or 2) put in the tunnel > ID (which is normally a configured tunnel identifier for a TE LSP) and > use whatever LSP that tunnel is using. > > [Fei]This let me consider another related question, why not introdcue > the Record Route TLV > in the PW signaling since the Explicit Route TLV has been introduced > in the > document > http://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-13#section-6.2.4. > > As described in http://tools.ietf.org/html/rfc3212#section-4.7.4, LSP > ID could be a sub-TLV > of Explicit Route TLV, which can be used in the Record Route TLV also. > > If the Record Route TLV can be reused in SS-PW or MS-PW, PW-to-LSP > binding can be realized > easily and the solution is scalable also. > No. That Explicit Path TLV has nothing to do with the underling PSN. It simply selects the S-PEs that should be traversed, by overriding the normal PW routing table look up procedures. > > For dymanic routing the tunnel should be using the best route > available at the time for the parameters configured on the tunnel. > The second method is a lot simpler. > > [Fei]Yeah, it is a simpler solution, but if two or more LSPs are > working LSPs under > the same tunnel (for example, in the scenarios of ECMP), how to > guarantee the same > selection of the LSP ID? > I believe that the best way to solve this problem is to force a PW to select a specific bi-directional LSP. In the case of MS-PW this process needs to be repeated at each S-PE. As Curtis suggested , we can add a "PSN Tunnel Profile TLV" to the LDP signaling to indicate to each S-PE what kind of PSN tunnel is needed. Then we would need a "PSN traversed tunnel list TLV" to make sure that the reverse path ( for the PW) uses the exact same set of PSN tunnels. What needs to be well thought out, is how to handle all the corner cases when an initial failure occurs , and when something goes wrong in a middle segment of a working MS-PW. Luca > If you needed dynamic PW switchover, you'd need to use something like > the XRO object in the MS-PW signaling so that the working and protect > PW did not take a common S-PE or LSP path through the network. > > My understanding is that MS-PW redundancy is T-PE to T-PE and is > mostly to protect against failure on the AC side of the PW, with LSP > protection dealing with a fault along the way. > > At some point you begin to duplicate IGP-TE and RSVP-TE in T-LDP. > Sort of like duplicating some of it in TP OAM (for no good technical > reason IMHO). > > Curtis > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > From lmartini@cisco.com Wed Apr 20 15:12:56 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 60B96E0721; Wed, 20 Apr 2011 15:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bzj5gBBIsnH; Wed, 20 Apr 2011 15:12:55 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 9FA02E074D; Wed, 20 Apr 2011 15:12:55 -0700 (PDT) Received: from seven.monoski.com ([65.114.195.189]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3KMCo1B019904 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 16:12:51 -0600 (MDT) Message-ID: <4DAF5A61.70102@cisco.com> Date: Wed, 20 Apr 2011 16:12:49 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: pwe3-bounces@ietf.org, Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:12:56 -0000 On 04/20/2011 02:54 AM, zhang.fei3@zte.com.cn wrote: Cut.... > [Fei] This let me consider another related question, why not introdcue the > Record Route TLV > in the PW signaling since the Explicit Route TLV has been introduced in > the > document > http://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-13#section-6.2.4. > > As described in http://tools.ietf.org/html/rfc3212#section-4.7.4, LSP ID > could be a sub-TLV > of Explicit Route TLV, which can be used in the Record Route TLV also. > Because the functionality is already there. In the S-PE TLV. Again note that none of this information applies to the PSN tunnel. Luca From lmartini@cisco.com Wed Apr 20 15:19:35 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 72324E0796; Wed, 20 Apr 2011 15:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH4yZl4H4tYE; Wed, 20 Apr 2011 15:19:34 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 9D96AE0791; Wed, 20 Apr 2011 15:19:34 -0700 (PDT) Received: from seven.monoski.com ([65.114.195.189]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3KMISmx020321 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 16:18:29 -0600 (MDT) Message-ID: <4DAF5BB3.9030607@cisco.com> Date: Wed, 20 Apr 2011 16:18:27 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mach Chen References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:19:35 -0000 On 04/14/2011 08:35 PM, Mach Chen wrote: > Hi Luca, > > You said T-LDP is not part of the MPLS-TP control plane. > > IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is figure about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP layer. > > In addition, in the abstract of MPLS-TP control plane (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says: > "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs)..." > Mach, The point is not about running LDP over an MPLS-TP LSP. Today you simply cannot control or provision an MPLS-TP LSP using LDP. You can Provision a PW using LDP, but not an MPLS-TP LSP. There are several ways to run LDP over an MPLS -TP LSP, as well, but I cannot find an explicit indication of a standard way. In any case the problem you are proposing is not specific to MPLS-TP, so solution must be general enough to apply to MPLS. Luca > Best regards, > Mach > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Luca Martini >> Sent: Friday, April 15, 2011 2:11 AM >> To: Greg Mirsky >> Cc: pwe3@ietf.org >> Subject: Re: [PWE3] PWE3 working group poll for >> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt >> >> On 04/14/11 00:09, Greg Mirsky wrote: >>> Luca, >>> you've asked >>> How would LDP , which is IP based , even run on an MPLS-TP network ? >>> but isn't T-LDP part of MPLS-TP control plane? Control plane assumes >>> IP addressing thus use of T-LDP is plausible. >>> >> No T-LDP is not part of the MPLS-TP control plane. >> It could be , but i think folks are more leaning toward GMPLS instead. >> >> Note that the problem described in this document exists for MPLS. So in >> that case LDP is certainly used. But the document appears to only care >> about MPLS-TP. >> >> Luca >> >> >> >>> Regards, >>> Greg >>> From lmartini@cisco.com Wed Apr 20 17:16:47 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 81046E0721 for ; Wed, 20 Apr 2011 17:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNlVDe4xhoq9 for ; Wed, 20 Apr 2011 17:16:46 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 6B4BDE06E2 for ; Wed, 20 Apr 2011 17:16:46 -0700 (PDT) Received: from seven.monoski.com ([65.114.195.189]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3L0GeVN029497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 18:16:41 -0600 (MDT) Message-ID: <4DAF7767.1040803@cisco.com> Date: Wed, 20 Apr 2011 18:16:39 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Francesco Fondelli References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:16:47 -0000 On 04/15/2011 08:19 AM, Francesco Fondelli wrote: > Hi, > > hemmm D'oh :-) > > --- draft-ietf-ccamp-mpls-tp-cp-framework-06 --- > > 'Per the MPLS-TP framework [RFC5921], the MPLS-TP control plane is > based on GMPLS with > RSVP-TE for LSP signaling and targeted LDP for PW signaling' > > and "How would LDP , which is IP based , even run on an MPLS-TP network ?" > > just fine > really ? what if there is no GMPLS control plane ? There are several ways to run IP across a mpls-TP LSP , how are folks going to pick the same method ? Since in LDP you must target an IP address , how do you know what IP address to target to reach the end of an LSP ? or the opposite: given an IP address which LSP gets you there ? Of course you can configure everything manually, but then what is the value of running LDP ? The one liner in that GMPLS RFC does not address these problems when we have an MPLS-TP network. Or Am I missing some other document ? Luca > ciao > FF > > On Thu, Apr 14, 2011 at 8:10 PM, Luca Martini wrote: >> On 04/14/11 00:09, Greg Mirsky wrote: >>> Luca, >>> you've asked >>> How would LDP , which is IP based , even run on an MPLS-TP network ? >>> but isn't T-LDP part of MPLS-TP control plane? Control plane assumes >>> IP addressing thus use of T-LDP is plausible. >>> >> No T-LDP is not part of the MPLS-TP control plane. >> It could be , but i think folks are more leaning toward GMPLS instead. >> >> Note that the problem described in this document exists for MPLS. So in >> that case LDP is certainly used. But the document appears to only care >> about MPLS-TP. >> >> Luca >> >> >> >>> Regards, >>> Greg >>> >>> On Wed, Apr 13, 2011 at 10:27 PM, Luca Martini >> > wrote: >>> >>> On 04/13/11 05:49, Andrew G. Malis wrote: >>> > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have >>> > asked that this draft be made a PWE3 working group draft. >>> > >>> > This email starts a two week poll, closing Tuesday April 26, to help >>> > judge consensus on this. >>> > >>> > Please send your responses to the PWE3 list. >>> > >>> > Thanks, >>> > Andy and Matthew >>> > _______________________________________________ >>> > pwe3 mailing list >>> > pwe3@ietf.org >>> > https://www.ietf.org/mailman/listinfo/pwe3 >>> No, Not in the current form. >>> Although I agree that this problem is a real problem and needs a >>> solution, this draft does not have enough information to actually >>> build >>> a protocol extension to LDP. >>> In addition to the problems that Curtis mentions, there is no >>> description on how to use the proposed TLVs in the LDP message. >>> >>> How would LDP , which is IP based , even run on an MPLS-TP network ? >>> >>> PW assume that a PSN tunnel is identified by an IP address, which is >>> also used as the LDP target session IP address. >>> How is this possible with an MPLS-TP LSP ? >>> >>> At the minimum we would need some way to identify the IP address >>> at the >>> other end of the mpls-tp tunnel. >>> >>> Also I strongly believe that this WG needs to stop attempting to >>> extend >>> FEC 128 to have similar functionality as FEC 129. >>> Just define new extensions for FEC 129 only , unless they are minor , >>> and can be supported by FEC 128 without changing any existing >>> procedures... >>> >>> >>> Luca >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >>> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> From zhang.fei3@zte.com.cn Wed Apr 20 17:42:11 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0128EE0752; Wed, 20 Apr 2011 17:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.126 X-Spam-Level: X-Spam-Status: No, score=-97.126 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jpBxIhX+TwU; Wed, 20 Apr 2011 17:42:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by ietfc.amsl.com (Postfix) with ESMTP id C7E69E0693; Wed, 20 Apr 2011 17:42:07 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35103491178658; Thu, 21 Apr 2011 08:39:31 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 4886.8036321864; Thu, 21 Apr 2011 08:42:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3L0g0vo024138; Thu, 21 Apr 2011 08:42:00 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4DAF5A61.70102@cisco.com> To: Luca Martini MIME-Version: 1.0 X-KeepSent: FBA8626B:36200899-48257879:00020114; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 21 Apr 2011 08:42:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-21 08:42:01, Serialize complete at 2011-04-21 08:42:01 Content-Type: multipart/alternative; boundary="=_alternative 0003D59248257879_=" X-MAIL: mse02.zte.com.cn p3L0g0vo024138 Cc: pwe3-bounces@ietf.org, Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:42:11 -0000 This is a multipart message in MIME format. --=_alternative 0003D59248257879_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTHVjYQ0KDQpzZWUgaW4gbGluZVtGZWldDQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkNCg0KDQoN Ckx1Y2EgTWFydGluaSA8bG1hcnRpbmlAY2lzY28uY29tPiANCjIwMTEtMDQtMjEgMDY6MTINCg0K ytW8/sjLDQp6aGFuZy5mZWkzQHp0ZS5jb20uY24NCrOty80NCmN1cnRpc0BvY2NuYy5jb20sICJw d2UzQGlldGYub3JnIiA8cHdlM0BpZXRmLm9yZz4sIHB3ZTMtYm91bmNlc0BpZXRmLm9yZywgDQpZ YWFrb3YgU3RlaW4gPHlhYWtvdl9zQHJhZC5jb20+LCBUaG9tYXMgTmFkZWF1IDx0bmFkZWF1QGx1 Y2lkdmlzaW9uLmNvbT4NCtb3zOINClJlOiBbUFdFM10gUFdFMyB3b3JraW5nIGdyb3VwIHBvbGwg Zm9yIA0KZHJhZnQtY2FvLXB3ZTMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wMi50eHQNCg0K DQoNCg0KDQoNCk9uIDA0LzIwLzIwMTEgMDI6NTQgQU0sIHpoYW5nLmZlaTNAenRlLmNvbS5jbiB3 cm90ZToNCkN1dC4uLi4NCj4gW0ZlaV0gVGhpcyBsZXQgbWUgY29uc2lkZXIgYW5vdGhlciByZWxh dGVkIHF1ZXN0aW9uLCB3aHkgbm90IGludHJvZGN1ZSANCnRoZSANCj4gUmVjb3JkIFJvdXRlIFRM Vg0KPiBpbiB0aGUgUFcgc2lnbmFsaW5nIHNpbmNlIHRoZSBFeHBsaWNpdCBSb3V0ZSBUTFYgaGFz IGJlZW4gaW50cm9kdWNlZCBpbiANCj4gdGhlDQo+IGRvY3VtZW50IA0KPiANCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcHdlMy1keW5hbWljLW1zLXB3LTEzI3NlY3Rpb24t Ni4yLjQuDQo+DQo+IEFzIGRlc2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmMzMjEyI3NlY3Rpb24tNC43LjQsIExTUCBJRCANCg0KPiBjb3VsZCBiZSBhIHN1Yi1UTFYNCj4g b2YgRXhwbGljaXQgUm91dGUgVExWLCB3aGljaCBjYW4gYmUgdXNlZCBpbiB0aGUgUmVjb3JkIFJv dXRlIFRMViBhbHNvLg0KPg0KQmVjYXVzZSB0aGUgZnVuY3Rpb25hbGl0eSBpcyBhbHJlYWR5IHRo ZXJlLiBJbiB0aGUgUy1QRSBUTFYuDQpBZ2FpbiBub3RlIHRoYXQgbm9uZSBvZiB0aGlzIGluZm9y bWF0aW9uIGFwcGxpZXMgdG8gdGhlIFBTTiB0dW5uZWwuDQpMdWNhDQoNCltGZWldIFllYWgsIFMt UEUgVExWIGFuZCBFeHBsaWNpdCBSb3V0ZSBUTFYgaGF2ZSBiZWVuIGludHJvZHVjZWQgaW4gdGhl IA0KZG91Y21lbnQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjA3Mw0KYW5kIA0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wd2UzLWR5bmFtaWMtbXMtcHctMTMj c2VjdGlvbi02LjIuNC4NClRoZSByZWNvcmQgcm91dGUgd2FzIG5vdCBpbnRyb3VjZWQgaW4gdGhl IGRvY3VtZW50IA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIxMiwgYnV0IGl0IGlz IHVzZWZ1bC4gSWYgaXQgY2FuIGJlDQppbnRyb2R1Y2VkIGluIHRoZSBkb2N1bWVudCANCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcHdlMy1keW5hbWljLW1zLXB3LTEzLCAi UFNOIFR1bm5lbCANClByb2ZpbGUgVExWIiBjYW4gYmUgb25lIG9mIGl0J3Mgc3ViLVRMViwganVz dA0KbGlrZSBMU1BJRCBUTFYgKDB4MDgyMSkgaXMgb25lIHN1Yi1UTFYgb2YgdGhlIEV4cGxpY2l0 IFJvdXRlIFRMVi4NCkluIHRoaXMgd2F5LCB0aGUgc29sdXRpb24gaXMgYXBwbGljYWJsZSB0byBN UExTIGFuZCBNUExTLVRQLg0KDQoNCg0KDQo= --=_alternative 0003D59248257879_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEx1Y2E8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNlZSBpbiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+bGluZVtGZWldPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHM8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5MdWNhIE1hcnRpbmkg Jmx0O2xtYXJ0aW5pQGNpc2NvLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNC0yMSAwNjoxMjwvZm9udD4NCjx0ZCB3aWR0aD02NCU+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj56aGFuZy5mZWkzQHp0ZS5jb20uY248 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPmN1cnRpc0BvY2NuYy5jb20sICZxdW90O3B3ZTNAaWV0Zi5vcmcm cXVvdDsNCiZsdDtwd2UzQGlldGYub3JnJmd0OywgcHdlMy1ib3VuY2VzQGlldGYub3JnLCBZYWFr b3YgU3RlaW4gJmx0O3lhYWtvdl9zQHJhZC5jb20mZ3Q7LA0KVGhvbWFzIE5hZGVhdSAmbHQ7dG5h ZGVhdUBsdWNpZHZpc2lvbi5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW1BXRTNdIFBX RTMgd29ya2luZyBncm91cCBwb2xsIGZvcg0KZHJhZnQtY2FvLXB3ZTMtbXBscy10cC1wdy1vdmVy LWJpZGlyLWxzcC0wMi50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPk9uIDA0LzIwLzIwMTEgMDI6NTQgQU0sIHpoYW5nLmZlaTNAenRl LmNvbS5jbiB3cm90ZTo8YnI+DQpDdXQuLi4uPGJyPg0KJmd0OyBbRmVpXSBUaGlzIGxldCBtZSBj b25zaWRlciBhbm90aGVyIHJlbGF0ZWQgcXVlc3Rpb24sIHdoeSBub3QgaW50cm9kY3VlDQp0aGUg PGJyPg0KJmd0OyBSZWNvcmQgUm91dGUgVExWPGJyPg0KJmd0OyBpbiB0aGUgUFcgc2lnbmFsaW5n IHNpbmNlIHRoZSBFeHBsaWNpdCBSb3V0ZSBUTFYgaGFzIGJlZW4gaW50cm9kdWNlZA0KaW4gPGJy Pg0KJmd0OyB0aGU8YnI+DQomZ3Q7IGRvY3VtZW50IDxicj4NCiZndDsgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wd2UzLWR5bmFtaWMtbXMtcHctMTMjc2VjdGlvbi02LjIu NC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBcyBkZXNjcmliZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjMzIxMiNzZWN0aW9uLTQuNy40LA0KTFNQIElEIDxicj4NCiZndDsgY291bGQg YmUgYSBzdWItVExWPGJyPg0KJmd0OyBvZiBFeHBsaWNpdCBSb3V0ZSBUTFYsIHdoaWNoIGNhbiBi ZSB1c2VkIGluIHRoZSBSZWNvcmQgUm91dGUgVExWIGFsc28uPGJyPg0KJmd0Ozxicj4NCkJlY2F1 c2UgdGhlIGZ1bmN0aW9uYWxpdHkgaXMgYWxyZWFkeSB0aGVyZS4gSW4gdGhlIFMtUEUgVExWLjxi cj4NCkFnYWluIG5vdGUgdGhhdCBub25lIG9mIHRoaXMgaW5mb3JtYXRpb24gYXBwbGllcyB0byB0 aGUgUFNOIHR1bm5lbC48YnI+DQpMdWNhPGJyPg0KPGJyPg0KW0ZlaV0gPC9mb250PjwvdHQ+PHR0 Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPlllYWgsIFMtUEUgVExWIGFuZCBFeHBsaWNpdA0KUm91 dGUgVExWIGhhdmUgYmVlbiBpbnRyb2R1Y2VkIGluIHRoZSBkb3VjbWVudCBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2MDczPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9MiBj b2xvcj1ibHVlPmFuZCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXB3ZTMt ZHluYW1pYy1tcy1wdy0xMyNzZWN0aW9uLTYuMi40LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZT5UaGUgcmVjb3JkIHJvdXRlIHdhcyBub3QgaW50cm91Y2VkIGlu IHRoZQ0KZG9jdW1lbnQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIxMiwgYnV0IGl0 IGlzIHVzZWZ1bC4gSWYgaXQgY2FuDQpiZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZT5pbnRyb2R1Y2VkIGluIHRoZSBkb2N1bWVudCBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXB3ZTMtZHluYW1pYy1tcy1wdy0xMywNCiZxdW90O1BTTiBU dW5uZWwgUHJvZmlsZSBUTFYmcXVvdDsgY2FuIGJlIG9uZSBvZiBpdCdzIHN1Yi1UTFYsIGp1c3Q8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+bGlrZSA8L2ZvbnQ+ PC90dD48dHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+TFNQSUQNClRMViAoMHgwODIxKSBpcyBv bmUgc3ViLVRMViBvZiA8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+dGhl DQpFeHBsaWNpdCBSb3V0ZSBUTFY8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWU+LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5JbiB0aGlz IHdheSwgdGhlIHNvbHV0aW9uIGlzIGFwcGxpY2FibGUNCnRvIE1QTFMgYW5kIE1QTFMtVFAuPC9m b250PjwvdHQ+PHR0Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4N Cjxicj4NCg== --=_alternative 0003D59248257879_=-- From mach.chen@huawei.com Wed Apr 20 18:57:12 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 397DCE0712; Wed, 20 Apr 2011 18:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.276 X-Spam-Level: X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=-1.481, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Kmky+dwucpZ; Wed, 20 Apr 2011 18:57:11 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id B2631E06DB; Wed, 20 Apr 2011 18:57:10 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJZ00IIKC36LG@szxga03-in.huawei.com>; Thu, 21 Apr 2011 09:57:06 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJZ008PVC2WX1@szxga03-in.huawei.com>; Thu, 21 Apr 2011 09:57:06 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Apr 2011 09:56:50 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 21 Apr 2011 09:56:54 +0800 Date: Thu, 21 Apr 2011 01:55:53 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.38] To: "zhang.fei3@zte.com.cn" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7HOnIWPrFKQ8iOsQwG5fog)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: RE: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL/lHK73nHo264nEOurU5XIB5ZMZRl7lcAgACR4BCAAABOoP//xV4AgAFKOYA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "pwe3-bounces@ietf.org" , "pwe3@ietf.org" , Yaakov Stein , Luca Martini Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 01:57:12 -0000 --Boundary_(ID_7HOnIWPrFKQ8iOsQwG5fog) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgRmVpLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UhDQoNCkZyb206IHpoYW5nLmZlaTNA enRlLmNvbS5jbiBbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbl0NClNlbnQ6IFdlZG5lc2Rh eSwgQXByaWwgMjAsIDIwMTEgMTA6MDggUE0NClRvOiBNYWNoIENoZW4NCkNjOiBjdXJ0aXNAb2Nj bmMuY29tOyBMdWNhIE1hcnRpbmk7IHB3ZTNAaWV0Zi5vcmc7IHB3ZTMtYm91bmNlc0BpZXRmLm9y ZzsgWWFha292IFN0ZWluDQpTdWJqZWN0OiC08Li0OiBSRTogW1BXRTNdIFBXRTMgd29ya2luZyBn cm91cCBwb2xsIGZvciBkcmFmdC1jYW8tcHdlMy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTAy LnR4dA0KDQoNCkhpIE1hY2gNCg0Kc2VlIGluIGxpbmUgW0ZlaV0NCg0KSWYgdGhlIG9yaWdpbmF0 aW5nIFBFIG9yIHRoZSBvcGVyYXRvciBoYXZlIHRoZSB0dW5uZWxzIGluZm9ybWF0aW9uLCBleHBs aWNpdGx5IHNwZWNpZnlpbmcgdGhlIFR1bm5lbCBMU1BzIGlzIGEgY2FuZGlkYXRlIHNvbHV0aW9u LCB0aGVyZSB3ZXJlIHNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbnMgYWJvdXQgdGhpcy4gRGVmaW5p bmcgYSBuZXcgVExWIG9yIHJldXNpbmcgdGhlIGV4aXN0aW5nIFRMViBpcyBlYXN5LCB0aGUgZGlm ZmljdWx0IGZvciB0aGlzIG1ldGhvZCBpcyB0aGF0IHRoZSBvcmlnaW5hdGluZyBQRSBpcyBoYXJk IG9yIGV2ZW4gaW1wb3NzaWJsZSB0byBrbm93IHRoZSBpbmZvcm1hdGlvbiBvZiB0aGUgbWlkZGxl IHR1bm5lbCBMU1BzLg0KDQpbRmVpXSBJIHRoaW5rIHlvdSBkaWQgbm90IGNhdGNoIG15IGlkZWEg Y2xlYXJseS4gdGhlIFJlY29yZCBSb3V0ZSBUTFYgaXMgdXNlZCB0byByZWNvcmQgdGhlIExTUCBJ RCBvciBpbnRlcmZhY2UgSUQgdGhhdCB0aGUgUFcgcGFzc2VzOyBsaWtlIHRoZSB1c2FnZSBvZiBS Uk8gb2JqZWN0IGluIFJTVlAtVEUuDQogICAgICBTbywgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhl IG9yaWdpbmF0aW5nIFBFIHRvIGtub3cgdGhlIGluZm9ybWF0aW9uIG9mIHRoZSBtaWRkbGUgdHVu bmVsIExTUHMgYXQgdGhlIHN0YXJ0aW5nIHRpbWUuDQpbTWFjaF0gWWVzLCB0aGVyZSBuZWVkIGEg bWVjaGFuaXNtIHRvIHJlY29yZCB0aGUgVHJhdmVyc2VkIFR1bm5lbCBMU1BzKGp1c3QgYXMgTHVj YSBzdWdnZXN0ZWQpLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQo= --Boundary_(ID_7HOnIWPrFKQ8iOsQwG5fog) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Fei,

 = ;

Thanks for= your response!

 = ;

From: zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
Sent: Wednesday, April 20, 2011 10:08 PM
To: Mach Chen
Cc: curtis@occnc.com; Luca Martini; pwe3@ietf.org; pwe3-bounces@ietf= .org; Yaakov Stein
Subject: =B4=F0=B8=B4= : RE: [PWE3] PWE3 working group poll for draft-c= ao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

 

=
Hi Mach

see in line [Fei]

If the originati= ng PE or the operator have the tunnels information, explicitly specifying t= he Tunnel LSPs is a candidate solution, there were some off-line discussion= s about this. Defining a new TLV or reusing the existing TLV is easy, the difficult for this method is that th= e originating PE is hard or even impossible to know the information of the = middle tunnel LSPs.

[Fei]= I think you did not catch my idea clearly. the Record Route TLV is used to= record the LSP ID or interface ID that the PW passes; like the usage of RR= O object in RSVP-TE.
 = ;     So, there is no need for the originating PE to know the inf= ormation of the middle tunnel LSPs at the starting time.

[Mach] Yes, there need a mechanism to record the Trave= rsed Tunnel LSPs(just as Luca suggested).

Best regards,

Mach

--Boundary_(ID_7HOnIWPrFKQ8iOsQwG5fog)-- From mach.chen@huawei.com Wed Apr 20 19:11:57 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 574F0E0803 for ; Wed, 20 Apr 2011 19:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.564 X-Spam-Level: X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UDl7fpcOiJu for ; Wed, 20 Apr 2011 19:11:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 83082E06DB for ; Wed, 20 Apr 2011 19:11:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJZ002R2CRUYP@szxga04-in.huawei.com> for pwe3@ietf.org; Thu, 21 Apr 2011 10:11:54 +0800 (CST) Received: from szxeml204-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJZ00FKFCRUU3@szxga04-in.huawei.com> for pwe3@ietf.org; Thu, 21 Apr 2011 10:11:54 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Apr 2011 10:11:44 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Thu, 21 Apr 2011 10:11:53 +0800 Date: Thu, 21 Apr 2011 02:10:52 +0000 From: Mach Chen In-reply-to: <4DAF0BDC.5050506@cisco.com> X-Originating-IP: [10.110.98.38] To: Luca Martini , "zhang.fei3@zte.com.cn" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Thread-index: AQHL/lHK73nHo264nEOurU5XIB5ZMZRl7lcAgACBeQCAASQS8A== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DAF0BDC.5050506@cisco.com> Cc: Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 02:11:57 -0000 Hi Luca, Fei, Thanks for the suggestions comments! > > [Fei]Yeah, it is a simpler solution, but if two or more LSPs are > > working LSPs under > > the same tunnel (for example, in the scenarios of ECMP), how to > > guarantee the same > > selection of the LSP ID? > > > I believe that the best way to solve this problem is to force a PW to > select a specific bi-directional LSP. > In the case of MS-PW this process needs to be repeated at each S-PE. > As Curtis suggested , we can add a "PSN Tunnel Profile TLV" to the LDP > signaling to indicate to each S-PE what kind of PSN tunnel is needed. > Then we would need a "PSN traversed tunnel list TLV" to make sure that > the reverse path ( for the PW) uses the exact same set of PSN tunnels. > What needs to be well thought out, is how to handle all the corner cases > when an initial failure occurs , and when something goes wrong in a > middle segment of a working MS-PW. It sounds reasonable! There are similar off-line discussions and ideas, we are working on a update to solve the issues in question. Best regards, Mach > > Luca > From mach.chen@huawei.com Wed Apr 20 19:19:20 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D33B6E0819; Wed, 20 Apr 2011 19:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.638 X-Spam-Level: X-Spam-Status: No, score=-5.638 tagged_above=-999 required=5 tests=[AWL=0.961, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUoQR+jC+YZ3; Wed, 20 Apr 2011 19:19:20 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id BB35DE080F; Wed, 20 Apr 2011 19:19:19 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJZ00J5ZD46V0@szxga04-in.huawei.com>; Thu, 21 Apr 2011 10:19:18 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJZ009G0D46FE@szxga04-in.huawei.com>; Thu, 21 Apr 2011 10:19:18 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Apr 2011 10:19:11 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 21 Apr 2011 10:19:18 +0800 Date: Thu, 21 Apr 2011 02:18:17 +0000 From: Mach Chen In-reply-to: <4DAF5BB3.9030607@cisco.com> X-Originating-IP: [10.110.98.38] To: Luca Martini Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] Whether T-LDP is part of the MPLS-TP control plane Thread-index: AQHL+xXOuBRay31Jh0yRN2bvU9H63ZRm1XWAgADHm5A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com> <4DAF5BB3.9030607@cisco.com> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 02:19:21 -0000 Hi Luca, > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Luca Martini > Sent: Thursday, April 21, 2011 6:18 AM > To: Mach Chen > Cc: pwe3@ietf.org; mpls@ietf.org > Subject: Re: [mpls] Whether T-LDP is part of the MPLS-TP control plane > > > On 04/14/2011 08:35 PM, Mach Chen wrote: > > Hi Luca, > > > > You said T-LDP is not part of the MPLS-TP control plane. > > > > IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is figure > about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP layer. > > > > In addition, in the abstract of MPLS-TP control plane > (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says: > > "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched > Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for > Pseudowires (PWs)..." > > > Mach, > The point is not about running LDP over an MPLS-TP LSP. Today you simply > cannot control or provision an MPLS-TP LSP using LDP. You can Provision > a PW using LDP, but not an MPLS-TP LSP. But noting that we are talking about whether LDP is "PART" of the MPLS-TP control plane :-) > > There are several ways to run LDP over an MPLS -TP LSP, as well, but I > cannot find an explicit indication of a standard way. > > In any case the problem you are proposing is not specific to MPLS-TP, so > solution must be general enough to apply to MPLS. Agree! Best regards, Mach > > Luca > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of > >> Luca Martini > >> Sent: Friday, April 15, 2011 2:11 AM > >> To: Greg Mirsky > >> Cc: pwe3@ietf.org > >> Subject: Re: [PWE3] PWE3 working group poll for > >> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > >> > >> On 04/14/11 00:09, Greg Mirsky wrote: > >>> Luca, > >>> you've asked > >>> How would LDP , which is IP based , even run on an MPLS-TP network ? > >>> but isn't T-LDP part of MPLS-TP control plane? Control plane assumes > >>> IP addressing thus use of T-LDP is plausible. > >>> > >> No T-LDP is not part of the MPLS-TP control plane. > >> It could be , but i think folks are more leaning toward GMPLS instead. > >> > >> Note that the problem described in this document exists for MPLS. So in > >> that case LDP is certainly used. But the document appears to only care > >> about MPLS-TP. > >> > >> Luca > >> > >> > >> > >>> Regards, > >>> Greg > >>> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From francesco.fondelli@gmail.com Thu Apr 21 02:32:51 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4A3E4E06B2 for ; Thu, 21 Apr 2011 02:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+JV7NOJEom6 for ; Thu, 21 Apr 2011 02:32:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 6BAD2E068A for ; Thu, 21 Apr 2011 02:32:50 -0700 (PDT) Received: by wwa36 with SMTP id 36so1260637wwa.13 for ; Thu, 21 Apr 2011 02:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UoT+j3ebEMx5W1yrzQJN63kqsKSk0xuKpZLfk7pr97k=; b=BCQkA49XvXokr03lE+mgwsCiRWNY+H1rnTcd8ED/jt0cW4/ppnZBMh3hgiwCa4w4en V/VqJik3e764eWsZtX96AqopQ70TOkXIyxUuTQw5sRZ9Hpjir7e2VchUnuKlfKTm5idW GIFqsluzNVgOrXsy2dLfZzZIOrc5ONemtFInE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iiVI+t8jzxSOUKKTns2oF4VAdiutFz006sMHzktZZI05oqNBOKx3/xuZ51+Sqda59+ KKz2BxIDT4rEwMuB7wEeVZcBaYEeRO6JVhB/3+1DOpE/fXG8LHPqHigqLFAldh336N4O 3vYvWaFNrVkw4Dptp3mtmpfTiaOsUf0LZQpLk= MIME-Version: 1.0 Received: by 10.216.145.200 with SMTP id p50mr1464913wej.79.1303378369285; Thu, 21 Apr 2011 02:32:49 -0700 (PDT) Received: by 10.216.175.68 with HTTP; Thu, 21 Apr 2011 02:32:49 -0700 (PDT) In-Reply-To: <4DAF7767.1040803@cisco.com> References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com> <4DAF7767.1040803@cisco.com> Date: Thu, 21 Apr 2011 11:32:49 +0200 Message-ID: From: Francesco Fondelli To: Luca Martini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 09:32:51 -0000 Hi, On Thu, Apr 21, 2011 at 2:16 AM, Luca Martini wrote: > On 04/15/2011 08:19 AM, Francesco Fondelli wrote: >> Hi, >> >> hemmm D'oh :-) >> >> =A0 =A0--- draft-ietf-ccamp-mpls-tp-cp-framework-06 --- >> >> =A0 =A0'Per the MPLS-TP framework [RFC5921], the MPLS-TP control plane i= s >> based on GMPLS with >> =A0 =A0 RSVP-TE for LSP signaling and targeted LDP for PW signaling' >> >> and "How would LDP , which is IP based , even run on an MPLS-TP network = ?" >> > >> just fine >> > really ? > what if there is no GMPLS control plane ? MPLS-TP ctrl plane :=3D GMPLS + RFC 4447, in case no GMPLS I guess no 4447 too. However I see no restrictions in running a mixed network: a) GMPLS and no PW signaling (manual PW conf), b) PW signaling and no GMPLS (manual LSP conf) [well 'manual' actually means NMS]. > There are several ways to run IP across a mpls-TP LSP , how are folks > going to pick the same method ? Implement everything that is in RFC 5718 and in ITU-T G.7712, or if you go for a subset make sure your customers are fine with that subset :-) > Since in LDP you must target an IP address , how do you know what IP > address to target to reach the end of an LSP ? or the opposite: given an > IP address which LSP gets you there ? A RSVP Notify message may be targeted too and reaches its destination even in a SONET/SDH network... and for sure there is no IP in the SONET/SDH data plane :-) In case control plane is present (with either one of the ingredients: GMPLS or LDP for PW) you MUST have IP! Perhaps some weird form of IP, tunneled/abused but... it's IP. On such a network, in case you need/want, you can establish a LDP targeted session between the tunnel head end and the tail end (automatically or manually). > Of course you can configure everything manually, but then what is the > value of running LDP ? agree, however once the session is up you get all PW LDP features > The one liner in that GMPLS RFC does not address these problems when we > have an MPLS-TP network. Partially agree. IMHO ramifications of the usage of LDP (targ session for PW signaling) within the context of a GMPLS controlled network (i.e. MPLS-TP) should be discussed somewhere (mpls-tp control plane draft?) in details. However what's in this email comes from the GMPLS framework. > Or Am I missing some other document ? I found http://tools.ietf.org/search/rfc4990 enlightening (think LDP for PW running in a "native control plane" as described in Section 7.1.1). > Luca thanks Ciao FF From lucy.yong@huawei.com Thu Apr 21 07:45:29 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92393E07B1 for ; Thu, 21 Apr 2011 07:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a0ipXUcuQ6z for ; Thu, 21 Apr 2011 07:45:28 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfc.amsl.com (Postfix) with ESMTP id BC983E07A4 for ; Thu, 21 Apr 2011 07:45:22 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LK000GMRBNLO4@usaga02-in.huawei.com> for pwe3@ietf.org; Thu, 21 Apr 2011 07:45:22 -0700 (PDT) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LK00035HBNL0E@usaga02-in.huawei.com> for pwe3@ietf.org; Thu, 21 Apr 2011 07:45:21 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Apr 2011 07:45:23 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.75]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 21 Apr 2011 07:45:03 -0700 Date: Thu, 21 Apr 2011 14:45:02 +0000 From: Lucy yong In-reply-to: <201104190539.p3J5dPoE020389@harbor.orleans.occnc.com> X-Originating-IP: [10.192.11.56] To: "curtis@occnc.com" , Jia He Message-id: <2691CE0099834E4A9C5044EEC662BB9D04965576@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [PWE3] GAL above and below the PW label Thread-index: AQHL/lQ9KQ4SDI72OEilxu7bTBACHJRoYiCA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: "Your message of Mon, 18 Apr 2011 15:28:18 +0800." <681080A6933146F2B1EA9033BB64B693@china.huawei.com> <201104190539.p3J5dPoE020389@harbor.orleans.occnc.com> Cc: Luca Martini , "pwe3@ietf.org" Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 14:45:29 -0000 Curtis. If GAL only applies to MPLS-TP LSP, this is not an issue because ECMP does not apply to such LSP. All PWs within such LSP will traverse through the same path. For MS-PW case, there are multi segment LSPs, each has its own session OAM. No problem is there too. If GAL also applies to LDP LSP, then I agree there is a problem. For example, for an entropy-label enabled LSP, we want to trace a flow within the LSP. But I don't know if GAL applies to such LSP since not following the MPLS-TP work. In our entropy label draft, we exclude MPLS-TP case. Regards, Lucy > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Tuesday, April 19, 2011 12:39 AM > To: Jia He > Cc: pwe3@ietf.org; Luca Martini > Subject: Re: [PWE3] GAL above and below the PW label > > > In message <681080A6933146F2B1EA9033BB64B693@china.huawei.com> > Jia He writes: > > > > Hi Cutis, > > > > > LSP label > > > GAL <- this is for LSP OAM > > > PW label > > > optional fat-pw label (S=1) > > > G-Ach > > > > If this is for LSP OAM, there is no PW label IMHO. > > > > B.R. > > Jia > > > If there is a multipath and you want the OAM to take the same path as > the payload then, yes there is a PW label. > > If that PW isn't working you don't want to be testing some other path. > > Curtis > > > > ----- Original Message ----- > > From: "Curtis Villamizar" > > To: "Luca Martini" > > Cc: > > Sent: Saturday, April 16, 2011 8:37 AM > > Subject: Re: [PWE3] GAL above and below the PW label > > > > > > > > > > In message <4DA71765.4060504@cisco.com> > > > Luca Martini writes: > > >> > > >> hello! > > >> > > >> It appears to me that it might not be clear that I also believe that > > >> the GAL should be at the bottom of the stack. I know that that is > not > > >> where we have it in the -00 version of the VCCV-2 draft , but that > was > > >> only an initial suggestion and we really wanted a good discussion on > > >> this list. > > >> > > >> We will update that document shortly. > > >> Thanks. > > >> Luca > > > > > > > > > Luca, > > > > > > Please specify below the PW label (below in the MPLS sense of bottom) > > > and not BOS. > > > > > > MPLS style stack orientation: > > > > > > LSP label > > > PW label > > > GAL <- this is for PW OAM > > > optional fat-pw label (S=1) > > > G-Ach > > > > > > LSP label > > > GAL <- this is for LSP OAM > > > PW label > > > optional fat-pw label (S=1) > > > G-Ach > > > > > > LSP label > > > PW label > > > optional fat-pw label (S=1) > > > payload > > > > > > Therefore there can consistently be a rule where GAL is under the > > > label for which the OAM is applied. > > > > > > If the hashing ignores reserved labels, then all three above take the > > > same path in the absence of fat-pw or take the same path given the > > > same value of the fat-pw label. > > > > > > Curtis > > > > > > > > >> On 04/13/11 23:41, Luca Martini wrote: > > >> > Curtis, > > >> > > > >> > If we keep the GAL at the bottom of the stack to flag the fact that > the > > >> > packet is GACH format , and not IP format, what is the problem ? > > >> > Surly FAT-PW would still work as most LSRs use the 2 bottom most > labels > > >> > to build a hash table. > > >> > > > >> > The gal = label 13 has a fixed binding to it. Do you propose that > we > > >> > change that ? or just the location of the label? > > >> > > > >> > Luca > > >> > > > >> > > > >> > > > >> > On 03/31/11 03:10, Curtis Villamizar wrote: > > >> >> In message > <60C093A41B5E45409A19D42CF7786DFD51D531132B@EUSAACMS0703.eamcs.ericsson.se > > > > >> >> David Allan I writes: > > >> >>> > > >> >>> HI Curtis: > > >> >>> > > >> >>> My suggestion is to avoid the GAL for PWs if it is to be a > > >> >>> homogenizing agent across TP and IP/MPLS domains in the form of > > >> >>> MS-PWs. The scenarios in which it was broken was simply a > statement of > > >> >>> fact. > > >> >>> > > >> >>> As for the problem GAL was proposed to fix (lack of CW), there > are > > >> >>> solutions on the table, just not palatable... > > >> >>> > > >> >>> D > > >> >> Dave, > > >> >> > > >> >> I think we are in agreement. > > >> >> > > >> >> We either use a non-GAL mechanism, or we fix GAL by removing the > > >> >> bottom of stack restriction and use GAL. > > >> >> > > >> >> I prefer the latter option, fix GAL. > > >> >> > > >> >> I support not using GAL at all in PW if GAL can't be fixed. > > >> >> > > >> >> Fixing GAL should really be an MPLS WG discussion. The result of > that > > >> >> discussion in MPLS should gate whether any PW proposal to use GAL > can > > >> >> be moved forward. > > >> >> > > >> >> Curtis > > >> >> > > >> >> > > >> >>> -----Original Message----- > > >> >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Curtis Villamizar > > >> >>> Sent: Thursday, March 31, 2011 9:03 AM > > >> >>> To: Loa Andersson > > >> >>> Cc: pwe3@ietf.org > > >> >>> Subject: Re: [PWE3] GAL above and below the PW label > > >> >>> > > >> >>> > > >> >>> Loa, Dave, Sasha, > > >> >>> > > >> >>> I've snipped from various posts on the thread that Sasha started. > See inline. > > >> >>> > > >> >>> In message <4D92F5D3.6080609@pi.nu> > > >> >>> Loa Andersson writes: > > >> >>>> > > >> >>>> All, > > >> >>>> > > >> >>>> missed a nuance in Sasha subject line. > > >> >>>> > > >> >>>> We have two issues > > >> >>>> > > >> >>>> - where the GAL is placed relative to the PW label, I believe > it is > > >> >>>> necessary to have the GAL below the PW label. > > >> >>>> > > >> >>>> - whether the the GAL label needs to be bottom of stack or not, > it > > >> >>>> figure that this is really a discussion if it is possible to > have > > >> >>>> a FAT label below the GAL or not. I'm not sure about my > preferences > > >> >>>> but I think it is possible. > > >> >>>> > > >> >>>> /Loa > > >> >>> > > >> >>> I agree with Loa's summary. Not putting GAL at the bottom may > confuse some LSR, but putting it above the PW label is likely to be even > more problematic. > > >> >>> > > >> >>> > > >> >>> In message > <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericsson.se > > > > >> >>> David Allan I writes: > > >> >>>> > > >> >>>> It does become a new behavior, GAL with S=3D0. However the > combination > > >> >>>> of G= AL being top label at the S-PE and TTL being encoded in > the PW > > >> >>>> label means = that fate sharing is broken at every S-PE. Life > only > > >> >>>> gets a little more str= ange if there is a FAT label as well... > > >> >>>> > > >> >>>> That being said, GAL as bottom label is broken in any ECMP > > >> >>>> environment, whi= ch is why GAL is a TP construct. > > >> >>>> > > >> >>>> my 2 cents > > >> >>>> D > > >> >>> > > >> >>> Dave, > > >> >>> > > >> >>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. > > >> >>> If all it takes to fix it is simple then lets just fix it. > > >> >>> > > >> >>> This is what we'd have to do. > > >> >>> > > >> >>> 1) Relax the requirement that GAL be at the bottom > > >> >>> > > >> >>> 2) Have the ingress insert GAL in the stack immediately below > the > > >> >>> label for which the measurement is made, keeping the rest of > the > > >> >>> label stack in place. > > >> >>> > > >> >>> The only thing the midpoing LSR at a multipath (LAG, link bundle > for > > >> >>> MPLS) has to do is skip over the GAL when hashing, as if the GAL > wasn't there. That will yield the same hash value and it will preserve > fate-sharing across multipath. > > >> >>> > > >> >>> I prefer that we fix things rather than complain that they are > broken. > > >> >>> > > >> >>> Curtis > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From Internet-Drafts@ietf.org Thu Apr 21 10:15:03 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1ACADE065F; Thu, 21 Apr 2011 10:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeL0CIRB6Eqg; Thu, 21 Apr 2011 10:15:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B42F7E07A9; Thu, 21 Apr 2011 10:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110421171501.2231.37175.idtracker@ietfc.amsl.com> Date: Thu, 21 Apr 2011 10:15:01 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-oam-msg-map-16.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 17:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Pseudowire (PW) OAM Message Mapping Author(s) : M. Aissaoui, et al. Filename : draft-ietf-pwe3-oam-msg-map-16.txt Pages : 40 Date : 2011-04-21 This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects. It addresses ATM, frame relay, TDM, and SONET/SDH PW services, carried over MPLS, MPLS/IP and L2TPv3/IP Packet Switched Networks (PSNs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pwe3-oam-msg-map-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-21101340.I-D@ietf.org> --NextPart-- From cpignata@cisco.com Thu Apr 21 21:48:52 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 80CE8E0761 for ; Thu, 21 Apr 2011 21:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bczqyhCo74fN for ; Thu, 21 Apr 2011 21:48:51 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfc.amsl.com (Postfix) with ESMTP id 9E133E064E for ; Thu, 21 Apr 2011 21:48:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3M4mm3a027818; Fri, 22 Apr 2011 00:48:48 -0400 (EDT) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3M4mkWD009196; Fri, 22 Apr 2011 00:48:46 -0400 (EDT) Message-ID: <4DB108AD.2040809@cisco.com> Date: Fri, 22 Apr 2011 00:48:45 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Sriganesh Kini References: <4D92F5D3.6080609@pi.nu> <201103310703.p2V73Hrx045107@harbor.orleans.occnc.com> In-Reply-To: X-Enigmail-Version: 1.1.1 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 04:48:52 -0000 Hi Sriganesh, Do you see the applicability of draft-kini-pwe3-inband-cc-offset strictly limited to the encapsulation proposed in draft-kini-pwe3-pkt-encap-efficient-ip-mpls? Specifically, for a PW that carries say Ethernet without CW (or any of the other encap modes with non-mandatory CW), there is no "flow" that is being ECMP-ed in the core that you want to mimic/imitate in a load-balancing pseudo-header. Conversely, for "IP PWs", LSP-Ping can take different Equal-cost paths (all of them, one by one) based on choosing the destination IP address. And there is no need for this when there is a CW. I am trying to understand how common is the use case for what this optimizes for. Thanks, -- Carlos. On 3/31/2011 4:08 AM, Sriganesh Kini wrote: > All, > > Just an FYI that a proposal for fate-sharing PW OAM and data given in > draft-kini-pwe3-inband-cc-offset > > Just to summarize the proposal. > 1. It does not require GAL in PW. TTL expiry is used to alert the S/T-PE. > 2. It is mainly applicable when CW is not used in the PW. > 3. It uses a fixed offset (negotiated between PW endpoints) after the > label stack before starting the OAM msg. > 4. The bytes between the label-stack and the fixed offset is referred > to as a pseudoflow header and is filled with byte-values (by the PE) > that represent the flow for which OAM is desired. This helps PW OAM > and data to fate-share even when the intermediate node looks beyond > label stack to do multipath forwarding decisions. > > > On Thu, Mar 31, 2011 at 12:03 AM, Curtis Villamizar wrote: >> >> Loa, Dave, Sasha, >> >> I've snipped from various posts on the thread that Sasha started. See >> inline. >> >> In message <4D92F5D3.6080609@pi.nu> >> Loa Andersson writes: >>> >>> All, >>> >>> missed a nuance in Sasha subject line. >>> >>> We have two issues >>> >>> - where the GAL is placed relative to the PW label, I believe it is >>> necessary to have the GAL below the PW label. >>> >>> - whether the the GAL label needs to be bottom of stack or not, it >>> figure that this is really a discussion if it is possible to have >>> a FAT label below the GAL or not. I'm not sure about my preferences >>> but I think it is possible. >>> >>> /Loa >> >> I agree with Loa's summary. Not putting GAL at the bottom may confuse >> some LSR, but putting it above the PW label is likely to be even more >> problematic. >> >> >> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericsson.se> >> David Allan I writes: >>> >>> It does become a new behavior, GAL with S=3D0. However the combination of G= >>> AL being top label at the S-PE and TTL being encoded in the PW label means = >>> that fate sharing is broken at every S-PE. Life only gets a little more str= >>> ange if there is a FAT label as well... >>> >>> That being said, GAL as bottom label is broken in any ECMP environment, whi= >>> ch is why GAL is a TP construct. >>> >>> my 2 cents >>> D >> >> Dave, >> >> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >> If all it takes to fix it is simple then lets just fix it. >> >> This is what we'd have to do. >> >> 1) Relax the requirement that GAL be at the bottom >> >> 2) Have the ingress insert GAL in the stack immediately below the >> label for which the measurement is made, keeping the rest of the >> label stack in place. >> >> The only thing the midpoing LSR at a multipath (LAG, link bundle for >> MPLS) has to do is skip over the GAL when hashing, as if the GAL >> wasn't there. That will yield the same hash value and it will >> preserve fate-sharing across multipath. >> >> I prefer that we fix things rather than complain that they are broken. >> >> Curtis >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > > From sriganeshkini@gmail.com Fri Apr 22 11:20:00 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0F52CE082A for ; Fri, 22 Apr 2011 11:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrBIQkkLiRdA for ; Fri, 22 Apr 2011 11:19:59 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfc.amsl.com (Postfix) with ESMTP id D33ABE0822 for ; Fri, 22 Apr 2011 11:19:58 -0700 (PDT) Received: by qyk29 with SMTP id 29so471668qyk.10 for ; Fri, 22 Apr 2011 11:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=oTpk0l2JQqN5tZu3qG/qgQHhR6i7AxOZNS4hMDBiz4o=; b=Wo6cwSlxxHu9gJIevQxE8bAwdXWzJeovrHNuUQSkARHL35PKBshLd+koOtOhhGN6TE WNdmNM8xIrH3FNwjs0hdDjypq/vDox92eLea7KPuCC88H8FNeqlBhyxsIabhasfmCq4C R7yIvcxHBaKnjZUDF3ka7PQ6YFMTCMt9KSTmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=PZeZRa0EvJREqROA2TmAo5Y4n6GXI+BVgj7UzaZY1xypyj5SYgrHKdkIxbfpUh5Tu+ qoYUr8SVmKg3pILA9+jVTEg+V5yR3dVejXFn9wVXtTPRBjs96MYmnxhlrEgJzjQTTQMP JeC6hZEpazalDHXghoLVq/Sxu97WL1hlPi8zg= Received: by 10.229.130.141 with SMTP id t13mr1018983qcs.117.1303496398174; Fri, 22 Apr 2011 11:19:58 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.94.143 with HTTP; Fri, 22 Apr 2011 11:19:28 -0700 (PDT) In-Reply-To: <4DB108AD.2040809@cisco.com> References: <4D92F5D3.6080609@pi.nu> <201103310703.p2V73Hrx045107@harbor.orleans.occnc.com> <4DB108AD.2040809@cisco.com> From: Sriganesh Kini Date: Fri, 22 Apr 2011 11:19:28 -0700 X-Google-Sender-Auth: pblruuEBYYJEH6VD36xQT3Fxz40 Message-ID: To: Carlos Pignataro Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 18:20:00 -0000 Hi Carlos, The applicability of draft-kini-pwe3-inband-cc-offset is when CW is not present, but the intermediate LSR looks beyond the PW label to do multipath decisions. The draft is independent of any (even proprietary logic) for multipath decision taken by intermediate nodes looking beyond PW label and also independent of any heuristic the intermediate routers may use to guess the packet type (beyond label stack) being carried. The most common heuristic is of course looking at the first nibble beyond label stack to determine that it is an IP packet. So this would also apply for an IP PW, IPLS, etc in addition to draft-kini-pwe3-pkt-encap-efficient-ip-mpls. LSP-Ping uses the 127 address and it is not easy to co-relate this to a problem reported for real (non 127) addresses. Thanks On Thu, Apr 21, 2011 at 9:48 PM, Carlos Pignataro wrot= e: > Hi Sriganesh, > > Do you see the applicability of draft-kini-pwe3-inband-cc-offset > strictly limited to the encapsulation proposed in > draft-kini-pwe3-pkt-encap-efficient-ip-mpls? > > Specifically, for a PW that carries say Ethernet without CW (or any of > the other encap modes with non-mandatory CW), there is no "flow" that is > being ECMP-ed in the core that you want to mimic/imitate in a > load-balancing pseudo-header. Conversely, for "IP PWs", LSP-Ping can > take different Equal-cost paths (all of them, one by one) based on > choosing the destination IP address. And there is no need for this when > there is a CW. > > I am trying to understand how common is the use case for what this > optimizes for. > > Thanks, > > -- Carlos. > > On 3/31/2011 4:08 AM, Sriganesh Kini wrote: >> All, >> >> Just an FYI that a proposal for fate-sharing PW OAM and data given in >> draft-kini-pwe3-inband-cc-offset >> >> Just to summarize the proposal. >> 1. It does not require GAL in PW. TTL expiry is used to alert the S/T-PE= . >> 2. It is mainly applicable when CW is not used in the PW. >> 3. It uses a fixed offset (negotiated between PW endpoints) after the >> label stack before starting the OAM msg. >> 4. The bytes between the label-stack and the fixed offset is referred >> to as a pseudoflow header and is filled with byte-values (by the PE) >> that represent the flow for which OAM is desired. This helps PW OAM >> and data to fate-share even when the intermediate node looks beyond >> label stack to do multipath forwarding decisions. >> >> >> On Thu, Mar 31, 2011 at 12:03 AM, Curtis Villamizar w= rote: >>> >>> Loa, Dave, Sasha, >>> >>> I've snipped from various posts on the thread that Sasha started. =A0Se= e >>> inline. >>> >>> In message <4D92F5D3.6080609@pi.nu> >>> Loa Andersson writes: >>>> >>>> All, >>>> >>>> missed a nuance in Sasha subject line. >>>> >>>> We have two issues >>>> >>>> - where the GAL is placed relative to the PW label, I =A0believe it is >>>> =A0 =A0necessary to have the GAL below the PW label. >>>> >>>> - whether the the GAL label needs to be bottom of stack or not, it >>>> =A0 =A0figure that this is really a discussion if it is possible to ha= ve >>>> =A0 =A0a FAT label below the GAL or not. I'm not sure =A0about my pref= erences >>>> =A0 =A0but I think it is possible. >>>> >>>> /Loa >>> >>> I agree with Loa's summary. =A0Not putting GAL at the bottom may confus= e >>> some LSR, but putting it above the PW label is likely to be even more >>> problematic. >>> >>> >>> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eam= cs.ericsson.se> >>> David Allan I writes: >>>> >>>> It does become a new behavior, GAL with S=3D3D0. However the combinati= on of G=3D >>>> AL being top label at the S-PE and TTL being encoded in the PW label m= eans =3D >>>> that fate sharing is broken at every S-PE. Life only gets a little mor= e str=3D >>>> ange if there is a FAT label as well... >>>> >>>> That being said, GAL as bottom label is broken in any ECMP environment= , whi=3D >>>> ch is why GAL is a TP construct. >>>> >>>> my 2 cents >>>> D >>> >>> Dave, >>> >>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >>> If all it takes to fix it is simple then lets just fix it. >>> >>> This is what we'd have to do. >>> >>> =A01) Relax the requirement that GAL be at the bottom >>> >>> =A02) Have the ingress insert GAL in the stack immediately below the >>> =A0 =A0 label for which the measurement is made, keeping the rest of th= e >>> =A0 =A0 label stack in place. >>> >>> The only thing the midpoing LSR at a multipath (LAG, link bundle for >>> MPLS) has to do is skip over the GAL when hashing, as if the GAL >>> wasn't there. =A0That will yield the same hash value and it will >>> preserve fate-sharing across multipath. >>> >>> I prefer that we fix things rather than complain that they are broken. >>> >>> Curtis >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >> >> >> > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --=20 - Sri From cpignata@cisco.com Fri Apr 22 18:23:20 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E8FBE06C0 for ; Fri, 22 Apr 2011 18:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.967 X-Spam-Level: X-Spam-Status: No, score=-107.967 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnOWsRGcFV-8 for ; Fri, 22 Apr 2011 18:23:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 19FC0E06A0 for ; Fri, 22 Apr 2011 18:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=8856; q=dns/txt; s=iport; t=1303521799; x=1304731399; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=MP6IGJS4UQjCY+f/wiaGwWW3ioS6VZPUC0hXwEQO7gQ=; b=ktMO1XBnQhVMYfGpU0g2esH0/d4NVOFN2c99trOcUWc1cPy/LLE5RodL MGKV82eIpjCrS+H2WKbLce0rtPNcKXaZ0xHSw1LrMu5idf3UJa8EW7kpK qL9zSn06pc+tbgCI+tC7alCXjSffIMPCJ4OOkq8rGhyI/HulHGxoT2F5U I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQHAM0psk2tJXG9/2dsb2JhbACET6APgQgCd4hwn16LYJBsgSmBVoF6fQSONYQO X-IronPort-AV: E=Sophos;i="4.64,256,1301875200"; d="scan'208";a="435150448" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2011 01:23:06 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3N1N5Hc015379; Sat, 23 Apr 2011 01:23:05 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 20:23:05 -0500 Received: from 72.163.62.136 ([72.163.62.136]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Sat, 23 Apr 2011 01:23:05 +0000 References: <4D92F5D3.6080609@pi.nu> <201103310703.p2V73Hrx045107@harbor.orleans.occnc.com> <4DB108AD.2040809@cisco.com> Content-Transfer-Encoding: base64 From: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset="utf-8" In-Reply-To: Message-ID: <164FBBE6-5814-4C12-8CC1-C1A4D22D7BE6@cisco.com> Date: Fri, 22 Apr 2011 21:23:26 -0400 Thread-Topic: [PWE3] GAL above and below the PW label Thread-Index: AcwBVP7zhMi7QhXCSY29aH4VhUfqcw== To: "Sriganesh Kini" MIME-Version: 1.0 (iPad Mail 8H7) X-OriginalArrivalTime: 23 Apr 2011 01:23:05.0636 (UTC) FILETIME=[FF246E40:01CC0154] Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 01:23:20 -0000 SGkgU3JpZ2FuZXNoLA0KDQpUaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZSBhbmQgbG93IFJU VCwgcGxlYXNlIGZpbmQgc29tZSBmb2xsb3ctdXBzIGlubGluZS4NCg0KQ2FybG9zIFAuDQoNCk9u IEFwciAyMiwgMjAxMSwgYXQgMjoyMCBQTSwgIlNyaWdhbmVzaCBLaW5pIiA8c3JpZ2FuZXNoLmtp bmlAZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPiBIaSBDYXJsb3MsDQo+IA0KPiBUaGUgYXBwbGlj YWJpbGl0eSBvZiBkcmFmdC1raW5pLXB3ZTMtaW5iYW5kLWNjLW9mZnNldCBpcyB3aGVuIENXIGlz DQo+IG5vdCBwcmVzZW50LCBidXQgdGhlIGludGVybWVkaWF0ZSBMU1IgbG9va3MgYmV5b25kIHRo ZSBQVyBsYWJlbCB0byBkbw0KPiBtdWx0aXBhdGggZGVjaXNpb25zLiBUaGUgZHJhZnQgaXMgaW5k ZXBlbmRlbnQgb2YgYW55IChldmVuIHByb3ByaWV0YXJ5DQo+IGxvZ2ljKSBmb3IgbXVsdGlwYXRo IGRlY2lzaW9uIHRha2VuIGJ5IGludGVybWVkaWF0ZSBub2RlcyBsb29raW5nDQo+IGJleW9uZCBQ VyBsYWJlbCBhbmQgYWxzbyBpbmRlcGVuZGVudCBvZiBhbnkgaGV1cmlzdGljIHRoZSBpbnRlcm1l ZGlhdGUNCj4gcm91dGVycyBtYXkgdXNlIHRvIGd1ZXNzIHRoZSBwYWNrZXQgdHlwZSAoYmV5b25k IGxhYmVsIHN0YWNrKSBiZWluZw0KPiBjYXJyaWVkLg0KDQpJIHRoaW5rIHRoYXQgdGhpcyBzdGF0 ZW1lbnQgaXMgYSBiaXQgdG9vIG9wdGltaXN0aWMgYW5kIHRvbyBnZW5lcmFsaXplZC4gSXQgc2Vl bXMgdG8gbWUgdGhhdCwgaW4gYWRkaXRpb24sIHRoZSBQRSBuZWVkcyB0byB1bmRlcnN0YW5kIHRo ZSBmbG93cyBjYXJyaWVkIGluc2lkZSB0aGUgUFcsIGhhdmUgc29tZSBjbHVlIGFzIHRvIHRoZSB0 eXBlIG9mIEVDTVAgaW4gdGhlIGNvcmUsIGFuZCB0aGVyZSBzaG91bGQgaGF2ZSBjb3JyZWxhdGlv biBiZXR3ZWVuIHRoZXNlIHR3by4gVGhpcyBkcmFtYXRpY2FsbHkgbGltaXRlZCB0aGUgYXBwbGlj YWJpbGl0eSBhcyB5b3Ugc2F5IGJlbG93Og0KDQo+IFRoZSBtb3N0IGNvbW1vbiBoZXVyaXN0aWMg aXMgb2YgY291cnNlIGxvb2tpbmcgYXQgdGhlIGZpcnN0DQo+IG5pYmJsZSBiZXlvbmQgbGFiZWwg c3RhY2sgdG8gZGV0ZXJtaW5lIHRoYXQgaXQgaXMgYW4gSVAgcGFja2V0LiBTbw0KPiB0aGlzIHdv dWxkIGFsc28gYXBwbHkgZm9yIGFuIElQIFBXLCBJUExTLCBldGMgaW4gYWRkaXRpb24gdG8NCj4g ZHJhZnQta2luaS1wd2UzLXBrdC1lbmNhcC1lZmZpY2llbnQtaXAtbXBscy4NCg0KUmlnaHQuIEkg dGhpbmsgaXQgd291bGQgYXBwbHkgdG8gYW4gSVAgUFcsIHdoZXJlIHRoZXJlIGFyZSBleGlzdGlu ZyB0ZWNobmlxdWVzIHRvIHdhbGsgbXVsdGlwYXRocy4gQnV0IGl0IHdvdWxkIG5vdCB0byBzYXkg YW4gRXRoZXJuZXQgUFcgKHdpdGhvdXQgQ1cpOiBldmVuIGlmIHRoZSBQRSBzZWVzIHRoZSBmbG93 cyBpbnNpZGUgdGhlIEV0aGVybmV0IChlLmcuLCBUQ1AgZmxvd3Mgb3ZlciBJUCBvdmVyIEV0aGVy bmV0KSwgdGhlIGlzIG5vIEVDTVAgaW4gdGhlIGNvcmUgYmFzZWQgb24gdGhvc2UuIA0KDQo+IExT UC1QaW5nIHVzZXMgdGhlIDEyNw0KPiBhZGRyZXNzIGFuZCBpdCBpcyBub3QgZWFzeSB0byBjby1y ZWxhdGUgdGhpcyB0byBhIHByb2JsZW0gcmVwb3J0ZWQgZm9yDQo+IHJlYWwgKG5vbiAxMjcpIGFk ZHJlc3Nlcy4NCg0KSSB0aGluayBMU1AtUGluZyBjYW4gZG8gYmV0dGVyOiBpZGVudGlmeSBhbmQg d2FsayBhbGwgRUNNUHMuIA0KSSBhbHNvIHRoaW5rIHRoYXQgdGhlIGFzc3VtcHRpb24gb2YgYSBw cm9ibGVtIGJlaW5nIHJlcG9ydGVkIG9uIGEgZ2l2ZW4gZmxvdywgb25seSBmb3IgYW4gSVAgUFcg VHlwZSBpcyB0b28gZXhwZW5zaXZlIGZvciB0aGUgcmV0dXJuLiANCg0KVGhhbmtzLA0KDQotLSBD YXJsb3MuIA0KDQo+IA0KPiBUaGFua3MNCj4gDQo+IA0KPiBPbiBUaHUsIEFwciAyMSwgMjAxMSBh dCA5OjQ4IFBNLCBDYXJsb3MgUGlnbmF0YXJvIDxjcGlnbmF0YUBjaXNjby5jb20+IHdyb3RlOg0K Pj4gSGkgU3JpZ2FuZXNoLA0KPj4gDQo+PiBEbyB5b3Ugc2VlIHRoZSBhcHBsaWNhYmlsaXR5IG9m IGRyYWZ0LWtpbmktcHdlMy1pbmJhbmQtY2Mtb2Zmc2V0DQo+PiBzdHJpY3RseSBsaW1pdGVkIHRv IHRoZSBlbmNhcHN1bGF0aW9uIHByb3Bvc2VkIGluDQo+PiBkcmFmdC1raW5pLXB3ZTMtcGt0LWVu Y2FwLWVmZmljaWVudC1pcC1tcGxzPw0KPj4gDQo+PiBTcGVjaWZpY2FsbHksIGZvciBhIFBXIHRo YXQgY2FycmllcyBzYXkgRXRoZXJuZXQgd2l0aG91dCBDVyAob3IgYW55IG9mDQo+PiB0aGUgb3Ro ZXIgZW5jYXAgbW9kZXMgd2l0aCBub24tbWFuZGF0b3J5IENXKSwgdGhlcmUgaXMgbm8gImZsb3ci IHRoYXQgaXMNCj4+IGJlaW5nIEVDTVAtZWQgaW4gdGhlIGNvcmUgdGhhdCB5b3Ugd2FudCB0byBt aW1pYy9pbWl0YXRlIGluIGENCj4+IGxvYWQtYmFsYW5jaW5nIHBzZXVkby1oZWFkZXIuIENvbnZl cnNlbHksIGZvciAiSVAgUFdzIiwgTFNQLVBpbmcgY2FuDQo+PiB0YWtlIGRpZmZlcmVudCBFcXVh bC1jb3N0IHBhdGhzIChhbGwgb2YgdGhlbSwgb25lIGJ5IG9uZSkgYmFzZWQgb24NCj4+IGNob29z aW5nIHRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzLiBBbmQgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig dGhpcyB3aGVuDQo+PiB0aGVyZSBpcyBhIENXLg0KPj4gDQo+PiBJIGFtIHRyeWluZyB0byB1bmRl cnN0YW5kIGhvdyBjb21tb24gaXMgdGhlIHVzZSBjYXNlIGZvciB3aGF0IHRoaXMNCj4+IG9wdGlt aXplcyBmb3IuDQo+PiANCj4+IFRoYW5rcywNCj4+IA0KPj4gLS0gQ2FybG9zLg0KPj4gDQo+PiBP biAzLzMxLzIwMTEgNDowOCBBTSwgU3JpZ2FuZXNoIEtpbmkgd3JvdGU6DQo+Pj4gQWxsLA0KPj4+ IA0KPj4+IEp1c3QgYW4gRllJIHRoYXQgYSBwcm9wb3NhbCBmb3IgZmF0ZS1zaGFyaW5nIFBXIE9B TSBhbmQgZGF0YSBnaXZlbiBpbg0KPj4+IGRyYWZ0LWtpbmktcHdlMy1pbmJhbmQtY2Mtb2Zmc2V0 DQo+Pj4gDQo+Pj4gSnVzdCB0byBzdW1tYXJpemUgdGhlIHByb3Bvc2FsLg0KPj4+IDEuIEl0IGRv ZXMgbm90IHJlcXVpcmUgR0FMIGluIFBXLiBUVEwgZXhwaXJ5IGlzIHVzZWQgdG8gYWxlcnQgdGhl IFMvVC1QRS4NCj4+PiAyLiBJdCBpcyBtYWlubHkgYXBwbGljYWJsZSB3aGVuIENXIGlzIG5vdCB1 c2VkIGluIHRoZSBQVy4NCj4+PiAzLiBJdCB1c2VzIGEgZml4ZWQgb2Zmc2V0IChuZWdvdGlhdGVk IGJldHdlZW4gUFcgZW5kcG9pbnRzKSBhZnRlciB0aGUNCj4+PiBsYWJlbCBzdGFjayBiZWZvcmUg c3RhcnRpbmcgdGhlIE9BTSBtc2cuDQo+Pj4gNC4gVGhlIGJ5dGVzIGJldHdlZW4gdGhlIGxhYmVs LXN0YWNrIGFuZCB0aGUgZml4ZWQgb2Zmc2V0IGlzIHJlZmVycmVkDQo+Pj4gdG8gYXMgYSBwc2V1 ZG9mbG93IGhlYWRlciBhbmQgaXMgZmlsbGVkIHdpdGggYnl0ZS12YWx1ZXMgKGJ5IHRoZSBQRSkN Cj4+PiB0aGF0IHJlcHJlc2VudCB0aGUgZmxvdyBmb3Igd2hpY2ggT0FNIGlzIGRlc2lyZWQuIFRo aXMgaGVscHMgUFcgT0FNDQo+Pj4gYW5kIGRhdGEgdG8gZmF0ZS1zaGFyZSBldmVuIHdoZW4gdGhl IGludGVybWVkaWF0ZSBub2RlIGxvb2tzIGJleW9uZA0KPj4+IGxhYmVsIHN0YWNrIHRvIGRvIG11 bHRpcGF0aCBmb3J3YXJkaW5nIGRlY2lzaW9ucy4NCj4+PiANCj4+PiANCj4+PiBPbiBUaHUsIE1h ciAzMSwgMjAxMSBhdCAxMjowMyBBTSwgQ3VydGlzIFZpbGxhbWl6YXIgPGN1cnRpc0BvY2NuYy5j b20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gTG9hLCBEYXZlLCBTYXNoYSwNCj4+Pj4gDQo+Pj4+IEkn dmUgc25pcHBlZCBmcm9tIHZhcmlvdXMgcG9zdHMgb24gdGhlIHRocmVhZCB0aGF0IFNhc2hhIHN0 YXJ0ZWQuIMOCIFNlZQ0KPj4+PiBpbmxpbmUuDQo+Pj4+IA0KPj4+PiBJbiBtZXNzYWdlIDw0RDky RjVEMy42MDgwNjA5QHBpLm51Pg0KPj4+PiBMb2EgQW5kZXJzc29uIHdyaXRlczoNCj4+Pj4+IA0K Pj4+Pj4gQWxsLA0KPj4+Pj4gDQo+Pj4+PiBtaXNzZWQgYSBudWFuY2UgaW4gU2FzaGEgc3ViamVj dCBsaW5lLg0KPj4+Pj4gDQo+Pj4+PiBXZSBoYXZlIHR3byBpc3N1ZXMNCj4+Pj4+IA0KPj4+Pj4g LSB3aGVyZSB0aGUgR0FMIGlzIHBsYWNlZCByZWxhdGl2ZSB0byB0aGUgUFcgbGFiZWwsIEkgw4Ig YmVsaWV2ZSBpdCBpcw0KPj4+Pj4gw4IgIMOCIG5lY2Vzc2FyeSB0byBoYXZlIHRoZSBHQUwgYmVs b3cgdGhlIFBXIGxhYmVsLg0KPj4+Pj4gDQo+Pj4+PiAtIHdoZXRoZXIgdGhlIHRoZSBHQUwgbGFi ZWwgbmVlZHMgdG8gYmUgYm90dG9tIG9mIHN0YWNrIG9yIG5vdCwgaXQNCj4+Pj4+IMOCICDDgiBm aWd1cmUgdGhhdCB0aGlzIGlzIHJlYWxseSBhIGRpc2N1c3Npb24gaWYgaXQgaXMgcG9zc2libGUg dG8gaGF2ZQ0KPj4+Pj4gw4IgIMOCIGEgRkFUIGxhYmVsIGJlbG93IHRoZSBHQUwgb3Igbm90LiBJ J20gbm90IHN1cmUgw4IgYWJvdXQgbXkgcHJlZmVyZW5jZXMNCj4+Pj4+IMOCICDDgiBidXQgSSB0 aGluayBpdCBpcyBwb3NzaWJsZS4NCj4+Pj4+IA0KPj4+Pj4gL0xvYQ0KPj4+PiANCj4+Pj4gSSBh Z3JlZSB3aXRoIExvYSdzIHN1bW1hcnkuIMOCIE5vdCBwdXR0aW5nIEdBTCBhdCB0aGUgYm90dG9t IG1heSBjb25mdXNlDQo+Pj4+IHNvbWUgTFNSLCBidXQgcHV0dGluZyBpdCBhYm92ZSB0aGUgUFcg bGFiZWwgaXMgbGlrZWx5IHRvIGJlIGV2ZW4gbW9yZQ0KPj4+PiBwcm9ibGVtYXRpYy4NCj4+Pj4g DQo+Pj4+IA0KPj4+PiBJbiBtZXNzYWdlIDw2MEMwOTNBNDFCNUU0NTQwOUExOUQ0MkNGNzc4NkRG RDUxRDUzMTBCNTNARVVTQUFDTVMwNzAzLmVhbWNzLmVyaWNzc29uLnNlPg0KPj4+PiBEYXZpZCBB bGxhbiBJIHdyaXRlczoNCj4+Pj4+IA0KPj4+Pj4gSXQgZG9lcyBiZWNvbWUgYSBuZXcgYmVoYXZp b3IsIEdBTCB3aXRoIFM9M0QwLiBIb3dldmVyIHRoZSBjb21iaW5hdGlvbiBvZiBHPQ0KPj4+Pj4g QUwgYmVpbmcgdG9wIGxhYmVsIGF0IHRoZSBTLVBFIGFuZCBUVEwgYmVpbmcgZW5jb2RlZCBpbiB0 aGUgUFcgbGFiZWwgbWVhbnMgPQ0KPj4+Pj4gdGhhdCBmYXRlIHNoYXJpbmcgaXMgYnJva2VuIGF0 IGV2ZXJ5IFMtUEUuIExpZmUgb25seSBnZXRzIGEgbGl0dGxlIG1vcmUgc3RyPQ0KPj4+Pj4gYW5n ZSBpZiB0aGVyZSBpcyBhIEZBVCBsYWJlbCBhcyB3ZWxsLi4uDQo+Pj4+PiANCj4+Pj4+IFRoYXQg YmVpbmcgc2FpZCwgR0FMIGFzIGJvdHRvbSBsYWJlbCBpcyBicm9rZW4gaW4gYW55IEVDTVAgZW52 aXJvbm1lbnQsIHdoaT0NCj4+Pj4+IGNoIGlzIHdoeSBHQUwgaXMgYSBUUCBjb25zdHJ1Y3QuDQo+ Pj4+PiANCj4+Pj4+IG15IDIgY2VudHMNCj4+Pj4+IEQNCj4+Pj4gDQo+Pj4+IERhdmUsDQo+Pj4+ IA0KPj4+PiBJZiBHQUwgaXMgYnJva2VuIGZvciBFQ01QLCB3aGljaCBpdCBpcywgdGhlbiBhbGwg VFAgT0FNIGlzIGJyb2tlbi4NCj4+Pj4gSWYgYWxsIGl0IHRha2VzIHRvIGZpeCBpdCBpcyBzaW1w bGUgdGhlbiBsZXRzIGp1c3QgZml4IGl0Lg0KPj4+PiANCj4+Pj4gVGhpcyBpcyB3aGF0IHdlJ2Qg aGF2ZSB0byBkby4NCj4+Pj4gDQo+Pj4+IMOCIDEpIFJlbGF4IHRoZSByZXF1aXJlbWVudCB0aGF0 IEdBTCBiZSBhdCB0aGUgYm90dG9tDQo+Pj4+IA0KPj4+PiDDgiAyKSBIYXZlIHRoZSBpbmdyZXNz IGluc2VydCBHQUwgaW4gdGhlIHN0YWNrIGltbWVkaWF0ZWx5IGJlbG93IHRoZQ0KPj4+PiDDgiAg w4IgIGxhYmVsIGZvciB3aGljaCB0aGUgbWVhc3VyZW1lbnQgaXMgbWFkZSwga2VlcGluZyB0aGUg cmVzdCBvZiB0aGUNCj4+Pj4gw4IgIMOCICBsYWJlbCBzdGFjayBpbiBwbGFjZS4NCj4+Pj4gDQo+ Pj4+IFRoZSBvbmx5IHRoaW5nIHRoZSBtaWRwb2luZyBMU1IgYXQgYSBtdWx0aXBhdGggKExBRywg bGluayBidW5kbGUgZm9yDQo+Pj4+IE1QTFMpIGhhcyB0byBkbyBpcyBza2lwIG92ZXIgdGhlIEdB TCB3aGVuIGhhc2hpbmcsIGFzIGlmIHRoZSBHQUwNCj4+Pj4gd2Fzbid0IHRoZXJlLiDDgiBUaGF0 IHdpbGwgeWllbGQgdGhlIHNhbWUgaGFzaCB2YWx1ZSBhbmQgaXQgd2lsbA0KPj4+PiBwcmVzZXJ2 ZSBmYXRlLXNoYXJpbmcgYWNyb3NzIG11bHRpcGF0aC4NCj4+Pj4gDQo+Pj4+IEkgcHJlZmVyIHRo YXQgd2UgZml4IHRoaW5ncyByYXRoZXIgdGhhbiBjb21wbGFpbiB0aGF0IHRoZXkgYXJlIGJyb2tl bi4NCj4+Pj4gDQo+Pj4+IEN1cnRpcw0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+PiBwd2UzIG1haWxpbmcgbGlzdA0KPj4+PiBwd2UzQGll dGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMw0K Pj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBwd2UzIG1haWxpbmcgbGlzdA0KPj4gcHdlM0BpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQo+PiANCj4g DQo+IA0KPiANCj4gLS0gDQo+IC0gU3JpDQo+IA0K From Internet-Drafts@ietf.org Mon Apr 25 11:45:02 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C369E0767; Mon, 25 Apr 2011 11:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQHBmWkr9GSa; Mon, 25 Apr 2011 11:45:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0A912E0752; Mon, 25 Apr 2011 11:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110425184502.15792.63844.idtracker@ietfc.amsl.com> Date: Mon, 25 Apr 2011 11:45:02 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-iccp-05.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 18:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Inter-Chassis Communication Protocol for L2VPN PE Redundancy Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-iccp-05.txt Pages : 78 Date : 2011-04-25 This document specifies an inter-chassis communication protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iccp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pwe3-iccp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-25114052.I-D@ietf.org> --NextPart-- From sriganeshkini@gmail.com Mon Apr 25 11:57:20 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E712E0752 for ; Mon, 25 Apr 2011 11:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjYA4UbiWzzq for ; Mon, 25 Apr 2011 11:57:19 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfc.amsl.com (Postfix) with ESMTP id 21D57E06BB for ; Mon, 25 Apr 2011 11:57:19 -0700 (PDT) Received: by qwc23 with SMTP id 23so1548757qwc.31 for ; Mon, 25 Apr 2011 11:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ISXEUuD5MxBfKAw7eTgzV/GpHYI8WOF3gvHC5vvRLcw=; b=NfLEuCr4+/+2/iPayjnRfP4ax9vAUHJdP/1g7D9QaCtNFyAlO2kYKTuPyoevsgNHOm +6eSLmLul8kz3CdToYuyReQ96nYejZxiz8vghoi/Pbxw5oYuW7RZGMLaIp9BED+dhcfR Jgn7u7VJbJwTp00ji4HSwBtHlrJUpar6BDKnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=oDvEBsvNqzjHbpDzB8yZMa26tnWrBAdRpQIuh4dqmzzGEz2iiUyhsRUP3rh6ncYp7+ fGYCD99ZTLt2RIvTAm4yPrjqTXlieA7V9lNhfhP4EXJzOSUS+vjeuG+r+TbbKzowoQ2+ gp8X3XddT/+6jh+9gU27xT7P7Oy/Sfx+CalCU= Received: by 10.229.212.193 with SMTP id gt1mr1929531qcb.231.1303757838361; Mon, 25 Apr 2011 11:57:18 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.94.143 with HTTP; Mon, 25 Apr 2011 11:56:47 -0700 (PDT) In-Reply-To: <164FBBE6-5814-4C12-8CC1-C1A4D22D7BE6@cisco.com> References: <4D92F5D3.6080609@pi.nu> <201103310703.p2V73Hrx045107@harbor.orleans.occnc.com> <4DB108AD.2040809@cisco.com> <164FBBE6-5814-4C12-8CC1-C1A4D22D7BE6@cisco.com> From: Sriganesh Kini Date: Mon, 25 Apr 2011 11:56:47 -0700 X-Google-Sender-Auth: Sfhl7qJrQVZ6C92h5dYlmn9HlJA Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 18:57:20 -0000 Hi Carlos, Pls see inline. On Fri, Apr 22, 2011 at 6:23 PM, Carlos Pignataro (cpignata) wrote: > Hi Sriganesh, > > Thanks for the quick response and low RTT, please find some follow-ups in= line. > > Carlos P. > > On Apr 22, 2011, at 2:20 PM, "Sriganesh Kini" wrote: > >> Hi Carlos, >> >> The applicability of draft-kini-pwe3-inband-cc-offset is when CW is >> not present, but the intermediate LSR looks beyond the PW label to do >> multipath decisions. The draft is independent of any (even proprietary >> logic) for multipath decision taken by intermediate nodes looking >> beyond PW label and also independent of any heuristic the intermediate >> routers may use to guess the packet type (beyond label stack) being >> carried. > > I think that this statement is a bit too optimistic and too generalized. = It seems to me that, in addition, the PE needs to understand the flows carr= ied inside the PW, have some clue as to the type of ECMP in the core, and t= here should have correlation between these two. This dramatically limited t= he applicability as you say below: > Correct that the PE needs to know the flow that the operator is trying to troubleshoot ! However the PE does not need to know the type of ECMP that is implemented in the core (P router). That algorithm would be typically proprietary. Not sure if you are saying that the PE should know the co-relation between the flow and the ECMP-type before the problem occurs. The draft is not a multi-path algorithm discovery mechanism. That is an important problem, but due to the proprietary nature of those algorithms a solution has limitations. The draft provides a PE a mechanism to troubleshoot a flow without having precise knowledge a-priori of how the multi-path algorithm is behaving for a specific flow. Regarding applicability, consider an encapsulation that has a single label stack in the core consisting of the adaptation label stack (PW in this case) and the label stack of a MPLS packet received from the client CE. This kind of encapsulation is in draft-kini-pwe3-pkt-encap-efficient-ip-mpls when CW is not used. I believe a similar encap is used in the network layer adaptation sec 3.4.5 RFC 5921 for a client layer that is MPLS enabled. In such a case too it is possible to troubleshoot a flow (that includes the client labels and the packet being carried below) of the combined label stack. Also note that this mechanism has some similarity to draft-nadeau-pwe3-vccv-2. The primary difference being that in draft-nadeau the GAL is used to identify an OAM packet instead of TTL, hence the presence of GAL in the hash computation is an issue. Moreover due to the offset, the inband-vccv draft is also independent of the pkt (and multi-path decision based on that) being carried below the label stack. >> The most common heuristic is of course looking at the first >> nibble beyond label stack to determine that it is an IP packet. So >> this would also apply for an IP PW, IPLS, etc in addition to >> draft-kini-pwe3-pkt-encap-efficient-ip-mpls. > > Right. I think it would apply to an IP PW, where there are existing techn= iques to walk multipaths. But it would not to say an Ethernet PW (without C= W): even if the PE sees the flows inside the Ethernet (e.g., TCP flows over= IP over Ethernet), the is no ECMP in the core based on those. > I would like to believe that too. But I have heard that implementations do different things with some packet inspection. >> LSP-Ping uses the 127 >> address and it is not easy to co-relate this to a problem reported for >> real (non 127) addresses. > > I think LSP-Ping can do better: identify and walk all ECMPs. If the ECMP algorithm is proprietary and info about that is not available to the PE, there will be issues. > I also think that the assumption of a problem being reported on a given f= low, only for an IP PW Type is too expensive for the return. > > Thanks, > > -- Carlos. > >> >> Thanks >> >> >> On Thu, Apr 21, 2011 at 9:48 PM, Carlos Pignataro w= rote: >>> Hi Sriganesh, >>> >>> Do you see the applicability of draft-kini-pwe3-inband-cc-offset >>> strictly limited to the encapsulation proposed in >>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls? >>> >>> Specifically, for a PW that carries say Ethernet without CW (or any of >>> the other encap modes with non-mandatory CW), there is no "flow" that i= s >>> being ECMP-ed in the core that you want to mimic/imitate in a >>> load-balancing pseudo-header. Conversely, for "IP PWs", LSP-Ping can >>> take different Equal-cost paths (all of them, one by one) based on >>> choosing the destination IP address. And there is no need for this when >>> there is a CW. >>> >>> I am trying to understand how common is the use case for what this >>> optimizes for. >>> >>> Thanks, >>> >>> -- Carlos. >>> >>> On 3/31/2011 4:08 AM, Sriganesh Kini wrote: >>>> All, >>>> >>>> Just an FYI that a proposal for fate-sharing PW OAM and data given in >>>> draft-kini-pwe3-inband-cc-offset >>>> >>>> Just to summarize the proposal. >>>> 1. It does not require GAL in PW. TTL expiry is used to alert the S/T-= PE. >>>> 2. It is mainly applicable when CW is not used in the PW. >>>> 3. It uses a fixed offset (negotiated between PW endpoints) after the >>>> label stack before starting the OAM msg. >>>> 4. The bytes between the label-stack and the fixed offset is referred >>>> to as a pseudoflow header and is filled with byte-values (by the PE) >>>> that represent the flow for which OAM is desired. This helps PW OAM >>>> and data to fate-share even when the intermediate node looks beyond >>>> label stack to do multipath forwarding decisions. >>>> >>>> >>>> On Thu, Mar 31, 2011 at 12:03 AM, Curtis Villamizar = wrote: >>>>> >>>>> Loa, Dave, Sasha, >>>>> >>>>> I've snipped from various posts on the thread that Sasha started. =C2= See >>>>> inline. >>>>> >>>>> In message <4D92F5D3.6080609@pi.nu> >>>>> Loa Andersson writes: >>>>>> >>>>>> All, >>>>>> >>>>>> missed a nuance in Sasha subject line. >>>>>> >>>>>> We have two issues >>>>>> >>>>>> - where the GAL is placed relative to the PW label, I =C2 believe it= is >>>>>> =C2 =A0=C2 necessary to have the GAL below the PW label. >>>>>> >>>>>> - whether the the GAL label needs to be bottom of stack or not, it >>>>>> =C2 =A0=C2 figure that this is really a discussion if it is possible= to have >>>>>> =C2 =A0=C2 a FAT label below the GAL or not. I'm not sure =C2 about = my preferences >>>>>> =C2 =A0=C2 but I think it is possible. >>>>>> >>>>>> /Loa >>>>> >>>>> I agree with Loa's summary. =C2 Not putting GAL at the bottom may con= fuse >>>>> some LSR, but putting it above the PW label is likely to be even more >>>>> problematic. >>>>> >>>>> >>>>> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.e= amcs.ericsson.se> >>>>> David Allan I writes: >>>>>> >>>>>> It does become a new behavior, GAL with S=3D3D0. However the combina= tion of G=3D >>>>>> AL being top label at the S-PE and TTL being encoded in the PW label= means =3D >>>>>> that fate sharing is broken at every S-PE. Life only gets a little m= ore str=3D >>>>>> ange if there is a FAT label as well... >>>>>> >>>>>> That being said, GAL as bottom label is broken in any ECMP environme= nt, whi=3D >>>>>> ch is why GAL is a TP construct. >>>>>> >>>>>> my 2 cents >>>>>> D >>>>> >>>>> Dave, >>>>> >>>>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >>>>> If all it takes to fix it is simple then lets just fix it. >>>>> >>>>> This is what we'd have to do. >>>>> >>>>> =C2 1) Relax the requirement that GAL be at the bottom >>>>> >>>>> =C2 2) Have the ingress insert GAL in the stack immediately below the >>>>> =C2 =A0=C2 =A0label for which the measurement is made, keeping the re= st of the >>>>> =C2 =A0=C2 =A0label stack in place. >>>>> >>>>> The only thing the midpoing LSR at a multipath (LAG, link bundle for >>>>> MPLS) has to do is skip over the GAL when hashing, as if the GAL >>>>> wasn't there. =C2 That will yield the same hash value and it will >>>>> preserve fate-sharing across multipath. >>>>> >>>>> I prefer that we fix things rather than complain that they are broken= . >>>>> >>>>> Curtis >>>>> _______________________________________________ >>>>> pwe3 mailing list >>>>> pwe3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >> >> >> >> -- >> - Sri >> > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --=20 - Sri From cpignata@cisco.com Mon Apr 25 12:27:59 2011 Return-Path: X-Original-To: pwe3@ietfc.amsl.com Delivered-To: pwe3@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B7630E06EB for ; Mon, 25 Apr 2011 12:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC0agHFGMxRf for ; Mon, 25 Apr 2011 12:27:58 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfc.amsl.com (Postfix) with ESMTP id 4D4F3E06DA for ; Mon, 25 Apr 2011 12:27:58 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3PJMWMP022531; Mon, 25 Apr 2011 15:22:32 -0400 (EDT) Received: from [64.102.157.122] (dhcp-64-102-157-122.cisco.com [64.102.157.122]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3PJMVOO006344; Mon, 25 Apr 2011 15:22:31 -0400 (EDT) Message-ID: <4DB5C9F6.60402@cisco.com> Date: Mon, 25 Apr 2011 15:22:30 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Sriganesh Kini References: <4D92F5D3.6080609@pi.nu> <201103310703.p2V73Hrx045107@harbor.orleans.occnc.com> <4DB108AD.2040809@cisco.com> <164FBBE6-5814-4C12-8CC1-C1A4D22D7BE6@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 19:27:59 -0000 Hi Sriganesh, Please see inline. On 4/25/2011 2:56 PM, Sriganesh Kini wrote: > Hi Carlos, > > Pls see inline. > > On Fri, Apr 22, 2011 at 6:23 PM, Carlos Pignataro (cpignata) > wrote: >> Hi Sriganesh, >> >> Thanks for the quick response and low RTT, please find some follow-ups inline. >> >> Carlos P. >> >> On Apr 22, 2011, at 2:20 PM, "Sriganesh Kini" wrote: >> >>> Hi Carlos, >>> >>> The applicability of draft-kini-pwe3-inband-cc-offset is when CW is >>> not present, but the intermediate LSR looks beyond the PW label to do >>> multipath decisions. The draft is independent of any (even proprietary >>> logic) for multipath decision taken by intermediate nodes looking >>> beyond PW label and also independent of any heuristic the intermediate >>> routers may use to guess the packet type (beyond label stack) being >>> carried. >> >> I think that this statement is a bit too optimistic and too generalized. It seems to me that, in addition, the PE needs to understand the flows carried inside the PW, have some clue as to the type of ECMP in the core, and there should have correlation between these two. This dramatically limited the applicability as you say below: >> > > Correct that the PE needs to know the flow that the operator is trying > to troubleshoot ! However the PE does not need to know the type of > ECMP that is implemented in the core (P router). That algorithm would > be typically proprietary. Not sure if you are saying that the PE > should know the co-relation between the flow and the ECMP-type before > the problem occurs. The draft is not a multi-path algorithm discovery > mechanism. That is an important problem, but due to the proprietary > nature of those algorithms a solution has limitations. The draft > provides a PE a mechanism to troubleshoot a flow without having > precise knowledge a-priori of how the multi-path algorithm is behaving > for a specific flow. Apologies as I was not clear. I did not mean that the PE would need to know the ECMP algorithm. I meant to say that the PE would need to know what the ECMP algorithm is expecting and what fields are relevant for the ECMP algorithm. This was a round-about way of saying that, assuming that ECMP algorithms hash on certain fields of an IP+Transport/ULP header after an MPLS header, then this I-D is applicable for an IP PW. Conversely, for an Ethernet PW, I do not see how you can do what the I-D claims: This document defines a simple extension to the TTL expiry CC (Type 3) to do inband VCCV. This can be used even without a CW. since a(n IP) flow (as received from a PE) is after an Ethernet header, but there is no ECMP based on these flows (since the core routers do not know what the PW is carrying). My point was that unless some flow identifier from the client perspective is what is used for ECMP (which is not the case if there is some L2 or MPLS between IP and the transport), then this technique cannot be used. > > Regarding applicability, consider an encapsulation that has a single > label stack in the core consisting of the adaptation label stack (PW > in this case) and the label stack of a MPLS packet received from the > client CE. This kind of encapsulation is in > draft-kini-pwe3-pkt-encap-efficient-ip-mpls when CW is not used. I > believe a similar encap is used in the network layer adaptation sec > 3.4.5 RFC 5921 for a client layer that is MPLS enabled. In such a case > too it is possible to troubleshoot a flow (that includes the client > labels and the packet being carried below) of the combined label > stack. I do not see how this applies other than for IP PWs. Let me try to ask a different way: The proposal in draft-kini-pwe3-inband-cc-offset uses a "pseudo flow header" after the PW label. It is the expectation that core routers would ECMP-distribute based on said "pseudo flow header". It is also the expectation that when this happens, this OAM would fate-share with actual user traffic. Does this imply that PW traffic needs to start (after the PW Label) with the same values as in the "pseudo flow header", and thus the flow identifiers for regular traffic follow the PW Label directly? > > Also note that this mechanism has some similarity to > draft-nadeau-pwe3-vccv-2. The primary difference being that in > draft-nadeau the GAL is used to identify an OAM packet instead of TTL, > hence the presence of GAL in the hash computation is an issue. > Moreover due to the offset, the inband-vccv draft is also independent > of the pkt (and multi-path decision based on that) being carried below > the label stack. > >>> The most common heuristic is of course looking at the first >>> nibble beyond label stack to determine that it is an IP packet. So >>> this would also apply for an IP PW, IPLS, etc in addition to >>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls. >> >> Right. I think it would apply to an IP PW, where there are existing techniques to walk multipaths. But it would not to say an Ethernet PW (without CW): even if the PE sees the flows inside the Ethernet (e.g., TCP flows over IP over Ethernet), the is no ECMP in the core based on those. >> > > I would like to believe that too. But I have heard that > implementations do different things with some packet inspection. > >>> LSP-Ping uses the 127 >>> address and it is not easy to co-relate this to a problem reported for >>> real (non 127) addresses. >> >> I think LSP-Ping can do better: identify and walk all ECMPs. > > If the ECMP algorithm is proprietary and info about that is not > available to the PE, there will be issues. does not need to know the internals. Thanks, -- Carlos. > >> I also think that the assumption of a problem being reported on a given flow, only for an IP PW Type is too expensive for the return. >> >> Thanks, >> >> -- Carlos. >> >>> >>> Thanks >>> >>> >>> On Thu, Apr 21, 2011 at 9:48 PM, Carlos Pignataro wrote: >>>> Hi Sriganesh, >>>> >>>> Do you see the applicability of draft-kini-pwe3-inband-cc-offset >>>> strictly limited to the encapsulation proposed in >>>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls? >>>> >>>> Specifically, for a PW that carries say Ethernet without CW (or any of >>>> the other encap modes with non-mandatory CW), there is no "flow" that is >>>> being ECMP-ed in the core that you want to mimic/imitate in a >>>> load-balancing pseudo-header. Conversely, for "IP PWs", LSP-Ping can >>>> take different Equal-cost paths (all of them, one by one) based on >>>> choosing the destination IP address. And there is no need for this when >>>> there is a CW. >>>> >>>> I am trying to understand how common is the use case for what this >>>> optimizes for. >>>> >>>> Thanks, >>>> >>>> -- Carlos. >>>> >>>> On 3/31/2011 4:08 AM, Sriganesh Kini wrote: >>>>> All, >>>>> >>>>> Just an FYI that a proposal for fate-sharing PW OAM and data given in >>>>> draft-kini-pwe3-inband-cc-offset >>>>> >>>>> Just to summarize the proposal. >>>>> 1. It does not require GAL in PW. TTL expiry is used to alert the S/T-PE. >>>>> 2. It is mainly applicable when CW is not used in the PW. >>>>> 3. It uses a fixed offset (negotiated between PW endpoints) after the >>>>> label stack before starting the OAM msg. >>>>> 4. The bytes between the label-stack and the fixed offset is referred >>>>> to as a pseudoflow header and is filled with byte-values (by the PE) >>>>> that represent the flow for which OAM is desired. This helps PW OAM >>>>> and data to fate-share even when the intermediate node looks beyond >>>>> label stack to do multipath forwarding decisions. >>>>> >>>>> >>>>> On Thu, Mar 31, 2011 at 12:03 AM, Curtis Villamizar wrote: >>>>>> >>>>>> Loa, Dave, Sasha, >>>>>> >>>>>> I've snipped from various posts on the thread that Sasha started.  See >>>>>> inline. >>>>>> >>>>>> In message <4D92F5D3.6080609@pi.nu> >>>>>> Loa Andersson writes: >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> missed a nuance in Sasha subject line. >>>>>>> >>>>>>> We have two issues >>>>>>> >>>>>>> - where the GAL is placed relative to the PW label, I  believe it is >>>>>>>   necessary to have the GAL below the PW label. >>>>>>> >>>>>>> - whether the the GAL label needs to be bottom of stack or not, it >>>>>>>   figure that this is really a discussion if it is possible to have >>>>>>>   a FAT label below the GAL or not. I'm not sure  about my preferences >>>>>>>   but I think it is possible. >>>>>>> >>>>>>> /Loa >>>>>> >>>>>> I agree with Loa's summary.  Not putting GAL at the bottom may confuse >>>>>> some LSR, but putting it above the PW label is likely to be even more >>>>>> problematic. >>>>>> >>>>>> >>>>>> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703.eamcs.ericsson.se> >>>>>> David Allan I writes: >>>>>>> >>>>>>> It does become a new behavior, GAL with S=3D0. However the combination of G= >>>>>>> AL being top label at the S-PE and TTL being encoded in the PW label means = >>>>>>> that fate sharing is broken at every S-PE. Life only gets a little more str= >>>>>>> ange if there is a FAT label as well... >>>>>>> >>>>>>> That being said, GAL as bottom label is broken in any ECMP environment, whi= >>>>>>> ch is why GAL is a TP construct. >>>>>>> >>>>>>> my 2 cents >>>>>>> D >>>>>> >>>>>> Dave, >>>>>> >>>>>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >>>>>> If all it takes to fix it is simple then lets just fix it. >>>>>> >>>>>> This is what we'd have to do. >>>>>> >>>>>>  1) Relax the requirement that GAL be at the bottom >>>>>> >>>>>>  2) Have the ingress insert GAL in the stack immediately below the >>>>>>   label for which the measurement is made, keeping the rest of the >>>>>>   label stack in place. >>>>>> >>>>>> The only thing the midpoing LSR at a multipath (LAG, link bundle for >>>>>> MPLS) has to do is skip over the GAL when hashing, as if the GAL >>>>>> wasn't there.  That will yield the same hash value and it will >>>>>> preserve fate-sharing across multipath. >>>>>> >>>>>> I prefer that we fix things rather than complain that they are broken. >>>>>> >>>>>> Curtis >>>>>> _______________________________________________ >>>>>> pwe3 mailing list >>>>>> pwe3@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> pwe3 mailing list >>>> pwe3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>> >>> >>> >>> >>> -- >>> - Sri >>> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > > From sriganeshkini@gmail.com Mon Apr 25 16:29:41 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BCAE064A for ; Mon, 25 Apr 2011 16:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v0pl5Xdw4Sp for ; Mon, 25 Apr 2011 16:29:40 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEB49E0663 for ; Mon, 25 Apr 2011 16:29:39 -0700 (PDT) Received: by qwc23 with SMTP id 23so55983qwc.31 for ; Mon, 25 Apr 2011 16:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=4t+9TbyG3V2dAk6fA2qF2Ihmt226VDsm4R4VKSH5mJg=; b=qvx1sTph5rQfS2jTprFLY9WP8w/qMYdFnFnaZq+r/bPTXRW/MCfRKT9Yuw7wK7ZeAb 0x/1yh3RmWsO6h1wKXqwWrM8eeahTvSGNZgHT/PVhCWtqIyo0Y0TWkAe4U/aCD7a70FP 10rBQQGiwk3BoQpW/hm4kQ4JE3U4oUGJNei44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=g46pLbx3mysXpyQANUm1UANgif5XYl2aXc4dryXXKt5JrkmwG9m4rrWQKizHM60elt Cabc+EomOWrHffRR4aN4MQVvB/PDpa5lDommsSBmGmTT6LF96f0PNhKqXnqAff6N0ANX uRXWtdCGf56uOQSUCzADAFJ8CdT95dmFucs9I= Received: by 10.229.33.67 with SMTP id g3mr49630qcd.155.1303774179128; Mon, 25 Apr 2011 16:29:39 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.94.143 with HTTP; Mon, 25 Apr 2011 16:29:08 -0700 (PDT) In-Reply-To: <4DB5C9F6.60402@cisco.com> References: <4D92F5D3.6080609@pi.nu> <201103310703.p2V73Hrx045107@harbor.orleans.occnc.com> <4DB108AD.2040809@cisco.com> <164FBBE6-5814-4C12-8CC1-C1A4D22D7BE6@cisco.com> <4DB5C9F6.60402@cisco.com> From: Sriganesh Kini Date: Mon, 25 Apr 2011 16:29:08 -0700 X-Google-Sender-Auth: SpUCpWl_uorMAObuz7oDTet0qrQ Message-ID: To: Carlos Pignataro Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 23:29:41 -0000 Hi Carlos, Pls see inline. On Mon, Apr 25, 2011 at 12:22 PM, Carlos Pignataro wro= te: > Hi Sriganesh, > > Please see inline. > > On 4/25/2011 2:56 PM, Sriganesh Kini wrote: >> Hi Carlos, >> >> Pls see inline. >> >> On Fri, Apr 22, 2011 at 6:23 PM, Carlos Pignataro (cpignata) >> wrote: >>> Hi Sriganesh, >>> >>> Thanks for the quick response and low RTT, please find some follow-ups = inline. >>> >>> Carlos P. >>> >>> On Apr 22, 2011, at 2:20 PM, "Sriganesh Kini" wrote: >>> >>>> Hi Carlos, >>>> >>>> The applicability of draft-kini-pwe3-inband-cc-offset is when CW is >>>> not present, but the intermediate LSR looks beyond the PW label to do >>>> multipath decisions. The draft is independent of any (even proprietary >>>> logic) for multipath decision taken by intermediate nodes looking >>>> beyond PW label and also independent of any heuristic the intermediate >>>> routers may use to guess the packet type (beyond label stack) being >>>> carried. >>> >>> I think that this statement is a bit too optimistic and too generalized= . It seems to me that, in addition, the PE needs to understand the flows ca= rried inside the PW, have some clue as to the type of ECMP in the core, and= there should have correlation between these two. This dramatically limited= the applicability as you say below: >>> >> >> Correct that the PE needs to know the flow that the operator is trying >> to troubleshoot ! However the PE does not need to know the type of >> ECMP that is implemented in the core (P router). That algorithm would >> be typically proprietary. Not sure if you are saying that the PE >> should know the co-relation between the flow and the ECMP-type before >> the problem occurs. The draft is not a multi-path algorithm discovery >> mechanism. That is an important problem, but due to the proprietary >> nature of those algorithms a solution has limitations. The draft >> provides a PE a mechanism to troubleshoot a flow without having >> precise knowledge a-priori of how the multi-path algorithm is behaving >> for a specific flow. > > Apologies as I was not clear. I did not mean that the PE would need to > know the ECMP algorithm. I meant to say that the PE would need to know > what the ECMP algorithm is expecting and what fields are relevant for > the ECMP algorithm. This was a round-about way of saying that, assuming > that ECMP algorithms hash on certain fields of an IP+Transport/ULP > header after an MPLS header, then this I-D is applicable for an IP PW. Maybe we are saying the same thing here but let me try. I think we both agree that ECMP algorithms at a P router typically look into the packet hdr to do multipath decisions. The caveat being that they may use a heuristic to guess the packet type (due to incomplete information). As long as they do not send a flow along multiple paths everything is ok. Consider a network with P routers P1, P2, P3, .... Say that different P routers have different ECMP algorithms - So P1 hashes only on the label stack, P2 looks at the first nibble beyond label stack and if it is IPv4/v6, hashes on IP src/dest. P3 does the same as P2 except that it looks further and hashes on protocol type and certain TCP/UDP hdrs params. PE1 does not know the details of the P routers algorithms or which parts of the header they look into. Say the PE wants to troubleshoot a TCP session between a pair of IP addresses. The packet that is used for VCCV purposes would look the same as a normal data packet for that TCP session with the exception that the TTL would be as specified for TTL Expiry VCCV type-3 and that beyond the pseudo-flow header, that actual VCCV message would be present instead of the data packet. For the P routers, this VCCV message looks the same as a data packet since it is just looking at the header to do multipath decisions and the data and VCCV message would take the same path through the P routers. In the case where the packet coming from the client has a MPLS label stack and that label stack is sent as a single label stack (i.e. PW label stack + client label stack), then again the client label stack would be part of the flow header (Note that PW label or the optional FAT-PW label will have S=3D0 in this case). > Conversely, for an Ethernet PW, I do not see how you can do what the I-D > claims: > > =A0This document > =A0 defines a simple extension to the TTL expiry CC (Type 3) to do inband > =A0 VCCV. This can be used even without a CW. > > since a(n IP) flow (as received from a PE) is after an Ethernet header, > but there is no ECMP based on these flows (since the core routers do not > know what the PW is carrying). > > My point was that unless some flow identifier from the client > perspective is what is used for ECMP (which is not the case if there is > some L2 or MPLS between IP and the transport), then this technique > cannot be used. If any field from the client packet is not used by the transit LSR for ECMP then TTL Expiry VCCV type 3 is always inband. So in that sense I agree. One of the problems we have with VCCV is that multiple types have been deployed (some of which are inband) and also that CW has been used in some PW deployments and not others. This draft is addressing cases where CW is not used and intermediate LSRs look beyond the PW labels (including FAT-PW) into the packet to do multipath decisions. This could be an IP packet immediately following label stack, any client labels that form a single label stack with the PW labels, or (as a stretch) even a P router heuristic such as - a nibble beyond label stack that indicates a non IPv4/6 packet is an ethernet header. I am not advocating such an approach, just making a point that this draft provides a solution that is agnostic of such behavior. > >> >> Regarding applicability, consider an encapsulation that has a single >> label stack in the core consisting of the adaptation label stack (PW >> in this case) and the label stack of a MPLS packet received from the >> client CE. This kind of encapsulation is in >> draft-kini-pwe3-pkt-encap-efficient-ip-mpls when CW is not used. I >> believe a similar encap is used in the network layer adaptation sec >> 3.4.5 RFC 5921 for a client layer that is MPLS enabled. In such a case >> too it is possible to troubleshoot a flow (that includes the client >> labels and the packet being carried below) of the combined label >> stack. > > I do not see how this applies other than for IP PWs. Let me try to ask a > different way: The proposal in draft-kini-pwe3-inband-cc-offset uses a > "pseudo flow header" after the PW label. It is the expectation that core > routers would ECMP-distribute based on said "pseudo flow header". It is > also the expectation that when this happens, this OAM would fate-share > with actual user traffic. Does this imply that PW traffic needs to start > (after the PW Label) with the same values as in the "pseudo flow > header", and thus the flow identifiers for regular traffic follow the PW > Label directly? > The PW payload stays exactly the way it does according to the adaptation defined for that type of PW. This draft does not define any new adaptation, so it has no new implications on where the PW traffic needs to start. All it defines is a variant of the TTL expiry VCCV, where the VCCV message starts at an offset after the PW label. The packet encoding (after the PW label) till the offset is exactly the same as for a data packet (for which the inband OAM needs to be executed). >> >> Also note that this mechanism has some similarity to >> draft-nadeau-pwe3-vccv-2. The primary difference being that in >> draft-nadeau the GAL is used to identify an OAM packet instead of TTL, >> hence the presence of GAL in the hash computation is an issue. >> Moreover due to the offset, the inband-vccv draft =A0is also independent >> of the pkt (and multi-path decision based on that) being carried below >> the label stack. >> >>>> The most common heuristic is of course looking at the first >>>> nibble beyond label stack to determine that it is an IP packet. So >>>> this would also apply for an IP PW, IPLS, etc in addition to >>>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls. >>> >>> Right. I think it would apply to an IP PW, where there are existing tec= hniques to walk multipaths. But it would not to say an Ethernet PW (without= CW): even if the PE sees the flows inside the Ethernet (e.g., TCP flows ov= er IP over Ethernet), the is no ECMP in the core based on those. >>> >> >> I would like to believe that too. But I have heard that >> implementations do different things with some packet inspection. >> >>>> LSP-Ping uses the 127 >>>> address and it is not easy to co-relate this to a problem reported for >>>> real (non 127) addresses. >>> >>> I think LSP-Ping can do better: identify and walk all ECMPs. >> >> If the ECMP algorithm is proprietary and info about that is not >> available to the PE, there will be issues. > > does not need to know > the internals. Yes, that can be used to identify LSP paths, find out which IP addresses (127 range) map to which LSP nexthop and so on. But VCCV is determining the health of the PW at the PW layer that may include multiple LSPs (especially MS-PW). When the PW can take multiple paths it is useful to quickly determine if a client flow that needs troubleshooting has a problem and which segment of the PW has that problem. That may be followed by a LSP tracing for the segment of the PW that has a problem. > > Thanks, > > -- Carlos. > >> >>> I also think that the assumption of a problem being reported on a given= flow, only for an IP PW Type is too expensive for the return. >>> >>> Thanks, >>> >>> -- Carlos. >>> >>>> >>>> Thanks >>>> >>>> >>>> On Thu, Apr 21, 2011 at 9:48 PM, Carlos Pignataro = wrote: >>>>> Hi Sriganesh, >>>>> >>>>> Do you see the applicability of draft-kini-pwe3-inband-cc-offset >>>>> strictly limited to the encapsulation proposed in >>>>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls? >>>>> >>>>> Specifically, for a PW that carries say Ethernet without CW (or any o= f >>>>> the other encap modes with non-mandatory CW), there is no "flow" that= is >>>>> being ECMP-ed in the core that you want to mimic/imitate in a >>>>> load-balancing pseudo-header. Conversely, for "IP PWs", LSP-Ping can >>>>> take different Equal-cost paths (all of them, one by one) based on >>>>> choosing the destination IP address. And there is no need for this wh= en >>>>> there is a CW. >>>>> >>>>> I am trying to understand how common is the use case for what this >>>>> optimizes for. >>>>> >>>>> Thanks, >>>>> >>>>> -- Carlos. >>>>> >>>>> On 3/31/2011 4:08 AM, Sriganesh Kini wrote: >>>>>> All, >>>>>> >>>>>> Just an FYI that a proposal for fate-sharing PW OAM and data given i= n >>>>>> draft-kini-pwe3-inband-cc-offset >>>>>> >>>>>> Just to summarize the proposal. >>>>>> 1. It does not require GAL in PW. TTL expiry is used to alert the S/= T-PE. >>>>>> 2. It is mainly applicable when CW is not used in the PW. >>>>>> 3. It uses a fixed offset (negotiated between PW endpoints) after th= e >>>>>> label stack before starting the OAM msg. >>>>>> 4. The bytes between the label-stack and the fixed offset is referre= d >>>>>> to as a pseudoflow header and is filled with byte-values (by the PE) >>>>>> that represent the flow for which OAM is desired. This helps PW OAM >>>>>> and data to fate-share even when the intermediate node looks beyond >>>>>> label stack to do multipath forwarding decisions. >>>>>> >>>>>> >>>>>> On Thu, Mar 31, 2011 at 12:03 AM, Curtis Villamizar wrote: >>>>>>> >>>>>>> Loa, Dave, Sasha, >>>>>>> >>>>>>> I've snipped from various posts on the thread that Sasha started. = =C2 See >>>>>>> inline. >>>>>>> >>>>>>> In message <4D92F5D3.6080609@pi.nu> >>>>>>> Loa Andersson writes: >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> missed a nuance in Sasha subject line. >>>>>>>> >>>>>>>> We have two issues >>>>>>>> >>>>>>>> - where the GAL is placed relative to the PW label, I =C2 believe = it is >>>>>>>> =C2 =A0=C2 necessary to have the GAL below the PW label. >>>>>>>> >>>>>>>> - whether the the GAL label needs to be bottom of stack or not, it >>>>>>>> =C2 =A0=C2 figure that this is really a discussion if it is possib= le to have >>>>>>>> =C2 =A0=C2 a FAT label below the GAL or not. I'm not sure =C2 abou= t my preferences >>>>>>>> =C2 =A0=C2 but I think it is possible. >>>>>>>> >>>>>>>> /Loa >>>>>>> >>>>>>> I agree with Loa's summary. =C2 Not putting GAL at the bottom may c= onfuse >>>>>>> some LSR, but putting it above the PW label is likely to be even mo= re >>>>>>> problematic. >>>>>>> >>>>>>> >>>>>>> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS0703= .eamcs.ericsson.se> >>>>>>> David Allan I writes: >>>>>>>> >>>>>>>> It does become a new behavior, GAL with S=3D3D0. However the combi= nation of G=3D >>>>>>>> AL being top label at the S-PE and TTL being encoded in the PW lab= el means =3D >>>>>>>> that fate sharing is broken at every S-PE. Life only gets a little= more str=3D >>>>>>>> ange if there is a FAT label as well... >>>>>>>> >>>>>>>> That being said, GAL as bottom label is broken in any ECMP environ= ment, whi=3D >>>>>>>> ch is why GAL is a TP construct. >>>>>>>> >>>>>>>> my 2 cents >>>>>>>> D >>>>>>> >>>>>>> Dave, >>>>>>> >>>>>>> If GAL is broken for ECMP, which it is, then all TP OAM is broken. >>>>>>> If all it takes to fix it is simple then lets just fix it. >>>>>>> >>>>>>> This is what we'd have to do. >>>>>>> >>>>>>> =C2 1) Relax the requirement that GAL be at the bottom >>>>>>> >>>>>>> =C2 2) Have the ingress insert GAL in the stack immediately below t= he >>>>>>> =C2 =A0=C2 =A0label for which the measurement is made, keeping the = rest of the >>>>>>> =C2 =A0=C2 =A0label stack in place. >>>>>>> >>>>>>> The only thing the midpoing LSR at a multipath (LAG, link bundle fo= r >>>>>>> MPLS) has to do is skip over the GAL when hashing, as if the GAL >>>>>>> wasn't there. =C2 That will yield the same hash value and it will >>>>>>> preserve fate-sharing across multipath. >>>>>>> >>>>>>> I prefer that we fix things rather than complain that they are brok= en. >>>>>>> >>>>>>> Curtis >>>>>>> _______________________________________________ >>>>>>> pwe3 mailing list >>>>>>> pwe3@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> pwe3 mailing list >>>>> pwe3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>>> >>>> >>>> >>>> >>>> -- >>>> - Sri >>>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >> >> >> > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --=20 - Sri From cpignata@cisco.com Mon Apr 25 18:07:30 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B30E069C for ; Mon, 25 Apr 2011 18:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.532 X-Spam-Level: X-Spam-Status: No, score=-108.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU8BG6r033pO for ; Mon, 25 Apr 2011 18:07:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7712DE0699 for ; Mon, 25 Apr 2011 18:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=22514; q=dns/txt; s=iport; t=1303780048; x=1304989648; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=AVo073Q+3X+7hqdAjwz9+yPMhP7p6I2UVay6VhGpdJc=; b=kYZ+TlI66BKelAczejJdlIK0vpa+musML/8boiTaRC2BhKMemHkBksDY S3aCWy9DjpKXWEE04cN2wj3eGuNTHaJr1XND00JfZLdeyP0NPsCSkQ7cL 0qmhCVCE+H3/OgmSIwIGqwX/XLpvadZV0k4DpKJfgRcKADUtzH+1iDq5R k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFACAatk2tJXG//2dsb2JhbACET6AIYwJ3iHCgSotgkSuBKYFWgXp9BI41hA8 X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208";a="686909720" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2011 01:07:27 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q17RfY022493; Tue, 26 Apr 2011 01:07:27 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Apr 2011 20:07:26 -0500 Received: from 72.163.62.204 ([72.163.62.204]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Apr 2011 01:07:26 +0000 References: <4D92F5D3.6080609@pi.nu> <201103310703.p2V73Hrx045107@harbor.orleans.occnc.com> <4DB108AD.2040809@cisco.com> <164FBBE6-5814-4C12-8CC1-C1A4D22D7BE6@cisco.com> <4DB5C9F6.60402@cisco.com> Content-Transfer-Encoding: base64 From: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset="utf-8" In-Reply-To: Message-ID: Date: Mon, 25 Apr 2011 21:07:15 -0400 To: "Sriganesh Kini" thread-topic: [PWE3] GAL above and below the PW label thread-index: AcwDrk6jq6rGPYrBR9O6HmqXA3BKuw== MIME-Version: 1.0 (iPad Mail 8H7) X-OriginalArrivalTime: 26 Apr 2011 01:07:26.0549 (UTC) FILETIME=[4EA46050:01CC03AE] Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 01:07:30 -0000 U3JpZ2FuZXNoLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNhcmxvcyBQLg0KDQpPbiBBcHIg MjUsIDIwMTEsIGF0IDc6MjkgUE0sICJTcmlnYW5lc2ggS2luaSIgPHNyaWdhbmVzaC5raW5pQGVy aWNzc29uLmNvbT4gd3JvdGU6DQoNCj4gSGkgQ2FybG9zLA0KPiANCj4gUGxzIHNlZSBpbmxpbmUu DQo+IA0KPiBPbiBNb24sIEFwciAyNSwgMjAxMSBhdCAxMjoyMiBQTSwgQ2FybG9zIFBpZ25hdGFy byA8Y3BpZ25hdGFAY2lzY28uY29tPiB3cm90ZToNCj4+IEhpIFNyaWdhbmVzaCwNCj4+IA0KPj4g UGxlYXNlIHNlZSBpbmxpbmUuDQo+PiANCj4+IE9uIDQvMjUvMjAxMSAyOjU2IFBNLCBTcmlnYW5l c2ggS2luaSB3cm90ZToNCj4+PiBIaSBDYXJsb3MsDQo+Pj4gDQo+Pj4gUGxzIHNlZSBpbmxpbmUu DQo+Pj4gDQo+Pj4gT24gRnJpLCBBcHIgMjIsIDIwMTEgYXQgNjoyMyBQTSwgQ2FybG9zIFBpZ25h dGFybyAoY3BpZ25hdGEpDQo+Pj4gPGNwaWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+IEhp IFNyaWdhbmVzaCwNCj4+Pj4gDQo+Pj4+IFRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlIGFu ZCBsb3cgUlRULCBwbGVhc2UgZmluZCBzb21lIGZvbGxvdy11cHMgaW5saW5lLg0KPj4+PiANCj4+ Pj4gQ2FybG9zIFAuDQo+Pj4+IA0KPj4+PiBPbiBBcHIgMjIsIDIwMTEsIGF0IDI6MjAgUE0sICJT cmlnYW5lc2ggS2luaSIgPHNyaWdhbmVzaC5raW5pQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+ IA0KPj4+Pj4gSGkgQ2FybG9zLA0KPj4+Pj4gDQo+Pj4+PiBUaGUgYXBwbGljYWJpbGl0eSBvZiBk cmFmdC1raW5pLXB3ZTMtaW5iYW5kLWNjLW9mZnNldCBpcyB3aGVuIENXIGlzDQo+Pj4+PiBub3Qg cHJlc2VudCwgYnV0IHRoZSBpbnRlcm1lZGlhdGUgTFNSIGxvb2tzIGJleW9uZCB0aGUgUFcgbGFi ZWwgdG8gZG8NCj4+Pj4+IG11bHRpcGF0aCBkZWNpc2lvbnMuIFRoZSBkcmFmdCBpcyBpbmRlcGVu ZGVudCBvZiBhbnkgKGV2ZW4gcHJvcHJpZXRhcnkNCj4+Pj4+IGxvZ2ljKSBmb3IgbXVsdGlwYXRo IGRlY2lzaW9uIHRha2VuIGJ5IGludGVybWVkaWF0ZSBub2RlcyBsb29raW5nDQo+Pj4+PiBiZXlv bmQgUFcgbGFiZWwgYW5kIGFsc28gaW5kZXBlbmRlbnQgb2YgYW55IGhldXJpc3RpYyB0aGUgaW50 ZXJtZWRpYXRlDQo+Pj4+PiByb3V0ZXJzIG1heSB1c2UgdG8gZ3Vlc3MgdGhlIHBhY2tldCB0eXBl IChiZXlvbmQgbGFiZWwgc3RhY2spIGJlaW5nDQo+Pj4+PiBjYXJyaWVkLg0KPj4+PiANCj4+Pj4g SSB0aGluayB0aGF0IHRoaXMgc3RhdGVtZW50IGlzIGEgYml0IHRvbyBvcHRpbWlzdGljIGFuZCB0 b28gZ2VuZXJhbGl6ZWQuIEl0IHNlZW1zIHRvIG1lIHRoYXQsIGluIGFkZGl0aW9uLCB0aGUgUEUg bmVlZHMgdG8gdW5kZXJzdGFuZCB0aGUgZmxvd3MgY2FycmllZCBpbnNpZGUgdGhlIFBXLCBoYXZl IHNvbWUgY2x1ZSBhcyB0byB0aGUgdHlwZSBvZiBFQ01QIGluIHRoZSBjb3JlLCBhbmQgdGhlcmUg c2hvdWxkIGhhdmUgY29ycmVsYXRpb24gYmV0d2VlbiB0aGVzZSB0d28uIFRoaXMgZHJhbWF0aWNh bGx5IGxpbWl0ZWQgdGhlIGFwcGxpY2FiaWxpdHkgYXMgeW91IHNheSBiZWxvdzoNCj4+Pj4gDQo+ Pj4gDQo+Pj4gQ29ycmVjdCB0aGF0IHRoZSBQRSBuZWVkcyB0byBrbm93IHRoZSBmbG93IHRoYXQg dGhlIG9wZXJhdG9yIGlzIHRyeWluZw0KPj4+IHRvIHRyb3VibGVzaG9vdCAhIEhvd2V2ZXIgdGhl IFBFIGRvZXMgbm90IG5lZWQgdG8ga25vdyB0aGUgdHlwZSBvZg0KPj4+IEVDTVAgdGhhdCBpcyBp bXBsZW1lbnRlZCBpbiB0aGUgY29yZSAoUCByb3V0ZXIpLiBUaGF0IGFsZ29yaXRobSB3b3VsZA0K Pj4+IGJlIHR5cGljYWxseSBwcm9wcmlldGFyeS4gTm90IHN1cmUgaWYgeW91IGFyZSBzYXlpbmcg dGhhdCB0aGUgUEUNCj4+PiBzaG91bGQga25vdyB0aGUgY28tcmVsYXRpb24gYmV0d2VlbiB0aGUg ZmxvdyBhbmQgdGhlIEVDTVAtdHlwZSBiZWZvcmUNCj4+PiB0aGUgcHJvYmxlbSBvY2N1cnMuIFRo ZSBkcmFmdCBpcyBub3QgYSBtdWx0aS1wYXRoIGFsZ29yaXRobSBkaXNjb3ZlcnkNCj4+PiBtZWNo YW5pc20uIFRoYXQgaXMgYW4gaW1wb3J0YW50IHByb2JsZW0sIGJ1dCBkdWUgdG8gdGhlIHByb3By aWV0YXJ5DQo+Pj4gbmF0dXJlIG9mIHRob3NlIGFsZ29yaXRobXMgYSBzb2x1dGlvbiBoYXMgbGlt aXRhdGlvbnMuIFRoZSBkcmFmdA0KPj4+IHByb3ZpZGVzIGEgUEUgYSBtZWNoYW5pc20gdG8gdHJv dWJsZXNob290IGEgZmxvdyB3aXRob3V0IGhhdmluZw0KPj4+IHByZWNpc2Uga25vd2xlZGdlIGEt cHJpb3JpIG9mIGhvdyB0aGUgbXVsdGktcGF0aCBhbGdvcml0aG0gaXMgYmVoYXZpbmcNCj4+PiBm b3IgYSBzcGVjaWZpYyBmbG93Lg0KPj4gDQo+PiBBcG9sb2dpZXMgYXMgSSB3YXMgbm90IGNsZWFy LiBJIGRpZCBub3QgbWVhbiB0aGF0IHRoZSBQRSB3b3VsZCBuZWVkIHRvDQo+PiBrbm93IHRoZSBF Q01QIGFsZ29yaXRobS4gSSBtZWFudCB0byBzYXkgdGhhdCB0aGUgUEUgd291bGQgbmVlZCB0byBr bm93DQo+PiB3aGF0IHRoZSBFQ01QIGFsZ29yaXRobSBpcyBleHBlY3RpbmcgYW5kIHdoYXQgZmll bGRzIGFyZSByZWxldmFudCBmb3INCj4+IHRoZSBFQ01QIGFsZ29yaXRobS4gVGhpcyB3YXMgYSBy b3VuZC1hYm91dCB3YXkgb2Ygc2F5aW5nIHRoYXQsIGFzc3VtaW5nDQo+PiB0aGF0IEVDTVAgYWxn b3JpdGhtcyBoYXNoIG9uIGNlcnRhaW4gZmllbGRzIG9mIGFuIElQK1RyYW5zcG9ydC9VTFANCj4+ IGhlYWRlciBhZnRlciBhbiBNUExTIGhlYWRlciwgdGhlbiB0aGlzIEktRCBpcyBhcHBsaWNhYmxl IGZvciBhbiBJUCBQVy4NCj4gDQo+IE1heWJlIHdlIGFyZSBzYXlpbmcgdGhlIHNhbWUgdGhpbmcg aGVyZSBidXQgbGV0IG1lIHRyeS4gSSB0aGluayB3ZQ0KPiBib3RoIGFncmVlIHRoYXQgRUNNUCBh bGdvcml0aG1zIGF0IGEgUCByb3V0ZXIgdHlwaWNhbGx5IGxvb2sgaW50byB0aGUNCj4gcGFja2V0 IGhkciB0byBkbyBtdWx0aXBhdGggZGVjaXNpb25zLiBUaGUgY2F2ZWF0IGJlaW5nIHRoYXQgdGhl eSBtYXkNCj4gdXNlIGEgaGV1cmlzdGljIHRvIGd1ZXNzIHRoZSBwYWNrZXQgdHlwZSAoZHVlIHRv IGluY29tcGxldGUNCj4gaW5mb3JtYXRpb24pLiBBcyBsb25nIGFzIHRoZXkgZG8gbm90IHNlbmQg YSBmbG93IGFsb25nIG11bHRpcGxlIHBhdGhzDQo+IGV2ZXJ5dGhpbmcgaXMgb2suDQo+IA0KPiBD b25zaWRlciBhIG5ldHdvcmsgd2l0aCBQIHJvdXRlcnMgUDEsIFAyLCBQMywgLi4uLiBTYXkgdGhh dCBkaWZmZXJlbnQNCj4gUCByb3V0ZXJzIGhhdmUgZGlmZmVyZW50IEVDTVAgYWxnb3JpdGhtcyAt IFNvIFAxIGhhc2hlcyBvbmx5IG9uIHRoZQ0KPiBsYWJlbCBzdGFjaywgUDIgbG9va3MgYXQgdGhl IGZpcnN0IG5pYmJsZSBiZXlvbmQgbGFiZWwgc3RhY2sgYW5kIGlmIGl0DQo+IGlzIElQdjQvdjYs IGhhc2hlcyBvbiBJUCBzcmMvZGVzdC4gUDMgZG9lcyB0aGUgc2FtZSBhcyBQMiBleGNlcHQgdGhh dA0KPiBpdCBsb29rcyBmdXJ0aGVyIGFuZCBoYXNoZXMgb24gcHJvdG9jb2wgdHlwZSBhbmQgY2Vy dGFpbiBUQ1AvVURQIGhkcnMNCj4gcGFyYW1zLg0KPiANCj4gUEUxIGRvZXMgbm90IGtub3cgdGhl IGRldGFpbHMgb2YgdGhlIFAgcm91dGVycyBhbGdvcml0aG1zIG9yIHdoaWNoDQo+IHBhcnRzIG9m IHRoZSBoZWFkZXIgdGhleSBsb29rIGludG8uIFNheSB0aGUgUEUgd2FudHMgdG8gdHJvdWJsZXNo b290IGENCj4gVENQIHNlc3Npb24gYmV0d2VlbiBhIHBhaXIgb2YgSVAgYWRkcmVzc2VzLiBUaGUg cGFja2V0IHRoYXQgaXMgdXNlZA0KPiBmb3IgVkNDViBwdXJwb3NlcyB3b3VsZCBsb29rIHRoZSBz YW1lIGFzIGEgbm9ybWFsIGRhdGEgcGFja2V0IGZvciB0aGF0DQo+IFRDUCBzZXNzaW9uIHdpdGgg dGhlIGV4Y2VwdGlvbiB0aGF0IHRoZSBUVEwgd291bGQgYmUgYXMgc3BlY2lmaWVkIGZvcg0KPiBU VEwgRXhwaXJ5IFZDQ1YgdHlwZS0zIGFuZCB0aGF0IGJleW9uZCB0aGUgcHNldWRvLWZsb3cgaGVh ZGVyLCB0aGF0DQo+IGFjdHVhbCBWQ0NWIG1lc3NhZ2Ugd291bGQgYmUgcHJlc2VudCBpbnN0ZWFk IG9mIHRoZSBkYXRhIHBhY2tldC4NCg0KTm8sIHRoaXMgaXMgdGhlIGtleS4gVkNDViBleGlzdHMg aW4gdGhlIGNvbnRleHQgb2YgYSBQVywgd2hpY2ggaXMgbW9yZSBnZW5lcmljIHRoYW4gSVAgZGly ZWN0bHkgb3ZlciBNUExTLiBTbyB0aGVyZSBpcywgcG90ZW50aWFsbHksIG5vIFRDUCBzZXNzaW9u IGZyb20gQ0VzIHdvdWxkIGluZmx1ZW5jZSBFQ01QIGZvciBhbiBFdGhlcm5ldCBQVywgd2hpY2gg aXMgdGhlIG5lZWQgZm9yIEZhdC1QVyB0byBzdW1tYXJpemUgdGhlIGZsb3cgaW4gc29tZXRoaW5n IG1lYW5pbmdmdWwgaW4gdGhlIGNvcmUuDQoNCj4gRm9yDQo+IHRoZSBQIHJvdXRlcnMsIHRoaXMg VkNDViBtZXNzYWdlIGxvb2tzIHRoZSBzYW1lIGFzIGEgZGF0YSBwYWNrZXQgc2luY2UNCj4gaXQg aXMganVzdCBsb29raW5nIGF0IHRoZSBoZWFkZXIgdG8gZG8gbXVsdGlwYXRoIGRlY2lzaW9ucyBh bmQgdGhlDQo+IGRhdGEgYW5kIFZDQ1YgbWVzc2FnZSB3b3VsZCB0YWtlIHRoZSBzYW1lIHBhdGgg dGhyb3VnaCB0aGUgUCByb3V0ZXJzLg0KPiANCj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIHBhY2tl dCBjb21pbmcgZnJvbSB0aGUgY2xpZW50IGhhcyBhIE1QTFMgbGFiZWwNCj4gc3RhY2sgYW5kIHRo YXQgbGFiZWwgc3RhY2sgaXMgc2VudCBhcyBhIHNpbmdsZSBsYWJlbCBzdGFjayAoaS5lLiBQVw0K PiBsYWJlbCBzdGFjayArIGNsaWVudCBsYWJlbCBzdGFjayksIHRoZW4gYWdhaW4gdGhlIGNsaWVu dCBsYWJlbCBzdGFjaw0KPiB3b3VsZCBiZSBwYXJ0IG9mIHRoZSBmbG93IGhlYWRlciAoTm90ZSB0 aGF0IFBXIGxhYmVsIG9yIHRoZSBvcHRpb25hbA0KPiBGQVQtUFcgbGFiZWwgd2lsbCBoYXZlIFM9 MCBpbiB0aGlzIGNhc2UpLg0KPiANCj4+IENvbnZlcnNlbHksIGZvciBhbiBFdGhlcm5ldCBQVywg SSBkbyBub3Qgc2VlIGhvdyB5b3UgY2FuIGRvIHdoYXQgdGhlIEktRA0KPj4gY2xhaW1zOg0KPj4g DQo+PiDDgiBUaGlzIGRvY3VtZW50DQo+PiDDgiAgZGVmaW5lcyBhIHNpbXBsZSBleHRlbnNpb24g dG8gdGhlIFRUTCBleHBpcnkgQ0MgKFR5cGUgMykgdG8gZG8gaW5iYW5kDQo+PiDDgiAgVkNDVi4g VGhpcyBjYW4gYmUgdXNlZCBldmVuIHdpdGhvdXQgYSBDVy4NCj4+IA0KPj4gc2luY2UgYShuIElQ KSBmbG93IChhcyByZWNlaXZlZCBmcm9tIGEgUEUpIGlzIGFmdGVyIGFuIEV0aGVybmV0IGhlYWRl ciwNCj4+IGJ1dCB0aGVyZSBpcyBubyBFQ01QIGJhc2VkIG9uIHRoZXNlIGZsb3dzIChzaW5jZSB0 aGUgY29yZSByb3V0ZXJzIGRvIG5vdA0KPj4ga25vdyB3aGF0IHRoZSBQVyBpcyBjYXJyeWluZyku DQo+PiANCj4+IE15IHBvaW50IHdhcyB0aGF0IHVubGVzcyBzb21lIGZsb3cgaWRlbnRpZmllciBm cm9tIHRoZSBjbGllbnQNCj4+IHBlcnNwZWN0aXZlIGlzIHdoYXQgaXMgdXNlZCBmb3IgRUNNUCAo d2hpY2ggaXMgbm90IHRoZSBjYXNlIGlmIHRoZXJlIGlzDQo+PiBzb21lIEwyIG9yIE1QTFMgYmV0 d2VlbiBJUCBhbmQgdGhlIHRyYW5zcG9ydCksIHRoZW4gdGhpcyB0ZWNobmlxdWUNCj4+IGNhbm5v dCBiZSB1c2VkLg0KPiANCj4gSWYgYW55IGZpZWxkIGZyb20gdGhlIGNsaWVudCBwYWNrZXQgaXMg bm90IHVzZWQgYnkgdGhlIHRyYW5zaXQgTFNSIGZvcg0KPiBFQ01QIHRoZW4gVFRMIEV4cGlyeSBW Q0NWIHR5cGUgMyBpcyBhbHdheXMgaW5iYW5kLiBTbyBpbiB0aGF0IHNlbnNlIEkNCj4gYWdyZWUu IE9uZSBvZiB0aGUgcHJvYmxlbXMgd2UgaGF2ZSB3aXRoIFZDQ1YgaXMgdGhhdCBtdWx0aXBsZSB0 eXBlcw0KPiBoYXZlIGJlZW4gZGVwbG95ZWQgKHNvbWUgb2Ygd2hpY2ggYXJlIGluYmFuZCkgYW5k IGFsc28gdGhhdCBDVyBoYXMNCj4gYmVlbiB1c2VkIGluIHNvbWUgUFcgZGVwbG95bWVudHMgYW5k IG5vdCBvdGhlcnMuIFRoaXMgZHJhZnQgaXMNCj4gYWRkcmVzc2luZyBjYXNlcyB3aGVyZSBDVyBp cyBub3QgdXNlZCBhbmQgaW50ZXJtZWRpYXRlIExTUnMgbG9vaw0KPiBiZXlvbmQgdGhlIFBXIGxh YmVscyAoaW5jbHVkaW5nIEZBVC1QVykgaW50byB0aGUgcGFja2V0IHRvIGRvDQo+IG11bHRpcGF0 aCBkZWNpc2lvbnMuIFRoaXMgY291bGQgYmUgYW4gSVAgcGFja2V0IGltbWVkaWF0ZWx5IGZvbGxv d2luZw0KPiBsYWJlbCBzdGFjaywgYW55IGNsaWVudCBsYWJlbHMgdGhhdCBmb3JtIGEgc2luZ2xl IGxhYmVsIHN0YWNrIHdpdGggdGhlDQo+IFBXIGxhYmVscywgb3IgKGFzIGEgc3RyZXRjaCkgZXZl biBhIFAgcm91dGVyIGhldXJpc3RpYyBzdWNoIGFzIC0gYQ0KPiBuaWJibGUgYmV5b25kIGxhYmVs IHN0YWNrIHRoYXQgaW5kaWNhdGVzIGEgbm9uIElQdjQvNiBwYWNrZXQgaXMgYW4NCj4gZXRoZXJu ZXQgaGVhZGVyLiBJIGFtIG5vdCBhZHZvY2F0aW5nIHN1Y2ggYW4gYXBwcm9hY2gsIGp1c3QgbWFr aW5nIGENCj4gcG9pbnQgdGhhdCB0aGlzIGRyYWZ0IHByb3ZpZGVzIGEgc29sdXRpb24gdGhhdCBp cyBhZ25vc3RpYyBvZiBzdWNoDQo+IGJlaGF2aW9yLg0KDQpNeSBjb21tZW50IGlzIHRoYXQgSSBh bSBub3QgY29udmluY2VkIG9mIHRoZSBsYXR0ZXIsIG5vdCBldmVuIGFzIGEgc3RyZXRjaC4gVGhh dCdzIHdoeSBJIHdhcyBhc2tpbmcgYWJvdXQgYXBwbGljYWJpbGl0eS4gDQoNCj4gDQo+PiANCj4+ PiANCj4+PiBSZWdhcmRpbmcgYXBwbGljYWJpbGl0eSwgY29uc2lkZXIgYW4gZW5jYXBzdWxhdGlv biB0aGF0IGhhcyBhIHNpbmdsZQ0KPj4+IGxhYmVsIHN0YWNrIGluIHRoZSBjb3JlIGNvbnNpc3Rp bmcgb2YgdGhlIGFkYXB0YXRpb24gbGFiZWwgc3RhY2sgKFBXDQo+Pj4gaW4gdGhpcyBjYXNlKSBh bmQgdGhlIGxhYmVsIHN0YWNrIG9mIGEgTVBMUyBwYWNrZXQgcmVjZWl2ZWQgZnJvbSB0aGUNCj4+ PiBjbGllbnQgQ0UuIFRoaXMga2luZCBvZiBlbmNhcHN1bGF0aW9uIGlzIGluDQo+Pj4gZHJhZnQt a2luaS1wd2UzLXBrdC1lbmNhcC1lZmZpY2llbnQtaXAtbXBscyB3aGVuIENXIGlzIG5vdCB1c2Vk LiBJDQo+Pj4gYmVsaWV2ZSBhIHNpbWlsYXIgZW5jYXAgaXMgdXNlZCBpbiB0aGUgbmV0d29yayBs YXllciBhZGFwdGF0aW9uIHNlYw0KPj4+IDMuNC41IFJGQyA1OTIxIGZvciBhIGNsaWVudCBsYXll ciB0aGF0IGlzIE1QTFMgZW5hYmxlZC4gSW4gc3VjaCBhIGNhc2UNCj4+PiB0b28gaXQgaXMgcG9z c2libGUgdG8gdHJvdWJsZXNob290IGEgZmxvdyAodGhhdCBpbmNsdWRlcyB0aGUgY2xpZW50DQo+ Pj4gbGFiZWxzIGFuZCB0aGUgcGFja2V0IGJlaW5nIGNhcnJpZWQgYmVsb3cpIG9mIHRoZSBjb21i aW5lZCBsYWJlbA0KPj4+IHN0YWNrLg0KPj4gDQo+PiBJIGRvIG5vdCBzZWUgaG93IHRoaXMgYXBw bGllcyBvdGhlciB0aGFuIGZvciBJUCBQV3MuIExldCBtZSB0cnkgdG8gYXNrIGENCj4+IGRpZmZl cmVudCB3YXk6IFRoZSBwcm9wb3NhbCBpbiBkcmFmdC1raW5pLXB3ZTMtaW5iYW5kLWNjLW9mZnNl dCB1c2VzIGENCj4+ICJwc2V1ZG8gZmxvdyBoZWFkZXIiIGFmdGVyIHRoZSBQVyBsYWJlbC4gSXQg aXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgY29yZQ0KPj4gcm91dGVycyB3b3VsZCBFQ01QLWRpc3Ry aWJ1dGUgYmFzZWQgb24gc2FpZCAicHNldWRvIGZsb3cgaGVhZGVyIi4gSXQgaXMNCj4+IGFsc28g dGhlIGV4cGVjdGF0aW9uIHRoYXQgd2hlbiB0aGlzIGhhcHBlbnMsIHRoaXMgT0FNIHdvdWxkIGZh dGUtc2hhcmUNCj4+IHdpdGggYWN0dWFsIHVzZXIgdHJhZmZpYy4gRG9lcyB0aGlzIGltcGx5IHRo YXQgUFcgdHJhZmZpYyBuZWVkcyB0byBzdGFydA0KPj4gKGFmdGVyIHRoZSBQVyBMYWJlbCkgd2l0 aCB0aGUgc2FtZSB2YWx1ZXMgYXMgaW4gdGhlICJwc2V1ZG8gZmxvdw0KPj4gaGVhZGVyIiwgYW5k IHRodXMgdGhlIGZsb3cgaWRlbnRpZmllcnMgZm9yIHJlZ3VsYXIgdHJhZmZpYyBmb2xsb3cgdGhl IFBXDQo+PiBMYWJlbCBkaXJlY3RseT8NCj4+IA0KPiANCj4gVGhlIFBXIHBheWxvYWQgc3RheXMg ZXhhY3RseSB0aGUgd2F5IGl0IGRvZXMgYWNjb3JkaW5nIHRvIHRoZQ0KPiBhZGFwdGF0aW9uIGRl ZmluZWQgZm9yIHRoYXQgdHlwZSBvZiBQVy4gVGhpcyBkcmFmdCBkb2VzIG5vdCBkZWZpbmUgYW55 DQo+IG5ldyBhZGFwdGF0aW9uLCBzbyBpdCBoYXMgbm8gbmV3IGltcGxpY2F0aW9ucyBvbiB3aGVy ZSB0aGUgUFcgdHJhZmZpYw0KPiBuZWVkcyB0byBzdGFydC4gQWxsIGl0IGRlZmluZXMgaXMgYSB2 YXJpYW50IG9mIHRoZSBUVEwgZXhwaXJ5IFZDQ1YsDQo+IHdoZXJlIHRoZSBWQ0NWIG1lc3NhZ2Ug c3RhcnRzIGF0IGFuIG9mZnNldCBhZnRlciB0aGUgUFcgbGFiZWwuIFRoZQ0KPiBwYWNrZXQgZW5j b2RpbmcgKGFmdGVyIHRoZSBQVyBsYWJlbCkgdGlsbCB0aGUgb2Zmc2V0IGlzIGV4YWN0bHkgdGhl DQo+IHNhbWUgYXMgZm9yIGEgZGF0YSBwYWNrZXQgKGZvciB3aGljaCB0aGUgaW5iYW5kIE9BTSBu ZWVkcyB0byBiZQ0KPiBleGVjdXRlZCkuDQo+IA0KDQpZZXMsIGFuZCB0aGF0IGhlbHBzIGZvciBJ UCBQV3MsIHdoZXJlIGV4aXN0aW5nIG1ldGhvZHMgY2FuIHRlc3QgYWxsIHBhdGhzLiANCg0KVGhh bmtzLA0KDQpDYXJsb3MuIA0KDQo+Pj4gDQo+Pj4gQWxzbyBub3RlIHRoYXQgdGhpcyBtZWNoYW5p c20gaGFzIHNvbWUgc2ltaWxhcml0eSB0bw0KPj4+IGRyYWZ0LW5hZGVhdS1wd2UzLXZjY3YtMi4g VGhlIHByaW1hcnkgZGlmZmVyZW5jZSBiZWluZyB0aGF0IGluDQo+Pj4gZHJhZnQtbmFkZWF1IHRo ZSBHQUwgaXMgdXNlZCB0byBpZGVudGlmeSBhbiBPQU0gcGFja2V0IGluc3RlYWQgb2YgVFRMLA0K Pj4+IGhlbmNlIHRoZSBwcmVzZW5jZSBvZiBHQUwgaW4gdGhlIGhhc2ggY29tcHV0YXRpb24gaXMg YW4gaXNzdWUuDQo+Pj4gTW9yZW92ZXIgZHVlIHRvIHRoZSBvZmZzZXQsIHRoZSBpbmJhbmQtdmNj diBkcmFmdCDDgiBpcyBhbHNvIGluZGVwZW5kZW50DQo+Pj4gb2YgdGhlIHBrdCAoYW5kIG11bHRp LXBhdGggZGVjaXNpb24gYmFzZWQgb24gdGhhdCkgYmVpbmcgY2FycmllZCBiZWxvdw0KPj4+IHRo ZSBsYWJlbCBzdGFjay4NCj4+PiANCj4+Pj4+IFRoZSBtb3N0IGNvbW1vbiBoZXVyaXN0aWMgaXMg b2YgY291cnNlIGxvb2tpbmcgYXQgdGhlIGZpcnN0DQo+Pj4+PiBuaWJibGUgYmV5b25kIGxhYmVs IHN0YWNrIHRvIGRldGVybWluZSB0aGF0IGl0IGlzIGFuIElQIHBhY2tldC4gU28NCj4+Pj4+IHRo aXMgd291bGQgYWxzbyBhcHBseSBmb3IgYW4gSVAgUFcsIElQTFMsIGV0YyBpbiBhZGRpdGlvbiB0 bw0KPj4+Pj4gZHJhZnQta2luaS1wd2UzLXBrdC1lbmNhcC1lZmZpY2llbnQtaXAtbXBscy4NCj4+ Pj4gDQo+Pj4+IFJpZ2h0LiBJIHRoaW5rIGl0IHdvdWxkIGFwcGx5IHRvIGFuIElQIFBXLCB3aGVy ZSB0aGVyZSBhcmUgZXhpc3RpbmcgdGVjaG5pcXVlcyB0byB3YWxrIG11bHRpcGF0aHMuIEJ1dCBp dCB3b3VsZCBub3QgdG8gc2F5IGFuIEV0aGVybmV0IFBXICh3aXRob3V0IENXKTogZXZlbiBpZiB0 aGUgUEUgc2VlcyB0aGUgZmxvd3MgaW5zaWRlIHRoZSBFdGhlcm5ldCAoZS5nLiwgVENQIGZsb3dz IG92ZXIgSVAgb3ZlciBFdGhlcm5ldCksIHRoZSBpcyBubyBFQ01QIGluIHRoZSBjb3JlIGJhc2Vk IG9uIHRob3NlLg0KPj4+PiANCj4+PiANCj4+PiBJIHdvdWxkIGxpa2UgdG8gYmVsaWV2ZSB0aGF0 IHRvby4gQnV0IEkgaGF2ZSBoZWFyZCB0aGF0DQo+Pj4gaW1wbGVtZW50YXRpb25zIGRvIGRpZmZl cmVudCB0aGluZ3Mgd2l0aCBzb21lIHBhY2tldCBpbnNwZWN0aW9uLg0KPj4+IA0KPj4+Pj4gTFNQ LVBpbmcgdXNlcyB0aGUgMTI3DQo+Pj4+PiBhZGRyZXNzIGFuZCBpdCBpcyBub3QgZWFzeSB0byBj by1yZWxhdGUgdGhpcyB0byBhIHByb2JsZW0gcmVwb3J0ZWQgZm9yDQo+Pj4+PiByZWFsIChub24g MTI3KSBhZGRyZXNzZXMuDQo+Pj4+IA0KPj4+PiBJIHRoaW5rIExTUC1QaW5nIGNhbiBkbyBiZXR0 ZXI6IGlkZW50aWZ5IGFuZCB3YWxrIGFsbCBFQ01Qcy4NCj4+PiANCj4+PiBJZiB0aGUgRUNNUCBh bGdvcml0aG0gaXMgcHJvcHJpZXRhcnkgYW5kIGluZm8gYWJvdXQgdGhhdCBpcyBub3QNCj4+PiBh dmFpbGFibGUgdG8gdGhlIFBFLCB0aGVyZSB3aWxsIGJlIGlzc3Vlcy4NCj4+IA0KPj4gPGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQzNzkjc2VjdGlvbi0zLjM+IGRvZXMgbm90IG5lZWQg dG8ga25vdw0KPj4gdGhlIGludGVybmFscy4NCj4gDQo+IFllcywgdGhhdCBjYW4gYmUgdXNlZCB0 byBpZGVudGlmeSBMU1AgcGF0aHMsIGZpbmQgb3V0IHdoaWNoIElQDQo+IGFkZHJlc3NlcyAoMTI3 IHJhbmdlKSBtYXAgdG8gd2hpY2ggTFNQIG5leHRob3AgYW5kIHNvIG9uLiBCdXQgVkNDViBpcw0K PiBkZXRlcm1pbmluZyB0aGUgaGVhbHRoIG9mIHRoZSBQVyBhdCB0aGUgUFcgbGF5ZXIgdGhhdCBt YXkgaW5jbHVkZQ0KPiBtdWx0aXBsZSBMU1BzIChlc3BlY2lhbGx5IE1TLVBXKS4gV2hlbiB0aGUg UFcgY2FuIHRha2UgbXVsdGlwbGUgcGF0aHMNCj4gaXQgaXMgdXNlZnVsIHRvIHF1aWNrbHkgZGV0 ZXJtaW5lIGlmIGEgY2xpZW50IGZsb3cgdGhhdCBuZWVkcw0KPiB0cm91Ymxlc2hvb3RpbmcgaGFz IGEgcHJvYmxlbSBhbmQgd2hpY2ggc2VnbWVudCBvZiB0aGUgUFcgaGFzIHRoYXQNCj4gcHJvYmxl bS4gVGhhdCBtYXkgYmUgZm9sbG93ZWQgYnkgYSBMU1AgdHJhY2luZyBmb3IgdGhlIHNlZ21lbnQg b2YgdGhlDQo+IFBXIHRoYXQgaGFzIGEgcHJvYmxlbS4NCj4gDQo+PiANCj4+IFRoYW5rcywNCj4+ IA0KPj4gLS0gQ2FybG9zLg0KPj4gDQo+Pj4gDQo+Pj4+IEkgYWxzbyB0aGluayB0aGF0IHRoZSBh c3N1bXB0aW9uIG9mIGEgcHJvYmxlbSBiZWluZyByZXBvcnRlZCBvbiBhIGdpdmVuIGZsb3csIG9u bHkgZm9yIGFuIElQIFBXIFR5cGUgaXMgdG9vIGV4cGVuc2l2ZSBmb3IgdGhlIHJldHVybi4NCj4+ Pj4gDQo+Pj4+IFRoYW5rcywNCj4+Pj4gDQo+Pj4+IC0tIENhcmxvcy4NCj4+Pj4gDQo+Pj4+PiAN Cj4+Pj4+IFRoYW5rcw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9uIFRodSwgQXByIDIxLCAyMDEx IGF0IDk6NDggUE0sIENhcmxvcyBQaWduYXRhcm8gPGNwaWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6 DQo+Pj4+Pj4gSGkgU3JpZ2FuZXNoLA0KPj4+Pj4+IA0KPj4+Pj4+IERvIHlvdSBzZWUgdGhlIGFw cGxpY2FiaWxpdHkgb2YgZHJhZnQta2luaS1wd2UzLWluYmFuZC1jYy1vZmZzZXQNCj4+Pj4+PiBz dHJpY3RseSBsaW1pdGVkIHRvIHRoZSBlbmNhcHN1bGF0aW9uIHByb3Bvc2VkIGluDQo+Pj4+Pj4g ZHJhZnQta2luaS1wd2UzLXBrdC1lbmNhcC1lZmZpY2llbnQtaXAtbXBscz8NCj4+Pj4+PiANCj4+ Pj4+PiBTcGVjaWZpY2FsbHksIGZvciBhIFBXIHRoYXQgY2FycmllcyBzYXkgRXRoZXJuZXQgd2l0 aG91dCBDVyAob3IgYW55IG9mDQo+Pj4+Pj4gdGhlIG90aGVyIGVuY2FwIG1vZGVzIHdpdGggbm9u LW1hbmRhdG9yeSBDVyksIHRoZXJlIGlzIG5vICJmbG93IiB0aGF0IGlzDQo+Pj4+Pj4gYmVpbmcg RUNNUC1lZCBpbiB0aGUgY29yZSB0aGF0IHlvdSB3YW50IHRvIG1pbWljL2ltaXRhdGUgaW4gYQ0K Pj4+Pj4+IGxvYWQtYmFsYW5jaW5nIHBzZXVkby1oZWFkZXIuIENvbnZlcnNlbHksIGZvciAiSVAg UFdzIiwgTFNQLVBpbmcgY2FuDQo+Pj4+Pj4gdGFrZSBkaWZmZXJlbnQgRXF1YWwtY29zdCBwYXRo cyAoYWxsIG9mIHRoZW0sIG9uZSBieSBvbmUpIGJhc2VkIG9uDQo+Pj4+Pj4gY2hvb3NpbmcgdGhl IGRlc3RpbmF0aW9uIElQIGFkZHJlc3MuIEFuZCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGlzIHdo ZW4NCj4+Pj4+PiB0aGVyZSBpcyBhIENXLg0KPj4+Pj4+IA0KPj4+Pj4+IEkgYW0gdHJ5aW5nIHRv IHVuZGVyc3RhbmQgaG93IGNvbW1vbiBpcyB0aGUgdXNlIGNhc2UgZm9yIHdoYXQgdGhpcw0KPj4+ Pj4+IG9wdGltaXplcyBmb3IuDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+IA0KPj4+ Pj4+IC0tIENhcmxvcy4NCj4+Pj4+PiANCj4+Pj4+PiBPbiAzLzMxLzIwMTEgNDowOCBBTSwgU3Jp Z2FuZXNoIEtpbmkgd3JvdGU6DQo+Pj4+Pj4+IEFsbCwNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEp1c3Qg YW4gRllJIHRoYXQgYSBwcm9wb3NhbCBmb3IgZmF0ZS1zaGFyaW5nIFBXIE9BTSBhbmQgZGF0YSBn aXZlbiBpbg0KPj4+Pj4+PiBkcmFmdC1raW5pLXB3ZTMtaW5iYW5kLWNjLW9mZnNldA0KPj4+Pj4+ PiANCj4+Pj4+Pj4gSnVzdCB0byBzdW1tYXJpemUgdGhlIHByb3Bvc2FsLg0KPj4+Pj4+PiAxLiBJ dCBkb2VzIG5vdCByZXF1aXJlIEdBTCBpbiBQVy4gVFRMIGV4cGlyeSBpcyB1c2VkIHRvIGFsZXJ0 IHRoZSBTL1QtUEUuDQo+Pj4+Pj4+IDIuIEl0IGlzIG1haW5seSBhcHBsaWNhYmxlIHdoZW4gQ1cg aXMgbm90IHVzZWQgaW4gdGhlIFBXLg0KPj4+Pj4+PiAzLiBJdCB1c2VzIGEgZml4ZWQgb2Zmc2V0 IChuZWdvdGlhdGVkIGJldHdlZW4gUFcgZW5kcG9pbnRzKSBhZnRlciB0aGUNCj4+Pj4+Pj4gbGFi ZWwgc3RhY2sgYmVmb3JlIHN0YXJ0aW5nIHRoZSBPQU0gbXNnLg0KPj4+Pj4+PiA0LiBUaGUgYnl0 ZXMgYmV0d2VlbiB0aGUgbGFiZWwtc3RhY2sgYW5kIHRoZSBmaXhlZCBvZmZzZXQgaXMgcmVmZXJy ZWQNCj4+Pj4+Pj4gdG8gYXMgYSBwc2V1ZG9mbG93IGhlYWRlciBhbmQgaXMgZmlsbGVkIHdpdGgg Ynl0ZS12YWx1ZXMgKGJ5IHRoZSBQRSkNCj4+Pj4+Pj4gdGhhdCByZXByZXNlbnQgdGhlIGZsb3cg Zm9yIHdoaWNoIE9BTSBpcyBkZXNpcmVkLiBUaGlzIGhlbHBzIFBXIE9BTQ0KPj4+Pj4+PiBhbmQg ZGF0YSB0byBmYXRlLXNoYXJlIGV2ZW4gd2hlbiB0aGUgaW50ZXJtZWRpYXRlIG5vZGUgbG9va3Mg YmV5b25kDQo+Pj4+Pj4+IGxhYmVsIHN0YWNrIHRvIGRvIG11bHRpcGF0aCBmb3J3YXJkaW5nIGRl Y2lzaW9ucy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBPbiBUaHUsIE1hciAzMSwgMjAx MSBhdCAxMjowMyBBTSwgQ3VydGlzIFZpbGxhbWl6YXIgPGN1cnRpc0BvY2NuYy5jb20+IHdyb3Rl Og0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBMb2EsIERhdmUsIFNhc2hhLA0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiBJJ3ZlIHNuaXBwZWQgZnJvbSB2YXJpb3VzIHBvc3RzIG9uIHRoZSB0aHJlYWQgdGhhdCBT YXNoYSBzdGFydGVkLiDDg+KAmiBTZWUNCj4+Pj4+Pj4+IGlubGluZS4NCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gSW4gbWVzc2FnZSA8NEQ5MkY1RDMuNjA4MDYwOUBwaS5udT4NCj4+Pj4+Pj4+IExvYSBB bmRlcnNzb24gd3JpdGVzOg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEFsbCwNCj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+PiBtaXNzZWQgYSBudWFuY2UgaW4gU2FzaGEgc3ViamVjdCBsaW5lLg0KPj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+IFdlIGhhdmUgdHdvIGlzc3Vlcw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ IC0gd2hlcmUgdGhlIEdBTCBpcyBwbGFjZWQgcmVsYXRpdmUgdG8gdGhlIFBXIGxhYmVsLCBJIMOD 4oCaIGJlbGlldmUgaXQgaXMNCj4+Pj4+Pj4+PiDDg+KAmiDDgiDDg+KAmiBuZWNlc3NhcnkgdG8g aGF2ZSB0aGUgR0FMIGJlbG93IHRoZSBQVyBsYWJlbC4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiAt IHdoZXRoZXIgdGhlIHRoZSBHQUwgbGFiZWwgbmVlZHMgdG8gYmUgYm90dG9tIG9mIHN0YWNrIG9y IG5vdCwgaXQNCj4+Pj4+Pj4+PiDDg+KAmiDDgiDDg+KAmiBmaWd1cmUgdGhhdCB0aGlzIGlzIHJl YWxseSBhIGRpc2N1c3Npb24gaWYgaXQgaXMgcG9zc2libGUgdG8gaGF2ZQ0KPj4+Pj4+Pj4+IMOD 4oCaIMOCIMOD4oCaIGEgRkFUIGxhYmVsIGJlbG93IHRoZSBHQUwgb3Igbm90LiBJJ20gbm90IHN1 cmUgw4PigJogYWJvdXQgbXkgcHJlZmVyZW5jZXMNCj4+Pj4+Pj4+PiDDg+KAmiDDgiDDg+KAmiBi dXQgSSB0aGluayBpdCBpcyBwb3NzaWJsZS4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiAvTG9hDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+IEkgYWdyZWUgd2l0aCBMb2EncyBzdW1tYXJ5LiDDg+KAmiBOb3Qg cHV0dGluZyBHQUwgYXQgdGhlIGJvdHRvbSBtYXkgY29uZnVzZQ0KPj4+Pj4+Pj4gc29tZSBMU1Is IGJ1dCBwdXR0aW5nIGl0IGFib3ZlIHRoZSBQVyBsYWJlbCBpcyBsaWtlbHkgdG8gYmUgZXZlbiBt b3JlDQo+Pj4+Pj4+PiBwcm9ibGVtYXRpYy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBJbiBtZXNzYWdlIDw2MEMwOTNBNDFCNUU0NTQwOUExOUQ0MkNGNzc4NkRGRDUxRDUzMTBCNTNA RVVTQUFDTVMwNzAzLmVhbWNzLmVyaWNzc29uLnNlPg0KPj4+Pj4+Pj4gRGF2aWQgQWxsYW4gSSB3 cml0ZXM6DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gSXQgZG9lcyBiZWNvbWUgYSBuZXcgYmVoYXZp b3IsIEdBTCB3aXRoIFM9M0QwLiBIb3dldmVyIHRoZSBjb21iaW5hdGlvbiBvZiBHPQ0KPj4+Pj4+ Pj4+IEFMIGJlaW5nIHRvcCBsYWJlbCBhdCB0aGUgUy1QRSBhbmQgVFRMIGJlaW5nIGVuY29kZWQg aW4gdGhlIFBXIGxhYmVsIG1lYW5zID0NCj4+Pj4+Pj4+PiB0aGF0IGZhdGUgc2hhcmluZyBpcyBi cm9rZW4gYXQgZXZlcnkgUy1QRS4gTGlmZSBvbmx5IGdldHMgYSBsaXR0bGUgbW9yZSBzdHI9DQo+ Pj4+Pj4+Pj4gYW5nZSBpZiB0aGVyZSBpcyBhIEZBVCBsYWJlbCBhcyB3ZWxsLi4uDQo+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gVGhhdCBiZWluZyBzYWlkLCBHQUwgYXMgYm90dG9tIGxhYmVsIGlzIGJy b2tlbiBpbiBhbnkgRUNNUCBlbnZpcm9ubWVudCwgd2hpPQ0KPj4+Pj4+Pj4+IGNoIGlzIHdoeSBH QUwgaXMgYSBUUCBjb25zdHJ1Y3QuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gbXkgMiBjZW50cw0K Pj4+Pj4+Pj4+IEQNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gRGF2ZSwNCj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4gSWYgR0FMIGlzIGJyb2tlbiBmb3IgRUNNUCwgd2hpY2ggaXQgaXMsIHRoZW4gYWxsIFRQIE9B TSBpcyBicm9rZW4uDQo+Pj4+Pj4+PiBJZiBhbGwgaXQgdGFrZXMgdG8gZml4IGl0IGlzIHNpbXBs ZSB0aGVuIGxldHMganVzdCBmaXggaXQuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRoaXMgaXMgd2hh dCB3ZSdkIGhhdmUgdG8gZG8uDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IMOD4oCaIDEpIFJlbGF4IHRo ZSByZXF1aXJlbWVudCB0aGF0IEdBTCBiZSBhdCB0aGUgYm90dG9tDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IMOD4oCaIDIpIEhhdmUgdGhlIGluZ3Jlc3MgaW5zZXJ0IEdBTCBpbiB0aGUgc3RhY2sgaW1t ZWRpYXRlbHkgYmVsb3cgdGhlDQo+Pj4+Pj4+PiDDg+KAmiDDgiDDg+KAmiDDgiBsYWJlbCBmb3Ig d2hpY2ggdGhlIG1lYXN1cmVtZW50IGlzIG1hZGUsIGtlZXBpbmcgdGhlIHJlc3Qgb2YgdGhlDQo+ Pj4+Pj4+PiDDg+KAmiDDgiDDg+KAmiDDgiBsYWJlbCBzdGFjayBpbiBwbGFjZS4NCj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4gVGhlIG9ubHkgdGhpbmcgdGhlIG1pZHBvaW5nIExTUiBhdCBhIG11bHRpcGF0 aCAoTEFHLCBsaW5rIGJ1bmRsZSBmb3INCj4+Pj4+Pj4+IE1QTFMpIGhhcyB0byBkbyBpcyBza2lw IG92ZXIgdGhlIEdBTCB3aGVuIGhhc2hpbmcsIGFzIGlmIHRoZSBHQUwNCj4+Pj4+Pj4+IHdhc24n dCB0aGVyZS4gw4PigJogVGhhdCB3aWxsIHlpZWxkIHRoZSBzYW1lIGhhc2ggdmFsdWUgYW5kIGl0 IHdpbGwNCj4+Pj4+Pj4+IHByZXNlcnZlIGZhdGUtc2hhcmluZyBhY3Jvc3MgbXVsdGlwYXRoLg0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJIHByZWZlciB0aGF0IHdlIGZpeCB0aGluZ3MgcmF0aGVyIHRo YW4gY29tcGxhaW4gdGhhdCB0aGV5IGFyZSBicm9rZW4uDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEN1 cnRpcw0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+Pj4+IHB3ZTMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBwd2UzQGlldGYub3Jn DQo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMNCj4+ Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gcHdlMyBtYWlsaW5n IGxpc3QNCj4+Pj4+PiBwd2UzQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wd2UzDQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiAtLQ0KPj4+Pj4gLSBTcmkNCj4+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBwd2UzIG1haWxpbmcgbGlzdA0KPj4+PiBw d2UzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cHdlMw0KPj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBwd2UzIG1haWxpbmcgbGlzdA0KPj4gcHdlM0Bp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQo+ PiANCj4gDQo+IA0KPiANCj4gLS0gDQo+IC0gU3JpDQo+IA0K From lizhong.jin@zte.com.cn Mon Apr 25 22:43:37 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AA0E06F5; Mon, 25 Apr 2011 22:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q1w7KQd8+J7; Mon, 25 Apr 2011 22:43:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 20339E067C; Mon, 25 Apr 2011 22:43:35 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 125202203882679; Tue, 26 Apr 2011 13:42:23 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 4886.2203882679; Tue, 26 Apr 2011 13:43:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3Q5hMUa059145; Tue, 26 Apr 2011 13:43:22 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-25 20:13:22, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-25 20:13:22, Serialize complete at 2011-04-25 20:13:22, S/MIME Sign failed at 2011-04-25 20:13:22: The cryptographic key was not found, S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-26 13:43:27, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-26 13:43:27, Serialize complete at 2011-04-26 13:43:27, S/MIME Sign failed at 2011-04-26 13:43:27: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-26 13:43:23, Serialize complete at 2011-04-26 13:43:23 To: pwe3@ietf.org Sensitivity: X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Tue, 26 Apr 2011 13:43:23 +0800 Content-Type: multipart/alternative; boundary="=_alternative 001F71CD4825787E_=" X-MAIL: mse01.zte.com.cn p3Q5hMUa059145 Cc: mpls@ietf.org Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-cbit-negotiation-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:43:37 -0000 This is a multipart message in MIME format. --=_alternative 001F71CD4825787E_= Content-Type: text/plain; charset="US-ASCII" Hi all, This draft is to collect all possible solutions to reach a most optimized one. In this 00 version of the draft, we got an alternative option at appendixB, and give a brief comparison between the two options. For better backward compatibility, we still keep the "label request message" option. If you have any preference or comments about the two options, please tell us. Also cc to MPLS WG, to ask for comments about the FEC128/129 update in current draft. There are many parameters in FEC128/129 which is not like prefix-FEC. In this draft, if a PE receives a label mapping with same FEC parameter and label, but only different Cbit value than previously received, then PE will update this FEC with new Cbit value. Thanks Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Apr 2011 10:45:02 -0700 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-cbit-negotiation-00.txt > Message-ID: <20110415174502.28931.24336.idtracker@ietfc.amsl.com> > Content-Type: text/plain; charset="us-ascii" > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Pseudowire Emulation Edge to Edge > Working Group of the IETF. > > Title : Pseudowire Control Word Negotiation Mechanism Update > > Author(s) : V. Manral, et al > Filename : draft-ietf-pwe3-cbit-negotiation-00.txt > Pages : 10 > Date : 2011-04-15 > > This document describes the problem of control word negotiation > mechanism specified in [RFC4447]. Based on the problem analysis, a > message exchanging mechanism is introduced to solve this control word > negotiation issue. This document is to update [RFC4447] control word > negotiation mechanism. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cbit-negotiation-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001F71CD4825787E_= Content-Type: text/html; charset="US-ASCII"
Hi all,
This draft is to collect all possible solutions to reach a most optimized one. In this 00 version of the draft, we got an alternative option at appendixB, and give a brief comparison between the two options. For better backward compatibility, we still keep the "label request message" option. If you have any preference or comments about the two options, please tell us.

Also cc to MPLS WG, to ask for comments about the FEC128/129 update in current draft. There are many parameters in FEC128/129 which is not like prefix-FEC. In this draft, if a PE receives a label mapping with same FEC parameter and label, but only different Cbit value than previously received, then PE will update this FEC with new Cbit value.

Thanks
Lizhong


>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 15 Apr 2011 10:45:02 -0700
> From: Internet-Drafts@ietf.org
> To: i-d-announce@ietf.org
> Cc: pwe3@ietf.org
> Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-cbit-negotiation-00.txt
> Message-ID: <20110415174502.28931.24336.idtracker@ietfc.amsl.com>
> Content-Type: text/plain; charset="us-ascii"
>
> A new Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Pseudowire Emulation Edge to Edge
> Working Group of the IETF.
>
>     Title         : Pseudowire Control Word Negotiation Mechanism Update
>
>     Author(s)     : V. Manral, et al
>     Filename      : draft-ietf-pwe3-cbit-negotiation-00.txt
>     Pages         : 10
>     Date          : 2011-04-15
>    
>    This document describes the problem of control word negotiation
>    mechanism specified in [RFC4447].  Based on the problem analysis, a
>    message exchanging mechanism is introduced to solve this control word
>    negotiation issue.  This document is to update [RFC4447] control word
>    negotiation mechanism.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cbit-negotiation-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 001F71CD4825787E_=-- From sriganeshkini@gmail.com Tue Apr 26 18:09:37 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3038E0770 for ; Tue, 26 Apr 2011 18:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlWMOZDKFyyX for ; Tue, 26 Apr 2011 18:09:36 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C70EE077D for ; Tue, 26 Apr 2011 18:09:35 -0700 (PDT) Received: by qwc23 with SMTP id 23so717464qwc.31 for ; Tue, 26 Apr 2011 18:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=h3g0fVuaqmcgfNibw7I9nNHnyt14MCu/b+mp/+6Iwj8=; b=eDmtbnMEyQhGlsd3k57MJsR7vR3n3CDXeT9Ycs3dpAtAWvQ5iQjGHM4LKttZUlFwsV eLrjPS7gChb57eEF5YOfAVtRDjN1d/Kkd8ChQJtEqxdg+ApLeLCeklr8CoMegDUtaA6a VtsdnGoMbM4twfTQTbKPWF/B6nBaNabZby004= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Zy7iePb+p3r02I0BsewcTtmbUArEvyK7LzW1PoE9hD/yA6ij6bttr/oI54v0RAIHnZ S00/6mPuPkWiEVcKsgRI1kEZbV4R/JllppMlLvYt+JV8IZSkNDZPWstUj006R15nQaNP dae0AIbDyo10bjp8+en3dWgaV2Q/AqVGkA0E8= Received: by 10.229.212.193 with SMTP id gt1mr1071636qcb.231.1303866575242; Tue, 26 Apr 2011 18:09:35 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.94.143 with HTTP; Tue, 26 Apr 2011 18:09:04 -0700 (PDT) In-Reply-To: References: <4D92F5D3.6080609@pi.nu> <201103310703.p2V73Hrx045107@harbor.orleans.occnc.com> <4DB108AD.2040809@cisco.com> <164FBBE6-5814-4C12-8CC1-C1A4D22D7BE6@cisco.com> <4DB5C9F6.60402@cisco.com> From: Sriganesh Kini Date: Tue, 26 Apr 2011 18:09:04 -0700 X-Google-Sender-Auth: uM65h0iExmUt3N_FOvEFFU_VPC0 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 01:09:38 -0000 Hi Carlos, Pls see inline On Mon, Apr 25, 2011 at 6:07 PM, Carlos Pignataro (cpignata) wrote: > Sriganesh, > > Please see inline. > > Carlos P. > > On Apr 25, 2011, at 7:29 PM, "Sriganesh Kini" wrote: > >> Hi Carlos, >> >> Pls see inline. >> >> On Mon, Apr 25, 2011 at 12:22 PM, Carlos Pignataro = wrote: >>> Hi Sriganesh, >>> >>> Please see inline. >>> >>> On 4/25/2011 2:56 PM, Sriganesh Kini wrote: >>>> Hi Carlos, >>>> >>>> Pls see inline. >>>> >>>> On Fri, Apr 22, 2011 at 6:23 PM, Carlos Pignataro (cpignata) >>>> wrote: >>>>> Hi Sriganesh, >>>>> >>>>> Thanks for the quick response and low RTT, please find some follow-up= s inline. >>>>> >>>>> Carlos P. >>>>> >>>>> On Apr 22, 2011, at 2:20 PM, "Sriganesh Kini" wrote: >>>>> >>>>>> Hi Carlos, >>>>>> >>>>>> The applicability of draft-kini-pwe3-inband-cc-offset is when CW is >>>>>> not present, but the intermediate LSR looks beyond the PW label to d= o >>>>>> multipath decisions. The draft is independent of any (even proprieta= ry >>>>>> logic) for multipath decision taken by intermediate nodes looking >>>>>> beyond PW label and also independent of any heuristic the intermedia= te >>>>>> routers may use to guess the packet type (beyond label stack) being >>>>>> carried. >>>>> >>>>> I think that this statement is a bit too optimistic and too generaliz= ed. It seems to me that, in addition, the PE needs to understand the flows = carried inside the PW, have some clue as to the type of ECMP in the core, a= nd there should have correlation between these two. This dramatically limit= ed the applicability as you say below: >>>>> >>>> >>>> Correct that the PE needs to know the flow that the operator is trying >>>> to troubleshoot ! However the PE does not need to know the type of >>>> ECMP that is implemented in the core (P router). That algorithm would >>>> be typically proprietary. Not sure if you are saying that the PE >>>> should know the co-relation between the flow and the ECMP-type before >>>> the problem occurs. The draft is not a multi-path algorithm discovery >>>> mechanism. That is an important problem, but due to the proprietary >>>> nature of those algorithms a solution has limitations. The draft >>>> provides a PE a mechanism to troubleshoot a flow without having >>>> precise knowledge a-priori of how the multi-path algorithm is behaving >>>> for a specific flow. >>> >>> Apologies as I was not clear. I did not mean that the PE would need to >>> know the ECMP algorithm. I meant to say that the PE would need to know >>> what the ECMP algorithm is expecting and what fields are relevant for >>> the ECMP algorithm. This was a round-about way of saying that, assuming >>> that ECMP algorithms hash on certain fields of an IP+Transport/ULP >>> header after an MPLS header, then this I-D is applicable for an IP PW. >> >> Maybe we are saying the same thing here but let me try. I think we >> both agree that ECMP algorithms at a P router typically look into the >> packet hdr to do multipath decisions. The caveat being that they may >> use a heuristic to guess the packet type (due to incomplete >> information). As long as they do not send a flow along multiple paths >> everything is ok. >> >> Consider a network with P routers P1, P2, P3, .... Say that different >> P routers have different ECMP algorithms - So P1 hashes only on the >> label stack, P2 looks at the first nibble beyond label stack and if it >> is IPv4/v6, hashes on IP src/dest. P3 does the same as P2 except that >> it looks further and hashes on protocol type and certain TCP/UDP hdrs >> params. >> >> PE1 does not know the details of the P routers algorithms or which >> parts of the header they look into. Say the PE wants to troubleshoot a >> TCP session between a pair of IP addresses. The packet that is used >> for VCCV purposes would look the same as a normal data packet for that >> TCP session with the exception that the TTL would be as specified for >> TTL Expiry VCCV type-3 and that beyond the pseudo-flow header, that >> actual VCCV message would be present instead of the data packet. > > No, this is the key. VCCV exists in the context of a PW, which is more ge= neric than IP directly over MPLS. So there is, potentially, no TCP session = from CEs would influence ECMP for an Ethernet PW, which is the need for Fat= -PW to summarize the flow in something meaningful in the core. I agree with your observation. However IP over MPLS has wide deployment (even if we leave out the case of the pkt PW in the efficient-ip-mpls encap draft). FAT-PW requires hardware to identify flows and in many cases it is not available or deployed, whereas ECMP based on looking for IP beyond MPLS is deployed widely. > >> For >> the P routers, this VCCV message looks the same as a data packet since >> it is just looking at the header to do multipath decisions and the >> data and VCCV message would take the same path through the P routers. >> >> In the case where the packet coming from the client has a MPLS label >> stack and that label stack is sent as a single label stack (i.e. PW >> label stack + client label stack), then again the client label stack >> would be part of the flow header (Note that PW label or the optional >> FAT-PW label will have S=3D0 in this case). >> >>> Conversely, for an Ethernet PW, I do not see how you can do what the I-= D >>> claims: >>> >>> =C2 This document >>> =C2 =A0defines a simple extension to the TTL expiry CC (Type 3) to do i= nband >>> =C2 =A0VCCV. This can be used even without a CW. >>> >>> since a(n IP) flow (as received from a PE) is after an Ethernet header, >>> but there is no ECMP based on these flows (since the core routers do no= t >>> know what the PW is carrying). >>> >>> My point was that unless some flow identifier from the client >>> perspective is what is used for ECMP (which is not the case if there is >>> some L2 or MPLS between IP and the transport), then this technique >>> cannot be used. >> >> If any field from the client packet is not used by the transit LSR for >> ECMP then TTL Expiry VCCV type 3 is always inband. So in that sense I >> agree. One of the problems we have with VCCV is that multiple types >> have been deployed (some of which are inband) and also that CW has >> been used in some PW deployments and not others. This draft is >> addressing cases where CW is not used and intermediate LSRs look >> beyond the PW labels (including FAT-PW) into the packet to do >> multipath decisions. This could be an IP packet immediately following >> label stack, any client labels that form a single label stack with the >> PW labels, or (as a stretch) even a P router heuristic such as - a >> nibble beyond label stack that indicates a non IPv4/6 packet is an >> ethernet header. I am not advocating such an approach, just making a >> point that this draft provides a solution that is agnostic of such >> behavior. > > My comment is that I am not convinced of the latter, not even as a stretc= h. That's why I was asking about applicability. > >> >>> >>>> >>>> Regarding applicability, consider an encapsulation that has a single >>>> label stack in the core consisting of the adaptation label stack (PW >>>> in this case) and the label stack of a MPLS packet received from the >>>> client CE. This kind of encapsulation is in >>>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls when CW is not used. I >>>> believe a similar encap is used in the network layer adaptation sec >>>> 3.4.5 RFC 5921 for a client layer that is MPLS enabled. In such a case >>>> too it is possible to troubleshoot a flow (that includes the client >>>> labels and the packet being carried below) of the combined label >>>> stack. >>> >>> I do not see how this applies other than for IP PWs. Let me try to ask = a >>> different way: The proposal in draft-kini-pwe3-inband-cc-offset uses a >>> "pseudo flow header" after the PW label. It is the expectation that cor= e >>> routers would ECMP-distribute based on said "pseudo flow header". It is >>> also the expectation that when this happens, this OAM would fate-share >>> with actual user traffic. Does this imply that PW traffic needs to star= t >>> (after the PW Label) with the same values as in the "pseudo flow >>> header", and thus the flow identifiers for regular traffic follow the P= W >>> Label directly? >>> >> >> The PW payload stays exactly the way it does according to the >> adaptation defined for that type of PW. This draft does not define any >> new adaptation, so it has no new implications on where the PW traffic >> needs to start. All it defines is a variant of the TTL expiry VCCV, >> where the VCCV message starts at an offset after the PW label. The >> packet encoding (after the PW label) till the offset is exactly the >> same as for a data packet (for which the inband OAM needs to be >> executed). >> > > Yes, and that helps for IP PWs, where existing methods can test all paths= . I may have missed the point you made about how this applies to MS-PW. Are you recommending that LSP trace be used on a segment by segment basis ? IMO it is useful to have a mechanism at the PW level that gives a quick answer on whether a flow on the PW has an issue. > > Thanks, > > Carlos. > >>>> >>>> Also note that this mechanism has some similarity to >>>> draft-nadeau-pwe3-vccv-2. The primary difference being that in >>>> draft-nadeau the GAL is used to identify an OAM packet instead of TTL, >>>> hence the presence of GAL in the hash computation is an issue. >>>> Moreover due to the offset, the inband-vccv draft =C2 is also independ= ent >>>> of the pkt (and multi-path decision based on that) being carried below >>>> the label stack. >>>> >>>>>> The most common heuristic is of course looking at the first >>>>>> nibble beyond label stack to determine that it is an IP packet. So >>>>>> this would also apply for an IP PW, IPLS, etc in addition to >>>>>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls. >>>>> >>>>> Right. I think it would apply to an IP PW, where there are existing t= echniques to walk multipaths. But it would not to say an Ethernet PW (witho= ut CW): even if the PE sees the flows inside the Ethernet (e.g., TCP flows = over IP over Ethernet), the is no ECMP in the core based on those. >>>>> >>>> >>>> I would like to believe that too. But I have heard that >>>> implementations do different things with some packet inspection. >>>> >>>>>> LSP-Ping uses the 127 >>>>>> address and it is not easy to co-relate this to a problem reported f= or >>>>>> real (non 127) addresses. >>>>> >>>>> I think LSP-Ping can do better: identify and walk all ECMPs. >>>> >>>> If the ECMP algorithm is proprietary and info about that is not >>>> available to the PE, there will be issues. >>> >>> does not need to know >>> the internals. >> >> Yes, that can be used to identify LSP paths, find out which IP >> addresses (127 range) map to which LSP nexthop and so on. But VCCV is >> determining the health of the PW at the PW layer that may include >> multiple LSPs (especially MS-PW). When the PW can take multiple paths >> it is useful to quickly determine if a client flow that needs >> troubleshooting has a problem and which segment of the PW has that >> problem. That may be followed by a LSP tracing for the segment of the >> PW that has a problem. >> >>> >>> Thanks, >>> >>> -- Carlos. >>> >>>> >>>>> I also think that the assumption of a problem being reported on a giv= en flow, only for an IP PW Type is too expensive for the return. >>>>> >>>>> Thanks, >>>>> >>>>> -- Carlos. >>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> On Thu, Apr 21, 2011 at 9:48 PM, Carlos Pignataro wrote: >>>>>>> Hi Sriganesh, >>>>>>> >>>>>>> Do you see the applicability of draft-kini-pwe3-inband-cc-offset >>>>>>> strictly limited to the encapsulation proposed in >>>>>>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls? >>>>>>> >>>>>>> Specifically, for a PW that carries say Ethernet without CW (or any= of >>>>>>> the other encap modes with non-mandatory CW), there is no "flow" th= at is >>>>>>> being ECMP-ed in the core that you want to mimic/imitate in a >>>>>>> load-balancing pseudo-header. Conversely, for "IP PWs", LSP-Ping ca= n >>>>>>> take different Equal-cost paths (all of them, one by one) based on >>>>>>> choosing the destination IP address. And there is no need for this = when >>>>>>> there is a CW. >>>>>>> >>>>>>> I am trying to understand how common is the use case for what this >>>>>>> optimizes for. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -- Carlos. >>>>>>> >>>>>>> On 3/31/2011 4:08 AM, Sriganesh Kini wrote: >>>>>>>> All, >>>>>>>> >>>>>>>> Just an FYI that a proposal for fate-sharing PW OAM and data given= in >>>>>>>> draft-kini-pwe3-inband-cc-offset >>>>>>>> >>>>>>>> Just to summarize the proposal. >>>>>>>> 1. It does not require GAL in PW. TTL expiry is used to alert the = S/T-PE. >>>>>>>> 2. It is mainly applicable when CW is not used in the PW. >>>>>>>> 3. It uses a fixed offset (negotiated between PW endpoints) after = the >>>>>>>> label stack before starting the OAM msg. >>>>>>>> 4. The bytes between the label-stack and the fixed offset is refer= red >>>>>>>> to as a pseudoflow header and is filled with byte-values (by the P= E) >>>>>>>> that represent the flow for which OAM is desired. This helps PW OA= M >>>>>>>> and data to fate-share even when the intermediate node looks beyon= d >>>>>>>> label stack to do multipath forwarding decisions. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 31, 2011 at 12:03 AM, Curtis Villamizar wrote: >>>>>>>>> >>>>>>>>> Loa, Dave, Sasha, >>>>>>>>> >>>>>>>>> I've snipped from various posts on the thread that Sasha started.= =C3=82 See >>>>>>>>> inline. >>>>>>>>> >>>>>>>>> In message <4D92F5D3.6080609@pi.nu> >>>>>>>>> Loa Andersson writes: >>>>>>>>>> >>>>>>>>>> All, >>>>>>>>>> >>>>>>>>>> missed a nuance in Sasha subject line. >>>>>>>>>> >>>>>>>>>> We have two issues >>>>>>>>>> >>>>>>>>>> - where the GAL is placed relative to the PW label, I =C3=82 bel= ieve it is >>>>>>>>>> =C3=82 =C2 =C3=82 necessary to have the GAL below the PW label. >>>>>>>>>> >>>>>>>>>> - whether the the GAL label needs to be bottom of stack or not, = it >>>>>>>>>> =C3=82 =C2 =C3=82 figure that this is really a discussion if it = is possible to have >>>>>>>>>> =C3=82 =C2 =C3=82 a FAT label below the GAL or not. I'm not sure= =C3=82 about my preferences >>>>>>>>>> =C3=82 =C2 =C3=82 but I think it is possible. >>>>>>>>>> >>>>>>>>>> /Loa >>>>>>>>> >>>>>>>>> I agree with Loa's summary. =C3=82 Not putting GAL at the bottom = may confuse >>>>>>>>> some LSR, but putting it above the PW label is likely to be even = more >>>>>>>>> problematic. >>>>>>>>> >>>>>>>>> >>>>>>>>> In message <60C093A41B5E45409A19D42CF7786DFD51D5310B53@EUSAACMS07= 03.eamcs.ericsson.se> >>>>>>>>> David Allan I writes: >>>>>>>>>> >>>>>>>>>> It does become a new behavior, GAL with S=3D3D0. However the com= bination of G=3D >>>>>>>>>> AL being top label at the S-PE and TTL being encoded in the PW l= abel means =3D >>>>>>>>>> that fate sharing is broken at every S-PE. Life only gets a litt= le more str=3D >>>>>>>>>> ange if there is a FAT label as well... >>>>>>>>>> >>>>>>>>>> That being said, GAL as bottom label is broken in any ECMP envir= onment, whi=3D >>>>>>>>>> ch is why GAL is a TP construct. >>>>>>>>>> >>>>>>>>>> my 2 cents >>>>>>>>>> D >>>>>>>>> >>>>>>>>> Dave, >>>>>>>>> >>>>>>>>> If GAL is broken for ECMP, which it is, then all TP OAM is broken= . >>>>>>>>> If all it takes to fix it is simple then lets just fix it. >>>>>>>>> >>>>>>>>> This is what we'd have to do. >>>>>>>>> >>>>>>>>> =C3=82 1) Relax the requirement that GAL be at the bottom >>>>>>>>> >>>>>>>>> =C3=82 2) Have the ingress insert GAL in the stack immediately be= low the >>>>>>>>> =C3=82 =C2 =C3=82 =C2 label for which the measurement is made, ke= eping the rest of the >>>>>>>>> =C3=82 =C2 =C3=82 =C2 label stack in place. >>>>>>>>> >>>>>>>>> The only thing the midpoing LSR at a multipath (LAG, link bundle = for >>>>>>>>> MPLS) has to do is skip over the GAL when hashing, as if the GAL >>>>>>>>> wasn't there. =C3=82 That will yield the same hash value and it w= ill >>>>>>>>> preserve fate-sharing across multipath. >>>>>>>>> >>>>>>>>> I prefer that we fix things rather than complain that they are br= oken. >>>>>>>>> >>>>>>>>> Curtis >>>>>>>>> _______________________________________________ >>>>>>>>> pwe3 mailing list >>>>>>>>> pwe3@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> pwe3 mailing list >>>>>>> pwe3@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> - Sri >>>>>> >>>>> _______________________________________________ >>>>> pwe3 mailing list >>>>> pwe3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pwe3 >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >> >> >> >> -- >> - Sri >> > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --=20 - Sri From cpignata@cisco.com Tue Apr 26 19:34:33 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9130E067B for ; Tue, 26 Apr 2011 19:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.532 X-Spam-Level: X-Spam-Status: No, score=-108.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0J9APjv6dDg for ; Tue, 26 Apr 2011 19:34:32 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 29BCFE062A for ; Tue, 26 Apr 2011 19:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=25700; q=dns/txt; s=iport; t=1303871672; x=1305081272; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=oI406z0UfkqF3gZOIaZMYCLGTnCyL0geTe/RKDrIFKM=; b=dVefxKUinF/PF+jWWFQSQVKANhbvvWsQ73dTP8exQP6MMI0VYKPZArwQ fbGipF8TNktbrtOO6R1DKUyCmEcgdbNIBF0T1yQqpObpH0xMxtX6aD8+C v3iYqXUntIYTKA67jZeUQEWulWlAybJleo1ewaHuQnCtXDF1a2QNu/t4F c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAM9/t02tJV2b/2dsb2JhbACEU6AuZwJ3iHCgEYtgkRKBKYFWgXp9BI5IhBiGJIQI X-IronPort-AV: E=Sophos;i="4.64,272,1301875200"; d="scan'208";a="345142253" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2011 02:34:31 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3R2YV8B012755; Wed, 27 Apr 2011 02:34:31 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 21:34:30 -0500 Received: from 128.107.191.87 ([128.107.191.87]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Apr 2011 02:34:31 +0000 References: <4D92F5D3.6080609@pi.nu> <201103310703.p2V73Hrx045107@harbor.orleans.occnc.com> <4DB108AD.2040809@cisco.com> <164FBBE6-5814-4C12-8CC1-C1A4D22D7BE6@cisco.com> <4DB5C9F6.60402@cisco.com> Content-Transfer-Encoding: base64 thread-topic: [PWE3] GAL above and below the PW label thread-index: AcwEg6Lm7tDWD5NOQR2VbYKkWT8wHg== From: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset="utf-8" In-Reply-To: Message-ID: <0B268BDD-9A96-4436-9A33-7BEA2386ADA6@cisco.com> Date: Tue, 26 Apr 2011 22:34:53 -0400 To: "Sriganesh Kini" MIME-Version: 1.0 (iPad Mail 8H7) X-OriginalArrivalTime: 27 Apr 2011 02:34:30.0585 (UTC) FILETIME=[A2D2C290:01CC0483] Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL above and below the PW label X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 02:34:33 -0000 SGkgU3JpZ2FuZXNoLA0KDQpUaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZXMgYW5kIGZvbGxv dy11cC4gUGVhc2Ugc2VlIGlubGluZS4gDQoNCkNhcmxvcyBQLg0KDQpPbiBBcHIgMjYsIDIwMTEs IGF0IDk6MDkgUE0sICJTcmlnYW5lc2ggS2luaSIgPHNyaWdhbmVzaC5raW5pQGVyaWNzc29uLmNv bT4gd3JvdGU6DQoNCj4gSGkgQ2FybG9zLA0KPiANCj4gUGxzIHNlZSBpbmxpbmUNCj4gDQo+IE9u IE1vbiwgQXByIDI1LCAyMDExIGF0IDY6MDcgUE0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRh KQ0KPiA8Y3BpZ25hdGFAY2lzY28uY29tPiB3cm90ZToNCj4+IFNyaWdhbmVzaCwNCj4+IA0KPj4g UGxlYXNlIHNlZSBpbmxpbmUuDQo+PiANCj4+IENhcmxvcyBQLg0KPj4gDQo+PiBPbiBBcHIgMjUs IDIwMTEsIGF0IDc6MjkgUE0sICJTcmlnYW5lc2ggS2luaSIgPHNyaWdhbmVzaC5raW5pQGVyaWNz c29uLmNvbT4gd3JvdGU6DQo+PiANCj4+PiBIaSBDYXJsb3MsDQo+Pj4gDQo+Pj4gUGxzIHNlZSBp bmxpbmUuDQo+Pj4gDQo+Pj4gT24gTW9uLCBBcHIgMjUsIDIwMTEgYXQgMTI6MjIgUE0sIENhcmxv cyBQaWduYXRhcm8gPGNwaWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+IEhpIFNyaWdhbmVz aCwNCj4+Pj4gDQo+Pj4+IFBsZWFzZSBzZWUgaW5saW5lLg0KPj4+PiANCj4+Pj4gT24gNC8yNS8y MDExIDI6NTYgUE0sIFNyaWdhbmVzaCBLaW5pIHdyb3RlOg0KPj4+Pj4gSGkgQ2FybG9zLA0KPj4+ Pj4gDQo+Pj4+PiBQbHMgc2VlIGlubGluZS4NCj4+Pj4+IA0KPj4+Pj4gT24gRnJpLCBBcHIgMjIs IDIwMTEgYXQgNjoyMyBQTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+Pj4+PiA8Y3Bp Z25hdGFAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+PiBIaSBTcmlnYW5lc2gsDQo+Pj4+Pj4gDQo+ Pj4+Pj4gVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UgYW5kIGxvdyBSVFQsIHBsZWFzZSBm aW5kIHNvbWUgZm9sbG93LXVwcyBpbmxpbmUuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQ2FybG9zIFAuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gT24gQXByIDIyLCAyMDExLCBhdCAyOjIwIFBNLCAiU3JpZ2FuZXNoIEtp bmkiIDxzcmlnYW5lc2gua2luaUBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+ PiBIaSBDYXJsb3MsDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGUgYXBwbGljYWJpbGl0eSBvZiBkcmFm dC1raW5pLXB3ZTMtaW5iYW5kLWNjLW9mZnNldCBpcyB3aGVuIENXIGlzDQo+Pj4+Pj4+IG5vdCBw cmVzZW50LCBidXQgdGhlIGludGVybWVkaWF0ZSBMU1IgbG9va3MgYmV5b25kIHRoZSBQVyBsYWJl bCB0byBkbw0KPj4+Pj4+PiBtdWx0aXBhdGggZGVjaXNpb25zLiBUaGUgZHJhZnQgaXMgaW5kZXBl bmRlbnQgb2YgYW55IChldmVuIHByb3ByaWV0YXJ5DQo+Pj4+Pj4+IGxvZ2ljKSBmb3IgbXVsdGlw YXRoIGRlY2lzaW9uIHRha2VuIGJ5IGludGVybWVkaWF0ZSBub2RlcyBsb29raW5nDQo+Pj4+Pj4+ IGJleW9uZCBQVyBsYWJlbCBhbmQgYWxzbyBpbmRlcGVuZGVudCBvZiBhbnkgaGV1cmlzdGljIHRo ZSBpbnRlcm1lZGlhdGUNCj4+Pj4+Pj4gcm91dGVycyBtYXkgdXNlIHRvIGd1ZXNzIHRoZSBwYWNr ZXQgdHlwZSAoYmV5b25kIGxhYmVsIHN0YWNrKSBiZWluZw0KPj4+Pj4+PiBjYXJyaWVkLg0KPj4+ Pj4+IA0KPj4+Pj4+IEkgdGhpbmsgdGhhdCB0aGlzIHN0YXRlbWVudCBpcyBhIGJpdCB0b28gb3B0 aW1pc3RpYyBhbmQgdG9vIGdlbmVyYWxpemVkLiBJdCBzZWVtcyB0byBtZSB0aGF0LCBpbiBhZGRp dGlvbiwgdGhlIFBFIG5lZWRzIHRvIHVuZGVyc3RhbmQgdGhlIGZsb3dzIGNhcnJpZWQgaW5zaWRl IHRoZSBQVywgaGF2ZSBzb21lIGNsdWUgYXMgdG8gdGhlIHR5cGUgb2YgRUNNUCBpbiB0aGUgY29y ZSwgYW5kIHRoZXJlIHNob3VsZCBoYXZlIGNvcnJlbGF0aW9uIGJldHdlZW4gdGhlc2UgdHdvLiBU aGlzIGRyYW1hdGljYWxseSBsaW1pdGVkIHRoZSBhcHBsaWNhYmlsaXR5IGFzIHlvdSBzYXkgYmVs b3c6DQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IENvcnJlY3QgdGhhdCB0aGUgUEUgbmVlZHMgdG8g a25vdyB0aGUgZmxvdyB0aGF0IHRoZSBvcGVyYXRvciBpcyB0cnlpbmcNCj4+Pj4+IHRvIHRyb3Vi bGVzaG9vdCAhIEhvd2V2ZXIgdGhlIFBFIGRvZXMgbm90IG5lZWQgdG8ga25vdyB0aGUgdHlwZSBv Zg0KPj4+Pj4gRUNNUCB0aGF0IGlzIGltcGxlbWVudGVkIGluIHRoZSBjb3JlIChQIHJvdXRlciku IFRoYXQgYWxnb3JpdGhtIHdvdWxkDQo+Pj4+PiBiZSB0eXBpY2FsbHkgcHJvcHJpZXRhcnkuIE5v dCBzdXJlIGlmIHlvdSBhcmUgc2F5aW5nIHRoYXQgdGhlIFBFDQo+Pj4+PiBzaG91bGQga25vdyB0 aGUgY28tcmVsYXRpb24gYmV0d2VlbiB0aGUgZmxvdyBhbmQgdGhlIEVDTVAtdHlwZSBiZWZvcmUN Cj4+Pj4+IHRoZSBwcm9ibGVtIG9jY3Vycy4gVGhlIGRyYWZ0IGlzIG5vdCBhIG11bHRpLXBhdGgg YWxnb3JpdGhtIGRpc2NvdmVyeQ0KPj4+Pj4gbWVjaGFuaXNtLiBUaGF0IGlzIGFuIGltcG9ydGFu dCBwcm9ibGVtLCBidXQgZHVlIHRvIHRoZSBwcm9wcmlldGFyeQ0KPj4+Pj4gbmF0dXJlIG9mIHRo b3NlIGFsZ29yaXRobXMgYSBzb2x1dGlvbiBoYXMgbGltaXRhdGlvbnMuIFRoZSBkcmFmdA0KPj4+ Pj4gcHJvdmlkZXMgYSBQRSBhIG1lY2hhbmlzbSB0byB0cm91Ymxlc2hvb3QgYSBmbG93IHdpdGhv dXQgaGF2aW5nDQo+Pj4+PiBwcmVjaXNlIGtub3dsZWRnZSBhLXByaW9yaSBvZiBob3cgdGhlIG11 bHRpLXBhdGggYWxnb3JpdGhtIGlzIGJlaGF2aW5nDQo+Pj4+PiBmb3IgYSBzcGVjaWZpYyBmbG93 Lg0KPj4+PiANCj4+Pj4gQXBvbG9naWVzIGFzIEkgd2FzIG5vdCBjbGVhci4gSSBkaWQgbm90IG1l YW4gdGhhdCB0aGUgUEUgd291bGQgbmVlZCB0bw0KPj4+PiBrbm93IHRoZSBFQ01QIGFsZ29yaXRo bS4gSSBtZWFudCB0byBzYXkgdGhhdCB0aGUgUEUgd291bGQgbmVlZCB0byBrbm93DQo+Pj4+IHdo YXQgdGhlIEVDTVAgYWxnb3JpdGhtIGlzIGV4cGVjdGluZyBhbmQgd2hhdCBmaWVsZHMgYXJlIHJl bGV2YW50IGZvcg0KPj4+PiB0aGUgRUNNUCBhbGdvcml0aG0uIFRoaXMgd2FzIGEgcm91bmQtYWJv dXQgd2F5IG9mIHNheWluZyB0aGF0LCBhc3N1bWluZw0KPj4+PiB0aGF0IEVDTVAgYWxnb3JpdGht cyBoYXNoIG9uIGNlcnRhaW4gZmllbGRzIG9mIGFuIElQK1RyYW5zcG9ydC9VTFANCj4+Pj4gaGVh ZGVyIGFmdGVyIGFuIE1QTFMgaGVhZGVyLCB0aGVuIHRoaXMgSS1EIGlzIGFwcGxpY2FibGUgZm9y IGFuIElQIFBXLg0KPj4+IA0KPj4+IE1heWJlIHdlIGFyZSBzYXlpbmcgdGhlIHNhbWUgdGhpbmcg aGVyZSBidXQgbGV0IG1lIHRyeS4gSSB0aGluayB3ZQ0KPj4+IGJvdGggYWdyZWUgdGhhdCBFQ01Q IGFsZ29yaXRobXMgYXQgYSBQIHJvdXRlciB0eXBpY2FsbHkgbG9vayBpbnRvIHRoZQ0KPj4+IHBh Y2tldCBoZHIgdG8gZG8gbXVsdGlwYXRoIGRlY2lzaW9ucy4gVGhlIGNhdmVhdCBiZWluZyB0aGF0 IHRoZXkgbWF5DQo+Pj4gdXNlIGEgaGV1cmlzdGljIHRvIGd1ZXNzIHRoZSBwYWNrZXQgdHlwZSAo ZHVlIHRvIGluY29tcGxldGUNCj4+PiBpbmZvcm1hdGlvbikuIEFzIGxvbmcgYXMgdGhleSBkbyBu b3Qgc2VuZCBhIGZsb3cgYWxvbmcgbXVsdGlwbGUgcGF0aHMNCj4+PiBldmVyeXRoaW5nIGlzIG9r Lg0KPj4+IA0KPj4+IENvbnNpZGVyIGEgbmV0d29yayB3aXRoIFAgcm91dGVycyBQMSwgUDIsIFAz LCAuLi4uIFNheSB0aGF0IGRpZmZlcmVudA0KPj4+IFAgcm91dGVycyBoYXZlIGRpZmZlcmVudCBF Q01QIGFsZ29yaXRobXMgLSBTbyBQMSBoYXNoZXMgb25seSBvbiB0aGUNCj4+PiBsYWJlbCBzdGFj aywgUDIgbG9va3MgYXQgdGhlIGZpcnN0IG5pYmJsZSBiZXlvbmQgbGFiZWwgc3RhY2sgYW5kIGlm IGl0DQo+Pj4gaXMgSVB2NC92NiwgaGFzaGVzIG9uIElQIHNyYy9kZXN0LiBQMyBkb2VzIHRoZSBz YW1lIGFzIFAyIGV4Y2VwdCB0aGF0DQo+Pj4gaXQgbG9va3MgZnVydGhlciBhbmQgaGFzaGVzIG9u IHByb3RvY29sIHR5cGUgYW5kIGNlcnRhaW4gVENQL1VEUCBoZHJzDQo+Pj4gcGFyYW1zLg0KPj4+ IA0KPj4+IFBFMSBkb2VzIG5vdCBrbm93IHRoZSBkZXRhaWxzIG9mIHRoZSBQIHJvdXRlcnMgYWxn b3JpdGhtcyBvciB3aGljaA0KPj4+IHBhcnRzIG9mIHRoZSBoZWFkZXIgdGhleSBsb29rIGludG8u IFNheSB0aGUgUEUgd2FudHMgdG8gdHJvdWJsZXNob290IGENCj4+PiBUQ1Agc2Vzc2lvbiBiZXR3 ZWVuIGEgcGFpciBvZiBJUCBhZGRyZXNzZXMuIFRoZSBwYWNrZXQgdGhhdCBpcyB1c2VkDQo+Pj4g Zm9yIFZDQ1YgcHVycG9zZXMgd291bGQgbG9vayB0aGUgc2FtZSBhcyBhIG5vcm1hbCBkYXRhIHBh Y2tldCBmb3IgdGhhdA0KPj4+IFRDUCBzZXNzaW9uIHdpdGggdGhlIGV4Y2VwdGlvbiB0aGF0IHRo ZSBUVEwgd291bGQgYmUgYXMgc3BlY2lmaWVkIGZvcg0KPj4+IFRUTCBFeHBpcnkgVkNDViB0eXBl LTMgYW5kIHRoYXQgYmV5b25kIHRoZSBwc2V1ZG8tZmxvdyBoZWFkZXIsIHRoYXQNCj4+PiBhY3R1 YWwgVkNDViBtZXNzYWdlIHdvdWxkIGJlIHByZXNlbnQgaW5zdGVhZCBvZiB0aGUgZGF0YSBwYWNr ZXQuDQo+PiANCj4+IE5vLCB0aGlzIGlzIHRoZSBrZXkuIFZDQ1YgZXhpc3RzIGluIHRoZSBjb250 ZXh0IG9mIGEgUFcsIHdoaWNoIGlzIG1vcmUgZ2VuZXJpYyB0aGFuIElQIGRpcmVjdGx5IG92ZXIg TVBMUy4gU28gdGhlcmUgaXMsIHBvdGVudGlhbGx5LCBubyBUQ1Agc2Vzc2lvbiBmcm9tIENFcyB3 b3VsZCBpbmZsdWVuY2UgRUNNUCBmb3IgYW4gRXRoZXJuZXQgUFcsIHdoaWNoIGlzIHRoZSBuZWVk IGZvciBGYXQtUFcgdG8gc3VtbWFyaXplIHRoZSBmbG93IGluIHNvbWV0aGluZyBtZWFuaW5nZnVs IGluIHRoZSBjb3JlLg0KPiANCj4gSSBhZ3JlZSB3aXRoIHlvdXIgb2JzZXJ2YXRpb24uIEhvd2V2 ZXIgSVAgb3ZlciBNUExTIGhhcyB3aWRlDQo+IGRlcGxveW1lbnQgKGV2ZW4gaWYgd2UgbGVhdmUg b3V0IHRoZSBjYXNlIG9mIHRoZSBwa3QgUFcgaW4gdGhlDQo+IGVmZmljaWVudC1pcC1tcGxzIGVu Y2FwIGRyYWZ0KS4NCg0KVGhhbmtzLiBJIGp1c3Qgbm90aWNlZCB0aGUgSVAgUFcgVHlwZSBpcyBu b3QgcHJlc2VudCBhdCBkcmFmdC1kZWxyZWduby1wd2UzLXB3LXZjY3YtaW1wbC1zdXJ2ZXktcmVz dWx0cy4gQWxzbywgd291bGQgaXQgbWFrZSBzZW5zZSB0byB1c2Ugc2FtZSBleGlzdGluZyB0ZWNo bmlxdWVzIGFzIE1QTFMgZm9yIElQLCBhcyBpdCdzIHRoZSBzYW1lIGRhdGFwbGFuZSBpbiB0aGUg Y29yZT8NCg0KPiBGQVQtUFcgcmVxdWlyZXMgaGFyZHdhcmUgdG8gaWRlbnRpZnkNCj4gZmxvd3Mg YW5kIGluIG1hbnkgY2FzZXMgaXQgaXMgbm90IGF2YWlsYWJsZSBvciBkZXBsb3llZCwgd2hlcmVh cyBFQ01QDQo+IGJhc2VkIG9uIGxvb2tpbmcgZm9yIElQIGJleW9uZCBNUExTIGlzIGRlcGxveWVk IHdpZGVseS4NCj4gDQoNCkJ1dCBhZ2FpbiB0aGlzIGlzIGZvciBJUCBQV3MuIA0KDQpUaGFua3Ms DQoNCkNhcmxvcy4gDQoNCj4+IA0KPj4+IEZvcg0KPj4+IHRoZSBQIHJvdXRlcnMsIHRoaXMgVkND ViBtZXNzYWdlIGxvb2tzIHRoZSBzYW1lIGFzIGEgZGF0YSBwYWNrZXQgc2luY2UNCj4+PiBpdCBp cyBqdXN0IGxvb2tpbmcgYXQgdGhlIGhlYWRlciB0byBkbyBtdWx0aXBhdGggZGVjaXNpb25zIGFu ZCB0aGUNCj4+PiBkYXRhIGFuZCBWQ0NWIG1lc3NhZ2Ugd291bGQgdGFrZSB0aGUgc2FtZSBwYXRo IHRocm91Z2ggdGhlIFAgcm91dGVycy4NCj4+PiANCj4+PiBJbiB0aGUgY2FzZSB3aGVyZSB0aGUg cGFja2V0IGNvbWluZyBmcm9tIHRoZSBjbGllbnQgaGFzIGEgTVBMUyBsYWJlbA0KPj4+IHN0YWNr IGFuZCB0aGF0IGxhYmVsIHN0YWNrIGlzIHNlbnQgYXMgYSBzaW5nbGUgbGFiZWwgc3RhY2sgKGku ZS4gUFcNCj4+PiBsYWJlbCBzdGFjayArIGNsaWVudCBsYWJlbCBzdGFjayksIHRoZW4gYWdhaW4g dGhlIGNsaWVudCBsYWJlbCBzdGFjaw0KPj4+IHdvdWxkIGJlIHBhcnQgb2YgdGhlIGZsb3cgaGVh ZGVyIChOb3RlIHRoYXQgUFcgbGFiZWwgb3IgdGhlIG9wdGlvbmFsDQo+Pj4gRkFULVBXIGxhYmVs IHdpbGwgaGF2ZSBTPTAgaW4gdGhpcyBjYXNlKS4NCj4+PiANCj4+Pj4gQ29udmVyc2VseSwgZm9y IGFuIEV0aGVybmV0IFBXLCBJIGRvIG5vdCBzZWUgaG93IHlvdSBjYW4gZG8gd2hhdCB0aGUgSS1E DQo+Pj4+IGNsYWltczoNCj4+Pj4gDQo+Pj4+IMOD4oCaIFRoaXMgZG9jdW1lbnQNCj4+Pj4gw4Pi gJogw4IgZGVmaW5lcyBhIHNpbXBsZSBleHRlbnNpb24gdG8gdGhlIFRUTCBleHBpcnkgQ0MgKFR5 cGUgMykgdG8gZG8gaW5iYW5kDQo+Pj4+IMOD4oCaIMOCIFZDQ1YuIFRoaXMgY2FuIGJlIHVzZWQg ZXZlbiB3aXRob3V0IGEgQ1cuDQo+Pj4+IA0KPj4+PiBzaW5jZSBhKG4gSVApIGZsb3cgKGFzIHJl Y2VpdmVkIGZyb20gYSBQRSkgaXMgYWZ0ZXIgYW4gRXRoZXJuZXQgaGVhZGVyLA0KPj4+PiBidXQg dGhlcmUgaXMgbm8gRUNNUCBiYXNlZCBvbiB0aGVzZSBmbG93cyAoc2luY2UgdGhlIGNvcmUgcm91 dGVycyBkbyBub3QNCj4+Pj4ga25vdyB3aGF0IHRoZSBQVyBpcyBjYXJyeWluZykuDQo+Pj4+IA0K Pj4+PiBNeSBwb2ludCB3YXMgdGhhdCB1bmxlc3Mgc29tZSBmbG93IGlkZW50aWZpZXIgZnJvbSB0 aGUgY2xpZW50DQo+Pj4+IHBlcnNwZWN0aXZlIGlzIHdoYXQgaXMgdXNlZCBmb3IgRUNNUCAod2hp Y2ggaXMgbm90IHRoZSBjYXNlIGlmIHRoZXJlIGlzDQo+Pj4+IHNvbWUgTDIgb3IgTVBMUyBiZXR3 ZWVuIElQIGFuZCB0aGUgdHJhbnNwb3J0KSwgdGhlbiB0aGlzIHRlY2huaXF1ZQ0KPj4+PiBjYW5u b3QgYmUgdXNlZC4NCj4+PiANCj4+PiBJZiBhbnkgZmllbGQgZnJvbSB0aGUgY2xpZW50IHBhY2tl dCBpcyBub3QgdXNlZCBieSB0aGUgdHJhbnNpdCBMU1IgZm9yDQo+Pj4gRUNNUCB0aGVuIFRUTCBF eHBpcnkgVkNDViB0eXBlIDMgaXMgYWx3YXlzIGluYmFuZC4gU28gaW4gdGhhdCBzZW5zZSBJDQo+ Pj4gYWdyZWUuIE9uZSBvZiB0aGUgcHJvYmxlbXMgd2UgaGF2ZSB3aXRoIFZDQ1YgaXMgdGhhdCBt dWx0aXBsZSB0eXBlcw0KPj4+IGhhdmUgYmVlbiBkZXBsb3llZCAoc29tZSBvZiB3aGljaCBhcmUg aW5iYW5kKSBhbmQgYWxzbyB0aGF0IENXIGhhcw0KPj4+IGJlZW4gdXNlZCBpbiBzb21lIFBXIGRl cGxveW1lbnRzIGFuZCBub3Qgb3RoZXJzLiBUaGlzIGRyYWZ0IGlzDQo+Pj4gYWRkcmVzc2luZyBj YXNlcyB3aGVyZSBDVyBpcyBub3QgdXNlZCBhbmQgaW50ZXJtZWRpYXRlIExTUnMgbG9vaw0KPj4+ IGJleW9uZCB0aGUgUFcgbGFiZWxzIChpbmNsdWRpbmcgRkFULVBXKSBpbnRvIHRoZSBwYWNrZXQg dG8gZG8NCj4+PiBtdWx0aXBhdGggZGVjaXNpb25zLiBUaGlzIGNvdWxkIGJlIGFuIElQIHBhY2tl dCBpbW1lZGlhdGVseSBmb2xsb3dpbmcNCj4+PiBsYWJlbCBzdGFjaywgYW55IGNsaWVudCBsYWJl bHMgdGhhdCBmb3JtIGEgc2luZ2xlIGxhYmVsIHN0YWNrIHdpdGggdGhlDQo+Pj4gUFcgbGFiZWxz LCBvciAoYXMgYSBzdHJldGNoKSBldmVuIGEgUCByb3V0ZXIgaGV1cmlzdGljIHN1Y2ggYXMgLSBh DQo+Pj4gbmliYmxlIGJleW9uZCBsYWJlbCBzdGFjayB0aGF0IGluZGljYXRlcyBhIG5vbiBJUHY0 LzYgcGFja2V0IGlzIGFuDQo+Pj4gZXRoZXJuZXQgaGVhZGVyLiBJIGFtIG5vdCBhZHZvY2F0aW5n IHN1Y2ggYW4gYXBwcm9hY2gsIGp1c3QgbWFraW5nIGENCj4+PiBwb2ludCB0aGF0IHRoaXMgZHJh ZnQgcHJvdmlkZXMgYSBzb2x1dGlvbiB0aGF0IGlzIGFnbm9zdGljIG9mIHN1Y2gNCj4+PiBiZWhh dmlvci4NCj4+IA0KPj4gTXkgY29tbWVudCBpcyB0aGF0IEkgYW0gbm90IGNvbnZpbmNlZCBvZiB0 aGUgbGF0dGVyLCBub3QgZXZlbiBhcyBhIHN0cmV0Y2guIFRoYXQncyB3aHkgSSB3YXMgYXNraW5n IGFib3V0IGFwcGxpY2FiaWxpdHkuDQo+PiANCj4+PiANCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFJl Z2FyZGluZyBhcHBsaWNhYmlsaXR5LCBjb25zaWRlciBhbiBlbmNhcHN1bGF0aW9uIHRoYXQgaGFz IGEgc2luZ2xlDQo+Pj4+PiBsYWJlbCBzdGFjayBpbiB0aGUgY29yZSBjb25zaXN0aW5nIG9mIHRo ZSBhZGFwdGF0aW9uIGxhYmVsIHN0YWNrIChQVw0KPj4+Pj4gaW4gdGhpcyBjYXNlKSBhbmQgdGhl IGxhYmVsIHN0YWNrIG9mIGEgTVBMUyBwYWNrZXQgcmVjZWl2ZWQgZnJvbSB0aGUNCj4+Pj4+IGNs aWVudCBDRS4gVGhpcyBraW5kIG9mIGVuY2Fwc3VsYXRpb24gaXMgaW4NCj4+Pj4+IGRyYWZ0LWtp bmktcHdlMy1wa3QtZW5jYXAtZWZmaWNpZW50LWlwLW1wbHMgd2hlbiBDVyBpcyBub3QgdXNlZC4g SQ0KPj4+Pj4gYmVsaWV2ZSBhIHNpbWlsYXIgZW5jYXAgaXMgdXNlZCBpbiB0aGUgbmV0d29yayBs YXllciBhZGFwdGF0aW9uIHNlYw0KPj4+Pj4gMy40LjUgUkZDIDU5MjEgZm9yIGEgY2xpZW50IGxh eWVyIHRoYXQgaXMgTVBMUyBlbmFibGVkLiBJbiBzdWNoIGEgY2FzZQ0KPj4+Pj4gdG9vIGl0IGlz IHBvc3NpYmxlIHRvIHRyb3VibGVzaG9vdCBhIGZsb3cgKHRoYXQgaW5jbHVkZXMgdGhlIGNsaWVu dA0KPj4+Pj4gbGFiZWxzIGFuZCB0aGUgcGFja2V0IGJlaW5nIGNhcnJpZWQgYmVsb3cpIG9mIHRo ZSBjb21iaW5lZCBsYWJlbA0KPj4+Pj4gc3RhY2suDQo+Pj4+IA0KPj4+PiBJIGRvIG5vdCBzZWUg aG93IHRoaXMgYXBwbGllcyBvdGhlciB0aGFuIGZvciBJUCBQV3MuIExldCBtZSB0cnkgdG8gYXNr IGENCj4+Pj4gZGlmZmVyZW50IHdheTogVGhlIHByb3Bvc2FsIGluIGRyYWZ0LWtpbmktcHdlMy1p bmJhbmQtY2Mtb2Zmc2V0IHVzZXMgYQ0KPj4+PiAicHNldWRvIGZsb3cgaGVhZGVyIiBhZnRlciB0 aGUgUFcgbGFiZWwuIEl0IGlzIHRoZSBleHBlY3RhdGlvbiB0aGF0IGNvcmUNCj4+Pj4gcm91dGVy cyB3b3VsZCBFQ01QLWRpc3RyaWJ1dGUgYmFzZWQgb24gc2FpZCAicHNldWRvIGZsb3cgaGVhZGVy Ii4gSXQgaXMNCj4+Pj4gYWxzbyB0aGUgZXhwZWN0YXRpb24gdGhhdCB3aGVuIHRoaXMgaGFwcGVu cywgdGhpcyBPQU0gd291bGQgZmF0ZS1zaGFyZQ0KPj4+PiB3aXRoIGFjdHVhbCB1c2VyIHRyYWZm aWMuIERvZXMgdGhpcyBpbXBseSB0aGF0IFBXIHRyYWZmaWMgbmVlZHMgdG8gc3RhcnQNCj4+Pj4g KGFmdGVyIHRoZSBQVyBMYWJlbCkgd2l0aCB0aGUgc2FtZSB2YWx1ZXMgYXMgaW4gdGhlICJwc2V1 ZG8gZmxvdw0KPj4+PiBoZWFkZXIiLCBhbmQgdGh1cyB0aGUgZmxvdyBpZGVudGlmaWVycyBmb3Ig cmVndWxhciB0cmFmZmljIGZvbGxvdyB0aGUgUFcNCj4+Pj4gTGFiZWwgZGlyZWN0bHk/DQo+Pj4+ IA0KPj4+IA0KPj4+IFRoZSBQVyBwYXlsb2FkIHN0YXlzIGV4YWN0bHkgdGhlIHdheSBpdCBkb2Vz IGFjY29yZGluZyB0byB0aGUNCj4+PiBhZGFwdGF0aW9uIGRlZmluZWQgZm9yIHRoYXQgdHlwZSBv ZiBQVy4gVGhpcyBkcmFmdCBkb2VzIG5vdCBkZWZpbmUgYW55DQo+Pj4gbmV3IGFkYXB0YXRpb24s IHNvIGl0IGhhcyBubyBuZXcgaW1wbGljYXRpb25zIG9uIHdoZXJlIHRoZSBQVyB0cmFmZmljDQo+ Pj4gbmVlZHMgdG8gc3RhcnQuIEFsbCBpdCBkZWZpbmVzIGlzIGEgdmFyaWFudCBvZiB0aGUgVFRM IGV4cGlyeSBWQ0NWLA0KPj4+IHdoZXJlIHRoZSBWQ0NWIG1lc3NhZ2Ugc3RhcnRzIGF0IGFuIG9m ZnNldCBhZnRlciB0aGUgUFcgbGFiZWwuIFRoZQ0KPj4+IHBhY2tldCBlbmNvZGluZyAoYWZ0ZXIg dGhlIFBXIGxhYmVsKSB0aWxsIHRoZSBvZmZzZXQgaXMgZXhhY3RseSB0aGUNCj4+PiBzYW1lIGFz IGZvciBhIGRhdGEgcGFja2V0IChmb3Igd2hpY2ggdGhlIGluYmFuZCBPQU0gbmVlZHMgdG8gYmUN Cj4+PiBleGVjdXRlZCkuDQo+Pj4gDQo+PiANCj4+IFllcywgYW5kIHRoYXQgaGVscHMgZm9yIElQ IFBXcywgd2hlcmUgZXhpc3RpbmcgbWV0aG9kcyBjYW4gdGVzdCBhbGwgcGF0aHMuDQo+IA0KPiBJ IG1heSBoYXZlIG1pc3NlZCB0aGUgcG9pbnQgeW91IG1hZGUgYWJvdXQgaG93IHRoaXMgYXBwbGll cyB0byBNUy1QVy4NCj4gQXJlIHlvdSByZWNvbW1lbmRpbmcgdGhhdCBMU1AgdHJhY2UgYmUgdXNl ZCBvbiBhIHNlZ21lbnQgYnkgc2VnbWVudA0KPiBiYXNpcyA/IElNTyBpdCBpcyB1c2VmdWwgdG8g aGF2ZSBhIG1lY2hhbmlzbSBhdCB0aGUgUFcgbGV2ZWwgdGhhdA0KPiBnaXZlcyBhIHF1aWNrIGFu c3dlciBvbiB3aGV0aGVyIGEgZmxvdyBvbiB0aGUgUFcgaGFzIGFuIGlzc3VlLg0KPiANCj4+IA0K Pj4gVGhhbmtzLA0KPj4gDQo+PiBDYXJsb3MuDQo+PiANCj4+Pj4+IA0KPj4+Pj4gQWxzbyBub3Rl IHRoYXQgdGhpcyBtZWNoYW5pc20gaGFzIHNvbWUgc2ltaWxhcml0eSB0bw0KPj4+Pj4gZHJhZnQt bmFkZWF1LXB3ZTMtdmNjdi0yLiBUaGUgcHJpbWFyeSBkaWZmZXJlbmNlIGJlaW5nIHRoYXQgaW4N Cj4+Pj4+IGRyYWZ0LW5hZGVhdSB0aGUgR0FMIGlzIHVzZWQgdG8gaWRlbnRpZnkgYW4gT0FNIHBh Y2tldCBpbnN0ZWFkIG9mIFRUTCwNCj4+Pj4+IGhlbmNlIHRoZSBwcmVzZW5jZSBvZiBHQUwgaW4g dGhlIGhhc2ggY29tcHV0YXRpb24gaXMgYW4gaXNzdWUuDQo+Pj4+PiBNb3Jlb3ZlciBkdWUgdG8g dGhlIG9mZnNldCwgdGhlIGluYmFuZC12Y2N2IGRyYWZ0IMOD4oCaIGlzIGFsc28gaW5kZXBlbmRl bnQNCj4+Pj4+IG9mIHRoZSBwa3QgKGFuZCBtdWx0aS1wYXRoIGRlY2lzaW9uIGJhc2VkIG9uIHRo YXQpIGJlaW5nIGNhcnJpZWQgYmVsb3cNCj4+Pj4+IHRoZSBsYWJlbCBzdGFjay4NCj4+Pj4+IA0K Pj4+Pj4+PiBUaGUgbW9zdCBjb21tb24gaGV1cmlzdGljIGlzIG9mIGNvdXJzZSBsb29raW5nIGF0 IHRoZSBmaXJzdA0KPj4+Pj4+PiBuaWJibGUgYmV5b25kIGxhYmVsIHN0YWNrIHRvIGRldGVybWlu ZSB0aGF0IGl0IGlzIGFuIElQIHBhY2tldC4gU28NCj4+Pj4+Pj4gdGhpcyB3b3VsZCBhbHNvIGFw cGx5IGZvciBhbiBJUCBQVywgSVBMUywgZXRjIGluIGFkZGl0aW9uIHRvDQo+Pj4+Pj4+IGRyYWZ0 LWtpbmktcHdlMy1wa3QtZW5jYXAtZWZmaWNpZW50LWlwLW1wbHMuDQo+Pj4+Pj4gDQo+Pj4+Pj4g UmlnaHQuIEkgdGhpbmsgaXQgd291bGQgYXBwbHkgdG8gYW4gSVAgUFcsIHdoZXJlIHRoZXJlIGFy ZSBleGlzdGluZyB0ZWNobmlxdWVzIHRvIHdhbGsgbXVsdGlwYXRocy4gQnV0IGl0IHdvdWxkIG5v dCB0byBzYXkgYW4gRXRoZXJuZXQgUFcgKHdpdGhvdXQgQ1cpOiBldmVuIGlmIHRoZSBQRSBzZWVz IHRoZSBmbG93cyBpbnNpZGUgdGhlIEV0aGVybmV0IChlLmcuLCBUQ1AgZmxvd3Mgb3ZlciBJUCBv dmVyIEV0aGVybmV0KSwgdGhlIGlzIG5vIEVDTVAgaW4gdGhlIGNvcmUgYmFzZWQgb24gdGhvc2Uu DQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEkgd291bGQgbGlrZSB0byBiZWxpZXZlIHRoYXQgdG9v LiBCdXQgSSBoYXZlIGhlYXJkIHRoYXQNCj4+Pj4+IGltcGxlbWVudGF0aW9ucyBkbyBkaWZmZXJl bnQgdGhpbmdzIHdpdGggc29tZSBwYWNrZXQgaW5zcGVjdGlvbi4NCj4+Pj4+IA0KPj4+Pj4+PiBM U1AtUGluZyB1c2VzIHRoZSAxMjcNCj4+Pj4+Pj4gYWRkcmVzcyBhbmQgaXQgaXMgbm90IGVhc3kg dG8gY28tcmVsYXRlIHRoaXMgdG8gYSBwcm9ibGVtIHJlcG9ydGVkIGZvcg0KPj4+Pj4+PiByZWFs IChub24gMTI3KSBhZGRyZXNzZXMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gSSB0aGluayBMU1AtUGluZyBj YW4gZG8gYmV0dGVyOiBpZGVudGlmeSBhbmQgd2FsayBhbGwgRUNNUHMuDQo+Pj4+PiANCj4+Pj4+ IElmIHRoZSBFQ01QIGFsZ29yaXRobSBpcyBwcm9wcmlldGFyeSBhbmQgaW5mbyBhYm91dCB0aGF0 IGlzIG5vdA0KPj4+Pj4gYXZhaWxhYmxlIHRvIHRoZSBQRSwgdGhlcmUgd2lsbCBiZSBpc3N1ZXMu DQo+Pj4+IA0KPj4+PiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDM3OSNzZWN0aW9u LTMuMz4gZG9lcyBub3QgbmVlZCB0byBrbm93DQo+Pj4+IHRoZSBpbnRlcm5hbHMuDQo+Pj4gDQo+ Pj4gWWVzLCB0aGF0IGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5IExTUCBwYXRocywgZmluZCBvdXQg d2hpY2ggSVANCj4+PiBhZGRyZXNzZXMgKDEyNyByYW5nZSkgbWFwIHRvIHdoaWNoIExTUCBuZXh0 aG9wIGFuZCBzbyBvbi4gQnV0IFZDQ1YgaXMNCj4+PiBkZXRlcm1pbmluZyB0aGUgaGVhbHRoIG9m IHRoZSBQVyBhdCB0aGUgUFcgbGF5ZXIgdGhhdCBtYXkgaW5jbHVkZQ0KPj4+IG11bHRpcGxlIExT UHMgKGVzcGVjaWFsbHkgTVMtUFcpLiBXaGVuIHRoZSBQVyBjYW4gdGFrZSBtdWx0aXBsZSBwYXRo cw0KPj4+IGl0IGlzIHVzZWZ1bCB0byBxdWlja2x5IGRldGVybWluZSBpZiBhIGNsaWVudCBmbG93 IHRoYXQgbmVlZHMNCj4+PiB0cm91Ymxlc2hvb3RpbmcgaGFzIGEgcHJvYmxlbSBhbmQgd2hpY2gg c2VnbWVudCBvZiB0aGUgUFcgaGFzIHRoYXQNCj4+PiBwcm9ibGVtLiBUaGF0IG1heSBiZSBmb2xs b3dlZCBieSBhIExTUCB0cmFjaW5nIGZvciB0aGUgc2VnbWVudCBvZiB0aGUNCj4+PiBQVyB0aGF0 IGhhcyBhIHByb2JsZW0uDQo+Pj4gDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+Pj4+IA0KPj4+PiAt LSBDYXJsb3MuDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gSSBhbHNvIHRoaW5rIHRoYXQgdGhlIGFz c3VtcHRpb24gb2YgYSBwcm9ibGVtIGJlaW5nIHJlcG9ydGVkIG9uIGEgZ2l2ZW4gZmxvdywgb25s eSBmb3IgYW4gSVAgUFcgVHlwZSBpcyB0b28gZXhwZW5zaXZlIGZvciB0aGUgcmV0dXJuLg0KPj4+ Pj4+IA0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiANCj4+Pj4+PiAtLSBDYXJsb3MuDQo+Pj4+Pj4g DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGFua3MNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBP biBUaHUsIEFwciAyMSwgMjAxMSBhdCA5OjQ4IFBNLCBDYXJsb3MgUGlnbmF0YXJvIDxjcGlnbmF0 YUBjaXNjby5jb20+IHdyb3RlOg0KPj4+Pj4+Pj4gSGkgU3JpZ2FuZXNoLA0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiBEbyB5b3Ugc2VlIHRoZSBhcHBsaWNhYmlsaXR5IG9mIGRyYWZ0LWtpbmktcHdlMy1p bmJhbmQtY2Mtb2Zmc2V0DQo+Pj4+Pj4+PiBzdHJpY3RseSBsaW1pdGVkIHRvIHRoZSBlbmNhcHN1 bGF0aW9uIHByb3Bvc2VkIGluDQo+Pj4+Pj4+PiBkcmFmdC1raW5pLXB3ZTMtcGt0LWVuY2FwLWVm ZmljaWVudC1pcC1tcGxzPw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBTcGVjaWZpY2FsbHksIGZvciBh IFBXIHRoYXQgY2FycmllcyBzYXkgRXRoZXJuZXQgd2l0aG91dCBDVyAob3IgYW55IG9mDQo+Pj4+ Pj4+PiB0aGUgb3RoZXIgZW5jYXAgbW9kZXMgd2l0aCBub24tbWFuZGF0b3J5IENXKSwgdGhlcmUg aXMgbm8gImZsb3ciIHRoYXQgaXMNCj4+Pj4+Pj4+IGJlaW5nIEVDTVAtZWQgaW4gdGhlIGNvcmUg dGhhdCB5b3Ugd2FudCB0byBtaW1pYy9pbWl0YXRlIGluIGENCj4+Pj4+Pj4+IGxvYWQtYmFsYW5j aW5nIHBzZXVkby1oZWFkZXIuIENvbnZlcnNlbHksIGZvciAiSVAgUFdzIiwgTFNQLVBpbmcgY2Fu DQo+Pj4+Pj4+PiB0YWtlIGRpZmZlcmVudCBFcXVhbC1jb3N0IHBhdGhzIChhbGwgb2YgdGhlbSwg b25lIGJ5IG9uZSkgYmFzZWQgb24NCj4+Pj4+Pj4+IGNob29zaW5nIHRoZSBkZXN0aW5hdGlvbiBJ UCBhZGRyZXNzLiBBbmQgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhpcyB3aGVuDQo+Pj4+Pj4+PiB0 aGVyZSBpcyBhIENXLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJIGFtIHRyeWluZyB0byB1bmRlcnN0 YW5kIGhvdyBjb21tb24gaXMgdGhlIHVzZSBjYXNlIGZvciB3aGF0IHRoaXMNCj4+Pj4+Pj4+IG9w dGltaXplcyBmb3IuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gLS0gQ2FybG9zLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBPbiAzLzMxLzIwMTEgNDowOCBB TSwgU3JpZ2FuZXNoIEtpbmkgd3JvdGU6DQo+Pj4+Pj4+Pj4gQWxsLA0KPj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+IEp1c3QgYW4gRllJIHRoYXQgYSBwcm9wb3NhbCBmb3IgZmF0ZS1zaGFyaW5nIFBXIE9B TSBhbmQgZGF0YSBnaXZlbiBpbg0KPj4+Pj4+Pj4+IGRyYWZ0LWtpbmktcHdlMy1pbmJhbmQtY2Mt b2Zmc2V0DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gSnVzdCB0byBzdW1tYXJpemUgdGhlIHByb3Bv c2FsLg0KPj4+Pj4+Pj4+IDEuIEl0IGRvZXMgbm90IHJlcXVpcmUgR0FMIGluIFBXLiBUVEwgZXhw aXJ5IGlzIHVzZWQgdG8gYWxlcnQgdGhlIFMvVC1QRS4NCj4+Pj4+Pj4+PiAyLiBJdCBpcyBtYWlu bHkgYXBwbGljYWJsZSB3aGVuIENXIGlzIG5vdCB1c2VkIGluIHRoZSBQVy4NCj4+Pj4+Pj4+PiAz LiBJdCB1c2VzIGEgZml4ZWQgb2Zmc2V0IChuZWdvdGlhdGVkIGJldHdlZW4gUFcgZW5kcG9pbnRz KSBhZnRlciB0aGUNCj4+Pj4+Pj4+PiBsYWJlbCBzdGFjayBiZWZvcmUgc3RhcnRpbmcgdGhlIE9B TSBtc2cuDQo+Pj4+Pj4+Pj4gNC4gVGhlIGJ5dGVzIGJldHdlZW4gdGhlIGxhYmVsLXN0YWNrIGFu ZCB0aGUgZml4ZWQgb2Zmc2V0IGlzIHJlZmVycmVkDQo+Pj4+Pj4+Pj4gdG8gYXMgYSBwc2V1ZG9m bG93IGhlYWRlciBhbmQgaXMgZmlsbGVkIHdpdGggYnl0ZS12YWx1ZXMgKGJ5IHRoZSBQRSkNCj4+ Pj4+Pj4+PiB0aGF0IHJlcHJlc2VudCB0aGUgZmxvdyBmb3Igd2hpY2ggT0FNIGlzIGRlc2lyZWQu IFRoaXMgaGVscHMgUFcgT0FNDQo+Pj4+Pj4+Pj4gYW5kIGRhdGEgdG8gZmF0ZS1zaGFyZSBldmVu IHdoZW4gdGhlIGludGVybWVkaWF0ZSBub2RlIGxvb2tzIGJleW9uZA0KPj4+Pj4+Pj4+IGxhYmVs IHN0YWNrIHRvIGRvIG11bHRpcGF0aCBmb3J3YXJkaW5nIGRlY2lzaW9ucy4NCj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBPbiBUaHUsIE1hciAzMSwgMjAxMSBhdCAxMjowMyBBTSwg Q3VydGlzIFZpbGxhbWl6YXIgPGN1cnRpc0BvY2NuYy5jb20+IHdyb3RlOg0KPj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4gTG9hLCBEYXZlLCBTYXNoYSwNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEkn dmUgc25pcHBlZCBmcm9tIHZhcmlvdXMgcG9zdHMgb24gdGhlIHRocmVhZCB0aGF0IFNhc2hhIHN0 YXJ0ZWQuIMODxpLDouKCrMWhIFNlZQ0KPj4+Pj4+Pj4+PiBpbmxpbmUuDQo+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+PiBJbiBtZXNzYWdlIDw0RDkyRjVEMy42MDgwNjA5QHBpLm51Pg0KPj4+Pj4+Pj4+ PiBMb2EgQW5kZXJzc29uIHdyaXRlczoNCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gQWxsLA0K Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBtaXNzZWQgYSBudWFuY2UgaW4gU2FzaGEgc3ViamVj dCBsaW5lLg0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBXZSBoYXZlIHR3byBpc3N1ZXMNCj4+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gLSB3aGVyZSB0aGUgR0FMIGlzIHBsYWNlZCByZWxhdGl2 ZSB0byB0aGUgUFcgbGFiZWwsIEkgw4PGksOi4oKsxaEgYmVsaWV2ZSBpdCBpcw0KPj4+Pj4+Pj4+ Pj4gw4PGksOi4oKsxaEgw4PigJogw4PGksOi4oKsxaEgbmVjZXNzYXJ5IHRvIGhhdmUgdGhlIEdB TCBiZWxvdyB0aGUgUFcgbGFiZWwuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IC0gd2hldGhl ciB0aGUgdGhlIEdBTCBsYWJlbCBuZWVkcyB0byBiZSBib3R0b20gb2Ygc3RhY2sgb3Igbm90LCBp dA0KPj4+Pj4+Pj4+Pj4gw4PGksOi4oKsxaEgw4PigJogw4PGksOi4oKsxaEgZmlndXJlIHRoYXQg dGhpcyBpcyByZWFsbHkgYSBkaXNjdXNzaW9uIGlmIGl0IGlzIHBvc3NpYmxlIHRvIGhhdmUNCj4+ Pj4+Pj4+Pj4+IMODxpLDouKCrMWhIMOD4oCaIMODxpLDouKCrMWhIGEgRkFUIGxhYmVsIGJlbG93 IHRoZSBHQUwgb3Igbm90LiBJJ20gbm90IHN1cmUgw4PGksOi4oKsxaEgYWJvdXQgbXkgcHJlZmVy ZW5jZXMNCj4+Pj4+Pj4+Pj4+IMODxpLDouKCrMWhIMOD4oCaIMODxpLDouKCrMWhIGJ1dCBJIHRo aW5rIGl0IGlzIHBvc3NpYmxlLg0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiAvTG9hDQo+Pj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBJIGFncmVlIHdpdGggTG9hJ3Mgc3VtbWFyeS4gw4PGksOi4oKs xaEgTm90IHB1dHRpbmcgR0FMIGF0IHRoZSBib3R0b20gbWF5IGNvbmZ1c2UNCj4+Pj4+Pj4+Pj4g c29tZSBMU1IsIGJ1dCBwdXR0aW5nIGl0IGFib3ZlIHRoZSBQVyBsYWJlbCBpcyBsaWtlbHkgdG8g YmUgZXZlbiBtb3JlDQo+Pj4+Pj4+Pj4+IHByb2JsZW1hdGljLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEluIG1lc3NhZ2UgPDYwQzA5M0E0MUI1RTQ1NDA5QTE5RDQyQ0Y3 Nzg2REZENTFENTMxMEI1M0BFVVNBQUNNUzA3MDMuZWFtY3MuZXJpY3Nzb24uc2U+DQo+Pj4+Pj4+ Pj4+IERhdmlkIEFsbGFuIEkgd3JpdGVzOg0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBJdCBk b2VzIGJlY29tZSBhIG5ldyBiZWhhdmlvciwgR0FMIHdpdGggUz0zRDAuIEhvd2V2ZXIgdGhlIGNv bWJpbmF0aW9uIG9mIEc9DQo+Pj4+Pj4+Pj4+PiBBTCBiZWluZyB0b3AgbGFiZWwgYXQgdGhlIFMt UEUgYW5kIFRUTCBiZWluZyBlbmNvZGVkIGluIHRoZSBQVyBsYWJlbCBtZWFucyA9DQo+Pj4+Pj4+ Pj4+PiB0aGF0IGZhdGUgc2hhcmluZyBpcyBicm9rZW4gYXQgZXZlcnkgUy1QRS4gTGlmZSBvbmx5 IGdldHMgYSBsaXR0bGUgbW9yZSBzdHI9DQo+Pj4+Pj4+Pj4+PiBhbmdlIGlmIHRoZXJlIGlzIGEg RkFUIGxhYmVsIGFzIHdlbGwuLi4NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gVGhhdCBiZWlu ZyBzYWlkLCBHQUwgYXMgYm90dG9tIGxhYmVsIGlzIGJyb2tlbiBpbiBhbnkgRUNNUCBlbnZpcm9u bWVudCwgd2hpPQ0KPj4+Pj4+Pj4+Pj4gY2ggaXMgd2h5IEdBTCBpcyBhIFRQIGNvbnN0cnVjdC4N Cj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gbXkgMiBjZW50cw0KPj4+Pj4+Pj4+Pj4gRA0KPj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gRGF2ZSwNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IElmIEdB TCBpcyBicm9rZW4gZm9yIEVDTVAsIHdoaWNoIGl0IGlzLCB0aGVuIGFsbCBUUCBPQU0gaXMgYnJv a2VuLg0KPj4+Pj4+Pj4+PiBJZiBhbGwgaXQgdGFrZXMgdG8gZml4IGl0IGlzIHNpbXBsZSB0aGVu IGxldHMganVzdCBmaXggaXQuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGlzIGlzIHdoYXQg d2UnZCBoYXZlIHRvIGRvLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gw4PGksOi4oKsxaEgMSkg UmVsYXggdGhlIHJlcXVpcmVtZW50IHRoYXQgR0FMIGJlIGF0IHRoZSBib3R0b20NCj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+IMODxpLDouKCrMWhIDIpIEhhdmUgdGhlIGluZ3Jlc3MgaW5zZXJ0IEdB TCBpbiB0aGUgc3RhY2sgaW1tZWRpYXRlbHkgYmVsb3cgdGhlDQo+Pj4+Pj4+Pj4+IMODxpLDouKC rMWhIMOD4oCaIMODxpLDouKCrMWhIMOD4oCaIGxhYmVsIGZvciB3aGljaCB0aGUgbWVhc3VyZW1l bnQgaXMgbWFkZSwga2VlcGluZyB0aGUgcmVzdCBvZiB0aGUNCj4+Pj4+Pj4+Pj4gw4PGksOi4oKs xaEgw4PigJogw4PGksOi4oKsxaEgw4PigJogbGFiZWwgc3RhY2sgaW4gcGxhY2UuDQo+Pj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+PiBUaGUgb25seSB0aGluZyB0aGUgbWlkcG9pbmcgTFNSIGF0IGEgbXVs dGlwYXRoIChMQUcsIGxpbmsgYnVuZGxlIGZvcg0KPj4+Pj4+Pj4+PiBNUExTKSBoYXMgdG8gZG8g aXMgc2tpcCBvdmVyIHRoZSBHQUwgd2hlbiBoYXNoaW5nLCBhcyBpZiB0aGUgR0FMDQo+Pj4+Pj4+ Pj4+IHdhc24ndCB0aGVyZS4gw4PGksOi4oKsxaEgVGhhdCB3aWxsIHlpZWxkIHRoZSBzYW1lIGhh c2ggdmFsdWUgYW5kIGl0IHdpbGwNCj4+Pj4+Pj4+Pj4gcHJlc2VydmUgZmF0ZS1zaGFyaW5nIGFj cm9zcyBtdWx0aXBhdGguDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBJIHByZWZlciB0aGF0IHdl IGZpeCB0aGluZ3MgcmF0aGVyIHRoYW4gY29tcGxhaW4gdGhhdCB0aGV5IGFyZSBicm9rZW4uDQo+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBDdXJ0aXMNCj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4gcHdlMyBtYWlsaW5n IGxpc3QNCj4+Pj4+Pj4+Pj4gcHdlM0BpZXRmLm9yZw0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gcHdlMyBtYWlsaW5nIGxpc3QNCj4+Pj4+ Pj4+IHB3ZTNAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcHdlMw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IC0tDQo+Pj4+Pj4+IC0gU3JpDQo+Pj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gcHdlMyBtYWlsaW5nIGxp c3QNCj4+Pj4+PiBwd2UzQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wd2UzDQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHB3 ZTMgbWFpbGluZyBsaXN0DQo+Pj4+IHB3ZTNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQo+Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+ IC0tDQo+Pj4gLSBTcmkNCj4+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiBwd2UzIG1haWxpbmcgbGlzdA0KPj4gcHdlM0BpZXRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQo+PiANCj4gDQo+ IA0KPiANCj4gLS0gDQo+IC0gU3JpDQo+IA0K