From nobody Thu Jan 1 06:27:45 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285521A1B5A for ; Thu, 1 Jan 2015 06:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kSCIR88XNYs for ; Thu, 1 Jan 2015 06:27:42 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20961A1B3D for ; Thu, 1 Jan 2015 06:27:40 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t01ERVs3008996; Thu, 1 Jan 2015 14:27:31 GMT Received: from 950129200 (089144213207.atnat0022.highway.a1.net [89.144.213.207]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t01ERS35008962 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2015 14:27:29 GMT From: "Adrian Farrel" To: References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> In-Reply-To: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> Date: Thu, 1 Jan 2015 14:27:27 -0000 Message-ID: <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4g5tkJK6A Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21214.007 X-TM-AS-Result: No--17.650-10.0-31-10 X-imss-scan-details: No--17.650-10.0-31-10 X-TMASE-MatchedRID: im+fhl6xvt1DKVWWbGcmRlvKDDArelUKJPNIV6GF8msifM7JMNHW69/i bzOMUcg25CzLqUhLk+f7Z54fPu77w/pnbbsOsupD7T+j7/gPsPP6jzWCu/BjHDPolapMwp0IZZ1 PS3tSmiHjDkdYDrlB6SFvXn+OTwJ8tJieP4rjvdnmAId+2bAQwrd2noO4P7rALraGNlLRahjxy/ H5BGyr4hER3LhQhgpmZfPmKJtMluaTT50vRhVUoHBRIrj8R47FI5K4Cd+0ao+M2ehTV+imi2mCt i+JzZB1nK6NH0kJeVrXDN74BR4+fA9Ox4R+yCZrR+GtoiXVeDGZYYkt8na3tw6QlBHhBZuwoxqT 18Pibe4X//kJXaDgNp3Vwn6CGem4MHsCEB6xhyMtMfCdg6KRDX0tCKdnhB581B0Hk1Q1KyIYq/Q JOAA07Y2j49Ftap9EOwBXM346/+z3EikyfBYJCLgnDLMvGsDxVWQAAy/BZYSSpeHOCm6Jq8KSzQ j3/aAL Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xOlVj_KN49Wy4KC5c0AvtiJx-pI Subject: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 14:27:44 -0000 Hi, Update is minor. - draft-dukhovni-opportunistic-security has been published as RFC 7435. - Add place-holder section 1.2 "Existing Security Tools for MPLS Data" I know a couple of people are considering experimental implementations = and (of course) we would welcome feedback from their experiences. We'd also really appreciate input from people close to silicon to = understand whether what we are proposing is achievable with existing = hardware or would require new silicon. Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 01 January 2015 14:22 > To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell > Subject: New Version Notification for = draft-farrelll-mpls-opportunistic-encrypt- > 04.txt >=20 >=20 > A new version of I-D, draft-farrelll-mpls-opportunistic-encrypt-04.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-farrelll-mpls-opportunistic-encrypt > Revision: 04 > Title: Opportunistic Security in MPLS Networks > Document date: 2015-01-01 > Group: Individual Submission > Pages: 30 > URL: = http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic- > encrypt-04.txt > Status: = https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- > encrypt/ > Htmlized: = http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- > 04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-farrelll-mpls-opportunistic- > encrypt-04 >=20 > Abstract: > This document describes a way to apply opportunistic security > between adjacent nodes on an MPLS Label Switched Path (LSP) or > between end points of an LSP. It explains how keys may be agreed > to enable encryption, and how key identifiers are exchanged in > encrypted MPLS packets. Finally, this document describes the > applicability of this approach to opportunistic security in MPLS > networks with an indication of the level of improved security as > well as the continued vulnerabilities. >=20 > This document does not describe security for MPLS control plane > protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Thu Jan 1 06:59:21 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD021A1B57 for ; Thu, 1 Jan 2015 06:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A2rG2rHZaON for ; Thu, 1 Jan 2015 06:59:17 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AD01A1B56 for ; Thu, 1 Jan 2015 06:59:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 35F7EBF11; Thu, 1 Jan 2015 14:59:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eolK3BKCs9g; Thu, 1 Jan 2015 14:59:13 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.21.122]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5B0F0BF0F; Thu, 1 Jan 2015 14:59:13 +0000 (GMT) Message-ID: <54A560C2.9050803@cs.tcd.ie> Date: Thu, 01 Jan 2015 14:59:14 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, mpls@ietf.org References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk> In-Reply-To: <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hbFs4RtwDj5zpWHm4PlO5mf0yxA Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 14:59:19 -0000 On 01/01/15 14:27, Adrian Farrel wrote: > Hi, > > Update is minor. > > - draft-dukhovni-opportunistic-security has been published as RFC > 7435. - Add place-holder section 1.2 "Existing Security Tools for > MPLS Data" Happy to get text help on the MACsec thing there in particular, we can probably write or find help with the IPsec stuff easily enough. > I know a couple of people are considering experimental > implementations and (of course) we would welcome feedback from their > experiences. > > We'd also really appreciate input from people close to silicon to > understand whether what we are proposing is achievable with existing > hardware or would require new silicon. And on the crypto/key agreement side, is integer DH ok when considering that or is ECDH so significantly better that that'd make a difference to the experiment or to later deployment? We've stuck with integer DH for now as the IPR is still cleaner and I'd rather we had the results of the CFRG work on additional ECDH curves done and dusted before considering whether to use one of those or a NIST curve as a possible ECDH MTI as an alternative to or in addition to integer DH. Cheers, S. > > Thanks, Adrian > >> -----Original Message----- From: internet-drafts@ietf.org >> [mailto:internet-drafts@ietf.org] Sent: 01 January 2015 14:22 To: >> Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell >> Subject: New Version Notification for >> draft-farrelll-mpls-opportunistic-encrypt- 04.txt >> >> >> A new version of I-D, >> draft-farrelll-mpls-opportunistic-encrypt-04.txt has been >> successfully submitted by Adrian Farrel and posted to the IETF >> repository. >> >> Name: draft-farrelll-mpls-opportunistic-encrypt Revision: 04 >> Title: Opportunistic Security in MPLS Networks Document date: >> 2015-01-01 Group: Individual Submission Pages: 30 URL: >> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic- >> >> encrypt-04.txt >> Status: >> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- >> >> encrypt/ >> Htmlized: >> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- >> >> 04 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-farrelll-mpls-opportunistic- >> >> encrypt-04 >> >> Abstract: This document describes a way to apply opportunistic >> security between adjacent nodes on an MPLS Label Switched Path >> (LSP) or between end points of an LSP. It explains how keys may be >> agreed to enable encryption, and how key identifiers are exchanged >> in encrypted MPLS packets. Finally, this document describes the >> applicability of this approach to opportunistic security in MPLS >> networks with an indication of the level of improved security as >> well as the continued vulnerabilities. >> >> This document does not describe security for MPLS control plane >> protocols. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat > > > From nobody Thu Jan 1 10:21:35 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC071A3BA0 for ; Thu, 1 Jan 2015 10:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHVO2jGF4rrZ for ; Thu, 1 Jan 2015 10:21:31 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.109]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC8D1A00B6 for ; Thu, 1 Jan 2015 10:21:30 -0800 (PST) Received: from [193.109.255.147] by server-5.bemta-14.messagelabs.com id 4C/78-08051-82095A45; Thu, 01 Jan 2015 18:21:28 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-72.messagelabs.com!1420136488!14185107!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5585 invoked from network); 1 Jan 2015 18:21:28 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-12.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 1 Jan 2015 18:21:28 -0000 Received: from EXHY012V.surrey.ac.uk (131.227.201.103) by EXHT021P.surrey.ac.uk (131.227.200.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 1 Jan 2015 18:21:28 +0000 Received: from emea01-db3-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY012v.surrey.ac.uk (131.227.201.103) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 1 Jan 2015 18:21:27 +0000 Received: from DB4PR06MB457.eurprd06.prod.outlook.com (10.141.238.15) by DB4PR06MB457.eurprd06.prod.outlook.com (10.141.238.15) with Microsoft SMTP Server (TLS) id 15.1.49.12; Thu, 1 Jan 2015 18:21:27 +0000 Received: from DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) by DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) with mapi id 15.01.0049.002; Thu, 1 Jan 2015 18:21:27 +0000 From: To: , , Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4g5tkJK6AgAAKLACAADgAGg== Date: Thu, 1 Jan 2015 18:21:27 +0000 Message-ID: References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>,<54A560C2.9050803@cs.tcd.ie> In-Reply-To: <54A560C2.9050803@cs.tcd.ie> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.78.127.223] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB457; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB457; x-forefront-prvs: 04433051BF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(479174004)(199003)(164054003)(51704005)(24454002)(377424004)(377454003)(13464003)(64706001)(2420400003)(15395725005)(92566001)(19580405001)(68736005)(1720100001)(54356999)(20776003)(54206007)(102836002)(76176999)(66066001)(2950100001)(74316001)(76576001)(230783001)(101416001)(99396003)(33656002)(54606007)(77156002)(120916001)(62966003)(2201001)(86362001)(4396001)(77096005)(31966008)(87936001)(15198665003)(106116001)(74482002)(106356001)(19580395003)(97736003)(107046002)(2656002)(2501002)(122556002)(46102003)(2900100001)(105586002)(50986999)(21056001)(15975445007)(107886001)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB457; H:DB4PR06MB457.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2015 18:21:27.2163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b902693-1074-40aa-9e21-d89446a2ebb5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB457 X-OrganizationHeadersPreserved: DB4PR06MB457.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY012v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Kr5EPwGRz9eYBUaXngY8Um-Qt-s Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 18:21:34 -0000 Are jargon and acronyms a barrier to meaningful discussion in the ietf? Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls on behalf of Stephen Farrell Sent: Friday, 2 January 2015 1:59:14 AM To: adrian@olddog.co.uk; mpls@ietf.org Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-op= portunistic-encrypt-04.txt On 01/01/15 14:27, Adrian Farrel wrote: > Hi, > > Update is minor. > > - draft-dukhovni-opportunistic-security has been published as RFC > 7435. - Add place-holder section 1.2 "Existing Security Tools for > MPLS Data" Happy to get text help on the MACsec thing there in particular, we can probably write or find help with the IPsec stuff easily enough. > I know a couple of people are considering experimental > implementations and (of course) we would welcome feedback from their > experiences. > > We'd also really appreciate input from people close to silicon to > understand whether what we are proposing is achievable with existing > hardware or would require new silicon. And on the crypto/key agreement side, is integer DH ok when considering that or is ECDH so significantly better that that'd make a difference to the experiment or to later deployment? We've stuck with integer DH for now as the IPR is still cleaner and I'd rather we had the results of the CFRG work on additional ECDH curves done and dusted before considering whether to use one of those or a NIST curve as a possible ECDH MTI as an alternative to or in addition to integer DH. Cheers, S. > > Thanks, Adrian > >> -----Original Message----- From: internet-drafts@ietf.org >> [mailto:internet-drafts@ietf.org] Sent: 01 January 2015 14:22 To: >> Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell >> Subject: New Version Notification for >> draft-farrelll-mpls-opportunistic-encrypt- 04.txt >> >> >> A new version of I-D, >> draft-farrelll-mpls-opportunistic-encrypt-04.txt has been >> successfully submitted by Adrian Farrel and posted to the IETF >> repository. >> >> Name: draft-farrelll-mpls-opportunistic-encrypt Revision:= 04 >> Title: Opportunistic Security in MPLS Networks Document da= te: >> 2015-01-01 Group: Individual Submission Pages: 30 = URL: >> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic- >> >> encrypt-04.txt >> Status: >> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- >> >> encrypt/ >> Htmlized: >> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- >> >> 04 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-farrelll-mpls-opportunistic- >> >> encrypt-04 >> >> Abstract: This document describes a way to apply opportunistic >> security between adjacent nodes on an MPLS Label Switched Path >> (LSP) or between end points of an LSP. It explains how keys may be >> agreed to enable encryption, and how key identifiers are exchanged >> in encrypted MPLS packets. Finally, this document describes the >> applicability of this approach to opportunistic security in MPLS >> networks with an indication of the level of improved security as >> well as the continued vulnerabilities. >> >> This document does not describe security for MPLS control plane >> protocols. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat > > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jan 1 17:15:53 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E20E1A86E8 for ; Thu, 1 Jan 2015 17:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfkK1lyG681X for ; Thu, 1 Jan 2015 17:15:48 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC491A86E7 for ; Thu, 1 Jan 2015 17:15:47 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t021Fe8h020760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2015 20:15:41 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t021Fe8h020760 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1420161341; bh=bkNE6XFhpICaqC2Hv9PrEAc2FIo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Up6d6FYBgn7GZiK0qqK0aoo55/GyvtKSDXKRUxYEmIhIA75c+j7XliCOt3ZWv75B9 nbQ14O/R8TZ5KOqxSib/zYbyoyJ14N4jlxHMZm6XTA/vnnB6Mtp8uT4BOy0GBIbX/R J+bv/ZSv2rgkwZis1mtCPx+m98GTO8nQu0qTurac= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t021Fe8h020760 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Thu, 1 Jan 2015 20:14:44 -0500 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t021FSKd004985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Jan 2015 20:15:29 -0500 Received: from MXHUB203.corp.emc.com (10.253.68.29) by mxhub33.corp.emc.com (10.254.93.81) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 1 Jan 2015 20:15:27 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB203.corp.emc.com ([10.253.68.29]) with mapi id 14.03.0195.001; Thu, 1 Jan 2015 20:15:27 -0500 From: "Black, David" To: "l.wood@surrey.ac.uk" , "stephen.farrell@cs.tcd.ie" , "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4g5tkJK6AgABd/QCAADiAgIAAFPfg Date: Fri, 2 Jan 2015 01:15:27 +0000 Message-ID: References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.132.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/duwSOxWo0xojY6GVOShLpf7CUCc Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 01:15:51 -0000 > Are jargon and acronyms a barrier to meaningful discussion in the ietf?= =0A= =0A= I suppose this is what can happen when a SEC AD posts to an RTG WG list :-)= .=0A= =0A= Here's an attempt at a "secret decoder ring" ...=0A= =0A= > Happy to get text help on the MACsec thing there in particular, we=0A= > can probably write or find help with the IPsec stuff easily enough.=0A= =0A= MACsec =3D IEEE 802.1AE, a standard for Ethernet link security that is roug= hly=0A= analogous to IPsec for IP security, but is at the link layer,=0A= see: http://en.wikipedia.org/wiki/IEEE_802.1AE=0A= =0A= > And on the crypto/key agreement side, is integer DH ok when=0A= > considering that or is ECDH so significantly better that that'd=0A= > make a difference to the experiment or to later deployment?=0A= =0A= DH =3D Diffie-Hellman, a class of algorithms used for key agreement or key = exchange.=0A= Protocols based on these algorithms produce session keys (e.g., for en= cryption)=0A= that are computationally infeasible to determine from the messages exc= hanged. =0A= integer DH - key agreement based on exponentiation involving large numbers,= 2048=0A= bits is the minimum size that should currently be used.=0A= ECDH =3D Elliptic Curve DH. Key agreement based on elliptic curve crypto i= nvolves=0A= much smaller numbers - 224-bit ECDH calculations have comparable secur= ity=0A= strength to 2048-bit integer DH calculations, although the calculation= s are=0A= different. EC calculations are done with respect to a "curve" (effect= ively a=0A= set of parameters).=0A= =0A= > We've=0A= > stuck with integer DH for now as the IPR is still cleaner and I'd=0A= > rather we had the results of the CFRG work on additional ECDH=0A= > curves done and dusted before considering whether to use one of=0A= > those or a NIST curve as a possible ECDH MTI as an alternative to=0A= > or in addition to integer DH.=0A= =0A= IPR =3D Intellectual Property Rights - go ask a lawyer, not me ;-).=0A= =0A= CFRG =3D IRTF Crypto Forum Research Group, a community of cryptographers th= at=0A= provides crypto advice to the IETF, see https://irtf.org/cfrg.=0A= =0A= NIST =3D National Institute of Standards and Technology (US government agen= cy).=0A= NIST curve - One of the NIST-specified curves for EC crypto. The NIST curv= es =0A= are currently the most commonly used for EC crypto in IETF standards.= =0A= The CFRG is in the midst of figuring out what other curves to recomme= nd.=0A= =0A= MTI =3D Mandatory To Implement.=0A= =0A= Enjoy,=0A= --David=0A= ________________________________________=0A= From: mpls [mpls-bounces@ietf.org] on behalf of l.wood@surrey.ac.uk [l.wood= @surrey.ac.uk]=0A= Sent: Thursday, January 01, 2015 1:21 PM=0A= To: stephen.farrell@cs.tcd.ie; adrian@olddog.co.uk; mpls@ietf.org=0A= Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-op= portunistic-encrypt-04.txt=0A= =0A= Are jargon and acronyms a barrier to meaningful discussion in the ietf?=0A= =0A= =0A= Lloyd Wood=0A= http://about.me/lloydwood=0A= ________________________________________=0A= From: mpls on behalf of Stephen Farrell =0A= Sent: Friday, 2 January 2015 1:59:14 AM=0A= To: adrian@olddog.co.uk; mpls@ietf.org=0A= Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-op= portunistic-encrypt-04.txt=0A= =0A= On 01/01/15 14:27, Adrian Farrel wrote:=0A= > Hi,=0A= >=0A= > Update is minor.=0A= >=0A= > - draft-dukhovni-opportunistic-security has been published as RFC=0A= > 7435. - Add place-holder section 1.2 "Existing Security Tools for=0A= > MPLS Data"=0A= =0A= Happy to get text help on the MACsec thing there in particular, we=0A= can probably write or find help with the IPsec stuff easily enough.=0A= =0A= > I know a couple of people are considering experimental=0A= > implementations and (of course) we would welcome feedback from their=0A= > experiences.=0A= >=0A= > We'd also really appreciate input from people close to silicon to=0A= > understand whether what we are proposing is achievable with existing=0A= > hardware or would require new silicon.=0A= =0A= And on the crypto/key agreement side, is integer DH ok when=0A= considering that or is ECDH so significantly better that that'd=0A= make a difference to the experiment or to later deployment? We've=0A= stuck with integer DH for now as the IPR is still cleaner and I'd=0A= rather we had the results of the CFRG work on additional ECDH=0A= curves done and dusted before considering whether to use one of=0A= those or a NIST curve as a possible ECDH MTI as an alternative to=0A= or in addition to integer DH.=0A= =0A= Cheers,=0A= S.=0A= =0A= =0A= >=0A= > Thanks, Adrian=0A= >=0A= >> -----Original Message----- From: internet-drafts@ietf.org=0A= >> [mailto:internet-drafts@ietf.org] Sent: 01 January 2015 14:22 To:=0A= >> Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell=0A= >> Subject: New Version Notification for=0A= >> draft-farrelll-mpls-opportunistic-encrypt- 04.txt=0A= >>=0A= >>=0A= >> A new version of I-D,=0A= >> draft-farrelll-mpls-opportunistic-encrypt-04.txt has been=0A= >> successfully submitted by Adrian Farrel and posted to the IETF=0A= >> repository.=0A= >>=0A= >> Name: draft-farrelll-mpls-opportunistic-encrypt Revision:= 04=0A= >> Title: Opportunistic Security in MPLS Networks Document da= te:=0A= >> 2015-01-01 Group: Individual Submission Pages: 30 = URL:=0A= >> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic-= =0A= >>=0A= >>=0A= encrypt-04.txt=0A= >> Status:=0A= >> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic-=0A= >>=0A= >>=0A= encrypt/=0A= >> Htmlized:=0A= >> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt-=0A= >>=0A= >>=0A= 04=0A= >> Diff:=0A= >> http://www.ietf.org/rfcdiff?url2=3Ddraft-farrelll-mpls-opportunistic-=0A= >>=0A= >>=0A= encrypt-04=0A= >>=0A= >> Abstract: This document describes a way to apply opportunistic=0A= >> security between adjacent nodes on an MPLS Label Switched Path=0A= >> (LSP) or between end points of an LSP. It explains how keys may be=0A= >> agreed to enable encryption, and how key identifiers are exchanged=0A= >> in encrypted MPLS packets. Finally, this document describes the=0A= >> applicability of this approach to opportunistic security in MPLS=0A= >> networks with an indication of the level of improved security as=0A= >> well as the continued vulnerabilities.=0A= >>=0A= >> This document does not describe security for MPLS control plane=0A= >> protocols.=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> Please note that it may take a couple of minutes from the time of=0A= >> submission until the htmlized version and diff are available at=0A= >> tools.ietf.org.=0A= >>=0A= >> The IETF Secretariat=0A= >=0A= >=0A= >=0A= =0A= _______________________________________________=0A= mpls mailing list=0A= mpls@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mpls=0A= =0A= _______________________________________________=0A= mpls mailing list=0A= mpls@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mpls=0A= From nobody Fri Jan 2 05:57:09 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F781A1B6B for ; Fri, 2 Jan 2015 05:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X90GdNVWLO3y for ; Fri, 2 Jan 2015 05:57:05 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CDF1A1EF8 for ; Fri, 2 Jan 2015 05:57:04 -0800 (PST) Received: from [85.158.136.51] by server-13.bemta-5.messagelabs.com id 71/57-02697-EA3A6A45; Fri, 02 Jan 2015 13:57:02 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-49.messagelabs.com!1420207021!22753518!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21584 invoked from network); 2 Jan 2015 13:57:01 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-15.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 2 Jan 2015 13:57:01 -0000 Received: from EXHY011V.surrey.ac.uk (131.227.200.103) by EXHT012P.surrey.ac.uk (131.227.200.39) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 2 Jan 2015 13:57:01 +0000 Received: from emea01-db3-obe.outbound.protection.outlook.com (131.227.200.4) by EXHY011v.surrey.ac.uk (131.227.200.103) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 2 Jan 2015 13:57:01 +0000 Received: from DB4PR06MB457.eurprd06.prod.outlook.com (10.141.238.15) by DB4PR06MB457.eurprd06.prod.outlook.com (10.141.238.15) with Microsoft SMTP Server (TLS) id 15.1.49.12; Fri, 2 Jan 2015 13:57:00 +0000 Received: from DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) by DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) with mapi id 15.01.0049.002; Fri, 2 Jan 2015 13:57:00 +0000 From: To: , , , Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4g5tkJK6AgAAKLACAADgAGoAAdCuAgADThAg= Date: Fri, 2 Jan 2015 13:57:00 +0000 Message-ID: References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [78.86.162.198] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB457; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB457; x-forefront-prvs: 0444EB1997 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(479174004)(199003)(164054003)(51704005)(24454002)(377424004)(377454003)(13464003)(64706001)(19580405001)(15395725005)(2420400003)(54356999)(68736005)(74316001)(2950100001)(20776003)(54206007)(102836002)(76176999)(66066001)(76576001)(92566001)(1720100001)(230783001)(101416001)(99396003)(33656002)(54606007)(77156002)(120916001)(62966003)(2201001)(86362001)(4396001)(77096005)(31966008)(87936001)(15198665003)(106116001)(107046002)(74482002)(106356001)(19580395003)(97736003)(2656002)(2501002)(122556002)(46102003)(2900100001)(105586002)(50986999)(93886004)(21056001)(15975445007)(107886001)(40100003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB457; H:DB4PR06MB457.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: surrey.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2015 13:57:00.6237 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b902693-1074-40aa-9e21-d89446a2ebb5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB457 X-OrganizationHeadersPreserved: DB4PR06MB457.eurprd06.prod.outlook.com X-OriginatorOrg: surrey.ac.uk X-CrossPremisesHeadersPromoted: EXHY011v.surrey.ac.uk X-CrossPremisesHeadersFiltered: EXHY011v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ss80YxmVlbsEn8fjitBrciBqf4E Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 13:57:08 -0000 More a barrier to discussion is that a conversation about anything can now = be derailed into a conversation about security, because all groups are secu= rity groups. The pressing question for mpls has always been not whether mpls requires se= curity, not what security mpls should have, but exactly what type of ellipt= ic curve to use. Good that we're attempting to answer that, no? L. Oh, and security is ALWAYS mandatory to implement. Because... It's security= . ________________________________________ From: Black, David Sent: Friday, 2 January 2015 12:15:27 PM To: Wood L Dr (Electronic Eng); stephen.farrell@cs.tcd.ie; adrian@olddog.c= o.uk; mpls@ietf.org Cc: Black, David Subject: RE: [mpls] FW: New Version Notification for draft-farrelll-mpls-op= portunistic-encrypt-04.txt > Are jargon and acronyms a barrier to meaningful discussion in the ietf? I suppose this is what can happen when a SEC AD posts to an RTG WG list :-)= . Here's an attempt at a "secret decoder ring" ... > Happy to get text help on the MACsec thing there in particular, we > can probably write or find help with the IPsec stuff easily enough. MACsec =3D IEEE 802.1AE, a standard for Ethernet link security that is roug= hly analogous to IPsec for IP security, but is at the link layer, see: http://en.wikipedia.org/wiki/IEEE_802.1AE > And on the crypto/key agreement side, is integer DH ok when > considering that or is ECDH so significantly better that that'd > make a difference to the experiment or to later deployment? DH =3D Diffie-Hellman, a class of algorithms used for key agreement or key = exchange. Protocols based on these algorithms produce session keys (e.g., for en= cryption) that are computationally infeasible to determine from the messages exc= hanged. integer DH - key agreement based on exponentiation involving large numbers,= 2048 bits is the minimum size that should currently be used. ECDH =3D Elliptic Curve DH. Key agreement based on elliptic curve crypto i= nvolves much smaller numbers - 224-bit ECDH calculations have comparable secur= ity strength to 2048-bit integer DH calculations, although the calculation= s are different. EC calculations are done with respect to a "curve" (effect= ively a set of parameters). > We've > stuck with integer DH for now as the IPR is still cleaner and I'd > rather we had the results of the CFRG work on additional ECDH > curves done and dusted before considering whether to use one of > those or a NIST curve as a possible ECDH MTI as an alternative to > or in addition to integer DH. IPR =3D Intellectual Property Rights - go ask a lawyer, not me ;-). CFRG =3D IRTF Crypto Forum Research Group, a community of cryptographers th= at provides crypto advice to the IETF, see https://irtf.org/cfrg. NIST =3D National Institute of Standards and Technology (US government agen= cy). NIST curve - One of the NIST-specified curves for EC crypto. The NIST curv= es are currently the most commonly used for EC crypto in IETF standards. The CFRG is in the midst of figuring out what other curves to recomme= nd. MTI =3D Mandatory To Implement. Enjoy, --David ________________________________________ From: mpls [mpls-bounces@ietf.org] on behalf of l.wood@surrey.ac.uk [l.wood= @surrey.ac.uk] Sent: Thursday, January 01, 2015 1:21 PM To: stephen.farrell@cs.tcd.ie; adrian@olddog.co.uk; mpls@ietf.org Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-op= portunistic-encrypt-04.txt Are jargon and acronyms a barrier to meaningful discussion in the ietf? Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls on behalf of Stephen Farrell Sent: Friday, 2 January 2015 1:59:14 AM To: adrian@olddog.co.uk; mpls@ietf.org Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-op= portunistic-encrypt-04.txt On 01/01/15 14:27, Adrian Farrel wrote: > Hi, > > Update is minor. > > - draft-dukhovni-opportunistic-security has been published as RFC > 7435. - Add place-holder section 1.2 "Existing Security Tools for > MPLS Data" Happy to get text help on the MACsec thing there in particular, we can probably write or find help with the IPsec stuff easily enough. > I know a couple of people are considering experimental > implementations and (of course) we would welcome feedback from their > experiences. > > We'd also really appreciate input from people close to silicon to > understand whether what we are proposing is achievable with existing > hardware or would require new silicon. And on the crypto/key agreement side, is integer DH ok when considering that or is ECDH so significantly better that that'd make a difference to the experiment or to later deployment? We've stuck with integer DH for now as the IPR is still cleaner and I'd rather we had the results of the CFRG work on additional ECDH curves done and dusted before considering whether to use one of those or a NIST curve as a possible ECDH MTI as an alternative to or in addition to integer DH. Cheers, S. > > Thanks, Adrian > >> -----Original Message----- From: internet-drafts@ietf.org >> [mailto:internet-drafts@ietf.org] Sent: 01 January 2015 14:22 To: >> Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell >> Subject: New Version Notification for >> draft-farrelll-mpls-opportunistic-encrypt- 04.txt >> >> >> A new version of I-D, >> draft-farrelll-mpls-opportunistic-encrypt-04.txt has been >> successfully submitted by Adrian Farrel and posted to the IETF >> repository. >> >> Name: draft-farrelll-mpls-opportunistic-encrypt Revision:= 04 >> Title: Opportunistic Security in MPLS Networks Document da= te: >> 2015-01-01 Group: Individual Submission Pages: 30 = URL: >> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic- >> >> encrypt-04.txt >> Status: >> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- >> >> encrypt/ >> Htmlized: >> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- >> >> 04 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-farrelll-mpls-opportunistic- >> >> encrypt-04 >> >> Abstract: This document describes a way to apply opportunistic >> security between adjacent nodes on an MPLS Label Switched Path >> (LSP) or between end points of an LSP. It explains how keys may be >> agreed to enable encryption, and how key identifiers are exchanged >> in encrypted MPLS packets. Finally, this document describes the >> applicability of this approach to opportunistic security in MPLS >> networks with an indication of the level of improved security as >> well as the continued vulnerabilities. >> >> This document does not describe security for MPLS control plane >> protocols. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat > > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Jan 2 08:42:07 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807A71A1B5A for ; Fri, 2 Jan 2015 08:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7BmQELtO7sZ for ; Fri, 2 Jan 2015 08:42:02 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5421A1B53 for ; Fri, 2 Jan 2015 08:42:01 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t02GflZJ019774; Fri, 2 Jan 2015 16:41:47 GMT Received: from 950129200 (089144233147.atnat0042.highway.a1.net [89.144.233.147]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t02Gfj35019757 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 2 Jan 2015 16:41:46 GMT From: "Adrian Farrel" To: , , References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , In-Reply-To: Date: Fri, 2 Jan 2015 16:41:45 -0000 Message-ID: <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4gwGyVrHWAcZrwUoBiuknFAIew9ozAdaN47ebHhHAQA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21220.001 X-TM-AS-Result: No--15.389-10.0-31-10 X-imss-scan-details: No--15.389-10.0-31-10 X-TMASE-MatchedRID: PL66URbwWA8/FLJq3yHG9RJEh4A6+HuFNNuh+5zmS69rMbakJN8Oed9e g0lscz7xxo14NaM8rnthql3mlRNuk2KplHd7ThK1XP5rFAucBUG0NJ9wxH7tk528BBVhm7jvgLo L7L33TP81Ag1KKGopD0VSoBGv+X5Y2qjKAYV8LUbcWo5Vvs8MQiOSuAnftGqP+Cckfm+bb6At2I l6WUBZ/xS+mUA0xMf28HLzq3q4RwTCOnm2lvjRgGtGlKM15tA2M2ts1frI8ep0QbvL4PujkLy+A bgLgbEpVqAFhhKN3GKUl3YiKaOD0th8848Kmd8CjhXy0Khej9J12bvfrQXWBaMVwpOQMj2MqAXw sdh85gb90TkpI5Gh2oBH6yFwyE6p1xQ2OgXti5WvPooS+PUQcgc2tG0iYoZPVjh537f64a1YqgM pOy5G5IHIAxUqIdIdQc+6gpnsX17ztD9H00RsqxzGdGwheTCgh8Ytn75ClDO2F4a+vI22PqGR3X pyK3SHHFveSbgtUqKRk6XtYogiarQ/aqQZTRfKC24oEZ6SpSk+Mqg+CyrtwA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mKwp6Vdhji8UKr1rZbFT-BuCM8w Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 16:42:04 -0000 Lloyd, It would be excellent to have the discussion of whether it is inappropriate or even impossible to provide security at the MPLS layer. My view was that the overhead of managed security associations in an MPLS network where relationships were n-squared times "class of service" was a limiting factor. This draft discusses some of the issues, and it is intended that section 1.2 will add a discussion of security-over (e.g., IPsec) and security-under (e.g., MACsec). Both of these have a part to play in security in MPLS networks, but it is not clear that they deliver everything you need. The discussion of Opportunistic Security and some of the lessons coming out of growing awareness of fibre-tap and untrusted routers leads to the thought that per hop layer 2 security may provide a lot of benefits, but that MPLS security might also have value. This draft is targeted at Experimental and several people have stated that they intend to experiment with it. >From a protocol point of view, I think that this working group is the right place to discuss how to negotiate the use of security and how to encode the security parameters on the wire. I don't believe this working group is the right place to determine what those parameters are, and I rely on security whizzards to tell me what information I need to carry. As far as "mandatory to implement" is concerned, Stephen and I might have some small disagreement :-) Nothing documented now is likely to be mandatory to implement in existing implementations. Therefore, this experiment (even were it to be standards track) would not be anything more than a strong recommendation for as many years as it takes to upgrade a lot of boxes - and so, of course, the document has to describe what happens if one or more routers in the network do not support these security mechanisms. This opens up the possibility of downgrade attacks, and the document observes that how you respond to a request to downgrade depends on how much you want to secure the data. However, once someone has decided to implement this document, there is value in observing that, from a set of security algorithms that are possible to support, there should be a common subset that all implementations will support - absent that, there is a high chance of lack of interop even between implementations of this document. So, to that extent, it is valuable to talk about mandatory to implement. Thanks for your interest in this work. Adrian > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: 02 January 2015 13:57 > To: david.black@emc.com; stephen.farrell@cs.tcd.ie; adrian@olddog.co.uk; > mpls@ietf.org > Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls- > opportunistic-encrypt-04.txt > > More a barrier to discussion is that a conversation about anything can now be > derailed into a conversation about security, because all groups are security > groups. > > The pressing question for mpls has always been not whether mpls requires > security, not what security mpls should have, but exactly what type of elliptic > curve to use. Good that we're attempting to answer that, no? From nobody Sat Jan 3 07:39:00 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9D41A874E; Sat, 3 Jan 2015 07:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwIT2SPtmu8V; Sat, 3 Jan 2015 07:38:54 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id C3D001A1B72; Sat, 3 Jan 2015 07:38:54 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CAC4518048B; Sat, 3 Jan 2015 07:38:40 -0800 (PST) To: gregory.mirsky@ericsson.com, eric.gray@ericsson.com, nitinb@juniper.net, sboutros@cisco.com, raggarwa_1@yahoo.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150103153840.CAC4518048B@rfc-editor.org> Date: Sat, 3 Jan 2015 07:38:40 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-b-7dVM9IZPAuF9M2fG_933Kfhg Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, mpls@ietf.org Subject: [mpls] [Errata Verified] RFC6426 (4012) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 15:38:57 -0000 The following errata report has been verified for RFC6426, "MPLS On-Demand Connectivity Verification and Route Tracing". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6426&eid=4012 -------------------------------------- Status: Verified Type: Technical Reported by: Gregory Mirsky Date Reported: 2014-06-10 Verified by: Adrian Farrel (IESG) Section: 7.6 Original Text ------------- Missing section Corrected Text -------------- 7.6 New Global Flags Bit RFC 6425 defines a registry for "Global Flags" under the "Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping Parameters" registry. This document defines a new Global Flag, "Validate Reverse Path (R)". IANA has added this flag to the registry as follows: Bit number | Name | Reference ------------+----------------------------+-------------- 13 | Validate Reverse Path | [RFC 6426] Notes ----- "Global Flags" registry was created per request of RFC 6425 and did not yet existed when RFC 6426 was published leading to the fumbling of this allocation. This "race condition" has to be fixed to avoid possible name-space collision between RFC 6426 and new extensions to LSP ping. -------------------------------------- RFC6426 (draft-ietf-mpls-tp-on-demand-cv-07) -------------------------------------- Title : MPLS On-Demand Connectivity Verification and Route Tracing Publication Date : November 2011 Author(s) : E. Gray, N. Bahadur, S. Boutros, R. Aggarwal Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Sat Jan 3 07:44:00 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90851A874B; Sat, 3 Jan 2015 07:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoSHgD2jfj-7; Sat, 3 Jan 2015 07:43:58 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86731A1B72; Sat, 3 Jan 2015 07:43:57 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t03FflJn002685; Sat, 3 Jan 2015 15:41:48 GMT Received: from 950129200 (089144224044.atnat0033.highway.a1.net [89.144.224.44]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t03Ffk8m002662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 3 Jan 2015 15:41:47 GMT From: "Adrian Farrel" To: Date: Sat, 3 Jan 2015 15:41:46 -0000 Message-ID: <001f01d0276b$c94e24f0$5bea6ed0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAna8UmaMOSa+ptRxqyhiCKmOSsLQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21222.000 X-TM-AS-Result: No--3.384-10.0-31-10 X-imss-scan-details: No--3.384-10.0-31-10 X-TMASE-MatchedRID: NqyQsIt6HqLJMGDPqGXR12ivjLE8DPtZ9xIiieITJagz91mDYZLM5QnZ 9MS7q5+g1DC3jwi5yfCwv/seOJZqgiTtChVcJtE4Ic33OEsY0c0ax3hQAS8V1Qpcq1+LTpsUo8W MkQWv6iV95l0nVeyiuBQF+BLVItD4C24oEZ6SpSmcfuxsiY4QFHMhQgIV1g5srbNrjjnztfh6Vj JTvKB8jd1URE8Pu1fD6GedSHWbZdwfKUWLJqLxkSmVqNPs6637+xhlPPxK2R3mU+XlH4NiWeQ/b JqlQQ/copZ51QxAj3fx+wL7E8WTG+w2n3R9PgSOsBTJSD2iAW0= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/I9X5F5c7-wQ596sEFOl-b9mr80w Cc: mpls@ietf.org, iesg@ietf.org Subject: [mpls] IANA action on Errata Report 4012 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 15:44:00 -0000 Hello IANA and Happy New Year, Please allocate the code point 2015 :-) I have just verified http://www.rfc-editor.org/errata_search.php?eid=4012 This captures an IANA action that was omitted from RFC 6426 but which was clearly intended by the authors and the working group. Could you please action this citing RFC 6426 and this Errata Report as the references. Thanks, Adrian From nobody Sun Jan 4 21:00:13 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC81A1ABC for ; Sun, 4 Jan 2015 21:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sUCRBPrv6Hv for ; Sun, 4 Jan 2015 21:00:09 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B021A1A7F for ; Sun, 4 Jan 2015 21:00:09 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.169.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C43AF180155B; Mon, 5 Jan 2015 06:00:04 +0100 (CET) Message-ID: <54AA1A4D.7010301@pi.nu> Date: Mon, 05 Jan 2015 12:59:57 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_jvX292Z4CdTkme245gyaRWv_fI Cc: "" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-rsvp-te-hsmp-lsp@tools.ietf.org Subject: [mpls] Plan to kill draft-ietf-mpls-rsvp-te-hsmp-lsp (two week notice) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 05:00:12 -0000 Woeking Group, We have a working group draft (and a corresponding milestone) - draft-ietf-mpls-rsvp-te-hsmp-lsp - that seems to have run out of steem (or out of application as one of the co-authors put it). The draft is expired and we have moved the milestone a couple of times. We've also polled the authors but the only response we have seen so far is that there is no interest to continue working on the draft. Unless we have someone step up and claim an interest to work with the draft and is able to commit cycles to do so the wg chairs will kill the draft by the end of next week (January 16th) and we will also remove the milestone. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jan 5 06:30:44 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D36B1A888A; Mon, 5 Jan 2015 06:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAdPDY-26UPf; Mon, 5 Jan 2015 06:30:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D50F71A8864; Mon, 5 Jan 2015 06:30:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105143028.3874.77102.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 06:30:28 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UNHj3bLN_nfet633-ONh8OzKZKA Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:30:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification Authors : Nobo Akiya George Swallow Carlos Pignataro Loa Andersson Mach(Guoyi) Chen Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-01.txt Pages : 12 Date : 2015-01-05 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the "Reply via Specified Path (5)" Reply Mode value to easily indicate the reverse LSP. This document also adds an optional TLV which can carry ordered list of Reply Mode values. This document updates RFC4379 and RFC7110. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mode-simple/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simple-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-reply-mode-simple-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 5 06:49:55 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE8B1A88CE for ; Mon, 5 Jan 2015 06:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.211 X-Spam-Level: X-Spam-Status: No, score=-112.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sspm-dT38nNB for ; Mon, 5 Jan 2015 06:49:50 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A2D1A88CA for ; Mon, 5 Jan 2015 06:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=794; q=dns/txt; s=iport; t=1420469390; x=1421678990; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g0BckBuWsVndbM4zmdt0QYSr1fmaUnNP9cOb/3EPoQw=; b=lx2S9rUKWrln0uKHnZcwnlRhcSUP+jVCm3cM9Tf+NhveJS2/z3EW+8gS upvd65XAswEAWsJHBmYaycUSU4dUOAbKpalkvcXba+nOHNqjnSyYwAmWK bMzzti9lKfY3O+itsuEQGyAbtso7SO+3vGFiFa5LXy+XBPm/o3L6D6XOt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0HAHmjqlStJV2U/2dsb2JhbABcgmQiUlMGA8YehXECgQgWAQEBAQF9hA0BAQQ6PxACAQgiFBAyJQIEAQ0NAYgjAQcFvFsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0YxB4MWgRMFjD6BV4M/hnGQEyKDboI0fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,700,1413244800"; d="scan'208";a="384498999" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jan 2015 14:49:50 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t05EnnNR004598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 14:49:49 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 08:49:49 -0600 From: "Nobo Akiya (nobo)" To: "Aissaoui, Mustapha (Mustapha)" , Mach Chen , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX7qUs104RkB0qetEn/yhEdopv0IawwgEFPqICAArRj8IACsOyAgACHbwCAAI7IgIABeaCA//+waQCAdT9icA== Date: Mon, 5 Jan 2015 14:49:49 +0000 Message-ID: References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D94772FAD@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D9477F433@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/nItwc7WAO7K-ukLWtrjq1VyynJ4 Cc: "Ross Callon \(rcallon@juniper.net\)" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:49:53 -0000 Hello Mustapha, MPLS WG, Happy new year! We have rolled out-01 of draft-ietf-mpls-lsp-ping-reply-mode-simple that in= corporated what we converged on. Which essentially are: > - Reply Mode 5 with no Reply Path TLV is no longer an error. > - Reply Mode 5 with no Reply Path TLV implies reverse LSP. The document now updates RFC7110. Links to -01 below. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mode-simple= / There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simple-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-reply-mode-simp= le-01 Thanks! -Nobo From nobody Mon Jan 5 09:00:28 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF621A6FBC for ; Mon, 5 Jan 2015 09:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmoaLudcOPEp for ; Mon, 5 Jan 2015 09:00:00 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1611A6F04 for ; Mon, 5 Jan 2015 08:59:40 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 131so10544948ykp.3 for ; Mon, 05 Jan 2015 08:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3G58jZmGOxOjwt7F8Z3VsOICoCk1JjKI8YSA2eEynQ8=; b=Iu2leaOh/7wVpsr65iGact+PgAtU6YV8wXNs5oKvTbi8qIU0QDKkAFRZ/GeHBRY7lS RoUQjawGhu1hFSBU1K/dWmH8eTTANGR2eL64gUSWLYPAx0AOvk5XX4+OLqKyu2Dner2B /SBB8g9LWnC0doN77HD7kT8NWcd6zgW03Hte8O9WTDftRBA2//vDOsNdqoZEbCfbV5yM i/ivmEZ+aZEEhm5ZF6TvE2C9Mz4sUSeIWzS8d2A9mKHVHnbfoBMmHY/Cc8aqa4suqW4V S6+0u43Cb+ChCGSD4ZdjVu2cF2OX/X7KQowRSPHXsGgUfCAHVHSo5oV7CZEc+jm1QhMU V3rA== MIME-Version: 1.0 X-Received: by 10.170.218.212 with SMTP id k203mr65517696ykf.15.1420477179610; Mon, 05 Jan 2015 08:59:39 -0800 (PST) Received: by 10.170.133.18 with HTTP; Mon, 5 Jan 2015 08:59:39 -0800 (PST) In-Reply-To: <201412180211.sBI2BBW53068@magenta.juniper.net> References: <20141217200749.EAB02181CD8@rfc-editor.org> <201412172105.sBHL52u19645@magenta.juniper.net> <201412172141.sBHLfqu40272@magenta.juniper.net> <201412180211.sBI2BBW53068@magenta.juniper.net> Date: Mon, 5 Jan 2015 11:59:39 -0500 Message-ID: From: Alia Atlas To: Yakov Rekhter Content-Type: multipart/alternative; boundary=001a113a83b6b3fadd050bea9d74 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sBoAoXRreyDTMMtjmzQ89OX4MJw Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] [Technical Errata Reported] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:00:18 -0000 --001a113a83b6b3fadd050bea9d74 Content-Type: text/plain; charset=UTF-8 Yakov, I've modified the Errata to suggest extending the text slightly as follows: Section 6 says: Whenever the PLR has a backup path available, the PLR MUST set the "local protection available" flag. It should say: Whenever the PLR has a backup path available, the PLR MUST set the "local protection available" flag. For example, if the PLR has determined to use a bypass tunnel and set up the necessary local forwarding state to be able to use it as a backup path, then that PLR has a backup path available. Assuming that's ok with the WG, Adrian or I can approve it. Regards, Alia On Wed, Dec 17, 2014 at 9:11 PM, Yakov Rekhter wrote: > Alia, > > > > Alia, > > > > > > > Yakov, > > > > > > > > On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter > > > wrote: > > > > > > > > > Alia, > > > > > > > > > > > Hi Yakov, > > > > > > > > > > > > Could you clarify your point for this errata? In RFC 4090, in > the > > > > > > terminology it says: > > > > > > "Backup Path: The LSP that is responsible for backing up one > > > > > > protected LSP. A backup path refers to > > > > > > either a detour LSP or a backup tunnel. > > > > > > > > > > > > Backup Tunnel: The LSP that is used to backup up one of the > many > > > > > > LSPs in many-to-one backup." > > > > > > > > > > In the terminology it also says: > > > > > > > > > > "Bypass Tunnel: An LSP that is used to protect a set of LSPs > > > > > passing over a common facility." > > > > > > > > > > My point is that (unless the term "bypass tunnel" means the same > > > > > as "backup path" or "backup tunnel") in many-to-one backup > > > > > the "local protection available" flag for a given protected LSP > > > > > MUST be set when the PLR has a *bypass* tunnel for that LSP. > > > > > > > > > > > > > Ah - ok. A backup path that uses a bypass tunnel is not just the > bypass > > > > tunnel itself. > > > > > > Correct. > > > > > > > There's the state associated for the protected LSP that > > > > also needs to be created and installed. In more concrete terms, this > > > > is installing an out-segment with the appropriate label for the > protected > > > > LSP to be understood by the merge point as > > > > well as an outer label for the bypass LSP. > > > > > > > > So, the text refers to a backup path instead of a bypass tunnel > because > > > > having the bypass tunnel isn't quite sufficient. > > > > Does that make sense to you? > > > > > > The current text is incorrect. This is because a PLR may signal a > > > backup path at the time of failure. Yet, one should not wait for > > > the failure to set the "local protection available" flag. The PLR > > > should set this flag as soon as it has a *bypass* tunnel. > > > > The backup path is created by the PLR before the failure and thus, before > > the associated signaling. Once the PLR has done the work to create > > a backup path using an existing bypass tunnel - which is internal > > work - then the PLR should set the "local protection available" flag. > > Perhaps we should step back and ask whether the quote from section 6: > > Whenever the PLR has a backup path available, the PLR MUST set > the "local protection available" flag. > > talks about forwarding state or control plane state. Is there > any text in rfc4090 that answers this question ? > > Yakov. > > > > > Alia > > > > > > > > > Yakov. > > > > > > > > > > > Regards, > > > > Alia > > > > > > > > > > > > > Yakov. > > > > > > > > > > > Thanks, > > > > > > Alia > > > > > > > > > > > > On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System < > > > > > > rfc-editor@rfc-editor.org> wrote: > > > > > > > > > > > > > The following errata report has been submitted for RFC4090, > > > > > > > "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". > > > > > > > > > > > > > > -------------------------------------- > > > > > > > You may review the report below and at: > > > > > > > http://www.rfc-editor.org/errata_search.php?rfc=4090&eid=4203 > > > > > > > > > > > > > > -------------------------------------- > > > > > > > Type: Technical > > > > > > > Reported by: Yakov Rekhter > > > > > > > > > > > > > > Section: 6 > > > > > > > > > > > > > > Original Text > > > > > > > ------------- > > > > > > > Whenever the PLR has a backup path available, the PLR MUST set > > > > > > > the "local protection available" flag. > > > > > > > > > > > > > > > > > > > > > Corrected Text > > > > > > > -------------- > > > > > > > Whenever the PLR has a one-to-one backup LSP or bypass tunnel > > > > > > > available, the PLR MUST set the "local protection available" > flag. > > > > > > > > > > > > > > > > > > > > > Notes > > > > > > > ----- > > > > > > > In the case of facility-based FRR the PLR must set the "local > > > > > protection > > > > > > > available" flag if it has the bypass tunnel available. > > > > > > > > > > > > > > Instructions: > > > > > > > ------------- > > > > > > > This erratum is currently posted as "Reported". If necessary, > > > please > > > > > > > use "Reply All" to discuss whether it should be verified or > > > > > > > rejected. When a decision is reached, the verifying party > (IESG) > > > > > > > can log in to change the status and edit the report, if > necessary. > > > > > > > > > > > > > > -------------------------------------- > > > > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07) > > > > > > > -------------------------------------- > > > > > > > Title : Fast Reroute Extensions to RSVP-TE for > LSP > > > > > Tunnels > > > > > > > Publication Date : May 2005 > > > > > > > Author(s) : P. Pan, Ed., G. Swallow, Ed., A. Atlas, > Ed. > > > > > > > Category : PROPOSED STANDARD > > > > > > > Source : Multiprotocol Label Switching > > > > > > > Area : Routing > > > > > > > Stream : IETF > > > > > > > Verifying Party : IESG > > > > > > > > > > > > > > > > > > > > > > > > > > --001a11397a2c9bda6e050a6f31ae > > > > > > Content-Type: text/html; charset="UTF-8" > > > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > >
Hi Yakov,

Could you clarify your point > for > > > this > > > > > err= > > > > > > ata?=C2=A0 In RFC 4090, in the terminology it says:
" > Backup > > > > > Path: = > > > > > > The LSP that is responsible for backing up one
=C2=A0 =C2=A0 > > > =C2=A0 > > > > > =C2= > > > > > > =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0protected > > > > > LSP.= > > > > > > =C2=A0 A backup path refers to either a detour LSP
=C2=A0 > =C2=A0 > > > > > =C2=A0 = > > > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or > a > > > > > backup t= > > > > > > unnel.

=C2=A0 Backup Tunnel: The LSP that is used to > backup up > > > > > one o= > > > > > > f the many
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 > > > > > =C2= > > > > > > =A0LSPs in many-to-one > > > > > backup."

Thanks,
A= > > > > > > lia

> > > > class=3D"gmail_quote">On= > > > > > > Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System > > > > dir=3D"ltr">< > > > > > ref=3D"mailto:rfc-editor@rfc-editor.org" > > > > > target=3D"_blank">rfc-editor@rfc-e= > > > > > > ditor.org> wrote:
class=3D"gmail_quote" > > > > > style= > > > > > > =3D"margin:0 0 0 .8ex;border-left:1px #ccc > > > solid;padding-left:1ex">The > > > > > foll= > > > > > owing errata report has been submitted for RFC4090,
> > > > > > "Fast Reroute Extensions to RSVP-TE for LSP > Tunnels".
> > > > > >
> > > > > > --------------------------------------
> > > > > > You may review the report below and at:
> > > > > > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4090&eid= > > > > > > =3D4203" target=3D"_blank"> > > > > > http://www.rfc-editor.org/errata_search.php?rfc= > > > > > > =3D4090&eid=3D4203
> > > > > >
> > > > > > --------------------------------------
> > > > > > Type: Technical
> > > > > > Reported by: Yakov Rekhter < yakov@juniper.net > > > > > ">yakov@j= > > > > > > uniper.net>
> > > > > >
> > > > > > Section: 6
> > > > > >
> > > > > > Original Text
> > > > > > -------------
> > > > > > Whenever the PLR has a backup path available, the PLR MUST > set
> > > > > > the "local protection available" flag.
> > > > > >
> > > > > >
> > > > > > Corrected Text
> > > > > > --------------
> > > > > > Whenever the PLR has a one-to-one backup LSP or bypass tunnel
> > > > > > available, the PLR MUST set the "local protection > > > available" > > > > > flag= > > > > > > .
> > > > > >
> > > > > >
> > > > > > Notes
> > > > > > -----
> > > > > > In the case of facility-based FRR the PLR must set the > "local > > > > > protecti= > > > > > > on available" flag if it has the bypass tunnel > available.
> > > > > >
> > > > > > Instructions:
> > > > > > -------------
> > > > > > This erratum is currently posted as "Reported". If > > > necessary, > > > > > ple= > > > > > > ase
> > > > > > use "Reply All" to discuss whether it should be > verified > > > or
> > > > > > rejected. When a decision is reached, the verifying party > (IESG)
> > > > > > can log in to change the status and edit the report, if > > > necessary.
> > > > > >
> > > > > > --------------------------------------
> > > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07)
> > > > > > --------------------------------------
> > > > > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: > Fast > > > > > Reroute = > > > > > > Extensions to RSVP-TE for LSP Tunnels
> > > > > > Publication Date=C2=A0 =C2=A0 : May 2005
> > > > > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: P. Pan, Ed., > G. > > > > > Swallow= > > > > > > , Ed., A. Atlas, Ed.
> > > > > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED > > STANDARD
> > > > > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : > > > Multiprotocol > > > > > Labe= > > > > > > l Switching
> > > > > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : > > > Routing
> > > > > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> > > > > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
> > > > > >
> > > > > >

> > > > > > > > > > > > --001a11397a2c9bda6e050a6f31ae-- > > > > > > > > > > > > > --047d7b5d99a33a914b050a70164e > > > > Content-Type: text/html; charset="UTF-8" > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > >
Yakov,

> > class=3D"gmail_q= > > > > uote">On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter > > dir=3D"ltr"><= > > > > > yakov@juniper.net > > > > > > >> wrote:
> > style=3D"margin:0 = > > > > 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Alia,
> > > >
> > > > > Hi Yakov,
> > > > >
> > > > > Could you clarify your point for this errata?=C2=A0 In RFC > 4090, in > > > th= > > > > e
> > > > > terminology it says:
> > > > >=C2=A0 "Backup Path: The LSP that is responsible for > backing up > > > on= > > > > e
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > > =C2=A0 = > > > > =C2=A0 =C2=A0 protected LSP.=C2=A0 A backup path refers to either > a
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > > =C2=A0 = > > > > =C2=A0 =C2=A0 detour LSP or a backup tunnel.
> > > > >
> > > > >=C2=A0 =C2=A0Backup Tunnel: The LSP that is used to backup up > one of > > > th= > > > > e many
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > LSPs > > > in = > > > > many-to-one backup."
> > > >
> > > > In the terminology it also says:
> > > >
> > > > =C2=A0 =C2=A0"Bypass Tunnel: An LSP that is used to protect a > set > > > of L= > > > > SPs
> > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 passing over a common > > > facility.&q= > > > > uot;
> > > >
> > > > My point is that (unless the term "bypass tunnel" means the > > > same<= > > > > br> > > > > as "backup path" or "backup tunnel") in > many-to-one > > > bac= > > > > kup
> > > > the "local protection available" flag for a given protected > > > LSP > > > r> > > > > MUST be set when the PLR has a *bypass* tunnel for that > > > LSP.
> > > e>

Ah - ok.=C2=A0 A backup path that uses a bypass > > > tunne= > > > > l is not just the bypass tunnel
itself.=C2=A0 There's > the > > > sta= > > > > te associated for the protected LSP that also needs to > > > be
created= > > > > and installed.=C2=A0 In more concrete terms, this is installing an > > > out-seg= > > > > ment with=C2=A0
the appropriate label for the protected > LSP to > > > be= > > > > understood by the merge point as
well as an outer label > for > > > the = > > > > bypass LSP.

So, the text refers to a backup > > > path i= > > > > nstead of a bypass tunnel because having the
bypass tunnel > > > isn= > > > > 9;t quite sufficient.=C2=A0 Does that make sense to > > > you?

> > > v>
Regards,
Alia
=C2=A0
> > class=3D"g= > > > > mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc > > > solid;padding-l= > > > > eft:1ex"> > > > > Yakov.
> > > >

> > > > > Thanks,
> > > > > Alia
> > > > >
> > > > > On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System <
> > > > > > > > rfc-editor@rfc-editor.org= > > > > > wrote:
> > > > >
> > > > > > The following errata report has been submitted for > RFC4090,
> > > > > > "Fast Reroute Extensions to RSVP-TE for LSP > > > Tunnels". > > > r> > > > > > >
> > > > > > --------------------------------------
> > > > > > You may review the report below and at:
> > > > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4090= > > > > &eid=3D4203" target=3D"_blank"> > > > http://www.rfc-editor.org/errata_search.= > > > > php?rfc=3D4090&eid=3D4203
> > > > > >
> > > > > > --------------------------------------
> > > > > > Type: Technical
> > > > > > Reported by: Yakov Rekhter < > > yakov@juniper.ne= > > > > t">yakov@juniper.net>
> > > > > >
> > > > > > Section: 6
> > > > > >
> > > > > > Original Text
> > > > > > -------------
> > > > > > Whenever the PLR has a backup path available, the PLR MUST > > > set > > > > > > > > > > the "local protection available" flag.
> > > > > >
> > > > > >
> > > > > > Corrected Text
> > > > > > --------------
> > > > > > Whenever the PLR has a one-to-one backup LSP or bypass > > > tunnel
> > > > > > available, the PLR MUST set the "local protection > > > available&= > > > > quot; flag.
> > > > > >
> > > > > >
> > > > > > Notes
> > > > > > -----
> > > > > > In the case of facility-based FRR the PLR must set the > > > "loca= > > > > l protection
> > > > > > available" flag if it has the bypass tunnel > available.
> > > > > >
> > > > > > Instructions:
> > > > > > -------------
> > > > > > This erratum is currently posted as "Reported". > If > > > nece= > > > > ssary, please
> > > > > > use "Reply All" to discuss whether it should be > > > verifie= > > > > d or
> > > > > > rejected. When a decision is reached, the verifying party > > > (IESG)<= > > > > br> > > > > > > can log in to change the status and edit the report, if > > > necessary= > > > > .
> > > > > >
> > > > > > --------------------------------------
> > > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07)
> > > > > > --------------------------------------
> > > > > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0: > > > Fas= > > > > t Reroute Extensions to RSVP-TE for LSP Tunnels
> > > > > > Publication Date=C2=A0 =C2=A0 : May 2005
> > > > > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: P. Pan, > > > Ed., = > > > > G. Swallow, Ed., A. Atlas, Ed.
> > > > > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : > PROPOSED > > > STAN= > > > > DARD
> > > > > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : > > > Multipro= > > > > tocol Label Switching
> > > > > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 : > > > Rou= > > > > ting
> > > > > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : > > > IETF
> > > > > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
> > > > > >
> > > > > >
> > > > >
> > > >
> --001a11397a2c9bda6e050a6f31ae
> > > > > Content-Type: text/html; charset=3D"UTF-8"
> > > > > Content-Transfer-Encoding: quoted-printable
> > > > >
> > > > > <div dir=3D3D"ltr">Hi > > > Yakov,<br><br>Could = > > > > you clarify your point for this err=3D
> > > > > ata?=3DC2=3DA0 In RFC 4090, in the terminology it > > > says:<br>&= > > > > quot; Backup Path: =3D
> > > > > The LSP that is responsible for backing up > one<br>=3DC2=3DA0 > > > =3D= > > > > C2=3DA0 =3DC2=3DA0 =3DC2=3D
> > > > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > > > =3DC2=3DA= > > > > 0 =3DC2=3DA0 =3DC2=3DA0protected LSP.=3D
> > > > > =3DC2=3DA0 A backup path refers to either a detour > > > LSP<br>=3DC2= > > > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D
> > > > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2=3DA0 > > > =3DC= > > > > 2=3DA0 =3DC2=3DA0 =3DC2=3DA0or a backup t=3D
> > > > > unnel.<br><br>=3DC2=3DA0 Backup Tunnel: The LSP > that is > > > us= > > > > ed to backup up one o=3D
> > > > > f the many<br>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > > > =3DC2= > > > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3D
> > > > > =3DA0LSPs in many-to-one > > > backup.&quot;<div><br></di= > > > > v><div>Thanks,</div><div>A=3D
> > > > > lia</div></div><div > > > class=3D3D"gmail_extra"&g= > > > > t;<br><div class=3D3D"gmail_quote">On=3D
> > > > >=C2=A0 Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System <span > > > dir=3D3= > > > > D"ltr">&lt;<a h=3D
> > > > > ref=3D3D"mailto: rfc-editor@rfc-editor.org > > > ">rfc-= > > > > editor@rfc-editor.org" > > > target=3D3D"_blank">rfc-editor= > > > > @rfc-e=3D
> > > > > ditor.org > > > </a>= > > > > &gt;</span> wrote:<br><blockquote > > > class=3D3D"gmail_= > > > > quote" style=3D
> > > > > =3D3D"margin:0 0 0 .8ex;border-left:1px #ccc > > > solid;padding-left:1= > > > > ex">The foll=3D
> > > > owing errata report has been submitted for RFC4090,<br>
> > > > > &quot;Fast Reroute Extensions to RSVP-TE for LSP > > > Tunnels&quot;= > > > > .<br>
> > > > > <br>
> > > > > --------------------------------------<br>
> > > > > You may review the report below and at:<br>
> > > > > <a href=3D3D" > > http://www.rfc-editor.org/errata_searc= > > > > h.php?rfc=3D3D4090&amp;eid=3D" target=3D"_blank"> > > > http://www.rfc-editor.= > > > > org/errata_search.php?rfc=3D3D4090&amp;eid=3D
> > > > > =3D3D4203" target=3D3D"_blank"> > > http://www= > > > > .rfc-editor.org/errata_search.php?rfc=3D" target=3D"_blank"> > > > http://www.rfc-= > > > > editor.org/errata_search.php?rfc=3D
> > > > > =3D3D4090&amp;eid=3D3D4203</a><br>
> > > > > <br>
> > > > > --------------------------------------<br>
> > > > > Type: Technical<br>
> > > > > Reported by: Yakov Rekhter &lt;<a href=3D3D"mailto: > > > href= > > > > =3D"mailto:yakov@juniper.net">yakov@juniper.net">yakov@j > > > =3D
> > > > > uniper.net > > > </a&g= > > > > t;&gt;<br>
> > > > > <br>
> > > > > Section: 6<br>
> > > > > <br>
> > > > > Original Text<br>
> > > > > -------------<br>
> > > > > Whenever the PLR has a backup path available, the PLR MUST > > > set<br&g= > > > > t;
> > > > > the &quot;local protection available&quot; > > > flag.<br>
> > > > > <br>
> > > > > <br>
> > > > > Corrected Text<br>
> > > > > --------------<br>
> > > > > Whenever the PLR has a one-to-one backup LSP or bypass > > > tunnel<br>= > > > > ;
> > > > > available, the PLR MUST set the &quot;local protection > > > available&a= > > > > mp;quot; flag=3D
> > > > > .<br>
> > > > > <br>
> > > > > <br>
> > > > > Notes<br>
> > > > > -----<br>
> > > > > In the case of facility-based FRR the PLR must set the > > > &quot;local= > > > > protecti=3D
> > > > > on available&quot; flag if it has the bypass tunnel > > > available.<= > > > > br>
> > > > > <br>
> > > > > Instructions:<br>
> > > > > -------------<br>
> > > > > This erratum is currently posted as > &quot;Reported&quot;. > > > If n= > > > > ecessary, ple=3D
> > > > > ase<br>
> > > > > use &quot;Reply All&quot; to discuss whether it should > be > > > veri= > > > > fied or<br>
> > > > > rejected. When a decision is reached, the verifying party > > > (IESG)<br= > > > > >
> > > > > can log in to change the status and edit the report, if > > > necessary.<= > > > > br>
> > > > > <br>
> > > > > --------------------------------------<br>
> > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07)<br>
> > > > > --------------------------------------<br>
> > > > > Title=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > > > =3DC2=3DA0= > > > > =3DC2=3DA0 =3DC2=3DA0: Fast Reroute =3D
> > > > > Extensions to RSVP-TE for LSP Tunnels<br>
> > > > > Publication Date=3DC2=3DA0 =3DC2=3DA0 : May 2005<br>
> > > > > Author(s)=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > > > =3DC2= > > > > =3DA0: P. Pan, Ed., G. Swallow=3D
> > > > > , Ed., A. Atlas, Ed.<br>
> > > > > Category=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > > > =3DC2= > > > > =3DA0 : PROPOSED STANDARD<br>
> > > > > Source=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > > > =3DC2=3DA= > > > > 0 =3DC2=3DA0 : Multiprotocol Labe=3D
> > > > > l Switching<br>
> > > > > Area=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > > > =3DC2=3DA0 = > > > > =3DC2=3DA0 =3DC2=3DA0 : Routing<br>
> > > > > Stream=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > > > =3DC2=3DA= > > > > 0 =3DC2=3DA0 : IETF<br>
> > > > > Verifying Party=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0: > IESG<br>
> > > > > <br>
> > > > > </blockquote></div><br></div>
> > > > >
> > > > > --001a11397a2c9bda6e050a6f31ae--
> > > >

> > > > > > > > --047d7b5d99a33a914b050a70164e-- > > > > > > > --001a11c1e9ee40fd19050a7068c9 > > Content-Type: text/html; charset="UTF-8" > > Content-Transfer-Encoding: quoted-printable > > > >
Yakov,

class=3D"gmail_q= > > uote">On Wed, Dec 17, 2014 at 4:41 PM, Yakov Rekhter dir=3D"ltr"><= > > yakov@juniper.net > > >> wrote:
style=3D"margin:0 = > > 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Alia,
> >
> > > Yakov,
> > >
> > > On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter < href=3D"mailto:y= > > akov@juniper.net">yakov@juniper.net> wrote:
> > >
> > > > Alia,
> > > >
> > > > > Hi Yakov,
> > > > >
> > > > > Could you clarify your point for this errata?=C2=A0 In > RFC 4= > > 090, in the
> > > > > terminology it says:
> > > > >=C2=A0 "Backup Path: The LSP that is responsible for > bac= > > king up one
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2= > > =A0 =C2=A0 =C2=A0 =C2=A0 protected LSP.=C2=A0 A backup path refers to > eithe= > > r a
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2= > > =A0 =C2=A0 =C2=A0 =C2=A0 detour LSP or a backup tunnel.
> > > > >
> > > > >=C2=A0 =C2=A0Backup Tunnel: The LSP that is used to backup > up= > > one of the many
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2= > > =A0 LSPs in many-to-one backup."
> > > >
> > > > In the terminology it also says:
> > > >
> > > >=C2=A0 =C2=A0 "Bypass Tunnel: An LSP that is used to > protect = > > a set of LSPs
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0passing over a > com= > > mon facility."
> > > >
> > > > My point is that (unless the term "bypass tunnel" > means= > > the same
> > > > as "backup path" or "backup tunnel") in > many-= > > to-one backup
> > > > the "local protection available" flag for a given > prote= > > cted LSP
> > > > MUST be set when the PLR has a *bypass* tunnel for that > LSP.
> > > >
> > >
> > > Ah - ok.=C2=A0 A backup path that uses a bypass tunnel is not just > the= > > bypass
> > > tunnel itself.
> >
> > Correct.
> >
> > > There's the state associated for the protected LSP that
> > > also needs to be created and installed.=C2=A0 In more concrete > terms, = > > this
> > > is installing an out-segment with the appropriate label for the > protec= > > ted
> > > LSP to be understood by the merge point as
> > > well as an outer label for the bypass LSP.
> > >
> > > So, the text refers to a backup path instead of a bypass tunnel > becaus= > > e
> > > having the bypass tunnel isn't quite sufficient.
> > > Does that make sense to you?
> >
> > The current text is incorrect. This is because a PLR may signal > a > > > > backup path at the time of failure. Yet, one should not wait for
> > the failure to set the "local protection available" flag. The > PLR= > >
> > should set this flag as soon as it has a *bypass* > tunnel.
<= > > div>
The backup path is created by the PLR before the > failure= > > and thus, before the
associated signaling.=C2=A0 Once the PLR > ha= > > s done the work to create a backup path using
an existing > bypass = > > tunnel - which is internal work - then the PLR should set
the > &qu= > > ot;local protection available" flag. > =C2=A0

A= > > lia=C2=A0

=C2=A0
class=3D"gma= > > il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc > solid;padding-lef= > > t:1ex"> > > Yakov.
> >

> > >
> > > Regards,
> > > Alia
> > >
> > >
> > > > Yakov.
> > > >
> > > > > Thanks,
> > > > > Alia
> > > > >
> > > > > On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System > <
> > > > > ">rfc-editor@rfc-= > > editor.org> wrote:
> > > > >
> > > > > > The following errata report has been submitted for > RFC4= > > 090,
> > > > > > "Fast Reroute Extensions to RSVP-TE for LSP > Tunnel= > > s".
> > > > > >
> > > > > > --------------------------------------
> > > > > > You may review the report below and at:
> > > > > > http://www.rfc-editor.org/errata_search.php?= > > rfc=3D4090&eid=3D4203" target=3D"_blank"> > http://www.rfc-editor.org/erra= > > ta_search.php?rfc=3D4090&eid=3D4203
> > > > > >
> > > > > > --------------------------------------
> > > > > > Type: Technical
> > > > > > Reported by: Yakov Rekhter < yakov@= > > juniper.net">yakov@juniper.net>
> > > > > >
> > > > > > Section: 6
> > > > > >
> > > > > > Original Text
> > > > > > -------------
> > > > > > Whenever the PLR has a backup path available, the > PLR M= > > UST set
> > > > > > the "local protection available" flag.
> > > > > >
> > > > > >
> > > > > > Corrected Text
> > > > > > --------------
> > > > > > Whenever the PLR has a one-to-one backup LSP or > bypass = > > tunnel
> > > > > > available, the PLR MUST set the "local > protection = > > available" flag.
> > > > > >
> > > > > >
> > > > > > Notes
> > > > > > -----
> > > > > > In the case of facility-based FRR the PLR must set > the = > > "local
> > > > protection
> > > > > > available" flag if it has the bypass tunnel > availa= > > ble.
> > > > > >
> > > > > > Instructions:
> > > > > > -------------
> > > > > > This erratum is currently posted as > "Reported"= > > ;. If necessary, please
> > > > > > use "Reply All" to discuss whether it > should = > > be verified or
> > > > > > rejected. When a decision is reached, the verifying > par= > > ty (IESG)
> > > > > > can log in to change the status and edit the report, > if= > > necessary.
> > > > > >
> > > > > > --------------------------------------
> > > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07)
> > > > > > --------------------------------------
> > > > > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 = > > =C2=A0: Fast Reroute Extensions to RSVP-TE for LSP
> > > > Tunnels
> > > > > > Publication Date=C2=A0 =C2=A0 : May 2005
> > > > > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: > P. = > > Pan, Ed., G. Swallow, Ed., A. Atlas, Ed.
> > > > > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : > PRO= > > POSED STANDARD
> > > > > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 = > > : Multiprotocol Label Switching
> > > > > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = > > =C2=A0 : Routing
> > > > > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 = > > : IETF
> > > > > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
> > > > > >
> > > > > >
> > > > >
> > > > > --001a11397a2c9bda6e050a6f31ae
> > > > > Content-Type: text/html; charset=3D"UTF-8"
> > > > > Content-Transfer-Encoding: quoted-printable
> > > > >
> > > > > <div dir=3D3D"ltr">Hi > Yakov,<br><br= > > >Could you clarify your point for this
> > > > err=3D
> > > > > ata?=3DC2=3DA0 In RFC 4090, in the terminology it > says:<b= > > r>&quot; Backup
> > > > Path: =3D
> > > > The LSP that is responsible for backing up > one<br>=3DC= > > 2=3DA0 =3DC2=3DA0 =3DC2=3DA0
> > > > =3DC2=3D
> > > > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2=3DA0= > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0protected
> > > > LSP.=3D
> > > > > =3DC2=3DA0 A backup path refers to either a detour > LSP<br= > > >=3DC2=3DA0 =3DC2=3DA0
> > > > =3DC2=3DA0 =3D
> > > > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2= > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0or a
> > > > backup t=3D
> > > > > unnel.<br><br>=3DC2=3DA0 Backup Tunnel: The > LSP = > > that is used to backup up
> > > > one o=3D
> > > > > f the many<br>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2= > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0
> > > > =3DC2=3D
> > > > > =3DA0LSPs in many-to-one
> > > > > backup.&quot;<div><br></div><div>Than= > > ks,</div><div>A=3D
> > > > > lia</div></div><div > class=3D3D"gmail_ext= > > ra"><br><div
> > > > class=3D3D"gmail_quote">On=3D
> > > > >=C2=A0 Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System > <sp= > > an
> > > > dir=3D3D"ltr">&lt;<a h=3D
> > > > > ref=3D3D"mailto: rfc-editor@rfc-editor= > > .org">rfc-editor@rfc-editor.org"
> > > > target=3D3D"_blank">rfc-editor@rfc-e=3D
> > > > > ditor.org > = > > </a>&gt;</span> wrote:<br><blockquote > class=3D3D&q= > > uot;gmail_quote"
> > > > style=3D
> > > > > =3D3D"margin:0 0 0 .8ex;border-left:1px #ccc > solid;padd= > > ing-left:1ex">The
> > > > foll=3D
> > > > owing errata report has been submitted for > RFC4090,<br>
> > > > > &quot;Fast Reroute Extensions to RSVP-TE for LSP > Tunnels= > > &quot;.<br>
> > > > > <br>
> > > > > --------------------------------------<br>
> > > > > You may review the report below and at:<br>
> > > > > <a href=3D3D"
> > > > http://www.rfc-editor.org/errata_search.php?rfc=3D3D40= > > 90&amp;eid=3D" target=3D"_blank"> > http://www.rfc-editor.org/errata_searc= > > h.php?rfc=3D3D4090&amp;eid=3D
> > > > > =3D3D4203" target=3D3D"_blank">
> > > > ta= > > rget=3D"_blank">http://www.rfc-editor.org/errata_search.php?rfc=3D >
> > > > > =3D3D4090&amp;eid=3D3D4203</a><br>
> > > > > <br>
> > > > > --------------------------------------<br>
> > > > > Type: Technical<br>
> > > > > Reported by: Yakov Rekhter &lt;<a > href=3D3D"mail= > > to:yakov@juniper.net
> > > > ">yakov@j=3D
> > > > > > uniper.net > a></a>&gt;<br>
> > > > > <br>
> > > > > Section: 6<br>
> > > > > <br>
> > > > > Original Text<br>
> > > > > -------------<br>
> > > > > Whenever the PLR has a backup path available, the PLR > MUST s= > > et<br>
> > > > > the &quot;local protection available&quot; > flag.<= > > br>
> > > > > <br>
> > > > > <br>
> > > > > Corrected Text<br>
> > > > > --------------<br>
> > > > > Whenever the PLR has a one-to-one backup LSP or bypass > tunne= > > l<br>
> > > > > available, the PLR MUST set the &quot;local > protection a= > > vailable&quot;
> > > > flag=3D
> > > > > .<br>
> > > > > <br>
> > > > > <br>
> > > > > Notes<br>
> > > > > -----<br>
> > > > > In the case of facility-based FRR the PLR must set the > &= > > quot;local
> > > > protecti=3D
> > > > > on available&quot; flag if it has the bypass tunnel > avai= > > lable.<br>
> > > > > <br>
> > > > > Instructions:<br>
> > > > > -------------<br>
> > > > > This erratum is currently posted as > &quot;Reported&q= > > uot;. If necessary,
> > > > ple=3D
> > > > > ase<br>
> > > > > use &quot;Reply All&quot; to discuss whether it > shou= > > ld be verified or<br>
> > > > > rejected. When a decision is reached, the verifying party > (I= > > ESG)<br>
> > > > > can log in to change the status and edit the report, if > nece= > > ssary.<br>
> > > > > <br>
> > > > > --------------------------------------<br>
> > > > > RFC4090 > (draft-ietf-mpls-rsvp-lsp-fastreroute-07)<br><= > > br> > > > > > --------------------------------------<br>
> > > > > Title=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2=3DA0 = > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0: Fast
> > > > Reroute =3D
> > > > > Extensions to RSVP-TE for LSP Tunnels<br>
> > > > > Publication Date=3DC2=3DA0 =3DC2=3DA0 : May > 2005<br> > r> > > > > > Author(s)=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2= > > =3DA0 =3DC2=3DA0: P. Pan, Ed., G.
> > > > Swallow=3D
> > > > > , Ed., A. Atlas, Ed.<br>
> > > > > Category=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2=3D= > > A0 =3DC2=3DA0 : PROPOSED STANDARD<br>
> > > > > Source=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2=3DA0= > > =3DC2=3DA0 =3DC2=3DA0 : Multiprotocol
> > > > Labe=3D
> > > > > l Switching<br>
> > > > > Area=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2=3DA0 = > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 : Routing<br>
> > > > > Stream=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2=3DA0= > > =3DC2=3DA0 =3DC2=3DA0 : IETF<br>
> > > > > Verifying Party=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0: > IESG<br&= > > gt;
> > > > > <br>
> > > > > </blockquote></div><br></div>
> > > > >
> > > > > --001a11397a2c9bda6e050a6f31ae--
> > > >
> > >
> >
> --047d7b5d99a33a914b050a70164e
> > > Content-Type: text/html; > charset=3D"UTF-8"<= > > br> > > > Content-Transfer-Encoding: quoted-printable
> > >
> > > <div dir=3D3D"ltr">Yakov,<div > class=3D3D&quo= > > t;gmail_extra"><br><div class=3D3D"gmail_q=3D
> > > uote">On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter > <span = > > dir=3D3D"ltr">&lt;=3D
> > > <a href=3D3D"mailto: ">yakov= > > @juniper.net" target=3D3D"_blank"> href=3D"mailto:y= > > akov@juniper.net">yakov@juniper.net</a=3D
> > > >&gt;</span> wrote:<br><blockquote > class=3D3D&qu= > > ot;gmail_quote" style=3D3D"margin:0 =3D
> > > 0 0 .8ex;border-left:1px #ccc > solid;padding-left:1ex">Alia,<= > > ;br>
> > > <span class=3D3D""><br>
> > > &gt; Hi Yakov,<br>
> > > &gt;<br>
> > > &gt; Could you clarify your point for this errata?=3DC2=3DA0 In > RF= > > C 4090, in th=3D
> > > e<br>
> > > &gt; terminology it says:<br>
> > > &gt;=3DC2=3DA0 &quot;Backup Path: The LSP that is > responsible = > > for backing up on=3D
> > e<br>
> > > &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2= > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D
> > > =3DC2=3DA0 =3DC2=3DA0 protected LSP.=3DC2=3DA0 A backup path refers > to= > > either a<br>
> > > &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2= > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D
> > > =3DC2=3DA0 =3DC2=3DA0 detour LSP or a backup tunnel.<br>
> > > &gt;<br>
> > > &gt;=3DC2=3DA0 =3DC2=3DA0Backup Tunnel: The LSP that is used to > ba= > > ckup up one of th=3D
> > > e many<br>
> > > &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2= > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 LSPs in =3D
> > > many-to-one backup.&quot;<br>
> > > <br>
> > > </span>In the terminology it also says:<br>
> > > <br>
> > > =3DC2=3DA0 =3DC2=3DA0&quot;Bypass Tunnel: An LSP that is used > to p= > > rotect a set of L=3D
> > > SPs<br>
> > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > pass= > > ing over a common facility.&q=3D
> > > uot;<br>
> > > <br>
> > > My point is that (unless the term &quot;bypass tunnel&quot; > me= > > ans the same<=3D
> > > br>
> > > as &quot;backup path&quot; or &quot;backup > tunnel&quot= > > ;) in many-to-one bac=3D
> > > kup<br>
> > > the &quot;local protection available&quot; flag for a given > pr= > > otected LSP<b=3D
> > > r>
> > > MUST be set when the PLR has a *bypass* tunnel for that > LSP.<br>= > > </blockquot=3D
> > > e><div><br></div><div>Ah - ok.=3DC2=3DA0 > A = > > backup path that uses a bypass tunne=3D
> > > l is not just the bypass > tunnel</div><div>itself.=3DC2=3DA= > > 0 There&#39;s the sta=3D
> > > te associated for the protected LSP that also needs to > be</div>&= > > lt;div>created=3D
> > >=C2=A0 and installed.=3DC2=3DA0 In more concrete terms, this is > install= > > ing an out-seg=3D
> > > ment with=3DC2=3DA0</div><div>the appropriate label for > th= > > e protected LSP to be=3D
> > >=C2=A0 understood by the merge point as</div><div>well > as a= > > n outer label for the =3D
> > > bypass > LSP.</div><div><br></div><div>So,= > > the text refers to a backup path i=3D
> > > nstead of a bypass tunnel because having > the</div><div>byp= > > ass tunnel isn&#3=3D
> > > 9;t quite sufficient.=3DC2=3DA0 Does that make sense to > you?</div&g= > > t;<div><br></di=3D
> > > > v><div>Regards,</div><div>Alia</div><div= > > >=3DC2=3DA0</div><blockquote class=3D3D"g=3D
> > > mail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px > #cc= > > c solid;padding-l=3D
> > > eft:1ex">
> > > Yakov.<br>
> > > <div><div class=3D3D"h5"><br>
> > > &gt; Thanks,<br>
> > > &gt; Alia<br>
> > > &gt;<br>
> > > &gt; On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System > &lt;&l= > > t;br>
> > > &gt; <a href=3D3D"mailto: rfc-editor@rfc-= > > editor.org">rfc-editor@rfc-editor.org"> rfc-ed= > > itor@rfc-editor.org">rfc-editor@rfc-editor.org=3D
> > > </a>&gt; wrote:<br>
> > > &gt;<br>
> > > &gt; &gt; The following errata report has been submitted > for R= > > FC4090,<br>
> > > &gt; &gt; &quot;Fast Reroute Extensions to RSVP-TE for > LSP= > > Tunnels&quot;.<b=3D
> > > r>
> > > &gt; &gt;<br>
> > > &gt; &gt; > --------------------------------------<br>
> > > &gt; &gt; You may review the report below and > at:<br> > > > > > &gt; &gt; <a href=3D3D" http://www.rfc-edito= > > r.org/errata_search.php?rfc=3D3D4090=3D" target=3D"_blank"> > http://www.rfc-e= > > ditor.org/errata_search.php?rfc=3D3D4090=3D
> > > &amp;eid=3D3D4203" target=3D3D"_blank"> href= > > =3D"http://www.rfc-editor.org/errata_search.=3D" target=3D"_blank"> > http://w= > > ww.rfc-editor.org/errata_search.=3D
> > > php?rfc=3D3D4090&amp;eid=3D3D4203</a><br>
> > > &gt; &gt;<br>
> > > &gt; &gt; > --------------------------------------<br>
> > > &gt; &gt; Type: Technical<br>
> > > &gt; &gt; Reported by: Yakov Rekhter &lt;<a > href=3D3D&q= > > uot;mailto:yakov@juniper.ne > =3D
> > > t">yakov@juniper.net > &= > > lt;/a>&gt;<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Section: 6<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Original Text<br>
> > > &gt; &gt; -------------<br>
> > > &gt; &gt; Whenever the PLR has a backup path available, the > PL= > > R MUST set<br=3D
> > > >
> > > &gt; &gt; the &quot;local protection > available&quot; f= > > lag.<br>
> > > &gt; &gt;<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Corrected Text<br>
> > > &gt; &gt; --------------<br>
> > > &gt; &gt; Whenever the PLR has a one-to-one backup LSP or > bypa= > > ss tunnel<br>
> > > &gt; &gt; available, the PLR MUST set the &quot;local > prot= > > ection available&=3D
> > > quot; flag.<br>
> > > &gt; &gt;<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Notes<br>
> > > &gt; &gt; -----<br>
> > > &gt; &gt; In the case of facility-based FRR the PLR must > set t= > > he &quot;loca=3D
> > > l protection<br>
> > > &gt; &gt; available&quot; flag if it has the bypass > tunnel= > > available.<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Instructions:<br>
> > > &gt; &gt; -------------<br>
> > > &gt; &gt; This erratum is currently posted as > &quot;Report= > > ed&quot;. If nece=3D
> > > ssary, please<br>
> > > &gt; &gt; use &quot;Reply All&quot; to discuss > whether= > > it should be verifie=3D
> > > d or<br>
> > > &gt; &gt; rejected. When a decision is reached, the > verifying = > > party (IESG)<=3D
> > > br>
> > > &gt; &gt; can log in to change the status and edit the > report,= > > if necessary=3D
> > > .<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; > --------------------------------------<br>
> > > &gt; &gt; RFC4090 > (draft-ietf-mpls-rsvp-lsp-fastreroute-07)<= > > ;br>
> > > &gt; &gt; > --------------------------------------<br>
> > > &gt; &gt; Title=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3D= > > C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0: Fas=3D
> > > t Reroute Extensions to RSVP-TE for LSP Tunnels<br>
> > > &gt; &gt; Publication Date=3DC2=3DA0 =3DC2=3DA0 : May > 2005<= > > br>
> > > &gt; &gt; Author(s)=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2=3DA0= > > =3DC2=3DA0 =3DC2=3DA0: P. Pan, Ed., =3D
> > > G. Swallow, Ed., A. Atlas, Ed.<br>
> > > &gt; &gt; Category=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC2=3DA0 = > > =3DC2=3DA0 =3DC2=3DA0 : PROPOSED STAN=3D
> > > DARD<br>
> > > &gt; &gt; Source=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > = > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 : Multipro=3D
> > > tocol Label Switching<br>
> > > &gt; &gt; Area=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3DC= > > 2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 : Rou=3D
> > > ting<br>
> > > &gt; &gt; Stream=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > = > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 : IETF<br>
> > > &gt; &gt; Verifying Party=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0: > IES= > > G<br>
> > > &gt; &gt;<br>
> > > &gt; &gt;<br>
> > > &gt;<br>
> > > </div></div>&gt; > --001a11397a2c9bda6e050a6f31ae<br&= > > gt;
> > > &gt; Content-Type: text/html; > charset=3D3D&quot;UTF-8&quot= > > ;<br>
> > > &gt; Content-Transfer-Encoding: quoted-printable<br>
> > > &gt;<br>
> > > &gt; &lt;div dir=3D3D3D&quot;ltr&quot;&gt;Hi > Yakov= > > ,&lt;br&gt;&lt;br&gt;Could =3D
> > > you clarify your point for this err=3D3D<br>
> > > &gt; ata?=3D3DC2=3D3DA0 In RFC 4090, in the terminology it > says:&a= > > mp;lt;br&gt;&amp;=3D
> > > quot; Backup Path: =3D3D<br>
> > > &gt; The LSP that is responsible for backing up > one&lt;br&= > > gt;=3D3DC2=3D3DA0 =3D3D=3D
> > > C2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3D<br>
> > > &gt; =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2= > > =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA=3D
> > > 0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0protected LSP.=3D3D<br>
> > > &gt; =3D3DC2=3D3DA0 A backup path refers to either a detour > LSP&am= > > p;lt;br&gt;=3D3DC2=3D
> > > =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3D<br>
> > > &gt; =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2=3D3DA0 = > > =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC=3D
> > > 2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0or a backup > t=3D3D<br>
> > > &gt; unnel.&lt;br&gt;&lt;br&gt;=3D3DC2=3D3DA0 > Back= > > up Tunnel: The LSP that is us=3D
> > > ed to backup up one o=3D3D<br>
> > > &gt; f the many&lt;br&gt;=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D= > > 3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D
> > > =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2=3D3D<b= > > r>
> > > &gt; =3D3DA0LSPs in many-to-one > backup.&amp;quot;&lt;div&a= > > mp;gt;&lt;br&gt;&lt;/di=3D
> > > > v&gt;&lt;div&gt;Thanks,&lt;/div&gt;&lt;div&= > > ;gt;A=3D3D<br>
> > > &gt; lia&lt;/div&gt;&lt;/div&gt;&lt;div > class= > > =3D3D3D&quot;gmail_extra&quot;&g=3D
> > > t;&lt;br&gt;&lt;div > class=3D3D3D&quot;gmail_quote&= > > quot;&gt;On=3D3D<br>
> > > &gt;=3DC2=3DA0 Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System > &am= > > p;lt;span dir=3D3D3=3D
> > > D&quot;ltr&quot;&gt;&amp;lt;&lt;a > h=3D3D<br>= > >
> > > &gt; ref=3D3D3D&quot;mailto:<a href=3D3D"mailto: hre= > > f=3D"mailto:rfc-editor@rfc-editor.org">rfc-editor@rfc-editor.org > "&= > > gt;rfc-=3D
> > > editor@rfc-editor.org > <= > > /a>&quot; > target=3D3D3D&quot;_blank&quot;&gt;rfc-editor= > > =3D
> > > @rfc-e=3D3D<br>
> > > &gt; <a href=3D3D" target=3D"_= > > blank">http://ditor.org" target=3D3D"_blank"> href= > > =3D"http://ditor.org" target=3D"_blank">ditor.org > </a>&lt;/a&a= > > mp;gt;=3D
> > > &amp;gt;&lt;/span&gt; > wrote:&lt;br&gt;&lt;bloc= > > kquote class=3D3D3D&quot;gmail_=3D
> > > quote&quot; style=3D3D<br>
> > > &gt; =3D3D3D&quot;margin:0 0 0 .8ex;border-left:1px #ccc > solid= > > ;padding-left:1=3D
> > > ex&quot;&gt;The foll=3D3D<br>
> > > owing errata report has been submitted for > RFC4090,&lt;br&gt;&= > > lt;br>
> > > &gt; &amp;quot;Fast Reroute Extensions to RSVP-TE for LSP > Tunn= > > els&amp;quot;=3D
> > > .&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; > --------------------------------------&lt;br&gt;<b= > > r>
> > > &gt; You may review the report below and > at:&lt;br&gt;<= > > br>
> > > &gt; &lt;a href=3D3D3D&quot;<a href=3D3D" href= > > =3D"http://www.rfc-editor.org/errata_searc=3D" target=3D"_blank"> > http://www= > > .rfc-editor.org/errata_searc=3D
> > > h.php?rfc=3D3D3D4090&amp;amp;eid=3D3D" > target=3D3D"_blan= > > k"> > http://www.= > > rfc-editor.=3D
> > > > org/errata_search.php?rfc=3D3D3D4090&amp;amp;eid=3D3D</a><= > > ;br>
> > > &gt; =3D3D3D4203&quot; > target=3D3D3D&quot;_blank&quot;= > > &gt;<a href=3D3D" target=3D"_blank">http:= > > //www=3D
> > > . target= > > =3D"_blank">rfc-editor.org/errata_search.php?rfc=3D3D" > target=3D3D= > > "_blank"> target=3D"_blank">http://= > > www.rfc-=3D
> > > target=3D"_bl= > > ank">editor.org/errata_search.php?rfc=3D3D</a><br>
> > > &gt; > =3D3D3D4090&amp;amp;eid=3D3D3D4203&lt;/a&gt;&= > > lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; > --------------------------------------&lt;br&gt;<b= > > r>
> > > &gt; Type: Technical&lt;br&gt;<br>
> > > &gt; Reported by: Yakov Rekhter &amp;lt;&lt;a > href=3D3D3D&= > > amp;quot;mailto:<a href=3D
> > > =3D3D"mailto: ">yakov@juniper.n= > > et">yakov@juniper.net > &= > > lt;/a>&quot;&gt;yakov@j=3D3D<br>
> > > &gt; <a href=3D3D" target=3D"= > > _blank">http://uniper.net" target=3D3D"_blank"> hre= > > f=3D"http://uniper.net" target=3D"_blank">uniper.net > </a>&lt;/= > > a&g=3D
> > > t;&amp;gt;&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Section: 6&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Original Text&lt;br&gt;<br>
> > > &gt; -------------&lt;br&gt;<br>
> > > &gt; Whenever the PLR has a backup path available, the PLR MUST > se= > > t&lt;br&g=3D
> > > t;<br>
> > > &gt; the &amp;quot;local protection available&amp;quot; > fl= > > ag.&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Corrected Text&lt;br&gt;<br>
> > > &gt; --------------&lt;br&gt;<br>
> > > &gt; Whenever the PLR has a one-to-one backup LSP or bypass > tunnel= > > &lt;br&gt=3D
> > > ;<br>
> > > &gt; available, the PLR MUST set the &amp;quot;local > protectio= > > n available&a=3D
> > > mp;quot; flag=3D3D<br>
> > > &gt; .&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Notes&lt;br&gt;<br>
> > > &gt; -----&lt;br&gt;<br>
> > > &gt; In the case of facility-based FRR the PLR must set the > &a= > > mp;quot;local=3D
> > >=C2=A0 protecti=3D3D<br>
> > > &gt; on available&amp;quot; flag if it has the bypass > tunnel a= > > vailable.&lt;=3D
> > > br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Instructions:&lt;br&gt;<br>
> > > &gt; -------------&lt;br&gt;<br>
> > > &gt; This erratum is currently posted as > &amp;quot;Reported&am= > > p;amp;quot;. If n=3D
> > > ecessary, ple=3D3D<br>
> > > &gt; ase&lt;br&gt;<br>
> > > &gt; use &amp;quot;Reply All&amp;quot; to discuss > whether = > > it should be veri=3D
> > > fied or&lt;br&gt;<br>
> > > &gt; rejected. When a decision is reached, the verifying party > (IE= > > SG)&lt;br=3D
> > > &gt;<br>
> > > &gt; can log in to change the status and edit the report, if > neces= > > sary.&lt;=3D
> > > br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; > --------------------------------------&lt;br&gt;<b= > > r>
> > > &gt; RFC4090 > (draft-ietf-mpls-rsvp-lsp-fastreroute-07)&lt;br&a= > > mp;gt;<br>
> > > &gt; > --------------------------------------&lt;br&gt;<b= > > r>
> > > &gt; Title=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2=3D3= > > DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0=3D
> > >=C2=A0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0: Fast Reroute > =3D3D<br>
> > > &gt; Extensions to RSVP-TE for LSP > Tunnels&lt;br&gt;<br= > > >
> > > &gt; Publication Date=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : May > 2005&= > > lt;br&gt;<br>
> > > &gt; Author(s)=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2= > > =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D
> > > =3D3DA0: P. Pan, Ed., G. Swallow=3D3D<br>
> > > &gt; , Ed., A. Atlas, Ed.&lt;br&gt;<br>
> > > &gt; Category=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2= > > =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D
> > > =3D3DA0 : PROPOSED STANDARD&lt;br&gt;<br>
> > > &gt; Source=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2=3D= > > 3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA=3D
> > > 0 =3D3DC2=3D3DA0 : Multiprotocol Labe=3D3D<br>
> > > &gt; l Switching&lt;br&gt;<br>
> > > &gt; Area=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2=3D3D= > > A0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D
> > > =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : > Routing&lt;br&gt;<br> > > > > > &gt; Stream=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2=3D= > > 3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA=3D
> > > 0 =3D3DC2=3D3DA0 : IETF&lt;br&gt;<br>
> > > &gt; Verifying Party=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 > =3D3DC2=3D3DA0: = > > IESG&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; > &lt;/blockquote&gt;&lt;/div&gt;&lt;br&= > > ;gt;&lt;/div&gt;<br>
> > > &gt;<br>
> > > &gt; --001a11397a2c9bda6e050a6f31ae--<br>
> > > > </blockquote></div><br></div></div>
> > >
> > > --047d7b5d99a33a914b050a70164e--
> >

> > > > --001a11c1e9ee40fd19050a7068c9-- > --001a113a83b6b3fadd050bea9d74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yakov,

I've modified the Errata to suggest exte= nding the text slightly as follows:

=C2=A0 =C2=A0Section 6 says:
=
=C2=A0 =C2=A0Whenever the PLR has a backup path available, the PLR MUST= set
=C2=A0 =C2=A0the "local protection available" flag.
=C2=A0 =C2=A0It should say:

=C2=A0 =C2=A0Whenever the PLR has a ba= ckup path available, the PLR MUST set
=C2=A0 =C2=A0the "local prote= ction available" flag.=C2=A0 For example, if the PLR
=C2=A0 =C2=A0= has determined to use a bypass tunnel and set up the necessary
=C2=A0 = =C2=A0local forwarding state to be able to use it as a backup path,
=C2= =A0 =C2=A0then that PLR has a backup path available.

Assuming that&#= 39;s ok with the WG, Adrian or I can approve it.

Regards= ,
Alia



On Wed, Dec 17, 2014 at 9:11 PM, Yakov Rekhter <yak= ov@juniper.net> wrote:
Alia= ,

> > Alia,
> >
> > > Yakov,
> > >
> > > On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter <yakov@juniper.net>
> > wrote:
> > >
> > > > Alia,
> > > >
> > > > > Hi Yakov,
> > > > >
> > > > > Could you clarify your point for this errata?=C2= =A0 In RFC 4090, in the
> > > > > terminology it says:
> > > > >=C2=A0 "Backup Path: The LSP that is responsib= le for backing up one
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 protected LSP.=C2=A0 A backup path refer= s to
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 either a detour LSP or a backup tunnel.
> > > > >
> > > > >=C2=A0 =C2=A0Backup Tunnel: The LSP that is used to= backup up one of the many
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 LSPs in many-to-one backup."
> > > >
> > > > In the terminology it also says:
> > > >
> > > >=C2=A0 =C2=A0 "Bypass Tunnel: An LSP that is used t= o protect a set of LSPs
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0passing = over a common facility."
> > > >
> > > > My point is that (unless the term "bypass tunnel&q= uot; means the same
> > > > as "backup path" or "backup tunnel"= ) in many-to-one backup
> > > > the "local protection available" flag for a g= iven protected LSP
> > > > MUST be set when the PLR has a *bypass* tunnel for that= LSP.
> > > >
> > >
> > > Ah - ok.=C2=A0 A backup path that uses a bypass tunnel is no= t just the bypass
> > > tunnel itself.
> >
> > Correct.
> >
> > > There's the state associated for the protected LSP that<= br> > > > also needs to be created and installed.=C2=A0 In more concre= te terms, this
> > > is installing an out-segment with the appropriate label for = the protected
> > > LSP to be understood by the merge point as
> > > well as an outer label for the bypass LSP.
> > >
> > > So, the text refers to a backup path instead of a bypass tun= nel because
> > > having the bypass tunnel isn't quite sufficient.
> > > Does that make sense to you?
> >
> > The current text is incorrect. This is because a PLR may signal a=
> > backup path at the time of failure. Yet, one should not wait for<= br> > > the failure to set the "local protection available" fla= g. The PLR
> > should set this flag as soon as it has a *bypass* tunnel.
>
> The backup path is created by the PLR before the failure and thus, bef= ore
> the associated signaling. Once the PLR has done the work to create
> a backup path using an existing bypass tunnel - which is internal
> work - then the PLR should set the "local protection available&qu= ot; flag.

Perhaps we should step back and ask whether the quote from sect= ion 6:

=C2=A0 =C2=A0Whenever the PLR has a backup path available, the PLR MUST set=
=C2=A0 =C2=A0the "local protection available" flag.

talks about forwarding state or control plane state. Is there
any text in rfc4090 that answers this question ?

Yakov.

>
> Alia
>
>
>
> > Yakov.
> >
> > >
> > > Regards,
> > > Alia
> > >
> > >
> > > > Yakov.
> > > >
> > > > > Thanks,
> > > > > Alia
> > > > >
> > > > > On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System= <
> > > > > rfc-e= ditor@rfc-editor.org> wrote:
> > > > >
> > > > > > The following errata report has been submitte= d for RFC4090,
> > > > > > "Fast Reroute Extensions to RSVP-TE for = LSP Tunnels".
> > > > > >
> > > > > > --------------------------------------
> > > > > > You may review the report below and at:
> > > > > > http://www.rfc-edito= r.org/errata_search.php?rfc=3D4090&eid=3D4203
> > > > > >
> > > > > > --------------------------------------
> > > > > > Type: Technical
> > > > > > Reported by: Yakov Rekhter <yakov@juniper.net>
> > > > > >
> > > > > > Section: 6
> > > > > >
> > > > > > Original Text
> > > > > > -------------
> > > > > > Whenever the PLR has a backup path available,= the PLR MUST set
> > > > > > the "local protection available" fl= ag.
> > > > > >
> > > > > >
> > > > > > Corrected Text
> > > > > > --------------
> > > > > > Whenever the PLR has a one-to-one backup LSP = or bypass tunnel
> > > > > > available, the PLR MUST set the "local p= rotection available" flag.
> > > > > >
> > > > > >
> > > > > > Notes
> > > > > > -----
> > > > > > In the case of facility-based FRR the PLR mus= t set the "local
> > > > protection
> > > > > > available" flag if it has the bypass tun= nel available.
> > > > > >
> > > > > > Instructions:
> > > > > > -------------
> > > > > > This erratum is currently posted as "Rep= orted". If necessary,
> > please
> > > > > > use "Reply All" to discuss whether = it should be verified or
> > > > > > rejected. When a decision is reached, the ver= ifying party (IESG)
> > > > > > can log in to change the status and edit the = report, if necessary.
> > > > > >
> > > > > > --------------------------------------
> > > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute= -07)
> > > > > > --------------------------------------
> > > > > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: Fast Reroute Extensions to RSVP-TE for LSP
> > > > Tunnels
> > > > > > Publication Date=C2=A0 =C2=A0 : May 2005
> > > > > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed.
> > > > > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : PROPOSED STANDARD
> > > > > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : Multiprotocol Label Switching
> > > > > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 : Routing
> > > > > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : IETF
> > > > > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
> > > > > >
> > > > > >
> > > > >
> > > > > --001a11397a2c9bda6e050a6f31ae
> > > > > Content-Type: text/html; charset=3D"UTF-8&quo= t;
> > > > > Content-Transfer-Encoding: quoted-printable
> > > > >
> > > > > <div dir=3D3D"ltr">Hi Yakov,<br= ><br>Could you clarify your point for
> > this
> > > > err=3D
> > > > > ata?=3DC2=3DA0 In RFC 4090, in the terminology it = says:<br>&quot; Backup
> > > > Path: =3D
> > > > > The LSP that is responsible for backing up one<= br>=3DC2=3DA0 =3DC2=3DA0
> > =3DC2=3DA0
> > > > =3DC2=3D
> > > > > =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0protected
> > > > LSP.=3D
> > > > > =3DC2=3DA0 A backup path refers to either a detour= LSP<br>=3DC2=3DA0 =3DC2=3DA0
> > > > =3DC2=3DA0 =3D
> > > > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0or a
> > > > backup t=3D
> > > > > unnel.<br><br>=3DC2=3DA0 Backup Tunnel= : The LSP that is used to backup up
> > > > one o=3D
> > > > > f the many<br>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0
> > > > =3DC2=3D
> > > > > =3DA0LSPs in many-to-one
> > > > backup.&quot;<div><br></div><d= iv>Thanks,</div><div>A=3D
> > > > > lia</div></div><div class=3D3D"= ;gmail_extra"><br><div
> > > > class=3D3D"gmail_quote">On=3D
> > > > >=C2=A0 Wed, Dec 17, 2014 at 3:07 PM, RFC Errata Sys= tem <span
> > > > dir=3D3D"ltr">&lt;<a h=3D
> > > > > ref=3D3D"mailto:rfc-editor@rfc-editor.org"
> > > > target=3D3D"_blank">rfc-editor@rfc-e=3D > > > > > dit= or.org</a>&gt;</span> wrote:<br><blockquote cl= ass=3D3D"gmail_quote"
> > > > style=3D
> > > > > =3D3D"margin:0 0 0 .8ex;border-left:1px #ccc<= br> > > solid;padding-left:1ex">The
> > > > foll=3D
> > > > owing errata report has been submitted for RFC4090,<= br>
> > > > > &quot;Fast Reroute Extensions to RSVP-TE for L= SP Tunnels&quot;.<br>
> > > > > <br>
> > > > > --------------------------------------<br> > > > > > You may review the report below and at:<br><= br> > > > > > <a href=3D3D"
> > > > http://www.rfc-editor.org/er= rata_search.php?rfc=3D3D4090&amp;eid=3D
> > > > > =3D3D4203" target=3D3D"_blank"><= br> > > > > http://www.rfc-editor.org/errata_search.php?rfc= =3D
> > > > > =3D3D4090&amp;eid=3D3D4203</a><br>=
> > > > > <br>
> > > > > --------------------------------------<br> > > > > > Type: Technical<br>
> > > > > Reported by: Yakov Rekhter &lt;<a href=3D3D= "mailto:yakov@juniper.net
> > > > ">yakov@j=3D
> > > > > un= iper.net</a>&gt;<br>
> > > > > <br>
> > > > > Section: 6<br>
> > > > > <br>
> > > > > Original Text<br>
> > > > > -------------<br>
> > > > > Whenever the PLR has a backup path available, the = PLR MUST set<br>
> > > > > the &quot;local protection available&quot;= flag.<br>
> > > > > <br>
> > > > > <br>
> > > > > Corrected Text<br>
> > > > > --------------<br>
> > > > > Whenever the PLR has a one-to-one backup LSP or by= pass tunnel<br>
> > > > > available, the PLR MUST set the &quot;local pr= otection
> > available&quot;
> > > > flag=3D
> > > > > .<br>
> > > > > <br>
> > > > > <br>
> > > > > Notes<br>
> > > > > -----<br>
> > > > > In the case of facility-based FRR the PLR must set= the &quot;local
> > > > protecti=3D
> > > > > on available&quot; flag if it has the bypass t= unnel available.<br>
> > > > > <br>
> > > > > Instructions:<br>
> > > > > -------------<br>
> > > > > This erratum is currently posted as &quot;Repo= rted&quot;. If
> > necessary,
> > > > ple=3D
> > > > > ase<br>
> > > > > use &quot;Reply All&quot; to discuss wheth= er it should be verified
> > or<br>
> > > > > rejected. When a decision is reached, the verifyin= g party (IESG)<br>
> > > > > can log in to change the status and edit the repor= t, if
> > necessary.<br>
> > > > > <br>
> > > > > --------------------------------------<br> > > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07)&= lt;br>
> > > > > --------------------------------------<br> > > > > > Title=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0: Fast
> > > > Reroute =3D
> > > > > Extensions to RSVP-TE for LSP Tunnels<br> > > > > > Publication Date=3DC2=3DA0 =3DC2=3DA0 : May 2005&l= t;br>
> > > > > Author(s)=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0: P. Pan, Ed., G.
> > > > Swallow=3D
> > > > > , Ed., A. Atlas, Ed.<br>
> > > > > Category=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA= 0 =3DC2=3DA0 =3DC2=3DA0 : PROPOSED
> STANDARD<br>
> > > > > Source=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 :
> > Multiprotocol
> > > > Labe=3D
> > > > > l Switching<br>
> > > > > Area=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 :
> > Routing<br>
> > > > > Stream=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 : IETF<br>
> > > > > Verifying Party=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0: I= ESG<br>
> > > > > <br>
> > > > > </blockquote></div><br></div&= gt;
> > > > >
> > > > > --001a11397a2c9bda6e050a6f31ae--
> > > >
> > >
> > > --047d7b5d99a33a914b050a70164e
> > > Content-Type: text/html; charset=3D"UTF-8"
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > <div dir=3D3D"ltr">Yakov,<div class=3D3D&= quot;gmail_extra"><br><div
> > class=3D3D"gmail_q=3D
> > > uote">On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter= <span
> > dir=3D3D"ltr">&lt;=3D
> > > <a href=3D3D"mailto:yakov@juniper.net" target=3D3D"_blank">yakov@juniper.net
> > </a=3D
> > > >&gt;</span> wrote:<br><blockquote cla= ss=3D3D"gmail_quote"
> > style=3D3D"margin:0 =3D
> > > 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"&g= t;Alia,<br>
> > > <span class=3D3D""><br>
> > > &gt; Hi Yakov,<br>
> > > &gt;<br>
> > > &gt; Could you clarify your point for this errata?=3DC2= =3DA0 In RFC 4090, in
> > th=3D
> > > e<br>
> > > &gt; terminology it says:<br>
> > > &gt;=3DC2=3DA0 &quot;Backup Path: The LSP that is re= sponsible for backing up
> > on=3D
> > > e<br>
> > > &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0
> > =3DC2=3DA0 =3D
> > > =3DC2=3DA0 =3DC2=3DA0 protected LSP.=3DC2=3DA0 A backup path= refers to either a<br>
> > > &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0
> > =3DC2=3DA0 =3D
> > > =3DC2=3DA0 =3DC2=3DA0 detour LSP or a backup tunnel.<br&g= t;
> > > &gt;<br>
> > > &gt;=3DC2=3DA0 =3DC2=3DA0Backup Tunnel: The LSP that is = used to backup up one of
> > th=3D
> > > e many<br>
> > > &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 LSPs
> > in =3D
> > > many-to-one backup.&quot;<br>
> > > <br>
> > > </span>In the terminology it also says:<br>
> > > <br>
> > > =3DC2=3DA0 =3DC2=3DA0&quot;Bypass Tunnel: An LSP that is= used to protect a set
> > of L=3D
> > > SPs<br>
> > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 passing over a common
> > facility.&q=3D
> > > uot;<br>
> > > <br>
> > > My point is that (unless the term &quot;bypass tunnel&am= p;quot; means the
> > same<=3D
> > > br>
> > > as &quot;backup path&quot; or &quot;backup tunne= l&quot;) in many-to-one
> > bac=3D
> > > kup<br>
> > > the &quot;local protection available&quot; flag for = a given protected
> > LSP<b=3D
> > > r>
> > > MUST be set when the PLR has a *bypass* tunnel for that
> > LSP.<br></blockquot=3D
> > > e><div><br></div><div>Ah - ok.=3D= C2=3DA0 A backup path that uses a bypass
> > tunne=3D
> > > l is not just the bypass tunnel</div><div>itself= .=3DC2=3DA0 There&#39;s the
> > sta=3D
> > > te associated for the protected LSP that also needs to
> > be</div><div>created=3D
> > >=C2=A0 and installed.=3DC2=3DA0 In more concrete terms, this = is installing an
> > out-seg=3D
> > > ment with=3DC2=3DA0</div><div>the appropriate la= bel for the protected LSP to
> > be=3D
> > >=C2=A0 understood by the merge point as</div><div>= ;well as an outer label for
> > the =3D
> > > bypass LSP.</div><div><br></div><= div>So, the text refers to a backup
> > path i=3D
> > > nstead of a bypass tunnel because having the</div><= div>bypass tunnel
> > isn&#3=3D
> > > 9;t quite sufficient.=3DC2=3DA0 Does that make sense to
> > you?</div><div><br></di=3D
> > > v><div>Regards,</div><div>Alia</div&= gt;<div>=3DC2=3DA0</div><blockquote
> > class=3D3D"g=3D
> > > mail_quote" style=3D3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc
> > solid;padding-l=3D
> > > eft:1ex">
> > > Yakov.<br>
> > > <div><div class=3D3D"h5"><br> > > > &gt; Thanks,<br>
> > > &gt; Alia<br>
> > > &gt;<br>
> > > &gt; On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System = &lt;<br>
> > > &gt; <a href=3D3D"mailto:rfc-editor@rfc-editor.org">
> > rfc-editor@rfc-edito= r.org=3D
> > > </a>&gt; wrote:<br>
> > > &gt;<br>
> > > &gt; &gt; The following errata report has been submi= tted for RFC4090,<br>
> > > &gt; &gt; &quot;Fast Reroute Extensions to RSVP-= TE for LSP
> > Tunnels&quot;.<b=3D
> > > r>
> > > &gt; &gt;<br>
> > > &gt; &gt; --------------------------------------<= br>
> > > &gt; &gt; You may review the report below and at:<= ;br>
> > > &gt; &gt; <a href=3D3D"
> > http://www.rfc-editor.org/errata_search.php?rfc=3D= 3D4090=3D
> > > &amp;eid=3D3D4203" target=3D3D"_blank">= ;
> > http://www.rfc-editor.org/errata_search.=3D
> > > php?rfc=3D3D4090&amp;eid=3D3D4203</a><br> > > > &gt; &gt;<br>
> > > &gt; &gt; --------------------------------------<= br>
> > > &gt; &gt; Type: Technical<br>
> > > &gt; &gt; Reported by: Yakov Rekhter &lt;<a h= ref=3D3D"mailto:
> > yakov@juniper.ne=3D
> > > t">yakov@junipe= r.net</a>&gt;<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Section: 6<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Original Text<br>
> > > &gt; &gt; -------------<br>
> > > &gt; &gt; Whenever the PLR has a backup path availab= le, the PLR MUST
> > set<br=3D
> > > >
> > > &gt; &gt; the &quot;local protection available&a= mp;quot; flag.<br>
> > > &gt; &gt;<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Corrected Text<br>
> > > &gt; &gt; --------------<br>
> > > &gt; &gt; Whenever the PLR has a one-to-one backup L= SP or bypass
> > tunnel<br>
> > > &gt; &gt; available, the PLR MUST set the &quot;= local protection
> > available&=3D
> > > quot; flag.<br>
> > > &gt; &gt;<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Notes<br>
> > > &gt; &gt; -----<br>
> > > &gt; &gt; In the case of facility-based FRR the PLR = must set the
> > &quot;loca=3D
> > > l protection<br>
> > > &gt; &gt; available&quot; flag if it has the byp= ass tunnel available.<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; Instructions:<br>
> > > &gt; &gt; -------------<br>
> > > &gt; &gt; This erratum is currently posted as &q= uot;Reported&quot;. If
> > nece=3D
> > > ssary, please<br>
> > > &gt; &gt; use &quot;Reply All&quot; to discu= ss whether it should be
> > verifie=3D
> > > d or<br>
> > > &gt; &gt; rejected. When a decision is reached, the = verifying party
> > (IESG)<=3D
> > > br>
> > > &gt; &gt; can log in to change the status and edit t= he report, if
> > necessary=3D
> > > .<br>
> > > &gt; &gt;<br>
> > > &gt; &gt; --------------------------------------<= br>
> > > &gt; &gt; RFC4090 (draft-ietf-mpls-rsvp-lsp-fastrero= ute-07)<br>
> > > &gt; &gt; --------------------------------------<= br>
> > > &gt; &gt; Title=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC= 2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0:
> > Fas=3D
> > > t Reroute Extensions to RSVP-TE for LSP Tunnels<br> > > > &gt; &gt; Publication Date=3DC2=3DA0 =3DC2=3DA0 : Ma= y 2005<br>
> > > &gt; &gt; Author(s)=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0: P. Pan,
> > Ed., =3D
> > > G. Swallow, Ed., A. Atlas, Ed.<br>
> > > &gt; &gt; Category=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 : PROPOSED
> > STAN=3D
> > > DARD<br>
> > > &gt; &gt; Source=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 :
> > Multipro=3D
> > > tocol Label Switching<br>
> > > &gt; &gt; Area=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 :
> > Rou=3D
> > > ting<br>
> > > &gt; &gt; Stream=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 :
> > IETF<br>
> > > &gt; &gt; Verifying Party=3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0: IESG<br>
> > > &gt; &gt;<br>
> > > &gt; &gt;<br>
> > > &gt;<br>
> > > </div></div>&gt; --001a11397a2c9bda6e050a6f3= 1ae<br>
> > > &gt; Content-Type: text/html; charset=3D3D&quot;UTF-= 8&quot;<br>
> > > &gt; Content-Transfer-Encoding: quoted-printable<br&g= t;
> > > &gt;<br>
> > > &gt; &lt;div dir=3D3D3D&quot;ltr&quot;&g= t;Hi
> > Yakov,&lt;br&gt;&lt;br&gt;Could =3D
> > > you clarify your point for this err=3D3D<br>
> > > &gt; ata?=3D3DC2=3D3DA0 In RFC 4090, in the terminology = it
> > says:&lt;br&gt;&amp;=3D
> > > quot; Backup Path: =3D3D<br>
> > > &gt; The LSP that is responsible for backing up one&= lt;br&gt;=3D3DC2=3D3DA0
> > =3D3D=3D
> > > C2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3D<br>
> > > &gt; =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA= 0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0
> > =3D3DC2=3D3DA=3D
> > > 0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0protected LSP.=3D3D<br>=
> > > &gt; =3D3DC2=3D3DA0 A backup path refers to either a det= our
> > LSP&lt;br&gt;=3D3DC2=3D
> > > =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3D<br>
> > > &gt; =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC= 2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0
> > =3D3DC=3D
> > > 2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0or a backup t=3D3D<= br>
> > > &gt; unnel.&lt;br&gt;&lt;br&gt;=3D3DC2= =3D3DA0 Backup Tunnel: The LSP that is
> > us=3D
> > > ed to backup up one o=3D3D<br>
> > > &gt; f the many&lt;br&gt;=3D3DC2=3D3DA0 =3D3DC2= =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0
> > =3D3DC2=3D
> > > =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2= =3D3D<br>
> > > &gt; =3D3DA0LSPs in many-to-one
> > backup.&amp;quot;&lt;div&gt;&lt;br&gt;&lt= ;/di=3D
> > > v&gt;&lt;div&gt;Thanks,&lt;/div&gt;&= lt;div&gt;A=3D3D<br>
> > > &gt; lia&lt;/div&gt;&lt;/div&gt;&lt;= div
> > class=3D3D3D&quot;gmail_extra&quot;&g=3D
> > > t;&lt;br&gt;&lt;div class=3D3D3D&quot;gmail_= quote&quot;&gt;On=3D3D<br>
> > > &gt;=3DC2=3DA0 Wed, Dec 17, 2014 at 3:07 PM, RFC Errata = System &lt;span
> > dir=3D3D3=3D
> > > D&quot;ltr&quot;&gt;&amp;lt;&lt;a h=3D3D= <br>
> > > &gt; ref=3D3D3D&quot;mailto:<a href=3D3D"mai= lto:rfc-editor@rfc-editor.org<= /a>
> > ">rfc-=3D
> > > editor@rfc-editor.o= rg</a>&quot;
> > target=3D3D3D&quot;_blank&quot;&gt;rfc-editor=3D
> > > @rfc-e=3D3D<br>
> > > &gt; <a href=3D3D"http://ditor.org" target=3D3D"_blank"&g= t;ditor.org
> > </a>&lt;/a&gt;=3D
> > > &amp;gt;&lt;/span&gt; wrote:&lt;br&gt;&a= mp;lt;blockquote
> > class=3D3D3D&quot;gmail_=3D
> > > quote&quot; style=3D3D<br>
> > > &gt; =3D3D3D&quot;margin:0 0 0 .8ex;border-left:1px = #ccc
> > solid;padding-left:1=3D
> > > ex&quot;&gt;The foll=3D3D<br>
> > > owing errata report has been submitted for RFC4090,&lt;b= r&gt;<br>
> > > &gt; &amp;quot;Fast Reroute Extensions to RSVP-TE fo= r LSP
> > Tunnels&amp;quot;=3D
> > > .&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; --------------------------------------&lt;br&am= p;gt;<br>
> > > &gt; You may review the report below and at:&lt;br&a= mp;gt;<br>
> > > &gt; &lt;a href=3D3D3D&quot;<a href=3D3D"= ;
> > http://www.rfc-editor.org/errata_searc=3D
> > > h.php?rfc=3D3D3D4090&amp;amp;eid=3D3D" target=3D3D&= quot;_blank">
> > http://www.r= fc-editor.=3D
> > > org/errata_search.php?rfc=3D3D3D4090&amp;amp;eid=3D3D<= ;/a><br>
> > > &gt; =3D3D3D4203&quot; target=3D3D3D&quot;_blank= &quot;&gt;<a href=3D3D"
> > http://www=3D
> > > .rfc-editor.org/errata_search.php?rfc=3D3D" tar= get=3D3D"_blank">
> > http://www.rfc-= =3D
> > > editor.org/errata_search.php?rfc=3D3D</a><br>= ;
> > > &gt; =3D3D3D4090&amp;amp;eid=3D3D3D4203&lt;/a&am= p;gt;&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; --------------------------------------&lt;br&am= p;gt;<br>
> > > &gt; Type: Technical&lt;br&gt;<br>
> > > &gt; Reported by: Yakov Rekhter &amp;lt;&lt;a hr= ef=3D3D3D&quot;mailto:<a
> > href=3D
> > > =3D3D"mailto:yakov= @juniper.net">yakov@junipe= r.net</a>&quot;&gt;yakov@j
> > =3D3D<br>
> > > &gt; <a href=3D3D"http://uniper.net" target=3D3D"_blank"= >uniper.net
> > </a>&lt;/a&g=3D
> > > t;&amp;gt;&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Section: 6&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Original Text&lt;br&gt;<br>
> > > &gt; -------------&lt;br&gt;<br>
> > > &gt; Whenever the PLR has a backup path available, the P= LR MUST
> > set&lt;br&g=3D
> > > t;<br>
> > > &gt; the &amp;quot;local protection available&am= p;quot;
> > flag.&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Corrected Text&lt;br&gt;<br>
> > > &gt; --------------&lt;br&gt;<br>
> > > &gt; Whenever the PLR has a one-to-one backup LSP or byp= ass
> > tunnel&lt;br&gt=3D
> > > ;<br>
> > > &gt; available, the PLR MUST set the &amp;quot;local= protection
> > available&a=3D
> > > mp;quot; flag=3D3D<br>
> > > &gt; .&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Notes&lt;br&gt;<br>
> > > &gt; -----&lt;br&gt;<br>
> > > &gt; In the case of facility-based FRR the PLR must set = the
> > &amp;quot;local=3D
> > >=C2=A0 protecti=3D3D<br>
> > > &gt; on available&amp;quot; flag if it has the bypas= s tunnel
> > available.&lt;=3D
> > > br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; Instructions:&lt;br&gt;<br>
> > > &gt; -------------&lt;br&gt;<br>
> > > &gt; This erratum is currently posted as &amp;quot;R= eported&amp;quot;.
> > If n=3D
> > > ecessary, ple=3D3D<br>
> > > &gt; ase&lt;br&gt;<br>
> > > &gt; use &amp;quot;Reply All&amp;quot; to discus= s whether it should be
> > veri=3D
> > > fied or&lt;br&gt;<br>
> > > &gt; rejected. When a decision is reached, the verifying= party
> > (IESG)&lt;br=3D
> > > &gt;<br>
> > > &gt; can log in to change the status and edit the report= , if
> > necessary.&lt;=3D
> > > br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; --------------------------------------&lt;br&am= p;gt;<br>
> > > &gt; RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07)&a= mp;lt;br&gt;<br>
> > > &gt; --------------------------------------&lt;br&am= p;gt;<br>
> > > &gt; Title=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 = =3D3DC2=3D3DA0 =3D3DC2=3D3DA0
> > =3D3DC2=3D3DA0=3D
> > >=C2=A0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0: Fast Reroute =3D3D<b= r>
> > > &gt; Extensions to RSVP-TE for LSP Tunnels&lt;br&= ;gt;<br>
> > > &gt; Publication Date=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : May= 2005&lt;br&gt;<br>
> > > &gt; Author(s)=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3D= A0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0
> > =3D3DC2=3D
> > > =3D3DA0: P. Pan, Ed., G. Swallow=3D3D<br>
> > > &gt; , Ed., A. Atlas, Ed.&lt;br&gt;<br> > > > &gt; Category=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA= 0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0
> > =3D3DC2=3D
> > > =3D3DA0 : PROPOSED STANDARD&lt;br&gt;<br>
> > > &gt; Source=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 = =3D3DC2=3D3DA0 =3D3DC2=3D3DA0
> > =3D3DC2=3D3DA=3D
> > > 0 =3D3DC2=3D3DA0 : Multiprotocol Labe=3D3D<br>
> > > &gt; l Switching&lt;br&gt;<br>
> > > &gt; Area=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 = =3D3DC2=3D3DA0 =3D3DC2=3D3DA0
> > =3D3DC2=3D3DA0 =3D
> > > =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : Routing&lt;br&gt;<= ;br>
> > > &gt; Stream=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 = =3D3DC2=3D3DA0 =3D3DC2=3D3DA0
> > =3D3DC2=3D3DA=3D
> > > 0 =3D3DC2=3D3DA0 : IETF&lt;br&gt;<br>
> > > &gt; Verifying Party=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC= 2=3D3DA0: IESG&lt;br&gt;<br>
> > > &gt; &lt;br&gt;<br>
> > > &gt; &lt;/blockquote&gt;&lt;/div&gt;&= ;lt;br&gt;&lt;/div&gt;<br>
> > > &gt;<br>
> > > &gt; --001a11397a2c9bda6e050a6f31ae--<br>
> > > </blockquote></div><br></div></di= v>
> > >
> > > --047d7b5d99a33a914b050a70164e--
> >
>
> --001a11c1e9ee40fd19050a7068c9
> Content-Type: text/html; charset=3D"UTF-8"<= br> > Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D3D"ltr">Yakov,<div class=3D3D"gmail= _extra"><br><div class=3D3D"gmail_q=3D
> uote">On Wed, Dec 17, 2014 at 4:41 PM, Yakov Rekhter &l= t;span dir=3D3D"ltr">&lt;=3D
> <a href=3D3D"mailto:yakov@juniper.net" target=3D3D"_blank">yakov@juniper.net</a=3D
> >&gt;</span> wrote:<br><blockquote class=3D3D&qu= ot;gmail_quote" style=3D3D"margin:0 =3D
> 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Alia,<= ;br>
> <span class=3D3D""><br>
> &gt; Yakov,<br>
> &gt;<br>
> &gt; On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter &lt;<a = href=3D3D"mailto:y=3D
> akov@juniper.net">yakov@juniper.net</a>&gt; wr= ote:<br>
> &gt;<br>
> &gt; &gt; Alia,<br>
> &gt; &gt;<br>
> &gt; &gt; &gt; Hi Yakov,<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; Could you clarify your point for this errat= a?=3DC2=3DA0 In RFC 4=3D
> 090, in the<br>
> &gt; &gt; &gt; terminology it says:<br>
> &gt; &gt; &gt;=3DC2=3DA0 &quot;Backup Path: The LSP th= at is responsible for bac=3D
> king up one<br>
> &gt; &gt; &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3D
> =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 protected LSP.=3DC2=3DA0 A back= up path refers to eithe=3D
> r a<br>
> &gt; &gt; &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3D
> =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 detour LSP or a backup tunnel.&= lt;br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt;=3DC2=3DA0 =3DC2=3DA0Backup Tunnel: The LSP = that is used to backup up=3D
>=C2=A0 one of the many<br>
> &gt; &gt; &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3D
> =3DA0 LSPs in many-to-one backup.&quot;<br>
> &gt; &gt;<br>
> &gt; &gt; In the terminology it also says:<br>
> &gt; &gt;<br>
> &gt; &gt;=3DC2=3DA0 =3DC2=3DA0 &quot;Bypass Tunnel: An LSP= that is used to protect =3D
> a set of LSPs<br>
> &gt; &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA= 0 =3DC2=3DA0 =3DC2=3DA0passing over a com=3D
> mon facility.&quot;<br>
> &gt; &gt;<br>
> &gt; &gt; My point is that (unless the term &quot;bypass t= unnel&quot; means=3D
>=C2=A0 the same<br>
> &gt; &gt; as &quot;backup path&quot; or &quot;back= up tunnel&quot;) in many-=3D
> to-one backup<br>
> &gt; &gt; the &quot;local protection available&quot; f= lag for a given prote=3D
> cted LSP<br>
> &gt; &gt; MUST be set when the PLR has a *bypass* tunnel for t= hat LSP.<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt; Ah - ok.=3DC2=3DA0 A backup path that uses a bypass tu= nnel is not just the=3D
>=C2=A0 bypass<br>
> &gt; tunnel itself.<br>
> <br>
> </span>Correct.<br>
> <span class=3D3D""><br>
> &gt; There&#39;s the state associated for the protected LSP th= at<br>
> &gt; also needs to be created and installed.=3DC2=3DA0 In more con= crete terms, =3D
> this<br>
> &gt; is installing an out-segment with the appropriate label for t= he protec=3D
> ted<br>
> &gt; LSP to be understood by the merge point as<br>
> &gt; well as an outer label for the bypass LSP.<br>
> &gt;<br>
> &gt; So, the text refers to a backup path instead of a bypass tunn= el becaus=3D
> e<br>
> &gt; having the bypass tunnel isn&#39;t quite sufficient.<b= r>
> &gt; Does that make sense to you?<br>
> <br>
> </span>The current text is incorrect. This is because a PLR may = signal a<br=3D
> >
> backup path at the time of failure. Yet, one should not wait for<br= >
> the failure to set the &quot;local protection available&quot; = flag. The PLR=3D
> <br>
> should set this flag as soon as it has a *bypass* tunnel.<br><= ;/blockquote><=3D
> div><br></div><div>The backup path is created by = the PLR before the failure=3D
>=C2=A0 and thus, before the</div><div>associated signaling.= =3DC2=3DA0 Once the PLR ha=3D
> s done the work to create a backup path using</div><div>an= existing bypass =3D
> tunnel - which is internal work - then the PLR should set</div>&= lt;div>the &qu=3D
> ot;local protection available&quot; flag. =3DC2=3DA0</div>&l= t;div><br></div><div>A=3D
> lia=3DC2=3DA0<br></div><div><br></div>&l= t;div>=3DC2=3DA0</div><blockquote class=3D3D"gma=3D
> il_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-lef=3D
> t:1ex">
> Yakov.<br>
> <div><div class=3D3D"h5"><br>
> &gt;<br>
> &gt; Regards,<br>
> &gt; Alia<br>
> &gt;<br>
> &gt;<br>
> &gt; &gt; Yakov.<br>
> &gt; &gt;<br>
> &gt; &gt; &gt; Thanks,<br>
> &gt; &gt; &gt; Alia<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata= System &lt;<br>
> &gt; &gt; &gt; <a href=3D3D"mailto:rfc-editor@rfc-editor.org">rfc-ed= itor@rfc-=3D
> editor.org</a&g= t;&gt; wrote:<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt; The following errata report has be= en submitted for RFC4=3D
> 090,<br>
> &gt; &gt; &gt; &gt; &quot;Fast Reroute Extensions = to RSVP-TE for LSP Tunnel=3D
> s&quot;.<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt; ----------------------------------= ----<br>
> &gt; &gt; &gt; &gt; You may review the report below an= d at:<br>
> &gt; &gt; &gt; &gt; <a href=3D3D"http://www= .rfc-editor.org/errata_search.php?=3D
> rfc=3D3D4090&amp;eid=3D3D4203" target=3D3D"_blank"&= gt;http://w= ww.rfc-editor.org/erra=3D
> ta_search.php?rfc=3D3D4090&amp;eid=3D3D4203</a><br> > &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt; ----------------------------------= ----<br>
> &gt; &gt; &gt; &gt; Type: Technical<br>
> &gt; &gt; &gt; &gt; Reported by: Yakov Rekhter &lt= ;<a href=3D3D"mailto:yakov@=3D
> juniper.net"= >yakov@juniper.net</a>&am= p;gt;<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt; Section: 6<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt; Original Text<br>
> &gt; &gt; &gt; &gt; -------------<br>
> &gt; &gt; &gt; &gt; Whenever the PLR has a backup path= available, the PLR M=3D
> UST set<br>
> &gt; &gt; &gt; &gt; the &quot;local protection ava= ilable&quot; flag.<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt; Corrected Text<br>
> &gt; &gt; &gt; &gt; --------------<br>
> &gt; &gt; &gt; &gt; Whenever the PLR has a one-to-one = backup LSP or bypass =3D
> tunnel<br>
> &gt; &gt; &gt; &gt; available, the PLR MUST set the &a= mp;quot;local protection =3D
> available&quot; flag.<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt; Notes<br>
> &gt; &gt; &gt; &gt; -----<br>
> &gt; &gt; &gt; &gt; In the case of facility-based FRR = the PLR must set the =3D
> &quot;local<br>
> &gt; &gt; protection<br>
> &gt; &gt; &gt; &gt; available&quot; flag if it has= the bypass tunnel availa=3D
> ble.<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt; Instructions:<br>
> &gt; &gt; &gt; &gt; -------------<br>
> &gt; &gt; &gt; &gt; This erratum is currently posted a= s &quot;Reported&quot=3D
> ;. If necessary, please<br>
> &gt; &gt; &gt; &gt; use &quot;Reply All&quot; = to discuss whether it should =3D
> be verified or<br>
> &gt; &gt; &gt; &gt; rejected. When a decision is reach= ed, the verifying par=3D
> ty (IESG)<br>
> &gt; &gt; &gt; &gt; can log in to change the status an= d edit the report, if=3D
>=C2=A0 necessary.<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt; ----------------------------------= ----<br>
> &gt; &gt; &gt; &gt; RFC4090 (draft-ietf-mpls-rsvp-lsp-= fastreroute-07)<br>
> &gt; &gt; &gt; &gt; ----------------------------------= ----<br>
> &gt; &gt; &gt; &gt; Title=3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D
> =3DC2=3DA0: Fast Reroute Extensions to RSVP-TE for LSP<br>
> &gt; &gt; Tunnels<br>
> &gt; &gt; &gt; &gt; Publication Date=3DC2=3DA0 =3DC2= =3DA0 : May 2005<br>
> &gt; &gt; &gt; &gt; Author(s)=3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0: P. =3D
> Pan, Ed., G. Swallow, Ed., A. Atlas, Ed.<br>
> &gt; &gt; &gt; &gt; Category=3DC2=3DA0 =3DC2=3DA0 =3DC= 2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 : PRO=3D
> POSED STANDARD<br>
> &gt; &gt; &gt; &gt; Source=3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D
> : Multiprotocol Label Switching<br>
> &gt; &gt; &gt; &gt; Area=3DC2=3DA0 =3DC2=3DA0 =3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D
> =3DC2=3DA0 : Routing<br>
> &gt; &gt; &gt; &gt; Stream=3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D
> : IETF<br>
> &gt; &gt; &gt; &gt; Verifying Party=3DC2=3DA0 =3DC2=3D= A0 =3DC2=3DA0: IESG<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &gt;<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; --001a11397a2c9bda6e050a6f31ae<br> > &gt; &gt; &gt; Content-Type: text/html; charset=3D3D&q= uot;UTF-8&quot;<br>
> &gt; &gt; &gt; Content-Transfer-Encoding: quoted-printable= <br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; &lt;div dir=3D3D3D&quot;ltr&quo= t;&gt;Hi Yakov,&lt;br&gt;&lt;br=3D
> &gt;Could you clarify your point for this<br>
> &gt; &gt; err=3D3D<br>
> &gt; &gt; &gt; ata?=3D3DC2=3D3DA0 In RFC 4090, in the term= inology it says:&lt;b=3D
> r&gt;&amp;quot; Backup<br>
> &gt; &gt; Path: =3D3D<br>
&gt; &gt; &gt; The LSP that is responsible for backing up one&a= mp;lt;br&gt;=3D3DC=3D
> 2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0<br>
> &gt; &gt; =3D3DC2=3D3D<br>
> &gt; &gt; &gt; =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3D= C2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0=3D
>=C2=A0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0protected<br><= br> > &gt; &gt; LSP.=3D3D<br>
> &gt; &gt; &gt; =3D3DC2=3D3DA0 A backup path refers to eith= er a detour LSP&lt;br=3D
> &gt;=3D3DC2=3D3DA0 =3D3DC2=3D3DA0<br>
> &gt; &gt; =3D3DC2=3D3DA0 =3D3D<br>
> &gt; &gt; &gt; =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA= 0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D
> =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0or a<br>
> &gt; &gt; backup t=3D3D<br>
> &gt; &gt; &gt; unnel.&lt;br&gt;&lt;br&gt;= =3D3DC2=3D3DA0 Backup Tunnel: The LSP =3D
> that is used to backup up<br>
> &gt; &gt; one o=3D3D<br>
> &gt; &gt; &gt; f the many&lt;br&gt;=3D3DC2=3D3DA0 = =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D
> =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0<= ;br>
> &gt; &gt; =3D3DC2=3D3D<br>
> &gt; &gt; &gt; =3D3DA0LSPs in many-to-one<br>
> &gt; &gt; backup.&amp;quot;&lt;div&gt;&lt;br&a= mp;gt;&lt;/div&gt;&lt;div&gt;Than=3D
> ks,&lt;/div&gt;&lt;div&gt;A=3D3D<b= r>
> &gt; &gt; &gt; lia&lt;/div&gt;&lt;/div&= amp;gt;&lt;div class=3D3D3D&quot;gmail_ext=3D
> ra&quot;&gt;&lt;br&gt;&lt;div<br>
> &gt; &gt; class=3D3D3D&quot;gmail_quote&quot;&gt;O= n=3D3D<br>
> &gt; &gt; &gt;=3DC2=3DA0 Wed, Dec 17, 2014 at 3:07 PM, RFC= Errata System &lt;sp=3D
> an<br>
> &gt; &gt; dir=3D3D3D&quot;ltr&quot;&gt;&amp;lt= ;&lt;a h=3D3D<br>
> &gt; &gt; &gt; ref=3D3D3D&quot;mailto:<a href=3D3D&= quot;mailto:rfc-editor@rfc-editor<= /a>=3D
> .org">rfc-editor@= rfc-editor.org</a>&quot;<br>
> &gt; &gt; target=3D3D3D&quot;_blank&quot;&gt;rfc-e= ditor@rfc-e=3D3D<br>
> &gt; &gt; &gt; <a href=3D3D"http://ditor.org" target=3D3D"_blank= ">ditor.org</= a>=3D
> &lt;/a&gt;&amp;gt;&lt;/span&gt; wrote:&lt;br&a= mp;gt;&lt;blockquote class=3D3D3D&q=3D
> uot;gmail_quote&quot;<br>
> &gt; &gt; style=3D3D<br>
> &gt; &gt; &gt; =3D3D3D&quot;margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padd=3D
> ing-left:1ex&quot;&gt;The<br>
> &gt; &gt; foll=3D3D<br>
> &gt; &gt; owing errata report has been submitted for RFC4090,&= amp;lt;br&gt;<br>
> &gt; &gt; &gt; &amp;quot;Fast Reroute Extensions to RS= VP-TE for LSP Tunnels=3D
> &amp;quot;.&lt;br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; --------------------------------------&= lt;br&gt;<br>
> &gt; &gt; &gt; You may review the report below and at:&= ;lt;br&gt;<br>
> &gt; &gt; &gt; &lt;a href=3D3D3D&quot;<br> > &gt; &gt; <a href=3D3D"http://www.rfc-e= ditor.org/errata_search.php?rfc=3D3D3D40=3D
> 90&amp;amp;eid=3D3D" target=3D3D"_blank">http://www= .rfc-editor.org/errata_searc=3D
> h.php?rfc=3D3D3D4090&amp;amp;eid=3D3D</a>&l= t;br>
> &gt; &gt; &gt; =3D3D3D4203&quot; target=3D3D3D&= amp;quot;_blank&quot;&gt;<br>
> &gt; &gt; <a href=3D3D"http://www.rfc-editor.o= rg/errata_search.php?rfc=3D3D" ta=3D
> rget=3D3D"_blank">http://www.rfc-editor.org/errat= a_search.php?rfc=3D3D</a><br>
> &gt; &gt; &gt; =3D3D3D4090&amp;amp;eid=3D3D3D4203&= lt;/a&gt;&lt;br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; --------------------------------------&= lt;br&gt;<br>
> &gt; &gt; &gt; Type: Technical&lt;br&gt;<br>=
> &gt; &gt; &gt; Reported by: Yakov Rekhter &amp;lt;&= ;lt;a href=3D3D3D&quot;mail=3D
> to:<a href=3D3D"mailto:ya= kov@juniper.net">yakov@jun= iper.net</a><br>
> &gt; &gt; &quot;&gt;yakov@j=3D3D<br>
> &gt; &gt; &gt; <a href=3D3D"http://uniper.net" target=3D3D"_bla= nk">uniper.net&= lt;/=3D
> a>&lt;/a&gt;&amp;gt;&lt;br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; Section: 6&lt;br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; Original Text&lt;br&gt;<br> > &gt; &gt; &gt; -------------&lt;br&gt;<br> > &gt; &gt; &gt; Whenever the PLR has a backup path availabl= e, the PLR MUST s=3D
> et&lt;br&gt;<br>
> &gt; &gt; &gt; the &amp;quot;local protection availabl= e&amp;quot; flag.&lt;=3D
> br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; Corrected Text&lt;br&gt;<br><= br> > &gt; &gt; &gt; --------------&lt;br&gt;<br><= br> > &gt; &gt; &gt; Whenever the PLR has a one-to-one backup LS= P or bypass tunne=3D
> l&lt;br&gt;<br>
> &gt; &gt; &gt; available, the PLR MUST set the &amp;qu= ot;local protection a=3D
> vailable&amp;quot;<br>
> &gt; &gt; flag=3D3D<br>
> &gt; &gt; &gt; .&lt;br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; Notes&lt;br&gt;<br>
> &gt; &gt; &gt; -----&lt;br&gt;<br>
> &gt; &gt; &gt; In the case of facility-based FRR the PLR m= ust set the &amp;=3D
> quot;local<br>
> &gt; &gt; protecti=3D3D<br>
> &gt; &gt; &gt; on available&amp;quot; flag if it has t= he bypass tunnel avai=3D
> lable.&lt;br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; Instructions:&lt;br&gt;<br> > &gt; &gt; &gt; -------------&lt;br&gt;<br> > &gt; &gt; &gt; This erratum is currently posted as &am= p;quot;Reported&amp;q=3D
> uot;. If necessary,<br>
> &gt; &gt; ple=3D3D<br>
> &gt; &gt; &gt; ase&lt;br&gt;<br>
> &gt; &gt; &gt; use &amp;quot;Reply All&amp;quot; t= o discuss whether it shou=3D
> ld be verified or&lt;br&gt;<br>
> &gt; &gt; &gt; rejected. When a decision is reached, the v= erifying party (I=3D
> ESG)&lt;br&gt;<br>
> &gt; &gt; &gt; can log in to change the status and edit th= e report, if nece=3D
> ssary.&lt;br&gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; --------------------------------------&= lt;br&gt;<br>
> &gt; &gt; &gt; RFC4090 (draft-ietf-mpls-rsvp-lsp-fastrerou= te-07)&lt;br&gt;<=3D
> br>
> &gt; &gt; &gt; --------------------------------------&= lt;br&gt;<br>
> &gt; &gt; &gt; Title=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2= =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D
> =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0: Fast<br>
> &gt; &gt; Reroute =3D3D<br>
> &gt; &gt; &gt; Extensions to RSVP-TE for LSP Tunnels&l= t;br&gt;<br>
> &gt; &gt; &gt; Publication Date=3D3DC2=3D3DA0 =3D3DC2=3D3D= A0 : May 2005&lt;br&gt;<b=3D
> r>
> &gt; &gt; &gt; Author(s)=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3= DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D
> =3D3DA0 =3D3DC2=3D3DA0: P. Pan, Ed., G.<br>
> &gt; &gt; Swallow=3D3D<br>
> &gt; &gt; &gt; , Ed., A. Atlas, Ed.&lt;br&gt;<b= r>
> &gt; &gt; &gt; Category=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3D= C2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3D=3D
> A0 =3D3DC2=3D3DA0 : PROPOSED STANDARD&lt;br&gt;<br>
> &gt; &gt; &gt; Source=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2= =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0=3D
>=C2=A0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : Multiprotocol<br>
> &gt; &gt; Labe=3D3D<br>
> &gt; &gt; &gt; l Switching&lt;br&gt;<br>
> &gt; &gt; &gt; Area=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2= =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D
> =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : Routing&lt;br&g= t;<br>
> &gt; &gt; &gt; Stream=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2= =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0=3D
>=C2=A0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : IETF&lt;br&gt;<br>=
> &gt; &gt; &gt; Verifying Party=3D3DC2=3D3DA0 =3D3DC2=3D3DA= 0 =3D3DC2=3D3DA0: IESG&lt;br&=3D
> gt;<br>
> &gt; &gt; &gt; &lt;br&gt;<br>
> &gt; &gt; &gt; &lt;/blockquote&gt;&lt;/div&= ;gt;&lt;br&gt;&lt;/div&gt;<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; --001a11397a2c9bda6e050a6f31ae--<br><= br> > &gt; &gt;<br>
> &gt;<br>
> </div></div>&gt; --047d7b5d99a33a914b050a70164e= <br>
> <span class=3D3D"">&gt; Content-Type: text/html; c= harset=3D3D&quot;UTF-8&quot;<=3D
> br>
> &gt; Content-Transfer-Encoding: quoted-printable<br>
> &gt;<br>
> </span>&gt; &lt;div dir=3D3D3D&quot;ltr&q= uot;&gt;Yakov,&lt;div class=3D3D3D&quo=3D
> t;gmail_extra&quot;&gt;&lt;br&gt;&lt;div class=3D3= D3D&quot;gmail_q=3D3D<br>
> &gt; uote&quot;&gt;On Wed, Dec 17, 2014 at 4:05 PM, Yakov = Rekhter &lt;span =3D
> dir=3D3D3D&quot;ltr&quot;&gt;&amp;lt;=3D3D<br> > &gt; &lt;a href=3D3D3D&quot;mailto:<a href=3D3D"ma= ilto:yakov@juniper.net">ya= kov=3D
> @juniper.net</= a>&quot; target=3D3D3D&quot;_blank&quot;&gt;<a href= =3D3D"mailto:y=3D
> akov@juniper.net">yakov@juniper.net</a>&lt;/a= =3D3D<br>
> &gt; &gt;&amp;gt;&lt;/span&gt; wrote:&lt;br&am= p;gt;&lt;blockquote class=3D3D3D&qu=3D
> ot;gmail_quote&quot; style=3D3D3D&quot;margin:0 =3D3D<br>= ;
> &gt; 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex&quot= ;&gt;Alia,&lt=3D
> ;br&gt;<br>
> &gt; &lt;span class=3D3D3D&quot;&quot;&gt;&lt;= br&gt;<br>
> &gt; &amp;gt; Hi Yakov,&lt;br&gt;<br>
> &gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; Could you clarify your point for this errata?=3D= 3DC2=3D3DA0 In RF=3D
> C 4090, in th=3D3D<br>
> &gt; e&lt;br&gt;<br>
> &gt; &amp;gt; terminology it says:&lt;br&gt;<br>=
> &gt; &amp;gt;=3D3DC2=3D3DA0 &amp;quot;Backup Path: The LSP= that is responsible =3D
> for backing up on=3D3D<br>
&gt; e&lt;br&gt;<br>
> &gt; &amp;gt;=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3= DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D
> =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 = =3D3D<br>
> &gt; =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 protected LSP.=3D3DC2=3D3DA0 A = backup path refers to=3D
>=C2=A0 either a&lt;br&gt;<br>
> &gt; &amp;gt;=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3= DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D
> =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 = =3D3D<br>
> &gt; =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 detour LSP or a backup tunnel.&= amp;lt;br&gt;<br>
> &gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt;=3D3DC2=3D3DA0 =3D3DC2=3D3DA0Backup Tunnel: The L= SP that is used to ba=3D
> ckup up one of th=3D3D<br>
> &gt; e many&lt;br&gt;<br>
> &gt; &amp;gt;=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3= DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D
> =3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 LSPs in =3D3D<= br>
> &gt; many-to-one backup.&amp;quot;&lt;br&gt;<br>=
> &gt; &lt;br&gt;<br>
> &gt; &lt;/span&gt;In the terminology it also says:&lt;= br&gt;<br>
> &gt; &lt;br&gt;<br>
> &gt; =3D3DC2=3D3DA0 =3D3DC2=3D3DA0&amp;quot;Bypass Tunnel: An = LSP that is used to p=3D
> rotect a set of L=3D3D<br>
> &gt; SPs&lt;br&gt;<br>
> &gt; =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 = =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 pass=3D
> ing over a common facility.&amp;q=3D3D<br>
> &gt; uot;&lt;br&gt;<br>
> &gt; &lt;br&gt;<br>
> &gt; My point is that (unless the term &amp;quot;bypass tunnel= &amp;quot; me=3D
> ans the same&lt;=3D3D<br>
> &gt; br&gt;<br>
> &gt; as &amp;quot;backup path&amp;quot; or &amp;quot;b= ackup tunnel&amp;quot=3D
> ;) in many-to-one bac=3D3D<br>
> &gt; kup&lt;br&gt;<br>
> &gt; the &amp;quot;local protection available&amp;quot; fl= ag for a given pr=3D
> otected LSP&lt;b=3D3D<br>
> &gt; r&gt;<br>
> &gt; MUST be set when the PLR has a *bypass* tunnel for that LSP.&= amp;lt;br&gt;=3D
> &lt;/blockquot=3D3D<br>
> &gt; e&gt;&lt;div&gt;&lt;br&gt;&lt;/div&am= p;gt;&lt;div&gt;Ah - ok.=3D3DC2=3D3DA0 A =3D
> backup path that uses a bypass tunne=3D3D<br>
> &gt; l is not just the bypass tunnel&lt;/div&gt;&lt;di= v&gt;itself.=3D3DC2=3D3DA=3D
> 0 There&amp;#39;s the sta=3D3D<br>
> &gt; te associated for the protected LSP that also needs to be&= ;lt;/div&gt;&=3D
> lt;div&gt;created=3D3D<br>
> &gt;=3DC2=3DA0 and installed.=3D3DC2=3D3DA0 In more concrete terms= , this is install=3D
> ing an out-seg=3D3D<br>
> &gt; ment with=3D3DC2=3D3DA0&lt;/div&gt;&lt;div&gt= ;the appropriate label for th=3D
> e protected LSP to be=3D3D<br>
> &gt;=3DC2=3DA0 understood by the merge point as&lt;/div&gt= ;&lt;div&gt;well as a=3D
> n outer label for the =3D3D<br>
> &gt; bypass LSP.&lt;/div&gt;&lt;div&gt;&lt;br&= amp;gt;&lt;/div&gt;&lt;div&gt;So,=3D
>=C2=A0 the text refers to a backup path i=3D3D<br>
> &gt; nstead of a bypass tunnel because having the&lt;/div&= gt;&lt;div&gt;byp=3D
> ass tunnel isn&amp;#3=3D3D<br>
> &gt; 9;t quite sufficient.=3D3DC2=3D3DA0 Does that make sense to y= ou?&lt;/div&g=3D
> t;&lt;div&gt;&lt;br&gt;&lt;/di=3D3D<br>
> &gt; v&gt;&lt;div&gt;Regards,&lt;/div&gt;&= lt;div&gt;Alia&lt;/div&gt;&lt;div=3D
> &gt;=3D3DC2=3D3DA0&lt;/div&gt;&lt;blockquote class=3D3= D3D&quot;g=3D3D<br>
> &gt; mail_quote&quot; style=3D3D3D&quot;margin:0 0 0 .8ex;= border-left:1px #cc=3D
> c solid;padding-l=3D3D<br>
> &gt; eft:1ex&quot;&gt;<br>
> &gt; Yakov.&lt;br&gt;<br>
> &gt; &lt;div&gt;&lt;div class=3D3D3D&quot;h5&q= uot;&gt;&lt;br&gt;<br>
> &gt; &amp;gt; Thanks,&lt;br&gt;<br>
> &gt; &amp;gt; Alia&lt;br&gt;<br>
> &gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata Syst= em &amp;lt;&l=3D
> t;br&gt;<br>
> &gt; &amp;gt; &lt;a href=3D3D3D&quot;mailto:<a href= =3D3D"mailto:rfc-editor@rfc-=3D=
> editor.org"&g= t;rfc-editor@rfc-editor.org</a>&quot;&gt;<a href=3D3D"mailto:rfc-ed=3D
> itor@rfc-editor.org"&g= t;rfc-editor@rfc-editor.org</a>=3D3D<br>
> &gt; &lt;/a&gt;&amp;gt; wrote:&lt;br&gt;<br= >
> &gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; The following errata report has bee= n submitted for R=3D
> FC4090,&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; &amp;quot;Fast Reroute Extensio= ns to RSVP-TE for LSP=3D
>=C2=A0 Tunnels&amp;quot;.&lt;b=3D3D<br>
> &gt; r&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; -----------------------------------= ---&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; You may review the report below and= at:&lt;br&gt;<br=3D
> >
> &gt; &amp;gt; &amp;gt; &lt;a href=3D3D3D&quot;<= a href=3D3D"http://= www.rfc-edito=3D
> r.org/errata_search.php?rfc=3D3D3D4090=3D3D" target=3D= 3D"_blank">http= ://www.rfc-e=3D
> ditor.org/errata_search.php?rfc=3D3D3D4090=3D3D</a>= ;<br>
> &gt; &amp;amp;eid=3D3D3D4203&quot; target=3D3D3D&quot;= _blank&quot;&gt;<a href=3D
> =3D3D"http://www.rfc-editor.org/errata_search.=3D3D" ta= rget=3D3D"_blank">http:= //w=3D
> ww.rfc-editor.org/errata_search.=3D3D</a><br>
> &gt; php?rfc=3D3D3D4090&amp;amp;eid=3D3D3D4203&lt;/a&g= t;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; -----------------------------------= ---&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Type: Technical&lt;br&gt;&l= t;br>
> &gt; &amp;gt; &amp;gt; Reported by: Yakov Rekhter &amp= ;lt;&lt;a href=3D3D3D&q=3D
> uot;mailto:<a href=3D3D"mailto:yakov@juniper.ne">yako= v@juniper.ne</a>=3D3D<br>
> &gt; t&quot;&gt;<a href=3D3D"mailto:yakov@juniper.net">yakov@juniper.net</a>&=3D
> lt;/a&gt;&amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Section: 6&lt;br&gt;<br&= gt;
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Original Text&lt;br&gt;<= br>
> &gt; &amp;gt; &amp;gt; -------------&lt;br&gt;<= br>
> &gt; &amp;gt; &amp;gt; Whenever the PLR has a backup path = available, the PL=3D
> R MUST set&lt;br=3D3D<br>
> &gt; &gt;<br>
> &gt; &amp;gt; &amp;gt; the &amp;quot;local protection = available&amp;quot; f=3D
> lag.&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Corrected Text&lt;br&gt;<= ;br>
> &gt; &amp;gt; &amp;gt; --------------&lt;br&gt;<= ;br>
> &gt; &amp;gt; &amp;gt; Whenever the PLR has a one-to-one b= ackup LSP or bypa=3D
> ss tunnel&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; available, the PLR MUST set the &am= p;amp;quot;local prot=3D
> ection available&amp;=3D3D<br>
> &gt; quot; flag.&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Notes&lt;br&gt;<br> > &gt; &amp;gt; &amp;gt; -----&lt;br&gt;<br> > &gt; &amp;gt; &amp;gt; In the case of facility-based FRR t= he PLR must set t=3D
> he &amp;quot;loca=3D3D<br>
> &gt; l protection&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; available&amp;quot; flag if it = has the bypass tunnel=3D
>=C2=A0 available.&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Instructions:&lt;br&gt;<= br>
> &gt; &amp;gt; &amp;gt; -------------&lt;br&gt;<= br>
> &gt; &amp;gt; &amp;gt; This erratum is currently posted as= &amp;quot;Report=3D
> ed&amp;quot;. If nece=3D3D<br>
> &gt; ssary, please&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; use &amp;quot;Reply All&amp= ;quot; to discuss whether=3D
>=C2=A0 it should be verifie=3D3D<br>
> &gt; d or&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; rejected. When a decision is reache= d, the verifying =3D
> party (IESG)&lt;=3D3D<br>
> &gt; br&gt;<br>
> &gt; &amp;gt; &amp;gt; can log in to change the status and= edit the report,=3D
>=C2=A0 if necessary=3D3D<br>
> &gt; .&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; -----------------------------------= ---&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; RFC4090 (draft-ietf-mpls-rsvp-lsp-f= astreroute-07)&lt=3D
> ;br&gt;<br>
> &gt; &amp;gt; &amp;gt; -----------------------------------= ---&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Title=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 = =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3D=3D
> C2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0: Fas=3D3D<br= >
> &gt; t Reroute Extensions to RSVP-TE for LSP Tunnels&lt;br&= ;gt;<br>
> &gt; &amp;gt; &amp;gt; Publication Date=3D3DC2=3D3DA0 =3D3= DC2=3D3DA0 : May 2005&lt;=3D
> br&gt;<br>
> &gt; &amp;gt; &amp;gt; Author(s)=3D3DC2=3D3DA0 =3D3DC2=3D3= DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0=3D
>=C2=A0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0: P. Pan, Ed., =3D3D<br>
> &gt; G. Swallow, Ed., A. Atlas, Ed.&lt;br&gt;<br> > &gt; &amp;gt; &amp;gt; Category=3D3DC2=3D3DA0 =3D3DC2=3D3D= A0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D
> =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : PROPOSED STAN=3D3D<br>
> &gt; DARD&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Source=3D3DC2=3D3DA0 =3D3DC2=3D3DA0= =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D
> =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : Multipro=3D3D<br>=
> &gt; tocol Label Switching&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Area=3D3DC2=3D3DA0 =3D3DC2=3D3DA0 = =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC=3D
> 2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : Rou=3D3D<br= >
> &gt; ting&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt; Stream=3D3DC2=3D3DA0 =3D3DC2=3D3DA0= =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D
> =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 =3D3DC2=3D3DA0 : IETF&lt;br&gt;&= lt;br>
> &gt; &amp;gt; &amp;gt; Verifying Party=3D3DC2=3D3DA0 =3D3D= C2=3D3DA0 =3D3DC2=3D3DA0: IES=3D
> G&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt;&lt;br&gt;<br>
> &gt; &lt;/div&gt;&lt;/div&gt;&amp;gt; --001a11= 397a2c9bda6e050a6f31ae&lt;br&=3D
> gt;<br>
> &gt; &amp;gt; Content-Type: text/html; charset=3D3D3D&amp;= quot;UTF-8&amp;quot=3D
> ;&lt;br&gt;<br>
> &gt; &amp;gt; Content-Transfer-Encoding: quoted-printable&= lt;br&gt;<br>
> &gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;lt;div dir=3D3D3D3D&amp;quot;ltr&am= p;amp;quot;&amp;gt;Hi Yakov=3D
> ,&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Could =3D3D<br= >
> &gt; you clarify your point for this err=3D3D3D&lt;br&gt;&= lt;br>
> &gt; &amp;gt; ata?=3D3D3DC2=3D3D3DA0 In RFC 4090, in the termi= nology it says:&a=3D
> mp;lt;br&amp;gt;&amp;amp;=3D3D<br>
> &gt; quot; Backup Path: =3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt; The LSP that is responsible for backing up one&a= mp;amp;lt;br&amp;=3D
> gt;=3D3D3DC2=3D3D3DA0 =3D3D3D=3D3D<br>
> &gt; C2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3D&lt;br&= ;gt;<br>
> &gt; &amp;gt; =3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 = =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D
> =3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA=3D3D<br>
> &gt; 0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0protected LSP.=3D3D3D&= amp;lt;br&gt;<br>
> &gt; &amp;gt; =3D3D3DC2=3D3D3DA0 A backup path refers to eithe= r a detour LSP&am=3D
> p;lt;br&amp;gt;=3D3D3DC2=3D3D<br>
> &gt; =3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3D&l= t;br&gt;<br>
> &gt; &amp;gt; =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2= =3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D
> =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC=3D3D<br>
> &gt; 2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0or a backup t= =3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt; unnel.&amp;lt;br&amp;gt;&amp;lt;br&a= mp;amp;gt;=3D3D3DC2=3D3D3DA0 Back=3D
> up Tunnel: The LSP that is us=3D3D<br>
> &gt; ed to backup up one o=3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt; f the many&amp;lt;br&amp;gt;=3D3D3DC2=3D= 3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D=3D
> 3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D<br>
> &gt; =3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3= D3DA0 =3D3D3DC2=3D3D3D&lt;b=3D
> r&gt;<br>
> &gt; &amp;gt; =3D3D3DA0LSPs in many-to-one backup.&amp;amp= ;quot;&amp;lt;div&a=3D
> mp;gt;&amp;lt;br&amp;gt;&amp;lt;/di=3D3D<br>
> &gt; v&amp;gt;&amp;lt;div&amp;gt;Thanks,&amp;lt;/d= iv&amp;gt;&amp;lt;div&amp=3D
> ;gt;A=3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt; lia&amp;lt;/div&amp;gt;&amp;lt;/div&= amp;amp;gt;&amp;lt;div class=3D
> =3D3D3D3D&amp;quot;gmail_extra&amp;quot;&amp;g=3D3D<br&= gt;
> &gt; t;&amp;lt;br&amp;gt;&amp;lt;div class=3D3D3D3D&am= p;amp;quot;gmail_quote&amp;=3D
> quot;&amp;gt;On=3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt;=3D3DC2=3D3DA0 Wed, Dec 17, 2014 at 3:07 PM, RFC = Errata System &am=3D
> p;lt;span dir=3D3D3D3=3D3D<br>
> &gt; D&amp;quot;ltr&amp;quot;&amp;gt;&amp;amp;lt;&= amp;amp;lt;a h=3D3D3D&lt;br&gt;=3D
> <br>
> &gt; &amp;gt; ref=3D3D3D3D&amp;quot;mailto:&lt;a href= =3D3D3D&quot;mailto:<a hre=3D
> f=3D3D"mailto:rfc-ed= itor@rfc-editor.org">rfc-editor@rfc-editor.org</a>&quot;&=3D
> gt;rfc-=3D3D<br>
> &gt; <a href=3D3D"mailto:editor@rfc-editor.org">editor@rfc-editor.org</a>&lt;=3D
> /a&gt;&amp;quot; target=3D3D3D3D&amp;quot;_blank&amp;q= uot;&amp;gt;rfc-editor=3D
> =3D3D<br>
> &gt; @rfc-e=3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt; &lt;a href=3D3D3D&quot;<a href=3D3D&q= uot;http://ditor.org&quo= t; target=3D3D"_=3D
> blank">http://d= itor.org</a>&quot; target=3D3D3D&quot;_blank&quot;&am= p;gt;<a href=3D
> =3D3D"http://ditor= .org" target=3D3D"_blank">ditor.org</a>&lt;/a&gt;&amp;lt;/a= &a=3D
> mp;gt;=3D3D<br>
> &gt; &amp;amp;gt;&amp;lt;/span&amp;gt; wrote:&amp;= lt;br&amp;gt;&amp;lt;bloc=3D
> kquote class=3D3D3D3D&amp;quot;gmail_=3D3D<br>
> &gt; quote&amp;quot; style=3D3D3D&lt;br&gt;<br><= br> > &gt; &amp;gt; =3D3D3D3D&amp;quot;margin:0 0 0 .8ex;border-= left:1px #ccc solid=3D
> ;padding-left:1=3D3D<br>
> &gt; ex&amp;quot;&amp;gt;The foll=3D3D3D&lt;br&gt;= <br>
> &gt; owing errata report has been submitted for RFC4090,&amp;l= t;br&amp;gt;&=3D
> lt;br&gt;<br>
> &gt; &amp;gt; &amp;amp;quot;Fast Reroute Extensions to RSV= P-TE for LSP Tunn=3D
> els&amp;amp;quot;=3D3D<br>
> &gt; .&amp;lt;br&amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; --------------------------------------&amp;l= t;br&amp;gt;&lt;b=3D
> r&gt;<br>
> &gt; &amp;gt; You may review the report below and at:&amp;= lt;br&amp;gt;&lt;=3D
> br&gt;<br>
> &gt; &amp;gt; &amp;lt;a href=3D3D3D3D&amp;quot;&lt= ;a href=3D3D3D&quot;<a href=3D
> =3D3D"http://www.rfc-editor.org/errata_searc=3D3D" target= =3D3D"_blank">http://= www=3D
> .rfc-editor.org/errata_searc=3D3D</a><br>
> &gt; h.php?rfc=3D3D3D3D4090&amp;amp;amp;eid=3D3D3D&quot; t= arget=3D3D3D&quot;_blan=3D
> k&quot;&gt;<a href=3D3D"http://www.rfc-editor." target=3D3D"_bl= ank">http://www.=3D > rfc-editor.</a>=3D3D<br>
> &gt; org/errata_search.php?rfc=3D3D3D3D4090&amp;amp;amp;eid=3D= 3D3D&lt;/a&gt;&lt=3D
> ;br&gt;<br>
> &gt; &amp;gt; =3D3D3D3D4203&amp;quot; target=3D3D3D3D&= amp;quot;_blank&amp;quot;=3D
> &amp;gt;&lt;a href=3D3D3D&quot;<a href=3D3D"http://www" target=3D3D"_b= lank">http:=3D
> //www</a>=3D3D<br>
> &gt; .<a href=3D3D"http://rfc-editor.org/errata_sear= ch.php?rfc=3D3D3D" target=3D
> =3D3D"_blank">rfc-editor.org/errata_search.php?rfc= =3D3D3D</a>&quot; target=3D3D3D=3D
> &quot;_blank&quot;&gt;<a href=3D3D"http://www.rfc-" target=3D3D"_= blank">http://=3D
> www.rfc-</a>=3D3D<br>
> &gt; <a href=3D3D"http://editor.org/errata_search.php?rf= c=3D3D3D" target=3D3D"_bl=3D
> ank">editor.org/errata_search.php?rfc=3D3D3D</a>&a= mp;lt;/a&gt;&lt;br&gt;<br>
> &gt; &amp;gt; =3D3D3D3D4090&amp;amp;amp;eid=3D3D3D3D4203&a= mp;amp;lt;/a&amp;gt;&amp;=3D
> lt;br&amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; --------------------------------------&amp;l= t;br&amp;gt;&lt;b=3D
> r&gt;<br>
> &gt; &amp;gt; Type: Technical&amp;lt;br&amp;gt;&lt= ;br&gt;<br>
> &gt; &amp;gt; Reported by: Yakov Rekhter &amp;amp;lt;&= amp;lt;a href=3D3D3D3D&=3D
> amp;quot;mailto:&lt;a href=3D3D<br>
> &gt; =3D3D3D&quot;mailto:<a href=3D3D"mailto:yakov@juniper.net">yakov@juniper.= n=3D
> et</a>&quot;&gt;<a href=3D3D"mailto:yakov@juniper.net">yakov@juniper.net</a>&=3D
> lt;/a&gt;&amp;quot;&amp;gt;yakov@j=3D3D3D&lt;br&gt= ;<br>
> &gt; &amp;gt; &lt;a href=3D3D3D&quot;<a href=3D3D&q= uot;http://uniper.net&q= uot; target=3D3D"=3D
> _blank">http:/= /uniper.net</a>&quot; target=3D3D3D&quot;_blank&quot;= &gt;<a hre=3D
> f=3D3D"http://uni= per.net" target=3D3D"_blank">uniper.net</a>&lt;/a&gt;&amp;= lt;/=3D
> a&amp;g=3D3D<br>
> &gt; t;&amp;amp;gt;&amp;lt;br&amp;gt;&lt;br&gt= ;<br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; Section: 6&amp;lt;br&amp;gt;&lt;br&a= mp;gt;<br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; Original Text&amp;lt;br&amp;gt;&lt;b= r&gt;<br>
> &gt; &amp;gt; -------------&amp;lt;br&amp;gt;&lt;b= r&gt;<br>
> &gt; &amp;gt; Whenever the PLR has a backup path available, th= e PLR MUST se=3D
> t&amp;lt;br&amp;g=3D3D<br>
> &gt; t;&lt;br&gt;<br>
> &gt; &amp;gt; the &amp;amp;quot;local protection available= &amp;amp;quot; fl=3D
> ag.&amp;lt;br&amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; Corrected Text&amp;lt;br&amp;gt;&lt;= br&gt;<br>
> &gt; &amp;gt; --------------&amp;lt;br&amp;gt;&lt;= br&gt;<br>
> &gt; &amp;gt; Whenever the PLR has a one-to-one backup LSP or = bypass tunnel=3D
> &amp;lt;br&amp;gt=3D3D<br>
> &gt; ;&lt;br&gt;<br>
> &gt; &amp;gt; available, the PLR MUST set the &amp;amp;quo= t;local protectio=3D
> n available&amp;a=3D3D<br>
> &gt; mp;quot; flag=3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt; .&amp;lt;br&amp;gt;&lt;br&gt;<= ;br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; Notes&amp;lt;br&amp;gt;&lt;br&gt= ;<br>
> &gt; &amp;gt; -----&amp;lt;br&amp;gt;&lt;br&gt= ;<br>
> &gt; &amp;gt; In the case of facility-based FRR the PLR must s= et the &amp;a=3D
> mp;quot;local=3D3D<br>
> &gt;=3DC2=3DA0 protecti=3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt; on available&amp;amp;quot; flag if it has th= e bypass tunnel a=3D
> vailable.&amp;lt;=3D3D<br>
> &gt; br&amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; Instructions:&amp;lt;br&amp;gt;&lt;b= r&gt;<br>
> &gt; &amp;gt; -------------&amp;lt;br&amp;gt;&lt;b= r&gt;<br>
> &gt; &amp;gt; This erratum is currently posted as &amp;amp= ;quot;Reported&am=3D
> p;amp;quot;. If n=3D3D<br>
> &gt; ecessary, ple=3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt; ase&amp;lt;br&amp;gt;&lt;br&gt;&= lt;br>
> &gt; &amp;gt; use &amp;amp;quot;Reply All&amp;amp;quot= ; to discuss whether =3D
> it should be veri=3D3D<br>
> &gt; fied or&amp;lt;br&amp;gt;&lt;br&gt;<br>=
> &gt; &amp;gt; rejected. When a decision is reached, the verify= ing party (IE=3D
> SG)&amp;lt;br=3D3D<br>
> &gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; can log in to change the status and edit the rep= ort, if neces=3D
> sary.&amp;lt;=3D3D<br>
> &gt; br&amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; --------------------------------------&amp;l= t;br&amp;gt;&lt;b=3D
> r&gt;<br>
> &gt; &amp;gt; RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07= )&amp;lt;br&a=3D
> mp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; --------------------------------------&am= p;amp;lt;br&amp;gt;&lt;b=3D
> r&gt;<br>
> &gt; &amp;gt; Title=3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D= 3DC2=3D3D3DA0 =3D3D3DC2=3D3D3=3D
> DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0=3D3D<br>
> &gt;=3DC2=3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0: Fast Reroute= =3D3D3D&lt;br&gt;<br>
> &gt; &amp;gt; Extensions to RSVP-TE for LSP Tunnels&amp;lt= ;br&amp;gt;&lt;br=3D
> &gt;<br>
> &gt; &amp;gt; Publication Date=3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3= D3DA0 : May 2005&amp;=3D
> lt;br&amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; Author(s)=3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 = =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D
> =3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D<br>
> &gt; =3D3D3DA0: P. Pan, Ed., G. Swallow=3D3D3D&lt;br&gt;&l= t;br>
> &gt; &amp;gt; , Ed., A. Atlas, Ed.&amp;lt;br&amp;gt;&a= mp;lt;br&gt;<br>
> &gt; &amp;gt; Category=3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 = =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D
> =3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D<br>
> &gt; =3D3D3DA0 : PROPOSED STANDARD&amp;lt;br&amp;gt;&l= t;br&gt;<br>
> &gt; &amp;gt; Source=3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3= D3DC2=3D3D3DA0 =3D3D3DC2=3D3D=3D
> 3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA=3D3D<br>
> &gt; 0 =3D3D3DC2=3D3D3DA0 : Multiprotocol Labe=3D3D3D&lt;br&am= p;gt;<br>
> &gt; &amp;gt; l Switching&amp;lt;br&amp;gt;&lt;br&= amp;gt;<br>
> &gt; &amp;gt; Area=3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3= DC2=3D3D3DA0 =3D3D3DC2=3D3D3D=3D
> A0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3D<br>
> &gt; =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 : Routing&amp;lt;br= &amp;gt;&lt;br&gt;<br=3D
> >
> &gt; &amp;gt; Stream=3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA0 =3D3= D3DC2=3D3D3DA0 =3D3D3DC2=3D3D=3D
> 3DA0 =3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D3DA=3D3D<br>
> &gt; 0 =3D3D3DC2=3D3D3DA0 : IETF&amp;lt;br&amp;gt;&lt;= br&gt;<br>
> &gt; &amp;gt; Verifying Party=3D3D3DC2=3D3D3DA0 =3D3D3DC2=3D3D= 3DA0 =3D3D3DC2=3D3D3DA0: =3D
> IESG&amp;lt;br&amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; &amp;lt;br&amp;gt;&lt;br&gt;<= br>
> &gt; &amp;gt; &amp;lt;/blockquote&amp;gt;&amp;lt;/= div&amp;gt;&amp;lt;br&amp=3D
> ;gt;&amp;lt;/div&amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt;&lt;br&gt;<br>
> &gt; &amp;gt; --001a11397a2c9bda6e050a6f31ae--&lt;br&g= t;<br>
> &gt; &lt;/blockquote&gt;&lt;/div&gt;&lt;br&= ;gt;&lt;/div&gt;&lt;/div&gt;<br>
> &gt;<br>
> &gt; --047d7b5d99a33a914b050a70164e--<br>
> </blockquote></div><br></div>= </div>
>
> --001a11c1e9ee40fd19050a7068c9--

--001a113a83b6b3fadd050bea9d74-- From nobody Mon Jan 5 09:03:52 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A76F1A6FF8 for ; Mon, 5 Jan 2015 09:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.176 X-Spam-Level: X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, J_CHICKENPOX_25=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPeDwGM-kZkF for ; Mon, 5 Jan 2015 09:03:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F04A1A6FF5 for ; Mon, 5 Jan 2015 09:03:04 -0800 (PST) Received: from DM2PR0501MB1437.namprd05.prod.outlook.com (25.161.224.147) by DM2PR0501MB1423.namprd05.prod.outlook.com (25.161.224.145) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 17:02:41 +0000 Received: from DM2PR0501MB1662.namprd05.prod.outlook.com (25.160.136.26) by DM2PR0501MB1437.namprd05.prod.outlook.com (25.161.224.147) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 17:02:38 +0000 Received: from DM2PR0501MB1662.namprd05.prod.outlook.com ([25.160.136.26]) by DM2PR0501MB1662.namprd05.prod.outlook.com ([25.160.136.26]) with mapi id 15.01.0049.002; Mon, 5 Jan 2015 17:02:38 +0000 From: Yakov Rekhter To: Alia Atlas Thread-Topic: [Technical Errata Reported] RFC4090 (4203) Thread-Index: AQHQKQkBSo9yzAHzDUagpIn9FMJyhpyxwHtw Date: Mon, 5 Jan 2015 17:02:38 +0000 Message-ID: References: <20141217200749.EAB02181CD8@rfc-editor.org> <201412172105.sBHL52u19645@magenta.juniper.net> <201412172141.sBHLfqu40272@magenta.juniper.net> <201412180211.sBI2BBW53068@magenta.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] authentication-results: spf=none (sender IP is ) smtp.mailfrom=yakov@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005003); SRVR:DM2PR0501MB1437; UriScan:; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(164054003)(189002)(37854004)(51704005)(199003)(377454003)(33656002)(19625215002)(110136001)(50986999)(120916001)(15975445007)(101416001)(93886004)(40100003)(16236675004)(107046002)(74316001)(15395725005)(20776003)(66066001)(77156002)(92566001)(16601075003)(102836002)(122556002)(97736003)(68736005)(64706001)(76176999)(31966008)(54606007)(62966003)(19617315012)(54356999)(87936001)(1411001)(86362001)(575784001)(2950100001)(2900100001)(99396003)(54206007)(15188155005)(19300405004)(2656002)(99286002)(19580405001)(512874002)(19580395003)(4396001)(46102003)(21056001)(105586002)(106116001)(76576001)(106356001)(19609705001)(18717965001)(16799955002)(319084006)(319154004)(559001)(579004)(299355004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1437; H:DM2PR0501MB1662.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DM2PR0501MB1662335A5977C94F9773CC94BE580DM2PR0501MB1662_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2015 17:02:38.4166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1437 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1423; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR0501MB1423; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1423; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JcdckIuDl26_1ga6R0J3KeUXhIo Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] [Technical Errata Reported] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:03:39 -0000 --_000_DM2PR0501MB1662335A5977C94F9773CC94BE580DM2PR0501MB1662_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxpYSwNCg0KVGhlIG1vZGlmaWVkIEVycmF0YSwgYXMgeW91IHN1Z2dlc3RlZCBiZWxvdywgaXMg ZmluZSB3aXRoIG1lLg0KDQpZYWtvdi4NCg0KRnJvbTogQWxpYSBBdGxhcyBbbWFpbHRvOmFrYXRs YXNAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDA1LCAyMDE1IDEyOjAwIFBNDQpU bzogWWFrb3YgUmVraHRlcg0KQ2M6IEdlb3JnZSBTd2FsbG93OyBBZHJpYW4gRmFycmVsOyBMb2Eg QW5kZXJzc29uOyBSb3NzIENhbGxvbjsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUZWNo bmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM0MDkwICg0MjAzKQ0KDQpZYWtvdiwNCg0KSSd2ZSBt b2RpZmllZCB0aGUgRXJyYXRhIHRvIHN1Z2dlc3QgZXh0ZW5kaW5nIHRoZSB0ZXh0IHNsaWdodGx5 IGFzIGZvbGxvd3M6DQoNCiAgIFNlY3Rpb24gNiBzYXlzOg0KDQogICBXaGVuZXZlciB0aGUgUExS IGhhcyBhIGJhY2t1cCBwYXRoIGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNUIHNldA0KICAgdGhlICJs b2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSIgZmxhZy4NCg0KICAgSXQgc2hvdWxkIHNheToNCg0K ICAgV2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBiYWNrdXAgcGF0aCBhdmFpbGFibGUsIHRoZSBQTFIg TVVTVCBzZXQNCiAgIHRoZSAibG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUiIGZsYWcuICBGb3Ig ZXhhbXBsZSwgaWYgdGhlIFBMUg0KICAgaGFzIGRldGVybWluZWQgdG8gdXNlIGEgYnlwYXNzIHR1 bm5lbCBhbmQgc2V0IHVwIHRoZSBuZWNlc3NhcnkNCiAgIGxvY2FsIGZvcndhcmRpbmcgc3RhdGUg dG8gYmUgYWJsZSB0byB1c2UgaXQgYXMgYSBiYWNrdXAgcGF0aCwNCiAgIHRoZW4gdGhhdCBQTFIg aGFzIGEgYmFja3VwIHBhdGggYXZhaWxhYmxlLg0KDQpBc3N1bWluZyB0aGF0J3Mgb2sgd2l0aCB0 aGUgV0csIEFkcmlhbiBvciBJIGNhbiBhcHByb3ZlIGl0Lg0KDQpSZWdhcmRzLA0KQWxpYQ0KDQoN Ck9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDk6MTEgUE0sIFlha292IFJla2h0ZXIgPHlha292QGp1 bmlwZXIubmV0PG1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KQWxpYSwNCg0KPiA+ IEFsaWEsDQo+ID4NCj4gPiA+IFlha292LA0KPiA+ID4NCj4gPiA+IE9uIFdlZCwgRGVjIDE3LCAy MDE0IGF0IDQ6MDUgUE0sIFlha292IFJla2h0ZXIgPHlha292QGp1bmlwZXIubmV0PG1haWx0bzp5 YWtvdkBqdW5pcGVyLm5ldD4+DQo+ID4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gPiBBbGlhLA0KPiA+ ID4gPg0KPiA+ID4gPiA+IEhpIFlha292LA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQ291bGQgeW91 IGNsYXJpZnkgeW91ciBwb2ludCBmb3IgdGhpcyBlcnJhdGE/ICBJbiBSRkMgNDA5MCwgaW4gdGhl DQo+ID4gPiA+ID4gdGVybWlub2xvZ3kgaXQgc2F5czoNCj4gPiA+ID4gPiAgIkJhY2t1cCBQYXRo OiBUaGUgTFNQIHRoYXQgaXMgcmVzcG9uc2libGUgZm9yIGJhY2tpbmcgdXAgb25lDQo+ID4gPiA+ ID4gICAgICAgICAgICAgICAgICAgICAgICBwcm90ZWN0ZWQgTFNQLiAgQSBiYWNrdXAgcGF0aCBy ZWZlcnMgdG8NCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgIGVpdGhlciBhIGRldG91ciBMU1Ag b3IgYSBiYWNrdXAgdHVubmVsLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICBCYWNrdXAgVHVubmVs OiBUaGUgTFNQIHRoYXQgaXMgdXNlZCB0byBiYWNrdXAgdXAgb25lIG9mIHRoZSBtYW55DQo+ID4g PiA+ID4gICAgICAgICAgICAgICAgICBMU1BzIGluIG1hbnktdG8tb25lIGJhY2t1cC4iDQo+ID4g PiA+DQo+ID4gPiA+IEluIHRoZSB0ZXJtaW5vbG9neSBpdCBhbHNvIHNheXM6DQo+ID4gPiA+DQo+ ID4gPiA+ICAgICJCeXBhc3MgVHVubmVsOiBBbiBMU1AgdGhhdCBpcyB1c2VkIHRvIHByb3RlY3Qg YSBzZXQgb2YgTFNQcw0KPiA+ID4gPiAgICAgICAgICAgICBwYXNzaW5nIG92ZXIgYSBjb21tb24g ZmFjaWxpdHkuIg0KPiA+ID4gPg0KPiA+ID4gPiBNeSBwb2ludCBpcyB0aGF0ICh1bmxlc3MgdGhl IHRlcm0gImJ5cGFzcyB0dW5uZWwiIG1lYW5zIHRoZSBzYW1lDQo+ID4gPiA+IGFzICJiYWNrdXAg cGF0aCIgb3IgImJhY2t1cCB0dW5uZWwiKSBpbiBtYW55LXRvLW9uZSBiYWNrdXANCj4gPiA+ID4g dGhlICJsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSIgZmxhZyBmb3IgYSBnaXZlbiBwcm90ZWN0 ZWQgTFNQDQo+ID4gPiA+IE1VU1QgYmUgc2V0IHdoZW4gdGhlIFBMUiBoYXMgYSAqYnlwYXNzKiB0 dW5uZWwgZm9yIHRoYXQgTFNQLg0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+IEFoIC0gb2suICBBIGJh Y2t1cCBwYXRoIHRoYXQgdXNlcyBhIGJ5cGFzcyB0dW5uZWwgaXMgbm90IGp1c3QgdGhlIGJ5cGFz cw0KPiA+ID4gdHVubmVsIGl0c2VsZi4NCj4gPg0KPiA+IENvcnJlY3QuDQo+ID4NCj4gPiA+IFRo ZXJlJ3MgdGhlIHN0YXRlIGFzc29jaWF0ZWQgZm9yIHRoZSBwcm90ZWN0ZWQgTFNQIHRoYXQNCj4g PiA+IGFsc28gbmVlZHMgdG8gYmUgY3JlYXRlZCBhbmQgaW5zdGFsbGVkLiAgSW4gbW9yZSBjb25j cmV0ZSB0ZXJtcywgdGhpcw0KPiA+ID4gaXMgaW5zdGFsbGluZyBhbiBvdXQtc2VnbWVudCB3aXRo IHRoZSBhcHByb3ByaWF0ZSBsYWJlbCBmb3IgdGhlIHByb3RlY3RlZA0KPiA+ID4gTFNQIHRvIGJl IHVuZGVyc3Rvb2QgYnkgdGhlIG1lcmdlIHBvaW50IGFzDQo+ID4gPiB3ZWxsIGFzIGFuIG91dGVy IGxhYmVsIGZvciB0aGUgYnlwYXNzIExTUC4NCj4gPiA+DQo+ID4gPiBTbywgdGhlIHRleHQgcmVm ZXJzIHRvIGEgYmFja3VwIHBhdGggaW5zdGVhZCBvZiBhIGJ5cGFzcyB0dW5uZWwgYmVjYXVzZQ0K PiA+ID4gaGF2aW5nIHRoZSBieXBhc3MgdHVubmVsIGlzbid0IHF1aXRlIHN1ZmZpY2llbnQuDQo+ ID4gPiBEb2VzIHRoYXQgbWFrZSBzZW5zZSB0byB5b3U/DQo+ID4NCj4gPiBUaGUgY3VycmVudCB0 ZXh0IGlzIGluY29ycmVjdC4gVGhpcyBpcyBiZWNhdXNlIGEgUExSIG1heSBzaWduYWwgYQ0KPiA+ IGJhY2t1cCBwYXRoIGF0IHRoZSB0aW1lIG9mIGZhaWx1cmUuIFlldCwgb25lIHNob3VsZCBub3Qg d2FpdCBmb3INCj4gPiB0aGUgZmFpbHVyZSB0byBzZXQgdGhlICJsb2NhbCBwcm90ZWN0aW9uIGF2 YWlsYWJsZSIgZmxhZy4gVGhlIFBMUg0KPiA+IHNob3VsZCBzZXQgdGhpcyBmbGFnIGFzIHNvb24g YXMgaXQgaGFzIGEgKmJ5cGFzcyogdHVubmVsLg0KPg0KPiBUaGUgYmFja3VwIHBhdGggaXMgY3Jl YXRlZCBieSB0aGUgUExSIGJlZm9yZSB0aGUgZmFpbHVyZSBhbmQgdGh1cywgYmVmb3JlDQo+IHRo ZSBhc3NvY2lhdGVkIHNpZ25hbGluZy4gT25jZSB0aGUgUExSIGhhcyBkb25lIHRoZSB3b3JrIHRv IGNyZWF0ZQ0KPiBhIGJhY2t1cCBwYXRoIHVzaW5nIGFuIGV4aXN0aW5nIGJ5cGFzcyB0dW5uZWwg LSB3aGljaCBpcyBpbnRlcm5hbA0KPiB3b3JrIC0gdGhlbiB0aGUgUExSIHNob3VsZCBzZXQgdGhl ICJsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSIgZmxhZy4NClBlcmhhcHMgd2Ugc2hvdWxkIHN0 ZXAgYmFjayBhbmQgYXNrIHdoZXRoZXIgdGhlIHF1b3RlIGZyb20gc2VjdGlvbiA2Og0KDQogICBX aGVuZXZlciB0aGUgUExSIGhhcyBhIGJhY2t1cCBwYXRoIGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNU IHNldA0KICAgdGhlICJsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSIgZmxhZy4NCg0KdGFsa3Mg YWJvdXQgZm9yd2FyZGluZyBzdGF0ZSBvciBjb250cm9sIHBsYW5lIHN0YXRlLiBJcyB0aGVyZQ0K YW55IHRleHQgaW4gcmZjNDA5MCB0aGF0IGFuc3dlcnMgdGhpcyBxdWVzdGlvbiA/DQoNCllha292 Lg0KDQo+DQo+IEFsaWENCj4NCj4NCj4NCj4gPiBZYWtvdi4NCj4gPg0KPiA+ID4NCj4gPiA+IFJl Z2FyZHMsDQo+ID4gPiBBbGlhDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gWWFrb3YuDQo+ID4gPiA+ DQo+ID4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPiA+IEFsaWENCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDM6MDcgUE0sIFJGQyBFcnJhdGEgU3lzdGVtIDwNCj4g PiA+ID4gPiByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnPj4gd3JvdGU6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoZSBmb2xsb3dpbmcg ZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzQwOTAsDQo+ID4gPiA+ID4g PiAiRmFzdCBSZXJvdXRlIEV4dGVuc2lvbnMgdG8gUlNWUC1URSBmb3IgTFNQIFR1bm5lbHMiLg0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4gPiA+ID4gPiBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBh dDoNCj4gPiA+ID4gPiA+IGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5w aHA/cmZjPTQwOTAmZWlkPTQyMDMNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+ID4gVHlwZTogVGVjaG5pY2Fs DQo+ID4gPiA+ID4gPiBSZXBvcnRlZCBieTogWWFrb3YgUmVraHRlciA8eWFrb3ZAanVuaXBlci5u ZXQ8bWFpbHRvOnlha292QGp1bmlwZXIubmV0Pj4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBT ZWN0aW9uOiA2DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gT3JpZ2luYWwgVGV4dA0KPiA+ID4g PiA+ID4gLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+ID4gV2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBi YWNrdXAgcGF0aCBhdmFpbGFibGUsIHRoZSBQTFIgTVVTVCBzZXQNCj4gPiA+ID4gPiA+IHRoZSAi bG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUiIGZsYWcuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IENvcnJlY3RlZCBUZXh0DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0t LQ0KPiA+ID4gPiA+ID4gV2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBvbmUtdG8tb25lIGJhY2t1cCBM U1Agb3IgYnlwYXNzIHR1bm5lbA0KPiA+ID4gPiA+ID4gYXZhaWxhYmxlLCB0aGUgUExSIE1VU1Qg c2V0IHRoZSAibG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUiIGZsYWcuDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE5vdGVzDQo+ID4gPiA+ID4gPiAtLS0tLQ0KPiA+ID4g PiA+ID4gSW4gdGhlIGNhc2Ugb2YgZmFjaWxpdHktYmFzZWQgRlJSIHRoZSBQTFIgbXVzdCBzZXQg dGhlICJsb2NhbA0KPiA+ID4gPiBwcm90ZWN0aW9uDQo+ID4gPiA+ID4gPiBhdmFpbGFibGUiIGZs YWcgaWYgaXQgaGFzIHRoZSBieXBhc3MgdHVubmVsIGF2YWlsYWJsZS4NCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiBJbnN0cnVjdGlvbnM6DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tDQo+ID4g PiA+ID4gPiBUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJ ZiBuZWNlc3NhcnksDQo+ID4gcGxlYXNlDQo+ID4gPiA+ID4gPiB1c2UgIlJlcGx5IEFsbCIgdG8g ZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPiA+ID4gPiA+ID4gcmVq ZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5IChJ RVNHKQ0KPiA+ID4gPiA+ID4gY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRp dCB0aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiA+IFJGQzQwOTAg KGRyYWZ0LWlldGYtbXBscy1yc3ZwLWxzcC1mYXN0cmVyb3V0ZS0wNykNCj4gPiA+ID4gPiA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gPiBUaXRsZSAg ICAgICAgICAgICAgIDogRmFzdCBSZXJvdXRlIEV4dGVuc2lvbnMgdG8gUlNWUC1URSBmb3IgTFNQ DQo+ID4gPiA+IFR1bm5lbHMNCj4gPiA+ID4gPiA+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBNYXkg MjAwNQ0KPiA+ID4gPiA+ID4gQXV0aG9yKHMpICAgICAgICAgICA6IFAuIFBhbiwgRWQuLCBHLiBT d2FsbG93LCBFZC4sIEEuIEF0bGFzLCBFZC4NCj4gPiA+ID4gPiA+IENhdGVnb3J5ICAgICAgICAg ICAgOiBQUk9QT1NFRCBTVEFOREFSRA0KPiA+ID4gPiA+ID4gU291cmNlICAgICAgICAgICAgICA6 IE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nDQo+ID4gPiA+ID4gPiBBcmVhICAgICAgICAg ICAgICAgIDogUm91dGluZw0KPiA+ID4gPiA+ID4gU3RyZWFtICAgICAgICAgICAgICA6IElFVEYN Cj4gPiA+ID4gPiA+IFZlcmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC0tMDAxYTExMzk3YTJjOWJkYTZlMDUwYTZm MzFhZQ0KPiA+ID4gPiA+IENvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PSJVVEYtOCIN Cj4gPiA+ID4gPiBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiA8ZGl2IGRpcj0zRCJsdHIiPkhpIFlha292LDxicj48YnI+Q291 bGQgeW91IGNsYXJpZnkgeW91ciBwb2ludCBmb3INCj4gPiB0aGlzDQo+ID4gPiA+IGVycj0NCj4g PiA+ID4gPiBhdGE/PUMyPUEwIEluIFJGQyA0MDkwLCBpbiB0aGUgdGVybWlub2xvZ3kgaXQgc2F5 czo8YnI+JnF1b3Q7IEJhY2t1cA0KPiA+ID4gPiBQYXRoOiA9DQo+ID4gPiA+ID4gVGhlIExTUCB0 aGF0IGlzIHJlc3BvbnNpYmxlIGZvciBiYWNraW5nIHVwIG9uZTxicj49QzI9QTAgPUMyPUEwDQo+ ID4gPUMyPUEwDQo+ID4gPiA+ID1DMj0NCj4gPiA+ID4gPiA9QTAgPUMyPUEwID1DMj1BMCA9QzI9 QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMHByb3RlY3RlZA0KPiA+ID4gPiBM U1AuPQ0KPiA+ID4gPiA+ID1DMj1BMCBBIGJhY2t1cCBwYXRoIHJlZmVycyB0byBlaXRoZXIgYSBk ZXRvdXIgTFNQPGJyPj1DMj1BMCA9QzI9QTANCj4gPiA+ID4gPUMyPUEwID0NCj4gPiA+ID4gPiA9 QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1D Mj1BMG9yIGENCj4gPiA+ID4gYmFja3VwIHQ9DQo+ID4gPiA+ID4gdW5uZWwuPGJyPjxicj49QzI9 QTAgQmFja3VwIFR1bm5lbDogVGhlIExTUCB0aGF0IGlzIHVzZWQgdG8gYmFja3VwIHVwDQo+ID4g PiA+IG9uZSBvPQ0KPiA+ID4gPiA+IGYgdGhlIG1hbnk8YnI+PUMyPUEwID1DMj1BMCA9QzI9QTAg PUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMA0KPiA+ID4gPiA9QzI9DQo+ID4gPiA+ ID4gPUEwTFNQcyBpbiBtYW55LXRvLW9uZQ0KPiA+ID4gPiBiYWNrdXAuJnF1b3Q7PGRpdj48YnI+ PC9kaXY+PGRpdj5UaGFua3MsPC9kaXY+PGRpdj5BPQ0KPiA+ID4gPiA+IGxpYTwvZGl2PjwvZGl2 PjxkaXYgY2xhc3M9M0QiZ21haWxfZXh0cmEiPjxicj48ZGl2DQo+ID4gPiA+IGNsYXNzPTNEImdt YWlsX3F1b3RlIj5Pbj0NCj4gPiA+ID4gPiAgV2VkLCBEZWMgMTcsIDIwMTQgYXQgMzowNyBQTSwg UkZDIEVycmF0YSBTeXN0ZW0gPHNwYW4NCj4gPiA+ID4gZGlyPTNEImx0ciI+Jmx0OzxhIGg9DQo+ ID4gPiA+ID4gcmVmPTNEIm1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpy ZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPiINCj4gPiA+ID4gdGFyZ2V0PTNEIl9ibGFuayI+cmZj LWVkaXRvckByZmMtZT0NCj4gPiA+ID4gPiBkaXRvci5vcmc8aHR0cDovL2RpdG9yLm9yZz48L2E+ Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPTNEImdtYWlsX3F1b3RlIg0K PiA+ID4gPiBzdHlsZT0NCj4gPiA+ID4gPiA9M0QibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2MNCj4gPiBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5UaGUNCj4gPiA+ID4gZm9s bD0NCj4gPiA+ID4gb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJG QzQwOTAsPGJyPg0KPiA+ID4gPiA+ICZxdW90O0Zhc3QgUmVyb3V0ZSBFeHRlbnNpb25zIHRvIFJT VlAtVEUgZm9yIExTUCBUdW5uZWxzJnF1b3Q7Ljxicj4NCj4gPiA+ID4gPiA8YnI+DQo+ID4gPiA+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo+ID4gPiA+ID4g WW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6PGJyPg0KPiA+ID4gPiA+IDxh IGhyZWY9M0QiDQo+ID4gPiA+IGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJj aC5waHA/cmZjPTNENDA5MCZhbXA7ZWlkPQ0KPiA+ID4gPiA+ID0zRDQyMDMiIHRhcmdldD0zRCJf YmxhbmsiPg0KPiA+ID4gPiBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gu cGhwP3JmYz0NCj4gPiA+ID4gPiA9M0Q0MDkwJmFtcDtlaWQ9M0Q0MjAzPC9hPjxicj4NCj4gPiA+ ID4gPiA8YnI+DQo+ID4gPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQo+ID4gPiA+ID4gVHlwZTogVGVjaG5pY2FsPGJyPg0KPiA+ID4gPiA+IFJlcG9ydGVk IGJ5OiBZYWtvdiBSZWtodGVyICZsdDs8YSBocmVmPTNEIm1haWx0bzp5YWtvdkBqdW5pcGVyLm5l dDxtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQ+DQo+ID4gPiA+ICI+eWFrb3ZAaj0NCj4gPiA+ID4g PiB1bmlwZXIubmV0PGh0dHA6Ly91bmlwZXIubmV0PjwvYT4mZ3Q7PGJyPg0KPiA+ID4gPiA+IDxi cj4NCj4gPiA+ID4gPiBTZWN0aW9uOiA2PGJyPg0KPiA+ID4gPiA+IDxicj4NCj4gPiA+ID4gPiBP cmlnaW5hbCBUZXh0PGJyPg0KPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS08YnI+DQo+ID4gPiA+ID4g V2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBiYWNrdXAgcGF0aCBhdmFpbGFibGUsIHRoZSBQTFIgTVVT VCBzZXQ8YnI+DQo+ID4gPiA+ID4gdGhlICZxdW90O2xvY2FsIHByb3RlY3Rpb24gYXZhaWxhYmxl JnF1b3Q7IGZsYWcuPGJyPg0KPiA+ID4gPiA+IDxicj4NCj4gPiA+ID4gPiA8YnI+DQo+ID4gPiA+ ID4gQ29ycmVjdGVkIFRleHQ8YnI+DQo+ID4gPiA+ID4gLS0tLS0tLS0tLS0tLS08YnI+DQo+ID4g PiA+ID4gV2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBvbmUtdG8tb25lIGJhY2t1cCBMU1Agb3IgYnlw YXNzIHR1bm5lbDxicj4NCj4gPiA+ID4gPiBhdmFpbGFibGUsIHRoZSBQTFIgTVVTVCBzZXQgdGhl ICZxdW90O2xvY2FsIHByb3RlY3Rpb24NCj4gPiBhdmFpbGFibGUmcXVvdDsNCj4gPiA+ID4gZmxh Zz0NCj4gPiA+ID4gPiAuPGJyPg0KPiA+ID4gPiA+IDxicj4NCj4gPiA+ID4gPiA8YnI+DQo+ID4g PiA+ID4gTm90ZXM8YnI+DQo+ID4gPiA+ID4gLS0tLS08YnI+DQo+ID4gPiA+ID4gSW4gdGhlIGNh c2Ugb2YgZmFjaWxpdHktYmFzZWQgRlJSIHRoZSBQTFIgbXVzdCBzZXQgdGhlICZxdW90O2xvY2Fs DQo+ID4gPiA+IHByb3RlY3RpPQ0KPiA+ID4gPiA+IG9uIGF2YWlsYWJsZSZxdW90OyBmbGFnIGlm IGl0IGhhcyB0aGUgYnlwYXNzIHR1bm5lbCBhdmFpbGFibGUuPGJyPg0KPiA+ID4gPiA+IDxicj4N Cj4gPiA+ID4gPiBJbnN0cnVjdGlvbnM6PGJyPg0KPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS08YnI+ DQo+ID4gPiA+ID4gVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJnF1b3Q7UmVw b3J0ZWQmcXVvdDsuIElmDQo+ID4gbmVjZXNzYXJ5LA0KPiA+ID4gPiBwbGU9DQo+ID4gPiA+ID4g YXNlPGJyPg0KPiA+ID4gPiA+IHVzZSAmcXVvdDtSZXBseSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3 aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZA0KPiA+IG9yPGJyPg0KPiA+ID4gPiA+IHJlamVj dGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAoSUVT Ryk8YnI+DQo+ID4gPiA+ID4gY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRp dCB0aGUgcmVwb3J0LCBpZg0KPiA+IG5lY2Vzc2FyeS48YnI+DQo+ID4gPiA+ID4gPGJyPg0KPiA+ ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPiA+ID4g PiA+IFJGQzQwOTAgKGRyYWZ0LWlldGYtbXBscy1yc3ZwLWxzcC1mYXN0cmVyb3V0ZS0wNyk8YnI+ DQo+ID4gPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo+ ID4gPiA+ID4gVGl0bGU9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9 QzI9QTAgPUMyPUEwOiBGYXN0DQo+ID4gPiA+IFJlcm91dGUgPQ0KPiA+ID4gPiA+IEV4dGVuc2lv bnMgdG8gUlNWUC1URSBmb3IgTFNQIFR1bm5lbHM8YnI+DQo+ID4gPiA+ID4gUHVibGljYXRpb24g RGF0ZT1DMj1BMCA9QzI9QTAgOiBNYXkgMjAwNTxicj4NCj4gPiA+ID4gPiBBdXRob3Iocyk9QzI9 QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMDogUC4gUGFuLCBFZC4sIEcuDQo+ ID4gPiA+IFN3YWxsb3c9DQo+ID4gPiA+ID4gLCBFZC4sIEEuIEF0bGFzLCBFZC48YnI+DQo+ID4g PiA+ID4gQ2F0ZWdvcnk9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA6 IFBST1BPU0VEDQo+IFNUQU5EQVJEPGJyPg0KPiA+ID4gPiA+IFNvdXJjZT1DMj1BMCA9QzI9QTAg PUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA6DQo+ID4gTXVsdGlwcm90b2NvbA0K PiA+ID4gPiBMYWJlPQ0KPiA+ID4gPiA+IGwgU3dpdGNoaW5nPGJyPg0KPiA+ID4gPiA+IEFyZWE9 QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwIDoN Cj4gPiBSb3V0aW5nPGJyPg0KPiA+ID4gPiA+IFN0cmVhbT1DMj1BMCA9QzI9QTAgPUMyPUEwID1D Mj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA6IElFVEY8YnI+DQo+ID4gPiA+ID4gVmVyaWZ5aW5n IFBhcnR5PUMyPUEwID1DMj1BMCA9QzI9QTA6IElFU0c8YnI+DQo+ID4gPiA+ID4gPGJyPg0KPiA+ ID4gPiA+IDwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo+ID4gPiA+ID4NCj4gPiA+ID4g PiAtLTAwMWExMTM5N2EyYzliZGE2ZTA1MGE2ZjMxYWUtLQ0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+ IC0tMDQ3ZDdiNWQ5OWEzM2E5MTRiMDUwYTcwMTY0ZQ0KPiA+ID4gQ29udGVudC1UeXBlOiB0ZXh0 L2h0bWw7IGNoYXJzZXQ9IlVURi04Ig0KPiA+ID4gQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog cXVvdGVkLXByaW50YWJsZQ0KPiA+ID4NCj4gPiA+IDxkaXYgZGlyPTNEImx0ciI+WWFrb3YsPGRp diBjbGFzcz0zRCJnbWFpbF9leHRyYSI+PGJyPjxkaXYNCj4gPiBjbGFzcz0zRCJnbWFpbF9xPQ0K PiA+ID4gdW90ZSI+T24gV2VkLCBEZWMgMTcsIDIwMTQgYXQgNDowNSBQTSwgWWFrb3YgUmVraHRl ciA8c3Bhbg0KPiA+IGRpcj0zRCJsdHIiPiZsdDs9DQo+ID4gPiA8YSBocmVmPTNEIm1haWx0bzp5 YWtvdkBqdW5pcGVyLm5ldDxtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQ+IiB0YXJnZXQ9M0QiX2Js YW5rIj55YWtvdkBqdW5pcGVyLm5ldDxtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQ+DQo+ID4gPC9h PQ0KPiA+ID4gPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0zRCJnbWFp bF9xdW90ZSINCj4gPiBzdHlsZT0zRCJtYXJnaW46MCA9DQo+ID4gPiAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5BbGlhLDxicj4NCj4gPiA+IDxz cGFuIGNsYXNzPTNEIiI+PGJyPg0KPiA+ID4gJmd0OyBIaSBZYWtvdiw8YnI+DQo+ID4gPiAmZ3Q7 PGJyPg0KPiA+ID4gJmd0OyBDb3VsZCB5b3UgY2xhcmlmeSB5b3VyIHBvaW50IGZvciB0aGlzIGVy cmF0YT89QzI9QTAgSW4gUkZDIDQwOTAsIGluDQo+ID4gdGg9DQo+ID4gPiBlPGJyPg0KPiA+ID4g Jmd0OyB0ZXJtaW5vbG9neSBpdCBzYXlzOjxicj4NCj4gPiA+ICZndDs9QzI9QTAgJnF1b3Q7QmFj a3VwIFBhdGg6IFRoZSBMU1AgdGhhdCBpcyByZXNwb25zaWJsZSBmb3IgYmFja2luZyB1cA0KPiA+ IG9uPQ0KPiA+ID4gZTxicj4NCj4gPiA+ICZndDs9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAg PUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMA0KPiA+ID1DMj1BMCA9DQo+ID4gPiA9 QzI9QTAgPUMyPUEwIHByb3RlY3RlZCBMU1AuPUMyPUEwIEEgYmFja3VwIHBhdGggcmVmZXJzIHRv IGVpdGhlciBhPGJyPg0KPiA+ID4gJmd0Oz1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9 QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwDQo+ID4gPUMyPUEwID0NCj4gPiA+ID1DMj1B MCA9QzI9QTAgZGV0b3VyIExTUCBvciBhIGJhY2t1cCB0dW5uZWwuPGJyPg0KPiA+ID4gJmd0Ozxi cj4NCj4gPiA+ICZndDs9QzI9QTAgPUMyPUEwQmFja3VwIFR1bm5lbDogVGhlIExTUCB0aGF0IGlz IHVzZWQgdG8gYmFja3VwIHVwIG9uZSBvZg0KPiA+IHRoPQ0KPiA+ID4gZSBtYW55PGJyPg0KPiA+ ID4gJmd0Oz1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9 QzI9QTAgPUMyPUEwIExTUHMNCj4gPiBpbiA9DQo+ID4gPiBtYW55LXRvLW9uZSBiYWNrdXAuJnF1 b3Q7PGJyPg0KPiA+ID4gPGJyPg0KPiA+ID4gPC9zcGFuPkluIHRoZSB0ZXJtaW5vbG9neSBpdCBh bHNvIHNheXM6PGJyPg0KPiA+ID4gPGJyPg0KPiA+ID4gPUMyPUEwID1DMj1BMCZxdW90O0J5cGFz cyBUdW5uZWw6IEFuIExTUCB0aGF0IGlzIHVzZWQgdG8gcHJvdGVjdCBhIHNldA0KPiA+IG9mIEw9 DQo+ID4gPiBTUHM8YnI+DQo+ID4gPiA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEw ID1DMj1BMCBwYXNzaW5nIG92ZXIgYSBjb21tb24NCj4gPiBmYWNpbGl0eS4mcT0NCj4gPiA+IHVv dDs8YnI+DQo+ID4gPiA8YnI+DQo+ID4gPiBNeSBwb2ludCBpcyB0aGF0ICh1bmxlc3MgdGhlIHRl cm0gJnF1b3Q7YnlwYXNzIHR1bm5lbCZxdW90OyBtZWFucyB0aGUNCj4gPiBzYW1lPD0NCj4gPiA+ IGJyPg0KPiA+ID4gYXMgJnF1b3Q7YmFja3VwIHBhdGgmcXVvdDsgb3IgJnF1b3Q7YmFja3VwIHR1 bm5lbCZxdW90OykgaW4gbWFueS10by1vbmUNCj4gPiBiYWM9DQo+ID4gPiBrdXA8YnI+DQo+ID4g PiB0aGUgJnF1b3Q7bG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUmcXVvdDsgZmxhZyBmb3IgYSBn aXZlbiBwcm90ZWN0ZWQNCj4gPiBMU1A8Yj0NCj4gPiA+IHI+DQo+ID4gPiBNVVNUIGJlIHNldCB3 aGVuIHRoZSBQTFIgaGFzIGEgKmJ5cGFzcyogdHVubmVsIGZvciB0aGF0DQo+ID4gTFNQLjxicj48 L2Jsb2NrcXVvdD0NCj4gPiA+IGU+PGRpdj48YnI+PC9kaXY+PGRpdj5BaCAtIG9rLj1DMj1BMCBB IGJhY2t1cCBwYXRoIHRoYXQgdXNlcyBhIGJ5cGFzcw0KPiA+IHR1bm5lPQ0KPiA+ID4gbCBpcyBu b3QganVzdCB0aGUgYnlwYXNzIHR1bm5lbDwvZGl2PjxkaXY+aXRzZWxmLj1DMj1BMCBUaGVyZSYj Mzk7cyB0aGUNCj4gPiBzdGE9DQo+ID4gPiB0ZSBhc3NvY2lhdGVkIGZvciB0aGUgcHJvdGVjdGVk IExTUCB0aGF0IGFsc28gbmVlZHMgdG8NCj4gPiBiZTwvZGl2PjxkaXY+Y3JlYXRlZD0NCj4gPiA+ ICBhbmQgaW5zdGFsbGVkLj1DMj1BMCBJbiBtb3JlIGNvbmNyZXRlIHRlcm1zLCB0aGlzIGlzIGlu c3RhbGxpbmcgYW4NCj4gPiBvdXQtc2VnPQ0KPiA+ID4gbWVudCB3aXRoPUMyPUEwPC9kaXY+PGRp dj50aGUgYXBwcm9wcmlhdGUgbGFiZWwgZm9yIHRoZSBwcm90ZWN0ZWQgTFNQIHRvDQo+ID4gYmU9 DQo+ID4gPiAgdW5kZXJzdG9vZCBieSB0aGUgbWVyZ2UgcG9pbnQgYXM8L2Rpdj48ZGl2PndlbGwg YXMgYW4gb3V0ZXIgbGFiZWwgZm9yDQo+ID4gdGhlID0NCj4gPiA+IGJ5cGFzcyBMU1AuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5TbywgdGhlIHRleHQgcmVmZXJzIHRvIGEgYmFja3VwDQo+ID4g cGF0aCBpPQ0KPiA+ID4gbnN0ZWFkIG9mIGEgYnlwYXNzIHR1bm5lbCBiZWNhdXNlIGhhdmluZyB0 aGU8L2Rpdj48ZGl2PmJ5cGFzcyB0dW5uZWwNCj4gPiBpc24mIzM9DQo+ID4gPiA5O3QgcXVpdGUg c3VmZmljaWVudC49QzI9QTAgRG9lcyB0aGF0IG1ha2Ugc2Vuc2UgdG8NCj4gPiB5b3U/PC9kaXY+ PGRpdj48YnI+PC9kaT0NCj4gPiA+IHY+PGRpdj5SZWdhcmRzLDwvZGl2PjxkaXY+QWxpYTwvZGl2 PjxkaXY+PUMyPUEwPC9kaXY+PGJsb2NrcXVvdGUNCj4gPiBjbGFzcz0zRCJnPQ0KPiA+ID4gbWFp bF9xdW90ZSIgc3R5bGU9M0QibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2MN Cj4gPiBzb2xpZDtwYWRkaW5nLWw9DQo+ID4gPiBlZnQ6MWV4Ij4NCj4gPiA+IFlha292Ljxicj4N Cj4gPiA+IDxkaXY+PGRpdiBjbGFzcz0zRCJoNSI+PGJyPg0KPiA+ID4gJmd0OyBUaGFua3MsPGJy Pg0KPiA+ID4gJmd0OyBBbGlhPGJyPg0KPiA+ID4gJmd0Ozxicj4NCj4gPiA+ICZndDsgT24gV2Vk LCBEZWMgMTcsIDIwMTQgYXQgMzowNyBQTSwgUkZDIEVycmF0YSBTeXN0ZW0gJmx0Ozxicj4NCj4g PiA+ICZndDsgPGEgaHJlZj0zRCJtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzxtYWls dG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4iPg0KPiA+IHJmYy1lZGl0b3JAcmZjLWVkaXRv ci5vcmc8bWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+PQ0KPiA+ID4gPC9hPiZndDsg d3JvdGU6PGJyPg0KPiA+ID4gJmd0Ozxicj4NCj4gPiA+ICZndDsgJmd0OyBUaGUgZm9sbG93aW5n IGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM0MDkwLDxicj4NCj4gPiA+ ICZndDsgJmd0OyAmcXVvdDtGYXN0IFJlcm91dGUgRXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBM U1ANCj4gPiBUdW5uZWxzJnF1b3Q7LjxiPQ0KPiA+ID4gcj4NCj4gPiA+ICZndDsgJmd0Ozxicj4N Cj4gPiA+ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCj4gPiA+ICZndDsgJmd0OyBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBh dDo8YnI+DQo+ID4gPiAmZ3Q7ICZndDsgPGEgaHJlZj0zRCINCj4gPiBodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRDQwOTA9DQo+ID4gPiAmYW1wO2VpZD0z RDQyMDMiIHRhcmdldD0zRCJfYmxhbmsiPg0KPiA+IGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcv ZXJyYXRhX3NlYXJjaC49DQo+ID4gPiBwaHA/cmZjPTNENDA5MCZhbXA7ZWlkPTNENDIwMzwvYT48 YnI+DQo+ID4gPiAmZ3Q7ICZndDs8YnI+DQo+ID4gPiAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo+ID4gPiAmZ3Q7ICZndDsgVHlwZTogVGVjaG5p Y2FsPGJyPg0KPiA+ID4gJmd0OyAmZ3Q7IFJlcG9ydGVkIGJ5OiBZYWtvdiBSZWtodGVyICZsdDs8 YSBocmVmPTNEIm1haWx0bzoNCj4gPiB5YWtvdkBqdW5pcGVyLm5lPG1haWx0bzp5YWtvdkBqdW5p cGVyLm5lPj0NCj4gPiA+IHQiPnlha292QGp1bmlwZXIubmV0PG1haWx0bzp5YWtvdkBqdW5pcGVy Lm5ldD48L2E+Jmd0Ozxicj4NCj4gPiA+ICZndDsgJmd0Ozxicj4NCj4gPiA+ICZndDsgJmd0OyBT ZWN0aW9uOiA2PGJyPg0KPiA+ID4gJmd0OyAmZ3Q7PGJyPg0KPiA+ID4gJmd0OyAmZ3Q7IE9yaWdp bmFsIFRleHQ8YnI+DQo+ID4gPiAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLTxicj4NCj4gPiA+ICZn dDsgJmd0OyBXaGVuZXZlciB0aGUgUExSIGhhcyBhIGJhY2t1cCBwYXRoIGF2YWlsYWJsZSwgdGhl IFBMUiBNVVNUDQo+ID4gc2V0PGJyPQ0KPiA+ID4gPg0KPiA+ID4gJmd0OyAmZ3Q7IHRoZSAmcXVv dDtsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSZxdW90OyBmbGFnLjxicj4NCj4gPiA+ICZndDsg Jmd0Ozxicj4NCj4gPiA+ICZndDsgJmd0Ozxicj4NCj4gPiA+ICZndDsgJmd0OyBDb3JyZWN0ZWQg VGV4dDxicj4NCj4gPiA+ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLTxicj4NCj4gPiA+ICZndDsg Jmd0OyBXaGVuZXZlciB0aGUgUExSIGhhcyBhIG9uZS10by1vbmUgYmFja3VwIExTUCBvciBieXBh c3MNCj4gPiB0dW5uZWw8YnI+DQo+ID4gPiAmZ3Q7ICZndDsgYXZhaWxhYmxlLCB0aGUgUExSIE1V U1Qgc2V0IHRoZSAmcXVvdDtsb2NhbCBwcm90ZWN0aW9uDQo+ID4gYXZhaWxhYmxlJj0NCj4gPiA+ IHF1b3Q7IGZsYWcuPGJyPg0KPiA+ID4gJmd0OyAmZ3Q7PGJyPg0KPiA+ID4gJmd0OyAmZ3Q7PGJy Pg0KPiA+ID4gJmd0OyAmZ3Q7IE5vdGVzPGJyPg0KPiA+ID4gJmd0OyAmZ3Q7IC0tLS0tPGJyPg0K PiA+ID4gJmd0OyAmZ3Q7IEluIHRoZSBjYXNlIG9mIGZhY2lsaXR5LWJhc2VkIEZSUiB0aGUgUExS IG11c3Qgc2V0IHRoZQ0KPiA+ICZxdW90O2xvY2E9DQo+ID4gPiBsIHByb3RlY3Rpb248YnI+DQo+ ID4gPiAmZ3Q7ICZndDsgYXZhaWxhYmxlJnF1b3Q7IGZsYWcgaWYgaXQgaGFzIHRoZSBieXBhc3Mg dHVubmVsIGF2YWlsYWJsZS48YnI+DQo+ID4gPiAmZ3Q7ICZndDs8YnI+DQo+ID4gPiAmZ3Q7ICZn dDsgSW5zdHJ1Y3Rpb25zOjxicj4NCj4gPiA+ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tPGJyPg0K PiA+ID4gJmd0OyAmZ3Q7IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICZxdW90 O1JlcG9ydGVkJnF1b3Q7LiBJZg0KPiA+IG5lY2U9DQo+ID4gPiBzc2FyeSwgcGxlYXNlPGJyPg0K PiA+ID4gJmd0OyAmZ3Q7IHVzZSAmcXVvdDtSZXBseSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3aGV0 aGVyIGl0IHNob3VsZCBiZQ0KPiA+IHZlcmlmaWU9DQo+ID4gPiBkIG9yPGJyPg0KPiA+ID4gJmd0 OyAmZ3Q7IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWlu ZyBwYXJ0eQ0KPiA+IChJRVNHKTw9DQo+ID4gPiBicj4NCj4gPiA+ICZndDsgJmd0OyBjYW4gbG9n IGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmDQo+ID4gbmVj ZXNzYXJ5PQ0KPiA+ID4gLjxicj4NCj4gPiA+ICZndDsgJmd0Ozxicj4NCj4gPiA+ICZndDsgJmd0 OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCj4gPiA+ICZndDsg Jmd0OyBSRkM0MDkwIChkcmFmdC1pZXRmLW1wbHMtcnN2cC1sc3AtZmFzdHJlcm91dGUtMDcpPGJy Pg0KPiA+ID4gJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KPiA+ID4gJmd0OyAmZ3Q7IFRpdGxlPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1D Mj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMDoNCj4gPiBGYXM9DQo+ID4gPiB0IFJlcm91dGUgRXh0 ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBMU1AgVHVubmVsczxicj4NCj4gPiA+ICZndDsgJmd0OyBQ dWJsaWNhdGlvbiBEYXRlPUMyPUEwID1DMj1BMCA6IE1heSAyMDA1PGJyPg0KPiA+ID4gJmd0OyAm Z3Q7IEF1dGhvcihzKT1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwOiBQ LiBQYW4sDQo+ID4gRWQuLCA9DQo+ID4gPiBHLiBTd2FsbG93LCBFZC4sIEEuIEF0bGFzLCBFZC48 YnI+DQo+ID4gPiAmZ3Q7ICZndDsgQ2F0ZWdvcnk9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAg PUMyPUEwID1DMj1BMCA6IFBST1BPU0VEDQo+ID4gU1RBTj0NCj4gPiA+IERBUkQ8YnI+DQo+ID4g PiAmZ3Q7ICZndDsgU291cmNlPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9 QTAgPUMyPUEwIDoNCj4gPiBNdWx0aXBybz0NCj4gPiA+IHRvY29sIExhYmVsIFN3aXRjaGluZzxi cj4NCj4gPiA+ICZndDsgJmd0OyBBcmVhPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1B MCA9QzI9QTAgPUMyPUEwID1DMj1BMCA6DQo+ID4gUm91PQ0KPiA+ID4gdGluZzxicj4NCj4gPiA+ ICZndDsgJmd0OyBTdHJlYW09QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1B MCA9QzI9QTAgOg0KPiA+IElFVEY8YnI+DQo+ID4gPiAmZ3Q7ICZndDsgVmVyaWZ5aW5nIFBhcnR5 PUMyPUEwID1DMj1BMCA9QzI9QTA6IElFU0c8YnI+DQo+ID4gPiAmZ3Q7ICZndDs8YnI+DQo+ID4g PiAmZ3Q7ICZndDs8YnI+DQo+ID4gPiAmZ3Q7PGJyPg0KPiA+ID4gPC9kaXY+PC9kaXY+Jmd0OyAt LTAwMWExMTM5N2EyYzliZGE2ZTA1MGE2ZjMxYWU8YnI+DQo+ID4gPiAmZ3Q7IENvbnRlbnQtVHlw ZTogdGV4dC9odG1sOyBjaGFyc2V0PTNEJnF1b3Q7VVRGLTgmcXVvdDs8YnI+DQo+ID4gPiAmZ3Q7 IENvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGU8YnI+DQo+ID4gPiAm Z3Q7PGJyPg0KPiA+ID4gJmd0OyAmbHQ7ZGl2IGRpcj0zRDNEJnF1b3Q7bHRyJnF1b3Q7Jmd0O0hp DQo+ID4gWWFrb3YsJmx0O2JyJmd0OyZsdDticiZndDtDb3VsZCA9DQo+ID4gPiB5b3UgY2xhcmlm eSB5b3VyIHBvaW50IGZvciB0aGlzIGVycj0zRDxicj4NCj4gPiA+ICZndDsgYXRhPz0zREMyPTNE QTAgSW4gUkZDIDQwOTAsIGluIHRoZSB0ZXJtaW5vbG9neSBpdA0KPiA+IHNheXM6Jmx0O2JyJmd0 OyZhbXA7PQ0KPiA+ID4gcXVvdDsgQmFja3VwIFBhdGg6ID0zRDxicj4NCj4gPiA+ICZndDsgVGhl IExTUCB0aGF0IGlzIHJlc3BvbnNpYmxlIGZvciBiYWNraW5nIHVwIG9uZSZsdDticiZndDs9M0RD Mj0zREEwDQo+ID4gPTNEPQ0KPiA+ID4gQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEPGJyPg0K PiA+ID4gJmd0OyA9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0z REEwID0zREMyPTNEQTANCj4gPiA9M0RDMj0zREE9DQo+ID4gPiAwID0zREMyPTNEQTAgPTNEQzI9 M0RBMHByb3RlY3RlZCBMU1AuPTNEPGJyPg0KPiA+ID4gJmd0OyA9M0RDMj0zREEwIEEgYmFja3Vw IHBhdGggcmVmZXJzIHRvIGVpdGhlciBhIGRldG91cg0KPiA+IExTUCZsdDticiZndDs9M0RDMj0N Cj4gPiA+ID0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0Q8YnI+DQo+ID4gPiAmZ3Q7ID0z REMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RD Mj0zREEwDQo+ID4gPTNEQz0NCj4gPiA+IDI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTBvciBh IGJhY2t1cCB0PTNEPGJyPg0KPiA+ID4gJmd0OyB1bm5lbC4mbHQ7YnImZ3Q7Jmx0O2JyJmd0Oz0z REMyPTNEQTAgQmFja3VwIFR1bm5lbDogVGhlIExTUCB0aGF0IGlzDQo+ID4gdXM9DQo+ID4gPiBl ZCB0byBiYWNrdXAgdXAgb25lIG89M0Q8YnI+DQo+ID4gPiAmZ3Q7IGYgdGhlIG1hbnkmbHQ7YnIm Z3Q7PTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMA0KPiA+ID0zREMy PQ0KPiA+ID4gPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0Q8 YnI+DQo+ID4gPiAmZ3Q7ID0zREEwTFNQcyBpbiBtYW55LXRvLW9uZQ0KPiA+IGJhY2t1cC4mYW1w O3F1b3Q7Jmx0O2RpdiZndDsmbHQ7YnImZ3Q7Jmx0Oy9kaT0NCj4gPiA+IHYmZ3Q7Jmx0O2RpdiZn dDtUaGFua3MsJmx0Oy9kaXYmZ3Q7Jmx0O2RpdiZndDtBPTNEPGJyPg0KPiA+ID4gJmd0OyBsaWEm bHQ7L2RpdiZndDsmbHQ7L2RpdiZndDsmbHQ7ZGl2DQo+ID4gY2xhc3M9M0QzRCZxdW90O2dtYWls X2V4dHJhJnF1b3Q7Jmc9DQo+ID4gPiB0OyZsdDticiZndDsmbHQ7ZGl2IGNsYXNzPTNEM0QmcXVv dDtnbWFpbF9xdW90ZSZxdW90OyZndDtPbj0zRDxicj4NCj4gPiA+ICZndDs9QzI9QTAgV2VkLCBE ZWMgMTcsIDIwMTQgYXQgMzowNyBQTSwgUkZDIEVycmF0YSBTeXN0ZW0gJmx0O3NwYW4NCj4gPiBk aXI9M0QzPQ0KPiA+ID4gRCZxdW90O2x0ciZxdW90OyZndDsmYW1wO2x0OyZsdDthIGg9M0Q8YnI+ DQo+ID4gPiAmZ3Q7IHJlZj0zRDNEJnF1b3Q7bWFpbHRvOjxhIGhyZWY9M0QibWFpbHRvOnJmYy1l ZGl0b3JAcmZjLWVkaXRvci5vcmc8bWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+DQo+ ID4gIj5yZmMtPQ0KPiA+ID4gZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzplZGl0b3JAcmZj LWVkaXRvci5vcmc+PC9hPiZxdW90Ow0KPiA+IHRhcmdldD0zRDNEJnF1b3Q7X2JsYW5rJnF1b3Q7 Jmd0O3JmYy1lZGl0b3I9DQo+ID4gPiBAcmZjLWU9M0Q8YnI+DQo+ID4gPiAmZ3Q7IDxhIGhyZWY9 M0QiaHR0cDovL2RpdG9yLm9yZyIgdGFyZ2V0PTNEIl9ibGFuayI+ZGl0b3Iub3JnPGh0dHA6Ly9k aXRvci5vcmc+DQo+ID4gPC9hPiZsdDsvYSZndDs9DQo+ID4gPiAmYW1wO2d0OyZsdDsvc3BhbiZn dDsgd3JvdGU6Jmx0O2JyJmd0OyZsdDtibG9ja3F1b3RlDQo+ID4gY2xhc3M9M0QzRCZxdW90O2dt YWlsXz0NCj4gPiA+IHF1b3RlJnF1b3Q7IHN0eWxlPTNEPGJyPg0KPiA+ID4gJmd0OyA9M0QzRCZx dW90O21hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjDQo+ID4gc29saWQ7cGFk ZGluZy1sZWZ0OjE9DQo+ID4gPiBleCZxdW90OyZndDtUaGUgZm9sbD0zRDxicj4NCj4gPiA+IG93 aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM0MDkwLCZsdDticiZn dDs8YnI+DQo+ID4gPiAmZ3Q7ICZhbXA7cXVvdDtGYXN0IFJlcm91dGUgRXh0ZW5zaW9ucyB0byBS U1ZQLVRFIGZvciBMU1ANCj4gPiBUdW5uZWxzJmFtcDtxdW90Oz0NCj4gPiA+IC4mbHQ7YnImZ3Q7 PGJyPg0KPiA+ID4gJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KPiA+ID4gJmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZsdDticiZndDs8YnI+DQo+ID4gPiAmZ3Q7IFlvdSBt YXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0OiZsdDticiZndDs8YnI+DQo+ID4gPiAm Z3Q7ICZsdDthIGhyZWY9M0QzRCZxdW90OzxhIGhyZWY9M0QiDQo+ID4gaHR0cDovL3d3dy5yZmMt ZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmM9DQo+ID4gPiBoLnBocD9yZmM9M0QzRDQwOTAmYW1wO2Ft cDtlaWQ9M0QiIHRhcmdldD0zRCJfYmxhbmsiPg0KPiA+IGh0dHA6Ly93d3cucmZjLWVkaXRvci49 DQo+ID4gPiBvcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTNEM0Q0MDkwJmFtcDthbXA7ZWlkPTNE PC9hPjxicj4NCj4gPiA+ICZndDsgPTNEM0Q0MjAzJnF1b3Q7IHRhcmdldD0zRDNEJnF1b3Q7X2Js YW5rJnF1b3Q7Jmd0OzxhIGhyZWY9M0QiDQo+ID4gaHR0cDovL3d3dz0NCj4gPiA+IC5yZmMtZWRp dG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9M0Q8aHR0cDovL3JmYy1lZGl0b3Iub3JnL2Vy cmF0YV9zZWFyY2gucGhwP3JmYz0zRD4iIHRhcmdldD0zRCJfYmxhbmsiPg0KPiA+IGh0dHA6Ly93 d3cucmZjLT0NCj4gPiA+IGVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTNEPGh0dHA6 Ly9lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRD48L2E+PGJyPg0KPiA+ID4gJmd0 OyA9M0QzRDQwOTAmYW1wO2FtcDtlaWQ9M0QzRDQyMDMmbHQ7L2EmZ3Q7Jmx0O2JyJmd0Ozxicj4N Cj4gPiA+ICZndDsgJmx0O2JyJmd0Ozxicj4NCj4gPiA+ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KPiA+ID4gJmd0OyBUeXBlOiBUZWNo bmljYWwmbHQ7YnImZ3Q7PGJyPg0KPiA+ID4gJmd0OyBSZXBvcnRlZCBieTogWWFrb3YgUmVraHRl ciAmYW1wO2x0OyZsdDthIGhyZWY9M0QzRCZxdW90O21haWx0bzo8YQ0KPiA+IGhyZWY9DQo+ID4g PiA9M0QibWFpbHRvOnlha292QGp1bmlwZXIubmV0PG1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldD4i Pnlha292QGp1bmlwZXIubmV0PG1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldD48L2E+JnF1b3Q7Jmd0 O3lha292QGoNCj4gPiA9M0Q8YnI+DQo+ID4gPiAmZ3Q7IDxhIGhyZWY9M0QiaHR0cDovL3VuaXBl ci5uZXQiIHRhcmdldD0zRCJfYmxhbmsiPnVuaXBlci5uZXQ8aHR0cDovL3VuaXBlci5uZXQ+DQo+ ID4gPC9hPiZsdDsvYSZnPQ0KPiA+ID4gdDsmYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ID4gPiAm Z3Q7ICZsdDticiZndDs8YnI+DQo+ID4gPiAmZ3Q7IFNlY3Rpb246IDYmbHQ7YnImZ3Q7PGJyPg0K PiA+ID4gJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KPiA+ID4gJmd0OyBPcmlnaW5hbCBUZXh0Jmx0O2Jy Jmd0Ozxicj4NCj4gPiA+ICZndDsgLS0tLS0tLS0tLS0tLSZsdDticiZndDs8YnI+DQo+ID4gPiAm Z3Q7IFdoZW5ldmVyIHRoZSBQTFIgaGFzIGEgYmFja3VwIHBhdGggYXZhaWxhYmxlLCB0aGUgUExS IE1VU1QNCj4gPiBzZXQmbHQ7YnImZz0NCj4gPiA+IHQ7PGJyPg0KPiA+ID4gJmd0OyB0aGUgJmFt cDtxdW90O2xvY2FsIHByb3RlY3Rpb24gYXZhaWxhYmxlJmFtcDtxdW90Ow0KPiA+IGZsYWcuJmx0 O2JyJmd0Ozxicj4NCj4gPiA+ICZndDsgJmx0O2JyJmd0Ozxicj4NCj4gPiA+ICZndDsgJmx0O2Jy Jmd0Ozxicj4NCj4gPiA+ICZndDsgQ29ycmVjdGVkIFRleHQmbHQ7YnImZ3Q7PGJyPg0KPiA+ID4g Jmd0OyAtLS0tLS0tLS0tLS0tLSZsdDticiZndDs8YnI+DQo+ID4gPiAmZ3Q7IFdoZW5ldmVyIHRo ZSBQTFIgaGFzIGEgb25lLXRvLW9uZSBiYWNrdXAgTFNQIG9yIGJ5cGFzcw0KPiA+IHR1bm5lbCZs dDticiZndD0NCj4gPiA+IDs8YnI+DQo+ID4gPiAmZ3Q7IGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNU IHNldCB0aGUgJmFtcDtxdW90O2xvY2FsIHByb3RlY3Rpb24NCj4gPiBhdmFpbGFibGUmYT0NCj4g PiA+IG1wO3F1b3Q7IGZsYWc9M0Q8YnI+DQo+ID4gPiAmZ3Q7IC4mbHQ7YnImZ3Q7PGJyPg0KPiA+ ID4gJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KPiA+ID4gJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KPiA+ID4g Jmd0OyBOb3RlcyZsdDticiZndDs8YnI+DQo+ID4gPiAmZ3Q7IC0tLS0tJmx0O2JyJmd0Ozxicj4N Cj4gPiA+ICZndDsgSW4gdGhlIGNhc2Ugb2YgZmFjaWxpdHktYmFzZWQgRlJSIHRoZSBQTFIgbXVz dCBzZXQgdGhlDQo+ID4gJmFtcDtxdW90O2xvY2FsPQ0KPiA+ID4gIHByb3RlY3RpPTNEPGJyPg0K PiA+ID4gJmd0OyBvbiBhdmFpbGFibGUmYW1wO3F1b3Q7IGZsYWcgaWYgaXQgaGFzIHRoZSBieXBh c3MgdHVubmVsDQo+ID4gYXZhaWxhYmxlLiZsdDs9DQo+ID4gPiBiciZndDs8YnI+DQo+ID4gPiAm Z3Q7ICZsdDticiZndDs8YnI+DQo+ID4gPiAmZ3Q7IEluc3RydWN0aW9uczombHQ7YnImZ3Q7PGJy Pg0KPiA+ID4gJmd0OyAtLS0tLS0tLS0tLS0tJmx0O2JyJmd0Ozxicj4NCj4gPiA+ICZndDsgVGhp cyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJmFtcDtxdW90O1JlcG9ydGVkJmFtcDtx dW90Oy4NCj4gPiBJZiBuPQ0KPiA+ID4gZWNlc3NhcnksIHBsZT0zRDxicj4NCj4gPiA+ICZndDsg YXNlJmx0O2JyJmd0Ozxicj4NCj4gPiA+ICZndDsgdXNlICZhbXA7cXVvdDtSZXBseSBBbGwmYW1w O3F1b3Q7IHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUNCj4gPiB2ZXJpPQ0KPiA+ID4g ZmllZCBvciZsdDticiZndDs8YnI+DQo+ID4gPiAmZ3Q7IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNp b24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eQ0KPiA+IChJRVNHKSZsdDticj0NCj4g PiA+ICZndDs8YnI+DQo+ID4gPiAmZ3Q7IGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMg YW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYNCj4gPiBuZWNlc3NhcnkuJmx0Oz0NCj4gPiA+IGJyJmd0 Ozxicj4NCj4gPiA+ICZndDsgJmx0O2JyJmd0Ozxicj4NCj4gPiA+ICZndDsgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KPiA+ID4gJmd0OyBSRkM0 MDkwIChkcmFmdC1pZXRmLW1wbHMtcnN2cC1sc3AtZmFzdHJlcm91dGUtMDcpJmx0O2JyJmd0Ozxi cj4NCj4gPiA+ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7 YnImZ3Q7PGJyPg0KPiA+ID4gJmd0OyBUaXRsZT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0z REEwID0zREMyPTNEQTAgPTNEQzI9M0RBMA0KPiA+ID0zREMyPTNEQTA9DQo+ID4gPiAgPTNEQzI9 M0RBMCA9M0RDMj0zREEwOiBGYXN0IFJlcm91dGUgPTNEPGJyPg0KPiA+ID4gJmd0OyBFeHRlbnNp b25zIHRvIFJTVlAtVEUgZm9yIExTUCBUdW5uZWxzJmx0O2JyJmd0Ozxicj4NCj4gPiA+ICZndDsg UHVibGljYXRpb24gRGF0ZT0zREMyPTNEQTAgPTNEQzI9M0RBMCA6IE1heSAyMDA1Jmx0O2JyJmd0 Ozxicj4NCj4gPiA+ICZndDsgQXV0aG9yKHMpPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNE QTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwDQo+ID4gPTNEQzI9DQo+ID4gPiA9M0RBMDogUC4gUGFu LCBFZC4sIEcuIFN3YWxsb3c9M0Q8YnI+DQo+ID4gPiAmZ3Q7ICwgRWQuLCBBLiBBdGxhcywgRWQu Jmx0O2JyJmd0Ozxicj4NCj4gPiA+ICZndDsgQ2F0ZWdvcnk9M0RDMj0zREEwID0zREMyPTNEQTAg PTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTANCj4gPiA9M0RDMj0NCj4gPiA+ID0zREEw IDogUFJPUE9TRUQgU1RBTkRBUkQmbHQ7YnImZ3Q7PGJyPg0KPiA+ID4gJmd0OyBTb3VyY2U9M0RD Mj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTANCj4gPiA9 M0RDMj0zREE9DQo+ID4gPiAwID0zREMyPTNEQTAgOiBNdWx0aXByb3RvY29sIExhYmU9M0Q8YnI+ DQo+ID4gPiAmZ3Q7IGwgU3dpdGNoaW5nJmx0O2JyJmd0Ozxicj4NCj4gPiA+ICZndDsgQXJlYT0z REMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMA0KPiA+ ID0zREMyPTNEQTAgPQ0KPiA+ID4gPTNEQzI9M0RBMCA9M0RDMj0zREEwIDogUm91dGluZyZsdDti ciZndDs8YnI+DQo+ID4gPiAmZ3Q7IFN0cmVhbT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0z REEwID0zREMyPTNEQTAgPTNEQzI9M0RBMA0KPiA+ID0zREMyPTNEQT0NCj4gPiA+IDAgPTNEQzI9 M0RBMCA6IElFVEYmbHQ7YnImZ3Q7PGJyPg0KPiA+ID4gJmd0OyBWZXJpZnlpbmcgUGFydHk9M0RD Mj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMDogSUVTRyZsdDticiZndDs8YnI+DQo+ID4gPiAm Z3Q7ICZsdDticiZndDs8YnI+DQo+ID4gPiAmZ3Q7ICZsdDsvYmxvY2txdW90ZSZndDsmbHQ7L2Rp diZndDsmbHQ7YnImZ3Q7Jmx0Oy9kaXYmZ3Q7PGJyPg0KPiA+ID4gJmd0Ozxicj4NCj4gPiA+ICZn dDsgLS0wMDFhMTEzOTdhMmM5YmRhNmUwNTBhNmYzMWFlLS08YnI+DQo+ID4gPiA8L2Jsb2NrcXVv dGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2Pg0KPiA+ID4NCj4gPiA+IC0tMDQ3ZDdiNWQ5OWEzM2E5 MTRiMDUwYTcwMTY0ZS0tDQo+ID4NCj4NCj4gLS0wMDFhMTFjMWU5ZWU0MGZkMTkwNTBhNzA2OGM5 DQo+IENvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PSJVVEYtOCINCj4gQ29udGVudC1U cmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KPg0KPiA8ZGl2IGRpcj0zRCJsdHIi Pllha292LDxkaXYgY2xhc3M9M0QiZ21haWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPTNEImdtYWls X3E9DQo+IHVvdGUiPk9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDQ6NDEgUE0sIFlha292IFJla2h0 ZXIgPHNwYW4gZGlyPTNEImx0ciI+Jmx0Oz0NCj4gPGEgaHJlZj0zRCJtYWlsdG86eWFrb3ZAanVu aXBlci5uZXQ8bWFpbHRvOnlha292QGp1bmlwZXIubmV0PiIgdGFyZ2V0PTNEIl9ibGFuayI+eWFr b3ZAanVuaXBlci5uZXQ8bWFpbHRvOnlha292QGp1bmlwZXIubmV0PjwvYT0NCj4gPiZndDs8L3Nw YW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0zRCJnbWFpbF9xdW90ZSIgc3R5bGU9M0Qi bWFyZ2luOjAgPQ0KPiAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij5BbGlhLDxicj4NCj4gPHNwYW4gY2xhc3M9M0QiIj48YnI+DQo+ICZndDsgWWFr b3YsPGJyPg0KPiAmZ3Q7PGJyPg0KPiAmZ3Q7IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDQ6MDUg UE0sIFlha292IFJla2h0ZXIgJmx0OzxhIGhyZWY9M0QibWFpbHRvOnk8bWFpbHRvOnk+PQ0KPiBh a292QGp1bmlwZXIubmV0PG1haWx0bzpha292QGp1bmlwZXIubmV0PiI+eWFrb3ZAanVuaXBlci5u ZXQ8bWFpbHRvOnlha292QGp1bmlwZXIubmV0PjwvYT4mZ3Q7IHdyb3RlOjxicj4NCj4gJmd0Ozxi cj4NCj4gJmd0OyAmZ3Q7IEFsaWEsPGJyPg0KPiAmZ3Q7ICZndDs8YnI+DQo+ICZndDsgJmd0OyAm Z3Q7IEhpIFlha292LDxicj4NCj4gJmd0OyAmZ3Q7ICZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7 IENvdWxkIHlvdSBjbGFyaWZ5IHlvdXIgcG9pbnQgZm9yIHRoaXMgZXJyYXRhPz1DMj1BMCBJbiBS RkMgND0NCj4gMDkwLCBpbiB0aGU8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IHRlcm1pbm9sb2d5IGl0 IHNheXM6PGJyPg0KPiAmZ3Q7ICZndDsgJmd0Oz1DMj1BMCAmcXVvdDtCYWNrdXAgUGF0aDogVGhl IExTUCB0aGF0IGlzIHJlc3BvbnNpYmxlIGZvciBiYWM9DQo+IGtpbmcgdXAgb25lPGJyPg0KPiAm Z3Q7ICZndDsgJmd0Oz1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1D Mj1BMCA9QzI9QTAgPUMyPQ0KPiA9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgcHJvdGVjdGVkIExT UC49QzI9QTAgQSBiYWNrdXAgcGF0aCByZWZlcnMgdG8gZWl0aGU9DQo+IHIgYTxicj4NCj4gJmd0 OyAmZ3Q7ICZndDs9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9 QTAgPUMyPUEwID1DMj0NCj4gPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwIGRldG91ciBMU1Agb3Ig YSBiYWNrdXAgdHVubmVsLjxicj4NCj4gJmd0OyAmZ3Q7ICZndDs8YnI+DQo+ICZndDsgJmd0OyAm Z3Q7PUMyPUEwID1DMj1BMEJhY2t1cCBUdW5uZWw6IFRoZSBMU1AgdGhhdCBpcyB1c2VkIHRvIGJh Y2t1cCB1cD0NCj4gIG9uZSBvZiB0aGUgbWFueTxicj4NCj4gJmd0OyAmZ3Q7ICZndDs9QzI9QTAg PUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj0NCj4g PUEwIExTUHMgaW4gbWFueS10by1vbmUgYmFja3VwLiZxdW90Ozxicj4NCj4gJmd0OyAmZ3Q7PGJy Pg0KPiAmZ3Q7ICZndDsgSW4gdGhlIHRlcm1pbm9sb2d5IGl0IGFsc28gc2F5czo8YnI+DQo+ICZn dDsgJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7PUMyPUEwID1DMj1BMCAmcXVvdDtCeXBhc3MgVHVubmVs OiBBbiBMU1AgdGhhdCBpcyB1c2VkIHRvIHByb3RlY3QgPQ0KPiBhIHNldCBvZiBMU1BzPGJyPg0K PiAmZ3Q7ICZndDs9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9 QTBwYXNzaW5nIG92ZXIgYSBjb209DQo+IG1vbiBmYWNpbGl0eS4mcXVvdDs8YnI+DQo+ICZndDsg Jmd0Ozxicj4NCj4gJmd0OyAmZ3Q7IE15IHBvaW50IGlzIHRoYXQgKHVubGVzcyB0aGUgdGVybSAm cXVvdDtieXBhc3MgdHVubmVsJnF1b3Q7IG1lYW5zPQ0KPiAgdGhlIHNhbWU8YnI+DQo+ICZndDsg Jmd0OyBhcyAmcXVvdDtiYWNrdXAgcGF0aCZxdW90OyBvciAmcXVvdDtiYWNrdXAgdHVubmVsJnF1 b3Q7KSBpbiBtYW55LT0NCj4gdG8tb25lIGJhY2t1cDxicj4NCj4gJmd0OyAmZ3Q7IHRoZSAmcXVv dDtsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSZxdW90OyBmbGFnIGZvciBhIGdpdmVuIHByb3Rl PQ0KPiBjdGVkIExTUDxicj4NCj4gJmd0OyAmZ3Q7IE1VU1QgYmUgc2V0IHdoZW4gdGhlIFBMUiBo YXMgYSAqYnlwYXNzKiB0dW5uZWwgZm9yIHRoYXQgTFNQLjxicj4NCj4gJmd0OyAmZ3Q7PGJyPg0K PiAmZ3Q7PGJyPg0KPiAmZ3Q7IEFoIC0gb2suPUMyPUEwIEEgYmFja3VwIHBhdGggdGhhdCB1c2Vz IGEgYnlwYXNzIHR1bm5lbCBpcyBub3QganVzdCB0aGU9DQo+ICBieXBhc3M8YnI+DQo+ICZndDsg dHVubmVsIGl0c2VsZi48YnI+DQo+IDxicj4NCj4gPC9zcGFuPkNvcnJlY3QuPGJyPg0KPiA8c3Bh biBjbGFzcz0zRCIiPjxicj4NCj4gJmd0OyBUaGVyZSYjMzk7cyB0aGUgc3RhdGUgYXNzb2NpYXRl ZCBmb3IgdGhlIHByb3RlY3RlZCBMU1AgdGhhdDxicj4NCj4gJmd0OyBhbHNvIG5lZWRzIHRvIGJl IGNyZWF0ZWQgYW5kIGluc3RhbGxlZC49QzI9QTAgSW4gbW9yZSBjb25jcmV0ZSB0ZXJtcywgPQ0K PiB0aGlzPGJyPg0KPiAmZ3Q7IGlzIGluc3RhbGxpbmcgYW4gb3V0LXNlZ21lbnQgd2l0aCB0aGUg YXBwcm9wcmlhdGUgbGFiZWwgZm9yIHRoZSBwcm90ZWM9DQo+IHRlZDxicj4NCj4gJmd0OyBMU1Ag dG8gYmUgdW5kZXJzdG9vZCBieSB0aGUgbWVyZ2UgcG9pbnQgYXM8YnI+DQo+ICZndDsgd2VsbCBh cyBhbiBvdXRlciBsYWJlbCBmb3IgdGhlIGJ5cGFzcyBMU1AuPGJyPg0KPiAmZ3Q7PGJyPg0KPiAm Z3Q7IFNvLCB0aGUgdGV4dCByZWZlcnMgdG8gYSBiYWNrdXAgcGF0aCBpbnN0ZWFkIG9mIGEgYnlw YXNzIHR1bm5lbCBiZWNhdXM9DQo+IGU8YnI+DQo+ICZndDsgaGF2aW5nIHRoZSBieXBhc3MgdHVu bmVsIGlzbiYjMzk7dCBxdWl0ZSBzdWZmaWNpZW50Ljxicj4NCj4gJmd0OyBEb2VzIHRoYXQgbWFr ZSBzZW5zZSB0byB5b3U/PGJyPg0KPiA8YnI+DQo+IDwvc3Bhbj5UaGUgY3VycmVudCB0ZXh0IGlz IGluY29ycmVjdC4gVGhpcyBpcyBiZWNhdXNlIGEgUExSIG1heSBzaWduYWwgYTxicj0NCj4gPg0K PiBiYWNrdXAgcGF0aCBhdCB0aGUgdGltZSBvZiBmYWlsdXJlLiBZZXQsIG9uZSBzaG91bGQgbm90 IHdhaXQgZm9yPGJyPg0KPiB0aGUgZmFpbHVyZSB0byBzZXQgdGhlICZxdW90O2xvY2FsIHByb3Rl Y3Rpb24gYXZhaWxhYmxlJnF1b3Q7IGZsYWcuIFRoZSBQTFI9DQo+IDxicj4NCj4gc2hvdWxkIHNl dCB0aGlzIGZsYWcgYXMgc29vbiBhcyBpdCBoYXMgYSAqYnlwYXNzKiB0dW5uZWwuPGJyPjwvYmxv Y2txdW90ZT48PQ0KPiBkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIGJhY2t1cCBwYXRoIGlzIGNyZWF0 ZWQgYnkgdGhlIFBMUiBiZWZvcmUgdGhlIGZhaWx1cmU9DQo+ICBhbmQgdGh1cywgYmVmb3JlIHRo ZTwvZGl2PjxkaXY+YXNzb2NpYXRlZCBzaWduYWxpbmcuPUMyPUEwIE9uY2UgdGhlIFBMUiBoYT0N Cj4gcyBkb25lIHRoZSB3b3JrIHRvIGNyZWF0ZSBhIGJhY2t1cCBwYXRoIHVzaW5nPC9kaXY+PGRp dj5hbiBleGlzdGluZyBieXBhc3MgPQ0KPiB0dW5uZWwgLSB3aGljaCBpcyBpbnRlcm5hbCB3b3Jr IC0gdGhlbiB0aGUgUExSIHNob3VsZCBzZXQ8L2Rpdj48ZGl2PnRoZSAmcXU9DQo+IG90O2xvY2Fs IHByb3RlY3Rpb24gYXZhaWxhYmxlJnF1b3Q7IGZsYWcuID1DMj1BMDwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+QT0NCj4gbGlhPUMyPUEwPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PUMy PUEwPC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9M0QiZ21hPQ0KPiBpbF9xdW90ZSIgc3R5bGU9M0Qi bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWY9 DQo+IHQ6MWV4Ij4NCj4gWWFrb3YuPGJyPg0KPiA8ZGl2PjxkaXYgY2xhc3M9M0QiaDUiPjxicj4N Cj4gJmd0Ozxicj4NCj4gJmd0OyBSZWdhcmRzLDxicj4NCj4gJmd0OyBBbGlhPGJyPg0KPiAmZ3Q7 PGJyPg0KPiAmZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgWWFrb3YuPGJyPg0KPiAmZ3Q7ICZndDs8YnI+ DQo+ICZndDsgJmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IEFsaWE8YnI+ DQo+ICZndDsgJmd0OyAmZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyBPbiBXZWQsIERlYyAxNywg MjAxNCBhdCAzOjA3IFBNLCBSRkMgRXJyYXRhIFN5c3RlbSAmbHQ7PGJyPg0KPiAmZ3Q7ICZndDsg Jmd0OyA8YSBocmVmPTNEIm1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpy ZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPiI+cmZjLWVkaXRvckByZmMtPQ0KPiBlZGl0b3Iub3Jn PGh0dHA6Ly9lZGl0b3Iub3JnPjwvYT4mZ3Q7IHdyb3RlOjxicj4NCj4gJmd0OyAmZ3Q7ICZndDs8 YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhh cyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDND0NCj4gMDkwLDxicj4NCj4gJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmcXVvdDtGYXN0IFJlcm91dGUgRXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBMU1AgVHVu bmVsPQ0KPiBzJnF1b3Q7Ljxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCj4gJmd0OyAm Z3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N Cj4gJmd0OyAmZ3Q7ICZndDsgJmd0OyBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFu ZCBhdDo8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0zRCJodHRwOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwPz0NCj4gcmZjPTNENDA5MCZhbXA7ZWlkPTNE NDIwMyIgdGFyZ2V0PTNEIl9ibGFuayI+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhPQ0K PiB0YV9zZWFyY2gucGhwP3JmYz0zRDQwOTAmYW1wO2VpZD0zRDQyMDM8L2E+PGJyPg0KPiAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFR5cGU6 IFRlY2huaWNhbDxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZXBvcnRlZCBieTogWWFrb3Yg UmVraHRlciAmbHQ7PGEgaHJlZj0zRCJtYWlsdG86eWFrb3ZAPG1haWx0bzp5YWtvdkA+PQ0KPiBq dW5pcGVyLm5ldDxodHRwOi8vanVuaXBlci5uZXQ+Ij55YWtvdkBqdW5pcGVyLm5ldDxtYWlsdG86 eWFrb3ZAanVuaXBlci5uZXQ+PC9hPiZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsgU2VjdGlvbjogNjxicj4NCj4gJmd0OyAmZ3Q7ICZndDsg Jmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmd0OyBPcmlnaW5hbCBUZXh0PGJyPg0KPiAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS08YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsg V2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBiYWNrdXAgcGF0aCBhdmFpbGFibGUsIHRoZSBQTFIgTT0N Cj4gVVNUIHNldDxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgJnF1b3Q7bG9jYWwgcHJv dGVjdGlvbiBhdmFpbGFibGUmcXVvdDsgZmxhZy48YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDs8 YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsgQ29y cmVjdGVkIFRleHQ8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS08YnI+ DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsgV2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBvbmUtdG8tb25l IGJhY2t1cCBMU1Agb3IgYnlwYXNzID0NCj4gdHVubmVsPGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNUIHNldCB0aGUgJnF1b3Q7bG9jYWwgcHJvdGVjdGlv biA9DQo+IGF2YWlsYWJsZSZxdW90OyBmbGFnLjxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmd0Ozxi cj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmd0OyBOb3Rl czxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLTxicj4NCj4gJmd0OyAmZ3Q7ICZndDsg Jmd0OyBJbiB0aGUgY2FzZSBvZiBmYWNpbGl0eS1iYXNlZCBGUlIgdGhlIFBMUiBtdXN0IHNldCB0 aGUgPQ0KPiAmcXVvdDtsb2NhbDxicj4NCj4gJmd0OyAmZ3Q7IHByb3RlY3Rpb248YnI+DQo+ICZn dDsgJmd0OyAmZ3Q7ICZndDsgYXZhaWxhYmxlJnF1b3Q7IGZsYWcgaWYgaXQgaGFzIHRoZSBieXBh c3MgdHVubmVsIGF2YWlsYT0NCj4gYmxlLjxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4N Cj4gJmd0OyAmZ3Q7ICZndDsgJmd0OyBJbnN0cnVjdGlvbnM6PGJyPg0KPiAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IC0tLS0tLS0tLS0tLS08YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhpcyBlcnJh dHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJnF1b3Q7UmVwb3J0ZWQmcXVvdD0NCj4gOy4gSWYg bmVjZXNzYXJ5LCBwbGVhc2U8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsgdXNlICZxdW90O1Jl cGx5IEFsbCZxdW90OyB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkID0NCj4gYmUgdmVyaWZp ZWQgb3I8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsgcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lv biBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcj0NCj4gdHkgKElFU0cpPGJyPg0KPiAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQg dGhlIHJlcG9ydCwgaWY9DQo+ICBuZWNlc3NhcnkuPGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJGQzQwOTAgKGRyYWZ0LWlldGYt bXBscy1yc3ZwLWxzcC1mYXN0cmVyb3V0ZS0wNyk8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo+ICZndDsgJmd0OyAm Z3Q7ICZndDsgVGl0bGU9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9 QzI9QTAgPQ0KPiA9QzI9QTA6IEZhc3QgUmVyb3V0ZSBFeHRlbnNpb25zIHRvIFJTVlAtVEUgZm9y IExTUDxicj4NCj4gJmd0OyAmZ3Q7IFR1bm5lbHM8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZndDsg UHVibGljYXRpb24gRGF0ZT1DMj1BMCA9QzI9QTAgOiBNYXkgMjAwNTxicj4NCj4gJmd0OyAmZ3Q7 ICZndDsgJmd0OyBBdXRob3Iocyk9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1D Mj1BMDogUC4gPQ0KPiBQYW4sIEVkLiwgRy4gU3dhbGxvdywgRWQuLCBBLiBBdGxhcywgRWQuPGJy Pg0KPiAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IENhdGVnb3J5PUMyPUEwID1DMj1BMCA9QzI9QTAgPUMy PUEwID1DMj1BMCA9QzI9QTAgOiBQUk89DQo+IFBPU0VEIFNUQU5EQVJEPGJyPg0KPiAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IFNvdXJjZT1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMy PUEwID1DMj1BMCA9DQo+IDogTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmc8YnI+DQo+ICZn dDsgJmd0OyAmZ3Q7ICZndDsgQXJlYT1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAg PUMyPUEwID1DMj1BMCA9DQo+ID1DMj1BMCA6IFJvdXRpbmc8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7 ICZndDsgU3RyZWFtPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMy PUEwID0NCj4gOiBJRVRGPGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFZlcmlmeWluZyBQYXJ0 eT1DMj1BMCA9QzI9QTAgPUMyPUEwOiBJRVNHPGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy Pg0KPiAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0Ozxicj4NCj4gJmd0 OyAmZ3Q7ICZndDsgLS0wMDFhMTEzOTdhMmM5YmRhNmUwNTBhNmYzMWFlPGJyPg0KPiAmZ3Q7ICZn dDsgJmd0OyBDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD0zRCZxdW90O1VURi04JnF1 b3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90 ZWQtcHJpbnRhYmxlPGJyPg0KPiAmZ3Q7ICZndDsgJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsg Jmx0O2RpdiBkaXI9M0QzRCZxdW90O2x0ciZxdW90OyZndDtIaSBZYWtvdiwmbHQ7YnImZ3Q7Jmx0 O2JyPQ0KPiAmZ3Q7Q291bGQgeW91IGNsYXJpZnkgeW91ciBwb2ludCBmb3IgdGhpczxicj4NCj4g Jmd0OyAmZ3Q7IGVycj0zRDxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgYXRhPz0zREMyPTNEQTAgSW4g UkZDIDQwOTAsIGluIHRoZSB0ZXJtaW5vbG9neSBpdCBzYXlzOiZsdDtiPQ0KPiByJmd0OyZhbXA7 cXVvdDsgQmFja3VwPGJyPg0KPiAmZ3Q7ICZndDsgUGF0aDogPTNEPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgVGhlIExTUCB0aGF0IGlzIHJlc3BvbnNpYmxlIGZvciBiYWNraW5nIHVwIG9uZSZsdDticiZn dDs9M0RDPQ0KPiAyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwPGJyPg0KPiAmZ3Q7ICZndDsg PTNEQzI9M0Q8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ID0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RB MCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMD0NCj4gID0zREMyPTNEQTAgPTNEQzI9 M0RBMCA9M0RDMj0zREEwcHJvdGVjdGVkPGJyPg0KPiAmZ3Q7ICZndDsgTFNQLj0zRDxicj4NCj4g Jmd0OyAmZ3Q7ICZndDsgPTNEQzI9M0RBMCBBIGJhY2t1cCBwYXRoIHJlZmVycyB0byBlaXRoZXIg YSBkZXRvdXIgTFNQJmx0O2JyPQ0KPiAmZ3Q7PTNEQzI9M0RBMCA9M0RDMj0zREEwPGJyPg0KPiAm Z3Q7ICZndDsgPTNEQzI9M0RBMCA9M0Q8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ID0zREMyPTNEQTAg PTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0NCj4gPTNE QTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTBvciBhPGJyPg0KPiAmZ3Q7ICZndDsg YmFja3VwIHQ9M0Q8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IHVubmVsLiZsdDticiZndDsmbHQ7YnIm Z3Q7PTNEQzI9M0RBMCBCYWNrdXAgVHVubmVsOiBUaGUgTFNQID0NCj4gdGhhdCBpcyB1c2VkIHRv IGJhY2t1cCB1cDxicj4NCj4gJmd0OyAmZ3Q7IG9uZSBvPTNEPGJyPg0KPiAmZ3Q7ICZndDsgJmd0 OyBmIHRoZSBtYW55Jmx0O2JyJmd0Oz0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0z REMyPQ0KPiA9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEw PGJyPg0KPiAmZ3Q7ICZndDsgPTNEQzI9M0Q8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ID0zREEwTFNQ cyBpbiBtYW55LXRvLW9uZTxicj4NCj4gJmd0OyAmZ3Q7IGJhY2t1cC4mYW1wO3F1b3Q7Jmx0O2Rp diZndDsmbHQ7YnImZ3Q7Jmx0Oy9kaXYmZ3Q7Jmx0O2RpdiZndDtUaGFuPQ0KPiBrcywmbHQ7L2Rp diZndDsmbHQ7ZGl2Jmd0O0E9M0Q8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IGxpYSZsdDsvZGl2Jmd0 OyZsdDsvZGl2Jmd0OyZsdDtkaXYgY2xhc3M9M0QzRCZxdW90O2dtYWlsX2V4dD0NCj4gcmEmcXVv dDsmZ3Q7Jmx0O2JyJmd0OyZsdDtkaXY8YnI+DQo+ICZndDsgJmd0OyBjbGFzcz0zRDNEJnF1b3Q7 Z21haWxfcXVvdGUmcXVvdDsmZ3Q7T249M0Q8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7PUMyPUEwIFdl ZCwgRGVjIDE3LCAyMDE0IGF0IDM6MDcgUE0sIFJGQyBFcnJhdGEgU3lzdGVtICZsdDtzcD0NCj4g YW48YnI+DQo+ICZndDsgJmd0OyBkaXI9M0QzRCZxdW90O2x0ciZxdW90OyZndDsmYW1wO2x0OyZs dDthIGg9M0Q8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IHJlZj0zRDNEJnF1b3Q7bWFpbHRvOjxhIGhy ZWY9M0QibWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvcjxtYWlsdG86cmZjLWVkaXRvckByZmMt ZWRpdG9yPj0NCj4gLm9yZyI+cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWVk aXRvckByZmMtZWRpdG9yLm9yZz48L2E+JnF1b3Q7PGJyPg0KPiAmZ3Q7ICZndDsgdGFyZ2V0PTNE M0QmcXVvdDtfYmxhbmsmcXVvdDsmZ3Q7cmZjLWVkaXRvckByZmMtZT0zRDxicj4NCj4gJmd0OyAm Z3Q7ICZndDsgPGEgaHJlZj0zRCJodHRwOi8vZGl0b3Iub3JnIiB0YXJnZXQ9M0QiX2JsYW5rIj5k aXRvci5vcmc8aHR0cDovL2RpdG9yLm9yZz48L2E+PQ0KPiAmbHQ7L2EmZ3Q7JmFtcDtndDsmbHQ7 L3NwYW4mZ3Q7IHdyb3RlOiZsdDticiZndDsmbHQ7YmxvY2txdW90ZSBjbGFzcz0zRDNEJnE9DQo+ IHVvdDtnbWFpbF9xdW90ZSZxdW90Ozxicj4NCj4gJmd0OyAmZ3Q7IHN0eWxlPTNEPGJyPg0KPiAm Z3Q7ICZndDsgJmd0OyA9M0QzRCZxdW90O21hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGQ9DQo+IGluZy1sZWZ0OjFleCZxdW90OyZndDtUaGU8YnI+DQo+ICZn dDsgJmd0OyBmb2xsPTNEPGJyPg0KPiAmZ3Q7ICZndDsgb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMg YmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzQwOTAsJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZn dDsgJmFtcDtxdW90O0Zhc3QgUmVyb3V0ZSBFeHRlbnNpb25zIHRvIFJTVlAtVEUgZm9yIExTUCBU dW5uZWxzPQ0KPiAmYW1wO3F1b3Q7LiZsdDticiZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZs dDticiZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgWW91IG1heSByZXZp ZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZn dDsgJmx0O2EgaHJlZj0zRDNEJnF1b3Q7PGJyPg0KPiAmZ3Q7ICZndDsgPGEgaHJlZj0zRCJodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRDNENDA9DQo+IDkw JmFtcDthbXA7ZWlkPTNEIiB0YXJnZXQ9M0QiX2JsYW5rIj5odHRwOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2VycmF0YV9zZWFyYz0NCj4gaC5waHA/cmZjPTNEM0Q0MDkwJmFtcDthbXA7ZWlkPTNEPC9h Pjxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgPTNEM0Q0MjAzJnF1b3Q7IHRhcmdldD0zRDNEJnF1b3Q7 X2JsYW5rJnF1b3Q7Jmd0Ozxicj4NCj4gJmd0OyAmZ3Q7IDxhIGhyZWY9M0QiaHR0cDovL3d3dy5y ZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9M0QiIHRhPQ0KPiByZ2V0PTNEIl9i bGFuayI+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9M0Q8 L2E+PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyA9M0QzRDQwOTAmYW1wO2FtcDtlaWQ9M0QzRDQyMDMm bHQ7L2EmZ3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmx0O2JyJmd0Ozxicj4N Cj4gJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0m bHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyBUeXBlOiBUZWNobmljYWwmbHQ7YnImZ3Q7 PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyBSZXBvcnRlZCBieTogWWFrb3YgUmVraHRlciAmYW1wO2x0 OyZsdDthIGhyZWY9M0QzRCZxdW90O21haWw9DQo+IHRvOjxhIGhyZWY9M0QibWFpbHRvOnlha292 QGp1bmlwZXIubmV0PG1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldD4iPnlha292QGp1bmlwZXIubmV0 PG1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldD48L2E+PGJyPg0KPiAmZ3Q7ICZndDsgJnF1b3Q7Jmd0 O3lha292QGo9M0Q8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9M0QiaHR0cDovL3VuaXBl ci5uZXQiIHRhcmdldD0zRCJfYmxhbmsiPnVuaXBlci5uZXQ8aHR0cDovL3VuaXBlci5uZXQ+PC89 DQo+IGE+Jmx0Oy9hJmd0OyZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsg Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgU2VjdGlvbjogNiZsdDticiZndDs8YnI+ DQo+ICZndDsgJmd0OyAmZ3Q7ICZsdDticiZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IE9yaWdp bmFsIFRleHQmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tJmx0 O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgV2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBiYWNr dXAgcGF0aCBhdmFpbGFibGUsIHRoZSBQTFIgTVVTVCBzPQ0KPiBldCZsdDticiZndDs8YnI+DQo+ ICZndDsgJmd0OyAmZ3Q7IHRoZSAmYW1wO3F1b3Q7bG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUm YW1wO3F1b3Q7IGZsYWcuJmx0Oz0NCj4gYnImZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmbHQ7 YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsg Jmd0OyBDb3JyZWN0ZWQgVGV4dCZsdDticiZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IC0tLS0t LS0tLS0tLS0tJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgV2hlbmV2ZXIgdGhlIFBM UiBoYXMgYSBvbmUtdG8tb25lIGJhY2t1cCBMU1Agb3IgYnlwYXNzIHR1bm5lPQ0KPiBsJmx0O2Jy Jmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgYXZhaWxhYmxlLCB0aGUgUExSIE1VU1Qgc2V0IHRo ZSAmYW1wO3F1b3Q7bG9jYWwgcHJvdGVjdGlvbiBhPQ0KPiB2YWlsYWJsZSZhbXA7cXVvdDs8YnI+ DQo+ICZndDsgJmd0OyBmbGFnPTNEPGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAuJmx0O2JyJmd0Ozxi cj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmx0 O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgTm90ZXMmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7 ICZndDsgJmd0OyAtLS0tLSZsdDticiZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IEluIHRoZSBj YXNlIG9mIGZhY2lsaXR5LWJhc2VkIEZSUiB0aGUgUExSIG11c3Qgc2V0IHRoZSAmYW1wOz0NCj4g cXVvdDtsb2NhbDxicj4NCj4gJmd0OyAmZ3Q7IHByb3RlY3RpPTNEPGJyPg0KPiAmZ3Q7ICZndDsg Jmd0OyBvbiBhdmFpbGFibGUmYW1wO3F1b3Q7IGZsYWcgaWYgaXQgaGFzIHRoZSBieXBhc3MgdHVu bmVsIGF2YWk9DQo+IGxhYmxlLiZsdDticiZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7ICZsdDti ciZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IEluc3RydWN0aW9uczombHQ7YnImZ3Q7PGJyPg0K PiAmZ3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7 ICZndDsgVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJmFtcDtxdW90O1JlcG9y dGVkJmFtcDtxPQ0KPiB1b3Q7LiBJZiBuZWNlc3NhcnksPGJyPg0KPiAmZ3Q7ICZndDsgcGxlPTNE PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyBhc2UmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0 OyB1c2UgJmFtcDtxdW90O1JlcGx5IEFsbCZhbXA7cXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyIGl0 IHNob3U9DQo+IGxkIGJlIHZlcmlmaWVkIG9yJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZn dDsgcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBh cnR5IChJPQ0KPiBFU0cpJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgY2FuIGxvZyBp biB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlPQ0KPiBz c2FyeS4mbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KPiAm Z3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZsdDti ciZndDs8YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IFJGQzQwOTAgKGRyYWZ0LWlldGYtbXBscy1yc3Zw LWxzcC1mYXN0cmVyb3V0ZS0wNykmbHQ7YnImZ3Q7PD0NCj4gYnI+DQo+ICZndDsgJmd0OyAmZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmx0O2JyJmd0Ozxicj4NCj4g Jmd0OyAmZ3Q7ICZndDsgVGl0bGU9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RD Mj0zREEwID0zREMyPTNEQTAgPQ0KPiA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMDog RmFzdDxicj4NCj4gJmd0OyAmZ3Q7IFJlcm91dGUgPTNEPGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyBF eHRlbnNpb25zIHRvIFJTVlAtVEUgZm9yIExTUCBUdW5uZWxzJmx0O2JyJmd0Ozxicj4NCj4gJmd0 OyAmZ3Q7ICZndDsgUHVibGljYXRpb24gRGF0ZT0zREMyPTNEQTAgPTNEQzI9M0RBMCA6IE1heSAy MDA1Jmx0O2JyJmd0OzxiPQ0KPiByPg0KPiAmZ3Q7ICZndDsgJmd0OyBBdXRob3Iocyk9M0RDMj0z REEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPQ0KPiA9M0RBMCA9M0RD Mj0zREEwOiBQLiBQYW4sIEVkLiwgRy48YnI+DQo+ICZndDsgJmd0OyBTd2FsbG93PTNEPGJyPg0K PiAmZ3Q7ICZndDsgJmd0OyAsIEVkLiwgQS4gQXRsYXMsIEVkLiZsdDticiZndDs8YnI+DQo+ICZn dDsgJmd0OyAmZ3Q7IENhdGVnb3J5PTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNE QzI9M0RBMCA9M0RDMj0zRD0NCj4gQTAgPTNEQzI9M0RBMCA6IFBST1BPU0VEIFNUQU5EQVJEJmx0 O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgU291cmNlPTNEQzI9M0RBMCA9M0RDMj0zREEw ID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwPQ0KPiAgPTNEQzI9M0RBMCA9M0RDMj0z REEwIDogTXVsdGlwcm90b2NvbDxicj4NCj4gJmd0OyAmZ3Q7IExhYmU9M0Q8YnI+DQo+ICZndDsg Jmd0OyAmZ3Q7IGwgU3dpdGNoaW5nJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgQXJl YT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9 DQo+ID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwIDogUm91dGluZyZsdDticiZndDs8 YnI+DQo+ICZndDsgJmd0OyAmZ3Q7IFN0cmVhbT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0z REEwID0zREMyPTNEQTAgPTNEQzI9M0RBMD0NCj4gID0zREMyPTNEQTAgPTNEQzI9M0RBMCA6IElF VEYmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyBWZXJpZnlpbmcgUGFydHk9M0RDMj0z REEwID0zREMyPTNEQTAgPTNEQzI9M0RBMDogSUVTRyZsdDticiY9DQo+IGd0Ozxicj4NCj4gJmd0 OyAmZ3Q7ICZndDsgJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmZ3Q7ICZndDsgJmx0Oy9ibG9ja3F1 b3RlJmd0OyZsdDsvZGl2Jmd0OyZsdDticiZndDsmbHQ7L2RpdiZndDs8YnI+DQo+ICZndDsgJmd0 OyAmZ3Q7PGJyPg0KPiAmZ3Q7ICZndDsgJmd0OyAtLTAwMWExMTM5N2EyYzliZGE2ZTA1MGE2ZjMx YWUtLTxicj4NCj4gJmd0OyAmZ3Q7PGJyPg0KPiAmZ3Q7PGJyPg0KPiA8L2Rpdj48L2Rpdj4mZ3Q7 IC0tMDQ3ZDdiNWQ5OWEzM2E5MTRiMDUwYTcwMTY0ZTxicj4NCj4gPHNwYW4gY2xhc3M9M0QiIj4m Z3Q7IENvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PTNEJnF1b3Q7VVRGLTgmcXVvdDs8 PQ0KPiBicj4NCj4gJmd0OyBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRh YmxlPGJyPg0KPiAmZ3Q7PGJyPg0KPiA8L3NwYW4+Jmd0OyAmbHQ7ZGl2IGRpcj0zRDNEJnF1b3Q7 bHRyJnF1b3Q7Jmd0O1lha292LCZsdDtkaXYgY2xhc3M9M0QzRCZxdW89DQo+IHQ7Z21haWxfZXh0 cmEmcXVvdDsmZ3Q7Jmx0O2JyJmd0OyZsdDtkaXYgY2xhc3M9M0QzRCZxdW90O2dtYWlsX3E9M0Q8 YnI+DQo+ICZndDsgdW90ZSZxdW90OyZndDtPbiBXZWQsIERlYyAxNywgMjAxNCBhdCA0OjA1IFBN LCBZYWtvdiBSZWtodGVyICZsdDtzcGFuID0NCj4gZGlyPTNEM0QmcXVvdDtsdHImcXVvdDsmZ3Q7 JmFtcDtsdDs9M0Q8YnI+DQo+ICZndDsgJmx0O2EgaHJlZj0zRDNEJnF1b3Q7bWFpbHRvOjxhIGhy ZWY9M0QibWFpbHRvOnlha292QGp1bmlwZXIubmV0PG1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldD4i Pnlha292PQ0KPiBAanVuaXBlci5uZXQ8aHR0cDovL2p1bmlwZXIubmV0PjwvYT4mcXVvdDsgdGFy Z2V0PTNEM0QmcXVvdDtfYmxhbmsmcXVvdDsmZ3Q7PGEgaHJlZj0zRCJtYWlsdG86eTxtYWlsdG86 eT49DQo+IGFrb3ZAanVuaXBlci5uZXQ8bWFpbHRvOmFrb3ZAanVuaXBlci5uZXQ+Ij55YWtvdkBq dW5pcGVyLm5ldDxtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQ+PC9hPiZsdDsvYT0zRDxicj4NCj4g Jmd0OyAmZ3Q7JmFtcDtndDsmbHQ7L3NwYW4mZ3Q7IHdyb3RlOiZsdDticiZndDsmbHQ7YmxvY2tx dW90ZSBjbGFzcz0zRDNEJnF1PQ0KPiBvdDtnbWFpbF9xdW90ZSZxdW90OyBzdHlsZT0zRDNEJnF1 b3Q7bWFyZ2luOjAgPTNEPGJyPg0KPiAmZ3Q7IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgmcXVvdDsmZ3Q7QWxpYSwmbHQ9DQo+IDticiZndDs8YnI+ DQo+ICZndDsgJmx0O3NwYW4gY2xhc3M9M0QzRCZxdW90OyZxdW90OyZndDsmbHQ7YnImZ3Q7PGJy Pg0KPiAmZ3Q7ICZhbXA7Z3Q7IEhpIFlha292LCZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtn dDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IENvdWxkIHlvdSBjbGFyaWZ5IHlvdXIg cG9pbnQgZm9yIHRoaXMgZXJyYXRhPz0zREMyPTNEQTAgSW4gUkY9DQo+IEMgNDA5MCwgaW4gdGg9 M0Q8YnI+DQo+ICZndDsgZSZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgdGVybWlub2xv Z3kgaXQgc2F5czombHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7PTNEQzI9M0RBMCAmYW1w O3F1b3Q7QmFja3VwIFBhdGg6IFRoZSBMU1AgdGhhdCBpcyByZXNwb25zaWJsZSA9DQo+IGZvciBi YWNraW5nIHVwIG9uPTNEPGJyPg0KJmd0OyBlJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0 Oz0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9 M0RDMj0NCj4gPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RB MCA9M0Q8YnI+DQo+ICZndDsgPTNEQzI9M0RBMCA9M0RDMj0zREEwIHByb3RlY3RlZCBMU1AuPTNE QzI9M0RBMCBBIGJhY2t1cCBwYXRoIHJlZmVycyB0bz0NCj4gIGVpdGhlciBhJmx0O2JyJmd0Ozxi cj4NCj4gJmd0OyAmYW1wO2d0Oz0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMy PTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0NCj4gPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0z REMyPTNEQTAgPTNEQzI9M0RBMCA9M0Q8YnI+DQo+ICZndDsgPTNEQzI9M0RBMCA9M0RDMj0zREEw IGRldG91ciBMU1Agb3IgYSBiYWNrdXAgdHVubmVsLiZsdDticiZndDs8YnI+DQo+ICZndDsgJmFt cDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7PTNEQzI9M0RBMCA9M0RDMj0zREEw QmFja3VwIFR1bm5lbDogVGhlIExTUCB0aGF0IGlzIHVzZWQgdG8gYmE9DQo+IGNrdXAgdXAgb25l IG9mIHRoPTNEPGJyPg0KPiAmZ3Q7IGUgbWFueSZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtn dDs9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAg PTNEQzI9DQo+ID0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwIExTUHMgaW4g PTNEPGJyPg0KPiAmZ3Q7IG1hbnktdG8tb25lIGJhY2t1cC4mYW1wO3F1b3Q7Jmx0O2JyJmd0Ozxi cj4NCj4gJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZsdDsvc3BhbiZndDtJbiB0aGUgdGVy bWlub2xvZ3kgaXQgYWxzbyBzYXlzOiZsdDticiZndDs8YnI+DQo+ICZndDsgJmx0O2JyJmd0Ozxi cj4NCj4gJmd0OyA9M0RDMj0zREEwID0zREMyPTNEQTAmYW1wO3F1b3Q7QnlwYXNzIFR1bm5lbDog QW4gTFNQIHRoYXQgaXMgdXNlZCB0byBwPQ0KPiByb3RlY3QgYSBzZXQgb2YgTD0zRDxicj4NCj4g Jmd0OyBTUHMmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RD Mj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwIHBhc3M9DQo+IGluZyBvdmVy IGEgY29tbW9uIGZhY2lsaXR5LiZhbXA7cT0zRDxicj4NCj4gJmd0OyB1b3Q7Jmx0O2JyJmd0Ozxi cj4NCj4gJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7IE15IHBvaW50IGlzIHRoYXQgKHVubGVz cyB0aGUgdGVybSAmYW1wO3F1b3Q7YnlwYXNzIHR1bm5lbCZhbXA7cXVvdDsgbWU9DQo+IGFucyB0 aGUgc2FtZSZsdDs9M0Q8YnI+DQo+ICZndDsgYnImZ3Q7PGJyPg0KPiAmZ3Q7IGFzICZhbXA7cXVv dDtiYWNrdXAgcGF0aCZhbXA7cXVvdDsgb3IgJmFtcDtxdW90O2JhY2t1cCB0dW5uZWwmYW1wO3F1 b3Q9DQo+IDspIGluIG1hbnktdG8tb25lIGJhYz0zRDxicj4NCj4gJmd0OyBrdXAmbHQ7YnImZ3Q7 PGJyPg0KPiAmZ3Q7IHRoZSAmYW1wO3F1b3Q7bG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUmYW1w O3F1b3Q7IGZsYWcgZm9yIGEgZ2l2ZW4gcHI9DQo+IG90ZWN0ZWQgTFNQJmx0O2I9M0Q8YnI+DQo+ ICZndDsgciZndDs8YnI+DQo+ICZndDsgTVVTVCBiZSBzZXQgd2hlbiB0aGUgUExSIGhhcyBhICpi eXBhc3MqIHR1bm5lbCBmb3IgdGhhdCBMU1AuJmx0O2JyJmd0Oz0NCj4gJmx0Oy9ibG9ja3F1b3Q9 M0Q8YnI+DQo+ICZndDsgZSZndDsmbHQ7ZGl2Jmd0OyZsdDticiZndDsmbHQ7L2RpdiZndDsmbHQ7 ZGl2Jmd0O0FoIC0gb2suPTNEQzI9M0RBMCBBID0NCj4gYmFja3VwIHBhdGggdGhhdCB1c2VzIGEg YnlwYXNzIHR1bm5lPTNEPGJyPg0KPiAmZ3Q7IGwgaXMgbm90IGp1c3QgdGhlIGJ5cGFzcyB0dW5u ZWwmbHQ7L2RpdiZndDsmbHQ7ZGl2Jmd0O2l0c2VsZi49M0RDMj0zREE9DQo+IDAgVGhlcmUmYW1w OyMzOTtzIHRoZSBzdGE9M0Q8YnI+DQo+ICZndDsgdGUgYXNzb2NpYXRlZCBmb3IgdGhlIHByb3Rl Y3RlZCBMU1AgdGhhdCBhbHNvIG5lZWRzIHRvIGJlJmx0Oy9kaXYmZ3Q7Jj0NCj4gbHQ7ZGl2Jmd0 O2NyZWF0ZWQ9M0Q8YnI+DQo+ICZndDs9QzI9QTAgYW5kIGluc3RhbGxlZC49M0RDMj0zREEwIElu IG1vcmUgY29uY3JldGUgdGVybXMsIHRoaXMgaXMgaW5zdGFsbD0NCj4gaW5nIGFuIG91dC1zZWc9 M0Q8YnI+DQo+ICZndDsgbWVudCB3aXRoPTNEQzI9M0RBMCZsdDsvZGl2Jmd0OyZsdDtkaXYmZ3Q7 dGhlIGFwcHJvcHJpYXRlIGxhYmVsIGZvciB0aD0NCj4gZSBwcm90ZWN0ZWQgTFNQIHRvIGJlPTNE PGJyPg0KPiAmZ3Q7PUMyPUEwIHVuZGVyc3Rvb2QgYnkgdGhlIG1lcmdlIHBvaW50IGFzJmx0Oy9k aXYmZ3Q7Jmx0O2RpdiZndDt3ZWxsIGFzIGE9DQo+IG4gb3V0ZXIgbGFiZWwgZm9yIHRoZSA9M0Q8 YnI+DQo+ICZndDsgYnlwYXNzIExTUC4mbHQ7L2RpdiZndDsmbHQ7ZGl2Jmd0OyZsdDticiZndDsm bHQ7L2RpdiZndDsmbHQ7ZGl2Jmd0O1NvLD0NCj4gIHRoZSB0ZXh0IHJlZmVycyB0byBhIGJhY2t1 cCBwYXRoIGk9M0Q8YnI+DQo+ICZndDsgbnN0ZWFkIG9mIGEgYnlwYXNzIHR1bm5lbCBiZWNhdXNl IGhhdmluZyB0aGUmbHQ7L2RpdiZndDsmbHQ7ZGl2Jmd0O2J5cD0NCj4gYXNzIHR1bm5lbCBpc24m YW1wOyMzPTNEPGJyPg0KPiAmZ3Q7IDk7dCBxdWl0ZSBzdWZmaWNpZW50Lj0zREMyPTNEQTAgRG9l cyB0aGF0IG1ha2Ugc2Vuc2UgdG8geW91PyZsdDsvZGl2Jmc9DQo+IHQ7Jmx0O2RpdiZndDsmbHQ7 YnImZ3Q7Jmx0Oy9kaT0zRDxicj4NCj4gJmd0OyB2Jmd0OyZsdDtkaXYmZ3Q7UmVnYXJkcywmbHQ7 L2RpdiZndDsmbHQ7ZGl2Jmd0O0FsaWEmbHQ7L2RpdiZndDsmbHQ7ZGl2PQ0KPiAmZ3Q7PTNEQzI9 M0RBMCZsdDsvZGl2Jmd0OyZsdDtibG9ja3F1b3RlIGNsYXNzPTNEM0QmcXVvdDtnPTNEPGJyPg0K PiAmZ3Q7IG1haWxfcXVvdGUmcXVvdDsgc3R5bGU9M0QzRCZxdW90O21hcmdpbjowIDAgMCAuOGV4 O2JvcmRlci1sZWZ0OjFweCAjY2M9DQo+IGMgc29saWQ7cGFkZGluZy1sPTNEPGJyPg0KPiAmZ3Q7 IGVmdDoxZXgmcXVvdDsmZ3Q7PGJyPg0KPiAmZ3Q7IFlha292LiZsdDticiZndDs8YnI+DQo+ICZn dDsgJmx0O2RpdiZndDsmbHQ7ZGl2IGNsYXNzPTNEM0QmcXVvdDtoNSZxdW90OyZndDsmbHQ7YnIm Z3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IFRoYW5rcywmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZh bXA7Z3Q7IEFsaWEmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4N Cj4gJmd0OyAmYW1wO2d0OyBPbiBXZWQsIERlYyAxNywgMjAxNCBhdCAzOjA3IFBNLCBSRkMgRXJy YXRhIFN5c3RlbSAmYW1wO2x0OyZsPQ0KPiB0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAm bHQ7YSBocmVmPTNEM0QmcXVvdDttYWlsdG86PGEgaHJlZj0zRCJtYWlsdG86cmZjLWVkaXRvckBy ZmMtPG1haWx0bzpyZmMtZWRpdG9yQHJmYy0+PQ0KPiBlZGl0b3Iub3JnPGh0dHA6Ly9lZGl0b3Iu b3JnPiI+cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWVkaXRvckByZmMtZWRp dG9yLm9yZz48L2E+JnF1b3Q7Jmd0OzxhIGhyZWY9M0QibWFpbHRvOnJmYy1lZDxtYWlsdG86cmZj LWVkPj0NCj4gaXRvckByZmMtZWRpdG9yLm9yZzxtYWlsdG86aXRvckByZmMtZWRpdG9yLm9yZz4i PnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8bWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5v cmc+PC9hPj0zRDxicj4NCj4gJmd0OyAmbHQ7L2EmZ3Q7JmFtcDtndDsgd3JvdGU6Jmx0O2JyJmd0 Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFt cDtndDsgVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3Ig Uj0NCj4gRkM0MDkwLCZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFt cDtxdW90O0Zhc3QgUmVyb3V0ZSBFeHRlbnNpb25zIHRvIFJTVlAtVEUgZm9yIExTUD0NCj4gIFR1 bm5lbHMmYW1wO3F1b3Q7LiZsdDtiPTNEPGJyPg0KPiAmZ3Q7IHImZ3Q7PGJyPg0KPiAmZ3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZsdDticiZndDs8YnI+DQo+ICZn dDsgJmFtcDtndDsgJmFtcDtndDsgWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQg YXQ6Jmx0O2JyJmd0Ozxicj0NCj4gPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZsdDthIGhy ZWY9M0QzRCZxdW90OzxhIGhyZWY9M0QiaHR0cDovL3d3dy5yZmMtZWRpdG89DQo+IHIub3JnL2Vy cmF0YV9zZWFyY2gucGhwP3JmYz0zRDNENDA5MD0zRDxodHRwOi8vci5vcmcvZXJyYXRhX3NlYXJj aC5waHA/cmZjPTNEM0Q0MDkwPTNEPiIgdGFyZ2V0PTNEIl9ibGFuayI+aHR0cDovL3d3dy5yZmMt ZT0NCj4gZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRDNENDA5MD0zRDxodHRwOi8v ZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRDNENDA5MD0zRD48L2E+PGJyPg0KPiAm Z3Q7ICZhbXA7YW1wO2VpZD0zRDNENDIwMyZxdW90OyB0YXJnZXQ9M0QzRCZxdW90O19ibGFuayZx dW90OyZndDs8YSBocmVmPQ0KPiA9M0QiaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFf c2VhcmNoLj0zRCIgdGFyZ2V0PTNEIl9ibGFuayI+aHR0cDovL3c9DQo+IHd3LnJmYy1lZGl0b3Iu b3JnL2VycmF0YV9zZWFyY2guPTNEPGh0dHA6Ly93dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2Vh cmNoLj0zRD48L2E+PGJyPg0KPiAmZ3Q7IHBocD9yZmM9M0QzRDQwOTAmYW1wO2FtcDtlaWQ9M0Qz RDQyMDMmbHQ7L2EmZ3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyZs dDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7 Z3Q7IFR5cGU6IFRlY2huaWNhbCZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtn dDsgUmVwb3J0ZWQgYnk6IFlha292IFJla2h0ZXIgJmFtcDtsdDsmbHQ7YSBocmVmPTNEM0QmcT0N Cj4gdW90O21haWx0bzo8YSBocmVmPTNEIm1haWx0bzp5YWtvdkBqdW5pcGVyLm5lPG1haWx0bzp5 YWtvdkBqdW5pcGVyLm5lPiI+eWFrb3ZAanVuaXBlci5uZTxtYWlsdG86eWFrb3ZAanVuaXBlci5u ZT48L2E+PTNEPGJyPg0KPiAmZ3Q7IHQmcXVvdDsmZ3Q7PGEgaHJlZj0zRCJtYWlsdG86eWFrb3ZA anVuaXBlci5uZXQ8bWFpbHRvOnlha292QGp1bmlwZXIubmV0PiI+eWFrb3ZAanVuaXBlci5uZXQ8 bWFpbHRvOnlha292QGp1bmlwZXIubmV0PjwvYT4mPQ0KPiBsdDsvYSZndDsmYW1wO2d0OyZsdDti ciZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFNlY3Rpb246IDYmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7 Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBPcmln aW5hbCBUZXh0Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAtLS0tLS0t LS0tLS0tJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBXaGVuZXZlciB0 aGUgUExSIGhhcyBhIGJhY2t1cCBwYXRoIGF2YWlsYWJsZSwgdGhlIFBMPQ0KPiBSIE1VU1Qgc2V0 Jmx0O2JyPTNEPGJyPg0KPiAmZ3Q7ICZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsg dGhlICZhbXA7cXVvdDtsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSZhbXA7cXVvdDsgZj0NCj4g bGFnLiZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJy Pg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0 OyAmYW1wO2d0OyBDb3JyZWN0ZWQgVGV4dCZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsg JmFtcDtndDsgLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZh bXA7Z3Q7IFdoZW5ldmVyIHRoZSBQTFIgaGFzIGEgb25lLXRvLW9uZSBiYWNrdXAgTFNQIG9yIGJ5 cGE9DQo+IHNzIHR1bm5lbCZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsg YXZhaWxhYmxlLCB0aGUgUExSIE1VU1Qgc2V0IHRoZSAmYW1wO3F1b3Q7bG9jYWwgcHJvdD0NCj4g ZWN0aW9uIGF2YWlsYWJsZSZhbXA7PTNEPGJyPg0KPiAmZ3Q7IHF1b3Q7IGZsYWcuJmx0O2JyJmd0 Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFt cDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IE5v dGVzJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAtLS0tLSZsdDticiZn dDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsgSW4gdGhlIGNhc2Ugb2YgZmFjaWxpdHkt YmFzZWQgRlJSIHRoZSBQTFIgbXVzdCBzZXQgdD0NCj4gaGUgJmFtcDtxdW90O2xvY2E9M0Q8YnI+ DQo+ICZndDsgbCBwcm90ZWN0aW9uJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1w O2d0OyBhdmFpbGFibGUmYW1wO3F1b3Q7IGZsYWcgaWYgaXQgaGFzIHRoZSBieXBhc3MgdHVubmVs PQ0KPiAgYXZhaWxhYmxlLiZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsm bHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IEluc3RydWN0aW9uczombHQ7 YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0mbHQ7YnIm Z3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50 bHkgcG9zdGVkIGFzICZhbXA7cXVvdDtSZXBvcnQ9DQo+IGVkJmFtcDtxdW90Oy4gSWYgbmVjZT0z RDxicj4NCj4gJmd0OyBzc2FyeSwgcGxlYXNlJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0 OyAmYW1wO2d0OyB1c2UgJmFtcDtxdW90O1JlcGx5IEFsbCZhbXA7cXVvdDsgdG8gZGlzY3VzcyB3 aGV0aGVyPQ0KPiAgaXQgc2hvdWxkIGJlIHZlcmlmaWU9M0Q8YnI+DQo+ICZndDsgZCBvciZsdDti ciZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsgcmVqZWN0ZWQuIFdoZW4gYSBkZWNp c2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nID0NCj4gcGFydHkgKElFU0cpJmx0Oz0zRDxi cj4NCj4gJmd0OyBiciZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsgY2FuIGxvZyBp biB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LD0NCj4gIGlmIG5lY2Vz c2FyeT0zRDxicj4NCj4gJmd0OyAuJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1w O2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7IFJGQzQwOTAgKGRyYWZ0LWlldGYtbXBscy1yc3ZwLWxzcC1mYXN0cmVyb3V0ZS0w NykmbHQ9DQo+IDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7 Z3Q7ICZhbXA7Z3Q7IFRpdGxlPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9 M0RBMCA9M0Q9DQo+IEMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTA6IEZh cz0zRDxicj4NCj4gJmd0OyB0IFJlcm91dGUgRXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBMU1Ag VHVubmVscyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsgUHVibGljYXRp b24gRGF0ZT0zREMyPTNEQTAgPTNEQzI9M0RBMCA6IE1heSAyMDA1Jmx0Oz0NCj4gYnImZ3Q7PGJy Pg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IEF1dGhvcihzKT0zREMyPTNEQTAgPTNEQzI9M0RB MCA9M0RDMj0zREEwID0zREMyPTNEQTA9DQo+ICA9M0RDMj0zREEwID0zREMyPTNEQTA6IFAuIFBh biwgRWQuLCA9M0Q8YnI+DQo+ICZndDsgRy4gU3dhbGxvdywgRWQuLCBBLiBBdGxhcywgRWQuJmx0 O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBDYXRlZ29yeT0zREMyPTNEQTAg PTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPQ0KPiA9M0RDMj0zREEwID0zREMyPTNE QTAgOiBQUk9QT1NFRCBTVEFOPTNEPGJyPg0KPiAmZ3Q7IERBUkQmbHQ7YnImZ3Q7PGJyPg0KPiAm Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFNvdXJjZT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0z REEwID0zREMyPTNEQTAgPQ0KPiA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA6IE11 bHRpcHJvPTNEPGJyPg0KPiAmZ3Q7IHRvY29sIExhYmVsIFN3aXRjaGluZyZsdDticiZndDs8YnI+ DQo+ICZndDsgJmFtcDtndDsgJmFtcDtndDsgQXJlYT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RD Mj0zREEwID0zREMyPTNEQTAgPTNEQz0NCj4gMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9 M0RDMj0zREEwIDogUm91PTNEPGJyPg0KPiAmZ3Q7IHRpbmcmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFN0cmVhbT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEw ID0zREMyPTNEQTAgPQ0KPiA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA6IElFVEYm bHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFZlcmlmeWluZyBQYXJ0eT0z REMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwOiBJRVM9DQo+IEcmbHQ7YnImZ3Q7PGJyPg0K PiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAm YW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAm Z3Q7ICZsdDsvZGl2Jmd0OyZsdDsvZGl2Jmd0OyZhbXA7Z3Q7IC0tMDAxYTExMzk3YTJjOWJkYTZl MDUwYTZmMzFhZSZsdDticiY9DQo+IGd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBDb250ZW50LVR5 cGU6IHRleHQvaHRtbDsgY2hhcnNldD0zRDNEJmFtcDtxdW90O1VURi04JmFtcDtxdW90PQ0KPiA7 Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5n OiBxdW90ZWQtcHJpbnRhYmxlJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyZsdDticiZn dDs8YnI+DQo+ICZndDsgJmFtcDtndDsgJmFtcDtsdDtkaXYgZGlyPTNEM0QzRCZhbXA7cXVvdDts dHImYW1wO3F1b3Q7JmFtcDtndDtIaSBZYWtvdj0NCj4gLCZhbXA7bHQ7YnImYW1wO2d0OyZhbXA7 bHQ7YnImYW1wO2d0O0NvdWxkID0zRDxicj4NCj4gJmd0OyB5b3UgY2xhcmlmeSB5b3VyIHBvaW50 IGZvciB0aGlzIGVycj0zRDNEJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBhdGE/PTNE M0RDMj0zRDNEQTAgSW4gUkZDIDQwOTAsIGluIHRoZSB0ZXJtaW5vbG9neSBpdCBzYXlzOiZhPQ0K PiBtcDtsdDticiZhbXA7Z3Q7JmFtcDthbXA7PTNEPGJyPg0KPiAmZ3Q7IHF1b3Q7IEJhY2t1cCBQ YXRoOiA9M0QzRCZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgVGhlIExTUCB0aGF0IGlz IHJlc3BvbnNpYmxlIGZvciBiYWNraW5nIHVwIG9uZSZhbXA7bHQ7YnImYW1wOz0NCj4gZ3Q7PTNE M0RDMj0zRDNEQTAgPTNEM0Q9M0Q8YnI+DQo+ICZndDsgQzI9M0QzREEwID0zRDNEQzI9M0QzREEw ID0zRDNEQzI9M0QzRCZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgPTNEM0RBMCA9M0Qz REMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPQ0KPiA9M0Qz REEwID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREE9M0Q8YnI+DQo+ICZndDsgMCA9M0QzREMy PTNEM0RBMCA9M0QzREMyPTNEM0RBMHByb3RlY3RlZCBMU1AuPTNEM0QmbHQ7YnImZ3Q7PGJyPg0K PiAmZ3Q7ICZhbXA7Z3Q7ID0zRDNEQzI9M0QzREEwIEEgYmFja3VwIHBhdGggcmVmZXJzIHRvIGVp dGhlciBhIGRldG91ciBMU1AmYW09DQo+IHA7bHQ7YnImYW1wO2d0Oz0zRDNEQzI9M0Q8YnI+DQo+ ICZndDsgPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzRCZsdDticiZn dDs8YnI+DQo+ICZndDsgJmFtcDtndDsgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNE M0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPQ0KPiA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNE M0RBMCA9M0QzREM9M0Q8YnI+DQo+ICZndDsgMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RD Mj0zRDNEQTBvciBhIGJhY2t1cCB0PTNEM0QmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7 IHVubmVsLiZhbXA7bHQ7YnImYW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0Oz0zRDNEQzI9M0QzREEw IEJhY2s9DQo+IHVwIFR1bm5lbDogVGhlIExTUCB0aGF0IGlzIHVzPTNEPGJyPg0KPiAmZ3Q7IGVk IHRvIGJhY2t1cCB1cCBvbmUgbz0zRDNEJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBm IHRoZSBtYW55JmFtcDtsdDticiZhbXA7Z3Q7PTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAg PTNEPQ0KPiAzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEPGJyPg0KPiAmZ3Q7 ID0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNE M0RDMj0zRDNEJmx0O2I9DQo+IHImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ID0zRDNEQTBMU1Bz IGluIG1hbnktdG8tb25lIGJhY2t1cC4mYW1wO2FtcDtxdW90OyZhbXA7bHQ7ZGl2JmE9DQo+IG1w O2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZhbXA7bHQ7L2RpPTNEPGJyPg0KPiAmZ3Q7IHYmYW1wO2d0 OyZhbXA7bHQ7ZGl2JmFtcDtndDtUaGFua3MsJmFtcDtsdDsvZGl2JmFtcDtndDsmYW1wO2x0O2Rp diZhbXA9DQo+IDtndDtBPTNEM0QmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IGxpYSZh bXA7bHQ7L2RpdiZhbXA7Z3Q7JmFtcDtsdDsvZGl2JmFtcDtndDsmYW1wO2x0O2RpdiBjbGFzcz0N Cj4gPTNEM0QzRCZhbXA7cXVvdDtnbWFpbF9leHRyYSZhbXA7cXVvdDsmYW1wO2c9M0Q8YnI+DQo+ ICZndDsgdDsmYW1wO2x0O2JyJmFtcDtndDsmYW1wO2x0O2RpdiBjbGFzcz0zRDNEM0QmYW1wO3F1 b3Q7Z21haWxfcXVvdGUmYW1wOz0NCj4gcXVvdDsmYW1wO2d0O09uPTNEM0QmbHQ7YnImZ3Q7PGJy Pg0KPiAmZ3Q7ICZhbXA7Z3Q7PTNEQzI9M0RBMCBXZWQsIERlYyAxNywgMjAxNCBhdCAzOjA3IFBN LCBSRkMgRXJyYXRhIFN5c3RlbSAmYW09DQo+IHA7bHQ7c3BhbiBkaXI9M0QzRDM9M0Q8YnI+DQo+ ICZndDsgRCZhbXA7cXVvdDtsdHImYW1wO3F1b3Q7JmFtcDtndDsmYW1wO2FtcDtsdDsmYW1wO2x0 O2EgaD0zRDNEJmx0O2JyJmd0Oz0NCj4gPGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IHJlZj0zRDNEM0Qm YW1wO3F1b3Q7bWFpbHRvOiZsdDthIGhyZWY9M0QzRCZxdW90O21haWx0bzo8YSBocmU9DQo+IGY9 M0QibWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8bWFpbHRvOnJmYy1lZGl0b3JAcmZj LWVkaXRvci5vcmc+Ij5yZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnPjwvYT4mcXVvdDsmPQ0KPiBndDtyZmMtPTNEPGJyPg0KPiAmZ3Q7IDxh IGhyZWY9M0QibWFpbHRvOmVkaXRvckByZmMtZWRpdG9yLm9yZzxtYWlsdG86ZWRpdG9yQHJmYy1l ZGl0b3Iub3JnPiI+ZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzplZGl0b3JAcmZjLWVkaXRv ci5vcmc+PC9hPiZsdDs9DQo+IC9hJmd0OyZhbXA7cXVvdDsgdGFyZ2V0PTNEM0QzRCZhbXA7cXVv dDtfYmxhbmsmYW1wO3F1b3Q7JmFtcDtndDtyZmMtZWRpdG9yPQ0KPiA9M0Q8YnI+DQo+ICZndDsg QHJmYy1lPTNEM0QmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZsdDthIGhyZWY9M0Qz RCZxdW90OzxhIGhyZWY9M0QiaHR0cDovL2RpdG9yLm9yZyIgdGFyZ2V0PTNEIl89DQo+IGJsYW5r Ij5odHRwOi8vZGl0b3Iub3JnPC9hPiZxdW90OyB0YXJnZXQ9M0QzRCZxdW90O19ibGFuayZxdW90 OyZndDs8YSBocmVmPQ0KPiA9M0QiaHR0cDovL2RpdG9yLm9yZyIgdGFyZ2V0PTNEIl9ibGFuayI+ ZGl0b3Iub3JnPGh0dHA6Ly9kaXRvci5vcmc+PC9hPiZsdDsvYSZndDsmYW1wO2x0Oy9hJmE9DQo+ IG1wO2d0Oz0zRDxicj4NCj4gJmd0OyAmYW1wO2FtcDtndDsmYW1wO2x0Oy9zcGFuJmFtcDtndDsg d3JvdGU6JmFtcDtsdDticiZhbXA7Z3Q7JmFtcDtsdDtibG9jPQ0KPiBrcXVvdGUgY2xhc3M9M0Qz RDNEJmFtcDtxdW90O2dtYWlsXz0zRDxicj4NCj4gJmd0OyBxdW90ZSZhbXA7cXVvdDsgc3R5bGU9 M0QzRCZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgPTNEM0QzRCZhbXA7cXVvdDttYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZD0NCj4gO3BhZGRpbmctbGVm dDoxPTNEPGJyPg0KPiAmZ3Q7IGV4JmFtcDtxdW90OyZhbXA7Z3Q7VGhlIGZvbGw9M0QzRCZsdDti ciZndDs8YnI+DQo+ICZndDsgb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQg Zm9yIFJGQzQwOTAsJmFtcDtsdDticiZhbXA7Z3Q7Jj0NCj4gbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7 ICZhbXA7Z3Q7ICZhbXA7YW1wO3F1b3Q7RmFzdCBSZXJvdXRlIEV4dGVuc2lvbnMgdG8gUlNWUC1U RSBmb3IgTFNQIFR1bm49DQo+IGVscyZhbXA7YW1wO3F1b3Q7PTNEPGJyPg0KPiAmZ3Q7IC4mYW1w O2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7YnIm YW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0mYW1wO2x0O2JyJmFtcDtndDsmbHQ7Yj0NCj4gciZndDs8YnI+ DQo+ICZndDsgJmFtcDtndDsgWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6 JmFtcDtsdDticiZhbXA7Z3Q7Jmx0Oz0NCj4gYnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZh bXA7bHQ7YSBocmVmPTNEM0QzRCZhbXA7cXVvdDsmbHQ7YSBocmVmPTNEM0QmcXVvdDs8YSBocmVm PQ0KPiA9M0QiaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmM9M0QiIHRhcmdl dD0zRCJfYmxhbmsiPmh0dHA6Ly93d3c9DQo+IC5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmM9 M0Q8aHR0cDovL3JmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyYz0zRD48L2E+PGJyPg0KPiAmZ3Q7 IGgucGhwP3JmYz0zRDNEM0Q0MDkwJmFtcDthbXA7YW1wO2VpZD0zRDNEJnF1b3Q7IHRhcmdldD0z RDNEJnF1b3Q7X2JsYW49DQo+IGsmcXVvdDsmZ3Q7PGEgaHJlZj0zRCJodHRwOi8vd3d3LnJmYy1l ZGl0b3IuIiB0YXJnZXQ9M0QiX2JsYW5rIj5odHRwOi8vd3d3Lj0NCj4gcmZjLWVkaXRvci48L2E+ PTNEPGJyPg0KPiAmZ3Q7IG9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9M0QzRDNENDA5MCZhbXA7 YW1wO2FtcDtlaWQ9M0QzRCZsdDsvYSZndDsmbHQ9DQo+IDticiZndDs8YnI+DQo+ICZndDsgJmFt cDtndDsgPTNEM0QzRDQyMDMmYW1wO3F1b3Q7IHRhcmdldD0zRDNEM0QmYW1wO3F1b3Q7X2JsYW5r JmFtcDtxdW90Oz0NCj4gJmFtcDtndDsmbHQ7YSBocmVmPTNEM0QmcXVvdDs8YSBocmVmPTNEImh0 dHA6Ly93d3ciIHRhcmdldD0zRCJfYmxhbmsiPmh0dHA6PQ0KPiAvL3d3dzwvYT49M0Q8YnI+DQo+ ICZndDsgLjxhIGhyZWY9M0QiaHR0cDovL3JmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhw P3JmYz0zRDNEIiB0YXJnZXQ9DQo+ID0zRCJfYmxhbmsiPnJmYy1lZGl0b3Iub3JnL2VycmF0YV9z ZWFyY2gucGhwP3JmYz0zRDNEPGh0dHA6Ly9yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBo cD9yZmM9M0QzRD48L2E+JnF1b3Q7IHRhcmdldD0zRDNEPQ0KPiAmcXVvdDtfYmxhbmsmcXVvdDsm Z3Q7PGEgaHJlZj0zRCJodHRwOi8vd3d3LnJmYy0iIHRhcmdldD0zRCJfYmxhbmsiPmh0dHA6Ly89 DQo+IHd3dy5yZmMtPC9hPj0zRDxicjxodHRwOi8vd3d3LnJmYy0lM2MvYSUzZT0zRCUzY2JyPj4N Cj4gJmd0OyA8YSBocmVmPTNEImh0dHA6Ly9lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3Jm Yz0zRDNEIiB0YXJnZXQ9M0QiX2JsPQ0KPiBhbmsiPmVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5w aHA/cmZjPTNEM0Q8aHR0cDovL2VkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTNEM0Q+ PC9hPiZsdDsvYSZndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ID0zRDNEM0Q0MDkw JmFtcDthbXA7YW1wO2VpZD0zRDNEM0Q0MjAzJmFtcDtsdDsvYSZhbXA7Z3Q7JmFtcDs9DQo+IGx0 O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7YnImYW1w O2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0mYW1wO2x0O2JyJmFtcDtndDsmbHQ7Yj0NCj4gciZndDs8YnI+DQo+ ICZndDsgJmFtcDtndDsgVHlwZTogVGVjaG5pY2FsJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0 Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBSZXBvcnRlZCBieTogWWFrb3YgUmVraHRlciAmYW1wO2Ft cDtsdDsmYW1wO2x0O2EgaHJlZj0zRDNEM0QmPQ0KPiBhbXA7cXVvdDttYWlsdG86Jmx0O2EgaHJl Zj0zRDxicj4NCj4gJmd0OyA9M0QzRCZxdW90O21haWx0bzo8YSBocmVmPTNEIm1haWx0bzp5YWtv dkBqdW5pcGVyLm5ldDxtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQ+Ij55YWtvdkBqdW5pcGVyLm48 bWFpbHRvOnlha292QGp1bmlwZXIubj49DQo+IGV0PC9hPiZxdW90OyZndDs8YSBocmVmPTNEIm1h aWx0bzp5YWtvdkBqdW5pcGVyLm5ldDxtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQ+Ij55YWtvdkBq dW5pcGVyLm5ldDxtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQ+PC9hPiY9DQo+IGx0Oy9hJmd0OyZh bXA7cXVvdDsmYW1wO2d0O3lha292QGo9M0QzRCZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtn dDsgJmx0O2EgaHJlZj0zRDNEJnF1b3Q7PGEgaHJlZj0zRCJodHRwOi8vdW5pcGVyLm5ldCIgdGFy Z2V0PTNEIj0NCj4gX2JsYW5rIj5odHRwOi8vdW5pcGVyLm5ldDwvYT4mcXVvdDsgdGFyZ2V0PTNE M0QmcXVvdDtfYmxhbmsmcXVvdDsmZ3Q7PGEgaHJlPQ0KPiBmPTNEImh0dHA6Ly91bmlwZXIubmV0 IiB0YXJnZXQ9M0QiX2JsYW5rIj51bmlwZXIubmV0PGh0dHA6Ly91bmlwZXIubmV0PjwvYT4mbHQ7 L2EmZ3Q7JmFtcDtsdDsvPQ0KPiBhJmFtcDtnPTNEPGJyPg0KPiAmZ3Q7IHQ7JmFtcDthbXA7Z3Q7 JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAmYW1wO2x0 O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IFNlY3Rpb246IDYmYW1w O2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7YnIm YW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgT3JpZ2luYWwgVGV4dCZhbXA7 bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0t LSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgV2hlbmV2 ZXIgdGhlIFBMUiBoYXMgYSBiYWNrdXAgcGF0aCBhdmFpbGFibGUsIHRoZSBQTFIgTVVTVCBzZT0N Cj4gdCZhbXA7bHQ7YnImYW1wO2c9M0Q8YnI+DQo+ICZndDsgdDsmbHQ7YnImZ3Q7PGJyPg0KPiAm Z3Q7ICZhbXA7Z3Q7IHRoZSAmYW1wO2FtcDtxdW90O2xvY2FsIHByb3RlY3Rpb24gYXZhaWxhYmxl JmFtcDthbXA7cXVvdDsgZmw9DQo+IGFnLiZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+ DQo+ICZndDsgJmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0 OyAmYW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7 Z3Q7IENvcnJlY3RlZCBUZXh0JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0 OyAmYW1wO2d0OyAtLS0tLS0tLS0tLS0tLSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+ DQo+ICZndDsgJmFtcDtndDsgV2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBvbmUtdG8tb25lIGJhY2t1 cCBMU1Agb3IgYnlwYXNzIHR1bm5lbD0NCj4gJmFtcDtsdDticiZhbXA7Z3Q9M0Q8YnI+DQo+ICZn dDsgOyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgYXZhaWxhYmxlLCB0aGUgUExSIE1V U1Qgc2V0IHRoZSAmYW1wO2FtcDtxdW90O2xvY2FsIHByb3RlY3Rpbz0NCj4gbiBhdmFpbGFibGUm YW1wO2E9M0Q8YnI+DQo+ICZndDsgbXA7cXVvdDsgZmxhZz0zRDNEJmx0O2JyJmd0Ozxicj4NCj4g Jmd0OyAmYW1wO2d0OyAuJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAm YW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7 ICZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgTm90ZXMm YW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IC0tLS0tJmFt cDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBJbiB0aGUgY2Fz ZSBvZiBmYWNpbGl0eS1iYXNlZCBGUlIgdGhlIFBMUiBtdXN0IHNldCB0aGUgJmFtcDthPQ0KPiBt cDtxdW90O2xvY2FsPTNEPGJyPg0KPiAmZ3Q7PUMyPUEwIHByb3RlY3RpPTNEM0QmbHQ7YnImZ3Q7 PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IG9uIGF2YWlsYWJsZSZhbXA7YW1wO3F1b3Q7IGZsYWcgaWYg aXQgaGFzIHRoZSBieXBhc3MgdHVubmVsIGE9DQo+IHZhaWxhYmxlLiZhbXA7bHQ7PTNEPGJyPg0K PiAmZ3Q7IGJyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7 YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgSW5zdHJ1Y3Rpb25zOiZh bXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgLS0tLS0tLS0t LS0tLSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgVGhp cyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJmFtcDthbXA7cXVvdDtSZXBvcnRlZCZh bT0NCj4gcDthbXA7cXVvdDsuIElmIG49M0Q8YnI+DQo+ICZndDsgZWNlc3NhcnksIHBsZT0zRDNE Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBhc2UmYW1wO2x0O2JyJmFtcDtndDsmbHQ7 YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IHVzZSAmYW1wO2FtcDtxdW90O1JlcGx5IEFsbCZh bXA7YW1wO3F1b3Q7IHRvIGRpc2N1c3Mgd2hldGhlciA9DQo+IGl0IHNob3VsZCBiZSB2ZXJpPTNE PGJyPg0KPiAmZ3Q7IGZpZWQgb3ImYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAm Z3Q7ICZhbXA7Z3Q7IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZl cmlmeWluZyBwYXJ0eSAoSUU9DQo+IFNHKSZhbXA7bHQ7YnI9M0Q8YnI+DQo+ICZndDsgJmFtcDtn dDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRo ZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXM9DQo+IHNhcnkuJmFtcDtsdDs9 M0Q8YnI+DQo+ICZndDsgYnImYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsg JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZhbXA7bHQ7YnImYW1wO2d0OyZsdDtiPQ0K PiByJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBSRkM0MDkwIChkcmFmdC1pZXRmLW1wbHMtcnN2 cC1sc3AtZmFzdHJlcm91dGUtMDcpJmFtcDtsdDticiZhPQ0KPiBtcDtndDsmbHQ7YnImZ3Q7PGJy Pg0KPiAmZ3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2I9DQo+IHImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7Z3Q7IFRp dGxlPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0z RDM9DQo+IERBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMD0zRDxicj4NCj4gJmd0Oz1D Mj1BMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMDogRmFzdCBSZXJvdXRlID0zRDNEJmx0 O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBFeHRlbnNpb25zIHRvIFJTVlAtVEUgZm9yIExT UCBUdW5uZWxzJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyPQ0KPiAmZ3Q7PGJyPg0KPiAmZ3Q7ICZh bXA7Z3Q7IFB1YmxpY2F0aW9uIERhdGU9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA6IE1h eSAyMDA1JmFtcDs9DQo+IGx0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZhbXA7 Z3Q7IEF1dGhvcihzKT0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEw ID0zRDNEQzI9DQo+ID0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDxicj4NCj4gJmd0 OyA9M0QzREEwOiBQLiBQYW4sIEVkLiwgRy4gU3dhbGxvdz0zRDNEJmx0O2JyJmd0Ozxicj4NCj4g Jmd0OyAmYW1wO2d0OyAsIEVkLiwgQS4gQXRsYXMsIEVkLiZhbXA7bHQ7YnImYW1wO2d0OyZsdDti ciZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgQ2F0ZWdvcnk9M0QzREMyPTNEM0RBMCA9M0QzREMy PTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPQ0KPiA9M0QzREEwID0zRDNEQzI9M0QzREEw ID0zRDNEQzI9M0Q8YnI+DQo+ICZndDsgPTNEM0RBMCA6IFBST1BPU0VEIFNUQU5EQVJEJmFtcDts dDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1wO2d0OyBTb3VyY2U9M0QzREMy PTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEPQ0KPiAzREEw ID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREE9M0Q8YnI+DQo+ICZndDsgMCA9M0QzREMyPTNE M0RBMCA6IE11bHRpcHJvdG9jb2wgTGFiZT0zRDNEJmx0O2JyJmd0Ozxicj4NCj4gJmd0OyAmYW1w O2d0OyBsIFN3aXRjaGluZyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsg JmFtcDtndDsgQXJlYT0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEw ID0zRDNEQzI9M0QzRD0NCj4gQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEPGJy Pg0KPiAmZ3Q7ID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEwIDogUm91dGluZyZhbXA7bHQ7 YnImYW1wO2d0OyZsdDticiZndDs8YnI9DQo+ID4NCj4gJmd0OyAmYW1wO2d0OyBTdHJlYW09M0Qz REMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEPQ0KPiAz REEwID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREE9M0Q8YnI+DQo+ICZndDsgMCA9M0QzREMy PTNEM0RBMCA6IElFVEYmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZh bXA7Z3Q7IFZlcmlmeWluZyBQYXJ0eT0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRDNE QzI9M0QzREEwOiA9DQo+IElFU0cmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KPiAm Z3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFt cDtndDsgJmFtcDtsdDsvYmxvY2txdW90ZSZhbXA7Z3Q7JmFtcDtsdDsvZGl2JmFtcDtndDsmYW1w O2x0O2JyJmFtcD0NCj4gO2d0OyZhbXA7bHQ7L2RpdiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCj4g Jmd0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQo+ICZndDsgJmFtcDtndDsgLS0wMDFhMTEzOTdh MmM5YmRhNmUwNTBhNmYzMWFlLS0mbHQ7YnImZ3Q7PGJyPg0KPiAmZ3Q7ICZsdDsvYmxvY2txdW90 ZSZndDsmbHQ7L2RpdiZndDsmbHQ7YnImZ3Q7Jmx0Oy9kaXYmZ3Q7Jmx0Oy9kaXYmZ3Q7PGJyPg0K PiAmZ3Q7PGJyPg0KPiAmZ3Q7IC0tMDQ3ZDdiNWQ5OWEzM2E5MTRiMDUwYTcwMTY0ZS0tPGJyPg0K PiA8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2Pg0KPg0KPiAtLTAwMWExMWMxZTll ZTQwZmQxOTA1MGE3MDY4YzktLQ0KDQo= --_000_DM2PR0501MB1662335A5977C94F9773CC94BE580DM2PR0501MB1662_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdo dDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsaWEsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBtb2RpZmllZCBFcnJhdGEsIGFzIHlv dSBzdWdnZXN0ZWQgYmVsb3csIGlzIGZpbmUgd2l0aCBtZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5ZYWtvdi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFsaWEgQXRs YXMgW21haWx0bzpha2F0bGFzQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks IEphbnVhcnkgMDUsIDIwMTUgMTI6MDAgUE08YnI+DQo8Yj5Ubzo8L2I+IFlha292IFJla2h0ZXI8 YnI+DQo8Yj5DYzo8L2I+IEdlb3JnZSBTd2FsbG93OyBBZHJpYW4gRmFycmVsOyBMb2EgQW5kZXJz c29uOyBSb3NzIENhbGxvbjsgbXBsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzQwOTAgKDQyMDMpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllha292LDxicj4NCjxicj4N CkkndmUgbW9kaWZpZWQgdGhlIEVycmF0YSB0byBzdWdnZXN0IGV4dGVuZGluZyB0aGUgdGV4dCBz bGlnaHRseSBhcyBmb2xsb3dzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtTZWN0aW9uIDYgc2F5 czo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7V2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBiYWNrdXAg cGF0aCBhdmFpbGFibGUsIHRoZSBQTFIgTVVTVCBzZXQ8YnI+DQombmJzcDsgJm5ic3A7dGhlICZx dW90O2xvY2FsIHByb3RlY3Rpb24gYXZhaWxhYmxlJnF1b3Q7IGZsYWcuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwO0l0IHNob3VsZCBzYXk6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1doZW5ldmVy IHRoZSBQTFIgaGFzIGEgYmFja3VwIHBhdGggYXZhaWxhYmxlLCB0aGUgUExSIE1VU1Qgc2V0PGJy Pg0KJm5ic3A7ICZuYnNwO3RoZSAmcXVvdDtsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSZxdW90 OyBmbGFnLiZuYnNwOyBGb3IgZXhhbXBsZSwgaWYgdGhlIFBMUiA8YnI+DQombmJzcDsgJm5ic3A7 aGFzIGRldGVybWluZWQgdG8gdXNlIGEgYnlwYXNzIHR1bm5lbCBhbmQgc2V0IHVwIHRoZSBuZWNl c3NhcnkgPGJyPg0KJm5ic3A7ICZuYnNwO2xvY2FsIGZvcndhcmRpbmcgc3RhdGUgdG8gYmUgYWJs ZSB0byB1c2UgaXQgYXMgYSBiYWNrdXAgcGF0aCwgPGJyPg0KJm5ic3A7ICZuYnNwO3RoZW4gdGhh dCBQTFIgaGFzIGEgYmFja3VwIHBhdGggYXZhaWxhYmxlLjxicj4NCjxicj4NCkFzc3VtaW5nIHRo YXQncyBvayB3aXRoIHRoZSBXRywgQWRyaWFuIG9yIEkgY2FuIGFwcHJvdmUgaXQuPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5BbGlhPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDk6MTEg UE0sIFlha292IFJla2h0ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldCIg dGFyZ2V0PSJfYmxhbmsiPnlha292QGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGlhLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCiZndDsgJmd0OyBBbGlhLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 IFlha292LDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgT24gV2VkLCBE ZWMgMTcsIDIwMTQgYXQgNDowNSBQTSwgWWFrb3YgUmVraHRlciAmbHQ7PGEgaHJlZj0ibWFpbHRv Onlha292QGp1bmlwZXIubmV0Ij55YWtvdkBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KJmd0OyAm Z3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBB bGlhLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgSGkgWWFrb3YsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IENvdWxkIHlvdSBjbGFyaWZ5IHlvdXIgcG9pbnQgZm9yIHRoaXMgZXJy YXRhPyZuYnNwOyBJbiBSRkMgNDA5MCwgaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IHRlcm1pbm9sb2d5IGl0IHNheXM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5i c3A7ICZxdW90O0JhY2t1cCBQYXRoOiBUaGUgTFNQIHRoYXQgaXMgcmVzcG9uc2libGUgZm9yIGJh Y2tpbmcgdXAgb25lPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgcHJvdGVjdGVkIExTUC4mbmJzcDsgQSBiYWNrdXAgcGF0aCByZWZlcnMgdG88 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlaXRoZXIgYSBkZXRvdXIgTFNQIG9y IGEgYmFja3VwIHR1bm5lbC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7QmFja3VwIFR1bm5lbDogVGhlIExTUCB0 aGF0IGlzIHVzZWQgdG8gYmFja3VwIHVwIG9uZSBvZiB0aGUgbWFueTxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IExTUHMgaW4gbWFueS10by1vbmUgYmFja3VwLiZxdW90Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEluIHRoZSB0ZXJt aW5vbG9neSBpdCBhbHNvIHNheXM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZxdW90O0J5cGFzcyBUdW5uZWw6IEFuIExTUCB0 aGF0IGlzIHVzZWQgdG8gcHJvdGVjdCBhIHNldCBvZiBMU1BzPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bhc3Np bmcgb3ZlciBhIGNvbW1vbiBmYWNpbGl0eS4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBNeSBwb2ludCBpcyB0aGF0ICh1bmxlc3MgdGhlIHRl cm0gJnF1b3Q7YnlwYXNzIHR1bm5lbCZxdW90OyBtZWFucyB0aGUgc2FtZTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgYXMgJnF1b3Q7YmFja3VwIHBhdGgmcXVvdDsgb3IgJnF1b3Q7YmFja3VwIHR1 bm5lbCZxdW90OykgaW4gbWFueS10by1vbmUgYmFja3VwPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyB0aGUgJnF1b3Q7bG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUmcXVvdDsgZmxhZyBmb3IgYSBn aXZlbiBwcm90ZWN0ZWQgTFNQPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBNVVNUIGJlIHNldCB3 aGVuIHRoZSBQTFIgaGFzIGEgKmJ5cGFzcyogdHVubmVsIGZvciB0aGF0IExTUC48YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBB aCAtIG9rLiZuYnNwOyBBIGJhY2t1cCBwYXRoIHRoYXQgdXNlcyBhIGJ5cGFzcyB0dW5uZWwgaXMg bm90IGp1c3QgdGhlIGJ5cGFzczxicj4NCiZndDsgJmd0OyAmZ3Q7IHR1bm5lbCBpdHNlbGYuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENvcnJlY3QuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgVGhlcmUncyB0aGUgc3RhdGUgYXNzb2NpYXRlZCBmb3IgdGhlIHByb3Rl Y3RlZCBMU1AgdGhhdDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFsc28gbmVlZHMgdG8gYmUgY3JlYXRl ZCBhbmQgaW5zdGFsbGVkLiZuYnNwOyBJbiBtb3JlIGNvbmNyZXRlIHRlcm1zLCB0aGlzPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgaXMgaW5zdGFsbGluZyBhbiBvdXQtc2VnbWVudCB3aXRoIHRoZSBhcHBy b3ByaWF0ZSBsYWJlbCBmb3IgdGhlIHByb3RlY3RlZDxicj4NCiZndDsgJmd0OyAmZ3Q7IExTUCB0 byBiZSB1bmRlcnN0b29kIGJ5IHRoZSBtZXJnZSBwb2ludCBhczxicj4NCiZndDsgJmd0OyAmZ3Q7 IHdlbGwgYXMgYW4gb3V0ZXIgbGFiZWwgZm9yIHRoZSBieXBhc3MgTFNQLjxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU28sIHRoZSB0ZXh0IHJlZmVycyB0byBhIGJhY2t1 cCBwYXRoIGluc3RlYWQgb2YgYSBieXBhc3MgdHVubmVsIGJlY2F1c2U8YnI+DQomZ3Q7ICZndDsg Jmd0OyBoYXZpbmcgdGhlIGJ5cGFzcyB0dW5uZWwgaXNuJ3QgcXVpdGUgc3VmZmljaWVudC48YnI+ DQomZ3Q7ICZndDsgJmd0OyBEb2VzIHRoYXQgbWFrZSBzZW5zZSB0byB5b3U/PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoZSBjdXJyZW50IHRleHQgaXMgaW5jb3JyZWN0LiBUaGlzIGlz IGJlY2F1c2UgYSBQTFIgbWF5IHNpZ25hbCBhPGJyPg0KJmd0OyAmZ3Q7IGJhY2t1cCBwYXRoIGF0 IHRoZSB0aW1lIG9mIGZhaWx1cmUuIFlldCwgb25lIHNob3VsZCBub3Qgd2FpdCBmb3I8YnI+DQom Z3Q7ICZndDsgdGhlIGZhaWx1cmUgdG8gc2V0IHRoZSAmcXVvdDtsb2NhbCBwcm90ZWN0aW9uIGF2 YWlsYWJsZSZxdW90OyBmbGFnLiBUaGUgUExSPGJyPg0KJmd0OyAmZ3Q7IHNob3VsZCBzZXQgdGhp cyBmbGFnIGFzIHNvb24gYXMgaXQgaGFzIGEgKmJ5cGFzcyogdHVubmVsLjxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZSBiYWNrdXAgcGF0aCBpcyBjcmVhdGVkIGJ5IHRoZSBQTFIgYmVmb3JlIHRoZSBm YWlsdXJlIGFuZCB0aHVzLCBiZWZvcmU8YnI+DQomZ3Q7IHRoZSBhc3NvY2lhdGVkIHNpZ25hbGlu Zy4gT25jZSB0aGUgUExSIGhhcyBkb25lIHRoZSB3b3JrIHRvIGNyZWF0ZTxicj4NCiZndDsgYSBi YWNrdXAgcGF0aCB1c2luZyBhbiBleGlzdGluZyBieXBhc3MgdHVubmVsIC0gd2hpY2ggaXMgaW50 ZXJuYWw8YnI+DQomZ3Q7IHdvcmsgLSB0aGVuIHRoZSBQTFIgc2hvdWxkIHNldCB0aGUgJnF1b3Q7 bG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUmcXVvdDsgZmxhZy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBzIHdlIHNob3VsZCBzdGVw IGJhY2sgYW5kIGFzayB3aGV0aGVyIHRoZSBxdW90ZSBmcm9tIHNlY3Rpb24gNjo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7V2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBiYWNrdXAgcGF0aCBhdmFpbGFi bGUsIHRoZSBQTFIgTVVTVCBzZXQ8YnI+DQombmJzcDsgJm5ic3A7dGhlICZxdW90O2xvY2FsIHBy b3RlY3Rpb24gYXZhaWxhYmxlJnF1b3Q7IGZsYWcuPGJyPg0KPGJyPg0KdGFsa3MgYWJvdXQgZm9y d2FyZGluZyBzdGF0ZSBvciBjb250cm9sIHBsYW5lIHN0YXRlLiBJcyB0aGVyZTxicj4NCmFueSB0 ZXh0IGluIHJmYzQwOTAgdGhhdCBhbnN3ZXJzIHRoaXMgcXVlc3Rpb24gPzxicj4NCjxicj4NCllh a292LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbGlhPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IFlha292Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBBbGlhPGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgWWFrb3YuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFsaWE8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT24g V2VkLCBEZWMgMTcsIDIwMTQgYXQgMzowNyBQTSwgUkZDIEVycmF0YSBTeXN0ZW0gJmx0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86cmZjLWVkaXRvckByZmMt ZWRpdG9yLm9yZyI+cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IFRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJG QzQwOTAsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJnF1b3Q7RmFzdCBSZXJv dXRlIEV4dGVuc2lvbnMgdG8gUlNWUC1URSBmb3IgTFNQIFR1bm5lbHMmcXVvdDsuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5k IGF0Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTQwOTAmYW1wO2VpZD00MjAz IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFy Y2gucGhwP3JmYz00MDkwJmFtcDtlaWQ9NDIwMzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgVHlwZTogVGVjaG5pY2FsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg UmVwb3J0ZWQgYnk6IFlha292IFJla2h0ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YWtvdkBqdW5p cGVyLm5ldCI+eWFrb3ZAanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgU2VjdGlvbjog Njxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgT3JpZ2luYWwgVGV4dDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IC0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBX aGVuZXZlciB0aGUgUExSIGhhcyBhIGJhY2t1cCBwYXRoIGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNU IHNldDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSAmcXVvdDtsb2NhbCBw cm90ZWN0aW9uIGF2YWlsYWJsZSZxdW90OyBmbGFnLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBDb3JyZWN0ZWQgVGV4dDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgV2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBvbmUtdG8tb25lIGJhY2t1cCBMU1Agb3Ig YnlwYXNzIHR1bm5lbDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF2YWlsYWJs ZSwgdGhlIFBMUiBNVVNUIHNldCB0aGUgJnF1b3Q7bG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUm cXVvdDsgZmxhZy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgTm90ZXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLTxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEluIHRoZSBjYXNlIG9mIGZhY2lsaXR5LWJhc2Vk IEZSUiB0aGUgUExSIG11c3Qgc2V0IHRoZSAmcXVvdDtsb2NhbDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgcHJvdGVjdGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF2YWls YWJsZSZxdW90OyBmbGFnIGlmIGl0IGhhcyB0aGUgYnlwYXNzIHR1bm5lbCBhdmFpbGFibGUuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyBJbnN0cnVjdGlvbnM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoaXMg ZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICZxdW90O1JlcG9ydGVkJnF1b3Q7LiBJZiBu ZWNlc3NhcnksPGJyPg0KJmd0OyAmZ3Q7IHBsZWFzZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IHVzZSAmcXVvdDtSZXBseSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyIGl0 IHNob3VsZCBiZSB2ZXJpZmllZCBvcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0 eSAoSUVTRyk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBjYW4gbG9nIGluIHRv IGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS48YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgUkZDNDA5MCAoZHJhZnQtaWV0Zi1tcGxzLXJzdnAt bHNwLWZhc3RyZXJvdXRlLTA3KTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7OiBGYXN0IFJlcm91dGUgRXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZv ciBMU1A8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFR1bm5lbHM8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyBQdWJsaWNhdGlvbiBEYXRlJm5ic3A7ICZuYnNwOyA6IE1heSAyMDA1 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQXV0aG9yKHMpJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IFAuIFBhbiwgRWQuLCBHLiBTd2FsbG93LCBF ZC4sIEEuIEF0bGFzLCBFZC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBDYXRl Z29yeSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogUFJPUE9TRUQg U1RBTkRBUkQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBTb3VyY2UmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBNdWx0aXByb3RvY29s IExhYmVsIFN3aXRjaGluZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFyZWEm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDog Um91dGluZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFN0cmVhbSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IElFVEY8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBWZXJpZnlpbmcgUGFydHkmbmJzcDsgJm5ic3A7ICZu YnNwOzogSUVTRzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgLS0wMDFhMTEzOTdhMmM5YmRhNmUwNTBhNmYzMWFl PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IENvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBj aGFyc2V0PSZxdW90O1VURi04JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IENv bnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGU8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O2RpdiBkaXI9 M0QmcXVvdDtsdHImcXVvdDsmZ3Q7SGkgWWFrb3YsJmx0O2JyJmd0OyZsdDticiZndDtDb3VsZCB5 b3UgY2xhcmlmeSB5b3VyIHBvaW50IGZvcjxicj4NCiZndDsgJmd0OyB0aGlzPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBlcnI9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF0YT89QzI9 QTAgSW4gUkZDIDQwOTAsIGluIHRoZSB0ZXJtaW5vbG9neSBpdCBzYXlzOiZsdDticiZndDsmYW1w O3F1b3Q7IEJhY2t1cDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgUGF0aDogPTxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgTFNQIHRoYXQgaXMgcmVzcG9uc2libGUgZm9yIGJhY2tp bmcgdXAgb25lJmx0O2JyJmd0Oz1DMj1BMCA9QzI9QTA8YnI+DQomZ3Q7ICZndDsgPUMyPUEwPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA9QzI9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ID1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMy PUEwcHJvdGVjdGVkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBMU1AuPTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyA9QzI9QTAgQSBiYWNrdXAgcGF0aCByZWZlcnMgdG8gZWl0aGVyIGEg ZGV0b3VyIExTUCZsdDticiZndDs9QzI9QTAgPUMyPUEwPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyA9QzI9QTAgPTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA9QzI9QTAgPUMyPUEwID1D Mj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMG9yIGE8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IGJhY2t1cCB0PTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyB1bm5lbC4mbHQ7YnImZ3Q7Jmx0O2JyJmd0Oz1DMj1BMCBCYWNrdXAgVHVubmVsOiBUaGUgTFNQ IHRoYXQgaXMgdXNlZCB0byBiYWNrdXAgdXA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9uZSBv PTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBmIHRoZSBtYW55Jmx0O2JyJmd0Oz1DMj1B MCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ID1DMj08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPUEw TFNQcyBpbiBtYW55LXRvLW9uZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYmFja3VwLiZhbXA7 cXVvdDsmbHQ7ZGl2Jmd0OyZsdDticiZndDsmbHQ7L2RpdiZndDsmbHQ7ZGl2Jmd0O1RoYW5rcywm bHQ7L2RpdiZndDsmbHQ7ZGl2Jmd0O0E9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxp YSZsdDsvZGl2Jmd0OyZsdDsvZGl2Jmd0OyZsdDtkaXYgY2xhc3M9M0QmcXVvdDtnbWFpbF9leHRy YSZxdW90OyZndDsmbHQ7YnImZ3Q7Jmx0O2Rpdjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgY2xh c3M9M0QmcXVvdDtnbWFpbF9xdW90ZSZxdW90OyZndDtPbj08YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsmbmJzcDsgV2VkLCBEZWMgMTcsIDIwMTQgYXQgMzowNyBQTSwgUkZDIEVycmF0YSBT eXN0ZW0gJmx0O3NwYW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRpcj0zRCZxdW90O2x0ciZx dW90OyZndDsmYW1wO2x0OyZsdDthIGg9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJl Zj0zRCZxdW90O21haWx0bzo8YSBocmVmPSJtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9y ZyI+cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzwvYT4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IHRhcmdldD0zRCZxdW90O19ibGFuayZxdW90OyZndDtyZmMtZWRpdG9yQHJmYy1lPTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vZGl0b3Iub3JnIiB0 YXJnZXQ9Il9ibGFuayI+ZGl0b3Iub3JnPC9hPiZsdDsvYSZndDsmYW1wO2d0OyZsdDsvc3BhbiZn dDsgd3JvdGU6Jmx0O2JyJmd0OyZsdDtibG9ja3F1b3RlIGNsYXNzPTNEJnF1b3Q7Z21haWxfcXVv dGUmcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHN0eWxlPTxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyA9M0QmcXVvdDttYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYzxicj4NCiZndDsgJmd0OyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4JnF1b3Q7Jmd0O1RoZTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZm9sbD08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG93 aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM0MDkwLCZsdDticiZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmFtcDtxdW90O0Zhc3QgUmVyb3V0ZSBF eHRlbnNpb25zIHRvIFJTVlAtVEUgZm9yIExTUCBUdW5uZWxzJmFtcDtxdW90Oy4mbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFlvdSBtYXkgcmV2aWV3IHRoZSBy ZXBvcnQgYmVsb3cgYW5kIGF0OiZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmx0O2EgaHJlZj0zRCZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0i aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9M0Q0MDkwJmFt cDthbXA7ZWlkPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9l cnJhdGFfc2VhcmNoLnBocD9yZmM9M0Q0MDkwJmFtcDthbXA7ZWlkPTwvYT48YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgPTNENDIwMyZxdW90OyB0YXJnZXQ9M0QmcXVvdDtfYmxhbmsmcXVv dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTwvYT48YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgPTNENDA5MCZhbXA7YW1wO2VpZD0zRDQyMDMmbHQ7L2EmZ3Q7 Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUeXBlOiBUZWNo bmljYWwmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJlcG9ydGVkIGJ5 OiBZYWtvdiBSZWtodGVyICZhbXA7bHQ7Jmx0O2EgaHJlZj0zRCZxdW90O21haWx0bzo8YSBocmVm PSJtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQiPnlha292QGp1bmlwZXIubmV0PC9hPjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJnF1b3Q7Jmd0O3lha292QGo9PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly91bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+dW5p cGVyLm5ldDwvYT4mbHQ7L2EmZ3Q7JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgU2Vj dGlvbjogNiZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O2JyJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBPcmlnaW5hbCBUZXh0Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tJmx0O2JyJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBXaGVuZXZlciB0aGUgUExSIGhhcyBhIGJhY2t1cCBw YXRoIGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNUIHNldCZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgdGhlICZhbXA7cXVvdDtsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSZh bXA7cXVvdDsgZmxhZy4mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZs dDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O2JyJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBDb3JyZWN0ZWQgVGV4dCZsdDticiZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IFdoZW5ldmVyIHRoZSBQTFIgaGFzIGEgb25lLXRvLW9uZSBiYWNr dXAgTFNQIG9yIGJ5cGFzcyB0dW5uZWwmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNUIHNldCB0aGUgJmFtcDtxdW90O2xvY2FsIHBy b3RlY3Rpb248YnI+DQomZ3Q7ICZndDsgYXZhaWxhYmxlJmFtcDtxdW90Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgZmxhZz08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgLiZsdDticiZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IE5vdGVzJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLSZsdDti ciZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSW4gdGhlIGNhc2Ugb2YgZmFjaWxp dHktYmFzZWQgRlJSIHRoZSBQTFIgbXVzdCBzZXQgdGhlICZhbXA7cXVvdDtsb2NhbDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgcHJvdGVjdGk9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IG9uIGF2YWlsYWJsZSZhbXA7cXVvdDsgZmxhZyBpZiBpdCBoYXMgdGhlIGJ5cGFzcyB0dW5uZWwg YXZhaWxhYmxlLiZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O2Jy Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBJbnN0cnVjdGlvbnM6Jmx0O2JyJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tJmx0O2JyJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBv c3RlZCBhcyAmYW1wO3F1b3Q7UmVwb3J0ZWQmYW1wO3F1b3Q7LiBJZjxicj4NCiZndDsgJmd0OyBu ZWNlc3NhcnksPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBwbGU9PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGFzZSZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg dXNlICZhbXA7cXVvdDtSZXBseSBBbGwmYW1wO3F1b3Q7IHRvIGRpc2N1c3Mgd2hldGhlciBpdCBz aG91bGQgYmUgdmVyaWZpZWQ8YnI+DQomZ3Q7ICZndDsgb3ImbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwg dGhlIHZlcmlmeWluZyBwYXJ0eSAoSUVTRykmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJl cG9ydCwgaWY8YnI+DQomZ3Q7ICZndDsgbmVjZXNzYXJ5LiZsdDticiZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZsdDticiZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgUkZDNDA5MCAoZHJhZnQtaWV0Zi1tcGxzLXJzdnAtbHNw LWZhc3RyZXJvdXRlLTA3KSZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRpdGxlPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1D Mj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMDogRmFzdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg UmVyb3V0ZSA9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEV4dGVuc2lvbnMgdG8gUlNW UC1URSBmb3IgTFNQIFR1bm5lbHMmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IFB1YmxpY2F0aW9uIERhdGU9QzI9QTAgPUMyPUEwIDogTWF5IDIwMDUmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEF1dGhvcihzKT1DMj1BMCA9QzI9QTAgPUMyPUEw ID1DMj1BMCA9QzI9QTAgPUMyPUEwOiBQLiBQYW4sIEVkLiwgRy48YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFN3YWxsb3c9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICwgRWQuLCBBLiBB dGxhcywgRWQuJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBDYXRlZ29y eT1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwIDogUFJPUE9TRUQ8YnI+ DQomZ3Q7IFNUQU5EQVJEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBT b3VyY2U9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgOjxi cj4NCiZndDsgJmd0OyBNdWx0aXByb3RvY29sPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBMYWJl PTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBsIFN3aXRjaGluZyZsdDticiZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQXJlYT1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1B MCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgOjxicj4NCiZndDsgJmd0OyBSb3V0aW5nJmx0 O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBTdHJlYW09QzI9QTAgPUMyPUEw ID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgOiBJRVRGJmx0O2JyJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBWZXJpZnlpbmcgUGFydHk9QzI9QTAgPUMyPUEwID1D Mj1BMDogSUVTRyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O2Jy Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7L2Jsb2NrcXVvdGUmZ3Q7Jmx0 Oy9kaXYmZ3Q7Jmx0O2JyJmd0OyZsdDsvZGl2Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAtLTAwMWExMTM5N2EyYzliZGE2ZTA1 MGE2ZjMxYWUtLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7IC0tMDQ3ZDdiNWQ5OWEzM2E5MTRiMDUwYTcwMTY0ZTxicj4NCiZn dDsgJmd0OyAmZ3Q7IENvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PSZxdW90O1VURi04 JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVv dGVkLXByaW50YWJsZTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0 O2RpdiBkaXI9M0QmcXVvdDtsdHImcXVvdDsmZ3Q7WWFrb3YsJmx0O2RpdiBjbGFzcz0zRCZxdW90 O2dtYWlsX2V4dHJhJnF1b3Q7Jmd0OyZsdDticiZndDsmbHQ7ZGl2PGJyPg0KJmd0OyAmZ3Q7IGNs YXNzPTNEJnF1b3Q7Z21haWxfcT08YnI+DQomZ3Q7ICZndDsgJmd0OyB1b3RlJnF1b3Q7Jmd0O09u IFdlZCwgRGVjIDE3LCAyMDE0IGF0IDQ6MDUgUE0sIFlha292IFJla2h0ZXIgJmx0O3NwYW48YnI+ DQomZ3Q7ICZndDsgZGlyPTNEJnF1b3Q7bHRyJnF1b3Q7Jmd0OyZhbXA7bHQ7PTxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZsdDthIGhyZWY9M0QmcXVvdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnlha292 QGp1bmlwZXIubmV0Ij55YWtvdkBqdW5pcGVyLm5ldDwvYT4mcXVvdDsgdGFyZ2V0PTNEJnF1b3Q7 X2JsYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9Im1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldCI+eWFrb3ZA anVuaXBlci5uZXQ8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZsdDsvYT08YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7JmFtcDtndDsmbHQ7L3NwYW4mZ3Q7IHdyb3RlOiZsdDticiZndDsmbHQ7YmxvY2txdW90 ZSBjbGFzcz0zRCZxdW90O2dtYWlsX3F1b3RlJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IHN0eWxlPTNE JnF1b3Q7bWFyZ2luOjAgPTxicj4NCiZndDsgJmd0OyAmZ3Q7IDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgmcXVvdDsmZ3Q7QWxpYSwmbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0O3NwYW4gY2xhc3M9M0QmcXVvdDsmcXVvdDsmZ3Q7Jmx0 O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IEhpIFlha292LCZsdDticiZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmYW1wO2d0OyBDb3VsZCB5b3UgY2xhcmlmeSB5b3VyIHBvaW50IGZvciB0aGlzIGVycmF0YT89 QzI9QTAgSW4gUkZDIDQwOTAsIGluPGJyPg0KJmd0OyAmZ3Q7IHRoPTxicj4NCiZndDsgJmd0OyAm Z3Q7IGUmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgdGVybWlub2xvZ3kg aXQgc2F5czombHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDs9QzI9QTAgJmFt cDtxdW90O0JhY2t1cCBQYXRoOiBUaGUgTFNQIHRoYXQgaXMgcmVzcG9uc2libGUgZm9yIGJhY2tp bmcgdXA8YnI+DQomZ3Q7ICZndDsgb249PGJyPg0KJmd0OyAmZ3Q7ICZndDsgZSZsdDticiZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0Oz1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9 QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwPGJyPg0KJmd0OyAmZ3Q7ID1DMj1BMCA9 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPUMyPUEwID1DMj1BMCBwcm90ZWN0ZWQgTFNQLj1DMj1BMCBB IGJhY2t1cCBwYXRoIHJlZmVycyB0byBlaXRoZXIgYSZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmYW1wO2d0Oz1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1D Mj1BMCA9QzI9QTAgPUMyPUEwPGJyPg0KJmd0OyAmZ3Q7ID1DMj1BMCA9PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPUMyPUEwID1DMj1BMCBkZXRvdXIgTFNQIG9yIGEgYmFja3VwIHR1bm5lbC4mbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmFtcDtndDs9QzI9QTAgPUMyPUEwQmFja3VwIFR1bm5lbDogVGhlIExTUCB0aGF0IGlz IHVzZWQgdG8gYmFja3VwIHVwIG9uZSBvZjxicj4NCiZndDsgJmd0OyB0aD08YnI+DQomZ3Q7ICZn dDsgJmd0OyBlIG1hbnkmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDs9QzI9 QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1B MCBMU1BzPGJyPg0KJmd0OyAmZ3Q7IGluID08YnI+DQomZ3Q7ICZndDsgJmd0OyBtYW55LXRvLW9u ZSBiYWNrdXAuJmFtcDtxdW90OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0Oy9zcGFuJmd0O0luIHRoZSB0ZXJtaW5vbG9neSBp dCBhbHNvIHNheXM6Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZsdDticiZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyA9QzI9QTAgPUMyPUEwJmFtcDtxdW90O0J5cGFzcyBUdW5uZWw6IEFu IExTUCB0aGF0IGlzIHVzZWQgdG8gcHJvdGVjdCBhIHNldDxicj4NCiZndDsgJmd0OyBvZiBMPTxi cj4NCiZndDsgJmd0OyAmZ3Q7IFNQcyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyA9QzI9 QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCBwYXNzaW5nIG92ZXIgYSBjb21t b248YnI+DQomZ3Q7ICZndDsgZmFjaWxpdHkuJmFtcDtxPTxicj4NCiZndDsgJmd0OyAmZ3Q7IHVv dDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7IE15IHBvaW50IGlzIHRoYXQgKHVubGVzcyB0aGUgdGVybSAmYW1wO3F1b3Q7YnlwYXNz IHR1bm5lbCZhbXA7cXVvdDsgbWVhbnMgdGhlPGJyPg0KJmd0OyAmZ3Q7IHNhbWUmbHQ7PTxicj4N CiZndDsgJmd0OyAmZ3Q7IGJyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IGFzICZhbXA7cXVvdDti YWNrdXAgcGF0aCZhbXA7cXVvdDsgb3IgJmFtcDtxdW90O2JhY2t1cCB0dW5uZWwmYW1wO3F1b3Q7 KSBpbiBtYW55LXRvLW9uZTxicj4NCiZndDsgJmd0OyBiYWM9PGJyPg0KJmd0OyAmZ3Q7ICZndDsg a3VwJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSAmYW1wO3F1b3Q7bG9jYWwgcHJv dGVjdGlvbiBhdmFpbGFibGUmYW1wO3F1b3Q7IGZsYWcgZm9yIGEgZ2l2ZW4gcHJvdGVjdGVkPGJy Pg0KJmd0OyAmZ3Q7IExTUCZsdDtiPTxicj4NCiZndDsgJmd0OyAmZ3Q7IHImZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgTVVTVCBiZSBzZXQgd2hlbiB0aGUgUExSIGhhcyBhICpieXBhc3MqIHR1bm5l bCBmb3IgdGhhdDxicj4NCiZndDsgJmd0OyBMU1AuJmx0O2JyJmd0OyZsdDsvYmxvY2txdW90PTxi cj4NCiZndDsgJmd0OyAmZ3Q7IGUmZ3Q7Jmx0O2RpdiZndDsmbHQ7YnImZ3Q7Jmx0Oy9kaXYmZ3Q7 Jmx0O2RpdiZndDtBaCAtIG9rLj1DMj1BMCBBIGJhY2t1cCBwYXRoIHRoYXQgdXNlcyBhIGJ5cGFz czxicj4NCiZndDsgJmd0OyB0dW5uZT08YnI+DQomZ3Q7ICZndDsgJmd0OyBsIGlzIG5vdCBqdXN0 IHRoZSBieXBhc3MgdHVubmVsJmx0Oy9kaXYmZ3Q7Jmx0O2RpdiZndDtpdHNlbGYuPUMyPUEwIFRo ZXJlJmFtcDsjMzk7cyB0aGU8YnI+DQomZ3Q7ICZndDsgc3RhPTxicj4NCiZndDsgJmd0OyAmZ3Q7 IHRlIGFzc29jaWF0ZWQgZm9yIHRoZSBwcm90ZWN0ZWQgTFNQIHRoYXQgYWxzbyBuZWVkcyB0bzxi cj4NCiZndDsgJmd0OyBiZSZsdDsvZGl2Jmd0OyZsdDtkaXYmZ3Q7Y3JlYXRlZD08YnI+DQomZ3Q7 ICZndDsgJmd0OyZuYnNwOyBhbmQgaW5zdGFsbGVkLj1DMj1BMCBJbiBtb3JlIGNvbmNyZXRlIHRl cm1zLCB0aGlzIGlzIGluc3RhbGxpbmcgYW48YnI+DQomZ3Q7ICZndDsgb3V0LXNlZz08YnI+DQom Z3Q7ICZndDsgJmd0OyBtZW50IHdpdGg9QzI9QTAmbHQ7L2RpdiZndDsmbHQ7ZGl2Jmd0O3RoZSBh cHByb3ByaWF0ZSBsYWJlbCBmb3IgdGhlIHByb3RlY3RlZCBMU1AgdG88YnI+DQomZ3Q7ICZndDsg YmU9PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgdW5kZXJzdG9vZCBieSB0aGUgbWVyZ2UgcG9p bnQgYXMmbHQ7L2RpdiZndDsmbHQ7ZGl2Jmd0O3dlbGwgYXMgYW4gb3V0ZXIgbGFiZWwgZm9yPGJy Pg0KJmd0OyAmZ3Q7IHRoZSA9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgYnlwYXNzIExTUC4mbHQ7L2Rp diZndDsmbHQ7ZGl2Jmd0OyZsdDticiZndDsmbHQ7L2RpdiZndDsmbHQ7ZGl2Jmd0O1NvLCB0aGUg dGV4dCByZWZlcnMgdG8gYSBiYWNrdXA8YnI+DQomZ3Q7ICZndDsgcGF0aCBpPTxicj4NCiZndDsg Jmd0OyAmZ3Q7IG5zdGVhZCBvZiBhIGJ5cGFzcyB0dW5uZWwgYmVjYXVzZSBoYXZpbmcgdGhlJmx0 Oy9kaXYmZ3Q7Jmx0O2RpdiZndDtieXBhc3MgdHVubmVsPGJyPg0KJmd0OyAmZ3Q7IGlzbiZhbXA7 IzM9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgOTt0IHF1aXRlIHN1ZmZpY2llbnQuPUMyPUEwIERvZXMg dGhhdCBtYWtlIHNlbnNlIHRvPGJyPg0KJmd0OyAmZ3Q7IHlvdT8mbHQ7L2RpdiZndDsmbHQ7ZGl2 Jmd0OyZsdDticiZndDsmbHQ7L2RpPTxicj4NCiZndDsgJmd0OyAmZ3Q7IHYmZ3Q7Jmx0O2RpdiZn dDtSZWdhcmRzLCZsdDsvZGl2Jmd0OyZsdDtkaXYmZ3Q7QWxpYSZsdDsvZGl2Jmd0OyZsdDtkaXYm Z3Q7PUMyPUEwJmx0Oy9kaXYmZ3Q7Jmx0O2Jsb2NrcXVvdGU8YnI+DQomZ3Q7ICZndDsgY2xhc3M9 M0QmcXVvdDtnPTxicj4NCiZndDsgJmd0OyAmZ3Q7IG1haWxfcXVvdGUmcXVvdDsgc3R5bGU9M0Qm cXVvdDttYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYzxicj4NCiZndDsgJmd0 OyBzb2xpZDtwYWRkaW5nLWw9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgZWZ0OjFleCZxdW90OyZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyBZYWtvdi4mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmx0O2RpdiZndDsmbHQ7ZGl2IGNsYXNzPTNEJnF1b3Q7aDUmcXVvdDsmZ3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IFRoYW5rcywmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmFtcDtndDsgQWxpYSZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1w O2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBPbiBXZWQsIERlYyAx NywgMjAxNCBhdCAzOjA3IFBNLCBSRkMgRXJyYXRhIFN5c3RlbSAmYW1wO2x0OyZsdDticiZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmbHQ7YSBocmVmPTNEJnF1b3Q7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnIj5yZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnPC9hPiZxdW90OyZndDs8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnJm Yy1lZGl0b3JAcmZjLWVkaXRvci5vcmciPnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8L2E+PTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZsdDsvYSZndDsmYW1wO2d0OyB3cm90ZTombHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg JmFtcDtndDsgJmFtcDtndDsgVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1 Ym1pdHRlZCBmb3IgUkZDNDA5MCwmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtn dDsgJmFtcDtndDsgJmFtcDtxdW90O0Zhc3QgUmVyb3V0ZSBFeHRlbnNpb25zIHRvIFJTVlAtVEUg Zm9yIExTUDxicj4NCiZndDsgJmd0OyBUdW5uZWxzJmFtcDtxdW90Oy4mbHQ7Yj08YnI+DQomZ3Q7 ICZndDsgJmd0OyByJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0 O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0 OiZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmbHQ7YSBo cmVmPTNEJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRv ci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTNENDA5MD0iIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTNENDA5MD08L2E+ PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDthbXA7ZWlkPTNENDIwMyZxdW90OyB0YXJnZXQ9M0Qm cXVvdDtfYmxhbmsmcXVvdDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cu cmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC49IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3 dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLj08L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsg cGhwP3JmYz0zRDQwOTAmYW1wO2FtcDtlaWQ9M0Q0MjAzJmx0Oy9hJmd0OyZsdDticiZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBU eXBlOiBUZWNobmljYWwmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFt cDtndDsgUmVwb3J0ZWQgYnk6IFlha292IFJla2h0ZXIgJmFtcDtsdDsmbHQ7YSBocmVmPTNEJnF1 b3Q7bWFpbHRvOjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86eWFrb3ZAanVuaXBlci5u ZSI+eWFrb3ZAanVuaXBlci5uZTwvYT49PGJyPg0KJmd0OyAmZ3Q7ICZndDsgdCZxdW90OyZndDs8 YSBocmVmPSJtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQiPnlha292QGp1bmlwZXIubmV0PC9hPiZs dDsvYSZndDsmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAm YW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBT ZWN0aW9uOiA2Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IE9yaWdpbmFs IFRleHQmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtndDsgLS0t LS0tLS0tLS0tLSZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0 OyBXaGVuZXZlciB0aGUgUExSIGhhcyBhIGJhY2t1cCBwYXRoIGF2YWlsYWJsZSwgdGhlIFBMUiBN VVNUPGJyPg0KJmd0OyAmZ3Q7IHNldCZsdDticj08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtndDsgdGhlICZhbXA7cXVvdDtsb2NhbCBw cm90ZWN0aW9uIGF2YWlsYWJsZSZhbXA7cXVvdDsgZmxhZy4mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmFtcDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg JmFtcDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsg JmFtcDtndDsgQ29ycmVjdGVkIFRleHQmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFt cDtndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmFtcDtndDsgJmFtcDtndDsgV2hlbmV2ZXIgdGhlIFBMUiBoYXMgYSBvbmUtdG8tb25lIGJh Y2t1cCBMU1Agb3IgYnlwYXNzPGJyPg0KJmd0OyAmZ3Q7IHR1bm5lbCZsdDticiZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBhdmFpbGFibGUsIHRoZSBQTFIgTVVTVCBz ZXQgdGhlICZhbXA7cXVvdDtsb2NhbCBwcm90ZWN0aW9uPGJyPg0KJmd0OyAmZ3Q7IGF2YWlsYWJs ZSZhbXA7PTxicj4NCiZndDsgJmd0OyAmZ3Q7IHF1b3Q7IGZsYWcuJmx0O2JyJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7 Z3Q7ICZhbXA7Z3Q7IE5vdGVzJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7IC0tLS0tJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZh bXA7Z3Q7IEluIHRoZSBjYXNlIG9mIGZhY2lsaXR5LWJhc2VkIEZSUiB0aGUgUExSIG11c3Qgc2V0 IHRoZTxicj4NCiZndDsgJmd0OyAmYW1wO3F1b3Q7bG9jYT08YnI+DQomZ3Q7ICZndDsgJmd0OyBs IHByb3RlY3Rpb24mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtn dDsgYXZhaWxhYmxlJmFtcDtxdW90OyBmbGFnIGlmIGl0IGhhcyB0aGUgYnlwYXNzIHR1bm5lbCBh dmFpbGFibGUuJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IEluc3RydWN0 aW9uczombHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtndDsgLS0t LS0tLS0tLS0tLSZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0 OyBUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAmYW1wO3F1b3Q7UmVwb3J0ZWQm YW1wO3F1b3Q7LiBJZjxicj4NCiZndDsgJmd0OyBuZWNlPTxicj4NCiZndDsgJmd0OyAmZ3Q7IHNz YXJ5LCBwbGVhc2UmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtn dDsgdXNlICZhbXA7cXVvdDtSZXBseSBBbGwmYW1wO3F1b3Q7IHRvIGRpc2N1c3Mgd2hldGhlciBp dCBzaG91bGQgYmU8YnI+DQomZ3Q7ICZndDsgdmVyaWZpZT08YnI+DQomZ3Q7ICZndDsgJmd0OyBk IG9yJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IHJlamVj dGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eTxicj4N CiZndDsgJmd0OyAoSUVTRykmbHQ7PTxicj4NCiZndDsgJmd0OyAmZ3Q7IGJyJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBz dGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWY8YnI+DQomZ3Q7ICZndDsgbmVjZXNzYXJ5PTxi cj4NCiZndDsgJmd0OyAmZ3Q7IC4mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtn dDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtn dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtndDsgUkZDNDA5MCAoZHJhZnQtaWV0Zi1tcGxz LXJzdnAtbHNwLWZhc3RyZXJvdXRlLTA3KSZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm YW1wO2d0OyAmYW1wO2d0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZs dDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBUaXRsZT1DMj1B MCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTA6PGJyPg0K Jmd0OyAmZ3Q7IEZhcz08YnI+DQomZ3Q7ICZndDsgJmd0OyB0IFJlcm91dGUgRXh0ZW5zaW9ucyB0 byBSU1ZQLVRFIGZvciBMU1AgVHVubmVscyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm YW1wO2d0OyAmYW1wO2d0OyBQdWJsaWNhdGlvbiBEYXRlPUMyPUEwID1DMj1BMCA6IE1heSAyMDA1 Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IEF1dGhvcihz KT1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwOiBQLiBQYW4sPGJyPg0K Jmd0OyAmZ3Q7IEVkLiwgPTxicj4NCiZndDsgJmd0OyAmZ3Q7IEcuIFN3YWxsb3csIEVkLiwgQS4g QXRsYXMsIEVkLiZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0 OyBDYXRlZ29yeT1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwIDogUFJP UE9TRUQ8YnI+DQomZ3Q7ICZndDsgU1RBTj08YnI+DQomZ3Q7ICZndDsgJmd0OyBEQVJEJmx0O2Jy Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFNvdXJjZT1DMj1BMCA9 QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA6PGJyPg0KJmd0OyAmZ3Q7 IE11bHRpcHJvPTxicj4NCiZndDsgJmd0OyAmZ3Q7IHRvY29sIExhYmVsIFN3aXRjaGluZyZsdDti ciZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBBcmVhPUMyPUEwID1D Mj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA6PGJyPg0KJmd0 OyAmZ3Q7IFJvdT08YnI+DQomZ3Q7ICZndDsgJmd0OyB0aW5nJmx0O2JyJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFN0cmVhbT1DMj1BMCA9QzI9QTAgPUMyPUEwID1D Mj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA6PGJyPg0KJmd0OyAmZ3Q7IElFVEYmbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtndDsgVmVyaWZ5aW5nIFBhcnR5PUMy PUEwID1DMj1BMCA9QzI9QTA6IElFU0cmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFt cDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFt cDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmx0Oy9kaXYmZ3Q7Jmx0Oy9kaXYmZ3Q7JmFtcDtndDsgLS0wMDFh MTEzOTdhMmM5YmRhNmUwNTBhNmYzMWFlJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZh bXA7Z3Q7IENvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PTNEJmFtcDtxdW90O1VURi04 JmFtcDtxdW90OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBDb250ZW50 LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlJmx0O2JyJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7 ICZhbXA7bHQ7ZGl2IGRpcj0zRDNEJmFtcDtxdW90O2x0ciZhbXA7cXVvdDsmYW1wO2d0O0hpPGJy Pg0KJmd0OyAmZ3Q7IFlha292LCZhbXA7bHQ7YnImYW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0O0Nv dWxkID08YnI+DQomZ3Q7ICZndDsgJmd0OyB5b3UgY2xhcmlmeSB5b3VyIHBvaW50IGZvciB0aGlz IGVycj0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBhdGE/PTNEQzI9 M0RBMCBJbiBSRkMgNDA5MCwgaW4gdGhlIHRlcm1pbm9sb2d5IGl0PGJyPg0KJmd0OyAmZ3Q7IHNh eXM6JmFtcDtsdDticiZhbXA7Z3Q7JmFtcDthbXA7PTxicj4NCiZndDsgJmd0OyAmZ3Q7IHF1b3Q7 IEJhY2t1cCBQYXRoOiA9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsg VGhlIExTUCB0aGF0IGlzIHJlc3BvbnNpYmxlIGZvciBiYWNraW5nIHVwIG9uZSZhbXA7bHQ7YnIm YW1wO2d0Oz0zREMyPTNEQTA8YnI+DQomZ3Q7ICZndDsgPTNEPTxicj4NCiZndDsgJmd0OyAmZ3Q7 IEMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmYW1wO2d0OyA9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0z REEwID0zREMyPTNEQTA8YnI+DQomZ3Q7ICZndDsgPTNEQzI9M0RBPTxicj4NCiZndDsgJmd0OyAm Z3Q7IDAgPTNEQzI9M0RBMCA9M0RDMj0zREEwcHJvdGVjdGVkIExTUC49M0QmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgPTNEQzI9M0RBMCBBIGJhY2t1cCBwYXRoIHJlZmVy cyB0byBlaXRoZXIgYSBkZXRvdXI8YnI+DQomZ3Q7ICZndDsgTFNQJmFtcDtsdDticiZhbXA7Z3Q7 PTNEQzI9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0z RCZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyA9M0RDMj0zREEwID0zREMy PTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMDxicj4NCiZn dDsgJmd0OyA9M0RDPTxicj4NCiZndDsgJmd0OyAmZ3Q7IDI9M0RBMCA9M0RDMj0zREEwID0zREMy PTNEQTBvciBhIGJhY2t1cCB0PTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7 Z3Q7IHVubmVsLiZhbXA7bHQ7YnImYW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0Oz0zREMyPTNEQTAg QmFja3VwIFR1bm5lbDogVGhlIExTUCB0aGF0IGlzPGJyPg0KJmd0OyAmZ3Q7IHVzPTxicj4NCiZn dDsgJmd0OyAmZ3Q7IGVkIHRvIGJhY2t1cCB1cCBvbmUgbz0zRCZsdDticiZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmYW1wO2d0OyBmIHRoZSBtYW55JmFtcDtsdDticiZhbXA7Z3Q7PTNEQzI9M0RB MCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMDxicj4NCiZndDsgJmd0OyA9M0RDMj08 YnI+DQomZ3Q7ICZndDsgJmd0OyA9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RB MCA9M0RDMj0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyA9M0RBMExT UHMgaW4gbWFueS10by1vbmU8YnI+DQomZ3Q7ICZndDsgYmFja3VwLiZhbXA7YW1wO3F1b3Q7JmFt cDtsdDtkaXYmYW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZhbXA7bHQ7L2RpPTxicj4NCiZndDsg Jmd0OyAmZ3Q7IHYmYW1wO2d0OyZhbXA7bHQ7ZGl2JmFtcDtndDtUaGFua3MsJmFtcDtsdDsvZGl2 JmFtcDtndDsmYW1wO2x0O2RpdiZhbXA7Z3Q7QT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmYW1wO2d0OyBsaWEmYW1wO2x0Oy9kaXYmYW1wO2d0OyZhbXA7bHQ7L2RpdiZhbXA7Z3Q7 JmFtcDtsdDtkaXY8YnI+DQomZ3Q7ICZndDsgY2xhc3M9M0QzRCZhbXA7cXVvdDtnbWFpbF9leHRy YSZhbXA7cXVvdDsmYW1wO2c9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgdDsmYW1wO2x0O2JyJmFtcDtn dDsmYW1wO2x0O2RpdiBjbGFzcz0zRDNEJmFtcDtxdW90O2dtYWlsX3F1b3RlJmFtcDtxdW90OyZh bXA7Z3Q7T249M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDs9QzI9QTAg V2VkLCBEZWMgMTcsIDIwMTQgYXQgMzowNyBQTSwgUkZDIEVycmF0YSBTeXN0ZW0gJmFtcDtsdDtz cGFuPGJyPg0KJmd0OyAmZ3Q7IGRpcj0zRDM9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRCZhbXA7cXVv dDtsdHImYW1wO3F1b3Q7JmFtcDtndDsmYW1wO2FtcDtsdDsmYW1wO2x0O2EgaD0zRCZsdDticiZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyByZWY9M0QzRCZhbXA7cXVvdDttYWlsdG86 Jmx0O2EgaHJlZj0zRCZxdW90O21haWx0bzo8YSBocmVmPSJtYWlsdG86cmZjLWVkaXRvckByZmMt ZWRpdG9yLm9yZyI+cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsg JnF1b3Q7Jmd0O3JmYy09PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOmVkaXRv ckByZmMtZWRpdG9yLm9yZyI+ZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9hPiZsdDsvYSZndDsmYW1w O3F1b3Q7PGJyPg0KJmd0OyAmZ3Q7IHRhcmdldD0zRDNEJmFtcDtxdW90O19ibGFuayZhbXA7cXVv dDsmYW1wO2d0O3JmYy1lZGl0b3I9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQHJmYy1lPTNEJmx0O2Jy Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZsdDthIGhyZWY9M0QmcXVvdDs8YSBo cmVmPSJodHRwOi8vZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RpdG9yLm9yZzwv YT4mcXVvdDsgdGFyZ2V0PTNEJnF1b3Q7X2JsYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly9k aXRvci5vcmciIHRhcmdldD0iX2JsYW5rIj5kaXRvci5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZs dDsvYSZndDsmYW1wO2x0Oy9hJmFtcDtndDs9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDthbXA7 Z3Q7JmFtcDtsdDsvc3BhbiZhbXA7Z3Q7IHdyb3RlOiZhbXA7bHQ7YnImYW1wO2d0OyZhbXA7bHQ7 YmxvY2txdW90ZTxicj4NCiZndDsgJmd0OyBjbGFzcz0zRDNEJmFtcDtxdW90O2dtYWlsXz08YnI+ DQomZ3Q7ICZndDsgJmd0OyBxdW90ZSZhbXA7cXVvdDsgc3R5bGU9M0QmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgPTNEM0QmYW1wO3F1b3Q7bWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2M8YnI+DQomZ3Q7ICZndDsgc29saWQ7cGFkZGluZy1sZWZ0OjE9 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgZXgmYW1wO3F1b3Q7JmFtcDtndDtUaGUgZm9sbD0zRCZsdDti ciZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1 Ym1pdHRlZCBmb3IgUkZDNDA5MCwmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDthbXA7cXVvdDtGYXN0IFJlcm91dGUgRXh0ZW5zaW9u cyB0byBSU1ZQLVRFIGZvciBMU1A8YnI+DQomZ3Q7ICZndDsgVHVubmVscyZhbXA7YW1wO3F1b3Q7 PTxicj4NCiZndDsgJmd0OyAmZ3Q7IC4mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZh bXA7Z3Q7IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0OiZhbXA7bHQ7YnIm YW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2x0O2Eg aHJlZj0zRDNEJmFtcDtxdW90OyZsdDthIGhyZWY9M0QmcXVvdDs8YnI+DQomZ3Q7ICZndDsgPGEg aHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmM9IiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmM9PC9hPjxicj4NCiZn dDsgJmd0OyAmZ3Q7IGgucGhwP3JmYz0zRDNENDA5MCZhbXA7YW1wO2FtcDtlaWQ9M0QmcXVvdDsg dGFyZ2V0PTNEJnF1b3Q7X2JsYW5rJnF1b3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJo dHRwOi8vd3d3LnJmYy1lZGl0b3IuIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5yZmMtZWRp dG9yLjwvYT49PGJyPg0KJmd0OyAmZ3Q7ICZndDsgb3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0z RDNENDA5MCZhbXA7YW1wO2FtcDtlaWQ9M0QmbHQ7L2EmZ3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZhbXA7Z3Q7ID0zRDNENDIwMyZhbXA7cXVvdDsgdGFyZ2V0PTNEM0QmYW1wO3F1 b3Q7X2JsYW5rJmFtcDtxdW90OyZhbXA7Z3Q7Jmx0O2EgaHJlZj0zRCZxdW90Ozxicj4NCiZndDsg Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dzwvYT49 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgLjxhIGhyZWY9Imh0dHA6Ly9yZmMtZWRpdG9yLm9yZy9lcnJh dGFfc2VhcmNoLnBocD9yZmM9M0QiIHRhcmdldD0iX2JsYW5rIj5yZmMtZWRpdG9yLm9yZy9lcnJh dGFfc2VhcmNoLnBocD9yZmM9M0Q8L2E+JnF1b3Q7IHRhcmdldD0zRCZxdW90O19ibGFuayZxdW90 OyZndDs8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL3d3dy5yZmMtPC9hPj08YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJo dHRwOi8vZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9M0QiIHRhcmdldD0iX2JsYW5r Ij5lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRDwvYT4mbHQ7L2EmZ3Q7Jmx0O2Jy Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ID0zRDNENDA5MCZhbXA7YW1wO2FtcDtl aWQ9M0QzRDQyMDMmYW1wO2x0Oy9hJmFtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7ICZhbXA7Z3Q7IFR5cGU6IFRlY2huaWNhbCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBSZXBvcnRlZCBieTogWWFrb3YgUmVraHRlciAm YW1wO2FtcDtsdDsmYW1wO2x0O2EgaHJlZj0zRDNEJmFtcDtxdW90O21haWx0bzombHQ7YTxicj4N CiZndDsgJmd0OyBocmVmPTxicj4NCiZndDsgJmd0OyAmZ3Q7ID0zRCZxdW90O21haWx0bzo8YSBo cmVmPSJtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQiPnlha292QGp1bmlwZXIubmV0PC9hPiZxdW90 OyZndDs8YSBocmVmPSJtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQiPnlha292QGp1bmlwZXIubmV0 PC9hPiZsdDsvYSZndDsmYW1wO3F1b3Q7JmFtcDtndDt5YWtvdkBqPGJyPg0KJmd0OyAmZ3Q7ID0z RCZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmbHQ7YSBocmVmPTNEJnF1 b3Q7PGEgaHJlZj0iaHR0cDovL3VuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdW5p cGVyLm5ldDwvYT4mcXVvdDsgdGFyZ2V0PTNEJnF1b3Q7X2JsYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9 Imh0dHA6Ly91bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+dW5pcGVyLm5ldDwvYT48YnI+DQom Z3Q7ICZndDsgJmx0Oy9hJmd0OyZhbXA7bHQ7L2EmYW1wO2c9PGJyPg0KJmd0OyAmZ3Q7ICZndDsg dDsmYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZhbXA7Z3Q7IFNlY3Rpb246IDYmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IE9yaWdpbmFsIFRleHQmYW1wO2x0O2JyJmFtcDtn dDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0tLSZh bXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBX aGVuZXZlciB0aGUgUExSIGhhcyBhIGJhY2t1cCBwYXRoIGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNU PGJyPg0KJmd0OyAmZ3Q7IHNldCZhbXA7bHQ7YnImYW1wO2c9PGJyPg0KJmd0OyAmZ3Q7ICZndDsg dDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgdGhlICZhbXA7YW1wO3F1 b3Q7bG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUmYW1wO2FtcDtxdW90Ozxicj4NCiZndDsgJmd0 OyBmbGFnLiZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm YW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg JmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZhbXA7Z3Q7IENvcnJlY3RlZCBUZXh0JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0tJmFtcDtsdDticiZhbXA7Z3Q7 Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IFdoZW5ldmVyIHRoZSBQTFIg aGFzIGEgb25lLXRvLW9uZSBiYWNrdXAgTFNQIG9yIGJ5cGFzczxicj4NCiZndDsgJmd0OyB0dW5u ZWwmYW1wO2x0O2JyJmFtcDtndD08YnI+DQomZ3Q7ICZndDsgJmd0OyA7Jmx0O2JyJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNUIHNldCB0aGUg JmFtcDthbXA7cXVvdDtsb2NhbCBwcm90ZWN0aW9uPGJyPg0KJmd0OyAmZ3Q7IGF2YWlsYWJsZSZh bXA7YT08YnI+DQomZ3Q7ICZndDsgJmd0OyBtcDtxdW90OyBmbGFnPTNEJmx0O2JyJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IC4mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBOb3RlcyZhbXA7bHQ7YnImYW1wO2d0OyZsdDti ciZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAtLS0tLSZhbXA7bHQ7YnImYW1wO2d0 OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBJbiB0aGUgY2FzZSBvZiBm YWNpbGl0eS1iYXNlZCBGUlIgdGhlIFBMUiBtdXN0IHNldCB0aGU8YnI+DQomZ3Q7ICZndDsgJmFt cDthbXA7cXVvdDtsb2NhbD08YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyBwcm90ZWN0aT0zRCZs dDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBvbiBhdmFpbGFibGUmYW1wO2Ft cDtxdW90OyBmbGFnIGlmIGl0IGhhcyB0aGUgYnlwYXNzIHR1bm5lbDxicj4NCiZndDsgJmd0OyBh dmFpbGFibGUuJmFtcDtsdDs9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgYnImYW1wO2d0OyZsdDticiZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgSW5zdHJ1Y3Rpb25zOiZhbXA7bHQ7YnIm YW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAtLS0tLS0tLS0t LS0tJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7 Z3Q7IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICZhbXA7YW1wO3F1b3Q7UmVw b3J0ZWQmYW1wO2FtcDtxdW90Oy48YnI+DQomZ3Q7ICZndDsgSWYgbj08YnI+DQomZ3Q7ICZndDsg Jmd0OyBlY2Vzc2FyeSwgcGxlPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7 Z3Q7IGFzZSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm YW1wO2d0OyB1c2UgJmFtcDthbXA7cXVvdDtSZXBseSBBbGwmYW1wO2FtcDtxdW90OyB0byBkaXNj dXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlPGJyPg0KJmd0OyAmZ3Q7IHZlcmk9PGJyPg0KJmd0OyAm Z3Q7ICZndDsgZmllZCBvciZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmYW1wO2d0OyByZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRo ZSB2ZXJpZnlpbmcgcGFydHk8YnI+DQomZ3Q7ICZndDsgKElFU0cpJmFtcDtsdDticj08YnI+DQom Z3Q7ICZndDsgJmd0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1w O2d0OyBjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQs IGlmPGJyPg0KJmd0OyAmZ3Q7IG5lY2Vzc2FyeS4mYW1wO2x0Oz08YnI+DQomZ3Q7ICZndDsgJmd0 OyBiciZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7 bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZhbXA7bHQ7YnImYW1wO2d0OyZsdDti ciZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBSRkM0MDkwIChkcmFmdC1pZXRmLW1w bHMtcnN2cC1sc3AtZmFzdHJlcm91dGUtMDcpJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZhbXA7Z3Q7IFRpdGxlPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RB MCA9M0RDMj0zREEwPGJyPg0KJmd0OyAmZ3Q7ID0zREMyPTNEQTA9PGJyPg0KJmd0OyAmZ3Q7ICZn dDsmbmJzcDsgPTNEQzI9M0RBMCA9M0RDMj0zREEwOiBGYXN0IFJlcm91dGUgPTNEJmx0O2JyJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IEV4dGVuc2lvbnMgdG8gUlNWUC1URSBmb3Ig TFNQIFR1bm5lbHMmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmFtcDtndDsgUHVibGljYXRpb24gRGF0ZT0zREMyPTNEQTAgPTNEQzI9M0RBMCA6IE1heSAy MDA1JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7 Z3Q7IEF1dGhvcihzKT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAg PTNEQzI9M0RBMDxicj4NCiZndDsgJmd0OyA9M0RDMj08YnI+DQomZ3Q7ICZndDsgJmd0OyA9M0RB MDogUC4gUGFuLCBFZC4sIEcuIFN3YWxsb3c9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmFtcDtndDsgLCBFZC4sIEEuIEF0bGFzLCBFZC4mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgQ2F0ZWdvcnk9M0RDMj0zREEwID0zREMy PTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTA8YnI+DQomZ3Q7ICZndDsgPTNE QzI9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPTNEQTAgOiBQUk9QT1NFRCBTVEFOREFSRCZhbXA7bHQ7 YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyBTb3VyY2U9 M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTA8YnI+ DQomZ3Q7ICZndDsgPTNEQzI9M0RBPTxicj4NCiZndDsgJmd0OyAmZ3Q7IDAgPTNEQzI9M0RBMCA6 IE11bHRpcHJvdG9jb2wgTGFiZT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1w O2d0OyBsIFN3aXRjaGluZyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmYW1wO2d0OyBBcmVhPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNE QzI9M0RBMCA9M0RDMj0zREEwPGJyPg0KJmd0OyAmZ3Q7ID0zREMyPTNEQTAgPTxicj4NCiZndDsg Jmd0OyAmZ3Q7ID0zREMyPTNEQTAgPTNEQzI9M0RBMCA6IFJvdXRpbmcmYW1wO2x0O2JyJmFtcDtn dDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmFtcDtndDsgU3RyZWFtPTNEQzI9M0RB MCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwPGJyPg0KJmd0OyAm Z3Q7ID0zREMyPTNEQT08YnI+DQomZ3Q7ICZndDsgJmd0OyAwID0zREMyPTNEQTAgOiBJRVRGJmFt cDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IFZl cmlmeWluZyBQYXJ0eT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwOiBJRVNHJmFtcDts dDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7ICZhbXA7 bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmYW1wO2d0OyAmYW1w O2x0Oy9ibG9ja3F1b3RlJmFtcDtndDsmYW1wO2x0Oy9kaXYmYW1wO2d0OyZhbXA7bHQ7YnImYW1w O2d0OyZhbXA7bHQ7L2RpdiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZh bXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZhbXA7Z3Q7IC0tMDAxYTExMzk3 YTJjOWJkYTZlMDUwYTZmMzFhZS0tJmx0O2JyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZsdDsv YmxvY2txdW90ZSZndDsmbHQ7L2RpdiZndDsmbHQ7YnImZ3Q7Jmx0Oy9kaXYmZ3Q7Jmx0Oy9kaXYm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLTA0N2Q3YjVkOTlh MzNhOTE0YjA1MGE3MDE2NGUtLTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IC0tMDAxYTExYzFl OWVlNDBmZDE5MDUwYTcwNjhjOTxicj4NCiZndDsgQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNo YXJzZXQ9JnF1b3Q7VVRGLTgmcXVvdDs8YnI+DQomZ3Q7IENvbnRlbnQtVHJhbnNmZXItRW5jb2Rp bmc6IHF1b3RlZC1wcmludGFibGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbHQ7ZGl2IGRpcj0zRCZx dW90O2x0ciZxdW90OyZndDtZYWtvdiwmbHQ7ZGl2IGNsYXNzPTNEJnF1b3Q7Z21haWxfZXh0cmEm cXVvdDsmZ3Q7Jmx0O2JyJmd0OyZsdDtkaXYgY2xhc3M9M0QmcXVvdDtnbWFpbF9xPTxicj4NCiZn dDsgdW90ZSZxdW90OyZndDtPbiBXZWQsIERlYyAxNywgMjAxNCBhdCA0OjQxIFBNLCBZYWtvdiBS ZWtodGVyICZsdDtzcGFuIGRpcj0zRCZxdW90O2x0ciZxdW90OyZndDsmYW1wO2x0Oz08YnI+DQom Z3Q7ICZsdDthIGhyZWY9M0QmcXVvdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnlha292QGp1bmlw ZXIubmV0Ij55YWtvdkBqdW5pcGVyLm5ldDwvYT4mcXVvdDsgdGFyZ2V0PTNEJnF1b3Q7X2JsYW5r JnF1b3Q7Jmd0OzxhIGhyZWY9Im1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldCI+eWFrb3ZAanVuaXBl ci5uZXQ8L2E+Jmx0Oy9hPTxicj4NCiZndDsgJmd0OyZhbXA7Z3Q7Jmx0Oy9zcGFuJmd0OyB3cm90 ZTombHQ7YnImZ3Q7Jmx0O2Jsb2NrcXVvdGUgY2xhc3M9M0QmcXVvdDtnbWFpbF9xdW90ZSZxdW90 OyBzdHlsZT0zRCZxdW90O21hcmdpbjowID08YnI+DQomZ3Q7IDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgmcXVvdDsmZ3Q7QWxpYSwmbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmbHQ7c3BhbiBjbGFzcz0zRCZxdW90OyZxdW90OyZndDsmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmYW1wO2d0OyBZYWtvdiwmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDQ6MDUgUE0s IFlha292IFJla2h0ZXIgJmFtcDtsdDsmbHQ7YSBocmVmPTNEJnF1b3Q7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzp5Ij55PC9hPj08YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpha292QGp1bmlwZXIu bmV0Ij5ha292QGp1bmlwZXIubmV0PC9hPiZxdW90OyZndDs8YSBocmVmPSJtYWlsdG86eWFrb3ZA anVuaXBlci5uZXQiPnlha292QGp1bmlwZXIubmV0PC9hPiZsdDsvYSZndDsmYW1wO2d0OyB3cm90 ZTombHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ICZhbXA7Z3Q7IEFsaWEsJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsm bHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBIaSBZYWtvdiwm bHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyZsdDticiZndDs8 YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IENvdWxkIHlvdSBjbGFyaWZ5IHlv dXIgcG9pbnQgZm9yIHRoaXMgZXJyYXRhPz1DMj1BMCBJbiBSRkMgND08YnI+DQomZ3Q7IDA5MCwg aW4gdGhlJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgdGVy bWlub2xvZ3kgaXQgc2F5czombHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAm YW1wO2d0Oz1DMj1BMCAmYW1wO3F1b3Q7QmFja3VwIFBhdGg6IFRoZSBMU1AgdGhhdCBpcyByZXNw b25zaWJsZSBmb3IgYmFjPTxicj4NCiZndDsga2luZyB1cCBvbmUmbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0Oz1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9 QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPTxicj4NCiZndDsgPUEwID1DMj1BMCA9QzI9 QTAgPUMyPUEwIHByb3RlY3RlZCBMU1AuPUMyPUEwIEEgYmFja3VwIHBhdGggcmVmZXJzIHRvIGVp dGhlPTxicj4NCiZndDsgciBhJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsg JmFtcDtndDs9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAg PUMyPUEwID1DMj08YnI+DQomZ3Q7ID1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCBkZXRvdXIgTFNQ IG9yIGEgYmFja3VwIHR1bm5lbC4mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0 OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 PUMyPUEwID1DMj1BMEJhY2t1cCBUdW5uZWw6IFRoZSBMU1AgdGhhdCBpcyB1c2VkIHRvIGJhY2t1 cCB1cD08YnI+DQomZ3Q7Jm5ic3A7IG9uZSBvZiB0aGUgbWFueSZsdDticiZndDs8YnI+DQomZ3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7PUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1D Mj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9PGJyPg0KJmd0OyA9QTAgTFNQcyBpbiBtYW55 LXRvLW9uZSBiYWNrdXAuJmFtcDtxdW90OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZh bXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgSW4gdGhlIHRlcm1p bm9sb2d5IGl0IGFsc28gc2F5czombHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0 OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7PUMyPUEwID1DMj1BMCAmYW1w O3F1b3Q7QnlwYXNzIFR1bm5lbDogQW4gTFNQIHRoYXQgaXMgdXNlZCB0byBwcm90ZWN0ID08YnI+ DQomZ3Q7IGEgc2V0IG9mIExTUHMmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0 Oz1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMHBhc3Npbmcg b3ZlciBhIGNvbT08YnI+DQomZ3Q7IG1vbiBmYWNpbGl0eS4mYW1wO3F1b3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAm YW1wO2d0OyBNeSBwb2ludCBpcyB0aGF0ICh1bmxlc3MgdGhlIHRlcm0gJmFtcDtxdW90O2J5cGFz cyB0dW5uZWwmYW1wO3F1b3Q7IG1lYW5zPTxicj4NCiZndDsmbmJzcDsgdGhlIHNhbWUmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBhcyAmYW1wO3F1b3Q7YmFja3VwIHBhdGgm YW1wO3F1b3Q7IG9yICZhbXA7cXVvdDtiYWNrdXAgdHVubmVsJmFtcDtxdW90OykgaW4gbWFueS09 PGJyPg0KJmd0OyB0by1vbmUgYmFja3VwJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFt cDtndDsgdGhlICZhbXA7cXVvdDtsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSZhbXA7cXVvdDsg ZmxhZyBmb3IgYSBnaXZlbiBwcm90ZT08YnI+DQomZ3Q7IGN0ZWQgTFNQJmx0O2JyJmd0Ozxicj4N CiZndDsgJmFtcDtndDsgJmFtcDtndDsgTVVTVCBiZSBzZXQgd2hlbiB0aGUgUExSIGhhcyBhICpi eXBhc3MqIHR1bm5lbCBmb3IgdGhhdCBMU1AuJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7 ICZhbXA7Z3Q7IEFoIC0gb2suPUMyPUEwIEEgYmFja3VwIHBhdGggdGhhdCB1c2VzIGEgYnlwYXNz IHR1bm5lbCBpcyBub3QganVzdCB0aGU9PGJyPg0KJmd0OyZuYnNwOyBieXBhc3MmbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmYW1wO2d0OyB0dW5uZWwgaXRzZWxmLiZsdDticiZndDs8YnI+DQomZ3Q7ICZs dDticiZndDs8YnI+DQomZ3Q7ICZsdDsvc3BhbiZndDtDb3JyZWN0LiZsdDticiZndDs8YnI+DQom Z3Q7ICZsdDtzcGFuIGNsYXNzPTNEJnF1b3Q7JnF1b3Q7Jmd0OyZsdDticiZndDs8YnI+DQomZ3Q7 ICZhbXA7Z3Q7IFRoZXJlJmFtcDsjMzk7cyB0aGUgc3RhdGUgYXNzb2NpYXRlZCBmb3IgdGhlIHBy b3RlY3RlZCBMU1AgdGhhdCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IGFsc28gbmVlZHMg dG8gYmUgY3JlYXRlZCBhbmQgaW5zdGFsbGVkLj1DMj1BMCBJbiBtb3JlIGNvbmNyZXRlIHRlcm1z LCA9PGJyPg0KJmd0OyB0aGlzJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgaXMgaW5zdGFs bGluZyBhbiBvdXQtc2VnbWVudCB3aXRoIHRoZSBhcHByb3ByaWF0ZSBsYWJlbCBmb3IgdGhlIHBy b3RlYz08YnI+DQomZ3Q7IHRlZCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IExTUCB0byBi ZSB1bmRlcnN0b29kIGJ5IHRoZSBtZXJnZSBwb2ludCBhcyZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7IHdlbGwgYXMgYW4gb3V0ZXIgbGFiZWwgZm9yIHRoZSBieXBhc3MgTFNQLiZsdDticiZn dDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgU28sIHRo ZSB0ZXh0IHJlZmVycyB0byBhIGJhY2t1cCBwYXRoIGluc3RlYWQgb2YgYSBieXBhc3MgdHVubmVs IGJlY2F1cz08YnI+DQomZ3Q7IGUmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyBoYXZpbmcg dGhlIGJ5cGFzcyB0dW5uZWwgaXNuJmFtcDsjMzk7dCBxdWl0ZSBzdWZmaWNpZW50LiZsdDticiZn dDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IERvZXMgdGhhdCBtYWtlIHNlbnNlIHRvIHlvdT8mbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmbHQ7L3NwYW4mZ3Q7VGhlIGN1cnJl bnQgdGV4dCBpcyBpbmNvcnJlY3QuIFRoaXMgaXMgYmVjYXVzZSBhIFBMUiBtYXkgc2lnbmFsIGEm bHQ7YnI9PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyBiYWNrdXAgcGF0aCBhdCB0aGUgdGltZSBv ZiBmYWlsdXJlLiBZZXQsIG9uZSBzaG91bGQgbm90IHdhaXQgZm9yJmx0O2JyJmd0Ozxicj4NCiZn dDsgdGhlIGZhaWx1cmUgdG8gc2V0IHRoZSAmYW1wO3F1b3Q7bG9jYWwgcHJvdGVjdGlvbiBhdmFp bGFibGUmYW1wO3F1b3Q7IGZsYWcuIFRoZSBQTFI9PGJyPg0KJmd0OyAmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyBzaG91bGQgc2V0IHRoaXMgZmxhZyBhcyBzb29uIGFzIGl0IGhhcyBhICpieXBhc3MqIHR1 bm5lbC4mbHQ7YnImZ3Q7Jmx0Oy9ibG9ja3F1b3RlJmd0OyZsdDs9PGJyPg0KJmd0OyBkaXYmZ3Q7 Jmx0O2JyJmd0OyZsdDsvZGl2Jmd0OyZsdDtkaXYmZ3Q7VGhlIGJhY2t1cCBwYXRoIGlzIGNyZWF0 ZWQgYnkgdGhlIFBMUiBiZWZvcmUgdGhlIGZhaWx1cmU9PGJyPg0KJmd0OyZuYnNwOyBhbmQgdGh1 cywgYmVmb3JlIHRoZSZsdDsvZGl2Jmd0OyZsdDtkaXYmZ3Q7YXNzb2NpYXRlZCBzaWduYWxpbmcu PUMyPUEwIE9uY2UgdGhlIFBMUiBoYT08YnI+DQomZ3Q7IHMgZG9uZSB0aGUgd29yayB0byBjcmVh dGUgYSBiYWNrdXAgcGF0aCB1c2luZyZsdDsvZGl2Jmd0OyZsdDtkaXYmZ3Q7YW4gZXhpc3Rpbmcg YnlwYXNzID08YnI+DQomZ3Q7IHR1bm5lbCAtIHdoaWNoIGlzIGludGVybmFsIHdvcmsgLSB0aGVu IHRoZSBQTFIgc2hvdWxkIHNldCZsdDsvZGl2Jmd0OyZsdDtkaXYmZ3Q7dGhlICZhbXA7cXU9PGJy Pg0KJmd0OyBvdDtsb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSZhbXA7cXVvdDsgZmxhZy4gPUMy PUEwJmx0Oy9kaXYmZ3Q7Jmx0O2RpdiZndDsmbHQ7YnImZ3Q7Jmx0Oy9kaXYmZ3Q7Jmx0O2RpdiZn dDtBPTxicj4NCiZndDsgbGlhPUMyPUEwJmx0O2JyJmd0OyZsdDsvZGl2Jmd0OyZsdDtkaXYmZ3Q7 Jmx0O2JyJmd0OyZsdDsvZGl2Jmd0OyZsdDtkaXYmZ3Q7PUMyPUEwJmx0Oy9kaXYmZ3Q7Jmx0O2Js b2NrcXVvdGUgY2xhc3M9M0QmcXVvdDtnbWE9PGJyPg0KJmd0OyBpbF9xdW90ZSZxdW90OyBzdHls ZT0zRCZxdW90O21hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmPTxicj4NCiZndDsgdDoxZXgmcXVvdDsmZ3Q7PGJyPg0KJmd0OyBZYWtvdi4mbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmbHQ7ZGl2Jmd0OyZsdDtkaXYgY2xhc3M9M0QmcXVvdDtoNSZxdW90 OyZndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7IFJlZ2FyZHMsJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgQWxpYSZsdDticiZn dDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBZYWtvdi4mbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7IFRoYW5rcywmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAm YW1wO2d0OyBBbGlhJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtn dDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBPbiBXZWQs IERlYyAxNywgMjAxNCBhdCAzOjA3IFBNLCBSRkMgRXJyYXRhIFN5c3RlbSAmYW1wO2x0OyZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZsdDthIGhyZWY9M0Qm cXVvdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmciPnJm Yy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8L2E+JnF1b3Q7Jmd0O3JmYy1lZGl0b3JAcmZjLT08YnI+ DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9lZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZWRpdG9y Lm9yZzwvYT4mbHQ7L2EmZ3Q7JmFtcDtndDsgd3JvdGU6Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFt cDtndDsgJmFtcDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1w O2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJl ZW4gc3VibWl0dGVkIGZvciBSRkM0PTxicj4NCiZndDsgMDkwLCZsdDticiZndDs8YnI+DQomZ3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7cXVvdDtGYXN0IFJlcm91 dGUgRXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBMU1AgVHVubmVsPTxicj4NCiZndDsgcyZhbXA7 cXVvdDsuJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFt cDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1w O2d0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZsdDticiZndDs8YnI+ DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFlvdSBtYXkgcmV2aWV3 IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0OiZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZsdDthIGhyZWY9M0QmcXVvdDs8YSBocmVmPSJodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwPz0iIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwPz08L2E+PGJyPg0K Jmd0OyByZmM9M0Q0MDkwJmFtcDthbXA7ZWlkPTNENDIwMyZxdW90OyB0YXJnZXQ9M0QmcXVvdDtf YmxhbmsmcXVvdDsmZ3Q7PGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhPSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYT08L2E+PGJyPg0K Jmd0OyB0YV9zZWFyY2gucGhwP3JmYz0zRDQwOTAmYW1wO2FtcDtlaWQ9M0Q0MjAzJmx0Oy9hJmd0 OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBUeXBlOiBUZWNobmljYWwmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBSZXBv cnRlZCBieTogWWFrb3YgUmVraHRlciAmYW1wO2x0OyZsdDthIGhyZWY9M0QmcXVvdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOnlha292QCI+eWFrb3ZAPC9hPj08YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHA6Ly9qdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmp1bmlwZXIubmV0PC9hPiZxdW90OyZn dDs8YSBocmVmPSJtYWlsdG86eWFrb3ZAanVuaXBlci5uZXQiPnlha292QGp1bmlwZXIubmV0PC9h PiZsdDsvYSZndDsmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsg JmFtcDtndDsgJmFtcDtndDsgU2VjdGlvbjogNiZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgT3JpZ2luYWwgVGV4dCZsdDticiZndDs8YnI+DQom Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0mbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBXaGVu ZXZlciB0aGUgUExSIGhhcyBhIGJhY2t1cCBwYXRoIGF2YWlsYWJsZSwgdGhlIFBMUiBNPTxicj4N CiZndDsgVVNUIHNldCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7 Z3Q7ICZhbXA7Z3Q7IHRoZSAmYW1wO3F1b3Q7bG9jYWwgcHJvdGVjdGlvbiBhdmFpbGFibGUmYW1w O3F1b3Q7IGZsYWcuJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtn dDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0 OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7IENvcnJlY3RlZCBUZXh0Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFt cDtndDsgJmFtcDtndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBXaGVuZXZlciB0aGUgUExSIGhh cyBhIG9uZS10by1vbmUgYmFja3VwIExTUCBvciBieXBhc3MgPTxicj4NCiZndDsgdHVubmVsJmx0 O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgYXZh aWxhYmxlLCB0aGUgUExSIE1VU1Qgc2V0IHRoZSAmYW1wO3F1b3Q7bG9jYWwgcHJvdGVjdGlvbiA9 PGJyPg0KJmd0OyBhdmFpbGFibGUmYW1wO3F1b3Q7IGZsYWcuJmx0O2JyJmd0Ozxicj4NCiZndDsg JmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IE5vdGVzJmx0O2JyJmd0Ozxicj4NCiZn dDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgLS0tLS0mbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBJbiB0aGUgY2FzZSBv ZiBmYWNpbGl0eS1iYXNlZCBGUlIgdGhlIFBMUiBtdXN0IHNldCB0aGUgPTxicj4NCiZndDsgJmFt cDtxdW90O2xvY2FsJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgcHJvdGVj dGlvbiZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7 Z3Q7IGF2YWlsYWJsZSZhbXA7cXVvdDsgZmxhZyBpZiBpdCBoYXMgdGhlIGJ5cGFzcyB0dW5uZWwg YXZhaWxhPTxicj4NCiZndDsgYmxlLiZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7 Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtn dDsgJmFtcDtndDsgJmFtcDtndDsgSW5zdHJ1Y3Rpb25zOiZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0mbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBUaGlzIGVycmF0 dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAmYW1wO3F1b3Q7UmVwb3J0ZWQmYW1wO3F1b3Q9PGJy Pg0KJmd0OyA7LiBJZiBuZWNlc3NhcnksIHBsZWFzZSZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IHVzZSAmYW1wO3F1b3Q7UmVwbHkgQWxsJmFt cDtxdW90OyB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkID08YnI+DQomZ3Q7IGJlIHZlcmlm aWVkIG9yJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFt cDtndDsgcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5n IHBhcj08YnI+DQomZ3Q7IHR5IChJRVNHKSZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMg YW5kIGVkaXQgdGhlIHJlcG9ydCwgaWY9PGJyPg0KJmd0OyZuYnNwOyBuZWNlc3NhcnkuJmx0O2Jy Jmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFJGQzQwOTAgKGRyYWZ0LWlldGYtbXBscy1y c3ZwLWxzcC1mYXN0cmVyb3V0ZS0wNykmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1w O2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7 Z3Q7IFRpdGxlPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEw ID08YnI+DQomZ3Q7ID1DMj1BMDogRmFzdCBSZXJvdXRlIEV4dGVuc2lvbnMgdG8gUlNWUC1URSBm b3IgTFNQJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgVHVubmVscyZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFB1Ymxp Y2F0aW9uIERhdGU9QzI9QTAgPUMyPUEwIDogTWF5IDIwMDUmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBBdXRob3Iocyk9QzI9QTAgPUMyPUEw ID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMDogUC4gPTxicj4NCiZndDsgUGFuLCBFZC4sIEcu IFN3YWxsb3csIEVkLiwgQS4gQXRsYXMsIEVkLiZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IENhdGVnb3J5PUMyPUEwID1DMj1BMCA9QzI9QTAg PUMyPUEwID1DMj1BMCA9QzI9QTAgOiBQUk89PGJyPg0KJmd0OyBQT1NFRCBTVEFOREFSRCZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFNvdXJj ZT1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9PGJyPg0K Jmd0OyA6IE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nJmx0O2JyJmd0Ozxicj4NCiZndDsg JmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgQXJlYT1DMj1BMCA9QzI9QTAgPUMy PUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9PGJyPg0KJmd0OyA9QzI9QTAgOiBSb3V0 aW5nJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtn dDsgU3RyZWFtPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEwID1DMj1BMCA9QzI9QTAgPUMyPUEw ID08YnI+DQomZ3Q7IDogSUVURiZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFZlcmlmeWluZyBQYXJ0eT1DMj1BMCA9QzI9QTAgPUMyPUEwOiBJ RVNHJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtn dDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0 OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0 Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgLS0wMDFhMTEzOTdhMmM5YmRh NmUwNTBhNmYzMWFlJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtn dDsgQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9M0QmYW1wO3F1b3Q7VVRGLTgmYW1w O3F1b3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgQ29u dGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZSZsdDticiZndDs8YnI+DQom Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtn dDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtsdDtkaXYgZGlyPTNEM0QmYW1wO3F1b3Q7bHRyJmFt cDtxdW90OyZhbXA7Z3Q7SGkgWWFrb3YsJmFtcDtsdDticiZhbXA7Z3Q7JmFtcDtsdDticj08YnI+ DQomZ3Q7ICZhbXA7Z3Q7Q291bGQgeW91IGNsYXJpZnkgeW91ciBwb2ludCBmb3IgdGhpcyZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IGVycj0zRCZsdDticiZndDs8YnI+DQom Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IGF0YT89M0RDMj0zREEwIEluIFJGQyA0MDkw LCBpbiB0aGUgdGVybWlub2xvZ3kgaXQgc2F5czomYW1wO2x0O2I9PGJyPg0KJmd0OyByJmFtcDtn dDsmYW1wO2FtcDtxdW90OyBCYWNrdXAmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1w O2d0OyBQYXRoOiA9M0QmbHQ7YnImZ3Q7PGJyPg0KJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsg VGhlIExTUCB0aGF0IGlzIHJlc3BvbnNpYmxlIGZvciBiYWNraW5nIHVwIG9uZSZhbXA7bHQ7YnIm YW1wO2d0Oz0zREM9PGJyPg0KJmd0OyAyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwJmx0O2Jy Jmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgPTNEQzI9M0QmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyA9M0RBMCA9M0RDMj0zREEwID0zREMyPTNE QTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTA9PGJyPg0KJmd0OyZuYnNwOyA9M0RD Mj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMHByb3RlY3RlZCZsdDticiZndDs8YnI+DQomZ3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7IExTUC49M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAm YW1wO2d0OyAmYW1wO2d0OyA9M0RDMj0zREEwIEEgYmFja3VwIHBhdGggcmVmZXJzIHRvIGVpdGhl ciBhIGRldG91ciBMU1AmYW1wO2x0O2JyPTxicj4NCiZndDsgJmFtcDtndDs9M0RDMj0zREEwID0z REMyPTNEQTAmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyA9M0RDMj0zREEw ID0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ID0zREMy PTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj08 YnI+DQomZ3Q7ID0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwb3IgYSZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IGJhY2t1cCB0PTNEJmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgdW5uZWwuJmFtcDtsdDticiZhbXA7 Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7PTNEQzI9M0RBMCBCYWNrdXAgVHVubmVsOiBUaGUgTFNQID08 YnI+DQomZ3Q7IHRoYXQgaXMgdXNlZCB0byBiYWNrdXAgdXAmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyAmYW1wO2d0OyBvbmUgbz0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7IGYgdGhlIG1hbnkmYW1wO2x0O2JyJmFtcDtndDs9M0RDMj0zREEwID0z REMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj08YnI+DQomZ3Q7ID0zREEwID0zREMyPTNEQTAgPTNE QzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0 OyAmYW1wO2d0OyA9M0RDMj0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7ID0zREEwTFNQcyBpbiBtYW55LXRvLW9uZSZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7IGJhY2t1cC4mYW1wO2FtcDtxdW90OyZhbXA7bHQ7ZGl2JmFtcDtndDsm YW1wO2x0O2JyJmFtcDtndDsmYW1wO2x0Oy9kaXYmYW1wO2d0OyZhbXA7bHQ7ZGl2JmFtcDtndDtU aGFuPTxicj4NCiZndDsga3MsJmFtcDtsdDsvZGl2JmFtcDtndDsmYW1wO2x0O2RpdiZhbXA7Z3Q7 QT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IGxpYSZh bXA7bHQ7L2RpdiZhbXA7Z3Q7JmFtcDtsdDsvZGl2JmFtcDtndDsmYW1wO2x0O2RpdiBjbGFzcz0z RDNEJmFtcDtxdW90O2dtYWlsX2V4dD08YnI+DQomZ3Q7IHJhJmFtcDtxdW90OyZhbXA7Z3Q7JmFt cDtsdDticiZhbXA7Z3Q7JmFtcDtsdDtkaXYmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAm YW1wO2d0OyBjbGFzcz0zRDNEJmFtcDtxdW90O2dtYWlsX3F1b3RlJmFtcDtxdW90OyZhbXA7Z3Q7 T249M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0Oz1DMj1B MCBXZWQsIERlYyAxNywgMjAxNCBhdCAzOjA3IFBNLCBSRkMgRXJyYXRhIFN5c3RlbSAmYW1wO2x0 O3NwPTxicj4NCiZndDsgYW4mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBk aXI9M0QzRCZhbXA7cXVvdDtsdHImYW1wO3F1b3Q7JmFtcDtndDsmYW1wO2FtcDtsdDsmYW1wO2x0 O2EgaD0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IHJl Zj0zRDNEJmFtcDtxdW90O21haWx0bzombHQ7YSBocmVmPTNEJnF1b3Q7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3IiPnJmYy1lZGl0b3JAcmZjLWVkaXRvcjwvYT49 PGJyPg0KJmd0OyAub3JnJnF1b3Q7Jmd0OzxhIGhyZWY9Im1haWx0bzpyZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnIj5yZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9hPiZsdDsvYSZndDsmYW1wO3F1 b3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgdGFyZ2V0PTNEM0QmYW1w O3F1b3Q7X2JsYW5rJmFtcDtxdW90OyZhbXA7Z3Q7cmZjLWVkaXRvckByZmMtZT0zRCZsdDticiZn dDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZsdDthIGhyZWY9M0QmcXVv dDs8YSBocmVmPSJodHRwOi8vZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RpdG9y Lm9yZzwvYT4mcXVvdDsgdGFyZ2V0PTNEJnF1b3Q7X2JsYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9Imh0 dHA6Ly9kaXRvci5vcmciIHRhcmdldD0iX2JsYW5rIj5kaXRvci5vcmc8L2E+Jmx0Oy9hJmd0Oz08 YnI+DQomZ3Q7ICZhbXA7bHQ7L2EmYW1wO2d0OyZhbXA7YW1wO2d0OyZhbXA7bHQ7L3NwYW4mYW1w O2d0OyB3cm90ZTomYW1wO2x0O2JyJmFtcDtndDsmYW1wO2x0O2Jsb2NrcXVvdGUgY2xhc3M9M0Qz RCZhbXA7cT08YnI+DQomZ3Q7IHVvdDtnbWFpbF9xdW90ZSZhbXA7cXVvdDsmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBzdHlsZT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ID0zRDNEJmFtcDtxdW90O21hcmdpbjowIDAgMCAuOGV4 O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGQ9PGJyPg0KJmd0OyBpbmctbGVmdDoxZXgm YW1wO3F1b3Q7JmFtcDtndDtUaGUmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0 OyBmb2xsPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgb3dpbmcgZXJy YXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzQwOTAsJmFtcDtsdDticiZhbXA7 Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDth bXA7cXVvdDtGYXN0IFJlcm91dGUgRXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBMU1AgVHVubmVs cz08YnI+DQomZ3Q7ICZhbXA7YW1wO3F1b3Q7LiZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8 YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7YnImYW1wO2d0OyZs dDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgWW91IG1heSByZXZpZXcgdGhlIHJl cG9ydCBiZWxvdyBhbmQgYXQ6JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsg JmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtsdDthIGhyZWY9M0QzRCZhbXA7cXVvdDsm bHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmbHQ7YSBocmVmPTNEJnF1b3Q7 PGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9 M0QzRDQwPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRh X3NlYXJjaC5waHA/cmZjPTNEM0Q0MD08L2E+PGJyPg0KJmd0OyA5MCZhbXA7YW1wO2FtcDtlaWQ9 M0QmcXVvdDsgdGFyZ2V0PTNEJnF1b3Q7X2JsYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjPTwvYT48YnI+DQomZ3Q7IGgucGhwP3JmYz0z RDNENDA5MCZhbXA7YW1wO2FtcDtlaWQ9M0QmbHQ7L2EmZ3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsg JmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgPTNEM0Q0MjAzJmFtcDtxdW90OyB0YXJnZXQ9M0Qz RCZhbXA7cXVvdDtfYmxhbmsmYW1wO3F1b3Q7JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyAmYW1wO2d0OyAmbHQ7YSBocmVmPTNEJnF1b3Q7PGEgaHJlZj0iaHR0cDovL3d3dy5y ZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9M0QiIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRDwvYT4mcXVv dDsgdGE9PGJyPg0KJmd0OyByZ2V0PTNEJnF1b3Q7X2JsYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9Imh0 dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTNEIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9 M0Q8L2E+Jmx0Oy9hJmd0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZh bXA7Z3Q7ID0zRDNENDA5MCZhbXA7YW1wO2FtcDtlaWQ9M0QzRDQyMDMmYW1wO2x0Oy9hJmFtcDtn dDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0 OyAmYW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0 OyAmYW1wO2d0OyAmYW1wO2d0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7IFR5cGU6IFRlY2huaWNhbCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+ DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IFJlcG9ydGVkIGJ5OiBZYWtvdiBSZWto dGVyICZhbXA7YW1wO2x0OyZhbXA7bHQ7YSBocmVmPTNEM0QmYW1wO3F1b3Q7bWFpbD08YnI+DQom Z3Q7IHRvOiZsdDthIGhyZWY9M0QmcXVvdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnlha292QGp1 bmlwZXIubmV0Ij55YWtvdkBqdW5pcGVyLm5ldDwvYT4mcXVvdDsmZ3Q7PGEgaHJlZj0ibWFpbHRv Onlha292QGp1bmlwZXIubmV0Ij55YWtvdkBqdW5pcGVyLm5ldDwvYT4mbHQ7L2EmZ3Q7Jmx0O2Jy Jmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtxdW90OyZhbXA7Z3Q7eWFrb3ZA aj0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZsdDth IGhyZWY9M0QmcXVvdDs8YSBocmVmPSJodHRwOi8vdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly91bmlwZXIubmV0PC9hPiZxdW90OyB0YXJnZXQ9M0QmcXVvdDtfYmxhbmsmcXVvdDsm Z3Q7PGEgaHJlZj0iaHR0cDovL3VuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj51bmlwZXIubmV0 PC9hPiZsdDsvPTxicj4NCiZndDsgYSZndDsmYW1wO2x0Oy9hJmFtcDtndDsmYW1wO2FtcDtndDsm YW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAm YW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAm YW1wO2d0OyAmYW1wO2d0OyBTZWN0aW9uOiA2JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0 O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgT3JpZ2luYWwgVGV4 dCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBXaGVuZXZlciB0aGUgUExSIGhhcyBhIGJh Y2t1cCBwYXRoIGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNUIHM9PGJyPg0KJmd0OyBldCZhbXA7bHQ7 YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 IHRoZSAmYW1wO2FtcDtxdW90O2xvY2FsIHByb3RlY3Rpb24gYXZhaWxhYmxlJmFtcDthbXA7cXVv dDsgZmxhZy4mYW1wO2x0Oz08YnI+DQomZ3Q7IGJyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsm bHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBDb3JyZWN0ZWQg VGV4dCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7 Z3Q7ICZhbXA7Z3Q7IC0tLS0tLS0tLS0tLS0tJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgV2hlbmV2ZXIgdGhlIFBMUiBoYXMg YSBvbmUtdG8tb25lIGJhY2t1cCBMU1Agb3IgYnlwYXNzIHR1bm5lPTxicj4NCiZndDsgbCZhbXA7 bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7 Z3Q7IGF2YWlsYWJsZSwgdGhlIFBMUiBNVVNUIHNldCB0aGUgJmFtcDthbXA7cXVvdDtsb2NhbCBw cm90ZWN0aW9uIGE9PGJyPg0KJmd0OyB2YWlsYWJsZSZhbXA7YW1wO3F1b3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgZmxhZz0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IC4mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2x0O2JyJmFt cDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBOb3Rl cyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7IC0tLS0tJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFt cDtndDsgJmFtcDtndDsgJmFtcDtndDsgSW4gdGhlIGNhc2Ugb2YgZmFjaWxpdHktYmFzZWQgRlJS IHRoZSBQTFIgbXVzdCBzZXQgdGhlICZhbXA7YW1wOz08YnI+DQomZ3Q7IHF1b3Q7bG9jYWwmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBwcm90ZWN0aT0zRCZsdDticiZndDs8 YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IG9uIGF2YWlsYWJsZSZhbXA7YW1w O3F1b3Q7IGZsYWcgaWYgaXQgaGFzIHRoZSBieXBhc3MgdHVubmVsIGF2YWk9PGJyPg0KJmd0OyBs YWJsZS4mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1w O2d0OyAmYW1wO2d0OyAmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1w O2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBJbnN0cnVjdGlvbnM6JmFtcDtsdDticiZhbXA7Z3Q7Jmx0 O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0t LSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICZhbXA7YW1wO3F1 b3Q7UmVwb3J0ZWQmYW1wO2FtcDtxPTxicj4NCiZndDsgdW90Oy4gSWYgbmVjZXNzYXJ5LCZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IHBsZT0zRCZsdDticiZndDs8YnI+DQom Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IGFzZSZhbXA7bHQ7YnImYW1wO2d0OyZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7IHVzZSAmYW1wO2FtcDtx dW90O1JlcGx5IEFsbCZhbXA7YW1wO3F1b3Q7IHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91PTxi cj4NCiZndDsgbGQgYmUgdmVyaWZpZWQgb3ImYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyByZWplY3RlZC4gV2hlbiBhIGRlY2lz aW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgKEk9PGJyPg0KJmd0OyBFU0cpJmFt cDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFt cDtndDsgY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0 LCBpZiBuZWNlPTxicj4NCiZndDsgc3NhcnkuJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0 O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBSRkM0MDkwIChkcmFmdC1pZXRmLW1w bHMtcnN2cC1sc3AtZmFzdHJlcm91dGUtMDcpJmFtcDtsdDticiZhbXA7Z3Q7Jmx0Oz08YnI+DQom Z3Q7IGJyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBUaXRsZT0zREMyPTNEQTAgPTNE QzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9PGJyPg0KJmd0OyA9M0RD Mj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMDogRmFzdCZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7ICZhbXA7Z3Q7IFJlcm91dGUgPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDtndDsgJmFtcDtndDsgRXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBMU1AgVHVubmVscyZh bXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZh bXA7Z3Q7IFB1YmxpY2F0aW9uIERhdGU9M0RDMj0zREEwID0zREMyPTNEQTAgOiBNYXkgMjAwNSZh bXA7bHQ7YnImYW1wO2d0OyZsdDtiPTxicj4NCiZndDsgciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7Z3Q7ICZhbXA7Z3Q7IEF1dGhvcihzKT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0z REEwID0zREMyPTNEQTAgPTNEQzI9PGJyPg0KJmd0OyA9M0RBMCA9M0RDMj0zREEwOiBQLiBQYW4s IEVkLiwgRy4mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyBTd2FsbG93PTNE Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgLCBFZC4sIEEu IEF0bGFzLCBFZC4mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0 OyAmYW1wO2d0OyAmYW1wO2d0OyBDYXRlZ29yeT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0z REEwID0zREMyPTNEQTAgPTNEQzI9M0Q9PGJyPg0KJmd0OyBBMCA9M0RDMj0zREEwIDogUFJPUE9T RUQgU1RBTkRBUkQmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0 OyAmYW1wO2d0OyAmYW1wO2d0OyBTb3VyY2U9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RB MCA9M0RDMj0zREEwID0zREMyPTNEQTA9PGJyPg0KJmd0OyZuYnNwOyA9M0RDMj0zREEwID0zREMy PTNEQTAgOiBNdWx0aXByb3RvY29sJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDtn dDsgTGFiZT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7 IGwgU3dpdGNoaW5nJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtn dDsgJmFtcDtndDsgJmFtcDtndDsgQXJlYT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEw ID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9PGJyPg0KJmd0OyA9M0RDMj0zREEwID0zREMyPTNEQTAg PTNEQzI9M0RBMCA6IFJvdXRpbmcmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyBTdHJlYW09M0RDMj0zREEwID0zREMyPTNEQTAg PTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTA9PGJyPg0KJmd0OyZuYnNwOyA9M0RDMj0z REEwID0zREMyPTNEQTAgOiBJRVRGJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZn dDsgJmFtcDtndDsgJmFtcDtndDsgJmFtcDtndDsgVmVyaWZ5aW5nIFBhcnR5PTNEQzI9M0RBMCA9 M0RDMj0zREEwID0zREMyPTNEQTA6IElFU0cmYW1wO2x0O2JyJmFtcDs9PGJyPg0KJmd0OyBndDsm bHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2x0O2Jy JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAmYW1wO2d0OyAm YW1wO2x0Oy9ibG9ja3F1b3RlJmFtcDtndDsmYW1wO2x0Oy9kaXYmYW1wO2d0OyZhbXA7bHQ7YnIm YW1wO2d0OyZhbXA7bHQ7L2RpdiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDtndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2d0OyAm YW1wO2d0OyAtLTAwMWExMTM5N2EyYzliZGE2ZTA1MGE2ZjMxYWUtLSZsdDticiZndDs8YnI+DQom Z3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmbHQ7L2RpdiZndDsmbHQ7L2RpdiZndDsmYW1wO2d0OyAtLTA0N2Q3YjVk OTlhMzNhOTE0YjA1MGE3MDE2NGUmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmbHQ7c3BhbiBjbGFzcz0z RCZxdW90OyZxdW90OyZndDsmYW1wO2d0OyBDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNl dD0zRCZhbXA7cXVvdDtVVEYtOCZhbXA7cXVvdDsmbHQ7PTxicj4NCiZndDsgYnImZ3Q7PGJyPg0K Jmd0OyAmYW1wO2d0OyBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxl Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmbHQ7L3Nw YW4mZ3Q7JmFtcDtndDsgJmFtcDtsdDtkaXYgZGlyPTNEM0QmYW1wO3F1b3Q7bHRyJmFtcDtxdW90 OyZhbXA7Z3Q7WWFrb3YsJmFtcDtsdDtkaXYgY2xhc3M9M0QzRCZhbXA7cXVvPTxicj4NCiZndDsg dDtnbWFpbF9leHRyYSZhbXA7cXVvdDsmYW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZhbXA7bHQ7 ZGl2IGNsYXNzPTNEM0QmYW1wO3F1b3Q7Z21haWxfcT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7IHVvdGUmYW1wO3F1b3Q7JmFtcDtndDtPbiBXZWQsIERlYyAxNywgMjAxNCBhdCA0OjA1 IFBNLCBZYWtvdiBSZWtodGVyICZhbXA7bHQ7c3BhbiA9PGJyPg0KJmd0OyBkaXI9M0QzRCZhbXA7 cXVvdDtsdHImYW1wO3F1b3Q7JmFtcDtndDsmYW1wO2FtcDtsdDs9M0QmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmYW1wO2d0OyAmYW1wO2x0O2EgaHJlZj0zRDNEJmFtcDtxdW90O21haWx0bzombHQ7YSBo cmVmPTNEJnF1b3Q7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldCI+eWFr b3ZAanVuaXBlci5uZXQ8L2E+JnF1b3Q7Jmd0O3lha292PTxicj4NCiZndDsgQDxhIGhyZWY9Imh0 dHA6Ly9qdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmp1bmlwZXIubmV0PC9hPiZsdDsvYSZn dDsmYW1wO3F1b3Q7IHRhcmdldD0zRDNEJmFtcDtxdW90O19ibGFuayZhbXA7cXVvdDsmYW1wO2d0 OyZsdDthIGhyZWY9M0QmcXVvdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnkiPnk8L2E+PTxicj4N CiZndDsgPGEgaHJlZj0ibWFpbHRvOmFrb3ZAanVuaXBlci5uZXQiPmFrb3ZAanVuaXBlci5uZXQ8 L2E+JnF1b3Q7Jmd0OzxhIGhyZWY9Im1haWx0bzp5YWtvdkBqdW5pcGVyLm5ldCI+eWFrb3ZAanVu aXBlci5uZXQ8L2E+Jmx0Oy9hJmd0OyZhbXA7bHQ7L2E9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyAmYW1wO2d0OyZhbXA7YW1wO2d0OyZhbXA7bHQ7L3NwYW4mYW1wO2d0OyB3cm90ZTom YW1wO2x0O2JyJmFtcDtndDsmYW1wO2x0O2Jsb2NrcXVvdGUgY2xhc3M9M0QzRCZhbXA7cXU9PGJy Pg0KJmd0OyBvdDtnbWFpbF9xdW90ZSZhbXA7cXVvdDsgc3R5bGU9M0QzRCZhbXA7cXVvdDttYXJn aW46MCA9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAwIDAgLjhleDtib3JkZXItbGVm dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4JmFtcDtxdW90OyZhbXA7Z3Q7QWxpYSwm YW1wO2x0PTxicj4NCiZndDsgO2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0 OyAmYW1wO2x0O3NwYW4gY2xhc3M9M0QzRCZhbXA7cXVvdDsmYW1wO3F1b3Q7JmFtcDtndDsmYW1w O2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsg SGkgWWFrb3YsJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtn dDsgJmFtcDthbXA7Z3Q7IENvdWxkIHlvdSBjbGFyaWZ5IHlvdXIgcG9pbnQgZm9yIHRoaXMgZXJy YXRhPz0zREMyPTNEQTAgSW4gUkY9PGJyPg0KJmd0OyBDIDQwOTAsIGluIHRoPTNEJmx0O2JyJmd0 Ozxicj4NCiZndDsgJmFtcDtndDsgZSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQom Z3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyB0ZXJtaW5vbG9neSBpdCBzYXlzOiZhbXA7bHQ7YnIm YW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0Oz0zREMyPTNE QTAgJmFtcDthbXA7cXVvdDtCYWNrdXAgUGF0aDogVGhlIExTUCB0aGF0IGlzIHJlc3BvbnNpYmxl ID08YnI+DQomZ3Q7IGZvciBiYWNraW5nIHVwIG9uPTNEJmx0O2JyJmd0Ozxicj4NCiZhbXA7Z3Q7 IGUmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2Ft cDtndDs9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNE QTAgPTNEQzI9PGJyPg0KJmd0OyA9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RB MCA9M0RDMj0zREEwID0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ID0zREMyPTNEQTAg PTNEQzI9M0RBMCBwcm90ZWN0ZWQgTFNQLj0zREMyPTNEQTAgQSBiYWNrdXAgcGF0aCByZWZlcnMg dG89PGJyPg0KJmd0OyZuYnNwOyBlaXRoZXIgYSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8 YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0Oz0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RD Mj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj08YnI+DQomZ3Q7ID0zREEwID0zREMy PTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEJmx0O2JyJmd0Ozxicj4N CiZndDsgJmFtcDtndDsgPTNEQzI9M0RBMCA9M0RDMj0zREEwIGRldG91ciBMU1Agb3IgYSBiYWNr dXAgdHVubmVsLiZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ICZhbXA7YW1wO2d0Oz0zREMyPTNEQTAgPTNEQzI9M0RBMEJhY2t1cCBUdW5uZWw6IFRoZSBM U1AgdGhhdCBpcyB1c2VkIHRvIGJhPTxicj4NCiZndDsgY2t1cCB1cCBvbmUgb2YgdGg9M0QmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyBlIG1hbnkmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDs9M0RDMj0zREEwID0zREMyPTNEQTAg PTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9PGJyPg0KJmd0OyA9M0RBMCA9 M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCBMU1BzIGluID0zRCZsdDticiZndDs8YnI+ DQomZ3Q7ICZhbXA7Z3Q7IG1hbnktdG8tb25lIGJhY2t1cC4mYW1wO2FtcDtxdW90OyZhbXA7bHQ7 YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7YnImYW1wO2d0 OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7L3NwYW4mYW1wO2d0O0luIHRo ZSB0ZXJtaW5vbG9neSBpdCBhbHNvIHNheXM6JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsg JmFtcDtndDsgPTNEQzI9M0RBMCA9M0RDMj0zREEwJmFtcDthbXA7cXVvdDtCeXBhc3MgVHVubmVs OiBBbiBMU1AgdGhhdCBpcyB1c2VkIHRvIHA9PGJyPg0KJmd0OyByb3RlY3QgYSBzZXQgb2YgTD0z RCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IFNQcyZhbXA7bHQ7YnImYW1wO2d0OyZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEw ID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwIHBhc3M9PGJyPg0KJmd0OyBpbmcgb3Zl ciBhIGNvbW1vbiBmYWNpbGl0eS4mYW1wO2FtcDtxPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFt cDtndDsgdW90OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IE15IHBvaW50 IGlzIHRoYXQgKHVubGVzcyB0aGUgdGVybSAmYW1wO2FtcDtxdW90O2J5cGFzcyB0dW5uZWwmYW1w O2FtcDtxdW90OyBtZT08YnI+DQomZ3Q7IGFucyB0aGUgc2FtZSZhbXA7bHQ7PTNEJmx0O2JyJmd0 Ozxicj4NCiZndDsgJmFtcDtndDsgYnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7IGFzICZhbXA7YW1wO3F1b3Q7YmFja3VwIHBhdGgmYW1wO2FtcDtxdW90OyBvciAmYW1wO2Ft cDtxdW90O2JhY2t1cCB0dW5uZWwmYW1wO2FtcDtxdW90PTxicj4NCiZndDsgOykgaW4gbWFueS10 by1vbmUgYmFjPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsga3VwJmFtcDtsdDticiZh bXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgdGhlICZhbXA7YW1wO3F1b3Q7bG9j YWwgcHJvdGVjdGlvbiBhdmFpbGFibGUmYW1wO2FtcDtxdW90OyBmbGFnIGZvciBhIGdpdmVuIHBy PTxicj4NCiZndDsgb3RlY3RlZCBMU1AmYW1wO2x0O2I9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyByJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyBNVVNUIGJlIHNl dCB3aGVuIHRoZSBQTFIgaGFzIGEgKmJ5cGFzcyogdHVubmVsIGZvciB0aGF0IExTUC4mYW1wO2x0 O2JyJmFtcDtndDs9PGJyPg0KJmd0OyAmYW1wO2x0Oy9ibG9ja3F1b3Q9M0QmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmYW1wO2d0OyBlJmFtcDtndDsmYW1wO2x0O2RpdiZhbXA7Z3Q7JmFtcDtsdDticiZh bXA7Z3Q7JmFtcDtsdDsvZGl2JmFtcDtndDsmYW1wO2x0O2RpdiZhbXA7Z3Q7QWggLSBvay49M0RD Mj0zREEwIEEgPTxicj4NCiZndDsgYmFja3VwIHBhdGggdGhhdCB1c2VzIGEgYnlwYXNzIHR1bm5l PTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgbCBpcyBub3QganVzdCB0aGUgYnlwYXNz IHR1bm5lbCZhbXA7bHQ7L2RpdiZhbXA7Z3Q7JmFtcDtsdDtkaXYmYW1wO2d0O2l0c2VsZi49M0RD Mj0zREE9PGJyPg0KJmd0OyAwIFRoZXJlJmFtcDthbXA7IzM5O3MgdGhlIHN0YT0zRCZsdDticiZn dDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IHRlIGFzc29jaWF0ZWQgZm9yIHRoZSBwcm90ZWN0ZWQgTFNQ IHRoYXQgYWxzbyBuZWVkcyB0byBiZSZhbXA7bHQ7L2RpdiZhbXA7Z3Q7JmFtcDs9PGJyPg0KJmd0 OyBsdDtkaXYmYW1wO2d0O2NyZWF0ZWQ9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0Oz1D Mj1BMCBhbmQgaW5zdGFsbGVkLj0zREMyPTNEQTAgSW4gbW9yZSBjb25jcmV0ZSB0ZXJtcywgdGhp cyBpcyBpbnN0YWxsPTxicj4NCiZndDsgaW5nIGFuIG91dC1zZWc9M0QmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmYW1wO2d0OyBtZW50IHdpdGg9M0RDMj0zREEwJmFtcDtsdDsvZGl2JmFtcDtndDsmYW1w O2x0O2RpdiZhbXA7Z3Q7dGhlIGFwcHJvcHJpYXRlIGxhYmVsIGZvciB0aD08YnI+DQomZ3Q7IGUg cHJvdGVjdGVkIExTUCB0byBiZT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7PUMyPUEw IHVuZGVyc3Rvb2QgYnkgdGhlIG1lcmdlIHBvaW50IGFzJmFtcDtsdDsvZGl2JmFtcDtndDsmYW1w O2x0O2RpdiZhbXA7Z3Q7d2VsbCBhcyBhPTxicj4NCiZndDsgbiBvdXRlciBsYWJlbCBmb3IgdGhl ID0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IGJ5cGFzcyBMU1AuJmFtcDtsdDsvZGl2 JmFtcDtndDsmYW1wO2x0O2RpdiZhbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7JmFtcDtsdDsvZGl2 JmFtcDtndDsmYW1wO2x0O2RpdiZhbXA7Z3Q7U28sPTxicj4NCiZndDsmbmJzcDsgdGhlIHRleHQg cmVmZXJzIHRvIGEgYmFja3VwIHBhdGggaT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 IG5zdGVhZCBvZiBhIGJ5cGFzcyB0dW5uZWwgYmVjYXVzZSBoYXZpbmcgdGhlJmFtcDtsdDsvZGl2 JmFtcDtndDsmYW1wO2x0O2RpdiZhbXA7Z3Q7YnlwPTxicj4NCiZndDsgYXNzIHR1bm5lbCBpc24m YW1wO2FtcDsjMz0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IDk7dCBxdWl0ZSBzdWZm aWNpZW50Lj0zREMyPTNEQTAgRG9lcyB0aGF0IG1ha2Ugc2Vuc2UgdG8geW91PyZhbXA7bHQ7L2Rp diZhbXA7Zz08YnI+DQomZ3Q7IHQ7JmFtcDtsdDtkaXYmYW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0 OyZhbXA7bHQ7L2RpPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgdiZhbXA7Z3Q7JmFt cDtsdDtkaXYmYW1wO2d0O1JlZ2FyZHMsJmFtcDtsdDsvZGl2JmFtcDtndDsmYW1wO2x0O2RpdiZh bXA7Z3Q7QWxpYSZhbXA7bHQ7L2RpdiZhbXA7Z3Q7JmFtcDtsdDtkaXY9PGJyPg0KJmd0OyAmYW1w O2d0Oz0zREMyPTNEQTAmYW1wO2x0Oy9kaXYmYW1wO2d0OyZhbXA7bHQ7YmxvY2txdW90ZSBjbGFz cz0zRDNEJmFtcDtxdW90O2c9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyBtYWlsX3F1 b3RlJmFtcDtxdW90OyBzdHlsZT0zRDNEJmFtcDtxdW90O21hcmdpbjowIDAgMCAuOGV4O2JvcmRl ci1sZWZ0OjFweCAjY2M9PGJyPg0KJmd0OyBjIHNvbGlkO3BhZGRpbmctbD0zRCZsdDticiZndDs8 YnI+DQomZ3Q7ICZhbXA7Z3Q7IGVmdDoxZXgmYW1wO3F1b3Q7JmFtcDtndDsmbHQ7YnImZ3Q7PGJy Pg0KJmd0OyAmYW1wO2d0OyBZYWtvdi4mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmYW1wO2d0OyAmYW1wO2x0O2RpdiZhbXA7Z3Q7JmFtcDtsdDtkaXYgY2xhc3M9M0QzRCZh bXA7cXVvdDtoNSZhbXA7cXVvdDsmYW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8 YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyBUaGFua3MsJmFtcDtsdDticiZhbXA7Z3Q7 Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7IEFsaWEmYW1wO2x0O2Jy JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsmYW1wO2x0 O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgT24g V2VkLCBEZWMgMTcsIDIwMTQgYXQgMzowNyBQTSwgUkZDIEVycmF0YSBTeXN0ZW0gJmFtcDthbXA7 bHQ7JmFtcDtsPTxicj4NCiZndDsgdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFt cDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7bHQ7YSBocmVmPTNEM0QmYW1wO3F1b3Q7bWFpbHRvOiZs dDthIGhyZWY9M0QmcXVvdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJmYy1lZGl0b3JAcmZjLSI+ cmZjLWVkaXRvckByZmMtPC9hPj08YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9lZGl0b3Iub3Jn IiB0YXJnZXQ9Il9ibGFuayI+ZWRpdG9yLm9yZzwvYT4mcXVvdDsmZ3Q7PGEgaHJlZj0ibWFpbHRv OnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmciPnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8L2E+ Jmx0Oy9hJmd0OyZhbXA7cXVvdDsmYW1wO2d0OyZsdDthIGhyZWY9M0QmcXVvdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnJmYy1lZCI+cmZjLWVkPC9hPj08YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0 bzppdG9yQHJmYy1lZGl0b3Iub3JnIj5pdG9yQHJmYy1lZGl0b3Iub3JnPC9hPiZxdW90OyZndDs8 YSBocmVmPSJtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyI+cmZjLWVkaXRvckByZmMt ZWRpdG9yLm9yZzwvYT4mbHQ7L2EmZ3Q7PTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDtsdDsvYSZhbXA7Z3Q7JmFtcDthbXA7Z3Q7IHdyb3RlOiZhbXA7bHQ7YnImYW1wO2d0OyZs dDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0 OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtndDsg VGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUj08YnI+ DQomZ3Q7IEZDNDA5MCwmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1w O2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO3F1b3Q7RmFzdCBSZXJvdXRl IEV4dGVuc2lvbnMgdG8gUlNWUC1URSBmb3IgTFNQPTxicj4NCiZndDsmbmJzcDsgVHVubmVscyZh bXA7YW1wO3F1b3Q7LiZhbXA7bHQ7Yj0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IHIm YW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2Ft cDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1w O2FtcDtndDsgJmFtcDthbXA7Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDth bXA7Z3Q7ICZhbXA7YW1wO2d0OyBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBh dDomYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnI9PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmYW1w O2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7bHQ7YSBocmVmPTNEM0QmYW1wO3F1 b3Q7Jmx0O2EgaHJlZj0zRCZxdW90OzxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5yZmMtZWRpdG88L2E+PTxicj4NCiZndDsgPGEgaHJlZj0i aHR0cDovL3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRDNENDA5MD0zRCIgdGFyZ2V0PSJf YmxhbmsiPnIub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRDNENDA5MD0zRDwvYT4mcXVvdDsg dGFyZ2V0PTNEJnF1b3Q7X2JsYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWUi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnJmYy1lPC9hPj08YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHA6Ly9kaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTNEM0Q0MDkwPTNEIiB0YXJn ZXQ9Il9ibGFuayI+ZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0zRDNENDA5MD0zRDwv YT4mbHQ7L2EmZ3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7YW1wO2Vp ZD0zRDNENDIwMyZhbXA7cXVvdDsgdGFyZ2V0PTNEM0QmYW1wO3F1b3Q7X2JsYW5rJmFtcDtxdW90 OyZhbXA7Z3Q7Jmx0O2EgaHJlZj08YnI+DQomZ3Q7ID0zRCZxdW90OzxhIGhyZWY9Imh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC49M0QiIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2guPTNEPC9hPiZxdW90OyB0YXJnZXQ9 M0QmcXVvdDtfYmxhbmsmcXVvdDsmZ3Q7PGEgaHJlZj0iaHR0cDovL3ciIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vdzwvYT49PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3cucmZjLWVkaXRvci5v cmcvZXJyYXRhX3NlYXJjaC49M0QiIHRhcmdldD0iX2JsYW5rIj53dy5yZmMtZWRpdG9yLm9yZy9l cnJhdGFfc2VhcmNoLj0zRDwvYT4mbHQ7L2EmZ3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtn dDsgcGhwP3JmYz0zRDNENDA5MCZhbXA7YW1wO2FtcDtlaWQ9M0QzRDQyMDMmYW1wO2x0Oy9hJmFt cDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1w O2FtcDtndDsgJmFtcDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZn dDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7 ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtndDsgVHlwZTogVGVjaG5pY2FsJmFtcDts dDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZh bXA7YW1wO2d0OyBSZXBvcnRlZCBieTogWWFrb3YgUmVraHRlciAmYW1wO2FtcDtsdDsmYW1wO2x0 O2EgaHJlZj0zRDNEJmFtcDtxPTxicj4NCiZndDsgdW90O21haWx0bzombHQ7YSBocmVmPTNEJnF1 b3Q7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp5YWtvdkBqdW5pcGVyLm5lIj55YWtvdkBqdW5pcGVy Lm5lPC9hPiZxdW90OyZndDs8YSBocmVmPSJtYWlsdG86eWFrb3ZAanVuaXBlci5uZSI+eWFrb3ZA anVuaXBlci5uZTwvYT4mbHQ7L2EmZ3Q7PTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg dCZhbXA7cXVvdDsmYW1wO2d0OyZsdDthIGhyZWY9M0QmcXVvdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnlha292QGp1bmlwZXIubmV0Ij55YWtvdkBqdW5pcGVyLm5ldDwvYT4mcXVvdDsmZ3Q7PGEg aHJlZj0ibWFpbHRvOnlha292QGp1bmlwZXIubmV0Ij55YWtvdkBqdW5pcGVyLm5ldDwvYT4mbHQ7 L2EmZ3Q7JmFtcDs9PGJyPg0KJmd0OyBsdDsvYSZhbXA7Z3Q7JmFtcDthbXA7Z3Q7JmFtcDtsdDti ciZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7 YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZh bXA7YW1wO2d0OyAmYW1wO2FtcDtndDsgU2VjdGlvbjogNiZhbXA7bHQ7YnImYW1wO2d0OyZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtndDsmYW1wO2x0 O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFt cDthbXA7Z3Q7IE9yaWdpbmFsIFRleHQmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7IC0tLS0tLS0tLS0tLS0mYW1w O2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsg JmFtcDthbXA7Z3Q7IFdoZW5ldmVyIHRoZSBQTFIgaGFzIGEgYmFja3VwIHBhdGggYXZhaWxhYmxl LCB0aGUgUEw9PGJyPg0KJmd0OyBSIE1VU1Qgc2V0JmFtcDtsdDticj0zRCZsdDticiZndDs8YnI+ DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFt cDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyB0aGUgJmFtcDthbXA7cXVvdDtsb2NhbCBwcm90ZWN0aW9u IGF2YWlsYWJsZSZhbXA7YW1wO3F1b3Q7IGY9PGJyPg0KJmd0OyBsYWcuJmFtcDtsdDticiZhbXA7 Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0 OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1w O2d0OyAmYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7IENvcnJlY3RlZCBUZXh0JmFtcDtsdDti ciZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7 YW1wO2d0OyAtLS0tLS0tLS0tLS0tLSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQom Z3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtndDsgV2hlbmV2ZXIgdGhlIFBMUiBo YXMgYSBvbmUtdG8tb25lIGJhY2t1cCBMU1Agb3IgYnlwYT08YnI+DQomZ3Q7IHNzIHR1bm5lbCZh bXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0 OyAmYW1wO2FtcDtndDsgYXZhaWxhYmxlLCB0aGUgUExSIE1VU1Qgc2V0IHRoZSAmYW1wO2FtcDtx dW90O2xvY2FsIHByb3Q9PGJyPg0KJmd0OyBlY3Rpb24gYXZhaWxhYmxlJmFtcDthbXA7PTNEJmx0 O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgcXVvdDsgZmxhZy4mYW1wO2x0O2JyJmFtcDtndDsm bHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7JmFt cDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7 ICZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtndDsgTm90ZXMmYW1wO2x0O2JyJmFtcDtndDsmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7IC0tLS0t JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7 Z3Q7ICZhbXA7YW1wO2d0OyBJbiB0aGUgY2FzZSBvZiBmYWNpbGl0eS1iYXNlZCBGUlIgdGhlIFBM UiBtdXN0IHNldCB0PTxicj4NCiZndDsgaGUgJmFtcDthbXA7cXVvdDtsb2NhPTNEJmx0O2JyJmd0 Ozxicj4NCiZndDsgJmFtcDtndDsgbCBwcm90ZWN0aW9uJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2Jy Jmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyBhdmFpbGFi bGUmYW1wO2FtcDtxdW90OyBmbGFnIGlmIGl0IGhhcyB0aGUgYnlwYXNzIHR1bm5lbD08YnI+DQom Z3Q7Jm5ic3A7IGF2YWlsYWJsZS4mYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0 O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyBJbnN0 cnVjdGlvbnM6JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyAtLS0tLS0tLS0tLS0tJmFtcDtsdDticiZhbXA7Z3Q7 Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyBU aGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAmYW1wO2FtcDtxdW90O1JlcG9ydD08 YnI+DQomZ3Q7IGVkJmFtcDthbXA7cXVvdDsuIElmIG5lY2U9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyBzc2FyeSwgcGxlYXNlJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4N CiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyB1c2UgJmFtcDthbXA7cXVv dDtSZXBseSBBbGwmYW1wO2FtcDtxdW90OyB0byBkaXNjdXNzIHdoZXRoZXI9PGJyPg0KJmd0OyZu YnNwOyBpdCBzaG91bGQgYmUgdmVyaWZpZT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 IGQgb3ImYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1w O2FtcDtndDsgJmFtcDthbXA7Z3Q7IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hl ZCwgdGhlIHZlcmlmeWluZyA9PGJyPg0KJmd0OyBwYXJ0eSAoSUVTRykmYW1wO2x0Oz0zRCZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IGJyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7IGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRo ZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCw9PGJyPg0KJmd0OyZuYnNwOyBpZiBuZWNlc3Nh cnk9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAuJmFtcDtsdDticiZhbXA7Z3Q7Jmx0 O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyZhbXA7 bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAm YW1wO2FtcDtndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mYW1wO2x0 O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFt cDthbXA7Z3Q7IFJGQzQwOTAgKGRyYWZ0LWlldGYtbXBscy1yc3ZwLWxzcC1mYXN0cmVyb3V0ZS0w NykmYW1wO2x0PTxicj4NCiZndDsgO2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1w O2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtn dDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyBUaXRsZT0zREMyPTNEQTAgPTNEQzI9M0RBMCA9 M0RDMj0zREEwID0zREMyPTNEQTAgPTNEPTxicj4NCiZndDsgQzI9M0RBMCA9M0RDMj0zREEwID0z REMyPTNEQTAgPTNEQzI9M0RBMDogRmFzPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg dCBSZXJvdXRlIEV4dGVuc2lvbnMgdG8gUlNWUC1URSBmb3IgTFNQIFR1bm5lbHMmYW1wO2x0O2Jy JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDth bXA7Z3Q7IFB1YmxpY2F0aW9uIERhdGU9M0RDMj0zREEwID0zREMyPTNEQTAgOiBNYXkgMjAwNSZh bXA7bHQ7PTxicj4NCiZndDsgYnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtndDsgQXV0aG9yKHMpPTNEQzI9M0RBMCA9M0RDMj0zREEw ID0zREMyPTNEQTAgPTNEQzI9M0RBMD08YnI+DQomZ3Q7Jm5ic3A7ID0zREMyPTNEQTAgPTNEQzI9 M0RBMDogUC4gUGFuLCBFZC4sID0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IEcuIFN3 YWxsb3csIEVkLiwgQS4gQXRsYXMsIEVkLiZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+ DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtndDsgQ2F0ZWdvcnk9M0RDMj0z REEwID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0zREEwID08YnI+DQomZ3Q7ID0zREMyPTNE QTAgPTNEQzI9M0RBMCA6IFBST1BPU0VEIFNUQU49M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1w O2d0OyBEQVJEJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyBTb3VyY2U9M0RDMj0zREEwID0zREMyPTNEQTAgPTNE QzI9M0RBMCA9M0RDMj0zREEwID08YnI+DQomZ3Q7ID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RD Mj0zREEwIDogTXVsdGlwcm89M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyB0b2NvbCBM YWJlbCBTd2l0Y2hpbmcmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1w O2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7IEFyZWE9M0RDMj0zREEwID0zREMyPTNEQTAg PTNEQzI9M0RBMCA9M0RDMj0zREEwID0zREM9PGJyPg0KJmd0OyAyPTNEQTAgPTNEQzI9M0RBMCA9 M0RDMj0zREEwID0zREMyPTNEQTAgOiBSb3U9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0 OyB0aW5nJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFt cDthbXA7Z3Q7ICZhbXA7YW1wO2d0OyBTdHJlYW09M0RDMj0zREEwID0zREMyPTNEQTAgPTNEQzI9 M0RBMCA9M0RDMj0zREEwID08YnI+DQomZ3Q7ID0zREMyPTNEQTAgPTNEQzI9M0RBMCA9M0RDMj0z REEwIDogSUVURiZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtndDsgVmVyaWZ5aW5nIFBhcnR5PTNEQzI9M0RBMCA9M0RD Mj0zREEwID0zREMyPTNEQTA6IElFUz08YnI+DQomZ3Q7IEcmYW1wO2x0O2JyJmFtcDtndDsmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7Z3Q7JmFtcDts dDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZh bXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ICZhbXA7bHQ7L2RpdiZhbXA7Z3Q7JmFtcDtsdDsvZGl2JmFtcDtndDsmYW1wO2FtcDtndDsg LS0wMDFhMTEzOTdhMmM5YmRhNmUwNTBhNmYzMWFlJmFtcDtsdDticiZhbXA7PTxicj4NCiZndDsg Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7IENvbnRlbnQtVHlw ZTogdGV4dC9odG1sOyBjaGFyc2V0PTNEM0QmYW1wO2FtcDtxdW90O1VURi04JmFtcDthbXA7cXVv dD08YnI+DQomZ3Q7IDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1w O2d0OyAmYW1wO2FtcDtndDsgQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50 YWJsZSZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7 YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZh bXA7YW1wO2d0OyAmYW1wO2FtcDtsdDtkaXYgZGlyPTNEM0QzRCZhbXA7YW1wO3F1b3Q7bHRyJmFt cDthbXA7cXVvdDsmYW1wO2FtcDtndDtIaSBZYWtvdj08YnI+DQomZ3Q7ICwmYW1wO2FtcDtsdDti ciZhbXA7YW1wO2d0OyZhbXA7YW1wO2x0O2JyJmFtcDthbXA7Z3Q7Q291bGQgPTNEJmx0O2JyJmd0 Ozxicj4NCiZndDsgJmFtcDtndDsgeW91IGNsYXJpZnkgeW91ciBwb2ludCBmb3IgdGhpcyBlcnI9 M0QzRCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7 YW1wO2d0OyBhdGE/PTNEM0RDMj0zRDNEQTAgSW4gUkZDIDQwOTAsIGluIHRoZSB0ZXJtaW5vbG9n eSBpdCBzYXlzOiZhbXA7YT08YnI+DQomZ3Q7IG1wO2x0O2JyJmFtcDthbXA7Z3Q7JmFtcDthbXA7 YW1wOz0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IHF1b3Q7IEJhY2t1cCBQYXRoOiA9 M0QzRCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7 YW1wO2d0OyBUaGUgTFNQIHRoYXQgaXMgcmVzcG9uc2libGUgZm9yIGJhY2tpbmcgdXAgb25lJmFt cDthbXA7bHQ7YnImYW1wO2FtcDs9PGJyPg0KJmd0OyBndDs9M0QzREMyPTNEM0RBMCA9M0QzRD0z RCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IEMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9 M0QzREMyPTNEM0QmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0 OyAmYW1wO2FtcDtndDsgPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0Qz REMyPTNEM0RBMCA9M0QzREMyPTxicj4NCiZndDsgPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0Qz REMyPTNEM0RBPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgMCA9M0QzREMyPTNEM0RB MCA9M0QzREMyPTNEM0RBMHByb3RlY3RlZCBMU1AuPTNEM0QmYW1wO2x0O2JyJmFtcDtndDsmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgPTNEM0RDMj0zRDNEQTAgQSBi YWNrdXAgcGF0aCByZWZlcnMgdG8gZWl0aGVyIGEgZGV0b3VyIExTUCZhbXA7YW09PGJyPg0KJmd0 OyBwO2x0O2JyJmFtcDthbXA7Z3Q7PTNEM0RDMj0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ID0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0QmYW1wO2x0O2Jy JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgPTNEM0RD Mj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTxi cj4NCiZndDsgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDPTNEJmx0O2JyJmd0 Ozxicj4NCiZndDsgJmFtcDtndDsgMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNE QTBvciBhIGJhY2t1cCB0PTNEM0QmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgdW5uZWwuJmFtcDthbXA7bHQ7YnImYW1wO2FtcDtndDsm YW1wO2FtcDtsdDticiZhbXA7YW1wO2d0Oz0zRDNEQzI9M0QzREEwIEJhY2s9PGJyPg0KJmd0OyB1 cCBUdW5uZWw6IFRoZSBMU1AgdGhhdCBpcyB1cz0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7IGVkIHRvIGJhY2t1cCB1cCBvbmUgbz0zRDNEJmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0 Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7IGYgdGhlIG1hbnkmYW1wO2FtcDtsdDti ciZhbXA7YW1wO2d0Oz0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRD08YnI+DQomZ3Q7 IDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyA9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRDNEQzI9 M0QzREEwID0zRDNEQzI9M0QzRCZhbXA7bHQ7Yj08YnI+DQomZ3Q7IHImYW1wO2d0OyZsdDticiZn dDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyA9M0QzREEwTFNQcyBpbiBtYW55LXRv LW9uZSBiYWNrdXAuJmFtcDthbXA7YW1wO3F1b3Q7JmFtcDthbXA7bHQ7ZGl2JmFtcDthPTxicj4N CiZndDsgbXA7Z3Q7JmFtcDthbXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2FtcDtsdDsvZGk9M0Qm bHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyB2JmFtcDthbXA7Z3Q7JmFtcDthbXA7bHQ7ZGl2 JmFtcDthbXA7Z3Q7VGhhbmtzLCZhbXA7YW1wO2x0Oy9kaXYmYW1wO2FtcDtndDsmYW1wO2FtcDts dDtkaXYmYW1wO2FtcD08YnI+DQomZ3Q7IDtndDtBPTNEM0QmYW1wO2x0O2JyJmFtcDtndDsmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgbGlhJmFtcDthbXA7bHQ7L2Rp diZhbXA7YW1wO2d0OyZhbXA7YW1wO2x0Oy9kaXYmYW1wO2FtcDtndDsmYW1wO2FtcDtsdDtkaXYg Y2xhc3M9PGJyPg0KJmd0OyA9M0QzRDNEJmFtcDthbXA7cXVvdDtnbWFpbF9leHRyYSZhbXA7YW1w O3F1b3Q7JmFtcDthbXA7Zz0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IHQ7JmFtcDth bXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2FtcDtsdDtkaXYgY2xhc3M9M0QzRDNEJmFtcDthbXA7 cXVvdDtnbWFpbF9xdW90ZSZhbXA7YW1wOz08YnI+DQomZ3Q7IHF1b3Q7JmFtcDthbXA7Z3Q7T249 M0QzRCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7 YW1wO2d0Oz0zREMyPTNEQTAgV2VkLCBEZWMgMTcsIDIwMTQgYXQgMzowNyBQTSwgUkZDIEVycmF0 YSBTeXN0ZW0gJmFtcDthbT08YnI+DQomZ3Q7IHA7bHQ7c3BhbiBkaXI9M0QzRDM9M0QmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyBEJmFtcDthbXA7cXVvdDtsdHImYW1wO2FtcDtxdW90OyZh bXA7YW1wO2d0OyZhbXA7YW1wO2FtcDtsdDsmYW1wO2FtcDtsdDthIGg9M0QzRCZhbXA7bHQ7YnIm YW1wO2d0Oz08YnI+DQomZ3Q7ICZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1w O2d0OyByZWY9M0QzRDNEJmFtcDthbXA7cXVvdDttYWlsdG86JmFtcDtsdDthIGhyZWY9M0QzRCZh bXA7cXVvdDttYWlsdG86Jmx0O2EgaHJlPTxicj4NCiZndDsgZj0zRCZxdW90O21haWx0bzo8YSBo cmVmPSJtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyI+cmZjLWVkaXRvckByZmMtZWRp dG9yLm9yZzwvYT4mcXVvdDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRv ci5vcmciPnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8L2E+Jmx0Oy9hJmd0OyZhbXA7cXVvdDsm YW1wOz08YnI+DQomZ3Q7IGd0O3JmYy09M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAm bHQ7YSBocmVmPTNEJnF1b3Q7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzplZGl0b3JAcmZjLWVkaXRv ci5vcmciPmVkaXRvckByZmMtZWRpdG9yLm9yZzwvYT4mcXVvdDsmZ3Q7PGEgaHJlZj0ibWFpbHRv OmVkaXRvckByZmMtZWRpdG9yLm9yZyI+ZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9hPiZsdDsvYSZn dDsmYW1wO2x0Oz08YnI+DQomZ3Q7IC9hJmFtcDtndDsmYW1wO2FtcDtxdW90OyB0YXJnZXQ9M0Qz RDNEJmFtcDthbXA7cXVvdDtfYmxhbmsmYW1wO2FtcDtxdW90OyZhbXA7YW1wO2d0O3JmYy1lZGl0 b3I9PGJyPg0KJmd0OyA9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyBAcmZjLWU9M0Qz RCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1w O2d0OyAmYW1wO2x0O2EgaHJlZj0zRDNEJmFtcDtxdW90OyZsdDthIGhyZWY9M0QmcXVvdDs8YSBo cmVmPSJodHRwOi8vZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RpdG9yLm9yZzwv YT4mcXVvdDsgdGFyZ2V0PTNEJnF1b3Q7Xz08YnI+DQomZ3Q7IGJsYW5rJnF1b3Q7Jmd0OzxhIGhy ZWY9Imh0dHA6Ly9kaXRvci5vcmciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGl0b3Iub3JnPC9h PiZsdDsvYSZndDsmYW1wO3F1b3Q7IHRhcmdldD0zRDNEJmFtcDtxdW90O19ibGFuayZhbXA7cXVv dDsmYW1wO2d0OyZsdDthIGhyZWY9PGJyPg0KJmd0OyA9M0QmcXVvdDs8YSBocmVmPSJodHRwOi8v ZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RpdG9yLm9yZzwvYT4mcXVvdDsgdGFy Z2V0PTNEJnF1b3Q7X2JsYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly9kaXRvci5vcmciIHRh cmdldD0iX2JsYW5rIj5kaXRvci5vcmc8L2E+Jmx0Oy9hJmd0OyZhbXA7bHQ7L2EmYW1wO2d0OyZh bXA7YW1wO2x0Oy9hJmFtcDthPTxicj4NCiZndDsgbXA7Z3Q7PTNEJmx0O2JyJmd0Ozxicj4NCiZn dDsgJmFtcDtndDsgJmFtcDthbXA7YW1wO2d0OyZhbXA7YW1wO2x0Oy9zcGFuJmFtcDthbXA7Z3Q7 IHdyb3RlOiZhbXA7YW1wO2x0O2JyJmFtcDthbXA7Z3Q7JmFtcDthbXA7bHQ7YmxvYz08YnI+DQom Z3Q7IGtxdW90ZSBjbGFzcz0zRDNEM0QmYW1wO2FtcDtxdW90O2dtYWlsXz0zRCZsdDticiZndDs8 YnI+DQomZ3Q7ICZhbXA7Z3Q7IHF1b3RlJmFtcDthbXA7cXVvdDsgc3R5bGU9M0QzRCZhbXA7bHQ7 YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyA9M0Qz RDNEJmFtcDthbXA7cXVvdDttYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZD08YnI+DQomZ3Q7IDtwYWRkaW5nLWxlZnQ6MT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7IGV4JmFtcDthbXA7cXVvdDsmYW1wO2FtcDtndDtUaGUgZm9sbD0zRDNEJmFtcDtsdDti ciZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgb3dpbmcgZXJyYXRhIHJlcG9y dCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzQwOTAsJmFtcDthbXA7bHQ7YnImYW1wO2FtcDtn dDsmYW1wOz08YnI+DQomZ3Q7IGx0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1w O2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7YW1wO3F1b3Q7RmFzdCBSZXJvdXRlIEV4dGVuc2lv bnMgdG8gUlNWUC1URSBmb3IgTFNQIFR1bm49PGJyPg0KJmd0OyBlbHMmYW1wO2FtcDthbXA7cXVv dDs9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAuJmFtcDthbXA7bHQ7YnImYW1wO2Ft cDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1w O2FtcDtndDsgJmFtcDthbXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0mYW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7bHQ7Yj08 YnI+DQomZ3Q7IHImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1w O2d0OyBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDomYW1wO2FtcDtsdDti ciZhbXA7YW1wO2d0OyZhbXA7bHQ7PTxicj4NCiZndDsgYnImYW1wO2d0OyZsdDticiZndDs8YnI+ DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtsdDthIGhyZWY9M0QzRDNEJmFt cDthbXA7cXVvdDsmYW1wO2x0O2EgaHJlZj0zRDNEJmFtcDtxdW90OyZsdDthIGhyZWY9PGJyPg0K Jmd0OyA9M0QmcXVvdDs8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9z ZWFyYz0zRCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRh X3NlYXJjPTNEPC9hPiZxdW90OyB0YXJnZXQ9M0QmcXVvdDtfYmxhbmsmcXVvdDsmZ3Q7PGEgaHJl Zj0iaHR0cDovL3d3dyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3c8L2E+PTxicj4NCiZndDsg LjxhIGhyZWY9Imh0dHA6Ly9yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmM9M0QiIHRhcmdldD0i X2JsYW5rIj5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmM9M0Q8L2E+Jmx0Oy9hJmd0OyZsdDti ciZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IGgucGhwP3JmYz0zRDNEM0Q0MDkwJmFtcDthbXA7YW1w O2FtcDtlaWQ9M0QzRCZhbXA7cXVvdDsgdGFyZ2V0PTNEM0QmYW1wO3F1b3Q7X2JsYW49PGJyPg0K Jmd0OyBrJmFtcDtxdW90OyZhbXA7Z3Q7Jmx0O2EgaHJlZj0zRCZxdW90OzxhIGhyZWY9Imh0dHA6 Ly93d3cucmZjLWVkaXRvciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cucmZjLWVkaXRvcjwv YT4uJnF1b3Q7IHRhcmdldD0zRCZxdW90O19ibGFuayZxdW90OyZndDs8YSBocmVmPSJodHRwOi8v d3d3LiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuPC9hPj08YnI+DQomZ3Q7IHJmYy1lZGl0 b3IuJmx0Oy9hJmd0Oz0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IG9yZy9lcnJhdGFf c2VhcmNoLnBocD9yZmM9M0QzRDNENDA5MCZhbXA7YW1wO2FtcDthbXA7ZWlkPTNEM0QmYW1wO2x0 Oy9hJmFtcDtndDsmYW1wO2x0PTxicj4NCiZndDsgO2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgPTNEM0QzRDQyMDMmYW1wO2FtcDtxdW90OyB0YXJn ZXQ9M0QzRDNEJmFtcDthbXA7cXVvdDtfYmxhbmsmYW1wO2FtcDtxdW90Oz08YnI+DQomZ3Q7ICZh bXA7YW1wO2d0OyZhbXA7bHQ7YSBocmVmPTNEM0QmYW1wO3F1b3Q7Jmx0O2EgaHJlZj0zRCZxdW90 OzxhIGhyZWY9Imh0dHA6Ly93d3ciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3PC9hPiZxdW90 OyB0YXJnZXQ9M0QmcXVvdDtfYmxhbmsmcXVvdDsmZ3Q7aHR0cDo9PGJyPg0KJmd0OyAvL3d3dyZs dDsvYSZndDs9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAuJmx0O2EgaHJlZj0zRCZx dW90OzxhIGhyZWY9Imh0dHA6Ly9yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9 M0QzRCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNo LnBocD9yZmM9M0QzRDwvYT4mcXVvdDsgdGFyZ2V0PTxicj4NCiZndDsgPTNEJnF1b3Q7X2JsYW5r JnF1b3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly9yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBo cD9yZmM9M0QzRCIgdGFyZ2V0PSJfYmxhbmsiPnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gu cGhwP3JmYz0zRDNEPC9hPiZsdDsvYSZndDsmYW1wO3F1b3Q7IHRhcmdldD0zRDNEPTxicj4NCiZn dDsgJmFtcDtxdW90O19ibGFuayZhbXA7cXVvdDsmYW1wO2d0OyZsdDthIGhyZWY9M0QmcXVvdDs8 YSBocmVmPSJodHRwOi8vd3d3LnJmYy0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnJmYy08 L2E+JnF1b3Q7IHRhcmdldD0zRCZxdW90O19ibGFuayZxdW90OyZndDs8YSBocmVmPSJodHRwOi8v Ij5odHRwOi8vPC9hPj08YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLSUzYy9hJTNl PTNEJTNjYnIiPnd3dy5yZmMtJmx0Oy9hJmd0Oz0zRCZsdDticjwvYT4mZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyAmbHQ7YSBocmVmPTNEJnF1b3Q7PGEgaHJlZj0iaHR0cDovL2VkaXRvci5vcmcvZXJy YXRhX3NlYXJjaC5waHA/cmZjPTNEM0QiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZWRpdG9yLm9y Zy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9M0QzRDwvYT4mcXVvdDsgdGFyZ2V0PTNEJnF1b3Q7X2Js PTxicj4NCiZndDsgYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly9lZGl0b3Iub3JnL2VycmF0 YV9zZWFyY2gucGhwP3JmYz0zRDNEIiB0YXJnZXQ9Il9ibGFuayI+ZWRpdG9yLm9yZy9lcnJhdGFf c2VhcmNoLnBocD9yZmM9M0QzRDwvYT4mbHQ7L2EmZ3Q7JmFtcDtsdDsvYSZhbXA7Z3Q7JmFtcDts dDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ID0z RDNEM0Q0MDkwJmFtcDthbXA7YW1wO2FtcDtlaWQ9M0QzRDNENDIwMyZhbXA7YW1wO2x0Oy9hJmFt cDthbXA7Z3Q7JmFtcDthbXA7PTxicj4NCiZndDsgbHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2Jy JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDth bXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0 OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0mYW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7bHQ7Yj08YnI+DQomZ3Q7IHImYW1w O2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyBUeXBlOiBUZWNo bmljYWwmYW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZn dDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyBSZXBvcnRlZCBieTogWWFrb3YgUmVr aHRlciAmYW1wO2FtcDthbXA7bHQ7JmFtcDthbXA7bHQ7YSBocmVmPTNEM0QzRCZhbXA7PTxicj4N CiZndDsgYW1wO3F1b3Q7bWFpbHRvOiZhbXA7bHQ7YSBocmVmPTNEJmx0O2JyJmd0Ozxicj4NCiZn dDsgJmFtcDtndDsgPTNEM0QmYW1wO3F1b3Q7bWFpbHRvOiZsdDthIGhyZWY9M0QmcXVvdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOnlha292QGp1bmlwZXIubmV0Ij55YWtvdkBqdW5pcGVyLm5ldDwv YT4mcXVvdDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOnlha292QGp1bmlwZXIubiI+eWFrb3ZAanVuaXBl ci5uPC9hPj08YnI+DQomZ3Q7IGV0Jmx0Oy9hJmd0OyZhbXA7cXVvdDsmYW1wO2d0OyZsdDthIGhy ZWY9M0QmcXVvdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnlha292QGp1bmlwZXIubmV0Ij55YWtv dkBqdW5pcGVyLm5ldDwvYT4mcXVvdDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOnlha292QGp1bmlwZXIu bmV0Ij55YWtvdkBqdW5pcGVyLm5ldDwvYT4mbHQ7L2EmZ3Q7JmFtcDs9PGJyPg0KJmd0OyBsdDsv YSZhbXA7Z3Q7JmFtcDthbXA7cXVvdDsmYW1wO2FtcDtndDt5YWtvdkBqPTNEM0QmYW1wO2x0O2Jy JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDts dDthIGhyZWY9M0QzRCZhbXA7cXVvdDsmbHQ7YSBocmVmPTNEJnF1b3Q7PGEgaHJlZj0iaHR0cDov L3VuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdW5pcGVyLm5ldDwvYT4mcXVvdDsg dGFyZ2V0PTNEJnF1b3Q7PTxicj4NCiZndDsgX2JsYW5rJnF1b3Q7Jmd0OzxhIGhyZWY9Imh0dHA6 Ly91bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3VuaXBlci5uZXQ8L2E+Jmx0Oy9h Jmd0OyZhbXA7cXVvdDsgdGFyZ2V0PTNEM0QmYW1wO3F1b3Q7X2JsYW5rJmFtcDtxdW90OyZhbXA7 Z3Q7Jmx0O2EgaHJlPTxicj4NCiZndDsgZj0zRCZxdW90OzxhIGhyZWY9Imh0dHA6Ly91bmlwZXIu bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3VuaXBlci5uZXQ8L2E+JnF1b3Q7IHRhcmdldD0z RCZxdW90O19ibGFuayZxdW90OyZndDs8YSBocmVmPSJodHRwOi8vdW5pcGVyLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPnVuaXBlci5uZXQ8L2E+Jmx0Oy9hJmd0OyZhbXA7bHQ7L2EmYW1wO2d0OyZhbXA7 YW1wO2x0Oy89PGJyPg0KJmd0OyBhJmFtcDthbXA7Zz0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZh bXA7Z3Q7IHQ7JmFtcDthbXA7YW1wO2d0OyZhbXA7YW1wO2x0O2JyJmFtcDthbXA7Z3Q7JmFtcDts dDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZh bXA7YW1wO2x0O2JyJmFtcDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4N CiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7IFNlY3Rpb246IDYmYW1wO2FtcDtsdDticiZhbXA7 YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZh bXA7YW1wO2d0OyAmYW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZs dDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyBPcmlnaW5hbCBUZXh0JmFt cDthbXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0K Jmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgLS0tLS0tLS0tLS0tLSZhbXA7YW1wO2x0O2JyJmFt cDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDthbXA7Z3Q7IFdoZW5ldmVyIHRoZSBQTFIgaGFzIGEgYmFja3VwIHBhdGggYXZhaWxhYmxl LCB0aGUgUExSIE1VU1Qgc2U9PGJyPg0KJmd0OyB0JmFtcDthbXA7bHQ7YnImYW1wO2FtcDtnPTNE Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgdDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgdGhlICZhbXA7YW1wO2FtcDtxdW90 O2xvY2FsIHByb3RlY3Rpb24gYXZhaWxhYmxlJmFtcDthbXA7YW1wO3F1b3Q7IGZsPTxicj4NCiZn dDsgYWcuJmFtcDthbXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnIm Z3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7bHQ7YnImYW1wO2Ft cDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1w O2FtcDtndDsgJmFtcDthbXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgQ29ycmVjdGVkIFRleHQmYW1w O2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQom Z3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAtLS0tLS0tLS0tLS0tLSZhbXA7YW1wO2x0O2JyJmFt cDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsg JmFtcDthbXA7Z3Q7IFdoZW5ldmVyIHRoZSBQTFIgaGFzIGEgb25lLXRvLW9uZSBiYWNrdXAgTFNQ IG9yIGJ5cGFzcyB0dW5uZWw9PGJyPg0KJmd0OyAmYW1wO2FtcDtsdDticiZhbXA7YW1wO2d0PTNE Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgOyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZn dDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyBhdmFpbGFibGUsIHRoZSBQTFIgTVVT VCBzZXQgdGhlICZhbXA7YW1wO2FtcDtxdW90O2xvY2FsIHByb3RlY3Rpbz08YnI+DQomZ3Q7IG4g YXZhaWxhYmxlJmFtcDthbXA7YT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IG1wO3F1 b3Q7IGZsYWc9M0QzRCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ICZhbXA7YW1wO2d0OyAuJmFtcDthbXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFt cDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7 bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyAmYW1wO2FtcDtndDsgJmFtcDthbXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2Jy JmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgTm90ZXMm YW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+ DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAtLS0tLSZhbXA7YW1wO2x0O2JyJmFtcDthbXA7 Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDth bXA7Z3Q7IEluIHRoZSBjYXNlIG9mIGZhY2lsaXR5LWJhc2VkIEZSUiB0aGUgUExSIG11c3Qgc2V0 IHRoZSAmYW1wO2FtcDthPTxicj4NCiZndDsgbXA7cXVvdDtsb2NhbD0zRCZsdDticiZndDs8YnI+ DQomZ3Q7ICZhbXA7Z3Q7PUMyPUEwIHByb3RlY3RpPTNEM0QmYW1wO2x0O2JyJmFtcDtndDsmbHQ7 YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgb24gYXZhaWxhYmxlJmFtcDth bXA7YW1wO3F1b3Q7IGZsYWcgaWYgaXQgaGFzIHRoZSBieXBhc3MgdHVubmVsIGE9PGJyPg0KJmd0 OyB2YWlsYWJsZS4mYW1wO2FtcDtsdDs9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyBi ciZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1w O2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyBJbnN0cnVjdGlv bnM6JmFtcDthbXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgLS0tLS0tLS0tLS0tLSZhbXA7YW1wO2x0 O2JyJmFtcDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFt cDtndDsgJmFtcDthbXA7Z3Q7IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICZh bXA7YW1wO2FtcDtxdW90O1JlcG9ydGVkJmFtcDthbT08YnI+DQomZ3Q7IHA7YW1wO3F1b3Q7LiBJ ZiBuPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgZWNlc3NhcnksIHBsZT0zRDNEJmFt cDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7 IGFzZSZhbXA7YW1wO2x0O2JyJmFtcDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0 Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7IHVzZSAmYW1wO2FtcDthbXA7cXVvdDtS ZXBseSBBbGwmYW1wO2FtcDthbXA7cXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyID08YnI+DQomZ3Q7 IGl0IHNob3VsZCBiZSB2ZXJpPTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgZmllZCBv ciZhbXA7YW1wO2x0O2JyJmFtcDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24g aXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAoSUU9PGJyPg0KJmd0OyBTRykmYW1wO2Ft cDtsdDticj0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyZhbXA7 bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyBj YW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5l Y2VzPTxicj4NCiZndDsgc2FyeS4mYW1wO2FtcDtsdDs9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAm YW1wO2d0OyBiciZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQom Z3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAmYW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7 bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZhbXA7YW1wO2x0O2JyJmFtcDth bXA7Z3Q7JmFtcDtsdDtiPTxicj4NCiZndDsgciZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsg JmFtcDtndDsgJmFtcDthbXA7Z3Q7IFJGQzQwOTAgKGRyYWZ0LWlldGYtbXBscy1yc3ZwLWxzcC1m YXN0cmVyb3V0ZS0wNykmYW1wO2FtcDtsdDticiZhbXA7YT08YnI+DQomZ3Q7IG1wO2d0OyZhbXA7 bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZhbXA7YW1wO2x0O2JyJmFtcDth bXA7Z3Q7JmFtcDtsdDtiPTxicj4NCiZndDsgciZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsg JmFtcDtndDsgJmFtcDthbXA7Z3Q7IFRpdGxlPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAg PTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDM9PGJyPg0KJmd0OyBEQTAgPTNEM0RDMj0zRDNEQTAg PTNEM0RDMj0zRDNEQTA9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0Oz1DMj1BMCA9M0Qz REMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMDogRmFzdCBSZXJvdXRlID0zRDNEJmFtcDtsdDticiZh bXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7IEV4dGVuc2lv bnMgdG8gUlNWUC1URSBmb3IgTFNQIFR1bm5lbHMmYW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZh bXA7bHQ7YnI9PGJyPg0KJmd0OyAmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7YW1wO2d0OyBQdWJsaWNhdGlvbiBEYXRlPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNE QTAgOiBNYXkgMjAwNSZhbXA7YW1wOz08YnI+DQomZ3Q7IGx0O2JyJmFtcDthbXA7Z3Q7JmFtcDts dDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7IEF1 dGhvcihzKT0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRDNE QzI9PGJyPg0KJmd0OyA9M0QzREEwID0zRDNEQzI9M0QzREEwID0zRDNEQzI9M0QmbHQ7YnImZ3Q7 PGJyPg0KJmd0OyAmYW1wO2d0OyA9M0QzREEwOiBQLiBQYW4sIEVkLiwgRy4gU3dhbGxvdz0zRDNE JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7 Z3Q7ICwgRWQuLCBBLiBBdGxhcywgRWQuJmFtcDthbXA7bHQ7YnImYW1wO2FtcDtndDsmYW1wO2x0 O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyAmYW1wO2FtcDtndDsgQ2F0 ZWdvcnk9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMy PTxicj4NCiZndDsgPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEJmx0O2JyJmd0Ozxi cj4NCiZndDsgJmFtcDtndDsgPTNEM0RBMCA6IFBST1BPU0VEIFNUQU5EQVJEJmFtcDthbXA7bHQ7 YnImYW1wO2FtcDtndDsmYW1wO2x0O2JyJmFtcDtndDsmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1w O2d0OyAmYW1wO2FtcDtndDsgU291cmNlPTNEM0RDMj0zRDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNE M0RDMj0zRDNEQTAgPTNEM0RDMj0zRD08YnI+DQomZ3Q7IDNEQTAgPTNEM0RDMj0zRDNEQTAgPTNE M0RDMj0zRDNEQT0zRCZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7IDAgPTNEM0RDMj0zRDNE QTAgOiBNdWx0aXByb3RvY29sIExhYmU9M0QzRCZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8 YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyBsIFN3aXRjaGluZyZhbXA7YW1wO2x0O2Jy JmFtcDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtn dDsgJmFtcDthbXA7Z3Q7IEFyZWE9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMy PTNEM0RBMCA9M0QzREMyPTNEM0Q9PGJyPg0KJmd0OyBBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMy PTNEM0RBMCA9M0QmbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmYW1wO2d0OyA9M0QzREMyPTNEM0RBMCA9 M0QzREMyPTNEM0RBMCA6IFJvdXRpbmcmYW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7bHQ7 YnImYW1wO2d0OyZsdDticj08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7 YW1wO2d0OyBTdHJlYW09M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RB MCA9M0QzREMyPTNEPTxicj4NCiZndDsgM0RBMCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RB PTNEJmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgMCA9M0QzREMyPTNEM0RBMCA6IElFVEYm YW1wO2FtcDtsdDticiZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+ DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7YW1wO2d0OyBWZXJpZnlpbmcgUGFydHk9M0QzREMyPTNEM0RB MCA9M0QzREMyPTNEM0RBMCA9M0QzREMyPTNEM0RBMDogPTxicj4NCiZndDsgSUVTRyZhbXA7YW1w O2x0O2JyJmFtcDthbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsg JmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7YW1wO2x0O2JyJmFtcDthbXA7Z3Q7JmFtcDtsdDti ciZhbXA7Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgJmFtcDthbXA7Z3Q7ICZhbXA7 YW1wO2x0Oy9ibG9ja3F1b3RlJmFtcDthbXA7Z3Q7JmFtcDthbXA7bHQ7L2RpdiZhbXA7YW1wO2d0 OyZhbXA7YW1wO2x0O2JyJmFtcDthbXA9PGJyPg0KJmd0OyA7Z3Q7JmFtcDthbXA7bHQ7L2RpdiZh bXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7 ICZhbXA7YW1wO2d0OyZhbXA7bHQ7YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7ICZhbXA7YW1wO2d0OyAtLTAwMWExMTM5N2EyYzliZGE2ZTA1MGE2ZjMxYWUtLSZhbXA7bHQ7 YnImYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7Z3Q7ICZhbXA7bHQ7L2Jsb2NrcXVv dGUmYW1wO2d0OyZhbXA7bHQ7L2RpdiZhbXA7Z3Q7JmFtcDtsdDticiZhbXA7Z3Q7JmFtcDtsdDsv ZGl2JmFtcDtndDsmYW1wO2x0Oy9kaXYmYW1wO2d0OyZsdDticiZndDs8YnI+DQomZ3Q7ICZhbXA7 Z3Q7Jmx0O2JyJmd0Ozxicj4NCiZndDsgJmFtcDtndDsgLS0wNDdkN2I1ZDk5YTMzYTkxNGIwNTBh NzAxNjRlLS0mbHQ7YnImZ3Q7PGJyPg0KJmd0OyAmbHQ7L2Jsb2NrcXVvdGUmZ3Q7Jmx0Oy9kaXYm Z3Q7Jmx0O2JyJmd0OyZsdDsvZGl2Jmd0OyZsdDsvZGl2Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IC0tMDAxYTExYzFlOWVlNDBmZDE5MDUwYTcwNjhjOS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM2PR0501MB1662335A5977C94F9773CC94BE580DM2PR0501MB1662_-- From nobody Mon Jan 5 13:45:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8DE1A8ACE; Mon, 5 Jan 2015 13:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhODLvvcptPa; Mon, 5 Jan 2015 13:40:44 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA221A8ACC; Mon, 5 Jan 2015 13:40:44 -0800 (PST) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t05LehqE030951; Mon, 5 Jan 2015 21:40:43 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id CD81C56048B; Mon, 5 Jan 2015 21:40:43 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <001f01d0276b$c94e24f0$5bea6ed0$@olddog.co.uk> References: <001f01d0276b$c94e24f0$5bea6ed0$@olddog.co.uk> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #801930 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: amanda.baber@icann.org To: adrian@olddog.co.uk, iesg@ietf.org, mpls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Mon, 5 Jan 2015 21:40:43 +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BkbFoHd7mZsqHuEOcrlimv8yc0E X-Mailman-Approved-At: Mon, 05 Jan 2015 13:45:39 -0800 Subject: [mpls] [IANA #801930] IANA action on Errata Report 4012 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 21:40:45 -0000 Hi, Resending this to the IESG and the MPLS list as well as Adrian: We've assigned the following in the Global Flags registry: 13 Validate Reverse Path [RFC6426][RFC Errata 4012] please see http://www.iana.org/assignments/mpls-lsp-ping-parameters Best regards, Amanda Baber IANA Request Specialist ICANN From nobody Mon Jan 5 20:27:11 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FB61A1A2D; Mon, 5 Jan 2015 20:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Mq9JxArTyfF; Mon, 5 Jan 2015 20:27:02 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78681A1A1B; Mon, 5 Jan 2015 20:27:02 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.169.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5863F18013B8; Tue, 6 Jan 2015 05:26:59 +0100 (CET) Message-ID: <54AB640C.6040006@pi.nu> Date: Tue, 06 Jan 2015 12:26:52 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: iana-issues@iana.org, adrian@olddog.co.uk, iesg@ietf.org, mpls@ietf.org References: <001f01d0276b$c94e24f0$5bea6ed0$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VoaQBm7n9woNHYZM9HlFltq3VEk Subject: Re: [mpls] [IANA #801930] IANA action on Errata Report 4012 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 04:27:05 -0000 Amanda, Tnx - this is what it should have from the start if we had not fumbled. /Loa On 2015-01-06 05:40, Amanda Baber via RT wrote: > Hi, > > Resending this to the IESG and the MPLS list as well as Adrian: > > We've assigned the following in the Global Flags registry: > > 13 Validate Reverse Path [RFC6426][RFC Errata 4012] > > please see > http://www.iana.org/assignments/mpls-lsp-ping-parameters > > Best regards, > > Amanda Baber > IANA Request Specialist > ICANN > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jan 6 01:11:21 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481771A0079 for ; Tue, 6 Jan 2015 01:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HncpTOxt8oC9 for ; Tue, 6 Jan 2015 01:11:03 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 455651A1F01 for ; Tue, 6 Jan 2015 01:11:03 -0800 (PST) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t069B2Rm001393 for ; Tue, 6 Jan 2015 18:11:02 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 933895F591 for ; Tue, 6 Jan 2015 18:11:02 +0900 (JST) Received: from imail1.m.ecl.ntt.co.jp (imail1.m.ecl.ntt.co.jp [129.60.5.246]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 86CBD5F587 for ; Tue, 6 Jan 2015 18:11:02 +0900 (JST) Received: from [129.60.21.195] (neba-hp-shiomoto.silab.ecl.ntt.co.jp [129.60.21.195]) by imail1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t069B2Cf015482 for ; Tue, 6 Jan 2015 18:11:02 +0900 Message-ID: <54ABA75C.8050501@lab.ntt.co.jp> Date: Tue, 06 Jan 2015 18:14:04 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eV-eXZ7yrCeKXh7u3G4aNLE0V1s Subject: [mpls] Call for Presentation: iPOP 2015 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:11:06 -0000 [Apologies, if you receive multiple copies of this CFP] --------------------------------------- Call for Presentation 11th International Conference on IP + Optical Network (iPOP 2015) April 20-22, 2015 Okinawa Jichikaikan, Naha Okinawa Japan http://www.pilab.jp/ipop2015/ Important Dates: Submission deadline of one-page abstract: January 16, 2015 Notification of acceptance: February 23, 2015 Submission deadline of final presentation slides: March 13, 2015 Following the successful events of iPOP, the 11th Conference on IP+Optical Network (iPOP 2015) will be held at Okinawa Jichikaikan, Naha Okinawa Japan, April 20-22, 2015. The conference has been provided opportunities for both of the industry and the academia to share their knowledge, new findings, and experiences on the state-of-the-art IP and optical networking technologies for these ten years. The Technical Program Committee for iPOP 2015 is soliciting presentation proposals for this conference. Architecture and protocol designs, experiments/PoCs/field trials, theories/algorithms, implementations, and operational experiences are solicited. The topics of the conference will include but not be limited to the following: * Control plane (MPLS/GMPLS, OpenFlow, etc) * SDN for packet and optical transport networks * MLN (Multi-Layer Network), MRN (Multi-Region Network) * TE (Traffic Engineering), PCE (Path Computation Element) * Network abstraction/virtualization * Flex-grid, elastic optical networks * Optical networking/switching for cloud services * Data center and WAN orchestration * Carrier Ethernet and MPLS-TP for backhauling * Service function chaining for mobile networks * Security * QoS (Quality of Service)/QoE (Quality of Experience) * Network operation and management * Standardization/interoperability * Open Source Software (OSS) for SDN/NFV * DevOps Submit an extended abstract (400 words, 1 page), including figures and diagrams, speaker’s name, affiliation, and contact information, to the Technical Program Committee: ipop2015-cfp@pilab.jp. Please see http://www.pilab.jp/ipop2015/ for more details. ------------------------------------------------------------------------ -- Kohei Shiomoto, Ph.D Senior Manager, Communication Traffic & Service Quality Project NTT Network Technology Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION TEL +81-422-59-4402 FAX +81-422-59-6364 From nobody Tue Jan 6 05:35:50 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9911A1A56; Mon, 5 Jan 2015 20:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8JvrD7kEkq2; Mon, 5 Jan 2015 20:51:54 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31C01A1A3D; Mon, 5 Jan 2015 20:51:53 -0800 (PST) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t064prgh022241; Tue, 6 Jan 2015 04:51:53 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id B18A65604B4; Tue, 6 Jan 2015 04:51:53 +0000 (UTC) RT-Owner: amanda.baber From: "Loa Andersson via RT" In-Reply-To: <54AB640C.6040006@pi.nu> References: <001f01d0276b$c94e24f0$5bea6ed0$@olddog.co.uk> <54AB640C.6040006@pi.nu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #801930 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: loa@pi.nu To: adrian@olddog.co.uk, iesg@ietf.org, mpls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Tue, 6 Jan 2015 04:51:53 +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rzs7Fxyws5pv-evC-J3m6wfPkTs X-Mailman-Approved-At: Tue, 06 Jan 2015 05:35:48 -0800 Subject: Re: [mpls] [IANA #801930] IANA action on Errata Report 4012 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 04:51:55 -0000 Amanda, Tnx - this is what it should have from the start if we had not fumbled. /Loa On 2015-01-06 05:40, Amanda Baber via RT wrote: > Hi, > > Resending this to the IESG and the MPLS list as well as Adrian: > > We've assigned the following in the Global Flags registry: > > 13 Validate Reverse Path [RFC6426][RFC Errata 4012] > > please see > http://www.iana.org/assignments/mpls-lsp-ping-parameters > > Best regards, > > Amanda Baber > IANA Request Specialist > ICANN > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jan 6 05:35:52 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC11A1BEC; Tue, 6 Jan 2015 03:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec_8ktokes1o; Tue, 6 Jan 2015 03:01:30 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637811A9154; Tue, 6 Jan 2015 03:01:30 -0800 (PST) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t06B1UYx005457; Tue, 6 Jan 2015 11:01:30 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id 2C425560D7C; Tue, 6 Jan 2015 11:01:30 +0000 (UTC) RT-Owner: amanda.baber From: "adrian@olddog.co.uk via RT" In-Reply-To: <035201d0299a$bb511520$31f33f60$@olddog.co.uk> References: <001f01d0276b$c94e24f0$5bea6ed0$@olddog.co.uk> <035201d0299a$bb511520$31f33f60$@olddog.co.uk> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #801930 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: adrian@olddog.co.uk To: iesg@ietf.org, mpls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Tue, 6 Jan 2015 11:01:30 +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Q2-M_YiDlPlmVREmK7b4MnzQ1Go X-Mailman-Approved-At: Tue, 06 Jan 2015 05:35:48 -0800 Subject: Re: [mpls] [IANA #801930] IANA action on Errata Report 4012 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 11:01:33 -0000 Thanks Amanda, Happy Three Kings Day. Adrian > -----Original Message----- > From: Amanda Baber via RT [mailto:iana-issues@iana.org] > Sent: 05 January 2015 21:41 > To: adrian@olddog.co.uk; iesg@ietf.org; mpls@ietf.org > Subject: [IANA #801930] IANA action on Errata Report 4012 > > Hi, > > Resending this to the IESG and the MPLS list as well as Adrian: > > We've assigned the following in the Global Flags registry: > > 13 Validate Reverse Path [RFC6426][RFC Errata 4012] > > please see > http://www.iana.org/assignments/mpls-lsp-ping-parameters > > Best regards, > > Amanda Baber > IANA Request Specialist > ICANN From nobody Tue Jan 6 10:45:54 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A921A1B20; Tue, 6 Jan 2015 10:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn6clSGbDD3C; Tue, 6 Jan 2015 10:45:40 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 95AE21A1B1E; Tue, 6 Jan 2015 10:45:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CDF95180448; Tue, 6 Jan 2015 10:45:15 -0800 (PST) To: yakov@juniper.net, ppan@hammerheadsystems.com, swallow@cisco.com, aatlas@avici.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150106184515.CDF95180448@rfc-editor.org> Date: Tue, 6 Jan 2015 10:45:15 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vgZOtNLDKd6AMTVoyxrpEvjUSoI Cc: mpls@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Errata Verified] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 18:45:52 -0000 The following errata report has been verified for RFC4090, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4090&eid=4203 -------------------------------------- Status: Verified Type: Technical Reported by: Yakov Rekhter Date Reported: 2014-12-17 Verified by: Alia Atlas (IESG) Section: 6 Original Text ------------- Whenever the PLR has a backup path available, the PLR MUST set the "local protection available" flag. Corrected Text -------------- Whenever the PLR has a backup path available, the PLR MUST set the "local protection available" flag. For example, if the PLR has determined to use a bypass tunnel and set up the necessary local forwarding state to be able to use it as a backup path, then that PLR has a backup path available. Notes ----- In the case of facility-based FRR the PLR must set the "local protection available" flag if it has the bypass tunnel available and the local forwarding state is set up. -------------------------------------- RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07) -------------------------------------- Title : Fast Reroute Extensions to RSVP-TE for LSP Tunnels Publication Date : May 2005 Author(s) : P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Jan 6 12:50:13 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FC61A1BA2 for ; Tue, 6 Jan 2015 12:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk6LcPiu2uVj for ; Tue, 6 Jan 2015 12:50:07 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573F51A044F for ; Tue, 6 Jan 2015 12:50:01 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-bf-54abec812770 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 11.C6.25146.18CEBA45; Tue, 6 Jan 2015 15:09:05 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 15:49:58 -0500 From: Uma Chunduri To: "adrian@olddog.co.uk" , "l.wood@surrey.ac.uk" , "david.black@emc.com" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4g5tkJK6AgABd/QCAADiAgIAAFPfggAEzewCAAC4IgIAGNx+w Date: Tue, 6 Jan 2015 20:49:58 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se> References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> In-Reply-To: <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPuG7jm9UhBpvPGlv86LnBbLH18Fp2 i+O7fzJZ3Fq6ktWBxePIkdksHkuW/GTyWLF5JaPH0Sm3mQJYorhsUlJzMstSi/TtErgyPvTc ZCtYpVSxrXcnewPjJ+kuRk4OCQETiaMH5zJB2GISF+6tZ+ti5OIQEjjCKLH8/nYWCGcZo8Tc 71fYQarYBPQkPk79yQ6SEBFYxygx+dx1sHZhgXSJBetnsoHYIgIZEquXPGOBsKMklj/8xghi swioSOzaugWohoODV8BX4sM2sBIhgVXMEr/vaIHYnALWEg+mbGAGsRmBLvp+ag3YeGYBcYlb T+ZDXSogsWTPeWYIW1Ti5eN/rBC2ksSkpedYIep1JBbs/sQGYWtLLFv4GqyeV0BQ4uTMJywT GEVnIRk7C0nLLCQts5C0LGBkWcXIUVqcWpabbmS4iREYN8ck2Bx3MC74ZHmIUYCDUYmHd4P/ 6hAh1sSy4srcQ4zSHCxK4rya1fOChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTD6SrcZsCoz 99b9ceu++izJI0jzaPqs4BmGKZu+c3AbP2JSllxR3Kh+49VK0S9rRa8u/GpzXyD03drNWqH/ HN/oGKyuKeCZFj1nCp8zC+MOy7jGRFHT7ff+7uE7sCP82bOUCRufTHnsfOLIqZSq/7kdcw+l 9J44E6fT7+AfJRsTWGjHc0XfolOJpTgj0VCLuag4EQCQYrljfAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kJ38j-O--8JCz5rLPhGZecYejJg Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:50:11 -0000 Dear Authors - I have few basic questions - 1. Is it on every hop/LSR along the path the whole packet with label stack = had to be decrypted and encrypted with Mel? If yes, IMO this is really=20 bad w.r.t performance (issues of key exchange for thousands of LSPs and = load associated would be insignificant in comparison perhaps?).=20 From this PoV content in section 1.2 is critical.=20 2. Section 2 is covering this - OS proposed here is similar to TCPInc stuf= f - meaning no authenticated key exchange (possible MITM) and no PFS. =20 3. Do you see any key roll over issues? -- Uma C. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 02, 2015 8:42 AM To: l.wood@surrey.ac.uk; david.black@emc.com; mpls@ietf.org Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-op= portunistic-encrypt-04.txt Lloyd, It would be excellent to have the discussion of whether it is inappropriate= or even impossible to provide security at the MPLS layer. My view was that the overhead of managed security associations in an MPLS n= etwork where relationships were n-squared times "class of service" was a li= miting factor.=20 This draft discusses some of the issues, and it is intended that section 1.= 2 will add a discussion of security-over (e.g., IPsec) and security-under (= e.g., MACsec). Both of these have a part to play in security in MPLS networ= ks, but it is not clear that they deliver everything you need. The discussion of Opportunistic Security and some of the lessons coming out= of growing awareness of fibre-tap and untrusted routers leads to the thoug= ht that per hop layer 2 security may provide a lot of benefits, but that MP= LS security might also have value. This draft is targeted at Experimental and several people have stated that = they intend to experiment with it. >From a protocol point of view, I think that this working group is the=20 >right place to discuss how to negotiate the use of security and how to encode the= security parameters on the wire. I don't believe this working group is the= right place to determine what those parameters are, and I rely on security= whizzards to tell me what information I need to carry.=20 As far as "mandatory to implement" is concerned, Stephen and I might have s= ome small disagreement :-) Nothing documented now is likely to be mandatory= to implement in existing implementations. Therefore, this experiment (even= were it to be standards track) would not be anything more than a strong re= commendation for as many years as it takes to upgrade a lot of boxes - and = so, of course, the document has to describe what happens if one or more rou= ters in the network do not support these security mechanisms. This opens up= the possibility of downgrade attacks, and the document observes that how y= ou respond to a request to downgrade depends on how much you want to secure= the data. However, once someone has decided to implement this document, there is valu= e in observing that, from a set of security algorithms that are possible to= support, there should be a common subset that all implementations will sup= port - absent that, there is a high chance of lack of interop even between = implementations of this document. So, to that extent, it is valuable to tal= k about mandatory to implement. Thanks for your interest in this work. Adrian > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: 02 January 2015 13:57 > To: david.black@emc.com; stephen.farrell@cs.tcd.ie;=20 > adrian@olddog.co.uk; mpls@ietf.org > Subject: Re: [mpls] FW: New Version Notification for=20 > draft-farrelll-mpls- opportunistic-encrypt-04.txt >=20 > More a barrier to discussion is that a conversation about anything can=20 > now be derailed into a conversation about security, because all groups=20 > are security groups. >=20 > The pressing question for mpls has always been not whether mpls=20 > requires security, not what security mpls should have, but exactly=20 > what type of elliptic > curve to use. Good that we're attempting to answer that, no? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Jan 6 13:02:08 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAD81A0113; Tue, 6 Jan 2015 13:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXOWWIlSWYy8; Tue, 6 Jan 2015 13:02:03 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09F91A6F2A; Tue, 6 Jan 2015 13:02:02 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 0D8BACD683244; Tue, 6 Jan 2015 21:01:54 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t06L1vfB029472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 16:01:57 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 16:01:57 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCqEA0A= Date: Tue, 6 Jan 2015 21:01:57 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947C86E5@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-2VDu4rBOHruViGLxUpUmbFU-t8 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 21:02:06 -0000 Adrian and authors, Can we also close on the IANA assignment for the new TLVs and specifically = for the Dual-Stack Capability TLV? I assume this will be drawn from the Common Hello Parameters range of the L= DP TLV Type Name Space. The next available value is 0x0409. I appreciate if= you could confirm this value. Regards, Mustapha. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha > (Mustapha) > Sent: Tuesday, December 16, 2014 12:22 PM > To: ietf@ietf.org; IETF-Announce > Cc: mpls@ietf.org > Subject: Re: [mpls] Last Call: (Updates= to LDP for > IPv6) to Proposed Standard >=20 > Hi Adrian and all, > I was the one who raised the interop issues we found while testing our > implementation of LDP IPv6 against existing and deployed implementations.= I > proposed a simple method of using the existing FEC advertisement capabili= ty at > the session level as a way for an LSR to detect if an implementation supp= ort LDP > IPv6 FECs and IPv6 addresses. This existing FEC advertisement capability = at > session level is defined in draft-ietf-mpls-ldp-ip-pw-capability-08 but w= ith the > limitation that it can be used only to disable support of IPv6 FECs in LD= P > Initialization Message; we proposed to generalize the method to also indi= cate > explicit support for IPv6 FECs and IPv6 Addresses in LDP Initialization M= essage. > This method is safe and was also used with mLDP P2MP and MP2MP FECs when > they were introduced. The intent here is that all session level capabilit= ies in LDP > should follow RFC 5561 approach. >=20 > There was an individual contributor which supported the proposal on the m= ailing > list but the authors chose to ignore it and went with a proposal which ov= erloaded > the meaning of the dual-stack capability TLV. Regardless of the merit of = either > method, the discussion on the MPLS mailing list was not closed properly f= rom my > perspective. >=20 > Now here is the concern I raised with using the dual-stack capability. No= t only this > TLV is an adjacency level feature which is has nothing to do with FEC cap= ability > advertisement, but it is introducing complexity in the implementation whi= ch now > has to check dual-stack capability for *each* adjacency to the peer *and*= the > session level FEC capability to decide what the peer is capable of at the= *session > level*. >=20 > Having said that, I want to keep the spirit of cooperation and make sure = we get this > draft published. To that effect, I am not opposed to its publication as l= ong as the > following points are clarified in the draft since now FEC capability of t= he LSR peer > is determined by a check a both adjacency and session levels: >=20 > 1. The draft is missing the behavior when multiple adjacencies exist to t= he same > LSR and the peer LSR advertised the dual-stack capability only over a sub= set of > these Hello adjacencies. > I assume here the peer LSR is considered to be dual-stack capable as soon= as any > of the Hello adjacencies includes the dual-stack capability. This would a= llow a > hitless upgrade scenario from an older implementation to one which compli= es to > this draft >=20 > 2. Similarly, what would be the behavior if a hello adjacency changes fro= m sending > the dual-stack capability to not sending it? This would be for example in= a hitless > downgrade to a version of LDP which does not comply to this draft. > I assume here that the session must be bounced since the LSRs need a clea= n state > to not send IPv6 addresses and IPv6 FECs. >=20 > 3. The document defines 2 values for the dual-stack capability TR. It doe= s not > mention the behavior when an unknown value is received. > Will that be considered a fatal error? >=20 > 4. The draft is missing the behavior of when the peer LSR does not advert= ise the > dual-stack capability in all the Hello adjacencies but it advertised the = enabling or > disabling of the IPv6 prefix FEC capability in the session initialization= message. > I assume here that the absence of the dual-stack capability overrides any= session > level IPv6 FEC prefix capability advertisement. >=20 > 5. The draft is missing the behavior of when the peer LSR does not advert= ise the > dual-stack capability in all the Hello adjacencies but it advertised the = enabling of > the IPv6 prefix FEC capability in the session Capability message. > I assume the same behavior as in (4) applies here. >=20 > Regards, > Mustapha. >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG > > Sent: Thursday, December 04, 2014 2:37 PM > > To: IETF-Announce > > Cc: mpls@ietf.org > > Subject: [mpls] Last Call: (Updates > > to LDP for IPv6) to Proposed Standard > > > > > > The IESG has received a request from the Multiprotocol Label Switching > > WG > > (mpls) to consider the following document: > > - 'Updates to LDP for IPv6' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2014-12-18. Exceptionally, comments may > > be sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > The Label Distribution Protocol (LDP) specification defines > > procedures to exchange label bindings over either IPv4, or IPv6 or > > both networks. This document corrects and clarifies the LDP behavior > > when IPv6 network is used (with or without IPv4). This document > > updates RFC 5036 and RFC 6720. > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Jan 6 15:03:20 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3E1A00E6; Tue, 6 Jan 2015 15:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDKkWisu6KnB; Tue, 6 Jan 2015 15:03:13 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DF41A0053; Tue, 6 Jan 2015 15:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7973; q=dns/txt; s=iport; t=1420585393; x=1421794993; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=asr9MAmt6npzAIlhWm7iKNktrng/1wCfyOBPhImWC3k=; b=W8jPIKz421EKqiWaX8gcK0Lkk456hC6hge87FWf1fdORyFR1QSBffpji SARfmRLVSvroqVU3+EfTcIpgvesIXBHKUvNprfSoPq2vTjMVTJb2aY635 nOMrhaYoqQci62bb5Cc1aYr/lTKg8AM8GaflrvH5Resc+qvpLgb4XoCZ7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAH5prFStJV2U/2dsb2JhbABcgwZSWATGNgqFcwKBDhYBAQEBAX2EDAEBAQMBAQEBawsFBwQCAQgRAwEBASQEBycLFAkIAgQBDQWIJAgNwwcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjzYXKwcGhCMBBI4lg0GFOIENMII6jWUigjKBPG+BBUB+AQEB X-IronPort-AV: E=Sophos;i="5.07,710,1413244800"; d="scan'208";a="384827431" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jan 2015 23:02:54 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t06N2rid001551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 23:02:54 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 17:02:53 -0600 From: "Rajiv Asati (rajiva)" To: "Aissaoui, Mustapha (Mustapha)" , "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCq3X4A= Date: Tue, 6 Jan 2015 23:02:53 +0000 Message-ID: References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.150.45.119] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1SNOpTTiwuKC7d40yxCmOQ_iEIc Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 23:03:18 -0000 Hi Mustapha,=20 > Having said that, I want to keep the spirit of cooperation and make sure >we get this > draft published. To that effect, I am not opposed to its publication as >long as the > following points are clarified in the draft since now FEC capability of >the LSR peer is > determined by a check a both adjacency and session levels: Thanks for pointing out the below scenarios. We think that all but one are either covered or require editorial changes. =20 1. This scenario (sending hellos with DS capability on fewer interfaces for a peer) does NOT look realistic, since hitless upgrading a router would result in sending v4+v6 hellos either with DS capability or without DS capability (for a DS peer, assuming the peer was enabled for DS LDP, default or not, in an implementation). Perhaps, you had a different scenario in mind. 2. Yes. This scenario is well covered in section 6.1.1 point#3. // 3. If "Dual-stack capability" TLV is NOT present, and =8A resulting in any established LDPoIPv4 session being reset and a fatal Notification message being sent (with status =8A // =09 3. Yes (to the expected behavior). This is somewhat covered in bullet #1 in section 6.1.1, but we can make it explicit by adding "or does not get recognized=B2 as below: OLD: If "Dual-stack capability" TLV is present and remote preference does not match with the local preference,.. NEW: If "Dual-stack capability" TLV is present and remote preference does not match with the local preference (or does not get recognized),.. 4 and 5. Yes (to the expected behavior). It is implicit in section 7.2 para 4.=20 //.. An LSR MAY further constrain the advertisement of FEC-label bindings for a particular address family by negotiating the IP Capability...// Are you suggesting to make it explicit? --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: , Mustapha Aissaoui Date: Tuesday, December 16, 2014 at 12:21 PM To: IETF Discussion , IETF-Announce Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard >Hi Adrian and all, >I was the one who raised the interop issues we found while testing our >implementation of LDP IPv6 against existing and deployed implementations. >I proposed a simple method of using the existing FEC advertisement >capability at the session level as a way for an LSR to detect if an >implementation support LDP IPv6 FECs and IPv6 addresses. This existing >FEC advertisement capability at session level is defined in >draft-ietf-mpls-ldp-ip-pw-capability-08 but with the limitation that it >can be used only to disable support of IPv6 FECs in LDP Initialization >Message; we proposed to generalize the method to also indicate explicit >support for IPv6 FECs and IPv6 Addresses in LDP Initialization Message. >This method is safe and was also used with mLDP P2MP and MP2MP FECs when >they were introduced. The intent here is that all session level >capabilities in LDP should follow RFC 5561 approach. > >There was an individual contributor which supported the proposal on the >mailing list but the authors chose to ignore it and went with a proposal >which overloaded the meaning of the dual-stack capability TLV. Regardless >of the merit of either method, the discussion on the MPLS mailing list >was not closed properly from my perspective. > >Now here is the concern I raised with using the dual-stack capability. >Not only this TLV is an adjacency level feature which is has nothing to >do with FEC capability advertisement, but it is introducing complexity in >the implementation which now has to check dual-stack capability for >*each* adjacency to the peer *and* the session level FEC capability to >decide what the peer is capable of at the *session level*. > >Having said that, I want to keep the spirit of cooperation and make sure >we get this draft published. To that effect, I am not opposed to its >publication as long as the following points are clarified in the draft >since now FEC capability of the LSR peer is determined by a check a both >adjacency and session levels: > >1. The draft is missing the behavior when multiple adjacencies exist to >the same LSR and the peer LSR advertised the dual-stack capability only >over a subset of these Hello adjacencies. >I assume here the peer LSR is considered to be dual-stack capable as soon >as any of the Hello adjacencies includes the dual-stack capability. This >would allow a hitless upgrade scenario from an older implementation to >one which complies to this draft > >2. Similarly, what would be the behavior if a hello adjacency changes >from sending the dual-stack capability to not sending it? This would be >for example in a hitless downgrade to a version of LDP which does not >comply to this draft. >I assume here that the session must be bounced since the LSRs need a >clean state to not send IPv6 addresses and IPv6 FECs. > >3. The document defines 2 values for the dual-stack capability TR. It >does not mention the behavior when an unknown value is received. >Will that be considered a fatal error? > >4. The draft is missing the behavior of when the peer LSR does not >advertise the dual-stack capability in all the Hello adjacencies but it >advertised the enabling or disabling of the IPv6 prefix FEC capability in >the session initialization message. >I assume here that the absence of the dual-stack capability overrides any >session level IPv6 FEC prefix capability advertisement. > >5. The draft is missing the behavior of when the peer LSR does not >advertise the dual-stack capability in all the Hello adjacencies but it >advertised the enabling of the IPv6 prefix FEC capability in the session >Capability message. >I assume the same behavior as in (4) applies here. > >Regards, >Mustapha. > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG >> Sent: Thursday, December 04, 2014 2:37 PM >> To: IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] Last Call: (Updates >>to LDP for IPv6) >> to Proposed Standard >>=20 >>=20 >> The IESG has received a request from the Multiprotocol Label Switching >>WG >> (mpls) to consider the following document: >> - 'Updates to LDP for IPv6' >> as Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >>final >> comments on this action. Please send substantive comments to the >>ietf@ietf.org >> mailing lists by 2014-12-18. Exceptionally, comments may be sent to >>iesg@ietf.org >> instead. In either case, please retain the beginning of the Subject >>line to allow >> automated sorting. >>=20 >> Abstract >>=20 >> The Label Distribution Protocol (LDP) specification defines >> procedures to exchange label bindings over either IPv4, or IPv6 or >> both networks. This document corrects and clarifies the LDP behavior >> when IPv6 network is used (with or without IPv4). This document >> updates RFC 5036 and RFC 6720. >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ >>=20 >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Jan 6 15:14:40 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6261A01F4 for ; Tue, 6 Jan 2015 15:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wP7dejx1lef for ; Tue, 6 Jan 2015 15:14:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978341A016A for ; Tue, 6 Jan 2015 15:14:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9D260BED5; Tue, 6 Jan 2015 23:14:31 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hA2piL3FHnfe; Tue, 6 Jan 2015 23:14:29 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.41.49.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 54DFFBEC0; Tue, 6 Jan 2015 23:14:29 +0000 (GMT) Message-ID: <54AC6C55.7050904@cs.tcd.ie> Date: Tue, 06 Jan 2015 23:14:29 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Uma Chunduri , "adrian@olddog.co.uk" , "l.wood@surrey.ac.uk" , "david.black@emc.com" , "mpls@ietf.org" References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/acKijID3FKpwCNOh6k7kTSuXnno Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 23:14:39 -0000 Hiya, A partly contingent answer from me sorry, MPLS specifics need Adrian for more certainty:-) On 06/01/15 20:49, Uma Chunduri wrote: > Dear Authors - > > I have few basic questions - > > 1. Is it on every hop/LSR along the path the whole packet with label > stack had to be decrypted and encrypted with Mel? If yes, IMO this is > really bad w.r.t performance (issues of key exchange for thousands of > LSPs and load associated would be insignificant in comparison > perhaps?). From this PoV content in section 1.2 is critical. I believe not. Encryption is done once and decryption once, for any given secret established via the key exchange. I think that means this should be less demanding of CPU than e.g. MACsec for common cases where you might want to use this. > 2. Section 2 is covering this - OS proposed here is similar to > TCPInc stuff - meaning no authenticated key exchange (possible MITM) > and no PFS. You do get PFS as it's a D-H exchange. And it is quite like TCPinc in that this protocol doesn't give you endpoint authentication but it does allow one to export values that can be used for endpoint authentication. (Or were it useful we could accept such values as an input to the KDF I guess.) Interestingly, I think MPLS, with all it's highly managed identifiers could make it practical to detect a MitM post-facto without endpoint authentication, which isn't going to be practical for TCPInc (e.g. due to NAT). I'll be interested in trying to figure out if that's possible later since if it were possible, it'd be very nice. > 3. Do you see any key roll over issues? Always;-) We tried to cover that in the draft but I'm sure that implementation and initial experimentation might tell us that more work is needed. Cheers, S. > > -- Uma C. > > > -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] > On Behalf Of Adrian Farrel Sent: Friday, January 02, 2015 8:42 AM To: > l.wood@surrey.ac.uk; david.black@emc.com; mpls@ietf.org Subject: Re: > [mpls] FW: New Version Notification for > draft-farrelll-mpls-opportunistic-encrypt-04.txt > > Lloyd, > > It would be excellent to have the discussion of whether it is > inappropriate or even impossible to provide security at the MPLS > layer. > > My view was that the overhead of managed security associations in an > MPLS network where relationships were n-squared times "class of > service" was a limiting factor. > > This draft discusses some of the issues, and it is intended that > section 1.2 will add a discussion of security-over (e.g., IPsec) and > security-under (e.g., MACsec). Both of these have a part to play in > security in MPLS networks, but it is not clear that they deliver > everything you need. > > The discussion of Opportunistic Security and some of the lessons > coming out of growing awareness of fibre-tap and untrusted routers > leads to the thought that per hop layer 2 security may provide a lot > of benefits, but that MPLS security might also have value. > > This draft is targeted at Experimental and several people have stated > that they intend to experiment with it. > >> From a protocol point of view, I think that this working group is >> the right > place to discuss how to negotiate the use of security and how to > encode the security parameters on the wire. I don't believe this > working group is the right place to determine what those parameters > are, and I rely on security whizzards to tell me what information I > need to carry. > > As far as "mandatory to implement" is concerned, Stephen and I might > have some small disagreement :-) Nothing documented now is likely to > be mandatory to implement in existing implementations. Therefore, > this experiment (even were it to be standards track) would not be > anything more than a strong recommendation for as many years as it > takes to upgrade a lot of boxes - and so, of course, the document has > to describe what happens if one or more routers in the network do not > support these security mechanisms. This opens up the possibility of > downgrade attacks, and the document observes that how you respond to > a request to downgrade depends on how much you want to secure the > data. However, once someone has decided to implement this document, > there is value in observing that, from a set of security algorithms > that are possible to support, there should be a common subset that > all implementations will support - absent that, there is a high > chance of lack of interop even between implementations of this > document. So, to that extent, it is valuable to talk about mandatory > to implement. > > Thanks for your interest in this work. > > Adrian > >> -----Original Message----- From: l.wood@surrey.ac.uk >> [mailto:l.wood@surrey.ac.uk] Sent: 02 January 2015 13:57 To: >> david.black@emc.com; stephen.farrell@cs.tcd.ie; >> adrian@olddog.co.uk; mpls@ietf.org Subject: Re: [mpls] FW: New >> Version Notification for draft-farrelll-mpls- >> opportunistic-encrypt-04.txt >> >> More a barrier to discussion is that a conversation about anything >> can now be derailed into a conversation about security, because all >> groups are security groups. >> >> The pressing question for mpls has always been not whether mpls >> requires security, not what security mpls should have, but exactly >> what type of > elliptic >> curve to use. Good that we're attempting to answer that, no? > > _______________________________________________ mpls mailing list > mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list > mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls > From nobody Tue Jan 6 16:59:51 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F471A00F0 for ; Tue, 6 Jan 2015 16:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loaRFc3sqdmk for ; Tue, 6 Jan 2015 16:59:48 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D5E1A0072 for ; Tue, 6 Jan 2015 16:59:48 -0800 (PST) Received: from BY2PR05MB192.namprd05.prod.outlook.com (10.242.39.149) by BY2PR05MB189.namprd05.prod.outlook.com (10.242.39.140) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 00:59:46 +0000 Received: from BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.38]) by BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.38]) with mapi id 15.01.0049.002; Wed, 7 Jan 2015 00:59:46 +0000 From: Santosh Esale To: "Tarek Saad (tsaad)" , "mpls@ietf.org" Thread-Topic: [mpls] MPLS-RT review of draft-esale-mpls-app-aware-tldp Thread-Index: AQHQKVLhLdk1xXgDvkqFOfkFmFRZfQ== Date: Wed, 7 Jan 2015 00:59:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.239.11] authentication-results: spf=none (sender IP is ) smtp.mailfrom=sesale@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BY2PR05MB189; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB189; x-forefront-prvs: 044968D9E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(252514010)(51704005)(164054003)(377424004)(377454003)(479174004)(189002)(199003)(40100003)(99286002)(101416001)(107046002)(99396003)(19580405001)(120916001)(105586002)(4396001)(19580395003)(2501002)(106116001)(87936001)(122556002)(97736003)(2656002)(106356001)(64706001)(20776003)(230783001)(31966008)(66066001)(86362001)(92566001)(83506001)(54356999)(36756003)(46102003)(102836002)(15975445007)(77156002)(62966003)(68736005)(2900100001)(50986999)(21056001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB189; H:BY2PR05MB192.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2015 00:59:45.5286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB189 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7-PpQHKh_0Wgo_uZNJIbOAF6cHI Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Lizhong Jin Subject: Re: [mpls] MPLS-RT review of draft-esale-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 00:59:50 -0000 SGkgVGFyZWssDQogICAgICAgIFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyBhbmQgY29tbWVudHMu DQoNClBsZWFzZSBmaW5kIHNvbWUgcmVzcG9uc2VzIGlubGluZS4NCk9uIDEyLzgvMTQsIDEwOjE0 IFBNLCAiVGFyZWsgU2FhZCAodHNhYWQpIiA8dHNhYWRAY2lzY28uY29tPiB3cm90ZToNCg0KPkhp LA0KPg0KPmJlbG93IGlzIG15IE1QTFMtUlQgcmV2aWV3Og0KPg0KPi0gaXMgdGhlIGRvY3VtZW50 IGNvaGVyZW50Pw0KPlllcywgaW4gZ2VuZXJhbCwgYnV0IGNhbiBiZW5lZml0IGZyb20gYW5vdGhl ciBlZGl0b3JpYWwgcm91bmQuDQo+DQo+LSBpcyBpdCB1c2VmdWw/DQo+WWVzLCBiZWluZyBhYmxl IHRvIGNvbnRyb2wgVC1MRFAgc2Vzc2lvbiBlc3RhYmxpc2htZW50IG9uLWRlbWFuZCB1c2luZyBu ZXcNCj50YXJnZXRlZCBhcHBsaWNhdGlvbiBjYXBhYmlsaXR5IFRMViBpcyB1c2VmdWwuDQo+DQo+ LSBpcyBpdCB0ZWNobmljYWxseSBzb3VuZD8NCj5ZZXMsIGJ1dCBjYW4gYmVuZWZpdCBmcm9tIGJl aW5nIG1vcmUgZXhwbGljaXQgb24gaG93IGl0IGNvbXBsZW1lbnRzIGFuZA0KPnBvc3NpYmx5IGNv LWV4aXN0cyB3aXRoIHdvcmsgZGVmaW5lZCBpbg0KPmRyYWZ0LWlldGYtbXBscy1sZHAtaXAtcHct Y2FwYWJpbGl0eS4NClNlY3Rpb24gNSBkZXNjcmliZXMgaW50ZXJ3b3JraW5nIG9mIHRoaXMgZHJh ZnQgd2l0aA0KZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcC1wdy1jYXBhYmlsaXR5LiBXZSBoYXZlIGFk ZGVkIG1vcmUgZXhwbGljaXQNCnRleHQgdG8gdGhpcyBzZWN0aW9uIGluIHZlcnNpb24gMDMsIHdo aWNoIHdpbGwgYmUgcHVibGlzaGVkIHNob3J0bHkuDQoNCg0KPkZvciBleGFtcGxlLCB3aGVuIGNv bmZsaWN0aW5nDQo+VEFDL1NBQyBhcmUgdXNlZCBhbmQgaG93IGl0IGNhbiBiZSBpbnRlcnByZXRl ZD8NClNlY3Rpb24gNSwgcGFyYWdyYXBoIDQgYW5kIDUgZGVzY3JpYmUgdGhlIHByb2NlZHVyYWwg cHJlZmVyZW5jZXMgZm9yDQp0aGUgY28tZXhpc3RlbmNlIG9mIFRBQy9TQUMgYW5kIGZvciB0aGUg YXZvaWRhbmNlIG9mIGNvbmZsaWN0aW5nDQpTQUMvVEFDIG9uIHRoZSB0TERQIHNlc3Npb24uIEFk ZGVkIOKAmG11c3TigJkga2V5d29yZCBmb3IgdGhlc2UgcHJvY2VkdXJlcy4NCiAgIA0KPkFub3Ro ZXIgKGlkZWEpIGlzIGNhbiBkbw0KPndpdGhvdXQgZXh0cmEgbWFwcGluZ3MgZm9yIFRhcmdldGVk IEFwcGxpY2F0aW9uIEVsZW1lbnQgdG8gU3RhdGUNCj5BZHZlcnRpc2VtZW50IENvbnRyb2wgKFNB QykgRWxlbWVudHMgYXMgZGVmaW5lZCBpbg0KPmRyYWZ0LWlldGYtbXBscy1sZHAtaXAtcHctY2Fw YWJpbGl0eSAoY2FuIGl0IGJlIHVuaWZpZWQgYXBwLWlkIGluc3RlYWQ/KT8NClRoZSBhcHBsaWNh dGlvbiB0eXBlIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcC1wdy1jYXBhYmlsaXR5 IG1hcHMNCnRvDQpMRFAgRkVDIHR5cGUgd2hpbGUgdGhlIFRBLUlkIGRlZmluZWQgaGVyZSBpcyB0 TERQIGFwcGxpY2F0aW9uIElkLCB3aGljaA0KaXMgbmVjZXNzYXJ5IHRvIGNvbnRyb2wgdExEUCBz ZXNzaW9uIGVzdGFibGlzaG1lbnQgcGVyIGFwcGxpY2F0aW9uIGFuZCB0bw0KYWR2ZXJ0aXNlIG9u bHkgbmVjZXNzYXJ5IExEUCBGRUMtTGFiZWwgYmluZGluZ3MgZm9yIHRoYXQgYXBwbGljYXRpb24u DQoNCj4NCj4tIGlzIGl0IHJlYWR5IGZvciBXRyBhZG9wdGlvbj8NCj5ZZXMsIGJ1dCByZWNvbW1l bmQgdW5kZXJnb2luZyBhbm90aGVyIHJvdW5kIG9mIGNsZWFudXAvZWRpdGluZyBiZWZvcmUuDQo+ DQo+DQo+PT09DQo+Q29tbWVudHM6DQo+DQo+U2VjdGlvbiAyOg0KPiogVmFsdWUgb2YgVS9GLWJp dHM6IHN1Z2dlc3QgYmVpbmcgZXhwbGljaXQgb24gdGhlIHJlY29tbWVuZGVkIHZhbHVlc+KAuQ0K PmUuZy4gVGhlIHZhbHVlIG9mIHRoZSBVLWJpdCBmb3IgdGhlIFRMViBNVVNUIGJlIHNldCB0byAx IHNvIHRoYXQgYQ0KPnJlY2VpdmVyIE1VU1Qgc2lsZW50bHkgaWdub3JlIHRoaXMgVExWIGlmIHVu a25vd24gdG8gaXQsIGFuZCBjb250aW51ZQ0KPnByb2Nlc3NpbmcgdGhlIHJlc3Qgb2YgdGhlIG1l c3NhZ2UuIFRoZSB2YWx1ZSBvZiBGLWJpdCBNVVNUIGJlIHNldCB0byAwLA0KPnNvIHRvIG5vdCBm b3J3YXJkLg0KV2Ugd2lsbCBtYWtlIGl0IGV4cGxpY2l0IGluIHRoZSBuZXcgcmV2aXNpb24gLTAz Lg0KDQo+DQo+KiAoVGFyZ2V0ZWQgQXBwbGljYXRpb24gSWRlbnRpZmllciAoVEEtSWQpKTogd291 bGQgcmVjb21tZW5kIG1ha2luZyBFLWJpdA0KPmJlIGF0IHBvc2l0aW9uIDAgdG8gYmUgY29uc2lz dGVudCB3aXRoIG90aGVyIGRlZmluaXRpb25zLg0KVGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlvbiwg V2Ugd2lsbCBjaGFuZ2UgaXQuDQoNCj5TZWN0aW9uIDM6IA0KPiogaXQgTVVTVCB0ZWFyZCBkb3du IC0+IGl0IE1VU1QgdGVhciBkb3duDQo+KiB3aXRoZHJhbCAtPiB3aXRoZHJhd2FsDQpEb25lLg0K DQo+KiByZXBlYXRlZCBUQS1JZHMvVEFFcyBvbiByZWNlaXZlIG1heSBiZSBjb25zaWRlcmVkIG1h bGZvcm1lZCAoPykgdG8gYmUNCj5jb25zaXRlbnQgd2l0aCBwcm9jZWR1cmVzIGluIGRyYWZ0LWll dGYtbXBscy1sZHAtaXAtcHctY2FwYWJpbGl0eT8NCldlIHRob3VnaHQgb3ZlciBpdCBhbmQgYXJy aXZlZCBhdCBhIGNvbmNsdXNpb24gdG8gaWdub3JlIGR1cGxpY2F0ZXMNCnJhdGhlciB0aGVuIHRv IGNvbnNpZGVyIHRoZW0gYXMgbWFsZm9ybWVkIHRvIGF2b2lkIHRMRFAgc2Vzc2lvbiBmbGFwLg0K DQo+KiBjYW4gZWxhYm9yYXRlIG9uIHRoZSBuZXcgcmVxdWlyZW1lbnQgYmVsb3cuLiBXaGF0IGFy ZSBpbXBsaWNhdGlvbnMgb2YNCj5ub3QgYWNjZXB0aW5nIGJ5IGRlZmF1bHQ/DQo+ICAgICAgIkFs c28sIGN1cnJlbnRseSB0aGUgcmVtb3RlIExTUiBhY2NlcHRzIGFzeW1tZXRyaWMgZXh0ZW5kZWQg SGVsbG9zDQo+YnkNCj4gICBkZWZhdWx0IG9yIGJ5IGFwcHJvcHJpYXRlIGNvbmZpZ3VyYXRpb24u IFdpdGggdGhpcyBkb2N1bWVudCwgaXQNCj4gICBzaG91bGQgYWNjZXB0IGJ5IGRlZmF1bHQgaW4g b3JkZXIgdG8gdGhlbiBhY2NlcHQgb3IgcmVqZWN0IHRoZSB0TERQDQo+ICAgc2Vzc2lvbiBiYXNl ZCBvbiB0aGUgYXBwbGljYXRpb24gaW5mb3JtYXRpb24uwrINCklmIHRoZSByZWNlaXZpbmcgTFNS IGRvZXMgbm90IGFjY2VwdCBhc3ltbWV0cmljIHRMRFAgaGVsbG9zLCBhc3ltbWV0cmljDQp0TERQ IHNlc3Npb25zIGNhbm5vdCBiZSBlc3RhYmxpc2hlZCB0byB0aGF0IExTUi4gU28gYXV0b21hdGlj IGFwcGxpY2F0aW9ucw0Kc3VjaCBhcyBSZW1vdGUgTEZBLCBCR1AgYXV0by1kaXNjb3ZlcmVkIHBz ZXVkb3dpcmUsIG1MRFAgbm9kZSBwcm90ZWN0aW9uDQpldGMgbWF5IG5vdCB3b3JrLg0KDQo+DQo+ U2VjdGlvbiA0Og0KPiogcy9hbiBMU1IgTUFZIHVzaW5nL2FuIExTUiBNQVkgdXNlDQo+DQo+U2Vj dGlvbiA1Og0KPiogIlRoZSBFLWJpdCBvZiB0aGUgVGFyZ2V0ZWQgQXBwbGljYXRpb24gRWxlbWVu dCBNVVNUIGJlIHNldCB0byAxIHRvDQo+ZW5hYmxlIFRhcmdldGVkIGFwcGxpY2F0aW9uLsKyLiBI b3cgdG8gaGFuZGxlIHdoZW4gRS1iaXQgaXMgMCBvbiBSWCwgaXMgaXQNCj5tYWxmb3JtZWQsIG9y IGlnbm9yZWQ/DQpJdCBpcyBpZ25vcmVkLiBBZGRlZCBpbiB0aGUgbmV3IHZlcnNpb24uDQoNCj4q IGNhbiBiZSBtb3JlIGVsYWJvcmF0aXZlIG9uIGhhbmRsaW5nIFRBQyB1cGRhdGUgaW4gTERQIGNh cGFiaWxpdHkNCj5tZXNzYWdlLi4NCk9raWUuDQoNCj4qIHMvZGlzYmFsZWQvZGlzYWJsZWQNCj4q IHMvdWRwYXRlcy91cGRhdGVzDQpEb25lLg0KDQo+KiAiVGhlIExTUiBNQVkgYWRkIGEgZGlmZmVy ZW50IEtlZXBBbGl2ZSBUaW1lwrIsIHdoeT8gbm90IGNsZWFyIGhvdw0KPnJlbGF0ZWQ/DQpSZW1v dmVkLg0KDQo+U2VjdGlvbiA2Og0KPiogcy9pbml0aWFsYXphdGlvbi9pbml0aWFsaXphdGlvbg0K Piogcy9wcm9jY2Vkcy9wcm9jZWVkcw0KPiogcy9lc3RhYmxpc2hlbXQvZXN0YWJsaXNobWVudA0K RG9uZS4NCg0KVGhhbmtzLA0KU2FudG9zaA0KPg0KPg0KPk9uIDIwMTQtMTEtMjQsIDI6NDAgQU0s ICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51PiB3cm90ZToNCj4NCj4+VGFyZWssIFRob21hcyBh bmQgTGl6aG9uZywNCj4+DQo+PllvdSBoYXZlIGJlIHNlbGVjdGVkIGFzIE1QTFMtUlQgcmV2aWV3 ZXJzIGZvciBkcmFmdC1lc2FsZS1tcGxzLWFwcC0NCj4+YXdhcmUtdGxkcC4NCj4+DQo+Pk5vdGUg dG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBDQydkIG9uIHRoaXMgZW1haWwgc28gdGhhdCB5b3Ug Y2FuIGtub3cNCj4+dGhhdCB0aGlzIHJldmlldyBpcyBnb2luZyBvbi4gSG93ZXZlciwgcGxlYXNl IGRvIG5vdCByZXZpZXcgeW91ciBvd24NCj4+ZG9jdW1lbnQuDQo+Pg0KPj5SZXZpZXdzIHNob3Vs ZCBjb21tZW50IG9uIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIGNvaGVyZW50LCBpcyBpdA0KPj51 c2VmdWwgKGllLCBpcyBpdCBsaWtlbHkgdG8gYmUgYWN0dWFsbHkgdXNlZnVsIGluIG9wZXJhdGlv bmFsDQo+Pm5ldHdvcmtzKSwgYW5kIGlzIHRoZSBkb2N1bWVudCB0ZWNobmljYWxseSBzb3VuZD8g IFdlIGFyZSBpbnRlcmVzdGVkDQo+PmluIGtub3dpbmcgd2hldGhlciB0aGUgZG9jdW1lbnQgaXMg cmVhZHkgdG8gYmUgY29uc2lkZXJlZCBmb3IgV0cNCj4+YWRvcHRpb24gKGllLCBpdCBkb2Vzbid0 IGhhdmUgdG8gYmUgcGVyZmVjdCBhdCB0aGlzIHBvaW50LCBidXQgc2hvdWxkIGJlDQo+PmEgZ29v ZCBzdGFydCkuDQo+Pg0KPj5SZXZpZXdzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBh dXRob3JzLCBXRyBjby1jaGFpcnMgYW5kDQo+PldHIHNlY3JldGFyeSwgYW5kIENDJ2QgdG8gdGhl IE1QTFMgV0cgZW1haWwgbGlzdC4gSWYgbmVjZXNzYXJ5LCBjb21tZW50cw0KPj5tYXkgYmUgc2Vu dCBwcml2YXRlbHkgdG8gb25seSB0aGUgV0cgY2hhaXJzLg0KPj4NCj4+SWYgeW91IGhhdmUgdGVj aG5pY2FsIGNvbW1lbnRzIHlvdSBzaG91bGQgdHJ5IHRvIGJlIGV4cGxpY2l0IGFib3V0IHdoYXQN Cj4+KnJlYWxseSogbmVlZCB0byBiZSByZXNvbHZlZCBiZWZvcmUgYWRvcHRpbmcgaXQgYXMgYSB3 b3JraW5nIGdyb3VwDQo+PmRvY3VtZW50LCBhbmQgd2hhdCBjYW4gd2FpdCB1bnRpbCB0aGUgZG9j dW1lbnQgaXMgYSB3b3JraW5nIGdyb3VwDQo+PmRvY3VtZW50IGFuZCB0aGUgd29ya2luZyBncm91 cCBoYXMgdGhlIHJldmlzaW9uIGNvbnRyb2wuDQo+Pg0KPj5BcmUgeW91IGFibGUgdG8gcmV2aWV3 IHRoaXMgZHJhZnQgYnkgRGVjIDksIDIwMTQ/IFBsZWFzZSByZXNwb25kIGluIGENCj4+dGltZWx5 IGZhc2hpb24uDQo+Pg0KPj4NCj4+VGhhbmtzLCBMb2ENCj4+KGFzIE1QTFMgV0cgY2hhaXIpDQo+ Pi0tIA0KPj4NCj4+DQo+PkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFp bDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+PlNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAg ICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+Pkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRh bnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWlsaW5nIGxpc3QNCj5tcGxzQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0K From nobody Wed Jan 7 08:46:24 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A221A00E5 for ; Wed, 7 Jan 2015 08:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRL5cstEF2E1 for ; Wed, 7 Jan 2015 08:46:20 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323A31A00B6 for ; Wed, 7 Jan 2015 08:46:15 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t07GkBPP028441; Wed, 7 Jan 2015 16:46:11 GMT Received: from 950129200 (089144212023.atnat0021.highway.a1.net [89.144.212.23]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t07Gk3VL028254 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2015 16:46:11 GMT From: "Adrian Farrel" To: "'Uma Chunduri'" , References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se> Date: Wed, 7 Jan 2015 16:46:02 -0000 Message-ID: <065a01d02a99$71490c80$53db2580$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4gwGyVrHWAcZrwUoBiuknFAIew9ozAdaN47cCBj1zSwII+SMumwVkl0A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21232.000 X-TM-AS-Result: No--1.852-10.0-31-10 X-imss-scan-details: No--1.852-10.0-31-10 X-TMASE-MatchedRID: 0dFPYP4mu5SBnJ5ETtWXffSc/vGQqsJK7mZrnwpHeQRLjXXGQy6nlC43 WPQJHsXD4umtNvHL9YzQWq1NrZFteC0huMCkGGV4/1aBDnIV4imgtpbT0VktX1+zitgyYMA0WHL 0Dxbk102HFPMzDeFLZZDeMiVV4joyuyXwa/V5eQodxBAG5/hkWwXAhAGZB7BnIbxYwbCxGTTmCP CXnBU23cuzJIrNacGOuANq6sAg1r9kgQopOf2aEhfY306nA3boyeUl7aCTy8j1qK3zmw2CQNajx h6Ch5UFEsyLc+k+hkA/7jTO+NbPdclezFEYnvd504Rmz/agfdxQCOsAlaxN758yGsyyjK/ccRFt Ls5mkQPywcyLZlmiP9qchukNEjIii2GqrvgLkWrFlCgYxEaGE7pAJMK7N+JVXSy/xwC6b/Pk1Lh A7Mwru1uTdbUFEbUFq4ziDX2k+65PNJFFp/jsVJ4CIKY/Hg3AtOt1ofVlaoIc4jS1nsD4HfoLR4 +zsDTtSeDAqzk56OfAvx80sCF18K/94x3hb8we8Nv46zaAO4zfyn/467qfbd1a0G7LnlAmBzqw+ nZKIKilPqmNN+Agut2ayWGhhEwaM7BUBTfe0yi563mv0F2G93TpyPFjxiWbVyxrQAZX9Jv7ogzH L/y/OcC+ksT6a9fy Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/H7KgNlf7JG-VtbCENrZMEofCNNs Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:46:23 -0000 Hi have read the thread based on this email from Stephen and Stewart, but deciding to reply back on Uma's original ... > 1. Is it on every hop/LSR along the path the whole packet with label stack had to > be decrypted and encrypted with Mel? If yes, IMO this is really > bad w.r.t performance (issues of key exchange for thousands of LSPs and load > associated would be insignificant in comparison perhaps?). > From this PoV content in section 1.2 is critical. The text in the introduction: MPLS opportunistic security can be achieved between adjacent Label Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and also between end points of an LSP. ...was intended to say that there are two options: 1. encrypt between two adjacent LSRs on an LSP 2. encrypt between the end-points of an LSP In the latter case you would not encrypt and decrypt at each hop (and indeed would not be able to since the keys would only be known at the end points). You are right to point at section 1.2 (and we do need to write that section :-) because L2 solutions (such as MACsec) are typically used on a hop-by-hop basis. I am not clear that MACsec used in this way is a significant performance issue (I think chips can do L2 security at line speed), although it might cause additional power consumption. > 2. Section 2 is covering this - OS proposed here is similar to TCPInc stuff - meaning > no authenticated key exchange (possible MITM) and no PFS. Adding to Stephen's reply: Yes, OS is vulnerable to Man-in-the-Middle attacks. It's a trade: if you make your security too hard to manage and configure, you get no security; if you make your security to simplistic, everyone uses it and it is no good. Our approach here is to make the security easy to use, suffer the potential MitM attacks, but: a. make MitM as expensive as possible b. make a MitM attack possible to detect > 3. Do you see any key roll over issues? I think key roll is covered in the text. We *do* need to roll the keys, but we believe that key roll can be achieved using the existing keying mechanisms with the additional benefit that the key messages are protected by the previous keys. ... and to answer Stewart's question about whether operators want this: I have certainly discussed the principle with a number of network operators and they have not said to be "you are crazy" (perhaps this is taken as read). On the other hand, would say that the interest is currently cautious. That is certainly why this document is positioned as Experimental, but also why we have tried to make the protocol mechanisms such that partial or incremental deployment is possible. But perhaps operators will want to speak for themselves (or perhaps they will be inclined to be shy because expressing an interest might be taken to mean their networks are currently vulnerable, or might lead to them being leant on). Adrian From nobody Wed Jan 7 08:46:29 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246821A1A5E; Wed, 7 Jan 2015 08:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEi_wy1z98JV; Wed, 7 Jan 2015 08:46:22 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292241A00AE; Wed, 7 Jan 2015 08:46:15 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t07GkAep028416; Wed, 7 Jan 2015 16:46:10 GMT Received: from 950129200 (089144212023.atnat0021.highway.a1.net [89.144.212.23]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t07Gk3VK028254 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2015 16:46:10 GMT From: "Adrian Farrel" To: "'Aissaoui, Mustapha \(Mustapha\)'" , References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D947C86E5@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C86E5@US70UWXCHMBA04.zam.alcatel-lucent.com> Date: Wed, 7 Jan 2015 16:46:02 -0000 Message-ID: <065001d02a99$70bf1c00$523d5400$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEavZr4LLvEoVKVBHX9h497xfv8bQIvycuoApIn9s6d+ZlW4A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21232.000 X-TM-AS-Result: No--9.827-10.0-31-10 X-imss-scan-details: No--9.827-10.0-31-10 X-TMASE-MatchedRID: L8tZF6zWW2ozx9GDMr0HvzYTypjB3iDVuikHZcC6ceAEgPcpc1tw6Fw9 Ld5cnKYUgADNzA1mkcUss6aOAqnY9aiX/8Y2seR/LNe+DcIJHlRReWnUUdhI9TPolapMwp0IKJj krG+1FfEcmDow06HKgcowTJnEdgrSxAFMYEMzeR0XrP0cYcrA2+Ae2rni5lNAV0aMY26wA5y/xi VRG8Gt83wB3gSA8cZDcp51Uxq7L6ucl7+trwU+WIdlc1JaOB1TnophrTcsI7abKItl61J/ycnjL TA/UDoAq61alUC6VkfkwjHXXC/4I7I7zVffJqTzIkJnsAqOgWszS9WNx152fXXnXcRx+KqGCUY9 4DFyv+myanhDJSlH7n7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/uxSjZRz7GIg5kbhqlqwfmSYuCyY Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:46:25 -0000 Hi Mustapha, > Can we also close on the IANA assignment for the new TLVs and specifically for > the Dual-Stack Capability TLV? > > I assume this will be drawn from the Common Hello Parameters range of the LDP > TLV Type Name Space. The next available value is 0x0409. I appreciate if you could > confirm this value. Are you asking for an early allocation of this code point? The document has been through IETF last call and with a few edits will be ready for processing by the IESG. After IESG approval, the IANA will make a provisional allocation of a code point that will be confirmed on publication of the RFC. The IANA is *likely* to allocate the next available value, but not if another I-D gets there first :-) Unless there is a reason for a rush, I suggest that we wait for normal process. Constructive discussion of the remaining issues with this draft should enable that to complete quickly. Thanks, Adrian From nobody Wed Jan 7 14:51:09 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F9A1A6FF0; Wed, 7 Jan 2015 14:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYaWbpJgJJY7; Wed, 7 Jan 2015 14:51:04 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3571A6F0B; Wed, 7 Jan 2015 14:51:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C94F91832B9; Wed, 7 Jan 2015 14:50:36 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150107225036.C94F91832B9@rfc-editor.org> Date: Wed, 7 Jan 2015 14:50:36 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qRZZPq7VbAB1SjNbwgOAIZ89MaY Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7439 on Gap Analysis for Operating IPv6-Only MPLS Networks X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 22:51:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7439 Title: Gap Analysis for Operating IPv6-Only MPLS Networks Author: W. George, Ed., C. Pignataro, Ed. Status: Informational Stream: IETF Date: January 2015 Mailbox: wesley.george@twcable.com, cpignata@cisco.com Pages: 28 Characters: 64087 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-ipv6-only-gap-04.txt URL: https://www.rfc-editor.org/info/rfc7439 This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality. In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jan 7 23:58:29 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8B31ACC86 for ; Wed, 7 Jan 2015 23:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H99j61FE5avv for ; Wed, 7 Jan 2015 23:58:25 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D2B1ACC84 for ; Wed, 7 Jan 2015 23:58:25 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.169.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C6822180155B; Thu, 8 Jan 2015 08:58:22 +0100 (CET) Message-ID: <54AE389C.7070106@pi.nu> Date: Thu, 08 Jan 2015 15:58:20 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/SM-qIQ2wJKPTvfNZACd-CIEbma0 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Prepairing response to a liaison from ITU-T SG15. X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 07:58:27 -0000 Working Group, We received a liaison from form ITU-T SG15 on their "OTNT standardization work plan". The liaison were sent to the mpls, pce and ccamp working group. It seems that it could also be of interest to pals, bess and teas. See: https://datatracker.ietf.org/liaison/1368/ We have briefly discussed this among the wg chairs and think we should send a joint response form all wirking groups. Our liaison managers - Scott and Deborah - will coordinate our response. Please send comments of what you think should be included in the response to Scott and Deborah, and copy the ccamp list. Working Group chairs plan to include a list the new RFCs that is relevant for ITU-T SG15, as well as new charter items. /Loa for the wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jan 8 03:54:33 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5A21ACD05 for ; Thu, 8 Jan 2015 03:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ju9FMH76YLM for ; Thu, 8 Jan 2015 03:54:28 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40151A3B9F for ; Thu, 8 Jan 2015 03:54:28 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.169.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 48C97180155B; Thu, 8 Jan 2015 12:54:24 +0100 (CET) Message-ID: <54AE6FEE.2010806@pi.nu> Date: Thu, 08 Jan 2015 19:54:22 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <548FC870.3090901@pi.nu> <54965E0B.3050701@pi.nu> In-Reply-To: <54965E0B.3050701@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@tools.ietf.org" , draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: Re: [mpls] Update:: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 11:54:31 -0000 Working Group, This adoption poll is closed. We have a new wg document. Can the authors please post: draft-ietf-mpls-ldp-mrt-00 with no other changes that the filename, date and version number. /Loa for the mpls wg chairs On 2014-12-21 13:43, Loa Andersson wrote: > Working Group, > > This is to notify that all authors has now responded to the IPR poll, > they are all unaware of any IPRs that relate to this document. > > /Loa > > On 2014-12-16 13:51, Loa Andersson wrote: >> Working Group, >> >> This is to start a two week poll on adopting >> draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. >> >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls@ietf.org). Please give a technical >> motivation for your support/not support, especially if you think that >> the document should not be adopted as a working group document. >> >> There is no IPR disclosures directly against this document. An IPR >> poll will be done in parallel to the adoption poll, and the adoption >> poll will not be closed before we have responses from all authors. >> >> If you are on the the mpls working group mailing list and >> aware of IPR that relates to this draft, you should respond to the >> IPR poll. >> >> This poll ends January 2, 2015. >> >> /Loa >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jan 8 04:10:18 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2301A89F0 for ; Thu, 8 Jan 2015 04:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aa14ug241UY for ; Thu, 8 Jan 2015 04:09:43 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3521ACD18 for ; Thu, 8 Jan 2015 04:09:38 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.169.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0385C180155B; Thu, 8 Jan 2015 13:09:35 +0100 (CET) Message-ID: <54AE737D.9070902@pi.nu> Date: Thu, 08 Jan 2015 20:09:33 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <5496EE53.6090009@pi.nu> In-Reply-To: <5496EE53.6090009@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: [mpls] Closed: Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:09:59 -0000 Working Group, This adoption poll is closed; we have an new working group document! Can the authors please post: draft-ietf-mpls-lsp-ping-lag-multipath-00 with no other changes that the filename, date and version number. /Loa for the mpls wg chairs On 2014-12-21 23:59, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group > document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is one IPR disclosures directly against this document. All the > authors has stated on the working group mailing that they are unaware of > any undisclosed IPRs against this document. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends January 7, 2015. > > /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jan 8 05:38:08 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D17D1A1DBE; Thu, 8 Jan 2015 05:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQzmRGf0xq0L; Thu, 8 Jan 2015 05:38:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E251A1B63; Thu, 8 Jan 2015 05:38:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108133802.32509.75444.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 05:38:02 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 13:38:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces Authors : Nobo Akiya George Swallow Stephane Litkowski Bruno Decraene John E. Drake Filename : draft-ietf-mpls-lsp-ping-lag-multipath-00.txt Pages : 27 Date : 2015-01-08 Abstract: This document defines an extension to the MPLS Label Switched Path (LSP) Ping and Traceroute as specified in RFC 4379. The extension allows the MPLS LSP Ping and Traceroute to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. This document updates RFC4379 and RFC6424. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multipath/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-lag-multipath-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 8 10:46:13 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2B1A007D for ; Thu, 8 Jan 2015 10:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZtxyRIE_Bah for ; Thu, 8 Jan 2015 10:46:10 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0106.outbound.protection.outlook.com [65.55.169.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4210F1A006C for ; Thu, 8 Jan 2015 10:46:10 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1432.namprd05.prod.outlook.com (25.160.107.154) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 8 Jan 2015 18:46:07 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0053.000; Thu, 8 Jan 2015 18:46:07 +0000 From: Ross Callon To: "mpls@ietf.org" , "bruno.decraene@orange.com" , "nobo@cisco.com" , "cpignata@cisco.com" , "loa@mail01.huawei.com" , "aldrin.ietf@gmail.com" Thread-Topic: IPR Poll for draft-ietf-mpls-lsp-ping-registry Thread-Index: AdArc1vI8DOj7GJuSvKpw8+C1PoOew== Date: Thu, 8 Jan 2015 18:46:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BY1PR0501MB1432; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1432; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(50986999)(54356999)(54606007)(2900100001)(74316001)(62966003)(2656002)(2201001)(92566001)(66066001)(15975445007)(102836002)(76576001)(229853001)(107046002)(77156002)(99286002)(106356001)(105586002)(68736005)(40100003)(230783001)(19580395003)(2501002)(97736003)(122556002)(4396001)(20776003)(64706001)(31966008)(87936001)(54206007)(575784001)(21056001)(33656002)(120916001)(46102003)(86362001)(99396003)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1432; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1430D86835DD68A935D31F50A5470BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2015 18:46:07.0329 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1432 Archived-At: Cc: "" Subject: [mpls] IPR Poll for draft-ietf-mpls-lsp-ping-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:46:12 -0000 --_000_BY1PR0501MB1430D86835DD68A935D31F50A5470BY1PR0501MB1430_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, The authors of draft-ietf-mpls-lsp-ping-registry have told us that the draft is ready for working group last call (WGLC). Before we do the WGLC we want to do an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-lsp-ping-registry? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_BY1PR0501MB1430D86835DD68A935D31F50A5470BY1PR0501MB1430_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
The authors of draft-ietf-mpls-lsp-ping-registry have told us that the=
draft is ready for working group last call (WGLC).
 
Before we do the WGLC we want to do an IPR poll on the document.
 
This mail starts that IPR poll.
 
Are you aware of any IPR that applies to draft-ietf-mpls-lsp-ping-regi= stry?
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
 
Currently there are no IPR disclosures that relates to this document.<= /div>
 
If you are listed as a document author or contributor please respond t= o
this email regardless of whether or not you are aware of any relevant<= /div>
IPR. *The response needs to be sent to the MPLS wg mailing list.* The =
document will not advance to the next stage until a response has been<= /div>
received from each author and contributor.
 
If you are on the MPLS WG email list but are not listed as an author o= r
contributor, then please explicitly respond only if you are aware of a= ny
IPR that has not yet been disclosed in conformance with IETF rules.
 
Thanks, Ross
(as MPLS WG co-chair)
 
 --_000_BY1PR0501MB1430D86835DD68A935D31F50A5470BY1PR0501MB1430_-- From nobody Thu Jan 8 11:07:00 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897B41A006D; Thu, 8 Jan 2015 11:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k0V8B6JtdSd; Thu, 8 Jan 2015 11:06:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88A1A006C; Thu, 8 Jan 2015 11:06:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108190656.11729.11265.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 11:06:56 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-mrt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 19:06:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Extensions to Support Maximally Redundant Trees Authors : Alia Atlas Kishore Tiruveedhula Chris Bowers Jeff Tantsura IJsbrand Wijnands Filename : draft-ietf-mpls-ldp-mrt-00.txt Pages : 16 Date : 2015-01-08 Abstract: This document specifies extensions to the Label Distribution Protocol(LDP) to support the creation of label-switched paths for Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR. The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for LSRs and LERs advertising the MRT Capability. MRT-FRR uses LDP multi-topology extensions and requires three different multi-topology IDs to be allocated from the LDP MT-ID space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-mrt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-mrt-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 8 11:14:20 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A8A1A8F48 for ; Thu, 8 Jan 2015 11:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HfbTp0S3KP8 for ; Thu, 8 Jan 2015 11:14:16 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F631A8F45 for ; Thu, 8 Jan 2015 11:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4915; q=dns/txt; s=iport; t=1420744455; x=1421954055; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Kbg9qjVbjm3SqYFy1Ha8eny2SPRlz2bd/HB1DXECcRY=; b=fAVRfDdbC+WYqL8r63JoYNPF+J/TMMYiFBdDs2uB8Psy1PTjZCtec+cf XHfVaeCRcSt4ztIJRXIqMXShzEtkpLzbzAG1V5M+OBJYSOjkfxUPEwI0E /zs9TRH6xzYUzHke/rFSYstr87XfACj8g2KLlp9AWmgKnkaifqZLOUwvt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFANTVrlStJA2G/2dsb2JhbABcgkMhIoEqBMNYiBYCgRFDAQEBAQF9hA0BAQRuBgUQAgEIBAoxBzIUEQEBBA4FiCwBxxgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjxcQAgFPB4MWgRMFjFmBWokHgQ6CcY1vIoNub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,724,1413244800"; d="scan'208,217";a="385448351" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jan 2015 19:14:15 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t08JEEQD003783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Jan 2015 19:14:15 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 13:14:14 -0600 From: "Carlos Pignataro (cpignata)" To: Ross Callon Thread-Topic: IPR Poll for draft-ietf-mpls-lsp-ping-registry Thread-Index: AdArc1vI8DOj7GJuSvKpw8+C1PoOewANjkIA Date: Thu, 8 Jan 2015 19:14:13 +0000 Message-ID: <1B0DD6DF-C7CE-4AAB-915B-7A91240C790C@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/alternative; boundary="_000_1B0DD6DFC7CE4AAB915B7A91240C790Cciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , Loa Andersson , "" Subject: Re: [mpls] IPR Poll for draft-ietf-mpls-lsp-ping-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 19:14:17 -0000 --_000_1B0DD6DFC7CE4AAB915B7A91240C790Cciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ross, I am not aware of any relevant IPR related to this document. Thanks, Carlos. On Jan 8, 2015, at 1:46 PM, Ross Callon > wrote: Working Group, The authors of draft-ietf-mpls-lsp-ping-registry have told us that the draft is ready for working group last call (WGLC). Before we do the WGLC we want to do an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-lsp-ping-registry? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_1B0DD6DFC7CE4AAB915B7A91240C790Cciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <21E0ED96FD9A414BB14CAB783A3DC801@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Ross,

I am not aware of any relevant IPR related to this document= .

Thanks,

Carlos.

On Jan 8, 2015, at 1:46 PM, Ross Callon <rcallon@juniper.net> wrote:

Working Group,
 
The authors of draft-ietf-mpls-lsp-ping-registry have told = us that the
draft is ready for working group last call (WGLC). 
 
Before we do the WGLC we want to do an IPR poll on the docu= ment.
 
This mail starts that IPR poll.
 
Are you aware of any IPR that applies to draft-ietf-mpls-ls= p-ping-registry?
 
If so, has this IPR been disclosed in compliance with IETF = IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
 
Currently there are no IPR disclosures that relates to this= document.
 
If you are listed as a document author or contributor pleas= e respond to
this email regardless of whether or not you are aware of an= y relevant
IPR. *The response needs to be sent to the MPLS wg mailing = list.* The 
document will not advance to the next stage until a respons= e has been
received from each author and contributor.
 
If you are on the MPLS WG email list but are not listed as = an author or
contributor, then please explicitly respond only if you are= aware of any
IPR that has not yet been disclosed in conformance with IET= F rules.
 
Thanks, Ross
(as MPLS WG co-chair)

--_000_1B0DD6DFC7CE4AAB915B7A91240C790Cciscocom_-- From nobody Thu Jan 8 11:51:37 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FDE1A040B for ; Thu, 8 Jan 2015 11:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCQna57BmHoC for ; Thu, 8 Jan 2015 11:51:33 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01891A03A9 for ; Thu, 8 Jan 2015 11:51:33 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id x3so4207255qcv.1 for ; Thu, 08 Jan 2015 11:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=fz3vOFBZZ+GG1qZicOS6GHaACengUVGOF1ZuchRaX50=; b=BENquQhDlAzYtkvEZ0ajNA2C2bLVguppFLCZBjsvjn30GeYZwmXfosegEfw2mX7zvu C4+cv8uP8WgkEieMsiYx3QaJmjNcfhmAWIV8d/GF27upNEnj3emyd7071HYpoij4klCT 5M+uvwSANGwj+B1PE2XeOEUV90cSYBh48Mu5bnNzYXRqV0mZV6zjCD1CBKHaaIHPx0z2 QbqAfYua9zHm/Bj/n4ncW3+X51h2jGAfnKqkbiczZBzStr6WQONQBCyU87ueJDysbI0h Tdu8OnGlAmK3foN5rvw2FygvShs6TiUhMLUiAnFnJhwxUesF1X8AO+X/LxhpbZBS5j0l ppMA== X-Received: by 10.140.93.139 with SMTP id d11mr17832660qge.101.1420746692438; Thu, 08 Jan 2015 11:51:32 -0800 (PST) Received: from ?IPv6:2002:6b03:9a3c:e472:9d72:3474:9379:abfe? ([2002:6b03:9a3c:e472:9d72:3474:9379:abfe]) by mx.google.com with ESMTPSA id p7sm4905889qat.4.2015.01.08.11.51.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Jan 2015 11:51:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_31C2D79F-AA10-4FAF-A7BD-19CCA3121A75" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Sam Aldrin In-Reply-To: Date: Thu, 8 Jan 2015 11:51:29 -0800 Message-Id: <1F0AB5DD-23A0-426E-AC12-9672AFDF32CE@gmail.com> References: To: Ross Callon X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "mpls@ietf.org" , "loa@mail01.huawei.com" , "" Subject: Re: [mpls] IPR Poll for draft-ietf-mpls-lsp-ping-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 19:51:35 -0000 --Apple-Mail=_31C2D79F-AA10-4FAF-A7BD-19CCA3121A75 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I am not aware of any IPR related to this document. -sam > On Jan 8, 2015, at 10:46 AM, Ross Callon wrote: > > Working Group, > > The authors of draft-ietf-mpls-lsp-ping-registry have told us that the > draft is ready for working group last call (WGLC). > > Before we do the WGLC we want to do an IPR poll on the document. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-lsp-ping-registry? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are no IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Ross > (as MPLS WG co-chair) --Apple-Mail=_31C2D79F-AA10-4FAF-A7BD-19CCA3121A75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am not aware of any IPR related to this document.

-sam
On = Jan 8, 2015, at 10:46 AM, Ross Callon <rcallon@juniper.net>= wrote:

Working Group,
 
The authors of = draft-ietf-mpls-lsp-ping-registry have told us that the
draft is ready for working group last call (WGLC). 
 
Before we do the WGLC we want to = do an IPR poll on the document.
 
This mail starts that IPR poll.
 
Are you aware of any IPR that = applies to draft-ietf-mpls-lsp-ping-registry?
 
If so, has this IPR been = disclosed in compliance with IETF IPR rules
(see = RFCs 3979, 4879, 3669 and 5378 for more details).
 
Currently there are no IPR = disclosures that relates to this document.
 
If you are listed as a document = author or contributor please respond to
this email = regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing = list.* The 
document will not advance to the next stage until a response = has been
received from each author and = contributor.
 
If you are = on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are = aware of any
IPR that has not yet been disclosed in = conformance with IETF rules.
 
Thanks, Ross
(as MPLS WG = co-chair)

= --Apple-Mail=_31C2D79F-AA10-4FAF-A7BD-19CCA3121A75-- From nobody Thu Jan 8 11:57:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D8F1A0382 for ; Thu, 8 Jan 2015 11:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkbOGcgaGmHy for ; Thu, 8 Jan 2015 11:57:43 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82C61A0363 for ; Thu, 8 Jan 2015 11:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11885; q=dns/txt; s=iport; t=1420747063; x=1421956663; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l0Qn2ZoFc4jM8F5tv4qG5Wg1yCTo7XCLub3CrEfYhRQ=; b=jz+g4IA1irMttVACt6Gy6stoJPjf7pcXUMS2fZTPOXYmuwg9PbXcD/qP Y/lO5+D8iiOdeXxFdnznjPXjTi0r6uT09XQ6Kkc/4RBpgChZGAM1KQBLE DzkhpDSzSfR+IoiDAOeS60j4CzdxhX1L4BBjZprh3SBKle0j2MKYplSsc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAOngrlStJA2D/2dsb2JhbABcgkMhIlJYBMtyAoERQwEBAQEBfYQMAQEBBC1BBgUQAgEIDgMEAQELHQchERQJCAEBBAENBQiIEAMRAcNDDYNDAQEBAQEBAQEBAQEBAQEBAQEBAQEBF41PgUgQAgEeMQYBgxaBEwWMWYFah0OCUoJxiBKFXSKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,724,1413244800"; d="scan'208,217";a="385453854" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jan 2015 19:57:42 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t08Jvgpi010401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Jan 2015 19:57:42 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 13:57:41 -0600 From: "Nobo Akiya (nobo)" To: Ross Callon , "mpls@ietf.org" , "bruno.decraene@orange.com" , "Carlos Pignataro (cpignata)" , "loa@mail01.huawei.com" , "aldrin.ietf@gmail.com" Thread-Topic: IPR Poll for draft-ietf-mpls-lsp-ping-registry Thread-Index: AdArc1vI8DOj7GJuSvKpw8+C1PoOewACej0Q Date: Thu, 8 Jan 2015 19:57:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.76] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD39446D3A7AFxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [mpls] IPR Poll for draft-ietf-mpls-lsp-ping-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 19:57:45 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD39446D3A7AFxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, I am not aware of any IPR related to this document. Thanks! -Nobo From: Ross Callon [mailto:rcallon@juniper.net] Sent: Thursday, January 08, 2015 1:46 PM To: mpls@ietf.org; bruno.decraene@orange.com; Nobo Akiya (nobo); Carlos Pig= nataro (cpignata); loa@mail01.huawei.com; aldrin.ietf@gmail.com Cc: Subject: IPR Poll for draft-ietf-mpls-lsp-ping-registry Working Group, The authors of draft-ietf-mpls-lsp-ping-registry have told us that the draft is ready for working group last call (WGLC). Before we do the WGLC we want to do an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-lsp-ping-registry? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_CECE764681BE964CBE1DFF78F3CDD39446D3A7AFxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 <= /p>

I am not aware of any IPR= related to this document.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: Ross Callon [mailto:rcallon@juniper.net]
Sent: Thursday, January 08, 2015 1:46 PM
To: mpls@ietf.org; bruno.decraene@orange.com; Nobo Akiya (nobo); Car= los Pignataro (cpignata); loa@mail01.huawei.com; aldrin.ietf@gmail.com
Cc: <mpls-chairs@tools.ietf.org>
Subject: IPR Poll for draft-ietf-mpls-lsp-ping-registry

 

Working Group,

 

The authors of draft-ietf-mpls-lsp-ping= -registry have told us that the

draft is ready for working group last c= all (WGLC).

 

Before we do the WGLC we want to do an = IPR poll on the document.

 

This mail starts that IPR poll.

 

Are you aware of any IPR that applies t= o draft-ietf-mpls-lsp-ping-registry?

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details).

 

Currently there are no IPR disclosures = that relates to this document.

 

If you are listed as a document author = or contributor please respond to

this email regardless of whether or not= you are aware of any relevant

IPR. *The response needs to be sent to = the MPLS wg mailing list.* The

document will not advance to the next s= tage until a response has been

received from each author and contribut= or.

 

If you are on the MPLS WG email list bu= t are not listed as an author or

contributor, then please explicitly res= pond only if you are aware of any

IPR that has not yet been disclosed in = conformance with IETF rules.

 

Thanks, Ross

(as MPLS WG co-chair)=

 

--_000_CECE764681BE964CBE1DFF78F3CDD39446D3A7AFxmbalnx01ciscoc_-- From nobody Thu Jan 8 17:49:28 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E771A01A5 for ; Thu, 8 Jan 2015 17:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGMRiqI5qwui for ; Thu, 8 Jan 2015 17:49:23 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859631A1A32 for ; Thu, 8 Jan 2015 17:49:23 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.169.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 3E6AC1801127; Fri, 9 Jan 2015 02:49:17 +0100 (CET) Message-ID: <54AF3399.6070000@pi.nu> Date: Fri, 09 Jan 2015 09:49:13 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , Ross Callon , "mpls@ietf.org" , "bruno.decraene@orange.com" , "Carlos Pignataro (cpignata)" , "loa@mail01.huawei.com" , "aldrin.ietf@gmail.com" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [mpls] IPR Poll for draft-ietf-mpls-lsp-ping-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 01:49:26 -0000 Ross, Likewise, I am not aware of any IPRs that relate to this draft. /Loa On 2015-01-09 03:57, Nobo Akiya (nobo) wrote: > Hi Ross, > > I am not aware of any IPR related to this document. > > Thanks! > > -Nobo > > *From:*Ross Callon [mailto:rcallon@juniper.net] > *Sent:* Thursday, January 08, 2015 1:46 PM > *To:* mpls@ietf.org; bruno.decraene@orange.com; Nobo Akiya (nobo); > Carlos Pignataro (cpignata); loa@mail01.huawei.com; aldrin.ietf@gmail.com > *Cc:* > *Subject:* IPR Poll for draft-ietf-mpls-lsp-ping-registry > > Working Group, > > The authors of draft-ietf-mpls-lsp-ping-registry have told us that the > > draft is ready for working group last call (WGLC). > > Before we do the WGLC we want to do an IPR poll on the document. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-lsp-ping-registry? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are no IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > > this email regardless of whether or not you are aware of any relevant > > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > > document will not advance to the next stage until a response has been > > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > > contributor, then please explicitly respond only if you are aware of any > > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Ross > > (as MPLS WG co-chair) > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jan 8 20:47:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789671A039C for ; Thu, 8 Jan 2015 20:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPtPl08hxEAl for ; Thu, 8 Jan 2015 20:47:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC491A03A8 for ; Thu, 8 Jan 2015 20:47:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109044743.20105.62568.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 20:47:43 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 04:47:45 -0000 URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 8 23:42:45 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1631A86E8 for ; Thu, 8 Jan 2015 23:42:42 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlUEkctD9qqB for ; Thu, 8 Jan 2015 23:42:40 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364301A86E7 for ; Thu, 8 Jan 2015 23:42:40 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id F1977374200; Fri, 9 Jan 2015 08:42:38 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id CF0D618006C; Fri, 9 Jan 2015 08:42:38 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 9 Jan 2015 08:42:38 +0100 From: To: Ross Callon Thread-Topic: IPR Poll for draft-ietf-mpls-lsp-ping-registry Thread-Index: AdArc1vI8DOj7GJuSvKpw8+C1PoOewAbEtTw Date: Fri, 9 Jan 2015 07:42:38 +0000 Message-ID: <8117_1420789358_54AF866E_8117_12898_1_53C29892C857584299CBF5D05346208A0EAFF377@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: Cc: "mpls@ietf.org" , "loa@mail01.huawei.com" , "" Subject: Re: [mpls] IPR Poll for draft-ietf-mpls-lsp-ping-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 07:42:43 -0000 Ross, I am not aware of any IPR related to this document. Thanks, Bruno ------------- From: Ross Callon [mailto:rcallon@juniper.net] Sent: Thursday, January 08, = 2015 7:46 PM Working Group, =A0 The authors of draft-ietf-mpls-lsp-ping-registry have told us that the draft is ready for working group last call (WGLC).=20 =A0 Before we do the WGLC we want to do an IPR poll on the document. =A0 This mail starts that IPR poll. =A0 Are you aware of any IPR that applies to draft-ietf-mpls-lsp-ping-registry? =A0 If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). =A0 Currently there are no IPR disclosures that relates to this document. =A0 If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The=20 document will not advance to the next stage until a response has been received from each author and contributor. =A0 If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. =A0 Thanks, Ross (as MPLS WG co-chair) =A0 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jan 9 01:19:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98BB1A86E8 for ; Fri, 9 Jan 2015 01:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O5Yo3L5Pb2G for ; Fri, 9 Jan 2015 01:19:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A801A86F5 for ; Fri, 9 Jan 2015 01:19:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109091941.31994.96880.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 01:19:41 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 09:19:44 -0000 Deleted milestone "Submit draft-ietf-mpls-rsvp-egress-protection for publication". Deleted milestone "Submit draft-ietf-mpls-rsvp-ingress-protection for publication". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Jan 9 01:26:07 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159721A86EB; Fri, 9 Jan 2015 01:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qggNZIISWny; Fri, 9 Jan 2015 01:26:02 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446CF1A86E8; Fri, 9 Jan 2015 01:26:02 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.169.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 40CF71801127; Fri, 9 Jan 2015 10:25:58 +0100 (CET) Message-ID: <54AF9EA4.1040505@pi.nu> Date: Fri, 09 Jan 2015 17:25:56 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: mpls@ietf.org References: <20150109091941.31994.96880.idtracker@ietfa.amsl.com> In-Reply-To: <20150109091941.31994.96880.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" , "mpls-chairs@tools.ietf.org" , "teas-chairs@ietf.org" Subject: Re: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 09:26:05 -0000 Working Group, I have removed two of our milestones On 2015-01-09 17:19, IETF Secretariat wrote: > Deleted milestone "Submit draft-ietf-mpls-rsvp-egress-protection for > publication". > > Deleted milestone "Submit draft-ietf-mpls-rsvp-ingress-protection for > publication". > > URL: http://datatracker.ietf.org/wg/mpls/charter/ > This is not because we actually requested publication, but because of that both documents as a result of the re-tuning of the RTG Area now is under the purview of the teas wg. Ross will remain the Shepherd for both documents. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Jan 9 11:06:05 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1891ABD8F for ; Fri, 9 Jan 2015 11:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rfPXVpCw50Y; Fri, 9 Jan 2015 11:06:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5951A924E; Fri, 9 Jan 2015 11:06:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, "Loa Andersson" , mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109190602.21665.44625.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 11:06:02 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 19:06:05 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ From nobody Fri Jan 9 12:46:58 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1561A9037; Fri, 9 Jan 2015 12:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUyzkONb0C4L; Fri, 9 Jan 2015 12:46:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 439F11A0396; Fri, 9 Jan 2015 12:46:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109204653.19253.38671.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 12:46:53 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-15.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 20:46:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Inter-Area P2MP Segmented LSPs Authors : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-15.txt Pages : 42 Date : 2015-01-09 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 9 15:19:41 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188441A1A3B; Fri, 9 Jan 2015 15:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsDGgYQvR0lL; Fri, 9 Jan 2015 15:19:16 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92DE1A1AB4; Fri, 9 Jan 2015 15:19:15 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 1CAABA966768F; Fri, 9 Jan 2015 23:19:08 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t09NJBhI003711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 18:19:11 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 18:19:11 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" , "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCq3X4CABH7I4A== Date: Fri, 9 Jan 2015 23:19:10 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947CA71B@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 23:19:27 -0000 Hi Rajiv, Thanks for the reply. I added some follow-up inline below. Regards, Mustapha. > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Tuesday, January 06, 2015 6:03 PM > To: Aissaoui, Mustapha (Mustapha); ietf@ietf.org; IETF-Announce > Cc: mpls@ietf.org > Subject: Re: [mpls] Last Call: (Updates= to LDP for > IPv6) to Proposed Standard >=20 > Hi Mustapha, >=20 > > Having said that, I want to keep the spirit of cooperation and make > >sure we get this draft published. To that effect, I am not opposed to > >its publication as long as the following points are clarified in the > >draft since now FEC capability of the LSR peer is determined by a > >check a both adjacency and session levels: >=20 > Thanks for pointing out the below scenarios. We think that all but one ar= e either > covered or require editorial changes. >=20 >=20 > 1. This scenario (sending hellos with DS capability on fewer interfaces f= or a peer) > does NOT look realistic, since hitless upgrading a router would result in= sending > v4+v6 hellos either with DS capability or without DS capability (for a DS= peer, > assuming the peer was enabled for DS LDP, default or not, in an implement= ation). >=20 > Perhaps, you had a different scenario in mind. MA> This could occur during a hitless upgrade for Hello adjacencies from di= fferent line cards during a transient time. I will not insist on this point= but I found the draft lacks what action to take if the Hello messages rece= ived on parallel links from the same LSR are not consistent, meaning they h= ave different TR values or the message on one link do not have the DS capab= ility. The only thing I found is this paragraph in Section 6.1.1 but it doe= s not say what to do if an LSR receives inconsistent Hello messages: " An LSR MUST convey the same transport connection preference ("TR" field value) in all (link and targeted) Hellos that advertise the same label space to the same peer and/or on same interface. This ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency. " =20 > 2. Yes. This scenario is well covered in section 6.1.1 point#3. >=20 >=20 > // > 3. If "Dual-stack capability" TLV is NOT present, and >=20 > =D0 > resulting in any established LDPoIPv4 session being reset > and a fatal Notification message being sent (with status >=20 > =D0 >=20 > // MA> What I was talking about is a transition from state 2a to state 3a or f= rom state 2b to state 3b in Section 6.1.1. Perhaps one way to explicitly st= ate that the session is bounced would be to add something like this to item= s 2a and 2b of Section 6..1.1: " 2. If "Dual-stack capability" TLV is present, and remote preference matches with the local preference, then: a) If TR=3D0100 (LDPoIPv4), then determine the active/passive roles for TCP connection using IPv4 transport address as defined in section 2.5.2 of RFC 5036. b) If TR=3D0110 (LDPoIPv6), then determine the active/passive roles for TCP connection by using IPv6 transport address as defined in section 2.5.2 of RFC 5036. *If subsequently to establishing the LDP session, the Hello messages fro= m the peer do not include the Dual-stack capability TLV, the session is terminated = and a fatal Notification message is sent with status code of 'Dual-Stac= k Non-Compliance' (IANA allocation TBD).* " >=20 > 3. Yes (to the expected behavior). This is somewhat covered in bullet #1 = in section > 6.1.1, but we can make it explicit by adding "or does not get recognized= =B2 as below: >=20 >=20 > OLD: > If "Dual-stack capability" TLV is present and remote preference does not = match > with the local preference,.. >=20 >=20 > NEW: > If "Dual-stack capability" TLV is present and remote preference does not = match > with the local preference (or does not get recognized),.. MA> Your proposed modification does address this comment. Thank you. =20 > 4 and 5. Yes (to the expected behavior). It is implicit in section 7.2 pa= ra 4. >=20 > //.. > An LSR MAY further constrain the advertisement of FEC-label bindings for= a > particular address family by negotiating the IP Capability...// >=20 > Are you suggesting to make it explicit? MA> Yes I wanted something more explicit. This section certainly says the I= Pv6 prefix FEC capability can further constrain a particular FEC type which= is allowed by the check of the DS capability TLV. It however does not disc= uss the negative case, i.e., the DS capability TLV did not allow a FEC type= but the IP capability allowed it.=20 I believe the following addition to an earlier paragraph in Section 7.2 wou= ld help clarify this: " If an LSR enabled with Dual-stack LDP for a peer and 1. Is NOT able to find the Dual-stack capability TLV in the incoming IPv4 LDP hello messages from that peer, then the LSR MUST NOT advertise IPv6 FEC-label bindings to the peer *even if it = received an IP capability=20 from the peer indicating the enabling of the IPv6 FEC type*. " BTW, there is a "copy & paste" mistake in the following paragraph in the sa= me Section 7.2. The "via ADDRESS message" is not correct here since this is= about FEC distribution, hence Label Mapping message, and not address distr= ibution. " If an LSR is enabled with Single-stack LDP for any peer, then it MUST advertise (via ADDRESS message) FEC-Label bindings for the enabled address family, and accept FEC-Label bindings for the enabled address family. " =20 > -- > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: , Mustapha Aissaoui > Date: Tuesday, December 16, 2014 at 12:21 PM > To: IETF Discussion , IETF-Announce > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Last Call: (Updates > to LDP for IPv6) to Proposed Standard >=20 > >Hi Adrian and all, > >I was the one who raised the interop issues we found while testing our > >implementation of LDP IPv6 against existing and deployed implementations= . > >I proposed a simple method of using the existing FEC advertisement > >capability at the session level as a way for an LSR to detect if an > >implementation support LDP IPv6 FECs and IPv6 addresses. This existing > >FEC advertisement capability at session level is defined in > >draft-ietf-mpls-ldp-ip-pw-capability-08 but with the limitation that it > >can be used only to disable support of IPv6 FECs in LDP Initialization > >Message; we proposed to generalize the method to also indicate explicit > >support for IPv6 FECs and IPv6 Addresses in LDP Initialization Message. > >This method is safe and was also used with mLDP P2MP and MP2MP FECs > when > >they were introduced. The intent here is that all session level > >capabilities in LDP should follow RFC 5561 approach. > > > >There was an individual contributor which supported the proposal on the > >mailing list but the authors chose to ignore it and went with a proposal > >which overloaded the meaning of the dual-stack capability TLV. Regardles= s > >of the merit of either method, the discussion on the MPLS mailing list > >was not closed properly from my perspective. > > > >Now here is the concern I raised with using the dual-stack capability. > >Not only this TLV is an adjacency level feature which is has nothing to > >do with FEC capability advertisement, but it is introducing complexity i= n > >the implementation which now has to check dual-stack capability for > >*each* adjacency to the peer *and* the session level FEC capability to > >decide what the peer is capable of at the *session level*. > > > >Having said that, I want to keep the spirit of cooperation and make sure > >we get this draft published. To that effect, I am not opposed to its > >publication as long as the following points are clarified in the draft > >since now FEC capability of the LSR peer is determined by a check a both > >adjacency and session levels: > > > >1. The draft is missing the behavior when multiple adjacencies exist to > >the same LSR and the peer LSR advertised the dual-stack capability only > >over a subset of these Hello adjacencies. > >I assume here the peer LSR is considered to be dual-stack capable as soo= n > >as any of the Hello adjacencies includes the dual-stack capability. This > >would allow a hitless upgrade scenario from an older implementation to > >one which complies to this draft > > > >2. Similarly, what would be the behavior if a hello adjacency changes > >from sending the dual-stack capability to not sending it? This would be > >for example in a hitless downgrade to a version of LDP which does not > >comply to this draft. > >I assume here that the session must be bounced since the LSRs need a > >clean state to not send IPv6 addresses and IPv6 FECs. > > > >3. The document defines 2 values for the dual-stack capability TR. It > >does not mention the behavior when an unknown value is received. > >Will that be considered a fatal error? > > > >4. The draft is missing the behavior of when the peer LSR does not > >advertise the dual-stack capability in all the Hello adjacencies but it > >advertised the enabling or disabling of the IPv6 prefix FEC capability i= n > >the session initialization message. > >I assume here that the absence of the dual-stack capability overrides an= y > >session level IPv6 FEC prefix capability advertisement. > > > >5. The draft is missing the behavior of when the peer LSR does not > >advertise the dual-stack capability in all the Hello adjacencies but it > >advertised the enabling of the IPv6 prefix FEC capability in the session > >Capability message. > >I assume the same behavior as in (4) applies here. > > > >Regards, > >Mustapha. > > > >> -----Original Message----- > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG > >> Sent: Thursday, December 04, 2014 2:37 PM > >> To: IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: [mpls] Last Call: (Updates > >>to LDP for IPv6) > >> to Proposed Standard > >> > >> > >> The IESG has received a request from the Multiprotocol Label Switching > >>WG > >> (mpls) to consider the following document: > >> - 'Updates to LDP for IPv6' > >> as Proposed Standard > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > >>final > >> comments on this action. Please send substantive comments to the > >>ietf@ietf.org > >> mailing lists by 2014-12-18. Exceptionally, comments may be sent to > >>iesg@ietf.org > >> instead. In either case, please retain the beginning of the Subject > >>line to allow > >> automated sorting. > >> > >> Abstract > >> > >> The Label Distribution Protocol (LDP) specification defines > >> procedures to exchange label bindings over either IPv4, or IPv6 or > >> both networks. This document corrects and clarifies the LDP behavio= r > >> when IPv6 network is used (with or without IPv4). This document > >> updates RFC 5036 and RFC 6720. > >> > >> The file can be obtained via > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ > >> > >> IESG discussion can be tracked via > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Jan 9 15:22:17 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969E61A005C; Fri, 9 Jan 2015 15:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XNlbK5z7s1R; Fri, 9 Jan 2015 15:22:08 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19F41A1ABF; Fri, 9 Jan 2015 15:22:05 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 355978AB0F0; Fri, 9 Jan 2015 23:22:01 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t09NM2HV012786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 18:22:02 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 18:22:02 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "adrian@olddog.co.uk" , "ietf@ietf.org" Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCqEA0CAAZ+DAIADPvEg Date: Fri, 9 Jan 2015 23:22:01 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947CA754@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D947C86E5@US70UWXCHMBA04.zam.alcatel-lucent.com> <065001d02a99$70bf1c00$523d5400$@olddog.co.uk> In-Reply-To: <065001d02a99$70bf1c00$523d5400$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 23:22:10 -0000 Ok thanks Adrian. Yes, we should close quickly on the remaining points. Mustapha. > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, January 07, 2015 11:46 AM > To: Aissaoui, Mustapha (Mustapha); ietf@ietf.org > Cc: mpls@ietf.org > Subject: RE: [mpls] Last Call: (Updates= to LDP for > IPv6) to Proposed Standard >=20 > Hi Mustapha, >=20 > > Can we also close on the IANA assignment for the new TLVs and > > specifically for the Dual-Stack Capability TLV? > > > > I assume this will be drawn from the Common Hello Parameters range of > > the LDP TLV Type Name Space. The next available value is 0x0409. I > > appreciate if you > could > > confirm this value. >=20 > Are you asking for an early allocation of this code point? >=20 > The document has been through IETF last call and with a few edits will be= ready for > processing by the IESG. After IESG approval, the IANA will make a provisi= onal > allocation of a code point that will be confirmed on publication of the R= FC. The > IANA is *likely* to allocate the next available value, but not if another= I-D gets there > first :-) >=20 > Unless there is a reason for a rush, I suggest that we wait for normal pr= ocess. > Constructive discussion of the remaining issues with this draft should en= able that > to complete quickly. >=20 > Thanks, > Adrian From nobody Fri Jan 9 19:27:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36B01A8F3E; Fri, 9 Jan 2015 19:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im29UkBrBZAv; Fri, 9 Jan 2015 19:27:33 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8E31A8BB3; Fri, 9 Jan 2015 19:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18890; q=dns/txt; s=iport; t=1420860453; x=1422070053; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QByLzpEY7T++AbY2Ptqsgx3kVkBJWumkkje76o4I5PU=; b=Pn9RTlTMFcFSKVqFyCaWW3m98JbY8/AjWVniZ6x3aQh5PYjMUrCTU88c NRyiLxwvgFIdDsyLxw5Q+IVEYrwT0kZv2IvAEuhESs7+lULgY4vpbRROw VtMDyt0hotzjShN90sJcEkhRXCvtbZkUP0e5BcjwiMwIQ9jP4nGOWvA1n g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAB2bsFStJA2K/2dsb2JhbABcgwZSWASDAcJ4CoVxAhx7QwEBAQEBfYQMAQEBBAEBASAROgsMBAIBCBEDAQEBAwIfBAMCAgIlCxQBCAgCBAENBYgsDbZTk1cBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGOFg8IKwcEAoJigUEBBIxdgVuDRIVHgQ4wgkGKO4M6IoIygTxvgQVAfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,735,1413244800"; d="scan'208";a="111950905" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP; 10 Jan 2015 03:27:31 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t0A3RVNR001281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Jan 2015 03:27:31 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 21:27:31 -0600 From: "Rajiv Asati (rajiva)" To: "Aissaoui, Mustapha (Mustapha)" , "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCq3X4CABH7I4IAAgi6A Date: Sat, 10 Jan 2015 03:27:31 +0000 Message-ID: References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D947CA71B@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947CA71B@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.235.12] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 03:27:37 -0000 SGkgTXVzdGFwaGEsIA0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaXR5Lg0KDQoxLiBZb3UgaGF2ZSBh IGZhaXIgcG9pbnQuIFdoaWxlIGl0IGlzIGltcGxpY2l0IHRoYXQgc2VjdGlvbiAyLjUuNSBvZiBS RkMNCjUwMzYgKG1haW50YWluaW5nIGhlbGxvIGFkaikgd291bGQgYXBwbHksIGl0IGlzIHJlYXNv bmFibGUgdG8gbWFrZSBpdA0KZXhwbGljaXQuIFdlIGNhbiBhZGQgdGhlIGJlbG93IHRleHQgLQ0K DQovL0EgRHVhbC1zdGFjayBMU1IgTVVTVCBzdGlsbCBmb2xsb3cgc2VjdGlvbiAyLjUuNSBvZiBS RkM1MDM2IGFuZCBjaGVjaw0KZm9yIG1hdGNoaW5nIEhlbGxvDQptZXNzYWdlcyBmcm9tIHRoZSBw ZWVyIChlaXRoZXIgYWxsIEhlbGxvcyBhbHNvIGluY2x1ZGUgdGhlIER1YWwtc3RhY2sNCmNhcGFi aWxpdHkgKHdpdGggc2FtZSBUUiB2YWx1ZSkgb3Igbm9uZSBkbykuLy8NCg0KDQoNCjIuIFRoaXMg aXMgYWxyZWFkeSBjb3ZlcmVkIGluIGJvdGggM2EgYW5kIDNiIGJ5IHRoZSBmb2xsb3dpbmcgdmVy YmlhZ2UNCiJIb3dldmVyLCBpZiBJUHY2IGhlbGxvcyBhcmUgYWxzbyByZWNlaXZlZCBhdCBhbnkg dGltZSBmcm9tIHRoYXQNCm5laWdoYm9yLi7igJ0gaW4gdGhlIGJlZ2lubmluZyBvZiAybmQgcGFy YS4gTm90ZSAiYXQgYW55IHRpbWXigJ0gaGVyZS4NCg0KVGhlIHRleHQgaXMgc3VmZmljaWVudCwg SU1ITy4NCg0KMy4gQ2xvc2VkLiANCg0KNC41LiBPay4gVGhlIGZvbGxvd2luZyAiKGV2ZW4gaWYg SVAgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBmb3IgSVB2Ng0KYWRkcmVzcyBmYW1pbHkgd2FzIGRv bmUp4oCdIGlzIGFwcGVuZGVkIHRvIG1ha2UgaXQgZXhwbGljaXQuIEFuZCBUaGFua3MgZm9yDQpj YXRjaGluZyB0aGUgY29weS1wYXN0ZSBlcnJvci4gOikgRml4ZWQuDQoNCkNsb3NlZC4NCg0KDQot LSANCkNoZWVycywNClJhaml2IEFzYXRpDQpEaXN0aW5ndWlzaGVkIEVuZ2luZWVyLCBDaXNjbw0K DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiA8QWlzc2FvdWk+LCBN dXN0YXBoYSBBaXNzYW91aSA8bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tPg0K RGF0ZTogRnJpZGF5LCBKYW51YXJ5IDksIDIwMTUgYXQgNjoxOSBQTQ0KVG86IFJhaml2IEFzYXRp IDxyYWppdmFAY2lzY28uY29tPiwgSUVURiBEaXNjdXNzaW9uIDxpZXRmQGlldGYub3JnPiwNCklF VEYtQW5ub3VuY2UgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQpDYzogIm1wbHNAaWV0Zi5vcmci IDxtcGxzQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1p ZXRmLW1wbHMtbGRwLWlwdjYtMTQudHh0PiAoVXBkYXRlcw0KdG8gTERQIGZvciBJUHY2KSB0byBQ cm9wb3NlZCBTdGFuZGFyZA0KDQo+SGkgUmFqaXYsDQo+VGhhbmtzIGZvciB0aGUgcmVwbHkuIEkg YWRkZWQgc29tZSBmb2xsb3ctdXAgaW5saW5lIGJlbG93Lg0KPg0KPlJlZ2FyZHMsDQo+TXVzdGFw aGEuDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUmFqaXYgQXNh dGkgKHJhaml2YSkgW21haWx0bzpyYWppdmFAY2lzY28uY29tXQ0KPj4gU2VudDogVHVlc2RheSwg SmFudWFyeSAwNiwgMjAxNSA2OjAzIFBNDQo+PiBUbzogQWlzc2FvdWksIE11c3RhcGhhIChNdXN0 YXBoYSk7IGlldGZAaWV0Zi5vcmc7IElFVEYtQW5ub3VuY2UNCj4+IENjOiBtcGxzQGlldGYub3Jn DQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1sZHAt aXB2Ni0xNC50eHQ+DQo+PihVcGRhdGVzIHRvIExEUCBmb3INCj4+IElQdjYpIHRvIFByb3Bvc2Vk IFN0YW5kYXJkDQo+PiANCj4+IEhpIE11c3RhcGhhLA0KPj4gDQo+PiA+IEhhdmluZyBzYWlkIHRo YXQsIEkgd2FudCB0byBrZWVwIHRoZSBzcGlyaXQgb2YgY29vcGVyYXRpb24gYW5kIG1ha2UNCj4+ ID5zdXJlIHdlIGdldCB0aGlzICBkcmFmdCBwdWJsaXNoZWQuIFRvIHRoYXQgZWZmZWN0LCBJIGFt IG5vdCBvcHBvc2VkIHRvDQo+PiA+aXRzIHB1YmxpY2F0aW9uIGFzIGxvbmcgYXMgdGhlICBmb2xs b3dpbmcgcG9pbnRzIGFyZSBjbGFyaWZpZWQgaW4gdGhlDQo+PiA+ZHJhZnQgc2luY2Ugbm93IEZF QyBjYXBhYmlsaXR5IG9mIHRoZSBMU1IgcGVlciBpcyAgZGV0ZXJtaW5lZCBieSBhDQo+PiA+Y2hl Y2sgYSBib3RoIGFkamFjZW5jeSBhbmQgc2Vzc2lvbiBsZXZlbHM6DQo+PiANCj4+IFRoYW5rcyBm b3IgcG9pbnRpbmcgb3V0IHRoZSBiZWxvdyBzY2VuYXJpb3MuIFdlIHRoaW5rIHRoYXQgYWxsIGJ1 dCBvbmUNCj4+YXJlIGVpdGhlcg0KPj4gY292ZXJlZCBvciByZXF1aXJlIGVkaXRvcmlhbCBjaGFu Z2VzLg0KPj4gDQo+PiANCj4+IDEuIFRoaXMgc2NlbmFyaW8gKHNlbmRpbmcgaGVsbG9zIHdpdGgg RFMgY2FwYWJpbGl0eSBvbiBmZXdlciBpbnRlcmZhY2VzDQo+PmZvciBhIHBlZXIpDQo+PiBkb2Vz IE5PVCBsb29rIHJlYWxpc3RpYywgc2luY2UgaGl0bGVzcyB1cGdyYWRpbmcgYSByb3V0ZXIgd291 bGQgcmVzdWx0DQo+PmluIHNlbmRpbmcNCj4+IHY0K3Y2IGhlbGxvcyBlaXRoZXIgd2l0aCBEUyBj YXBhYmlsaXR5IG9yIHdpdGhvdXQgRFMgY2FwYWJpbGl0eSAoZm9yIGENCj4+RFMgcGVlciwNCj4+ IGFzc3VtaW5nIHRoZSBwZWVyIHdhcyBlbmFibGVkIGZvciBEUyBMRFAsIGRlZmF1bHQgb3Igbm90 LCBpbiBhbg0KPj5pbXBsZW1lbnRhdGlvbikuDQo+PiANCj4+IFBlcmhhcHMsIHlvdSBoYWQgYSBk aWZmZXJlbnQgc2NlbmFyaW8gaW4gbWluZC4NCj5NQT4gVGhpcyBjb3VsZCBvY2N1ciBkdXJpbmcg YSBoaXRsZXNzIHVwZ3JhZGUgZm9yIEhlbGxvIGFkamFjZW5jaWVzIGZyb20NCj5kaWZmZXJlbnQg bGluZSBjYXJkcyBkdXJpbmcgYSB0cmFuc2llbnQgdGltZS4gSSB3aWxsIG5vdCBpbnNpc3Qgb24g dGhpcw0KPnBvaW50IGJ1dCBJIGZvdW5kIHRoZSBkcmFmdCBsYWNrcyB3aGF0IGFjdGlvbiB0byB0 YWtlIGlmIHRoZSBIZWxsbw0KPm1lc3NhZ2VzIHJlY2VpdmVkIG9uIHBhcmFsbGVsIGxpbmtzIGZy b20gdGhlIHNhbWUgTFNSIGFyZSBub3QgY29uc2lzdGVudCwNCj5tZWFuaW5nIHRoZXkgaGF2ZSBk aWZmZXJlbnQgVFIgdmFsdWVzIG9yIHRoZSBtZXNzYWdlIG9uIG9uZSBsaW5rIGRvIG5vdA0KPmhh dmUgdGhlIERTIGNhcGFiaWxpdHkuIFRoZSBvbmx5IHRoaW5nIEkgZm91bmQgaXMgdGhpcyBwYXJh Z3JhcGggaW4NCj5TZWN0aW9uIDYuMS4xIGJ1dCBpdCBkb2VzIG5vdCBzYXkgd2hhdCB0byBkbyBp ZiBhbiBMU1IgcmVjZWl2ZXMNCj5pbmNvbnNpc3RlbnQgSGVsbG8gbWVzc2FnZXM6DQo+Ig0KPkFu IExTUiBNVVNUIGNvbnZleSB0aGUgc2FtZSB0cmFuc3BvcnQgY29ubmVjdGlvbiBwcmVmZXJlbmNl ICgiVFIiDQo+ICAgZmllbGQgdmFsdWUpIGluIGFsbCAobGluayBhbmQgdGFyZ2V0ZWQpIEhlbGxv cyB0aGF0IGFkdmVydGlzZSB0aGUNCj4gICBzYW1lIGxhYmVsIHNwYWNlIHRvIHRoZSBzYW1lIHBl ZXIgYW5kL29yIG9uIHNhbWUgaW50ZXJmYWNlLiAgVGhpcw0KPiAgIGVuc3VyZXMgdGhhdCB0d28g TFNScyBsaW5rZWQgYnkgbXVsdGlwbGUgSGVsbG8gYWRqYWNlbmNpZXMgdXNpbmcgdGhlDQo+ICAg c2FtZSBsYWJlbCBzcGFjZXMgcGxheSB0aGUgc2FtZSBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQg cm9sZSBmb3INCj4gICBlYWNoIGFkamFjZW5jeS4NCj4iDQo+IA0KPj4gMi4gWWVzLiBUaGlzIHNj ZW5hcmlvIGlzIHdlbGwgY292ZXJlZCBpbiBzZWN0aW9uIDYuMS4xIHBvaW50IzMuDQo+PiANCj4+ IA0KPj4gLy8NCj4+ICAgICAgMy4gSWYgIkR1YWwtc3RhY2sgY2FwYWJpbGl0eSIgVExWIGlzIE5P VCBwcmVzZW50LCBhbmQNCj4+IA0KPj4gxaANCj4+ICAgICAgICAgICAgICByZXN1bHRpbmcgaW4g YW55IGVzdGFibGlzaGVkIExEUG9JUHY0IHNlc3Npb24gYmVpbmcgcmVzZXQNCj4+ICAgICAgICAg ICAgICBhbmQgYSBmYXRhbCBOb3RpZmljYXRpb24gbWVzc2FnZSBiZWluZyBzZW50ICh3aXRoIHN0 YXR1cw0KPj4gDQo+PiDFoA0KPj4gDQo+PiAvLw0KPk1BPiBXaGF0IEkgd2FzIHRhbGtpbmcgYWJv dXQgaXMgYSB0cmFuc2l0aW9uIGZyb20gc3RhdGUgMmEgdG8gc3RhdGUgM2Egb3INCj5mcm9tIHN0 YXRlIDJiIHRvIHN0YXRlIDNiIGluIFNlY3Rpb24gNi4xLjEuIFBlcmhhcHMgb25lIHdheSB0byBl eHBsaWNpdGx5DQo+c3RhdGUgdGhhdCB0aGUgc2Vzc2lvbiBpcyBib3VuY2VkIHdvdWxkIGJlIHRv IGFkZCBzb21ldGhpbmcgbGlrZSB0aGlzIHRvDQo+aXRlbXMgMmEgYW5kIDJiIG9mIFNlY3Rpb24g Ni4uMS4xOg0KPiINCj4yLiBJZiAiRHVhbC1zdGFjayBjYXBhYmlsaXR5IiBUTFYgaXMgcHJlc2Vu dCwgYW5kIHJlbW90ZQ0KPiAgICAgICAgcHJlZmVyZW5jZSBtYXRjaGVzIHdpdGggdGhlIGxvY2Fs IHByZWZlcmVuY2UsIHRoZW46DQo+DQo+ICAgICAgICAgIGEpIElmIFRSPTAxMDAgKExEUG9JUHY0 KSwgdGhlbiBkZXRlcm1pbmUgdGhlIGFjdGl2ZS9wYXNzaXZlDQo+ICAgICAgICAgICAgIHJvbGVz IGZvciBUQ1AgY29ubmVjdGlvbiB1c2luZyBJUHY0IHRyYW5zcG9ydCBhZGRyZXNzIGFzDQo+ICAg ICAgICAgICAgIGRlZmluZWQgaW4gc2VjdGlvbiAyLjUuMiBvZiBSRkMgNTAzNi4NCj4NCj4gICAg ICAgICAgYikgSWYgVFI9MDExMCAoTERQb0lQdjYpLCB0aGVuIGRldGVybWluZSB0aGUgYWN0aXZl L3Bhc3NpdmUNCj4gICAgICAgICAgICAgcm9sZXMgZm9yIFRDUCBjb25uZWN0aW9uIGJ5IHVzaW5n IElQdjYgdHJhbnNwb3J0IGFkZHJlc3MNCj4gICAgICAgICAgICAgYXMgZGVmaW5lZCBpbiBzZWN0 aW9uIDIuNS4yIG9mIFJGQyA1MDM2Lg0KPiAgICpJZiBzdWJzZXF1ZW50bHkgdG8gZXN0YWJsaXNo aW5nIHRoZSBMRFAgc2Vzc2lvbiwgdGhlIEhlbGxvIG1lc3NhZ2VzDQo+ZnJvbSB0aGUgcGVlcg0K PiAgIGRvIG5vdCBpbmNsdWRlIHRoZSBEdWFsLXN0YWNrIGNhcGFiaWxpdHkgVExWLCB0aGUgc2Vz c2lvbiBpcw0KPnRlcm1pbmF0ZWQgYW5kIGEgZmF0YWwgTm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMg c2VudCB3aXRoICAgICBzdGF0dXMgY29kZQ0KPm9mICdEdWFsLVN0YWNrIE5vbi1Db21wbGlhbmNl JyAoSUFOQSBhbGxvY2F0aW9uIFRCRCkuKg0KPiINCj4NCj4NCj4+IA0KPj4gMy4gWWVzICh0byB0 aGUgZXhwZWN0ZWQgYmVoYXZpb3IpLiBUaGlzIGlzIHNvbWV3aGF0IGNvdmVyZWQgaW4gYnVsbGV0 DQo+PiMxIGluIHNlY3Rpb24NCj4+IDYuMS4xLCBidXQgd2UgY2FuIG1ha2UgaXQgZXhwbGljaXQg YnkgYWRkaW5nICJvciBkb2VzIG5vdCBnZXQNCj4+cmVjb2duaXplZMKyIGFzIGJlbG93Og0KPj4g DQo+PiANCj4+IE9MRDoNCj4+IElmICJEdWFsLXN0YWNrIGNhcGFiaWxpdHkiIFRMViBpcyBwcmVz ZW50IGFuZCByZW1vdGUgcHJlZmVyZW5jZSBkb2VzDQo+Pm5vdCBtYXRjaA0KPj4gd2l0aCB0aGUg bG9jYWwgcHJlZmVyZW5jZSwuLg0KPj4gDQo+PiANCj4+IE5FVzoNCj4+IElmICJEdWFsLXN0YWNr IGNhcGFiaWxpdHkiIFRMViBpcyBwcmVzZW50IGFuZCByZW1vdGUgcHJlZmVyZW5jZSBkb2VzDQo+ Pm5vdCBtYXRjaA0KPj4gd2l0aCB0aGUgbG9jYWwgcHJlZmVyZW5jZSAob3IgZG9lcyBub3QgZ2V0 IHJlY29nbml6ZWQpLC4uDQo+TUE+IFlvdXIgcHJvcG9zZWQgbW9kaWZpY2F0aW9uIGRvZXMgYWRk cmVzcyB0aGlzIGNvbW1lbnQuIFRoYW5rIHlvdS4NCj4NCj4gDQo+PiA0IGFuZCA1LiBZZXMgKHRv IHRoZSBleHBlY3RlZCBiZWhhdmlvcikuIEl0IGlzIGltcGxpY2l0IGluIHNlY3Rpb24gNy4yDQo+ PnBhcmEgNC4NCj4+IA0KPj4gLy8uLg0KPj4gIEFuIExTUiBNQVkgZnVydGhlciBjb25zdHJhaW4g dGhlIGFkdmVydGlzZW1lbnQgb2YgRkVDLWxhYmVsIGJpbmRpbmdzDQo+PmZvciBhDQo+PiBwYXJ0 aWN1bGFyIGFkZHJlc3MgZmFtaWx5IGJ5IG5lZ290aWF0aW5nIHRoZSBJUCBDYXBhYmlsaXR5Li4u Ly8NCj4+IA0KPj4gQXJlIHlvdSBzdWdnZXN0aW5nIHRvIG1ha2UgaXQgZXhwbGljaXQ/DQo+TUE+ IFllcyBJIHdhbnRlZCBzb21ldGhpbmcgbW9yZSBleHBsaWNpdC4gVGhpcyBzZWN0aW9uIGNlcnRh aW5seSBzYXlzIHRoZQ0KPklQdjYgcHJlZml4IEZFQyBjYXBhYmlsaXR5IGNhbiBmdXJ0aGVyIGNv bnN0cmFpbiBhIHBhcnRpY3VsYXIgRkVDIHR5cGUNCj53aGljaCBpcyBhbGxvd2VkIGJ5IHRoZSBj aGVjayBvZiB0aGUgRFMgY2FwYWJpbGl0eSBUTFYuIEl0IGhvd2V2ZXIgZG9lcw0KPm5vdCBkaXNj dXNzIHRoZSBuZWdhdGl2ZSBjYXNlLCBpLmUuLCB0aGUgRFMgY2FwYWJpbGl0eSBUTFYgZGlkIG5v dCBhbGxvdw0KPmEgRkVDIHR5cGUgYnV0IHRoZSBJUCBjYXBhYmlsaXR5IGFsbG93ZWQgaXQuDQo+ SSBiZWxpZXZlIHRoZSBmb2xsb3dpbmcgYWRkaXRpb24gdG8gYW4gZWFybGllciBwYXJhZ3JhcGgg aW4gU2VjdGlvbiA3LjINCj53b3VsZCBoZWxwIGNsYXJpZnkgdGhpczoNCj4iDQo+SWYgYW4gTFNS IGVuYWJsZWQgd2l0aCBEdWFsLXN0YWNrIExEUCBmb3IgYSBwZWVyIGFuZA0KPg0KPiAgICAgMS4g SXMgTk9UIGFibGUgdG8gZmluZCB0aGUgRHVhbC1zdGFjayBjYXBhYmlsaXR5IFRMViBpbiB0aGUN Cj4gICAgICAgIGluY29taW5nIElQdjQgTERQIGhlbGxvIG1lc3NhZ2VzIGZyb20gdGhhdCBwZWVy LCB0aGVuIHRoZSBMU1INCj4gICAgICAgIE1VU1QgTk9UIGFkdmVydGlzZSBJUHY2IEZFQy1sYWJl bCBiaW5kaW5ncyB0byB0aGUgcGVlciAqZXZlbiBpZg0KPml0IHJlY2VpdmVkIGFuIElQIGNhcGFi aWxpdHkNCj4gICAgICAgIGZyb20gdGhlIHBlZXIgaW5kaWNhdGluZyB0aGUgZW5hYmxpbmcgb2Yg dGhlIElQdjYgRkVDIHR5cGUqLg0KPiINCj5CVFcsIHRoZXJlIGlzIGEgImNvcHkgJiBwYXN0ZSIg bWlzdGFrZSBpbiB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCBpbiB0aGUNCj5zYW1lIFNlY3Rpb24g Ny4yLiBUaGUgInZpYSBBRERSRVNTIG1lc3NhZ2UiIGlzIG5vdCBjb3JyZWN0IGhlcmUgc2luY2UN Cj50aGlzIGlzIGFib3V0IEZFQyBkaXN0cmlidXRpb24sIGhlbmNlIExhYmVsIE1hcHBpbmcgbWVz c2FnZSwgYW5kIG5vdA0KPmFkZHJlc3MgZGlzdHJpYnV0aW9uLg0KPiINCj5JZiBhbiBMU1IgaXMg ZW5hYmxlZCB3aXRoIFNpbmdsZS1zdGFjayBMRFAgZm9yIGFueSBwZWVyLCB0aGVuIGl0DQo+ICAg TVVTVCBhZHZlcnRpc2UgKHZpYSBBRERSRVNTIG1lc3NhZ2UpIEZFQy1MYWJlbCBiaW5kaW5ncyBm b3IgdGhlDQo+ICAgZW5hYmxlZCBhZGRyZXNzIGZhbWlseSwgYW5kIGFjY2VwdCBGRUMtTGFiZWwg YmluZGluZ3MgZm9yIHRoZQ0KPiAgIGVuYWJsZWQgYWRkcmVzcyBmYW1pbHkuDQo+Ig0KPiANCj4+ IC0tDQo+PiBDaGVlcnMsDQo+PiBSYWppdiBBc2F0aQ0KPj4gRGlzdGluZ3Vpc2hlZCBFbmdpbmVl ciwgQ2lzY28NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gRnJvbTogPEFpc3Nhb3VpPiwgTXVzdGFwaGEgQWlzc2FvdWkNCj4+PG11c3Rh cGhhLmFpc3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbT4NCj4+IERhdGU6IFR1ZXNkYXksIERlY2Vt YmVyIDE2LCAyMDE0IGF0IDEyOjIxIFBNDQo+PiBUbzogSUVURiBEaXNjdXNzaW9uIDxpZXRmQGll dGYub3JnPiwgSUVURi1Bbm5vdW5jZQ0KPj48aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCj4+IENj OiAibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW21wbHNd IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0xNC50eHQ+DQo+PihVcGRhdGVz DQo+PiB0byBMRFAgZm9yIElQdjYpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+PiANCj4+ID5IaSBB ZHJpYW4gYW5kIGFsbCwNCj4+ID5JIHdhcyB0aGUgb25lIHdobyByYWlzZWQgdGhlIGludGVyb3Ag aXNzdWVzIHdlIGZvdW5kIHdoaWxlIHRlc3Rpbmcgb3VyDQo+PiA+aW1wbGVtZW50YXRpb24gb2Yg TERQIElQdjYgYWdhaW5zdCBleGlzdGluZyBhbmQgZGVwbG95ZWQNCj4+aW1wbGVtZW50YXRpb25z Lg0KPj4gPkkgcHJvcG9zZWQgYSBzaW1wbGUgbWV0aG9kIG9mIHVzaW5nIHRoZSBleGlzdGluZyBG RUMgYWR2ZXJ0aXNlbWVudA0KPj4gPmNhcGFiaWxpdHkgYXQgdGhlIHNlc3Npb24gbGV2ZWwgYXMg YSB3YXkgZm9yIGFuIExTUiB0byBkZXRlY3QgaWYgYW4NCj4+ID5pbXBsZW1lbnRhdGlvbiBzdXBw b3J0IExEUCBJUHY2IEZFQ3MgYW5kIElQdjYgYWRkcmVzc2VzLiBUaGlzIGV4aXN0aW5nDQo+PiA+ RkVDIGFkdmVydGlzZW1lbnQgY2FwYWJpbGl0eSBhdCBzZXNzaW9uIGxldmVsIGlzIGRlZmluZWQg aW4NCj4+ID5kcmFmdC1pZXRmLW1wbHMtbGRwLWlwLXB3LWNhcGFiaWxpdHktMDggYnV0IHdpdGgg dGhlIGxpbWl0YXRpb24gdGhhdCBpdA0KPj4gPmNhbiBiZSB1c2VkIG9ubHkgdG8gZGlzYWJsZSBz dXBwb3J0IG9mIElQdjYgRkVDcyBpbiBMRFAgSW5pdGlhbGl6YXRpb24NCj4+ID5NZXNzYWdlOyB3 ZSBwcm9wb3NlZCB0byBnZW5lcmFsaXplIHRoZSBtZXRob2QgdG8gYWxzbyBpbmRpY2F0ZSBleHBs aWNpdA0KPj4gPnN1cHBvcnQgZm9yIElQdjYgRkVDcyBhbmQgSVB2NiBBZGRyZXNzZXMgaW4gTERQ IEluaXRpYWxpemF0aW9uIE1lc3NhZ2UuDQo+PiA+VGhpcyBtZXRob2QgaXMgc2FmZSBhbmQgd2Fz IGFsc28gdXNlZCB3aXRoIG1MRFAgUDJNUCBhbmQgTVAyTVAgRkVDcw0KPj4gd2hlbg0KPj4gPnRo ZXkgd2VyZSBpbnRyb2R1Y2VkLiBUaGUgaW50ZW50IGhlcmUgaXMgdGhhdCBhbGwgc2Vzc2lvbiBs ZXZlbA0KPj4gPmNhcGFiaWxpdGllcyBpbiBMRFAgc2hvdWxkIGZvbGxvdyBSRkMgNTU2MSBhcHBy b2FjaC4NCj4+ID4NCj4+ID5UaGVyZSB3YXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvciB3aGlj aCBzdXBwb3J0ZWQgdGhlIHByb3Bvc2FsIG9uIHRoZQ0KPj4gPm1haWxpbmcgbGlzdCBidXQgdGhl IGF1dGhvcnMgY2hvc2UgdG8gaWdub3JlIGl0IGFuZCB3ZW50IHdpdGggYQ0KPj5wcm9wb3NhbA0K Pj4gPndoaWNoIG92ZXJsb2FkZWQgdGhlIG1lYW5pbmcgb2YgdGhlIGR1YWwtc3RhY2sgY2FwYWJp bGl0eSBUTFYuDQo+PlJlZ2FyZGxlc3MNCj4+ID5vZiB0aGUgbWVyaXQgb2YgZWl0aGVyIG1ldGhv ZCwgdGhlIGRpc2N1c3Npb24gb24gdGhlIE1QTFMgbWFpbGluZyBsaXN0DQo+PiA+d2FzIG5vdCBj bG9zZWQgcHJvcGVybHkgZnJvbSBteSBwZXJzcGVjdGl2ZS4NCj4+ID4NCj4+ID5Ob3cgaGVyZSBp cyB0aGUgY29uY2VybiBJIHJhaXNlZCB3aXRoIHVzaW5nIHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxp dHkuDQo+PiA+Tm90IG9ubHkgdGhpcyBUTFYgaXMgYW4gYWRqYWNlbmN5IGxldmVsIGZlYXR1cmUg d2hpY2ggaXMgaGFzIG5vdGhpbmcgdG8NCj4+ID5kbyB3aXRoIEZFQyBjYXBhYmlsaXR5IGFkdmVy dGlzZW1lbnQsIGJ1dCBpdCBpcyBpbnRyb2R1Y2luZyBjb21wbGV4aXR5DQo+PmluDQo+PiA+dGhl IGltcGxlbWVudGF0aW9uIHdoaWNoIG5vdyBoYXMgdG8gY2hlY2sgZHVhbC1zdGFjayBjYXBhYmls aXR5IGZvcg0KPj4gPiplYWNoKiBhZGphY2VuY3kgdG8gdGhlIHBlZXIgKmFuZCogdGhlIHNlc3Np b24gbGV2ZWwgRkVDIGNhcGFiaWxpdHkgdG8NCj4+ID5kZWNpZGUgd2hhdCB0aGUgcGVlciBpcyBj YXBhYmxlIG9mIGF0IHRoZSAqc2Vzc2lvbiBsZXZlbCouDQo+PiA+DQo+PiA+SGF2aW5nIHNhaWQg dGhhdCwgSSB3YW50IHRvIGtlZXAgdGhlIHNwaXJpdCBvZiBjb29wZXJhdGlvbiBhbmQgbWFrZQ0K Pj5zdXJlDQo+PiA+d2UgZ2V0IHRoaXMgZHJhZnQgcHVibGlzaGVkLiBUbyB0aGF0IGVmZmVjdCwg SSBhbSBub3Qgb3Bwb3NlZCB0byBpdHMNCj4+ID5wdWJsaWNhdGlvbiBhcyBsb25nIGFzIHRoZSBm b2xsb3dpbmcgcG9pbnRzIGFyZSBjbGFyaWZpZWQgaW4gdGhlIGRyYWZ0DQo+PiA+c2luY2Ugbm93 IEZFQyBjYXBhYmlsaXR5IG9mIHRoZSBMU1IgcGVlciBpcyBkZXRlcm1pbmVkIGJ5IGEgY2hlY2sg YQ0KPj5ib3RoDQo+PiA+YWRqYWNlbmN5IGFuZCBzZXNzaW9uIGxldmVsczoNCj4+ID4NCj4+ID4x LiBUaGUgZHJhZnQgaXMgbWlzc2luZyB0aGUgYmVoYXZpb3Igd2hlbiBtdWx0aXBsZSBhZGphY2Vu Y2llcyBleGlzdCB0bw0KPj4gPnRoZSBzYW1lIExTUiBhbmQgdGhlIHBlZXIgTFNSIGFkdmVydGlz ZWQgdGhlIGR1YWwtc3RhY2sgY2FwYWJpbGl0eSBvbmx5DQo+PiA+b3ZlciBhIHN1YnNldCBvZiB0 aGVzZSBIZWxsbyBhZGphY2VuY2llcy4NCj4+ID5JIGFzc3VtZSBoZXJlIHRoZSBwZWVyIExTUiBp cyBjb25zaWRlcmVkIHRvIGJlIGR1YWwtc3RhY2sgY2FwYWJsZSBhcw0KPj5zb29uDQo+PiA+YXMg YW55IG9mIHRoZSBIZWxsbyBhZGphY2VuY2llcyBpbmNsdWRlcyB0aGUgZHVhbC1zdGFjayBjYXBh YmlsaXR5Lg0KPj5UaGlzDQo+PiA+d291bGQgYWxsb3cgYSBoaXRsZXNzIHVwZ3JhZGUgc2NlbmFy aW8gZnJvbSBhbiBvbGRlciBpbXBsZW1lbnRhdGlvbiB0bw0KPj4gPm9uZSB3aGljaCBjb21wbGll cyB0byB0aGlzIGRyYWZ0DQo+PiA+DQo+PiA+Mi4gU2ltaWxhcmx5LCB3aGF0IHdvdWxkIGJlIHRo ZSBiZWhhdmlvciBpZiBhIGhlbGxvIGFkamFjZW5jeSBjaGFuZ2VzDQo+PiA+ZnJvbSBzZW5kaW5n IHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkgdG8gbm90IHNlbmRpbmcgaXQ/IFRoaXMgd291bGQg YmUNCj4+ID5mb3IgZXhhbXBsZSBpbiBhIGhpdGxlc3MgZG93bmdyYWRlIHRvIGEgdmVyc2lvbiBv ZiBMRFAgd2hpY2ggZG9lcyBub3QNCj4+ID5jb21wbHkgdG8gdGhpcyBkcmFmdC4NCj4+ID5JIGFz c3VtZSBoZXJlIHRoYXQgdGhlIHNlc3Npb24gbXVzdCBiZSBib3VuY2VkIHNpbmNlIHRoZSBMU1Jz IG5lZWQgYQ0KPj4gPmNsZWFuIHN0YXRlIHRvIG5vdCBzZW5kIElQdjYgYWRkcmVzc2VzIGFuZCBJ UHY2IEZFQ3MuDQo+PiA+DQo+PiA+My4gVGhlIGRvY3VtZW50IGRlZmluZXMgMiB2YWx1ZXMgZm9y IHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkgVFIuIEl0DQo+PiA+ZG9lcyBub3QgbWVudGlvbiB0 aGUgYmVoYXZpb3Igd2hlbiBhbiB1bmtub3duIHZhbHVlIGlzIHJlY2VpdmVkLg0KPj4gPldpbGwg dGhhdCBiZSBjb25zaWRlcmVkIGEgZmF0YWwgZXJyb3I/DQo+PiA+DQo+PiA+NC4gVGhlIGRyYWZ0 IGlzIG1pc3NpbmcgdGhlIGJlaGF2aW9yIG9mIHdoZW4gdGhlIHBlZXIgTFNSIGRvZXMgbm90DQo+ PiA+YWR2ZXJ0aXNlIHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkgaW4gYWxsIHRoZSBIZWxsbyBh ZGphY2VuY2llcyBidXQgaXQNCj4+ID5hZHZlcnRpc2VkIHRoZSBlbmFibGluZyBvciBkaXNhYmxp bmcgb2YgdGhlIElQdjYgcHJlZml4IEZFQyBjYXBhYmlsaXR5DQo+PmluDQo+PiA+dGhlIHNlc3Np b24gaW5pdGlhbGl6YXRpb24gbWVzc2FnZS4NCj4+ID5JIGFzc3VtZSBoZXJlIHRoYXQgdGhlIGFi c2VuY2Ugb2YgdGhlIGR1YWwtc3RhY2sgY2FwYWJpbGl0eSBvdmVycmlkZXMNCj4+YW55DQo+PiA+ c2Vzc2lvbiBsZXZlbCBJUHY2IEZFQyBwcmVmaXggY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50Lg0K Pj4gPg0KPj4gPjUuIFRoZSBkcmFmdCBpcyBtaXNzaW5nIHRoZSBiZWhhdmlvciBvZiB3aGVuIHRo ZSBwZWVyIExTUiBkb2VzIG5vdA0KPj4gPmFkdmVydGlzZSB0aGUgZHVhbC1zdGFjayBjYXBhYmls aXR5IGluIGFsbCB0aGUgSGVsbG8gYWRqYWNlbmNpZXMgYnV0IGl0DQo+PiA+YWR2ZXJ0aXNlZCB0 aGUgZW5hYmxpbmcgb2YgdGhlIElQdjYgcHJlZml4IEZFQyBjYXBhYmlsaXR5IGluIHRoZQ0KPj5z ZXNzaW9uDQo+PiA+Q2FwYWJpbGl0eSBtZXNzYWdlLg0KPj4gPkkgYXNzdW1lIHRoZSBzYW1lIGJl aGF2aW9yIGFzIGluICg0KSBhcHBsaWVzIGhlcmUuDQo+PiA+DQo+PiA+UmVnYXJkcywNCj4+ID5N dXN0YXBoYS4NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBG cm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGhl IElFU0cNCj4+ID4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCAyOjM3IFBNDQo+ PiA+PiBUbzogSUVURi1Bbm5vdW5jZQ0KPj4gPj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4+ID4+IFN1 YmplY3Q6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYtMTQudHh0 PiAoVXBkYXRlcw0KPj4gPj50byBMRFAgZm9yIElQdjYpDQo+PiA+PiB0byBQcm9wb3NlZCBTdGFu ZGFyZA0KPj4gPj4NCj4+ID4+DQo+PiA+PiBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0 IGZyb20gdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwNCj4+U3dpdGNoaW5nDQo+PiA+PldHDQo+PiA+ PiAobXBscykgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCj4+ID4+IC0gJ1Vw ZGF0ZXMgdG8gTERQIGZvciBJUHY2Jw0KPj4gPj4gICA8ZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2 LTE0LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCj4+ID4+DQo+PiA+PiBUaGUgSUVTRyBwbGFu cyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMN Cj4+ID4+ZmluYWwNCj4+ID4+IGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBz dWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCj4+ID4+aWV0ZkBpZXRmLm9yZw0KPj4gPj4gbWFp bGluZyBsaXN0cyBieSAyMDE0LTEyLTE4LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkgYmUg c2VudCB0bw0KPj4gPj5pZXNnQGlldGYub3JnDQo+PiA+PiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2Fz ZSwgcGxlYXNlIHJldGFpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0DQo+PiA+PmxpbmUg dG8gYWxsb3cNCj4+ID4+IGF1dG9tYXRlZCBzb3J0aW5nLg0KPj4gPj4NCj4+ID4+IEFic3RyYWN0 DQo+PiA+Pg0KPj4gPj4gICAgVGhlIExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbCAoTERQKSBz cGVjaWZpY2F0aW9uIGRlZmluZXMNCj4+ID4+ICAgIHByb2NlZHVyZXMgdG8gZXhjaGFuZ2UgbGFi ZWwgYmluZGluZ3Mgb3ZlciBlaXRoZXIgSVB2NCwgb3IgSVB2NiBvcg0KPj4gPj4gICAgYm90aCBu ZXR3b3Jrcy4gVGhpcyBkb2N1bWVudCBjb3JyZWN0cyBhbmQgY2xhcmlmaWVzIHRoZSBMRFANCj4+ YmVoYXZpb3INCj4+ID4+ICAgIHdoZW4gSVB2NiBuZXR3b3JrIGlzIHVzZWQgKHdpdGggb3Igd2l0 aG91dCBJUHY0KS4gVGhpcyBkb2N1bWVudA0KPj4gPj4gICAgdXBkYXRlcyBSRkMgNTAzNiBhbmQg UkZDIDY3MjAuDQo+PiA+Pg0KPj4gPj4gVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KPj4g Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtbGRwLWlw djYvDQo+PiA+Pg0KPj4gPj4gSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPj4g Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtbGRwLWlw djYvYmFsbG90Lw0KPj4gPj4NCj4+ID4+DQo+PiA+PiBObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUg YmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+PiA+Pg0KPj4gPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IG1wbHMgbWFp bGluZyBsaXN0DQo+PiA+PiBtcGxzQGlldGYub3JnDQo+PiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPm1wbHMgbWFpbGluZyBsaXN0DQo+PiA+bXBs c0BpZXRmLm9yZw0KPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPg0KDQo= From nobody Sat Jan 10 11:10:17 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE5D1A6F7C for ; Sat, 10 Jan 2015 11:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnpKZhOalenf for ; Sat, 10 Jan 2015 11:10:06 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD9B1A00F8 for ; Sat, 10 Jan 2015 11:10:04 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0AJ9s8G007067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2015 14:09:55 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t0AJ9s8G007067 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1420916996; bh=saU6uGwhak0M5UIt4c4fRZnY/28=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=BPfDKJHlQl1wFU1562OrjPv/UUrUlpyFT1MPDiXJd4YJyruovfo2+UEuYMBrp5PH1 hDll9lwF7b0PCSzpdrIBojw+CsudS68aQM7brO8HXgVye59yUuxTMpJu8ToUoXmFdX qP4AAgBjHkitWtO2feUfPtwtZ5654WHcIVaItLkM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t0AJ9s8G007067 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd04.lss.emc.com (RSA Interceptor); Sat, 10 Jan 2015 14:09:20 -0500 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0AJ9cN8014479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Jan 2015 14:09:38 -0500 Received: from MXHUB208.corp.emc.com (10.253.68.34) by mxhub27.corp.emc.com (10.254.110.183) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sat, 10 Jan 2015 14:09:37 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB208.corp.emc.com ([10.253.68.34]) with mapi id 14.03.0195.001; Sat, 10 Jan 2015 14:09:37 -0500 From: "Black, David" To: "adrian@olddog.co.uk" , "mpls@ietf.org" , "Stephen Farrell [stephen.farrell@cs.tcd.ie]" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4g5tkJK6AgABd/QCAADiAgIAAFPfggAEzewCAAC4IgIAGNx+wgAGluwCABIS77A== Date: Sat, 10 Jan 2015 19:09:37 +0000 Message-ID: References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se>, <065a01d02a99$71490c80$53db2580$@olddog.co.uk> In-Reply-To: <065a01d02a99$71490c80$53db2580$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.132.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 19:10:15 -0000 > > 3. Do you see any key roll over issues?=0A= > =0A= > I think key roll is covered in the text. We *do* need to roll the keys, b= ut we=0A= > believe that key roll can be achieved using the existing keying mechanism= s with=0A= > the additional benefit that the key messages are protected by the previou= s keys.=0A= =0A= Related question - why is the key-id an output of the key exchange process,= =0A= specifically part of the HKDF output (near the end of 4.2.2)?=0A= =0A= Since the key-id is 4-bits, there's a 1-in-16 possibility that rekeying=0A= yields the same id, which is a potential minor problem - if that happens,= =0A= I suppose one could rerun the key exchange, which is unlikely to collide=0A= a second time (odds of two collisions in a row is less than one-half of 1%)= .=0A= =0A= I'd also expect that configuration could override that key-id output=0A= (e.g., Alice and Bob might both know via some other means that this key=0A= exchange is generating key 7, even if the HKDF produces a key-id of 2).=0A= =0A= If I had to guess why key-id is a key exchange output, it might be courtesy= =0A= of the initial key exchange being unauthenticated - the obvious alternative= =0A= of passing the key-id in the unauthenticated key exchange messages makes=0A= it simple for a man-in-the-middle to defeat opportunistic encryption by=0A= changing that key-id. Such a change causes the resulting key to be=0A= installed under key-ids at the two endpoints, which will then fail to=0A= successfully exchange encrypted traffic using that key ...=0A= =0A= Thanks,=0A= --David=0A= ________________________________________=0A= From: mpls [mpls-bounces@ietf.org] on behalf of Adrian Farrel [adrian@olddo= g.co.uk]=0A= Sent: Wednesday, January 07, 2015 11:46 AM=0A= To: 'Uma Chunduri'; mpls@ietf.org=0A= Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-op= portunistic-encrypt-04.txt=0A= =0A= Hi have read the thread based on this email from Stephen and Stewart, but= =0A= deciding to reply back on Uma's original ...=0A= =0A= > 1. Is it on every hop/LSR along the path the whole packet with label stac= k had=0A= to=0A= > be decrypted and encrypted with Mel? If yes, IMO this is really=0A= > bad w.r.t performance (issues of key exchange for thousands of LSPs an= d=0A= load=0A= > associated would be insignificant in comparison perhaps?).=0A= > From this PoV content in section 1.2 is critical.=0A= =0A= The text in the introduction:=0A= MPLS opportunistic security can be achieved between adjacent Label=0A= Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and=0A= also between end points of an LSP.=0A= ...was intended to say that there are two options:=0A= 1. encrypt between two adjacent LSRs on an LSP=0A= 2. encrypt between the end-points of an LSP=0A= In the latter case you would not encrypt and decrypt at each hop (and indee= d=0A= would not be able to since the keys would only be known at the end points).= =0A= =0A= You are right to point at section 1.2 (and we do need to write that section= :-)=0A= because L2 solutions (such as MACsec) are typically used on a hop-by-hop ba= sis.=0A= I am not clear that MACsec used in this way is a significant performance is= sue=0A= (I think chips can do L2 security at line speed), although it might cause= =0A= additional power consumption.=0A= =0A= > 2. Section 2 is covering this - OS proposed here is similar to TCPInc st= uff -=0A= meaning=0A= > no authenticated key exchange (possible MITM) and no PFS.=0A= =0A= Adding to Stephen's reply:=0A= Yes, OS is vulnerable to Man-in-the-Middle attacks.=0A= It's a trade: if you make your security too hard to manage and configure, y= ou=0A= get no security; if you make your security to simplistic, everyone uses it = and=0A= it is no good.=0A= Our approach here is to make the security easy to use, suffer the potential= MitM=0A= attacks, but:=0A= a. make MitM as expensive as possible=0A= b. make a MitM attack possible to detect=0A= =0A= > 3. Do you see any key roll over issues?=0A= =0A= I think key roll is covered in the text. We *do* need to roll the keys, but= we=0A= believe that key roll can be achieved using the existing keying mechanisms = with=0A= the additional benefit that the key messages are protected by the previous = keys.=0A= =0A= ... and to answer Stewart's question about whether operators want this:=0A= I have certainly discussed the principle with a number of network operators= and=0A= they have not said to be "you are crazy" (perhaps this is taken as read). O= n the=0A= other hand, would say that the interest is currently cautious.=0A= That is certainly why this document is positioned as Experimental, but also= why=0A= we have tried to make the protocol mechanisms such that partial or incremen= tal=0A= deployment is possible.=0A= But perhaps operators will want to speak for themselves (or perhaps they wi= ll be=0A= inclined to be shy because expressing an interest might be taken to mean th= eir=0A= networks are currently vulnerable, or might lead to them being leant on).= =0A= =0A= Adrian=0A= =0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= mpls mailing list=0A= mpls@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mpls=0A= From nobody Sat Jan 10 14:13:38 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8723B1A03A5 for ; Sat, 10 Jan 2015 14:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcLpoDe6vIEs for ; Sat, 10 Jan 2015 14:13:32 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB4F1A03A1 for ; Sat, 10 Jan 2015 14:13:31 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0AMDMMb003241; Sat, 10 Jan 2015 22:13:23 GMT Received: from 950129200 (72.35.14.46.dynamic.wline.lns.sme.cust.swisscom.ch [46.14.35.72]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0AMDK5i003226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2015 22:13:21 GMT From: "Adrian Farrel" To: "'Black, David'" , , References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se>, <065a01d02a99$71490c80$53db2580$@olddog.co.uk> In-Reply-To: Date: Sat, 10 Jan 2015 22:13:19 -0000 Message-ID: <027c01d02d22$a50a0660$ef1e1320$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4gwGyVrHWAcZrwUoBiuknFAIew9ozAdaN47cCBj1zSwII+SMuAkTU7ZwBk6jJoprrvKEQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21240.002 X-TM-AS-Result: No--14.483-10.0-31-10 X-imss-scan-details: No--14.483-10.0-31-10 X-TMASE-MatchedRID: hls5oAVArl8n2WEbWzq9rcpQKjU7fBXV9QODh/WEPkNrRM6wvXgDaRzg cDH9HmxuPpdyuMpL6DyNl5Y6EH/oPEn4dMSWXlsdVP9jNEQH04oKajiKVoihqQFbHA9TqNLQLSK 0svjMGFBCcRi+Dr/+SQHuJEJpcOrSnVg7OlStuLVoGUpnbsMsHsMdI0UcXEHzQQ1XgvCe7sEu6l mGakqVh9Ujo9Kkm1dLEZEQVbovJZM6DiriUk823yj8QbJIB1s2MWSlIGqx6OQY0A95tjAn+1O1A 06iwWrpfLnWqh+I27SN6fDbnTu0n01+zyfzlN7y/sToY2qzpx5dT8gO3hPj4foLR4+zsDTtX28x NpU0U3MRKN+/FLv2GU05AN0U2B/TmfIo87BvLLZXismZQuzV/g== Archived-At: Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 22:13:34 -0000 > > I think key roll is covered in the text. We *do* need to roll the keys, but we > > believe that key roll can be achieved using the existing keying mechanisms with > > the additional benefit that the key messages are protected by the previous > keys. > > Related question - why is the key-id an output of the key exchange process, > specifically part of the HKDF output (near the end of 4.2.2)? > > Since the key-id is 4-bits, there's a 1-in-16 possibility that rekeying > yields the same id, which is a potential minor problem - if that happens, > I suppose one could rerun the key exchange, which is unlikely to collide > a second time (odds of two collisions in a row is less than one-half of 1%). Ah, no. The key-id is not the key. The key-id is an ID used to refer to the key. It is used in the encrypted packets to refer to the key and, since there is no need for more than a couple of active keys (current and roll-forward) at any time one could argue that one bit is enough, but four seemed safer for rapid rolls and a couple of spare keys. So all that is necessary is that the KDF generates a new number each time. Maybe that requires state and something in the input to the KDF. > I'd also expect that configuration could override that key-id output > (e.g., Alice and Bob might both know via some other means that this key > exchange is generating key 7, even if the HKDF produces a key-id of 2). So long as Alice and Bob both know that the same key-id refers to the same key and algorithm everything in the world will be wonderful. Adrian > If I had to guess why key-id is a key exchange output, it might be courtesy > of the initial key exchange being unauthenticated - the obvious alternative > of passing the key-id in the unauthenticated key exchange messages makes > it simple for a man-in-the-middle to defeat opportunistic encryption by > changing that key-id. Such a change causes the resulting key to be > installed under key-ids at the two endpoints, which will then fail to > successfully exchange encrypted traffic using that key ... From nobody Sun Jan 11 06:31:00 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6475B1A6F05 for ; Sun, 11 Jan 2015 06:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWjOFSNi9-I3 for ; Sun, 11 Jan 2015 06:30:55 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B6D1A6F02 for ; Sun, 11 Jan 2015 06:30:55 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0BEUmvV025231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2015 09:30:48 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t0BEUmvV025231 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1420986648; bh=t5APKvDUu+X5U5zRfdiIiuq1lYg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=fiK9P/AsPNSuXpxm/8YxjPsqrsz6MPjiSBNOKIbepM+YQUVbvGiVR8gjYxHdhb0AO 6NMsKeeOYbgYd16LkrPeaU9SfcQgcf1L0Rgq/va2zrcMQWOZihUyj5SUV2ZOYYIgjD gaeAu7IEWv1LfPL9/krm4nMSiAL06uU1Osjo6uUo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t0BEUmvV025231 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd03.lss.emc.com (RSA Interceptor); Sun, 11 Jan 2015 09:30:07 -0500 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0BEUVxB026323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 11 Jan 2015 09:30:33 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub22.corp.emc.com (128.222.70.134) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sun, 11 Jan 2015 09:30:31 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Sun, 11 Jan 2015 09:30:31 -0500 From: "Black, David" To: "adrian@olddog.co.uk" , "mpls@ietf.org" , "stephen.farrell@cs.tcd.ie" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4g5tkJK6AgABd/QCAADiAgIAAFPfggAEzewCAAC4IgIAGNx+wgAGluwCABIS77IAAjbWAgACvS/A= Date: Sun, 11 Jan 2015 14:30:31 +0000 Message-ID: References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se>, <065a01d02a99$71490c80$53db2580$@olddog.co.uk> <027c01d02d22$a50a0660$ef1e1320$@olddog.co.uk> In-Reply-To: <027c01d02d22$a50a0660$ef1e1320$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.42.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 14:30:58 -0000 > > Since the key-id is 4-bits, there's a 1-in-16 possibility that rekeying > > yields the same id, which is a potential minor problem - if that happen= s, > > I suppose one could rerun the key exchange, which is unlikely to collid= e > > a second time (odds of two collisions in a row is less than one-half of= 1%). > > Ah, no. The key-id is not the key. The key-id is an ID used to refer to t= he > key. Yes, that's what I understood. Generating the same key twice from this sor= t of key exchange is effectively impossible if the entropy inputs are good. If the entropy inputs aren't good, that's a much bigger problem (resulting keys appear to be secure, but actually aren't). OTOH, generating the same 4-bit key-id is definitely going to happen. > So all that is necessary is that the KDF generates a new number each time= . > Maybe that requires state and something in the input to the KDF. That won't work with HKDF. Moreover, it's a bad design approach in general= , as it leads to weak KDFs courtesy of predictable output - don't go there ;-= ). One could deterministically find another key-id if the generated key-id is in use (e.g., via iteration - if the KDF generates key-id 7 but key-id 7 is not available, try 8, etc.). Another idea would be to take two key-ids from the KDF output instead of just one. Then if the first key-id matches the key-id that's being rekeyed= , try the second key-id; if that also matches, just rerun the key exchange. The odds of the key-id that's being rekeyed showing up twice is 1-in-256, so key exchange reruns should be infrequent. In all cases, both endpoints have to figure out whether the new key-id is acceptable and reach the same conclusion. The requirement that "once encrypted data packets protected with the new key have been successfully received, the old key SHOULD be discarded" is helpful, but probably not enough. I can think of more that could be said, but understanding what happens in practice with error and corner cases will be important, e.g., if things break in the wrong way at the wrong moment, can the two endpoints reach different conclusions about whether the new key is working? If so, that's probably of significant interest to an attacker who can introduce errors. Thanks, --David > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Saturday, January 10, 2015 5:13 PM > To: Black, David; mpls@ietf.org; stephen.farrell@cs.tcd.ie > Subject: RE: [mpls] FW: New Version Notification for draft-farrelll-mpls- > opportunistic-encrypt-04.txt >=20 > > > I think key roll is covered in the text. We *do* need to roll the key= s, > but > we > > > believe that key roll can be achieved using the existing keying mecha= nisms > with > > > the additional benefit that the key messages are protected by the pre= vious > > keys. > > > > Related question - why is the key-id an output of the key exchange proc= ess, > > specifically part of the HKDF output (near the end of 4.2.2)? > > > > Since the key-id is 4-bits, there's a 1-in-16 possibility that rekeying > > yields the same id, which is a potential minor problem - if that happen= s, > > I suppose one could rerun the key exchange, which is unlikely to collid= e > > a second time (odds of two collisions in a row is less than one-half of= 1%). >=20 > Ah, no. The key-id is not the key. The key-id is an ID used to refer to t= he > key. > It is used in the encrypted packets to refer to the key and, since there = is no > need for more than a couple of active keys (current and roll-forward) at = any > time one could argue that one bit is enough, but four seemed safer for ra= pid > rolls and a couple of spare keys. >=20 > So all that is necessary is that the KDF generates a new number each time= . > Maybe > that requires state and something in the input to the KDF. >=20 > > I'd also expect that configuration could override that key-id output > > (e.g., Alice and Bob might both know via some other means that this key > > exchange is generating key 7, even if the HKDF produces a key-id of 2). >=20 > So long as Alice and Bob both know that the same key-id refers to the sam= e key > and algorithm everything in the world will be wonderful. >=20 > Adrian >=20 > > If I had to guess why key-id is a key exchange output, it might be cour= tesy > > of the initial key exchange being unauthenticated - the obvious alterna= tive > > of passing the key-id in the unauthenticated key exchange messages make= s > > it simple for a man-in-the-middle to defeat opportunistic encryption by > > changing that key-id. Such a change causes the resulting key to be > > installed under key-ids at the two endpoints, which will then fail to > > successfully exchange encrypted traffic using that key ... >=20 >=20 From nobody Sun Jan 11 10:56:12 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512551A87E4; Sun, 11 Jan 2015 10:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA2sORIXeWSD; Sun, 11 Jan 2015 10:56:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B231A87CB; Sun, 11 Jan 2015 10:56:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150111185606.7030.66266.idtracker@ietfa.amsl.com> Date: Sun, 11 Jan 2015 10:56:06 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-15.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 18:56:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Updates to LDP for IPv6 Authors : Rajiv Asati Carlos Pignataro Vishwas Manral Rajiv Papneja Filename : draft-ietf-mpls-ldp-ipv6-15.txt Pages : 25 Date : 2015-01-11 Abstract: The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036 and RFC 6720. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-ipv6-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 11 16:18:27 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C7B1A038E; Sun, 11 Jan 2015 16:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn5zxzLGnX45; Sun, 11 Jan 2015 16:18:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2A21A1A7C; Sun, 11 Jan 2015 16:18:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112001822.601.61022.idtracker@ietfa.amsl.com> Date: Sun, 11 Jan 2015 16:18:22 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 00:18:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping Authors : Elisa Bellagamba Gregory Mirsky Loa Andersson Pontus Skoldstrom Dave Ward John Drake Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt Pages : 25 Date : 2015-01-11 Abstract: This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP-Ping protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 11 16:24:49 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529301A1A23 for ; Sun, 11 Jan 2015 16:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLSNsmYOhgxe for ; Sun, 11 Jan 2015 16:24:45 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9951A1A7C for ; Sun, 11 Jan 2015 16:24:45 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-f5-54b2c23e70f2 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E8.FC.03307.E32C2B45; Sun, 11 Jan 2015 19:34:39 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Sun, 11 Jan 2015 19:24:43 -0500 From: Gregory Mirsky To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt Thread-Index: AQHQLf1eyO7KBqSU/0SZsXT53NXlyJy7nysQ Date: Mon, 12 Jan 2015 00:24:42 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8CF8F5@eusaamb103.ericsson.se> References: <20150112001822.601.61022.idtracker@ietfa.amsl.com> In-Reply-To: <20150112001822.601.61022.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyuXRPiK79oU0hBs9m8VvcWrqS1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGT0d1gULhSpu37/J1MDYxdfFyMkhIWAisf/ZHnYIW0ziwr31 bF2MXBxCAkcYJZquPWaGcJYzSpw7PJcVpIpNwEjixcYesA4RAWWJIxO7weLCAkES2/beY4GI B0scuNoLVMMBZBtJbD2tDhJmEVCVuPfvLVg5r4CvxOInr9hAbCEBe4nO1nVgrZwCDhI9vVfB 4oxAB30/tYYJxGYWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKYStJzHl9jRmiXkdiwe5PbBC2 tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYOUqLU8ty040MNjECw/6YBJvu DsY9Ly0PMQpwMCrx8Bo83xgixJpYVlyZe4hRmoNFSZy35d36ECGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MDHvUX937vCtlQSHbmz022wu798Unqu6cP/Hpn26mNf75fFdueb6vrApxWLzA NVHAT3byxzVNZ9+KcroZ75ORvWW6Z87HgwI7y6ZUf/bZeZa3rZCJ/4DnxCXOVZEXH9s97mJe zDXv6ov++o+5b8xjrns/eGWWzLD+hNqUWKYnGdHvQxWnarV6KbEUZyQaajEXFScCAN0knJlc AgAA Archived-At: Subject: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 00:24:47 -0000 Dear All, this update addresses comments we received from Nobo. Also it reflects wor= k authors done with sister document draft-ietf-ccamp-rsvp-te-mpls-tp-oam-e= xt addressing AD and GEN-Art review comments. Your comments, questions and suggestions always welcome and greatly appreci= ated. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Sunday, January 11, 2015 4:18 PM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Configuration of Pro-Active Operations, Administr= ation, and Maintenance (OAM) Functions for MPLS-based Transport Networks us= ing LSP Ping Authors : Elisa Bellagamba Gregory Mirsky Loa Andersson Pontus Skoldstrom Dave Ward John Drake Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt Pages : 25 Date : 2015-01-11 Abstract: This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP-Ping protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-mpls-tp-oam-con= f-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Jan 11 16:30:33 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721CE1A038E for ; Sun, 11 Jan 2015 16:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiZ-AJuHih4s for ; Sun, 11 Jan 2015 16:30:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EA21A8848 for ; Sun, 11 Jan 2015 16:30:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C439EBEC6; Mon, 12 Jan 2015 00:30:23 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpzuB8s3U-IP; Mon, 12 Jan 2015 00:30:22 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.41.61.17]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1847FBEBC; Mon, 12 Jan 2015 00:30:22 +0000 (GMT) Message-ID: <54B3159D.1060407@cs.tcd.ie> Date: Mon, 12 Jan 2015 00:30:21 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Black, David" , "adrian@olddog.co.uk" , "mpls@ietf.org" References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se>, <065a01d02a99$71490c80$53db2580$@olddog.co.uk> <027c01d02d22$a50a0660$ef1e1320$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 00:30:29 -0000 Hi David, On 11/01/15 14:30, Black, David wrote: >>> Since the key-id is 4-bits, there's a 1-in-16 possibility that rekeying >>> yields the same id, which is a potential minor problem - if that happens, >>> I suppose one could rerun the key exchange, which is unlikely to collide >>> a second time (odds of two collisions in a row is less than one-half of 1%). >> >> Ah, no. The key-id is not the key. The key-id is an ID used to refer to the >> key. > > Yes, that's what I understood. Generating the same key twice from this sort > of key exchange is effectively impossible if the entropy inputs are good. > If the entropy inputs aren't good, that's a much bigger problem (resulting > keys appear to be secure, but actually aren't). OTOH, generating the same > 4-bit key-id is definitely going to happen. Good catch. > >> So all that is necessary is that the KDF generates a new number each time. >> Maybe that requires state and something in the input to the KDF. > > That won't work with HKDF. Moreover, it's a bad design approach in general, > as it leads to weak KDFs courtesy of predictable output - don't go there ;-). > > One could deterministically find another key-id if the generated key-id > is in use (e.g., via iteration - if the KDF generates key-id 7 but key-id 7 > is not available, try 8, etc.). > > Another idea would be to take two key-ids from the KDF output instead of > just one. Then if the first key-id matches the key-id that's being rekeyed, > try the second key-id; if that also matches, just rerun the key exchange. > The odds of the key-id that's being rekeyed showing up twice is 1-in-256, > so key exchange reruns should be infrequent. Yep, something like one of the above. Or we just take more output bits from HKDF and say that the new key-id is the first of the relevant set of bits != the old key-id. That way we can lower the probability of a collision as much as we want. Will include a fix in a -05. Cheers, S. > > In all cases, both endpoints have to figure out whether the new key-id is > acceptable and reach the same conclusion. The requirement that "once > encrypted data packets protected with the new key have been successfully > received, the old key SHOULD be discarded" is helpful, but probably not > enough. > > I can think of more that could be said, but understanding what happens in > practice with error and corner cases will be important, e.g., if things > break in the wrong way at the wrong moment, can the two endpoints reach > different conclusions about whether the new key is working? If so, > that's probably of significant interest to an attacker who can introduce > errors. > > Thanks, > --David > >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Saturday, January 10, 2015 5:13 PM >> To: Black, David; mpls@ietf.org; stephen.farrell@cs.tcd.ie >> Subject: RE: [mpls] FW: New Version Notification for draft-farrelll-mpls- >> opportunistic-encrypt-04.txt >> >>>> I think key roll is covered in the text. We *do* need to roll the keys, >> but >> we >>>> believe that key roll can be achieved using the existing keying mechanisms >> with >>>> the additional benefit that the key messages are protected by the previous >>> keys. >>> >>> Related question - why is the key-id an output of the key exchange process, >>> specifically part of the HKDF output (near the end of 4.2.2)? >>> >>> Since the key-id is 4-bits, there's a 1-in-16 possibility that rekeying >>> yields the same id, which is a potential minor problem - if that happens, >>> I suppose one could rerun the key exchange, which is unlikely to collide >>> a second time (odds of two collisions in a row is less than one-half of 1%). >> >> Ah, no. The key-id is not the key. The key-id is an ID used to refer to the >> key. >> It is used in the encrypted packets to refer to the key and, since there is no >> need for more than a couple of active keys (current and roll-forward) at any >> time one could argue that one bit is enough, but four seemed safer for rapid >> rolls and a couple of spare keys. >> >> So all that is necessary is that the KDF generates a new number each time. >> Maybe >> that requires state and something in the input to the KDF. >> >>> I'd also expect that configuration could override that key-id output >>> (e.g., Alice and Bob might both know via some other means that this key >>> exchange is generating key 7, even if the HKDF produces a key-id of 2). >> >> So long as Alice and Bob both know that the same key-id refers to the same key >> and algorithm everything in the world will be wonderful. >> >> Adrian >> >>> If I had to guess why key-id is a key exchange output, it might be courtesy >>> of the initial key exchange being unauthenticated - the obvious alternative >>> of passing the key-id in the unauthenticated key exchange messages makes >>> it simple for a man-in-the-middle to defeat opportunistic encryption by >>> changing that key-id. Such a change causes the resulting key to be >>> installed under key-ids at the two endpoints, which will then fail to >>> successfully exchange encrypted traffic using that key ... >> >> > > From nobody Sun Jan 11 23:05:07 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA6F1A88A4 for ; Sun, 11 Jan 2015 23:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU_Z97Vtb1HZ for ; Sun, 11 Jan 2015 23:04:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56531A1B01 for ; Sun, 11 Jan 2015 23:04:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRC87428; Mon, 12 Jan 2015 07:04:55 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 12 Jan 2015 07:04:55 +0000 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.8]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 12 Jan 2015 15:04:49 +0800 From: Youjianjie To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-you-mpls-spring-sfc-oam-01.txt Thread-Index: AQHQLjGjDxhPylkX60y8vUcbJB9vu5y8B/aQ Date: Mon, 12 Jan 2015 07:04:48 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [mpls] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-you-mpls-spring-sfc-oam-01=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 07:05:02 -0000 RGVhciBhbGwsDQoNClRoaXMgdmVyc2lvbiByZWZsZWN0cyB0aGUgY29tbWVudHMgd2UndmUgcmVj ZWl2ZWQuIA0KUGxlYXNlIHJldmlldywgdGhhbmtzIQ0KDQpKaWFuamllDQoNCg0KLS0tLS3pgq7k u7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0MeaciDEy 5pelIDE0OjMzDQrmlLbku7bkuro6IFlvdWppYW5qaWU7IFh1eGlhb2h1OyBYdXhpYW9odTsgWW91 amlhbmppZQ0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXlvdS1t cGxzLXNwcmluZy1zZmMtb2FtLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC15b3UtbXBscy1zcHJpbmctc2ZjLW9hbS0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgSmlhbmppZSBZb3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOgkJZHJhZnQteW91LW1wbHMtc3ByaW5nLXNmYy1vYW0NClJldmlzaW9uOgkwMQ0K VGl0bGU6CQlTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIE9BTSBpbiBNUExTLVNQUklORyBOZXR3 b3Jrcw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wMS0xMQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1p c3Npb24NClBhZ2VzOgkJOQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXlvdS1tcGxzLXNwcmluZy1zZmMtb2FtLTAxLnR4dA0KU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlvdS1tcGxz LXNwcmluZy1zZmMtb2FtLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXlvdS1tcGxzLXNwcmluZy1zZmMtb2FtLTAxDQpEaWZmOiAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQteW91LW1wbHMtc3ByaW5nLXNmYy1v YW0tMDENCg0KQWJzdHJhY3Q6DQogICBUbyBwZXJmb3JtIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5p bmcgKFNGQykgaW4gbmV0d29ya3Mgd2hlcmUgYm90aA0KICAgTVBMUyBhbmQgU1BSSU5HIChTb3Vy Y2UgUGFja2V0IFJvdXRpbmcgaW4gTmV0d29ya2luZykgYXJlIGVuYWJsZWQsIGl0DQogICBpcyBy ZXF1aXJlZCB0byBiZSBhYmxlIHRvIGRldGVjdCBTZXJ2aWNlIEZ1bmN0aW9uIChTRikgY29ubmVj dGl2aXR5DQogICBhbmQgYXZhaWxhYmlsaXR5LiAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIHNp bXBsZSBtZWNoYW5pc20gZm9yIFNGDQogICBjb25uZWN0aXZpdHkgYW5kIGF2YWlsYWJpbGl0eSBk ZXRlY3Rpb24gYnkgdXNpbmcgdGhlIE1QTFMgZWNobw0KICAgcmVxdWVzdCBhbmQgcmVwbHkgbWVz c2FnZXMgYXMgZGVmaW5lZCBpbiBbUkZDNDM3OV0uDQoNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K From nobody Mon Jan 12 00:09:54 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80D31A8A67; Mon, 12 Jan 2015 00:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wqdoiNONhlJ; Mon, 12 Jan 2015 00:09:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB5D1A1AEC; Mon, 12 Jan 2015 00:09:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, "Loa Andersson" , mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112080951.14747.88816.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 00:09:51 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [mpls] Last Call Expired: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 08:09:53 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Mon Jan 12 06:50:07 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03321AC39E for ; Mon, 12 Jan 2015 06:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWGk6Opc7nMN; Mon, 12 Jan 2015 06:50:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D3E1AC398; Mon, 12 Jan 2015 06:50:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, "Loa Andersson" , mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112145004.17839.42580.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 06:50:04 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 14:50:06 -0000 IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead I am waiting for an updated draft that handles my review comments. I saw a response from David Black, but no further action. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ From nobody Mon Jan 12 07:02:39 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7ACE1AC3C2 for ; Mon, 12 Jan 2015 07:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIS7MtUSd2AT for ; Mon, 12 Jan 2015 07:02:30 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074CC1AC3B2 for ; Mon, 12 Jan 2015 07:02:25 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0CF2NOA004819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2015 10:02:24 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t0CF2NOA004819 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1421074944; bh=JYz7aDv6ArYHnANPQgYQ1w6fGH4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=mjFf/oNCssBkqxAtmn2L4nulG2elPBVN9Rlt6YmrS7SkGLBFzdaxQtQDfbEMvcRYw mfk6vpsTpDnihum6P/StzrwvcJvQH/IXTqHvYR/DWkZo3xBBB7T7M2GuRiKrWRg+yP Ri5BWTBsUc2txNt1sMDZYUhMYX8Q/PtmGVEwOcUY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t0CF2NOA004819 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Mon, 12 Jan 2015 10:00:39 -0500 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0CF28DM017141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 10:02:09 -0500 Received: from MXHUB106.corp.emc.com (10.253.58.23) by mxhub07.corp.emc.com (128.222.70.204) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 12 Jan 2015 10:02:08 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 10:02:08 -0500 From: "Black, David" To: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-in-udp@tools.ietf.org" , Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] ID Tracker State Update Notice: Thread-Index: AQHQLncnpwyB+JDf40O60wz/VXObRZy8lDnQ Date: Mon, 12 Jan 2015 15:02:07 +0000 Message-ID: References: <20150112145004.17839.42580.idtracker@ietfa.amsl.com> In-Reply-To: <20150112145004.17839.42580.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.40.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: " \(mpls-ads@tools.ietf.org\)" Subject: Re: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 15:02:34 -0000 The draft author team is working on that revision, should be submitted in n= ext few days. Thanks, --David > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: Monday, January 12, 2015 9:50 AM > To: mpls-chairs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; Lo= a > Andersson; mpls@ietf.org > Subject: [mpls] ID Tracker State Update Notice: 09.txt> >=20 > IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Wa= iting > for AD Go-Ahead > I am waiting for an updated draft that handles my review comments. I saw= a > response from David Black, but no further > action. > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Jan 12 07:52:47 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EF11AC3B2; Mon, 12 Jan 2015 07:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQs7DTZ48kHb; Mon, 12 Jan 2015 07:52:42 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D9B1AC3AB; Mon, 12 Jan 2015 07:52:41 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 61EEBD9D64624; Mon, 12 Jan 2015 15:52:32 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t0CFqVpS032098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 10:52:34 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 10:52:23 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" , "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCq3X4CABH7I4IAAgi6AgAPeSVA= Date: Mon, 12 Jan 2015 15:52:23 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947CC61C@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D947CA71B@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 15:52:46 -0000 SGkgUmFqaXYsDQpJIGFtIGdvb2Qgd2l0aCB5b3VyIHJlc3BvbnNlIGJlbG93LiBUaGFua3MhDQoN Ck11c3RhcGhhLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJhaml2 IEFzYXRpIChyYWppdmEpIFttYWlsdG86cmFqaXZhQGNpc2NvLmNvbV0NCj4gU2VudDogRnJpZGF5 LCBKYW51YXJ5IDA5LCAyMDE1IDEwOjI4IFBNDQo+IFRvOiBBaXNzYW91aSwgTXVzdGFwaGEgKE11 c3RhcGhhKTsgaWV0ZkBpZXRmLm9yZzsgSUVURi1Bbm5vdW5jZQ0KPiBDYzogbXBsc0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1sZHAt aXB2Ni0xNC50eHQ+IChVcGRhdGVzIHRvIExEUCBmb3INCj4gSVB2NikgdG8gUHJvcG9zZWQgU3Rh bmRhcmQNCj4gDQo+IEhpIE11c3RhcGhhLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgY2xhcml0eS4N Cj4gDQo+IDEuIFlvdSBoYXZlIGEgZmFpciBwb2ludC4gV2hpbGUgaXQgaXMgaW1wbGljaXQgdGhh dCBzZWN0aW9uIDIuNS41IG9mIFJGQw0KPiA1MDM2IChtYWludGFpbmluZyBoZWxsbyBhZGopIHdv dWxkIGFwcGx5LCBpdCBpcyByZWFzb25hYmxlIHRvIG1ha2UgaXQgZXhwbGljaXQuIFdlDQo+IGNh biBhZGQgdGhlIGJlbG93IHRleHQgLQ0KPiANCj4gLy9BIER1YWwtc3RhY2sgTFNSIE1VU1Qgc3Rp bGwgZm9sbG93IHNlY3Rpb24gMi41LjUgb2YgUkZDNTAzNiBhbmQgY2hlY2sgZm9yDQo+IG1hdGNo aW5nIEhlbGxvIG1lc3NhZ2VzIGZyb20gdGhlIHBlZXIgKGVpdGhlciBhbGwgSGVsbG9zIGFsc28g aW5jbHVkZSB0aGUgRHVhbC0NCj4gc3RhY2sgY2FwYWJpbGl0eSAod2l0aCBzYW1lIFRSIHZhbHVl KSBvciBub25lIGRvKS4vLw0KPiANCj4gDQo+IA0KPiAyLiBUaGlzIGlzIGFscmVhZHkgY292ZXJl ZCBpbiBib3RoIDNhIGFuZCAzYiBieSB0aGUgZm9sbG93aW5nIHZlcmJpYWdlICJIb3dldmVyLCBp Zg0KPiBJUHY2IGhlbGxvcyBhcmUgYWxzbyByZWNlaXZlZCBhdCBhbnkgdGltZSBmcm9tIHRoYXQg bmVpZ2hib3IuLuKAnSBpbiB0aGUgYmVnaW5uaW5nIG9mDQo+IDJuZCBwYXJhLiBOb3RlICJhdCBh bnkgdGltZeKAnSBoZXJlLg0KPiANCj4gVGhlIHRleHQgaXMgc3VmZmljaWVudCwgSU1ITy4NCj4g DQo+IDMuIENsb3NlZC4NCj4gDQo+IDQuNS4gT2suIFRoZSBmb2xsb3dpbmcgIihldmVuIGlmIElQ IGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gZm9yIElQdjYgYWRkcmVzcyBmYW1pbHkNCj4gd2FzIGRv bmUp4oCdIGlzIGFwcGVuZGVkIHRvIG1ha2UgaXQgZXhwbGljaXQuIEFuZCBUaGFua3MgZm9yIGNh dGNoaW5nIHRoZSBjb3B5LQ0KPiBwYXN0ZSBlcnJvci4gOikgRml4ZWQuDQo+IA0KPiBDbG9zZWQu DQo+IA0KPiANCj4gLS0NCj4gQ2hlZXJzLA0KPiBSYWppdiBBc2F0aQ0KPiBEaXN0aW5ndWlzaGVk IEVuZ2luZWVyLCBDaXNjbw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IDxBaXNzYW91aT4sIE11c3RhcGhhIEFpc3Nhb3VpIDxtdXN0YXBo YS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20+DQo+IERhdGU6IEZyaWRheSwgSmFudWFyeSA5 LCAyMDE1IGF0IDY6MTkgUE0NCj4gVG86IFJhaml2IEFzYXRpIDxyYWppdmFAY2lzY28uY29tPiwg SUVURiBEaXNjdXNzaW9uIDxpZXRmQGlldGYub3JnPiwNCj4gSUVURi1Bbm5vdW5jZSA8aWV0Zi1h bm5vdW5jZUBpZXRmLm9yZz4NCj4gQ2M6ICJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4N Cj4gU3ViamVjdDogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtbGRwLWlw djYtMTQudHh0PiAoVXBkYXRlcw0KPiB0byBMRFAgZm9yIElQdjYpIHRvIFByb3Bvc2VkIFN0YW5k YXJkDQo+IA0KPiA+SGkgUmFqaXYsDQo+ID5UaGFua3MgZm9yIHRoZSByZXBseS4gSSBhZGRlZCBz b21lIGZvbGxvdy11cCBpbmxpbmUgYmVsb3cuDQo+ID4NCj4gPlJlZ2FyZHMsDQo+ID5NdXN0YXBo YS4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBSYWpp diBBc2F0aSAocmFqaXZhKSBbbWFpbHRvOnJhaml2YUBjaXNjby5jb21dDQo+ID4+IFNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMDYsIDIwMTUgNjowMyBQTQ0KPiA+PiBUbzogQWlzc2FvdWksIE11c3Rh cGhhIChNdXN0YXBoYSk7IGlldGZAaWV0Zi5vcmc7IElFVEYtQW5ub3VuY2UNCj4gPj4gQ2M6IG1w bHNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1p ZXRmLW1wbHMtbGRwLWlwdjYtMTQudHh0Pg0KPiA+PihVcGRhdGVzIHRvIExEUCBmb3INCj4gPj4g SVB2NikgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPj4NCj4gPj4gSGkgTXVzdGFwaGEsDQo+ID4+ DQo+ID4+ID4gSGF2aW5nIHNhaWQgdGhhdCwgSSB3YW50IHRvIGtlZXAgdGhlIHNwaXJpdCBvZiBj b29wZXJhdGlvbiBhbmQgbWFrZQ0KPiA+PiA+c3VyZSB3ZSBnZXQgdGhpcyAgZHJhZnQgcHVibGlz aGVkLiBUbyB0aGF0IGVmZmVjdCwgSSBhbSBub3Qgb3Bwb3NlZCB0bw0KPiA+PiA+aXRzIHB1Ymxp Y2F0aW9uIGFzIGxvbmcgYXMgdGhlICBmb2xsb3dpbmcgcG9pbnRzIGFyZSBjbGFyaWZpZWQgaW4g dGhlDQo+ID4+ID5kcmFmdCBzaW5jZSBub3cgRkVDIGNhcGFiaWxpdHkgb2YgdGhlIExTUiBwZWVy IGlzICBkZXRlcm1pbmVkIGJ5IGENCj4gPj4gPmNoZWNrIGEgYm90aCBhZGphY2VuY3kgYW5kIHNl c3Npb24gbGV2ZWxzOg0KPiA+Pg0KPiA+PiBUaGFua3MgZm9yIHBvaW50aW5nIG91dCB0aGUgYmVs b3cgc2NlbmFyaW9zLiBXZSB0aGluayB0aGF0IGFsbCBidXQgb25lDQo+ID4+YXJlIGVpdGhlcg0K PiA+PiBjb3ZlcmVkIG9yIHJlcXVpcmUgZWRpdG9yaWFsIGNoYW5nZXMuDQo+ID4+DQo+ID4+DQo+ ID4+IDEuIFRoaXMgc2NlbmFyaW8gKHNlbmRpbmcgaGVsbG9zIHdpdGggRFMgY2FwYWJpbGl0eSBv biBmZXdlciBpbnRlcmZhY2VzDQo+ID4+Zm9yIGEgcGVlcikNCj4gPj4gZG9lcyBOT1QgbG9vayBy ZWFsaXN0aWMsIHNpbmNlIGhpdGxlc3MgdXBncmFkaW5nIGEgcm91dGVyIHdvdWxkIHJlc3VsdA0K PiA+PmluIHNlbmRpbmcNCj4gPj4gdjQrdjYgaGVsbG9zIGVpdGhlciB3aXRoIERTIGNhcGFiaWxp dHkgb3Igd2l0aG91dCBEUyBjYXBhYmlsaXR5IChmb3IgYQ0KPiA+PkRTIHBlZXIsDQo+ID4+IGFz c3VtaW5nIHRoZSBwZWVyIHdhcyBlbmFibGVkIGZvciBEUyBMRFAsIGRlZmF1bHQgb3Igbm90LCBp biBhbg0KPiA+PmltcGxlbWVudGF0aW9uKS4NCj4gPj4NCj4gPj4gUGVyaGFwcywgeW91IGhhZCBh IGRpZmZlcmVudCBzY2VuYXJpbyBpbiBtaW5kLg0KPiA+TUE+IFRoaXMgY291bGQgb2NjdXIgZHVy aW5nIGEgaGl0bGVzcyB1cGdyYWRlIGZvciBIZWxsbyBhZGphY2VuY2llcyBmcm9tDQo+ID5kaWZm ZXJlbnQgbGluZSBjYXJkcyBkdXJpbmcgYSB0cmFuc2llbnQgdGltZS4gSSB3aWxsIG5vdCBpbnNp c3Qgb24gdGhpcw0KPiA+cG9pbnQgYnV0IEkgZm91bmQgdGhlIGRyYWZ0IGxhY2tzIHdoYXQgYWN0 aW9uIHRvIHRha2UgaWYgdGhlIEhlbGxvDQo+ID5tZXNzYWdlcyByZWNlaXZlZCBvbiBwYXJhbGxl bCBsaW5rcyBmcm9tIHRoZSBzYW1lIExTUiBhcmUgbm90IGNvbnNpc3RlbnQsDQo+ID5tZWFuaW5n IHRoZXkgaGF2ZSBkaWZmZXJlbnQgVFIgdmFsdWVzIG9yIHRoZSBtZXNzYWdlIG9uIG9uZSBsaW5r IGRvIG5vdA0KPiA+aGF2ZSB0aGUgRFMgY2FwYWJpbGl0eS4gVGhlIG9ubHkgdGhpbmcgSSBmb3Vu ZCBpcyB0aGlzIHBhcmFncmFwaCBpbg0KPiA+U2VjdGlvbiA2LjEuMSBidXQgaXQgZG9lcyBub3Qg c2F5IHdoYXQgdG8gZG8gaWYgYW4gTFNSIHJlY2VpdmVzDQo+ID5pbmNvbnNpc3RlbnQgSGVsbG8g bWVzc2FnZXM6DQo+ID4iDQo+ID5BbiBMU1IgTVVTVCBjb252ZXkgdGhlIHNhbWUgdHJhbnNwb3J0 IGNvbm5lY3Rpb24gcHJlZmVyZW5jZSAoIlRSIg0KPiA+ICAgZmllbGQgdmFsdWUpIGluIGFsbCAo bGluayBhbmQgdGFyZ2V0ZWQpIEhlbGxvcyB0aGF0IGFkdmVydGlzZSB0aGUNCj4gPiAgIHNhbWUg bGFiZWwgc3BhY2UgdG8gdGhlIHNhbWUgcGVlciBhbmQvb3Igb24gc2FtZSBpbnRlcmZhY2UuICBU aGlzDQo+ID4gICBlbnN1cmVzIHRoYXQgdHdvIExTUnMgbGlua2VkIGJ5IG11bHRpcGxlIEhlbGxv IGFkamFjZW5jaWVzIHVzaW5nIHRoZQ0KPiA+ICAgc2FtZSBsYWJlbCBzcGFjZXMgcGxheSB0aGUg c2FtZSBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgcm9sZSBmb3INCj4gPiAgIGVhY2ggYWRqYWNl bmN5Lg0KPiA+Ig0KPiA+DQo+ID4+IDIuIFllcy4gVGhpcyBzY2VuYXJpbyBpcyB3ZWxsIGNvdmVy ZWQgaW4gc2VjdGlvbiA2LjEuMSBwb2ludCMzLg0KPiA+Pg0KPiA+Pg0KPiA+PiAvLw0KPiA+PiAg ICAgIDMuIElmICJEdWFsLXN0YWNrIGNhcGFiaWxpdHkiIFRMViBpcyBOT1QgcHJlc2VudCwgYW5k DQo+ID4+DQo+ID4+IMWgDQo+ID4+ICAgICAgICAgICAgICByZXN1bHRpbmcgaW4gYW55IGVzdGFi bGlzaGVkIExEUG9JUHY0IHNlc3Npb24gYmVpbmcgcmVzZXQNCj4gPj4gICAgICAgICAgICAgIGFu ZCBhIGZhdGFsIE5vdGlmaWNhdGlvbiBtZXNzYWdlIGJlaW5nIHNlbnQgKHdpdGggc3RhdHVzDQo+ ID4+DQo+ID4+IMWgDQo+ID4+DQo+ID4+IC8vDQo+ID5NQT4gV2hhdCBJIHdhcyB0YWxraW5nIGFi b3V0IGlzIGEgdHJhbnNpdGlvbiBmcm9tIHN0YXRlIDJhIHRvIHN0YXRlIDNhIG9yDQo+ID5mcm9t IHN0YXRlIDJiIHRvIHN0YXRlIDNiIGluIFNlY3Rpb24gNi4xLjEuIFBlcmhhcHMgb25lIHdheSB0 byBleHBsaWNpdGx5DQo+ID5zdGF0ZSB0aGF0IHRoZSBzZXNzaW9uIGlzIGJvdW5jZWQgd291bGQg YmUgdG8gYWRkIHNvbWV0aGluZyBsaWtlIHRoaXMgdG8NCj4gPml0ZW1zIDJhIGFuZCAyYiBvZiBT ZWN0aW9uIDYuLjEuMToNCj4gPiINCj4gPjIuIElmICJEdWFsLXN0YWNrIGNhcGFiaWxpdHkiIFRM ViBpcyBwcmVzZW50LCBhbmQgcmVtb3RlDQo+ID4gICAgICAgIHByZWZlcmVuY2UgbWF0Y2hlcyB3 aXRoIHRoZSBsb2NhbCBwcmVmZXJlbmNlLCB0aGVuOg0KPiA+DQo+ID4gICAgICAgICAgYSkgSWYg VFI9MDEwMCAoTERQb0lQdjQpLCB0aGVuIGRldGVybWluZSB0aGUgYWN0aXZlL3Bhc3NpdmUNCj4g PiAgICAgICAgICAgICByb2xlcyBmb3IgVENQIGNvbm5lY3Rpb24gdXNpbmcgSVB2NCB0cmFuc3Bv cnQgYWRkcmVzcyBhcw0KPiA+ICAgICAgICAgICAgIGRlZmluZWQgaW4gc2VjdGlvbiAyLjUuMiBv ZiBSRkMgNTAzNi4NCj4gPg0KPiA+ICAgICAgICAgIGIpIElmIFRSPTAxMTAgKExEUG9JUHY2KSwg dGhlbiBkZXRlcm1pbmUgdGhlIGFjdGl2ZS9wYXNzaXZlDQo+ID4gICAgICAgICAgICAgcm9sZXMg Zm9yIFRDUCBjb25uZWN0aW9uIGJ5IHVzaW5nIElQdjYgdHJhbnNwb3J0IGFkZHJlc3MNCj4gPiAg ICAgICAgICAgICBhcyBkZWZpbmVkIGluIHNlY3Rpb24gMi41LjIgb2YgUkZDIDUwMzYuDQo+ID4g ICAqSWYgc3Vic2VxdWVudGx5IHRvIGVzdGFibGlzaGluZyB0aGUgTERQIHNlc3Npb24sIHRoZSBI ZWxsbyBtZXNzYWdlcw0KPiA+ZnJvbSB0aGUgcGVlcg0KPiA+ICAgZG8gbm90IGluY2x1ZGUgdGhl IER1YWwtc3RhY2sgY2FwYWJpbGl0eSBUTFYsIHRoZSBzZXNzaW9uIGlzDQo+ID50ZXJtaW5hdGVk IGFuZCBhIGZhdGFsIE5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHNlbnQgd2l0aCAgICAgc3RhdHVz IGNvZGUNCj4gPm9mICdEdWFsLVN0YWNrIE5vbi1Db21wbGlhbmNlJyAoSUFOQSBhbGxvY2F0aW9u IFRCRCkuKg0KPiA+Ig0KPiA+DQo+ID4NCj4gPj4NCj4gPj4gMy4gWWVzICh0byB0aGUgZXhwZWN0 ZWQgYmVoYXZpb3IpLiBUaGlzIGlzIHNvbWV3aGF0IGNvdmVyZWQgaW4gYnVsbGV0DQo+ID4+IzEg aW4gc2VjdGlvbg0KPiA+PiA2LjEuMSwgYnV0IHdlIGNhbiBtYWtlIGl0IGV4cGxpY2l0IGJ5IGFk ZGluZyAib3IgZG9lcyBub3QgZ2V0DQo+ID4+cmVjb2duaXplZMKyIGFzIGJlbG93Og0KPiA+Pg0K PiA+Pg0KPiA+PiBPTEQ6DQo+ID4+IElmICJEdWFsLXN0YWNrIGNhcGFiaWxpdHkiIFRMViBpcyBw cmVzZW50IGFuZCByZW1vdGUgcHJlZmVyZW5jZSBkb2VzDQo+ID4+bm90IG1hdGNoDQo+ID4+IHdp dGggdGhlIGxvY2FsIHByZWZlcmVuY2UsLi4NCj4gPj4NCj4gPj4NCj4gPj4gTkVXOg0KPiA+PiBJ ZiAiRHVhbC1zdGFjayBjYXBhYmlsaXR5IiBUTFYgaXMgcHJlc2VudCBhbmQgcmVtb3RlIHByZWZl cmVuY2UgZG9lcw0KPiA+Pm5vdCBtYXRjaA0KPiA+PiB3aXRoIHRoZSBsb2NhbCBwcmVmZXJlbmNl IChvciBkb2VzIG5vdCBnZXQgcmVjb2duaXplZCksLi4NCj4gPk1BPiBZb3VyIHByb3Bvc2VkIG1v ZGlmaWNhdGlvbiBkb2VzIGFkZHJlc3MgdGhpcyBjb21tZW50LiBUaGFuayB5b3UuDQo+ID4NCj4g Pg0KPiA+PiA0IGFuZCA1LiBZZXMgKHRvIHRoZSBleHBlY3RlZCBiZWhhdmlvcikuIEl0IGlzIGlt cGxpY2l0IGluIHNlY3Rpb24gNy4yDQo+ID4+cGFyYSA0Lg0KPiA+Pg0KPiA+PiAvLy4uDQo+ID4+ ICBBbiBMU1IgTUFZIGZ1cnRoZXIgY29uc3RyYWluIHRoZSBhZHZlcnRpc2VtZW50IG9mIEZFQy1s YWJlbCBiaW5kaW5ncw0KPiA+PmZvciBhDQo+ID4+IHBhcnRpY3VsYXIgYWRkcmVzcyBmYW1pbHkg YnkgbmVnb3RpYXRpbmcgdGhlIElQIENhcGFiaWxpdHkuLi4vLw0KPiA+Pg0KPiA+PiBBcmUgeW91 IHN1Z2dlc3RpbmcgdG8gbWFrZSBpdCBleHBsaWNpdD8NCj4gPk1BPiBZZXMgSSB3YW50ZWQgc29t ZXRoaW5nIG1vcmUgZXhwbGljaXQuIFRoaXMgc2VjdGlvbiBjZXJ0YWlubHkgc2F5cyB0aGUNCj4g PklQdjYgcHJlZml4IEZFQyBjYXBhYmlsaXR5IGNhbiBmdXJ0aGVyIGNvbnN0cmFpbiBhIHBhcnRp Y3VsYXIgRkVDIHR5cGUNCj4gPndoaWNoIGlzIGFsbG93ZWQgYnkgdGhlIGNoZWNrIG9mIHRoZSBE UyBjYXBhYmlsaXR5IFRMVi4gSXQgaG93ZXZlciBkb2VzDQo+ID5ub3QgZGlzY3VzcyB0aGUgbmVn YXRpdmUgY2FzZSwgaS5lLiwgdGhlIERTIGNhcGFiaWxpdHkgVExWIGRpZCBub3QgYWxsb3cNCj4g PmEgRkVDIHR5cGUgYnV0IHRoZSBJUCBjYXBhYmlsaXR5IGFsbG93ZWQgaXQuDQo+ID5JIGJlbGll dmUgdGhlIGZvbGxvd2luZyBhZGRpdGlvbiB0byBhbiBlYXJsaWVyIHBhcmFncmFwaCBpbiBTZWN0 aW9uIDcuMg0KPiA+d291bGQgaGVscCBjbGFyaWZ5IHRoaXM6DQo+ID4iDQo+ID5JZiBhbiBMU1Ig ZW5hYmxlZCB3aXRoIER1YWwtc3RhY2sgTERQIGZvciBhIHBlZXIgYW5kDQo+ID4NCj4gPiAgICAg MS4gSXMgTk9UIGFibGUgdG8gZmluZCB0aGUgRHVhbC1zdGFjayBjYXBhYmlsaXR5IFRMViBpbiB0 aGUNCj4gPiAgICAgICAgaW5jb21pbmcgSVB2NCBMRFAgaGVsbG8gbWVzc2FnZXMgZnJvbSB0aGF0 IHBlZXIsIHRoZW4gdGhlIExTUg0KPiA+ICAgICAgICBNVVNUIE5PVCBhZHZlcnRpc2UgSVB2NiBG RUMtbGFiZWwgYmluZGluZ3MgdG8gdGhlIHBlZXIgKmV2ZW4gaWYNCj4gPml0IHJlY2VpdmVkIGFu IElQIGNhcGFiaWxpdHkNCj4gPiAgICAgICAgZnJvbSB0aGUgcGVlciBpbmRpY2F0aW5nIHRoZSBl bmFibGluZyBvZiB0aGUgSVB2NiBGRUMgdHlwZSouDQo+ID4iDQo+ID5CVFcsIHRoZXJlIGlzIGEg ImNvcHkgJiBwYXN0ZSIgbWlzdGFrZSBpbiB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCBpbiB0aGUN Cj4gPnNhbWUgU2VjdGlvbiA3LjIuIFRoZSAidmlhIEFERFJFU1MgbWVzc2FnZSIgaXMgbm90IGNv cnJlY3QgaGVyZSBzaW5jZQ0KPiA+dGhpcyBpcyBhYm91dCBGRUMgZGlzdHJpYnV0aW9uLCBoZW5j ZSBMYWJlbCBNYXBwaW5nIG1lc3NhZ2UsIGFuZCBub3QNCj4gPmFkZHJlc3MgZGlzdHJpYnV0aW9u Lg0KPiA+Ig0KPiA+SWYgYW4gTFNSIGlzIGVuYWJsZWQgd2l0aCBTaW5nbGUtc3RhY2sgTERQIGZv ciBhbnkgcGVlciwgdGhlbiBpdA0KPiA+ICAgTVVTVCBhZHZlcnRpc2UgKHZpYSBBRERSRVNTIG1l c3NhZ2UpIEZFQy1MYWJlbCBiaW5kaW5ncyBmb3IgdGhlDQo+ID4gICBlbmFibGVkIGFkZHJlc3Mg ZmFtaWx5LCBhbmQgYWNjZXB0IEZFQy1MYWJlbCBiaW5kaW5ncyBmb3IgdGhlDQo+ID4gICBlbmFi bGVkIGFkZHJlc3MgZmFtaWx5Lg0KPiA+Ig0KPiA+DQo+ID4+IC0tDQo+ID4+IENoZWVycywNCj4g Pj4gUmFqaXYgQXNhdGkNCj4gPj4gRGlzdGluZ3Vpc2hlZCBFbmdpbmVlciwgQ2lzY28NCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4gRnJvbTogPEFpc3Nhb3VpPiwgTXVzdGFwaGEgQWlzc2FvdWkNCj4gPj48bXVzdGFwaGEu YWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tPg0KPiA+PiBEYXRlOiBUdWVzZGF5LCBEZWNlbWJl ciAxNiwgMjAxNCBhdCAxMjoyMSBQTQ0KPiA+PiBUbzogSUVURiBEaXNjdXNzaW9uIDxpZXRmQGll dGYub3JnPiwgSUVURi1Bbm5vdW5jZQ0KPiA+PjxpZXRmLWFubm91bmNlQGlldGYub3JnPg0KPiA+ PiBDYzogIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0KPiA+PiBTdWJqZWN0OiBSZTog W21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0xNC50eHQ+DQo+ID4+ KFVwZGF0ZXMNCj4gPj4gdG8gTERQIGZvciBJUHY2KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ Pg0KPiA+PiA+SGkgQWRyaWFuIGFuZCBhbGwsDQo+ID4+ID5JIHdhcyB0aGUgb25lIHdobyByYWlz ZWQgdGhlIGludGVyb3AgaXNzdWVzIHdlIGZvdW5kIHdoaWxlIHRlc3Rpbmcgb3VyDQo+ID4+ID5p bXBsZW1lbnRhdGlvbiBvZiBMRFAgSVB2NiBhZ2FpbnN0IGV4aXN0aW5nIGFuZCBkZXBsb3llZA0K PiA+PmltcGxlbWVudGF0aW9ucy4NCj4gPj4gPkkgcHJvcG9zZWQgYSBzaW1wbGUgbWV0aG9kIG9m IHVzaW5nIHRoZSBleGlzdGluZyBGRUMgYWR2ZXJ0aXNlbWVudA0KPiA+PiA+Y2FwYWJpbGl0eSBh dCB0aGUgc2Vzc2lvbiBsZXZlbCBhcyBhIHdheSBmb3IgYW4gTFNSIHRvIGRldGVjdCBpZiBhbg0K PiA+PiA+aW1wbGVtZW50YXRpb24gc3VwcG9ydCBMRFAgSVB2NiBGRUNzIGFuZCBJUHY2IGFkZHJl c3Nlcy4gVGhpcyBleGlzdGluZw0KPiA+PiA+RkVDIGFkdmVydGlzZW1lbnQgY2FwYWJpbGl0eSBh dCBzZXNzaW9uIGxldmVsIGlzIGRlZmluZWQgaW4NCj4gPj4gPmRyYWZ0LWlldGYtbXBscy1sZHAt aXAtcHctY2FwYWJpbGl0eS0wOCBidXQgd2l0aCB0aGUgbGltaXRhdGlvbiB0aGF0IGl0DQo+ID4+ ID5jYW4gYmUgdXNlZCBvbmx5IHRvIGRpc2FibGUgc3VwcG9ydCBvZiBJUHY2IEZFQ3MgaW4gTERQ IEluaXRpYWxpemF0aW9uDQo+ID4+ID5NZXNzYWdlOyB3ZSBwcm9wb3NlZCB0byBnZW5lcmFsaXpl IHRoZSBtZXRob2QgdG8gYWxzbyBpbmRpY2F0ZSBleHBsaWNpdA0KPiA+PiA+c3VwcG9ydCBmb3Ig SVB2NiBGRUNzIGFuZCBJUHY2IEFkZHJlc3NlcyBpbiBMRFAgSW5pdGlhbGl6YXRpb24gTWVzc2Fn ZS4NCj4gPj4gPlRoaXMgbWV0aG9kIGlzIHNhZmUgYW5kIHdhcyBhbHNvIHVzZWQgd2l0aCBtTERQ IFAyTVAgYW5kIE1QMk1QIEZFQ3MNCj4gPj4gd2hlbg0KPiA+PiA+dGhleSB3ZXJlIGludHJvZHVj ZWQuIFRoZSBpbnRlbnQgaGVyZSBpcyB0aGF0IGFsbCBzZXNzaW9uIGxldmVsDQo+ID4+ID5jYXBh YmlsaXRpZXMgaW4gTERQIHNob3VsZCBmb2xsb3cgUkZDIDU1NjEgYXBwcm9hY2guDQo+ID4+ID4N Cj4gPj4gPlRoZXJlIHdhcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yIHdoaWNoIHN1cHBvcnRl ZCB0aGUgcHJvcG9zYWwgb24gdGhlDQo+ID4+ID5tYWlsaW5nIGxpc3QgYnV0IHRoZSBhdXRob3Jz IGNob3NlIHRvIGlnbm9yZSBpdCBhbmQgd2VudCB3aXRoIGENCj4gPj5wcm9wb3NhbA0KPiA+PiA+ d2hpY2ggb3ZlcmxvYWRlZCB0aGUgbWVhbmluZyBvZiB0aGUgZHVhbC1zdGFjayBjYXBhYmlsaXR5 IFRMVi4NCj4gPj5SZWdhcmRsZXNzDQo+ID4+ID5vZiB0aGUgbWVyaXQgb2YgZWl0aGVyIG1ldGhv ZCwgdGhlIGRpc2N1c3Npb24gb24gdGhlIE1QTFMgbWFpbGluZyBsaXN0DQo+ID4+ID53YXMgbm90 IGNsb3NlZCBwcm9wZXJseSBmcm9tIG15IHBlcnNwZWN0aXZlLg0KPiA+PiA+DQo+ID4+ID5Ob3cg aGVyZSBpcyB0aGUgY29uY2VybiBJIHJhaXNlZCB3aXRoIHVzaW5nIHRoZSBkdWFsLXN0YWNrIGNh cGFiaWxpdHkuDQo+ID4+ID5Ob3Qgb25seSB0aGlzIFRMViBpcyBhbiBhZGphY2VuY3kgbGV2ZWwg ZmVhdHVyZSB3aGljaCBpcyBoYXMgbm90aGluZyB0bw0KPiA+PiA+ZG8gd2l0aCBGRUMgY2FwYWJp bGl0eSBhZHZlcnRpc2VtZW50LCBidXQgaXQgaXMgaW50cm9kdWNpbmcgY29tcGxleGl0eQ0KPiA+ PmluDQo+ID4+ID50aGUgaW1wbGVtZW50YXRpb24gd2hpY2ggbm93IGhhcyB0byBjaGVjayBkdWFs LXN0YWNrIGNhcGFiaWxpdHkgZm9yDQo+ID4+ID4qZWFjaCogYWRqYWNlbmN5IHRvIHRoZSBwZWVy ICphbmQqIHRoZSBzZXNzaW9uIGxldmVsIEZFQyBjYXBhYmlsaXR5IHRvDQo+ID4+ID5kZWNpZGUg d2hhdCB0aGUgcGVlciBpcyBjYXBhYmxlIG9mIGF0IHRoZSAqc2Vzc2lvbiBsZXZlbCouDQo+ID4+ ID4NCj4gPj4gPkhhdmluZyBzYWlkIHRoYXQsIEkgd2FudCB0byBrZWVwIHRoZSBzcGlyaXQgb2Yg Y29vcGVyYXRpb24gYW5kIG1ha2UNCj4gPj5zdXJlDQo+ID4+ID53ZSBnZXQgdGhpcyBkcmFmdCBw dWJsaXNoZWQuIFRvIHRoYXQgZWZmZWN0LCBJIGFtIG5vdCBvcHBvc2VkIHRvIGl0cw0KPiA+PiA+ cHVibGljYXRpb24gYXMgbG9uZyBhcyB0aGUgZm9sbG93aW5nIHBvaW50cyBhcmUgY2xhcmlmaWVk IGluIHRoZSBkcmFmdA0KPiA+PiA+c2luY2Ugbm93IEZFQyBjYXBhYmlsaXR5IG9mIHRoZSBMU1Ig cGVlciBpcyBkZXRlcm1pbmVkIGJ5IGEgY2hlY2sgYQ0KPiA+PmJvdGgNCj4gPj4gPmFkamFjZW5j eSBhbmQgc2Vzc2lvbiBsZXZlbHM6DQo+ID4+ID4NCj4gPj4gPjEuIFRoZSBkcmFmdCBpcyBtaXNz aW5nIHRoZSBiZWhhdmlvciB3aGVuIG11bHRpcGxlIGFkamFjZW5jaWVzIGV4aXN0IHRvDQo+ID4+ ID50aGUgc2FtZSBMU1IgYW5kIHRoZSBwZWVyIExTUiBhZHZlcnRpc2VkIHRoZSBkdWFsLXN0YWNr IGNhcGFiaWxpdHkgb25seQ0KPiA+PiA+b3ZlciBhIHN1YnNldCBvZiB0aGVzZSBIZWxsbyBhZGph Y2VuY2llcy4NCj4gPj4gPkkgYXNzdW1lIGhlcmUgdGhlIHBlZXIgTFNSIGlzIGNvbnNpZGVyZWQg dG8gYmUgZHVhbC1zdGFjayBjYXBhYmxlIGFzDQo+ID4+c29vbg0KPiA+PiA+YXMgYW55IG9mIHRo ZSBIZWxsbyBhZGphY2VuY2llcyBpbmNsdWRlcyB0aGUgZHVhbC1zdGFjayBjYXBhYmlsaXR5Lg0K PiA+PlRoaXMNCj4gPj4gPndvdWxkIGFsbG93IGEgaGl0bGVzcyB1cGdyYWRlIHNjZW5hcmlvIGZy b20gYW4gb2xkZXIgaW1wbGVtZW50YXRpb24gdG8NCj4gPj4gPm9uZSB3aGljaCBjb21wbGllcyB0 byB0aGlzIGRyYWZ0DQo+ID4+ID4NCj4gPj4gPjIuIFNpbWlsYXJseSwgd2hhdCB3b3VsZCBiZSB0 aGUgYmVoYXZpb3IgaWYgYSBoZWxsbyBhZGphY2VuY3kgY2hhbmdlcw0KPiA+PiA+ZnJvbSBzZW5k aW5nIHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkgdG8gbm90IHNlbmRpbmcgaXQ/IFRoaXMgd291 bGQgYmUNCj4gPj4gPmZvciBleGFtcGxlIGluIGEgaGl0bGVzcyBkb3duZ3JhZGUgdG8gYSB2ZXJz aW9uIG9mIExEUCB3aGljaCBkb2VzIG5vdA0KPiA+PiA+Y29tcGx5IHRvIHRoaXMgZHJhZnQuDQo+ ID4+ID5JIGFzc3VtZSBoZXJlIHRoYXQgdGhlIHNlc3Npb24gbXVzdCBiZSBib3VuY2VkIHNpbmNl IHRoZSBMU1JzIG5lZWQgYQ0KPiA+PiA+Y2xlYW4gc3RhdGUgdG8gbm90IHNlbmQgSVB2NiBhZGRy ZXNzZXMgYW5kIElQdjYgRkVDcy4NCj4gPj4gPg0KPiA+PiA+My4gVGhlIGRvY3VtZW50IGRlZmlu ZXMgMiB2YWx1ZXMgZm9yIHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkgVFIuIEl0DQo+ID4+ID5k b2VzIG5vdCBtZW50aW9uIHRoZSBiZWhhdmlvciB3aGVuIGFuIHVua25vd24gdmFsdWUgaXMgcmVj ZWl2ZWQuDQo+ID4+ID5XaWxsIHRoYXQgYmUgY29uc2lkZXJlZCBhIGZhdGFsIGVycm9yPw0KPiA+ PiA+DQo+ID4+ID40LiBUaGUgZHJhZnQgaXMgbWlzc2luZyB0aGUgYmVoYXZpb3Igb2Ygd2hlbiB0 aGUgcGVlciBMU1IgZG9lcyBub3QNCj4gPj4gPmFkdmVydGlzZSB0aGUgZHVhbC1zdGFjayBjYXBh YmlsaXR5IGluIGFsbCB0aGUgSGVsbG8gYWRqYWNlbmNpZXMgYnV0IGl0DQo+ID4+ID5hZHZlcnRp c2VkIHRoZSBlbmFibGluZyBvciBkaXNhYmxpbmcgb2YgdGhlIElQdjYgcHJlZml4IEZFQyBjYXBh YmlsaXR5DQo+ID4+aW4NCj4gPj4gPnRoZSBzZXNzaW9uIGluaXRpYWxpemF0aW9uIG1lc3NhZ2Uu DQo+ID4+ID5JIGFzc3VtZSBoZXJlIHRoYXQgdGhlIGFic2VuY2Ugb2YgdGhlIGR1YWwtc3RhY2sg Y2FwYWJpbGl0eSBvdmVycmlkZXMNCj4gPj5hbnkNCj4gPj4gPnNlc3Npb24gbGV2ZWwgSVB2NiBG RUMgcHJlZml4IGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudC4NCj4gPj4gPg0KPiA+PiA+NS4gVGhl IGRyYWZ0IGlzIG1pc3NpbmcgdGhlIGJlaGF2aW9yIG9mIHdoZW4gdGhlIHBlZXIgTFNSIGRvZXMg bm90DQo+ID4+ID5hZHZlcnRpc2UgdGhlIGR1YWwtc3RhY2sgY2FwYWJpbGl0eSBpbiBhbGwgdGhl IEhlbGxvIGFkamFjZW5jaWVzIGJ1dCBpdA0KPiA+PiA+YWR2ZXJ0aXNlZCB0aGUgZW5hYmxpbmcg b2YgdGhlIElQdjYgcHJlZml4IEZFQyBjYXBhYmlsaXR5IGluIHRoZQ0KPiA+PnNlc3Npb24NCj4g Pj4gPkNhcGFiaWxpdHkgbWVzc2FnZS4NCj4gPj4gPkkgYXNzdW1lIHRoZSBzYW1lIGJlaGF2aW9y IGFzIGluICg0KSBhcHBsaWVzIGhlcmUuDQo+ID4+ID4NCj4gPj4gPlJlZ2FyZHMsDQo+ID4+ID5N dXN0YXBoYS4NCj4gPj4gPg0KPiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ PiA+PiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgVGhlIElFU0cNCj4gPj4gPj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDI6 MzcgUE0NCj4gPj4gPj4gVG86IElFVEYtQW5ub3VuY2UNCj4gPj4gPj4gQ2M6IG1wbHNAaWV0Zi5v cmcNCj4gPj4gPj4gU3ViamVjdDogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1s ZHAtaXB2Ni0xNC50eHQ+IChVcGRhdGVzDQo+ID4+ID4+dG8gTERQIGZvciBJUHY2KQ0KPiA+PiA+ PiB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBUaGUgSUVT RyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwNCj4g Pj5Td2l0Y2hpbmcNCj4gPj4gPj5XRw0KPiA+PiA+PiAobXBscykgdG8gY29uc2lkZXIgdGhlIGZv bGxvd2luZyBkb2N1bWVudDoNCj4gPj4gPj4gLSAnVXBkYXRlcyB0byBMRFAgZm9yIElQdjYnDQo+ ID4+ID4+ICAgPGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0xNC50eHQ+IGFzIFByb3Bvc2VkIFN0 YW5kYXJkDQo+ID4+ID4+DQo+ID4+ID4+IFRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lv biBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cw0KPiA+PiA+PmZpbmFsDQo+ID4+ ID4+IGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21t ZW50cyB0byB0aGUNCj4gPj4gPj5pZXRmQGlldGYub3JnDQo+ID4+ID4+IG1haWxpbmcgbGlzdHMg YnkgMjAxNC0xMi0xOC4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IGJlIHNlbnQgdG8NCj4g Pj4gPj5pZXNnQGlldGYub3JnDQo+ID4+ID4+IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVh c2UgcmV0YWluIHRoZSBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QNCj4gPj4gPj5saW5lIHRvIGFs bG93DQo+ID4+ID4+IGF1dG9tYXRlZCBzb3J0aW5nLg0KPiA+PiA+Pg0KPiA+PiA+PiBBYnN0cmFj dA0KPiA+PiA+Pg0KPiA+PiA+PiAgICBUaGUgTGFiZWwgRGlzdHJpYnV0aW9uIFByb3RvY29sIChM RFApIHNwZWNpZmljYXRpb24gZGVmaW5lcw0KPiA+PiA+PiAgICBwcm9jZWR1cmVzIHRvIGV4Y2hh bmdlIGxhYmVsIGJpbmRpbmdzIG92ZXIgZWl0aGVyIElQdjQsIG9yIElQdjYgb3INCj4gPj4gPj4g ICAgYm90aCBuZXR3b3Jrcy4gVGhpcyBkb2N1bWVudCBjb3JyZWN0cyBhbmQgY2xhcmlmaWVzIHRo ZSBMRFANCj4gPj5iZWhhdmlvcg0KPiA+PiA+PiAgICB3aGVuIElQdjYgbmV0d29yayBpcyB1c2Vk ICh3aXRoIG9yIHdpdGhvdXQgSVB2NCkuIFRoaXMgZG9jdW1lbnQNCj4gPj4gPj4gICAgdXBkYXRl cyBSRkMgNTAzNiBhbmQgUkZDIDY3MjAuDQo+ID4+ID4+DQo+ID4+ID4+IFRoZSBmaWxlIGNhbiBi ZSBvYnRhaW5lZCB2aWENCj4gPj4gPj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYvDQo+ID4+ID4+DQo+ID4+ID4+IElFU0cgZGlzY3Vzc2lv biBjYW4gYmUgdHJhY2tlZCB2aWENCj4gPj4gPj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYvYmFsbG90Lw0KPiA+PiA+Pg0KPiA+PiA+Pg0K PiA+PiA+PiBObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkg b24gdGhpcyBJLUQuDQo+ID4+ID4+DQo+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+ID4+ IG1wbHNAaWV0Zi5vcmcNCj4gPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo+ID4+ID4NCj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+ID5tcGxzIG1haWxpbmcgbGlzdA0KPiA+PiA+bXBsc0BpZXRm Lm9yZw0KPiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ ID4NCg0K From nobody Mon Jan 12 09:26:00 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F371ACD11; Mon, 12 Jan 2015 09:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrKf0YJ3HAW6; Mon, 12 Jan 2015 09:25:50 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9133E1ACD07; Mon, 12 Jan 2015 09:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55120; q=dns/txt; s=iport; t=1421083549; x=1422293149; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FQQvrI5PVZTTT19ctfk2ztVMQXbLroY1ic1DnxzBWZs=; b=lQFC/cRB14Synsrgv2BtA+k/4js80bx2aMe3XBfo1gxcPTr6X5M+Knci 7KTnJGVVH2H2ht7uMAySvGePMoOddhLAMXvAtQGqgBtq9N59HILSrHwBK ydNvA6+gNYxru1JDRMzMBKzgyeztvoE/O0/pWuMPFwI+8z57nH9DuavZa c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMGAEoCtFStJA2G/2dsb2JhbABbgkNDUlyDAbNbjTmBRhkBCYVxAhx0QwEBAQEBfYQMAQEBAwEBAQEXCUsLBQcEAgEIEQMBAQEhAQIEAwICAiULFAkIAgQBDQWIJAgNuRmTUAEBAQEBAQEBAQEBAQEBAQEBAQEBARePNxcQCg0EBwaCYoFBBYxigVuDRYVIgQ8wgkKKPYM6IoIygTxvgQVAfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,744,1413244800"; d="scan'208,217";a="386325646" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 12 Jan 2015 17:25:48 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t0CHPlQ0032674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 17:25:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 11:25:47 -0600 From: "Rajiv Asati (rajiva)" To: "Aissaoui, Mustapha (Mustapha)" , "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCq3X4CABH7I4IAAgi6AgAPeSVCAADCVAA== Date: Mon, 12 Jan 2015 17:25:47 +0000 Message-ID: References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D947CA71B@US70UWXCHMBA04.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D947CC61C@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947CC61C@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.252.59] Content-Type: multipart/alternative; boundary="_000_D0D964582499DErajivaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 17:25:56 -0000 --_000_D0D964582499DErajivaciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBNdXN0YXBoYS4NCg0KLS0NCkNoZWVycywNClJhaml2IEFzYXRpDQpEaXN0aW5ndWlz aGVkIEVuZ2luZWVyLCBDaXNjbw0KDQpGcm9tOiA8QWlzc2FvdWk+LCBNdXN0YXBoYSBBaXNzYW91 aSA8bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzptdXN0YXBoYS5h aXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20+Pg0KRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDEyLCAy MDE1IGF0IDEwOjUyIEFNDQpUbzogUmFqaXYgQXNhdGkgPHJhaml2YUBjaXNjby5jb208bWFpbHRv OnJhaml2YUBjaXNjby5jb20+PiwgSUVURiBEaXNjdXNzaW9uIDxpZXRmQGlldGYub3JnPG1haWx0 bzppZXRmQGlldGYub3JnPj4sIElFVEYtQW5ub3VuY2UgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8 bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6ICJtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPiIgPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYt MTQudHh0PiAoVXBkYXRlcyB0byBMRFAgZm9yIElQdjYpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoN CkhpIFJhaml2LA0KSSBhbSBnb29kIHdpdGggeW91ciByZXNwb25zZSBiZWxvdy4gVGhhbmtzIQ0K DQpNdXN0YXBoYS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJhaml2IEFz YXRpIChyYWppdmEpIFttYWlsdG86cmFqaXZhQGNpc2NvLmNvbV0NClNlbnQ6IEZyaWRheSwgSmFu dWFyeSAwOSwgMjAxNSAxMDoyOCBQTQ0KVG86IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEp OyBpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPjsgSUVURi1Bbm5vdW5jZQ0KQ2M6 IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNd IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0xNC50eHQ+IChVcGRhdGVzIHRv IExEUCBmb3INCklQdjYpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQpIaSBNdXN0YXBoYSwNClRoYW5r cyBmb3IgdGhlIGNsYXJpdHkuDQoxLiBZb3UgaGF2ZSBhIGZhaXIgcG9pbnQuIFdoaWxlIGl0IGlz IGltcGxpY2l0IHRoYXQgc2VjdGlvbiAyLjUuNSBvZiBSRkMNCjUwMzYgKG1haW50YWluaW5nIGhl bGxvIGFkaikgd291bGQgYXBwbHksIGl0IGlzIHJlYXNvbmFibGUgdG8gbWFrZSBpdCBleHBsaWNp dC4gV2UNCmNhbiBhZGQgdGhlIGJlbG93IHRleHQgLQ0KLy9BIER1YWwtc3RhY2sgTFNSIE1VU1Qg c3RpbGwgZm9sbG93IHNlY3Rpb24gMi41LjUgb2YgUkZDNTAzNiBhbmQgY2hlY2sgZm9yDQptYXRj aGluZyBIZWxsbyBtZXNzYWdlcyBmcm9tIHRoZSBwZWVyIChlaXRoZXIgYWxsIEhlbGxvcyBhbHNv IGluY2x1ZGUgdGhlIER1YWwtDQpzdGFjayBjYXBhYmlsaXR5ICh3aXRoIHNhbWUgVFIgdmFsdWUp IG9yIG5vbmUgZG8pLi8vDQoyLiBUaGlzIGlzIGFscmVhZHkgY292ZXJlZCBpbiBib3RoIDNhIGFu ZCAzYiBieSB0aGUgZm9sbG93aW5nIHZlcmJpYWdlICJIb3dldmVyLCBpZg0KSVB2NiBoZWxsb3Mg YXJlIGFsc28gcmVjZWl2ZWQgYXQgYW55IHRpbWUgZnJvbSB0aGF0IG5laWdoYm9yLi7igJ0gaW4g dGhlIGJlZ2lubmluZyBvZg0KMm5kIHBhcmEuIE5vdGUgImF0IGFueSB0aW1l4oCdIGhlcmUuDQpU aGUgdGV4dCBpcyBzdWZmaWNpZW50LCBJTUhPLg0KMy4gQ2xvc2VkLg0KNC41LiBPay4gVGhlIGZv bGxvd2luZyAiKGV2ZW4gaWYgSVAgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBmb3IgSVB2NiBhZGRy ZXNzIGZhbWlseQ0Kd2FzIGRvbmUp4oCdIGlzIGFwcGVuZGVkIHRvIG1ha2UgaXQgZXhwbGljaXQu IEFuZCBUaGFua3MgZm9yIGNhdGNoaW5nIHRoZSBjb3B5LQ0KcGFzdGUgZXJyb3IuIDopIEZpeGVk Lg0KQ2xvc2VkLg0KLS0NCkNoZWVycywNClJhaml2IEFzYXRpDQpEaXN0aW5ndWlzaGVkIEVuZ2lu ZWVyLCBDaXNjbw0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IDxBaXNzYW91aT4s IE11c3RhcGhhIEFpc3Nhb3VpIDxtdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb208 bWFpbHRvOm11c3RhcGhhLmFpc3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbT4+DQpEYXRlOiBGcmlk YXksIEphbnVhcnkgOSwgMjAxNSBhdCA2OjE5IFBNDQpUbzogUmFqaXYgQXNhdGkgPHJhaml2YUBj aXNjby5jb208bWFpbHRvOnJhaml2YUBjaXNjby5jb20+PiwgSUVURiBEaXNjdXNzaW9uIDxpZXRm QGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPj4sDQpJRVRGLUFubm91bmNlIDxpZXRmLWFu bm91bmNlQGlldGYub3JnPG1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnPj4NCkNjOiAibXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzpt cGxzQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0 Zi1tcGxzLWxkcC1pcHY2LTE0LnR4dD4gKFVwZGF0ZXMNCnRvIExEUCBmb3IgSVB2NikgdG8gUHJv cG9zZWQgU3RhbmRhcmQNCj5IaSBSYWppdiwNCj5UaGFua3MgZm9yIHRoZSByZXBseS4gSSBhZGRl ZCBzb21lIGZvbGxvdy11cCBpbmxpbmUgYmVsb3cuDQo+DQo+UmVnYXJkcywNCj5NdXN0YXBoYS4N Cj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBSYWppdiBBc2F0aSAo cmFqaXZhKSBbbWFpbHRvOnJhaml2YUBjaXNjby5jb21dDQo+PiBTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDA2LCAyMDE1IDY6MDMgUE0NCj4+IFRvOiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhh KTsgaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz47IElFVEYtQW5ub3VuY2UNCj4+ IENjOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6 IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYtMTQudHh0Pg0KPj4o VXBkYXRlcyB0byBMRFAgZm9yDQo+PiBJUHY2KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPj4NCj4+ IEhpIE11c3RhcGhhLA0KPj4NCj4+ID4gSGF2aW5nIHNhaWQgdGhhdCwgSSB3YW50IHRvIGtlZXAg dGhlIHNwaXJpdCBvZiBjb29wZXJhdGlvbiBhbmQgbWFrZQ0KPj4gPnN1cmUgd2UgZ2V0IHRoaXMg IGRyYWZ0IHB1Ymxpc2hlZC4gVG8gdGhhdCBlZmZlY3QsIEkgYW0gbm90IG9wcG9zZWQgdG8NCj4+ ID5pdHMgcHVibGljYXRpb24gYXMgbG9uZyBhcyB0aGUgIGZvbGxvd2luZyBwb2ludHMgYXJlIGNs YXJpZmllZCBpbiB0aGUNCj4+ID5kcmFmdCBzaW5jZSBub3cgRkVDIGNhcGFiaWxpdHkgb2YgdGhl IExTUiBwZWVyIGlzICBkZXRlcm1pbmVkIGJ5IGENCj4+ID5jaGVjayBhIGJvdGggYWRqYWNlbmN5 IGFuZCBzZXNzaW9uIGxldmVsczoNCj4+DQo+PiBUaGFua3MgZm9yIHBvaW50aW5nIG91dCB0aGUg YmVsb3cgc2NlbmFyaW9zLiBXZSB0aGluayB0aGF0IGFsbCBidXQgb25lDQo+PmFyZSBlaXRoZXIN Cj4+IGNvdmVyZWQgb3IgcmVxdWlyZSBlZGl0b3JpYWwgY2hhbmdlcy4NCj4+DQo+Pg0KPj4gMS4g VGhpcyBzY2VuYXJpbyAoc2VuZGluZyBoZWxsb3Mgd2l0aCBEUyBjYXBhYmlsaXR5IG9uIGZld2Vy IGludGVyZmFjZXMNCj4+Zm9yIGEgcGVlcikNCj4+IGRvZXMgTk9UIGxvb2sgcmVhbGlzdGljLCBz aW5jZSBoaXRsZXNzIHVwZ3JhZGluZyBhIHJvdXRlciB3b3VsZCByZXN1bHQNCj4+aW4gc2VuZGlu Zw0KPj4gdjQrdjYgaGVsbG9zIGVpdGhlciB3aXRoIERTIGNhcGFiaWxpdHkgb3Igd2l0aG91dCBE UyBjYXBhYmlsaXR5IChmb3IgYQ0KPj5EUyBwZWVyLA0KPj4gYXNzdW1pbmcgdGhlIHBlZXIgd2Fz IGVuYWJsZWQgZm9yIERTIExEUCwgZGVmYXVsdCBvciBub3QsIGluIGFuDQo+PmltcGxlbWVudGF0 aW9uKS4NCj4+DQo+PiBQZXJoYXBzLCB5b3UgaGFkIGEgZGlmZmVyZW50IHNjZW5hcmlvIGluIG1p bmQuDQo+TUE+IFRoaXMgY291bGQgb2NjdXIgZHVyaW5nIGEgaGl0bGVzcyB1cGdyYWRlIGZvciBI ZWxsbyBhZGphY2VuY2llcyBmcm9tDQo+ZGlmZmVyZW50IGxpbmUgY2FyZHMgZHVyaW5nIGEgdHJh bnNpZW50IHRpbWUuIEkgd2lsbCBub3QgaW5zaXN0IG9uIHRoaXMNCj5wb2ludCBidXQgSSBmb3Vu ZCB0aGUgZHJhZnQgbGFja3Mgd2hhdCBhY3Rpb24gdG8gdGFrZSBpZiB0aGUgSGVsbG8NCj5tZXNz YWdlcyByZWNlaXZlZCBvbiBwYXJhbGxlbCBsaW5rcyBmcm9tIHRoZSBzYW1lIExTUiBhcmUgbm90 IGNvbnNpc3RlbnQsDQo+bWVhbmluZyB0aGV5IGhhdmUgZGlmZmVyZW50IFRSIHZhbHVlcyBvciB0 aGUgbWVzc2FnZSBvbiBvbmUgbGluayBkbyBub3QNCj5oYXZlIHRoZSBEUyBjYXBhYmlsaXR5LiBU aGUgb25seSB0aGluZyBJIGZvdW5kIGlzIHRoaXMgcGFyYWdyYXBoIGluDQo+U2VjdGlvbiA2LjEu MSBidXQgaXQgZG9lcyBub3Qgc2F5IHdoYXQgdG8gZG8gaWYgYW4gTFNSIHJlY2VpdmVzDQo+aW5j b25zaXN0ZW50IEhlbGxvIG1lc3NhZ2VzOg0KPiINCj5BbiBMU1IgTVVTVCBjb252ZXkgdGhlIHNh bWUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gcHJlZmVyZW5jZSAoIlRSIg0KPiAgIGZpZWxkIHZhbHVl KSBpbiBhbGwgKGxpbmsgYW5kIHRhcmdldGVkKSBIZWxsb3MgdGhhdCBhZHZlcnRpc2UgdGhlDQo+ ICAgc2FtZSBsYWJlbCBzcGFjZSB0byB0aGUgc2FtZSBwZWVyIGFuZC9vciBvbiBzYW1lIGludGVy ZmFjZS4gIFRoaXMNCj4gICBlbnN1cmVzIHRoYXQgdHdvIExTUnMgbGlua2VkIGJ5IG11bHRpcGxl IEhlbGxvIGFkamFjZW5jaWVzIHVzaW5nIHRoZQ0KPiAgIHNhbWUgbGFiZWwgc3BhY2VzIHBsYXkg dGhlIHNhbWUgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IHJvbGUgZm9yDQo+ICAgZWFjaCBhZGph Y2VuY3kuDQo+Ig0KPg0KPj4gMi4gWWVzLiBUaGlzIHNjZW5hcmlvIGlzIHdlbGwgY292ZXJlZCBp biBzZWN0aW9uIDYuMS4xIHBvaW50IzMuDQo+Pg0KPj4NCj4+IC8vDQo+PiAgICAgIDMuIElmICJE dWFsLXN0YWNrIGNhcGFiaWxpdHkiIFRMViBpcyBOT1QgcHJlc2VudCwgYW5kDQo+Pg0KPj4gxaAN Cj4+ICAgICAgICAgICAgICByZXN1bHRpbmcgaW4gYW55IGVzdGFibGlzaGVkIExEUG9JUHY0IHNl c3Npb24gYmVpbmcgcmVzZXQNCj4+ICAgICAgICAgICAgICBhbmQgYSBmYXRhbCBOb3RpZmljYXRp b24gbWVzc2FnZSBiZWluZyBzZW50ICh3aXRoIHN0YXR1cw0KPj4NCj4+IMWgDQo+Pg0KPj4gLy8N Cj5NQT4gV2hhdCBJIHdhcyB0YWxraW5nIGFib3V0IGlzIGEgdHJhbnNpdGlvbiBmcm9tIHN0YXRl IDJhIHRvIHN0YXRlIDNhIG9yDQo+ZnJvbSBzdGF0ZSAyYiB0byBzdGF0ZSAzYiBpbiBTZWN0aW9u IDYuMS4xLiBQZXJoYXBzIG9uZSB3YXkgdG8gZXhwbGljaXRseQ0KPnN0YXRlIHRoYXQgdGhlIHNl c3Npb24gaXMgYm91bmNlZCB3b3VsZCBiZSB0byBhZGQgc29tZXRoaW5nIGxpa2UgdGhpcyB0bw0K Pml0ZW1zIDJhIGFuZCAyYiBvZiBTZWN0aW9uIDYuLjEuMToNCj4iDQo+Mi4gSWYgIkR1YWwtc3Rh Y2sgY2FwYWJpbGl0eSIgVExWIGlzIHByZXNlbnQsIGFuZCByZW1vdGUNCj4gICAgICAgIHByZWZl cmVuY2UgbWF0Y2hlcyB3aXRoIHRoZSBsb2NhbCBwcmVmZXJlbmNlLCB0aGVuOg0KPg0KPiAgICAg ICAgICBhKSBJZiBUUj0wMTAwIChMRFBvSVB2NCksIHRoZW4gZGV0ZXJtaW5lIHRoZSBhY3RpdmUv cGFzc2l2ZQ0KPiAgICAgICAgICAgICByb2xlcyBmb3IgVENQIGNvbm5lY3Rpb24gdXNpbmcgSVB2 NCB0cmFuc3BvcnQgYWRkcmVzcyBhcw0KPiAgICAgICAgICAgICBkZWZpbmVkIGluIHNlY3Rpb24g Mi41LjIgb2YgUkZDIDUwMzYuDQo+DQo+ICAgICAgICAgIGIpIElmIFRSPTAxMTAgKExEUG9JUHY2 KSwgdGhlbiBkZXRlcm1pbmUgdGhlIGFjdGl2ZS9wYXNzaXZlDQo+ICAgICAgICAgICAgIHJvbGVz IGZvciBUQ1AgY29ubmVjdGlvbiBieSB1c2luZyBJUHY2IHRyYW5zcG9ydCBhZGRyZXNzDQo+ICAg ICAgICAgICAgIGFzIGRlZmluZWQgaW4gc2VjdGlvbiAyLjUuMiBvZiBSRkMgNTAzNi4NCj4gICAq SWYgc3Vic2VxdWVudGx5IHRvIGVzdGFibGlzaGluZyB0aGUgTERQIHNlc3Npb24sIHRoZSBIZWxs byBtZXNzYWdlcw0KPmZyb20gdGhlIHBlZXINCj4gICBkbyBub3QgaW5jbHVkZSB0aGUgRHVhbC1z dGFjayBjYXBhYmlsaXR5IFRMViwgdGhlIHNlc3Npb24gaXMNCj50ZXJtaW5hdGVkIGFuZCBhIGZh dGFsIE5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHNlbnQgd2l0aCAgICAgc3RhdHVzIGNvZGUNCj5v ZiAnRHVhbC1TdGFjayBOb24tQ29tcGxpYW5jZScgKElBTkEgYWxsb2NhdGlvbiBUQkQpLioNCj4i DQo+DQo+DQo+Pg0KPj4gMy4gWWVzICh0byB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IpLiBUaGlzIGlz IHNvbWV3aGF0IGNvdmVyZWQgaW4gYnVsbGV0DQo+PiMxIGluIHNlY3Rpb24NCj4+IDYuMS4xLCBi dXQgd2UgY2FuIG1ha2UgaXQgZXhwbGljaXQgYnkgYWRkaW5nICJvciBkb2VzIG5vdCBnZXQNCj4+ cmVjb2duaXplZMKyIGFzIGJlbG93Og0KPj4NCj4+DQo+PiBPTEQ6DQo+PiBJZiAiRHVhbC1zdGFj ayBjYXBhYmlsaXR5IiBUTFYgaXMgcHJlc2VudCBhbmQgcmVtb3RlIHByZWZlcmVuY2UgZG9lcw0K Pj5ub3QgbWF0Y2gNCj4+IHdpdGggdGhlIGxvY2FsIHByZWZlcmVuY2UsLi4NCj4+DQo+Pg0KPj4g TkVXOg0KPj4gSWYgIkR1YWwtc3RhY2sgY2FwYWJpbGl0eSIgVExWIGlzIHByZXNlbnQgYW5kIHJl bW90ZSBwcmVmZXJlbmNlIGRvZXMNCj4+bm90IG1hdGNoDQo+PiB3aXRoIHRoZSBsb2NhbCBwcmVm ZXJlbmNlIChvciBkb2VzIG5vdCBnZXQgcmVjb2duaXplZCksLi4NCj5NQT4gWW91ciBwcm9wb3Nl ZCBtb2RpZmljYXRpb24gZG9lcyBhZGRyZXNzIHRoaXMgY29tbWVudC4gVGhhbmsgeW91Lg0KPg0K Pg0KPj4gNCBhbmQgNS4gWWVzICh0byB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IpLiBJdCBpcyBpbXBs aWNpdCBpbiBzZWN0aW9uIDcuMg0KPj5wYXJhIDQuDQo+Pg0KPj4gLy8uLg0KPj4gIEFuIExTUiBN QVkgZnVydGhlciBjb25zdHJhaW4gdGhlIGFkdmVydGlzZW1lbnQgb2YgRkVDLWxhYmVsIGJpbmRp bmdzDQo+PmZvciBhDQo+PiBwYXJ0aWN1bGFyIGFkZHJlc3MgZmFtaWx5IGJ5IG5lZ290aWF0aW5n IHRoZSBJUCBDYXBhYmlsaXR5Li4uLy8NCj4+DQo+PiBBcmUgeW91IHN1Z2dlc3RpbmcgdG8gbWFr ZSBpdCBleHBsaWNpdD8NCj5NQT4gWWVzIEkgd2FudGVkIHNvbWV0aGluZyBtb3JlIGV4cGxpY2l0 LiBUaGlzIHNlY3Rpb24gY2VydGFpbmx5IHNheXMgdGhlDQo+SVB2NiBwcmVmaXggRkVDIGNhcGFi aWxpdHkgY2FuIGZ1cnRoZXIgY29uc3RyYWluIGEgcGFydGljdWxhciBGRUMgdHlwZQ0KPndoaWNo IGlzIGFsbG93ZWQgYnkgdGhlIGNoZWNrIG9mIHRoZSBEUyBjYXBhYmlsaXR5IFRMVi4gSXQgaG93 ZXZlciBkb2VzDQo+bm90IGRpc2N1c3MgdGhlIG5lZ2F0aXZlIGNhc2UsIGkuZS4sIHRoZSBEUyBj YXBhYmlsaXR5IFRMViBkaWQgbm90IGFsbG93DQo+YSBGRUMgdHlwZSBidXQgdGhlIElQIGNhcGFi aWxpdHkgYWxsb3dlZCBpdC4NCj5JIGJlbGlldmUgdGhlIGZvbGxvd2luZyBhZGRpdGlvbiB0byBh biBlYXJsaWVyIHBhcmFncmFwaCBpbiBTZWN0aW9uIDcuMg0KPndvdWxkIGhlbHAgY2xhcmlmeSB0 aGlzOg0KPiINCj5JZiBhbiBMU1IgZW5hYmxlZCB3aXRoIER1YWwtc3RhY2sgTERQIGZvciBhIHBl ZXIgYW5kDQo+DQo+ICAgICAxLiBJcyBOT1QgYWJsZSB0byBmaW5kIHRoZSBEdWFsLXN0YWNrIGNh cGFiaWxpdHkgVExWIGluIHRoZQ0KPiAgICAgICAgaW5jb21pbmcgSVB2NCBMRFAgaGVsbG8gbWVz c2FnZXMgZnJvbSB0aGF0IHBlZXIsIHRoZW4gdGhlIExTUg0KPiAgICAgICAgTVVTVCBOT1QgYWR2 ZXJ0aXNlIElQdjYgRkVDLWxhYmVsIGJpbmRpbmdzIHRvIHRoZSBwZWVyICpldmVuIGlmDQo+aXQg cmVjZWl2ZWQgYW4gSVAgY2FwYWJpbGl0eQ0KPiAgICAgICAgZnJvbSB0aGUgcGVlciBpbmRpY2F0 aW5nIHRoZSBlbmFibGluZyBvZiB0aGUgSVB2NiBGRUMgdHlwZSouDQo+Ig0KPkJUVywgdGhlcmUg aXMgYSAiY29weSAmIHBhc3RlIiBtaXN0YWtlIGluIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIGlu IHRoZQ0KPnNhbWUgU2VjdGlvbiA3LjIuIFRoZSAidmlhIEFERFJFU1MgbWVzc2FnZSIgaXMgbm90 IGNvcnJlY3QgaGVyZSBzaW5jZQ0KPnRoaXMgaXMgYWJvdXQgRkVDIGRpc3RyaWJ1dGlvbiwgaGVu Y2UgTGFiZWwgTWFwcGluZyBtZXNzYWdlLCBhbmQgbm90DQo+YWRkcmVzcyBkaXN0cmlidXRpb24u DQo+Ig0KPklmIGFuIExTUiBpcyBlbmFibGVkIHdpdGggU2luZ2xlLXN0YWNrIExEUCBmb3IgYW55 IHBlZXIsIHRoZW4gaXQNCj4gICBNVVNUIGFkdmVydGlzZSAodmlhIEFERFJFU1MgbWVzc2FnZSkg RkVDLUxhYmVsIGJpbmRpbmdzIGZvciB0aGUNCj4gICBlbmFibGVkIGFkZHJlc3MgZmFtaWx5LCBh bmQgYWNjZXB0IEZFQy1MYWJlbCBiaW5kaW5ncyBmb3IgdGhlDQo+ICAgZW5hYmxlZCBhZGRyZXNz IGZhbWlseS4NCj4iDQo+DQo+PiAtLQ0KPj4gQ2hlZXJzLA0KPj4gUmFqaXYgQXNhdGkNCj4+IERp c3Rpbmd1aXNoZWQgRW5naW5lZXIsIENpc2NvDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiA8QWlzc2FvdWk+LCBNdXN0YXBoYSBBaXNz YW91aQ0KPj48bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzptdXN0 YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20+Pg0KPj4gRGF0ZTogVHVlc2RheSwgRGVj ZW1iZXIgMTYsIDIwMTQgYXQgMTI6MjEgUE0NCj4+IFRvOiBJRVRGIERpc2N1c3Npb24gPGlldGZA aWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+PiwgSUVURi1Bbm5vdW5jZQ0KPj48aWV0Zi1h bm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4+DQo+PiBDYzog Im1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4+DQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRy YWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0xNC50eHQ+DQo+PihVcGRhdGVzDQo+PiB0byBMRFAgZm9y IElQdjYpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+Pg0KPj4gPkhpIEFkcmlhbiBhbmQgYWxsLA0K Pj4gPkkgd2FzIHRoZSBvbmUgd2hvIHJhaXNlZCB0aGUgaW50ZXJvcCBpc3N1ZXMgd2UgZm91bmQg d2hpbGUgdGVzdGluZyBvdXINCj4+ID5pbXBsZW1lbnRhdGlvbiBvZiBMRFAgSVB2NiBhZ2FpbnN0 IGV4aXN0aW5nIGFuZCBkZXBsb3llZA0KPj5pbXBsZW1lbnRhdGlvbnMuDQo+PiA+SSBwcm9wb3Nl ZCBhIHNpbXBsZSBtZXRob2Qgb2YgdXNpbmcgdGhlIGV4aXN0aW5nIEZFQyBhZHZlcnRpc2VtZW50 DQo+PiA+Y2FwYWJpbGl0eSBhdCB0aGUgc2Vzc2lvbiBsZXZlbCBhcyBhIHdheSBmb3IgYW4gTFNS IHRvIGRldGVjdCBpZiBhbg0KPj4gPmltcGxlbWVudGF0aW9uIHN1cHBvcnQgTERQIElQdjYgRkVD cyBhbmQgSVB2NiBhZGRyZXNzZXMuIFRoaXMgZXhpc3RpbmcNCj4+ID5GRUMgYWR2ZXJ0aXNlbWVu dCBjYXBhYmlsaXR5IGF0IHNlc3Npb24gbGV2ZWwgaXMgZGVmaW5lZCBpbg0KPj4gPmRyYWZ0LWll dGYtbXBscy1sZHAtaXAtcHctY2FwYWJpbGl0eS0wOCBidXQgd2l0aCB0aGUgbGltaXRhdGlvbiB0 aGF0IGl0DQo+PiA+Y2FuIGJlIHVzZWQgb25seSB0byBkaXNhYmxlIHN1cHBvcnQgb2YgSVB2NiBG RUNzIGluIExEUCBJbml0aWFsaXphdGlvbg0KPj4gPk1lc3NhZ2U7IHdlIHByb3Bvc2VkIHRvIGdl bmVyYWxpemUgdGhlIG1ldGhvZCB0byBhbHNvIGluZGljYXRlIGV4cGxpY2l0DQo+PiA+c3VwcG9y dCBmb3IgSVB2NiBGRUNzIGFuZCBJUHY2IEFkZHJlc3NlcyBpbiBMRFAgSW5pdGlhbGl6YXRpb24g TWVzc2FnZS4NCj4+ID5UaGlzIG1ldGhvZCBpcyBzYWZlIGFuZCB3YXMgYWxzbyB1c2VkIHdpdGgg bUxEUCBQMk1QIGFuZCBNUDJNUCBGRUNzDQo+PiB3aGVuDQo+PiA+dGhleSB3ZXJlIGludHJvZHVj ZWQuIFRoZSBpbnRlbnQgaGVyZSBpcyB0aGF0IGFsbCBzZXNzaW9uIGxldmVsDQo+PiA+Y2FwYWJp bGl0aWVzIGluIExEUCBzaG91bGQgZm9sbG93IFJGQyA1NTYxIGFwcHJvYWNoLg0KPj4gPg0KPj4g PlRoZXJlIHdhcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yIHdoaWNoIHN1cHBvcnRlZCB0aGUg cHJvcG9zYWwgb24gdGhlDQo+PiA+bWFpbGluZyBsaXN0IGJ1dCB0aGUgYXV0aG9ycyBjaG9zZSB0 byBpZ25vcmUgaXQgYW5kIHdlbnQgd2l0aCBhDQo+PnByb3Bvc2FsDQo+PiA+d2hpY2ggb3Zlcmxv YWRlZCB0aGUgbWVhbmluZyBvZiB0aGUgZHVhbC1zdGFjayBjYXBhYmlsaXR5IFRMVi4NCj4+UmVn YXJkbGVzcw0KPj4gPm9mIHRoZSBtZXJpdCBvZiBlaXRoZXIgbWV0aG9kLCB0aGUgZGlzY3Vzc2lv biBvbiB0aGUgTVBMUyBtYWlsaW5nIGxpc3QNCj4+ID53YXMgbm90IGNsb3NlZCBwcm9wZXJseSBm cm9tIG15IHBlcnNwZWN0aXZlLg0KPj4gPg0KPj4gPk5vdyBoZXJlIGlzIHRoZSBjb25jZXJuIEkg cmFpc2VkIHdpdGggdXNpbmcgdGhlIGR1YWwtc3RhY2sgY2FwYWJpbGl0eS4NCj4+ID5Ob3Qgb25s eSB0aGlzIFRMViBpcyBhbiBhZGphY2VuY3kgbGV2ZWwgZmVhdHVyZSB3aGljaCBpcyBoYXMgbm90 aGluZyB0bw0KPj4gPmRvIHdpdGggRkVDIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCwgYnV0IGl0 IGlzIGludHJvZHVjaW5nIGNvbXBsZXhpdHkNCj4+aW4NCj4+ID50aGUgaW1wbGVtZW50YXRpb24g d2hpY2ggbm93IGhhcyB0byBjaGVjayBkdWFsLXN0YWNrIGNhcGFiaWxpdHkgZm9yDQo+PiA+KmVh Y2gqIGFkamFjZW5jeSB0byB0aGUgcGVlciAqYW5kKiB0aGUgc2Vzc2lvbiBsZXZlbCBGRUMgY2Fw YWJpbGl0eSB0bw0KPj4gPmRlY2lkZSB3aGF0IHRoZSBwZWVyIGlzIGNhcGFibGUgb2YgYXQgdGhl ICpzZXNzaW9uIGxldmVsKi4NCj4+ID4NCj4+ID5IYXZpbmcgc2FpZCB0aGF0LCBJIHdhbnQgdG8g a2VlcCB0aGUgc3Bpcml0IG9mIGNvb3BlcmF0aW9uIGFuZCBtYWtlDQo+PnN1cmUNCj4+ID53ZSBn ZXQgdGhpcyBkcmFmdCBwdWJsaXNoZWQuIFRvIHRoYXQgZWZmZWN0LCBJIGFtIG5vdCBvcHBvc2Vk IHRvIGl0cw0KPj4gPnB1YmxpY2F0aW9uIGFzIGxvbmcgYXMgdGhlIGZvbGxvd2luZyBwb2ludHMg YXJlIGNsYXJpZmllZCBpbiB0aGUgZHJhZnQNCj4+ID5zaW5jZSBub3cgRkVDIGNhcGFiaWxpdHkg b2YgdGhlIExTUiBwZWVyIGlzIGRldGVybWluZWQgYnkgYSBjaGVjayBhDQo+PmJvdGgNCj4+ID5h ZGphY2VuY3kgYW5kIHNlc3Npb24gbGV2ZWxzOg0KPj4gPg0KPj4gPjEuIFRoZSBkcmFmdCBpcyBt aXNzaW5nIHRoZSBiZWhhdmlvciB3aGVuIG11bHRpcGxlIGFkamFjZW5jaWVzIGV4aXN0IHRvDQo+ PiA+dGhlIHNhbWUgTFNSIGFuZCB0aGUgcGVlciBMU1IgYWR2ZXJ0aXNlZCB0aGUgZHVhbC1zdGFj ayBjYXBhYmlsaXR5IG9ubHkNCj4+ID5vdmVyIGEgc3Vic2V0IG9mIHRoZXNlIEhlbGxvIGFkamFj ZW5jaWVzLg0KPj4gPkkgYXNzdW1lIGhlcmUgdGhlIHBlZXIgTFNSIGlzIGNvbnNpZGVyZWQgdG8g YmUgZHVhbC1zdGFjayBjYXBhYmxlIGFzDQo+PnNvb24NCj4+ID5hcyBhbnkgb2YgdGhlIEhlbGxv IGFkamFjZW5jaWVzIGluY2x1ZGVzIHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkuDQo+PlRoaXMN Cj4+ID53b3VsZCBhbGxvdyBhIGhpdGxlc3MgdXBncmFkZSBzY2VuYXJpbyBmcm9tIGFuIG9sZGVy IGltcGxlbWVudGF0aW9uIHRvDQo+PiA+b25lIHdoaWNoIGNvbXBsaWVzIHRvIHRoaXMgZHJhZnQN Cj4+ID4NCj4+ID4yLiBTaW1pbGFybHksIHdoYXQgd291bGQgYmUgdGhlIGJlaGF2aW9yIGlmIGEg aGVsbG8gYWRqYWNlbmN5IGNoYW5nZXMNCj4+ID5mcm9tIHNlbmRpbmcgdGhlIGR1YWwtc3RhY2sg Y2FwYWJpbGl0eSB0byBub3Qgc2VuZGluZyBpdD8gVGhpcyB3b3VsZCBiZQ0KPj4gPmZvciBleGFt cGxlIGluIGEgaGl0bGVzcyBkb3duZ3JhZGUgdG8gYSB2ZXJzaW9uIG9mIExEUCB3aGljaCBkb2Vz IG5vdA0KPj4gPmNvbXBseSB0byB0aGlzIGRyYWZ0Lg0KPj4gPkkgYXNzdW1lIGhlcmUgdGhhdCB0 aGUgc2Vzc2lvbiBtdXN0IGJlIGJvdW5jZWQgc2luY2UgdGhlIExTUnMgbmVlZCBhDQo+PiA+Y2xl YW4gc3RhdGUgdG8gbm90IHNlbmQgSVB2NiBhZGRyZXNzZXMgYW5kIElQdjYgRkVDcy4NCj4+ID4N Cj4+ID4zLiBUaGUgZG9jdW1lbnQgZGVmaW5lcyAyIHZhbHVlcyBmb3IgdGhlIGR1YWwtc3RhY2sg Y2FwYWJpbGl0eSBUUi4gSXQNCj4+ID5kb2VzIG5vdCBtZW50aW9uIHRoZSBiZWhhdmlvciB3aGVu IGFuIHVua25vd24gdmFsdWUgaXMgcmVjZWl2ZWQuDQo+PiA+V2lsbCB0aGF0IGJlIGNvbnNpZGVy ZWQgYSBmYXRhbCBlcnJvcj8NCj4+ID4NCj4+ID40LiBUaGUgZHJhZnQgaXMgbWlzc2luZyB0aGUg YmVoYXZpb3Igb2Ygd2hlbiB0aGUgcGVlciBMU1IgZG9lcyBub3QNCj4+ID5hZHZlcnRpc2UgdGhl IGR1YWwtc3RhY2sgY2FwYWJpbGl0eSBpbiBhbGwgdGhlIEhlbGxvIGFkamFjZW5jaWVzIGJ1dCBp dA0KPj4gPmFkdmVydGlzZWQgdGhlIGVuYWJsaW5nIG9yIGRpc2FibGluZyBvZiB0aGUgSVB2NiBw cmVmaXggRkVDIGNhcGFiaWxpdHkNCj4+aW4NCj4+ID50aGUgc2Vzc2lvbiBpbml0aWFsaXphdGlv biBtZXNzYWdlLg0KPj4gPkkgYXNzdW1lIGhlcmUgdGhhdCB0aGUgYWJzZW5jZSBvZiB0aGUgZHVh bC1zdGFjayBjYXBhYmlsaXR5IG92ZXJyaWRlcw0KPj5hbnkNCj4+ID5zZXNzaW9uIGxldmVsIElQ djYgRkVDIHByZWZpeCBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQuDQo+PiA+DQo+PiA+NS4gVGhl IGRyYWZ0IGlzIG1pc3NpbmcgdGhlIGJlaGF2aW9yIG9mIHdoZW4gdGhlIHBlZXIgTFNSIGRvZXMg bm90DQo+PiA+YWR2ZXJ0aXNlIHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkgaW4gYWxsIHRoZSBI ZWxsbyBhZGphY2VuY2llcyBidXQgaXQNCj4+ID5hZHZlcnRpc2VkIHRoZSBlbmFibGluZyBvZiB0 aGUgSVB2NiBwcmVmaXggRkVDIGNhcGFiaWxpdHkgaW4gdGhlDQo+PnNlc3Npb24NCj4+ID5DYXBh YmlsaXR5IG1lc3NhZ2UuDQo+PiA+SSBhc3N1bWUgdGhlIHNhbWUgYmVoYXZpb3IgYXMgaW4gKDQp IGFwcGxpZXMgaGVyZS4NCj4+ID4NCj4+ID5SZWdhcmRzLA0KPj4gPk11c3RhcGhhLg0KPj4gPg0K Pj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IG1wbHMgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaGUgSUVTRw0KPj4gPj4gU2Vu dDogVGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDI6MzcgUE0NCj4+ID4+IFRvOiBJRVRGLUFu bm91bmNlDQo+PiA+PiBDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+ ID4+IFN1YmplY3Q6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYt MTQudHh0PiAoVXBkYXRlcw0KPj4gPj50byBMRFAgZm9yIElQdjYpDQo+PiA+PiB0byBQcm9wb3Nl ZCBTdGFuZGFyZA0KPj4gPj4NCj4+ID4+DQo+PiA+PiBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSBy ZXF1ZXN0IGZyb20gdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwNCj4+U3dpdGNoaW5nDQo+PiA+PldH DQo+PiA+PiAobXBscykgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCj4+ID4+ IC0gJ1VwZGF0ZXMgdG8gTERQIGZvciBJUHY2Jw0KPj4gPj4gICA8ZHJhZnQtaWV0Zi1tcGxzLWxk cC1pcHY2LTE0LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCj4+ID4+DQo+PiA+PiBUaGUgSUVT RyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29s aWNpdHMNCj4+ID4+ZmluYWwNCj4+ID4+IGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ug c2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCj4+ID4+aWV0ZkBpZXRmLm9yZzxtYWls dG86aWV0ZkBpZXRmLm9yZz4NCj4+ID4+IG1haWxpbmcgbGlzdHMgYnkgMjAxNC0xMi0xOC4gRXhj ZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IGJlIHNlbnQgdG8NCj4+ID4+aWVzZ0BpZXRmLm9yZzxt YWlsdG86aWVzZ0BpZXRmLm9yZz4NCj4+ID4+IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVh c2UgcmV0YWluIHRoZSBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QNCj4+ID4+bGluZSB0byBhbGxv dw0KPj4gPj4gYXV0b21hdGVkIHNvcnRpbmcuDQo+PiA+Pg0KPj4gPj4gQWJzdHJhY3QNCj4+ID4+ DQo+PiA+PiAgICBUaGUgTGFiZWwgRGlzdHJpYnV0aW9uIFByb3RvY29sIChMRFApIHNwZWNpZmlj YXRpb24gZGVmaW5lcw0KPj4gPj4gICAgcHJvY2VkdXJlcyB0byBleGNoYW5nZSBsYWJlbCBiaW5k aW5ncyBvdmVyIGVpdGhlciBJUHY0LCBvciBJUHY2IG9yDQo+PiA+PiAgICBib3RoIG5ldHdvcmtz LiBUaGlzIGRvY3VtZW50IGNvcnJlY3RzIGFuZCBjbGFyaWZpZXMgdGhlIExEUA0KPj5iZWhhdmlv cg0KPj4gPj4gICAgd2hlbiBJUHY2IG5ldHdvcmsgaXMgdXNlZCAod2l0aCBvciB3aXRob3V0IElQ djQpLiBUaGlzIGRvY3VtZW50DQo+PiA+PiAgICB1cGRhdGVzIFJGQyA1MDM2IGFuZCBSRkMgNjcy MC4NCj4+ID4+DQo+PiA+PiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+PiA+PiBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni8NCj4+ ID4+DQo+PiA+PiBJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+PiA+PiBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni9iYWxs b3QvDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IE5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1 Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC4NCj4+ID4+DQo+PiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gbXBscyBtYWlsaW5nIGxp c3QNCj4+ID4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+PiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+ID4NCj4+ID5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPm1wbHMgbWFpbGlu ZyBsaXN0DQo+PiA+bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+ID5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4NCg0KDQo= --_000_D0D964582499DErajivaciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <97AAC34217DF424A9A505AB5B3A0FB69@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlRoYW5rcywgTXVzdGFwaGEuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+LS0mbmJzcDs8L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdj5SYWppdiBB c2F0aTwvZGl2Pg0KPGRpdj5EaXN0aW5ndWlzaGVkIEVuZ2luZWVyLCBDaXNjbzwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp emU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mbHQ7QWlzc2Fv dWkmZ3Q7LCBNdXN0YXBoYSBBaXNzYW91aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm11c3RhcGhhLmFp c3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbSI+bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNl bnQuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTog PC9zcGFuPk1vbmRheSwgSmFudWFyeSAxMiwgMjAxNSBhdCAxMDo1MiBBTTxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPlJhaml2IEFzYXRpICZsdDs8YSBocmVm PSJtYWlsdG86cmFqaXZhQGNpc2NvLmNvbSI+cmFqaXZhQGNpc2NvLmNvbTwvYT4mZ3Q7LCBJRVRG IERpc2N1c3Npb24gJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYu b3JnPC9hPiZndDssIElFVEYtQW5ub3VuY2UgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91 bmNlQGlldGYub3JnIj5pZXRmLWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiBbbXBsc10gTGFzdCBDYWxsOiAm bHQ7ZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTE0LnR4dCZndDsgKFVwZGF0ZXMgdG8gTERQIGZv ciBJUHY2KSB0byBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBz dHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJH SU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2PkhpIFJhaml2LDwvZGl2Pg0KPGRpdj5J IGFtIGdvb2Qgd2l0aCB5b3VyIHJlc3BvbnNlIGJlbG93LiBUaGFua3MhPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5NdXN0YXBoYS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJP UkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAw IDU7Ij4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+RnJvbTog UmFqaXYgQXNhdGkgKHJhaml2YSkgWzxhIGhyZWY9Im1haWx0bzpyYWppdmFAY2lzY28uY29tIj5t YWlsdG86cmFqaXZhQGNpc2NvLmNvbTwvYT5dPC9kaXY+DQo8ZGl2PlNlbnQ6IEZyaWRheSwgSmFu dWFyeSAwOSwgMjAxNSAxMDoyOCBQTTwvZGl2Pg0KPGRpdj5UbzogQWlzc2FvdWksIE11c3RhcGhh IChNdXN0YXBoYSk7IDxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYub3Jn PC9hPjsgSUVURi1Bbm5vdW5jZTwvZGl2Pg0KPGRpdj5DYzogPGEgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PlN1YmplY3Q6IFJlOiBbbXBs c10gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTE0LnR4dCZndDsgKFVw ZGF0ZXMgdG8gTERQIGZvcjwvZGl2Pg0KPGRpdj5JUHY2KSB0byBQcm9wb3NlZCBTdGFuZGFyZDwv ZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+SGkgTXVzdGFwaGEsPC9kaXY+DQo8ZGl2PjwvZGl2Pg0K PGRpdj5UaGFua3MgZm9yIHRoZSBjbGFyaXR5LjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+MS4g WW91IGhhdmUgYSBmYWlyIHBvaW50LiBXaGlsZSBpdCBpcyBpbXBsaWNpdCB0aGF0IHNlY3Rpb24g Mi41LjUgb2YgUkZDPC9kaXY+DQo8ZGl2PjUwMzYgKG1haW50YWluaW5nIGhlbGxvIGFkaikgd291 bGQgYXBwbHksIGl0IGlzIHJlYXNvbmFibGUgdG8gbWFrZSBpdCBleHBsaWNpdC4gV2U8L2Rpdj4N CjxkaXY+Y2FuIGFkZCB0aGUgYmVsb3cgdGV4dCAtPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4v L0EgRHVhbC1zdGFjayBMU1IgTVVTVCBzdGlsbCBmb2xsb3cgc2VjdGlvbiAyLjUuNSBvZiBSRkM1 MDM2IGFuZCBjaGVjayBmb3I8L2Rpdj4NCjxkaXY+bWF0Y2hpbmcgSGVsbG8gbWVzc2FnZXMgZnJv bSB0aGUgcGVlciAoZWl0aGVyIGFsbCBIZWxsb3MgYWxzbyBpbmNsdWRlIHRoZSBEdWFsLTwvZGl2 Pg0KPGRpdj5zdGFjayBjYXBhYmlsaXR5ICh3aXRoIHNhbWUgVFIgdmFsdWUpIG9yIG5vbmUgZG8p Li8vPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PjIu IFRoaXMgaXMgYWxyZWFkeSBjb3ZlcmVkIGluIGJvdGggM2EgYW5kIDNiIGJ5IHRoZSBmb2xsb3dp bmcgdmVyYmlhZ2UgJnF1b3Q7SG93ZXZlciwgaWY8L2Rpdj4NCjxkaXY+SVB2NiBoZWxsb3MgYXJl IGFsc28gcmVjZWl2ZWQgYXQgYW55IHRpbWUgZnJvbSB0aGF0IG5laWdoYm9yLi7igJ0gaW4gdGhl IGJlZ2lubmluZyBvZjwvZGl2Pg0KPGRpdj4ybmQgcGFyYS4gTm90ZSAmcXVvdDthdCBhbnkgdGlt ZeKAnSBoZXJlLjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+VGhlIHRleHQgaXMgc3VmZmljaWVu dCwgSU1ITy48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PjMuIENsb3NlZC48L2Rpdj4NCjxkaXY+ PC9kaXY+DQo8ZGl2PjQuNS4gT2suIFRoZSBmb2xsb3dpbmcgJnF1b3Q7KGV2ZW4gaWYgSVAgY2Fw YWJpbGl0eSBuZWdvdGlhdGlvbiBmb3IgSVB2NiBhZGRyZXNzIGZhbWlseTwvZGl2Pg0KPGRpdj53 YXMgZG9uZSnigJ0gaXMgYXBwZW5kZWQgdG8gbWFrZSBpdCBleHBsaWNpdC4gQW5kIFRoYW5rcyBm b3IgY2F0Y2hpbmcgdGhlIGNvcHktPC9kaXY+DQo8ZGl2PnBhc3RlIGVycm9yLiA6KSBGaXhlZC48 L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PkNsb3NlZC48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2 PjwvZGl2Pg0KPGRpdj4tLTwvZGl2Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8ZGl2PlJhaml2IEFz YXRpPC9kaXY+DQo8ZGl2PkRpc3Rpbmd1aXNoZWQgRW5naW5lZXIsIENpc2NvPC9kaXY+DQo8ZGl2 PjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48L2Rp dj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+RnJvbTogJmx0 O0Fpc3Nhb3VpJmd0OywgTXVzdGFwaGEgQWlzc2FvdWkgJmx0OzxhIGhyZWY9Im1haWx0bzptdXN0 YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20iPm11c3RhcGhhLmFpc3Nhb3VpQGFsY2F0 ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PkRhdGU6IEZyaWRheSwgSmFudWFyeSA5 LCAyMDE1IGF0IDY6MTkgUE08L2Rpdj4NCjxkaXY+VG86IFJhaml2IEFzYXRpICZsdDs8YSBocmVm PSJtYWlsdG86cmFqaXZhQGNpc2NvLmNvbSI+cmFqaXZhQGNpc2NvLmNvbTwvYT4mZ3Q7LCBJRVRG IERpc2N1c3Npb24gJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYu b3JnPC9hPiZndDssPC9kaXY+DQo8ZGl2PklFVEYtQW5ub3VuY2UgJmx0OzxhIGhyZWY9Im1haWx0 bzppZXRmLWFubm91bmNlQGlldGYub3JnIj5pZXRmLWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8 L2Rpdj4NCjxkaXY+Q2M6ICZxdW90OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxz QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1w bHNAaWV0Zi5vcmc8L2E+Jmd0OzwvZGl2Pg0KPGRpdj5TdWJqZWN0OiBSRTogW21wbHNdIExhc3Qg Q2FsbDogJmx0O2RyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0xNC50eHQmZ3Q7IChVcGRhdGVzPC9k aXY+DQo8ZGl2PnRvIExEUCBmb3IgSVB2NikgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8L2Rpdj4NCjxk aXY+PC9kaXY+DQo8ZGl2PiZndDtIaSBSYWppdiw8L2Rpdj4NCjxkaXY+Jmd0O1RoYW5rcyBmb3Ig dGhlIHJlcGx5LiBJIGFkZGVkIHNvbWUgZm9sbG93LXVwIGlubGluZSBiZWxvdy48L2Rpdj4NCjxk aXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7UmVnYXJkcyw8L2Rpdj4NCjxkaXY+Jmd0O011c3RhcGhh LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IEZyb206IFJhaml2IEFzYXRpIChyYWppdmEp IFs8YSBocmVmPSJtYWlsdG86cmFqaXZhQGNpc2NvLmNvbSI+bWFpbHRvOnJhaml2YUBjaXNjby5j b208L2E+XTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDA2LCAy MDE1IDY6MDMgUE08L2Rpdj4NCjxkaXY+Jmd0OyZndDsgVG86IEFpc3Nhb3VpLCBNdXN0YXBoYSAo TXVzdGFwaGEpOyA8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwv YT47IElFVEYtQW5ub3VuY2U8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgQ2M6IDxhIGhyZWY9Im1haWx0 bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBT dWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtbXBscy1sZHAtaXB2 Ni0xNC50eHQmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7KFVwZGF0ZXMgdG8gTERQIGZvcjwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyBJUHY2KSB0byBQcm9wb3NlZCBTdGFuZGFyZDwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBIaSBNdXN0YXBoYSw8L2Rpdj4NCjxkaXY+Jmd0 OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyBIYXZpbmcgc2FpZCB0aGF0LCBJIHdhbnQg dG8ga2VlcCB0aGUgc3Bpcml0IG9mIGNvb3BlcmF0aW9uIGFuZCBtYWtlPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7ICZndDtzdXJlIHdlIGdldCB0aGlzJm5ic3A7Jm5ic3A7ZHJhZnQgcHVibGlzaGVkLiBU byB0aGF0IGVmZmVjdCwgSSBhbSBub3Qgb3Bwb3NlZCB0bzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAm Z3Q7aXRzIHB1YmxpY2F0aW9uIGFzIGxvbmcgYXMgdGhlJm5ic3A7Jm5ic3A7Zm9sbG93aW5nIHBv aW50cyBhcmUgY2xhcmlmaWVkIGluIHRoZTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7ZHJhZnQg c2luY2Ugbm93IEZFQyBjYXBhYmlsaXR5IG9mIHRoZSBMU1IgcGVlciBpcyZuYnNwOyZuYnNwO2Rl dGVybWluZWQgYnkgYTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Y2hlY2sgYSBib3RoIGFkamFj ZW5jeSBhbmQgc2Vzc2lvbiBsZXZlbHM6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7IFRoYW5rcyBmb3IgcG9pbnRpbmcgb3V0IHRoZSBiZWxvdyBzY2VuYXJpb3MuIFdl IHRoaW5rIHRoYXQgYWxsIGJ1dCBvbmU8L2Rpdj4NCjxkaXY+Jmd0OyZndDthcmUgZWl0aGVyPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7IGNvdmVyZWQgb3IgcmVxdWlyZSBlZGl0b3JpYWwgY2hhbmdlcy48 L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsgMS4gVGhpcyBzY2VuYXJpbyAoc2VuZGluZyBoZWxsb3Mgd2l0aCBEUyBjYXBhYmlsaXR5 IG9uIGZld2VyIGludGVyZmFjZXM8L2Rpdj4NCjxkaXY+Jmd0OyZndDtmb3IgYSBwZWVyKTwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyBkb2VzIE5PVCBsb29rIHJlYWxpc3RpYywgc2luY2UgaGl0bGVzcyB1 cGdyYWRpbmcgYSByb3V0ZXIgd291bGQgcmVzdWx0PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7aW4gc2Vu ZGluZzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyB2NCYjNDM7djYgaGVsbG9zIGVpdGhlciB3aXRoIERT IGNhcGFiaWxpdHkgb3Igd2l0aG91dCBEUyBjYXBhYmlsaXR5IChmb3IgYTwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0O0RTIHBlZXIsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IGFzc3VtaW5nIHRoZSBwZWVyIHdh cyBlbmFibGVkIGZvciBEUyBMRFAsIGRlZmF1bHQgb3Igbm90LCBpbiBhbjwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0O2ltcGxlbWVudGF0aW9uKS48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZndDsgUGVyaGFwcywgeW91IGhhZCBhIGRpZmZlcmVudCBzY2VuYXJpbyBpbiBtaW5kLjwv ZGl2Pg0KPGRpdj4mZ3Q7TUEmZ3Q7IFRoaXMgY291bGQgb2NjdXIgZHVyaW5nIGEgaGl0bGVzcyB1 cGdyYWRlIGZvciBIZWxsbyBhZGphY2VuY2llcyBmcm9tPC9kaXY+DQo8ZGl2PiZndDtkaWZmZXJl bnQgbGluZSBjYXJkcyBkdXJpbmcgYSB0cmFuc2llbnQgdGltZS4gSSB3aWxsIG5vdCBpbnNpc3Qg b24gdGhpczwvZGl2Pg0KPGRpdj4mZ3Q7cG9pbnQgYnV0IEkgZm91bmQgdGhlIGRyYWZ0IGxhY2tz IHdoYXQgYWN0aW9uIHRvIHRha2UgaWYgdGhlIEhlbGxvPC9kaXY+DQo8ZGl2PiZndDttZXNzYWdl cyByZWNlaXZlZCBvbiBwYXJhbGxlbCBsaW5rcyBmcm9tIHRoZSBzYW1lIExTUiBhcmUgbm90IGNv bnNpc3RlbnQsPC9kaXY+DQo8ZGl2PiZndDttZWFuaW5nIHRoZXkgaGF2ZSBkaWZmZXJlbnQgVFIg dmFsdWVzIG9yIHRoZSBtZXNzYWdlIG9uIG9uZSBsaW5rIGRvIG5vdDwvZGl2Pg0KPGRpdj4mZ3Q7 aGF2ZSB0aGUgRFMgY2FwYWJpbGl0eS4gVGhlIG9ubHkgdGhpbmcgSSBmb3VuZCBpcyB0aGlzIHBh cmFncmFwaCBpbjwvZGl2Pg0KPGRpdj4mZ3Q7U2VjdGlvbiA2LjEuMSBidXQgaXQgZG9lcyBub3Qg c2F5IHdoYXQgdG8gZG8gaWYgYW4gTFNSIHJlY2VpdmVzPC9kaXY+DQo8ZGl2PiZndDtpbmNvbnNp c3RlbnQgSGVsbG8gbWVzc2FnZXM6PC9kaXY+DQo8ZGl2PiZndDsmcXVvdDs8L2Rpdj4NCjxkaXY+ Jmd0O0FuIExTUiBNVVNUIGNvbnZleSB0aGUgc2FtZSB0cmFuc3BvcnQgY29ubmVjdGlvbiBwcmVm ZXJlbmNlICgmcXVvdDtUUiZxdW90OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7IGZpZWxk IHZhbHVlKSBpbiBhbGwgKGxpbmsgYW5kIHRhcmdldGVkKSBIZWxsb3MgdGhhdCBhZHZlcnRpc2Ug dGhlPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsgc2FtZSBsYWJlbCBzcGFjZSB0byB0aGUg c2FtZSBwZWVyIGFuZC9vciBvbiBzYW1lIGludGVyZmFjZS4mbmJzcDsmbmJzcDtUaGlzPC9kaXY+ DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsgZW5zdXJlcyB0aGF0IHR3byBMU1JzIGxpbmtlZCBieSBt dWx0aXBsZSBIZWxsbyBhZGphY2VuY2llcyB1c2luZyB0aGU8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyBzYW1lIGxhYmVsIHNwYWNlcyBwbGF5IHRoZSBzYW1lIGNvbm5lY3Rpb24gZXN0YWJs aXNobWVudCByb2xlIGZvcjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7IGVhY2ggYWRqYWNl bmN5LjwvZGl2Pg0KPGRpdj4mZ3Q7JnF1b3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZndDsgMi4gWWVzLiBUaGlzIHNjZW5hcmlvIGlzIHdlbGwgY292ZXJlZCBpbiBzZWN0aW9u IDYuMS4xIHBvaW50IzMuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IC8vPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7My4gSWYgJnF1b3Q7RHVhbC1zdGFjayBjYXBhYmlsaXR5 JnF1b3Q7IFRMViBpcyBOT1QgcHJlc2VudCwgYW5kPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7IMWgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7cmVzdWx0aW5nIGluIGFueSBlc3RhYmxpc2hlZCBMRFBvSVB2NCBzZXNzaW9uIGJl aW5nIHJlc2V0PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 YW5kIGEgZmF0YWwgTm90aWZpY2F0aW9uIG1lc3NhZ2UgYmVpbmcgc2VudCAod2l0aCBzdGF0dXM8 L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgxaA8L2Rpdj4NCjxkaXY+ Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgLy88L2Rpdj4NCjxkaXY+Jmd0O01BJmd0OyBX aGF0IEkgd2FzIHRhbGtpbmcgYWJvdXQgaXMgYSB0cmFuc2l0aW9uIGZyb20gc3RhdGUgMmEgdG8g c3RhdGUgM2Egb3I8L2Rpdj4NCjxkaXY+Jmd0O2Zyb20gc3RhdGUgMmIgdG8gc3RhdGUgM2IgaW4g U2VjdGlvbiA2LjEuMS4gUGVyaGFwcyBvbmUgd2F5IHRvIGV4cGxpY2l0bHk8L2Rpdj4NCjxkaXY+ Jmd0O3N0YXRlIHRoYXQgdGhlIHNlc3Npb24gaXMgYm91bmNlZCB3b3VsZCBiZSB0byBhZGQgc29t ZXRoaW5nIGxpa2UgdGhpcyB0bzwvZGl2Pg0KPGRpdj4mZ3Q7aXRlbXMgMmEgYW5kIDJiIG9mIFNl Y3Rpb24gNi4uMS4xOjwvZGl2Pg0KPGRpdj4mZ3Q7JnF1b3Q7PC9kaXY+DQo8ZGl2PiZndDsyLiBJ ZiAmcXVvdDtEdWFsLXN0YWNrIGNhcGFiaWxpdHkmcXVvdDsgVExWIGlzIHByZXNlbnQsIGFuZCBy ZW1vdGU8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3ByZWZlcmVuY2UgbWF0Y2hlcyB3aXRoIHRoZSBsb2NhbCBwcmVmZXJlbmNl LCB0aGVuOjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthKSBJZiBUUj0wMTAw IChMRFBvSVB2NCksIHRoZW4gZGV0ZXJtaW5lIHRoZSBhY3RpdmUvcGFzc2l2ZTwvZGl2Pg0KPGRp dj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJvbGVzIGZvciBUQ1AgY29ubmVjdGlvbiB1c2luZyBJUHY0 IHRyYW5zcG9ydCBhZGRyZXNzIGFzPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVm aW5lZCBpbiBzZWN0aW9uIDIuNS4yIG9mIFJGQyA1MDM2LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtiKSBJZiBUUj0wMTEwIChMRFBvSVB2NiksIHRoZW4gZGV0ZXJtaW5lIHRo ZSBhY3RpdmUvcGFzc2l2ZTwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJvbGVzIGZv ciBUQ1AgY29ubmVjdGlvbiBieSB1c2luZyBJUHY2IHRyYW5zcG9ydCBhZGRyZXNzPC9kaXY+DQo8 ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXMgZGVmaW5lZCBpbiBzZWN0aW9uIDIuNS4yIG9mIFJG QyA1MDM2LjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7ICpJZiBzdWJzZXF1ZW50bHkgdG8g ZXN0YWJsaXNoaW5nIHRoZSBMRFAgc2Vzc2lvbiwgdGhlIEhlbGxvIG1lc3NhZ2VzPC9kaXY+DQo8 ZGl2PiZndDtmcm9tIHRoZSBwZWVyPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsgZG8gbm90 IGluY2x1ZGUgdGhlIER1YWwtc3RhY2sgY2FwYWJpbGl0eSBUTFYsIHRoZSBzZXNzaW9uIGlzPC9k aXY+DQo8ZGl2PiZndDt0ZXJtaW5hdGVkIGFuZCBhIGZhdGFsIE5vdGlmaWNhdGlvbiBtZXNzYWdl IGlzIHNlbnQgd2l0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdGF0dXMgY29kZTwvZGl2Pg0K PGRpdj4mZ3Q7b2YgJ0R1YWwtU3RhY2sgTm9uLUNvbXBsaWFuY2UnIChJQU5BIGFsbG9jYXRpb24g VEJEKS4qPC9kaXY+DQo8ZGl2PiZndDsmcXVvdDs8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRp dj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IDMuIFllcyAo dG8gdGhlIGV4cGVjdGVkIGJlaGF2aW9yKS4gVGhpcyBpcyBzb21ld2hhdCBjb3ZlcmVkIGluIGJ1 bGxldDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyMxIGluIHNlY3Rpb248L2Rpdj4NCjxkaXY+Jmd0OyZn dDsgNi4xLjEsIGJ1dCB3ZSBjYW4gbWFrZSBpdCBleHBsaWNpdCBieSBhZGRpbmcgJnF1b3Q7b3Ig ZG9lcyBub3QgZ2V0PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7cmVjb2duaXplZMKyIGFzIGJlbG93Ojwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyBPTEQ6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IElmICZxdW90O0R1YWwtc3RhY2sgY2FwYWJp bGl0eSZxdW90OyBUTFYgaXMgcHJlc2VudCBhbmQgcmVtb3RlIHByZWZlcmVuY2UgZG9lczwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0O25vdCBtYXRjaDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyB3aXRoIHRoZSBs b2NhbCBwcmVmZXJlbmNlLC4uPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IE5FVzo8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgSWYgJnF1 b3Q7RHVhbC1zdGFjayBjYXBhYmlsaXR5JnF1b3Q7IFRMViBpcyBwcmVzZW50IGFuZCByZW1vdGUg cHJlZmVyZW5jZSBkb2VzPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7bm90IG1hdGNoPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7IHdpdGggdGhlIGxvY2FsIHByZWZlcmVuY2UgKG9yIGRvZXMgbm90IGdldCByZWNv Z25pemVkKSwuLjwvZGl2Pg0KPGRpdj4mZ3Q7TUEmZ3Q7IFlvdXIgcHJvcG9zZWQgbW9kaWZpY2F0 aW9uIGRvZXMgYWRkcmVzcyB0aGlzIGNvbW1lbnQuIFRoYW5rIHlvdS48L2Rpdj4NCjxkaXY+Jmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IDQgYW5kIDUuIFllcyAodG8g dGhlIGV4cGVjdGVkIGJlaGF2aW9yKS4gSXQgaXMgaW1wbGljaXQgaW4gc2VjdGlvbiA3LjI8L2Rp dj4NCjxkaXY+Jmd0OyZndDtwYXJhIDQuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7IC8vLi48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDtBbiBMU1IgTUFZ IGZ1cnRoZXIgY29uc3RyYWluIHRoZSBhZHZlcnRpc2VtZW50IG9mIEZFQy1sYWJlbCBiaW5kaW5n czwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O2ZvciBhPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IHBhcnRpY3Vs YXIgYWRkcmVzcyBmYW1pbHkgYnkgbmVnb3RpYXRpbmcgdGhlIElQIENhcGFiaWxpdHkuLi4vLzwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBBcmUgeW91IHN1Z2dlc3Rp bmcgdG8gbWFrZSBpdCBleHBsaWNpdD88L2Rpdj4NCjxkaXY+Jmd0O01BJmd0OyBZZXMgSSB3YW50 ZWQgc29tZXRoaW5nIG1vcmUgZXhwbGljaXQuIFRoaXMgc2VjdGlvbiBjZXJ0YWlubHkgc2F5cyB0 aGU8L2Rpdj4NCjxkaXY+Jmd0O0lQdjYgcHJlZml4IEZFQyBjYXBhYmlsaXR5IGNhbiBmdXJ0aGVy IGNvbnN0cmFpbiBhIHBhcnRpY3VsYXIgRkVDIHR5cGU8L2Rpdj4NCjxkaXY+Jmd0O3doaWNoIGlz IGFsbG93ZWQgYnkgdGhlIGNoZWNrIG9mIHRoZSBEUyBjYXBhYmlsaXR5IFRMVi4gSXQgaG93ZXZl ciBkb2VzPC9kaXY+DQo8ZGl2PiZndDtub3QgZGlzY3VzcyB0aGUgbmVnYXRpdmUgY2FzZSwgaS5l LiwgdGhlIERTIGNhcGFiaWxpdHkgVExWIGRpZCBub3QgYWxsb3c8L2Rpdj4NCjxkaXY+Jmd0O2Eg RkVDIHR5cGUgYnV0IHRoZSBJUCBjYXBhYmlsaXR5IGFsbG93ZWQgaXQuPC9kaXY+DQo8ZGl2PiZn dDtJIGJlbGlldmUgdGhlIGZvbGxvd2luZyBhZGRpdGlvbiB0byBhbiBlYXJsaWVyIHBhcmFncmFw aCBpbiBTZWN0aW9uIDcuMjwvZGl2Pg0KPGRpdj4mZ3Q7d291bGQgaGVscCBjbGFyaWZ5IHRoaXM6 PC9kaXY+DQo8ZGl2PiZndDsmcXVvdDs8L2Rpdj4NCjxkaXY+Jmd0O0lmIGFuIExTUiBlbmFibGVk IHdpdGggRHVhbC1zdGFjayBMRFAgZm9yIGEgcGVlciBhbmQ8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEuIElzIE5PVCBhYmxlIHRvIGZp bmQgdGhlIER1YWwtc3RhY2sgY2FwYWJpbGl0eSBUTFYgaW4gdGhlPC9kaXY+DQo8ZGl2PiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbmNvbWluZyBJ UHY0IExEUCBoZWxsbyBtZXNzYWdlcyBmcm9tIHRoYXQgcGVlciwgdGhlbiB0aGUgTFNSPC9kaXY+ DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtNVVNUIE5PVCBhZHZlcnRpc2UgSVB2NiBGRUMtbGFiZWwgYmluZGluZ3MgdG8gdGhlIHBlZXIg KmV2ZW4gaWY8L2Rpdj4NCjxkaXY+Jmd0O2l0IHJlY2VpdmVkIGFuIElQIGNhcGFiaWxpdHk8L2Rp dj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2Zyb20gdGhlIHBlZXIgaW5kaWNhdGluZyB0aGUgZW5hYmxpbmcgb2YgdGhlIElQdjYgRkVD IHR5cGUqLjwvZGl2Pg0KPGRpdj4mZ3Q7JnF1b3Q7PC9kaXY+DQo8ZGl2PiZndDtCVFcsIHRoZXJl IGlzIGEgJnF1b3Q7Y29weSAmYW1wOyBwYXN0ZSZxdW90OyBtaXN0YWtlIGluIHRoZSBmb2xsb3dp bmcgcGFyYWdyYXBoIGluIHRoZTwvZGl2Pg0KPGRpdj4mZ3Q7c2FtZSBTZWN0aW9uIDcuMi4gVGhl ICZxdW90O3ZpYSBBRERSRVNTIG1lc3NhZ2UmcXVvdDsgaXMgbm90IGNvcnJlY3QgaGVyZSBzaW5j ZTwvZGl2Pg0KPGRpdj4mZ3Q7dGhpcyBpcyBhYm91dCBGRUMgZGlzdHJpYnV0aW9uLCBoZW5jZSBM YWJlbCBNYXBwaW5nIG1lc3NhZ2UsIGFuZCBub3Q8L2Rpdj4NCjxkaXY+Jmd0O2FkZHJlc3MgZGlz dHJpYnV0aW9uLjwvZGl2Pg0KPGRpdj4mZ3Q7JnF1b3Q7PC9kaXY+DQo8ZGl2PiZndDtJZiBhbiBM U1IgaXMgZW5hYmxlZCB3aXRoIFNpbmdsZS1zdGFjayBMRFAgZm9yIGFueSBwZWVyLCB0aGVuIGl0 PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsgTVVTVCBhZHZlcnRpc2UgKHZpYSBBRERSRVNT IG1lc3NhZ2UpIEZFQy1MYWJlbCBiaW5kaW5ncyBmb3IgdGhlPC9kaXY+DQo8ZGl2PiZndDsmbmJz cDsmbmJzcDsgZW5hYmxlZCBhZGRyZXNzIGZhbWlseSwgYW5kIGFjY2VwdCBGRUMtTGFiZWwgYmlu ZGluZ3MgZm9yIHRoZTwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7IGVuYWJsZWQgYWRkcmVz cyBmYW1pbHkuPC9kaXY+DQo8ZGl2PiZndDsmcXVvdDs8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyAtLTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBDaGVlcnMsPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7IFJhaml2IEFzYXRpPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IERpc3Rpbmd1aXNoZWQg RW5naW5lZXIsIENpc2NvPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7IEZyb206ICZsdDtBaXNzYW91aSZndDssIE11c3RhcGhhIEFpc3Nh b3VpPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzptdXN0YXBoYS5haXNz YW91aUBhbGNhdGVsLWx1Y2VudC5jb20iPm11c3RhcGhhLmFpc3Nhb3VpQGFsY2F0ZWwtbHVjZW50 LmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IERhdGU6IFR1ZXNkYXksIERlY2VtYmVy IDE2LCAyMDE0IGF0IDEyOjIxIFBNPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IFRvOiBJRVRGIERpc2N1 c3Npb24gJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9h PiZndDssIElFVEYtQW5ub3VuY2U8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbHQ7PGEgaHJlZj0ibWFp bHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmciPmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBDYzogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0 Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0Bp ZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IFN1Ympl Y3Q6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTE0 LnR4dCZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsoVXBkYXRlczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyB0byBMRFAgZm9yIElQdjYpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDtIaSBBZHJpYW4gYW5kIGFsbCw8L2Rpdj4NCjxk aXY+Jmd0OyZndDsgJmd0O0kgd2FzIHRoZSBvbmUgd2hvIHJhaXNlZCB0aGUgaW50ZXJvcCBpc3N1 ZXMgd2UgZm91bmQgd2hpbGUgdGVzdGluZyBvdXI8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O2lt cGxlbWVudGF0aW9uIG9mIExEUCBJUHY2IGFnYWluc3QgZXhpc3RpbmcgYW5kIGRlcGxveWVkPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7aW1wbGVtZW50YXRpb25zLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAm Z3Q7SSBwcm9wb3NlZCBhIHNpbXBsZSBtZXRob2Qgb2YgdXNpbmcgdGhlIGV4aXN0aW5nIEZFQyBh ZHZlcnRpc2VtZW50PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDtjYXBhYmlsaXR5IGF0IHRoZSBz ZXNzaW9uIGxldmVsIGFzIGEgd2F5IGZvciBhbiBMU1IgdG8gZGV0ZWN0IGlmIGFuPC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7ICZndDtpbXBsZW1lbnRhdGlvbiBzdXBwb3J0IExEUCBJUHY2IEZFQ3MgYW5k IElQdjYgYWRkcmVzc2VzLiBUaGlzIGV4aXN0aW5nPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDtG RUMgYWR2ZXJ0aXNlbWVudCBjYXBhYmlsaXR5IGF0IHNlc3Npb24gbGV2ZWwgaXMgZGVmaW5lZCBp bjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7ZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcC1wdy1jYXBh YmlsaXR5LTA4IGJ1dCB3aXRoIHRoZSBsaW1pdGF0aW9uIHRoYXQgaXQ8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsgJmd0O2NhbiBiZSB1c2VkIG9ubHkgdG8gZGlzYWJsZSBzdXBwb3J0IG9mIElQdjYgRkVD cyBpbiBMRFAgSW5pdGlhbGl6YXRpb248L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O01lc3NhZ2U7 IHdlIHByb3Bvc2VkIHRvIGdlbmVyYWxpemUgdGhlIG1ldGhvZCB0byBhbHNvIGluZGljYXRlIGV4 cGxpY2l0PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDtzdXBwb3J0IGZvciBJUHY2IEZFQ3MgYW5k IElQdjYgQWRkcmVzc2VzIGluIExEUCBJbml0aWFsaXphdGlvbiBNZXNzYWdlLjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyAmZ3Q7VGhpcyBtZXRob2QgaXMgc2FmZSBhbmQgd2FzIGFsc28gdXNlZCB3aXRo IG1MRFAgUDJNUCBhbmQgTVAyTVAgRkVDczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyB3aGVuPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7ICZndDt0aGV5IHdlcmUgaW50cm9kdWNlZC4gVGhlIGludGVudCBoZXJl IGlzIHRoYXQgYWxsIHNlc3Npb24gbGV2ZWw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O2NhcGFi aWxpdGllcyBpbiBMRFAgc2hvdWxkIGZvbGxvdyBSRkMgNTU2MSBhcHByb2FjaC48L2Rpdj4NCjxk aXY+Jmd0OyZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7VGhlcmUgd2FzIGFuIGlu ZGl2aWR1YWwgY29udHJpYnV0b3Igd2hpY2ggc3VwcG9ydGVkIHRoZSBwcm9wb3NhbCBvbiB0aGU8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O21haWxpbmcgbGlzdCBidXQgdGhlIGF1dGhvcnMgY2hv c2UgdG8gaWdub3JlIGl0IGFuZCB3ZW50IHdpdGggYTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O3Byb3Bv c2FsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDt3aGljaCBvdmVybG9hZGVkIHRoZSBtZWFuaW5n IG9mIHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkgVExWLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O1Jl Z2FyZGxlc3M8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O29mIHRoZSBtZXJpdCBvZiBlaXRoZXIg bWV0aG9kLCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgTVBMUyBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxk aXY+Jmd0OyZndDsgJmd0O3dhcyBub3QgY2xvc2VkIHByb3Blcmx5IGZyb20gbXkgcGVyc3BlY3Rp dmUuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O05v dyBoZXJlIGlzIHRoZSBjb25jZXJuIEkgcmFpc2VkIHdpdGggdXNpbmcgdGhlIGR1YWwtc3RhY2sg Y2FwYWJpbGl0eS48L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O05vdCBvbmx5IHRoaXMgVExWIGlz IGFuIGFkamFjZW5jeSBsZXZlbCBmZWF0dXJlIHdoaWNoIGlzIGhhcyBub3RoaW5nIHRvPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7ICZndDtkbyB3aXRoIEZFQyBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQs IGJ1dCBpdCBpcyBpbnRyb2R1Y2luZyBjb21wbGV4aXR5PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7aW48 L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O3RoZSBpbXBsZW1lbnRhdGlvbiB3aGljaCBub3cgaGFz IHRvIGNoZWNrIGR1YWwtc3RhY2sgY2FwYWJpbGl0eSBmb3I8L2Rpdj4NCjxkaXY+Jmd0OyZndDsg Jmd0OyplYWNoKiBhZGphY2VuY3kgdG8gdGhlIHBlZXIgKmFuZCogdGhlIHNlc3Npb24gbGV2ZWwg RkVDIGNhcGFiaWxpdHkgdG88L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O2RlY2lkZSB3aGF0IHRo ZSBwZWVyIGlzIGNhcGFibGUgb2YgYXQgdGhlICpzZXNzaW9uIGxldmVsKi48L2Rpdj4NCjxkaXY+ Jmd0OyZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7SGF2aW5nIHNhaWQgdGhhdCwg SSB3YW50IHRvIGtlZXAgdGhlIHNwaXJpdCBvZiBjb29wZXJhdGlvbiBhbmQgbWFrZTwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0O3N1cmU8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O3dlIGdldCB0aGlzIGRy YWZ0IHB1Ymxpc2hlZC4gVG8gdGhhdCBlZmZlY3QsIEkgYW0gbm90IG9wcG9zZWQgdG8gaXRzPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDtwdWJsaWNhdGlvbiBhcyBsb25nIGFzIHRoZSBmb2xsb3dp bmcgcG9pbnRzIGFyZSBjbGFyaWZpZWQgaW4gdGhlIGRyYWZ0PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 ICZndDtzaW5jZSBub3cgRkVDIGNhcGFiaWxpdHkgb2YgdGhlIExTUiBwZWVyIGlzIGRldGVybWlu ZWQgYnkgYSBjaGVjayBhPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Ym90aDwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyAmZ3Q7YWRqYWNlbmN5IGFuZCBzZXNzaW9uIGxldmVsczo8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7MS4gVGhlIGRyYWZ0IGlzIG1pc3Npbmcg dGhlIGJlaGF2aW9yIHdoZW4gbXVsdGlwbGUgYWRqYWNlbmNpZXMgZXhpc3QgdG88L2Rpdj4NCjxk aXY+Jmd0OyZndDsgJmd0O3RoZSBzYW1lIExTUiBhbmQgdGhlIHBlZXIgTFNSIGFkdmVydGlzZWQg dGhlIGR1YWwtc3RhY2sgY2FwYWJpbGl0eSBvbmx5PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDtv dmVyIGEgc3Vic2V0IG9mIHRoZXNlIEhlbGxvIGFkamFjZW5jaWVzLjwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyAmZ3Q7SSBhc3N1bWUgaGVyZSB0aGUgcGVlciBMU1IgaXMgY29uc2lkZXJlZCB0byBiZSBk dWFsLXN0YWNrIGNhcGFibGUgYXM8L2Rpdj4NCjxkaXY+Jmd0OyZndDtzb29uPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7ICZndDthcyBhbnkgb2YgdGhlIEhlbGxvIGFkamFjZW5jaWVzIGluY2x1ZGVzIHRo ZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7VGhpczwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyAmZ3Q7d291bGQgYWxsb3cgYSBoaXRsZXNzIHVwZ3JhZGUgc2NlbmFyaW8g ZnJvbSBhbiBvbGRlciBpbXBsZW1lbnRhdGlvbiB0bzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7 b25lIHdoaWNoIGNvbXBsaWVzIHRvIHRoaXMgZHJhZnQ8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Mi4gU2ltaWxhcmx5LCB3aGF0IHdvdWxkIGJlIHRo ZSBiZWhhdmlvciBpZiBhIGhlbGxvIGFkamFjZW5jeSBjaGFuZ2VzPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7ICZndDtmcm9tIHNlbmRpbmcgdGhlIGR1YWwtc3RhY2sgY2FwYWJpbGl0eSB0byBub3Qgc2Vu ZGluZyBpdD8gVGhpcyB3b3VsZCBiZTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Zm9yIGV4YW1w bGUgaW4gYSBoaXRsZXNzIGRvd25ncmFkZSB0byBhIHZlcnNpb24gb2YgTERQIHdoaWNoIGRvZXMg bm90PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDtjb21wbHkgdG8gdGhpcyBkcmFmdC48L2Rpdj4N CjxkaXY+Jmd0OyZndDsgJmd0O0kgYXNzdW1lIGhlcmUgdGhhdCB0aGUgc2Vzc2lvbiBtdXN0IGJl IGJvdW5jZWQgc2luY2UgdGhlIExTUnMgbmVlZCBhPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDtj bGVhbiBzdGF0ZSB0byBub3Qgc2VuZCBJUHY2IGFkZHJlc3NlcyBhbmQgSVB2NiBGRUNzLjwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDszLiBUaGUgZG9j dW1lbnQgZGVmaW5lcyAyIHZhbHVlcyBmb3IgdGhlIGR1YWwtc3RhY2sgY2FwYWJpbGl0eSBUUi4g SXQ8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O2RvZXMgbm90IG1lbnRpb24gdGhlIGJlaGF2aW9y IHdoZW4gYW4gdW5rbm93biB2YWx1ZSBpcyByZWNlaXZlZC48L2Rpdj4NCjxkaXY+Jmd0OyZndDsg Jmd0O1dpbGwgdGhhdCBiZSBjb25zaWRlcmVkIGEgZmF0YWwgZXJyb3I/PC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OzQuIFRoZSBkcmFmdCBpcyBtaXNz aW5nIHRoZSBiZWhhdmlvciBvZiB3aGVuIHRoZSBwZWVyIExTUiBkb2VzIG5vdDwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyAmZ3Q7YWR2ZXJ0aXNlIHRoZSBkdWFsLXN0YWNrIGNhcGFiaWxpdHkgaW4gYWxs IHRoZSBIZWxsbyBhZGphY2VuY2llcyBidXQgaXQ8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O2Fk dmVydGlzZWQgdGhlIGVuYWJsaW5nIG9yIGRpc2FibGluZyBvZiB0aGUgSVB2NiBwcmVmaXggRkVD IGNhcGFiaWxpdHk8L2Rpdj4NCjxkaXY+Jmd0OyZndDtpbjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAm Z3Q7dGhlIHNlc3Npb24gaW5pdGlhbGl6YXRpb24gbWVzc2FnZS48L2Rpdj4NCjxkaXY+Jmd0OyZn dDsgJmd0O0kgYXNzdW1lIGhlcmUgdGhhdCB0aGUgYWJzZW5jZSBvZiB0aGUgZHVhbC1zdGFjayBj YXBhYmlsaXR5IG92ZXJyaWRlczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O2FueTwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyAmZ3Q7c2Vzc2lvbiBsZXZlbCBJUHY2IEZFQyBwcmVmaXggY2FwYWJpbGl0eSBhZHZl cnRpc2VtZW50LjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 ICZndDs1LiBUaGUgZHJhZnQgaXMgbWlzc2luZyB0aGUgYmVoYXZpb3Igb2Ygd2hlbiB0aGUgcGVl ciBMU1IgZG9lcyBub3Q8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O2FkdmVydGlzZSB0aGUgZHVh bC1zdGFjayBjYXBhYmlsaXR5IGluIGFsbCB0aGUgSGVsbG8gYWRqYWNlbmNpZXMgYnV0IGl0PC9k aXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDthZHZlcnRpc2VkIHRoZSBlbmFibGluZyBvZiB0aGUgSVB2 NiBwcmVmaXggRkVDIGNhcGFiaWxpdHkgaW4gdGhlPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7c2Vzc2lv bjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Q2FwYWJpbGl0eSBtZXNzYWdlLjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyAmZ3Q7SSBhc3N1bWUgdGhlIHNhbWUgYmVoYXZpb3IgYXMgaW4gKDQpIGFwcGxp ZXMgaGVyZS48L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAm Z3Q7UmVnYXJkcyw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0O011c3RhcGhhLjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7IEZyb206IG1wbHMg WzxhIGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgVGhlIElFU0c8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsgJmd0OyZndDsgU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDI6MzcgUE08L2Rp dj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDsgVG86IElFVEYtQW5ub3VuY2U8L2Rpdj4NCjxkaXY+ Jmd0OyZndDsgJmd0OyZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxz QGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBbbXBs c10gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTE0LnR4dCZndDsgKFVw ZGF0ZXM8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDt0byBMRFAgZm9yIElQdjYpPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7IHRvIFByb3Bvc2VkIFN0YW5kYXJkPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7ICZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7PC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJv bSB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O1N3aXRjaGluZzwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Jmd0O1dHPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsm Z3Q7IChtcGxzKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50OjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtICdVcGRhdGVzIHRvIExEUCBmb3IgSVB2Nic8L2Rpdj4NCjxk aXY+Jmd0OyZndDsgJmd0OyZndDsmbmJzcDsmbmJzcDsgJmx0O2RyYWZ0LWlldGYtbXBscy1sZHAt aXB2Ni0xNC50eHQmZ3Q7IGFzIFByb3Bvc2VkIFN0YW5kYXJkPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 ICZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7IFRoZSBJRVNHIHBsYW5zIHRv IG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0czwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Jmd0O2ZpbmFsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsm Z3Q7IGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21t ZW50cyB0byB0aGU8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDs8YSBocmVmPSJtYWlsdG86 aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0 OyZndDsgbWFpbGluZyBsaXN0cyBieSAyMDE0LTEyLTE4LiBFeGNlcHRpb25hbGx5LCBjb21tZW50 cyBtYXkgYmUgc2VudCB0bzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OzxhIGhyZWY9Im1h aWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUgYmVn aW5uaW5nIG9mIHRoZSBTdWJqZWN0PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7bGluZSB0 byBhbGxvdzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyBhdXRvbWF0ZWQgc29ydGluZy48 L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZn dDsgQWJzdHJhY3Q8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsgJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgTGFiZWwgRGlzdHJpYnV0 aW9uIFByb3RvY29sIChMRFApIHNwZWNpZmljYXRpb24gZGVmaW5lczwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Byb2NlZHVyZXMgdG8gZXhjaGFu Z2UgbGFiZWwgYmluZGluZ3Mgb3ZlciBlaXRoZXIgSVB2NCwgb3IgSVB2NiBvcjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2JvdGggbmV0d29ya3Mu IFRoaXMgZG9jdW1lbnQgY29ycmVjdHMgYW5kIGNsYXJpZmllcyB0aGUgTERQPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7YmVoYXZpb3I8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt3aGVuIElQdjYgbmV0d29yayBpcyB1c2VkICh3aXRoIG9yIHdpdGhvdXQg SVB2NCkuIFRoaXMgZG9jdW1lbnQ8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt1cGRhdGVzIFJGQyA1MDM2IGFuZCBSRkMgNjcyMC48L2Rpdj4NCjxk aXY+Jmd0OyZndDsgJmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDsgVGhlIGZp bGUgY2FuIGJlIG9idGFpbmVkIHZpYTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1sZHAt aXB2Ni8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLWxk cC1pcHY2LzwvYT48L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsgJmd0OyZndDsgSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYTwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni9iYWxsb3QvIj4NCmh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2L2JhbGxvdC88L2E+PC9k aXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDsmZ3Q7IE5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBi ZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC48L2Rpdj4NCjxkaXY+Jmd0OyZndDsg Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZn dDsgbXBscyBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0OyZndDsgPGEgaHJl Zj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9h PjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ICZndDtfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyAmZ3Q7bXBscyBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgJmd0Ozxh IGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+ PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bh bj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D0D964582499DErajivaciscocom_-- From nobody Mon Jan 12 21:07:30 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE57A1A8A14 for ; Mon, 12 Jan 2015 21:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6QaPLYrD0rx for ; Mon, 12 Jan 2015 21:07:21 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5985E1A8A07 for ; Mon, 12 Jan 2015 21:07:21 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.212.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 820EA180131A; Tue, 13 Jan 2015 06:07:17 +0100 (CET) Message-ID: <54B4A801.3010008@pi.nu> Date: Tue, 13 Jan 2015 13:07:13 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Black, David" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" References: <20150112145004.17839.42580.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: " \(mpls-ads@tools.ietf.org\)" Subject: Re: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 05:07:26 -0000 Folks, I guess that this question came from Alia, and at least in part is motivated that the draft is on the IESG agenda Jan 22. I know that there are a number of activities going on in parallel, but it would be nice if we could meet the date. /Loa On 2015-01-12 23:02, Black, David wrote: > The draft author team is working on that revision, should be submitted in next few days. > > Thanks, > --David > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of IETF Secretariat >> Sent: Monday, January 12, 2015 9:50 AM >> To: mpls-chairs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; Loa >> Andersson; mpls@ietf.org >> Subject: [mpls] ID Tracker State Update Notice: > 09.txt> >> >> IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting >> for AD Go-Ahead >> I am waiting for an updated draft that handles my review comments. I saw a >> response from David Black, but no further >> action. >> ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jan 12 21:30:01 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5151A89B0 for ; Mon, 12 Jan 2015 21:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-AX9BDDbN5o for ; Mon, 12 Jan 2015 21:29:56 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7471A89AB for ; Mon, 12 Jan 2015 21:29:56 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id 9so505669ykp.8 for ; Mon, 12 Jan 2015 21:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r2gKibKYSsJXL/hEuo1d1O9nCzOd457Gj2jEpynaSNg=; b=ez3fcuJcmb7PLt3zBy0F40wA0GI4xQg+vi5EqXGAJI4Tb8RKHxkFmn4zquglEn27Y7 npGOO3XtW+h6MR9CXJi/AxfHzoZEk7ObiPZHiGWx6dSRUhIO4x5CI/d5mDvIgpyyMhd1 KOK7B0sZyZtgqJgKw1CFXYmd7NclgxHp5hRQXhquRmAJi7/5YH9qSOztoWHkPt0BgDtB OGumeXE6KiUNTue1CNefgzsZy2Hn5hzu3DClAUInhwwTrmULxrBbAsenAeSgNhbBQxj1 ZcY77BBds+EkH8aODhwAa23kXlXQ8Mpkf5fvHw6ABb4hKv13QF/AQ6KR04TX8AHE0YR5 eyCw== MIME-Version: 1.0 X-Received: by 10.236.23.228 with SMTP id v64mr25338940yhv.25.1421126994914; Mon, 12 Jan 2015 21:29:54 -0800 (PST) Received: by 10.170.133.18 with HTTP; Mon, 12 Jan 2015 21:29:54 -0800 (PST) Received: by 10.170.133.18 with HTTP; Mon, 12 Jan 2015 21:29:54 -0800 (PST) In-Reply-To: <54B4A801.3010008@pi.nu> References: <20150112145004.17839.42580.idtracker@ietfa.amsl.com> <54B4A801.3010008@pi.nu> Date: Tue, 13 Jan 2015 00:29:54 -0500 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=089e01229e7eb67357050c81e953 Archived-At: Cc: "" , "draft-ietf-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 05:29:59 -0000 --089e01229e7eb67357050c81e953 Content-Type: text/plain; charset=UTF-8 Yes, it was in my AD Review which was done before the IETF Last Call. I'm hoping not to need to move it out past this telechat, but it is what the authors make it. Regards, Alia On Jan 12, 2015 9:07 PM, "Loa Andersson" wrote: > Folks, > > I guess that this question came from Alia, and at least in part is > motivated that the draft is on the IESG agenda Jan 22. I know that there > are a number of activities going on in parallel, but it would be nice > if we could meet the date. > > /Loa > > On 2015-01-12 23:02, Black, David wrote: > >> The draft author team is working on that revision, should be submitted in >> next few days. >> >> Thanks, >> --David >> >> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of IETF Secretariat >>> Sent: Monday, January 12, 2015 9:50 AM >>> To: mpls-chairs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; >>> Loa >>> Andersson; mpls@ietf.org >>> Subject: [mpls] ID Tracker State Update Notice: >> 09.txt> >>> >>> IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from >>> Waiting >>> for AD Go-Ahead >>> I am waiting for an updated draft that handles my review comments. I >>> saw a >>> response from David Black, but no further >>> action. >>> ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --089e01229e7eb67357050c81e953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, it was in my AD Review which was done before the IETF L= ast Call.=C2=A0 I'm hoping not to need to move it out past this telecha= t, but it is what the authors make it.

Regards,
Alia

On Jan 12, 2015 9:07 PM, "Loa Andersson&quo= t; <loa@pi.nu> wrote:
Folks,

I guess that this question came from Alia, and at least in part is
motivated that the draft is on the IESG agenda Jan 22. I know that there are a number of activities going on in parallel, but it would be nice
if we could meet the date.

/Loa

On 2015-01-12 23:02, Black, David wrote:
The draft author team is working on that revision, should be submitted in n= ext few days.

Thanks,
--David

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of IETF Secretariat
Sent: Monday, January 12, 2015 9:50 AM
To: mpls-ch= airs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; = Loa
Andersson; mpls@ietf.org=
Subject: [mpls] ID Tracker State Update Notice: <draft-ietf-mpls-in-udp-=
09.txt>

IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Wait= ing
for AD Go-Ahead
I am waiting for an updated draft that handles my review comments.=C2=A0 I = saw a
response from David Black, but no further
action.
ID Tracker URL: http://datatracker.ietf.org/doc/draft-iet= f-mpls-in-udp/

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

--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64
--089e01229e7eb67357050c81e953-- From nobody Tue Jan 13 02:41:38 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32B01A8A9C for ; Tue, 13 Jan 2015 02:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAG5MJ6IEFab for ; Tue, 13 Jan 2015 02:41:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4111ACE60 for ; Tue, 13 Jan 2015 02:41:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113104134.3306.11717.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 02:41:34 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 10:41:37 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-mrt for publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-lsp-ping-lag-multipath for publication", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Tue Jan 13 02:44:50 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45ABE1A8836 for ; Tue, 13 Jan 2015 02:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oMcLmYqgiW8; Tue, 13 Jan 2015 02:44:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 887401A8A8E; Tue, 13 Jan 2015 02:44:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-oam-ipv6-rao.all@tools.ietf.org, loa@pi.nu X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113104446.14141.56824.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 02:44:46 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 10:44:48 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ From nobody Tue Jan 13 04:19:41 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466821A8A9C for ; Tue, 13 Jan 2015 04:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPuFNB_CDPmW for ; Tue, 13 Jan 2015 04:19:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DDC1A8A9E for ; Tue, 13 Jan 2015 04:19:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113121936.10295.67119.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 04:19:36 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 12:19:39 -0000 Changed milestone "Submit draft-ietf-mpls-tp-oam-id-mib for publication", set due date to March 2015 from December 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Tue Jan 13 14:07:05 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1C71ACD01 for ; Tue, 13 Jan 2015 14:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMaXhT7CLUTb for ; Tue, 13 Jan 2015 14:06:58 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107AB1B29F3 for ; Tue, 13 Jan 2015 14:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4721; q=dns/txt; s=iport; t=1421186818; x=1422396418; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Wu1ApKKYt1x5wwh/XkoqfNzHgbHA+yt3JdMGNjTbaZ0=; b=GUVeRnVuTZF4RNrTbj8zw0rEBUcxb8GPQzNWqoeVZM837UiAN384WvCF Erd3YipdWa4mAENmVgPB8uq9SVxQUEP/fQfx3H+Pbxon2JeeH1yeGrEQU fNRBiXDurzDYcGZN3XZ9yEVQylK3bF4uXwh8QW9SX4sKPtADjds6ypJJW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIFAGSWtVStJV2a/2dsb2JhbABbgmQiUlMFBMYKDIVvAoEbQwEBAQEBfYQMAQEBBAEBATctBAMXBAIBCBEEAQELFAkHJwsUCAEIAgQBEggBiCMBBwXPdAEBAQEBAQEBAQEBAQEBAQEBAQEBARePSDgGgxCBEwWMZ4Fbg0WGVzCCQoddgmGDPSKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,751,1413244800"; d="scan'208";a="112996859" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 13 Jan 2015 22:06:50 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0DM6ncH006847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 22:06:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 16:06:49 -0600 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "mpls@ietf.org" Thread-Topic: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt Thread-Index: AQHQLf4yKXbUFDLRvUGh5WD7HIbbn5y+loOg Date: Tue, 13 Jan 2015 22:06:49 +0000 Message-ID: References: <20150112001822.601.61022.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B8CF8F5@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8CF8F5@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.11.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 22:07:03 -0000 Hello Greg, Thanks for incorporating my comments, and I've verified that all my comment= s are addressed in the updated document. I did come across one more thing that's worth being raised. In Section 2.2.4: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Auth. sub-type (103) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Key ID | Reserved (0s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Yes it's true that RFC5880 defined all the "Auth Key ID" to be 8 bits. Newe= r BFD authentication documents, like draft-ietf-bfd-generic-crypto-auth (ex= pired), attempted to increase the "Auth Key ID" field to be 16 bits. I am n= o security expert, but I would guess someone out there thought 255 keys isn= 't sufficient. One approach is to say that current definition is ok since it covers RFC588= 0. Another approach is to add a text stating that the length of the Auth Ke= y ID field depends on the value of the Auth Type field ... or something equ= ivalent to be forward compatible. Now, I do realize the above comment is also applicable to the companion doc= ument draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. And you already had to jump= through hoops to apply some changes to that recently. If the door is alrea= dy closed (or too much hassle to get things in the door), then perhaps movi= ng forward as is the path that makes most sense. My primary intent is to raise this so that folks are aware when somebody de= fines BFD authentication key ID field > 8 bits :) Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky > Sent: Sunday, January 11, 2015 7:25 PM > To: mpls@ietf.org > Subject: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf= - > 08.txt >=20 > Dear All, > this update addresses comments we received from Nobo. Also it reflects > work authors done with sister document draft-ietf-ccamp-rsvp-te-mpls-tp- > oam-ext addressing AD and GEN-Art review comments. >=20 > Your comments, questions and suggestions always welcome and greatly > appreciated. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Sunday, January 11, 2015 4:18 PM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.= txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. >=20 > Title : Configuration of Pro-Active Operations, Adminis= tration, and > Maintenance (OAM) Functions for MPLS-based Transport Networks using > LSP Ping > Authors : Elisa Bellagamba > Gregory Mirsky > Loa Andersson > Pontus Skoldstrom > Dave Ward > John Drake > Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt > Pages : 25 > Date : 2015-01-11 >=20 > Abstract: > This specification describes the configuration of pro-active MPLS-TP > Operations, Administration, and Maintenance (OAM) Functions for a > given LSP using a set of TLVs that are carried by the LSP-Ping > protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Jan 13 14:33:45 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851051B2A17 for ; Tue, 13 Jan 2015 14:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsTf8AHvFBPY for ; Tue, 13 Jan 2015 14:33:42 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81731B2A04 for ; Tue, 13 Jan 2015 14:33:41 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-04-54b53eeb4d8d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C6.D5.25146.BEE35B45; Tue, 13 Jan 2015 16:51:07 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 17:33:33 -0500 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "mpls@ietf.org" Thread-Topic: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt Thread-Index: AQHQL31AfA1yONhUsUqoU+7JvSdUipy+oDMg Date: Tue, 13 Jan 2015 22:33:32 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8D13CF@eusaamb103.ericsson.se> References: <20150112001822.601.61022.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B8CF8F5@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXRPgu5ru60hBjdPGFncWrqS1WJ2R7wD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfH40yPWgptaFX9ffmRvYPyp0MXIySEhYCKx ffJsNghbTOLCvfVANheHkMARRokDm18zQzjLGSV+fH7KAlLFJmAk8WJjDzuILSLgKXH7416w bmGBMInuiUeZIeLhEu37JrNB2EYSj+52gcVZBFQl9n9dwghi8wr4SryYvIAVYsExRonJ+zvB EpxAieMt08GWMQKd9P3UGiYQm1lAXOLWk/lMEKcKSCzZc54ZwhaVePn4HyuErSixr386O0S9 jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjFylBanluWmGxlu YgTGwzEJNscdjAs+WR5iFOBgVOLh3SC5JUSINbGsuDL3EKM0B4uSOG/Eo/UhQgLpiSWp2amp BalF8UWlOanFhxiZODilGhhnK314e7JXvKplpsnqpXu2Hrtec9X27P2vc0Qslt69sGClFKOc NUvmzSPN89Z+mp9xy/dC247YmTHrr764IFPhp3cpRuuus9PVGcL1/+y3MF1k2J749O/n23Yh s6Zc040Kq+fU+CB9eursCeJPo5d63K1k9Jb6xseqzfFa4cmUPPuf1uV3ryV9VmIpzkg01GIu Kk4EAEkYLhxoAgAA Archived-At: Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 22:33:44 -0000 Hi Nobo, many thanks for your always thoughtful comments. There will be new updates to RSVP-TE document and if we, as community, deci= de that the particular aspect must be update, we'll take care of that in bo= th documents. As for the case of Authentication sub-TLV, we may just need to hint that Re= served field MAY be of variable length, not just 16 bits long. Thus, new Au= th Type would have to define its sub-TLV format. Regards, Greg -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Tuesday, January 13, 2015 2:07 PM To: Gregory Mirsky; mpls@ietf.org Subject: RE: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-co= nf-08.txt Hello Greg, Thanks for incorporating my comments, and I've verified that all my comment= s are addressed in the updated document. I did come across one more thing that's worth being raised. In Section 2.2.4: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Auth. sub-type (103) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Key ID | Reserved (0s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Yes it's true that RFC5880 defined all the "Auth Key ID" to be 8 bits. Newe= r BFD authentication documents, like draft-ietf-bfd-generic-crypto-auth (ex= pired), attempted to increase the "Auth Key ID" field to be 16 bits. I am n= o security expert, but I would guess someone out there thought 255 keys isn= 't sufficient. One approach is to say that current definition is ok since it covers RFC588= 0. Another approach is to add a text stating that the length of the Auth Ke= y ID field depends on the value of the Auth Type field ... or something equ= ivalent to be forward compatible. Now, I do realize the above comment is also applicable to the companion doc= ument draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. And you already had to jump= through hoops to apply some changes to that recently. If the door is alrea= dy closed (or too much hassle to get things in the door), then perhaps movi= ng forward as is the path that makes most sense. My primary intent is to raise this so that folks are aware when somebody de= fines BFD authentication key ID field > 8 bits :) Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky > Sent: Sunday, January 11, 2015 7:25 PM > To: mpls@ietf.org > Subject: [mpls] FW: I-D Action:=20 > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf- > 08.txt >=20 > Dear All, > this update addresses comments we received from Nobo. Also it=20 > reflects work authors done with sister document=20 > draft-ietf-ccamp-rsvp-te-mpls-tp- oam-ext addressing AD and GEN-Art revie= w comments. >=20 > Your comments, questions and suggestions always welcome and greatly=20 > appreciated. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-=20 > drafts@ietf.org > Sent: Sunday, January 11, 2015 4:18 PM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action:=20 > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Multiprotocol Label Switching=20 > Working Group of the IETF. >=20 > Title : Configuration of Pro-Active Operations, Adminis= tration, and > Maintenance (OAM) Functions for MPLS-based Transport Networks using=20 > LSP Ping > Authors : Elisa Bellagamba > Gregory Mirsky > Loa Andersson > Pontus Skoldstrom > Dave Ward > John Drake > Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt > Pages : 25 > Date : 2015-01-11 >=20 > Abstract: > This specification describes the configuration of pro-active MPLS-TP > Operations, Administration, and Maintenance (OAM) Functions for a > given LSP using a set of TLVs that are carried by the LSP-Ping > protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-0 > 8 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Jan 13 14:47:55 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189E91B2AA8 for ; Tue, 13 Jan 2015 14:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBD3mXNklGMB for ; Tue, 13 Jan 2015 14:47:49 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587A51B2AA0 for ; Tue, 13 Jan 2015 14:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6149; q=dns/txt; s=iport; t=1421189149; x=1422398749; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ko1JgZ5O/n4iCdEJnw8kxGhHe6wbWvfP89OJ9x5leU0=; b=W1J82dc+8MokssVT33NPZKaPI3EmV/Ucn+4iXaJO0ciGavEz/WNcTSS2 NIrqYK45IvNLTh9EZ9icfI/ek6EIHLmYuO19i6bvdfuTiqScjPF3HI4rl UhwH+rFGJqWO+LjleRUJ6mP8Ysxis0unlStIne0Wiat5RwUpwtqyDB2Sr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIFAAaftVStJV2S/2dsb2JhbABbgmQiUlMFBMYLCoVxAoEbQwEBAQEBfYQMAQEBAwEBAQE3LQQDEAcEAgEIEQQBAQsUCQcnCxQIAQgCBAESCAELiBAIAQcFz3cBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0g4BoMQgRMFjGeBW4NFhlcwgkKHXYJhgz0ig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,752,1413244800"; d="scan'208";a="113004055" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP; 13 Jan 2015 22:45:48 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t0DMjlto010905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 22:45:47 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 16:45:47 -0600 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "mpls@ietf.org" Thread-Topic: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt Thread-Index: AQHQLf4yKXbUFDLRvUGh5WD7HIbbn5y+loOggAB0AQD//53H0A== Date: Tue, 13 Jan 2015 22:45:46 +0000 Message-ID: References: <20150112001822.601.61022.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B8CF8F5@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8D13CF@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8D13CF@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.11.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 22:47:52 -0000 Hello Greg, Thanks for very quick reply! Please see in-line. > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Tuesday, January 13, 2015 5:34 PM > To: Nobo Akiya (nobo); mpls@ietf.org > Subject: RE: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf-08.txt >=20 > Hi Nobo, > many thanks for your always thoughtful comments. > There will be new updates to RSVP-TE document and if we, as community, > decide that the particular aspect must be update, we'll take care of that= in > both documents. Sounds good. > As for the case of Authentication sub-TLV, we may just need to hint that > Reserved field MAY be of variable length, not just 16 bits long. Thus, ne= w > Auth Type would have to define its sub-TLV format. Or add Auth Key ID Length field and let Auth Ken ID field size be variable? Thanks! -Nobo >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Tuesday, January 13, 2015 2:07 PM > To: Gregory Mirsky; mpls@ietf.org > Subject: RE: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf-08.txt >=20 > Hello Greg, >=20 > Thanks for incorporating my comments, and I've verified that all my > comments are addressed in the updated document. >=20 > I did come across one more thing that's worth being raised. >=20 > In Section 2.2.4: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Auth. sub-type (103) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Auth Type | Auth Key ID | Reserved (0s) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Yes it's true that RFC5880 defined all the "Auth Key ID" to be 8 bits. Ne= wer > BFD authentication documents, like draft-ietf-bfd-generic-crypto-auth > (expired), attempted to increase the "Auth Key ID" field to be 16 bits. I= am > no security expert, but I would guess someone out there thought 255 keys > isn't sufficient. >=20 > One approach is to say that current definition is ok since it covers RFC5= 880. > Another approach is to add a text stating that the length of the Auth Key= ID > field depends on the value of the Auth Type field ... or something > equivalent to be forward compatible. >=20 > Now, I do realize the above comment is also applicable to the companion > document draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. And you already had > to jump through hoops to apply some changes to that recently. If the door= is > already closed (or too much hassle to get things in the door), then perha= ps > moving forward as is the path that makes most sense. >=20 > My primary intent is to raise this so that folks are aware when somebody > defines BFD authentication key ID field > 8 bits :) >=20 > Thanks! >=20 > -Nobo >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky > > Sent: Sunday, January 11, 2015 7:25 PM > > To: mpls@ietf.org > > Subject: [mpls] FW: I-D Action: > > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf- > > 08.txt > > > > Dear All, > > this update addresses comments we received from Nobo. Also it > > reflects work authors done with sister document > > draft-ietf-ccamp-rsvp-te-mpls-tp- oam-ext addressing AD and GEN-Art > review comments. > > > > Your comments, questions and suggestions always welcome and greatly > > appreciated. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Sunday, January 11, 2015 4:18 PM > > To: i-d-announce@ietf.org > > Cc: mpls@ietf.org > > Subject: [mpls] I-D Action: > > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Multiprotocol Label Switching > > Working Group of the IETF. > > > > Title : Configuration of Pro-Active Operations, Admin= istration, > and > > Maintenance (OAM) Functions for MPLS-based Transport Networks using > > LSP Ping > > Authors : Elisa Bellagamba > > Gregory Mirsky > > Loa Andersson > > Pontus Skoldstrom > > Dave Ward > > John Drake > > Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt > > Pages : 25 > > Date : 2015-01-11 > > > > Abstract: > > This specification describes the configuration of pro-active MPLS-TP > > Operations, Administration, and Maintenance (OAM) Functions for a > > given LSP using a set of TLVs that are carried by the LSP-Ping > > protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam- > > conf/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-0 > > 8 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-mpls-tp-oam= - > > conf-08 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Jan 13 17:09:35 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535621ACE1B for ; Tue, 13 Jan 2015 17:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb5vZwlOyy2c for ; Tue, 13 Jan 2015 17:09:29 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5ABA1ACD46 for ; Tue, 13 Jan 2015 17:09:28 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0E19PLX008784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2015 20:09:26 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t0E19PLX008784 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1421197766; bh=zTpNaolPt6lE5gJvrLZDrjgtZKQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=RME4wfXROg2ZuwaNRsvloE/1SWvIbh5ZlKWJBzblg209tCOKEHU6lGw2saYn9l1aU 1FlTNPsEQlbY1dSqWYAmN5wFlmWfQ0K1UivN1VtUWLRh91eMKWWAUHO7lPcifP7TiR gA4Wq20BDKxDQp34gUapEJH3OFTfO1J8DfLb7i5I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t0E19PLX008784 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd54.lss.emc.com (RSA Interceptor); Tue, 13 Jan 2015 20:07:45 -0500 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0E19GFE019208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 20:09:16 -0500 Received: from MXHUB208.corp.emc.com (10.253.68.34) by mxhub33.corp.emc.com (10.254.93.81) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 13 Jan 2015 20:09:16 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB208.corp.emc.com ([10.253.68.34]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 20:09:16 -0500 From: "Black, David" To: Alia Atlas , Loa Andersson Thread-Topic: [mpls] ID Tracker State Update Notice: Thread-Index: AQHQLu7SS8av+WlV4Uqvk1fyX9yBEpy92d8AgAD1g7A= Date: Wed, 14 Jan 2015 01:09:15 +0000 Message-ID: References: <20150112145004.17839.42580.idtracker@ietfa.amsl.com> <54B4A801.3010008@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.44.204] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362E05D1MX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 01:09:32 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362E05D1MX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGF1dGhvcnMgaW50ZW5kIHRvIGdldCBzb21ldGhpbmcgcG9zdGVkIGluIHRpbWUgZm9yIHRo ZSBkcmFmdCB0byByZW1haW4gb24gdGhpcyB0ZWxlY2hhdC4NCg0KVGhhbmtzLA0KLS1EYXZpZA0K DQpGcm9tOiBBbGlhIEF0bGFzIFttYWlsdG86YWthdGxhc0BnbWFpbC5jb21dDQpTZW50OiBUdWVz ZGF5LCBKYW51YXJ5IDEzLCAyMDE1IDEyOjMwIEFNDQpUbzogTG9hIEFuZGVyc3Nvbg0KQ2M6IEJs YWNrLCBEYXZpZDsgPG1wbHMtYWRzQHRvb2xzLmlldGYub3JnPjsgbXBsc0BpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gSUQgVHJhY2tlciBTdGF0ZSBVcGRhdGUgTm90aWNl OiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wOS50eHQ+DQoNCg0KWWVzLCBpdCB3YXMgaW4gbXkg QUQgUmV2aWV3IHdoaWNoIHdhcyBkb25lIGJlZm9yZSB0aGUgSUVURiBMYXN0IENhbGwuICBJJ20g aG9waW5nIG5vdCB0byBuZWVkIHRvIG1vdmUgaXQgb3V0IHBhc3QgdGhpcyB0ZWxlY2hhdCwgYnV0 IGl0IGlzIHdoYXQgdGhlIGF1dGhvcnMgbWFrZSBpdC4NCg0KUmVnYXJkcywNCkFsaWENCk9uIEph biAxMiwgMjAxNSA5OjA3IFBNLCAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udTxtYWlsdG86bG9h QHBpLm51Pj4gd3JvdGU6DQpGb2xrcywNCg0KSSBndWVzcyB0aGF0IHRoaXMgcXVlc3Rpb24gY2Ft ZSBmcm9tIEFsaWEsIGFuZCBhdCBsZWFzdCBpbiBwYXJ0IGlzDQptb3RpdmF0ZWQgdGhhdCB0aGUg ZHJhZnQgaXMgb24gdGhlIElFU0cgYWdlbmRhIEphbiAyMi4gSSBrbm93IHRoYXQgdGhlcmUNCmFy ZSBhIG51bWJlciBvZiBhY3Rpdml0aWVzIGdvaW5nIG9uIGluIHBhcmFsbGVsLCBidXQgaXQgd291 bGQgYmUgbmljZQ0KaWYgd2UgY291bGQgbWVldCB0aGUgZGF0ZS4NCg0KL0xvYQ0KDQpPbiAyMDE1 LTAxLTEyIDIzOjAyLCBCbGFjaywgRGF2aWQgd3JvdGU6DQpUaGUgZHJhZnQgYXV0aG9yIHRlYW0g aXMgd29ya2luZyBvbiB0aGF0IHJldmlzaW9uLCBzaG91bGQgYmUgc3VibWl0dGVkIGluIG5leHQg ZmV3IGRheXMuDQoNClRoYW5rcywNCi0tRGF2aWQNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSUVURiBTZWNyZXRhcmlhdA0KU2VudDogTW9u ZGF5LCBKYW51YXJ5IDEyLCAyMDE1IDk6NTAgQU0NClRvOiBtcGxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW1wbHMt aW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xz LmlldGYub3JnPjsgTG9hDQpBbmRlcnNzb247IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbbXBsc10gSUQgVHJhY2tlciBTdGF0ZSBVcGRhdGUgTm90aWNlOiA8 ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0NCjA5LnR4dD4NCg0KSUVTRyBzdGF0ZSBjaGFuZ2VkIHRv IFdhaXRpbmcgZm9yIEFEIEdvLUFoZWFkOjpSZXZpc2VkIEktRCBOZWVkZWQgZnJvbSBXYWl0aW5n DQpmb3IgQUQgR28tQWhlYWQNCkkgYW0gd2FpdGluZyBmb3IgYW4gdXBkYXRlZCBkcmFmdCB0aGF0 IGhhbmRsZXMgbXkgcmV2aWV3IGNvbW1lbnRzLiAgSSBzYXcgYQ0KcmVzcG9uc2UgZnJvbSBEYXZp ZCBCbGFjaywgYnV0IG5vIGZ1cnRoZXINCmFjdGlvbi4NCklEIFRyYWNrZXIgVVJMOiBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1pbi11ZHAvDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcg bGlzdA0KbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzps b2FAbWFpbDAxLmh1YXdlaS5jb20+DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAg ICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2ll cyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDcz OSUyMDgxJTIwMjElMjA2ND4NCg== --_000_CE03DB3D7B45C245BCA0D243277949362E05D1MX104CL02corpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250 LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPlRoZSBhdXRob3JzIGludGVuZCB0byBnZXQgc29tZXRoaW5nIHBvc3RlZCBpbiB0aW1lIGZv ciB0aGUgZHJhZnQgdG8gcmVtYWluIG9uIHRoaXMgdGVsZWNoYXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+VGhhbmtzLDxicj4NCi0tRGF2aWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFsaWEgQXRsYXMgW21haWx0 bzpha2F0bGFzQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5 IDEzLCAyMDE1IDEyOjMwIEFNPGJyPg0KPGI+VG86PC9iPiBMb2EgQW5kZXJzc29uPGJyPg0KPGI+ Q2M6PC9iPiBCbGFjaywgRGF2aWQ7ICZsdDttcGxzLWFkc0B0b29scy5pZXRmLm9yZyZndDs7IG1w bHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gSUQg VHJhY2tlciBTdGF0ZSBVcGRhdGUgTm90aWNlOiAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0w OS50eHQmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+WWVzLCBpdCB3YXMgaW4gbXkg QUQgUmV2aWV3IHdoaWNoIHdhcyBkb25lIGJlZm9yZSB0aGUgSUVURiBMYXN0IENhbGwuJm5ic3A7 IEknbSBob3Bpbmcgbm90IHRvIG5lZWQgdG8gbW92ZSBpdCBvdXQgcGFzdCB0aGlzIHRlbGVjaGF0 LCBidXQgaXQgaXMgd2hhdCB0aGUgYXV0aG9ycyBtYWtlIGl0Lg0KPG86cD48L286cD48L3A+DQo8 cD5SZWdhcmRzLCA8YnI+DQpBbGlhIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEphbiAxMiwgMjAxNSA5OjA3IFBNLCAmcXVvdDtMb2EgQW5kZXJzc29uJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51Ij5sb2FAcGkubnU8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvbGtzLDxicj4NCjxicj4N CkkgZ3Vlc3MgdGhhdCB0aGlzIHF1ZXN0aW9uIGNhbWUgZnJvbSBBbGlhLCBhbmQgYXQgbGVhc3Qg aW4gcGFydCBpczxicj4NCm1vdGl2YXRlZCB0aGF0IHRoZSBkcmFmdCBpcyBvbiB0aGUgSUVTRyBh Z2VuZGEgSmFuIDIyLiBJIGtub3cgdGhhdCB0aGVyZTxicj4NCmFyZSBhIG51bWJlciBvZiBhY3Rp dml0aWVzIGdvaW5nIG9uIGluIHBhcmFsbGVsLCBidXQgaXQgd291bGQgYmUgbmljZTxicj4NCmlm IHdlIGNvdWxkIG1lZXQgdGhlIGRhdGUuPGJyPg0KPGJyPg0KL0xvYTxicj4NCjxicj4NCk9uIDIw MTUtMDEtMTIgMjM6MDIsIEJsYWNrLCBEYXZpZCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIGRyYWZ0IGF1 dGhvciB0ZWFtIGlzIHdvcmtpbmcgb24gdGhhdCByZXZpc2lvbiwgc2hvdWxkIGJlIHN1Ym1pdHRl ZCBpbiBuZXh0IGZldyBkYXlzLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQotLURhdmlkPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IG1wbHMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo YWxmIE9mIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMTIsIDIw MTUgOTo1MCBBTTxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47DQo8 YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8L2E+OyBM b2E8YnI+DQpBbmRlcnNzb247IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbbXBsc10gSUQgVHJhY2tl ciBTdGF0ZSBVcGRhdGUgTm90aWNlOiAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC08YnI+DQow OS50eHQmZ3Q7PGJyPg0KPGJyPg0KSUVTRyBzdGF0ZSBjaGFuZ2VkIHRvIFdhaXRpbmcgZm9yIEFE IEdvLUFoZWFkOjpSZXZpc2VkIEktRCBOZWVkZWQgZnJvbSBXYWl0aW5nPGJyPg0KZm9yIEFEIEdv LUFoZWFkPGJyPg0KSSBhbSB3YWl0aW5nIGZvciBhbiB1cGRhdGVkIGRyYWZ0IHRoYXQgaGFuZGxl cyBteSByZXZpZXcgY29tbWVudHMuJm5ic3A7IEkgc2F3IGE8YnI+DQpyZXNwb25zZSBmcm9tIERh dmlkIEJsYWNrLCBidXQgbm8gZnVydGhlcjxicj4NCmFjdGlvbi48YnI+DQpJRCBUcmFja2VyIFVS TDogPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1w bHMtaW4tdWRwLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW1wbHMtaW4tdWRwLzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxz QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBsczwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWwwMS5odWF3ZWkuY29tPC9hPjxicj4NClNlbmlvciBN UExTIEV4cGVydCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWls dG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+DQpsb2FAcGkubnU8L2E+PGJyPg0KSHVhd2Vp IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiA8YSBo cmVmPSJ0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHRhcmdldD0iX2JsYW5rIj4NCiYj NDM7NDYgNzM5IDgxIDIxIDY0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949362E05D1MX104CL02corpemcc_-- From nobody Tue Jan 13 17:17:03 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB581ACE2E for ; Tue, 13 Jan 2015 17:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK-iiZeuxjmE for ; Tue, 13 Jan 2015 17:16:57 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778451ACE27 for ; Tue, 13 Jan 2015 17:16:57 -0800 (PST) Received: by mail-yk0-f179.google.com with SMTP id 19so2937873ykq.10 for ; Tue, 13 Jan 2015 17:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NMslpfQHc7VHluiApRHro+u53umtGXueNpWx0Q8atPM=; b=w0D4GvmT2vi7hBkX5YECNKNjW+2s4JHNXoJzjsrVPiJHL62QxWggjrQRcamj5xe7HZ yckwdY0JRl4mj7cYbmz/VedOREdsQ9TjQjHTmyZXJnzS/GmZVw8anRM24aPbS9gx+CTi HKob6oRnoD4YOWynJ3dgMRV7/R8YkCjLB1uJzk1xFKmpzRq1LVQRXCjcabeXyBPuxp/r zf45wgKi+qfBQYKKSDZtrVUhNdnOkPKSZ5crM6x5qMArf6SKgj+ONiutMbcMx0qxVWRA GXVZERSChYw1jiKF+vNAC9NYa+xnZ8AGp5hoPhMFHyY2hA5k8MSCppCfCM+VuDTMqfnR CT9A== MIME-Version: 1.0 X-Received: by 10.170.119.7 with SMTP id l7mr535105ykb.51.1421198216711; Tue, 13 Jan 2015 17:16:56 -0800 (PST) Received: by 10.170.133.18 with HTTP; Tue, 13 Jan 2015 17:16:56 -0800 (PST) Received: by 10.170.133.18 with HTTP; Tue, 13 Jan 2015 17:16:56 -0800 (PST) In-Reply-To: References: <20150112145004.17839.42580.idtracker@ietfa.amsl.com> <54B4A801.3010008@pi.nu> Date: Tue, 13 Jan 2015 20:16:56 -0500 Message-ID: From: Alia Atlas To: "Black, David" Content-Type: multipart/alternative; boundary=001a1137a79edcd637050c927ee3 Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, "mpls-chairs@tools.ietf.org" , "" , mpls@ietf.org Subject: Re: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 01:17:01 -0000 --001a1137a79edcd637050c927ee3 Content-Type: text/plain; charset=UTF-8 Thanks! On Jan 13, 2015 5:09 PM, "Black, David" wrote: > The authors intend to get something posted in time for the draft to > remain on this telechat. > > > > Thanks, > --David > > > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > *Sent:* Tuesday, January 13, 2015 12:30 AM > *To:* Loa Andersson > *Cc:* Black, David; ; mpls@ietf.org; > draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org > *Subject:* Re: [mpls] ID Tracker State Update Notice: > > > > > Yes, it was in my AD Review which was done before the IETF Last Call. I'm > hoping not to need to move it out past this telechat, but it is what the > authors make it. > > Regards, > Alia > > On Jan 12, 2015 9:07 PM, "Loa Andersson" wrote: > > Folks, > > I guess that this question came from Alia, and at least in part is > motivated that the draft is on the IESG agenda Jan 22. I know that there > are a number of activities going on in parallel, but it would be nice > if we could meet the date. > > /Loa > > On 2015-01-12 23:02, Black, David wrote: > > The draft author team is working on that revision, should be submitted in > next few days. > > Thanks, > --David > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: Monday, January 12, 2015 9:50 AM > To: mpls-chairs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; Loa > Andersson; mpls@ietf.org > Subject: [mpls] ID Tracker State Update Notice: 09.txt> > > IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from > Waiting > for AD Go-Ahead > I am waiting for an updated draft that handles my review comments. I saw a > response from David Black, but no further > action. > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a1137a79edcd637050c927ee3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks!

On Jan 13, 2015 5:09 PM, "Black, David"= ; <david.black@emc.com> wr= ote:

The authors intend to get something posted in = time for the draft to remain on this telechat.

=C2=A0

Thanks,
--David

=C2=A0

From: Alia Atl= as [mailto:akatlas@g= mail.com]
Sent: Tuesday, January 13, 2015 12:30 AM
To: Loa Andersson
Cc: Black, David; <mpls-ads@tools.ietf.org>; mpls@ietf.org; draft-ietf-mpls-in-udp@tools.iet= f.org; = mpls-chairs@tools.ietf.org
Subject: Re: [mpls] ID Tracker State Update Notice: <draft-ietf-m= pls-in-udp-09.txt>

=C2=A0

Yes, it was in my AD Review which was done before the IETF Last Call.=C2= =A0 I'm hoping not to need to move it out past this telechat, but it is= what the authors make it.

Regards,
Alia

On Jan 12, 2015 9:07 PM, "Loa Andersson" &= lt;loa@pi.nu> wrote:<= u>

Folks,

I guess that this question came from Alia, and at least in part is
motivated that the draft is on the IESG agenda Jan 22. I know that there are a number of activities going on in parallel, but it would be nice
if we could meet the date.

/Loa

On 2015-01-12 23:02, Black, David wrote:

The draft author team= is working on that revision, should be submitted in next few days.

Thanks,
--David

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of IETF Secretariat
Sent: Monday, January 12, 2015 9:50 AM
To: mpls-ch= airs@tools.ietf.org; = draft-ietf-mpls-in-udp@tools.ietf.org; Loa
Andersson; mpls@ietf.org=
Subject: [mpls] ID Tracker State Update Notice: <draft-ietf-mpls-in-udp-=
09.txt>

IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Wait= ing
for AD Go-Ahead
I am waiting for an updated draft that handles my review comments.=C2=A0 I = saw a
response from David Black, but no further
action.
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/

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


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

--001a1137a79edcd637050c927ee3-- From nobody Wed Jan 14 00:00:28 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7031B1A8AA3 for ; Wed, 14 Jan 2015 00:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBdqDNNH9gOb for ; Wed, 14 Jan 2015 00:00:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EED1A90F7 for ; Wed, 14 Jan 2015 00:00:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114080024.24843.60658.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 00:00:24 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 08:00:27 -0000 Changed milestone "Submit draft-ietf-mpls-mldp-node-protection for publication", set due date to March 2015 from October 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Wed Jan 14 00:37:56 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895691A1B3A; Wed, 14 Jan 2015 00:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJNOrD9ykBqH; Wed, 14 Jan 2015 00:37:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 120901A8A42; Wed, 14 Jan 2015 00:37:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114083752.21576.78898.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 00:37:52 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-10.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 08:37:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Encapsulating MPLS in UDP Authors : Xiaohu Xu Nischal Sheth Lucy Yong Ross Callon David Black Filename : draft-ietf-mpls-in-udp-10.txt Pages : 17 Date : 2015-01-14 Abstract: This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol) for situations where UDP encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. The MPLS-in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of co-operating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in- UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 14 00:37:59 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78621A8AA3 for ; Wed, 14 Jan 2015 00:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJfy2wfz0Smf; Wed, 14 Jan 2015 00:37:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 474A81A8ADB; Wed, 14 Jan 2015 00:37:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, "Loa Andersson" , mpls@ietf.org, akatlas@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114083752.21576.57234.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 00:37:52 -0800 Archived-At: Subject: [mpls] New Version Notification - draft-ietf-mpls-in-udp-10.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 08:37:55 -0000 A new version (-10) has been submitted for draft-ietf-mpls-in-udp: http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-udp-10.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Jan 14 14:45:04 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E091ACEF9; Wed, 14 Jan 2015 14:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6jP7vqOAoyr; Wed, 14 Jan 2015 14:44:44 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 2781B1ACEEF; Wed, 14 Jan 2015 14:44:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 461F61832B9; Wed, 14 Jan 2015 14:43:36 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150114224336.461F61832B9@rfc-editor.org> Date: Wed, 14 Jan 2015 14:43:36 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7438 on Multipoint LDP (mLDP) In-Band Signaling with Wildcards X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 22:44:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7438 Title: Multipoint LDP (mLDP) In-Band Signaling with Wildcards Author: IJ. Wijnands, Ed., E. Rosen, A. Gulko, U. Joorde, J. Tantsura Status: Standards Track Stream: IETF Date: January 2015 Mailbox: ice@cisco.com, erosen@juniper.net, arkadiy.gulko@thomsonreuters.com, uwe.joorde@telekom.de, jeff.tantsura@ericsson.com Pages: 16 Characters: 36744 Updates: RFC 6826, RFC 7246 I-D Tag: draft-ietf-mpls-mldp-in-band-wildcard-encoding-03.txt URL: https://www.rfc-editor.org/info/rfc7438 There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label Switched Path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or Bidirectional Multicast trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP Any-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jan 14 20:31:26 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841B21ACEED for ; Wed, 14 Jan 2015 20:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cQ4S6fbwiKp for ; Wed, 14 Jan 2015 20:31:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885A81ACEE8 for ; Wed, 14 Jan 2015 20:31:22 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1429.namprd05.prod.outlook.com (25.160.107.151) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 15 Jan 2015 04:30:59 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0059.007; Thu, 15 Jan 2015 04:30:59 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: working group last call for draft-ietf-mpls-lsp-ping-registry-00 Thread-Index: AdAwfA5Rl6NPHWj3TvCQ85M9DnILEA== Date: Thu, 15 Jan 2015 04:30:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BY1PR0501MB1429; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1429; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(2656002)(92566002)(87936001)(40100003)(19580405001)(106356001)(33656002)(19580395003)(105586002)(101416001)(97736003)(122556002)(76576001)(77156002)(62966003)(54356999)(50986999)(54206007)(54606007)(66066001)(230783001)(102836002)(74316001)(15975445007)(99286002)(110136001)(68736005)(86362001)(2501002)(575784001)(64706001)(229853001)(46102003)(2351001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1429; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB14304975E932ADA60FA1BF15A54E0BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2015 04:30:59.1554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1429 Archived-At: Cc: "" , "draft-ietf-mpls-lsp-ping-registry@tools.ietf.org" Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 04:31:24 -0000 --_000_BY1PR0501MB14304975E932ADA60FA1BF15A54E0BY1PR0501MB1430_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-lsp-ping-registry-00. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have stated on the working group mailing list that they are not aware of any IPR that relates to this draft. This working group last call ends January 29, 2015. Ross for the MPLS wg chairs --_000_BY1PR0501MB14304975E932ADA60FA1BF15A54E0BY1PR0501MB1430_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
This is to initiate a two week working group last call on
draft-ietf-mpls-lsp-ping-registry-00.
 
Please send your comments to the mpls wg mailing list (mpls@ietf.org).=
 
There are no IPR disclosures against this document. All the authors ha= ve
stated on the working group mailing list that they are not aware of an= y
IPR that relates to this draft.
 
This working group last call ends January 29, 2015. 
 
Ross
for the MPLS wg chairs
 
 --_000_BY1PR0501MB14304975E932ADA60FA1BF15A54E0BY1PR0501MB1430_-- From nobody Thu Jan 15 06:10:38 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45251B2BF2 for ; Thu, 15 Jan 2015 06:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X57S9oH1ySx6 for ; Thu, 15 Jan 2015 06:10:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF1B1B2BEC for ; Thu, 15 Jan 2015 06:10:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115141035.12924.75841.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:10:35 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:10:37 -0000 URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 06:15:14 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2851B2BF2 for ; Thu, 15 Jan 2015 06:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKX1XtEuDgXm for ; Thu, 15 Jan 2015 06:15:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F39761B2BE0 for ; Thu, 15 Jan 2015 06:15:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115141509.19920.9625.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:15:09 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:15:12 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-ip-pw-capability for publication", set due date to March 2015 from June 2014, reverted to not being resolved. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 06:16:33 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9221B2BDF for ; Thu, 15 Jan 2015 06:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ajCC2Loeyp4 for ; Thu, 15 Jan 2015 06:16:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E05531B2BEE for ; Thu, 15 Jan 2015 06:16:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115141629.23332.35187.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:16:29 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:16:31 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-ipv6 for publication", set due date to March 2015 from May 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 06:20:09 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6611B2BF2 for ; Thu, 15 Jan 2015 06:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9_h4yaVSU3P for ; Thu, 15 Jan 2015 06:20:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE91B2BF3 for ; Thu, 15 Jan 2015 06:20:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115142005.15731.61523.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:20:05 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:20:08 -0000 URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 06:21:47 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157611B2BF2 for ; Thu, 15 Jan 2015 06:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7BP4Gurkc7L for ; Thu, 15 Jan 2015 06:21:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E591B2BF3 for ; Thu, 15 Jan 2015 06:21:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115142142.25181.25870.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:21:42 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:21:45 -0000 Changed milestone "Submit draft-ietf-mpls-lsp-ping-registry for publication", set due date to May 2015 from January 2015. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 06:45:30 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9251F1B2BFF for ; Thu, 15 Jan 2015 06:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOc5HTIwbBby for ; Thu, 15 Jan 2015 06:45:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 622AE1B2C01 for ; Thu, 15 Jan 2015 06:45:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115144526.2044.1803.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:45:26 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:45:28 -0000 Changed milestone "Submit draft-ietf-mpls-lsp-ping-relay-reply for publication", set due date to May 2015 from November 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 06:46:58 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CFB1B2BEC for ; Thu, 15 Jan 2015 06:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NiyqyqgZKv5 for ; Thu, 15 Jan 2015 06:46:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1921B2BFE for ; Thu, 15 Jan 2015 06:46:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115144654.31189.8076.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:46:54 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:46:57 -0000 Changed milestone "Submit draft-ietf-mpls-lsp-ping-reply-mode-simple for publication", set due date to June 2015 from January 2015. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 06:48:41 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BF91B2BFB for ; Thu, 15 Jan 2015 06:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eIvphr5BM67 for ; Thu, 15 Jan 2015 06:48:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAA11B2C04 for ; Thu, 15 Jan 2015 06:48:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115144836.32140.27334.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:48:36 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:48:39 -0000 Changed milestone "Submit draft-ietf-mpls-mldp-node-protection for publication", set due date to May 2015 from March 2015. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 06:50:59 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718321B2BFB for ; Thu, 15 Jan 2015 06:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuYTJM7JVSVb for ; Thu, 15 Jan 2015 06:50:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70D1B2C03 for ; Thu, 15 Jan 2015 06:50:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115145054.26656.64193.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:50:54 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:50:56 -0000 URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 06:52:31 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A818C1B2BF2 for ; Thu, 15 Jan 2015 06:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B614zI-sUZDW for ; Thu, 15 Jan 2015 06:52:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F331B2C0C for ; Thu, 15 Jan 2015 06:52:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115145225.25593.7958.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 06:52:25 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:52:27 -0000 Changed milestone "Submit draft-ietf-mpls-in-udp for publication", set due date to March 2015 from April 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 07:02:01 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE941B2B24 for ; Thu, 15 Jan 2015 07:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV8Sz7a0j2ET for ; Thu, 15 Jan 2015 07:01:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 740891B2BDF for ; Thu, 15 Jan 2015 07:01:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115150158.9475.91009.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 07:01:58 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 15:02:00 -0000 Changed milestone "Submit draft-ietf-mpls-seamless-mcast for publication", set due date to March 2015 from December 2014. Changed milestone "Submit draft-ietf-mpls-proxy-lsp-ping fpr publication", set due date to March 2015 from January 2015. Changed milestone "Submit draft-ietf-mpls-rfc6374-udp-return-path for publicatiion", set due date to May 2015 from January 2015. Changed milestone "Submit draft-ietf-mpls-seamless-mpls for publication", set due date to May 2015 from October 2014. Changed milestone "Submit draft-ietf-mpls-te-express-path", set due date to July 2015 from September 2014. Changed milestone "Submit draft-ietf-mpls-tp-linear-protection-mib", set due date to August 2015 from August 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 07:03:51 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A13C1B2BC5 for ; Thu, 15 Jan 2015 07:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27-_r61qech8 for ; Thu, 15 Jan 2015 07:03:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9861D1B2C0E for ; Thu, 15 Jan 2015 07:03:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115150348.10500.84197.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 07:03:48 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 15:03:51 -0000 Changed milestone "Submit draft-ietf-mpls-p2mp-loose-path-reopt for publicatiion", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 15 14:44:05 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6A21A9089; Thu, 15 Jan 2015 14:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9icG22_yAq8; Thu, 15 Jan 2015 14:43:59 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E571A9050; Thu, 15 Jan 2015 14:43:59 -0800 (PST) Received: by mail-oi0-f50.google.com with SMTP id x69so14772145oia.9; Thu, 15 Jan 2015 14:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ffb+amJnM+sEvCYKdKFCy0xFCccCbiLNZMR9VM49k4Y=; b=EszqBhr1DKBOIYds8ntISJGm7pjRfkByzfjlEZ6H6YGn4CY3MOcX3kyw/ymKMdzhWZ 2eQbIWem9pPqagfStbdCh1rQMSQGc64WaDEvfh9sLCTyXwP6gn8GU6fJi1mzN1rWC88w q9SS/AI1tLeXiBaGZCWW1qo//CPJL16oguGRrdmw0ZpFx21LN/ymfA0WMVJ0MLb/VlMU XuG8LGdyRfT7NyEMliKgSolIGitTQWhmR73DKSBvga0Pk3P8ZYJQpmwiEIZI0OBL0YR+ 30W2s67v6mAzqk4LqhpgRiuN/K2+DmMkZ55r2wz5wVlnJIKwvW1k97CAfXGHZx5Q/e4b BhpA== MIME-Version: 1.0 X-Received: by 10.182.211.70 with SMTP id na6mr7519659obc.13.1421361838416; Thu, 15 Jan 2015 14:43:58 -0800 (PST) Received: by 10.202.197.141 with HTTP; Thu, 15 Jan 2015 14:43:58 -0800 (PST) Date: Thu, 15 Jan 2015 14:43:58 -0800 Message-ID: From: Chen Liu To: mpls@ietf.org, gsmp@ietf.org, manet@ietf.org, sip@ietf.org Content-Type: multipart/alternative; boundary=e89a8f838df779e9ed050cb89706 Archived-At: Subject: [mpls] MISSION 2015 - IEEE Workshop on Management Issues in SDN, SDI and NFV X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 22:44:02 -0000 --e89a8f838df779e9ed050cb89706 Content-Type: text/plain; charset=UTF-8 --------------------------------------------------------------------------------------------------------------------------- Apologies for cross-postings! --------------------------------------------------------------------------------------------------------------------------- IEEE Workshop on Management Issues in SDN, SDI and NFV LONDON, UK, APRIL 13-17, 2015 http://sites.ieee.org/netsoft/workshop/MISSION/ CALL FOR PAPERS SCOPE The IEEE International Workshop on Management Issues in Software defined network, Software defined infrastructure and network function virtualizatION (MISSION 2015) will be held between April 13-17, 2015 in London, U.K. at the Cruciform Building of University College London (UCL) along with 1st IEEE International Conference on Network Softwarization (NetSoft 2015). Software is increasing flexibility and programmability of infrastructure in SDN, SDI and NFV. This softwarization trend has materialized new product and services that lead to significant business benefits. To realize these benefits, we also need to rethink the management issues along with making progress in core functionalities for SDN, SDI and NFV. A holistic system-oriented innovation approach is needed to redesign infrastructure management operations, NMS artefacts and functionalities at multiple levels. The MISSION 2015 workshop will address these new and emerging management issues in SDN, SDI and NFV. TOPICS OF INTEREST Authors are invited to submit papers that fall into the area of software-defined and virtualized infrastructures. Topics of interest include, but are not limited to, the following: - System management challenges in SDN, SDI, NFV - Network management practices and business procedures for SDN, NFV, SDI in telco and enterprise data center infrastructures - New paradigms in network operations, administration and management for SDN, SDI and NFV - Management challenges in mobile and wireless SDN and NFV environment - Service orchestration in converged network-compute and data center management - Reliability issues in SDN and NFV Network management & operations related automation, troubleshooting and administration tools for SDN, SDI and NFV - Cloud based network and system management application paradigms for SDN , SDI and NFV - Application of artificial intelligence (AI), machine learning (ML), analytics and big data in network and system management of SDN, SDI and NFV - Insights about Network Management System (NMS) architectural requirements & analysis - User experience, user interface design issues and challenges in NMS for SDN, SDI, NFV ethnographic studies on network operations centers, usability studies of management applications PAPER SUBMISSION Authors are invited to submit only original papers not published or submitted for publication elsewhere. Papers should be within 6 pages, in IEEE 2-column US-Letter style using IEEE Conference ( www.ieee.org/conferences_events/conferences/publishing/templates.html) templates and submitted in PDF format via EDAS at: http://edas.info/19315. Papers exceeding these limits, multiple submissions elsewhere, and self-plagiarized papers will be rejected without further review. All submitted papers will be subject to a peer-review process. Accepted and presented papers will be published in the MISSION 2015 Workshop Proceedings and submitted to IEEE Xplore. IMPORTANT DATES - Paper Submission: January 30, 2015 - Notification of Acceptance: February 28, 2015 - Camera Ready Papers: March 13, 2015 WORKSHOP CO-CHAIRS - Kashinath Basu, Oxford Brookes University, UK - Chen Liu, Microsoft, US NETSOFT WORKSHOP CO-CHAIRS - Amitava Biswas, Cisco Systems, US - Noura Limam, University of Waterloo, Canada NETSOFT GENERAL CO-CHAIRS - Prosper Chemouil, Orange Labs, France - George Pavlou, University College London, UK IEEE SDN Initiative Chair - Antonio Manzalini, Telecom Italia, Italy TECHNICAL SPONSORS - IEEE Communications Society, IEEE Computer Society, IEEE Consumer Electronics Society and IEEE Signal Processing --e89a8f838df779e9ed050cb89706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
------------------------------------------------= ---------------------------------------------------------------------------=
Apologies for cross-postings!
-------------------------------------= ---------------------------------------------------------------------------= -----------

IEEE Workshop on Management Issu= es in SDN, SDI and NFV
LONDON, UK, APRIL 13-17, 2015
http://site= s.ieee.org/netsoft/workshop/MISSION/

CALL FOR PAPERS

SC= OPE

The IEEE International Workshop on Management Issues in Software= defined network, Software defined infrastructure and network function virt= ualizatION (MISSION 2015) will be held between April 13-17, 2015 in London,= U.K. at the Cruciform Building of University College London (UCL) along wi= th 1st IEEE International Conference on Network Softwarization (NetSoft 201= 5). Software is increasing flexibility and programmability of infrastructur= e in SDN, SDI and NFV. This softwarization trend has materialized new produ= ct and services that lead to significant business benefits. To realize thes= e benefits, we also need to rethink the management issues along with making= progress in core functionalities for SDN, SDI and NFV. A holistic system-o= riented innovation approach is needed to redesign infrastructure management= operations, NMS artefacts and functionalities at multiple levels. The MISS= ION 2015 workshop will address these new and emerging management issues in = SDN, SDI and NFV.

TOPICS OF INTEREST

Authors are invited to s= ubmit papers that fall into the area of software-defined and virtualized in= frastructures. Topics of interest include, but are not limited to, the foll= owing:

- System management challenges in SDN, SDI, NFV
- Network= management practices and business procedures for SDN, NFV, SDI in telco an= d enterprise data center infrastructures
- New paradigms in network ope= rations, administration and management for SDN, SDI and NFV
- Managemen= t challenges in mobile and wireless SDN and NFV environment
- Service o= rchestration in converged network-compute and data center management
- = Reliability issues in SDN and NFV
Network management & operations r= elated automation, troubleshooting and administration tools for SDN, SDI an= d NFV
- Cloud based network and system management application paradigms= for SDN , SDI and NFV
- Application of artificial intelligence (AI), m= achine learning (ML), analytics and big data in network and system manageme= nt of SDN, SDI and NFV
- Insights about Network Management System (NMS)= architectural requirements & analysis
- User experience, user inte= rface design issues and challenges in NMS for SDN, SDI, NFV ethnographic st= udies on network operations centers, usability studies of management applic= ations


PAPER SUBMISSION

Authors are invited to submit onl= y original papers not published or submitted for publication elsewhere. Pap= ers should be within 6 pages, in IEEE 2-column US-Letter style using IEEE C= onference (www.ieee.org/conferences_events/= conferences/publishing/templates.html) templates and submitted in PDF f= ormat via EDAS at: htt= p://edas.info/19315. Papers exceeding these limits, multiple submission= s elsewhere, and self-plagiarized papers will be rejected without further r= eview. All submitted papers will be subject to a peer-review process. Accep= ted and presented papers will be published in the MISSION 2015 Workshop Pro= ceedings and submitted to IEEE Xplore.


IMPORTANT DATES

- = Paper Submission: January 30, 2015
- Notification of Acceptance: Februa= ry 28, 2015
- Camera Ready Papers: March 13, 2015

WORKSHOP CO-CH= AIRS

- Kashinath Basu, Oxford Brookes University, UK
- Chen Liu,= Microsoft, US


NETSOFT WORKSHOP CO-CHAIRS

- Amitava Biswa= s, Cisco Systems, US
- Noura Limam, University of Waterloo, Canada

=


NETSOFT GENERAL CO-CHAIRS

- Prosper Chemouil, Orange Labs, Fr= ance
- George Pavlou, University College London, UK


IEEE SDN= Initiative Chair

- Antonio Manzalini, Telecom Italia, Italy

=
TECHNICAL SPONSORS

- IEEE Communications Society, IEEE Computer = Society, IEEE Consumer Electronics Society and IEEE Signal Processing

<= /div> --e89a8f838df779e9ed050cb89706-- From nobody Thu Jan 15 14:46:26 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2351A9050; Thu, 15 Jan 2015 14:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csqWX8HeFcWC; Thu, 15 Jan 2015 14:46:16 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3587B1A8FD6; Thu, 15 Jan 2015 14:46:16 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp4so571295obc.1; Thu, 15 Jan 2015 14:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lR+ynT3cRDjWjTpPCuR24tG/1hHRw8plcsfkNRgmHnE=; b=DRoYHnrPmCg9Eva+urWMZn6nIkMPzwdywHf1Sbta1DpK3m75yf9gpS7rtQMoX/tdnO 2jLWr155tdRxjA1wq+mSqLn9Nq3zudne2JE/FVvoaGc3R64wc+RtO2wVjV+FkEKXNiW9 CrJqnP46hEjaP+1NdQxU0QgFnSUnOBWNcX0FXA4lWIyUqCJCcFMzjNY4dE3WNhCLkUPu 1trSZpRyKHP1UJogXxwVI0a5PGMCtUno9lee2pk6y1R2V+Ag8vCJuwxvAI7LYh64dHHm lmI9Di9uC5U8RQGGOC5pUIcdAc7hTPkT7WrwaNV5/izG23UKwgyzkOGKqTNwfKY3/a81 y9ww== MIME-Version: 1.0 X-Received: by 10.202.226.2 with SMTP id z2mr7122990oig.64.1421361975442; Thu, 15 Jan 2015 14:46:15 -0800 (PST) Received: by 10.202.197.141 with HTTP; Thu, 15 Jan 2015 14:46:15 -0800 (PST) Date: Thu, 15 Jan 2015 14:46:15 -0800 Message-ID: From: Chen Liu To: mpls@ietf.org, gsmp@ietf.org, manet@ietf.org, sip@ietf.org Content-Type: multipart/alternative; boundary=001a1141bac0a4cce1050cb89feb Archived-At: Subject: [mpls] MASONS 2015 - IEEE International Workshop on Manageability and Security of Network Function Virtualization and Software Defined Network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 22:46:19 -0000 --001a1141bac0a4cce1050cb89feb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ---------------------------------------------------------------------------= ------------------------------------------------ Apologies for cross-postings! ---------------------------------------------------------------------------= ------------------------------------------------ Call for Papers IEEE International Workshop on Manageability and Security of Network Function Virtualization and Software Defined Network (MASONS) With ICCCN 2015 at Las Vegas, Aug 3 =E2=80=93 6, 2015 http://www.icccn.org/icccn15/ MASONS 2015 is Technically Co-Sponsored by the IEEE Communication Society 1. Theme Today, many research organizations in academia, government labs and industry are exploring SDN and NFV technologies to study and materialize their benefits in real world networks. These benefits are enabling automation, reducing time to market in case of new service introductions, optimization and/or improving overall economics of network and system management and operations. However to materialize the benefits of SDN and NFV at larger scale across multiple domains, similar to today=E2=80=99s int= ernet, additional investigations are needed which should focus beyond the core SDN, NFV features and functionalities. This involves: development of multi-domain SDN network to support Internet; large scale deployment of novel applications, identification of technological and operational gaps in research and development over the longer term to increase the capability of SDN and NFV powered networks, and better integrate them with existing public Internet and emerging cloud technologies; Identification of security, manageability gaps, including opportunities to build in additional levels of security, resilience and management capabilities. 2. Topics of interest This workshop aims to show case and disseminate new ideas and high quality research on manageability and security of Software Defined Network and Network Function Virtualization. We solicit original research articles, review papers, theoretical studies, and practical software systems incorporating new paradigms, experimental prototypes, and insightful requirement analysis with the above theme including, but not limited to the topics below: * Design, requirements and prototypes of Software Defined Exchanges (SDX) to enable interoperability and use of new approaches with the current Internet infrastructure. * Security, privacy, authentication, trust, verification for SDN and NFV. * Integration of compute, storage and network under the Software Defined Infrastructure (SDI) paradigm. * Analysis of new management challenges that SDN and NFV has introduced. * Network management practices and business processes for SDN and NFV, in service provider and data center infrastructures. * Tools and operational procedures for managing SDN. * New paradigms in network operations, administration and management (OAM), service orchestration, service engineering, converged network-compute and data center management. * Software Defined Network (SDN), abstraction, programmability, application Interface, south and northbound API. * Network Function Virtualization (NFV), distributed control, virtual switches, routing virtualization. * Network system management, orchestration, resource management and optimization, integration, interoperability. * Network operations management related automation, troubleshooting and management tools. * Cloud based network and system management application paradigms. * Application of artificial intelligence (AI), machine learning (ML), analytics and big data in network and system management. * Insights about Network Management System architectural requirements analysis. * Scalability of SDN, NFV, SDI, NMS systems. * User experience, user interface design issues and challenges in NMS for SDN, NFV, ethnographic studies on network operations centers, usability studies of management applications. 3. Instructions for IEEE MASONS 2015 Workshop Authors: Submitted manuscripts must be formatted in standard IEEE camera ready format (double column, 10 pt font) and must be submitted via EasyChair ( http://www.easychair.org/) as PDF files (formatted for 8.5=C3=9711 inch pap= er). It should be no longer than 6 pages with up to two extra pages given the authors are willing to pay an over-length charge per extra page. The detailed information can be found in the ICCCN 2015 (Las Vegas) website. For any workshop related questions or additional information please contact the General, TPC, or Workshop Chairs. Submitted papers should not be previously published in or be under consideration for publication in another conference or journal. Paper titles and/or author names cannot be changed and/or added to the papers once papers are submitted to ICCCN 2015 for review. Submissions must include a title, abstract, keywords, author(s) and affiliation(s) with postal and email address(es) and phone number(s). A paper abstract must be registered on EasyChair by the deadline indicated below. 4. Important dates: * Abstract Due: Mar 2, 2015 * Paper Due: Mar 10, 2015 * Acceptance Notification: Apr 13, 2015 * Camera Ready Due: May 8, 2015 5. Review and Publication of Manuscripts: Submitted papers will be reviewed by the ICCCN 2015 TPC members and judged on originality, technical correctness, relevance, and quality of presentation. An accepted paper must be presented at the conference venue by one (who registered/paid full author reg. fee) of authors to be included in the conference venue. Each full registration covers up to two ICCCN 2015 conference papers authored by the registered/paid author. Accepted and presented papers will be published in the conference proceedings and submitted to IEEE Xplore as well as other Abstracting and Indexing (A&I) databases. The page limit for papers is 6 pages. Papers should be submitted on EDAS, the link for this workshop will be published here shortly. Papers of special merit will be selected for possible fast track at a journal special issue at IJCNDS (see details at http://www.inderscience.com/info/ingeneral/cfplist.php?jcode=3Dijcnds and http://www.manageability-at-scale.org/cfp/). 6. Workshop chairs * Inder Monga, ESnet and LBNL, USA, imonga@es.net * Amitava Biswas, Cisco Systems, USA, amitavabiswas@ieee.org * Chen Liu, Microsoft, USA, chenliu419@gmail.com --001a1141bac0a4cce1050cb89feb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
------------------------------------------------= ---------------------------------------------------------------------------=
Apologies for cross-postings!
-------------------------------------= ---------------------------------------------------------------------------= -----------

Call for Papers

IEEE Int= ernational Workshop on Manageability and Security of Network Function Virtu= alization and Software Defined Network (MASONS)=C2=A0
With ICCCN 2015 a= t Las Vegas, Aug 3 =E2=80=93 6, 2015
http://www.icccn.org/icccn15/

MASONS 20= 15 is Technically Co-Sponsored by the IEEE Communication Society

1. T= heme

Today, many research organizations in academia, government labs = and industry are exploring SDN and NFV technologies to study and materializ= e their benefits in real world networks. These benefits are enabling automa= tion, reducing time to market in case of new service introductions, optimiz= ation and/or improving overall economics of network and system management a= nd operations. However to materialize the benefits of SDN and NFV at larger= scale across multiple domains, similar to today=E2=80=99s internet, additi= onal investigations are needed which should focus beyond the core SDN, NFV = features and functionalities. This involves: development of multi-domain SD= N network to support Internet; large scale deployment of novel applications= , identification of technological and operational gaps in research and deve= lopment over the longer term to increase the capability of SDN and NFV powe= red networks, and better integrate them with existing public Internet and e= merging cloud technologies; Identification of security, manageability gaps,= including opportunities to build in additional levels of security, resilie= nce and management capabilities.

2. Topics of interest

This wor= kshop aims to show case and disseminate new ideas and high quality research= on manageability and security of Software Defined Network and Network Func= tion Virtualization. We solicit original research articles, review papers, = theoretical studies, and practical software systems incorporating new parad= igms, experimental prototypes, and insightful requirement analysis with the= above theme including, but not limited to the topics below:
* Design, = requirements and prototypes of Software Defined Exchanges (SDX) to enable i= nteroperability and use of new approaches with the current Internet infrast= ructure.
* Security, privacy, authentication, trust, verification for SD= N and NFV.
* Integration of compute, storage and network under the Softw= are Defined Infrastructure (SDI) paradigm.
* Analysis of new management = challenges that SDN and NFV has introduced.
* Network management practi= ces and business processes for SDN and NFV, in service provider and data ce= nter infrastructures.
* Tools and operational procedures for managing SD= N.
* New paradigms in network operations, administration and management = (OAM), service orchestration, service engineering, converged network-comput= e and data center management.
* Software Defined Network (SDN), abstract= ion, programmability, application Interface, south and northbound API.
*= Network Function Virtualization (NFV), distributed control, virtual switch= es, routing virtualization.
* Network system management, orchestration, = resource management and optimization, integration, interoperability.
* N= etwork operations management related automation, troubleshooting and manage= ment tools.
* Cloud based network and system management application para= digms.
* Application of artificial intelligence (AI), machine learning (= ML), analytics and big data in network and system management.
* Insights= about Network Management System architectural requirements analysis.
* = Scalability of SDN, NFV, SDI, NMS systems.
* User experience, user inter= face design issues and challenges in NMS for SDN, NFV, ethnographic studies= on network operations centers, usability studies of management application= s.

3. Instructions for IEEE MASONS 2015 Workshop Authors:

Submi= tted manuscripts must be formatted in standard IEEE camera ready format (do= uble column, 10 pt font) and must be submitted via EasyChair (http://www.easychair.org/) a= s PDF files (formatted for 8.5=C3=9711 inch paper). It should be no longer = than 6 pages with up to two extra pages given the authors are willing to pa= y an over-length charge per extra page. The detailed information can be fou= nd in the ICCCN 2015 (Las Vegas) website. For any workshop related question= s or additional information please contact the General, TPC, or Workshop Ch= airs.

Submitted papers should not be previously published in or be un= der consideration for publication in another conference or journal. Paper t= itles and/or author names cannot be changed and/or added to the papers once= papers are submitted to ICCCN 2015 for review. Submissions must include a = title, abstract, keywords, author(s) and affiliation(s) with postal and ema= il address(es) and phone number(s). A paper abstract must be registered on = EasyChair by the deadline indicated below.

4. Important dates:

= * Abstract Due: Mar 2, 2015
* Paper Due: Mar 10, 2015
* Acceptance No= tification: Apr 13, 2015
* Camera Ready Due: May 8, 2015

5. Review= and Publication of Manuscripts:

Submitted papers will be reviewed by= the ICCCN 2015 TPC members and judged on originality, technical correctnes= s, relevance, and quality of presentation. An accepted paper must be presen= ted at the conference venue by one (who registered/paid full author reg. fe= e) of authors to be included in the conference venue. Each full registratio= n covers up to two ICCCN 2015 conference papers authored by the registered/= paid author. Accepted and presented papers will be published in the confere= nce proceedings and submitted to IEEE Xplore as well as other Abstracting a= nd Indexing (A&I) databases. The page limit for papers is 6 pages. Pape= rs should be submitted on EDAS, the link for this workshop will be publishe= d here shortly.

Papers of special merit will be selected for possible= fast track at a journal special issue at IJCNDS (see details at http://www.inderscience.com/info/ingeneral/cfplist.php?jcode= =3Dijcnds and=C2=A0 http://www.manageability-at-scale.org/cfp/).

<= p>6. Workshop chairs
* Inder Monga, ESnet and LBNL, USA, imonga@es.net
* Amitava Biswas,= Cisco Systems, USA, amitavabiswas@ieee.org
* Chen Liu, Microsoft, USA, chenliu419@gmail.com
--001a1141bac0a4cce1050cb89feb-- From nobody Thu Jan 15 19:27:08 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310CC1A9151 for ; Thu, 15 Jan 2015 19:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSZBmpLgsMCq for ; Thu, 15 Jan 2015 19:27:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 880DA1A9162 for ; Thu, 15 Jan 2015 19:27:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150116032705.12128.20351.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 19:27:05 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 03:27:07 -0000 URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Jan 16 10:26:47 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A205B1B2A19 for ; Fri, 16 Jan 2015 10:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfKIivliJgI1 for ; Fri, 16 Jan 2015 10:26:43 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB221B2A20 for ; Fri, 16 Jan 2015 10:26:42 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id f51so17488336qge.8 for ; Fri, 16 Jan 2015 10:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ehZViS92EoGJR0SpLAPxHuMmui4wtrXOHxjTlb+oD6s=; b=r7OTqt9PQt3mciqMBnKGx1UNKW6fI+T/8RZGr3Ri3peLjn3NKnSB1GaXhNJZERqVql qj53a9uu4UO6iU8cpc8HDdWI3JcY/W0RHsNb5qdNC1U3qpLM4AapOlK2zLDYVyPEqZzz DxAMafgCZqw3JvI3efgXjRN+GKJanchcgUQUPaH+PbrmsfKmZkKm+cmcq0dYaDe23ij+ 4uXkfmsbm5C4lA+vQzqcCU6GmkAMUifnd1Xj2f83swy9jiMAhh+WUi6H5p499emq8v3N iOfc6Fqn1hEVgZz0aSdU3BCBmanXmYugMCgz/MVUYu9aibzaNnL4n5Hb/0mBhaBVCirL +W6w== X-Received: by 10.140.25.169 with SMTP id 38mr16564670qgt.57.1421432801832; Fri, 16 Jan 2015 10:26:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.106 with HTTP; Fri, 16 Jan 2015 10:26:21 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 16 Jan 2015 13:26:21 -0500 Message-ID: To: Ross Callon Content-Type: multipart/alternative; boundary=001a11c12cdc39c3c4050cc91d79 Archived-At: Cc: "mpls@ietf.org" , "" , "draft-ietf-mpls-lsp-ping-registry@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 18:26:45 -0000 --001a11c12cdc39c3c4050cc91d79 Content-Type: text/plain; charset=UTF-8 Ross, This is a short and useful draft that I believe is ready for publication. Cheers, Andy On Wed, Jan 14, 2015 at 11:30 PM, Ross Callon wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-lsp-ping-registry-00. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures against this document. All the authors have > stated on the working group mailing list that they are not aware of any > IPR that relates to this draft. > > This working group last call ends January 29, 2015. > > Ross > for the MPLS wg chairs > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --001a11c12cdc39c3c4050cc91d79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ross,

This is a short and useful draft = that I believe is ready for publication.

Cheers,
Andy

On Wed, Jan 14, 2015 at 11:30 PM, Ross Callon <= ;rcallon@juniper.n= et> wrote:
Working Group,
=C2=A0
This is to initiate a two week working group last call on
draft-ietf-mpls-lsp-ping-registry-00.
=C2=A0
Please send your comments to the mpls wg mailing list (mpls@ietf.org).
=C2=A0
There are no IPR disclosures against this document. All the authors ha= ve
stated on the working group mailing list that they are not aware of an= y
IPR that relates to this draft.
=C2=A0
This working group last call ends January 29, 2015.=C2=A0
=C2=A0
Ross
for the MPLS wg chairs
=C2=A0

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


--001a11c12cdc39c3c4050cc91d79-- From nobody Fri Jan 16 17:58:20 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74281A9127 for ; Fri, 16 Jan 2015 17:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCaYjWCdJZng for ; Fri, 16 Jan 2015 17:58:10 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3EDB1A9126 for ; Fri, 16 Jan 2015 17:58:09 -0800 (PST) Received: from BY2PR05MB192.namprd05.prod.outlook.com (10.242.39.149) by BY2PR05MB190.namprd05.prod.outlook.com (10.242.39.139) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sat, 17 Jan 2015 01:58:07 +0000 Received: from BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.61]) by BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.145]) with mapi id 15.01.0053.000; Sat, 17 Jan 2015 01:58:07 +0000 From: Santosh Esale To: "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-esale-mpls-app-aware-tldp Thread-Index: AQHQB7ntcA+TJ/b/VEG/W2opEeS7r5yG/EIAgDxJ1wCAABZsgA== Date: Sat, 17 Jan 2015 01:58:07 +0000 Message-ID: References: <5472E0DF.5080109@pi.nu> <065601d01385$dff68e80$9fe3ab80$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.239.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=sesale@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BY2PR05MB190; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB190; x-forefront-prvs: 04599F3534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(164054003)(252514010)(199003)(189002)(24454002)(13464003)(479174004)(64706001)(68736005)(2656002)(36756003)(62966003)(86362001)(66066001)(40100003)(87936001)(2501002)(122556002)(19580395003)(77156002)(102836002)(101416001)(83506001)(99286002)(106116001)(2950100001)(2900100001)(97736003)(50986999)(105586002)(92566002)(110136001)(76176999)(54356999)(19580405001)(2351001)(230783001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB190; H:BY2PR05MB192.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2015 01:58:07.5530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB190 Archived-At: Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-esale-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 01:58:13 -0000 KyBtcGxzDQoNCk9uIDEvMTYvMTUsIDQ6MzcgUE0sICJTYW50b3NoIEVzYWxlIiA8c2VzYWxlQGp1 bmlwZXIubmV0PiB3cm90ZToNCg0KPkhpIExpemhvbmcsDQo+ICAgICAgICAgIFRoYW5rIHlvdSBm b3IgdGhlIHJldmlldy4gUGxlYXNlIGZpbmQgc29tZSBhbnN3ZXJzIGlubGluZS4NCj4NCj5PbiAx Mi84LzE0LCAxMTo1OCBQTSwgIkxpemhvbmcgSmluIiA8bGl6aG8uamluQGdtYWlsLmNvbT4gd3Jv dGU6DQo+PkhpIGF1dGhvcnMsDQo+PkkgcmV2aWV3IHRoZSBkb2N1bWVudCwgYW5kIGl0IGlzIHRl Y2huaWNhbGx5IHNvdW5kIGFuZCB1c2VmdWwsIGFuZCByZWFkeQ0KPj5mb3INCj4+YWRvcHRpb24u IFNvbWUgbWlub3IgY29tbWVudHMgYXJlIGFzIGJlbG93Lg0KPj5TZWN0aW9uIDMsICJPbiB0aGUg cmVjZWlwdCBvZiBhIHZhbGlkIFRBQyBUTFYuLi4iLiBZb3UgZG8gbm90IHNheQ0KPj5leHBsaWNp dGx5DQo+PmhvdyB0byBoYW5kbGUgdGhlIEUgYml0LCBpZ25vcmU/DQo+WWVzLCB0aGUgRS1iaXQg c2hvdWxkIGJlIGlnbm9yZWQgb24gcmVjZWlwdCBpbiB0aGUgaW5pdGlhbGl6YXRpb24gbWVzc2Fn ZS4NCj5XZSBoYXZlIGFkZGVkIGl0IHRvIHRoZSBpbml0aWFsaXphdGlvbiBtZXNzYWdlIHByb2Nl ZHVyZSBpbiB0aGUgdXBjb21pbmcNCj52ZXJzaW9uLg0KPg0KPj5TZWN0aW9uIDMsICJJZiBpdCBz ZXRzIHRoZSBzZXNzaW9uIHNldHVwIHJldHJ5IGludGVydmFsIHRvIG1heGltdW0sIHRoZQ0KPj5z ZXNzaW9uIE1BWSBzdGF5IGluIGEgbm9uLW9wZXJhdGlvbmFsIHN0YXRlIi4gIiBub24tb3BlcmF0 aW9uYWwgIiBzaG91bGQNCj4+YmUNCj4+IiBOT04gRVhJU1RFTlQgIiBhY2NvcmRpbmcgZGVmaW5p dGlvbiBpbiBSRkM1MDM2Pw0KPk9raWUsIHVwZGF0ZWQuDQo+DQo+PlNlY3Rpb24gMywgaGF2ZSB5 b3UgY29uc2lkZXIgdGhlIG92ZXJmbG93IG9mIENvbmZpZ3VyYXRpb24gU2VxdWVuY2UNCj4+TnVt YmVyPw0KPj5JIGRpZCBub3Qgc2VlIHRoYXQgaW4gUkZDNTAzNi4NCj5JIHRoaW5rIGl0IGlzIGlt cGxpY2l0IGluIFJGQzUwMzYuIE1vc3Qgb2YgdGhlIGltcGxlbWVudGF0aW9ucyBoYW5kbGUNCj50 aGUgb3ZlcmZsb3cuIElmIG5lY2Vzc2FyeSwgSSB0aGluayB3ZSBzaG91bGQgZ2V0IHRoYXQgZml4 ZWQgaW4gUkZDNTAzNi4NCj4NCj4+U2VjdGlvbiA0LCBpdCBzZWVtcyB0aGVyZSBpcyBzdGlsbCBz b21lIGFwcGxpY2F0aW9uIG1pc3NlZCwgZS5nLiwgRW50cm9weQ0KPj5MYWJlbCBDYXBhYmlsaXR5 LCBIU01QIExTUCBDYXBhYmlsaXR5LCBldGMuDQo+RW50cm9weSBsYWJlbCBpcyBwZXIgTFNQIGNh cGFiaWxpdHkuIFdlIHdpbGwgYWRkIEhTTVAgRkVDIGFkdmVydGlzZW1lbnQgYXMNCj5wYXJ0IG9m IG1MRFAgdHVubmVsaW5nIGFuZCBtTERQIG5vZGUgcHJvdGVjdGlvbiBhcHBsaWNhdGlvbnMuDQo+ DQo+UmVnYXJkcywNCj5TYW50b3NoDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4gRnJvbTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5udV0NCj4+PiBTZW50OiAy MDE05bm0MTHmnIgyNOaXpSAxNTo0MA0KPj4+IFRvOiB0c2FhZEBjaXNjby5jb207IHRob21hcy5i ZWNraGF1c0B0ZWxla29tLmRlOyBMaXpob25nIEppbg0KPj4+IENjOiBkcmFmdC1lc2FsZS1tcGxz LWFwcC1hd2FyZS10bGRwQHRvb2xzLmlldGYub3JnOyBtcGxzLQ0KPj4+IGNoYWlyc0B0b29scy5p ZXRmLm9yZzsgVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTikNCj4+PiBTdWJqZWN0OiBNUExTLVJU IHJldmlldyBvZiBkcmFmdC1lc2FsZS1tcGxzLWFwcC1hd2FyZS10bGRwDQo+Pj4gDQo+Pj4gVGFy ZWssIFRob21hcyBhbmQgTGl6aG9uZywNCj4+PiANCj4+PiBZb3UgaGF2ZSBiZSBzZWxlY3RlZCBh cyBNUExTLVJUIHJldmlld2VycyBmb3IgZHJhZnQtZXNhbGUtbXBscy1hcHAtDQo+Pj4gYXdhcmUt dGxkcC4NCj4+PiANCj4+PiBOb3RlIHRvIGF1dGhvcnM6IFlvdSBoYXZlIGJlZW4gQ0MnZCBvbiB0 aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93DQo+PnRoYXQNCj4+PiB0aGlzIHJldmlldyBp cyBnb2luZyBvbi4gSG93ZXZlciwgcGxlYXNlIGRvIG5vdCByZXZpZXcgeW91ciBvd24NCj4+PmRv Y3VtZW50Lg0KPj4+IA0KPj4+IFJldmlld3Mgc2hvdWxkIGNvbW1lbnQgb24gd2hldGhlciB0aGUg ZG9jdW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0DQo+Pj51c2VmdWwNCj4+PiAoaWUsIGlzIGl0IGxp a2VseSB0byBiZSBhY3R1YWxseSB1c2VmdWwgaW4gb3BlcmF0aW9uYWwgbmV0d29ya3MpLCBhbmQN Cj4+PmlzDQo+PnRoZQ0KPj4+IGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5kPyAgV2UgYXJlIGlu dGVyZXN0ZWQgaW4ga25vd2luZyB3aGV0aGVyIHRoZQ0KPj4+IGRvY3VtZW50IGlzIHJlYWR5IHRv IGJlIGNvbnNpZGVyZWQgZm9yIFdHIGFkb3B0aW9uIChpZSwgaXQgZG9lc24ndCBoYXZlDQo+Pj50 bw0KPj4+IGJlIHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBiZSBhIGdvb2Qgc3Rh cnQpLg0KPj4+IA0KPj4+IFJldmlld3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3VtZW50IGF1 dGhvcnMsIFdHIGNvLWNoYWlycyBhbmQgV0cNCj4+PiBzZWNyZXRhcnksIGFuZCBDQydkIHRvIHRo ZSBNUExTIFdHIGVtYWlsIGxpc3QuIElmIG5lY2Vzc2FyeSwgY29tbWVudHMNCj4+Pm1heQ0KPj4+ IGJlIHNlbnQgcHJpdmF0ZWx5IHRvIG9ubHkgdGhlIFdHIGNoYWlycy4NCj4+PiANCj4+PiBJZiB5 b3UgaGF2ZSB0ZWNobmljYWwgY29tbWVudHMgeW91IHNob3VsZCB0cnkgdG8gYmUgZXhwbGljaXQg YWJvdXQgd2hhdA0KPj4+ICpyZWFsbHkqIG5lZWQgdG8gYmUgcmVzb2x2ZWQgYmVmb3JlIGFkb3B0 aW5nIGl0IGFzIGEgd29ya2luZyBncm91cA0KPj4+IGRvY3VtZW50LCBhbmQgd2hhdCBjYW4gd2Fp dCB1bnRpbCB0aGUgZG9jdW1lbnQgaXMgYSB3b3JraW5nIGdyb3VwDQo+Pj4gZG9jdW1lbnQgYW5k IHRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgcmV2aXNpb24gY29udHJvbC4NCj4+PiANCj4+PiBB cmUgeW91IGFibGUgdG8gcmV2aWV3IHRoaXMgZHJhZnQgYnkgRGVjIDksIDIwMTQ/IFBsZWFzZSBy ZXNwb25kIGluIGENCj4+dGltZWx5DQo+Pj4gZmFzaGlvbi4NCj4+PiANCj4+PiANCj4+PiBUaGFu a3MsIExvYQ0KPj4+IChhcyBNUExTIFdHIGNoYWlyKQ0KPj4+IC0tDQo+Pj4gDQo+Pj4gDQo+Pj4g TG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1 YXdlaS5jb20NCj4+PiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAg IGxvYUBwaS5udQ0KPj4+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9u ZTogKzQ2IDczOSA4MSAyMSA2NA0KPj4NCj4NCj4NCg0K From nobody Fri Jan 16 21:36:48 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E961A9120 for ; Fri, 16 Jan 2015 21:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFhy0MUfyTZN for ; Fri, 16 Jan 2015 21:36:43 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D681A9145 for ; Fri, 16 Jan 2015 21:36:43 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.75.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E4DD2180155B; Sat, 17 Jan 2015 06:36:38 +0100 (CET) Message-ID: <54B9F4E2.3010500@pi.nu> Date: Sat, 17 Jan 2015 13:36:34 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <54AA1A4D.7010301@pi.nu> In-Reply-To: <54AA1A4D.7010301@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-rsvp-te-hsmp-lsp@tools.ietf.org Subject: Re: [mpls] Plan to kill draft-ietf-mpls-rsvp-te-hsmp-lsp (two week notice) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 05:36:45 -0000 Working Group, We sent this two weeks ago and have not had the resonse needed. The document is now in the state "Dead WG document", which means that it can't be revived. If some one in the future want to address the same technical issues, they need to do so starting with a new individual document. /Loa On 2015-01-05 12:59, Loa Andersson wrote: > Working Group, > > We have a working group draft (and a corresponding milestone) > - draft-ietf-mpls-rsvp-te-hsmp-lsp - that seems to have run out > of steem (or out of application as one of the co-authors put it). > > The draft is expired and we have moved the milestone a couple of times. > We've also polled the authors but the only response we have seen so far > is that there is no interest to continue working on the draft. > > Unless we have someone step up and claim an interest to work with the > draft and is able to commit cycles to do so the wg chairs will kill the > draft by the end of next week (January 16th) and we will also remove the > milestone. > > /Loa > for the mpls wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jan 17 09:21:10 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9E1ACE6A for ; Sat, 17 Jan 2015 09:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYG3Y8qY4a4y for ; Sat, 17 Jan 2015 09:21:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C1D1ACE7B for ; Sat, 17 Jan 2015 09:21:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150117172102.22748.61840.idtracker@ietfa.amsl.com> Date: Sat, 17 Jan 2015 09:21:02 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 17:21:08 -0000 Changed milestone "Submit draft-ietf-mpls-entropy-lsp-ping for publication", set state to active from review, accepting new milestone. Changed milestone "** Progress draft-ietf-mpls-pim-sm-over-mldp to publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf for publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-oam-ipv6-rao for publication", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Sat Jan 17 22:27:50 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA9F1ACE9A; Sat, 17 Jan 2015 22:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a61Ga9k0RkuE; Sat, 17 Jan 2015 22:27:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4F21ACE2E; Sat, 17 Jan 2015 22:27:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRL63098; Sun, 18 Jan 2015 06:27:45 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 18 Jan 2015 06:27:43 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sun, 18 Jan 2015 14:27:38 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(2): Challenge of Proxy Egress for SR-BE Path Thread-Index: AdAy5zNQlgE+8KxmSiyUMl/Nw1wAtw== Date: Sun, 18 Jan 2015 06:27:37 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D477269F1@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477269F1nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" Subject: [mpls] New Comments on Segment Routing(2): Challenge of Proxy Egress for SR-BE Path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 06:27:49 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477269F1nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgc2Vj b25kIGlzc3VlLiBJbiBvcmRlciBmb3IgYmV0dGVyIHVuZGVyc3RhbmRpbmcgYW5kIGRpc2N1c3Np b24sIEkgaW5jbHVkZSBNUExTIFdHIGluIHRoZSBkaXNjdXNzaW9uLg0KDQpJIHdpbGwgcHJvcG9z ZSBvbmUgdXNlIGNhc2Ugb2YgTERQIHByb3h5IGVncmVzczogSW50ZXItQVMgVlBOIE9wdGlvbiBD DQoNCg0KDQogIFBFMTEtLS0tLS0tLUFTQlIxMS0tLS0tLS0tQVNCUjIxLS0tLS0tLVBFMjENCiAg IHwgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgIHwgICAgQVMxICAg ICAgfCAgICAgICAgICAgIHwgICAgQVMyICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAg ICAgIHwgICAgICAgICAgIHwNCiAgUEUxMi0tLS0tLS0tQVNCUjEyLS0tLS0tLS1BU0JSMjItLS0t LS0tUEUyMg0KDQpJbiB0aGlzIGNhc2UsIHRoZSBsYWJlbCBCR1AoUkZDMzEwNykgY2FuIGFkdmVy dGlzZSB0aGUgbGFiZWwgcm91dGUgZm9yIFBFMjEgYW5kIFBFMjIgZnJvbSB0aGUgQVNCUiBpbiBB UzIgdG8gdGhlIEFTQlIgaW4gQVMxLg0KU29tZSBjYXJyaWVycyBwcmVmZXJzIHRvIHVzZSBsYWJl bCBCR1AgdG8gZ28gb24gdG8gYWR2ZXJ0aXNlIHRoZSBsYWJlbCByb3V0ZSB0byBQRTExIGFuZCBQ RTEyLiBCdXQgc29tZSBjYXJyaWVycyBkbyBub3QgbGlrZSBmdWxsDQptZXNoIEJHUCBwZWVycyBh bmQgdGhyZWUgbGF5ZXIgbGFiZWwgZm9yIHRoZSB0cmFmZmljLCB0aGV5IHdvdWxkIHJlZGlzdHJp YnV0ZSB0aGUgQkdQIHJvdXRlcyB0byBJR1AgYXQgQVNCUjExL0FTQlIxMiBhbmQgZGVwZW5kDQpv biBMRFAgdG8gc2V0dXAgTERQIExTUCBmb3IgdGhlIHByZWZpeCBQRTIxL1BFMjIgaW4gdGhlIEFT MS4NCg0KDQoNCkZvciB0aGUgdXNlIGNhc2UgaWYgdGhlIFNSIGlzIGFkb3B0ZWQsIHRoZXJlIG1h eSBwcm9wb3NlIGZvbGxvd2luZyBjaGFsbGVuZ2VzOg0KMS4gSG93IHRvIGNvbmZpZ3VyZSB0aGUg U0lEL2xhYmVsIGZvciB0aGVzZSBwcm94eSBlZ3Jlc3MgYWRkcmVzc2VzPyBPbiBib3RoIEFTQlIx MSBhbmQgQVNCUjIyPyBJZiB0aGVyZSBtb3JlIEFTQlJzLCB0aGVyZSB3aWxsIGJlDQptb3JlIGNv bmZpZ3VyYXRpb24gd29yay4gSXMgaXQgcmlnaHQ/DQoyLiBBY2NvcmRpbmcgdG8gc2VhbWxlc3Mg TVBMUywgdGhlcmUgbWF5IGJlIDEwLDAwMCBub2RlIGFkZHJlc3Nlcy4gSWYgdGFrZSB0aGUgYXNz dW1wdGlvbiwgaXQgd2lsbCBiZSBhIGdyZWF0IGNvbmZpZ3VyYXRpb24gd29yay4NCjMuIFRoZSBs YWJlbCByb3V0ZSBvbiB0aGUgQVNCUiBjYW4gYmUgZHltYW1pYyBjaGFuZ2VkLiBJcyB0aGVyZSB0 aGUgY2FzZSB0aGF0IHRoZSBtb3JlIG9yIGxlc3MgU0lEL0xhYmVscyBhcmUgY29uZmlndXJlZD8N Cg0KSWYgbXkgdW5kZXJzdGFuZGluZyBpcyByaWdodCwgY29tcGFyaW5nIHdpdGggdGhlIHNpbXBs ZSBjYXNlIHdpdGggYWN0dWFsIGVncmVzcywgdGhlcmUgd2lsbCBiZSBtb3JlIGNoYWxsZW5nZSBm b3IgdGhlIHByb3h5IGVncmVzcw0KDQpjYXNlIGZvciBTUi4gSW4gZmFjdCwgdGhlcmUgYXJlIG1v cmUgdXNlY2FzZXMgb2YgcHJveHkgZWdyZXNzOg0KMS4gQyAmIEM6IFByb3h5IGVncmVzcyBmb3Ig dGhlIFZQTiByb3V0ZXMNCjIuIFNlYW1sZXNzIE1QTFM6IFByb3h5IGVncmVzcyBmb3IgdGhlIExE UCBEb0QNCg0KMy4gU29tZSB1c2VjYXNlcyB3aGljaCBuZWVkcyBMRFAgbm9kZSBhbmQgTm9uLUxE UCBub2RlIGNvZXhpc3RzLg0KDQpJIHdvbmRlciBpZiB5b3UgaGF2ZSB0aG91Z2h0IGFib3V0IHRo ZSBwcm94eSBlZ3Jlc3Mgc2NlbmFyaW9zIGFuZCB3aGF0IGlzIHRoZSBwb3NzaWJsZSBzb2x1dGlv bj8gSWYgdGhlIHByb3h5IGVncmVzcyBjYW5ub3QgYmUNCnN1cHBvcnRlZCwgdGhlcmUgd2lsbCBi ZSBtb3JlIGNoYWxsZW5nZXM6DQoxLiBMRFAgY2Fubm90IGJlIHJlcGxhY2VkIGJ5IFNSLUJFIHBh dGguIEluIHRoZSBhYm92ZSB1c2VjYXNlLCBMRFAgUHJveHkgRWdyZXNzIGFuZCBTUiBhY3R1YWwg ZWdyZXNzIG1heSBoYXZlIHRvIGNvLWV4aXN0ZWQuIEl0IHdpbGwNCg0KYmUgdG9vIGNvbXBsZXhl ZCBhbmQgU1IgaXMgdG90YWxseSB1bm5lY2Vzc2FyeS4NCjIuIFRJLUZSUiBmb3IgdGhlIHByb3h5 IGVncmVzcyBjYXNlIGNhbm5vdCBzdXBwb3J0ZWQgZWl0aGVyLiBCdXQgdGhpcyBjYXNlIGNhbiBi ZSBzdXBwb3J0ZWQgYnkgb3RoZXIgRlJSIHNvbHV0aW9ucy4NCg0KDQoNCkhvcGUgdG8gZ2V0IHlv dXIgb3BpbmlvbiBvbiB0aGUgcHJvZ3Jlc3MgZWdyZXNzIGZvciBTUi4NCg0KDQoNClJlZ2FyZHMs DQpSb2Jpbg0K --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477269F1nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the second issue. In order for better understanding and discussi= on, I include MPLS WG in the discussion.


I will propose one use case of LDP proxy egress: Inter-AS VPN Option C

 

  PE11--------ASBR11--------ASBR21-------PE21
   |          &= nbsp;  |          &n= bsp; |           |
   |    AS1      | &= nbsp;          |  &n= bsp; AS2    |
   |          &= nbsp;  |          &n= bsp; |           |
  PE12--------ASBR12--------ASBR22-------PE22


In this case, the label BGP(RFC3107) can advertise the label route for PE21= and PE22 from the ASBR in AS2 to the ASBR in AS1.
Some carriers prefers to use label BGP to go on to advertise the label rout= e to PE11 and PE12. But some carriers do not like full
mesh BGP peers and three layer label for the traffic, they would redistribu= te the BGP routes to IGP at ASBR11/ASBR12 and depend
on LDP to setup LDP LSP for the prefix PE21/PE22 in the AS1.

 

For the use case if the SR is adopted, there may propose following chall= enges:
1. How to configure the SID/label for these proxy egress addresses? On both= ASBR11 and ASBR22? If there more ASBRs, there will be
more configuration work. Is it right?
2. According to seamless MPLS, there may be 10,000 node addresses. If take = the assumption, it will be a great configuration work.
3. The label route on the ASBR can be dymamic changed. Is there the case th= at the more or less SID/Labels are configured?

If my understanding is right, comparing with the simple case with actual= egress, there will be more challenge for the proxy egress

case for SR. In fact, there are more usecases of proxy egress:
1. C & C: Proxy egress for the VPN routes
2. Seamless MPLS: Proxy egress for the LDP DoD

3. Some usecases which needs LDP node and Non-LDP node coexists.

I wonder if you have thought about the proxy egress scenarios and what i= s the possible solution? If the proxy egress cannot be
supported, there will be more challenges:
1. LDP cannot be replaced by SR-BE path. In the above usecase, LDP Proxy Eg= ress and SR actual egress may have to co-existed. It will

be too complexed and SR is totally unnecessary.
2. TI-FRR for the proxy egress case cannot supported either. But this case = can be supported by other FRR solutions.

 

Hope to get your opinion on the progress egress for SR.

 


Regards,
Robin

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477269F1nkgeml506mbxchi_-- From nobody Sun Jan 18 02:39:57 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F21AD0D1; Sun, 18 Jan 2015 02:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHWU1v7XelOC; Sun, 18 Jan 2015 02:39:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75981AC39B; Sun, 18 Jan 2015 02:39:50 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 456AC18C1CF; Sun, 18 Jan 2015 11:39:48 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2521D4C086; Sun, 18 Jan 2015 11:39:48 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Sun, 18 Jan 2015 11:39:47 +0100 From: To: Lizhenbin , "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(2): Challenge of Proxy Egress for SR-BE Path Thread-Index: AdAy5zNQlgE+8KxmSiyUMl/Nw1wAtwAIDBtA Date: Sun, 18 Jan 2015 10:39:47 +0000 Message-ID: <32079_1421577588_54BB8D74_32079_13885_1_53C29892C857584299CBF5D05346208A0EB08630@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D477269F1@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D477269F1@nkgeml506-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EB08630PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.18.83620 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] New Comments on Segment Routing(2): Challenge of Proxy Egress for SR-BE Path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 10:39:55 -0000 --_000_53C29892C857584299CBF5D05346208A0EB08630PEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robin, Thanks for your interest in SPRING/Segment Routing. Please see inline [Bruno] Regards, Bruno From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhenbin Sent: Sunday, January 18, 2015 7:28 AM To: spring@ietf.org Cc: mpls@ietf.org Subject: [mpls] New Comments on Segment Routing(2): Challenge of Proxy Egre= ss for SR-BE Path Hi all authors of segment routing, This is the second issue. In order for better understanding and discussion,= I include MPLS WG in the discussion. I will propose one use case of LDP proxy egress: Inter-AS VPN Option C PE11--------ASBR11--------ASBR21-------PE21 | | | | | AS1 | | AS2 | | | | | PE12--------ASBR12--------ASBR22-------PE22 In this case, the label BGP(RFC3107) can advertise the label route for PE21= and PE22 from the ASBR in AS2 to the ASBR in AS1. Some carriers prefers to use label BGP to go on to advertise the label rout= e to PE11 and PE12. But some carriers do not like full mesh BGP peers and three layer label for the traffic, they would redistribu= te the BGP routes to IGP at ASBR11/ASBR12 and depend on LDP to setup LDP LSP for the prefix PE21/PE22 in the AS1. For the use case if the SR is adopted, there may propose following challeng= es: 1. How to configure the SID/label for these proxy egress addresses? [Bruno] I a priori see 3 options, but this is open for discussion 1- If you want to use MPLS hierarchy. ASBR1x advertise in IGP the SIDs= /MPLS labels as local labels. PE11 will need to use a 2 label stack: Node_S= ID(ASBR1x), Prefix_SID (PE2y). 2- If you don't want to use MPLS hierarchy: a. ASBR1x only advertise the IP reachability. The SID mapping is adve= rtised by the mapping server. b. Assuming AS2 also use SPRING, then the real issue is the redistribu= tion between protocols. IGP->BGP->IGP. This can be done with a BGP extensio= n to carry the SID. e.g. https://tools.ietf.org/html/draft-keyupate-idr-bgp= -prefix-sid-00 On both ASBR11 and ASBR22? If there more ASBRs, there will be more configur= ation work. Is it right? [Bruno] no, see above with 3 solutions. Others could be discussed if needed. 2. According to seamless MPLS, there may be 10,000 node addresses. If take = the assumption, it will be a great configuration work. 3. The label route on the ASBR can be dymamic changed. Is there the case th= at the more or less SID/Labels are configured? [Bruno] I don't see what you mean. If my understanding is right, comparing with the simple case with actual eg= ress, there will be more challenge for the proxy egress case for SR. In fact, there are more usecases of proxy egress: 1. C & C: Proxy egress for the VPN routes 2. Seamless MPLS: Proxy egress for the LDP DoD [Bruno] For the downstream direction (signaling toward upstream), If you us= e BGP, you can still use BGP. If you use IGP cf solutions 1 & 2.a above. 3. Some usecases which needs LDP node and Non-LDP node coexists. I wonder if you have thought about the proxy egress scenarios and what is t= he possible solution? If the proxy egress cannot be supported, there will be more challenges: 1. LDP cannot be replaced by SR-BE path. In the above usecase, LDP Proxy Eg= ress and SR actual egress may have to co-existed. It will be too complexed and SR is totally unnecessary. 2. TI-FRR for the proxy egress case cannot supported either. But this case = can be supported by other FRR solutions. [Bruno] TI-FRR protects solutions using the IGP (1 & 2.a). Node protecting BGP destination is possible (e.g. draft-minto-2547-egress-n= ode-fast-protection) but this is a different story. /Bruno Hope to get your opinion on the progress egress for SR. Regards, Robin ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0EB08630PEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robin,<= o:p>

 = ;

Thanks for= your interest in SPRING/Segment Routing.

Please see= inline [Bruno]

 = ;

Regards,

Bruno=

 = ;

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Sunday, January 18, 2015 7:28 AM
To: spring@ietf.org
Cc: mpls@ietf.org
Subject: [mpls] New Comments on Segment Routing(2): Challenge of Pro= xy Egress for SR-BE Path

 

Hi all = authors of segment routing,

 <= o:p>

This is= the second issue. In order for better understanding and discussion, I incl= ude MPLS WG in the discussion.


I will propose one use case of LDP proxy egress: Inter-AS VPN Option C=

 <= o:p>

  = PE11--------ASBR11--------ASBR21-------PE21
   |          &= nbsp;  |          &n= bsp; |           |
   |    AS1      | &= nbsp;          |  &n= bsp; AS2    |
   |          &= nbsp;  |          &n= bsp; |           |
  PE12--------ASBR12--------ASBR22-------PE22


In this case, the label BGP(RFC3107) can advertise the label route for PE21= and PE22 from the ASBR in AS2 to the ASBR in AS1.
Some carriers prefers to use label BGP to go on to advertise the label rout= e to PE11 and PE12. But some carriers do not like full
mesh BGP peers and three layer label for the traffic, they would redistribu= te the BGP routes to IGP at ASBR11/ASBR12 and depend
on LDP to setup LDP LSP for the prefix PE21/PE22 in the AS1.

 <= o:p>

For the= use case if the SR is adopted, there may propose following challenges:
1. How to configure the SID/label for these proxy egress addresses?<= span style=3D"font-size:10.0pt;font-family:Courier;color:#1F497D">

[Bruno] I a priori see 3 optio= ns, but this is open for discussion

1-      If= you want to use MPLS hierarchy. ASBR1x advertise in IGP the SIDs/MPLS labe= ls as local labels. PE11 will need to use a 2 label stack: Node_SID(ASBR1x), Prefix_SID (PE2y).

2-      If= you don’t want to use MPLS hierarchy:

a.       AS= BR1x only advertise the IP reachability. The SID mapping is advertised by t= he mapping server.

b.      As= suming AS2 also use SPRING, then the real issue is the redistribution betwe= en protocols. IGP->BGP->IGP. This can be done with a BGP extension to carry the SID. e.g. https://tools.ietf.org/html/draft-keyupate-idr-bgp-prefix-sid-00

<= o:p> 

 

On both ASBR11 and ASBR22? If there more ASBRs, there will be more configuration work. Is = it right?

[Bruno] no, see above with 3 s= olutions. Others could be discussed if needed.


2. According to seamless MPLS, there may be 10,000 node addresses. <= span style=3D"font-size:10.0pt;font-family:Courier;color:black">If take the= assumption, it will be a great configuration work.
3. The label route on the ASBR can be dymamic changed. Is there the case th= at the more or less SID/Labels are configured?

[Bruno] I don’t see what= you mean.

If my understanding is right, comparing with the simple case with a= ctual egress, there will be more challenge for the proxy egress

case fo= r SR. In fact, there are more usecases of proxy egress:
1. C & C: Proxy egress for the VPN routes
2. Seamless MPLS: Proxy egress for the LDP DoD

[Bruno] For the downstream dir= ection (signaling toward upstream), If you use BGP, you can still use BGP. = If you use IGP cf solutions 1 & 2.a above.

3. Some= usecases which needs LDP node and Non-LDP node coexists.=

I wonde= r if you have thought about the proxy egress scenarios and what is the poss= ible solution? If the proxy egress cannot be
supported, there will be more challenges:
1. LDP cannot be replaced by SR-BE path. In the above usecase, LDP Proxy Eg= ress and SR actual egress may have to co-existed. It will

be too = complexed and SR is totally unnecessary.
2. TI-FRR for the proxy egress case cannot supported either. But this case = can be supported by other FRR solutions.

[Bruno] TI-FRR protects soluti= ons using the IGP (1 & 2.a).

Node protecting BGP destinatio= n is possible (e.g. draft-minto-2547-egress-node-fast-protection) but this = is a different story.

 

/Bruno <= /o:p>

Hope to get your opinion on the progress egress for SR.<= /span>

 


Regards,
Robin

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0EB08630PEXCVZYM11corpo_-- From nobody Sun Jan 18 12:52:44 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970C81ACE2F; Sun, 18 Jan 2015 12:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyEJUxmCFPpG; Sun, 18 Jan 2015 12:52:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DD01ACE16; Sun, 18 Jan 2015 12:52:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150118205231.19267.237.idtracker@ietfa.amsl.com> Date: Sun, 18 Jan 2015 12:52:31 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 20:52:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Controlling State Advertisements Of Non-negotiated LDP Applications Authors : Kamran Raza Sami Boutros Filename : draft-ietf-mpls-ldp-ip-pw-capability-09.txt Pages : 14 Date : 2015-01-18 Abstract: There is no capability negotiation done for Label Distribution Protocol (LDP) applications that setup Label Switched Paths (LSPs) for IP prefixes or that signal Point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise be advertised over the established LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-ip-pw-capability-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 18 20:01:42 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47651AD0B6 for ; Sun, 18 Jan 2015 20:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LLzaUzNH6FP for ; Sun, 18 Jan 2015 20:01:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 249CF1AD0B7 for ; Sun, 18 Jan 2015 20:01:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119040139.23266.54873.idtracker@ietfa.amsl.com> Date: Sun, 18 Jan 2015 20:01:39 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 04:01:41 -0000 Deleted milestone "Submit draft-ietf-mpls-rsvp-te-hsmp-lsp". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Mon Jan 19 09:41:00 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FC61B2B7C for ; Mon, 19 Jan 2015 09:40:57 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knNTFvAKgTZU for ; Mon, 19 Jan 2015 09:40:55 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909DD1B2B6A for ; Mon, 19 Jan 2015 09:40:54 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id BA0272641AF; Mon, 19 Jan 2015 18:40:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8F0FB238055; Mon, 19 Jan 2015 18:40:52 +0100 (CET) Received: from OPEXCLILM33.corporate.adroot.infra.ftgroup ([169.254.3.79]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Mon, 19 Jan 2015 18:40:52 +0100 From: To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 Thread-Index: AdAwfA5Rl6NPHWj3TvCQ85M9DnILEADkhW5g Date: Mon, 19 Jan 2015 17:40:51 +0000 Message-ID: <30083_1421689252_54BD41A4_30083_3855_1_95B8C2085563754CA854528418622B3D5F498ED9@OPEXCLILM33.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_95B8C2085563754CA854528418622B3D5F498ED9OPEXCLILM33corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.19.85422 Archived-At: Cc: "" , "draft-ietf-mpls-lsp-ping-registry@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 17:40:57 -0000 --_000_95B8C2085563754CA854528418622B3D5F498ED9OPEXCLILM33corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Nothing to note on the registry draft "draft-ietf-mpls-lsp-ping-registry-00= ". For me it is a ready to go for this needed draft (ietf-mpls-entropy-lsp-= ping and ietf-= mpls-lsp-ping-lag-multipath)! Regards, Youssef El Fathi From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, January 15, 2015 05:31 To: mpls@ietf.org Cc: ; draft-ietf-mpls-lsp-ping-registry@tools.i= etf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-regist= ry-00 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-lsp-ping-registry-00. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have stated on the working group mailing list that they are not aware of any IPR that relates to this draft. This working group last call ends January 29, 2015. Ross for the MPLS wg chairs ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_95B8C2085563754CA854528418622B3D5F498ED9OPEXCLILM33corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Nothing to note on the re= gistry draft “draft-ietf-mpls-lsp-ping-registry-00”. For me it = is a ready to go for this needed draft (= iet= f-mpls-entropy-lsp-ping and ietf-mpls-lsp-ping-lag-multipath<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">)!

 <= /p>

Regards,=

 

Youssef El Fa= thi

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, January 15, 2015 05:31
To: mpls@ietf.org
Cc: <mpls-chairs@tools.ietf.org>; draft-ietf-mpls-lsp-ping-reg= istry@tools.ietf.org
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping= -registry-00

 

Working Group,

 

This is to initiate a two week working = group last call on

draft-ietf-mpls-lsp-ping-registry-00.

 

Please send your comments to the mpls w= g mailing list (mpls@ietf.org).

 

There are no IPR disclosures against th= is document. All the authors have

stated on the working group mailing lis= t that they are not aware of any

IPR that relates to this draft.

 

This working group last call ends Janua= ry 29, 2015. 

 

Ross

for the MPLS wg chairs

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_95B8C2085563754CA854528418622B3D5F498ED9OPEXCLILM33corp_-- From nobody Mon Jan 19 09:41:34 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F90A1B2B7C for ; Mon, 19 Jan 2015 09:41:33 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFz8JxPNGrWg for ; Mon, 19 Jan 2015 09:41:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A761B2BA3 for ; Mon, 19 Jan 2015 09:41:31 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 46E653B43D4 for ; Mon, 19 Jan 2015 18:41:29 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 146D2C804F for ; Mon, 19 Jan 2015 18:41:29 +0100 (CET) Received: from OPEXCLILM33.corporate.adroot.infra.ftgroup ([169.254.3.79]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Mon, 19 Jan 2015 18:41:29 +0100 From: To: "mpls@ietf.org" Thread-Topic: [mpls] Comment on draft-ietf-mpls-entropy-lsp-ping Thread-Index: AdA0DpYOGBt9Cqn8Rxe9b0GU3+szfg== Date: Mon, 19 Jan 2015 17:41:28 +0000 Message-ID: <24050_1421689289_54BD41C9_24050_3260_1_95B8C2085563754CA854528418622B3D5F498EF1@OPEXCLILM33.corporate.adroot.infra.ftgroup> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_95B8C2085563754CA854528418622B3D5F498EF1OPEXCLILM33corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.19.62420 Archived-At: Subject: [mpls] Comment on draft-ietf-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 17:41:33 -0000 --_000_95B8C2085563754CA854528418622B3D5F498EF1OPEXCLILM33corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A quick note to spot a typo in section 2: Note that the terms "IP Based Load Balancer", "Label Based Load Balancer" and "Label Based Load Balancer" are in context of how received MPLS echo request is handled by the responder LSR. Regards, Youssef El Fathi ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_95B8C2085563754CA854528418622B3D5F498EF1OPEXCLILM33corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A quick note to spot a typo in section 2:=

 

Note that the terms "IP Based Load Balancer", "Label Based Load

   Balancer" and "Label Bas= ed Load Balancer" are in context of how

  = ; received MPLS echo request is handled by the responder LSR.

 = ;

Regards,

 

Youssef El Fathi

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_95B8C2085563754CA854528418622B3D5F498EF1OPEXCLILM33corp_-- From nobody Mon Jan 19 14:04:04 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2201B2CCC for ; Mon, 19 Jan 2015 14:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLri4X9M5Q2j for ; Mon, 19 Jan 2015 14:04:00 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9B01B2CC7 for ; Mon, 19 Jan 2015 14:03:59 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0JM3wV3013596; Mon, 19 Jan 2015 22:03:58 GMT Received: from 950129200 (178-190-140-73.adsl.highway.telekom.at [178.190.140.73]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0JM3uTa013581 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2015 22:03:57 GMT From: "Adrian Farrel" To: Date: Mon, 19 Jan 2015 22:03:57 -0000 Message-ID: <03b301d03433$d32d1d30$79875790$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA0M8210AFg3P+vS8aK+naGx0wpjg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21264.003 X-TM-AS-Result: No--6.185-10.0-31-10 X-imss-scan-details: No--6.185-10.0-31-10 X-TMASE-MatchedRID: /vmo5u6D2ITLLefpbEkxkHBRIrj8R47FQPCWRE0Lo8JkueSaR+/6na0R omhWPJaQZwyCMsrDlD5ldTUcEWGVJogeee+ESM++c+QhWKJM04MS12tj9Zvd8+OxOq7LQlGL+RS SUvAsW4ZQAVx8HYn7bId+6Qw4AThOpffDv4oDZL6ZroPNdqiG8+/qSJUJMhVKYQ5G2uxyeNQyH5 ttGd24nWJQj0mg9FSVlMgwdBi5cG0EPvtjyrrEq0KcYi5Qw/RVYcG2ssIvc2e+cLXRiCoxN1SB5 kaFwbmXT+ul7n8dAz59Srr6VJLZnNGGsBL/uYnrw4PlNTUpnLll0qH7/7HRjspj/9aYiP+hMq+e n+OaNutbzG0L+MC4bkZNnKUTfZN9OMzWonUNEQMdxBAG5/hkW0olfE5GSrD5q8z7POX8FJOGkTn 1RxBcpcZ9UZxeemkgV8ZoivzOWHERoCQ3XTVZYZ4CIKY/Hg3AtOt1ofVlaoIc4jS1nsD4HfoLR4 +zsDTtX28xNpU0U3Oay4mxkK8+LVk101fwZH2hdjq0widDJ18NDgYtZ29VVQ== Archived-At: Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-seamless-mcast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 22:04:03 -0000 Hello authors, I have conducted my usual AD review of this document to attempt to catch issues that would otherwise show in IETF last call or IESG evaluation. There are number of small nits listed below. None of these needs delay the document and you should feel free to debate the points with me rather than blindly accepting my view. I will start the IETF last call and enter these as last call comments. You can then address them together with any other review comments you receive during last call. Thanks for the work. Adrian === idnits reveals that the copyright year needs to be 2015. Please update that if you revise the document. idnits also points out that you probably don't need the boilerplate for pre-RFC5378 work. unless you are sure you need it, please take it out. --- I think that the RFC Editor will need your help expanding some of the abbreviations that are not listed as "well known" in the list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt You might kick this off by doing a scrub yourselves. --- Section 3 line 1 s/suppose/assumed/ --- 5.1.2 and 5.2.2 titles s/re-advertise/re-advertised/ --- 5.1.3 has To avoid requiring ABRs to participate in the propagation of C- multicast routes, this document requires ABRs NOT to modify BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. "NOT" is not a 2119 term in its own right. Suggest you rephrase as To avoid requiring ABRs to participate in the propagation of C- multicast routes, this document specifies that ABRs MUST NOT modify BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. --- In 6.1.2 If the application is global table multicast, then the unicast routes to multicast sources/RPs SHOULD carry the "VRF Route Import" Extended Community [RFC6514] where the IP address in the Global Administrator field is set to the IP address of the PE or ASBR advertising the unicast route. I wondered about this "SHOULD". Trying to decide why we might decide to vary that and what the consequences would be. Similarly one para later... Further, if the application is global table multicast, then the BGP unicast routes that advertise the routes to the IP addresses of PEs/ASBRs/ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop Extended Community. --- 7.2.2.1 This section applies only if it is desirable to send a particular (S, G) or (*, G) global table multicast flow only to those egress PEs that have receivers for that multicast flow. Is this s/desirable/desired/ ? If not then some guidance as to how to judge when it is desirable. If so, then perhaps you could be a little less passive-voice: who desires it? --- 7.2.2.2 It may be desirable for an ingress PE to carry multiple multicast flows associated with the global table multicast over the same inter- area P2MP service LSP. Can you give guidance as to why it might be desirable? Or possible (as above) s/desirable for/desired that/ also adding some explanation about who has the desire (and possible why). --- 7.2.3 To allow the egress PE to determine the sender upstream node, the intra-area P2MP LSP must be signaled with no PHP, when the mapping between the inter-area P2MP service LSP for global table multicast service and the intra-area P2MP LSP is many-to-one. The lower case "must" jumped out. Probably upper case? --- Section 14 Is the term "transport LSP" introduced by this document? If so, a little more definition would be nice (just a few words to make it clear that you are defining the term). If not, can you supply a reference. --- After 38 pages of spec you have just five lines of security considerations. You don't even mention BGP security directly. I confess that I don't see anything obvious that is missing, but are there no specific risks associated with this approach? No amplification through mcast? From nobody Mon Jan 19 15:43:31 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635631B2D35 for ; Mon, 19 Jan 2015 15:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeHEDnD3fNId for ; Mon, 19 Jan 2015 15:43:26 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4CC1B2D37 for ; Mon, 19 Jan 2015 15:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9118; q=dns/txt; s=iport; t=1421711007; x=1422920607; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=gwra7X7JCc5PkzfhQaYzj+9UszjAOJN3cQa5Ec/YMqo=; b=PnaSN2MkM/Cn5X56mvCwBMqRfdaOiZ3jAFgOxl7AHALWz3YnlXqQFkJi 3oEFjd3vqdN9k+u8e3aTiZJmj73DEMGInuwkJ40moEGl7udPoIwO1+BVD W2h9SioCo4UXFTMRzljC0SQ2/uLHOEpwJdjjpSSvvKF1zm0cAneR1gJBB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAJ2VvVStJV2b/2dsb2JhbABcgkMhIlJYBMwzAoEeQwEBAQEBfYQMAQEBBC04JAIBCBEEAQELHQcyFAkIAQEEARIIiCQBzhgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjxcRAR83AQaDEIETBYx6gV+KK4J8jhoig25vgQw5fgEBAQ X-IronPort-AV: E=Sophos;i="5.09,430,1418083200"; d="scan'208,217";a="388235393" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 19 Jan 2015 23:43:26 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t0JNhPrV001383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Jan 2015 23:43:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 17:43:25 -0600 From: "Nobo Akiya (nobo)" To: "youssef.elfathi@orange.com" , "mpls@ietf.org" Thread-Topic: [mpls] Comment on draft-ietf-mpls-entropy-lsp-ping Thread-Index: AdA0DpYOGBt9Cqn8Rxe9b0GU3+szfgAMwhYw Date: Mon, 19 Jan 2015 23:43:25 +0000 Message-ID: References: <24050_1421689289_54BD41C9_24050_3260_1_95B8C2085563754CA854528418622B3D5F498EF1@OPEXCLILM33.corporate.adroot.infra.ftgroup> In-Reply-To: <24050_1421689289_54BD41C9_24050_3260_1_95B8C2085563754CA854528418622B3D5F498EF1@OPEXCLILM33.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.64] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD39446D78447xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Comment on draft-ietf-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 23:43:29 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD39446D78447xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Youssef, Good catch, what you pointed out is indeed a typo. We will address it in th= e next revision. Thanks! -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of youssef.elfathi@oran= ge.com Sent: Monday, January 19, 2015 12:41 PM To: mpls@ietf.org Subject: [mpls] Comment on draft-ietf-mpls-entropy-lsp-ping Hi, A quick note to spot a typo in section 2: Note that the terms "IP Based Load Balancer", "Label Based Load Balancer" and "Label Based Load Balancer" are in context of how received MPLS echo request is handled by the responder LSR. Regards, Youssef El Fathi ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CECE764681BE964CBE1DFF78F3CDD39446D78447xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Youssef,=

 

Good catch, what you p= ointed out is indeed a typo. We will address it in the next revision.<= /o:p>

 

Thanks!

 

-Nobo

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of youssef.elfathi@orange.com
Sent: Monday, January 19, 2015 12:41 PM
To: mpls@ietf.org
Subject: [mpls] Comment on draft-ietf-mpls-entropy-lsp-ping

 

Hi,

 

A quick note to spot a typo in = section 2:

 

Note that the terms "IP Based Load Balancer", "Label Based Load

   Balancer" and "Label Bas= ed Load Balancer" are in context of how

  = ; received MPLS echo request is handled by the responder LSR.

 = ;

Regards,

 

Youssef El Fathi

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_CECE764681BE964CBE1DFF78F3CDD39446D78447xmbalnx01ciscoc_-- From nobody Mon Jan 19 17:04:14 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B146B1B2D56; Mon, 19 Jan 2015 17:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwdunTdwnMAV; Mon, 19 Jan 2015 17:04:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEC31A90D9; Mon, 19 Jan 2015 17:04:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150120010407.18207.73076.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 17:04:07 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] Last Call: (Inter-Area P2MP Segmented LSPs) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 01:04:11 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Inter-Area P2MP Segmented LSPs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, VPLS multicast, or global table multicast over MPLS. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2047/ From nobody Mon Jan 19 21:01:19 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1A71ACF60 for ; Mon, 19 Jan 2015 21:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GyTBPVFOUZE for ; Mon, 19 Jan 2015 21:01:16 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29A21A909C for ; Mon, 19 Jan 2015 21:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4536; q=dns/txt; s=iport; t=1421730075; x=1422939675; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=sPaio7H2BiUVhC3gJxiWz40k6SmS5O7wa3fXHH7p3xA=; b=Dlb2BaXt2uGedwVmFPMxXtTjXP1kn1DQlP4VKfbZWw/YOj069fF+MAri DRfLEv731HnKEbKKQmjj5WanKRbI1Vv/bkP4vtLoS5meudS/2I6LANfZn CH30hPOeLNN5dD20v3KUkFu6yiEnYsNlQecNaV9zHyhF92F6YivRL8cTJ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAGAI/gvVStJV2b/2dsb2JhbABbgkNDgSoExB6IFgKBIkMBAQEBAX2EDAECBB0QQQsSAQgECgMDAQIoORQJCAIEAQ0FiCzOFwEBAQEBAQEBAQEBAQEBAQEBAQEBARePaBEHhCkFjHqBX4kXgRSCfIpdgz0ig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.09,431,1418083200"; d="scan'208,217";a="114827684" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 20 Jan 2015 05:01:14 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t0K51E8T001845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Jan 2015 05:01:14 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.219]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 23:01:14 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 Thread-Index: AQHQNG4dk94+/dygXUS8TEFL2HBduQ== Date: Tue, 20 Jan 2015 05:01:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.227.142] Content-Type: multipart/alternative; boundary="_000_D0E34A994CE5Bnaikumarciscocom_" MIME-Version: 1.0 Archived-At: Cc: "" , "draft-ietf-mpls-lsp-ping-registry@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 05:01:17 -0000 --_000_D0E34A994CE5Bnaikumarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Support. This is a simple and useful draft. Thanks, Nagendra From: Ross Callon > Date: Wednesday, January 14, 2015 at 11:30 PM To: "mpls@ietf.org" > Cc: "mpls-chairs@tools.ietf.org" >, "draft-ietf-mpls-= lsp-ping-registry@tools.ietf.org" > Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-regist= ry-00 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-lsp-ping-registry-00. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have stated on the working group mailing list that they are not aware of any IPR that relates to this draft. This working group last call ends January 29, 2015. Ross for the MPLS wg chairs --_000_D0E34A994CE5Bnaikumarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <14C231AFB01E564791B5D032EF988AD1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

Support.

This is a simple and useful draft. 

Thanks,
Nagendra

From: Ross Callon <rcallon@juniper.net>
Date: Wednesday, January 14, 2015 a= t 11:30 PM
To: "mpls@ietf.org" <mpls@i= etf.org>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "= draft-i= etf-mpls-lsp-ping-registry@tools.ietf.org" <dr= aft-ietf-mpls-lsp-ping-registry@tools.ietf.org>
Subject: [mpls] working group last = call for draft-ietf-mpls-lsp-ping-registry-00

Working Group,
 
This is to initiate a two week working group last call on
draft-ietf-mpls-lsp-ping-registry-00.
 
Please send your comments to the mpls wg mailing list (mpls@ietf.org).
 
There are no IPR disclosures against this document. All the authors ha= ve
stated on the working group mailing list that they are not aware of an= y
IPR that relates to this draft.
 
This working group last call ends January 29, 2015. 
 
Ross
for the MPLS wg chairs
 
 --_000_D0E34A994CE5Bnaikumarciscocom_-- From nobody Mon Jan 19 22:56:30 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8901A8BB0; Mon, 19 Jan 2015 22:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.64 X-Spam-Level: **** X-Spam-Status: No, score=4.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MANGLED_SIDE=2.3, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgTQQ3wmxLtS; Mon, 19 Jan 2015 22:56:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146341ACF18; Mon, 19 Jan 2015 22:56:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOF39894; Tue, 20 Jan 2015 06:56:22 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 06:56:21 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 20 Jan 2015 14:56:16 +0800 From: Lizhenbin To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(2): Challenge of Proxy Egress for SR-BE Path Thread-Index: AdAy5zNQlgE+8KxmSiyUMl/Nw1wAtwAIDBtAAF1EZ/M= Date: Tue, 20 Jan 2015 06:56:16 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D47727D58@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D477269F1@nkgeml506-mbx.china.huawei.com>, <32079_1421577588_54BB8D74_32079_13885_1_53C29892C857584299CBF5D05346208A0EB08630@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <32079_1421577588_54BB8D74_32079_13885_1_53C29892C857584299CBF5D05346208A0EB08630@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D47727D58nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogTmV3IENvbW1lbnRzIG9uIFNlZ21lbnQgUm91?= =?gb2312?b?dGluZygyKTogQ2hhbGxlbmdlIG9mIFByb3h5IEVncmVzcyBmb3IgU1ItQkUg?= =?gb2312?b?UGF0aA==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 06:56:27 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D47727D58nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQnJ1bm8sDQoNClBsZWFzZSBzZWUgaW5saW5lIFtSb2Jpbl0uIEkgY2xhcmlmeSBteSBjaGFs bGVuZ2VzLiBIb3BlIHlvdSByZXRoaW5rIGl0Lg0KDQoNCg0KVGhhbmtzICYgUmVnYXJkcywNCg0K Um9iaW4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjL OiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIFticnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tXQ0K t6LLzcqxvOQ6IDIwMTXE6jHUwjE4yNUgMTg6MzkNCsrVvP7IyzogTGl6aGVuYmluOyBzcHJpbmdA aWV0Zi5vcmcNCrOty806IG1wbHNAaWV0Zi5vcmcNCtb3zOI6IFJFOiBOZXcgQ29tbWVudHMgb24g U2VnbWVudCBSb3V0aW5nKDIpOiBDaGFsbGVuZ2Ugb2YgUHJveHkgRWdyZXNzIGZvciBTUi1CRSBQ YXRoDQoNCkhpIFJvYmluLA0KDQpUaGFua3MgZm9yIHlvdXIgaW50ZXJlc3QgaW4gU1BSSU5HL1Nl Z21lbnQgUm91dGluZy4NClBsZWFzZSBzZWUgaW5saW5lIFtCcnVub10NCg0KUmVnYXJkcywNCkJy dW5vDQoNCkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBMaXpoZW5iaW4NClNlbnQ6IFN1bmRheSwgSmFudWFyeSAxOCwgMjAxNSA3OjI4IEFNDQpU bzogc3ByaW5nQGlldGYub3JnDQpDYzogbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogW21wbHNdIE5l dyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoMik6IENoYWxsZW5nZSBvZiBQcm94eSBFZ3Jl c3MgZm9yIFNSLUJFIFBhdGgNCg0KDQpIaSBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRpbmcs DQoNCg0KDQpUaGlzIGlzIHRoZSBzZWNvbmQgaXNzdWUuIEluIG9yZGVyIGZvciBiZXR0ZXIgdW5k ZXJzdGFuZGluZyBhbmQgZGlzY3Vzc2lvbiwgSSBpbmNsdWRlIE1QTFMgV0cgaW4gdGhlIGRpc2N1 c3Npb24uDQoNCkkgd2lsbCBwcm9wb3NlIG9uZSB1c2UgY2FzZSBvZiBMRFAgcHJveHkgZWdyZXNz OiBJbnRlci1BUyBWUE4gT3B0aW9uIEMNCg0KDQoNCiAgUEUxMS0tLS0tLS0tQVNCUjExLS0tLS0t LS1BU0JSMjEtLS0tLS0tUEUyMQ0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgfA0KICAgfCAgICBBUzEgICAgICB8ICAgICAgICAgICAgfCAgICBBUzIgICAgfA0KICAg fCAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgfA0KICBQRTEyLS0tLS0tLS1B U0JSMTItLS0tLS0tLUFTQlIyMi0tLS0tLS1QRTIyDQoNCkluIHRoaXMgY2FzZSwgdGhlIGxhYmVs IEJHUChSRkMzMTA3KSBjYW4gYWR2ZXJ0aXNlIHRoZSBsYWJlbCByb3V0ZSBmb3IgUEUyMSBhbmQg UEUyMiBmcm9tIHRoZSBBU0JSIGluIEFTMiB0byB0aGUgQVNCUiBpbiBBUzEuDQpTb21lIGNhcnJp ZXJzIHByZWZlcnMgdG8gdXNlIGxhYmVsIEJHUCB0byBnbyBvbiB0byBhZHZlcnRpc2UgdGhlIGxh YmVsIHJvdXRlIHRvIFBFMTEgYW5kIFBFMTIuIEJ1dCBzb21lIGNhcnJpZXJzIGRvIG5vdCBsaWtl IGZ1bGwNCm1lc2ggQkdQIHBlZXJzIGFuZCB0aHJlZSBsYXllciBsYWJlbCBmb3IgdGhlIHRyYWZm aWMsIHRoZXkgd291bGQgcmVkaXN0cmlidXRlIHRoZSBCR1Agcm91dGVzIHRvIElHUCBhdCBBU0JS MTEvQVNCUjEyIGFuZCBkZXBlbmQNCm9uIExEUCB0byBzZXR1cCBMRFAgTFNQIGZvciB0aGUgcHJl Zml4IFBFMjEvUEUyMiBpbiB0aGUgQVMxLg0KDQoNCg0KRm9yIHRoZSB1c2UgY2FzZSBpZiB0aGUg U1IgaXMgYWRvcHRlZCwgdGhlcmUgbWF5IHByb3Bvc2UgZm9sbG93aW5nIGNoYWxsZW5nZXM6DQox LiBIb3cgdG8gY29uZmlndXJlIHRoZSBTSUQvbGFiZWwgZm9yIHRoZXNlIHByb3h5IGVncmVzcyBh ZGRyZXNzZXM/DQoNCltCcnVub10gSSBhIHByaW9yaSBzZWUgMyBvcHRpb25zLCBidXQgdGhpcyBp cyBvcGVuIGZvciBkaXNjdXNzaW9uDQoNCjEtICAgICAgSWYgeW91IHdhbnQgdG8gdXNlIE1QTFMg aGllcmFyY2h5LiBBU0JSMXggYWR2ZXJ0aXNlIGluIElHUCB0aGUgU0lEcy9NUExTIGxhYmVscyBh cyBsb2NhbCBsYWJlbHMuIFBFMTEgd2lsbCBuZWVkIHRvIHVzZSBhIDIgbGFiZWwgc3RhY2s6IE5v ZGVfU0lEKEFTQlIxeCksIFByZWZpeF9TSUQgKFBFMnkpLg0KDQoyLSAgICAgIElmIHlvdSBkb26h r3Qgd2FudCB0byB1c2UgTVBMUyBoaWVyYXJjaHk6DQoNCmEuICAgICAgIEFTQlIxeCBvbmx5IGFk dmVydGlzZSB0aGUgSVAgcmVhY2hhYmlsaXR5LiBUaGUgU0lEIG1hcHBpbmcgaXMgYWR2ZXJ0aXNl ZCBieSB0aGUgbWFwcGluZyBzZXJ2ZXIuDQoNCmIuICAgICAgQXNzdW1pbmcgQVMyIGFsc28gdXNl IFNQUklORywgdGhlbiB0aGUgcmVhbCBpc3N1ZSBpcyB0aGUgcmVkaXN0cmlidXRpb24gYmV0d2Vl biBwcm90b2NvbHMuIElHUC0+QkdQLT5JR1AuIFRoaXMgY2FuIGJlIGRvbmUgd2l0aCBhIEJHUCBl eHRlbnNpb24gdG8gY2FycnkgdGhlIFNJRC4gZS5nLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQta2V5dXBhdGUtaWRyLWJncC1wcmVmaXgtc2lkLTAwDQoNCg0KDQpbUm9iaW5dIE15 IG9iamVjdGl2ZSBpcyBub3QgdG8gcGVyc3VlIHRoZSBzb2x1dGlvbi4gTXkgcHJvcG9zZWQgY2hh bGxlbmdlcyBpcyBhcyBmb2xsb3dzOg0KDQoxKSBJbiBvcmRlciB0byBzdXBwb3J0IHByb3h5IGVn cmVzcyBmb3IgU1ItQkUgcGF0aCwgd2UgaGF2ZSB0byBjb25maWd1cmUgdGhlIFNJRC9sYWJlbCBm b3IgdGhlIHByb3h5IGVncmVzcyBub2Rlcywgc28gd2hpY2ggQVNCUiB3ZSBzaG91bGQgdG8gY2hv b3NlIHRvIGNvbmZpZ3VyZSB0aGVzZSBTSUQvbGFiZWwgYmluZGluZ3M/DQoNCjIpIElmIHRoZXJl IGFyZSAxMCwwMDAgcHJveHkgZWdyZXNzIGFkZHJlc3NlcyBwcm9wb3NlZCBieSBzZWFtbGVzcyBN UExTLCB0aGlzIG1lYW5zIHdlIGhhdmUgdG8gY29uZmlndXJlIDEwLDAwMCBTSUQvbGFiZWwgYmlu ZGluZ3Mgb24gb25lIEFTQlI/IFRoZSBodWdlIGNvbmZpZ3VyYXRpb24gd29yayBjYW5ub3QgYmUg YWNjZXB0ZWQgYWNjb3JkaW5nIHRvIG15IHVuZGVyc3RhbmRpbmcuDQoNCjMpIFNpbmNlIHRoZSBw cm94eSBlZ3Jlc3MgaXMgbGVhcm5lZCBmcm9tIG91dHNpZGUgb2YgdGhlIG5ldHdvcmssIGlmIGNv bmZpZ3VyZSB0aGUgc3RhdGljIHRoZSBTSUQvbGFiZWwgZm9yIGEgc3BlY2lmaWMgcHJveHkgZWdy ZXNzLCBidXQgdGhlIHByb3h5IGVncmVzcyBpcyBub3QgbGVhcm5lZCwgdGhlIFNJRC9sYWJlbCBp cyB3YXN0ZWQuIElmIG5vdA0KDQpjb25maWd1cmVkLCBidXQgdGhlIHByb3h5IGVncmVzcyBpcyBs ZWFybmVkLCB0aGUgU1ItQkUgcGF0aCBkb2VzIG5vdCB3b3JrLiBIb3cgdG8gY29wZSB3aXRoIHRo ZSBpc3N1ZXM/DQoNCg0KDQoNCg0KDQoNCk9uIGJvdGggQVNCUjExIGFuZCBBU0JSMjI/IElmIHRo ZXJlIG1vcmUgQVNCUnMsIHRoZXJlIHdpbGwgYmUgbW9yZSBjb25maWd1cmF0aW9uIHdvcmsuIElz IGl0IHJpZ2h0Pw0KDQpbQnJ1bm9dIG5vLCBzZWUgYWJvdmUgd2l0aCAzIHNvbHV0aW9ucy4gT3Ro ZXJzIGNvdWxkIGJlIGRpc2N1c3NlZCBpZiBuZWVkZWQuDQoNCjIuIEFjY29yZGluZyB0byBzZWFt bGVzcyBNUExTLCB0aGVyZSBtYXkgYmUgMTAsMDAwIG5vZGUgYWRkcmVzc2VzLiBJZiB0YWtlIHRo ZSBhc3N1bXB0aW9uLCBpdCB3aWxsIGJlIGEgZ3JlYXQgY29uZmlndXJhdGlvbiB3b3JrLg0KMy4g VGhlIGxhYmVsIHJvdXRlIG9uIHRoZSBBU0JSIGNhbiBiZSBkeW1hbWljIGNoYW5nZWQuIElzIHRo ZXJlIHRoZSBjYXNlIHRoYXQgdGhlIG1vcmUgb3IgbGVzcyBTSUQvTGFiZWxzIGFyZSBjb25maWd1 cmVkPw0KDQpbQnJ1bm9dIEkgZG9uoa90IHNlZSB3aGF0IHlvdSBtZWFuLg0KDQpJZiBteSB1bmRl cnN0YW5kaW5nIGlzIHJpZ2h0LCBjb21wYXJpbmcgd2l0aCB0aGUgc2ltcGxlIGNhc2Ugd2l0aCBh Y3R1YWwgZWdyZXNzLCB0aGVyZSB3aWxsIGJlIG1vcmUgY2hhbGxlbmdlIGZvciB0aGUgcHJveHkg ZWdyZXNzDQoNCmNhc2UgZm9yIFNSLiBJbiBmYWN0LCB0aGVyZSBhcmUgbW9yZSB1c2VjYXNlcyBv ZiBwcm94eSBlZ3Jlc3M6DQoxLiBDICYgQzogUHJveHkgZWdyZXNzIGZvciB0aGUgVlBOIHJvdXRl cw0KMi4gU2VhbWxlc3MgTVBMUzogUHJveHkgZWdyZXNzIGZvciB0aGUgTERQIERvRA0KDQpbQnJ1 bm9dIEZvciB0aGUgZG93bnN0cmVhbSBkaXJlY3Rpb24gKHNpZ25hbGluZyB0b3dhcmQgdXBzdHJl YW0pLCBJZiB5b3UgdXNlIEJHUCwgeW91IGNhbiBzdGlsbCB1c2UgQkdQLiBJZiB5b3UgdXNlIElH UCBjZiBzb2x1dGlvbnMgMSAmIDIuYSBhYm92ZS4NCg0KMy4gU29tZSB1c2VjYXNlcyB3aGljaCBu ZWVkcyBMRFAgbm9kZSBhbmQgTm9uLUxEUCBub2RlIGNvZXhpc3RzLg0KDQpJIHdvbmRlciBpZiB5 b3UgaGF2ZSB0aG91Z2h0IGFib3V0IHRoZSBwcm94eSBlZ3Jlc3Mgc2NlbmFyaW9zIGFuZCB3aGF0 IGlzIHRoZSBwb3NzaWJsZSBzb2x1dGlvbj8gSWYgdGhlIHByb3h5IGVncmVzcyBjYW5ub3QgYmUN CnN1cHBvcnRlZCwgdGhlcmUgd2lsbCBiZSBtb3JlIGNoYWxsZW5nZXM6DQoxLiBMRFAgY2Fubm90 IGJlIHJlcGxhY2VkIGJ5IFNSLUJFIHBhdGguIEluIHRoZSBhYm92ZSB1c2VjYXNlLCBMRFAgUHJv eHkgRWdyZXNzIGFuZCBTUiBhY3R1YWwgZWdyZXNzIG1heSBoYXZlIHRvIGNvLWV4aXN0ZWQuIEl0 IHdpbGwNCg0KYmUgdG9vIGNvbXBsZXhlZCBhbmQgU1IgaXMgdG90YWxseSB1bm5lY2Vzc2FyeS4N CjIuIFRJLUZSUiBmb3IgdGhlIHByb3h5IGVncmVzcyBjYXNlIGNhbm5vdCBzdXBwb3J0ZWQgZWl0 aGVyLiBCdXQgdGhpcyBjYXNlIGNhbiBiZSBzdXBwb3J0ZWQgYnkgb3RoZXIgRlJSIHNvbHV0aW9u cy4NCg0KW0JydW5vXSBUSS1GUlIgcHJvdGVjdHMgc29sdXRpb25zIHVzaW5nIHRoZSBJR1AgKDEg JiAyLmEpLg0KDQpOb2RlIHByb3RlY3RpbmcgQkdQIGRlc3RpbmF0aW9uIGlzIHBvc3NpYmxlIChl LmcuIGRyYWZ0LW1pbnRvLTI1NDctZWdyZXNzLW5vZGUtZmFzdC1wcm90ZWN0aW9uKSBidXQgdGhp cyBpcyBhIGRpZmZlcmVudCBzdG9yeS4NCg0KDQoNCi9CcnVubw0KDQpIb3BlIHRvIGdldCB5b3Vy IG9waW5pb24gb24gdGhlIHByb2dyZXNzIGVncmVzcyBmb3IgU1IuDQoNCg0KDQpSZWdhcmRzLA0K Um9iaW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0K --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D47727D58nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

Please see inline [Robin]. I clarify my challenges. Hope you rethink it.=

 

Thanks & Regards,

Robin

 

 

=B7=A2=BC=FE=C8=CB: bruno.decraene@orange.= com [bruno.decraene@orange.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C218=C8=D5 18:39
=CA=D5=BC=FE=C8=CB: Lizhenbin; spring@ietf.org
=B3=AD=CB=CD: mpls@ietf.org
=D6=F7=CC=E2: RE: New Comments on Segment Routing(2): Challenge of P= roxy Egress for SR-BE Path

Hi Robin,

 

Thanks for your interest in= SPRING/Segment Routing.

Please see inline [Bruno]

 

Regards,

Bruno

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Sunday, January 18, 2015 7:28 AM
To: spring@ietf.org
Cc: mpls@ietf.org
Subject: [mpls] New Comments on Segment Routing(2): Challenge of Pro= xy Egress for SR-BE Path

 

Hi a= ll authors of segment routing,

 

This= is the second issue. In order for better understanding and discussion, I i= nclude MPLS WG in the discussion.


I will propose one use case of LDP proxy egress: Inter-AS VPN Option C

 

&nbs= p; PE11--------ASBR11--------ASBR21-------PE21
   |          &= nbsp;  |          &n= bsp; |           |
   |    AS1      | &= nbsp;          |  &n= bsp; AS2    |
   |          &= nbsp;  |          &n= bsp; |           |
  PE12--------ASBR12--------ASBR22-------PE22


In this case, the label BGP(RFC3107) can advertise the label route for PE21= and PE22 from the ASBR in AS2 to the ASBR in AS1.
Some carriers prefers to use label BGP to go on to advertise the label rout= e to PE11 and PE12. But some carriers do not like full
mesh BGP peers and three layer label for the traffic, they would redistribu= te the BGP routes to IGP at ASBR11/ASBR12 and depend
on LDP to setup LDP LSP for the prefix PE21/PE22 in the AS1.

 

For = the use case if the SR is adopted, there may propose following challenges:<= br> 1. How to configure the SID/label for these proxy egress addresses?<= span style=3D"FONT-FAMILY: Courier; COLOR: #1f497d; FONT-SIZE: 10pt">

[Bruno] I a priori see 3 options, but this is o= pen for discussion

1-   &nbs= p;  If you want to use MPLS hiera= rchy. ASBR1x advertise in IGP the SIDs/MPLS labels as local labels. PE11 wi= ll need to use a 2 label stack: Node_SID(ASBR1x), Prefix_SID (PE2y).

2-   &nbs= p;  If you don=A1=AFt want to use= MPLS hierarchy:

a.   &nbs= p;   ASBR1x only advertise the IP = reachability. The SID mapping is advertised by the mapping server.

b.   &nbs= p;  Assuming AS2 also use SPRING,= then the real issue is the redistribution between protocols. IGP->BGP-&= gt;IGP. This can be done with a BGP extension to carry the SID. e.g. https://tools.ietf.org/html/draft-keyupate-idr-bgp-prefix-sid-00=

 

[Robin] My objective is not to persue the solut= ion. My proposed challenges is as follows:

1) In order to support proxy egress for SR-BE p= ath, we have to configure the SID/label for the proxy egress nodes, so whic= h ASBR we should to choose to configure these SID/label bindings?

2) If there are 10,000 proxy egress addresses p= roposed by seamless MPLS, this means we have to configure 10,000 SID/label = bindings on one ASBR? The huge configuration work cannot be accepted according to my understanding.

3) Since the proxy egress is learned from outsi= de of the network, if configure the static the SID/label for a specific pro= xy egress, but the proxy egress is not learned, the SID/label is wasted. If not

configured, but the proxy egress is learned, th= e SR-BE path does not work. How to cope with the issues?

 

 

 

On both ASBR11 and ASBR22? If there more ASBRs, there will be more configuration work. = Is it right?

[Bruno] no, see above with 3 solutions. Others = could be discussed if needed.


2. According to seamless MPLS, there may be 10,000 node addresses. <= span style=3D"FONT-FAMILY: Courier; COLOR: black; FONT-SIZE: 10pt">If take = the assumption, it will be a great configuration work.
3. The label route on the ASBR can be dymamic changed. Is there the case th= at the more or less SID/Labels are configured?

[Bruno] I don=A1=AFt see what you mean.<= /p>

If my understanding is right, comparing with the simple case wit= h actual egress, there will be more challenge for the proxy egress

case= for SR. In fact, there are more usecases of proxy egress:
1. C & C: Proxy egress for the VPN routes
2. Seamless MPLS: Proxy egress for the LDP DoD

[Bruno] For the downstream direction (signaling= toward upstream), If you use BGP, you can still use BGP. If you use IGP cf= solutions 1 & 2.a above.

3. S= ome usecases which needs LDP node and Non-LDP node coexists.

I wo= nder if you have thought about the proxy egress scenarios and what is the p= ossible solution? If the proxy egress cannot be
supported, there will be more challenges:
1. LDP cannot be replaced by SR-BE path. In the above usecase, LDP Proxy Eg= ress and SR actual egress may have to co-existed. It will

be t= oo complexed and SR is totally unnecessary.
2. TI-FRR for the proxy egress case cannot supported either. But this case = can be supported by other FRR solutions.

[Bruno] TI-FRR protects solutions using the IGP= (1 & 2.a).

Node protecting BGP destination is possible (e.= g. draft-minto-2547-egress-node-fast-protection) but this is a different st= ory.

 

/Bruno 

Hope to get your opinion on the progress egress for SR.

 


Regards,
Robin

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D47727D58nkgeml506mbxchi_-- From nobody Tue Jan 20 02:08:00 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A741AD2C0 for ; Tue, 20 Jan 2015 02:07:53 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgNKOqeslSsn for ; Tue, 20 Jan 2015 02:07:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4633A1AD09C for ; Tue, 20 Jan 2015 02:07:51 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 8BE943B4164 for ; Tue, 20 Jan 2015 11:07:46 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 665FEC8075 for ; Tue, 20 Jan 2015 11:07:46 +0100 (CET) Received: from [10.193.71.211] (10.197.38.4) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 20 Jan 2015 11:07:42 +0100 Date: Tue, 20 Jan 2015 11:07:41 +0100 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.4] Message-ID: <31315_1421748466_54BE28F2_31315_8209_1_87a47bd4-2859-4850-9c3d-3d1c469cc3b0@PEXCVZYH01.corporate.adroot.infra.ftgroup> X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.20.81522 Archived-At: Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 10:07:57 -0000 Hi all. This necessary I-D looks ready to move forward. I have spotted a few nits that may be addressed later in the publication process: - s/those RFC/those RFCs/ [twice: abstract and introduction] - "DS" deserves expansion at first use [routing loves "DS": Downstream, Diffserv, Dual Stack, etc.] - s/both TLVs shares/both TLVs share/ - In the "DS flag" registry name field, the capital F has vanished: is that on purpose? Regards, Julien Jan. 15, 2015 - Ross Callon: > Working Group, > This is to initiate a two week working group last call on > draft-ietf-mpls-lsp-ping-registry-00. > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > There are no IPR disclosures against this document. All the authors have > stated on the working group mailing list that they are not aware of any > IPR that relates to this draft. > This working group last call ends January 29, 2015. > Ross > for the MPLS wg chairs > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Tue Jan 20 03:47:32 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA9B1B29EB; Tue, 20 Jan 2015 03:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZplIQm1NLTx; Tue, 20 Jan 2015 03:47:24 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258D41B29DF; Tue, 20 Jan 2015 03:47:23 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0KBlMpE016624; Tue, 20 Jan 2015 11:47:22 GMT Received: from 950129200 (178-190-140-73.adsl.highway.telekom.at [178.190.140.73]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0KBlKQC016599 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2015 11:47:21 GMT From: "Adrian Farrel" To: Date: Tue, 20 Jan 2015 11:47:20 -0000 Message-ID: <054601d034a6$da268f40$8e73adc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA0ptW+dTYevG+7RUeuvyEFLp/bWg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21264.006 X-TM-AS-Result: No--22.652-10.0-31-10 X-imss-scan-details: No--22.652-10.0-31-10 X-TMASE-MatchedRID: d1I8/WNsBW5JOUjEvT0q+2zBijri5+RVQPCWRE0Lo8IJmdXzOhEMdvzE 5fw2C9LfUAFcfB2J+2yHfukMOAE4Tv9Nl0WAv/HrdiLDwvWethhBXoFkn1Z4Vrl+cLJWP9lZgwO 8VyXMhRjkEzU1JofnWLjgmytTEBayqyqf6qWHukU5yOdvO+rz3+4Z3yke5WgSiqL4na19PJ24I4 lyB2hc3QZZzxPWNFJY1Q6esTeosV0S5iXdhf8hbmoeWgEnkImxlWXxvHK+rV4OAHqXajwVGNKmy J56Qa3EJFdcwKgrTDJg+/B9tammQbnuANUvLzt6fxzygoxuBhgpWss5kPUFdLRWD4ydITYYK937 aFdF5XNb0Paratu11apQggjDTxT/pEOHRag0ivVIRA38P/dwbsmmXM8NVa682nVuImEjI1Fdrb7 MTVw/5bD1hMBclwCfOkFzm5NIdb4YzUbg+r0vVJEbNXwHGDRxO1K5iM8Q6KBm+uTUWJSSYCGEMA Wxi4VzATXuPGzTRmXsxKstGJLsCNK1EXQfDHRTaDCzqDR7DPZ/qILR82ilmfgnJH5vm2+gBwCVL GJ6cz3CIAP5moMWLi2+lyx46iL0nJe/ra8FPlgWGNJh59eVbH0tCKdnhB58vqq8s2MNhPDPPeN6 HN6d7ARE6GKKq2/yC24oEZ6SpSk+Mqg+CyrtwA== Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-seamless-mcast.all@tools.ietf.org Subject: [mpls] Last Call comments draft-ietf-mpls-seamless-mcast-15.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 11:47:27 -0000 As part of my AD review of this document I found a number of small editorial issues that I am raising now as Last Call comments. Adrian === idnits reveals that the copyright year needs to be 2015. Please update that if you revise the document. idnits also points out that you probably don't need the boilerplate for pre-RFC5378 work. unless you are sure you need it, please take it out. --- I think that the RFC Editor will need your help expanding some of the abbreviations that are not listed as "well known" in the list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt You might kick this off by doing a scrub yourselves. --- Section 3 line 1 s/suppose/assumed/ --- 5.1.2 and 5.2.2 titles s/re-advertise/re-advertised/ --- 5.1.3 has To avoid requiring ABRs to participate in the propagation of C- multicast routes, this document requires ABRs NOT to modify BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. "NOT" is not a 2119 term in its own right. Suggest you rephrase as To avoid requiring ABRs to participate in the propagation of C- multicast routes, this document specifies that ABRs MUST NOT modify BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. --- In 6.1.2 If the application is global table multicast, then the unicast routes to multicast sources/RPs SHOULD carry the "VRF Route Import" Extended Community [RFC6514] where the IP address in the Global Administrator field is set to the IP address of the PE or ASBR advertising the unicast route. I wondered about this "SHOULD". Trying to decide why we might decide to vary that and what the consequences would be. Similarly one para later... Further, if the application is global table multicast, then the BGP unicast routes that advertise the routes to the IP addresses of PEs/ASBRs/ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop Extended Community. --- 7.2.2.1 This section applies only if it is desirable to send a particular (S, G) or (*, G) global table multicast flow only to those egress PEs that have receivers for that multicast flow. Is this s/desirable/desired/ ? If not then some guidance as to how to judge when it is desirable. If so, then perhaps you could be a little less passive-voice: who desires it? --- 7.2.2.2 It may be desirable for an ingress PE to carry multiple multicast flows associated with the global table multicast over the same inter- area P2MP service LSP. Can you give guidance as to why it might be desirable? Or possible (as above) s/desirable for/desired that/ also adding some explanation about who has the desire (and possible why). --- 7.2.3 To allow the egress PE to determine the sender upstream node, the intra-area P2MP LSP must be signaled with no PHP, when the mapping between the inter-area P2MP service LSP for global table multicast service and the intra-area P2MP LSP is many-to-one. The lower case "must" jumped out. Probably upper case? --- Section 14 Is the term "transport LSP" introduced by this document? If so, a little more definition would be nice (just a few words to make it clear that you are defining the term). If not, can you supply a reference. --- After 38 pages of spec you have just five lines of security considerations. You don't even mention BGP security directly. I confess that I don't see anything obvious that is missing, but are there no specific risks associated with this approach? No amplification through mcast? > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The > IESG > Sent: 20 January 2015 01:04 > To: IETF-Announce > Cc: mpls@ietf.org > Subject: Last Call: (Inter-Area P2MP > Segmented LSPs) to Proposed Standard > > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'Inter-Area P2MP Segmented LSPs' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-02-02. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > This document describes procedures for building inter-area point-to- > multipoint (P2MP) segmented service LSPs by partitioning such LSPs > into intra-area segments and using BGP as the inter-area routing and > label distribution protocol. Within each IGP area the intra-area > segments are either carried over intra-area P2MP LSPs, using P2MP LSP > hierarchy, or instantiated using ingress replication. The intra-area > P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress > replication is used within an IGP area, then (multipoint-to-point) > LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP > area. The applications/services that use such inter-area service LSPs > may be BGP Multicast VPN, VPLS multicast, or global table multicast > over MPLS. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/2047/ From nobody Tue Jan 20 07:49:26 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938101B2DC3; Tue, 20 Jan 2015 07:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nDtrU-WD9bK; Tue, 20 Jan 2015 07:49:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 350BE1B2E06; Tue, 20 Jan 2015 07:49:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120154921.2851.98564.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 07:49:21 -0800 Archived-At: Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Controlling State Advertisements Of Non-negotiated LDP Applications' to Proposed Standard (draft-ietf-mpls-ldp-ip-pw-capability-09.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 15:49:25 -0000 The IESG has approved the following document: - 'Controlling State Advertisements Of Non-negotiated LDP Applications' (draft-ietf-mpls-ldp-ip-pw-capability-09.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability/ Technical Summary There is no capability negotiation done for Label Distribution Protocol (LDP) applications that setup Label Switched Paths (LSPs) for IP prefixes or that signal Point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise be advertised over the established LDP session. Working Group Summary There is a strong support for this document in the working group and it has been has been well reviewed. Document Quality We know of ongoing/intended implementations. Personnel Loa Andersson is the document shepherd. Adrian Farrel is the responsible AD. From nobody Tue Jan 20 12:40:48 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CD21B2B21; Tue, 20 Jan 2015 12:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QALZHsWoVLxq; Tue, 20 Jan 2015 12:40:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E93741B2B5B; Tue, 20 Jan 2015 12:40:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120204041.13054.51744.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 12:40:41 -0800 Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 20:40:44 -0000 Alia Atlas has entered the following ballot position for draft-ietf-mpls-in-udp-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am still waiting for this review comment to be resolved. In Sec 4, it says: "That is to say, if the destination IP address is a multicast address, the top label SHOULD be upstream-assigned, otherwise if the destination IP address is a ..." This seems to require that the IP network is capable of supporting multicast where one can easily see using MPLS-in-UDP tunnels to provide point-to-point tunnels. Is there a reason that the negotiation mechanism to set up the MPLS-in-UDP tunnel wouldn't also be able to specify alternate destination IP addresses for upstrteam-assigned? How much discussion and agreement has this limitation had?? From nobody Tue Jan 20 19:12:59 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AE61A01F2; Tue, 20 Jan 2015 19:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx38J4w-aRYI; Tue, 20 Jan 2015 19:12:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1D71A01E7; Tue, 20 Jan 2015 19:12:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRO37889; Wed, 21 Jan 2015 03:12:31 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 21 Jan 2015 03:12:30 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 21 Jan 2015 11:12:27 +0800 From: Xuxiaohu To: Alia Atlas , The IESG Thread-Topic: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) Thread-Index: AQHQNPFmwdIsDbrCNEKSMvMGh5Y85pzJ1ebw Date: Wed, 21 Jan 2015 03:12:27 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FBAD1@NKGEML512-MBS.china.huawei.com> References: <20150120204041.13054.51744.idtracker@ietfa.amsl.com> In-Reply-To: <20150120204041.13054.51744.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 03:12:43 -0000 SGkgQWxpYSwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIEFEIHJldmlldyBvZiB0aGlzIG5ldyBy ZXZpc2lvbi4gUGxlYXNlIHNlZSBteSBleHBsYW5hdGlvbiBpbmxpbmUuDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxpYSBBdGxhcyBbbWFpbHRvOmFrYXRsYXNAZ21h aWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjEsIDIwMTUgNDo0MSBBTQ0KPiBU bzogVGhlIElFU0cNCj4gQ2M6IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRm LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBMb2ENCj4gQW5kZXJzc29uOyBtcGxzQGlldGYu b3JnDQo+IFN1YmplY3Q6IEFsaWEgQXRsYXMnIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tcGxzLWlu LXVkcC0xMDogKHdpdGggRElTQ1VTUykNCj4gDQo+IEFsaWEgQXRsYXMgaGFzIGVudGVyZWQgdGhl IGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtbXBscy1pbi11ZHAt MTA6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1 Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8g aHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwN Cj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90 IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBJIGFtIHN0aWxsIHdhaXRp bmcgZm9yIHRoaXMgcmV2aWV3IGNvbW1lbnQgdG8gYmUgcmVzb2x2ZWQuDQo+IA0KPiBJbiBTZWMg NCwgaXQgc2F5czoNCj4gIlRoYXQgaXMgdG8gc2F5LCBpZiB0aGUgZGVzdGluYXRpb24gSVAgYWRk cmVzcyBpcyBhIG11bHRpY2FzdCBhZGRyZXNzLCB0aGUgdG9wIGxhYmVsDQo+IFNIT1VMRCBiZSB1 cHN0cmVhbS1hc3NpZ25lZCwgb3RoZXJ3aXNlIGlmIHRoZSBkZXN0aW5hdGlvbg0KPiBJUCBhZGRy ZXNzIGlzIGEgLi4uIiAgIFRoaXMgc2VlbXMgdG8gcmVxdWlyZSB0aGF0IHRoZSBJUCBuZXR3b3Jr IGlzDQo+IGNhcGFibGUgb2Ygc3VwcG9ydGluZyBtdWx0aWNhc3Qgd2hlcmUgb25lIGNhbiBlYXNp bHkgc2VlIHVzaW5nIE1QTFMtaW4tVURQDQo+IHR1bm5lbHMgdG8gcHJvdmlkZSBwb2ludC10by1w b2ludCB0dW5uZWxzLiAgSXMgdGhlcmUgYSByZWFzb24gdGhhdCB0aGUNCg0KUDJQIE1QTFMtaW4t VURQIHR1bm5lbHMgY291bGQgYmUgdXNlZCB0byBjYXJyeSBtdWx0aWNhc3QgSVAgb3IgRXRoZXJu ZXQgdHJhZmZpYyBhcyB3ZWxsIChlLmcuLCBpbiB0aGUgaW5ncmVzcyByZXBsaWNhdGlvbiBtb2Rl KS4gSW4gdGhpcyBjYXNlLCB0aGUgTVBMUyBsYWJlbHMgc2hvdWxkIGJlIGRvd25zdHJlYW0tYXNz aWduZWQuIEFsdGhvdWdoIGl0J3MgcG9zc2libGUgdG8gdXNlIHVwc3RyZWFtLWFzc2lnbmVkIGxh YmVscyBpbiB0aGVvcnksIGl0IGJyaW5ncyBubyB2YWx1ZSBpbiBwcmFjdGljZSBzaW5jZSBpdCdz IG1vcmUgY29tcGxleCBjb21wYXJlZCB0byB0aGUgdXNhZ2Ugb2YgZG93bnN0cmVhbS1hc3NpZ25l ZCBsYWJlbHMgZnJvbSB0aGUgaW1wbGVtZW50YXRpb24gcGVyc3BlY3RpdmUuIEluIG90aGVyIHdv cmRzLCBpdCBkb2Vzbid0IHJlcXVpcmUgdGhhdCB0aGUgSVAgbmV0d29yayBpcyBjYXBhYmxlIG9m IHN1cHBvcnRpbmcgbXVsdGljYXN0IGluIG9yZGVyIHRvIHRyYW5zcG9ydCBtdWx0aWNhc3QgSVAg b3IgRXRoZXJuZXQgdHJhZmZpYyBvdmVyIE1QTFMtaW4tVURQIHR1bm5lbHMuIA0KDQo+IG5lZ290 aWF0aW9uIG1lY2hhbmlzbSB0byBzZXQgdXAgdGhlIE1QTFMtaW4tVURQIHR1bm5lbCB3b3VsZG4n dCBhbHNvIGJlIGFibGUNCj4gdG8gc3BlY2lmeSBhbHRlcm5hdGUgZGVzdGluYXRpb24gSVAgYWRk cmVzc2VzIGZvciB1cHN0cnRlYW0tYXNzaWduZWQ/ICBIb3cNCg0KSW4gbXkgdW5kZXJzdGFuZGlu ZywgdGhlIG9ubHkgcmVhbCB1c2UgY2FzZSBvZiB1cHN0cmVhbS1hc3NpZ25lZCBsYWJlbHMgaXMg bXVsdGljYXN0IHNlcnZpY2UgdXAgdGlsbCBub3cuIElmIG11bHRpY2FzdCB0cmFmZmljIGlzIHRy YW5zcG9ydGVkIG92ZXIgUDJNUCBNUExTLWluLVVEUCB0dW5uZWxzLCB0aGUgTVBMUyBsYWJlbCBN VVNUIGJlIHVwc3RyZWFtLWFzc2lnbmVkLiBPdGhlcndpc2UsIHRoZSBNUExTIGxhYmVsIHNob3Vs ZCBiZSBkb3duc3RyZWFtLWFzc2lnbmVkIGFzIHNhaWQgYWJvdmUuDQoNCj4gbXVjaCBkaXNjdXNz aW9uIGFuZCBhZ3JlZW1lbnQgaGFzIHRoaXMgbGltaXRhdGlvbiBoYWQ/Pw0KDQpNYXliZSBteSBw b2ludHMgYXMgbWVudGlvbmVkIGFib3ZlIGFyZSBpbmNvcnJlY3QuIFRoZXJlZm9yZSwgSSdtIGxv b2tpbmcgZm9yd2FyZCB0byBzZWVpbmcgZnVydGhlciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMg b24gdGhpcyBwb2ludCwgZXNwZWNpYWxseSBmcm9tIHRob3NlIHBlb3BsZSB3aG8gYXJlIGtub3ds ZWRnZWFibGUgYWJvdXQgdGhlIHVzYWdlIG9mIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVscy4NCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQo+IA0KPiANCj4gDQoNCg== From nobody Tue Jan 20 19:29:26 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EAD1A024C for ; Tue, 20 Jan 2015 19:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld94Gbp0jRsA for ; Tue, 20 Jan 2015 19:29:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C128B1A023E for ; Tue, 20 Jan 2015 19:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8184; q=dns/txt; s=iport; t=1421810957; x=1423020557; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AGNRALsDfmVKkViD15IB6PT0Z1W1oZJ7pllkGKVj7z4=; b=OS+cz0x4xtvN8StgJHMGZxsCYT2as0GojjPV68joiLcS02K9ounEIA4N 57QaoqqdcnQ//wmUScWqVr0Q0vDm1p9IMJVb0FZ7cH/T+tY5BQoyyh2Av x4WVkSZ3ZhVdwBlx79yOgBnUU/r4SmNlw2rfPCalPOecUUF1blDArrzhC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFACYcv1StJA2F/2dsb2JhbABbgkNDUlgEzCYCgR5DAQEBAQF9hAwBAQEEHRBBCxACAQgOAwQBAQsdBzIUCQgBAQQBDQUIiCTQUgEBAQEBAQEBAQEBAQEBAQEBAQEBARePSDEGAYMWgRMFjHqBX4orgnyKXYM9IoNub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,439,1418083200"; d="scan'208,217";a="389253294" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jan 2015 03:29:16 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t0L3TFsx018907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 03:29:15 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.81]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 21:29:15 -0600 From: "Faisal Iqbal (faiqbal)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 Thread-Index: AdAwfA5Rl6NPHWj3TvCQ85M9DnILEAErXPAg Date: Wed, 21 Jan 2015 03:29:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.86] Content-Type: multipart/alternative; boundary="_000_E7820E943E0928409E27AA7805EA720380E00FD4xmbalnx15ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "" , "draft-ietf-mpls-lsp-ping-registry@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 03:29:19 -0000 --_000_E7820E943E0928409E27AA7805EA720380E00FD4xmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a concise, useful and well-written document. I support this draft f= or publication so that WG can proceed on ietf-mpls-entropy-lsp-ping and iet= f-mpls-lsp-ping-lag-multipath. Regards, Faisal From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, January 14, 2015 11:31 PM To: mpls@ietf.org Cc: ; draft-ietf-mpls-lsp-ping-registry@tools.i= etf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-regist= ry-00 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-lsp-ping-registry-00. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have stated on the working group mailing list that they are not aware of any IPR that relates to this draft. This working group last call ends January 29, 2015. Ross for the MPLS wg chairs --_000_E7820E943E0928409E27AA7805EA720380E00FD4xmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is a concise, useful= and well-written document. I support this draft for publication so that WG= can proceed on ietf-mpls-entropy-lsp-ping and ietf-mpls-lsp-ping-lag-multi= path.

 <= /p>

Regards,

Faisal<= /p>

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, January 14, 2015 11:31 PM
To: mpls@ietf.org
Cc: <mpls-chairs@tools.ietf.org>; draft-ietf-mpls-lsp-ping-reg= istry@tools.ietf.org
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping= -registry-00

 

Working Group,

 

This is to initiate a two week working = group last call on

draft-ietf-mpls-lsp-ping-registry-00.

 

Please send your comments to the mpls w= g mailing list (mpls@ietf.org).

 

There are no IPR disclosures against th= is document. All the authors have

stated on the working group mailing lis= t that they are not aware of any

IPR that relates to this draft.

 

This working group last call ends Janua= ry 29, 2015. 

 

Ross

for the MPLS wg chairs

 

--_000_E7820E943E0928409E27AA7805EA720380E00FD4xmbalnx15ciscoc_-- From nobody Wed Jan 21 03:10:43 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D401A19EF; Wed, 21 Jan 2015 03:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osLKZrol4DU9; Wed, 21 Jan 2015 03:09:38 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1B11A1A23; Wed, 21 Jan 2015 03:09:37 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LB9UKS019210; Wed, 21 Jan 2015 11:09:30 GMT Received: from 950129200 (089144192169.atnat0001.highway.a1.net [89.144.192.169]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LB9RnI019198 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 11:09:28 GMT From: "Adrian Farrel" To: "'Xuxiaohu'" , "'Alia Atlas'" , "'The IESG'" References: <20150120204041.13054.51744.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FBAD1@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FBAD1@NKGEML512-MBS.china.huawei.com> Date: Wed, 21 Jan 2015 11:09:27 -0000 Message-ID: <00e601d0356a$ba3315e0$2e9941a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGtiNBqmnn4hUJoEt4+WxKFPzoeewJcJVZznPzhLHA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21270.001 X-TM-AS-Result: No--21.643-10.0-31-10 X-imss-scan-details: No--21.643-10.0-31-10 X-TMASE-MatchedRID: gTucSmrmRMMwk3SkELeip7Gj3LN0+Ey9s1hEwUD1d/J94c+e7fWIcCOh B/49+Z8oQCUkT/+sPdRBsJaf/YUTGAM6op3uvrMHxZQoGMRGhhNAq6/y5AEOOvMuCEhNXx7OiKw uibVqTFfxrMH6PtzklK6H0sz2GGlQ58xsyI+eeCdbuDP8ZuCmXruesBT0pDFRtWFMPVR2Crzk1L hA7Mwru8OrvhE/lA0iwDTc/wNgEcP0kOmVivCT5fHkpkyUphL9Ud7Bjfo+5jQ5CCUkHUNu7tLuX 2hj/M7UJP00JqzxhIDANNz/A2ARwyUetYXFvf04vHKClHGjjr1+Mk6ACsw4JuTqs5BN/8M2gsYR edTa5fDJx0UjgCpQwQ+7lVm8sg1SPyFc0r7cUGFUXvI6K7iraWv34qCfZeB4Xcrx57pzoqP0Mir jzklqaH3rpeg52m/QsnEYhH55mj9Itg64/Sl11wPZZctd3P4BkT7cMJfe6JsdY1owGR6BJysi3J PF5sc4BCaoisinHS+rcAgDGD4SOoKJRpKTDwLfE0Q83A2vD+taNaxZBRbNWm3D6f6IpbLIVhbDE H23DRN5/5kb+TlT7pFdqDUSMsCU5eObWKza9i0pkU5pBuPqH6KaxHqGRwkC2Fq6de/aaIYtpTeE sjPeCAtc8Ae+Hp27snEYhH55mj9cqim4vwMm8KZCFtxq3n99LPZWqnMLGVKbKItl61J/ybLn+0V m71Lcq7rFUcuGp/G8QIu4z6HhEH7cGd19dSFd Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 11:09:49 -0000 X-List-Received-Date: Wed, 21 Jan 2015 11:09:49 -0000 [co-author hat - not being an AD] In a separate private reply to Alia I just suggested that the text about = upstream assigned labels is overly optimistic. I'm not sure when it crept in. The assumption is that a multi-access link is being replaced with a UDP = multicast tunnel. I suspect this is unlikely and I have no idea why it = would be necessary unless: - the IP/UDP network supports multicast - the traffic being distributed is multicast - there are more than two sites being connected - the volume of traffic is more than moderate Otherwise, p2p UDP tunnels would be enough. My suggestion to Alia is to make upstream assigned labels for future = study. That way this I-D can move forward (at last!) and if anyone is = interested in the multicast work they can write a short additional = document. The fix would be to remove the offending text from section 4 and to add = a note to the Abstract and Introduction that this document is limited to = downstream assigned labels. Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: 21 January 2015 03:12 > To: Alia Atlas; The IESG > Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; > mpls@ietf.org; Loa Andersson > Subject: RE: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with = DISCUSS) >=20 > Hi Alia, >=20 > Thanks a lot for your AD review of this new revision. Please see my = explanation > inline. >=20 > > -----Original Message----- > > From: Alia Atlas [mailto:akatlas@gmail.com] > > Sent: Wednesday, January 21, 2015 4:41 AM > > To: The IESG > > Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-in-udp@tools.ietf.org; Loa > > Andersson; mpls@ietf.org > > Subject: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with = DISCUSS) > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-mpls-in-udp-10: Discuss > > > > When responding, please keep the subject line intact and reply to = all email > > addresses included in the To and CC lines. (Feel free to cut this = introductory > > paragraph, however.) > > > > > > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ > > > > > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > I am still waiting for this review comment to be resolved. > > > > In Sec 4, it says: > > "That is to say, if the destination IP address is a multicast = address, the top label > > SHOULD be upstream-assigned, otherwise if the destination > > IP address is a ..." This seems to require that the IP network is > > capable of supporting multicast where one can easily see using = MPLS-in-UDP > > tunnels to provide point-to-point tunnels. Is there a reason that = the >=20 > P2P MPLS-in-UDP tunnels could be used to carry multicast IP or = Ethernet traffic as > well (e.g., in the ingress replication mode). In this case, the MPLS = labels should be > downstream-assigned. Although it's possible to use upstream-assigned = labels in > theory, it brings no value in practice since it's more complex = compared to the > usage of downstream-assigned labels from the implementation = perspective. In > other words, it doesn't require that the IP network is capable of = supporting > multicast in order to transport multicast IP or Ethernet traffic over = MPLS-in-UDP > tunnels. >=20 > > negotiation mechanism to set up the MPLS-in-UDP tunnel wouldn't also = be able > > to specify alternate destination IP addresses for = upstrteam-assigned? How >=20 > In my understanding, the only real use case of upstream-assigned = labels is > multicast service up till now. If multicast traffic is transported = over P2MP MPLS-in- > UDP tunnels, the MPLS label MUST be upstream-assigned. Otherwise, the = MPLS > label should be downstream-assigned as said above. >=20 > > much discussion and agreement has this limitation had?? >=20 > Maybe my points as mentioned above are incorrect. Therefore, I'm = looking > forward to seeing further comments and suggestions on this point, = especially > from those people who are knowledgeable about the usage of upstream- > assigned labels. >=20 > Best regards, > Xiaohu > > > > > > From nobody Wed Jan 21 04:44:43 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3951A1A3C; Wed, 21 Jan 2015 04:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y38sE_y2nvtD; Wed, 21 Jan 2015 04:44:38 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F681A1A38; Wed, 21 Jan 2015 04:44:36 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.75.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 56706180159D; Wed, 21 Jan 2015 13:44:30 +0100 (CET) Message-ID: <54BF9F28.3090908@pi.nu> Date: Wed, 21 Jan 2015 20:44:24 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Xuxiaohu' , 'Alia Atlas' , 'The IESG' References: <20150120204041.13054.51744.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FBAD1@NKGEML512-MBS.china.huawei.com> <00e601d0356a$ba3315e0$2e9941a0$@olddog.co.uk> In-Reply-To: <00e601d0356a$ba3315e0$2e9941a0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 12:44:41 -0000 Adrian, If I understand you correctly you say that the current text makes a general statement that UDP multicast tunnels are needed and if they are we need the upstream assigned labels; yuo on the other hand say that this is a corner case that we can (for the time being) live with the multi-access link and UDP point to point links are enough. If this is correct, I support scoping the document as you proposed. /Loa On 2015-01-21 19:09, Adrian Farrel wrote: > [co-author hat - not being an AD] > > In a separate private reply to Alia I just suggested that the text about upstream assigned labels is overly optimistic. > > I'm not sure when it crept in. > > The assumption is that a multi-access link is being replaced with a UDP multicast tunnel. I suspect this is unlikely and I have no idea why it would be necessary unless: > - the IP/UDP network supports multicast > - the traffic being distributed is multicast > - there are more than two sites being connected > - the volume of traffic is more than moderate > Otherwise, p2p UDP tunnels would be enough. > > My suggestion to Alia is to make upstream assigned labels for future study. That way this I-D can move forward (at last!) and if anyone is interested in the multicast work they can write a short additional document. > > The fix would be to remove the offending text from section 4 and to add a note to the Abstract and Introduction that this document is limited to downstream assigned labels. > > Adrian > >> -----Original Message----- >> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Xuxiaohu >> Sent: 21 January 2015 03:12 >> To: Alia Atlas; The IESG >> Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; >> mpls@ietf.org; Loa Andersson >> Subject: RE: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) >> >> Hi Alia, >> >> Thanks a lot for your AD review of this new revision. Please see my explanation >> inline. >> >>> -----Original Message----- >>> From: Alia Atlas [mailto:akatlas@gmail.com] >>> Sent: Wednesday, January 21, 2015 4:41 AM >>> To: The IESG >>> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; Loa >>> Andersson; mpls@ietf.org >>> Subject: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) >>> >>> Alia Atlas has entered the following ballot position for >>> draft-ietf-mpls-in-udp-10: Discuss >>> >>> When responding, please keep the subject line intact and reply to all email >>> addresses included in the To and CC lines. (Feel free to cut this introductory >>> paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I am still waiting for this review comment to be resolved. >>> >>> In Sec 4, it says: >>> "That is to say, if the destination IP address is a multicast address, the top label >>> SHOULD be upstream-assigned, otherwise if the destination >>> IP address is a ..." This seems to require that the IP network is >>> capable of supporting multicast where one can easily see using MPLS-in-UDP >>> tunnels to provide point-to-point tunnels. Is there a reason that the >> >> P2P MPLS-in-UDP tunnels could be used to carry multicast IP or Ethernet traffic as >> well (e.g., in the ingress replication mode). In this case, the MPLS labels should be >> downstream-assigned. Although it's possible to use upstream-assigned labels in >> theory, it brings no value in practice since it's more complex compared to the >> usage of downstream-assigned labels from the implementation perspective. In >> other words, it doesn't require that the IP network is capable of supporting >> multicast in order to transport multicast IP or Ethernet traffic over MPLS-in-UDP >> tunnels. >> >>> negotiation mechanism to set up the MPLS-in-UDP tunnel wouldn't also be able >>> to specify alternate destination IP addresses for upstrteam-assigned? How >> >> In my understanding, the only real use case of upstream-assigned labels is >> multicast service up till now. If multicast traffic is transported over P2MP MPLS-in- >> UDP tunnels, the MPLS label MUST be upstream-assigned. Otherwise, the MPLS >> label should be downstream-assigned as said above. >> >>> much discussion and agreement has this limitation had?? >> >> Maybe my points as mentioned above are incorrect. Therefore, I'm looking >> forward to seeing further comments and suggestions on this point, especially >> from those people who are knowledgeable about the usage of upstream- >> assigned labels. >> >> Best regards, >> Xiaohu >>> >>> >>> > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jan 21 06:23:57 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2D51A1ABE; Wed, 21 Jan 2015 06:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBbgI1D0KwNL; Wed, 21 Jan 2015 06:23:34 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B941A1ACC; Wed, 21 Jan 2015 06:23:33 -0800 (PST) Received: by mail-yk0-f181.google.com with SMTP id 79so6629241ykr.12; Wed, 21 Jan 2015 06:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MTk3Ql0Ews7yN9WZJdk1AiwuRspF+UWpxYlmY4b4fC8=; b=SmYTMalhOs29Vv/DAoQYqxzpHspB+26cMaINYCd+epI9aLnxMARLp1nw9IE3Gn79aZ AOOsQ8LdZqPkiferIlptDIghcbMr/G/Rv2vvi3jKfY0Qxt89LeaxVLdoe1US6tY0pUuM mk/I1Se+EeO3iZbUPJgScdR7oPFaBLRj/uGWFNZJ8d/FjEs5fjSZUSldnlaVZRWqqsha RHbY076ngLTA6GBARrF0pmGCNXAHdCFCzddWCGhKRBvfimaf1lc8QZXkyQssdEBPnVmO MhKASPg3U6/73ouZlm4Gt5HZaeLnzv4ptVV0PLw5cBQmjpajMKjEAFhYAx5CHhBixBW8 Bq0w== MIME-Version: 1.0 X-Received: by 10.170.153.8 with SMTP id u8mr27644237ykc.52.1421850212240; Wed, 21 Jan 2015 06:23:32 -0800 (PST) Received: by 10.170.133.18 with HTTP; Wed, 21 Jan 2015 06:23:32 -0800 (PST) In-Reply-To: <54BF9F28.3090908@pi.nu> References: <20150120204041.13054.51744.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FBAD1@NKGEML512-MBS.china.huawei.com> <00e601d0356a$ba3315e0$2e9941a0$@olddog.co.uk> <54BF9F28.3090908@pi.nu> Date: Wed, 21 Jan 2015 09:23:32 -0500 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=001a113a5baad3127e050d2a4c50 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-in-udp@tools.ietf.org" , The IESG , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:23:42 -0000 --001a113a5baad3127e050d2a4c50 Content-Type: text/plain; charset=UTF-8 Loa & Adrian, My concern was that requiring the underlay to support multicast routing might be too restrictive in a data center. However, if you are comfortable that upstream labels only make sense if the link technology is multi-access (so a multicast UDP tunnel is the equivalent), then I am ok with the text as is. I was concerned that we were not missing a case that would be hard to fix later and wanted to have that double-checked. Thanks, Alia On Wed, Jan 21, 2015 at 7:44 AM, Loa Andersson wrote: > Adrian, > > If I understand you correctly you say that the current text makes a > general statement that UDP multicast tunnels are needed and if they > are we need the upstream assigned labels; yuo on the other hand say > that this is a corner case that we can (for the time being) live with > the multi-access link and UDP point to point links are enough. > > If this is correct, I support scoping the document as you proposed. > > /Loa > > > > > On 2015-01-21 19:09, Adrian Farrel wrote: > >> [co-author hat - not being an AD] >> >> In a separate private reply to Alia I just suggested that the text about >> upstream assigned labels is overly optimistic. >> >> I'm not sure when it crept in. >> >> The assumption is that a multi-access link is being replaced with a UDP >> multicast tunnel. I suspect this is unlikely and I have no idea why it >> would be necessary unless: >> - the IP/UDP network supports multicast >> - the traffic being distributed is multicast >> - there are more than two sites being connected >> - the volume of traffic is more than moderate >> Otherwise, p2p UDP tunnels would be enough. >> >> My suggestion to Alia is to make upstream assigned labels for future >> study. That way this I-D can move forward (at last!) and if anyone is >> interested in the multicast work they can write a short additional document. >> >> The fix would be to remove the offending text from section 4 and to add a >> note to the Abstract and Introduction that this document is limited to >> downstream assigned labels. >> >> Adrian >> >> -----Original Message----- >>> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Xuxiaohu >>> Sent: 21 January 2015 03:12 >>> To: Alia Atlas; The IESG >>> Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; >>> mpls@ietf.org; Loa Andersson >>> Subject: RE: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with >>> DISCUSS) >>> >>> Hi Alia, >>> >>> Thanks a lot for your AD review of this new revision. Please see my >>> explanation >>> inline. >>> >>> -----Original Message----- >>>> From: Alia Atlas [mailto:akatlas@gmail.com] >>>> Sent: Wednesday, January 21, 2015 4:41 AM >>>> To: The IESG >>>> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; >>>> Loa >>>> Andersson; mpls@ietf.org >>>> Subject: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with >>>> DISCUSS) >>>> >>>> Alia Atlas has entered the following ballot position for >>>> draft-ietf-mpls-in-udp-10: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email >>>> addresses included in the To and CC lines. (Feel free to cut this >>>> introductory >>>> paragraph, however.) >>>> >>>> >>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria. >>>> html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> I am still waiting for this review comment to be resolved. >>>> >>>> In Sec 4, it says: >>>> "That is to say, if the destination IP address is a multicast address, >>>> the top label >>>> SHOULD be upstream-assigned, otherwise if the destination >>>> IP address is a ..." This seems to require that the IP network is >>>> capable of supporting multicast where one can easily see using >>>> MPLS-in-UDP >>>> tunnels to provide point-to-point tunnels. Is there a reason that the >>>> >>> >>> P2P MPLS-in-UDP tunnels could be used to carry multicast IP or Ethernet >>> traffic as >>> well (e.g., in the ingress replication mode). In this case, the MPLS >>> labels should be >>> downstream-assigned. Although it's possible to use upstream-assigned >>> labels in >>> theory, it brings no value in practice since it's more complex compared >>> to the >>> usage of downstream-assigned labels from the implementation perspective. >>> In >>> other words, it doesn't require that the IP network is capable of >>> supporting >>> multicast in order to transport multicast IP or Ethernet traffic over >>> MPLS-in-UDP >>> tunnels. >>> >>> negotiation mechanism to set up the MPLS-in-UDP tunnel wouldn't also be >>>> able >>>> to specify alternate destination IP addresses for upstrteam-assigned? >>>> How >>>> >>> >>> In my understanding, the only real use case of upstream-assigned labels >>> is >>> multicast service up till now. If multicast traffic is transported over >>> P2MP MPLS-in- >>> UDP tunnels, the MPLS label MUST be upstream-assigned. Otherwise, the >>> MPLS >>> label should be downstream-assigned as said above. >>> >>> much discussion and agreement has this limitation had?? >>>> >>> >>> Maybe my points as mentioned above are incorrect. Therefore, I'm looking >>> forward to seeing further comments and suggestions on this point, >>> especially >>> from those people who are knowledgeable about the usage of upstream- >>> assigned labels. >>> >>> Best regards, >>> Xiaohu >>> >>>> >>>> >>>> >>>> >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a113a5baad3127e050d2a4c50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa & Adrian,

My concern was that r= equiring the underlay to support multicast routing might be too
r= estrictive in a data center.=C2=A0 However, if you are comfortable that ups= tream labels only
make sense if the link technology is multi-acce= ss (so a multicast UDP tunnel is the
equivalent), then I am ok wi= th the text as is.

I was concerned that we were no= t missing a case that would be hard to fix later and
wanted to ha= ve that double-checked.

Thanks,
Alia

On Wed, J= an 21, 2015 at 7:44 AM, Loa Andersson <loa@pi.nu> wrote:
Adrian,

If I understand you correctly you say that the current text makes a
general statement that UDP multicast tunnels are needed and if they
are we need the upstream assigned labels; yuo on the other hand say
that this is a corner case that we can (for the time being) live with
the=C2=A0 multi-access link and UDP point to point links are enough.

If this is correct, I support scoping the document as you proposed.

/Loa




On 2015-01-21 19:09, Adrian Farrel wrote:
[co-author hat - not being an AD]

In a separate private reply to Alia I just suggested that the text about up= stream assigned labels is overly optimistic.

I'm not sure when it crept in.

The assumption is that a multi-access link is being replaced with a UDP mul= ticast tunnel. I suspect this is unlikely and I have no idea why it would b= e necessary unless:
- the IP/UDP network supports multicast
- the traffic being distributed is multicast
- there are more than two sites being connected
- the volume of traffic is more than moderate
Otherwise, p2p UDP tunnels would be enough.

My suggestion to Alia is to make upstream assigned labels for future study.= That way this I-D can move forward (at last!) and if anyone is interested = in the multicast work they can write a short additional document.

The fix would be to remove the offending text from section 4 and to add a n= ote to the Abstract and Introduction that this document is limited to downs= tream assigned labels.

Adrian

-----Original Message-----
From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: 21 January 2015 03:12
To: Alia Atlas; The IESG
Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org;<= br> mpls@ietf.org; Loa A= ndersson
Subject: RE: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DI= SCUSS)

Hi Alia,

Thanks a lot for your AD review of this new revision. Please see my explana= tion
inline.

-----Original Message-----
From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Wednesday, January 21, 2015 4:41 AM
To: The IESG
Cc: mpls-ch= airs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; = Loa
Andersson; mpls@ietf.org=
Subject: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUS= S)

Alia Atlas has entered the following ballot position for
draft-ietf-mpls-in-udp-10: Discuss

When responding, please keep the subject line intact and reply to all email=
addresses included in the To and CC lines. (Feel free to cut this introduct= ory
paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discu= ss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/<= /a>



-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------

I am still waiting for this review comment to be resolved.

In Sec 4, it says:
"That is to say, if the destination IP address is a multicast address,= the top label
SHOULD be upstream-assigned, otherwise if the destination
IP address is a ..."=C2=A0 =C2=A0This seems to require that the IP net= work is
capable of supporting multicast where one can easily see using MPLS-in-UDP<= br> tunnels to provide point-to-point tunnels.=C2=A0 Is there a reason that the=

P2P MPLS-in-UDP tunnels could be used to carry multicast IP or Ethernet tra= ffic as
well (e.g., in the ingress replication mode). In this case, the MPLS labels= should be
downstream-assigned. Although it's possible to use upstream-assigned la= bels in
theory, it brings no value in practice since it's more complex compared= to the
usage of downstream-assigned labels from the implementation perspective. In=
other words, it doesn't require that the IP network is capable of suppo= rting
multicast in order to transport multicast IP or Ethernet traffic over MPLS-= in-UDP
tunnels.

negotiation mechanism to set up the MPLS-in-UDP tunnel wouldn't also be= able
to specify alternate destination IP addresses for upstrteam-assigned?=C2=A0= How

In my understanding, the only real use case of upstream-assigned labels is<= br> multicast service up till now. If multicast traffic is transported over P2M= P MPLS-in-
UDP tunnels, the MPLS label MUST be upstream-assigned. Otherwise, the MPLS<= br> label should be downstream-assigned as said above.

much discussion and agreement has this limitation had??

Maybe my points as mentioned above are incorrect. Therefore, I'm lookin= g
forward to seeing further comments and suggestions on this point, especiall= y
from those people who are knowledgeable about the usage of upstream-
assigned labels.

Best regards,
Xiaohu






--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--001a113a5baad3127e050d2a4c50-- From nobody Wed Jan 21 06:38:25 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55BD1A001C; Wed, 21 Jan 2015 06:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlLhrd1skM1P; Wed, 21 Jan 2015 06:38:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B063B1A1ABE; Wed, 21 Jan 2015 06:38:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121143819.18888.5284.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 06:38:19 -0800 Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: [mpls] Alia Atlas' Yes on draft-ietf-mpls-in-udp-10: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:38:22 -0000 Alia Atlas has entered the following ballot position for draft-ietf-mpls-in-udp-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for clarifying my concerns that we aren't missing a case of upstream-assigned labels in a unicast tunnel. We only really need upstream-assigned labels if the tunnel itself is multi-access. From nobody Wed Jan 21 07:19:16 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1991E1A1ACA; Wed, 21 Jan 2015 07:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtnPZgnMs0PZ; Wed, 21 Jan 2015 07:19:06 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1A11A1ADB; Wed, 21 Jan 2015 07:19:05 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LFIurL015953; Wed, 21 Jan 2015 15:18:56 GMT Received: from 950129200 (089144210022.atnat0019.highway.a1.net [89.144.210.22]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LFIpRp015715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 15:18:52 GMT From: "Adrian Farrel" To: "'Alia Atlas'" , "'Loa Andersson'" References: <20150120204041.13054.51744.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FBAD1@NKGEML512-MBS.china.huawei.com> <00e601d0356a$ba3315e0$2e9941a0$@olddog.co.uk> <54BF9F28.3090908@pi.nu> In-Reply-To: Date: Wed, 21 Jan 2015 15:18:38 -0000 Message-ID: <018e01d0358d$90abe670$b203b350$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018F_01D0358D.90B0A160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGtiNBqmnn4hUJoEt4+WxKFPzoeewJcJVZzAduyxukCc/XsLgImalQanMl2shA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21272.000 X-TM-AS-Result: No--20.450-10.0-31-10 X-imss-scan-details: No--20.450-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGDAd1DtN1q7XQIOMndeKgEvb7cLF+X1+g52X8YwVUEW3lg QxadX0I3fKkLs5wh2J67hw59i5efeB6Hacd6Ohq7Op/QO0+WfifKKVIuVXV5reQydRUvl3QTxjf J+i+nbHRl/p5QlddQ8Z2DdYyTLheOw9dU5xwENT1DU5wIS9P5tw/deY3h1H9DSSUXkvSVAdz7XJ 5E3BcU3Bv/G3meNDKmyjBMmcR2CtJStHBroCfBrnuzDvI75j0sjI6qXkf2FQ194c+e7fWIcIaRi UQlb8ekKQRxirZZgE/ugL34uOT5ea4jY8PS6Fo7jWe5HOFKvuNkBDPLxNH5Bqnu3/KtWfGQIZnp VU5Vh5bE2aprnmOeSW48M+WPVclAGexLvU6j8fCIWiitCNuhaVHewY36PuY02oLGTNKlb9c9CUo n0NTGeRi5kmMEDF/i1JtxRRxxMARJdpt3T6o+M7tsiy3ZR8MEDYBVKmbeeQMt88jwUkXq9SMOuG tF4L1ENOVZUUCTfWD7psjgv3jTHGGN6M1vhJ4HlY5qr7f6fHI+pLi/6EK1X6+WgCcaviqGluXXt EqKBeGW00p9LWWxDyyLtGIg8bA2hHRwYf/w/Q999e0rIz5z6zTbofuc5kuvv+26ZYWzwkKQ9EfN hyhiPf9IEEousIWA82HXDiODsmPz50g+jp9gns+ayFtEW0uYL34I8IpvQcKVEMx1gSjhQOdIBvX zI0jReNmdysT7k9r7iGV8G0sWBUj+bWNtFbsnfh/0N74LJAKE6lq+K7jth5y1Yc8tPkV9mtHuQh KV0oPHo8rIduRFYUtaOk5smBUr7nVkzMb2RnKeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyKyK0hOq 6voMyIQ5mZ5SqHP8VmJqbh1mcl81+ZQkOeSk290FdLWcnhqjxZII6piCZIizgft1asCeA== Archived-At: Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, 'The IESG' , mpls@ietf.org Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 15:19:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018F_01D0358D.90B0A160 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable No, it is not "if the link technology is multi-access". It is if the virtual link is multi-access. I.e. if the UDP tunnel is p2mp Such as, for example, connecting a set of distributed DC sites for the = purpose of distributing multicast data. =20 A =20 From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: 21 January 2015 14:24 To: Loa Andersson Cc: Adrian Farrel; Xuxiaohu; The IESG; = draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; = mpls@ietf.org Subject: Re: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with = DISCUSS) =20 Loa & Adrian, =20 My concern was that requiring the underlay to support multicast routing = might be too restrictive in a data center. However, if you are comfortable that = upstream labels only make sense if the link technology is multi-access (so a multicast UDP = tunnel is the equivalent), then I am ok with the text as is. =20 I was concerned that we were not missing a case that would be hard to = fix later and wanted to have that double-checked. =20 Thanks, Alia =20 On Wed, Jan 21, 2015 at 7:44 AM, Loa Andersson wrote: Adrian, If I understand you correctly you say that the current text makes a general statement that UDP multicast tunnels are needed and if they are we need the upstream assigned labels; yuo on the other hand say that this is a corner case that we can (for the time being) live with the multi-access link and UDP point to point links are enough. If this is correct, I support scoping the document as you proposed. /Loa On 2015-01-21 19:09, Adrian Farrel wrote: [co-author hat - not being an AD] In a separate private reply to Alia I just suggested that the text about = upstream assigned labels is overly optimistic. I'm not sure when it crept in. The assumption is that a multi-access link is being replaced with a UDP = multicast tunnel. I suspect this is unlikely and I have no idea why it = would be necessary unless: - the IP/UDP network supports multicast - the traffic being distributed is multicast - there are more than two sites being connected - the volume of traffic is more than moderate Otherwise, p2p UDP tunnels would be enough. My suggestion to Alia is to make upstream assigned labels for future = study. That way this I-D can move forward (at last!) and if anyone is = interested in the multicast work they can write a short additional = document. The fix would be to remove the offending text from section 4 and to add = a note to the Abstract and Introduction that this document is limited to = downstream assigned labels. Adrian -----Original Message----- From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: 21 January 2015 03:12 To: Alia Atlas; The IESG Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; mpls@ietf.org; Loa Andersson Subject: RE: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with = DISCUSS) Hi Alia, Thanks a lot for your AD review of this new revision. Please see my = explanation inline. -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, January 21, 2015 4:41 AM To: The IESG Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; = Loa Andersson; mpls@ietf.org Subject: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with = DISCUSS) Alia Atlas has entered the following ballot position for draft-ietf-mpls-in-udp-10: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am still waiting for this review comment to be resolved. In Sec 4, it says: "That is to say, if the destination IP address is a multicast address, = the top label SHOULD be upstream-assigned, otherwise if the destination IP address is a ..." This seems to require that the IP network is capable of supporting multicast where one can easily see using = MPLS-in-UDP tunnels to provide point-to-point tunnels. Is there a reason that the P2P MPLS-in-UDP tunnels could be used to carry multicast IP or Ethernet = traffic as well (e.g., in the ingress replication mode). In this case, the MPLS = labels should be downstream-assigned. Although it's possible to use upstream-assigned = labels in theory, it brings no value in practice since it's more complex compared = to the usage of downstream-assigned labels from the implementation perspective. = In other words, it doesn't require that the IP network is capable of = supporting multicast in order to transport multicast IP or Ethernet traffic over = MPLS-in-UDP tunnels. negotiation mechanism to set up the MPLS-in-UDP tunnel wouldn't also be = able to specify alternate destination IP addresses for upstrteam-assigned? = How In my understanding, the only real use case of upstream-assigned labels = is multicast service up till now. If multicast traffic is transported over = P2MP MPLS-in- UDP tunnels, the MPLS label MUST be upstream-assigned. Otherwise, the = MPLS label should be downstream-assigned as said above. much discussion and agreement has this limitation had?? Maybe my points as mentioned above are incorrect. Therefore, I'm looking forward to seeing further comments and suggestions on this point, = especially from those people who are knowledgeable about the usage of upstream- assigned labels. Best regards, Xiaohu =20 =20 --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 = =20 =20 ------=_NextPart_000_018F_01D0358D.90B0A160 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

No, it is not "if the = link technology is multi-access".

It is if the virtual link is = multi-access.

I.e. if the UDP tunnel is = p2mp

Such as, for example, = connecting a set of distributed DC sites for the purpose of distributing = multicast data.

 

A

 

From: Alia Atlas = [mailto:akatlas@gmail.com]
Sent: 21 January 2015 = 14:24
To: Loa Andersson
Cc: Adrian Farrel; Xuxiaohu; = The IESG; draft-ietf-mpls-in-udp@tools.ietf.org; = mpls-chairs@tools.ietf.org; mpls@ietf.org
Subject: Re: Alia = Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with = DISCUSS)

 

Loa = & Adrian,

 

My concern was that requiring the underlay to support = multicast routing might be too

restrictive in a data center.  However, if you = are comfortable that upstream labels only

make sense if the link technology is multi-access (so = a multicast UDP tunnel is the

equivalent), then I am ok with the text as = is.

 

I = was concerned that we were not missing a case that would be hard to fix = later and

wanted to have = that double-checked.

 

Thanks,

Alia

 

On Wed, = Jan 21, 2015 at 7:44 AM, Loa Andersson <loa@pi.nu> wrote:

Adrian,

If I understand you correctly you say = that the current text makes a
general statement that UDP multicast = tunnels are needed and if they
are we need the upstream assigned = labels; yuo on the other hand say
that this is a corner case that we = can (for the time being) live with
the  multi-access link and = UDP point to point links are enough.

If this is correct, I = support scoping the document as you = proposed.

/Loa





On 2015-01-21 19:09, Adrian Farrel = wrote:

[co-author hat - not being an = AD]

In a separate private reply to Alia I just suggested that the = text about upstream assigned labels is overly optimistic.

I'm not = sure when it crept in.

The assumption is that a multi-access link = is being replaced with a UDP multicast tunnel. I suspect this is = unlikely and I have no idea why it would be necessary unless:
- the = IP/UDP network supports multicast
- the traffic being distributed is = multicast
- there are more than two sites being connected
- the = volume of traffic is more than moderate
Otherwise, p2p UDP tunnels = would be enough.

My suggestion to Alia is to make upstream = assigned labels for future study. That way this I-D can move forward (at = last!) and if anyone is interested in the multicast work they can write = a short additional document.

The fix would be to remove the = offending text from section 4 and to add a note to the Abstract and = Introduction that this document is limited to downstream assigned = labels.

Adrian

-----Original Message-----
From: iesg = [mailto:iesg-bounces@ietf.org] On Behalf Of = Xuxiaohu
Sent: 21 January 2015 03:12
To: Alia Atlas; The = IESG
Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org;
mpls@ietf.org; Loa = Andersson
Subject: RE: Alia Atlas' Discuss on = draft-ietf-mpls-in-udp-10: (with DISCUSS)

Hi Alia,

Thanks = a lot for your AD review of this new revision. Please see my = explanation
inline.

-----Original = Message-----
From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Wednesday, January 21, = 2015 4:41 AM
To: The IESG
Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; = Loa
Andersson; mpls@ietf.org
Subject: Alia Atlas' Discuss on = draft-ietf-mpls-in-udp-10: (with DISCUSS)

Alia Atlas has entered = the following ballot position for
draft-ietf-mpls-in-udp-10: = Discuss

When responding, please keep the subject line intact and = reply to all email
addresses included in the To and CC lines. (Feel = free to cut this introductory
paragraph, however.)


Please = refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l
for more information about IESG DISCUSS and COMMENT = positions.


The document, along with other ballot positions, = can be found here:
http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/=



-----------------------------------------------------= -----------------
DISCUSS:
----------------------------------------= ------------------------------

I am still waiting for this review = comment to be resolved.

In Sec 4, it says:
"That is to = say, if the destination IP address is a multicast address, the top = label
SHOULD be upstream-assigned, otherwise if the destination
IP = address is a ..."   This seems to require that the IP = network is
capable of supporting multicast where one can easily see = using MPLS-in-UDP
tunnels to provide point-to-point tunnels.  Is = there a reason that the


P2P MPLS-in-UDP tunnels could be used = to carry multicast IP or Ethernet traffic as
well (e.g., in the = ingress replication mode). In this case, the MPLS labels should = be
downstream-assigned. Although it's possible to use = upstream-assigned labels in
theory, it brings no value in practice = since it's more complex compared to the
usage of downstream-assigned = labels from the implementation perspective. In
other words, it = doesn't require that the IP network is capable of = supporting
multicast in order to transport multicast IP or Ethernet = traffic over MPLS-in-UDP
tunnels.

negotiation mechanism to set up the MPLS-in-UDP tunnel = wouldn't also be able
to specify alternate destination IP addresses = for upstrteam-assigned?  How


In my understanding, the only real = use case of upstream-assigned labels is
multicast service up till = now. If multicast traffic is transported over P2MP MPLS-in-
UDP = tunnels, the MPLS label MUST be upstream-assigned. Otherwise, the = MPLS
label should be downstream-assigned as said = above.

much discussion and agreement = has this limitation had??


Maybe = my points as mentioned above are incorrect. Therefore, I'm = looking
forward to seeing further comments and suggestions on this = point, especially
from those people who are knowledgeable about the = usage of upstream-
assigned labels.

Best = regards,
Xiaohu



 

 

-- =


Loa Andersson            =             email: loa@mail01.huawei.com
Senior MPLS Expert          =                 loa@pi.nu
Huawei = Technologies (consultant)     phone: +46 739 81 21 = 64

 

------=_NextPart_000_018F_01D0358D.90B0A160-- From nobody Wed Jan 21 07:21:36 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B141A1AE5; Wed, 21 Jan 2015 07:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6KMLay47OMD; Wed, 21 Jan 2015 07:21:32 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8831A1ADD; Wed, 21 Jan 2015 07:21:31 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id v1so1694245yhn.8; Wed, 21 Jan 2015 07:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PPW7aW6HmhvA0Nl5KXQft0GE4gcsfI6Ererwwf1hA54=; b=N/WZwFJQagXT/LDy4XRiIPvj/CqfSNIrA4dHR/qx/bvGkeRndEFe01r2W/fr09RGAY iY5Gng+SgCjkv6PidqUQBw289bFEabq3/KIh+P18feZgEikXV1CEiI7jlFPPPW2+hkWj 0kjd4alVKTSJtt4m7sws5XDbBqC5zDnG3hdMb9UN7LuipV7QHFlA/8V2liEPfE2dtqBr eXsxFQN6Vkl/HUvOc+x4zl1z4i5Mw8DxX2xkbzShfhK17rmyDM9g4PvF9h014ih08km/ EXjteyycAUFAYMbKiBP/jA8Xw9vmSQ3E/SU1aIi96T5ByRbnpNzhHUcrVr7c21HqMRVw 8JlA== MIME-Version: 1.0 X-Received: by 10.170.207.131 with SMTP id y125mr14262350yke.55.1421853690986; Wed, 21 Jan 2015 07:21:30 -0800 (PST) Received: by 10.170.133.18 with HTTP; Wed, 21 Jan 2015 07:21:30 -0800 (PST) In-Reply-To: <018e01d0358d$90abe670$b203b350$@olddog.co.uk> References: <20150120204041.13054.51744.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FBAD1@NKGEML512-MBS.china.huawei.com> <00e601d0356a$ba3315e0$2e9941a0$@olddog.co.uk> <54BF9F28.3090908@pi.nu> <018e01d0358d$90abe670$b203b350$@olddog.co.uk> Date: Wed, 21 Jan 2015 10:21:30 -0500 Message-ID: From: Alia Atlas To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a1139c4c62c865b050d2b1c59 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-in-udp@tools.ietf.org" , The IESG , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 15:21:35 -0000 --001a1139c4c62c865b050d2b1c59 Content-Type: text/plain; charset=UTF-8 Adrian, On Wed, Jan 21, 2015 at 10:18 AM, Adrian Farrel wrote: > No, it is not "if the link technology is multi-access". > That is what the upstream label assignment was developed for. > It is if the virtual link is multi-access. > > I.e. if the UDP tunnel is p2mp > Right - and that is the parallel for the MPLS-in-UDP case - that the UDP tunnel is p2mp. > Such as, for example, connecting a set of distributed DC sites for the > purpose of distributing multicast data. > Exactly. I may have phrased it badly, but I think we are on the same page. Alia > A > > > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > *Sent:* 21 January 2015 14:24 > *To:* Loa Andersson > *Cc:* Adrian Farrel; Xuxiaohu; The IESG; > draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; > mpls@ietf.org > *Subject:* Re: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with > DISCUSS) > > > > Loa & Adrian, > > > > My concern was that requiring the underlay to support multicast routing > might be too > > restrictive in a data center. However, if you are comfortable that > upstream labels only > > make sense if the link technology is multi-access (so a multicast UDP > tunnel is the > > equivalent), then I am ok with the text as is. > > > > I was concerned that we were not missing a case that would be hard to fix > later and > > wanted to have that double-checked. > > > > Thanks, > > Alia > > > > On Wed, Jan 21, 2015 at 7:44 AM, Loa Andersson wrote: > > Adrian, > > If I understand you correctly you say that the current text makes a > general statement that UDP multicast tunnels are needed and if they > are we need the upstream assigned labels; yuo on the other hand say > that this is a corner case that we can (for the time being) live with > the multi-access link and UDP point to point links are enough. > > If this is correct, I support scoping the document as you proposed. > > /Loa > > > > > > On 2015-01-21 19:09, Adrian Farrel wrote: > > [co-author hat - not being an AD] > > In a separate private reply to Alia I just suggested that the text about > upstream assigned labels is overly optimistic. > > I'm not sure when it crept in. > > The assumption is that a multi-access link is being replaced with a UDP > multicast tunnel. I suspect this is unlikely and I have no idea why it > would be necessary unless: > - the IP/UDP network supports multicast > - the traffic being distributed is multicast > - there are more than two sites being connected > - the volume of traffic is more than moderate > Otherwise, p2p UDP tunnels would be enough. > > My suggestion to Alia is to make upstream assigned labels for future > study. That way this I-D can move forward (at last!) and if anyone is > interested in the multicast work they can write a short additional document. > > The fix would be to remove the offending text from section 4 and to add a > note to the Abstract and Introduction that this document is limited to > downstream assigned labels. > > Adrian > > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: 21 January 2015 03:12 > To: Alia Atlas; The IESG > Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; > mpls@ietf.org; Loa Andersson > Subject: RE: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with > DISCUSS) > > Hi Alia, > > Thanks a lot for your AD review of this new revision. Please see my > explanation > inline. > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, January 21, 2015 4:41 AM > To: The IESG > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; Loa > Andersson; mpls@ietf.org > Subject: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) > > Alia Atlas has entered the following ballot position for > draft-ietf-mpls-in-udp-10: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory > paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I am still waiting for this review comment to be resolved. > > In Sec 4, it says: > "That is to say, if the destination IP address is a multicast address, the > top label > SHOULD be upstream-assigned, otherwise if the destination > IP address is a ..." This seems to require that the IP network is > capable of supporting multicast where one can easily see using MPLS-in-UDP > tunnels to provide point-to-point tunnels. Is there a reason that the > > > P2P MPLS-in-UDP tunnels could be used to carry multicast IP or Ethernet > traffic as > well (e.g., in the ingress replication mode). In this case, the MPLS > labels should be > downstream-assigned. Although it's possible to use upstream-assigned > labels in > theory, it brings no value in practice since it's more complex compared to > the > usage of downstream-assigned labels from the implementation perspective. In > other words, it doesn't require that the IP network is capable of > supporting > multicast in order to transport multicast IP or Ethernet traffic over > MPLS-in-UDP > tunnels. > > negotiation mechanism to set up the MPLS-in-UDP tunnel wouldn't also be > able > to specify alternate destination IP addresses for upstrteam-assigned? How > > > In my understanding, the only real use case of upstream-assigned labels is > multicast service up till now. If multicast traffic is transported over > P2MP MPLS-in- > UDP tunnels, the MPLS label MUST be upstream-assigned. Otherwise, the MPLS > label should be downstream-assigned as said above. > > much discussion and agreement has this limitation had?? > > > Maybe my points as mentioned above are incorrect. Therefore, I'm looking > forward to seeing further comments and suggestions on this point, > especially > from those people who are knowledgeable about the usage of upstream- > assigned labels. > > Best regards, > Xiaohu > > > > > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > --001a1139c4c62c865b050d2b1c59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adrian,

On Wed, Jan 21, 2015 at 10:18 AM, Adrian Farrel &l= t;adrian@olddog.co= .uk> wrote:

No, it is not "if the link technology is multi-access&= quot;.


That is what = the upstream label assignment was developed for.
=C2=A0

It is if the virt= ual link is multi-access.

I.e. if the UDP tunnel is p2mp


Right - and that is the parallel for th= e MPLS-in-UDP case - that the UDP tunnel is p2mp.
=C2=A0

=

Such as, for example,= connecting a set of distributed DC sites for the purpose of distributing m= ulticast data.


Exactly.=C2= =A0 I may have phrased it badly, but I think we are on the same page.
=

Alia=C2=A0
=C2= =A0

<= /u>

A=

=C2= =A0

From: Alia Atlas = [mailto:akatlas@gmai= l.com]
Sent: 21 January 2015 14:24
To: Loa Anderss= on
Cc: Adrian Farrel; Xuxiaohu; The IESG; draft-ietf-mpls-in-udp@= tools.ietf.org; mpls-chairs@tools.ietf.org; mpls@ietf.org
Subject: Re: Alia Atlas' D= iscuss on draft-ietf-mpls-in-udp-10: (with DISCUSS)

=C2=A0=

Loa & Adrian,

=C2=A0

My concern was that requiring the underlay to support multicast rout= ing might be too

restric= tive in a data center.=C2=A0 However, if you are comfortable that upstream = labels only

make sense i= f the link technology is multi-access (so a multicast UDP tunnel is the<= /u>

equivalent), then I am ok w= ith the text as is.

<= /u>=C2=A0

I was concerned that = we were not missing a case that would be hard to fix later and

wanted to have that double-checked.<= u>

=C2=A0

=

Thanks,

Alia

=C2=A0

On Wed, Jan 21, 20= 15 at 7:44 AM, Loa Andersson <loa@pi.nu> wrote:

Adria= n,

If I understand you correctly you say that the current text makes= a
general statement that UDP multicast tunnels are needed and if theyare we need the upstream assigned labels; yuo on the other hand say
th= at this is a corner case that we can (for the time being) live with
the= =C2=A0 multi-access link and UDP point to point links are enough.

If= this is correct, I support scoping the document as you proposed.

/L= oa





On 201= 5-01-21 19:09, Adrian Farrel wrote:

[co-author hat - not being an AD]

In= a separate private reply to Alia I just suggested that the text about upst= ream assigned labels is overly optimistic.

I'm not sure when it = crept in.

The assumption is that a multi-access link is being replac= ed with a UDP multicast tunnel. I suspect this is unlikely and I have no id= ea why it would be necessary unless:
- the IP/UDP network supports multi= cast
- the traffic being distributed is multicast
- there are more th= an two sites being connected
- the volume of traffic is more than modera= te
Otherwise, p2p UDP tunnels would be enough.

My suggestion to A= lia is to make upstream assigned labels for future study. That way this I-D= can move forward (at last!) and if anyone is interested in the multicast w= ork they can write a short additional document.

The fix would be to = remove the offending text from section 4 and to add a note to the Abstract = and Introduction that this document is limited to downstream assigned label= s.

Adrian

-----Original Message-----
From: iesg [mailto:iesg-bounces@ietf.org] On= Behalf Of Xuxiaohu
Sent: 21 January 2015 03:12
To: Alia Atlas; The I= ESG
Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org;=
mpls@ietf.org; L= oa Andersson
Subject: RE: Alia Atlas' Discuss on draft-ietf-mpls-in-= udp-10: (with DISCUSS)

Hi Alia,

Thanks a lot for your AD revi= ew of this new revision. Please see my explanation
inline.=

-----Original Message-----
From: Alia Atlas [= mailto:akatlas@gmail= .com]
Sent: Wednesday, January 21, 2015 4:41 AM
To: The IESG
C= c: mpls-cha= irs@tools.ietf.org; draft-ietf-mpls-in-udp@tools.ietf.org; Loa
A= ndersson; mpls@ietf.org<= /a>
Subject: Alia Atlas' Discuss on draft-ietf-mpls-in-udp-10: (with= DISCUSS)

Alia Atlas has entered the following ballot position fordraft-ietf-mpls-in-udp-10: Discuss

When responding, please keep th= e subject line intact and reply to all email
addresses included in the T= o and CC lines. (Feel free to cut this introductory
paragraph, however.)=


Please refer to http://www.ietf.org/iesg/statement/= discuss-criteria.html
for more information about IESG DISCUSS and CO= MMENT positions.


The document, along with other ballot positions= , can be found here:
http://datatracker.ietf.org/doc/draft-ie= tf-mpls-in-udp/



----------------------------------------= ------------------------------
DISCUSS:
-----------------------------= -----------------------------------------

I am still waiting for thi= s review comment to be resolved.

In Sec 4, it says:
"That is= to say, if the destination IP address is a multicast address, the top labe= l
SHOULD be upstream-assigned, otherwise if the destination
IP addres= s is a ..."=C2=A0 =C2=A0This seems to require that the IP network iscapable of supporting multicast where one can easily see using MPLS-in-UD= P
tunnels to provide point-to-point tunnels.=C2=A0 Is there a reason tha= t the


P2P MPLS-in-UDP tunnels could be used to carry multicast IP or Ethern= et traffic as
well (e.g., in the ingress replication mode). In this case= , the MPLS labels should be
downstream-assigned. Although it's possi= ble to use upstream-assigned labels in
theory, it brings no value in pra= ctice since it's more complex compared to the
usage of downstream-as= signed labels from the implementation perspective. In
other words, it do= esn't require that the IP network is capable of supporting
multicast= in order to transport multicast IP or Ethernet traffic over MPLS-in-UDPtunnels.

negotiation mechanism to = set up the MPLS-in-UDP tunnel wouldn't also be able
to specify alter= nate destination IP addresses for upstrteam-assigned?=C2=A0 How


In my under= standing, the only real use case of upstream-assigned labels is
multicas= t service up till now. If multicast traffic is transported over P2MP MPLS-i= n-
UDP tunnels, the MPLS label MUST be upstream-assigned. Otherwise, the= MPLS
label should be downstream-assigned as said above.

much discussion and agreement has this limitation = had??


Maybe my points as mentio= ned above are incorrect. Therefore, I'm looking
forward to seeing fu= rther comments and suggestions on this point, especially
from those peop= le who are knowledgeable about the usage of upstream-
assigned labels.
Best regards,
Xiaohu



=C2=A0

=C2=A0

--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.comSenior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant= )=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

=C2=A0

<= /div>

--001a1139c4c62c865b050d2b1c59-- From nobody Wed Jan 21 09:32:55 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBC91A1B2E; Wed, 21 Jan 2015 09:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBwB9LxjuEbj; Wed, 21 Jan 2015 09:32:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 625F91A1B46; Wed, 21 Jan 2015 09:32:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121173247.23372.18349.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 09:32:47 -0800 Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 17:32:52 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-mpls-in-udp-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The draft improved a lot and I am on no-objection after discussing the point below: The UDP source port is randomly chosen and I guess not further retained (*) for receiving incoming MPLS-over-UDP packets. In turn this means that "returning" packets are sent to the MPLS/UDP port number. (*) nobody is listening on that UDP port. This will cause issues when NATs/firewalls are in-between, as the return traffic, i.e., the traffic incoming from the public part of the NAT, is not matching any NAT binding that was created before by an outgoing packet. Similar for firewalls as no state was created when the packet traversed the firewall. NATs are probably not a big issue in a carrier net, but firewalls will for sure. I guess this should be mentioned as an operational note. From nobody Wed Jan 21 09:49:59 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273F11A1B4B; Wed, 21 Jan 2015 09:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCFYzHTGNXpR; Wed, 21 Jan 2015 09:49:51 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A811A1B49; Wed, 21 Jan 2015 09:49:51 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LHnmU3017997; Wed, 21 Jan 2015 17:49:48 GMT Received: from 950129200 (089144210022.atnat0019.highway.a1.net [89.144.210.22]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LHnkML017968 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 17:49:47 GMT From: "Adrian Farrel" To: "'Martin Stiemerling'" , "'The IESG'" Date: Wed, 21 Jan 2015 17:49:45 -0000 Message-ID: <022f01d035a2$a5f07e00$f1d17a00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA1oqOFqXa6TZniRmKdoDHGpf5pnw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21272.001 X-TM-AS-Result: No--6.502-10.0-31-10 X-imss-scan-details: No--6.502-10.0-31-10 X-TMASE-MatchedRID: L8tZF6zWW2rRhEyb9f1sjtxajlW+zwxCvjmFPx5veRnTEy+FT1zrlxX0 C/Gbw7Ij1o37o3IrD/Izw8o06RnAsmDSz0Ilzxe87dmK7UHrB4QrHkgIan9a0c2mvbig5LjGHAC UcDvcWyAFpt9nAr6Q+TwE5uh/KeY4MZpnc+6w+DSiy+EhgYW4s9DEd24oCD8nMMn1rcqKQaiNgC T7rrYqSzqBXzgUb1NWNB7jBV5VDYMTuziBf/xOQ4xVBvj1jbcj4wQlYP0sRm9cKZwALwMGs0z/R vHjxP13585VzGMOFzA9wJeM2pSaRXnN0DN7HnFmiWuTJQsDwrkMj50G/zgmfnpSoLWss/i+z8v/ ZDPN8AJ59TByPJZhl5RMZUCEHkRt Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 17:49:56 -0000 Hi Martin, Speaking as a contributor to this I-D and recused... I think you have a valid point, but the details are a bit wrong. > The UDP source port is randomly chosen and I guess not further = retained > (*) for receiving incoming MPLS-over-UDP packets. In turn this means = that > "returning" packets are sent to the MPLS/UDP port number. >=20 > (*) nobody is listening on that UDP port. I think this is no different from when the port is assigned through = entropy. That is, a source port is assigned for use on the outward flow = with no assumption that returning packets will use the same port number = as the destination port. Indeed, the destination port is always "MPLS" = on traffic flowing in both directions. This might require "knowledge" to be configured into a firewall if it = finds itself in the path. > This will cause issues when NATs/firewalls are in-between, as the = return > traffic, i.e., the traffic incoming from the public part of the NAT, = is > not matching any NAT binding that was created before by an outgoing > packet. Similar for firewalls as no state was created when the packet > traversed the firewall. >=20 > NATs are probably not a big issue in a carrier net, but firewalls will > for sure. I guess this should be mentioned as an operational note. If you think a warning should be added, that is pretty simple to do (and = possibly gels with the warning about zero checksum). (Is the addition of such a warning a Discuss? Who cares! We can add the = note whatever :-) Adrian From nobody Wed Jan 21 11:21:55 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AFA1A8715; Wed, 21 Jan 2015 11:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf0uSugP0KxM; Wed, 21 Jan 2015 11:21:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 558841A8709; Wed, 21 Jan 2015 11:21:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121192135.31451.97017.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 11:21:35 -0800 Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: [mpls] Brian Haberman's No Objection on draft-ietf-mpls-in-udp-10: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 19:21:50 -0000 Brian Haberman has entered the following ballot position for draft-ietf-mpls-in-udp-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the extensive discussion of the UDP zero checksum over IPv6 issue. From nobody Wed Jan 21 14:15:21 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC4F1A00BB; Wed, 21 Jan 2015 14:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJAU2MwRdv7O; Wed, 21 Jan 2015 14:15:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9A81A006C; Wed, 21 Jan 2015 14:15:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-oam-ipv6-rao.all@tools.ietf.org, loa@pi.nu X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121221518.16630.21640.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 14:15:18 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Telechat update notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 22:15:20 -0000 Placed on agenda for telechat - 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ From nobody Wed Jan 21 14:15:47 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541041A8957 for ; Wed, 21 Jan 2015 14:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R7SbI-TUI0S; Wed, 21 Jan 2015 14:15:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 366A61A1A29; Wed, 21 Jan 2015 14:15:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-oam-ipv6-rao.all@tools.ietf.org, loa@pi.nu X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121221544.16626.6525.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 14:15:44 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 22:15:45 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ From nobody Wed Jan 21 15:22:49 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25901A8A78; Wed, 21 Jan 2015 15:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TerNGLkoOf4S; Wed, 21 Jan 2015 15:22:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8811A19F8; Wed, 21 Jan 2015 15:22:41 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150121232241.12288.98926.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 15:22:41 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] Last Call: (IPv6 Router Alert Option for MPLS OAM) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 23:22:46 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'IPv6 Router Alert Option for MPLS OAM' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the Router Alert Option MUST be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on the Reply Mode used. While a generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO), there is no generic Router Alert Option Value defined for IPv6 that can be used. This document allocates a new generic IPv6 Router Alert Option Value that can be used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS in IPv6 environments. Consequently, it updates RFC 4379. The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this code point is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jan 21 15:22:52 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF091A8A78 for ; Wed, 21 Jan 2015 15:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEAy4-5eJG6V; Wed, 21 Jan 2015 15:22:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D39071A8A7F; Wed, 21 Jan 2015 15:22:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-oam-ipv6-rao.all@tools.ietf.org, loa@pi.nu X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121232242.12288.78703.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 15:22:42 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 23:22:48 -0000 Last call has been made for draft-ietf-mpls-oam-ipv6-rao and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ From nobody Wed Jan 21 18:05:27 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826821A00EF for ; Wed, 21 Jan 2015 18:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5BWXDgRnXff; Wed, 21 Jan 2015 18:05:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3B71A00DC; Wed, 21 Jan 2015 18:05:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, "Loa Andersson" , mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122020522.2662.46594.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 18:05:22 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 02:05:25 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ From nobody Wed Jan 21 20:58:31 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF2B1A916F; Wed, 21 Jan 2015 20:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPUJxwoCxOgS; Wed, 21 Jan 2015 20:58:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E047D1A916E; Wed, 21 Jan 2015 20:58:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOH43142; Thu, 22 Jan 2015 04:58:24 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 22 Jan 2015 04:54:16 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 22 Jan 2015 12:54:09 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(3): Challenge of DoD and Inter-area extensions for SR-BE Path Thread-Index: AdA1/3T2w0zgoP/sS4aArDSYrF7eAQ== Date: Thu, 22 Jan 2015 04:54:08 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772806A@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772806Ankgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" Subject: [mpls] New Comments on Segment Routing(3): Challenge of DoD and Inter-area extensions for SR-BE Path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 04:58:28 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772806Ankgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgdGhp cmQgY29tbWVudHMuDQoNCg0KDQogICAgICAgICAgICAgICstLS0tLS0tKyAgICstLS0tLS0tKyAg ICstLS0tLS0rICAgKy0tLS0tLSsNCiAgICAgICAgICAgICAgfCAgICAgICB8ICAgfCAgICAgICB8 ICAgfCAgICAgIHwgICB8ICAgICAgfA0KICAgICAgICAgICArLS0rIEFHTjExICstLS0rIEFHTjIx ICstLS0rIEFCUjEgKy0tLSsgTFNSMSArLS0+IHRvIEFHTg0KICAgICAgICAgIC8gICB8ICAgICAg IHwgIC98ICAgICAgIHwgICB8ICAgICAgfCAgIHwgICAgICB8DQogICArLS0tLSsvICAgICstLS0t LS0tK1wvICstLS0tLS0tKyAgICstLS0tLS0rICAvKy0tLS0tLSsNCiAgIHwgQU4gfCAgICAgICAg ICAgICAgL1wgICAgICAgICAgICAgICAgICAgICBcLyAgICAgfA0KICAgKy0tLS0rXCAgICArLS0t LS0tLSsgIFwrLS0tLS0tLSsgICArLS0tLS0tKy9cICstLS0tLS0rDQogICAgICAgICAgXCAgIHwg ICAgICAgfCAgIHwgICAgICAgfCAgIHwgICAgICB8ICBcfCAgICAgIHwNCiAgICAgICAgICAgKy0t KyBBR04xMiArLS0tKyBBR04yMiArLS0tKyBBQlIyICstLS0rIExTUjIgKy0tPiB0byBBR04NCiAg ICAgICAgICAgICAgfCAgICAgICB8ICAgfCAgICAgICB8ICAgfCAgICAgIHwgICB8ICAgICAgfA0K ICAgICAgICAgICAgICArLS0tLS0tLSsgICArLS0tLS0tLSsgICArLS0tLS0tKyAgICstLS0tLS0r DQoNCiAgIHN0YXRpYyByb3V0ZSAgICAgSVNJUyBMMSAgICAgICAgICAgICAgICBJU0lTIEwyDQog ICAgTERQIERvRCAgICAgICAgIExEUCBEVSAgICAgICAgICAgICAgICAgTERQIERVDQogICA8LUFj Y2Vzcy0+PC0tQWdncmVnYXRpb24gRG9tYWluLS0+PC0tLS0tLS0tLUNvcmUtLS0tLS0tLS0+DQoN Cg0KU2VhbWxlc3MgTVBMUyBoYXMgYmVlbiBwcm9wb3NlZCBhcyBvbmUgaW1wb3J0YW50IGFyY2hp dGVjdHVyZSBmb3IgbmV0d29yayBpbnRlZ3JhdGlvbi4gQXMgc2hvdyBpbiB0aGUNCmFib3ZlIHRo ZSBmaWd1cmUuIEluIHRoZSBhY2Nlc3MgbmV0d29yayBiZXR3ZWVuIEFOIGFuZCBBR05zLCBzdGF0 aWMgcm91dGUgYW5kIExEUCBEb0QgYXJlIGFkb3B0ZWQuDQpUaGVyZSBldmVuIG1vcmUgZmV0dXJl cyByZWxhdGVkIExEUCBpbiB0aGUgc2NlbmFyaW9zOiBMRFAgcHJveHkgZWdyZXNzIG9uIEFHTiBh bmQgSW50ZXItYXJlYSBleHRlbnNpb25zDQogb2YgTERQLiBUaGUgY2hhbGxlbmdlIG9mIHByb3h5 IGVncmVzcyBmb3IgU1IgaGFzIGJlZW4gcHJvcG9zZWQgaW4gdGhlIHByZXZpb3VzIGNvbW1lbnRz LiBJIHdvdWxkIGxpa2UNCnRvIGRpc2N1c3MgdGhlIG90aGVyIHR3byBpc3N1ZXM6DQoxLiBMRFAg RG9EOiBJbiB0aGlzIHNjZW5hcmlvcywgTERQIERvRCBpcyBhZG9wdGVkIHRvIHNldCB1cCBMU1Ag b24gZGVtYW5kIHdoaWNoIGNhbiBjb250cm9sbGVkIHRoZSBudW1iZXINCm9mIExTUC4gVGhlIGNv bnRyb2wgY2FuIGJlIGFwcGxpZWQgaW4gdGhlIGluZ3Jlc3Mgbm9kZSBjb21iaW5nIHdpdGggdGhl IHNlcnZpY2Ugc3VwcG9ydGVkKGUuZy4gaW4gdGhlIGNhc2UsDQppZiB0aGUgY29uZmlndXJlZCBM RFAgcmVtb3RlIHBlZXIgZm9yIFBXIHNlcnZpY2UgY2FuIHRyaWdnZXIgTERQIERvRCB0byBzZW5k IGxhYmVsIHJlcXVlc3QgaW4gQU4pLiBCdXQgZm9yDQpTUiwgaXRzIGZsb29kcyB0aGUgbGFiZWwg bWFwcGluZyBpbiB0aGUgbmV0d29yay4gSWYgaG9wZSB0byBjb250cm9sIHRoZSBzZXR1cCBvZiBM U1AsIHRoZSBjb21wbGV4IHBvbGljeQ0KDQptdXN0IGJlIGFwcGxpZWQgb24gbXVsdGlwbGUgbm9k ZXMuDQoyLiBSRkM1MjgzIHByb3Bvc2VzIHRoZSBMRFAgaW50ZXItYXJlYSBleHRlbnNpb25zLiBU aGF0IGlzLCB3aGVuIHNlYXJjaCByb3V0ZXMgZm9yIHRoZSByZWNlaXZlZCBsYWJlbHAgbWFwcGlu ZywNCmxvbmdlc3QtbWF0Y2ggbWV0aG9kIGNhbiBhbHNvIGJlIGFkb3B0ZWQgYmVzaWRlcyB0aGUg ZXhhY3QgbWF0Y2guIENvdWxkIHlvdSBkZWZpbmUgY2xlYXJseSBmb3IgU1Igd2hhdCBtZXRob2QN Cg0KaXMgYWRvcHRlZCBmb3IgU1ItQkUgcGF0aD8gQ291bGQgeW91IGV4cGxhaW4gdGhlIGVmZmVj dHMgcHJvcG9zZWQgYnkgZGlmZmVyZW50IG1ldGhvZHMgaWYgeW91IGhhZCB0YWtlbiBpbnRvDQoN CmFjY291bnQgdGhlIGlzc3VlPw0KDQoNCg0KDQoNCg0KDQoNCg0KUmVnYXJkcywNClJvYmluDQoN Cg0K --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772806Ankgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the third comments.

 


            &nb= sp; +-------+   +-------+   +------= +   +------+
            &nb= sp; |       |   |   =     |   |      | &nb= sp; |      |
           +--+ A= GN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> = to AGN
          /   | = ;      |  /|     &nb= sp; |   |      |   | &nbs= p;    |
   +----+/    +-------+\/ +---= ----+   +------+  /+------+
   | AN |         &n= bsp;    /\        &n= bsp;            \/&n= bsp;    |
   +----+\    +-------+  \= 3;-------+   +------+/\ +------+
          \   | = ;      |   |    &nbs= p;  |   |      |  \| &nbs= p;    |
           +--+ A= GN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> = to AGN
            &nb= sp; |       |   |   =     |   |      | &nb= sp; |      |
            &nb= sp; +-------+   +-------+   +------= +   +------+

   static route     ISIS L1  &nb= sp;            = ISIS L2
    LDP DoD         = LDP DU           &nb= sp;     LDP DU
   <-Access-><--Aggregation Domain--><---------Cor= e--------->
  

Seamless MPLS has been proposed as one important architecture for networ= k integration. As show in the
above the figure. In the access network between AN and AGNs, static route a= nd LDP DoD are adopted.
There even more fetures related LDP in the scenarios: LDP proxy egress on A= GN and Inter-area extensions
 of LDP. The challenge of proxy egress for SR has been proposed in the= previous comments. I would like
to discuss the other two issues:
1. LDP DoD: In this scenarios, LDP DoD is adopted to set up LSP on demand w= hich can controlled the number
of LSP. The control can be applied in the ingress node combing with the ser= vice supported(e.g. in the case,
if the configured LDP remote peer for PW service can trigger LDP DoD to sen= d label request in AN). But for
SR, its floods the label mapping in the network. If hope to control the set= up of LSP, the complex policy

must be applied on multiple nodes.
2. RFC5283 proposes the LDP inter-area extensions. That is, when search rou= tes for the received labelp mapping,
longest-match method can also be adopted besides the exact match. Could you= define clearly for SR what method

is adopted for SR-BE path? Could you explain the effects proposed by dif= ferent methods if you had taken into

account the issue?

 

 

 

 

Regards,
Robin

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772806Ankgeml506mbxchi_-- From nobody Wed Jan 21 21:08:10 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152441A9177; Wed, 21 Jan 2015 21:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCJXJ1S2UzEd; Wed, 21 Jan 2015 21:07:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE0A1A9172; Wed, 21 Jan 2015 21:07:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOH43731; Thu, 22 Jan 2015 05:07:50 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 22 Jan 2015 05:07:49 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 22 Jan 2015 13:07:41 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path Thread-Index: AdA2AFmCnRYsHpISS4y8T7IvquyS6A== Date: Thu, 22 Jan 2015 05:07:41 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808A@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808Ankgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" Subject: [mpls] New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 05:07:55 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808Ankgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgZm91 cnRoIGNvbW1lbnRzLg0KDQoNCg0KRm9yIExEUCwgd2hlbiBzZWFyY2ggcm91dGUgZm9yIHRoZSBk ZXN0aW5hdGlvbiBhZGRyZXNzIHdoaWNoIGlzIHRoZSBGRUMgb2YgdGhlIGxhYmVsIG1hcHBpbmcs IGl0IHNob3VsZCBzZWFyY2gNCnRoZSBGSUIgaW4gd2hpY2ggdGhlIHJvdXRlcyBhcmUgc2VsZWN0 ZWQgZnJvbSB0aGUgc3RhdGljIHJvdXRlLCBPU1BGLCBJU0lTLCBCR1AsIGV0YyBiYXNlZCBvbiB0 aGUgcHJlZmVyZW5jZXMuDQpOb3cgdGhlcmUgaXMgb25lIHF1ZXN0aW9uIGZvciBTUi1CRSBwYXRo LCBmb3IgZXhhbXBsZSwgaWYgdGhlIFNJRC9MYWJlbCBpcyBhZHZlcnRpc2VkIHRocm91Z2ggT1NQ Riwgd2hhdCB0eXBlDQoNCm9mIHJvdXRlcyBzaG91bGQgdGhlIGxhYmVsIG1hcHBpbmcgZGVwZW5k IG9uIHdoZW4gc2V0dXAgdGhlIFNSLUJFIHBhdGg/DQoNCg0KDQpJIHRoaW5rIHRoZXJlIG1heSBi ZSB0d28gY2hvaWNlczoNCjEuIE9ubHkgZGVwZW5kIG9uIHRoZSBPU1BGJ3Mgb3duIHJvdXRlOw0K Mi4gTGlrZSB0aGUgTERQLCBkZXBlbmRzIG9uIHRoZSBzZWxlY3RlZCByb3V0ZS4NCg0KDQoNCkkg ZG9uJ3QgdGhpbmsgaXQgc2hvdWxkIGJlIHRoZSBPcHRpb24gMS4gRm9yIGV4YW1wbGUsIHdlIGNv bmZpZ3VyZSBzdGF0aWMgcm91dGVzIGZvciBhbGwgbm9kZXMgYWxvbmcgdGhlIHBhdGggdG8NCmEg c3BlY2lmaWMgbm9kZSB3aGljaCBjYW4gYmUgdG90YWxseSBkaWZmZXJlbnQgZnJvbSB0aGUgT1NQ RiByb3V0ZXMgdG8gdGhlIG5vZGUuIElmIHRoZSBzdGF0aWMgcm91dGUgaGFzIGhpZ2hlcg0KcHJp b3JpdHkgdGhhbiB0aGUgT1NQRiBhbmQgdGhlIFNJRC9sYWJlbCBpcyBhZHZlcnRpc2VkIGJ5IE9T UEYgZGVwZW5kcyBvbiBPU1BGIHJvdXRlcywgdGhlcmUgd2lsbCBiZSB0aGUNCg0KaW5jb25zaXN0 ZW5jeSBiZXR3ZWVuIHRoZSBTUi1CRSBwYXRoIGFuZCB0aGUgcm91dGUgcGF0aC4NCg0KDQoNCklm IHRoZSBvcHRpb24gMiBpcyBhZG9wdGVkLCBpdCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0IHRoZSBs YWJlbCBtYXBwaW5nIGFuZCB0aGUgcm91dGUgYXJlIGluIHRoZSBzYW1lIExTREIgd2hpY2gNCg0K Y2FuIGJlIGVhc2lseSBzeW5jaHJvbml6ZWQuIFRoZXJlIGFyZSB0d28gY2hhbGxlbmdlczoNCjEu IFRoZSBkaXJlY3QgZWZmZWN0IGZvciB0aGUgT1NQRiBpcyB0aGF0IGF0IHRoZSBiZWdpbm5pbmcg aXQganVzdCBkb3dubG9hZHMgaXQgcm91dGVzIHRvIHRoZSBSSUIgZm9yIHRoZSByb3V0ZQ0Kc2Vs ZWN0aW9uLiBUaGF0IGlzLCBpdCBpcyB0aGUgc291cmNlIG9mIHRoZSByb3V0ZSBzZWxlY3Rpb24u IEJ1dCBub3cgb3dpbmcgdG8gU1ItQkUgcGF0aCwgaXQgaGFzIHRvIGRlcGVuZCBvbg0KDQp0aGUg cmVzdWx0IG9mIHRoZSByb3V0ZSBzZWxlY3Rpb24uDQoyLiBPU1BGIFNSLUJFIHBhdGggbWF5IGRl cGVuZCBvbiB0aGUgcm91dGVzIGZyb20gdGhlIHN0YXRpYyByb3V0ZSwgSVNJUywgQkdQLCBldGMu IEl0IGlzIGNsYWltZWQgdGhhdCB0aGUgU1IgY2FuDQpyZW1vdmUgdGhlIElHUC1MRFAgc3luYy4g QnV0IGFjY29yZGluZyB0byB0aGlzIGFuYWx5c2lzLCBhcmUgdGhlcmUgdGhlIHBvc3NpYmxlIHJp c2sgd2UgaGF2ZSB0byBpbnRyb2R1Y2UgdGhlDQoNCk9TUEYtSVNJUyBzeW5jLCBPU1BGLVN0YXRp YyBSb3V0ZSBzeW5jLCBPU1BGLUJHUCBzeW5jPyBPciBkbyB5b3UganVzdCB0aGluayB0aGV5IGFy ZSByYXJlIGNhc2VzIHdoaWNoIHNob3VsZCBub3QNCg0KIGJlIHRha2VuIGludG8gYWNjb3VudD8g SG9wZSB5b3UgaGF2ZSBoYWQgZW5vdWdoIGFuYWx5c2lzIG9uIHRoaXMgaXNzdWUuDQoNCg0KDQpB Y2NvcmRpbmcgdG8gdGhlIGNvbW1lbnRzIG9uIHRoZSBkZXBlbmRlbmN5LCBJIGhvcGUgeW91IGNv dWxkIHNwZWNpZnkgY2xlYXJseSBpbiB0aGUgYXBwcm9wcmlhdGUgZHJhZnQgb2Ygc2VnbWVudA0K DQpyb3V0aW5nIGFzIHRvIGZvbGxvd3MgcXVlc3Rpb25zIGZvciBTUi1CRSBwYXRoIHdoaWNoIGlz IGhlbHBmdWwgZm9yIGludGVyb3BlcmFiaWxpdHk6DQotLSBkZXBlbmQgb24gdGhlIGxvbmdlc3Qg bWF0Y2gsIG9yIGV4YWN0IG1hdGNoLCBvciBib3RoLg0KLS0gZGVwbmVkIG9uIHRoZSBTUiBwcm90 b2NvbCdzIG93biByb3V0ZXMgb3IgdGhlIHJvdXRlIHNlbGVjdGlvbiByZXN1bHRlIGZyb20gbXVs dGlwbGUgc291cmNlcy4NCg0KDQoNCg0KDQoNCg0KUmVnYXJkcywNClJvYmluDQoNCg0K --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808Ankgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the fourth comments.

 

For LDP, when search route for the destination ad= dress which is the FEC of the label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS,= BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is = advertised through OSPF, what type

of routes should th= e label mapping depend on when setup the SR-BE path?

 

I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.

 

I don't think it should be the Option 1. For exam= ple, we configure static routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the = node. If the static route has higher
priority than the OSPF and the SID/label is advertised by OSPF depends= on OSPF routes, there will be the

inconsistency between the SR-BE path and the route path.

 

If the option 2 is adopted, it cannot be assumed = that the label mapping and the route are in the same LSDB which

can be easily synchronized. There are two challen= ges:
1. The direct effect for the OSPF is that at the beginning it just download= s it routes to the RIB for the route
selection. That is, it is the source of the route selection. But now owing = to SR-BE path, it has to depend on

the result of the route selection.
2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BG= P, etc. It is claimed that the SR can
remove the IGP-LDP sync. But according to this analysis, are there the poss= ible risk we have to introduce the

OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP = sync? Or do you just think they are rare cases which should not

 be taken into account? Hope you have had en= ough analysis on this issue.

 

According to the comments on the depend= ency, I hope you could specify clearly in the appropriate draft of seg= ment

routing as to follows questions for SR-BE path wh= ich is helpful for interoperability:
-- depend on the longest match, or exact match, or both.
-- depned on the SR protocol's own routes or the route selection resulte fr= om multiple sources.

 

 

 

Regards,
Robin

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808Ankgeml506mbxchi_-- From nobody Wed Jan 21 23:32:58 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8084E1A00D8; Wed, 21 Jan 2015 23:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBWGa_XPecOJ; Wed, 21 Jan 2015 23:32:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C721A1B61; Wed, 21 Jan 2015 23:32:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122073252.29549.85375.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 23:32:52 -0800 Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: [mpls] Spencer Dawkins' Yes on draft-ietf-mpls-in-udp-10: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 07:32:56 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-mpls-in-udp-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to all involved for working through the issues with congestion and zero checksums. I'm happy to ballot Yes on this version (while watching Martin's Discuss out of the corner of my eye). From nobody Wed Jan 21 23:46:54 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12F71AC434; Wed, 21 Jan 2015 23:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5u-lOGU3C7m; Wed, 21 Jan 2015 23:46:51 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2EF1A037D; Wed, 21 Jan 2015 23:46:50 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar1so94832iec.6; Wed, 21 Jan 2015 23:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NsbY5QXx0HQvDs1ESJ4vQN1uH//QUEK6cKLcOHSBy6w=; b=B/wYDUt3rNH4HPrcYc00D9G0/3pFyR6HblvN3hwdPu1WH32PkaIcZsbRc+tzs+nnaz 0Gf7+2sXndNb1cEn7d+8u15GD+eyuWRyrM8UB6M5OAq0GmTzbbW80fUW7y+CnjQlHghs /tUCSrpMbdIlojI/6C4dbujMxo7oWIi+okOmyVknrdz0Br5VStQ1XZFBujqJXHabfEo6 AKCqOg7vAEhAfjuiENUVN5DZxdPVmD6GLW/aYu7yn18G7sec+xLZW2Z9Gf1jOl7TI1QI GwQ3jujwYDC3EiIROcmOCzsGiKIVz+5EbofhVzGlTMa/hWgfSj0FHUtvWM6vUjn6aRWW FpFA== MIME-Version: 1.0 X-Received: by 10.50.124.133 with SMTP id mi5mr1571727igb.13.1421912809821; Wed, 21 Jan 2015 23:46:49 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.27.165 with HTTP; Wed, 21 Jan 2015 23:46:49 -0800 (PST) In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808A@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808A@nkgeml506-mbx.china.huawei.com> Date: Thu, 22 Jan 2015 08:46:49 +0100 X-Google-Sender-Auth: 7RQ5BwHO5S054CWRVQu1COQgMMc Message-ID: From: Robert Raszuk To: Lizhenbin Content-Type: multipart/alternative; boundary=001a1135f578ee5d40050d38df4e Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [mpls] [spring] New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 07:46:53 -0000 --001a1135f578ee5d40050d38df4e Content-Type: text/plain; charset=UTF-8 Hi Robin, I think your question is not applicable to SR architecture. The right SR analogy to LDP would *NOT* be hop by hop LDP like in your example, but targeted (aka directed) LDP session. In those how to get to FEC's address is just regular lookup in the RIB/FIB (global or vrf depends on use case) and it does not matter what protocol src installed the route. Also note that like in most LDP case SR "labels" or "IDs" are global so regardless on which interface packet arrives (within given topology in case of mt) the lookup result will be identical. Rgs, R. On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin wrote: > Hi all authors of segment routing, > > > > This is the fourth comments. > > > > For LDP, when search route for the destination address which is the FEC of > the label mapping, it should search > the FIB in which the routes are selected from the static route, OSPF, > ISIS, BGP, etc based on the preferences. > Now there is one question for SR-BE path, for example, if the SID/Label is > advertised through OSPF, what type > > of routes should the label mapping depend on when setup the SR-BE path? > > > > I think there may be two choices: > 1. Only depend on the OSPF's own route; > 2. Like the LDP, depends on the selected route. > > > > I don't think it should be the Option 1. For example, we configure static > routes for all nodes along the path to > a specific node which can be totally different from the OSPF routes to the > node. If the static route has higher > priority than the OSPF and the SID/label is advertised by OSPF depends on > OSPF routes, there will be the > > inconsistency between the SR-BE path and the route path. > > > > If the option 2 is adopted, it cannot be assumed that the label mapping > and the route are in the same LSDB which > > can be easily synchronized. There are two challenges: > 1. The direct effect for the OSPF is that at the beginning it just > downloads it routes to the RIB for the route > selection. That is, it is the source of the route selection. But now owing > to SR-BE path, it has to depend on > > the result of the route selection. > 2. OSPF SR-BE path may depend on the routes from the static route, ISIS, > BGP, etc. It is claimed that the SR can > remove the IGP-LDP sync. But according to this analysis, are there the > possible risk we have to introduce the > > OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP sync? Or do you just > think they are rare cases which should not > > be taken into account? Hope you have had enough analysis on this issue. > > > > According to the comments on the dependency, I hope you could specify > clearly in the appropriate draft of segment > > routing as to follows questions for SR-BE path which is helpful for > interoperability: > -- depend on the longest match, or exact match, or both. > -- depned on the SR protocol's own routes or the route selection resulte > from multiple sources. > > > > > > > > Regards, > Robin > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --001a1135f578ee5d40050d38df4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robin,

I think your question is not applicable to SR architecture.=C2=A0<= /div>

The right SR analogy to LDP woul= d *NOT* be hop by hop LDP like in your example, but targeted (aka directed)= LDP session. In those how to get to FEC's address is just regular look= up in the RIB/FIB (global or vrf depends on use case) and it does not matte= r what protocol src installed the route.=C2=A0

Also note that like in most LDP case SR "labels" o= r "IDs" are global so regardless on which interface packet arrive= s (within given topology in case of mt) the lookup result will be identical= .

Rgs,
R.


On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin <lizhenbin@= huawei.com> wrote:

Hi all authors of segment routing,

=C2=A0

This is the fourth comments.

=C2=A0

For LDP, when search route for the destination ad= dress which is the FEC of the label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS,= BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is = advertised through OSPF, what type

of routes should th= e label mapping depend on when setup the SR-BE path?

=C2=A0

I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.

=C2=A0

I don't think it should be the Option 1. For = example, we configure static routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the = node. If the static route has higher
priority than the OSPF=C2=A0and the SID/label is advertised by OSPF depends= on OSPF routes, there will be the

inconsistency between the=C2=A0SR-BE path and the route path.

=C2=A0

If the option 2 is adopted, it cannot be assumed = that the label mapping and the route are in the same LSDB which

can be easily synchronized. There are two challen= ges:
1. The direct effect for the OSPF is that at the beginning it just download= s it routes to the RIB for the route
selection. That is, it is the source of the route selection. But now owing = to SR-BE path, it has to depend on

the result of the route selection.
2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BG= P, etc. It is claimed that the SR can
remove the IGP-LDP sync. But according to this analysis, are there the poss= ible risk we have to introduce the

OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP = sync? Or do you just think they are rare cases which should not

=C2=A0be taken into account? Hope you have had en= ough analysis on this issue.

=C2=A0

According to the=C2=A0comments on=C2=A0the depend= ency,=C2=A0I hope you could specify clearly in the appropriate draft of seg= ment

routing as to follows questions for SR-BE path wh= ich is helpful for interoperability:
-- depend on the longest match, or exact match, or both.
-- depned on the SR protocol's own routes or the route selection result= e from multiple sources.

=C2=A0

=C2=A0

=C2=A0

Regards,
Robin

=C2=A0


_______________________________________________
spring mailing list
spring@ietf.org
= https://www.ietf.org/mailman/listinfo/spring


--001a1135f578ee5d40050d38df4e-- From nobody Thu Jan 22 02:24:46 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078601AC410; Thu, 22 Jan 2015 02:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB5b5GKAibqI; Thu, 22 Jan 2015 02:24:41 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCF41A9172; Thu, 22 Jan 2015 02:24:40 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0MAOb5j014624; Thu, 22 Jan 2015 10:24:37 GMT Received: from 950129200 (089144198119.atnat0007.highway.a1.net [89.144.198.119]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0MAOYFE014594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 10:24:35 GMT From: "Adrian Farrel" To: Date: Thu, 22 Jan 2015 10:24:34 -0000 Message-ID: <044501d0362d$9f0864a0$dd192de0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA2LZvAW8/WwMW2T5CDaUv2+mQtEw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21272.006 X-TM-AS-Result: No--4.893-10.0-31-10 X-imss-scan-details: No--4.893-10.0-31-10 X-TMASE-MatchedRID: lE7Cmzn5KhyeCT0HsFTwbwPZZctd3P4BveCbyZ3xax5b8pv4L0h+IjAl 1y8YMtiUtEYmUZwqVBnxTwx4UJIMcoLSdZH87Opgrz6KEvj1EHIZskwWqoib3ESVpnjjB2vkVbP ODjBSiBfi8zVgXoAltlwtzewu2M63tuZmiwj/lnLdB/CxWTRRu+rAZ8KTspSzKzUzzkE0Hk3uDH pa0Zg2MlYBNguqrfZaHAkiq22LSWNrsq45P6dDG2gg5JPHuhX+yxfhaSGhnTGBgfrdk4lMWhBF8 DhEphUUCQKeQDeH+fUPvTV19UCLO5Iv06+1Rxr97r4PjzaceGt+3BndfXUhXQ== Archived-At: Cc: mpls@ietf.org Subject: [mpls] Last Call comment: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 10:24:43 -0000 A small nit to include in the last call comments... Section 5 OLD "IPv6 Router Alert Option Values" registry defined by [RFC5350] and NEW "IPv6 Router Alert Option Values" registry defined by [RFC2711] and updated by [RFC5350] and END Adrian > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The > IESG > Sent: 21 January 2015 23:23 > To: IETF-Announce > Cc: mpls@ietf.org > Subject: Last Call: (IPv6 Router Alert > Option for MPLS OAM) to Proposed Standard From nobody Thu Jan 22 03:07:23 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0C31AC443; Thu, 22 Jan 2015 03:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUjy3E8gwjb9; Thu, 22 Jan 2015 03:07:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DAD1AC7E7; Thu, 22 Jan 2015 03:07:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122110708.6977.8048.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 03:07:08 -0800 Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-in-udp-10: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 11:07:14 -0000 Benoit Claise has entered the following ballot position for draft-ietf-mpls-in-udp-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - An editorial detail in the abstract. Take it or leave it The MPLS-in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of co-operating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. We rarely see specifications ("must" sentences) in abstracts. Do you want to say something like: The MPLS-in-UDP encapsulation applicability is for networks where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. From nobody Thu Jan 22 03:09:29 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4051ACC81; Thu, 22 Jan 2015 03:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdhn7oFe7ZYY; Thu, 22 Jan 2015 03:09:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1423E1ACC82; Thu, 22 Jan 2015 03:08:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRP86397; Thu, 22 Jan 2015 11:08:58 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 22 Jan 2015 11:08:57 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 22 Jan 2015 19:08:54 +0800 From: Lizhenbin To: Robert Raszuk Thread-Topic: [spring] New Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Path Thread-Index: AdA2AFmCnRYsHpISS4y8T7IvquyS6P//qFiAgAC74dk= Date: Thu, 22 Jan 2015 11:08:54 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818C@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808A@nkgeml506-mbx.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818Cnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNl?= =?gb2312?b?Z21lbnQgUm91dGluZyg0KTogQ2hhbGxlbmdlIG9mIFJvdXRlIERlcGVuZGVu?= =?gb2312?b?Y3kgZm9yIFNSLUJFIFBhdGg=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 11:09:09 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818Cnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpQbGVhc2UgcmVmZXIgdG8gbXkgaW5saW5lICdbUm9iaW5dJy4NCg0KDQoN ClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBycmFzenVrQGdtYWlsLmNvbSBbcnJhc3p1a0BnbWFpbC5jb21dILT6se0gUm9i ZXJ0IFJhc3p1ayBbcm9iZXJ0QHJhc3p1ay5uZXRdDQq3osvNyrG85DogMjAxNcTqMdTCMjLI1SAx NTo0Ng0KytW8/sjLOiBMaXpoZW5iaW4NCrOty806IHNwcmluZ0BpZXRmLm9yZzsgbXBsc0BpZXRm Lm9yZw0K1vfM4jogUmU6IFtzcHJpbmddIE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmco NCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBEZXBlbmRlbmN5IGZvciBTUi1CRSBQYXRoDQoNCkhpIFJv YmluLA0KDQpJIHRoaW5rIHlvdXIgcXVlc3Rpb24gaXMgbm90IGFwcGxpY2FibGUgdG8gU1IgYXJj aGl0ZWN0dXJlLg0KDQpUaGUgcmlnaHQgU1IgYW5hbG9neSB0byBMRFAgd291bGQgKk5PVCogYmUg aG9wIGJ5IGhvcCBMRFAgbGlrZSBpbiB5b3VyIGV4YW1wbGUsIGJ1dCB0YXJnZXRlZCAoYWthIGRp cmVjdGVkKSBMRFAgc2Vzc2lvbi4NCltSb2Jpbl0gSSBjb3VsZCBub3QgdW5kZXJzdGFuZCB5b3Vy IHBvaW50LiBObyBtYXR0ZXIgVC1MRFAgb3IgbG9jYWwgTERQLCB0aGV5IHNob3VsZCBsb29rdXAg aW4gdGhlIFJJQi9GSUIgdG8gZGV0ZXJtaW5lIGlmIHRoZSBsYWJlbCBtYXBwaW5nIGlzIGFjdGl2 ZS4NCkluIHRob3NlIGhvdyB0byBnZXQgdG8gRkVDJ3MgYWRkcmVzcyBpcyBqdXN0IHJlZ3VsYXIg bG9va3VwIGluIHRoZSBSSUIvRklCIChnbG9iYWwgb3IgdnJmIGRlcGVuZHMgb24gdXNlIGNhc2Up IGFuZCBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hhdCBwcm90b2NvbCBzcmMgaW5zdGFsbGVkIHRoZSBy b3V0ZS4NCltSb2Jpbl0gQXMgd2hhdCB5b3UgZGVzY3JpYmVkLCBjb3VsZCBJIHVuZGVyc3RhbmQg eW91IG1lYW5zIGZvciB0aGUgU1IgYmFzZWQgb24gYSBzcGVjaWZpYyBJR1AoZS5nLiBPU1BGKSwg aXQgc2hvdWxkIGxvb2sgdXAgaW4gdGhlIFJJQi9GSUIgdG8gZGV0ZXJtaW5lIGlmIHRoZSBsYWJl bCBiaW5kaW5nIGlzIHVwPyBJZiBzbywgdGhlcmUgd2lsbCBiZSB0aGUgdHdvIHJvdXRlIGRlcGVu ZGVuY3kgY2hhbmdlIGlzc3VlcyBJIHByb3Bvc2VkIGZvciB0aGUgT1NQRi4gV2h5IGRvIHlvdSB0 aGluayB0aGV5IGFyZSBub3QgYXBwbGljYWJsZSB0byBTUj8NCg0KDQpBbHNvIG5vdGUgdGhhdCBs aWtlIGluIG1vc3QgTERQIGNhc2UgU1IgImxhYmVscyIgb3IgIklEcyIgYXJlIGdsb2JhbCBzbyBy ZWdhcmRsZXNzIG9uIHdoaWNoIGludGVyZmFjZSBwYWNrZXQgYXJyaXZlcyAod2l0aGluIGdpdmVu IHRvcG9sb2d5IGluIGNhc2Ugb2YgbXQpIHRoZSBsb29rdXAgcmVzdWx0IHdpbGwgYmUgaWRlbnRp Y2FsLg0KDQpSZ3MsDQpSLg0KDQoNCk9uIFRodSwgSmFuIDIyLCAyMDE1IGF0IDY6MDcgQU0sIExp emhlbmJpbiA8bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRvOmxpemhlbmJpbkBodWF3ZWkuY29t Pj4gd3JvdGU6DQoNCkhpIGFsbCBhdXRob3JzIG9mIHNlZ21lbnQgcm91dGluZywNCg0KDQoNClRo aXMgaXMgdGhlIGZvdXJ0aCBjb21tZW50cy4NCg0KDQoNCkZvciBMRFAsIHdoZW4gc2VhcmNoIHJv dXRlIGZvciB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyB3aGljaCBpcyB0aGUgRkVDIG9mIHRoZSBs YWJlbCBtYXBwaW5nLCBpdCBzaG91bGQgc2VhcmNoDQp0aGUgRklCIGluIHdoaWNoIHRoZSByb3V0 ZXMgYXJlIHNlbGVjdGVkIGZyb20gdGhlIHN0YXRpYyByb3V0ZSwgT1NQRiwgSVNJUywgQkdQLCBl dGMgYmFzZWQgb24gdGhlIHByZWZlcmVuY2VzLg0KTm93IHRoZXJlIGlzIG9uZSBxdWVzdGlvbiBm b3IgU1ItQkUgcGF0aCwgZm9yIGV4YW1wbGUsIGlmIHRoZSBTSUQvTGFiZWwgaXMgYWR2ZXJ0aXNl ZCB0aHJvdWdoIE9TUEYsIHdoYXQgdHlwZQ0KDQpvZiByb3V0ZXMgc2hvdWxkIHRoZSBsYWJlbCBt YXBwaW5nIGRlcGVuZCBvbiB3aGVuIHNldHVwIHRoZSBTUi1CRSBwYXRoPw0KDQoNCg0KSSB0aGlu ayB0aGVyZSBtYXkgYmUgdHdvIGNob2ljZXM6DQoxLiBPbmx5IGRlcGVuZCBvbiB0aGUgT1NQRidz IG93biByb3V0ZTsNCjIuIExpa2UgdGhlIExEUCwgZGVwZW5kcyBvbiB0aGUgc2VsZWN0ZWQgcm91 dGUuDQoNCg0KDQpJIGRvbid0IHRoaW5rIGl0IHNob3VsZCBiZSB0aGUgT3B0aW9uIDEuIEZvciBl eGFtcGxlLCB3ZSBjb25maWd1cmUgc3RhdGljIHJvdXRlcyBmb3IgYWxsIG5vZGVzIGFsb25nIHRo ZSBwYXRoIHRvDQphIHNwZWNpZmljIG5vZGUgd2hpY2ggY2FuIGJlIHRvdGFsbHkgZGlmZmVyZW50 IGZyb20gdGhlIE9TUEYgcm91dGVzIHRvIHRoZSBub2RlLiBJZiB0aGUgc3RhdGljIHJvdXRlIGhh cyBoaWdoZXINCnByaW9yaXR5IHRoYW4gdGhlIE9TUEYgYW5kIHRoZSBTSUQvbGFiZWwgaXMgYWR2 ZXJ0aXNlZCBieSBPU1BGIGRlcGVuZHMgb24gT1NQRiByb3V0ZXMsIHRoZXJlIHdpbGwgYmUgdGhl DQoNCmluY29uc2lzdGVuY3kgYmV0d2VlbiB0aGUgU1ItQkUgcGF0aCBhbmQgdGhlIHJvdXRlIHBh dGguDQoNCg0KDQpJZiB0aGUgb3B0aW9uIDIgaXMgYWRvcHRlZCwgaXQgY2Fubm90IGJlIGFzc3Vt ZWQgdGhhdCB0aGUgbGFiZWwgbWFwcGluZyBhbmQgdGhlIHJvdXRlIGFyZSBpbiB0aGUgc2FtZSBM U0RCIHdoaWNoDQoNCmNhbiBiZSBlYXNpbHkgc3luY2hyb25pemVkLiBUaGVyZSBhcmUgdHdvIGNo YWxsZW5nZXM6DQoxLiBUaGUgZGlyZWN0IGVmZmVjdCBmb3IgdGhlIE9TUEYgaXMgdGhhdCBhdCB0 aGUgYmVnaW5uaW5nIGl0IGp1c3QgZG93bmxvYWRzIGl0IHJvdXRlcyB0byB0aGUgUklCIGZvciB0 aGUgcm91dGUNCnNlbGVjdGlvbi4gVGhhdCBpcywgaXQgaXMgdGhlIHNvdXJjZSBvZiB0aGUgcm91 dGUgc2VsZWN0aW9uLiBCdXQgbm93IG93aW5nIHRvIFNSLUJFIHBhdGgsIGl0IGhhcyB0byBkZXBl bmQgb24NCg0KdGhlIHJlc3VsdCBvZiB0aGUgcm91dGUgc2VsZWN0aW9uLg0KMi4gT1NQRiBTUi1C RSBwYXRoIG1heSBkZXBlbmQgb24gdGhlIHJvdXRlcyBmcm9tIHRoZSBzdGF0aWMgcm91dGUsIElT SVMsIEJHUCwgZXRjLiBJdCBpcyBjbGFpbWVkIHRoYXQgdGhlIFNSIGNhbg0KcmVtb3ZlIHRoZSBJ R1AtTERQIHN5bmMuIEJ1dCBhY2NvcmRpbmcgdG8gdGhpcyBhbmFseXNpcywgYXJlIHRoZXJlIHRo ZSBwb3NzaWJsZSByaXNrIHdlIGhhdmUgdG8gaW50cm9kdWNlIHRoZQ0KDQpPU1BGLUlTSVMgc3lu YywgT1NQRi1TdGF0aWMgUm91dGUgc3luYywgT1NQRi1CR1Agc3luYz8gT3IgZG8geW91IGp1c3Qg dGhpbmsgdGhleSBhcmUgcmFyZSBjYXNlcyB3aGljaCBzaG91bGQgbm90DQoNCiBiZSB0YWtlbiBp bnRvIGFjY291bnQ/IEhvcGUgeW91IGhhdmUgaGFkIGVub3VnaCBhbmFseXNpcyBvbiB0aGlzIGlz c3VlLg0KDQoNCg0KQWNjb3JkaW5nIHRvIHRoZSBjb21tZW50cyBvbiB0aGUgZGVwZW5kZW5jeSwg SSBob3BlIHlvdSBjb3VsZCBzcGVjaWZ5IGNsZWFybHkgaW4gdGhlIGFwcHJvcHJpYXRlIGRyYWZ0 IG9mIHNlZ21lbnQNCg0Kcm91dGluZyBhcyB0byBmb2xsb3dzIHF1ZXN0aW9ucyBmb3IgU1ItQkUg cGF0aCB3aGljaCBpcyBoZWxwZnVsIGZvciBpbnRlcm9wZXJhYmlsaXR5Og0KLS0gZGVwZW5kIG9u IHRoZSBsb25nZXN0IG1hdGNoLCBvciBleGFjdCBtYXRjaCwgb3IgYm90aC4NCi0tIGRlcG5lZCBv biB0aGUgU1IgcHJvdG9jb2wncyBvd24gcm91dGVzIG9yIHRoZSByb3V0ZSBzZWxlY3Rpb24gcmVz dWx0ZSBmcm9tIG11bHRpcGxlIHNvdXJjZXMuDQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMsDQpSb2Jp bg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0KDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818Cnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Robert,

Please refer to my inline '[Robin]'.

 

Regards,

Robin

 

=B7=A2=BC=FE=C8=CB: rraszuk@gmail.com [rra= szuk@gmail.com] =B4=FA=B1=ED Robert Raszuk [robert@raszuk.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C222=C8=D5 15:46
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: spring@ietf.org; mpls@ietf.org
=D6=F7=CC=E2: Re: [spring] New Comments on Segment Routing(4): Chall= enge of Route Dependency for SR-BE Path

Hi Robin,

I think your question is not applicable to SR architecture. 

The right SR analogy to LDP would *NOT* be hop by hop LDP like in your exam= ple, but targeted (aka directed) LDP session.
[Robin] I could not understand your point. No matter T-LDP or local LD= P, they should lookup in the RIB/FIB to determine if the label mapping is a= ctive.
In those how to get to FEC's address is just regular lookup in the RIB/FIB = (global or vrf depends on use case) and it does not matter what protocol sr= c installed the route. 
[Robin] As what you described, could I understand you means for the SR base= d on a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to determi= ne if the label binding is up? If so, there will be the two route dependenc= y change issues I proposed for the OSPF. Why do you think they are not applicable to SR?
 
 
Also note that like in most LDP case SR "labels" or "IDs&quo= t; are global so regardless on which interface packet arrives (within given= topology in case of mt) the lookup result will be identical.

Rgs,
R.


On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin <lizhenbin@hua= wei.com> wrote:

Hi all authors of segment routing,

 

This is the fourth comments.

 

For LDP, when search route for the destination ad= dress which is the FEC of the label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS,= BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is = advertised through OSPF, what type

of routes should th= e label mapping depend on when setup the SR-BE path?

 

I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.

 

I don't think it should be the Option 1. For exam= ple, we configure static routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the = node. If the static route has higher
priority than the OSPF and the SID/label is advertised by OSPF depends= on OSPF routes, there will be the

inconsistency between the SR-BE path and the route path.

 

If the option 2 is adopted, it cannot be assumed = that the label mapping and the route are in the same LSDB which

can be easily synchronized. There are two challen= ges:
1. The direct effect for the OSPF is that at the beginning it just download= s it routes to the RIB for the route
selection. That is, it is the source of the route selection. But now owing = to SR-BE path, it has to depend on

the result of the route selection.
2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BG= P, etc. It is claimed that the SR can
remove the IGP-LDP sync. But according to this analysis, are there the poss= ible risk we have to introduce the

OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP = sync? Or do you just think they are rare cases which should not

 be taken into account? Hope you have had en= ough analysis on this issue.

 

According to the comments on the depend= ency, I hope you could specify clearly in the appropriate draft of seg= ment

routing as to follows questions for SR-BE path wh= ich is helpful for interoperability:
-- depend on the longest match, or exact match, or both.
-- depned on the SR protocol's own routes or the route selection resulte fr= om multiple sources.

 

 

 

Regards,
Robin

 


_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring


--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818Cnkgeml506mbxchi_-- From nobody Thu Jan 22 03:11:15 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E981AC44E; Thu, 22 Jan 2015 03:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsyf1DN-pehU; Thu, 22 Jan 2015 03:11:03 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8D91AC44C; Thu, 22 Jan 2015 03:11:02 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0MBAv1E023458; Thu, 22 Jan 2015 11:10:57 GMT Received: from 950129200 (089144227112.atnat0036.highway.a1.net [89.144.227.112]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0MBAswb023360 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 11:10:55 GMT From: "Adrian Farrel" To: "'Benoit Claise'" , "'The IESG'" References: <20150122110708.6977.8048.idtracker@ietfa.amsl.com> In-Reply-To: <20150122110708.6977.8048.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 11:10:54 -0000 Message-ID: <045b01d03634$18705a40$49510ec0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMknKfV/cORwcmI3OVNoepoP6sI4ZojLmTg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21272.006 X-TM-AS-Result: No--11.236-10.0-31-10 X-imss-scan-details: No--11.236-10.0-31-10 X-TMASE-MatchedRID: QW5G6BKkLTodVBXyH4TZjsAmcZEx8XHJ+28MI88F5wQwp/4s3hUlGMom H/F60Za8Jztihk0JotTxTwx4UJIMcsDxbnxe/DuInJ5tL+LbGOPzL5MQzw14h2tEzrC9eANpE7o rXnCF9AyI7qXZddSBHa0Pj/9cOH4sCAKizYVJv3/K09/T6AzbViIBy2vbJcliuqWf6Nh7tmGzP/ mFbCCOqJyujR9JCXlawqOonHKEy6dtNLAj8DYO8O/1OyZjKYoh98YfqyXzGgraqqH/oHw+kXLyy EMJEoRO7v93e1IVuSVftuJwrFEhTbew1twePJJB3QfwsVk0UbtuRXh7bFKB7saIZhg6vl2y0OQl KB9EAm6VmJGm72DDZ0mqXV/2xl0cHIV02d1rpG8= Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-in-udp-10: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 11:11:09 -0000 I'd be happy to change the Abstract as Benoit suggests, but I note that = we have been doing a dance to keep the TSV community happy, and these = words did the trick. Changing them at this late stage might be seen as = going back on a promise. Adrian (contributing author and recused) > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: 22 January 2015 11:07 > To: The IESG > Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; > mpls@ietf.org; Loa Andersson > Subject: Benoit Claise's No Objection on draft-ietf-mpls-in-udp-10: = (with > COMMENT) >=20 > Benoit Claise has entered the following ballot position for > draft-ietf-mpls-in-udp-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - An editorial detail in the abstract. Take it or leave it > The MPLS-in-UDP encapsulation technology must only be deployed = within > a > single network (with a single network operator) or networks of an > adjacent set of co-operating network operators where traffic is > managed to avoid congestion, rather than over the Internet where > congestion control is required. >=20 > We rarely see specifications ("must" sentences) in abstracts. > Do you want to say something like: > The MPLS-in-UDP encapsulation applicability is for networks where > traffic is managed to avoid congestion, rather than over the = Internet >=20 > where congestion control is required. From nobody Thu Jan 22 03:14:41 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF3A1ACAD8; Thu, 22 Jan 2015 03:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn9SvTzYPA_U; Thu, 22 Jan 2015 03:14:37 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E539F1AC43D; Thu, 22 Jan 2015 03:14:36 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id vy18so776910iec.5; Thu, 22 Jan 2015 03:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mzIZCYC6IGz0n+eTb36eQQXmrnHjaJUcyYh7K/kntx8=; b=oJt1wEkAp9HgWW9XSXg/K2pPwS6gqaxT0c7E0U5sWvS8DJ405O/XYhrK+7qjRrWT2x QrJDr5xftGmWo610z19zB28IA9nlBfMk4Oi3PJKFhyopbkqJKCSEFwx4w/V+MaeX0TtZ 5UypFxdz3EWzEyKReGOcMLuQERt/e02WFjKReuQCoLNe1XAZB+fH9RrjNKr3wL+d+GUF AhzeHLqkrKdEf3yCVPTVWpSPiPnzpe3ID3GweOC7FddkxCDgBwSeRP5D/7gTmMK1OQrZ +gYWa36Uo/GoIHQewkrw218uZFbTN9iVK+z3u/rynotxRAReDVPBz678gErOcQ6HbAPt vTbA== MIME-Version: 1.0 X-Received: by 10.42.29.6 with SMTP id p6mr2025000icc.85.1421925276097; Thu, 22 Jan 2015 03:14:36 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.27.165 with HTTP; Thu, 22 Jan 2015 03:14:36 -0800 (PST) In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818C@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808A@nkgeml506-mbx.china.huawei.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818C@nkgeml506-mbx.china.huawei.com> Date: Thu, 22 Jan 2015 12:14:36 +0100 X-Google-Sender-Auth: 0-KEaswUKEO3u2CbQ2jvFrMEuxM Message-ID: From: Robert Raszuk To: Lizhenbin Content-Type: multipart/alternative; boundary=20cf301d4266faa273050d3bc686 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2Vn?= =?utf-8?q?ment_Routing=284=29=3A_Challenge_of_Route_Dependency_for_SR-BE_?= =?utf-8?q?Path?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 11:14:39 -0000 --20cf301d4266faa273050d3bc686 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robin, Label binding being up or active seems orthogonal to SR. If it is not active/up different transport will be used between SR nodes for example GRE or UDP etc.. What is the issue with that ? Thx, R. On Thu, Jan 22, 2015 at 12:08 PM, Lizhenbin wrote: > Hi Robert, > > Please refer to my inline '[Robin]'. > > > > Regards, > > Robin > > > ------------------------------ > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* rraszuk@gmail.com [rraszuk@gmail.com] =E4= =BB=A3=E8=A1=A8 Robert Raszuk [ > robert@raszuk.net] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2015=E5=B9=B41=E6=9C=8822=E6=97= =A5 15:46 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Lizhenbin > *=E6=8A=84=E9=80=81:* spring@ietf.org; mpls@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: [spring] New Comments on Segment Routing(4): Ch= allenge of Route > Dependency for SR-BE Path > > Hi Robin, > > I think your question is not applicable to SR architecture. > > The right SR analogy to LDP would *NOT* be hop by hop LDP like in your > example, but targeted (aka directed) LDP session. > [Robin] I could not understand your point. No matter T-LDP or local LDP, > they should lookup in the RIB/FIB to determine if the label mapping is > active. > In those how to get to FEC's address is just regular lookup in the > RIB/FIB (global or vrf depends on use case) and it does not matter what > protocol src installed the route. > [Robin] As what you described, could I understand you means for the SR > based on a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to > determine if the label binding is up? If so, there will be the two route > dependency change issues I proposed for the OSPF. Why do you think they a= re > not applicable to SR? > > > Also note that like in most LDP case SR "labels" or "IDs" are global so > regardless on which interface packet arrives (within given topology in ca= se > of mt) the lookup result will be identical. > > Rgs, > R. > > > On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin wrote: > >> Hi all authors of segment routing, >> >> >> >> This is the fourth comments. >> >> >> >> For LDP, when search route for the destination address which is the FEC >> of the label mapping, it should search >> the FIB in which the routes are selected from the static route, OSPF, >> ISIS, BGP, etc based on the preferences. >> Now there is one question for SR-BE path, for example, if the SID/Label >> is advertised through OSPF, what type >> >> of routes should the label mapping depend on when setup the SR-BE path? >> >> >> >> I think there may be two choices: >> 1. Only depend on the OSPF's own route; >> 2. Like the LDP, depends on the selected route. >> >> >> >> I don't think it should be the Option 1. For example, we configure stati= c >> routes for all nodes along the path to >> a specific node which can be totally different from the OSPF routes to >> the node. If the static route has higher >> priority than the OSPF and the SID/label is advertised by OSPF depends o= n >> OSPF routes, there will be the >> >> inconsistency between the SR-BE path and the route path. >> >> >> >> If the option 2 is adopted, it cannot be assumed that the label mapping >> and the route are in the same LSDB which >> >> can be easily synchronized. There are two challenges: >> 1. The direct effect for the OSPF is that at the beginning it just >> downloads it routes to the RIB for the route >> selection. That is, it is the source of the route selection. But now >> owing to SR-BE path, it has to depend on >> >> the result of the route selection. >> 2. OSPF SR-BE path may depend on the routes from the static route, ISIS, >> BGP, etc. It is claimed that the SR can >> remove the IGP-LDP sync. But according to this analysis, are there the >> possible risk we have to introduce the >> >> OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP sync? Or do you just >> think they are rare cases which should not >> >> be taken into account? Hope you have had enough analysis on this issue. >> >> >> >> According to the comments on the dependency, I hope you could specify >> clearly in the appropriate draft of segment >> >> routing as to follows questions for SR-BE path which is helpful for >> interoperability: >> -- depend on the longest match, or exact match, or both. >> -- depned on the SR protocol's own routes or the route selection resulte >> from multiple sources. >> >> >> >> >> >> >> >> Regards, >> Robin >> >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> > --20cf301d4266faa273050d3bc686 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robin,

Label binding being up or active seems orthogonal to SR. If it is not= active/up different transport will be used between SR nodes for example GR= E or UDP etc.. What is the issue with that ?

<= div class=3D"gmail_default" style=3D"font-family:courier new,monospace;font= -size:small">Thx,
R.

On Thu, Jan 22, 2015 at 12:08 PM, Lizhenb= in <lizhenbin@huawei.com> wrote:

Hi Robert,

Please refer to my inline '[Robin]'.

=C2=A0

Regards,

Robin

=C2=A0

=E5= =8F=91=E4=BB=B6=E4=BA=BA: rraszuk@gmail.com [rraszuk@gmail.com] =E4=BB=A3=E8=A1=A8 Robert Raszuk [robert@raszuk.net]<= br> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B41=E6=9C=8822=E6= =97=A5 15:46
=E6=94=B6=E4=BB=B6=E4=BA=BA: Lizhenbin
=E6=8A=84=E9=80=81: spring@ietf.org; mpls@ietf.org
=E4=B8=BB=E9=A2=98: Re: [spring] New Comments on Segment Routing(4):= Challenge of Route Dependency for SR-BE Path

Hi Robin,

I think your question is not applicable to SR architecture.=C2=A0

The right SR analogy to LDP would *NOT* be hop by hop LDP like in your exam= ple, but targeted (aka directed) LDP session.
[Robin]=C2=A0I could not understand your point. No matter T-LDP or local LD= P, they should lookup in the RIB/FIB to determine if the label mapping is a= ctive.
In those how to get to FEC's address is just regular lookup in the RIB/= FIB (global or vrf depends on use case) and it does not matter what protoco= l src installed the route.=C2=A0
[Robin] As what you described, could I understand you means for the SR base= d on a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to determi= ne if the label binding is up? If so, there will be the two route dependenc= y change issues I proposed for the OSPF. Why do you think they are not applicable to SR?
=C2=A0
=C2=A0
Also note that like in most LDP case SR "labels" or "IDs&quo= t; are global so regardless on which interface packet arrives (within given= topology in case of mt) the lookup result will be identical.

Rgs,
R.


On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin <lizhenbin@hua= wei.com> wrote:

Hi all authors of segment routing,

=C2=A0

This is the fourth comments.

=C2=A0

For LDP, when search route for the destination ad= dress which is the FEC of the label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS,= BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is = advertised through OSPF, what type

of routes should th= e label mapping depend on when setup the SR-BE path?

=C2=A0

I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.

=C2=A0

I don't think it should be the Option 1. For = example, we configure static routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the = node. If the static route has higher
priority than the OSPF=C2=A0and the SID/label is advertised by OSPF depends= on OSPF routes, there will be the

inconsistency between the=C2=A0SR-BE path and the route path.

=C2=A0

If the option 2 is adopted, it cannot be assumed = that the label mapping and the route are in the same LSDB which

can be easily synchronized. There are two challen= ges:
1. The direct effect for the OSPF is that at the beginning it just download= s it routes to the RIB for the route
selection. That is, it is the source of the route selection. But now owing = to SR-BE path, it has to depend on

the result of the route selection.
2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BG= P, etc. It is claimed that the SR can
remove the IGP-LDP sync. But according to this analysis, are there the poss= ible risk we have to introduce the

OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP = sync? Or do you just think they are rare cases which should not

=C2=A0be taken into account? Hope you have had en= ough analysis on this issue.

=C2=A0

According to the=C2=A0comments on=C2=A0the depend= ency,=C2=A0I hope you could specify clearly in the appropriate draft of seg= ment

routing as to follows questions for SR-BE path wh= ich is helpful for interoperability:
-- depend on the longest match, or exact match, or both.
-- depned on the SR protocol's own routes or the route selection result= e from multiple sources.

=C2=A0

=C2=A0

=C2=A0

Regards,
Robin

=C2=A0


_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring



--20cf301d4266faa273050d3bc686-- From nobody Thu Jan 22 03:48:26 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C871ACAD8; Thu, 22 Jan 2015 03:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqCGCrHD4ANH; Thu, 22 Jan 2015 03:48:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465291AC7E7; Thu, 22 Jan 2015 03:48:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOH82520; Thu, 22 Jan 2015 11:48:19 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 22 Jan 2015 11:48:17 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 22 Jan 2015 19:48:12 +0800 From: Lizhenbin To: Robert Raszuk Thread-Topic: =?gb2312?B?tPC4tDogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNlZ21lbnQgUm91dGlu?= =?gb2312?B?Zyg0KTogQ2hhbGxlbmdlIG9mIFJvdXRlIERlcGVuZGVuY3kgZm9yIFNSLUJF?= =?gb2312?Q?_Path?= Thread-Index: AdA2AFmCnRYsHpISS4y8T7IvquyS6P//qFiAgAC74dn//34tAIAAjmRb Date: Thu, 22 Jan 2015 11:48:11 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D477281AE@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808A@nkgeml506-mbx.china.huawei.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818C@nkgeml506-mbx.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477281AEnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogtPC4tDogW3NwcmluZ10gTmV3IENvbW1lbnRz?= =?gb2312?b?IG9uIFNlZ21lbnQgUm91dGluZyg0KTogQ2hhbGxlbmdlIG9mIFJvdXRlIERl?= =?gb2312?b?cGVuZGVuY3kgZm9yIFNSLUJFIFBhdGg=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 11:48:25 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477281AEnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJIGdpdmUgeW91IGFuIGV4YW1wbGUuIFRoZSB0b3BvbG9neSBpcyBhcyBm b2xsb3dzIGFuZCBhbGwgbm9kZXMgc3VwcG9ydCBTUi4NCg0KDQoNCkEgIC0tLSAgQiAgLS0tICBD ICAtLS0tIEQNCg0KDQoNCklmIFNJRC9sYWJlbCBpcyBjb25maWd1cmVkIG9uIEQgYW5kIHRoZSBT SUQvbGFiZWwgYmluZGluZyBmb3IgdGhlIG5vZGUgRCBhcmUgZmxvb2RlZCB0byBBL0IvQyB0aHJv dWdoIE9TUEYsIGNvdWxkIHlvdSB0ZWxsIG1lIGhvdyB0aGUgU1ItQkUgcGF0aCB0byB0aGUgbm9k ZSBEIGlzIHNldCB1cCBhbmQgdGhlIGxhYmVsIGZvd2FyZGluZyBlbnRyeSBpcyBjcmVhdGVkIG9u IEEsIEIsIEM/DQoNCg0KDQpSZWdhcmRzLA0KDQpSb2Jpbg0KDQoNCg0KDQoNCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogcnJhc3p1a0BnbWFpbC5jb20g W3JyYXN6dWtAZ21haWwuY29tXSC0+rHtIFJvYmVydCBSYXN6dWsgW3JvYmVydEByYXN6dWsubmV0 XQ0Kt6LLzcqxvOQ6IDIwMTXE6jHUwjIyyNUgMTk6MTQNCsrVvP7IyzogTGl6aGVuYmluDQqzrcvN OiBzcHJpbmdAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCtb3zOI6IFJlOiC08Li0OiBbc3ByaW5n XSBOZXcgQ29tbWVudHMgb24gU2VnbWVudCBSb3V0aW5nKDQpOiBDaGFsbGVuZ2Ugb2YgUm91dGUg RGVwZW5kZW5jeSBmb3IgU1ItQkUgUGF0aA0KDQpSb2JpbiwNCg0KTGFiZWwgYmluZGluZyBiZWlu ZyB1cCBvciBhY3RpdmUgc2VlbXMgb3J0aG9nb25hbCB0byBTUi4gSWYgaXQgaXMgbm90IGFjdGl2 ZS91cCBkaWZmZXJlbnQgdHJhbnNwb3J0IHdpbGwgYmUgdXNlZCBiZXR3ZWVuIFNSIG5vZGVzIGZv ciBleGFtcGxlIEdSRSBvciBVRFAgZXRjLi4gV2hhdCBpcyB0aGUgaXNzdWUgd2l0aCB0aGF0ID8N Cg0KVGh4LA0KUi4NCg0KT24gVGh1LCBKYW4gMjIsIDIwMTUgYXQgMTI6MDggUE0sIExpemhlbmJp biA8bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRvOmxpemhlbmJpbkBodWF3ZWkuY29tPj4gd3Jv dGU6DQoNCkhpIFJvYmVydCwNCg0KUGxlYXNlIHJlZmVyIHRvIG15IGlubGluZSAnW1JvYmluXScu DQoNCg0KDQpSZWdhcmRzLA0KDQpSb2Jpbg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCreivP7IyzogcnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwu Y29tPiBbcnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0gtPqx7SBS b2JlcnQgUmFzenVrIFtyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+ XQ0Kt6LLzcqxvOQ6IDIwMTXE6jHUwjIyyNUgMTU6NDYNCsrVvP7IyzogTGl6aGVuYmluDQqzrcvN OiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQrW98ziOiBSZTogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9u IFNlZ21lbnQgUm91dGluZyg0KTogQ2hhbGxlbmdlIG9mIFJvdXRlIERlcGVuZGVuY3kgZm9yIFNS LUJFIFBhdGgNCg0KSGkgUm9iaW4sDQoNCkkgdGhpbmsgeW91ciBxdWVzdGlvbiBpcyBub3QgYXBw bGljYWJsZSB0byBTUiBhcmNoaXRlY3R1cmUuDQoNClRoZSByaWdodCBTUiBhbmFsb2d5IHRvIExE UCB3b3VsZCAqTk9UKiBiZSBob3AgYnkgaG9wIExEUCBsaWtlIGluIHlvdXIgZXhhbXBsZSwgYnV0 IHRhcmdldGVkIChha2EgZGlyZWN0ZWQpIExEUCBzZXNzaW9uLg0KW1JvYmluXSBJIGNvdWxkIG5v dCB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuIE5vIG1hdHRlciBULUxEUCBvciBsb2NhbCBMRFAsIHRo ZXkgc2hvdWxkIGxvb2t1cCBpbiB0aGUgUklCL0ZJQiB0byBkZXRlcm1pbmUgaWYgdGhlIGxhYmVs IG1hcHBpbmcgaXMgYWN0aXZlLg0KSW4gdGhvc2UgaG93IHRvIGdldCB0byBGRUMncyBhZGRyZXNz IGlzIGp1c3QgcmVndWxhciBsb29rdXAgaW4gdGhlIFJJQi9GSUIgKGdsb2JhbCBvciB2cmYgZGVw ZW5kcyBvbiB1c2UgY2FzZSkgYW5kIGl0IGRvZXMgbm90IG1hdHRlciB3aGF0IHByb3RvY29sIHNy YyBpbnN0YWxsZWQgdGhlIHJvdXRlLg0KW1JvYmluXSBBcyB3aGF0IHlvdSBkZXNjcmliZWQsIGNv dWxkIEkgdW5kZXJzdGFuZCB5b3UgbWVhbnMgZm9yIHRoZSBTUiBiYXNlZCBvbiBhIHNwZWNpZmlj IElHUChlLmcuIE9TUEYpLCBpdCBzaG91bGQgbG9vayB1cCBpbiB0aGUgUklCL0ZJQiB0byBkZXRl cm1pbmUgaWYgdGhlIGxhYmVsIGJpbmRpbmcgaXMgdXA/IElmIHNvLCB0aGVyZSB3aWxsIGJlIHRo ZSB0d28gcm91dGUgZGVwZW5kZW5jeSBjaGFuZ2UgaXNzdWVzIEkgcHJvcG9zZWQgZm9yIHRoZSBP U1BGLiBXaHkgZG8geW91IHRoaW5rIHRoZXkgYXJlIG5vdCBhcHBsaWNhYmxlIHRvIFNSPw0KDQoN CkFsc28gbm90ZSB0aGF0IGxpa2UgaW4gbW9zdCBMRFAgY2FzZSBTUiAibGFiZWxzIiBvciAiSURz IiBhcmUgZ2xvYmFsIHNvIHJlZ2FyZGxlc3Mgb24gd2hpY2ggaW50ZXJmYWNlIHBhY2tldCBhcnJp dmVzICh3aXRoaW4gZ2l2ZW4gdG9wb2xvZ3kgaW4gY2FzZSBvZiBtdCkgdGhlIGxvb2t1cCByZXN1 bHQgd2lsbCBiZSBpZGVudGljYWwuDQoNClJncywNClIuDQoNCg0KT24gVGh1LCBKYW4gMjIsIDIw MTUgYXQgNjowNyBBTSwgTGl6aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNvbTxtYWlsdG86bGl6 aGVuYmluQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCBy b3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgZm91cnRoIGNvbW1lbnRzLg0KDQoNCg0KRm9yIExE UCwgd2hlbiBzZWFyY2ggcm91dGUgZm9yIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIHdoaWNoIGlz IHRoZSBGRUMgb2YgdGhlIGxhYmVsIG1hcHBpbmcsIGl0IHNob3VsZCBzZWFyY2gNCnRoZSBGSUIg aW4gd2hpY2ggdGhlIHJvdXRlcyBhcmUgc2VsZWN0ZWQgZnJvbSB0aGUgc3RhdGljIHJvdXRlLCBP U1BGLCBJU0lTLCBCR1AsIGV0YyBiYXNlZCBvbiB0aGUgcHJlZmVyZW5jZXMuDQpOb3cgdGhlcmUg aXMgb25lIHF1ZXN0aW9uIGZvciBTUi1CRSBwYXRoLCBmb3IgZXhhbXBsZSwgaWYgdGhlIFNJRC9M YWJlbCBpcyBhZHZlcnRpc2VkIHRocm91Z2ggT1NQRiwgd2hhdCB0eXBlDQoNCm9mIHJvdXRlcyBz aG91bGQgdGhlIGxhYmVsIG1hcHBpbmcgZGVwZW5kIG9uIHdoZW4gc2V0dXAgdGhlIFNSLUJFIHBh dGg/DQoNCg0KDQpJIHRoaW5rIHRoZXJlIG1heSBiZSB0d28gY2hvaWNlczoNCjEuIE9ubHkgZGVw ZW5kIG9uIHRoZSBPU1BGJ3Mgb3duIHJvdXRlOw0KMi4gTGlrZSB0aGUgTERQLCBkZXBlbmRzIG9u IHRoZSBzZWxlY3RlZCByb3V0ZS4NCg0KDQoNCkkgZG9uJ3QgdGhpbmsgaXQgc2hvdWxkIGJlIHRo ZSBPcHRpb24gMS4gRm9yIGV4YW1wbGUsIHdlIGNvbmZpZ3VyZSBzdGF0aWMgcm91dGVzIGZvciBh bGwgbm9kZXMgYWxvbmcgdGhlIHBhdGggdG8NCmEgc3BlY2lmaWMgbm9kZSB3aGljaCBjYW4gYmUg dG90YWxseSBkaWZmZXJlbnQgZnJvbSB0aGUgT1NQRiByb3V0ZXMgdG8gdGhlIG5vZGUuIElmIHRo ZSBzdGF0aWMgcm91dGUgaGFzIGhpZ2hlcg0KcHJpb3JpdHkgdGhhbiB0aGUgT1NQRiBhbmQgdGhl IFNJRC9sYWJlbCBpcyBhZHZlcnRpc2VkIGJ5IE9TUEYgZGVwZW5kcyBvbiBPU1BGIHJvdXRlcywg dGhlcmUgd2lsbCBiZSB0aGUNCg0KaW5jb25zaXN0ZW5jeSBiZXR3ZWVuIHRoZSBTUi1CRSBwYXRo IGFuZCB0aGUgcm91dGUgcGF0aC4NCg0KDQoNCklmIHRoZSBvcHRpb24gMiBpcyBhZG9wdGVkLCBp dCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0IHRoZSBsYWJlbCBtYXBwaW5nIGFuZCB0aGUgcm91dGUg YXJlIGluIHRoZSBzYW1lIExTREIgd2hpY2gNCg0KY2FuIGJlIGVhc2lseSBzeW5jaHJvbml6ZWQu IFRoZXJlIGFyZSB0d28gY2hhbGxlbmdlczoNCjEuIFRoZSBkaXJlY3QgZWZmZWN0IGZvciB0aGUg T1NQRiBpcyB0aGF0IGF0IHRoZSBiZWdpbm5pbmcgaXQganVzdCBkb3dubG9hZHMgaXQgcm91dGVz IHRvIHRoZSBSSUIgZm9yIHRoZSByb3V0ZQ0Kc2VsZWN0aW9uLiBUaGF0IGlzLCBpdCBpcyB0aGUg c291cmNlIG9mIHRoZSByb3V0ZSBzZWxlY3Rpb24uIEJ1dCBub3cgb3dpbmcgdG8gU1ItQkUgcGF0 aCwgaXQgaGFzIHRvIGRlcGVuZCBvbg0KDQp0aGUgcmVzdWx0IG9mIHRoZSByb3V0ZSBzZWxlY3Rp b24uDQoyLiBPU1BGIFNSLUJFIHBhdGggbWF5IGRlcGVuZCBvbiB0aGUgcm91dGVzIGZyb20gdGhl IHN0YXRpYyByb3V0ZSwgSVNJUywgQkdQLCBldGMuIEl0IGlzIGNsYWltZWQgdGhhdCB0aGUgU1Ig Y2FuDQpyZW1vdmUgdGhlIElHUC1MRFAgc3luYy4gQnV0IGFjY29yZGluZyB0byB0aGlzIGFuYWx5 c2lzLCBhcmUgdGhlcmUgdGhlIHBvc3NpYmxlIHJpc2sgd2UgaGF2ZSB0byBpbnRyb2R1Y2UgdGhl DQoNCk9TUEYtSVNJUyBzeW5jLCBPU1BGLVN0YXRpYyBSb3V0ZSBzeW5jLCBPU1BGLUJHUCBzeW5j PyBPciBkbyB5b3UganVzdCB0aGluayB0aGV5IGFyZSByYXJlIGNhc2VzIHdoaWNoIHNob3VsZCBu b3QNCg0KIGJlIHRha2VuIGludG8gYWNjb3VudD8gSG9wZSB5b3UgaGF2ZSBoYWQgZW5vdWdoIGFu YWx5c2lzIG9uIHRoaXMgaXNzdWUuDQoNCg0KDQpBY2NvcmRpbmcgdG8gdGhlIGNvbW1lbnRzIG9u IHRoZSBkZXBlbmRlbmN5LCBJIGhvcGUgeW91IGNvdWxkIHNwZWNpZnkgY2xlYXJseSBpbiB0aGUg YXBwcm9wcmlhdGUgZHJhZnQgb2Ygc2VnbWVudA0KDQpyb3V0aW5nIGFzIHRvIGZvbGxvd3MgcXVl c3Rpb25zIGZvciBTUi1CRSBwYXRoIHdoaWNoIGlzIGhlbHBmdWwgZm9yIGludGVyb3BlcmFiaWxp dHk6DQotLSBkZXBlbmQgb24gdGhlIGxvbmdlc3QgbWF0Y2gsIG9yIGV4YWN0IG1hdGNoLCBvciBi b3RoLg0KLS0gZGVwbmVkIG9uIHRoZSBTUiBwcm90b2NvbCdzIG93biByb3V0ZXMgb3IgdGhlIHJv dXRlIHNlbGVjdGlvbiByZXN1bHRlIGZyb20gbXVsdGlwbGUgc291cmNlcy4NCg0KDQoNCg0KDQoN Cg0KUmVnYXJkcywNClJvYmluDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwcmluZw0KDQoNCg0K --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477281AEnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Robert,

I give you an example. The topology is as follows and all nodes support = SR.

 

A  ---  B  ---  C  ---- D

 

If SID/label is configured on D and the SID/label binding for the node D= are flooded to A/B/C through OSPF, could you tell me how the SR-BE path to= the node D is set up and the label fowarding entry is created on A, B, C?<= /p>

 

Regards,

Robin

 

 

 

 

=B7=A2=BC=FE=C8=CB: rraszuk@gmail.com [rras= zuk@gmail.com] =B4=FA=B1=ED Robert Raszuk [robert@raszuk.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C222=C8=D5 19:14
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: spring@ietf.org; mpls@ietf.org
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: [spring] New Comments on Segment Rou= ting(4): Challenge of Route Dependency for SR-BE Path

Robin,

Label binding being up or active seems orthogonal to SR. If it is not activ= e/up different transport will be used between SR nodes for example GRE or U= DP etc.. What is the issue with that ?

Thx,
R.

On Thu, Jan 22, 2015 at 12:08 PM, Lizhenbin <lizhenbin@hua= wei.com> wrote:

Hi Robert,

Please refer to my inline '[Robin]'.

 

Regards,

Robin

 

= =B7=A2=BC=FE=C8=CB: rraszuk@gmail.com [rraszuk@gmail.com] =B4=FA=B1=ED Robert Raszuk [robert@raszuk.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C222=C8=D5 15:46
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: s= pring@ietf.org; mpls@ietf.org
=D6=F7=CC=E2: Re: [spring] New Comments on Segment Routing(4): Chall= enge of Route Dependency for SR-BE Path

Hi Robin,

I think your question is not applicable to SR architecture. 

The right SR analogy to LDP would *NOT* be hop by hop LDP like in your exam= ple, but targeted (aka directed) LDP session.
[Robin] I could not understand your point. No matter T-LDP or local LD= P, they should lookup in the RIB/FIB to determine if the label mapping is a= ctive.
In those how to get to FEC's address is just regular lookup in the RIB/FIB = (global or vrf depends on use case) and it does not matter what protocol sr= c installed the route. 
[Robin] As what you described, could I understand you means for the SR base= d on a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to determi= ne if the label binding is up? If so, there will be the two route dependenc= y change issues I proposed for the OSPF. Why do you think they are not applicable to SR?
 
 
Also note that like in most LDP case SR "labels" or "IDs&quo= t; are global so regardless on which interface packet arrives (within given= topology in case of mt) the lookup result will be identical.

Rgs,
R.


On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin <lizhenbin@hua= wei.com> wrote:

Hi all authors of segment routing,

 

This is the fourth comments.

 

For LDP, when search route for the destination ad= dress which is the FEC of the label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS,= BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is = advertised through OSPF, what type

of routes should th= e label mapping depend on when setup the SR-BE path?

 

I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.

 

I don't think it should be the Option 1. For exam= ple, we configure static routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the = node. If the static route has higher
priority than the OSPF and the SID/label is advertised by OSPF depends= on OSPF routes, there will be the

inconsistency between the SR-BE path and the route path.

 

If the option 2 is adopted, it cannot be assumed = that the label mapping and the route are in the same LSDB which

can be easily synchronized. There are two challen= ges:
1. The direct effect for the OSPF is that at the beginning it just download= s it routes to the RIB for the route
selection. That is, it is the source of the route selection. But now owing = to SR-BE path, it has to depend on

the result of the route selection.
2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BG= P, etc. It is claimed that the SR can
remove the IGP-LDP sync. But according to this analysis, are there the poss= ible risk we have to introduce the

OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP = sync? Or do you just think they are rare cases which should not

 be taken into account? Hope you have had en= ough analysis on this issue.

 

According to the comments on the depend= ency, I hope you could specify clearly in the appropriate draft of seg= ment

routing as to follows questions for SR-BE path wh= ich is helpful for interoperability:
-- depend on the longest match, or exact match, or both.
-- depned on the SR protocol's own routes or the route selection resulte fr= om multiple sources.

 

 

 

Regards,
Robin

 


_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring



--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477281AEnkgeml506mbxchi_-- From nobody Thu Jan 22 05:41:17 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7151A1A30; Thu, 22 Jan 2015 05:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvuJpX0F0Mkd; Thu, 22 Jan 2015 05:41:07 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9E21A1A2E; Thu, 22 Jan 2015 05:41:06 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D0EF1180131A; Thu, 22 Jan 2015 14:41:02 +0100 (CET) Message-ID: <54C0FDE9.4010905@pi.nu> Date: Thu, 22 Jan 2015 21:40:57 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Benoit Claise' , 'The IESG' References: <20150122110708.6977.8048.idtracker@ietfa.amsl.com> <045b01d03634$18705a40$49510ec0$@olddog.co.uk> In-Reply-To: <045b01d03634$18705a40$49510ec0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-in-udp-10: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 13:41:10 -0000 Folks, I agree with Adrian - would only chage if it were a very strong requirement - "take it or leave it " - doesn't to be so strong. /Loa (chair hat and shepherd cape on) On 2015-01-22 19:10, Adrian Farrel wrote: > I'd be happy to change the Abstract as Benoit suggests, but I note that we have been doing a dance to keep the TSV community happy, and these words did the trick. Changing them at this late stage might be seen as going back on a promise. > > Adrian (contributing author and recused) > >> -----Original Message----- >> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Benoit Claise >> Sent: 22 January 2015 11:07 >> To: The IESG >> Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; >> mpls@ietf.org; Loa Andersson >> Subject: Benoit Claise's No Objection on draft-ietf-mpls-in-udp-10: (with >> COMMENT) >> >> Benoit Claise has entered the following ballot position for >> draft-ietf-mpls-in-udp-10: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - An editorial detail in the abstract. Take it or leave it >> The MPLS-in-UDP encapsulation technology must only be deployed within >> a >> single network (with a single network operator) or networks of an >> adjacent set of co-operating network operators where traffic is >> managed to avoid congestion, rather than over the Internet where >> congestion control is required. >> >> We rarely see specifications ("must" sentences) in abstracts. >> Do you want to say something like: >> The MPLS-in-UDP encapsulation applicability is for networks where >> traffic is managed to avoid congestion, rather than over the Internet >> >> where congestion control is required. > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jan 22 05:54:15 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FAA1ACCD8; Thu, 22 Jan 2015 05:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7C6vBQEVl9Y; Thu, 22 Jan 2015 05:54:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 345551A1A31; Thu, 22 Jan 2015 05:54:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122135410.22526.80951.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 05:54:10 -0800 Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: [mpls] Stephen Farrell's Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 13:54:11 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-mpls-in-udp-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think you're missing a little bit of spec needed for the MPLS with DTLS case. (Are there implementations of the DTLS stuff btw?) 1) I assume the intent is that the MPLS-with-DTPS port (TBD2) is only ever used with DTLS, in which case don't you need a MUST or MUST NOT somewhere? 2) Is a single listener on port TBD2 supposed to handle just one DTLS session with one LSR or many DTLS sessions with each LSR that's on a different host/port or something else? Don't you need to say? From nobody Thu Jan 22 05:58:42 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77F1AC445; Thu, 22 Jan 2015 05:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCfop6AMh5RP; Thu, 22 Jan 2015 05:58:36 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B89D1A1A24; Thu, 22 Jan 2015 05:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1240; q=dns/txt; s=iport; t=1421935117; x=1423144717; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XeRakCRKK4TzEfn24EoPql+o66IOKZmzPScKYS6VaaE=; b=g8KWYAMdy5+TPzndpe4XDnAuDKkBpDS+EYZL6GZTpCcALkIRr8xVp/jb h5+LD70NA0H0Owct+0kFGT8PKo4PPZ0DFTzmR8DPD89mxI6JH+ua0xEh3 9L7hlYNx4BLHfyVu2uoapr9U6Kdoiy+CW8ELS8FgE9vcXOpiKzQY/FgKD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusFAEkBwVStJV2T/2dsb2JhbABagmQiUlgEgwDBHIIbCoVxAhx4QwEBAQEBfYQMAQEBAwEBAQEgEToLBQcEAgEIEQQBAQECAiMDAgICJQsUAQgIAQEEDgWIJAgBDL18lFEBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhjiUzBwaCYi6BEwEEjmaJGZI1IoNub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,449,1418083200"; d="scan'208";a="389987126" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 22 Jan 2015 13:58:36 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t0MDwZvf002831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Jan 2015 13:58:35 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 07:58:35 -0600 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: [mpls] Last Call comment: Thread-Index: AdA2LZvAW8/WwMW2T5CDaUv2+mQtEwAUDG4A Date: Thu, 22 Jan 2015 13:58:34 +0000 Message-ID: <4FA813E5-FCD4-4BF1-86CB-25E413C3F67E@cisco.com> References: <044501d0362d$9f0864a0$dd192de0$@olddog.co.uk> In-Reply-To: <044501d0362d$9f0864a0$dd192de0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.52] Content-Type: text/plain; charset="utf-8" Content-ID: <1ADA8B16225332418FC0FB648AC13604@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] Last Call comment: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 13:58:39 -0000 VGhhbmtzIEFkcmlhbi4gR29vZCBwb2ludC4gVXBkYXRlZCBpbiBvdXIgd29ya2luZyBjb3B5Lg0K DQrigJQgQ2FybG9zLg0KDQo+IE9uIEphbiAyMiwgMjAxNSwgYXQgNToyNCBBTSwgQWRyaWFuIEZh cnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQo+IA0KPiBBIHNtYWxsIG5pdCB0byBp bmNsdWRlIGluIHRoZSBsYXN0IGNhbGwgY29tbWVudHMuLi4NCj4gDQo+IFNlY3Rpb24gNQ0KPiBP TEQNCj4gICAiSVB2NiBSb3V0ZXIgQWxlcnQgT3B0aW9uIFZhbHVlcyIgcmVnaXN0cnkgZGVmaW5l ZCBieSBbUkZDNTM1MF0gYW5kDQo+IE5FVw0KPiAgICJJUHY2IFJvdXRlciBBbGVydCBPcHRpb24g VmFsdWVzIiByZWdpc3RyeSBkZWZpbmVkIGJ5IFtSRkMyNzExXSBhbmQNCj4gICB1cGRhdGVkIGJ5 IFtSRkM1MzUwXSBhbmQNCj4gRU5EDQo+IA0KPiBBZHJpYW4NCj4gDQo+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogSUVURi1Bbm5vdW5jZSBbbWFpbHRvOmlldGYtYW5ub3Vu Y2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRoZQ0KPj4gSUVTRw0KPj4gU2VudDog MjEgSmFudWFyeSAyMDE1IDIzOjIzDQo+PiBUbzogSUVURi1Bbm5vdW5jZQ0KPj4gQ2M6IG1wbHNA aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1vYW0taXB2 Ni1yYW8tMDIudHh0PiAoSVB2NiBSb3V0ZXIgQWxlcnQNCj4+IE9wdGlvbiBmb3IgTVBMUyBPQU0p IHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= From nobody Thu Jan 22 06:16:03 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADFB1A1ABF; Thu, 22 Jan 2015 06:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.56 X-Spam-Level: X-Spam-Status: No, score=-8.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoCJiVSnkV8Q; Thu, 22 Jan 2015 06:15:56 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D45A1ACCC7; Thu, 22 Jan 2015 06:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17529; q=dns/txt; s=iport; t=1421936157; x=1423145757; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rC94SbQ2j4KR9yn9ReTtU+4Qi967m36WzMKJKMYcWtc=; b=cy9fACrD39bU5ba/Ck9go+oZn6n5L4jxRxbS6e5Z5FB0VS/cEHbGrfVE EsQ6fCj8mJM/aRkVHXE9Nh6rJylZiWkYnXhljSA/7EiBUEN2ixCyMhOBg 6ug01YAKsEJCFi05XjpNiClAC6+9RL355bM7SlMz1V9j0+MyM3fDrdAiK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAN8FwVStJV2R/2dsb2JhbABagkNDUlgEgwDDNwEJhSdKAhx4QwEBAQEBfYQMAQEBBAEBAWsLEAIBBgIRAQIBAhYOBAUCAh8GCxQDAwMIAgQBDQWIGAMRDaEgnGYIj28NhFUBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI1Pgg8KDQQGAQqCWoFFBY0GgWCHVYFEgRSCfogxgjWDPSKCMoE8b4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,449,1418083200"; d="scan'208,217";a="389927567" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jan 2015 14:15:48 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0MEFkWr013448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Jan 2015 14:15:46 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.144]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 08:15:46 -0600 From: "Acee Lindem (acee)" To: Lizhenbin , Robert Raszuk Thread-Topic: =?gb2312?B?W3NwcmluZ10gtPC4tDogIE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRp?= =?gb2312?B?bmcoNCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBEZXBlbmRlbmN5IGZvciBTUi1C?= =?gb2312?Q?E_Path?= Thread-Index: AQHQNjPiE4hfIaFp3kmv182Nzw+zL5zMQC0A Date: Thu, 22 Jan 2015 14:15:46 +0000 Message-ID: References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808A@nkgeml506-mbx.china.huawei.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818C@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818C@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D0E66F44C1AAaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [mpls] =?gb2312?b?W3NwcmluZ10gtPC4tDogIE5ldyBDb21tZW50cyBvbiBT?= =?gb2312?b?ZWdtZW50IFJvdXRpbmcoNCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBEZXBlbmRl?= =?gb2312?b?bmN5IGZvciBTUi1CRSBQYXRo?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 14:16:00 -0000 --_000_D0E66F44C1AAaceeciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iaW4sDQpJIGRvbqGvdCBrbm93IGFib3V0IG90aGVyIElHUCBpbXBsZW1lbnRhdGlvbnMg YnV0IHRoZSBvbmVzIEmhr3ZlIHdvcmtlZCBvbiBkbyBub3QgcmVzb2x2ZSByb3V0ZXMgcmVjdXJz aXZlbHkgKHVubGlrZSBMRFAgb3IgQkdQIHdoaWNoIGRvKS4gIFRoZXJlIGFyZSBjYXNlcyB3aGVy ZSBPU1BGIHJ1bnMgb3ZlciBhIHR1bm5lbCBidXQgaW4gdGhlc2UgY2FzZXMgdGhlIE9TUEYgaW50 ZXJmYWNlIGlzIGVpdGhlciB1cCBvciBkb3duIGRlcGVuZGVudCBvbiB0aGUgdHVubmVsIHN0YXR1 cy4gSGVuY2UsIEkgdGhpbmsgdGhlIGlzc3VlIHlvdaGvdmUgcmFpc2VkIHJlZ2FyZGluZyBwcm90 b2NvbCBzeW5jaHJvbml6YXRpb24gaXMgYSBtb290IHBvaW50Lg0KVGhhbmtzLA0KQWNlZQ0KDQpG cm9tOiBMaXpoZW5iaW4gPGxpemhlbmJpbkBodWF3ZWkuY29tPG1haWx0bzpsaXpoZW5iaW5AaHVh d2VpLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgSmFudWFyeSAyMiwgMjAxNSBhdCA2OjA4IEFNDQpU bzogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsu bmV0Pj4NCkNjOiAibXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGll dGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4sICJzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4iIDxzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+ DQpTdWJqZWN0OiBbc3ByaW5nXSC08Li0OiBOZXcgQ29tbWVudHMgb24gU2VnbWVudCBSb3V0aW5n KDQpOiBDaGFsbGVuZ2Ugb2YgUm91dGUgRGVwZW5kZW5jeSBmb3IgU1ItQkUgUGF0aA0KDQoNCkhp IFJvYmVydCwNCg0KUGxlYXNlIHJlZmVyIHRvIG15IGlubGluZSAnW1JvYmluXScuDQoNCg0KDQpS ZWdhcmRzLA0KDQpSb2Jpbg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CreivP7IyzogcnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPiBbcnJh c3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0gtPqx7SBSb2JlcnQgUmFz enVrIFtyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+XQ0Kt6LLzcqx vOQ6IDIwMTXE6jHUwjIyyNUgMTU6NDYNCsrVvP7IyzogTGl6aGVuYmluDQqzrcvNOiBzcHJpbmdA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+DQrW98ziOiBSZTogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNlZ21lbnQg Um91dGluZyg0KTogQ2hhbGxlbmdlIG9mIFJvdXRlIERlcGVuZGVuY3kgZm9yIFNSLUJFIFBhdGgN Cg0KSGkgUm9iaW4sDQoNCkkgdGhpbmsgeW91ciBxdWVzdGlvbiBpcyBub3QgYXBwbGljYWJsZSB0 byBTUiBhcmNoaXRlY3R1cmUuDQoNClRoZSByaWdodCBTUiBhbmFsb2d5IHRvIExEUCB3b3VsZCAq Tk9UKiBiZSBob3AgYnkgaG9wIExEUCBsaWtlIGluIHlvdXIgZXhhbXBsZSwgYnV0IHRhcmdldGVk IChha2EgZGlyZWN0ZWQpIExEUCBzZXNzaW9uLg0KW1JvYmluXSBJIGNvdWxkIG5vdCB1bmRlcnN0 YW5kIHlvdXIgcG9pbnQuIE5vIG1hdHRlciBULUxEUCBvciBsb2NhbCBMRFAsIHRoZXkgc2hvdWxk IGxvb2t1cCBpbiB0aGUgUklCL0ZJQiB0byBkZXRlcm1pbmUgaWYgdGhlIGxhYmVsIG1hcHBpbmcg aXMgYWN0aXZlLg0KSW4gdGhvc2UgaG93IHRvIGdldCB0byBGRUMncyBhZGRyZXNzIGlzIGp1c3Qg cmVndWxhciBsb29rdXAgaW4gdGhlIFJJQi9GSUIgKGdsb2JhbCBvciB2cmYgZGVwZW5kcyBvbiB1 c2UgY2FzZSkgYW5kIGl0IGRvZXMgbm90IG1hdHRlciB3aGF0IHByb3RvY29sIHNyYyBpbnN0YWxs ZWQgdGhlIHJvdXRlLg0KW1JvYmluXSBBcyB3aGF0IHlvdSBkZXNjcmliZWQsIGNvdWxkIEkgdW5k ZXJzdGFuZCB5b3UgbWVhbnMgZm9yIHRoZSBTUiBiYXNlZCBvbiBhIHNwZWNpZmljIElHUChlLmcu IE9TUEYpLCBpdCBzaG91bGQgbG9vayB1cCBpbiB0aGUgUklCL0ZJQiB0byBkZXRlcm1pbmUgaWYg dGhlIGxhYmVsIGJpbmRpbmcgaXMgdXA/IElmIHNvLCB0aGVyZSB3aWxsIGJlIHRoZSB0d28gcm91 dGUgZGVwZW5kZW5jeSBjaGFuZ2UgaXNzdWVzIEkgcHJvcG9zZWQgZm9yIHRoZSBPU1BGLiBXaHkg ZG8geW91IHRoaW5rIHRoZXkgYXJlIG5vdCBhcHBsaWNhYmxlIHRvIFNSPw0KDQoNCkFsc28gbm90 ZSB0aGF0IGxpa2UgaW4gbW9zdCBMRFAgY2FzZSBTUiAibGFiZWxzIiBvciAiSURzIiBhcmUgZ2xv YmFsIHNvIHJlZ2FyZGxlc3Mgb24gd2hpY2ggaW50ZXJmYWNlIHBhY2tldCBhcnJpdmVzICh3aXRo aW4gZ2l2ZW4gdG9wb2xvZ3kgaW4gY2FzZSBvZiBtdCkgdGhlIGxvb2t1cCByZXN1bHQgd2lsbCBi ZSBpZGVudGljYWwuDQoNClJncywNClIuDQoNCg0KT24gVGh1LCBKYW4gMjIsIDIwMTUgYXQgNjow NyBBTSwgTGl6aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNvbTxtYWlsdG86bGl6aGVuYmluQGh1 YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0K DQoNCg0KVGhpcyBpcyB0aGUgZm91cnRoIGNvbW1lbnRzLg0KDQoNCg0KRm9yIExEUCwgd2hlbiBz ZWFyY2ggcm91dGUgZm9yIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIHdoaWNoIGlzIHRoZSBGRUMg b2YgdGhlIGxhYmVsIG1hcHBpbmcsIGl0IHNob3VsZCBzZWFyY2gNCnRoZSBGSUIgaW4gd2hpY2gg dGhlIHJvdXRlcyBhcmUgc2VsZWN0ZWQgZnJvbSB0aGUgc3RhdGljIHJvdXRlLCBPU1BGLCBJU0lT LCBCR1AsIGV0YyBiYXNlZCBvbiB0aGUgcHJlZmVyZW5jZXMuDQpOb3cgdGhlcmUgaXMgb25lIHF1 ZXN0aW9uIGZvciBTUi1CRSBwYXRoLCBmb3IgZXhhbXBsZSwgaWYgdGhlIFNJRC9MYWJlbCBpcyBh ZHZlcnRpc2VkIHRocm91Z2ggT1NQRiwgd2hhdCB0eXBlDQoNCm9mIHJvdXRlcyBzaG91bGQgdGhl IGxhYmVsIG1hcHBpbmcgZGVwZW5kIG9uIHdoZW4gc2V0dXAgdGhlIFNSLUJFIHBhdGg/DQoNCg0K DQpJIHRoaW5rIHRoZXJlIG1heSBiZSB0d28gY2hvaWNlczoNCjEuIE9ubHkgZGVwZW5kIG9uIHRo ZSBPU1BGJ3Mgb3duIHJvdXRlOw0KMi4gTGlrZSB0aGUgTERQLCBkZXBlbmRzIG9uIHRoZSBzZWxl Y3RlZCByb3V0ZS4NCg0KDQoNCkkgZG9uJ3QgdGhpbmsgaXQgc2hvdWxkIGJlIHRoZSBPcHRpb24g MS4gRm9yIGV4YW1wbGUsIHdlIGNvbmZpZ3VyZSBzdGF0aWMgcm91dGVzIGZvciBhbGwgbm9kZXMg YWxvbmcgdGhlIHBhdGggdG8NCmEgc3BlY2lmaWMgbm9kZSB3aGljaCBjYW4gYmUgdG90YWxseSBk aWZmZXJlbnQgZnJvbSB0aGUgT1NQRiByb3V0ZXMgdG8gdGhlIG5vZGUuIElmIHRoZSBzdGF0aWMg cm91dGUgaGFzIGhpZ2hlcg0KcHJpb3JpdHkgdGhhbiB0aGUgT1NQRiBhbmQgdGhlIFNJRC9sYWJl bCBpcyBhZHZlcnRpc2VkIGJ5IE9TUEYgZGVwZW5kcyBvbiBPU1BGIHJvdXRlcywgdGhlcmUgd2ls bCBiZSB0aGUNCg0KaW5jb25zaXN0ZW5jeSBiZXR3ZWVuIHRoZSBTUi1CRSBwYXRoIGFuZCB0aGUg cm91dGUgcGF0aC4NCg0KDQoNCklmIHRoZSBvcHRpb24gMiBpcyBhZG9wdGVkLCBpdCBjYW5ub3Qg YmUgYXNzdW1lZCB0aGF0IHRoZSBsYWJlbCBtYXBwaW5nIGFuZCB0aGUgcm91dGUgYXJlIGluIHRo ZSBzYW1lIExTREIgd2hpY2gNCg0KY2FuIGJlIGVhc2lseSBzeW5jaHJvbml6ZWQuIFRoZXJlIGFy ZSB0d28gY2hhbGxlbmdlczoNCjEuIFRoZSBkaXJlY3QgZWZmZWN0IGZvciB0aGUgT1NQRiBpcyB0 aGF0IGF0IHRoZSBiZWdpbm5pbmcgaXQganVzdCBkb3dubG9hZHMgaXQgcm91dGVzIHRvIHRoZSBS SUIgZm9yIHRoZSByb3V0ZQ0Kc2VsZWN0aW9uLiBUaGF0IGlzLCBpdCBpcyB0aGUgc291cmNlIG9m IHRoZSByb3V0ZSBzZWxlY3Rpb24uIEJ1dCBub3cgb3dpbmcgdG8gU1ItQkUgcGF0aCwgaXQgaGFz IHRvIGRlcGVuZCBvbg0KDQp0aGUgcmVzdWx0IG9mIHRoZSByb3V0ZSBzZWxlY3Rpb24uDQoyLiBP U1BGIFNSLUJFIHBhdGggbWF5IGRlcGVuZCBvbiB0aGUgcm91dGVzIGZyb20gdGhlIHN0YXRpYyBy b3V0ZSwgSVNJUywgQkdQLCBldGMuIEl0IGlzIGNsYWltZWQgdGhhdCB0aGUgU1IgY2FuDQpyZW1v dmUgdGhlIElHUC1MRFAgc3luYy4gQnV0IGFjY29yZGluZyB0byB0aGlzIGFuYWx5c2lzLCBhcmUg dGhlcmUgdGhlIHBvc3NpYmxlIHJpc2sgd2UgaGF2ZSB0byBpbnRyb2R1Y2UgdGhlDQoNCk9TUEYt SVNJUyBzeW5jLCBPU1BGLVN0YXRpYyBSb3V0ZSBzeW5jLCBPU1BGLUJHUCBzeW5jPyBPciBkbyB5 b3UganVzdCB0aGluayB0aGV5IGFyZSByYXJlIGNhc2VzIHdoaWNoIHNob3VsZCBub3QNCg0KIGJl IHRha2VuIGludG8gYWNjb3VudD8gSG9wZSB5b3UgaGF2ZSBoYWQgZW5vdWdoIGFuYWx5c2lzIG9u IHRoaXMgaXNzdWUuDQoNCg0KDQpBY2NvcmRpbmcgdG8gdGhlIGNvbW1lbnRzIG9uIHRoZSBkZXBl bmRlbmN5LCBJIGhvcGUgeW91IGNvdWxkIHNwZWNpZnkgY2xlYXJseSBpbiB0aGUgYXBwcm9wcmlh dGUgZHJhZnQgb2Ygc2VnbWVudA0KDQpyb3V0aW5nIGFzIHRvIGZvbGxvd3MgcXVlc3Rpb25zIGZv ciBTUi1CRSBwYXRoIHdoaWNoIGlzIGhlbHBmdWwgZm9yIGludGVyb3BlcmFiaWxpdHk6DQotLSBk ZXBlbmQgb24gdGhlIGxvbmdlc3QgbWF0Y2gsIG9yIGV4YWN0IG1hdGNoLCBvciBib3RoLg0KLS0g ZGVwbmVkIG9uIHRoZSBTUiBwcm90b2NvbCdzIG93biByb3V0ZXMgb3IgdGhlIHJvdXRlIHNlbGVj dGlvbiByZXN1bHRlIGZyb20gbXVsdGlwbGUgc291cmNlcy4NCg0KDQoNCg0KDQoNCg0KUmVnYXJk cywNClJvYmluDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu Zw0KDQoNCg== --_000_D0E66F44C1AAaceeciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Robin, 
I don=A1=AFt know about other IGP implementations but the ones I=A1=AF= ve worked on do not resolve routes recursively (unlike LDP or BGP which do)= .  There are cases where OSPF runs over a tunnel but in these cases th= e OSPF interface is either up or down dependent on the tunnel status. Hence, I think the issue you=A1=AFve raised regardin= g protocol synchronization is a moot point. 
Thanks,
Acee 

From: Lizhenbin <lizhenbin@huawei.com>
Date: Thursday, January 22, 2015 at= 6:08 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: "mpls@ietf.org" <mpls@i= etf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: [spring] =B4=F0=B8=B4: New= Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE Pa= th

Hi Robert,

Please refer to my inline '[Robin]'.

 

Regards,

Robin

 

=B7=A2=BC=FE=C8=CB: rraszuk@gmail.com [rraszuk@gmail.com] =B4=FA=B1=ED Robert Raszuk [robert@raszuk.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C222=C8=D5 15:46
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: spring@ietf.org= ; mpls@ietf.org
=D6=F7=CC=E2: Re: [spring] New Comments on Segment Routing(4): Chall= enge of Route Dependency for SR-BE Path

Hi Robin,

I think your question is not applicable to SR architecture. 

The right SR analogy to LDP would *NOT* be hop by hop LDP like in your exam= ple, but targeted (aka directed) LDP session.
[Robin] I could not understand your point. No matter T-LDP or local LD= P, they should lookup in the RIB/FIB to determine if the label mapping is a= ctive.
In those how to get to FEC's address is just regular lookup in the RIB/FIB = (global or vrf depends on use case) and it does not matter what protocol sr= c installed the route. 
[Robin] As what you described, could I understand you means for the SR base= d on a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to determi= ne if the label binding is up? If so, there will be the two route dependenc= y change issues I proposed for the OSPF. Why do you think they are not applicable to SR?
 
 
Also note that like in most LDP case SR "labels" or "IDs&quo= t; are global so regardless on which interface packet arrives (within given= topology in case of mt) the lookup result will be identical.

Rgs,
R.


On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin <lizhenbin@hua= wei.com> wrote:

Hi all authors of segment routing,

 

This is the fourth comments.

 

For LDP, when search route for the destination ad= dress which is the FEC of the label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS,= BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is = advertised through OSPF, what type

of routes should th= e label mapping depend on when setup the SR-BE path?

 

I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.

 

I don't think it should be the Option 1. For exam= ple, we configure static routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the = node. If the static route has higher
priority than the OSPF and the SID/label is advertised by OSPF depends= on OSPF routes, there will be the

inconsistency between the SR-BE path and the route path.

 

If the option 2 is adopted, it cannot be assumed = that the label mapping and the route are in the same LSDB which

can be easily synchronized. There are two challen= ges:
1. The direct effect for the OSPF is that at the beginning it just download= s it routes to the RIB for the route
selection. That is, it is the source of the route selection. But now owing = to SR-BE path, it has to depend on

the result of the route selection.
2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BG= P, etc. It is claimed that the SR can
remove the IGP-LDP sync. But according to this analysis, are there the poss= ible risk we have to introduce the

OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP = sync? Or do you just think they are rare cases which should not

 be taken into account? Hope you have had en= ough analysis on this issue.

 

According to the comments on the depend= ency, I hope you could specify clearly in the appropriate draft of seg= ment

routing as to follows questions for SR-BE path wh= ich is helpful for interoperability:
-- depend on the longest match, or exact match, or both.
-- depned on the SR protocol's own routes or the route selection resulte fr= om multiple sources.

 

 

 

Regards,
Robin

 


_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring


 --_000_D0E66F44C1AAaceeciscocom_-- From nobody Thu Jan 22 06:57:24 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7231A1A9D for ; Thu, 22 Jan 2015 06:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ME6P2CqXAOb for ; Thu, 22 Jan 2015 06:57:20 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8751A1AA6 for ; Thu, 22 Jan 2015 06:57:20 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D8714180155B; Thu, 22 Jan 2015 15:57:16 +0100 (CET) Message-ID: <54C10FC7.2030800@pi.nu> Date: Thu, 22 Jan 2015 22:57:11 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sam Aldrin , adrian@olddog.co.uk References: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> <364122F3-AD7C-4112-8C66-14CF969E1079@gmail.com> <013f01d022af$7fe6d5c0$7fb48140$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org, mpls , "mpls-chairs@tools.ietf.org" Subject: [mpls] Are we ready to post a version soon? - Re: AD review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 14:57:22 -0000 Folks, Counter says 158 days can we post a new version soon?? /Loa On 2014-12-29 03:59, Sam Aldrin wrote: > Hi Adrian, > > I am sorry for not publishing a new version. > I will do it at the earliest. > Sorry again for the delay. > > -sam >> On Dec 28, 2014, at 7:03 AM, Adrian Farrel wrote: >> >> Hello Sam, authors, all, >> >> Did I miss some update of this document? >> It's now 133 days since I first did my review, and the changes requested were >> not huge. >> >> I know we all run out of energy towards the end of publication process, but if >> there is no-one in the WG concerned to take this the final few steps, then >> perhaps the WG doesn't need to request publication. >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>> Sent: 19 October 2014 21:31 >>> To: 'Sam Aldrin' >>> Cc: 'draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org'; 'mpls' >>> Subject: RE: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping >>> >>> Hi Sam, >>> >>>>>> Do you really need the pre-RFC5378 disclaimer? >>>> As this updates or add to RFC4379, we need that. Would you agree? >>> >>> No, not really. >>> You can included it if you believe you are reproducing text that does not have >> a >>> transfer of copyright and for which it is hard to get the authors to confirm >>> copyright transfer. But the act of updating is not, itself, a reason to >> include the >>> disclaimer. >>> >>>>>> Section 2 would be enhanced by a figure. >>> [snip] >>>> %sam - We deliberated on this and feel it will add more confusion than >> helping >>>> the reader to understand. Also, it may necessitates lot of changes to the >> text to >>>> reflect the use of R1, R2 etc. >>>> Would you be ok if we don't add this ASCII art and keep it simple? >>> >>> I won't object more than to say "I thought it would help". >>> >>>>>> It seems that proxy ping messages would be relatively easy to spoof. >>>>>> This, combined with the fact that the receipt of a proxy ping causes >>>>>> the proxy to retain state and to issue echo requests to the network >>>>>> looks like two DoS vectors for the price of one. >>>>>> >>>>>> So, I think you need: >>>>>> - discussion of authentication for proxy requests >>>>>> - recommendation to rate limit receipt of proxy requests >>>>>> - recommendation to discard "duplicate" proxy requests >>>>>> >>>> %sam - Proxy do NOT maintain any state. Hence, not sure why the above apply >>>> to proxy and not regular Echo requests. When proxy echo request is, it >>>> (proxy LSR) merely issues a request and no state is maintained on it. >>>> For ex: it has no way to discard duplicate requests, because is doesn't >> maintain >>>> any state for the requests. >>> >>> I read in 3.2 (the description of processing at a Proxy) >>> >>> The header fields Sender's Handle and Sequence Number are not >>> examined, but are saved to be included in the MPLS proxy ping reply >>> or MPLS Echo Request messages. >>> >>> Maybe that "saving" is ambiguous? Maybe this is an implementation specific >> note >>> for the message that is being built, and is not actually "state". If so, I >> think you >>> should strike "saved to be", s/messages/message/ and add "...if one is sent as >> a >>> direct result of the received message." >>> >>> Anyhow, the fact that a branch node will make copies of a ping to send >>> downstream *is* a vector. >>> >>>>>> I'm not quite sure about the initiator being allowed to instruct the >>>>>> proxy about which source port it must use in an echo request. >>>>>> >>>>>> (Incidentally, Section 3.2 doesn't restate that this has to happen >>>>>> although 3.2.4.1 does restate it). >>>>>> >>>>>> What happens if the proxy request asks for a reserved port number to be >>>>>> used? What if the port is already in use by the proxy for something >>>>>> else? Why does it matter which source port the proxy uses? Why does the >>>>>> proxy need to be able to control that? Why can't the proxy select its >>>>>> own source port? >>>> %sam - I think there is some confusion here. The source port number is not >> to >>>> request Proxy to use, rather to issue a request, so that the replying router >>>> could send the reply back to the initiator at the right port. >>>> proxy echo request does not specify what port Proxy has to use. >>> >>> Section 3.1 is about how to handle a received Proxy message >>> >>> The Reply mode and Global Flags of the Proxy Echo Parameters TLV are >>> set to the values to be used in the MPLS Echo Request message header. >>> The Source UDP Port is set to the value to be used in the MPLS Echo >>> Request packet. The TTL is set to the value to be used in the >>> outgoing MPLS label stack. See Section 5.1 for further details. >>> >>> 3.2.4.1 is describing how to build an echo request from a proxy request. >>> >>> The message is then encapsulated in a UDP packet. The source UDP >>> port is copied from the Proxy Echo Parameters TLV. The destination >>> port copied from the proxy ping request message. >>> >>> And to be clear section 5.1 describes the Proxy Echo Parameters TLV >>> >>> The Proxy Echo Parameters TLV is a TLV that MUST be included in an >>> MPLS proxy ping request message. >>> >>> I didn't go back and search the rest of the document. >>> >>> If you do not intend that the proxy message can control the ports used in the >>> echo request, I think you have some text to fix. But surely this text is clear >> and >>> reflects the intention of the WG, in which case my questions hold. >>> >>> Cheers, >>> Adrian >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jan 22 08:23:01 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CABB1ACD1A; Thu, 22 Jan 2015 08:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFG6kSLv7QJi; Thu, 22 Jan 2015 08:22:51 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4041A1B05; Thu, 22 Jan 2015 08:22:51 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 20so1070516yks.7; Thu, 22 Jan 2015 08:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jW/DW03ZbOb4kLZJkSiYCerrUqH3s4TwjM8F+pGserY=; b=TqdXNWmlwaQR8VxLzAWPpggl7mPmXfPAbj9oCqab+MNRgMMQ9Qx7iV8LRSCyVFISnG BjNSwKFDuroUw4sw+mIopCSpu310o0ypOaV0WURLXGk10TlOxOROab3BFEAq4w4z7qLo CmYXS+Ifm70pTFkrirMhjh2iz67NZk/8M+fp5YHYujaO1JTIWo0UGgUzOgioX53c+dJT siL2Iy+Hbv/SWu29dTib1PYN2WxlNrT71S1zSedDZPhx7qiFi3MJZ2WWqxrKKCy1C2bH TlBq8RMoY98CSJN6arSvR/fAQ7pTXblmmn/9DtrXAV666nrFqdqq5CgMSB23T5CPS4rA YnZw== MIME-Version: 1.0 X-Received: by 10.170.119.7 with SMTP id l7mr1447280ykb.51.1421943770515; Thu, 22 Jan 2015 08:22:50 -0800 (PST) Received: by 10.170.133.18 with HTTP; Thu, 22 Jan 2015 08:22:50 -0800 (PST) In-Reply-To: <20150122135410.22526.80951.idtracker@ietfa.amsl.com> References: <20150122135410.22526.80951.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 11:22:50 -0500 Message-ID: From: Alia Atlas To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1137a79e5510ea050d401521 Archived-At: Cc: "draft-ietf-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , The IESG , "mpls@ietf.org" Subject: Re: [mpls] Stephen Farrell's Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 16:22:53 -0000 --001a1137a79e5510ea050d401521 Content-Type: text/plain; charset=UTF-8 Hi Stephen, On Thu, Jan 22, 2015 at 8:54 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-mpls-in-udp-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I think you're missing a little bit of spec needed for the > MPLS with DTLS case. (Are there implementations of the DTLS > stuff btw?) > > 1) I assume the intent is that the MPLS-with-DTPS port > (TBD2) is only ever used with DTLS, in which case don't you > need a MUST or MUST NOT somewhere? > Good point and yes, I think so. > 2) Is a single listener on port TBD2 supposed to handle just > one DTLS session with one LSR or many DTLS sessions with > each LSR that's on a different host/port or something else? > Don't you need to say? > I'd say one DTLS session per LSR sender - distinguished by a different host. The authors will have to comment and update the draft. Thanks, Alia --001a1137a79e5510ea050d401521 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

On Thu, Jan 22, 2015 at 8:54 AM, Stephen Farrell <steph= en.farrell@cs.tcd.ie> wrote:
http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


I think you're missing a little bit of spec needed for the
MPLS with DTLS case. (Are there implementations of the DTLS
stuff btw?)

1) I assume the intent is that the MPLS-with-DTPS port
(TBD2) is only ever used with DTLS, in which case don't you
need a MUST or MUST NOT somewhere?

Good= point and yes, I think so.=C2=A0
=C2=A0
2) Is a single listener on port TBD2 supposed to handle just
one DTLS session with one LSR or many DTLS sessions with
each LSR that's on a different host/port or something else?
Don't you need to say?

I'd say one DTLS session per LSR sender - distinguished b= y a different
host. =C2=A0 The authors will= have to comment and update the draft.

=
Thanks,
Al= ia
--001a1137a79e5510ea050d401521-- From nobody Thu Jan 22 08:41:36 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E26F1A1AD3; Thu, 22 Jan 2015 08:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1GQiWKzUvWm; Thu, 22 Jan 2015 08:41:30 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC63F1A1A11; Thu, 22 Jan 2015 08:41:28 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id y19so2766848wgg.11; Thu, 22 Jan 2015 08:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0qYe9B6g42ZVdwoa25BYVY0P4G4SI2oyGm/7eqc8n90=; b=F7L5ynLGuKuMDA+iW4MdnF82AOUkkjvFTkQamTckkKvXbFt+MYdsLf0pTPKHJrUMiU HNvblhQ/xnrlD/sROx/xzdn+vMXrqTiXXKqP80dnB+/2u9Y9l1X9vWqOHGceNkxs9TnB 5Wz5kCTxoKBiRBl7r/dyWkhh+zyPyT6CGusLmqhoEtjbdZaYZVwqOI2OMgTfuLdo0cC7 CptQ3qrxoFa5ZCYRVFu3m0Y7sP0LRTH34TKXsqjDgXzvowNfYcZrh362NbZfKa1lm9eD nULsh9Az/LFlr+6mW4GQtTVtFoLDtCO10tx/m/3fYGRn3N0nadCKzpAu452A/pGT4zTg TRGA== X-Received: by 10.194.236.1 with SMTP id uq1mr5029797wjc.28.1421944887652; Thu, 22 Jan 2015 08:41:27 -0800 (PST) Received: from Martins-MBP-4.fritz.box ([2001:1a80:2807:8400:d1:e6c6:db1a:ade8]) by mx.google.com with ESMTPSA id l6sm4624667wjx.33.2015.01.22.08.41.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2015 08:41:26 -0800 (PST) Message-ID: <54C12835.9090000@gmail.com> Date: Thu, 22 Jan 2015 17:41:25 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'The IESG' References: <022f01d035a2$a5f07e00$f1d17a00$@olddog.co.uk> In-Reply-To: <022f01d035a2$a5f07e00$f1d17a00$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 16:41:31 -0000 Adrian, We are on-track :) I will clear when there is text. Martin Am 21.01.15 um 18:49 schrieb Adrian Farrel: > Hi Martin, > > Speaking as a contributor to this I-D and recused... > > I think you have a valid point, but the details are a bit wrong. > >> The UDP source port is randomly chosen and I guess not further retained >> (*) for receiving incoming MPLS-over-UDP packets. In turn this means that >> "returning" packets are sent to the MPLS/UDP port number. >> >> (*) nobody is listening on that UDP port. > > I think this is no different from when the port is assigned through entropy. That is, a source port is assigned for use on the outward flow with no assumption that returning packets will use the same port number as the destination port. Indeed, the destination port is always "MPLS" on traffic flowing in both directions. > > This might require "knowledge" to be configured into a firewall if it finds itself in the path. > >> This will cause issues when NATs/firewalls are in-between, as the return >> traffic, i.e., the traffic incoming from the public part of the NAT, is >> not matching any NAT binding that was created before by an outgoing >> packet. Similar for firewalls as no state was created when the packet >> traversed the firewall. >> >> NATs are probably not a big issue in a carrier net, but firewalls will >> for sure. I guess this should be mentioned as an operational note. > > If you think a warning should be added, that is pretty simple to do (and possibly gels with the warning about zero checksum). > > (Is the addition of such a warning a Discuss? Who cares! We can add the note whatever :-) > > Adrian > > From nobody Thu Jan 22 10:19:02 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C571ACF04 for ; Thu, 22 Jan 2015 10:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP14BlK-PJxP; Thu, 22 Jan 2015 10:18:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCDC1ACEDD; Thu, 22 Jan 2015 10:18:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, "Loa Andersson" , mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122181844.11811.94302.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 10:18:44 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 18:19:00 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ From nobody Thu Jan 22 18:17:33 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E511A00CD; Thu, 22 Jan 2015 18:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ1l1QiWP-yH; Thu, 22 Jan 2015 18:17:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8903F1A00BE; Thu, 22 Jan 2015 18:17:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOI36055; Fri, 23 Jan 2015 02:17:27 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 02:17:26 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 10:17:20 +0800 From: Xuxiaohu To: "sfc@ietf.org" , "mpls@ietf.org" Thread-Topic: How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSeg== Date: Fri, 23 Jan 2015 02:17:20 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 02:17:30 -0000 Hi all, It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): The service header is independent of the encapsulation used and is encapsulated in existing transports. The presence of NSH is indicated via protocol type or other indicator in the outer encapsulation. In the case where the outer encapsulation is an MPLS LSP, how to indicate t= he presence of NSH since the MPLS encapsulation has no explicit protocol id= entifier field to indicate the protocol type of the MPLS payload? Should we= make each SFF to allocate a unique label for indicating the presence of NS= H? Or should we use the control word to indicate it? Or should we reconside= r the possibility of adding an explicit protocol identifier field to the MP= LS encapsulation so as to solve such kind of issues once and for all? Best regards, Xiaohu From nobody Fri Jan 23 02:28:23 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A721A066C; Fri, 23 Jan 2015 02:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDPtkIlldHA1; Fri, 23 Jan 2015 02:28:13 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C401A049C; Fri, 23 Jan 2015 02:28:13 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so1758653wib.5; Fri, 23 Jan 2015 02:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=TlKN9okzEMYp/eoA00hh/YfvXTbDsk1M/evJC4zvR2Y=; b=nQAgLFfkf/AuwwkF78v+/POvgJrI+waYQnai5f8ZmbSMRH4T0GHYYmDIlSbAwHWZEd c3HO/9GpmwiqyRQ3car6vZO8bNmV6s+odLxn6pj1HYIhLZtKAEE696Ao5ZG0doaXAA09 1Vj0xvWb5ocWnUVZh/0z69kwwDABBf3l9l7KVwNqyKpe0+H5tsMDfHbFUjQRwf9TFmcA tXjGJFht6h7dEyoMOxdjwdyDeYABiCLnL7BZuPjDp+vJ0Dmf8BE7eQvwKVL9Oc+fl85H c+OS4LrH8SRyLRARXX9tQFlsN/QBVE3T26bKpl5QFr+ybyfImvUk1F3RDWaeiJtP8Se+ qb9Q== X-Received: by 10.180.38.66 with SMTP id e2mr2169317wik.55.1422008892143; Fri, 23 Jan 2015 02:28:12 -0800 (PST) Received: from McObelix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id u13sm1600259wjr.26.2015.01.23.02.28.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jan 2015 02:28:11 -0800 (PST) Message-ID: <54C2223A.3080605@gmail.com> Date: Fri, 23 Jan 2015 11:28:10 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Xuxiaohu , "sfc@ietf.org" , "mpls@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 10:28:18 -0000 Xuxiaohu æ‚¨å¥½ï¼ Please correct me if I am wrong: It has always been my understanding that the MPLS header/label was independent of the protocol/payload. So no indication of the actual payload content was necessary. IMHO you could use the alert label 1 to indicate to the LSR that it has to further examine the content of a packet. Regards, Huub. ======== > It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): > > The service header is independent of the encapsulation used and is > encapsulated in existing transports. The presence of NSH is > indicated via protocol type or other indicator in the outer > encapsulation. > > In the case where the outer encapsulation is an MPLS LSP, how to indicate the presence of NSH since the MPLS encapsulation has no explicit protocol identifier field to indicate the protocol type of the MPLS payload? Should we make each SFF to allocate a unique label for indicating the presence of NSH? Or should we use the control word to indicate it? Or should we reconsider the possibility of adding an explicit protocol identifier field to the MPLS encapsulation so as to solve such kind of issues once and for all? > > Best regards, > Xiaohu > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From nobody Fri Jan 23 18:24:30 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572F71A00CF for ; Fri, 23 Jan 2015 18:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMz7QQ65yMVB for ; Fri, 23 Jan 2015 18:24:27 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5AD1A003B for ; Fri, 23 Jan 2015 18:24:26 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id m14so554993wev.11 for ; Fri, 23 Jan 2015 18:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BP/HGd6VH/TiNvYC9KAkOES7sdmU2p8h8+T4DyqkQCI=; b=mBZAl31CHW7rezlakxUF5cb7gwhzI8MTJc/293yKl/IEUy+gK62UMrk+UvkQ82HHCq 6BE4/k1itbx5QhKybMm+1AXjq1p8HnpbxIgrV1rJfmV/NGHDdkU+vxEuhFNcCCkuciBA YJUeWGDiCpfA7Q8qnqZ451sYMS8KP+wOVdW1/FiOgjnYxr53QVM67Ri/NoblYcbZk6F6 QGkaxc3E3BV1gcXS3a8OhCZvIKhUgW4z65tY2GLeIj9kKkwxuEzgrXWR/NkO+hRz91gs hkeIo3i5uvytMZRhRmg1Q0ILshjLSt56sKaqmyb7qClUVS2EP4EX/qpJHIR1YBEgwJtY NCmA== X-Received: by 10.180.36.77 with SMTP id o13mr9414691wij.74.1422066265467; Fri, 23 Jan 2015 18:24:25 -0800 (PST) Received: from [10.234.209.38] ([94.205.252.246]) by mx.google.com with ESMTPSA id u7sm4066025wiy.18.2015.01.23.18.24.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 18:24:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sam Aldrin X-Mailer: iPhone Mail (12B440) In-Reply-To: <54C10FC7.2030800@pi.nu> Date: Sat, 24 Jan 2015 06:24:22 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> <364122F3-AD7C-4112-8C66-14CF969E1079@gmail.com> <013f01d022af$7fe6d5c0$7fb48140$@olddog.co.uk> <54C10FC7.2030800@pi.nu> To: Loa Andersson Archived-At: Cc: "draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , mpls Subject: Re: [mpls] Are we ready to post a version soon? - Re: AD review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 02:24:29 -0000 Hi Loa, I am on a business trip for the past 2+ weeks. I plan to post an updated ver= sion in the coming week. Thanks for your understanding. Cheers Sam Sent from my iPhone > On Jan 22, 2015, at 6:57 PM, Loa Andersson wrote: >=20 > Folks, >=20 > Counter says 158 days can we post a new version soon?? >=20 > /Loa >=20 >> On 2014-12-29 03:59, Sam Aldrin wrote: >> Hi Adrian, >>=20 >> I am sorry for not publishing a new version. >> I will do it at the earliest. >> Sorry again for the delay. >>=20 >> -sam >>> On Dec 28, 2014, at 7:03 AM, Adrian Farrel wrote: >>>=20 >>> Hello Sam, authors, all, >>>=20 >>> Did I miss some update of this document? >>> It's now 133 days since I first did my review, and the changes requested= were >>> not huge. >>>=20 >>> I know we all run out of energy towards the end of publication process, b= ut if >>> there is no-one in the WG concerned to take this the final few steps, th= en >>> perhaps the WG doesn't need to request publication. >>>=20 >>> Thanks, >>> Adrian >>>=20 >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: 19 October 2014 21:31 >>>> To: 'Sam Aldrin' >>>> Cc: 'draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org'; 'mpls' >>>> Subject: RE: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping >>>>=20 >>>> Hi Sam, >>>>=20 >>>>>>> Do you really need the pre-RFC5378 disclaimer? >>>>> As this updates or add to RFC4379, we need that. Would you agree? >>>>=20 >>>> No, not really. >>>> You can included it if you believe you are reproducing text that does n= ot have >>> a >>>> transfer of copyright and for which it is hard to get the authors to co= nfirm >>>> copyright transfer. But the act of updating is not, itself, a reason to= >>> include the >>>> disclaimer. >>>>=20 >>>>>>> Section 2 would be enhanced by a figure. >>>> [snip] >>>>> %sam - We deliberated on this and feel it will add more confusion than= >>> helping >>>>> the reader to understand. Also, it may necessitates lot of changes to t= he >>> text to >>>>> reflect the use of R1, R2 etc. >>>>> Would you be ok if we don't add this ASCII art and keep it simple? >>>>=20 >>>> I won't object more than to say "I thought it would help". >>>>=20 >>>>>>> It seems that proxy ping messages would be relatively easy to spoof.= >>>>>>> This, combined with the fact that the receipt of a proxy ping causes= >>>>>>> the proxy to retain state and to issue echo requests to the network >>>>>>> looks like two DoS vectors for the price of one. >>>>>>>=20 >>>>>>> So, I think you need: >>>>>>> - discussion of authentication for proxy requests >>>>>>> - recommendation to rate limit receipt of proxy requests >>>>>>> - recommendation to discard "duplicate" proxy requests >>>>> %sam - Proxy do NOT maintain any state. Hence, not sure why the above a= pply >>>>> to proxy and not regular Echo requests. When proxy echo request is, it= >>>>> (proxy LSR) merely issues a request and no state is maintained on it. >>>>> For ex: it has no way to discard duplicate requests, because is doesn'= t >>> maintain >>>>> any state for the requests. >>>>=20 >>>> I read in 3.2 (the description of processing at a Proxy) >>>>=20 >>>> The header fields Sender's Handle and Sequence Number are not >>>> examined, but are saved to be included in the MPLS proxy ping reply >>>> or MPLS Echo Request messages. >>>>=20 >>>> Maybe that "saving" is ambiguous? Maybe this is an implementation speci= fic >>> note >>>> for the message that is being built, and is not actually "state". If so= , I >>> think you >>>> should strike "saved to be", s/messages/message/ and add "...if one is s= ent as >>> a >>>> direct result of the received message." >>>>=20 >>>> Anyhow, the fact that a branch node will make copies of a ping to send >>>> downstream *is* a vector. >>>>=20 >>>>>>> I'm not quite sure about the initiator being allowed to instruct the= >>>>>>> proxy about which source port it must use in an echo request. >>>>>>>=20 >>>>>>> (Incidentally, Section 3.2 doesn't restate that this has to happen >>>>>>> although 3.2.4.1 does restate it). >>>>>>>=20 >>>>>>> What happens if the proxy request asks for a reserved port number to= be >>>>>>> used? What if the port is already in use by the proxy for something >>>>>>> else? Why does it matter which source port the proxy uses? Why does t= he >>>>>>> proxy need to be able to control that? Why can't the proxy select it= s >>>>>>> own source port? >>>>> %sam - I think there is some confusion here. The source port number is= not >>> to >>>>> request Proxy to use, rather to issue a request, so that the replying r= outer >>>>> could send the reply back to the initiator at the right port. >>>>> proxy echo request does not specify what port Proxy has to use. >>>>=20 >>>> Section 3.1 is about how to handle a received Proxy message >>>>=20 >>>> The Reply mode and Global Flags of the Proxy Echo Parameters TLV are >>>> set to the values to be used in the MPLS Echo Request message header.= >>>> The Source UDP Port is set to the value to be used in the MPLS Echo >>>> Request packet. The TTL is set to the value to be used in the >>>> outgoing MPLS label stack. See Section 5.1 for further details. >>>>=20 >>>> 3.2.4.1 is describing how to build an echo request from a proxy request= . >>>>=20 >>>> The message is then encapsulated in a UDP packet. The source UDP >>>> port is copied from the Proxy Echo Parameters TLV. The destination >>>> port copied from the proxy ping request message. >>>>=20 >>>> And to be clear section 5.1 describes the Proxy Echo Parameters TLV >>>>=20 >>>> The Proxy Echo Parameters TLV is a TLV that MUST be included in an >>>> MPLS proxy ping request message. >>>>=20 >>>> I didn't go back and search the rest of the document. >>>>=20 >>>> If you do not intend that the proxy message can control the ports used i= n the >>>> echo request, I think you have some text to fix. But surely this text i= s clear >>> and >>>> reflects the intention of the WG, in which case my questions hold. >>>>=20 >>>> Cheers, >>>> Adrian >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Jan 25 19:05:24 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FF31A1BC3; Sun, 25 Jan 2015 19:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wraqs3Tpdci; Sun, 25 Jan 2015 19:05:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35A01A1BCF; Sun, 25 Jan 2015 19:05:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRS61099; Mon, 26 Jan 2015 03:05:14 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 03:05:13 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 26 Jan 2015 11:05:06 +0800 From: Xuxiaohu To: "huubatwork@gmail.com" , "sfc@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfA= Date: Mon, 26 Jan 2015 03:05:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com> In-Reply-To: <54C2223A.3080605@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 03:05:19 -0000 SGkgSHV1YiwNCg0KVGhlIGFsdGVyIGxhYmVsIGl0c2VsZiBjb3VsZG7igJl0IG1ha2UgdGhlIHJl Y2VpdmluZyBMU1IgdG8gZGV0ZXJtaW5lIHRoZSBNUExTIHBheWxvYWQgdHlwZSBieSBleGFtaW5p bmcgdGhlIE1QTFMgcGF5bG9hZC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSHV1YiB2YW4gSGVsdm9vcnQgW21haWx0bzpo dXViYXR3b3JrQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDIzLCAyMDE1IDY6 MjggUE0NCj4gVG86IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBh biBNUExTIHBhY2tldD8NCj4gDQo+IFh1eGlhb2h1IOaCqOWlve+8gQ0KPiANCj4gUGxlYXNlIGNv cnJlY3QgbWUgaWYgSSBhbSB3cm9uZzoNCj4gDQo+IEl0IGhhcyBhbHdheXMgYmVlbiBteSB1bmRl cnN0YW5kaW5nIHRoYXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcw0KPiBpbmRlcGVuZGVudCBv ZiB0aGUgcHJvdG9jb2wvcGF5bG9hZC4NCj4gU28gbm8gaW5kaWNhdGlvbiBvZiB0aGUgYWN0dWFs IHBheWxvYWQgY29udGVudCB3YXMgbmVjZXNzYXJ5Lg0KPiANCj4gSU1ITyB5b3UgY291bGQgdXNl IHRoZSBhbGVydCBsYWJlbCAxIHRvIGluZGljYXRlIHRvIHRoZSBMU1IgdGhhdCBpdCBoYXMgdG8g ZnVydGhlcg0KPiBleGFtaW5lIHRoZSBjb250ZW50IG9mIGEgcGFja2V0Lg0KPiANCj4gUmVnYXJk cywgSHV1Yi4NCj4gDQo+ID09PT09PT09DQo+IA0KPiA+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1zZmMtbnNoLTA0KToNCj4gPg0KPiA+ICAgICBU aGUgc2VydmljZSBoZWFkZXIgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIGVuY2Fwc3VsYXRpb24gdXNl ZCBhbmQgaXMNCj4gPiAgICAgZW5jYXBzdWxhdGVkIGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBU aGUgcHJlc2VuY2Ugb2YgTlNIIGlzDQo+ID4gICAgIGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlw ZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQo+ID4gICAgIGVuY2Fwc3VsYXRpb24u DQo+ID4NCj4gPiBJbiB0aGUgY2FzZSB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBh biBNUExTIExTUCwgaG93IHRvIGluZGljYXRlIHRoZQ0KPiBwcmVzZW5jZSBvZiBOU0ggc2luY2Ug dGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBoYXMgbm8gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRpZmll cg0KPiBmaWVsZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUgTVBMUyBwYXls b2FkPyBTaG91bGQgd2UgbWFrZSBlYWNoDQo+IFNGRiB0byBhbGxvY2F0ZSBhIHVuaXF1ZSBsYWJl bCBmb3IgaW5kaWNhdGluZyB0aGUgcHJlc2VuY2Ugb2YgTlNIPyBPciBzaG91bGQgd2UNCj4gdXNl IHRoZSBjb250cm9sIHdvcmQgdG8gaW5kaWNhdGUgaXQ/IE9yIHNob3VsZCB3ZSByZWNvbnNpZGVy IHRoZSBwb3NzaWJpbGl0eSBvZg0KPiBhZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRp ZmllciBmaWVsZCB0byB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHNvIGFzIHRvDQo+IHNvbHZlIHN1 Y2gga2luZCBvZiBpc3N1ZXMgb25jZSBhbmQgZm9yIGFsbD8NCj4gPg0KPiA+IEJlc3QgcmVnYXJk cywNCj4gPiBYaWFvaHUNCj4gPg0KPiANCj4gDQo+IC0tDQo+ICoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gKioqKg0KPiAgICAg ICAgICAgICAgICDor7forrDkvY/vvIzkvaDmmK/ni6zkuIDml6DkuoznmoTvvIzlsLHlg4/lhbbk u5bmr4/kuIDkuKrkurrkuIDmoLcNCg== From nobody Sun Jan 25 22:34:31 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62031A1EFF; Sun, 25 Jan 2015 22:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.491 X-Spam-Level: *** X-Spam-Status: No, score=3.491 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 874g-nPuy0NF; Sun, 25 Jan 2015 22:34:26 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232B61A1BD7; Sun, 25 Jan 2015 22:34:26 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0809.eurprd03.prod.outlook.com (25.161.55.141) with Microsoft SMTP Server (TLS) id 15.1.59.20; Mon, 26 Jan 2015 06:21:33 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Mon, 26 Jan 2015 06:21:32 +0000 From: Alexander Vainshtein To: Xuxiaohu , "huubatwork@gmail.com" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6Fg== Date: Mon, 26 Jan 2015 06:21:32 +0000 Message-ID: <1422253291241.41262@ecitele.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.206] authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0809; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0809; x-forefront-prvs: 0468FE4A2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(46102003)(76176999)(40100003)(62966003)(2501002)(77156002)(2950100001)(2900100001)(50986999)(92566002)(87936001)(122556002)(86362001)(2656002)(117636001)(102836002)(19580405001)(19580395003)(54356999)(36756003)(66066001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0809; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2015 06:21:32.4767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0809 Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 06:34:28 -0000 WGlhb2h1LCBIdXViLApJIGRvIG5vdCBmb2xsb3cgdGhlIFNGQyB3b3JrIGNsb3NlbHksIHNvIEkg d291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHdoZXRoZXIgdGhlIE5TSCBzaG91bGQgYmUgY2FwdHVy ZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0gb3IganVzdCBieSB0aGUgTEVSIGFjdGlu ZyBhcyB0aGUgTFNQIHRhaWwtZW5kPwoKSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2lt cGxlc3Qgd2F5IHRvIGluZGljYXRlIHByZXNlbmNlIG9mIHRoZSBOU0ggaW4gdGhlIE1QTFMgcGF5 bG9hZCB3b3VsZCBiZSBieSBhbGxvY2F0aW5nIGFuICJhcHBsaWNhdGlvbiBsYWJlbCIgaW5kaWNh dGluZyBpdHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0 IGF0IHRoZSBib3R0b20gb2YgdGhlIGxhYmVsIHN0YWNrIGJ5IHRoZSBoZWFkLWVuZCBMRVIgLSBz aW1pbGFyIHRvIHdoYXQgaXMgZG9uZSBmb3IgTDIvTDNWUE4uICBXaXRoaW4gdGhpcyBhcHByb2Fj aCwgaWYgbGFiZWwtYmFzZWQgZGVtdWx0aXBsZXhpbmcgb2YgIHBhY2tldHMgd2l0aCBOU0ggaW4g dGhlIE1QTFMgcGF5bG9hZCBpcyBub3QgcmVxdWlyZWQsIHlvdSBjb3VsZCByZXF1ZXN0IGFsbG9j YXRpb24gb2YgYSBuZXcgc3BlY2lhbCBwdXJwb3NlIGxhYmVsIGZyb20gdGhlIGV4dGVuZGVkIHNw ZWNpYWwgcHVycG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJGQyA3Mjc0LCBhbmQgdG8gaW5zZXJ0 IHN1Y2ggYSBsYWJlbCAocHJlY2VkZWQgYnkgdGhlIEV4dGVuc2lvbiBMYWJlbCApIGF0IHRoZSBC b1MuCgpJZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRoZSBwcm9jZXNzIGFib3ZlIHN0aWxsIGhh cyB0byBiZSB1c2VkIGJ1dCBpdCBoYXMgdG8gYmUgYXVnbWVudGVkIGJ5IGFkZGluZyB0aGUgUm91 dGVyIEFsZXJ0IExhYmVsICAgYXQgdGhlIHRvcCBvZiB0aGUgbGFiZWwgc3RhY2suCgpGcm9tIG15 IFBPViB0aGVzZSBzdWdnZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRoZSBwcm92aXNpb25zIG9m IFNlY3Rpb24gMi4yIG9mIFJGQyAzMDMyICJEZXRlcm1pbmluZyB0aGUgTmV0d29yayBMYXllciBQ cm90b2NvbCIgdGhhdCBzdGF0ZXM6Cgo8cXVvdGU+CiAgIFdoZW4gdGhlIGxhc3QgbGFiZWwgaXMg cG9wcGVkIGZyb20gYSBwYWNrZXQncyBsYWJlbCBzdGFjayAocmVzdWx0aW5nCiAgIGluIHRoZSBz dGFjayBiZWluZyBlbXB0aWVkKSwgZnVydGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQgaXMK ICAgYmFzZWQgb24gdGhlIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgaGVhZGVyLiAgVGhlIExTUiB3 aGljaCBwb3BzIHRoZQogICBsYXN0IGxhYmVsIG9mZiB0aGUgc3RhY2sgbXVzdCB0aGVyZWZvcmUg YmUgYWJsZSB0byBpZGVudGlmeSB0aGUKICAgcGFja2V0J3MgbmV0d29yayBsYXllciBwcm90b2Nv bC4gIEhvd2V2ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5vdAogICBjb250YWluIGFueSBmaWVs ZCB3aGljaCBleHBsaWNpdGx5IGlkZW50aWZpZXMgdGhlIG5ldHdvcmsgbGF5ZXIKICAgcHJvdG9j b2wuICBUaGlzIG1lYW5zIHRoYXQgdGhlIGlkZW50aXR5IG9mIHRoZSBuZXR3b3JrIGxheWVyIHBy b3RvY29sCiAgIG11c3QgYmUgaW5mZXJhYmxlIGZyb20gdGhlIHZhbHVlIG9mIHRoZSBsYWJlbCB3 aGljaCBpcyBwb3BwZWQgZnJvbQogICB0aGUgYm90dG9tIG9mIHRoZSBzdGFjaywgcG9zc2libHkg YWxvbmcgd2l0aCB0aGUgY29udGVudHMgb2YgdGhlCiAgIG5ldHdvcmsgbGF5ZXIgaGVhZGVyIGl0 c2VsZi4KPGVuZCBxdW90ZT4KCk15IDJjLApTYXNoYQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCkZyb206IG1wbHMgPG1wbHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVo YWxmIG9mIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPgpTZW50OiBNb25kYXksIEphbnVh cnkgMjYsIDIwMTUgNTowNSBBTQpUbzogaHV1YmF0d29ya0BnbWFpbC5jb207IHNmY0BpZXRmLm9y ZzsgbXBsc0BpZXRmLm9yZwpTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUg cHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0PwoKSGkgSHV1YiwKClRoZSBhbHRlciBs YWJlbCBpdHNlbGYgY291bGRuoa90IG1ha2UgdGhlIHJlY2VpdmluZyBMU1IgdG8gZGV0ZXJtaW5l IHRoZSBNUExTIHBheWxvYWQgdHlwZSBieSBleGFtaW5pbmcgdGhlIE1QTFMgcGF5bG9hZC4KCkJl c3QgcmVnYXJkcywKWGlhb2h1Cgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTog SHV1YiB2YW4gSGVsdm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0KPiBTZW50OiBG cmlkYXksIEphbnVhcnkgMjMsIDIwMTUgNjoyOCBQTQo+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYu b3JnOyBtcGxzQGlldGYub3JnCj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUg dGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8KPgo+IFh1eGlhb2h1IMT6usOj oQo+Cj4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZzoKPgo+IEl0IGhhcyBhbHdheXMg YmVlbiBteSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcwo+IGlu ZGVwZW5kZW50IG9mIHRoZSBwcm90b2NvbC9wYXlsb2FkLgo+IFNvIG5vIGluZGljYXRpb24gb2Yg dGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vzc2FyeS4KPgo+IElNSE8geW91IGNv dWxkIHVzZSB0aGUgYWxlcnQgbGFiZWwgMSB0byBpbmRpY2F0ZSB0byB0aGUgTFNSIHRoYXQgaXQg aGFzIHRvIGZ1cnRoZXIKPiBleGFtaW5lIHRoZSBjb250ZW50IG9mIGEgcGFja2V0Lgo+Cj4gUmVn YXJkcywgSHV1Yi4KPgo+ID09PT09PT09Cj4KPiA+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1zZmMtbnNoLTA0KToKPiA+Cj4gPiAgICAgVGhlIHNl cnZpY2UgaGVhZGVyIGlzIGluZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQgYW5k IGlzCj4gPiAgICAgZW5jYXBzdWxhdGVkIGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBUaGUgcHJl c2VuY2Ugb2YgTlNIIGlzCj4gPiAgICAgaW5kaWNhdGVkIHZpYSBwcm90b2NvbCB0eXBlIG9yIG90 aGVyIGluZGljYXRvciBpbiB0aGUgb3V0ZXIKPiA+ICAgICBlbmNhcHN1bGF0aW9uLgo+ID4KPiA+ IEluIHRoZSBjYXNlIHdoZXJlIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uIGlzIGFuIE1QTFMgTFNQ LCBob3cgdG8gaW5kaWNhdGUgdGhlCj4gcHJlc2VuY2Ugb2YgTlNIIHNpbmNlIHRoZSBNUExTIGVu Y2Fwc3VsYXRpb24gaGFzIG5vIGV4cGxpY2l0IHByb3RvY29sIGlkZW50aWZpZXIKPiBmaWVsZCB0 byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUgTVBMUyBwYXlsb2FkPyBTaG91bGQg d2UgbWFrZSBlYWNoCj4gU0ZGIHRvIGFsbG9jYXRlIGEgdW5pcXVlIGxhYmVsIGZvciBpbmRpY2F0 aW5nIHRoZSBwcmVzZW5jZSBvZiBOU0g/IE9yIHNob3VsZCB3ZQo+IHVzZSB0aGUgY29udHJvbCB3 b3JkIHRvIGluZGljYXRlIGl0PyBPciBzaG91bGQgd2UgcmVjb25zaWRlciB0aGUgcG9zc2liaWxp dHkgb2YKPiBhZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRpZmllciBmaWVsZCB0byB0 aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHNvIGFzIHRvCj4gc29sdmUgc3VjaCBraW5kIG9mIGlzc3Vl cyBvbmNlIGFuZCBmb3IgYWxsPwo+ID4KPiA+IEJlc3QgcmVnYXJkcywKPiA+IFhpYW9odQo+ID4K Pgo+Cj4gLS0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqCj4gKioqKgo+ICAgICAgICAgICAgICAgIMfrvMfXoaOsxOPKx7bA0rvO 3rb+tcSjrL7Nz/HG5Mv7w7/Su7j2yMvSu9H5Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm1wbHMgbWFpbGluZyBsaXN0Cm1wbHNAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzCg== From nobody Sun Jan 25 23:54:55 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01891A6ED8 for ; Sun, 25 Jan 2015 23:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76sgv_eokRUH for ; Sun, 25 Jan 2015 23:54:51 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA131A1DE2 for ; Sun, 25 Jan 2015 23:54:50 -0800 (PST) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0Q7snVl027120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Jan 2015 02:54:49 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t0Q7snVl027120 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1422258889; bh=Lu2ZJlkHo29TLfnhABMytA2nJkU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Ejk7AmdooJtzIicwLT1kdjItavXSHv4YO65WztqLRBV6Cov9OePVCo3hm0FyAtAez ewRsxusmzF+jpAX+erPE3w2UeT7cqn/sA8jcr9w39lrc8ao4pZH/gvcxmVmsCzt2vl NMO42z1ntLEsTymos460oTq0Yir5Ml4hMwxgnHVw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t0Q7snVl027120 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Mon, 26 Jan 2015 02:53:42 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0Q7sW9O019876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Jan 2015 02:54:33 -0500 Received: from MXHUB105.corp.emc.com (10.253.50.22) by mxhub12.corp.emc.com (10.254.92.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 26 Jan 2015 02:54:32 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB105.corp.emc.com ([10.253.50.22]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 02:54:32 -0500 From: "Black, David" To: "mpls@ietf.org" Thread-Topic: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) Thread-Index: AdA1oqOFqXa6TZniRmKdoDHGpf5pnwA6YgqAABOkGQAAHFgfgAAHNMUgAHT03HA= Date: Mon, 26 Jan 2015 07:54:31 +0000 Message-ID: References: <022f01d035a2$a5f07e00$f1d17a00$@olddog.co.uk> <54C12835.9090000@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4A4@NKGEML512-MBS.china.huawei.com> <008101d03722$350a2f20$9f1e8d60$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.59.230] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Subject: [mpls] FW: Martin Stiemerling's Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 07:54:54 -0000 I just talked to Martin at the IAB SEMI workshop in Zurich. The following text addition to the start of Section 4 will suffice to resolve his Discuss on the mpls-in-udp draft: OLD This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded through "UDP tunnels". When performing MPLS-in-UDP encapsulation by the encapsulator, the entropy value would be generated by the encapsulator and then be filled in the Source Port field of the UDP header. The Destination Port field is set to a value (TBD1) allocated by IANA to indicate that the UDP tunnel payload is an MPLS packet. NEW This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded through "UDP tunnels". When performing MPLS-in-UDP encapsulation by the encapsulator, the entropy value would be generated by the encapsulator and then be filled in the Source Port field of the UDP header. The Destination Port field is set to a value (TBD1) allocated by IANA to indicate that the UDP tunnel payload is an MPLS packet. Each UDP tunnel is unidirectional, as MPLS-in-UDP traffic is sent to the IANA-allocated UDP Destination Port, and in particular, is never sent back to any port used as a UDP Source Port (which serves solely as a source of entropy). This is at odds with a common middlebox (e.g., firewall) assumption that bidirectional traffic uses a common pair of UDP ports. As a result, arranging to pass bidirectional MPLS-in-UDP traffic through middleboxes may require separate configuration for each direction of traffic. I would also add a paragraph break after this change. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Martin Stiemer= ling > > > Sent: Friday, January 23, 2015 12:41 AM > > > To: adrian@olddog.co.uk; 'The IESG' > > > Cc: draft-ietf-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org= ; > > > mpls@ietf.org > > > Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-i= n-udp-10: > > > (with DISCUSS) > > > > > > Adrian, > > > > > > We are on-track :) > > > > > > I will clear when there is text. > > > > > > Martin > > > > > > Am 21.01.15 um 18:49 schrieb Adrian Farrel: > > > > Hi Martin, > > > > > > > > Speaking as a contributor to this I-D and recused... > > > > > > > > I think you have a valid point, but the details are a bit wrong. > > > > > > > >> The UDP source port is randomly chosen and I guess not further > > > >> retained > > > >> (*) for receiving incoming MPLS-over-UDP packets. In turn this mea= ns > > > >> that "returning" packets are sent to the MPLS/UDP port number. > > > >> > > > >> (*) nobody is listening on that UDP port. > > > > > > > > I think this is no different from when the port is assigned through= entropy. > > > That is, a source port is assigned for use on the outward flow with n= o > > > assumption that returning packets will use the same port number as th= e > > > destination port. Indeed, the destination port is always "MPLS" on tr= affic flowing > > > in both directions. > > > > > > > > This might require "knowledge" to be configured into a firewall if = it finds itself > > > in the path. > > > > > > > >> This will cause issues when NATs/firewalls are in-between, as the > > > >> return traffic, i.e., the traffic incoming from the public part of > > > >> the NAT, is not matching any NAT binding that was created before b= y > > > >> an outgoing packet. Similar for firewalls as no state was created > > > >> when the packet traversed the firewall. > > > >> > > > >> NATs are probably not a big issue in a carrier net, but firewalls > > > >> will for sure. I guess this should be mentioned as an operational = note. > > > > > > > > If you think a warning should be added, that is pretty simple to do= (and > > > possibly gels with the warning about zero checksum). > > > > > > > > (Is the addition of such a warning a Discuss? Who cares! We can add > > > > the note whatever :-) > > > > > > > > Adrian > > > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Jan 26 03:12:07 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212581A88F1; Mon, 26 Jan 2015 03:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBSANUHdRaIx; Mon, 26 Jan 2015 03:12:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530A31A88E4; Mon, 26 Jan 2015 03:11:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT04513; Mon, 26 Jan 2015 11:11:57 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 11:11:55 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 26 Jan 2015 19:11:50 +0800 From: Lizhenbin To: "Acee Lindem (acee)" , Robert Raszuk Thread-Topic: =?gb2312?B?W3NwcmluZ10gtPC4tDogIE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRp?= =?gb2312?B?bmcoNCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBEZXBlbmRlbmN5IGZvciBTUi1C?= =?gb2312?Q?E_Path?= Thread-Index: AQHQNk31EWeTb7PlAk6XFAlvuWJ1QZzSQx8H Date: Mon, 26 Jan 2015 11:11:49 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D47729671@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772808A@nkgeml506-mbx.china.huawei.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772818C@nkgeml506-mbx.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D47729671nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogW3NwcmluZ10gtPC4tDogIE5ldyBDb21tZW50?= =?gb2312?b?cyBvbiBTZWdtZW50IFJvdXRpbmcoNCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBE?= =?gb2312?b?ZXBlbmRlbmN5IGZvciBTUi1CRSBQYXRo?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 11:12:03 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D47729671nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWNlZSwNCg0KSSBkb24ndCB0aGluayBteSBwcm9wb3NlZCBpc3N1ZXMgaXMgdGhlIHNhbWUg Y2FzZSBhcyB5b3UgcHJvcG9zZWQuIEkgdGhpbmsgeW91ciBwcm9wb3NlZCBjYXNlIGlzIGxpa2Ug Zm9yd2FyZGluZyBhZ2VuY3kgb3IgSUdQIHNob3J0LWN1dCB1c2luZyB0dW5uZWwgYXMgdGhlIGlu dGVyZmFjZSB0byBoaWRlIHRoZSBNUExTIGZyb20gdGhlIE9TUEYuICBNeSBjYXNlIGlzIHRoZSBT Ui1CRSBwYXRoIGluIHdoaWNoIE9TUEYgaXMgbGlrZSBMRFAgYXMgb25lIE1QTFMgY29udHJvbCBw cm90b2NvbCB0byBsb29wIHVwIHRoZSByb3V0ZSB0byBkZXRlcm1pbmUgdGhlIG91dGdvdGluZyBp bnRlcmZhY2UgYW5kIHRoZSBuZXh0aG9wIGZvciB0aGUgbGFiZWwgbWFwcGluZyBhZHZlcnRpc2Vk IGJ5IE9TUEYncyBzZWxmIGluc3RlYWQgb2YgaGlkaW5nIHRoZSBsYWJlbCBpbiB0aGUgdHVubmVs Lg0KDQoNCg0KDQoNClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoNCg0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBBY2VlIExpbmRlbSAoYWNlZSkgW2Fj ZWVAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTXE6jHUwjIyyNUgMjI6MTUNCsrVvP7IyzogTGl6 aGVuYmluOyBSb2JlcnQgUmFzenVrDQqzrcvNOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5v cmcNCtb3zOI6IFJlOiBbc3ByaW5nXSC08Li0OiBOZXcgQ29tbWVudHMgb24gU2VnbWVudCBSb3V0 aW5nKDQpOiBDaGFsbGVuZ2Ugb2YgUm91dGUgRGVwZW5kZW5jeSBmb3IgU1ItQkUgUGF0aA0KDQpI aSBSb2JpbiwNCkkgZG9uoa90IGtub3cgYWJvdXQgb3RoZXIgSUdQIGltcGxlbWVudGF0aW9ucyBi dXQgdGhlIG9uZXMgSaGvdmUgd29ya2VkIG9uIGRvIG5vdCByZXNvbHZlIHJvdXRlcyByZWN1cnNp dmVseSAodW5saWtlIExEUCBvciBCR1Agd2hpY2ggZG8pLiAgVGhlcmUgYXJlIGNhc2VzIHdoZXJl IE9TUEYgcnVucyBvdmVyIGEgdHVubmVsIGJ1dCBpbiB0aGVzZSBjYXNlcyB0aGUgT1NQRiBpbnRl cmZhY2UgaXMgZWl0aGVyIHVwIG9yIGRvd24gZGVwZW5kZW50IG9uIHRoZSB0dW5uZWwgc3RhdHVz LiBIZW5jZSwgSSB0aGluayB0aGUgaXNzdWUgeW91oa92ZSByYWlzZWQgcmVnYXJkaW5nIHByb3Rv Y29sIHN5bmNocm9uaXphdGlvbiBpcyBhIG1vb3QgcG9pbnQuDQpUaGFua3MsDQpBY2VlDQoNCkZy b206IExpemhlbmJpbiA8bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRvOmxpemhlbmJpbkBodWF3 ZWkuY29tPj4NCkRhdGU6IFRodXJzZGF5LCBKYW51YXJ5IDIyLCAyMDE1IGF0IDY6MDggQU0NClRv OiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5u ZXQ+Pg0KQ2M6ICJtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiIgPG1wbHNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PiwgInNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3By aW5nQGlldGYub3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4N ClN1YmplY3Q6IFtzcHJpbmddILTwuLQ6IE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmco NCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBEZXBlbmRlbmN5IGZvciBTUi1CRSBQYXRoDQoNCg0KSGkg Um9iZXJ0LA0KDQpQbGVhc2UgcmVmZXIgdG8gbXkgaW5saW5lICdbUm9iaW5dJy4NCg0KDQoNClJl Z2FyZHMsDQoNClJvYmluDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K t6K8/sjLOiBycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+IFtycmFz enVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+XSC0+rHtIFJvYmVydCBSYXN6 dWsgW3JvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD5dDQq3osvNyrG8 5DogMjAxNcTqMdTCMjLI1SAxNTo0Ng0KytW8/sjLOiBMaXpoZW5iaW4NCrOty806IHNwcmluZ0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBs c0BpZXRmLm9yZz4NCtb3zOI6IFJlOiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2VnbWVudCBS b3V0aW5nKDQpOiBDaGFsbGVuZ2Ugb2YgUm91dGUgRGVwZW5kZW5jeSBmb3IgU1ItQkUgUGF0aA0K DQpIaSBSb2JpbiwNCg0KSSB0aGluayB5b3VyIHF1ZXN0aW9uIGlzIG5vdCBhcHBsaWNhYmxlIHRv IFNSIGFyY2hpdGVjdHVyZS4NCg0KVGhlIHJpZ2h0IFNSIGFuYWxvZ3kgdG8gTERQIHdvdWxkICpO T1QqIGJlIGhvcCBieSBob3AgTERQIGxpa2UgaW4geW91ciBleGFtcGxlLCBidXQgdGFyZ2V0ZWQg KGFrYSBkaXJlY3RlZCkgTERQIHNlc3Npb24uDQpbUm9iaW5dIEkgY291bGQgbm90IHVuZGVyc3Rh bmQgeW91ciBwb2ludC4gTm8gbWF0dGVyIFQtTERQIG9yIGxvY2FsIExEUCwgdGhleSBzaG91bGQg bG9va3VwIGluIHRoZSBSSUIvRklCIHRvIGRldGVybWluZSBpZiB0aGUgbGFiZWwgbWFwcGluZyBp cyBhY3RpdmUuDQpJbiB0aG9zZSBob3cgdG8gZ2V0IHRvIEZFQydzIGFkZHJlc3MgaXMganVzdCBy ZWd1bGFyIGxvb2t1cCBpbiB0aGUgUklCL0ZJQiAoZ2xvYmFsIG9yIHZyZiBkZXBlbmRzIG9uIHVz ZSBjYXNlKSBhbmQgaXQgZG9lcyBub3QgbWF0dGVyIHdoYXQgcHJvdG9jb2wgc3JjIGluc3RhbGxl ZCB0aGUgcm91dGUuDQpbUm9iaW5dIEFzIHdoYXQgeW91IGRlc2NyaWJlZCwgY291bGQgSSB1bmRl cnN0YW5kIHlvdSBtZWFucyBmb3IgdGhlIFNSIGJhc2VkIG9uIGEgc3BlY2lmaWMgSUdQKGUuZy4g T1NQRiksIGl0IHNob3VsZCBsb29rIHVwIGluIHRoZSBSSUIvRklCIHRvIGRldGVybWluZSBpZiB0 aGUgbGFiZWwgYmluZGluZyBpcyB1cD8gSWYgc28sIHRoZXJlIHdpbGwgYmUgdGhlIHR3byByb3V0 ZSBkZXBlbmRlbmN5IGNoYW5nZSBpc3N1ZXMgSSBwcm9wb3NlZCBmb3IgdGhlIE9TUEYuIFdoeSBk byB5b3UgdGhpbmsgdGhleSBhcmUgbm90IGFwcGxpY2FibGUgdG8gU1I/DQoNCg0KQWxzbyBub3Rl IHRoYXQgbGlrZSBpbiBtb3N0IExEUCBjYXNlIFNSICJsYWJlbHMiIG9yICJJRHMiIGFyZSBnbG9i YWwgc28gcmVnYXJkbGVzcyBvbiB3aGljaCBpbnRlcmZhY2UgcGFja2V0IGFycml2ZXMgKHdpdGhp biBnaXZlbiB0b3BvbG9neSBpbiBjYXNlIG9mIG10KSB0aGUgbG9va3VwIHJlc3VsdCB3aWxsIGJl IGlkZW50aWNhbC4NCg0KUmdzLA0KUi4NCg0KDQpPbiBUaHUsIEphbiAyMiwgMjAxNSBhdCA2OjA3 IEFNLCBMaXpoZW5iaW4gPGxpemhlbmJpbkBodWF3ZWkuY29tPG1haWx0bzpsaXpoZW5iaW5AaHVh d2VpLmNvbT4+IHdyb3RlOg0KDQpIaSBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRpbmcsDQoN Cg0KDQpUaGlzIGlzIHRoZSBmb3VydGggY29tbWVudHMuDQoNCg0KDQpGb3IgTERQLCB3aGVuIHNl YXJjaCByb3V0ZSBmb3IgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mgd2hpY2ggaXMgdGhlIEZFQyBv ZiB0aGUgbGFiZWwgbWFwcGluZywgaXQgc2hvdWxkIHNlYXJjaA0KdGhlIEZJQiBpbiB3aGljaCB0 aGUgcm91dGVzIGFyZSBzZWxlY3RlZCBmcm9tIHRoZSBzdGF0aWMgcm91dGUsIE9TUEYsIElTSVMs IEJHUCwgZXRjIGJhc2VkIG9uIHRoZSBwcmVmZXJlbmNlcy4NCk5vdyB0aGVyZSBpcyBvbmUgcXVl c3Rpb24gZm9yIFNSLUJFIHBhdGgsIGZvciBleGFtcGxlLCBpZiB0aGUgU0lEL0xhYmVsIGlzIGFk dmVydGlzZWQgdGhyb3VnaCBPU1BGLCB3aGF0IHR5cGUNCg0Kb2Ygcm91dGVzIHNob3VsZCB0aGUg bGFiZWwgbWFwcGluZyBkZXBlbmQgb24gd2hlbiBzZXR1cCB0aGUgU1ItQkUgcGF0aD8NCg0KDQoN CkkgdGhpbmsgdGhlcmUgbWF5IGJlIHR3byBjaG9pY2VzOg0KMS4gT25seSBkZXBlbmQgb24gdGhl IE9TUEYncyBvd24gcm91dGU7DQoyLiBMaWtlIHRoZSBMRFAsIGRlcGVuZHMgb24gdGhlIHNlbGVj dGVkIHJvdXRlLg0KDQoNCg0KSSBkb24ndCB0aGluayBpdCBzaG91bGQgYmUgdGhlIE9wdGlvbiAx LiBGb3IgZXhhbXBsZSwgd2UgY29uZmlndXJlIHN0YXRpYyByb3V0ZXMgZm9yIGFsbCBub2RlcyBh bG9uZyB0aGUgcGF0aCB0bw0KYSBzcGVjaWZpYyBub2RlIHdoaWNoIGNhbiBiZSB0b3RhbGx5IGRp ZmZlcmVudCBmcm9tIHRoZSBPU1BGIHJvdXRlcyB0byB0aGUgbm9kZS4gSWYgdGhlIHN0YXRpYyBy b3V0ZSBoYXMgaGlnaGVyDQpwcmlvcml0eSB0aGFuIHRoZSBPU1BGIGFuZCB0aGUgU0lEL2xhYmVs IGlzIGFkdmVydGlzZWQgYnkgT1NQRiBkZXBlbmRzIG9uIE9TUEYgcm91dGVzLCB0aGVyZSB3aWxs IGJlIHRoZQ0KDQppbmNvbnNpc3RlbmN5IGJldHdlZW4gdGhlIFNSLUJFIHBhdGggYW5kIHRoZSBy b3V0ZSBwYXRoLg0KDQoNCg0KSWYgdGhlIG9wdGlvbiAyIGlzIGFkb3B0ZWQsIGl0IGNhbm5vdCBi ZSBhc3N1bWVkIHRoYXQgdGhlIGxhYmVsIG1hcHBpbmcgYW5kIHRoZSByb3V0ZSBhcmUgaW4gdGhl IHNhbWUgTFNEQiB3aGljaA0KDQpjYW4gYmUgZWFzaWx5IHN5bmNocm9uaXplZC4gVGhlcmUgYXJl IHR3byBjaGFsbGVuZ2VzOg0KMS4gVGhlIGRpcmVjdCBlZmZlY3QgZm9yIHRoZSBPU1BGIGlzIHRo YXQgYXQgdGhlIGJlZ2lubmluZyBpdCBqdXN0IGRvd25sb2FkcyBpdCByb3V0ZXMgdG8gdGhlIFJJ QiBmb3IgdGhlIHJvdXRlDQpzZWxlY3Rpb24uIFRoYXQgaXMsIGl0IGlzIHRoZSBzb3VyY2Ugb2Yg dGhlIHJvdXRlIHNlbGVjdGlvbi4gQnV0IG5vdyBvd2luZyB0byBTUi1CRSBwYXRoLCBpdCBoYXMg dG8gZGVwZW5kIG9uDQoNCnRoZSByZXN1bHQgb2YgdGhlIHJvdXRlIHNlbGVjdGlvbi4NCjIuIE9T UEYgU1ItQkUgcGF0aCBtYXkgZGVwZW5kIG9uIHRoZSByb3V0ZXMgZnJvbSB0aGUgc3RhdGljIHJv dXRlLCBJU0lTLCBCR1AsIGV0Yy4gSXQgaXMgY2xhaW1lZCB0aGF0IHRoZSBTUiBjYW4NCnJlbW92 ZSB0aGUgSUdQLUxEUCBzeW5jLiBCdXQgYWNjb3JkaW5nIHRvIHRoaXMgYW5hbHlzaXMsIGFyZSB0 aGVyZSB0aGUgcG9zc2libGUgcmlzayB3ZSBoYXZlIHRvIGludHJvZHVjZSB0aGUNCg0KT1NQRi1J U0lTIHN5bmMsIE9TUEYtU3RhdGljIFJvdXRlIHN5bmMsIE9TUEYtQkdQIHN5bmM/IE9yIGRvIHlv dSBqdXN0IHRoaW5rIHRoZXkgYXJlIHJhcmUgY2FzZXMgd2hpY2ggc2hvdWxkIG5vdA0KDQogYmUg dGFrZW4gaW50byBhY2NvdW50PyBIb3BlIHlvdSBoYXZlIGhhZCBlbm91Z2ggYW5hbHlzaXMgb24g dGhpcyBpc3N1ZS4NCg0KDQoNCkFjY29yZGluZyB0byB0aGUgY29tbWVudHMgb24gdGhlIGRlcGVu ZGVuY3ksIEkgaG9wZSB5b3UgY291bGQgc3BlY2lmeSBjbGVhcmx5IGluIHRoZSBhcHByb3ByaWF0 ZSBkcmFmdCBvZiBzZWdtZW50DQoNCnJvdXRpbmcgYXMgdG8gZm9sbG93cyBxdWVzdGlvbnMgZm9y IFNSLUJFIHBhdGggd2hpY2ggaXMgaGVscGZ1bCBmb3IgaW50ZXJvcGVyYWJpbGl0eToNCi0tIGRl cGVuZCBvbiB0aGUgbG9uZ2VzdCBtYXRjaCwgb3IgZXhhY3QgbWF0Y2gsIG9yIGJvdGguDQotLSBk ZXBuZWQgb24gdGhlIFNSIHByb3RvY29sJ3Mgb3duIHJvdXRlcyBvciB0aGUgcm91dGUgc2VsZWN0 aW9uIHJlc3VsdGUgZnJvbSBtdWx0aXBsZSBzb3VyY2VzLg0KDQoNCg0KDQoNCg0KDQpSZWdhcmRz LA0KUm9iaW4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n DQoNCg0K --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D47729671nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Acee,

I don't think my proposed issues is the same case as you proposed. I thi= nk your proposed case is like forwarding agency or IGP short-cut using tunn= el as the interface to hide the MPLS from the OSPF.  My case is the SR= -BE path in which OSPF is like LDP as one MPLS control protocol to loop up the route to determine the outgoting = interface and the nexthop for the label mapping advertised by OSPF's self i= nstead of hiding the label in the tunnel.

 

 

Regards,

Robin

 

 

 

 

=B7=A2=BC=FE=C8=CB: Acee Lindem (acee) [ac= ee@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C222=C8=D5 22:15
=CA=D5=BC=FE=C8=CB: Lizhenbin; Robert Raszuk
=B3=AD=CB=CD: mpls@ietf.org; spring@ietf.org
=D6=F7=CC=E2: Re: [spring] =B4=F0=B8=B4: New Comments on Segment Rou= ting(4): Challenge of Route Dependency for SR-BE Path

Hi Robin, 
I don=A1=AFt know about other IGP implementations but the ones I=A1=AF= ve worked on do not resolve routes recursively (unlike LDP or BGP which do)= .  There are cases where OSPF runs over a tunnel but in these cases th= e OSPF interface is either up or down dependent on the tunnel status. Hence, I think the issue you=A1=AFve raised regardin= g protocol synchronization is a moot point. 
Thanks,
Acee 

From: Lizhenbin <lizhenbin@huawei.com> Date: Thursday, January 22, 2015 a= t 6:08 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: [spring] =B4=F0=B8=B4: Ne= w Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE P= ath

Hi Robert,

Please refer to my inline '[Robin]'.

 

Regards,

Robin

 

=B7=A2=BC=FE=C8=CB: rraszuk@gmail.com [rraszuk@gmail.com= ] =B4=FA=B1=ED Robert Raszuk [robert@raszuk.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C222=C8=D5 15:46
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: s= pring@ietf.org; mpls@ietf.org
=D6=F7=CC=E2: Re: [spring] New Comments on Segment Routing(4): Chall= enge of Route Dependency for SR-BE Path

Hi Robin,

I think your question is not applicable to SR architecture. 

The right SR analogy to LDP would *NOT* be hop by hop LDP like in your exam= ple, but targeted (aka directed) LDP session.
[Robin] I could not understand your point. No matter T-LDP or local LD= P, they should lookup in the RIB/FIB to determine if the label mapping is a= ctive.
In those how to get to FEC's address is just regular lookup in the RIB/FIB = (global or vrf depends on use case) and it does not matter what protocol sr= c installed the route. 
[Robin] As what you described, could I understand you means for the SR base= d on a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to determi= ne if the label binding is up? If so, there will be the two route dependenc= y change issues I proposed for the OSPF. Why do you think they are not applicable to SR?
 
 
Also note that like in most LDP case SR "labels" or "IDs&quo= t; are global so regardless on which interface packet arrives (within given= topology in case of mt) the lookup result will be identical.

Rgs,
R.


On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin <lizhenbin@hua= wei.com> wrote:

Hi all authors of segment routing,

 

This is the fourth comments.

 

For LDP, when search route for the destination ad= dress which is the FEC of the label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS,= BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is = advertised through OSPF, what type

of routes should th= e label mapping depend on when setup the SR-BE path?

 

I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.

 

I don't think it should be the Option 1. For exam= ple, we configure static routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the = node. If the static route has higher
priority than the OSPF and the SID/label is advertised by OSPF depends= on OSPF routes, there will be the

inconsistency between the SR-BE path and the route path.

 

If the option 2 is adopted, it cannot be assumed = that the label mapping and the route are in the same LSDB which

can be easily synchronized. There are two challen= ges:
1. The direct effect for the OSPF is that at the beginning it just download= s it routes to the RIB for the route
selection. That is, it is the source of the route selection. But now owing = to SR-BE path, it has to depend on

the result of the route selection.
2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BG= P, etc. It is claimed that the SR can
remove the IGP-LDP sync. But according to this analysis, are there the poss= ible risk we have to introduce the

OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP = sync? Or do you just think they are rare cases which should not

 be taken into account? Hope you have had en= ough analysis on this issue.

 

According to the comments on the depend= ency, I hope you could specify clearly in the appropriate draft of seg= ment

routing as to follows questions for SR-BE path wh= ich is helpful for interoperability:
-- depend on the longest match, or exact match, or both.
-- depned on the SR protocol's own routes or the route selection resulte fr= om multiple sources.

 

 

 

Regards,
Robin

 


_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring


--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D47729671nkgeml506mbxchi_-- From nobody Mon Jan 26 03:21:27 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009581A8910; Mon, 26 Jan 2015 03:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrRGdia_0tT3; Mon, 26 Jan 2015 03:21:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9D31A882F; Mon, 26 Jan 2015 03:21:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOK89819; Mon, 26 Jan 2015 11:21:21 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 11:21:20 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 26 Jan 2015 19:21:16 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(5): Challenge of Hot-standby for SR-TE Path Thread-Index: AQHQOVoyK64QSjXka0yfZ8lTIcYadw== Date: Mon, 26 Jan 2015 11:21:15 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968B@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968Bnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [mpls] New Comments on Segment Routing(5): Challenge of Hot-standby for SR-TE Path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 11:21:25 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968Bnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgZmlm dGggY29tbWVudHMgb24gc2VnbWVudCByb3V0aW5nLiBJdCBpcyByZWxhdGVkIHdpdGggU1ItVEUg cGF0aCBhbmQgSSBpbmNsdWRlIHRoZSBURUFTIFdHIGluIHRoZSBkaWN1c3Npb24uDQoNCg0KDQog ICAgICAgICAxICAgICAgICAgICAgICAxICAgICAgICAgICAxICAgICAgICAgICAgMQ0KICBTMTEt LS0tLS0tLS0tLVMxMi0tLS0tLS0tLS1TMTMtLS0tLS0tLS1TMTQtLS0tLS0tLS1TMTUNCiAgIHwg ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgMXwg ICAgICAgICAgICAxfCAgICAgICAgICAgMXwgICAgICAgICAgMXwgICAgICAgICAgMXwNCiAgIHwg ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgUzIx LS0tLS0tLS0tLS1TMjItLS0tLS0tLS0tUzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1DQogICAg ICAgICA0ICAgICAgICAgICAgICA0ICAgICAgICAgICA0ICAgICAgICAgICAgNA0KDQpNUExTIFRF IGhvdHN0YW5keSBpcyBhbHdheXMgYWRvcHRlZCBpbiB0aGUgTVBMUyBmb3IgdGhlIHRyYWZmaWMg cHJvdGVjdGlvbi4gSW4gb3JkZXIgdG8gYXZvaWQgb25lIG5vZGUvbGluayBmYWlsdXJlIGNhdXNl DQoNCmJvdGggdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGJlY29tZXMgZG93 biwgaXQgaXMgcmVxdWlyZWQgdGhhdCB0aGUgcHJpbWFyeSBwYXRoIGFuZCB0aGUgYmFja3VwIHBh dGggc2hvdWxkDQoNCmJlIHRvdGFsbHkgZGlzam9pbnRlZC4NCg0KDQoNCkkgYXNzdW1lIHRoYXQg dGhlIGRlc2lnbiBwcmluaWNpcGxlIHNob3VsZCBiZSBhbHNvIGFwcGxpZWQgdG8gdGhlIFNSLVRF IHBhdGguIElmIHNvLCB0YWtpbmcgaW50byBhY2NvdW50IHRoZSBhYm92ZSB0b3BvbG90eQ0KDQog KHRoZSBudW1iZXJzIG5lYXIgdGhlIGxpbmUgcmVwcmVzZW50IHRoZSBtZXRyaWNzIG9mIHRoZSBs aW5rcyksIGluIG9yZGVyIHRvIGd1YXJhbnRlZSB0aGUgZGlzam9pbnQgb2YgdGhlIHByaW1hcnkg cGF0aA0KDQphbmQgdGhlIGJhY2t1cCBwYXRoLCB0aGUgbGFiZWwgc3RhY2sgWyBTMjIgU0woUzIy L1MyMykgUzIzIFNMKFMyMy8yNCkgUzI0IFNMKFMyNC9TMjUpIFMxNSBdIChTTCBtZWFucyB0aGUg bGluayBzZWdtZW50DQoNCmJldHdlZW4gdGhlIHR3byBuZWlnaGJvcmluZyBub2RlcykgbXVzdCBi ZSBzcGVjaWZpZWQgZm9yIHRoZSBob3RzdGFuZGJ5IHBhdGguIFNvIGluIHRoZSBjYXNlIHRoZXJl IG1heWJlIG1vcmUgbGFiZWxzIHRvIGJlDQoNCmVuY2Fwc3VsYXRlZCBmb3IgdGhlIHBhY2tldHMg Zm9yd2FyZGVkIHRocm91Z2ggdGhlIGhvdC1zdGFuZGJ5IHBhdGguIEl0IG1heSBiZSBlYXN5IHRv IGV4Y2VlZCB0aGUgaGFyZHdhcmUgbGltaXRhdGlvbiBhbmQNCg0KY2F1c2UgdGhlIGxvdyBlZmZp Y2llbmN5IHBheWxvYWQuDQoNCkkgd29uZGVyIGlmIHlvdSB0aGluayBhYm91dCB0aGUgY2hhbGxl bmdlLiBIb3BlIHRvIGdldCB5b3VyIG9waW5pb24gb24gaXQuDQoNCg0KDQoNCg0KUmVnYXJkcywN ClJvYmluDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968Bnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the fifth comments on segment routing. It= is related with SR-TE path and I include the TEAS WG in the dicussion.

 


         1    &= nbsp;         1   &n= bsp;       1     &nb= sp;      1
  S11-----------S12----------S13---------S14---------S15
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  1|           = 1|           1| &nb= sp;        1|    &nb= sp;     1|
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  S21-----------S22----------S23---------S24---------S25
         4    &= nbsp;         4   &n= bsp;       4     &nb= sp;      4

MPLS TE hotstandy is always adopted in the MPLS for the traffic protecti= on. In order to avoid one node/link failure cause

both the primary path and the backup path becomes down, it is requi= red that the primary path and the backup path should

be totally disjointed.

 

I assume that the design priniciple should be also applied to the SR-TE = path. If so, taking into account the above topoloty

 (the numbers near the line represent the metrics of the links), in= order to guarantee the disjoint of the primary path

and the backup path, the label stack [ S22 SL(S22/S23) S23 SL(S23/24) S2= 4 SL(S24/S25) S15 ] (SL means the link segment

between the two neighboring nodes) must be specified for the hotstandby = path. So in the case there maybe more labels to be

encapsulated for the packets forwarded through the hot-standby path= . It may be easy to exceed the hardware limitation and

cause the low efficiency payload.

I wonder if you think about the challenge. Hope to get your opinion on i= t.

 

 


Regards,
Robin

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968Bnkgeml506mbxchi_-- From nobody Mon Jan 26 03:41:13 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8681A892C; Mon, 26 Jan 2015 03:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4Pr_D03-m0M; Mon, 26 Jan 2015 03:41:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D661A882F; Mon, 26 Jan 2015 03:41:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT07897; Mon, 26 Jan 2015 11:41:07 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 11:41:06 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 26 Jan 2015 19:40:58 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(6): Challenge of Loose Explicit Path for SR-TE Path Thread-Index: AQHQOVry9L8WAh2w3ECX3Jff5mfs3Q== Date: Mon, 26 Jan 2015 11:40:57 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BD@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BDnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [mpls] New Comments on Segment Routing(6): Challenge of Loose Explicit Path for SR-TE Path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 11:41:11 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BDnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgc2l4 dGggY29tbWVudHMgb24gc2VnbWVudCByb3V0aW5nLiBJdCBpcyBhbm90aGVyIGlzc3VlIHJlbGF0 ZWQgd2l0aCBTUi1URSBwYXRoLg0KDQogICAgICAgICAgICAgICAgIFM0LS0tUzUNCiAgICAgICAg ICAgICAgICAvICAgICAgIFwNCiAgICBTMS0tLVMyLS0tUzMgICAgICAgICBTOC0tLVM5LS0tUzEw DQogICAgICAgICAgICAgICAgXCAgICAgICAvDQogICAgICAgICAgICAgICAgIFM2LS0tUzcNCg0K Rm9yIE1QTFMgVEUsIHRoZXJlIGFyZSB0d28gdHlwZXMgb2YgZXhwbGljaXQgcGF0aHM6IHN0cmlj dCBhbmQgbG9vc2UuIEV2ZW4gZm9yIHRoZSBsb29zZSBob3AsIHRoZSBpbmdyZXNzIG5vZGUgd2ls bA0KDQpjYWxjdWxhdGUgYWxsIHRoZSBob3BzIHRvIHRoZSBsb29zZSBob3AuIEFuZCB0aGUgTVBM UyBURSBwYXRoIGlzIGluZGVwZW5kZW50IGZyb20gdGhlIHJvdXRpbmcsIHRoaXMgbWVhbnMgZXZl biBpZg0KDQp0aGUgcm91dGUgY2hhbmdlLCB0aGUgTVBMUyBURSBwYXRoIHRvIHRoZSBsb29zZSBo b3AgY2FuIGJlIGtlcHQuIEZvciBleGFtcGxlLCBhcyBzaG93biBpbiB0aGUgYWJvdmUgZmlndXJl LCBpZiB0aGUNCg0KaW5ncmVzcyBTMSBjb25maWd1cmVzIHRoZSBsb29zZSBob3AgUzggdG8gdGhl IGRlc3RpbmF0aW9uIFMxMCwgaXQgd2lsbCBjYWxjdWxhdGUgdGhlIHBhdGggUzEtPlMyLT5TMy0+ UzQtPlM1LT5TOC0+UzktPlMxMC4NCg0KSWYgdGhlIG1ldHJpYyBjaGFuZ2VzIGZvciB0aGUgbGlu ayBiZXR3ZWVuIFMzIGFuZCBTNCBhbmQgbWFrZSB0aGUgc2hvcnRlc3Qgcm91dGUgcGF0aCB0byBT OCBmcm9tIHRoZSBTMy0+UzQtPlM1LT5TOCB0bw0KUzMtPlM2LT5TNy0+UzguIEJ1dCB0aGUgZXhp dGluZyBNUExTIFRFIHBhdGggd2lsbCBub3QgY2hhbmdlIGFjY29yZGluZ2x5Lg0KDQoNCg0KRm9y IFNSLUJFIFBhdGgsIGlmIHRoZSBsb29zZSBob3AgaXMgY29uZmlndXJlZCwgdGhlcmUgd2lsbCBi ZSB0d28gcG9zc2libGUgY2hvaWNlczoNCk9wdGlvbiAxLiBTYW1lIGFzIHRoZSBleGlzdGluZyBN UExTIFRFLg0KDQpJZiB0aGUgb3B0aW9uIGlzIGFkb3B0ZWQsIHRoZXJlIHdpbGwgYmUgZm9sbG93 aW5nIGNoYWxsZW5nZXM6DQoxKSBUaGlzIG1lYW5zIHRoZSBsb29zZSBob3AgY2Fubm90IHJlZHVj ZSB0aGUgbGFiZWwgc3RhY2sgZm9yIHRoZSBTUi1URSBwYXRoLiBJdCBuZWVkIG1vcmUgbGFiZWxz IHRvIGJlIGVuY2Fwc3VsYXRlZCBhZnRlcg0KDQpjYWxjdWxhdGluZyB0aGUgd2hvbGUgcGF0aCBh bmQgcmVwcmVzZW50aW5nIGVhY2ggaG9wIHdpdGggbm9kZSBsYWJlbCBvciBhZGphY2VuY3kgbGFi ZWwuIFRoZSBkZWVwIGRlcHRoIG9mIHRoZSBsYWJlbCBzdGF0Y2sNCg0KIG1heSBleGNlZWRzIHRo ZSBoYXJkd2FyZSBsaW1pdGF0aW9uIG9yIGNhdXNlIGxvdyBlZmZpY2llbmN5IHBheWxvYWQuDQoy KSBNb3JlIGNoYWxsZW5nZXMgY2FuIGJlIHByb3Bvc2VkIGZyb20gdGhlIGludGVyLWFyZWEgYmFo YXZpb3IuIElmIFBDRSBpcyBub3QgYWRvcHRlZCwgaWYgdGhlIGluZ3Jlc3Mgbm9kZSBoYXMgdG8g b25seQ0KDQpzcGVjaWZ5IHRoZSBBQlJzIGFzIHRoZSBsb29zZSBob3AgdG8gdGhlIGRlc3RpbmF0 aW9uIGZvciBpbnRlci1hcmVhLCBmb3IgTVBMUyBURSwgdGhlIGluZ3Jlc3Mgbm9kZSBjYW4gYWNx dWlyZSB0aGUgZW5kLXRvLWVuZA0KDQpwYXRoIGluZm8gdGhyb3VnaCBSUk8uICBCdXQgc2luY2Ug dGhlcmUgaXMgbm8gUlJPLWxpa2UgbWVjaGFuaXNtIGluIElHUCwgaXQgaXMgaW1wb3NzaWJsZSBm b3IgU1ItVEUgcGF0aCB0byBnZXQgdGhlIGVuZC10by1lbmQNCg0KcGF0aCBpbmZvLiBUaGlzIG1l YW5zIHRoZSBpbmdyZXNzIG5vZGUgY2Fubm90IGdldCB0aGUgd2hvbGUgbGFiZWwgc3RhY2sgaW5m byB0byBkZXRlcm1pbmUgdGhlIHdob2xlIFNSLVRFIHBhdGguDQoNCg0KDQpPcHRpb24gMi4gTGlt aXRlZCBsYWJlbHMgZm9yIHRoZSBsb29zZSBob3AuIEZvciBleGFtcGxlLCBzaW5jZSBvbmx5IGxv b3NlIGhvcCBTOCBpcyBzcGVjaWZpZWQsIHRoZW4gdGhlIGxhYmVsIHN0YWNrIGZvciB0aGUNCg0K U1ItVEUgcGF0aCB0byB0aGUgUzEwIGlzIFtTOCBTMTBdLiBUaGF0IGlzLCB0d28gbGF5ZXJzIG9m IGxhYmVscyBpcyBlbm91Z2guDQoNClRoaXMgbWV0aG9kIGNhbiBhdm9pZCB0aGUgZGVlcCBsYWJl bCBzdGFjayBpc3N1ZS4gQnV0IGl0IHdpbGwgaW50cm9kdWNlIG90aGVyIGlzc3Vlcy4gSW4gZmFj dCwgZm9yIHRoZSBTUi1URSBwYXRoLCBpdCBtaXhlcw0KDQp0aGUgcm91dGUgcGF0aCBhbmQgdGhl IFRFIHBhdGggdG9nZXRoZXIuIFRoZXJlIG1heSBiZSBmb2xsb3dpbmcgaXNzdWVzOg0KDQoxKSBU aGUgcm91dGUgY2hhbmdlIHdpbGwgaGF2ZSBlZmZlY3Qgb24gdGhlIFNSLVRFIHBhdGguIElmIHRo ZSByb3V0ZXMgdG8gdGhlIFM4IGlzIGNoYW5nZXMsIHRoZSBTUi1URSBwYXRoIHRvIHRoZSBTMTAg d2lsbA0KDQpjaGFuZ2UgYWNjb3JkaW5nbHkuDQoyKSBGb3IgdGhlIGluZ3Jlc3Mgbm9kZSwgZnJv bSB0aGUgcG9pbnQgb2YgdGhlIG5ldHdvcmsgbWFpbnRlbmFuY2UgdmlldywgaXQgbG9zZXMgdGhl IGNvbnRyb2wgb24gdGhlIGVuZC10by1lbmQgcGF0aC4gVGhhdCBpcywNCg0KdGhlIGVuZC10by1l bmQgcGF0aCBpcyB1bmtub3duIHRvIHRoZSBpbmdyZXNzIG5vZGUuDQozKSBJZiB0aGVyZSBpcyBs b2FkIGJhbGFuY2UgZm9yIHRoZSByb3V0ZSwgZm9yIGV4YW1wbGUsIHRoZXJlIGFyZSB0d28gZXF1 YWwgcGF0aHMgdG8gUzggYXMgdGhlIGFib3ZlIHRvcG9sb2d5OiBTMy0+UzQtPlM1LT5TOCwNCg0K UzMtPlM2LT5TNy0+UzguSWYgQkZEIGlzIGVuYWJsZWQgZm9yIHRoZSBTUi1URSBwYXRoLCB0aGUg QkZEIHBhY2tldHMgYW5kIHRoZSByZWFsIHRyYWZmaWMgbWF5IGdvIHRocm91Z2ggZGlmZmVyZW50 IHBhdGguDQoNClRoZXJlIHdpbGwgYmUgdGhlIHBvc3NpYmlsaXR5IHRoYXQgQkZEIHdpbGwgZGV0 ZWN0IHRoZSB3cm9uZyBwYXRoIGFuZCBtYXkgY2F1c2UgZnVydGhlIHByb2JsZW0gc3VjaCBhcyB0 aGUgd3JvbmcgdHJhZmZpYyBzd2l0Y2guDQoNCg0KDQpJIHdvbmRlciBpZiB0aGUgaXNzdWUgaGFz IGJlZW4gdGFrZW4gaW50byBhY2NvdW50IGFuZCB3aGljaCBvcHRpb24geW91IHByZWZlci4NCg0K DQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoNCg0KDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BDnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the sixth comments on segment routing. It= is another issue related with SR-TE path.


            &nb= sp;    S4---S5
            &nb= sp;   /       \
    S1---S2---S3       &n= bsp; S8---S9---S10
            &nb= sp;   \       /
            &nb= sp;    S6---S7


For MPLS TE, there are two types of explicit paths: strict and loose. Even = for the loose hop, the ingress node will

calculate all the hops to the loose hop. And the MPLS TE path is indepen= dent from the routing, this means even if

the route change, the MPLS TE path to the loose hop can be kept. For exa= mple, as shown in the above figure, if the

ingress S1 configures the loose hop S8 to the destination S10, it will c= alculate the path S1->S2->S3->S4->S5->S8->S9->S10.

If the metric changes for the link between S3 and S4 and make the shorte= st route path to S8 from the S3->S4->S5->S8 to
S3->S6->S7->S8. But the exiting MPLS TE path will not change accor= dingly.

 

For SR-BE Path, if the loose hop is configured, there will be two possib= le choices:
Option 1. Same as the existing MPLS TE.

If the option is adopted, there will be following challenges:
1) This means the loose hop cannot reduce the label stack for the SR-TE pat= h. It need more labels to be encapsulated after

calculating the whole path and representing each hop with node label or = adjacency label. The deep depth of the label statck

 may exceeds the hardware limitation or cause low efficiency payloa= d.
2) More challenges can be proposed from the inter-area bahavior. If PCE is = not adopted, if the ingress node has to only

specify the ABRs as the loose hop to the destination for inter-area, for= MPLS TE, the ingress node can acquire the end-to-end

path info through RRO.  But since there is no RRO-like me= chanism in IGP, it is impossible for SR-TE path to get the end-to-end

path info. This means the ingress node cannot get the whole label stack = info to determine the whole SR-TE path.

 

Option 2. Limited labels for the loose hop. For example, since only loos= e hop S8 is specified, then the label stack for the

SR-TE path to the S10 is [S8 S10]. That is, two layers of labels is enou= gh.

This method can avoid the deep label stack issue. But it will introduce = other issues. In fact, for the SR-TE path, it mixes

the route path and the TE path together. There may be following issues:<= /p>

1) The route change will have effect on the SR-TE path. If the routes to= the S8 is changes, the SR-TE path to the S10 will

change accordingly.
2) For the ingress node, from the point of the network maintenance view, it= loses the control on the end-to-end path. That is,

the end-to-end path is unknown to the ingress node.
3) If there is load balance for the route, for example, there are two equal= paths to S8 as the above topology: S3->S4->S5->S8,

S3->S6->S7->S8.If BFD is enabled for the SR-TE path, the BFD pa= ckets and the real traffic may go through different path.

There will be the possibility that BFD will detect the wrong path and ma= y cause furthe problem such as the wrong traffic switch.

 

I wonder if the issue has been taken into account and which option you p= refer.

 

 

 

 

Regards,

Robin

 

 

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BDnkgeml506mbxchi_-- From nobody Mon Jan 26 05:57:24 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A080E1A8AAF; Mon, 26 Jan 2015 05:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.56 X-Spam-Level: X-Spam-Status: No, score=-8.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxNw6rdIc71w; Mon, 26 Jan 2015 05:57:14 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2341A8906; Mon, 26 Jan 2015 05:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23725; q=dns/txt; s=iport; t=1422280634; x=1423490234; h=from:to:cc:subject:date:message-id:mime-version; bh=pOyfZNmM6rx9IYl40l7he6UhxYdZ00yKPlVFkInWUsE=; b=YpCKbmdP2hytrc6R8BvdC95OiAt6EqxAc9mz35zH/p5D5lE1EEx+Z72c 9sO9eZ/NKZ/+eYGAz5vmT79PNLzO00zaut+x+bcf1VJZeqn0/spk1nSMz gJu4Tf3NUrbzfyXsGxzLsoK4i7adeHJigto3xLWctsmPqN/OyRX4kv4OJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DkBQAHR8ZU/4MNJK1agkNDUlkEgnzDNgEJhSdKAhx8QwEBAQEBfYQMAQEBBAEBAWsLEgEGAhEBAgECFg4EBQQfBgsUAwMDCgQBDQWIGAMRDaIWnGYIjw4NhQ4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBI1Ogg8KDQQGC4JagUUFjQ2BYYdcgUWBFYJ/iDKCOYM9IoIygTxvgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,469,1418083200"; d="scan'208,217";a="117571384" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 26 Jan 2015 13:57:13 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t0QDvD13008622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Jan 2015 13:57:13 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.144]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 07:57:12 -0600 From: "Acee Lindem (acee)" To: Lizhenbin , Robert Raszuk Thread-Topic: =?gb2312?B?tPC4tDogW3NwcmluZ10gtPC4tDogIE5ldyBDb21tZW50cyBvbiBTZWdtZW50?= =?gb2312?B?IFJvdXRpbmcoNCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBEZXBlbmRlbmN5IGZv?= =?gb2312?Q?r_SR-BE_Path?= Thread-Index: AQHQOW/72sceR5fD3UaIHxskBX26+w== Date: Mon, 26 Jan 2015 13:57:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D0EBB113C426aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [mpls] =?gb2312?b?tPC4tDogW3NwcmluZ10gtPC4tDogIE5ldyBDb21tZW50?= =?gb2312?b?cyBvbiBTZWdtZW50IFJvdXRpbmcoNCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBE?= =?gb2312?b?ZXBlbmRlbmN5IGZvciBTUi1CRSBQYXRo?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 13:57:17 -0000 --_000_D0EBB113C426aceeciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iaW4sDQoNCkZyb206IExpemhlbmJpbiA8bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRv OmxpemhlbmJpbkBodWF3ZWkuY29tPj4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSAyNiwgMjAxNSBh dCA2OjExIEFNDQpUbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNp c2NvLmNvbT4+LCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0 QHJhc3p1ay5uZXQ+Pg0KQ2M6ICJtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiIg PG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PiwgInNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPj4NClN1YmplY3Q6ILTwuLQ6IFtzcHJpbmddILTwuLQ6IE5ldyBDb21tZW50cyBvbiBT ZWdtZW50IFJvdXRpbmcoNCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBEZXBlbmRlbmN5IGZvciBTUi1C RSBQYXRoDQoNCg0KSGkgQWNlZSwNCg0KSSBkb24ndCB0aGluayBteSBwcm9wb3NlZCBpc3N1ZXMg aXMgdGhlIHNhbWUgY2FzZSBhcyB5b3UgcHJvcG9zZWQuIEkgdGhpbmsgeW91ciBwcm9wb3NlZCBj YXNlIGlzIGxpa2UgZm9yd2FyZGluZyBhZ2VuY3kgb3IgSUdQIHNob3J0LWN1dCB1c2luZyB0dW5u ZWwgYXMgdGhlIGludGVyZmFjZSB0byBoaWRlIHRoZSBNUExTIGZyb20gdGhlIE9TUEYuICBNeSBj YXNlIGlzIHRoZSBTUi1CRSBwYXRoIGluIHdoaWNoIE9TUEYgaXMgbGlrZSBMRFAgYXMgb25lIE1Q TFMgY29udHJvbCBwcm90b2NvbCB0byBsb29wIHVwIHRoZSByb3V0ZSB0byBkZXRlcm1pbmUgdGhl IG91dGdvdGluZyBpbnRlcmZhY2UgYW5kIHRoZSBuZXh0aG9wIGZvciB0aGUgbGFiZWwgbWFwcGlu ZyBhZHZlcnRpc2VkIGJ5IE9TUEYncyBzZWxmIGluc3RlYWQgb2YgaGlkaW5nIHRoZSBsYWJlbCBp biB0aGUgdHVubmVsLg0KDQpSaWdodCAtIGFuZCBteSBwb2ludCBpcyB0aGF0IG5vcm1hbGx5IE9T UEYgd291bGQgb25seSBjb25zaWRlciBPU1BGIHJvdXRlcyBpbiB0aGlzIGNhc2UuDQoNClRoYW5r cywNCkFjZWUNCg0KDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQoNCg0KDQoNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEFjZWUgTGluZGVt IChhY2VlKSBbYWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPl0NCreiy83Ksbzk OiAyMDE1xOox1MIyMsjVIDIyOjE1DQrK1bz+yMs6IExpemhlbmJpbjsgUm9iZXJ0IFJhc3p1aw0K s63LzTogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K1vfM4jogUmU6IFtzcHJpbmddILTwuLQ6IE5ldyBD b21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoNCk6IENoYWxsZW5nZSBvZiBSb3V0ZSBEZXBlbmRl bmN5IGZvciBTUi1CRSBQYXRoDQoNCkhpIFJvYmluLA0KSSBkb26hr3Qga25vdyBhYm91dCBvdGhl ciBJR1AgaW1wbGVtZW50YXRpb25zIGJ1dCB0aGUgb25lcyBJoa92ZSB3b3JrZWQgb24gZG8gbm90 IHJlc29sdmUgcm91dGVzIHJlY3Vyc2l2ZWx5ICh1bmxpa2UgTERQIG9yIEJHUCB3aGljaCBkbyku ICBUaGVyZSBhcmUgY2FzZXMgd2hlcmUgT1NQRiBydW5zIG92ZXIgYSB0dW5uZWwgYnV0IGluIHRo ZXNlIGNhc2VzIHRoZSBPU1BGIGludGVyZmFjZSBpcyBlaXRoZXIgdXAgb3IgZG93biBkZXBlbmRl bnQgb24gdGhlIHR1bm5lbCBzdGF0dXMuIEhlbmNlLCBJIHRoaW5rIHRoZSBpc3N1ZSB5b3Whr3Zl IHJhaXNlZCByZWdhcmRpbmcgcHJvdG9jb2wgc3luY2hyb25pemF0aW9uIGlzIGEgbW9vdCBwb2lu dC4NClRoYW5rcywNCkFjZWUNCg0KRnJvbTogTGl6aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNv bTxtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIEphbnVhcnkg MjIsIDIwMTUgYXQgNjowOCBBTQ0KVG86IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0 PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQpDYzogIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+LCAic3By aW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IiA8c3ByaW5nQGlldGYub3JnPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NwcmluZ10gtPC4tDogTmV3IENvbW1l bnRzIG9uIFNlZ21lbnQgUm91dGluZyg0KTogQ2hhbGxlbmdlIG9mIFJvdXRlIERlcGVuZGVuY3kg Zm9yIFNSLUJFIFBhdGgNCg0KDQpIaSBSb2JlcnQsDQoNClBsZWFzZSByZWZlciB0byBteSBpbmxp bmUgJ1tSb2Jpbl0nLg0KDQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJy YXN6dWtAZ21haWwuY29tPiBbcnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwu Y29tPl0gtPqx7SBSb2JlcnQgUmFzenVrIFtyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0 QHJhc3p1ay5uZXQ+XQ0Kt6LLzcqxvOQ6IDIwMTXE6jHUwjIyyNUgMTU6NDYNCsrVvP7IyzogTGl6 aGVuYmluDQqzrcvNOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQrW98ziOiBSZTogW3NwcmluZ10gTmV3 IENvbW1lbnRzIG9uIFNlZ21lbnQgUm91dGluZyg0KTogQ2hhbGxlbmdlIG9mIFJvdXRlIERlcGVu ZGVuY3kgZm9yIFNSLUJFIFBhdGgNCg0KSGkgUm9iaW4sDQoNCkkgdGhpbmsgeW91ciBxdWVzdGlv biBpcyBub3QgYXBwbGljYWJsZSB0byBTUiBhcmNoaXRlY3R1cmUuDQoNClRoZSByaWdodCBTUiBh bmFsb2d5IHRvIExEUCB3b3VsZCAqTk9UKiBiZSBob3AgYnkgaG9wIExEUCBsaWtlIGluIHlvdXIg ZXhhbXBsZSwgYnV0IHRhcmdldGVkIChha2EgZGlyZWN0ZWQpIExEUCBzZXNzaW9uLg0KW1JvYmlu XSBJIGNvdWxkIG5vdCB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuIE5vIG1hdHRlciBULUxEUCBvciBs b2NhbCBMRFAsIHRoZXkgc2hvdWxkIGxvb2t1cCBpbiB0aGUgUklCL0ZJQiB0byBkZXRlcm1pbmUg aWYgdGhlIGxhYmVsIG1hcHBpbmcgaXMgYWN0aXZlLg0KSW4gdGhvc2UgaG93IHRvIGdldCB0byBG RUMncyBhZGRyZXNzIGlzIGp1c3QgcmVndWxhciBsb29rdXAgaW4gdGhlIFJJQi9GSUIgKGdsb2Jh bCBvciB2cmYgZGVwZW5kcyBvbiB1c2UgY2FzZSkgYW5kIGl0IGRvZXMgbm90IG1hdHRlciB3aGF0 IHByb3RvY29sIHNyYyBpbnN0YWxsZWQgdGhlIHJvdXRlLg0KW1JvYmluXSBBcyB3aGF0IHlvdSBk ZXNjcmliZWQsIGNvdWxkIEkgdW5kZXJzdGFuZCB5b3UgbWVhbnMgZm9yIHRoZSBTUiBiYXNlZCBv biBhIHNwZWNpZmljIElHUChlLmcuIE9TUEYpLCBpdCBzaG91bGQgbG9vayB1cCBpbiB0aGUgUklC L0ZJQiB0byBkZXRlcm1pbmUgaWYgdGhlIGxhYmVsIGJpbmRpbmcgaXMgdXA/IElmIHNvLCB0aGVy ZSB3aWxsIGJlIHRoZSB0d28gcm91dGUgZGVwZW5kZW5jeSBjaGFuZ2UgaXNzdWVzIEkgcHJvcG9z ZWQgZm9yIHRoZSBPU1BGLiBXaHkgZG8geW91IHRoaW5rIHRoZXkgYXJlIG5vdCBhcHBsaWNhYmxl IHRvIFNSPw0KDQoNCkFsc28gbm90ZSB0aGF0IGxpa2UgaW4gbW9zdCBMRFAgY2FzZSBTUiAibGFi ZWxzIiBvciAiSURzIiBhcmUgZ2xvYmFsIHNvIHJlZ2FyZGxlc3Mgb24gd2hpY2ggaW50ZXJmYWNl IHBhY2tldCBhcnJpdmVzICh3aXRoaW4gZ2l2ZW4gdG9wb2xvZ3kgaW4gY2FzZSBvZiBtdCkgdGhl IGxvb2t1cCByZXN1bHQgd2lsbCBiZSBpZGVudGljYWwuDQoNClJncywNClIuDQoNCg0KT24gVGh1 LCBKYW4gMjIsIDIwMTUgYXQgNjowNyBBTSwgTGl6aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNv bTxtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgYWxsIGF1dGhvcnMg b2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgZm91cnRoIGNvbW1lbnRzLg0K DQoNCg0KRm9yIExEUCwgd2hlbiBzZWFyY2ggcm91dGUgZm9yIHRoZSBkZXN0aW5hdGlvbiBhZGRy ZXNzIHdoaWNoIGlzIHRoZSBGRUMgb2YgdGhlIGxhYmVsIG1hcHBpbmcsIGl0IHNob3VsZCBzZWFy Y2gNCnRoZSBGSUIgaW4gd2hpY2ggdGhlIHJvdXRlcyBhcmUgc2VsZWN0ZWQgZnJvbSB0aGUgc3Rh dGljIHJvdXRlLCBPU1BGLCBJU0lTLCBCR1AsIGV0YyBiYXNlZCBvbiB0aGUgcHJlZmVyZW5jZXMu DQpOb3cgdGhlcmUgaXMgb25lIHF1ZXN0aW9uIGZvciBTUi1CRSBwYXRoLCBmb3IgZXhhbXBsZSwg aWYgdGhlIFNJRC9MYWJlbCBpcyBhZHZlcnRpc2VkIHRocm91Z2ggT1NQRiwgd2hhdCB0eXBlDQoN Cm9mIHJvdXRlcyBzaG91bGQgdGhlIGxhYmVsIG1hcHBpbmcgZGVwZW5kIG9uIHdoZW4gc2V0dXAg dGhlIFNSLUJFIHBhdGg/DQoNCg0KDQpJIHRoaW5rIHRoZXJlIG1heSBiZSB0d28gY2hvaWNlczoN CjEuIE9ubHkgZGVwZW5kIG9uIHRoZSBPU1BGJ3Mgb3duIHJvdXRlOw0KMi4gTGlrZSB0aGUgTERQ LCBkZXBlbmRzIG9uIHRoZSBzZWxlY3RlZCByb3V0ZS4NCg0KDQoNCkkgZG9uJ3QgdGhpbmsgaXQg c2hvdWxkIGJlIHRoZSBPcHRpb24gMS4gRm9yIGV4YW1wbGUsIHdlIGNvbmZpZ3VyZSBzdGF0aWMg cm91dGVzIGZvciBhbGwgbm9kZXMgYWxvbmcgdGhlIHBhdGggdG8NCmEgc3BlY2lmaWMgbm9kZSB3 aGljaCBjYW4gYmUgdG90YWxseSBkaWZmZXJlbnQgZnJvbSB0aGUgT1NQRiByb3V0ZXMgdG8gdGhl IG5vZGUuIElmIHRoZSBzdGF0aWMgcm91dGUgaGFzIGhpZ2hlcg0KcHJpb3JpdHkgdGhhbiB0aGUg T1NQRiBhbmQgdGhlIFNJRC9sYWJlbCBpcyBhZHZlcnRpc2VkIGJ5IE9TUEYgZGVwZW5kcyBvbiBP U1BGIHJvdXRlcywgdGhlcmUgd2lsbCBiZSB0aGUNCg0KaW5jb25zaXN0ZW5jeSBiZXR3ZWVuIHRo ZSBTUi1CRSBwYXRoIGFuZCB0aGUgcm91dGUgcGF0aC4NCg0KDQoNCklmIHRoZSBvcHRpb24gMiBp cyBhZG9wdGVkLCBpdCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0IHRoZSBsYWJlbCBtYXBwaW5nIGFu ZCB0aGUgcm91dGUgYXJlIGluIHRoZSBzYW1lIExTREIgd2hpY2gNCg0KY2FuIGJlIGVhc2lseSBz eW5jaHJvbml6ZWQuIFRoZXJlIGFyZSB0d28gY2hhbGxlbmdlczoNCjEuIFRoZSBkaXJlY3QgZWZm ZWN0IGZvciB0aGUgT1NQRiBpcyB0aGF0IGF0IHRoZSBiZWdpbm5pbmcgaXQganVzdCBkb3dubG9h ZHMgaXQgcm91dGVzIHRvIHRoZSBSSUIgZm9yIHRoZSByb3V0ZQ0Kc2VsZWN0aW9uLiBUaGF0IGlz LCBpdCBpcyB0aGUgc291cmNlIG9mIHRoZSByb3V0ZSBzZWxlY3Rpb24uIEJ1dCBub3cgb3dpbmcg dG8gU1ItQkUgcGF0aCwgaXQgaGFzIHRvIGRlcGVuZCBvbg0KDQp0aGUgcmVzdWx0IG9mIHRoZSBy b3V0ZSBzZWxlY3Rpb24uDQoyLiBPU1BGIFNSLUJFIHBhdGggbWF5IGRlcGVuZCBvbiB0aGUgcm91 dGVzIGZyb20gdGhlIHN0YXRpYyByb3V0ZSwgSVNJUywgQkdQLCBldGMuIEl0IGlzIGNsYWltZWQg dGhhdCB0aGUgU1IgY2FuDQpyZW1vdmUgdGhlIElHUC1MRFAgc3luYy4gQnV0IGFjY29yZGluZyB0 byB0aGlzIGFuYWx5c2lzLCBhcmUgdGhlcmUgdGhlIHBvc3NpYmxlIHJpc2sgd2UgaGF2ZSB0byBp bnRyb2R1Y2UgdGhlDQoNCk9TUEYtSVNJUyBzeW5jLCBPU1BGLVN0YXRpYyBSb3V0ZSBzeW5jLCBP U1BGLUJHUCBzeW5jPyBPciBkbyB5b3UganVzdCB0aGluayB0aGV5IGFyZSByYXJlIGNhc2VzIHdo aWNoIHNob3VsZCBub3QNCg0KIGJlIHRha2VuIGludG8gYWNjb3VudD8gSG9wZSB5b3UgaGF2ZSBo YWQgZW5vdWdoIGFuYWx5c2lzIG9uIHRoaXMgaXNzdWUuDQoNCg0KDQpBY2NvcmRpbmcgdG8gdGhl IGNvbW1lbnRzIG9uIHRoZSBkZXBlbmRlbmN5LCBJIGhvcGUgeW91IGNvdWxkIHNwZWNpZnkgY2xl YXJseSBpbiB0aGUgYXBwcm9wcmlhdGUgZHJhZnQgb2Ygc2VnbWVudA0KDQpyb3V0aW5nIGFzIHRv IGZvbGxvd3MgcXVlc3Rpb25zIGZvciBTUi1CRSBwYXRoIHdoaWNoIGlzIGhlbHBmdWwgZm9yIGlu dGVyb3BlcmFiaWxpdHk6DQotLSBkZXBlbmQgb24gdGhlIGxvbmdlc3QgbWF0Y2gsIG9yIGV4YWN0 IG1hdGNoLCBvciBib3RoLg0KLS0gZGVwbmVkIG9uIHRoZSBTUiBwcm90b2NvbCdzIG93biByb3V0 ZXMgb3IgdGhlIHJvdXRlIHNlbGVjdGlvbiByZXN1bHRlIGZyb20gbXVsdGlwbGUgc291cmNlcy4N Cg0KDQoNCg0KDQoNCg0KUmVnYXJkcywNClJvYmluDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5n QGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQoNCg== --_000_D0EBB113C426aceeciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Robin, 

From: Lizhenbin <lizhenbin@huawei.com>
Date: Monday, January 26, 2015 at 6= :11 AM
To: Acee Lindem <acee@cisco.com>, Robert Raszuk <robert@raszuk.net>
Cc: "mpls@ietf.org" <mpls@i= etf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: =B4=F0=B8=B4: [spring] =B4= =F0=B8=B4: New Comments on Segment Routing(4): Challenge of Route Dependenc= y for SR-BE Path

Hi Acee,

I don't think my proposed issues is the same case as you proposed. I thi= nk your proposed case is like forwarding agency or IGP short-cut using tunn= el as the interface to hide the MPLS from the OSPF.  My case is the SR= -BE path in which OSPF is like LDP as one MPLS control protocol to loop up the route to determine the outgoting = interface and the nexthop for the label mapping advertised by OSPF's self i= nstead of hiding the label in the tunnel.

Right - and my point is that normally OSPF would only consider OSPF ro= utes in this case.  

Thanks,
Acee


 

 

Regards,

Robin

 

 

 

 

=B7=A2=BC=FE=C8=CB: Acee Lindem (acee) [acee@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C222=C8=D5 22:15
=CA=D5=BC=FE=C8=CB: Lizhenbin; Robert Raszuk
=B3=AD=CB=CD: mpls@ietf.org; spring@ietf.org
=D6=F7=CC=E2: Re: [spring] =B4=F0=B8=B4: New Comments on Segment Rou= ting(4): Challenge of Route Dependency for SR-BE Path

Hi Robin, 
I don=A1=AFt know about other IGP implementations but the ones I=A1=AF= ve worked on do not resolve routes recursively (unlike LDP or BGP which do)= .  There are cases where OSPF runs over a tunnel but in these cases th= e OSPF interface is either up or down dependent on the tunnel status. Hence, I think the issue you=A1=AFve raised regardin= g protocol synchronization is a moot point. 
Thanks,
Acee 

From: Lizhenbin <lizhenbin@huawei.com> Date: Thursday, January 22, 2015 a= t 6:08 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: [spring] =B4=F0=B8=B4: Ne= w Comments on Segment Routing(4): Challenge of Route Dependency for SR-BE P= ath

Hi Robert,

Please refer to my inline '[Robin]'.

 

Regards,

Robin

 

=B7=A2=BC=FE=C8=CB:rraszuk@gmail.com [rraszuk@gmail.com] =B4=FA=B1=ED Robe= rt Raszuk [robert@rasz= uk.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C222=C8=D5 15:46
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: s= pring@ietf.org; mpls@ietf.org
=D6=F7=CC=E2: Re: [spring] New Comments on Segment Routing(4): Chall= enge of Route Dependency for SR-BE Path

Hi Robin,

I think your question is not applicable to SR architecture. 

The right SR analogy to LDP would *NOT* be hop by hop LDP like in your exam= ple, but targeted (aka directed) LDP session.
[Robin] I could not understand your point. No matter T-LDP or local LD= P, they should lookup in the RIB/FIB to determine if the label mapping is a= ctive.
In those how to get to FEC's address is just regular lookup in the RIB/FIB = (global or vrf depends on use case) and it does not matter what protocol sr= c installed the route. 
[Robin] As what you described, could I understand you means for the SR base= d on a specific IGP(e.g. OSPF), it should look up in the RIB/FIB to determi= ne if the label binding is up? If so, there will be the two route dependenc= y change issues I proposed for the OSPF. Why do you think they are not applicable to SR?
 
 
Also note that like in most LDP case SR "labels" or "IDs&quo= t; are global so regardless on which interface packet arrives (within given= topology in case of mt) the lookup result will be identical.

Rgs,
R.


On Thu, Jan 22, 2015 at 6:07 AM, Lizhenbin <lizhenbin@hua= wei.com> wrote:

Hi all authors of segment routing,

 

This is the fourth comments.

 

For LDP, when search route for the destination ad= dress which is the FEC of the label mapping, it should search
the FIB in which the routes are selected from the static route, OSPF, ISIS,= BGP, etc based on the preferences.
Now there is one question for SR-BE path, for example, if the SID/Label is = advertised through OSPF, what type

of routes should th= e label mapping depend on when setup the SR-BE path?

 

I think there may be two choices:
1. Only depend on the OSPF's own route;
2. Like the LDP, depends on the selected route.

 

I don't think it should be the Option 1. For exam= ple, we configure static routes for all nodes along the path to
a specific node which can be totally different from the OSPF routes to the = node. If the static route has higher
priority than the OSPF and the SID/label is advertised by OSPF depends= on OSPF routes, there will be the

inconsistency between the SR-BE path and the route path.

 

If the option 2 is adopted, it cannot be assumed = that the label mapping and the route are in the same LSDB which

can be easily synchronized. There are two challen= ges:
1. The direct effect for the OSPF is that at the beginning it just download= s it routes to the RIB for the route
selection. That is, it is the source of the route selection. But now owing = to SR-BE path, it has to depend on

the result of the route selection.
2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BG= P, etc. It is claimed that the SR can
remove the IGP-LDP sync. But according to this analysis, are there the poss= ible risk we have to introduce the

OSPF-ISIS sync, OSPF-Static Route sync, OSPF-BGP = sync? Or do you just think they are rare cases which should not

 be taken into account? Hope you have had en= ough analysis on this issue.

 

According to the comments on the depend= ency, I hope you could specify clearly in the appropriate draft of seg= ment

routing as to follows questions for SR-BE path wh= ich is helpful for interoperability:
-- depend on the longest match, or exact match, or both.
-- depned on the SR protocol's own routes or the route selection resulte fr= om multiple sources.

 

 

 

Regards,
Robin

 


_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring


 --_000_D0EBB113C426aceeciscocom_-- From nobody Mon Jan 26 11:59:44 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94E21AD368; Mon, 26 Jan 2015 11:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucYJ3YwzZtVg; Mon, 26 Jan 2015 11:59:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 367FB1AD363; Mon, 26 Jan 2015 11:59:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126195938.6289.68868.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 11:59:38 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 19:59:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping Authors : Elisa Bellagamba Gregory Mirsky Loa Andersson Pontus Skoldstrom Dave Ward John Drake Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09.txt Pages : 25 Date : 2015-01-26 Abstract: This specification describes the configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP-Ping protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 26 22:27:58 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B103C1B2BA7; Mon, 26 Jan 2015 22:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.783 X-Spam-Level: X-Spam-Status: No, score=0.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmoU0Lnj53rh; Mon, 26 Jan 2015 22:27:55 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2300C1A008C; Mon, 26 Jan 2015 22:27:55 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BEC80180155B; Tue, 27 Jan 2015 07:27:51 +0100 (CET) Message-ID: <54C72FE0.40502@pi.nu> Date: Tue, 27 Jan 2015 14:27:44 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alexander Vainshtein , Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> In-Reply-To: <1422253291241.41262@ecitele.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 06:27:56 -0000 Sasha, On 2015-01-26 14:21, Alexander Vainshtein wrote: > Xiaohu, Huub, > I do not follow the SFC work closely, so I would like to understand whether the NSH should be captured by transit LSRs on the LSP - or just by the LER acting as the LSP tail-end? > > If the latter is correct, the simplest way to indicate presence of the NSH in the MPLS payload would be by allocating an "application label" indicating its presence by the tail-end LER and by inserting it at the bottom of the label stack by the head-end LER - similar to what is done for L2/L3VPN. Within this approach, if label-based demultiplexing of packets with NSH in the MPLS payload is not required, you could request allocation of a new special purpose label from the extended special purposes label space as per RFC 7274, and to insert such a label (preceded by the Extension Label ) at the BoS. > I think "the latter" is correct, the only issue I see is adding one more label stack entry to the label stack. /Loa > If the former is correct, the process above still has to be used but it has to be augmented by adding the Router Alert Label at the top of the label stack. > > From my POV these suggestions are in line with the provisions of Section 2.2 of RFC 3032 "Determining the Network Layer Protocol" that states: > > > When the last label is popped from a packet's label stack (resulting > in the stack being emptied), further processing of the packet is > based on the packet's network layer header. The LSR which pops the > last label off the stack must therefore be able to identify the > packet's network layer protocol. However, the label stack does not > contain any field which explicitly identifies the network layer > protocol. This means that the identity of the network layer protocol > must be inferable from the value of the label which is popped from > the bottom of the stack, possibly along with the contents of the > network layer header itself. > > > My 2c, > Sasha > ________________________________________ > From: mpls on behalf of Xuxiaohu > Sent: Monday, January 26, 2015 5:05 AM > To: huubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org > Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? > > Hi Huub, > > The alter label itself couldn¡¯t make the receiving LSR to determine the MPLS payload type by examining the MPLS payload. > > Best regards, > Xiaohu > >> -----Original Message----- >> From: Huub van Helvoort [mailto:huubatwork@gmail.com] >> Sent: Friday, January 23, 2015 6:28 PM >> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org >> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> Xuxiaohu ÄúºÃ£¡ >> >> Please correct me if I am wrong: >> >> It has always been my understanding that the MPLS header/label was >> independent of the protocol/payload. >> So no indication of the actual payload content was necessary. >> >> IMHO you could use the alert label 1 to indicate to the LSR that it has to further >> examine the content of a packet. >> >> Regards, Huub. >> >> ======== >> >>> It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): >>> >>> The service header is independent of the encapsulation used and is >>> encapsulated in existing transports. The presence of NSH is >>> indicated via protocol type or other indicator in the outer >>> encapsulation. >>> >>> In the case where the outer encapsulation is an MPLS LSP, how to indicate the >> presence of NSH since the MPLS encapsulation has no explicit protocol identifier >> field to indicate the protocol type of the MPLS payload? Should we make each >> SFF to allocate a unique label for indicating the presence of NSH? Or should we >> use the control word to indicate it? Or should we reconsider the possibility of >> adding an explicit protocol identifier field to the MPLS encapsulation so as to >> solve such kind of issues once and for all? >>> >>> Best regards, >>> Xiaohu >>> >> >> >> -- >> ************************************************************* >> **** >> Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jan 26 22:45:33 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958161A1A19; Mon, 26 Jan 2015 22:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGZnmeJx1-iK; Mon, 26 Jan 2015 22:45:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE6B1A1A0F; Mon, 26 Jan 2015 22:45:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT82744; Tue, 27 Jan 2015 06:45:24 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 06:45:23 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 14:45:18 +0800 From: Xuxiaohu To: Alexander Vainshtein , "huubatwork@gmail.com" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAP/94nYA Date: Tue, 27 Jan 2015 06:45:18 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> In-Reply-To: <1422253291241.41262@ecitele.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 06:45:29 -0000 SGkgU2FzaGEsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFu ZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0N Cj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0NCj4gVG86IFh1eGlhb2h1 OyBodXViYXR3b3JrQGdtYWlsLmNvbQ0KPiBDYzogc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBO U0ggaW4gYW4gTVBMUyBwYWNrZXQ/DQo+IA0KPiBYaWFvaHUsIEh1dWIsDQo+IEkgZG8gbm90IGZv bGxvdyB0aGUgU0ZDIHdvcmsgY2xvc2VseSwgc28gSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQg d2hldGhlciB0aGUNCj4gTlNIIHNob3VsZCBiZSBjYXB0dXJlZCBieSAgdHJhbnNpdCBMU1JzIG9u IHRoZSBMU1AgLSBvciBqdXN0IGJ5IHRoZSBMRVIgYWN0aW5nIGFzDQo+IHRoZSBMU1AgdGFpbC1l bmQ/DQo+IA0KPiBJZiB0aGUgbGF0dGVyIGlzIGNvcnJlY3QsIHRoZSBzaW1wbGVzdCB3YXkgdG8g aW5kaWNhdGUgcHJlc2VuY2Ugb2YgdGhlIE5TSCBpbiB0aGUNCj4gTVBMUyBwYXlsb2FkIHdvdWxk IGJlIGJ5IGFsbG9jYXRpbmcgYW4gImFwcGxpY2F0aW9uIGxhYmVsIiBpbmRpY2F0aW5nIGl0cw0K PiBwcmVzZW5jZSBieSB0aGUgdGFpbC1lbmQgTEVSIGFuZCBieSBpbnNlcnRpbmcgaXQgYXQgdGhl IGJvdHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sNCj4gYnkgdGhlIGhlYWQtZW5kIExFUiAtIHNpbWls YXIgdG8gd2hhdCBpcyBkb25lIGZvciBMMi9MM1ZQTi4gIFdpdGhpbiB0aGlzDQoNCklmIEkgdW5k ZXJzdGFuZCBpdCBjb3JyZWN0LCB0aGUgYWJvdmUgYXBwcm9hY2ggaXMgdGhlIHNhbWUgYXMgb3B0 aW9uIDEgYXMgSSBtZW50aW9uZWQgaW4gdGhlIGVhcmxpZXIgZW1haWwgKGkuZS4sIG1ha2luZyBl YWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVuaXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZyB0aGUNCnBy ZXNlbmNlIG9mIE5TSCkuDQoNCj4gYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRlbXVsdGlwbGV4 aW5nIG9mICBwYWNrZXRzIHdpdGggTlNIIGluIHRoZSBNUExTDQo+IHBheWxvYWQgaXMgbm90IHJl cXVpcmVkLCB5b3UgY291bGQgcmVxdWVzdCBhbGxvY2F0aW9uIG9mIGEgbmV3IHNwZWNpYWwgcHVy cG9zZQ0KPiBsYWJlbCBmcm9tIHRoZSBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2VzIGxhYmVsIHNw YWNlIGFzIHBlciBSRkMgNzI3NCwgYW5kIHRvDQo+IGluc2VydCBzdWNoIGEgbGFiZWwgKHByZWNl ZGVkIGJ5IHRoZSBFeHRlbnNpb24gTGFiZWwgKSBhdCB0aGUgQm9TLg0KDQpXaGF0J3MgdGhlIHB1 cnBvc2Ugb2YgaW5zZXJ0aW5nIGEgcGFydGljdWxhciBFU1AgbGFiZWwgYXQgdGhlIEJvUz8NCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gSWYgdGhlIGZvcm1lciBpcyBjb3JyZWN0LCB0aGUg cHJvY2VzcyBhYm92ZSBzdGlsbCBoYXMgdG8gYmUgdXNlZCBidXQgaXQgaGFzIHRvIGJlDQo+IGF1 Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBBbGVydCBMYWJlbCAgIGF0IHRoZSB0b3Agb2Yg dGhlIGxhYmVsIHN0YWNrLg0KPiANCj4gRnJvbSBteSBQT1YgdGhlc2Ugc3VnZ2VzdGlvbnMgYXJl IGluIGxpbmUgd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDIuMiBvZg0KPiBSRkMgMzAz MiAiRGV0ZXJtaW5pbmcgdGhlIE5ldHdvcmsgTGF5ZXIgUHJvdG9jb2wiIHRoYXQgc3RhdGVzOg0K PiANCj4gPHF1b3RlPg0KPiAgICBXaGVuIHRoZSBsYXN0IGxhYmVsIGlzIHBvcHBlZCBmcm9tIGEg cGFja2V0J3MgbGFiZWwgc3RhY2sgKHJlc3VsdGluZw0KPiAgICBpbiB0aGUgc3RhY2sgYmVpbmcg ZW1wdGllZCksIGZ1cnRoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0IGlzDQo+ICAgIGJhc2Vk IG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVyIGhlYWRlci4gIFRoZSBMU1Igd2hpY2ggcG9w cyB0aGUNCj4gICAgbGFzdCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11c3QgdGhlcmVmb3JlIGJlIGFi bGUgdG8gaWRlbnRpZnkgdGhlDQo+ICAgIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wu ICBIb3dldmVyLCB0aGUgbGFiZWwgc3RhY2sgZG9lcyBub3QNCj4gICAgY29udGFpbiBhbnkgZmll bGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVzIHRoZSBuZXR3b3JrIGxheWVyDQo+ICAgIHBy b3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBpZGVudGl0eSBvZiB0aGUgbmV0d29yayBsYXll ciBwcm90b2NvbA0KPiAgICBtdXN0IGJlIGluZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUg bGFiZWwgd2hpY2ggaXMgcG9wcGVkIGZyb20NCj4gICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ss IHBvc3NpYmx5IGFsb25nIHdpdGggdGhlIGNvbnRlbnRzIG9mIHRoZQ0KPiAgICBuZXR3b3JrIGxh eWVyIGhlYWRlciBpdHNlbGYuDQo+IDxlbmQgcXVvdGU+DQo+IA0KPiBNeSAyYywNCj4gU2FzaGEN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBtcGxz IDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBYdXhpYW9odQ0KPiA8eHV4aWFv aHVAaHVhd2VpLmNvbT4NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0N Cj4gVG86IGh1dWJhdHdvcmtAZ21haWwuY29tOyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5T SCBpbiBhbiBNUExTIHBhY2tldD8NCj4gDQo+IEhpIEh1dWIsDQo+IA0KPiBUaGUgYWx0ZXIgbGFi ZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZpbmcgTFNSIHRvIGRldGVybWluZSB0 aGUgTVBMUw0KPiBwYXlsb2FkIHR5cGUgYnkgZXhhbWluaW5nIHRoZSBNUExTIHBheWxvYWQuDQo+ IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFttYWlsdG86aHV1YmF0d29ya0Bn bWFpbC5jb21dDQo+ID4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDIzLCAyMDE1IDY6MjggUE0NCj4g PiBUbzogWHV4aWFvaHU7IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6 IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBM UyBwYWNrZXQ/DQo+ID4NCj4gPiBYdXhpYW9odSDE+rrDo6ENCj4gPg0KPiA+IFBsZWFzZSBjb3Jy ZWN0IG1lIGlmIEkgYW0gd3Jvbmc6DQo+ID4NCj4gPiBJdCBoYXMgYWx3YXlzIGJlZW4gbXkgdW5k ZXJzdGFuZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJlbCB3YXMNCj4gPiBpbmRlcGVuZGVu dCBvZiB0aGUgcHJvdG9jb2wvcGF5bG9hZC4NCj4gPiBTbyBubyBpbmRpY2F0aW9uIG9mIHRoZSBh Y3R1YWwgcGF5bG9hZCBjb250ZW50IHdhcyBuZWNlc3NhcnkuDQo+ID4NCj4gPiBJTUhPIHlvdSBj b3VsZCB1c2UgdGhlIGFsZXJ0IGxhYmVsIDEgdG8gaW5kaWNhdGUgdG8gdGhlIExTUiB0aGF0IGl0 DQo+ID4gaGFzIHRvIGZ1cnRoZXIgZXhhbWluZSB0aGUgY29udGVudCBvZiBhIHBhY2tldC4NCj4g Pg0KPiA+IFJlZ2FyZHMsIEh1dWIuDQo+ID4NCj4gPiA9PT09PT09PQ0KPiA+DQo+ID4gPiBJdCBz YWlkIGluIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLW5zaC0w NCk6DQo+ID4gPg0KPiA+ID4gICAgIFRoZSBzZXJ2aWNlIGhlYWRlciBpcyBpbmRlcGVuZGVudCBv ZiB0aGUgZW5jYXBzdWxhdGlvbiB1c2VkIGFuZCBpcw0KPiA+ID4gICAgIGVuY2Fwc3VsYXRlZCBp biBleGlzdGluZyB0cmFuc3BvcnRzLiAgVGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KPiA+ID4gICAg IGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91 dGVyDQo+ID4gPiAgICAgZW5jYXBzdWxhdGlvbi4NCj4gPiA+DQo+ID4gPiBJbiB0aGUgY2FzZSB3 aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBhbiBNUExTIExTUCwgaG93IHRvDQo+ID4g PiBpbmRpY2F0ZSB0aGUNCj4gPiBwcmVzZW5jZSBvZiBOU0ggc2luY2UgdGhlIE1QTFMgZW5jYXBz dWxhdGlvbiBoYXMgbm8gZXhwbGljaXQgcHJvdG9jb2wNCj4gPiBpZGVudGlmaWVyIGZpZWxkIHRv IGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBNUExTIHBheWxvYWQ/DQo+ID4gU2hv dWxkIHdlIG1ha2UgZWFjaCBTRkYgdG8gYWxsb2NhdGUgYSB1bmlxdWUgbGFiZWwgZm9yIGluZGlj YXRpbmcgdGhlDQo+ID4gcHJlc2VuY2Ugb2YgTlNIPyBPciBzaG91bGQgd2UgdXNlIHRoZSBjb250 cm9sIHdvcmQgdG8gaW5kaWNhdGUgaXQ/IE9yDQo+ID4gc2hvdWxkIHdlIHJlY29uc2lkZXIgdGhl IHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhbiBleHBsaWNpdCBwcm90b2NvbA0KPiA+IGlkZW50aWZp ZXIgZmllbGQgdG8gdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBzbyBhcyB0byBzb2x2ZSBzdWNoIGtp bmQgb2YgaXNzdWVzDQo+IG9uY2UgYW5kIGZvciBhbGw/DQo+ID4gPg0KPiA+ID4gQmVzdCByZWdh cmRzLA0KPiA+ID4gWGlhb2h1DQo+ID4gPg0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+DQo+ICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cj4gPiAqKioqDQo+ID4gICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOsvs3P 8cbky/vDv9K7uPbIy9K70fkNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From nobody Mon Jan 26 23:29:47 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8431B2BA8; Mon, 26 Jan 2015 23:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWnahzzuKYwE; Mon, 26 Jan 2015 23:29:44 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609991A88E2; Mon, 26 Jan 2015 23:29:43 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0810.eurprd03.prod.outlook.com (25.161.55.142) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 07:27:38 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 07:27:38 +0000 From: Alexander Vainshtein To: Xuxiaohu Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6FgAz0J4AAAFTF/U= Date: Tue, 27 Jan 2015 07:27:38 +0000 Message-ID: <1422343655626.35892@ecitele.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.40.145.154] authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0810; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0810; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(19580405001)(102836002)(15975445007)(2900100001)(2950100001)(19580395003)(117636001)(76176999)(54356999)(50986999)(77156002)(92566002)(62966003)(2656002)(87936001)(46102003)(93886004)(40100003)(66066001)(122556002)(36756003)(110136001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0810; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 07:27:38.1329 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0810 Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" , "huubatwork@gmail.com" Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 07:29:46 -0000 WGlhb2h1LApSZWdhcmRpbmcgeW91ciBxdWVzdGlvbjogIldoYXQncyB0aGUgcHVycG9zZSBvZiBp bnNlcnRpbmcgYSBwYXJ0aWN1bGFyIEVTUCBsYWJlbCBhdCB0aGUgQm9TPyIgCgpUaGlzIGlzIGFu IGFsdGVybmF0aXZlIHRvIGVhY2ggU0ZGIGFsbG9jYXRpbmcgYSB1bmlxdWUgYXBwbGljYXRpb24g bGFiZWwuIApUaGlzIGFsdGVybmF0aXZlIHdvdWxkIHdvcmsgaWYgZGVtdWx0aXBsZXhpbmcgb2Yg YSByZWNlaXZlZCBsYWJlbGVkIHBhY2tldCB3aXRoIE5TSCBoZWFkZXIgdG8gYSBzcGVjaWZpYyBT U0Ygd2l0aGluIHRoZSBwcm9jZXNzaW5nIG5vZGUgY2FuIGJlIGRvbmUgYmFzZWQgb24gdGhlIE5T SCBvbmx5LgpTYXZlcyB5b3UgdGhlIG5lZWQgdG8gYWxsb2NhdGUgYW5kIGRpc3RyaWJ1dGUgcGVy IFNTRiBsYWJlbHMuCgpIb3BlZnVsbHkgdGhpcyBhbnN3ZXJzIHlvdXIgcXVlc3Rpb24uCgpSZWdh cmRzLApTYXNoYSAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJv bTogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+ClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkg MjcsIDIwMTUgODo0NSBBTQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IGh1dWJhdHdvcmtAZ21h aWwuY29tCkNjOiBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcKU3ViamVjdDogUkU6IFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8K CkhpIFNhc2hhLAoKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IEFsZXhhbmRl ciBWYWluc2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dCj4g U2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0KPiBUbzogWHV4aWFvaHU7IGh1 dWJhdHdvcmtAZ21haWwuY29tCj4gQ2M6IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZwo+IFN1 YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4gTVBMUyBwYWNrZXQ/Cj4KPiBYaWFvaHUsIEh1dWIsCj4gSSBkbyBub3QgZm9sbG93IHRoZSBT RkMgd29yayBjbG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCB3aGV0aGVyIHRo ZQo+IE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0g b3IganVzdCBieSB0aGUgTEVSIGFjdGluZyBhcwo+IHRoZSBMU1AgdGFpbC1lbmQ/Cj4KPiBJZiB0 aGUgbGF0dGVyIGlzIGNvcnJlY3QsIHRoZSBzaW1wbGVzdCB3YXkgdG8gaW5kaWNhdGUgcHJlc2Vu Y2Ugb2YgdGhlIE5TSCBpbiB0aGUKPiBNUExTIHBheWxvYWQgd291bGQgYmUgYnkgYWxsb2NhdGlu ZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiIGluZGljYXRpbmcgaXRzCj4gcHJlc2VuY2UgYnkgdGhl IHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0IGF0IHRoZSBib3R0b20gb2YgdGhlIGxh YmVsIHN0YWNrCj4gYnkgdGhlIGhlYWQtZW5kIExFUiAtIHNpbWlsYXIgdG8gd2hhdCBpcyBkb25l IGZvciBMMi9MM1ZQTi4gIFdpdGhpbiB0aGlzCgpJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdCwg dGhlIGFib3ZlIGFwcHJvYWNoIGlzIHRoZSBzYW1lIGFzIG9wdGlvbiAxIGFzIEkgbWVudGlvbmVk IGluIHRoZSBlYXJsaWVyIGVtYWlsIChpLmUuLCBtYWtpbmcgZWFjaCBTRkYgdG8gYWxsb2NhdGUg YSB1bmlxdWUgbGFiZWwgZm9yIGluZGljYXRpbmcgdGhlCnByZXNlbmNlIG9mIE5TSCkuCgo+IGFw cHJvYWNoLCBpZiBsYWJlbC1iYXNlZCBkZW11bHRpcGxleGluZyBvZiAgcGFja2V0cyB3aXRoIE5T SCBpbiB0aGUgTVBMUwo+IHBheWxvYWQgaXMgbm90IHJlcXVpcmVkLCB5b3UgY291bGQgcmVxdWVz dCBhbGxvY2F0aW9uIG9mIGEgbmV3IHNwZWNpYWwgcHVycG9zZQo+IGxhYmVsIGZyb20gdGhlIGV4 dGVuZGVkIHNwZWNpYWwgcHVycG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJGQyA3Mjc0LCBhbmQg dG8KPiBpbnNlcnQgc3VjaCBhIGxhYmVsIChwcmVjZWRlZCBieSB0aGUgRXh0ZW5zaW9uIExhYmVs ICkgYXQgdGhlIEJvUy4KCldoYXQncyB0aGUgcHVycG9zZSBvZiBpbnNlcnRpbmcgYSBwYXJ0aWN1 bGFyIEVTUCBsYWJlbCBhdCB0aGUgQm9TPwoKQmVzdCByZWdhcmRzLApYaWFvaHUKCj4gSWYgdGhl IGZvcm1lciBpcyBjb3JyZWN0LCB0aGUgcHJvY2VzcyBhYm92ZSBzdGlsbCBoYXMgdG8gYmUgdXNl ZCBidXQgaXQgaGFzIHRvIGJlCj4gYXVnbWVudGVkIGJ5IGFkZGluZyB0aGUgUm91dGVyIEFsZXJ0 IExhYmVsICAgYXQgdGhlIHRvcCBvZiB0aGUgbGFiZWwgc3RhY2suCj4KPiBGcm9tIG15IFBPViB0 aGVzZSBzdWdnZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIFNlY3Rp b24gMi4yIG9mCj4gUkZDIDMwMzIgIkRldGVybWluaW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3Rv Y29sIiB0aGF0IHN0YXRlczoKPgo+IDxxdW90ZT4KPiAgICBXaGVuIHRoZSBsYXN0IGxhYmVsIGlz IHBvcHBlZCBmcm9tIGEgcGFja2V0J3MgbGFiZWwgc3RhY2sgKHJlc3VsdGluZwo+ICAgIGluIHRo ZSBzdGFjayBiZWluZyBlbXB0aWVkKSwgZnVydGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQg aXMKPiAgICBiYXNlZCBvbiB0aGUgcGFja2V0J3MgbmV0d29yayBsYXllciBoZWFkZXIuICBUaGUg TFNSIHdoaWNoIHBvcHMgdGhlCj4gICAgbGFzdCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11c3QgdGhl cmVmb3JlIGJlIGFibGUgdG8gaWRlbnRpZnkgdGhlCj4gICAgcGFja2V0J3MgbmV0d29yayBsYXll ciBwcm90b2NvbC4gIEhvd2V2ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5vdAo+ICAgIGNvbnRh aW4gYW55IGZpZWxkIHdoaWNoIGV4cGxpY2l0bHkgaWRlbnRpZmllcyB0aGUgbmV0d29yayBsYXll cgo+ICAgIHByb3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBpZGVudGl0eSBvZiB0aGUgbmV0 d29yayBsYXllciBwcm90b2NvbAo+ICAgIG11c3QgYmUgaW5mZXJhYmxlIGZyb20gdGhlIHZhbHVl IG9mIHRoZSBsYWJlbCB3aGljaCBpcyBwb3BwZWQgZnJvbQo+ICAgIHRoZSBib3R0b20gb2YgdGhl IHN0YWNrLCBwb3NzaWJseSBhbG9uZyB3aXRoIHRoZSBjb250ZW50cyBvZiB0aGUKPiAgICBuZXR3 b3JrIGxheWVyIGhlYWRlciBpdHNlbGYuCj4gPGVuZCBxdW90ZT4KPgo+IE15IDJjLAo+IFNhc2hh Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IEZyb206IG1wbHMg PG1wbHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFh1eGlhb2h1Cj4gPHh1eGlhb2h1 QGh1YXdlaS5jb20+Cj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0KPiBU bzogaHV1YmF0d29ya0BnbWFpbC5jb207IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZwo+IFN1 YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4gTVBMUyBwYWNrZXQ/Cj4KPiBIaSBIdXViLAo+Cj4gVGhlIGFsdGVyIGxhYmVsIGl0c2VsZiBj b3VsZG6hr3QgbWFrZSB0aGUgcmVjZWl2aW5nIExTUiB0byBkZXRlcm1pbmUgdGhlIE1QTFMKPiBw YXlsb2FkIHR5cGUgYnkgZXhhbWluaW5nIHRoZSBNUExTIHBheWxvYWQuCj4KPiBCZXN0IHJlZ2Fy ZHMsCj4gWGlhb2h1Cj4KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPiBGcm9tOiBI dXViIHZhbiBIZWx2b29ydCBbbWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tXQo+ID4gU2VudDog RnJpZGF5LCBKYW51YXJ5IDIzLCAyMDE1IDY6MjggUE0KPiA+IFRvOiBYdXhpYW9odTsgc2ZjQGll dGYub3JnOyBtcGxzQGlldGYub3JnCj4gPiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRp Y2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0Pwo+ID4KPiA+IFh1eGlh b2h1IMT6usOjoQo+ID4KPiA+IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3Jvbmc6Cj4gPgo+ ID4gSXQgaGFzIGFsd2F5cyBiZWVuIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgTVBMUyBoZWFk ZXIvbGFiZWwgd2FzCj4gPiBpbmRlcGVuZGVudCBvZiB0aGUgcHJvdG9jb2wvcGF5bG9hZC4KPiA+ IFNvIG5vIGluZGljYXRpb24gb2YgdGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vz c2FyeS4KPiA+Cj4gPiBJTUhPIHlvdSBjb3VsZCB1c2UgdGhlIGFsZXJ0IGxhYmVsIDEgdG8gaW5k aWNhdGUgdG8gdGhlIExTUiB0aGF0IGl0Cj4gPiBoYXMgdG8gZnVydGhlciBleGFtaW5lIHRoZSBj b250ZW50IG9mIGEgcGFja2V0Lgo+ID4KPiA+IFJlZ2FyZHMsIEh1dWIuCj4gPgo+ID4gPT09PT09 PT0KPiA+Cj4gPiA+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1xdWlubi1zZmMtbnNoLTA0KToKPiA+ID4KPiA+ID4gICAgIFRoZSBzZXJ2aWNlIGhlYWRlciBp cyBpbmRlcGVuZGVudCBvZiB0aGUgZW5jYXBzdWxhdGlvbiB1c2VkIGFuZCBpcwo+ID4gPiAgICAg ZW5jYXBzdWxhdGVkIGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBUaGUgcHJlc2VuY2Ugb2YgTlNI IGlzCj4gPiA+ICAgICBpbmRpY2F0ZWQgdmlhIHByb3RvY29sIHR5cGUgb3Igb3RoZXIgaW5kaWNh dG9yIGluIHRoZSBvdXRlcgo+ID4gPiAgICAgZW5jYXBzdWxhdGlvbi4KPiA+ID4KPiA+ID4gSW4g dGhlIGNhc2Ugd2hlcmUgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBMUyBMU1AsIGhv dyB0bwo+ID4gPiBpbmRpY2F0ZSB0aGUKPiA+IHByZXNlbmNlIG9mIE5TSCBzaW5jZSB0aGUgTVBM UyBlbmNhcHN1bGF0aW9uIGhhcyBubyBleHBsaWNpdCBwcm90b2NvbAo+ID4gaWRlbnRpZmllciBm aWVsZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUgTVBMUyBwYXlsb2FkPwo+ ID4gU2hvdWxkIHdlIG1ha2UgZWFjaCBTRkYgdG8gYWxsb2NhdGUgYSB1bmlxdWUgbGFiZWwgZm9y IGluZGljYXRpbmcgdGhlCj4gPiBwcmVzZW5jZSBvZiBOU0g/IE9yIHNob3VsZCB3ZSB1c2UgdGhl IGNvbnRyb2wgd29yZCB0byBpbmRpY2F0ZSBpdD8gT3IKPiA+IHNob3VsZCB3ZSByZWNvbnNpZGVy IHRoZSBwb3NzaWJpbGl0eSBvZiBhZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wKPiA+IGlkZW50 aWZpZXIgZmllbGQgdG8gdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBzbyBhcyB0byBzb2x2ZSBzdWNo IGtpbmQgb2YgaXNzdWVzCj4gb25jZSBhbmQgZm9yIGFsbD8KPiA+ID4KPiA+ID4gQmVzdCByZWdh cmRzLAo+ID4gPiBYaWFvaHUKPiA+ID4KPiA+Cj4gPgo+ID4gLS0KPiA+Cj4gKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo+ID4gKioq Kgo+ID4gICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOsvs3P8cbky/vDv9K7 uPbIy9K70fkKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+IG1wbHMgbWFpbGluZyBsaXN0Cj4gbXBsc0BpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscwo= From nobody Mon Jan 26 23:46:37 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F3C1B2BB9; Mon, 26 Jan 2015 23:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObjTugY7D6WQ; Mon, 26 Jan 2015 23:46:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEE81B2BCB; Mon, 26 Jan 2015 23:46:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL71401; Tue, 27 Jan 2015 07:46:09 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 07:46:09 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 15:46:00 +0800 From: Xuxiaohu To: Loa Andersson , Alexander Vainshtein Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAIABlBAA//9rmmA= Date: Tue, 27 Jan 2015 07:46:00 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> In-Reply-To: <54C72FE0.40502@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 07:46:32 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9hIEFuZGVyc3NvbiBb bWFpbHRvOmxvYUBwaS5udV0NCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAyOjI4 IFBNDQo+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgWHV4aWFvaHUNCj4gQ2M6IG1wbHNAaWV0 Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gW21wbHNdIEhvdyB0byBp bmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0Pw0KPiANCj4gU2Fz aGEsDQo+IA0KPiANCj4gDQo+IE9uIDIwMTUtMDEtMjYgMTQ6MjEsIEFsZXhhbmRlciBWYWluc2h0 ZWluIHdyb3RlOg0KPiA+IFhpYW9odSwgSHV1YiwNCj4gPiBJIGRvIG5vdCBmb2xsb3cgdGhlIFNG QyB3b3JrIGNsb3NlbHksIHNvIEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHdoZXRoZXIgdGhl DQo+IE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0g b3IganVzdCBieSB0aGUgTEVSIGFjdGluZyBhcw0KPiB0aGUgTFNQIHRhaWwtZW5kPw0KPiA+DQo+ ID4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2ltcGxlc3Qgd2F5IHRvIGluZGljYXRl IHByZXNlbmNlIG9mIHRoZSBOU0ggaW4gdGhlDQo+IE1QTFMgcGF5bG9hZCB3b3VsZCBiZSBieSBh bGxvY2F0aW5nIGFuICJhcHBsaWNhdGlvbiBsYWJlbCIgaW5kaWNhdGluZyBpdHMNCj4gcHJlc2Vu Y2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0IGF0IHRoZSBib3R0b20g b2YgdGhlIGxhYmVsIHN0YWNrDQo+IGJ5IHRoZSBoZWFkLWVuZCBMRVIgLSBzaW1pbGFyIHRvIHdo YXQgaXMgZG9uZSBmb3IgTDIvTDNWUE4uICBXaXRoaW4gdGhpcw0KPiBhcHByb2FjaCwgaWYgbGFi ZWwtYmFzZWQgZGVtdWx0aXBsZXhpbmcgb2YgIHBhY2tldHMgd2l0aCBOU0ggaW4gdGhlIE1QTFMN Cj4gcGF5bG9hZCBpcyBub3QgcmVxdWlyZWQsIHlvdSBjb3VsZCByZXF1ZXN0IGFsbG9jYXRpb24g b2YgYSBuZXcgc3BlY2lhbCBwdXJwb3NlDQo+IGxhYmVsIGZyb20gdGhlIGV4dGVuZGVkIHNwZWNp YWwgcHVycG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJGQyA3Mjc0LCBhbmQgdG8NCj4gaW5zZXJ0 IHN1Y2ggYSBsYWJlbCAocHJlY2VkZWQgYnkgdGhlIEV4dGVuc2lvbiBMYWJlbCApIGF0IHRoZSBC b1MuDQo+ID4NCj4gSSB0aGluayAidGhlIGxhdHRlciIgaXMgY29ycmVjdCwgdGhlIG9ubHkgaXNz dWUgSSBzZWUgaXMgYWRkaW5nIG9uZSBtb3JlIGxhYmVsIHN0YWNrDQo+IGVudHJ5IHRvIHRoZSBs YWJlbCBzdGFjay4NCg0KWWVzLCB0aGUgbGF0dGVyIGlzIGNvcnJlY3QuIFRoZSBpc3N1ZSBvZiBh ZGRpbmcgb25lIG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhlIGxhYmVsIHN0YWNrIG1heSBi ZWNvbWUgdW5hY2NlcHRhYmxlIGluIHRoZSBjYXNlIHdoZXJlIHRoZSBTZXJ2aWNlIEZ1bmN0aW9u IFBhdGggKFNGUCkgaXMgcmVwcmVzZW50ZWQgYnkgYW4gbGFiZWwgc3RhY2sgd2hpbGUgdGhlIE5T SCBpcyBub3cgb25seSB1c2VkIGFzIGEgbWV0YWRhdGEgY29udGFpbmVyLiBGb3IgZXhhbXBsZSwg Zm9yIGFuIFNGUCBjb25zaXN0IG9mIG4gU0ZzLCBuICJhcHBsaWNhdGlvbiBsYWJlbHMiIHdvdWxk IGhhdmUgdG8gYmUgaW5zZXJ0ZWQgaW50byB0aGUgbGFiZWwgc3RhY2suDQoNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KDQo+IC9Mb2ENCj4gPiBJZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRoZSBw cm9jZXNzIGFib3ZlIHN0aWxsIGhhcyB0byBiZSB1c2VkIGJ1dCBpdCBoYXMgdG8gYmUNCj4gYXVn bWVudGVkIGJ5IGFkZGluZyB0aGUgUm91dGVyIEFsZXJ0IExhYmVsICAgYXQgdGhlIHRvcCBvZiB0 aGUgbGFiZWwgc3RhY2suDQo+ID4NCj4gPiAgRnJvbSBteSBQT1YgdGhlc2Ugc3VnZ2VzdGlvbnMg YXJlIGluIGxpbmUgd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDIuMg0KPiBvZiBSRkMg MzAzMiAiRGV0ZXJtaW5pbmcgdGhlIE5ldHdvcmsgTGF5ZXIgUHJvdG9jb2wiIHRoYXQgc3RhdGVz Og0KPiA+DQo+ID4gPHF1b3RlPg0KPiA+ICAgICBXaGVuIHRoZSBsYXN0IGxhYmVsIGlzIHBvcHBl ZCBmcm9tIGEgcGFja2V0J3MgbGFiZWwgc3RhY2sgKHJlc3VsdGluZw0KPiA+ICAgICBpbiB0aGUg c3RhY2sgYmVpbmcgZW1wdGllZCksIGZ1cnRoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0IGlz DQo+ID4gICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVyIGhlYWRlci4gIFRo ZSBMU1Igd2hpY2ggcG9wcyB0aGUNCj4gPiAgICAgbGFzdCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11 c3QgdGhlcmVmb3JlIGJlIGFibGUgdG8gaWRlbnRpZnkgdGhlDQo+ID4gICAgIHBhY2tldCdzIG5l dHdvcmsgbGF5ZXIgcHJvdG9jb2wuICBIb3dldmVyLCB0aGUgbGFiZWwgc3RhY2sgZG9lcyBub3QN Cj4gPiAgICAgY29udGFpbiBhbnkgZmllbGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVzIHRo ZSBuZXR3b3JrIGxheWVyDQo+ID4gICAgIHByb3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBp ZGVudGl0eSBvZiB0aGUgbmV0d29yayBsYXllciBwcm90b2NvbA0KPiA+ICAgICBtdXN0IGJlIGlu ZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUgbGFiZWwgd2hpY2ggaXMgcG9wcGVkIGZyb20N Cj4gPiAgICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3NpYmx5IGFsb25nIHdpdGggdGhl IGNvbnRlbnRzIG9mIHRoZQ0KPiA+ICAgICBuZXR3b3JrIGxheWVyIGhlYWRlciBpdHNlbGYuDQo+ ID4gPGVuZCBxdW90ZT4NCj4gPg0KPiA+IE15IDJjLA0KPiA+IFNhc2hhDQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IG1wbHMgPG1wbHMtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFh1eGlhb2h1DQo+ID4gPHh1eGlhb2h1QGh1YXdl aS5jb20+DQo+ID4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0NCj4gPiBU bzogaHV1YmF0d29ya0BnbWFpbC5jb207IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KPiA+ IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0gg aW4gYW4gTVBMUyBwYWNrZXQ/DQo+ID4NCj4gPiBIaSBIdXViLA0KPiA+DQo+ID4gVGhlIGFsdGVy IGxhYmVsIGl0c2VsZiBjb3VsZG6hr3QgbWFrZSB0aGUgcmVjZWl2aW5nIExTUiB0byBkZXRlcm1p bmUgdGhlIE1QTFMNCj4gcGF5bG9hZCB0eXBlIGJ5IGV4YW1pbmluZyB0aGUgTVBMUyBwYXlsb2Fk Lg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFttYWlsdG86 aHV1YmF0d29ya0BnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAyMywgMjAx NSA2OjI4IFBNDQo+ID4+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3Jn DQo+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBv ZiBOU0ggaW4gYW4gTVBMUyBwYWNrZXQ/DQo+ID4+DQo+ID4+IFh1eGlhb2h1IMT6usOjoQ0KPiA+ Pg0KPiA+PiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nOg0KPiA+Pg0KPiA+PiBJdCBo YXMgYWx3YXlzIGJlZW4gbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJl bCB3YXMNCj4gPj4gaW5kZXBlbmRlbnQgb2YgdGhlIHByb3RvY29sL3BheWxvYWQuDQo+ID4+IFNv IG5vIGluZGljYXRpb24gb2YgdGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vzc2Fy eS4NCj4gPj4NCj4gPj4gSU1ITyB5b3UgY291bGQgdXNlIHRoZSBhbGVydCBsYWJlbCAxIHRvIGlu ZGljYXRlIHRvIHRoZSBMU1IgdGhhdCBpdA0KPiA+PiBoYXMgdG8gZnVydGhlciBleGFtaW5lIHRo ZSBjb250ZW50IG9mIGEgcGFja2V0Lg0KPiA+Pg0KPiA+PiBSZWdhcmRzLCBIdXViLg0KPiA+Pg0K PiA+PiA9PT09PT09PQ0KPiA+Pg0KPiA+Pj4gSXQgc2FpZCBpbiAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtMDQpOg0KPiA+Pj4NCj4gPj4+ICAgICAgVGhl IHNlcnZpY2UgaGVhZGVyIGlzIGluZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQg YW5kIGlzDQo+ID4+PiAgICAgIGVuY2Fwc3VsYXRlZCBpbiBleGlzdGluZyB0cmFuc3BvcnRzLiAg VGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KPiA+Pj4gICAgICBpbmRpY2F0ZWQgdmlhIHByb3RvY29s IHR5cGUgb3Igb3RoZXIgaW5kaWNhdG9yIGluIHRoZSBvdXRlcg0KPiA+Pj4gICAgICBlbmNhcHN1 bGF0aW9uLg0KPiA+Pj4NCj4gPj4+IEluIHRoZSBjYXNlIHdoZXJlIHRoZSBvdXRlciBlbmNhcHN1 bGF0aW9uIGlzIGFuIE1QTFMgTFNQLCBob3cgdG8NCj4gPj4+IGluZGljYXRlIHRoZQ0KPiA+PiBw cmVzZW5jZSBvZiBOU0ggc2luY2UgdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBoYXMgbm8gZXhwbGlj aXQgcHJvdG9jb2wNCj4gPj4gaWRlbnRpZmllciBmaWVsZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9j b2wgdHlwZSBvZiB0aGUgTVBMUyBwYXlsb2FkPw0KPiA+PiBTaG91bGQgd2UgbWFrZSBlYWNoIFNG RiB0byBhbGxvY2F0ZSBhIHVuaXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZyB0aGUNCj4gPj4gcHJl c2VuY2Ugb2YgTlNIPyBPciBzaG91bGQgd2UgdXNlIHRoZSBjb250cm9sIHdvcmQgdG8gaW5kaWNh dGUgaXQ/IE9yDQo+ID4+IHNob3VsZCB3ZSByZWNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZiBh ZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wNCj4gPj4gaWRlbnRpZmllciBmaWVsZCB0byB0aGUg TVBMUyBlbmNhcHN1bGF0aW9uIHNvIGFzIHRvIHNvbHZlIHN1Y2gga2luZCBvZiBpc3N1ZXMNCj4g b25jZSBhbmQgZm9yIGFsbD8NCj4gPj4+DQo+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+PiBYaWFv aHUNCj4gPj4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tDQo+ID4+DQo+ICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPj4gKioqKg0K PiA+PiAgICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOsvs3P8cbky/vDv9K7 uPbIy9K70fkNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc2ZjIG1haWxpbmcgbGlzdA0K PiA+IHNmY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+ID4NCj4gDQo+IC0tDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAg ICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gU2VuaW9yIE1QTFMg RXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4gSHVhd2VpIFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From nobody Mon Jan 26 23:49:34 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034161B2BB6; Mon, 26 Jan 2015 23:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ19xl6ATiHB; Mon, 26 Jan 2015 23:49:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE871B2BBA; Mon, 26 Jan 2015 23:49:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT88802; Tue, 27 Jan 2015 07:49:26 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 07:49:25 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 15:49:20 +0800 From: Xuxiaohu To: Alexander Vainshtein Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAP/94nYAgAPCVgD//3Rm4A== Date: Tue, 27 Jan 2015 07:49:19 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08302093@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> <1422343655626.35892@ecitele.com> In-Reply-To: <1422343655626.35892@ecitele.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" , "huubatwork@gmail.com" Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 07:49:31 -0000 SGkgU2FzaGEsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFu ZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0N Cj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAzOjI4IFBNDQo+IFRvOiBYdXhpYW9o dQ0KPiBDYzogc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBodXViYXR3b3JrQGdtYWlsLmNv bQ0KPiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2Yg TlNIIGluIGFuIE1QTFMgcGFja2V0Pw0KPiANCj4gWGlhb2h1LA0KPiBSZWdhcmRpbmcgeW91ciBx dWVzdGlvbjogIldoYXQncyB0aGUgcHVycG9zZSBvZiBpbnNlcnRpbmcgYSBwYXJ0aWN1bGFyIEVT UCBsYWJlbA0KPiBhdCB0aGUgQm9TPyINCj4gDQo+IFRoaXMgaXMgYW4gYWx0ZXJuYXRpdmUgdG8g ZWFjaCBTRkYgYWxsb2NhdGluZyBhIHVuaXF1ZSBhcHBsaWNhdGlvbiBsYWJlbC4NCj4gVGhpcyBh bHRlcm5hdGl2ZSB3b3VsZCB3b3JrIGlmIGRlbXVsdGlwbGV4aW5nIG9mIGEgcmVjZWl2ZWQgbGFi ZWxlZCBwYWNrZXQgd2l0aA0KPiBOU0ggaGVhZGVyIHRvIGEgc3BlY2lmaWMgU1NGIHdpdGhpbiB0 aGUgcHJvY2Vzc2luZyBub2RlIGNhbiBiZSBkb25lIGJhc2VkIG9uDQo+IHRoZSBOU0ggb25seS4N Cj4gU2F2ZXMgeW91IHRoZSBuZWVkIHRvIGFsbG9jYXRlIGFuZCBkaXN0cmlidXRlIHBlciBTU0Yg bGFiZWxzLg0KDQpEaWQgeW91IG1lYW4gdG8gdXNlIGEgcGFydGljdWxhciBFU1AgbGFiZWwgdG8g aW5kaWNhdGUgYSBnaXZlbiBNUExTIHBheWxvYWQgdHlwZSAoZS5nLiwgTlNIKT8NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCj4gSG9wZWZ1bGx5IHRoaXMgYW5zd2VycyB5b3VyIHF1ZXN0aW9u Lg0KPiANCj4gUmVnYXJkcywNCj4gU2FzaGENCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gRnJvbTogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+ DQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjcsIDIwMTUgODo0NSBBTQ0KPiBUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW47IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+IENjOiBzZmNAaWV0Zi5vcmc7 IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhl IHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8NCj4gDQo+IEhpIFNhc2hhLA0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEFsZXhhbmRlciBWYWlu c2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQo+ID4gU2Vu dDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0NCj4gPiBUbzogWHV4aWFvaHU7IGh1 dWJhdHdvcmtAZ21haWwuY29tDQo+ID4gQ2M6IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0K PiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBO U0ggaW4gYW4gTVBMUyBwYWNrZXQ/DQo+ID4NCj4gPiBYaWFvaHUsIEh1dWIsDQo+ID4gSSBkbyBu b3QgZm9sbG93IHRoZSBTRkMgd29yayBjbG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8gdW5kZXJz dGFuZA0KPiA+IHdoZXRoZXIgdGhlIE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQg TFNScyBvbiB0aGUgTFNQIC0gb3INCj4gPiBqdXN0IGJ5IHRoZSBMRVIgYWN0aW5nIGFzIHRoZSBM U1AgdGFpbC1lbmQ/DQo+ID4NCj4gPiBJZiB0aGUgbGF0dGVyIGlzIGNvcnJlY3QsIHRoZSBzaW1w bGVzdCB3YXkgdG8gaW5kaWNhdGUgcHJlc2VuY2Ugb2YgdGhlDQo+ID4gTlNIIGluIHRoZSBNUExT IHBheWxvYWQgd291bGQgYmUgYnkgYWxsb2NhdGluZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiDQo+ ID4gaW5kaWNhdGluZyBpdHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5z ZXJ0aW5nIGl0IGF0IHRoZQ0KPiA+IGJvdHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sgYnkgdGhlIGhl YWQtZW5kIExFUiAtIHNpbWlsYXIgdG8gd2hhdCBpcw0KPiA+IGRvbmUgZm9yIEwyL0wzVlBOLiAg V2l0aGluIHRoaXMNCj4gDQo+IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0LCB0aGUgYWJvdmUg YXBwcm9hY2ggaXMgdGhlIHNhbWUgYXMgb3B0aW9uIDEgYXMgSQ0KPiBtZW50aW9uZWQgaW4gdGhl IGVhcmxpZXIgZW1haWwgKGkuZS4sIG1ha2luZyBlYWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVuaXF1 ZSBsYWJlbA0KPiBmb3IgaW5kaWNhdGluZyB0aGUgcHJlc2VuY2Ugb2YgTlNIKS4NCj4gDQo+ID4g YXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRlbXVsdGlwbGV4aW5nIG9mICBwYWNrZXRzIHdpdGgg TlNIIGluIHRoZQ0KPiA+IE1QTFMgcGF5bG9hZCBpcyBub3QgcmVxdWlyZWQsIHlvdSBjb3VsZCBy ZXF1ZXN0IGFsbG9jYXRpb24gb2YgYSBuZXcNCj4gPiBzcGVjaWFsIHB1cnBvc2UgbGFiZWwgZnJv bSB0aGUgZXh0ZW5kZWQgc3BlY2lhbCBwdXJwb3NlcyBsYWJlbCBzcGFjZQ0KPiA+IGFzIHBlciBS RkMgNzI3NCwgYW5kIHRvIGluc2VydCBzdWNoIGEgbGFiZWwgKHByZWNlZGVkIGJ5IHRoZSBFeHRl bnNpb24gTGFiZWwgKQ0KPiBhdCB0aGUgQm9TLg0KPiANCj4gV2hhdCdzIHRoZSBwdXJwb3NlIG9m IGluc2VydGluZyBhIHBhcnRpY3VsYXIgRVNQIGxhYmVsIGF0IHRoZSBCb1M/DQo+IA0KPiBCZXN0 IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiBJZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRo ZSBwcm9jZXNzIGFib3ZlIHN0aWxsIGhhcyB0byBiZSB1c2VkIGJ1dCBpdCBoYXMgdG8gYmUNCj4g PiBhdWdtZW50ZWQgYnkgYWRkaW5nIHRoZSBSb3V0ZXIgQWxlcnQgTGFiZWwgICBhdCB0aGUgdG9w IG9mIHRoZSBsYWJlbCBzdGFjay4NCj4gPg0KPiA+IEZyb20gbXkgUE9WIHRoZXNlIHN1Z2dlc3Rp b25zIGFyZSBpbiBsaW5lIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YNCj4gPiBTZWN0aW9uIDIuMiBv ZiBSRkMgMzAzMiAiRGV0ZXJtaW5pbmcgdGhlIE5ldHdvcmsgTGF5ZXIgUHJvdG9jb2wiIHRoYXQN Cj4gc3RhdGVzOg0KPiA+DQo+ID4gPHF1b3RlPg0KPiA+ICAgIFdoZW4gdGhlIGxhc3QgbGFiZWwg aXMgcG9wcGVkIGZyb20gYSBwYWNrZXQncyBsYWJlbCBzdGFjayAocmVzdWx0aW5nDQo+ID4gICAg aW4gdGhlIHN0YWNrIGJlaW5nIGVtcHRpZWQpLCBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBh Y2tldCBpcw0KPiA+ICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVyIGhlYWRl ci4gIFRoZSBMU1Igd2hpY2ggcG9wcyB0aGUNCj4gPiAgICBsYXN0IGxhYmVsIG9mZiB0aGUgc3Rh Y2sgbXVzdCB0aGVyZWZvcmUgYmUgYWJsZSB0byBpZGVudGlmeSB0aGUNCj4gPiAgICBwYWNrZXQn cyBuZXR3b3JrIGxheWVyIHByb3RvY29sLiAgSG93ZXZlciwgdGhlIGxhYmVsIHN0YWNrIGRvZXMg bm90DQo+ID4gICAgY29udGFpbiBhbnkgZmllbGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVz IHRoZSBuZXR3b3JrIGxheWVyDQo+ID4gICAgcHJvdG9jb2wuICBUaGlzIG1lYW5zIHRoYXQgdGhl IGlkZW50aXR5IG9mIHRoZSBuZXR3b3JrIGxheWVyIHByb3RvY29sDQo+ID4gICAgbXVzdCBiZSBp bmZlcmFibGUgZnJvbSB0aGUgdmFsdWUgb2YgdGhlIGxhYmVsIHdoaWNoIGlzIHBvcHBlZCBmcm9t DQo+ID4gICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3NpYmx5IGFsb25nIHdpdGggdGhl IGNvbnRlbnRzIG9mIHRoZQ0KPiA+ICAgIG5ldHdvcmsgbGF5ZXIgaGVhZGVyIGl0c2VsZi4NCj4g PiA8ZW5kIHF1b3RlPg0KPiA+DQo+ID4gTXkgMmMsDQo+ID4gU2FzaGENCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRnJvbTogbXBscyA8bXBscy1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgWHV4aWFvaHUNCj4gPiA8eHV4aWFvaHVAaHVhd2Vp LmNvbT4NCj4gPiBTZW50OiBNb25kYXksIEphbnVhcnkgMjYsIDIwMTUgNTowNSBBTQ0KPiA+IFRv OiBodXViYXR3b3JrQGdtYWlsLmNvbTsgc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+ID4g U3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBp biBhbiBNUExTIHBhY2tldD8NCj4gPg0KPiA+IEhpIEh1dWIsDQo+ID4NCj4gPiBUaGUgYWx0ZXIg bGFiZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZpbmcgTFNSIHRvIGRldGVybWlu ZQ0KPiA+IHRoZSBNUExTIHBheWxvYWQgdHlwZSBieSBleGFtaW5pbmcgdGhlIE1QTFMgcGF5bG9h ZC4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFttYWls dG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQo+ID4gPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMjMs IDIwMTUgNjoyOCBQTQ0KPiA+ID4gVG86IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0 Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVz ZW5jZSBvZiBOU0ggaW4gYW4gTVBMUyBwYWNrZXQ/DQo+ID4gPg0KPiA+ID4gWHV4aWFvaHUgxPq6 w6OhDQo+ID4gPg0KPiA+ID4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZzoNCj4gPiA+ DQo+ID4gPiBJdCBoYXMgYWx3YXlzIGJlZW4gbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBNUExT IGhlYWRlci9sYWJlbCB3YXMNCj4gPiA+IGluZGVwZW5kZW50IG9mIHRoZSBwcm90b2NvbC9wYXls b2FkLg0KPiA+ID4gU28gbm8gaW5kaWNhdGlvbiBvZiB0aGUgYWN0dWFsIHBheWxvYWQgY29udGVu dCB3YXMgbmVjZXNzYXJ5Lg0KPiA+ID4NCj4gPiA+IElNSE8geW91IGNvdWxkIHVzZSB0aGUgYWxl cnQgbGFiZWwgMSB0byBpbmRpY2F0ZSB0byB0aGUgTFNSIHRoYXQgaXQNCj4gPiA+IGhhcyB0byBm dXJ0aGVyIGV4YW1pbmUgdGhlIGNvbnRlbnQgb2YgYSBwYWNrZXQuDQo+ID4gPg0KPiA+ID4gUmVn YXJkcywgSHV1Yi4NCj4gPiA+DQo+ID4gPiA9PT09PT09PQ0KPiA+ID4NCj4gPiA+ID4gSXQgc2Fp ZCBpbiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtMDQp Og0KPiA+ID4gPg0KPiA+ID4gPiAgICAgVGhlIHNlcnZpY2UgaGVhZGVyIGlzIGluZGVwZW5kZW50 IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQgYW5kIGlzDQo+ID4gPiA+ICAgICBlbmNhcHN1bGF0 ZWQgaW4gZXhpc3RpbmcgdHJhbnNwb3J0cy4gIFRoZSBwcmVzZW5jZSBvZiBOU0ggaXMNCj4gPiA+ ID4gICAgIGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4g dGhlIG91dGVyDQo+ID4gPiA+ICAgICBlbmNhcHN1bGF0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiBJ biB0aGUgY2FzZSB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBhbiBNUExTIExTUCwg aG93IHRvDQo+ID4gPiA+IGluZGljYXRlIHRoZQ0KPiA+ID4gcHJlc2VuY2Ugb2YgTlNIIHNpbmNl IHRoZSBNUExTIGVuY2Fwc3VsYXRpb24gaGFzIG5vIGV4cGxpY2l0DQo+ID4gPiBwcm90b2NvbCBp ZGVudGlmaWVyIGZpZWxkIHRvIGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBNUExT IHBheWxvYWQ/DQo+ID4gPiBTaG91bGQgd2UgbWFrZSBlYWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVu aXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZw0KPiA+ID4gdGhlIHByZXNlbmNlIG9mIE5TSD8gT3Ig c2hvdWxkIHdlIHVzZSB0aGUgY29udHJvbCB3b3JkIHRvIGluZGljYXRlDQo+ID4gPiBpdD8gT3Ig c2hvdWxkIHdlIHJlY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhbiBleHBsaWNp dA0KPiA+ID4gcHJvdG9jb2wgaWRlbnRpZmllciBmaWVsZCB0byB0aGUgTVBMUyBlbmNhcHN1bGF0 aW9uIHNvIGFzIHRvIHNvbHZlDQo+ID4gPiBzdWNoIGtpbmQgb2YgaXNzdWVzDQo+ID4gb25jZSBh bmQgZm9yIGFsbD8NCj4gPiA+ID4NCj4gPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPiBYaWFv aHUNCj4gPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+DQo+ID4NCj4gKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K PiA+ID4gKioqKg0KPiA+ID4gICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOs vs3P8cbky/vDv9K7uPbIy9K70fkNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From nobody Tue Jan 27 00:46:13 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C511A8750; Tue, 27 Jan 2015 00:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em8Aq9upfpWG; Tue, 27 Jan 2015 00:46:01 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8AD1A8A11; Tue, 27 Jan 2015 00:45:53 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0810.eurprd03.prod.outlook.com (25.161.55.142) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 08:45:30 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 08:45:30 +0000 From: Alexander Vainshtein To: Xuxiaohu Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6FgAzM48AAAK7wgAAAgCbEA== Date: Tue, 27 Jan 2015 08:45:30 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0810; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0810; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377424004)(252514010)(377454003)(46102003)(74316001)(2656002)(87936001)(122556002)(86362001)(110136001)(40100003)(93886004)(76576001)(66066001)(19580395003)(2950100001)(19580405001)(15975445007)(102836002)(2900100001)(92566002)(54606007)(62966003)(54356999)(76176999)(33656002)(54206007)(77156002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0810; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 08:45:30.6177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0810 Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 08:46:04 -0000 WGlhb2ggaGkhDQpJIGRvIG5vdCB0aGluayB5b3UgbmVlZCBtdWx0aXBsZSBhcHBsaWNhdGlvbiBs YWJlbHMuIA0KUmF0aGVyLCB5b3UgY291bGQgc3dhcCB0aGVzZSBsYWJlbHMgYXMgdGhlIHBhY2tl dCBwcm9ncmVzc2VzIGFsb25nIHRoZSBTRlAsIHNhbWUgYXMgaXMgZG9uZSB3aXRoIE1TLVBXcy4N Cg0KUmVnYXJkcywNCiAgICAgICBTYXNoYSANCkVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbQ0KTW9iaWxlOiAwNTQtOTI2NjMwMg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0K PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDk6NDYgQU0NCj4gVG86IExvYSBBbmRl cnNzb247IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IENjOiBtcGxzQGlldGYub3JnOyBzZmNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtzZmNdIFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHBy ZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQo+IHBhY2tldD8NCj4gDQo+IA0KPiANCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzps b2FAcGkubnVdDQo+ID4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAyOjI4IFBNDQo+ ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBYdXhpYW9odQ0KPiA+IENjOiBtcGxzQGlldGYu b3JnOyBzZmNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3NmY10gW21wbHNdIEhvdyB0byBp bmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMNCj4gcGFja2V0Pw0KPiA+DQo+ ID4gU2FzaGEsDQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gMjAxNS0wMS0yNiAxNDoyMSwgQWxleGFu ZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+ID4gPiBYaWFvaHUsIEh1dWIsDQo+ID4gPiBJIGRvIG5v dCBmb2xsb3cgdGhlIFNGQyB3b3JrIGNsb3NlbHksIHNvIEkgd291bGQgbGlrZSB0byB1bmRlcnN0 YW5kDQo+ID4gPiB3aGV0aGVyIHRoZQ0KPiA+IE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRy YW5zaXQgTFNScyBvbiB0aGUgTFNQIC0gb3IganVzdCBieSB0aGUNCj4gPiBMRVIgYWN0aW5nIGFz IHRoZSBMU1AgdGFpbC1lbmQ/DQo+ID4gPg0KPiA+ID4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0 LCB0aGUgc2ltcGxlc3Qgd2F5IHRvIGluZGljYXRlIHByZXNlbmNlIG9mDQo+ID4gPiB0aGUgTlNI IGluIHRoZQ0KPiA+IE1QTFMgcGF5bG9hZCB3b3VsZCBiZSBieSBhbGxvY2F0aW5nIGFuICJhcHBs aWNhdGlvbiBsYWJlbCIgaW5kaWNhdGluZw0KPiA+IGl0cyBwcmVzZW5jZSBieSB0aGUgdGFpbC1l bmQgTEVSIGFuZCBieSBpbnNlcnRpbmcgaXQgYXQgdGhlIGJvdHRvbSBvZg0KPiA+IHRoZSBsYWJl bCBzdGFjayBieSB0aGUgaGVhZC1lbmQgTEVSIC0gc2ltaWxhciB0byB3aGF0IGlzIGRvbmUgZm9y DQo+ID4gTDIvTDNWUE4uICBXaXRoaW4gdGhpcyBhcHByb2FjaCwgaWYgbGFiZWwtYmFzZWQgZGVt dWx0aXBsZXhpbmcgb2YNCj4gPiBwYWNrZXRzIHdpdGggTlNIIGluIHRoZSBNUExTIHBheWxvYWQg aXMgbm90IHJlcXVpcmVkLCB5b3UgY291bGQNCj4gPiByZXF1ZXN0IGFsbG9jYXRpb24gb2YgYSBu ZXcgc3BlY2lhbCBwdXJwb3NlIGxhYmVsIGZyb20gdGhlIGV4dGVuZGVkDQo+ID4gc3BlY2lhbCBw dXJwb3NlcyBsYWJlbCBzcGFjZSBhcyBwZXIgUkZDIDcyNzQsIGFuZCB0byBpbnNlcnQgc3VjaCBh IGxhYmVsDQo+IChwcmVjZWRlZCBieSB0aGUgRXh0ZW5zaW9uIExhYmVsICkgYXQgdGhlIEJvUy4N Cj4gPiA+DQo+ID4gSSB0aGluayAidGhlIGxhdHRlciIgaXMgY29ycmVjdCwgdGhlIG9ubHkgaXNz dWUgSSBzZWUgaXMgYWRkaW5nIG9uZQ0KPiA+IG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhl IGxhYmVsIHN0YWNrLg0KPiANCj4gWWVzLCB0aGUgbGF0dGVyIGlzIGNvcnJlY3QuIFRoZSBpc3N1 ZSBvZiBhZGRpbmcgb25lIG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8NCj4gdGhlIGxhYmVsIHN0 YWNrIG1heSBiZWNvbWUgdW5hY2NlcHRhYmxlIGluIHRoZSBjYXNlIHdoZXJlIHRoZSBTZXJ2aWNl DQo+IEZ1bmN0aW9uIFBhdGggKFNGUCkgaXMgcmVwcmVzZW50ZWQgYnkgYW4gbGFiZWwgc3RhY2sg d2hpbGUgdGhlIE5TSCBpcyBub3cNCj4gb25seSB1c2VkIGFzIGEgbWV0YWRhdGEgY29udGFpbmVy LiBGb3IgZXhhbXBsZSwgZm9yIGFuIFNGUCBjb25zaXN0IG9mIG4gU0ZzLCBuDQo+ICJhcHBsaWNh dGlvbiBsYWJlbHMiIHdvdWxkIGhhdmUgdG8gYmUgaW5zZXJ0ZWQgaW50byB0aGUgbGFiZWwgc3Rh Y2suDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAvTG9hDQo+ID4gPiBJ ZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRoZSBwcm9jZXNzIGFib3ZlIHN0aWxsIGhhcyB0byBi ZSB1c2VkIGJ1dA0KPiA+ID4gaXQgaGFzIHRvIGJlDQo+ID4gYXVnbWVudGVkIGJ5IGFkZGluZyB0 aGUgUm91dGVyIEFsZXJ0IExhYmVsICAgYXQgdGhlIHRvcCBvZiB0aGUgbGFiZWwgc3RhY2suDQo+ ID4gPg0KPiA+ID4gIEZyb20gbXkgUE9WIHRoZXNlIHN1Z2dlc3Rpb25zIGFyZSBpbiBsaW5lIHdp dGggdGhlIHByb3Zpc2lvbnMgb2YNCj4gPiA+IFNlY3Rpb24gMi4yDQo+ID4gb2YgUkZDIDMwMzIg IkRldGVybWluaW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3RvY29sIiB0aGF0IHN0YXRlczoNCj4g PiA+DQo+ID4gPiA8cXVvdGU+DQo+ID4gPiAgICAgV2hlbiB0aGUgbGFzdCBsYWJlbCBpcyBwb3Bw ZWQgZnJvbSBhIHBhY2tldCdzIGxhYmVsIHN0YWNrIChyZXN1bHRpbmcNCj4gPiA+ICAgICBpbiB0 aGUgc3RhY2sgYmVpbmcgZW1wdGllZCksIGZ1cnRoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0 IGlzDQo+ID4gPiAgICAgYmFzZWQgb24gdGhlIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgaGVhZGVy LiAgVGhlIExTUiB3aGljaCBwb3BzIHRoZQ0KPiA+ID4gICAgIGxhc3QgbGFiZWwgb2ZmIHRoZSBz dGFjayBtdXN0IHRoZXJlZm9yZSBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZQ0KPiA+ID4gICAgIHBh Y2tldCdzIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wuICBIb3dldmVyLCB0aGUgbGFiZWwgc3RhY2sg ZG9lcyBub3QNCj4gPiA+ICAgICBjb250YWluIGFueSBmaWVsZCB3aGljaCBleHBsaWNpdGx5IGlk ZW50aWZpZXMgdGhlIG5ldHdvcmsgbGF5ZXINCj4gPiA+ICAgICBwcm90b2NvbC4gIFRoaXMgbWVh bnMgdGhhdCB0aGUgaWRlbnRpdHkgb2YgdGhlIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wNCj4gPiA+ ICAgICBtdXN0IGJlIGluZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUgbGFiZWwgd2hpY2gg aXMgcG9wcGVkIGZyb20NCj4gPiA+ICAgICB0aGUgYm90dG9tIG9mIHRoZSBzdGFjaywgcG9zc2li bHkgYWxvbmcgd2l0aCB0aGUgY29udGVudHMgb2YgdGhlDQo+ID4gPiAgICAgbmV0d29yayBsYXll ciBoZWFkZXIgaXRzZWxmLg0KPiA+ID4gPGVuZCBxdW90ZT4NCj4gPiA+DQo+ID4gPiBNeSAyYywN Cj4gPiA+IFNhc2hhDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiBGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBYdXhpYW9odQ0KPiA+ID4gPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+ID4gPiBTZW50OiBNb25k YXksIEphbnVhcnkgMjYsIDIwMTUgNTowNSBBTQ0KPiA+ID4gVG86IGh1dWJhdHdvcmtAZ21haWwu Y29tOyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbbXBs c10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiBwYWNr ZXQ/DQo+ID4gPg0KPiA+ID4gSGkgSHV1YiwNCj4gPiA+DQo+ID4gPiBUaGUgYWx0ZXIgbGFiZWwg aXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZpbmcgTFNSIHRvIGRldGVybWluZQ0KPiA+ ID4gdGhlIE1QTFMNCj4gPiBwYXlsb2FkIHR5cGUgYnkgZXhhbWluaW5nIHRoZSBNUExTIHBheWxv YWQuDQo+ID4gPg0KPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gWGlhb2h1DQo+ID4gPg0KPiA+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4gRnJvbTogSHV1YiB2YW4gSGVs dm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0NCj4gPiA+PiBTZW50OiBGcmlkYXks IEphbnVhcnkgMjMsIDIwMTUgNjoyOCBQTQ0KPiA+ID4+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYu b3JnOyBtcGxzQGlldGYub3JnDQo+ID4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5k aWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQo+IHBhY2tldD8NCj4gPiA+Pg0K PiA+ID4+IFh1eGlhb2h1IMT6usOjoQ0KPiA+ID4+DQo+ID4gPj4gUGxlYXNlIGNvcnJlY3QgbWUg aWYgSSBhbSB3cm9uZzoNCj4gPiA+Pg0KPiA+ID4+IEl0IGhhcyBhbHdheXMgYmVlbiBteSB1bmRl cnN0YW5kaW5nIHRoYXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcw0KPiA+ID4+IGluZGVwZW5k ZW50IG9mIHRoZSBwcm90b2NvbC9wYXlsb2FkLg0KPiA+ID4+IFNvIG5vIGluZGljYXRpb24gb2Yg dGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vzc2FyeS4NCj4gPiA+Pg0KPiA+ID4+ IElNSE8geW91IGNvdWxkIHVzZSB0aGUgYWxlcnQgbGFiZWwgMSB0byBpbmRpY2F0ZSB0byB0aGUg TFNSIHRoYXQgaXQNCj4gPiA+PiBoYXMgdG8gZnVydGhlciBleGFtaW5lIHRoZSBjb250ZW50IG9m IGEgcGFja2V0Lg0KPiA+ID4+DQo+ID4gPj4gUmVnYXJkcywgSHV1Yi4NCj4gPiA+Pg0KPiA+ID4+ ID09PT09PT09DQo+ID4gPj4NCj4gPiA+Pj4gSXQgc2FpZCBpbiAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtMDQpOg0KPiA+ID4+Pg0KPiA+ID4+PiAgICAg IFRoZSBzZXJ2aWNlIGhlYWRlciBpcyBpbmRlcGVuZGVudCBvZiB0aGUgZW5jYXBzdWxhdGlvbiB1 c2VkIGFuZCBpcw0KPiA+ID4+PiAgICAgIGVuY2Fwc3VsYXRlZCBpbiBleGlzdGluZyB0cmFuc3Bv cnRzLiAgVGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KPiA+ID4+PiAgICAgIGluZGljYXRlZCB2aWEg cHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQo+ID4gPj4+ICAg ICAgZW5jYXBzdWxhdGlvbi4NCj4gPiA+Pj4NCj4gPiA+Pj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhl IG91dGVyIGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBMUyBMU1AsIGhvdyB0bw0KPiA+ID4+PiBpbmRp Y2F0ZSB0aGUNCj4gPiA+PiBwcmVzZW5jZSBvZiBOU0ggc2luY2UgdGhlIE1QTFMgZW5jYXBzdWxh dGlvbiBoYXMgbm8gZXhwbGljaXQNCj4gPiA+PiBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRv IGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBNUExTDQo+IHBheWxvYWQ/DQo+ID4g Pj4gU2hvdWxkIHdlIG1ha2UgZWFjaCBTRkYgdG8gYWxsb2NhdGUgYSB1bmlxdWUgbGFiZWwgZm9y IGluZGljYXRpbmcNCj4gPiA+PiB0aGUgcHJlc2VuY2Ugb2YgTlNIPyBPciBzaG91bGQgd2UgdXNl IHRoZSBjb250cm9sIHdvcmQgdG8gaW5kaWNhdGUNCj4gPiA+PiBpdD8gT3Igc2hvdWxkIHdlIHJl Y29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhbiBleHBsaWNpdA0KPiA+ID4+IHBy b3RvY29sIGlkZW50aWZpZXIgZmllbGQgdG8gdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBzbyBhcyB0 byBzb2x2ZQ0KPiA+ID4+IHN1Y2gga2luZCBvZiBpc3N1ZXMNCj4gPiBvbmNlIGFuZCBmb3IgYWxs Pw0KPiA+ID4+Pg0KPiA+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPj4+IFhpYW9odQ0KPiA+ID4+ Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiAtLQ0KPiA+ID4+DQo+ID4NCj4gKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAqKioNCj4g PiA+PiAqKioqDQo+ID4gPj4gICAgICAgICAgICAgICAgIMfrvMfXoaOsxOPKx7bA0rvO3rb+tcSj rL7Nz/HG5Mv7w7/Su7j2yMvSu9H5DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+IG1wbHNA aWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+IHNmYyBtYWlsaW5nIGxpc3QNCj4gPiA+IHNmY0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPiA+DQo+ID4NCj4gPiAtLQ0K PiA+DQo+ID4NCj4gPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6 IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiA+IFNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAg ICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+ID4gSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3Vs dGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From nobody Tue Jan 27 00:58:58 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AFF1A8A8D; Tue, 27 Jan 2015 00:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 268QUEapvkyX; Tue, 27 Jan 2015 00:58:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89BF1A8751; Tue, 27 Jan 2015 00:58:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL79644; Tue, 27 Jan 2015 08:58:49 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 08:58:48 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 16:58:41 +0800 From: Xuxiaohu To: Alexander Vainshtein Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAIABlBAA//9rmmCAALrkAP//d10Q Date: Tue, 27 Jan 2015 08:58:41 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 08:58:56 -0000 SGkgU2FzaGEsDQoNCklmIG9ubHkgb25lIGFwcGxpY2F0aW9uIGxhYmVsIGlzIHJlcXVpcmVkIHRv IGJlIGluc2VydGVkIGludG8gdGhlIGxhYmVsIHN0YWNrLCB3aGVyZSBzaG91bGQgaXQgYmUgaW5z ZXJ0ZWQ/IGF0IHRoZSBCb1M/IElmIHNvLCBpdCBzZWVtcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBs YWJlbCBtdXN0IGJlIGFuIEVTUCBsYWJlbC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4g W21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gU2VudDogVHVlc2Rh eSwgSmFudWFyeSAyNywgMjAxNSA0OjQ2IFBNDQo+IFRvOiBYdXhpYW9odQ0KPiBDYzogbXBsc0Bp ZXRmLm9yZzsgc2ZjQGlldGYub3JnOyBMb2EgQW5kZXJzc29uDQo+IFN1YmplY3Q6IFJFOiBbc2Zj XSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUyBw YWNrZXQ/DQo+IA0KPiBYaWFvaCBoaSENCj4gSSBkbyBub3QgdGhpbmsgeW91IG5lZWQgbXVsdGlw bGUgYXBwbGljYXRpb24gbGFiZWxzLg0KPiBSYXRoZXIsIHlvdSBjb3VsZCBzd2FwIHRoZXNlIGxh YmVscyBhcyB0aGUgcGFja2V0IHByb2dyZXNzZXMgYWxvbmcgdGhlIFNGUCwgc2FtZQ0KPiBhcyBp cyBkb25lIHdpdGggTVMtUFdzLg0KPiANCj4gUmVnYXJkcywNCj4gICAgICAgIFNhc2hhDQo+IEVt YWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPiBNb2JpbGU6IDA1NC05MjY2 MzAyDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFh1 eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPiBTZW50OiBUdWVzZGF5LCBK YW51YXJ5IDI3LCAyMDE1IDk6NDYgQU0NCj4gPiBUbzogTG9hIEFuZGVyc3NvbjsgQWxleGFuZGVy IFZhaW5zaHRlaW4NCj4gPiBDYzogbXBsc0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+ID4gU3Vi amVjdDogUkU6IFtzZmNdIFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5T SCBpbiBhbiBNUExTDQo+ID4gcGFja2V0Pw0KPiA+DQo+ID4NCj4gPg0KPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzpsb2FA cGkubnVdDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDI6MjggUE0NCj4g PiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgWHV4aWFvaHUNCj4gPiA+IENjOiBtcGxzQGll dGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbc2ZjXSBbbXBsc10gSG93 IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiA+IHBhY2tldD8N Cj4gPiA+DQo+ID4gPiBTYXNoYSwNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IE9uIDIwMTUt MDEtMjYgMTQ6MjEsIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOg0KPiA+ID4gPiBYaWFvaHUs IEh1dWIsDQo+ID4gPiA+IEkgZG8gbm90IGZvbGxvdyB0aGUgU0ZDIHdvcmsgY2xvc2VseSwgc28g SSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQNCj4gPiA+ID4gd2hldGhlciB0aGUNCj4gPiA+IE5T SCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0gb3IganVz dCBieSB0aGUNCj4gPiA+IExFUiBhY3RpbmcgYXMgdGhlIExTUCB0YWlsLWVuZD8NCj4gPiA+ID4N Cj4gPiA+ID4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2ltcGxlc3Qgd2F5IHRvIGlu ZGljYXRlIHByZXNlbmNlIG9mDQo+ID4gPiA+IHRoZSBOU0ggaW4gdGhlDQo+ID4gPiBNUExTIHBh eWxvYWQgd291bGQgYmUgYnkgYWxsb2NhdGluZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiIGluZGlj YXRpbmcNCj4gPiA+IGl0cyBwcmVzZW5jZSBieSB0aGUgdGFpbC1lbmQgTEVSIGFuZCBieSBpbnNl cnRpbmcgaXQgYXQgdGhlIGJvdHRvbSBvZg0KPiA+ID4gdGhlIGxhYmVsIHN0YWNrIGJ5IHRoZSBo ZWFkLWVuZCBMRVIgLSBzaW1pbGFyIHRvIHdoYXQgaXMgZG9uZSBmb3INCj4gPiA+IEwyL0wzVlBO LiAgV2l0aGluIHRoaXMgYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRlbXVsdGlwbGV4aW5nIG9m DQo+ID4gPiBwYWNrZXRzIHdpdGggTlNIIGluIHRoZSBNUExTIHBheWxvYWQgaXMgbm90IHJlcXVp cmVkLCB5b3UgY291bGQNCj4gPiA+IHJlcXVlc3QgYWxsb2NhdGlvbiBvZiBhIG5ldyBzcGVjaWFs IHB1cnBvc2UgbGFiZWwgZnJvbSB0aGUgZXh0ZW5kZWQNCj4gPiA+IHNwZWNpYWwgcHVycG9zZXMg bGFiZWwgc3BhY2UgYXMgcGVyIFJGQyA3Mjc0LCBhbmQgdG8gaW5zZXJ0IHN1Y2ggYSBsYWJlbA0K PiA+IChwcmVjZWRlZCBieSB0aGUgRXh0ZW5zaW9uIExhYmVsICkgYXQgdGhlIEJvUy4NCj4gPiA+ ID4NCj4gPiA+IEkgdGhpbmsgInRoZSBsYXR0ZXIiIGlzIGNvcnJlY3QsIHRoZSBvbmx5IGlzc3Vl IEkgc2VlIGlzIGFkZGluZyBvbmUNCj4gPiA+IG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhl IGxhYmVsIHN0YWNrLg0KPiA+DQo+ID4gWWVzLCB0aGUgbGF0dGVyIGlzIGNvcnJlY3QuIFRoZSBp c3N1ZSBvZiBhZGRpbmcgb25lIG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8NCj4gPiB0aGUgbGFi ZWwgc3RhY2sgbWF5IGJlY29tZSB1bmFjY2VwdGFibGUgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIFNl cnZpY2UNCj4gPiBGdW5jdGlvbiBQYXRoIChTRlApIGlzIHJlcHJlc2VudGVkIGJ5IGFuIGxhYmVs IHN0YWNrIHdoaWxlIHRoZSBOU0ggaXMgbm93DQo+ID4gb25seSB1c2VkIGFzIGEgbWV0YWRhdGEg Y29udGFpbmVyLiBGb3IgZXhhbXBsZSwgZm9yIGFuIFNGUCBjb25zaXN0IG9mIG4gU0ZzLCBuDQo+ ID4gImFwcGxpY2F0aW9uIGxhYmVscyIgd291bGQgaGF2ZSB0byBiZSBpbnNlcnRlZCBpbnRvIHRo ZSBsYWJlbCBzdGFjay4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0K PiA+ID4gL0xvYQ0KPiA+ID4gPiBJZiB0aGUgZm9ybWVyIGlzIGNvcnJlY3QsIHRoZSBwcm9jZXNz IGFib3ZlIHN0aWxsIGhhcyB0byBiZSB1c2VkIGJ1dA0KPiA+ID4gPiBpdCBoYXMgdG8gYmUNCj4g PiA+IGF1Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBBbGVydCBMYWJlbCAgIGF0IHRoZSB0 b3Agb2YgdGhlIGxhYmVsIHN0YWNrLg0KPiA+ID4gPg0KPiA+ID4gPiAgRnJvbSBteSBQT1YgdGhl c2Ugc3VnZ2VzdGlvbnMgYXJlIGluIGxpbmUgd2l0aCB0aGUgcHJvdmlzaW9ucyBvZg0KPiA+ID4g PiBTZWN0aW9uIDIuMg0KPiA+ID4gb2YgUkZDIDMwMzIgIkRldGVybWluaW5nIHRoZSBOZXR3b3Jr IExheWVyIFByb3RvY29sIiB0aGF0IHN0YXRlczoNCj4gPiA+ID4NCj4gPiA+ID4gPHF1b3RlPg0K PiA+ID4gPiAgICAgV2hlbiB0aGUgbGFzdCBsYWJlbCBpcyBwb3BwZWQgZnJvbSBhIHBhY2tldCdz IGxhYmVsIHN0YWNrIChyZXN1bHRpbmcNCj4gPiA+ID4gICAgIGluIHRoZSBzdGFjayBiZWluZyBl bXB0aWVkKSwgZnVydGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQgaXMNCj4gPiA+ID4gICAg IGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVyIGhlYWRlci4gIFRoZSBMU1Igd2hp Y2ggcG9wcw0KPiB0aGUNCj4gPiA+ID4gICAgIGxhc3QgbGFiZWwgb2ZmIHRoZSBzdGFjayBtdXN0 IHRoZXJlZm9yZSBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZQ0KPiA+ID4gPiAgICAgcGFja2V0J3Mg bmV0d29yayBsYXllciBwcm90b2NvbC4gIEhvd2V2ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5v dA0KPiA+ID4gPiAgICAgY29udGFpbiBhbnkgZmllbGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlm aWVzIHRoZSBuZXR3b3JrIGxheWVyDQo+ID4gPiA+ICAgICBwcm90b2NvbC4gIFRoaXMgbWVhbnMg dGhhdCB0aGUgaWRlbnRpdHkgb2YgdGhlIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wNCj4gPiA+ID4g ICAgIG11c3QgYmUgaW5mZXJhYmxlIGZyb20gdGhlIHZhbHVlIG9mIHRoZSBsYWJlbCB3aGljaCBp cyBwb3BwZWQgZnJvbQ0KPiA+ID4gPiAgICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3Np Ymx5IGFsb25nIHdpdGggdGhlIGNvbnRlbnRzIG9mIHRoZQ0KPiA+ID4gPiAgICAgbmV0d29yayBs YXllciBoZWFkZXIgaXRzZWxmLg0KPiA+ID4gPiA8ZW5kIHF1b3RlPg0KPiA+ID4gPg0KPiA+ID4g PiBNeSAyYywNCj4gPiA+ID4gU2FzaGENCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPiBGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiBYdXhpYW9odQ0KPiA+ID4gPiA8eHV4aWFvaHVAaHVhd2VpLmNvbT4N Cj4gPiA+ID4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0NCj4gPiA+ID4g VG86IGh1dWJhdHdvcmtAZ21haWwuY29tOyBzZmNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCj4g PiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9m IE5TSCBpbiBhbiBNUExTDQo+ID4gcGFja2V0Pw0KPiA+ID4gPg0KPiA+ID4gPiBIaSBIdXViLA0K PiA+ID4gPg0KPiA+ID4gPiBUaGUgYWx0ZXIgbGFiZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRo ZSByZWNlaXZpbmcgTFNSIHRvIGRldGVybWluZQ0KPiA+ID4gPiB0aGUgTVBMUw0KPiA+ID4gcGF5 bG9hZCB0eXBlIGJ5IGV4YW1pbmluZyB0aGUgTVBMUyBwYXlsb2FkLg0KPiA+ID4gPg0KPiA+ID4g PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPg0KPiA+ID4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFtt YWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQo+ID4gPiA+PiBTZW50OiBGcmlkYXksIEphbnVh cnkgMjMsIDIwMTUgNjoyOCBQTQ0KPiA+ID4gPj4gVG86IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc7 IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGlj YXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiA+IHBhY2tldD8NCj4gPiA+ID4+ DQo+ID4gPiA+PiBYdXhpYW9odSDE+rrDo6ENCj4gPiA+ID4+DQo+ID4gPiA+PiBQbGVhc2UgY29y cmVjdCBtZSBpZiBJIGFtIHdyb25nOg0KPiA+ID4gPj4NCj4gPiA+ID4+IEl0IGhhcyBhbHdheXMg YmVlbiBteSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcw0KPiA+ ID4gPj4gaW5kZXBlbmRlbnQgb2YgdGhlIHByb3RvY29sL3BheWxvYWQuDQo+ID4gPiA+PiBTbyBu byBpbmRpY2F0aW9uIG9mIHRoZSBhY3R1YWwgcGF5bG9hZCBjb250ZW50IHdhcyBuZWNlc3Nhcnku DQo+ID4gPiA+Pg0KPiA+ID4gPj4gSU1ITyB5b3UgY291bGQgdXNlIHRoZSBhbGVydCBsYWJlbCAx IHRvIGluZGljYXRlIHRvIHRoZSBMU1IgdGhhdCBpdA0KPiA+ID4gPj4gaGFzIHRvIGZ1cnRoZXIg ZXhhbWluZSB0aGUgY29udGVudCBvZiBhIHBhY2tldC4NCj4gPiA+ID4+DQo+ID4gPiA+PiBSZWdh cmRzLCBIdXViLg0KPiA+ID4gPj4NCj4gPiA+ID4+ID09PT09PT09DQo+ID4gPiA+Pg0KPiA+ID4g Pj4+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1z ZmMtbnNoLTA0KToNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICAgICAgVGhlIHNlcnZpY2UgaGVhZGVy IGlzIGluZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQgYW5kDQo+IGlzDQo+ID4g PiA+Pj4gICAgICBlbmNhcHN1bGF0ZWQgaW4gZXhpc3RpbmcgdHJhbnNwb3J0cy4gIFRoZSBwcmVz ZW5jZSBvZiBOU0ggaXMNCj4gPiA+ID4+PiAgICAgIGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlw ZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQo+ID4gPiA+Pj4gICAgICBlbmNhcHN1 bGF0aW9uLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG91dGVy IGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBMUyBMU1AsIGhvdyB0bw0KPiA+ID4gPj4+IGluZGljYXRl IHRoZQ0KPiA+ID4gPj4gcHJlc2VuY2Ugb2YgTlNIIHNpbmNlIHRoZSBNUExTIGVuY2Fwc3VsYXRp b24gaGFzIG5vIGV4cGxpY2l0DQo+ID4gPiA+PiBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRv IGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBNUExTDQo+ID4gcGF5bG9hZD8NCj4g PiA+ID4+IFNob3VsZCB3ZSBtYWtlIGVhY2ggU0ZGIHRvIGFsbG9jYXRlIGEgdW5pcXVlIGxhYmVs IGZvciBpbmRpY2F0aW5nDQo+ID4gPiA+PiB0aGUgcHJlc2VuY2Ugb2YgTlNIPyBPciBzaG91bGQg d2UgdXNlIHRoZSBjb250cm9sIHdvcmQgdG8gaW5kaWNhdGUNCj4gPiA+ID4+IGl0PyBPciBzaG91 bGQgd2UgcmVjb25zaWRlciB0aGUgcG9zc2liaWxpdHkgb2YgYWRkaW5nIGFuIGV4cGxpY2l0DQo+ ID4gPiA+PiBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRvIHRoZSBNUExTIGVuY2Fwc3VsYXRp b24gc28gYXMgdG8gc29sdmUNCj4gPiA+ID4+IHN1Y2gga2luZCBvZiBpc3N1ZXMNCj4gPiA+IG9u Y2UgYW5kIGZvciBhbGw/DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4g PiA+Pj4gWGlhb2h1DQo+ID4gPiA+Pj4NCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPj4gLS0N Cj4gPiA+ID4+DQo+ID4gPg0KPiA+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCj4gPiAqKioNCj4gPiA+ID4+ICoqKioNCj4gPiA+ID4+ ICAgICAgICAgICAgICAgICDH67zH16GjrMTjyse2wNK7zt62/rXEo6y+zc/xxuTL+8O/0ru49sjL 0rvR+Q0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+ID4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBtcGxzQGlldGYub3JnDQo+ ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4g PiBzZmMgbWFpbGluZyBsaXN0DQo+ID4gPiA+IHNmY0BpZXRmLm9yZw0KPiA+ID4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+ IC0tDQo+ID4gPg0KPiA+ID4NCj4gPiA+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAg ICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+ID4gPiBTZW5pb3IgTVBMUyBFeHBl cnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiA+ID4gSHVhd2VpIFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From nobody Tue Jan 27 02:03:14 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0EC1A875C; Tue, 27 Jan 2015 02:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.783 X-Spam-Level: X-Spam-Status: No, score=0.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVh4ygmKBVob; Tue, 27 Jan 2015 02:03:03 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24D11A875A; Tue, 27 Jan 2015 02:03:01 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D49C4180155B; Tue, 27 Jan 2015 11:02:58 +0100 (CET) Message-ID: <54C7624B.3080309@pi.nu> Date: Tue, 27 Jan 2015 18:02:51 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Xuxiaohu , Alexander Vainshtein References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 10:03:08 -0000 Sasha, (correct me if I'm wrong) I thnk you say that there are tow cases - you can infer from the NSH everything you need to treat the SFC packet correct - you need more information than the NSH In the first case you can the label at the BoS just need to point out that the NSH is present and the rest is done based on the HSH There are two cases here also - you assign the label that points to the NSH tLDP style and it is signaled between the egress and ingress LSR - you assign a ESPL and you don't need the signaling. In the second case you need the application label to point out how the and the correct handling of the NSH should be done. In this case you need the signaling? /Loa On 2015-01-27 16:58, Xuxiaohu wrote: > Hi Sasha, > > If only one application label is required to be inserted into the label stack, where should it be inserted? at the BoS? If so, it seems that the application label must be an ESP label. > > Best regards, > Xiaohu > >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Tuesday, January 27, 2015 4:46 PM >> To: Xuxiaohu >> Cc: mpls@ietf.org; sfc@ietf.org; Loa Andersson >> Subject: RE: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> Xiaoh hi! >> I do not think you need multiple application labels. >> Rather, you could swap these labels as the packet progresses along the SFP, same >> as is done with MS-PWs. >> >> Regards, >> Sasha >> Email: Alexander.Vainshtein@ecitele.com >> Mobile: 054-9266302 >> >> >>> -----Original Message----- >>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>> Sent: Tuesday, January 27, 2015 9:46 AM >>> To: Loa Andersson; Alexander Vainshtein >>> Cc: mpls@ietf.org; sfc@ietf.org >>> Subject: RE: [sfc] [mpls] How to indicate the presence of NSH in an MPLS >>> packet? >>> >>> >>> >>>> -----Original Message----- >>>> From: Loa Andersson [mailto:loa@pi.nu] >>>> Sent: Tuesday, January 27, 2015 2:28 PM >>>> To: Alexander Vainshtein; Xuxiaohu >>>> Cc: mpls@ietf.org; sfc@ietf.org >>>> Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS >>> packet? >>>> >>>> Sasha, >>>> >>>> >>>> >>>> On 2015-01-26 14:21, Alexander Vainshtein wrote: >>>>> Xiaohu, Huub, >>>>> I do not follow the SFC work closely, so I would like to understand >>>>> whether the >>>> NSH should be captured by transit LSRs on the LSP - or just by the >>>> LER acting as the LSP tail-end? >>>>> >>>>> If the latter is correct, the simplest way to indicate presence of >>>>> the NSH in the >>>> MPLS payload would be by allocating an "application label" indicating >>>> its presence by the tail-end LER and by inserting it at the bottom of >>>> the label stack by the head-end LER - similar to what is done for >>>> L2/L3VPN. Within this approach, if label-based demultiplexing of >>>> packets with NSH in the MPLS payload is not required, you could >>>> request allocation of a new special purpose label from the extended >>>> special purposes label space as per RFC 7274, and to insert such a label >>> (preceded by the Extension Label ) at the BoS. >>>>> >>>> I think "the latter" is correct, the only issue I see is adding one >>>> more label stack entry to the label stack. >>> >>> Yes, the latter is correct. The issue of adding one more label stack entry to >>> the label stack may become unacceptable in the case where the Service >>> Function Path (SFP) is represented by an label stack while the NSH is now >>> only used as a metadata container. For example, for an SFP consist of n SFs, n >>> "application labels" would have to be inserted into the label stack. >>> >>> Best regards, >>> Xiaohu >>> >>>> /Loa >>>>> If the former is correct, the process above still has to be used but >>>>> it has to be >>>> augmented by adding the Router Alert Label at the top of the label stack. >>>>> >>>>> From my POV these suggestions are in line with the provisions of >>>>> Section 2.2 >>>> of RFC 3032 "Determining the Network Layer Protocol" that states: >>>>> >>>>> >>>>> When the last label is popped from a packet's label stack (resulting >>>>> in the stack being emptied), further processing of the packet is >>>>> based on the packet's network layer header. The LSR which pops >> the >>>>> last label off the stack must therefore be able to identify the >>>>> packet's network layer protocol. However, the label stack does not >>>>> contain any field which explicitly identifies the network layer >>>>> protocol. This means that the identity of the network layer protocol >>>>> must be inferable from the value of the label which is popped from >>>>> the bottom of the stack, possibly along with the contents of the >>>>> network layer header itself. >>>>> >>>>> >>>>> My 2c, >>>>> Sasha >>>>> ________________________________________ >>>>> From: mpls on behalf of Xuxiaohu >>>>> >>>>> Sent: Monday, January 26, 2015 5:05 AM >>>>> To: huubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org >>>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS >>> packet? >>>>> >>>>> Hi Huub, >>>>> >>>>> The alter label itself couldn¡¯t make the receiving LSR to determine >>>>> the MPLS >>>> payload type by examining the MPLS payload. >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> -----Original Message----- >>>>>> From: Huub van Helvoort [mailto:huubatwork@gmail.com] >>>>>> Sent: Friday, January 23, 2015 6:28 PM >>>>>> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org >>>>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS >>> packet? >>>>>> >>>>>> Xuxiaohu ÄúºÃ£¡ >>>>>> >>>>>> Please correct me if I am wrong: >>>>>> >>>>>> It has always been my understanding that the MPLS header/label was >>>>>> independent of the protocol/payload. >>>>>> So no indication of the actual payload content was necessary. >>>>>> >>>>>> IMHO you could use the alert label 1 to indicate to the LSR that it >>>>>> has to further examine the content of a packet. >>>>>> >>>>>> Regards, Huub. >>>>>> >>>>>> ======== >>>>>> >>>>>>> It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): >>>>>>> >>>>>>> The service header is independent of the encapsulation used and >> is >>>>>>> encapsulated in existing transports. The presence of NSH is >>>>>>> indicated via protocol type or other indicator in the outer >>>>>>> encapsulation. >>>>>>> >>>>>>> In the case where the outer encapsulation is an MPLS LSP, how to >>>>>>> indicate the >>>>>> presence of NSH since the MPLS encapsulation has no explicit >>>>>> protocol identifier field to indicate the protocol type of the MPLS >>> payload? >>>>>> Should we make each SFF to allocate a unique label for indicating >>>>>> the presence of NSH? Or should we use the control word to indicate >>>>>> it? Or should we reconsider the possibility of adding an explicit >>>>>> protocol identifier field to the MPLS encapsulation so as to solve >>>>>> such kind of issues >>>> once and for all? >>>>>>> >>>>>>> Best regards, >>>>>>> Xiaohu >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>> >>> ********************************************************** >>> *** >>>>>> **** >>>>>> Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jan 27 03:14:59 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C821A879A; Tue, 27 Jan 2015 03:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VvhzuQ6TS8K; Tue, 27 Jan 2015 03:14:53 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E4C1A8794; Tue, 27 Jan 2015 03:14:52 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 11:12:47 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 11:12:47 +0000 From: Alexander Vainshtein To: Loa Andersson Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6FgAzM48AAAK7wgAAAgCbEAAAiTyAAAI9soAAAjTwYA== Date: Tue, 27 Jan 2015 11:12:47 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> <54C7624B.3080309@pi.nu> In-Reply-To: <54C7624B.3080309@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0812; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0812; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(252514010)(377454003)(377424004)(51704005)(77156002)(86362001)(93886004)(2950100001)(33656002)(2900100001)(54206007)(110136001)(62966003)(2656002)(76576001)(74316001)(92566002)(54356999)(76176999)(66066001)(15975445007)(102836002)(54606007)(87936001)(19580405001)(19580395003)(40100003)(122556002)(46102003)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0812; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 11:12:47.2278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0812 Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 11:14:57 -0000 TG9hLA0KWW91ciBhbmFseXNpcyBpcyBhYnNvbHV0ZWx5IGNvcnJlY3QuIFRoZXJlIGFyZSB0d28g Y2FzZXMsIGFuZCBJIGRvIG5vdCBrbm93IHdoaWNoIG9uZSBpcyBhcHBsaWNhYmxlIHNpbmNlIGJ5 IGtub3dsZWRnZSBvZiBTRkMgaXMgbm9uLWV4aXN0ZW50Lg0KDQotIElmIHNwZWNpZmljIFNGIGlu c3RhbmNlIHdpdGhpbiB0aGUgbm9kZSBjYW4gYmUgaW5mZXJyZWQgZnJvbSB0aGUgTlNILCBhbmQg aWYgaXRzIHByb2Nlc3NpbmcgaW5jbHVkZXMgaWRlbnRpZmljYXRpb24gb2YgdGhlIG5leHQgaG9w IG9mIHRoZSBTRiBwYXRoLCB0aGVuIHdlIGNhbiB1c2UgRVNQTCwgYW5kIHRoZXJlIGlzIG5vIG5l ZWQgZm9yIHNpZ25hbGluZyAoc2luY2UgaXQgaXMgb25lIHZhbHVlIG9ubHkgYW5kICBpdHMgaW50 ZXJwcmV0YXRpb24gaXMgcHJlZGVmaW5lZCkuDQotIElmIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQg dGhlIGhhbmRsaW5nIGNhbm5vdCBiZSBpbmZlcnJlZCBmcm9tIHRoZSBOU0gsIGJlIGl0IHNwZWNp ZmljIFNGIGluc3RhbmNlIGluIHRoaXMgbm9kZSwgb3IgdGhlIG5leHQgaG9wIG9uIHRoZSBTRiBw YXRoIGFuZCB0aGUgU0YgaW5zdGFuY2Ugd2l0aGluIHRoaXMgbm9kZSwgb3IsIHBvc3NpYmx5LCBz b21lIGNvbWJpbmF0aW9uIG9mIHRob3NlLCB0aGVuIHlvdSBuZWVkIGFwcGxpY2F0aW9uIGxhYmVs cyBiZWluZyBhbGxvY2F0ZWQgYnkgdGhlIFNGIG5vZGVzIHdpdGggc29tZSBncmFudWxhcml0eSwg YW5kIHRoZWlyIGRpc3RyaWJ1dGlvbiB2aWEgc29tZSBmb3JtIG9mIHNpZ25hbGluZyAodExEUCBv ciBNUC1CR1AgY291bGQgYmUgdXNlZCkuICANCg0KUmVnYXJkcywNCiAgICAgICBTYXNoYSANCkVt YWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KTW9iaWxlOiAwNTQtOTI2NjMw Mg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9hIEFuZGVyc3Nv biBbbWFpbHRvOmxvYUBwaS5udV0NCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAx MjowMyBQTQ0KPiBUbzogWHV4aWFvaHU7IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IENjOiBtcGxz QGlldGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzZmNdIFttcGxzXSBIb3cg dG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQo+IHBhY2tldD8NCj4g DQo+IFNhc2hhLCAoY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcpDQo+IA0KPiBJIHRobmsgeW91IHNh eSB0aGF0IHRoZXJlIGFyZSB0b3cgY2FzZXMNCj4gDQo+IC0geW91IGNhbiBpbmZlciBmcm9tIHRo ZSBOU0ggZXZlcnl0aGluZyB5b3UgbmVlZCB0byB0cmVhdCB0aGUgU0ZDIHBhY2tldA0KPiAgICBj b3JyZWN0DQo+IC0geW91IG5lZWQgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIHRoZSBOU0gNCj4gDQo+ IEluIHRoZSBmaXJzdCBjYXNlIHlvdSBjYW4gdGhlIGxhYmVsIGF0IHRoZSBCb1MganVzdCBuZWVk IHRvIHBvaW50IG91dCB0aGF0IHRoZQ0KPiBOU0ggaXMgcHJlc2VudCBhbmQgdGhlIHJlc3QgaXMg ZG9uZSBiYXNlZCBvbiB0aGUgSFNIDQo+IA0KPiBUaGVyZSBhcmUgdHdvIGNhc2VzIGhlcmUgYWxz bw0KPiAtIHlvdSBhc3NpZ24gdGhlIGxhYmVsIHRoYXQgcG9pbnRzIHRvIHRoZSBOU0ggdExEUCBz dHlsZSBhbmQgaXQgaXMNCj4gICAgc2lnbmFsZWQgYmV0d2VlbiB0aGUgZWdyZXNzIGFuZCBpbmdy ZXNzIExTUg0KPiAtIHlvdSBhc3NpZ24gYSBFU1BMIGFuZCB5b3UgZG9uJ3QgbmVlZCB0aGUgc2ln bmFsaW5nLg0KPiANCj4gSW4gdGhlIHNlY29uZCBjYXNlIHlvdSBuZWVkIHRoZSBhcHBsaWNhdGlv biBsYWJlbCB0byBwb2ludCBvdXQgaG93IHRoZSBhbmQNCj4gdGhlIGNvcnJlY3QgaGFuZGxpbmcg b2YgdGhlIE5TSCBzaG91bGQgYmUgZG9uZS4NCj4gSW4gdGhpcyBjYXNlIHlvdSBuZWVkIHRoZSBz aWduYWxpbmc/DQo+IA0KPiAvTG9hDQo+IA0KPiANCj4gT24gMjAxNS0wMS0yNyAxNjo1OCwgWHV4 aWFvaHUgd3JvdGU6DQo+ID4gSGkgU2FzaGEsDQo+ID4NCj4gPiBJZiBvbmx5IG9uZSBhcHBsaWNh dGlvbiBsYWJlbCBpcyByZXF1aXJlZCB0byBiZSBpbnNlcnRlZCBpbnRvIHRoZSBsYWJlbCBzdGFj aywNCj4gd2hlcmUgc2hvdWxkIGl0IGJlIGluc2VydGVkPyBhdCB0aGUgQm9TPyBJZiBzbywgaXQg c2VlbXMgdGhhdCB0aGUgYXBwbGljYXRpb24NCj4gbGFiZWwgbXVzdCBiZSBhbiBFU1AgbGFiZWwu DQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0 bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gPj4gU2VudDogVHVlc2RheSwg SmFudWFyeSAyNywgMjAxNSA0OjQ2IFBNDQo+ID4+IFRvOiBYdXhpYW9odQ0KPiA+PiBDYzogbXBs c0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnOyBMb2EgQW5kZXJzc29uDQo+ID4+IFN1YmplY3Q6IFJF OiBbc2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4g TVBMUw0KPiBwYWNrZXQ/DQo+ID4+DQo+ID4+IFhpYW9oIGhpIQ0KPiA+PiBJIGRvIG5vdCB0aGlu ayB5b3UgbmVlZCBtdWx0aXBsZSBhcHBsaWNhdGlvbiBsYWJlbHMuDQo+ID4+IFJhdGhlciwgeW91 IGNvdWxkIHN3YXAgdGhlc2UgbGFiZWxzIGFzIHRoZSBwYWNrZXQgcHJvZ3Jlc3NlcyBhbG9uZw0K PiA+PiB0aGUgU0ZQLCBzYW1lIGFzIGlzIGRvbmUgd2l0aCBNUy1QV3MuDQo+ID4+DQo+ID4+IFJl Z2FyZHMsDQo+ID4+ICAgICAgICAgU2FzaGENCj4gPj4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tDQo+ID4+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4gPj4NCj4gPj4NCj4g Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBYdXhpYW9odSBbbWFp bHRvOnh1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4+PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI3 LCAyMDE1IDk6NDYgQU0NCj4gPj4+IFRvOiBMb2EgQW5kZXJzc29uOyBBbGV4YW5kZXIgVmFpbnNo dGVpbg0KPiA+Pj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiA+Pj4gU3ViamVj dDogUkU6IFtzZmNdIFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBp biBhbg0KPiA+Pj4gTVBMUyBwYWNrZXQ/DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWls dG86bG9hQHBpLm51XQ0KPiA+Pj4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjcsIDIwMTUgMjoy OCBQTQ0KPiA+Pj4+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgWHV4aWFvaHUNCj4gPj4+PiBD YzogbXBsc0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+ID4+Pj4gU3ViamVjdDogUmU6IFtzZmNd IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbg0KPiA+Pj4+ IE1QTFMNCj4gPj4+IHBhY2tldD8NCj4gPj4+Pg0KPiA+Pj4+IFNhc2hhLA0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+IE9uIDIwMTUtMDEtMjYgMTQ6MjEsIEFsZXhhbmRlciBWYWluc2h0 ZWluIHdyb3RlOg0KPiA+Pj4+PiBYaWFvaHUsIEh1dWIsDQo+ID4+Pj4+IEkgZG8gbm90IGZvbGxv dyB0aGUgU0ZDIHdvcmsgY2xvc2VseSwgc28gSSB3b3VsZCBsaWtlIHRvDQo+ID4+Pj4+IHVuZGVy c3RhbmQgd2hldGhlciB0aGUNCj4gPj4+PiBOU0ggc2hvdWxkIGJlIGNhcHR1cmVkIGJ5ICB0cmFu c2l0IExTUnMgb24gdGhlIExTUCAtIG9yIGp1c3QgYnkgdGhlDQo+ID4+Pj4gTEVSIGFjdGluZyBh cyB0aGUgTFNQIHRhaWwtZW5kPw0KPiA+Pj4+Pg0KPiA+Pj4+PiBJZiB0aGUgbGF0dGVyIGlzIGNv cnJlY3QsIHRoZSBzaW1wbGVzdCB3YXkgdG8gaW5kaWNhdGUgcHJlc2VuY2Ugb2YNCj4gPj4+Pj4g dGhlIE5TSCBpbiB0aGUNCj4gPj4+PiBNUExTIHBheWxvYWQgd291bGQgYmUgYnkgYWxsb2NhdGlu ZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiDQo+ID4+Pj4gaW5kaWNhdGluZyBpdHMgcHJlc2VuY2Ug YnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0IGF0DQo+ID4+Pj4gdGhlIGJv dHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sgYnkgdGhlIGhlYWQtZW5kIExFUiAtIHNpbWlsYXIgdG8g d2hhdA0KPiA+Pj4+IGlzIGRvbmUgZm9yIEwyL0wzVlBOLiAgV2l0aGluIHRoaXMgYXBwcm9hY2gs IGlmIGxhYmVsLWJhc2VkDQo+ID4+Pj4gZGVtdWx0aXBsZXhpbmcgb2YgcGFja2V0cyB3aXRoIE5T SCBpbiB0aGUgTVBMUyBwYXlsb2FkIGlzIG5vdA0KPiA+Pj4+IHJlcXVpcmVkLCB5b3UgY291bGQg cmVxdWVzdCBhbGxvY2F0aW9uIG9mIGEgbmV3IHNwZWNpYWwgcHVycG9zZQ0KPiA+Pj4+IGxhYmVs IGZyb20gdGhlIGV4dGVuZGVkIHNwZWNpYWwgcHVycG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJG Qw0KPiA+Pj4+IDcyNzQsIGFuZCB0byBpbnNlcnQgc3VjaCBhIGxhYmVsDQo+ID4+PiAocHJlY2Vk ZWQgYnkgdGhlIEV4dGVuc2lvbiBMYWJlbCApIGF0IHRoZSBCb1MuDQo+ID4+Pj4+DQo+ID4+Pj4g SSB0aGluayAidGhlIGxhdHRlciIgaXMgY29ycmVjdCwgdGhlIG9ubHkgaXNzdWUgSSBzZWUgaXMg YWRkaW5nIG9uZQ0KPiA+Pj4+IG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhlIGxhYmVsIHN0 YWNrLg0KPiA+Pj4NCj4gPj4+IFllcywgdGhlIGxhdHRlciBpcyBjb3JyZWN0LiBUaGUgaXNzdWUg b2YgYWRkaW5nIG9uZSBtb3JlIGxhYmVsIHN0YWNrDQo+ID4+PiBlbnRyeSB0byB0aGUgbGFiZWwg c3RhY2sgbWF5IGJlY29tZSB1bmFjY2VwdGFibGUgaW4gdGhlIGNhc2Ugd2hlcmUNCj4gPj4+IHRo ZSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgaXMgcmVwcmVzZW50ZWQgYnkgYW4gbGFiZWwg c3RhY2sNCj4gPj4+IHdoaWxlIHRoZSBOU0ggaXMgbm93IG9ubHkgdXNlZCBhcyBhIG1ldGFkYXRh IGNvbnRhaW5lci4gRm9yIGV4YW1wbGUsDQo+ID4+PiBmb3IgYW4gU0ZQIGNvbnNpc3Qgb2YgbiBT RnMsIG4gImFwcGxpY2F0aW9uIGxhYmVscyIgd291bGQgaGF2ZSB0byBiZQ0KPiBpbnNlcnRlZCBp bnRvIHRoZSBsYWJlbCBzdGFjay4NCj4gPj4+DQo+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+PiBY aWFvaHUNCj4gPj4+DQo+ID4+Pj4gL0xvYQ0KPiA+Pj4+PiBJZiB0aGUgZm9ybWVyIGlzIGNvcnJl Y3QsIHRoZSBwcm9jZXNzIGFib3ZlIHN0aWxsIGhhcyB0byBiZSB1c2VkDQo+ID4+Pj4+IGJ1dCBp dCBoYXMgdG8gYmUNCj4gPj4+PiBhdWdtZW50ZWQgYnkgYWRkaW5nIHRoZSBSb3V0ZXIgQWxlcnQg TGFiZWwgICBhdCB0aGUgdG9wIG9mIHRoZSBsYWJlbA0KPiBzdGFjay4NCj4gPj4+Pj4NCj4gPj4+ Pj4gICBGcm9tIG15IFBPViB0aGVzZSBzdWdnZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRoZSBw cm92aXNpb25zIG9mDQo+ID4+Pj4+IFNlY3Rpb24gMi4yDQo+ID4+Pj4gb2YgUkZDIDMwMzIgIkRl dGVybWluaW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3RvY29sIiB0aGF0IHN0YXRlczoNCj4gPj4+ Pj4NCj4gPj4+Pj4gPHF1b3RlPg0KPiA+Pj4+PiAgICAgIFdoZW4gdGhlIGxhc3QgbGFiZWwgaXMg cG9wcGVkIGZyb20gYSBwYWNrZXQncyBsYWJlbCBzdGFjayAocmVzdWx0aW5nDQo+ID4+Pj4+ICAg ICAgaW4gdGhlIHN0YWNrIGJlaW5nIGVtcHRpZWQpLCBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhl IHBhY2tldCBpcw0KPiA+Pj4+PiAgICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxh eWVyIGhlYWRlci4gIFRoZSBMU1Igd2hpY2gNCj4gPj4+Pj4gcG9wcw0KPiA+PiB0aGUNCj4gPj4+ Pj4gICAgICBsYXN0IGxhYmVsIG9mZiB0aGUgc3RhY2sgbXVzdCB0aGVyZWZvcmUgYmUgYWJsZSB0 byBpZGVudGlmeSB0aGUNCj4gPj4+Pj4gICAgICBwYWNrZXQncyBuZXR3b3JrIGxheWVyIHByb3Rv Y29sLiAgSG93ZXZlciwgdGhlIGxhYmVsIHN0YWNrIGRvZXMgbm90DQo+ID4+Pj4+ICAgICAgY29u dGFpbiBhbnkgZmllbGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVzIHRoZSBuZXR3b3JrIGxh eWVyDQo+ID4+Pj4+ICAgICAgcHJvdG9jb2wuICBUaGlzIG1lYW5zIHRoYXQgdGhlIGlkZW50aXR5 IG9mIHRoZSBuZXR3b3JrIGxheWVyDQo+IHByb3RvY29sDQo+ID4+Pj4+ICAgICAgbXVzdCBiZSBp bmZlcmFibGUgZnJvbSB0aGUgdmFsdWUgb2YgdGhlIGxhYmVsIHdoaWNoIGlzIHBvcHBlZCBmcm9t DQo+ID4+Pj4+ICAgICAgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3NpYmx5IGFsb25nIHdp dGggdGhlIGNvbnRlbnRzIG9mIHRoZQ0KPiA+Pj4+PiAgICAgIG5ldHdvcmsgbGF5ZXIgaGVhZGVy IGl0c2VsZi4NCj4gPj4+Pj4gPGVuZCBxdW90ZT4NCj4gPj4+Pj4NCj4gPj4+Pj4gTXkgMmMsDQo+ ID4+Pj4+IFNhc2hhDQo+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+Pj4gRnJvbTogbXBscyA8bXBscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh bGYgb2YgWHV4aWFvaHUNCj4gPj4+Pj4gPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+ID4+Pj4+IFNl bnQ6IE1vbmRheSwgSmFudWFyeSAyNiwgMjAxNSA1OjA1IEFNDQo+ID4+Pj4+IFRvOiBodXViYXR3 b3JrQGdtYWlsLmNvbTsgc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+ID4+Pj4+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4g TVBMUw0KPiA+Pj4gcGFja2V0Pw0KPiA+Pj4+Pg0KPiA+Pj4+PiBIaSBIdXViLA0KPiA+Pj4+Pg0K PiA+Pj4+PiBUaGUgYWx0ZXIgbGFiZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZp bmcgTFNSIHRvDQo+ID4+Pj4+IGRldGVybWluZSB0aGUgTVBMUw0KPiA+Pj4+IHBheWxvYWQgdHlw ZSBieSBleGFtaW5pbmcgdGhlIE1QTFMgcGF5bG9hZC4NCj4gPj4+Pj4NCj4gPj4+Pj4gQmVzdCBy ZWdhcmRzLA0KPiA+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4NCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+Pj4+PiBGcm9tOiBIdXViIHZhbiBIZWx2b29ydCBbbWFpbHRvOmh1 dWJhdHdvcmtAZ21haWwuY29tXQ0KPiA+Pj4+Pj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDIzLCAy MDE1IDY6MjggUE0NCj4gPj4+Pj4+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnOyBtcGxzQGll dGYub3JnDQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUg cHJlc2VuY2Ugb2YgTlNIIGluIGFuDQo+ID4+Pj4+PiBNUExTDQo+ID4+PiBwYWNrZXQ/DQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gWHV4aWFvaHUgxPq6w6OhDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUGxlYXNl IGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZzoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJdCBoYXMgYWx3 YXlzIGJlZW4gbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJlbA0KPiA+ Pj4+Pj4gd2FzIGluZGVwZW5kZW50IG9mIHRoZSBwcm90b2NvbC9wYXlsb2FkLg0KPiA+Pj4+Pj4g U28gbm8gaW5kaWNhdGlvbiBvZiB0aGUgYWN0dWFsIHBheWxvYWQgY29udGVudCB3YXMgbmVjZXNz YXJ5Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IElNSE8geW91IGNvdWxkIHVzZSB0aGUgYWxlcnQgbGFi ZWwgMSB0byBpbmRpY2F0ZSB0byB0aGUgTFNSIHRoYXQNCj4gPj4+Pj4+IGl0IGhhcyB0byBmdXJ0 aGVyIGV4YW1pbmUgdGhlIGNvbnRlbnQgb2YgYSBwYWNrZXQuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g UmVnYXJkcywgSHV1Yi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiA9PT09PT09PQ0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+PiBJdCBzYWlkIGluIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVp bm4tc2ZjLW5zaC0wNCk6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAgICAgICBUaGUgc2VydmljZSBo ZWFkZXIgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIGVuY2Fwc3VsYXRpb24NCj4gPj4+Pj4+PiB1c2Vk IGFuZA0KPiA+PiBpcw0KPiA+Pj4+Pj4+ICAgICAgIGVuY2Fwc3VsYXRlZCBpbiBleGlzdGluZyB0 cmFuc3BvcnRzLiAgVGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KPiA+Pj4+Pj4+ICAgICAgIGluZGlj YXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQo+ ID4+Pj4+Pj4gICAgICAgZW5jYXBzdWxhdGlvbi4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEluIHRo ZSBjYXNlIHdoZXJlIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uIGlzIGFuIE1QTFMgTFNQLCBob3cg dG8NCj4gPj4+Pj4+PiBpbmRpY2F0ZSB0aGUNCj4gPj4+Pj4+IHByZXNlbmNlIG9mIE5TSCBzaW5j ZSB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIGhhcyBubyBleHBsaWNpdA0KPiA+Pj4+Pj4gcHJvdG9j b2wgaWRlbnRpZmllciBmaWVsZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUN Cj4gPj4+Pj4+IE1QTFMNCj4gPj4+IHBheWxvYWQ/DQo+ID4+Pj4+PiBTaG91bGQgd2UgbWFrZSBl YWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVuaXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZw0KPiA+Pj4+ Pj4gdGhlIHByZXNlbmNlIG9mIE5TSD8gT3Igc2hvdWxkIHdlIHVzZSB0aGUgY29udHJvbCB3b3Jk IHRvDQo+ID4+Pj4+PiBpbmRpY2F0ZSBpdD8gT3Igc2hvdWxkIHdlIHJlY29uc2lkZXIgdGhlIHBv c3NpYmlsaXR5IG9mIGFkZGluZyBhbg0KPiA+Pj4+Pj4gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRp ZmllciBmaWVsZCB0byB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHNvDQo+ID4+Pj4+PiBhcyB0byBz b2x2ZSBzdWNoIGtpbmQgb2YgaXNzdWVzDQo+ID4+Pj4gb25jZSBhbmQgZm9yIGFsbD8NCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtLQ0KPiA+Pj4+Pj4NCj4gPj4+Pg0KPiA+ Pj4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KPiA+Pj4gKioqDQo+ID4+Pj4+PiAqKioqDQo+ID4+Pj4+PiAgICAgICAgICAgICAg ICAgIMfrvMfXoaOsxOPKx7bA0rvO3rb+tcSjrL7Nz/HG5Mv7w7/Su7j2yMvSu9H5DQo+ID4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IHNmYyBtYWlsaW5n IGxpc3QNCj4gPj4+Pj4gc2ZjQGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAtLQ0KPiA+Pj4+ DQo+ID4+Pj4NCj4gPj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1h aWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiA+Pj4+IFNlbmlvciBNUExTIEV4cGVydCAgICAg ICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+ID4+Pj4gSHVhd2VpIFRlY2hub2xvZ2ll cyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzZmMgbWFpbGluZyBs aXN0DQo+ID4gc2ZjQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4gPg0KPiANCj4gLS0NCj4gDQo+IA0KPiBMb2EgQW5kZXJzc29uICAgICAg ICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3Ig TVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBIdWF3ZWkg VGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Tue Jan 27 03:24:38 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9948E1A8782; Tue, 27 Jan 2015 03:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7dfOw9pHtQS; Tue, 27 Jan 2015 03:24:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B951A8794; Tue, 27 Jan 2015 03:24:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL96717; Tue, 27 Jan 2015 11:24:32 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 11:24:31 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 19:24:23 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AdA6Iy10hnzSmHMYSNeVsID5YDgzbA== Date: Tue, 27 Jan 2015 11:24:23 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [mpls] New Comments on Segment Routing(7): MTU Challenges for SR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 11:24:36 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQpUaGlzIGlzIHRoZSBzZXZlbnRo IGNvbW1lbnMuIFRoZSBpc3N1ZXMgcHJvcG9zZWQgaGVyZSBhcmUgZm9yIGJvdGggU1ItVEUgcGF0 aCBhbmQgU1ItQkUgcGF0aC4NCg0KDQoNCiAgICAgICAgIDEgICAgICAgICAgICAgIDEgICAgICAg ICAgIDEgICAgICAgICAgICAxDQogIFMxMS0tLS0tLS0tLS0tUzEyLS0tLS0tLS0tLVMxMy0tLS0t LS0tLVMxNC0tLS0tLS0tLVMxNQ0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgfCAgICAgICAgICAgfA0KICAxfCAgICAgICAgICAgIDF8ICAgICAgICAgICAxfCAgICAg ICAgICAxfCAgICAgICAgICAxfA0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgfCAgICAgICAgICAgfA0KICBTMjEtLS0tLS0tLS0tLVMyMi0tLS0tLS0tLS1TMjMtLS0t LS0tLS1TMjQtLS0tLS0tLS1TMjUNCiAgICAgICAgIDQgICAgICAgICAgICAgIDQgICAgICAgICAg IDQgICAgICAgICAgICA0DQoNCg0KDQpTdGlsbCB0YWtlIHRoZSB0b3BvbG9neSBpbiB0aGUgY29t bWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIgdGhlIGxvb3NlIGV4cGxpY2l0IHBhdGgg b3INCg0KdGhlIHN0cmljdCBleHBsaWNpdCBwYXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUg dGhlIE1UVSBvZiB0aGUgaW50ZXJmYWNlIGlzIHRoZSBzYW1lLA0KDQpzaW5jZSB0aGUgZGVwdGgg b2YgdGhlIGxhYmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBw YXRoIGFyZSBkaWZmZXJlbnQuDQoNClRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0aXZl IHBheWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlIHByaW1hcnkgcGF0aCwgYnV0IG1heSBi ZQ0KDQpmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBwYXRoLiBBcyB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIHRoZSBsYWJlbCBzdGFja3Mgb2YgdGhlDQoNCnByaW1hcnkgcGF0aCBh bmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0aGUgcmlzayB3aWxsIGluY3JlYXNlLg0KDQoN Cg0KRnJvbSB0aGUgY2FzZSwgd2UgY2FuIGRlZHVjZSB0aGF0IHRoZSByaXNrIG1heSBleGlzdHMg Zm9yIGFueSBzY2VuYXJpb3MgaW4gd2hpY2ggdGhlIHNhbWUgdHJhZmZpYw0KDQogbWF5IHN3aXRj aCBmcm9tIG9uZSBTUiBwYXRoIHRvIHRoZSBvdGhlciBTUiBwYXRoLiBUaGUgU1IgcGF0aCBpbmNs dWRlcyBTUi1URSBwYXRoIHN1Y2ggYXMgTVBMUyBURQ0KDQpob3RzdGFuZGJ5L3Jlb3B0aW1pemF0 aW9uIGFuZCBTUi1CRSBwYXRoIHN1Y2ggYXMgVEktRlJSLg0KDQoNCg0KQmVzaWRlcyBhYm92ZSBp c3N1ZXMsIExEUC9SU1ZQLVRFIGNhbiBzdXBwb3J0IHRoZSBwYXRoIE1UVSB0byB0cmFjayB0aGUg TVRVIGluZm9ybWFpdG9uIGFsb25nIHRoZQ0KDQpMU1AgdGhyb3VnaCBzaWduYWxsaW5nLiBUaGVu IHRoZSByZWFzb25hYmxlIE1UVSBpbmZvIHdpbGwgYmUgYWRvcHRlZCBpbiB0aGUgaW5ncmVzcyBu b2RlLiBGb3IgYm90aA0KDQogU1ItVEUgcGF0aCAoaWYgUENFIGlzIG5vdCB1c2VkKSBhbmQgU1It QkUgcGF0aCwgc2luY2UgdGhlcmUgaXMgbm8gc2lnbmFsbGluZyB0byBhZHZlcnRpc2UNCg0KdGhl IGluZm9ybWF0aW9uLiBIb3cgdG8gaW1wbGVtZW50IHRoZSBmZWF0dXJlPyBPciB0aGVyZSBtYXli ZSB0aGUgcmlzayB0aGF0IHRoZSBwYWNrZXQgbWF5IGJlDQoNCmRyb3BwZWQgYnkgdGhlIG5vZGVz IGFsb25nIHRoZSBMU1AuDQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMsDQoNClJvYmluDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,


This is the seventh commens. The issues proposed here are for both SR-TE pa= th and SR-BE path.

 


         1    &= nbsp;         1   &n= bsp;       1     &nb= sp;      1
  S11-----------S12----------S13---------S14---------S15
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  1|           = 1|           1| &nb= sp;        1|    &nb= sp;     1|
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  S21-----------S22----------S23---------S24---------S25
         4    &= nbsp;         4   &n= bsp;       4     &nb= sp;      4

 

Still take the topology in the comment 6 as the example. No matter the l= oose explicit path or

the strict explicit path for the loose hop, assume the MTU of the interf= ace is the same,

since the depth of the label stacks for the primary path and the backup = path are different.

There is the risk that the effetive payload may transmit through the pri= mary path, but may be

fragmented or dropped in the backup path. As the difference between the = label stacks of the

primary path and the backup path increase, the risk will increase.

 

From the case, we can deduce that the risk may exists for any scenarios = in which the same traffic

 may switch from one SR path to the other SR path. The SR path incl= udes SR-TE path such as MPLS TE

hotstandby/reoptimization and SR-BE path such as TI-FRR.

 

Besides above issues, LDP/RSVP-TE can support the path MTU to track the = MTU informaiton along the

LSP through signalling. Then the reasonable MTU info will be adopted in = the ingress node. For both

 SR-TE path (if PCE is not used) and SR-BE path, since there is no = signalling to advertise

the information. How to implement the feature? Or there maybe the risk t= hat the packet may be

dropped by the nodes along the LSP.

 

 

 

Regards,

Robin

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9nkgeml506mbxchi_-- From nobody Tue Jan 27 03:41:49 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB2B1A8797; Tue, 27 Jan 2015 03:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.792 X-Spam-Level: X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdX5iRxLK-hB; Tue, 27 Jan 2015 03:41:43 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F3D1A2119; Tue, 27 Jan 2015 03:41:42 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0811.eurprd03.prod.outlook.com (25.161.55.143) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 11:01:00 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 11:00:59 +0000 From: Alexander Vainshtein To: Xuxiaohu Thread-Topic: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegARJH4AAIdmfAAABiq6FgAzM48AAAK7wgAAAgCbEAAAiTyAAAOaX3A= Date: Tue, 27 Jan 2015 11:00:59 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ecitele.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0811; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0811; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(377454003)(51704005)(252514010)(377424004)(19300405004)(19580395003)(19580405001)(74316001)(86362001)(87936001)(2656002)(62966003)(54206007)(77156002)(66066001)(92566002)(2950100001)(19625215002)(33656002)(102836002)(15975445007)(2900100001)(76576001)(16236675004)(110136001)(16234385003)(40100003)(122556002)(54606007)(54356999)(93886004)(46102003)(76176999)(19617315012)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0811; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0812936A8223F4750DAEA9849D320DB3PR03MB0812eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 11:00:59.6629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0811 Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 11:41:47 -0000 --_000_DB3PR03MB0812936A8223F4750DAEA9849D320DB3PR03MB0812eurp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WGlhb2h1LA0KDQpJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBteSBwb3NpdGlvbi4NCg0KMS4gICAg ICAgQXBwbGljYXRpb24gbGV2ZWwgYW5kIGEgZGVkaWNhdGVkIEVTUCBhcmUgdHdvIGFsdGVybmF0 aXZlIG9wdGlvbnMgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiB0aGUgcGF5bG9h ZCBvZiBhIGxhYmVsZWQgcGFja2V0Lg0KDQphLiAgICAgICBBIGRlZGljYXRlZCBFU1AgY291bGQg YmUgdXNlZCBpZiBhc3NvY2lhdGlvbiBvZiB0aGUgcmVjZWl2ZWQgcGFja2V0IHdpdGggYSBzcGVj aWZpYyBTRiBpbnN0YW5jZSB3aXRoaW4gdGhlIHByb2Nlc3NpbmcgTkUgY2FuIGJlIHBlcmZvcm1l ZCBiYXNlZCBleGNsdXNpdmVseSBvbiBOU0guIEp1c3Qgb25lIEVTUCBsYWJlbCB3b3VsZCBiZSB1 c2VkIChvY2N1cHlpbmcgMiBlbnRyaWVzIGluIHRoZSBsYWJlbCBzdGFjayksIGFuZCBpdCB3b3Vs ZCBqdXN0IGJlIHRyZWF0ZWQgYXMgdGhlIE5TSCBwcmVzZW5jZSBpbmRpY2F0b3IuIFRoaXMgc2l0 dWF0aW9uIGlzIHNpbWlsYXIgdG8gdXNpbmcgdGhlIEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVs IExhYmVsIChHQUwpIGluIE1QTFMtVFAuDQoNCmIuICAgICAgQW4gYXBwbGljYXRpb24gbGFiZWwg cGVyIFNGIGluc3RhbmNlIHNob3VsZCBiZSB1c2VkIGlmIHRoZSBOU0ggaGVhZGVyIGlzIG5vdCBz dWZmaWNpZW50IGZvciBkZWZpbmluZyB0aGUgU0YgaW5zdGFuY2UgdGhhdCB3b3VsZCBoYW5kbGUg dGhlIHBhY2tldC4gQSBkZWRpY2F0ZWQgYXBwbGljYXRpb24gbGFiZWwgd291bGQgYmUgYWxsb2Nh dGVkIGF0IGxlYXN0IHBlciBTRiBpbnN0YW5jZSB3aXRoaW4gdGhlIE5FLCBhbmQgc29tZSBzdWl0 YWJsZSBwcm90b2NvbCB3b3VsZCBiZSB1c2VkIGZvciBkaXN0cmlidXRpbmcgYXNzb2NpYXRpb24g YmV0d2VlbiB0aGlzIGxhYmVsIGFuZCBpdHMgc3BlY2lmaWMgU0YgaW5zdGFuY2UuIFRoaXMgaXMg c2ltaWxhciB0byB1c2luZyBQVyBsYWJlbHMgaW4gUFdzIGFuZC9vciBBcHBsaWNhdGlvbiBsYWJl bHMgKGRpc3RyaWJ1dGVkIHdpdGggdGhlaXIgYXNzb2NpYXRlZCBsYWJlbGVkIElQLVZQTiByb3V0 ZXMpIGluIEwzVlBODQoNCmMuICAgICAgIE15IGtub3dsZWRnZSBvZiBTRkMgaXMgYWxsIGJ1dCBv bi1leGlzdGVudCwgc28gSSBjYW5ub3Qgc2F5IHdoaWNoIG9mIHRoZXNlIHR3byBhbHRlcm5hdGl2 ZXMgaXMgcmVsZXZhbnQuDQoNCjIuICAgICAgIEluIGJvdGggY2FzZXMgdGhlIGxhYmVsIChiZSBp dCBhbiBhcHBsaWNhdGlvbiBsYWJlbCBvciBhIGRlZGljYXRlZCBFU1ApIG11c3QgYmUgaW5zZXJ0 ZWQgYnkgdGhlIGhlYWQtZW5kIGF0IHRoZSBCb1Mgc28gdGhhdCBpdCB3b3VsZCBiZSBwcm9jZXNz ZWQgYnkgdGhlIHRhaWwtZW5kIG5vZGUgb2YgdGhlIExTUCB3aXRob3V0IGFmZmVjdGluZyBhbnkg dHJhbnNpdCBub2RlcyAod2hpY2ggd291bGQganVzdCBwZXJmb3JtIHN0YW5kYXJkIE1QTFMgZm9y d2FyZGluZykuDQoNCjMuICAgICAgIEluIHRoZSBjYXNlIG9mIFNGIHBhdGhzOg0KDQphLiAgICAg ICBJZiB0aGUgZGVkaWNhdGVkIEVTUCBpcyB1c2VkLCBoYW5kbGluZyBvZiB0aGUgcGFja2V0IGJ5 IHRoZSBjdXJyZW50IFNGIG11c3QgaW5jbHVkZSBkZWZpbml0aW9uIG9mIHRoZSBuZXh0IFNGIG5v ZGUgYW5kIGZvcndhcmRpbmcgdG8gdGhpcyBub2RlLiBUaGUgZm9yd2FyZGVkIHBhY2tldCB3b3Vs ZCBhZ2FpbiBpbmNsdWRlIHRoZSBkZWRpY2F0ZWQgRVNQIGF0IHRoZSBCb1MsIHdpdGggdGhlIKGw dHVubmVsIExTUKGxIGxhYmVsIHN0YWNrIG9uIHRvcCBvZiB0aGF0DQoNCmIuICAgICAgSWYgdGhl IGFwcGxpY2F0aW9uIGxhYmVsIGlzIHVzZWQsIHRoZSBuZXh0IFNGIG5vZGUgYW5kIHRoZSBTRiBp bnN0YW5jZSB3aXRoaW4gdGhpcyBub2RlIGNvdWxkIGJlIGluZmVycmVkIGVpdGhlciBmcm9tIHRo ZSBwYXlsb2FkIG9yIGZyb20gdGhlIGFwcGxpY2F0aW9uIGxhYmVsLCBvciBmcm9tIHRoZWlyIGNv bWJpbmF0aW9uLiBJbiBhbnkgY2FzZSBmb3J3YXJkaW5nIG9mIHRoZSBwYWNrZXQgdG8gdGhlIG5l eHQgU0Ygd291bGQgcmVzdWx0IGluIHN3YXBwaW5nIG9mIHRoZSBhcHBsaWNhdGlvbiBsYWJlbCBh dCB0aGUgQm9TIChzaW1pbGFyIHRvIHdoYXQgaXMgZG9uZSBpbiBNUy1QV3MpIGFuZCBwdXNoaW5n IHRoZSChsHR1bm5lbCBMU1ChsSBsYWJlbCBzdGFjayBvbiB0b3Agb2YgdGhhdC4NCg0KDQoNCk5v dCBzdXJlIGlmIHRoaXMgaGVscHMsIG9yIGp1c3QgYWRkcyBtb3JlIG5vaXNlOikuDQoNCg0KDQpS ZWdhcmRzLA0KDQogICAgICAgU2FzaGENCg0KRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tDQoNCk1vYmlsZTogMDU0LTkyNjYzMDINCg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3 ZWkuY29tXQ0KDQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjcsIDIwMTUgMTA6NTkgQU0NCg0K PiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4NCg0KPiBDYzogbXBsc0BpZXRmLm9yZzsgc2ZjQGll dGYub3JnOyBMb2EgQW5kZXJzc29uDQoNCj4gU3ViamVjdDogUkU6IFtzZmNdIFttcGxzXSBIb3cg dG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQoNCj4gcGFja2V0Pw0K DQo+DQoNCj4gSGkgU2FzaGEsDQoNCj4NCg0KPiBJZiBvbmx5IG9uZSBhcHBsaWNhdGlvbiBsYWJl bCBpcyByZXF1aXJlZCB0byBiZSBpbnNlcnRlZCBpbnRvIHRoZSBsYWJlbCBzdGFjaywNCg0KPiB3 aGVyZSBzaG91bGQgaXQgYmUgaW5zZXJ0ZWQ/IGF0IHRoZSBCb1M/IElmIHNvLCBpdCBzZWVtcyB0 aGF0IHRoZSBhcHBsaWNhdGlvbg0KDQo+IGxhYmVsIG11c3QgYmUgYW4gRVNQIGxhYmVsLg0KDQo+ DQoNCj4gQmVzdCByZWdhcmRzLA0KDQo+IFhpYW9odQ0KDQo+DQoNCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KDQo+ID4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCg0KPiA+IFNlbnQ6IFR1ZXNkYXksIEph bnVhcnkgMjcsIDIwMTUgNDo0NiBQTQ0KDQo+ID4gVG86IFh1eGlhb2h1DQoNCj4gPiBDYzogbXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPjsgTG9hIEFuZGVyc3Nvbg0KDQo+ID4gU3ViamVjdDogUkU6IFtzZmNdIFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTDQoNCj4gcGFj a2V0Pw0KDQo+ID4NCg0KPiA+IFhpYW9oIGhpIQ0KDQo+ID4gSSBkbyBub3QgdGhpbmsgeW91IG5l ZWQgbXVsdGlwbGUgYXBwbGljYXRpb24gbGFiZWxzLg0KDQo+ID4gUmF0aGVyLCB5b3UgY291bGQg c3dhcCB0aGVzZSBsYWJlbHMgYXMgdGhlIHBhY2tldCBwcm9ncmVzc2VzIGFsb25nIHRoZQ0KDQo+ ID4gU0ZQLCBzYW1lIGFzIGlzIGRvbmUgd2l0aCBNUy1QV3MuDQoNCj4gPg0KDQo+ID4gUmVnYXJk cywNCg0KPiA+ICAgICAgICBTYXNoYQ0KDQo+ID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCg0K PiA+IE1vYmlsZTogMDU0LTkyNjYzMDINCg0KPiA+DQoNCj4gPg0KDQo+ID4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KDQo+ID4gPiBGcm9tOiBYdXhpYW9odSBbbWFpbHRvOnh1eGlhb2h1 QGh1YXdlaS5jb21dDQoNCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjcsIDIwMTUgOTo0 NiBBTQ0KDQo+ID4gPiBUbzogTG9hIEFuZGVyc3NvbjsgQWxleGFuZGVyIFZhaW5zaHRlaW4NCg0K PiA+ID4gQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCg0KPiA+ID4gU3ViamVjdDogUkU6IFtzZmNdIFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbg0KDQo+ID4gPiBNUExT IHBhY2tldD8NCg0KPiA+ID4NCg0KPiA+ID4NCg0KPiA+ID4NCg0KPiA+ID4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KDQo+ID4gPiA+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzps b2FAcGkubnVdDQoNCj4gPiA+ID4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAyOjI4 IFBNDQoNCj4gPiA+ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBYdXhpYW9odQ0KDQo+ID4g PiA+IENjOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQoNCj4gPiA+ID4gU3ViamVjdDogUmU6IFtzZmNdIFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbg0KDQo+ID4gPiA+IGFuIE1Q TFMNCg0KPiA+ID4gcGFja2V0Pw0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gU2FzaGEsDQoNCj4gPiA+ ID4NCg0KPiA+ID4gPg0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gT24gMjAxNS0wMS0yNiAxNDoyMSwg QWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQoNCj4gPiA+ID4gPiBYaWFvaHUsIEh1dWIsDQoN Cj4gPiA+ID4gPiBJIGRvIG5vdCBmb2xsb3cgdGhlIFNGQyB3b3JrIGNsb3NlbHksIHNvIEkgd291 bGQgbGlrZSB0bw0KDQo+ID4gPiA+ID4gdW5kZXJzdGFuZCB3aGV0aGVyIHRoZQ0KDQo+ID4gPiA+ IE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0gb3Ig anVzdCBieQ0KDQo+ID4gPiA+IHRoZSBMRVIgYWN0aW5nIGFzIHRoZSBMU1AgdGFpbC1lbmQ/DQoN Cj4gPiA+ID4gPg0KDQo+ID4gPiA+ID4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2lt cGxlc3Qgd2F5IHRvIGluZGljYXRlIHByZXNlbmNlDQoNCj4gPiA+ID4gPiBvZiB0aGUgTlNIIGlu IHRoZQ0KDQo+ID4gPiA+IE1QTFMgcGF5bG9hZCB3b3VsZCBiZSBieSBhbGxvY2F0aW5nIGFuICJh cHBsaWNhdGlvbiBsYWJlbCINCg0KPiA+ID4gPiBpbmRpY2F0aW5nIGl0cyBwcmVzZW5jZSBieSB0 aGUgdGFpbC1lbmQgTEVSIGFuZCBieSBpbnNlcnRpbmcgaXQgYXQNCg0KPiA+ID4gPiB0aGUgYm90 dG9tIG9mIHRoZSBsYWJlbCBzdGFjayBieSB0aGUgaGVhZC1lbmQgTEVSIC0gc2ltaWxhciB0bw0K DQo+ID4gPiA+IHdoYXQgaXMgZG9uZSBmb3IgTDIvTDNWUE4uICBXaXRoaW4gdGhpcyBhcHByb2Fj aCwgaWYgbGFiZWwtYmFzZWQNCg0KPiA+ID4gPiBkZW11bHRpcGxleGluZyBvZiBwYWNrZXRzIHdp dGggTlNIIGluIHRoZSBNUExTIHBheWxvYWQgaXMgbm90DQoNCj4gPiA+ID4gcmVxdWlyZWQsIHlv dSBjb3VsZCByZXF1ZXN0IGFsbG9jYXRpb24gb2YgYSBuZXcgc3BlY2lhbCBwdXJwb3NlDQoNCj4g PiA+ID4gbGFiZWwgZnJvbSB0aGUgZXh0ZW5kZWQgc3BlY2lhbCBwdXJwb3NlcyBsYWJlbCBzcGFj ZSBhcyBwZXIgUkZDDQoNCj4gPiA+ID4gNzI3NCwgYW5kIHRvIGluc2VydCBzdWNoIGEgbGFiZWwN Cg0KPiA+ID4gKHByZWNlZGVkIGJ5IHRoZSBFeHRlbnNpb24gTGFiZWwgKSBhdCB0aGUgQm9TLg0K DQo+ID4gPiA+ID4NCg0KPiA+ID4gPiBJIHRoaW5rICJ0aGUgbGF0dGVyIiBpcyBjb3JyZWN0LCB0 aGUgb25seSBpc3N1ZSBJIHNlZSBpcyBhZGRpbmcNCg0KPiA+ID4gPiBvbmUgbW9yZSBsYWJlbCBz dGFjayBlbnRyeSB0byB0aGUgbGFiZWwgc3RhY2suDQoNCj4gPiA+DQoNCj4gPiA+IFllcywgdGhl IGxhdHRlciBpcyBjb3JyZWN0LiBUaGUgaXNzdWUgb2YgYWRkaW5nIG9uZSBtb3JlIGxhYmVsIHN0 YWNrDQoNCj4gPiA+IGVudHJ5IHRvIHRoZSBsYWJlbCBzdGFjayBtYXkgYmVjb21lIHVuYWNjZXB0 YWJsZSBpbiB0aGUgY2FzZSB3aGVyZQ0KDQo+ID4gPiB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRo IChTRlApIGlzIHJlcHJlc2VudGVkIGJ5IGFuIGxhYmVsIHN0YWNrDQoNCj4gPiA+IHdoaWxlIHRo ZSBOU0ggaXMgbm93IG9ubHkgdXNlZCBhcyBhIG1ldGFkYXRhIGNvbnRhaW5lci4gRm9yIGV4YW1w bGUsDQoNCj4gPiA+IGZvciBhbiBTRlAgY29uc2lzdCBvZiBuIFNGcywgbiAiYXBwbGljYXRpb24g bGFiZWxzIiB3b3VsZCBoYXZlIHRvIGJlDQoNCj4gaW5zZXJ0ZWQgaW50byB0aGUgbGFiZWwgc3Rh Y2suDQoNCj4gPiA+DQoNCj4gPiA+IEJlc3QgcmVnYXJkcywNCg0KPiA+ID4gWGlhb2h1DQoNCj4g PiA+DQoNCj4gPiA+ID4gL0xvYQ0KDQo+ID4gPiA+ID4gSWYgdGhlIGZvcm1lciBpcyBjb3JyZWN0 LCB0aGUgcHJvY2VzcyBhYm92ZSBzdGlsbCBoYXMgdG8gYmUgdXNlZA0KDQo+ID4gPiA+ID4gYnV0 IGl0IGhhcyB0byBiZQ0KDQo+ID4gPiA+IGF1Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBB bGVydCBMYWJlbCAgIGF0IHRoZSB0b3Agb2YgdGhlIGxhYmVsDQoNCj4gc3RhY2suDQoNCj4gPiA+ ID4gPg0KDQo+ID4gPiA+ID4gIEZyb20gbXkgUE9WIHRoZXNlIHN1Z2dlc3Rpb25zIGFyZSBpbiBs aW5lIHdpdGggdGhlIHByb3Zpc2lvbnMNCg0KPiA+ID4gPiA+IG9mIFNlY3Rpb24gMi4yDQoNCj4g PiA+ID4gb2YgUkZDIDMwMzIgIkRldGVybWluaW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3RvY29s IiB0aGF0IHN0YXRlczoNCg0KPiA+ID4gPiA+DQoNCj4gPiA+ID4gPiA8cXVvdGU+DQoNCj4gPiA+ ID4gPiAgICAgV2hlbiB0aGUgbGFzdCBsYWJlbCBpcyBwb3BwZWQgZnJvbSBhIHBhY2tldCdzIGxh YmVsIHN0YWNrIChyZXN1bHRpbmcNCg0KPiA+ID4gPiA+ICAgICBpbiB0aGUgc3RhY2sgYmVpbmcg ZW1wdGllZCksIGZ1cnRoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0IGlzDQoNCj4gPiA+ID4g PiAgICAgYmFzZWQgb24gdGhlIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgaGVhZGVyLiAgVGhlIExT UiB3aGljaA0KDQo+ID4gPiA+ID4gcG9wcw0KDQo+ID4gdGhlDQoNCj4gPiA+ID4gPiAgICAgbGFz dCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11c3QgdGhlcmVmb3JlIGJlIGFibGUgdG8gaWRlbnRpZnkg dGhlDQoNCj4gPiA+ID4gPiAgICAgcGFja2V0J3MgbmV0d29yayBsYXllciBwcm90b2NvbC4gIEhv d2V2ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5vdA0KDQo+ID4gPiA+ID4gICAgIGNvbnRhaW4g YW55IGZpZWxkIHdoaWNoIGV4cGxpY2l0bHkgaWRlbnRpZmllcyB0aGUgbmV0d29yayBsYXllcg0K DQo+ID4gPiA+ID4gICAgIHByb3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBpZGVudGl0eSBv ZiB0aGUgbmV0d29yayBsYXllciBwcm90b2NvbA0KDQo+ID4gPiA+ID4gICAgIG11c3QgYmUgaW5m ZXJhYmxlIGZyb20gdGhlIHZhbHVlIG9mIHRoZSBsYWJlbCB3aGljaCBpcyBwb3BwZWQgZnJvbQ0K DQo+ID4gPiA+ID4gICAgIHRoZSBib3R0b20gb2YgdGhlIHN0YWNrLCBwb3NzaWJseSBhbG9uZyB3 aXRoIHRoZSBjb250ZW50cyBvZiB0aGUNCg0KPiA+ID4gPiA+ICAgICBuZXR3b3JrIGxheWVyIGhl YWRlciBpdHNlbGYuDQoNCj4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0KDQo+ID4gPiA+ID4NCg0KPiA+ ID4gPiA+IE15IDJjLA0KDQo+ID4gPiA+ID4gU2FzaGENCg0KPiA+ID4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPiA+ID4gPiA+IEZyb206IG1wbHMgPG1w bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIFh1eGlhb2h1DQoNCj4gPiA+ID4gPiA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86 eHV4aWFvaHVAaHVhd2VpLmNvbT4+DQoNCj4gPiA+ID4gPiBTZW50OiBNb25kYXksIEphbnVhcnkg MjYsIDIwMTUgNTowNSBBTQ0KDQo+ID4gPiA+ID4gVG86IGh1dWJhdHdvcmtAZ21haWwuY29tPG1h aWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCg0KPiA+ID4gPiA+IFN1 YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4NCg0KPiA+ID4gPiA+IE1QTFMNCg0KPiA+ID4gcGFja2V0Pw0KDQo+ID4gPiA+ID4NCg0KPiA+ ID4gPiA+IEhpIEh1dWIsDQoNCj4gPiA+ID4gPg0KDQo+ID4gPiA+ID4gVGhlIGFsdGVyIGxhYmVs IGl0c2VsZiBjb3VsZG6hr3QgbWFrZSB0aGUgcmVjZWl2aW5nIExTUiB0bw0KDQo+ID4gPiA+ID4g ZGV0ZXJtaW5lIHRoZSBNUExTDQoNCj4gPiA+ID4gcGF5bG9hZCB0eXBlIGJ5IGV4YW1pbmluZyB0 aGUgTVBMUyBwYXlsb2FkLg0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+IEJlc3QgcmVnYXJkcywN Cg0KPiA+ID4gPiA+IFhpYW9odQ0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KDQo+ID4gPiA+ID4+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFtt YWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQoNCj4gPiA+ID4gPj4gU2VudDogRnJpZGF5LCBK YW51YXJ5IDIzLCAyMDE1IDY6MjggUE0NCg0KPiA+ID4gPiA+PiBUbzogWHV4aWFvaHU7IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NCg0KPiA+ID4gPiA+PiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0 ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuDQoNCj4gPiA+ID4gPj4gTVBMUw0KDQo+ID4gPiBw YWNrZXQ/DQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+PiBYdXhpYW9odSDE+rrDo6ENCg0KPiA+ ID4gPiA+Pg0KDQo+ID4gPiA+ID4+IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3Jvbmc6DQoN Cj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+PiBJdCBoYXMgYWx3YXlzIGJlZW4gbXkgdW5kZXJzdGFu ZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJlbA0KDQo+ID4gPiA+ID4+IHdhcyBpbmRlcGVu ZGVudCBvZiB0aGUgcHJvdG9jb2wvcGF5bG9hZC4NCg0KPiA+ID4gPiA+PiBTbyBubyBpbmRpY2F0 aW9uIG9mIHRoZSBhY3R1YWwgcGF5bG9hZCBjb250ZW50IHdhcyBuZWNlc3NhcnkuDQoNCj4gPiA+ ID4gPj4NCg0KPiA+ID4gPiA+PiBJTUhPIHlvdSBjb3VsZCB1c2UgdGhlIGFsZXJ0IGxhYmVsIDEg dG8gaW5kaWNhdGUgdG8gdGhlIExTUg0KDQo+ID4gPiA+ID4+IHRoYXQgaXQgaGFzIHRvIGZ1cnRo ZXIgZXhhbWluZSB0aGUgY29udGVudCBvZiBhIHBhY2tldC4NCg0KPiA+ID4gPiA+Pg0KDQo+ID4g PiA+ID4+IFJlZ2FyZHMsIEh1dWIuDQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+PiA9PT09PT09 PQ0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1zZmMtbnNoLTA0KToNCg0KPiA+ID4gPiA+Pj4NCg0K PiA+ID4gPiA+Pj4gICAgICBUaGUgc2VydmljZSBoZWFkZXIgaXMgaW5kZXBlbmRlbnQgb2YgdGhl IGVuY2Fwc3VsYXRpb24NCg0KPiA+ID4gPiA+Pj4gdXNlZCBhbmQNCg0KPiA+IGlzDQoNCj4gPiA+ ID4gPj4+ICAgICAgZW5jYXBzdWxhdGVkIGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBUaGUgcHJl c2VuY2Ugb2YgTlNIIGlzDQoNCj4gPiA+ID4gPj4+ICAgICAgaW5kaWNhdGVkIHZpYSBwcm90b2Nv bCB0eXBlIG9yIG90aGVyIGluZGljYXRvciBpbiB0aGUgb3V0ZXINCg0KPiA+ID4gPiA+Pj4gICAg ICBlbmNhcHN1bGF0aW9uLg0KDQo+ID4gPiA+ID4+Pg0KDQo+ID4gPiA+ID4+PiBJbiB0aGUgY2Fz ZSB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBhbiBNUExTIExTUCwgaG93DQoNCj4g PiA+ID4gPj4+IHRvIGluZGljYXRlIHRoZQ0KDQo+ID4gPiA+ID4+IHByZXNlbmNlIG9mIE5TSCBz aW5jZSB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIGhhcyBubyBleHBsaWNpdA0KDQo+ID4gPiA+ID4+ IHByb3RvY29sIGlkZW50aWZpZXIgZmllbGQgdG8gaW5kaWNhdGUgdGhlIHByb3RvY29sIHR5cGUg b2YgdGhlDQoNCj4gPiA+ID4gPj4gTVBMUw0KDQo+ID4gPiBwYXlsb2FkPw0KDQo+ID4gPiA+ID4+ IFNob3VsZCB3ZSBtYWtlIGVhY2ggU0ZGIHRvIGFsbG9jYXRlIGEgdW5pcXVlIGxhYmVsIGZvcg0K DQo+ID4gPiA+ID4+IGluZGljYXRpbmcgdGhlIHByZXNlbmNlIG9mIE5TSD8gT3Igc2hvdWxkIHdl IHVzZSB0aGUgY29udHJvbA0KDQo+ID4gPiA+ID4+IHdvcmQgdG8gaW5kaWNhdGUgaXQ/IE9yIHNo b3VsZCB3ZSByZWNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZg0KDQo+ID4gPiA+ID4+IGFkZGlu ZyBhbiBleHBsaWNpdCBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRvIHRoZSBNUExTDQoNCj4g PiA+ID4gPj4gZW5jYXBzdWxhdGlvbiBzbyBhcyB0byBzb2x2ZSBzdWNoIGtpbmQgb2YgaXNzdWVz DQoNCj4gPiA+ID4gb25jZSBhbmQgZm9yIGFsbD8NCg0KPiA+ID4gPiA+Pj4NCg0KPiA+ID4gPiA+ Pj4gQmVzdCByZWdhcmRzLA0KDQo+ID4gPiA+ID4+PiBYaWFvaHUNCg0KPiA+ID4gPiA+Pj4NCg0K PiA+ID4gPiA+Pg0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4gLS0NCg0KPiA+ID4gPiA+Pg0K DQo+ID4gPiA+DQoNCj4gPiA+DQoNCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo+ID4gPiAqKioNCg0KPiA+ID4gPiA+PiAqKioq DQoNCj4gPiA+ID4gPj4gICAgICAgICAgICAgICAgIMfrvMfXoaOsxOPKx7bA0rvO3rb+tcSjrL7N z/HG5Mv7w7/Su7j2yMvSu9H5DQoNCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQo+ID4gPiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCg0K PiA+ID4gPiA+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQoNCj4gPiA+ID4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KPiA+ID4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gPiA+ ID4gPiBzZmMgbWFpbGluZyBsaXN0DQoNCj4gPiA+ID4gPiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCg0KPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQoNCj4gPiA+ID4gPg0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gLS0NCg0KPiA+ID4g Pg0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAg ICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2Vp LmNvbT4NCg0KPiA+ID4gPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAg ICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KDQo+ID4gPiA+IEh1YXdlaSBUZWNobm9s b2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_DB3PR03MB0812936A8223F4750DAEA9849D320DB3PR03MB0812eurp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Xiaohu,

I would like to clarify my position. <= /p>

1.       Application level and a de= dicated ESP are two alternative options to indicate the presence of NSH in = the payload of a labeled packet.

a.       A dedicated ESP could be u= sed if association of the received packet with a specific SF instance withi= n the processing NE can be performed based exclusively on NSH. Just one ESP= label would be used (occupying 2 entries in the label stack), and it would just be treated as the NSH prese= nce indicator. This situation is similar to using the Generic Associated Ch= annel Label (GAL) in MPLS-TP.

b.      An application label per S= F instance should be used if the NSH header is not sufficient for defining = the SF instance that would handle the packet. A dedicated application label= would be allocated at least per SF instance within the NE, and some suitable protocol would be used for distr= ibuting association between this label and its specific SF instance. This i= s similar to using PW labels in PWs and/or Application labels (distributed = with their associated labeled IP-VPN routes) in L3VPN

c.       My knowledge of SFC is all= but on-existent, so I cannot say which of these two alternatives is releva= nt.

2.       In both cases the label (b= e it an application label or a dedicated ESP) must be inserted by the head-= end at the BoS so that it would be processed by the tail-end node of the LS= P without affecting any transit nodes (which would just perform standard MPLS forwarding).

3.       In the case of SF paths:

a.       If the dedicated ESP is us= ed, handling of the packet by the current SF must include definition of the= next SF node and forwarding to this node. The forwarded packet would again= include the dedicated ESP at the BoS, with the =A1=B0tunnel LSP=A1=B1 label stack on top of that=

b.      If the application label i= s used, the next SF node and the SF instance within this node could be infe= rred either from the payload or from the application label, or from their c= ombination. In any case forwarding of the packet to the next SF would result in swapping of the application l= abel at the BoS (similar to what is done in MS-PWs) and pushing the =A1=B0t= unnel LSP=A1=B1 label stack on top of that.

 

Not sure if this helps, or just adds more noiseJ.

 

Regards,

       Sasha <= /o:p>

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

 

> -= ----Original Message-----

> F= rom: Xuxiaohu [mailto:xuxiaohu@huawei.com]

> S= ent: Tuesday, January 27, 2015 10:59 AM

> T= o: Alexander Vainshtein

> C= c: mpls@ietf.org; sfc@ietf.org; Loa Andersson

> S= ubject: RE: [sfc] [mpls] How to indicate the presence of NSH in an MPLS

> p= acket?

>

> Hi Sasha,

>

> If only one application label is required to= be inserted into the label stack,

> where should it be inserted? at the BoS? If = so, it seems that the application

> label must be an ESP label.

>

> Best regards,

> Xiaohu

>

> > -----Original Message-----

> > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]

> > Sent: Tuesday, January 27, 2015 4:46 PM=

> > To: Xuxiaohu

> > Cc: mpls@ietf.org; sfc@ietf.org; Loa Andersson

> > Subject: RE: [sfc] [mpls] How to indica= te the presence of NSH in an MPLS

> packet?

> >

> > Xiaoh hi!

> > I do not think you need multiple applic= ation labels.

> > Rather, you could swap these labels as = the packet progresses along the

> > SFP, same as is done with MS-PWs.

> >

> > Regards,

> >      &nbs= p; Sasha

> > Email: Alexander.Vainshtein@= ecitele.com

> > Mobile: 054-9266302

> >

> >

> > > -----Original Message-----

> > > From: Xuxiaohu [= mailto:xuxiaohu@huawei.com]

> > > Sent: Tuesday, January 27, 2015 9:= 46 AM

> > > To: Loa Andersson; Alexander Vains= htein

> > > Cc: mpls@ietf.org; sfc@ietf.org

> > > Subject: RE: [sfc] [mpls] How to i= ndicate the presence of NSH in an

> > > MPLS packet?

> > >

> > >

> > >

> > > > -----Original Message-----

> > > > From: Loa Andersson [mailto:loa@pi.nu]

> > > > Sent: Tuesday, January 27, 20= 15 2:28 PM

> > > > To: Alexander Vainshtein; Xux= iaohu

> > > > Cc: mpls@ietf.org= ; sfc@ietf.org

> > > > Subject: Re: [sfc] [mpls] How= to indicate the presence of NSH in

> > > > an MPLS

> > > packet?

> > > >

> > > > Sasha,

> > > >

> > > >

> > > >

> > > > On 2015-01-26 14:21, Alexande= r Vainshtein wrote:

> > > > > Xiaohu, Huub,

> > > > > I do not follow the SFC = work closely, so I would like to

> > > > > understand whether the

> > > > NSH should be captured by&nbs= p; transit LSRs on the LSP - or just by

> > > > the LER acting as the LSP tai= l-end?

> > > > >

> > > > > If the latter is correct= , the simplest way to indicate presence

> > > > > of the NSH in the

> > > > MPLS payload would be by allo= cating an "application label"

> > > > indicating its presence by th= e tail-end LER and by inserting it at

> > > > the bottom of the label stack= by the head-end LER - similar to

> > > > what is done for L2/L3VPN.&nb= sp; Within this approach, if label-based

> > > > demultiplexing of packets wit= h NSH in the MPLS payload is not

> > > > required, you could request a= llocation of a new special purpose

> > > > label from the extended speci= al purposes label space as per RFC

> > > > 7274, and to insert such a la= bel

> > > (preceded by the Extension Label )= at the BoS.

> > > > >

> > > > I think "the latter"= ; is correct, the only issue I see is adding

> > > > one more label stack entry to= the label stack.

> > >

> > > Yes, the latter is correct. The is= sue of adding one more label stack

> > > entry to the label stack may becom= e unacceptable in the case where

> > > the Service Function Path (SFP) is= represented by an label stack

> > > while the NSH is now only used as = a metadata container. For example,

> > > for an SFP consist of n SFs, n &qu= ot;application labels" would have to be

> inserted into the label stack.

> > >

> > > Best regards,

> > > Xiaohu

> > >

> > > > /Loa

> > > > > If the former is correct= , the process above still has to be used

> > > > > but it has to be

> > > > augmented by adding the Route= r Alert Label   at the top of the label

> stack.

> > > > >

> > > > >  From my POV these = suggestions are in line with the provisions

> > > > > of Section 2.2

> > > > of RFC 3032 "Determining= the Network Layer Protocol" that states:

> > > > >

> > > > > <quote>

> > > > >     = When the last label is popped from a packet's label stack (resulting

> > > > >     = in the stack being emptied), further processing of the packet is

> > > > >     = based on the packet's network layer header.  The LSR which

> > > > > pops

> > the

> > > > >     = last label off the stack must therefore be able to identify the

> > > > >     = packet's network layer protocol.  However, the label stack does not

> > > > >     = contain any field which explicitly identifies the network layer

> > > > >     = protocol.  This means that the identity of the network layer protocol<= /p>

> > > > >     = must be inferable from the value of the label which is popped from

> > > > >     = the bottom of the stack, possibly along with the contents of the

> > > > >     = network layer header itself.

> > > > > <end quote>

> > > > >

> > > > > My 2c,

> > > > > Sasha

> > > > > ________________________= ________________

> > > > > From: mpls <mpls-bounces@ietf.org> on behalf of Xuxiaohu

> > > > > <xu= xiaohu@huawei.com>

> > > > > Sent: Monday, January 26= , 2015 5:05 AM

> > > > > To: h= uubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org

> > > > > Subject: Re: [mpls] How = to indicate the presence of NSH in an

> > > > > MPLS

> > > packet?

> > > > >

> > > > > Hi Huub,

> > > > >

> > > > > The alter label itself c= ouldn=A1=AFt make the receiving LSR to

> > > > > determine the MPLS

> > > > payload type by examining the= MPLS payload.

> > > > >

> > > > > Best regards,

> > > > > Xiaohu

> > > > >

> > > > >> -----Original Messag= e-----

> > > > >> From: Huub van Helvo= ort [mailto:huubatwork@gmail.com]

> > > > >> Sent: Friday, Januar= y 23, 2015 6:28 PM

> > > > >> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org

> > > > >> Subject: Re: [mpls] = How to indicate the presence of NSH in an

> > > > >> MPLS

> > > packet?

> > > > >>

> > > > >> Xuxiaohu =C4=FA=BA=C3=A3=A1

> > > > >>

> > > > >> Please correct me if= I am wrong:

> > > > >>

> > > > >> It has always been m= y understanding that the MPLS header/label

> > > > >> was independent of t= he protocol/payload.

> > > > >> So no indication of = the actual payload content was necessary.

> > > > >>

> > > > >> IMHO you could use t= he alert label 1 to indicate to the LSR

> > > > >> that it has to furth= er examine the content of a packet.

> > > > >>

> > > > >> Regards, Huub.

> > > > >>

> > > > >> =3D=3D=3D=3D=3D=3D= =3D=3D

> > > > >>

> > > > >>> It said in (https://tools.ietf.org/html/draft-qui= nn-sfc-nsh-04):

> > > > >>>

> > > > >>>   = ;   The service header is independent of the encapsulation

> > > > >>> used and

> > is

> > > > >>>   = ;   encapsulated in existing transports.  The presence of NS= H is

> > > > >>>   = ;   indicated via protocol type or other indicator in the outer

> > > > >>>   = ;   encapsulation.

> > > > >>>

> > > > >>> In the case wher= e the outer encapsulation is an MPLS LSP, how

> > > > >>> to indicate the<= /p>

> > > > >> presence of NSH sinc= e the MPLS encapsulation has no explicit

> > > > >> protocol identifier = field to indicate the protocol type of the

> > > > >> MPLS

> > > payload?

> > > > >> Should we make each = SFF to allocate a unique label for

> > > > >> indicating the prese= nce of NSH? Or should we use the control

> > > > >> word to indicate it?= Or should we reconsider the possibility of

> > > > >> adding an explicit p= rotocol identifier field to the MPLS

> > > > >> encapsulation so as = to solve such kind of issues

> > > > once and for all?

> > > > >>>

> > > > >>> Best regards,

> > > > >>> Xiaohu

> > > > >>>

> > > > >>

> > > > >>

> > > > >> --

> > > > >>

> > > >

> > >

> ********************************************= **************

> > > ***

> > > > >> ****

> > > > >>   &nb= sp;            = =C7=EB=BC=C7=D7=A1=A3=AC=C4=E3=CA=C7=B6=C0=D2=BB=CE=DE=B6=FE=B5=C4=A3=AC=BE= =CD=CF=F1=C6=E4=CB=FB=C3=BF=D2=BB=B8=F6=C8=CB=D2=BB=D1=F9

> > > > > ________________________= _______________________

> > > > > mpls mailing list

> > > > > mpls@ietf.or= g

> > > > > https://www.ietf.org/= mailman/listinfo/mpls

> > > > > ________________________= _______________________

> > > > > sfc mailing list

> > > > > sfc@ietf.org<= /span>

> > > > > https://www.ietf.org/= mailman/listinfo/sfc

> > > > >

> > > >

> > > > --

> > > >

> > > >

> > > > Loa Andersson  &nbs= p;            &= nbsp;        email: loa@mail01.huawei.com=

> > > > Senior MPLS Expert  = ;            &n= bsp;           loa@pi.nu<= /p>

> > > > Huawei Technologies (consulta= nt)     phone: +46 739 81 21 64

--_000_DB3PR03MB0812936A8223F4750DAEA9849D320DB3PR03MB0812eurp_-- From nobody Tue Jan 27 07:37:59 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B981A883E; Tue, 27 Jan 2015 07:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9ajzPKOcj3P; Tue, 27 Jan 2015 07:37:44 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA171A883C; Tue, 27 Jan 2015 07:37:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D4C7A1C077E; Tue, 27 Jan 2015 07:37:43 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6AE8E1C0673; Tue, 27 Jan 2015 07:37:42 -0800 (PST) Message-ID: <54C7B084.3090709@joelhalpern.com> Date: Tue, 27 Jan 2015 10:36:36 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Xuxiaohu , Alexander Vainshtein , "huubatwork@gmail.com" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 15:37:47 -0000 I am a bit concerned by the tone of this which assumes that there is only one way to use MPLS as a transport for NSH. There are several different MPLS-based transport architectures that will work. As far as I can tell, most of them will even interoperate with each other. But they do imply different things about how NSH is indicated. As far as I can tell, all of the transport mechanisms operate on the assumption that forwarding devices between SFF will not see or need to be aware of the NSH header. Thus, those will always interoperate. In the MPLS case, whether one terminates the MPLS LSP at the first SFF, or allows to to cross several SFF affects how identification is done. Also, if segment routing is used then there are other options such as the use of dedicated local service labels for NSH delivery. (Doing that with conventional MPLS is more complex, but likely can also be done.) Yours, Joel On 1/27/15 1:45 AM, Xuxiaohu wrote: > Hi Sasha, > >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Monday, January 26, 2015 2:22 PM >> To: Xuxiaohu; huubatwork@gmail.com >> Cc: sfc@ietf.org; mpls@ietf.org >> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> Xiaohu, Huub, >> I do not follow the SFC work closely, so I would like to understand whether the >> NSH should be captured by transit LSRs on the LSP - or just by the LER acting as >> the LSP tail-end? >> >> If the latter is correct, the simplest way to indicate presence of the NSH in the >> MPLS payload would be by allocating an "application label" indicating its >> presence by the tail-end LER and by inserting it at the bottom of the label stack >> by the head-end LER - similar to what is done for L2/L3VPN. Within this > > If I understand it correct, the above approach is the same as option 1 as I mentioned in the earlier email (i.e., making each SFF to allocate a unique label for indicating the > presence of NSH). > >> approach, if label-based demultiplexing of packets with NSH in the MPLS >> payload is not required, you could request allocation of a new special purpose >> label from the extended special purposes label space as per RFC 7274, and to >> insert such a label (preceded by the Extension Label ) at the BoS. > > What's the purpose of inserting a particular ESP label at the BoS? > > Best regards, > Xiaohu > >> If the former is correct, the process above still has to be used but it has to be >> augmented by adding the Router Alert Label at the top of the label stack. >> >> From my POV these suggestions are in line with the provisions of Section 2.2 of >> RFC 3032 "Determining the Network Layer Protocol" that states: >> >> >> When the last label is popped from a packet's label stack (resulting >> in the stack being emptied), further processing of the packet is >> based on the packet's network layer header. The LSR which pops the >> last label off the stack must therefore be able to identify the >> packet's network layer protocol. However, the label stack does not >> contain any field which explicitly identifies the network layer >> protocol. This means that the identity of the network layer protocol >> must be inferable from the value of the label which is popped from >> the bottom of the stack, possibly along with the contents of the >> network layer header itself. >> >> >> My 2c, >> Sasha >> ________________________________________ >> From: mpls on behalf of Xuxiaohu >> >> Sent: Monday, January 26, 2015 5:05 AM >> To: huubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org >> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> Hi Huub, >> >> The alter label itself couldn¡¯t make the receiving LSR to determine the MPLS >> payload type by examining the MPLS payload. >> >> Best regards, >> Xiaohu >> >>> -----Original Message----- >>> From: Huub van Helvoort [mailto:huubatwork@gmail.com] >>> Sent: Friday, January 23, 2015 6:28 PM >>> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org >>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >>> >>> Xuxiaohu ÄúºÃ£¡ >>> >>> Please correct me if I am wrong: >>> >>> It has always been my understanding that the MPLS header/label was >>> independent of the protocol/payload. >>> So no indication of the actual payload content was necessary. >>> >>> IMHO you could use the alert label 1 to indicate to the LSR that it >>> has to further examine the content of a packet. >>> >>> Regards, Huub. >>> >>> ======== >>> >>>> It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): >>>> >>>> The service header is independent of the encapsulation used and is >>>> encapsulated in existing transports. The presence of NSH is >>>> indicated via protocol type or other indicator in the outer >>>> encapsulation. >>>> >>>> In the case where the outer encapsulation is an MPLS LSP, how to >>>> indicate the >>> presence of NSH since the MPLS encapsulation has no explicit protocol >>> identifier field to indicate the protocol type of the MPLS payload? >>> Should we make each SFF to allocate a unique label for indicating the >>> presence of NSH? Or should we use the control word to indicate it? Or >>> should we reconsider the possibility of adding an explicit protocol >>> identifier field to the MPLS encapsulation so as to solve such kind of issues >> once and for all? >>>> >>>> Best regards, >>>> Xiaohu >>>> >>> >>> >>> -- >>> >> ************************************************************* >>> **** >>> Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Tue Jan 27 09:56:03 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBEF1A88F1; Tue, 27 Jan 2015 09:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.507 X-Spam-Level: X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybDQKHtCu-dJ; Tue, 27 Jan 2015 09:55:44 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A614D1A1B38; Tue, 27 Jan 2015 09:55:37 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-c5-54c77e3ca922 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6F.D6.03307.C3E77C45; Tue, 27 Jan 2015 13:02:05 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 12:55:36 -0500 From: David Allan I To: "mpls@ietf.org" , "sfc@ietf.org" Thread-Topic: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AQHQOfpp3GPXWcXE5UuPlLNIHMj25JzT6nIAgAAQoACAAAOvgIAAIiuAgAAbVeA= Date: Tue, 27 Jan 2015 17:55:35 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <54C72FE0.40502@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830207F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083020E2@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C39376271eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPuK5t3fEQg77FXBa3lq5ktXjyYCu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyXq1uZyu4NYu54vfWZtYGxo3fmboYOTkkBEwkVi5Z zQJhi0lcuLeerYuRi0NI4AijxInuJcwQznJGid7OHWAdbAIGEnv+f2EEsUUEnCT+/7jNCmIL CwRJvOlqZoGIB0scefYUyvaTuHv9PFg9i4CqxIHmPcwgNq+Ar8T3W/PAbCGBXSwSDe1g9ZwC sRKrvt9mA7EZgS76fmoN2F5mAXGJW0/mQ10tILFkz3lmCFtU4uXjf6wQtqLEvv7p7BD1+RL/ dvxlhdglKHFy5hOWCYwis5CMmoWkbBaSMoi4lsS8ht9QNYoSU7ofskPYmhJXJh+CsrUlli18 zbyAkX0VI0dpcWpZbrqRwSZGYOQck2DT3cG456XlIUYBDkYlHt4NfcdChFgTy4orcw8xSnOw KInzLnpwMERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY+mF2S3KhUvKf+ndUJ99ee2i+UEW /s9u7Yg99JDz+0ex2M1tItvOTd7xiPNBgN6LGZ+2vb856VCFuMeiVxP71lzf3XXv0uaEzKn8 6/8pXd2ftcCqa9JsRR0pqa+f87gUXDLqM6OiP39Q+/PJo/1f86/mO+x8rAlFnP1lEpeUOp8/ NdDJfC3eEKTEUpyRaKjFXFScCACE6CB9fQIAAA== Archived-At: Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 17:55:57 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C39376271eusaamb105erics_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgZm9sa3M6DQoNCkNvcnJlY3QgbWUgaWYgSaGvbSB3cm9uZywgYnV0IGlzbqGvdCBhbnkgbGFi ZWwgc3RhY2sgZGlyZWN0bHkgcHJlcGVuZGluZyBhbiBOU0ggdGhhdCBpcyBjb21wb3NlZCBlbnRp cmVseSBvZiBub24tcmVzZXJ2ZWQgbGFiZWxzIGdvaW5nIHRvIG1lYW4gYW4gU0ZDIGhlYWRlciAo YXQgbGVhc3QgZm9yIG5vbiBPQU0sIG5vbiBjcml0aWNhbCBtZXRhZGF0YSwgdmVyc2lvbiAxIHBh Y2tldHMpIHdpbGwgYWxpYXMgYXMgYW4gSVB2NCBwYWNrZXQgZm9yIHByZXR0eSBtdWNoIGFsbCB0 cmFuc2l0IExTUnM/IEFuZCB2ZXJzaW9uIDEgT0FNIHBhY2tldHMgd2lsbCBhbGlhcyBhcyBJUHY2 IGJsb3dpbmcgb3V0IGZhdGUgc2hhcmluZz8gSW4gZWl0aGVyIGNhc2UsIG9idGFpbmluZyBlbnRy b3B5IGZvciBFQ01QIGJ5IHRyYW5zaXQgTFNScyB3aWxsIGJlIG92ZXJsYWlkIG9uIHRoZSBiYXNl IGFuZCBzZXJ2aWNlIHBhdGggaGVhZGVycyAoYW5kIGJleW9uZCBmb3IgSVB2NiBhbGlhc2luZymh rS4NCg0KUmVnYXJkcw0KRGF2ZQ0KDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZGVyIFZhaW5zaHRlaW4NClNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMjcsIDIwMTUgMzowMSBBTQ0KVG86IFh1eGlhb2h1DQpDYzogbXBsc0BpZXRmLm9y Zzsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIFtzZmNdIEhvdyB0byBpbmRpY2F0 ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0Pw0KDQoNClhpYW9odSwNCg0K SSB3b3VsZCBsaWtlIHRvIGNsYXJpZnkgbXkgcG9zaXRpb24uDQoNCjEuICAgICAgIEFwcGxpY2F0 aW9uIGxldmVsIGFuZCBhIGRlZGljYXRlZCBFU1AgYXJlIHR3byBhbHRlcm5hdGl2ZSBvcHRpb25z IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gdGhlIHBheWxvYWQgb2YgYSBsYWJl bGVkIHBhY2tldC4NCg0KYS4gICAgICAgQSBkZWRpY2F0ZWQgRVNQIGNvdWxkIGJlIHVzZWQgaWYg YXNzb2NpYXRpb24gb2YgdGhlIHJlY2VpdmVkIHBhY2tldCB3aXRoIGEgc3BlY2lmaWMgU0YgaW5z dGFuY2Ugd2l0aGluIHRoZSBwcm9jZXNzaW5nIE5FIGNhbiBiZSBwZXJmb3JtZWQgYmFzZWQgZXhj bHVzaXZlbHkgb24gTlNILiBKdXN0IG9uZSBFU1AgbGFiZWwgd291bGQgYmUgdXNlZCAob2NjdXB5 aW5nIDIgZW50cmllcyBpbiB0aGUgbGFiZWwgc3RhY2spLCBhbmQgaXQgd291bGQganVzdCBiZSB0 cmVhdGVkIGFzIHRoZSBOU0ggcHJlc2VuY2UgaW5kaWNhdG9yLiBUaGlzIHNpdHVhdGlvbiBpcyBz aW1pbGFyIHRvIHVzaW5nIHRoZSBHZW5lcmljIEFzc29jaWF0ZWQgQ2hhbm5lbCBMYWJlbCAoR0FM KSBpbiBNUExTLVRQLg0KDQpiLiAgICAgIEFuIGFwcGxpY2F0aW9uIGxhYmVsIHBlciBTRiBpbnN0 YW5jZSBzaG91bGQgYmUgdXNlZCBpZiB0aGUgTlNIIGhlYWRlciBpcyBub3Qgc3VmZmljaWVudCBm b3IgZGVmaW5pbmcgdGhlIFNGIGluc3RhbmNlIHRoYXQgd291bGQgaGFuZGxlIHRoZSBwYWNrZXQu IEEgZGVkaWNhdGVkIGFwcGxpY2F0aW9uIGxhYmVsIHdvdWxkIGJlIGFsbG9jYXRlZCBhdCBsZWFz dCBwZXIgU0YgaW5zdGFuY2Ugd2l0aGluIHRoZSBORSwgYW5kIHNvbWUgc3VpdGFibGUgcHJvdG9j b2wgd291bGQgYmUgdXNlZCBmb3IgZGlzdHJpYnV0aW5nIGFzc29jaWF0aW9uIGJldHdlZW4gdGhp cyBsYWJlbCBhbmQgaXRzIHNwZWNpZmljIFNGIGluc3RhbmNlLiBUaGlzIGlzIHNpbWlsYXIgdG8g dXNpbmcgUFcgbGFiZWxzIGluIFBXcyBhbmQvb3IgQXBwbGljYXRpb24gbGFiZWxzIChkaXN0cmli dXRlZCB3aXRoIHRoZWlyIGFzc29jaWF0ZWQgbGFiZWxlZCBJUC1WUE4gcm91dGVzKSBpbiBMM1ZQ Tg0KDQpjLiAgICAgICBNeSBrbm93bGVkZ2Ugb2YgU0ZDIGlzIGFsbCBidXQgb24tZXhpc3RlbnQs IHNvIEkgY2Fubm90IHNheSB3aGljaCBvZiB0aGVzZSB0d28gYWx0ZXJuYXRpdmVzIGlzIHJlbGV2 YW50Lg0KDQoyLiAgICAgICBJbiBib3RoIGNhc2VzIHRoZSBsYWJlbCAoYmUgaXQgYW4gYXBwbGlj YXRpb24gbGFiZWwgb3IgYSBkZWRpY2F0ZWQgRVNQKSBtdXN0IGJlIGluc2VydGVkIGJ5IHRoZSBo ZWFkLWVuZCBhdCB0aGUgQm9TIHNvIHRoYXQgaXQgd291bGQgYmUgcHJvY2Vzc2VkIGJ5IHRoZSB0 YWlsLWVuZCBub2RlIG9mIHRoZSBMU1Agd2l0aG91dCBhZmZlY3RpbmcgYW55IHRyYW5zaXQgbm9k ZXMgKHdoaWNoIHdvdWxkIGp1c3QgcGVyZm9ybSBzdGFuZGFyZCBNUExTIGZvcndhcmRpbmcpLg0K DQozLiAgICAgICBJbiB0aGUgY2FzZSBvZiBTRiBwYXRoczoNCg0KYS4gICAgICAgSWYgdGhlIGRl ZGljYXRlZCBFU1AgaXMgdXNlZCwgaGFuZGxpbmcgb2YgdGhlIHBhY2tldCBieSB0aGUgY3VycmVu dCBTRiBtdXN0IGluY2x1ZGUgZGVmaW5pdGlvbiBvZiB0aGUgbmV4dCBTRiBub2RlIGFuZCBmb3J3 YXJkaW5nIHRvIHRoaXMgbm9kZS4gVGhlIGZvcndhcmRlZCBwYWNrZXQgd291bGQgYWdhaW4gaW5j bHVkZSB0aGUgZGVkaWNhdGVkIEVTUCBhdCB0aGUgQm9TLCB3aXRoIHRoZSChsHR1bm5lbCBMU1Ch sSBsYWJlbCBzdGFjayBvbiB0b3Agb2YgdGhhdA0KDQpiLiAgICAgIElmIHRoZSBhcHBsaWNhdGlv biBsYWJlbCBpcyB1c2VkLCB0aGUgbmV4dCBTRiBub2RlIGFuZCB0aGUgU0YgaW5zdGFuY2Ugd2l0 aGluIHRoaXMgbm9kZSBjb3VsZCBiZSBpbmZlcnJlZCBlaXRoZXIgZnJvbSB0aGUgcGF5bG9hZCBv ciBmcm9tIHRoZSBhcHBsaWNhdGlvbiBsYWJlbCwgb3IgZnJvbSB0aGVpciBjb21iaW5hdGlvbi4g SW4gYW55IGNhc2UgZm9yd2FyZGluZyBvZiB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGIHdvdWxk IHJlc3VsdCBpbiBzd2FwcGluZyBvZiB0aGUgYXBwbGljYXRpb24gbGFiZWwgYXQgdGhlIEJvUyAo c2ltaWxhciB0byB3aGF0IGlzIGRvbmUgaW4gTVMtUFdzKSBhbmQgcHVzaGluZyB0aGUgobB0dW5u ZWwgTFNQobEgbGFiZWwgc3RhY2sgb24gdG9wIG9mIHRoYXQuDQoNCg0KDQpOb3Qgc3VyZSBpZiB0 aGlzIGhlbHBzLCBvciBqdXN0IGFkZHMgbW9yZSBub2lzZTopLg0KDQoNCg0KUmVnYXJkcywNCg0K ICAgICAgIFNhc2hhDQoNCkVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQoNCk1vYmlsZTogMDU0LTky NjYzMDINCg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTog WHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KDQo+IFNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMjcsIDIwMTUgMTA6NTkgQU0NCg0KPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4N Cg0KPiBDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPjsgTG9hIEFuZGVyc3Nvbg0KDQo+IFN1YmplY3Q6IFJFOiBb c2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBM Uw0KDQo+IHBhY2tldD8NCg0KPg0KDQo+IEhpIFNhc2hhLA0KDQo+DQoNCj4gSWYgb25seSBvbmUg YXBwbGljYXRpb24gbGFiZWwgaXMgcmVxdWlyZWQgdG8gYmUgaW5zZXJ0ZWQgaW50byB0aGUgbGFi ZWwgc3RhY2ssDQoNCj4gd2hlcmUgc2hvdWxkIGl0IGJlIGluc2VydGVkPyBhdCB0aGUgQm9TPyBJ ZiBzbywgaXQgc2VlbXMgdGhhdCB0aGUgYXBwbGljYXRpb24NCg0KPiBsYWJlbCBtdXN0IGJlIGFu IEVTUCBsYWJlbC4NCg0KPg0KDQo+IEJlc3QgcmVnYXJkcywNCg0KPiBYaWFvaHUNCg0KPg0KDQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+IEZyb206IEFsZXhhbmRlciBWYWlu c2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQoNCj4gPiBT ZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDQ6NDYgUE0NCg0KPiA+IFRvOiBYdXhpYW9o dQ0KDQo+ID4gQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47IExvYSBBbmRlcnNzb24NCg0KPiA+IFN1YmplY3Q6 IFJFOiBbc2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4gTVBMUw0KDQo+IHBhY2tldD8NCg0KPiA+DQoNCj4gPiBYaWFvaCBoaSENCg0KPiA+IEkgZG8g bm90IHRoaW5rIHlvdSBuZWVkIG11bHRpcGxlIGFwcGxpY2F0aW9uIGxhYmVscy4NCg0KPiA+IFJh dGhlciwgeW91IGNvdWxkIHN3YXAgdGhlc2UgbGFiZWxzIGFzIHRoZSBwYWNrZXQgcHJvZ3Jlc3Nl cyBhbG9uZyB0aGUNCg0KPiA+IFNGUCwgc2FtZSBhcyBpcyBkb25lIHdpdGggTVMtUFdzLg0KDQo+ ID4NCg0KPiA+IFJlZ2FyZHMsDQoNCj4gPiAgICAgICAgU2FzaGENCg0KPiA+IEVtYWlsOiBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+DQoNCj4gPiBNb2JpbGU6IDA1NC05MjY2MzAyDQoNCj4gPg0KDQo+ID4NCg0K PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+ID4gRnJvbTogWHV4aWFvaHUg W21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDI3LCAyMDE1IDk6NDYgQU0NCg0KPiA+ID4gVG86IExvYSBBbmRlcnNzb247IEFsZXhhbmRl ciBWYWluc2h0ZWluDQoNCj4gPiA+IENjOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQoNCj4gPiA+IFN1YmplY3Q6 IFJFOiBbc2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4g YW4NCg0KPiA+ID4gTVBMUyBwYWNrZXQ/DQoNCj4gPiA+DQoNCj4gPiA+DQoNCj4gPiA+DQoNCj4g PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+ID4gPiBGcm9tOiBMb2EgQW5k ZXJzc29uIFttYWlsdG86bG9hQHBpLm51XQ0KDQo+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIEphbnVh cnkgMjcsIDIwMTUgMjoyOCBQTQ0KDQo+ID4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsg WHV4aWFvaHUNCg0KPiA+ID4gPiBDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9y Zz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KDQo+ID4gPiA+IFN1YmplY3Q6 IFJlOiBbc2ZjXSBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4N Cg0KPiA+ID4gPiBhbiBNUExTDQoNCj4gPiA+IHBhY2tldD8NCg0KPiA+ID4gPg0KDQo+ID4gPiA+ IFNhc2hhLA0KDQo+ID4gPiA+DQoNCj4gPiA+ID4NCg0KPiA+ID4gPg0KDQo+ID4gPiA+IE9uIDIw MTUtMDEtMjYgMTQ6MjEsIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOg0KDQo+ID4gPiA+ID4g WGlhb2h1LCBIdXViLA0KDQo+ID4gPiA+ID4gSSBkbyBub3QgZm9sbG93IHRoZSBTRkMgd29yayBj bG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8NCg0KPiA+ID4gPiA+IHVuZGVyc3RhbmQgd2hldGhl ciB0aGUNCg0KPiA+ID4gPiBOU0ggc2hvdWxkIGJlIGNhcHR1cmVkIGJ5ICB0cmFuc2l0IExTUnMg b24gdGhlIExTUCAtIG9yIGp1c3QgYnkNCg0KPiA+ID4gPiB0aGUgTEVSIGFjdGluZyBhcyB0aGUg TFNQIHRhaWwtZW5kPw0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+IElmIHRoZSBsYXR0ZXIgaXMg Y29ycmVjdCwgdGhlIHNpbXBsZXN0IHdheSB0byBpbmRpY2F0ZSBwcmVzZW5jZQ0KDQo+ID4gPiA+ ID4gb2YgdGhlIE5TSCBpbiB0aGUNCg0KPiA+ID4gPiBNUExTIHBheWxvYWQgd291bGQgYmUgYnkg YWxsb2NhdGluZyBhbiAiYXBwbGljYXRpb24gbGFiZWwiDQoNCj4gPiA+ID4gaW5kaWNhdGluZyBp dHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0aW5nIGl0IGF0DQoN Cj4gPiA+ID4gdGhlIGJvdHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sgYnkgdGhlIGhlYWQtZW5kIExF UiAtIHNpbWlsYXIgdG8NCg0KPiA+ID4gPiB3aGF0IGlzIGRvbmUgZm9yIEwyL0wzVlBOLiAgV2l0 aGluIHRoaXMgYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkDQoNCj4gPiA+ID4gZGVtdWx0aXBsZXhp bmcgb2YgcGFja2V0cyB3aXRoIE5TSCBpbiB0aGUgTVBMUyBwYXlsb2FkIGlzIG5vdA0KDQo+ID4g PiA+IHJlcXVpcmVkLCB5b3UgY291bGQgcmVxdWVzdCBhbGxvY2F0aW9uIG9mIGEgbmV3IHNwZWNp YWwgcHVycG9zZQ0KDQo+ID4gPiA+IGxhYmVsIGZyb20gdGhlIGV4dGVuZGVkIHNwZWNpYWwgcHVy cG9zZXMgbGFiZWwgc3BhY2UgYXMgcGVyIFJGQw0KDQo+ID4gPiA+IDcyNzQsIGFuZCB0byBpbnNl cnQgc3VjaCBhIGxhYmVsDQoNCj4gPiA+IChwcmVjZWRlZCBieSB0aGUgRXh0ZW5zaW9uIExhYmVs ICkgYXQgdGhlIEJvUy4NCg0KPiA+ID4gPiA+DQoNCj4gPiA+ID4gSSB0aGluayAidGhlIGxhdHRl ciIgaXMgY29ycmVjdCwgdGhlIG9ubHkgaXNzdWUgSSBzZWUgaXMgYWRkaW5nDQoNCj4gPiA+ID4g b25lIG1vcmUgbGFiZWwgc3RhY2sgZW50cnkgdG8gdGhlIGxhYmVsIHN0YWNrLg0KDQo+ID4gPg0K DQo+ID4gPiBZZXMsIHRoZSBsYXR0ZXIgaXMgY29ycmVjdC4gVGhlIGlzc3VlIG9mIGFkZGluZyBv bmUgbW9yZSBsYWJlbCBzdGFjaw0KDQo+ID4gPiBlbnRyeSB0byB0aGUgbGFiZWwgc3RhY2sgbWF5 IGJlY29tZSB1bmFjY2VwdGFibGUgaW4gdGhlIGNhc2Ugd2hlcmUNCg0KPiA+ID4gdGhlIFNlcnZp Y2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBpcyByZXByZXNlbnRlZCBieSBhbiBsYWJlbCBzdGFjaw0K DQo+ID4gPiB3aGlsZSB0aGUgTlNIIGlzIG5vdyBvbmx5IHVzZWQgYXMgYSBtZXRhZGF0YSBjb250 YWluZXIuIEZvciBleGFtcGxlLA0KDQo+ID4gPiBmb3IgYW4gU0ZQIGNvbnNpc3Qgb2YgbiBTRnMs IG4gImFwcGxpY2F0aW9uIGxhYmVscyIgd291bGQgaGF2ZSB0byBiZQ0KDQo+IGluc2VydGVkIGlu dG8gdGhlIGxhYmVsIHN0YWNrLg0KDQo+ID4gPg0KDQo+ID4gPiBCZXN0IHJlZ2FyZHMsDQoNCj4g PiA+IFhpYW9odQ0KDQo+ID4gPg0KDQo+ID4gPiA+IC9Mb2ENCg0KPiA+ID4gPiA+IElmIHRoZSBm b3JtZXIgaXMgY29ycmVjdCwgdGhlIHByb2Nlc3MgYWJvdmUgc3RpbGwgaGFzIHRvIGJlIHVzZWQN Cg0KPiA+ID4gPiA+IGJ1dCBpdCBoYXMgdG8gYmUNCg0KPiA+ID4gPiBhdWdtZW50ZWQgYnkgYWRk aW5nIHRoZSBSb3V0ZXIgQWxlcnQgTGFiZWwgICBhdCB0aGUgdG9wIG9mIHRoZSBsYWJlbA0KDQo+ IHN0YWNrLg0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+ICBGcm9tIG15IFBPViB0aGVzZSBzdWdn ZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRoZSBwcm92aXNpb25zDQoNCj4gPiA+ID4gPiBvZiBT ZWN0aW9uIDIuMg0KDQo+ID4gPiA+IG9mIFJGQyAzMDMyICJEZXRlcm1pbmluZyB0aGUgTmV0d29y ayBMYXllciBQcm90b2NvbCIgdGhhdCBzdGF0ZXM6DQoNCj4gPiA+ID4gPg0KDQo+ID4gPiA+ID4g PHF1b3RlPg0KDQo+ID4gPiA+ID4gICAgIFdoZW4gdGhlIGxhc3QgbGFiZWwgaXMgcG9wcGVkIGZy b20gYSBwYWNrZXQncyBsYWJlbCBzdGFjayAocmVzdWx0aW5nDQoNCj4gPiA+ID4gPiAgICAgaW4g dGhlIHN0YWNrIGJlaW5nIGVtcHRpZWQpLCBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBhY2tl dCBpcw0KDQo+ID4gPiA+ID4gICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3JrIGxheWVy IGhlYWRlci4gIFRoZSBMU1Igd2hpY2gNCg0KPiA+ID4gPiA+IHBvcHMNCg0KPiA+IHRoZQ0KDQo+ ID4gPiA+ID4gICAgIGxhc3QgbGFiZWwgb2ZmIHRoZSBzdGFjayBtdXN0IHRoZXJlZm9yZSBiZSBh YmxlIHRvIGlkZW50aWZ5IHRoZQ0KDQo+ID4gPiA+ID4gICAgIHBhY2tldCdzIG5ldHdvcmsgbGF5 ZXIgcHJvdG9jb2wuICBIb3dldmVyLCB0aGUgbGFiZWwgc3RhY2sgZG9lcyBub3QNCg0KPiA+ID4g PiA+ICAgICBjb250YWluIGFueSBmaWVsZCB3aGljaCBleHBsaWNpdGx5IGlkZW50aWZpZXMgdGhl IG5ldHdvcmsgbGF5ZXINCg0KPiA+ID4gPiA+ICAgICBwcm90b2NvbC4gIFRoaXMgbWVhbnMgdGhh dCB0aGUgaWRlbnRpdHkgb2YgdGhlIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wNCg0KPiA+ID4gPiA+ ICAgICBtdXN0IGJlIGluZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUgbGFiZWwgd2hpY2gg aXMgcG9wcGVkIGZyb20NCg0KPiA+ID4gPiA+ICAgICB0aGUgYm90dG9tIG9mIHRoZSBzdGFjaywg cG9zc2libHkgYWxvbmcgd2l0aCB0aGUgY29udGVudHMgb2YgdGhlDQoNCj4gPiA+ID4gPiAgICAg bmV0d29yayBsYXllciBoZWFkZXIgaXRzZWxmLg0KDQo+ID4gPiA+ID4gPGVuZCBxdW90ZT4NCg0K PiA+ID4gPiA+DQoNCj4gPiA+ID4gPiBNeSAyYywNCg0KPiA+ID4gPiA+IFNhc2hhDQoNCj4gPiA+ ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gPiA+ID4g PiBGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBYdXhpYW9odQ0KDQo+ID4gPiA+ID4gPHh1eGlhb2h1QGh1 YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+Pg0KDQo+ID4gPiA+ID4gU2VudDog TW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDU6MDUgQU0NCg0KPiA+ID4gPiA+IFRvOiBodXViYXR3 b3JrQGdtYWlsLmNvbTxtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20+OyBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+ DQoNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUgcHJl c2VuY2Ugb2YgTlNIIGluIGFuDQoNCj4gPiA+ID4gPiBNUExTDQoNCj4gPiA+IHBhY2tldD8NCg0K PiA+ID4gPiA+DQoNCj4gPiA+ID4gPiBIaSBIdXViLA0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+ IFRoZSBhbHRlciBsYWJlbCBpdHNlbGYgY291bGRuoa90IG1ha2UgdGhlIHJlY2VpdmluZyBMU1Ig dG8NCg0KPiA+ID4gPiA+IGRldGVybWluZSB0aGUgTVBMUw0KDQo+ID4gPiA+IHBheWxvYWQgdHlw ZSBieSBleGFtaW5pbmcgdGhlIE1QTFMgcGF5bG9hZC4NCg0KPiA+ID4gPiA+DQoNCj4gPiA+ID4g PiBCZXN0IHJlZ2FyZHMsDQoNCj4gPiA+ID4gPiBYaWFvaHUNCg0KPiA+ID4gPiA+DQoNCj4gPiA+ ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+ID4gPiA+PiBGcm9tOiBIdXVi IHZhbiBIZWx2b29ydCBbbWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tXQ0KDQo+ID4gPiA+ID4+ IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAyMywgMjAxNSA2OjI4IFBNDQoNCj4gPiA+ID4gPj4gVG86 IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47IG1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQoNCj4gPiA+ID4gPj4gU3ViamVjdDogUmU6IFttcGxz XSBIb3cgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbg0KDQo+ID4gPiA+ID4+ IE1QTFMNCg0KPiA+ID4gcGFja2V0Pw0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4gWHV4aWFv aHUgxPq6w6OhDQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+PiBQbGVhc2UgY29ycmVjdCBtZSBp ZiBJIGFtIHdyb25nOg0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4gSXQgaGFzIGFsd2F5cyBi ZWVuIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgTVBMUyBoZWFkZXIvbGFiZWwNCg0KPiA+ID4g PiA+PiB3YXMgaW5kZXBlbmRlbnQgb2YgdGhlIHByb3RvY29sL3BheWxvYWQuDQoNCj4gPiA+ID4g Pj4gU28gbm8gaW5kaWNhdGlvbiBvZiB0aGUgYWN0dWFsIHBheWxvYWQgY29udGVudCB3YXMgbmVj ZXNzYXJ5Lg0KDQo+ID4gPiA+ID4+DQoNCj4gPiA+ID4gPj4gSU1ITyB5b3UgY291bGQgdXNlIHRo ZSBhbGVydCBsYWJlbCAxIHRvIGluZGljYXRlIHRvIHRoZSBMU1INCg0KPiA+ID4gPiA+PiB0aGF0 IGl0IGhhcyB0byBmdXJ0aGVyIGV4YW1pbmUgdGhlIGNvbnRlbnQgb2YgYSBwYWNrZXQuDQoNCj4g PiA+ID4gPj4NCg0KPiA+ID4gPiA+PiBSZWdhcmRzLCBIdXViLg0KDQo+ID4gPiA+ID4+DQoNCj4g PiA+ID4gPj4gPT09PT09PT0NCg0KPiA+ID4gPiA+Pg0KDQo+ID4gPiA+ID4+PiBJdCBzYWlkIGlu IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLW5zaC0wNCk6DQoN Cj4gPiA+ID4gPj4+DQoNCj4gPiA+ID4gPj4+ICAgICAgVGhlIHNlcnZpY2UgaGVhZGVyIGlzIGlu ZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uDQoNCj4gPiA+ID4gPj4+IHVzZWQgYW5kDQoN Cj4gPiBpcw0KDQo+ID4gPiA+ID4+PiAgICAgIGVuY2Fwc3VsYXRlZCBpbiBleGlzdGluZyB0cmFu c3BvcnRzLiAgVGhlIHByZXNlbmNlIG9mIE5TSCBpcw0KDQo+ID4gPiA+ID4+PiAgICAgIGluZGlj YXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRpY2F0b3IgaW4gdGhlIG91dGVyDQoN Cj4gPiA+ID4gPj4+ICAgICAgZW5jYXBzdWxhdGlvbi4NCg0KPiA+ID4gPiA+Pj4NCg0KPiA+ID4g PiA+Pj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBM UyBMU1AsIGhvdw0KDQo+ID4gPiA+ID4+PiB0byBpbmRpY2F0ZSB0aGUNCg0KPiA+ID4gPiA+PiBw cmVzZW5jZSBvZiBOU0ggc2luY2UgdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBoYXMgbm8gZXhwbGlj aXQNCg0KPiA+ID4gPiA+PiBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRvIGluZGljYXRlIHRo ZSBwcm90b2NvbCB0eXBlIG9mIHRoZQ0KDQo+ID4gPiA+ID4+IE1QTFMNCg0KPiA+ID4gcGF5bG9h ZD8NCg0KPiA+ID4gPiA+PiBTaG91bGQgd2UgbWFrZSBlYWNoIFNGRiB0byBhbGxvY2F0ZSBhIHVu aXF1ZSBsYWJlbCBmb3INCg0KPiA+ID4gPiA+PiBpbmRpY2F0aW5nIHRoZSBwcmVzZW5jZSBvZiBO U0g/IE9yIHNob3VsZCB3ZSB1c2UgdGhlIGNvbnRyb2wNCg0KPiA+ID4gPiA+PiB3b3JkIHRvIGlu ZGljYXRlIGl0PyBPciBzaG91bGQgd2UgcmVjb25zaWRlciB0aGUgcG9zc2liaWxpdHkgb2YNCg0K PiA+ID4gPiA+PiBhZGRpbmcgYW4gZXhwbGljaXQgcHJvdG9jb2wgaWRlbnRpZmllciBmaWVsZCB0 byB0aGUgTVBMUw0KDQo+ID4gPiA+ID4+IGVuY2Fwc3VsYXRpb24gc28gYXMgdG8gc29sdmUgc3Vj aCBraW5kIG9mIGlzc3Vlcw0KDQo+ID4gPiA+IG9uY2UgYW5kIGZvciBhbGw/DQoNCj4gPiA+ID4g Pj4+DQoNCj4gPiA+ID4gPj4+IEJlc3QgcmVnYXJkcywNCg0KPiA+ID4gPiA+Pj4gWGlhb2h1DQoN Cj4gPiA+ID4gPj4+DQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPiA+Pg0KDQo+ID4gPiA+ID4+IC0t DQoNCj4gPiA+ID4gPj4NCg0KPiA+ID4gPg0KDQo+ID4gPg0KDQo+ICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KPiA+ID4gKioqDQoN Cj4gPiA+ID4gPj4gKioqKg0KDQo+ID4gPiA+ID4+ICAgICAgICAgICAgICAgICDH67zH16GjrMTj yse2wNK7zt62/rXEo6y+zc/xxuTL+8O/0ru49sjL0rvR+Q0KDQo+ID4gPiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPiA+ID4gPiA+IG1wbHMg bWFpbGluZyBsaXN0DQoNCj4gPiA+ID4gPiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPg0KDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQoNCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQo+ID4gPiA+ID4gc2ZjIG1haWxpbmcgbGlzdA0KDQo+ID4gPiA+ID4gc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQoNCj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPg0KDQo+ID4g PiA+IC0tDQoNCj4gPiA+ID4NCg0KPiA+ID4gPg0KDQo+ID4gPiA+IExvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzps b2FAbWFpbDAxLmh1YXdlaS5jb20+DQoNCj4gPiA+ID4gU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAg ICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCg0KPiA+ID4g PiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEg MjEgNjQNCg== --_000_E6C17D2345AC7A45B7D054D407AA205C39376271eusaamb105erics_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi folks:

 

Correct me if I=A1=AFm= wrong, but isn=A1=AFt any label stack directly prepending an NSH that is c= omposed entirely of non-reserved labels going to mean an SFC header (at lea= st for non OAM, non critical metadata, version 1 packets) will alias as an IPv4 packet for pretty much all transit LSRs? = And version 1 OAM packets will alias as IPv6 blowing out fate sharing? In e= ither case, obtaining entropy for ECMP by transit LSRs will be overlaid on = the base and service path headers (and beyond for IPv6 aliasing)=A1=AD.

 

Regards

Dave=

 

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, January 27, 2015 3:01 AM
To: Xuxiaohu
Cc: mpls@ietf.org; sfc@ietf.org
Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an = MPLS packet?

 

Xiaohu,

I would like to clarify my position. <= /p>

1.       Application level and a dedicated ESP are two alter= native options to indicate the presence of NSH in the payload of a labeled = packet.

a.       A dedicated ESP could be used if association of the= received packet with a specific SF instance within the processing NE can b= e performed based exclusively on NSH. Just one ESP label would be used (occ= upying 2 entries in the label stack), and it would just be treated as the NSH presence indicator. This situation= is similar to using the Generic Associated Channel Label (GAL) in MPLS-TP.=

b.      An application label per SF instance should be used= if the NSH header is not sufficient for defining the SF instance that woul= d handle the packet. A dedicated application label would be allocated at le= ast per SF instance within the NE, and some suitable protocol would be used for distributing association betw= een this label and its specific SF instance. This is similar to using PW la= bels in PWs and/or Application labels (distributed with their associated la= beled IP-VPN routes) in L3VPN

c.       My knowledge of SFC is all but on-existent, so I ca= nnot say which of these two alternatives is relevant.

2.       In both cases the label (be it an application label= or a dedicated ESP) must be inserted by the head-end at the BoS so that it= would be processed by the tail-end node of the LSP without affecting any t= ransit nodes (which would just perform standard MPLS forwarding).

3.       In the case of SF paths:

a.       If the dedicated ESP is used, handling of the packe= t by the current SF must include definition of the next SF node and forward= ing to this node. The forwarded packet would again include the dedicated ES= P at the BoS, with the =A1=B0tunnel LSP=A1=B1 label stack on top of that

b.      If the application label is used, the next SF node = and the SF instance within this node could be inferred either from the payl= oad or from the application label, or from their combination. In any case f= orwarding of the packet to the next SF would result in swapping of the application label at the BoS (similar t= o what is done in MS-PWs) and pushing the =A1=B0tunnel LSP=A1=B1 label stac= k on top of that.

 

Not sure if this helps, or just adds more noiseJ.

 

Regards,

       Sasha <= /o:p>

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

 

> -----Original Message-----

> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]

> Sent: Tuesday, January 27, 2015 10:59 AM

> To: Alexander Vainshtein

> Cc: mpls@ie= tf.org; sfc@ietf.org; Loa Andersson

> Subject: RE: [sfc] [mpls] How to indicate th= e presence of NSH in an MPLS

> packet?

>

> Hi Sasha,

>

> If only one application label is required to= be inserted into the label stack,

> where should it be inserted? at the BoS? If = so, it seems that the application

> label must be an ESP label.

>

> Best regards,

> Xiaohu

>

> > -----Original Message-----

> > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]

> > Sent: Tuesday, January 27, 2015 4:46 PM=

> > To: Xuxiaohu

> > Cc: mpls@ietf.org; sfc@ietf.org; Loa Andersson

> > Subject: RE: [sfc] [mpls] How to indica= te the presence of NSH in an MPLS

> packet?

> >

> > Xiaoh hi!

> > I do not think you need multiple applic= ation labels.

> > Rather, you could swap these labels as = the packet progresses along the

> > SFP, same as is done with MS-PWs.<= /o:p>

> >

> > Regards,

> >      &nbs= p; Sasha

> > Email: Alexander.Vainshtein@= ecitele.com

> > Mobile: 054-9266302

> >

> >

> > > -----Original Message-----

> > > From: Xuxiaohu [= mailto:xuxiaohu@huawei.com]

> > > Sent: Tuesday, January 27, 2015 9:= 46 AM

> > > To: Loa Andersson; Alexander Vains= htein

> > > Cc: mpls@ietf.org; sfc@ietf.org

> > > Subject: RE: [sfc] [mpls] How to i= ndicate the presence of NSH in an

> > > MPLS packet?

> > >

> > >

> > >

> > > > -----Original Message-----

> > > > From: Loa Andersson [mailto:loa@pi.nu]

> > > > Sent: Tuesday, January 27, 20= 15 2:28 PM

> > > > To: Alexander Vainshtein; Xux= iaohu

> > > > Cc: mpls@ietf.org= ; sfc@ietf.org

> > > > Subject: Re: [sfc] [mpls] How= to indicate the presence of NSH in

> > > > an MPLS

> > > packet?

> > > >

> > > > Sasha,

> > > >

> > > >

> > > >

> > > > On 2015-01-26 14:21, Alexande= r Vainshtein wrote:

> > > > > Xiaohu, Huub,=

> > > > > I do not follow the SFC = work closely, so I would like to

> > > > > understand whether the

> > > > NSH should be captured by&nbs= p; transit LSRs on the LSP - or just by

> > > > the LER acting as the LSP tai= l-end?

> > > > >

> > > > > If the latter is correct= , the simplest way to indicate presence

> > > > > of the NSH in the

> > > > MPLS payload would be by allo= cating an "application label"

> > > > indicating its presence by th= e tail-end LER and by inserting it at

> > > > the bottom of the label stack= by the head-end LER - similar to

> > > > what is done for L2/L3VPN.&nb= sp; Within this approach, if label-based

> > > > demultiplexing of packets wit= h NSH in the MPLS payload is not

> > > > required, you could request a= llocation of a new special purpose

> > > > label from the extended speci= al purposes label space as per RFC

> > > > 7274, and to insert such a la= bel

> > > (preceded by the Extension Label )= at the BoS.

> > > > >

> > > > I think "the latter"= ; is correct, the only issue I see is adding

> > > > one more label stack entry to= the label stack.

> > >

> > > Yes, the latter is correct. The is= sue of adding one more label stack

> > > entry to the label stack may becom= e unacceptable in the case where

> > > the Service Function Path (SFP) is= represented by an label stack

> > > while the NSH is now only used as = a metadata container. For example,

> > > for an SFP consist of n SFs, n &qu= ot;application labels" would have to be

> inserted into the label stack.

> > >

> > > Best regards,

> > > Xiaohu

> > >

> > > > /Loa

> > > > > If the former is correct= , the process above still has to be used

> > > > > but it has to be

> > > > augmented by adding the Route= r Alert Label   at the top of the label

> stack.

> > > > >

> > > > >  From my POV these = suggestions are in line with the provisions

> > > > > of Section 2.2

> > > > of RFC 3032 "Determining= the Network Layer Protocol" that states:

> > > > >

> > > > > <quote>=

> > > > >     = When the last label is popped from a packet's label stack (resulting

> > > > >     = in the stack being emptied), further processing of the packet is=

> > > > >     = based on the packet's network layer header.  The LSR which<= /p>

> > > > > pops

> > the

> > > > >     = last label off the stack must therefore be able to identify the<= /p>

> > > > >     = packet's network layer protocol.  However, the label stack does not

> > > > >     = contain any field which explicitly identifies the network layer<= /p>

> > > > >     = protocol.  This means that the identity of the network layer protocol<= o:p>

> > > > >     = must be inferable from the value of the label which is popped from

> > > > >     = the bottom of the stack, possibly along with the contents of the=

> > > > >     = network layer header itself.

> > > > > <end quote>

> > > > >

> > > > > My 2c,

> > > > > Sasha

> > > > > ________________________= ________________

> > > > > From: mpls <mpls-bounces@ietf.org> on behalf of Xuxiaohu

> > > > > <xu= xiaohu@huawei.com>

> > > > > Sent: Monday, January 26= , 2015 5:05 AM

> > > > > To: h= uubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org

> > > > > Subject: Re: [mpls] How = to indicate the presence of NSH in an

> > > > > MPLS

> > > packet?

> > > > >

> > > > > Hi Huub,

> > > > >

> > > > > The alter label itself c= ouldn=A1=AFt make the receiving LSR to

> > > > > determine the MPLS<= /o:p>

> > > > payload type by examining the= MPLS payload.

> > > > >

> > > > > Best regards,=

> > > > > Xiaohu

> > > > >

> > > > >> -----Original Messag= e-----

> > > > >> From: Huub van Helvo= ort [mailto:huubatwork@gmail.com]<= /p>

> > > > >> Sent: Friday, Januar= y 23, 2015 6:28 PM

> > > > >> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org

> > > > >> Subject: Re: [mpls] = How to indicate the presence of NSH in an

> > > > >> MPLS

> > > packet?

> > > > >>

> > > > >> Xuxiaohu =C4=FA=BA=C3=A3=A1

> > > > >>

> > > > >> Please correct me if= I am wrong:

> > > > >>

> > > > >> It has always been m= y understanding that the MPLS header/label

> > > > >> was independent of t= he protocol/payload.

> > > > >> So no indication of = the actual payload content was necessary.

> > > > >>

> > > > >> IMHO you could use t= he alert label 1 to indicate to the LSR

> > > > >> that it has to furth= er examine the content of a packet.

> > > > >>

> > > > >> Regards, Huub.<= /o:p>

> > > > >>

> > > > >> =3D=3D=3D=3D=3D=3D= =3D=3D

> > > > >>

> > > > >>> It said in (https://tools.ietf.org/html/draft-qui= nn-sfc-nsh-04):

> > > > >>>

> > > > >>>   = ;   The service header is independent of the encapsulation

> > > > >>> used and

> > is

> > > > >>>   = ;   encapsulated in existing transports.  The presence of NS= H is

> > > > >>>   = ;   indicated via protocol type or other indicator in the outer

> > > > >>>   = ;   encapsulation.

> > > > >>>

> > > > >>> In the case wher= e the outer encapsulation is an MPLS LSP, how

> > > > >>> to indicate the<= o:p>

> > > > >> presence of NSH sinc= e the MPLS encapsulation has no explicit

> > > > >> protocol identifier = field to indicate the protocol type of the

> > > > >> MPLS

> > > payload?

> > > > >> Should we make each = SFF to allocate a unique label for

> > > > >> indicating the prese= nce of NSH? Or should we use the control

> > > > >> word to indicate it?= Or should we reconsider the possibility of

> > > > >> adding an explicit p= rotocol identifier field to the MPLS

> > > > >> encapsulation so as = to solve such kind of issues

> > > > once and for all?<= /p>

> > > > >>>

> > > > >>> Best regards,

> > > > >>> Xiaohu

> > > > >>>

> > > > >>

> > > > >>

> > > > >> --

> > > > >>

> > > >

> > >

> ********************************************= **************

> > > ***

> > > > >> ****

> > > > >>   &nb= sp;            = =C7=EB=BC=C7=D7=A1=A3=AC=C4=E3=CA=C7=B6=C0=D2=BB=CE=DE=B6=FE=B5=C4=A3=AC=BE= =CD=CF=F1=C6=E4=CB=FB=C3=BF=D2=BB=B8=F6=C8=CB=D2=BB=D1=F9=

> > > > > ________________________= _______________________

> > > > > mpls mailing list

> > > > > mpls@ietf.or= g

> > > > > https://www.ietf.org/= mailman/listinfo/mpls

> > > > > ________________________= _______________________

> > > > > sfc mailing list

> > > > > sfc@ietf.org<= /span>

> > > > > https://www.ietf.org/= mailman/listinfo/sfc

> > > > >

> > > >

> > > > --

> > > >

> > > >

> > > > Loa Andersson  &nbs= p;            &= nbsp;        email: loa@mail01.huawei.com=

> > > > Senior MPLS Expert  = ;            &n= bsp;           loa@pi.nu<= o:p>

> > > > Huawei Technologies (consulta= nt)     phone: +46 739 81 21 64

--_000_E6C17D2345AC7A45B7D054D407AA205C39376271eusaamb105erics_-- From nobody Tue Jan 27 12:01:52 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2D1A6FF0; Tue, 27 Jan 2015 12:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aVm6-wcOVsD; Tue, 27 Jan 2015 12:01:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8BD1A8A46; Tue, 27 Jan 2015 12:01:39 -0800 (PST) Received: from hannes-mba.local (193.110.55.11) by DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) with Microsoft SMTP Server (TLS) id 15.1.59.20; Tue, 27 Jan 2015 20:01:16 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 50A73D6E580; Tue, 27 Jan 2015 21:01:01 +0100 (CET) Date: Tue, 27 Jan 2015 21:01:01 +0100 From: Hannes Gredler To: Lizhenbin Message-ID: <20150127200101.GA21477@hannes-mba.local> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.11] X-ClientProxiedBy: DB4PR06CA0018.eurprd06.prod.outlook.com (25.160.40.146) To DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DM2PR05MB447; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR05MB447; X-Forefront-PRVS: 046985391D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(37854004)(24454002)(53754006)(83506001)(46102003)(77096005)(98436002)(92566002)(62966003)(76176999)(54356999)(122386002)(2950100001)(47776003)(19580395003)(33656002)(77156002)(97736003)(76506005)(122856001)(15975445007)(23726002)(40100003)(86362001)(46406003)(110136001)(87976001)(19580405001)(50466002)(50986999)(68736005)(97756001)(66066001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB447; H:hannes-mba.local; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB447; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2015 20:01:16.6798 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB447 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: Re: [mpls] [spring] New Comments on Segment Routing(7): MTU Challenges for SR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 20:01:48 -0000 only can speak for IS-IS - afaik the Trill extensions gave us a way of signaling the MTU of a link ... so what we could do is to advertise the MTU for each adjacency and implement proper fragmentation at the TE tunnel ingress. /hannes On Tue, Jan 27, 2015 at 11:24:23AM +0000, Lizhenbin wrote: | Hi all authors of segment routing, | | This is the seventh commens. The issues proposed here are for both SR-TE | path and SR-BE path. | | | | 1 1 1 1 | S11-----------S12----------S13---------S14---------S15 | | | | | | | 1| 1| 1| 1| 1| | | | | | | | S21-----------S22----------S23---------S24---------S25 | 4 4 4 4 | | | | Still take the topology in the comment 6 as the example. No matter the | loose explicit path or | | the strict explicit path for the loose hop, assume the MTU of the | interface is the same, | | since the depth of the label stacks for the primary path and the backup | path are different. | | There is the risk that the effetive payload may transmit through the | primary path, but may be | | fragmented or dropped in the backup path. As the difference between the | label stacks of the | | primary path and the backup path increase, the risk will increase. | | | | From the case, we can deduce that the risk may exists for any scenarios in | which the same traffic | | may switch from one SR path to the other SR path. The SR path includes | SR-TE path such as MPLS TE | | hotstandby/reoptimization and SR-BE path such as TI-FRR. | | | | Besides above issues, LDP/RSVP-TE can support the path MTU to track the | MTU informaiton along the | | LSP through signalling. Then the reasonable MTU info will be adopted in | the ingress node. For both | | SR-TE path (if PCE is not used) and SR-BE path, since there is no | signalling to advertise | | the information. How to implement the feature? Or there maybe the risk | that the packet may be | | dropped by the nodes along the LSP. | | | | | | | | Regards, | | Robin | _______________________________________________ | spring mailing list | spring@ietf.org | https://www.ietf.org/mailman/listinfo/spring From nobody Tue Jan 27 15:29:41 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C72C1A9047 for ; Tue, 27 Jan 2015 15:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdHWZuTmkZhy for ; Tue, 27 Jan 2015 15:29:34 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022851A8834 for ; Tue, 27 Jan 2015 15:29:33 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1429.namprd05.prod.outlook.com (25.160.107.151) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 23:29:33 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 23:29:32 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 Thread-Index: AQHQOokaUQM9sTytWUe6Gbn/I16rRw== Date: Tue, 27 Jan 2015 23:29:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.15] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BY1PR0501MB1429; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1429; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(164054003)(377454003)(106116001)(62966003)(99286002)(2351001)(2900100001)(19609705001)(2950100001)(110136001)(15975445007)(102836002)(19580395003)(77156002)(19580405001)(86362001)(16236675004)(92566002)(50986999)(54356999)(54606007)(76176999)(46102003)(2656002)(87936001)(40100003)(122556002)(54206007)(19300405004)(2501002)(230783001)(33656002)(19625215002)(74316001)(66066001)(18717965001)(76576001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1429; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1430F180D82359BED2D4D676A5320BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 23:29:32.0106 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1429 Archived-At: Cc: "" , "draft-ietf-mpls-lsp-ping-registry@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 23:29:39 -0000 --_000_BY1PR0501MB1430F180D82359BED2D4D676A5320BY1PR0501MB1430_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder: there are two days left on this working group last call. Thanks, Ross From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, January 14, 2015 11:31 PM To: mpls@ietf.org Cc: ; draft-ietf-mpls-lsp-ping-registry@tools.i= etf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-regist= ry-00 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-lsp-ping-registry-00. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have stated on the working group mailing list that they are not aware of any IPR that relates to this draft. This working group last call ends January 29, 2015. Ross for the MPLS wg chairs --_000_BY1PR0501MB1430F180D82359BED2D4D676A5320BY1PR0501MB1430_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reminder: there are two d= ays left on this working group last call.

 <= /p>

Thanks, Ross

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, January 14, 2015 11:31 PM
To: mpls@ietf.org
Cc: <mpls-chairs@tools.ietf.org>; draft-ietf-mpls-lsp-ping-reg= istry@tools.ietf.org
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping= -registry-00

 

Working Group,

 

This is to initiate a two week working = group last call on

draft-ietf-mpls-lsp-ping-registry-00.

 

Please send your comments to the mpls w= g mailing list (mpls@ietf.org).

 

There are no IPR disclosures against th= is document. All the authors have

stated on the working group mailing lis= t that they are not aware of any

IPR that relates to this draft.

 

This working group last call ends Janua= ry 29, 2015. 

 

Ross

for the MPLS wg chairs

 

--_000_BY1PR0501MB1430F180D82359BED2D4D676A5320BY1PR0501MB1430_-- From nobody Tue Jan 27 16:05:30 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDC21AC3D1 for ; Tue, 27 Jan 2015 16:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEPeFHgtzSMG; Tue, 27 Jan 2015 16:05:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E03D61AC3D6; Tue, 27 Jan 2015 16:05:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-oam-ipv6-rao.all@tools.ietf.org, loa@pi.nu X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150128000524.6528.62596.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 16:05:24 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 00:05:28 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ From nobody Tue Jan 27 18:34:20 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6851ACC87; Tue, 27 Jan 2015 18:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgD_BAGL0Xqp; Tue, 27 Jan 2015 18:34:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0D31ACC82; Tue, 27 Jan 2015 18:34:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOM57127; Wed, 28 Jan 2015 02:34:14 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 02:34:13 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 28 Jan 2015 10:34:10 +0800 From: Xuxiaohu To: "Joel M. Halpern" , Alexander Vainshtein , "huubatwork@gmail.com" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAP/94nYAgARK9AD//sdrIA== Date: Wed, 28 Jan 2015 02:34:09 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083025EF@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> <54C7B084.3090709@joelhalpern.com> In-Reply-To: <54C7B084.3090709@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 02:34:19 -0000 SGkgSm9lbCwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15 IHJlc3BvbnNlIGlubGluZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiBTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDExOjM3IFBNDQo+IFRvOiBYdXhpYW9odTsgQWxleGFu ZGVyIFZhaW5zaHRlaW47IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+IENjOiBtcGxzQGlldGYub3Jn OyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNhdGUgdGhl IHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8NCj4gDQo+IEkgYW0gYSBiaXQgY29u Y2VybmVkIGJ5IHRoZSB0b25lIG9mIHRoaXMgd2hpY2ggYXNzdW1lcyB0aGF0IHRoZXJlIGlzIG9u bHkgb25lDQo+IHdheSB0byB1c2UgTVBMUyBhcyBhIHRyYW5zcG9ydCBmb3IgTlNILiAgVGhlcmUg YXJlIHNldmVyYWwgZGlmZmVyZW50DQo+IE1QTFMtYmFzZWQgdHJhbnNwb3J0IGFyY2hpdGVjdHVy ZXMgdGhhdCB3aWxsIHdvcmsuICBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgbW9zdCBvZg0KPiB0aGVt IHdpbGwgZXZlbiBpbnRlcm9wZXJhdGUgd2l0aCBlYWNoIG90aGVyLiAgQnV0IHRoZXkgZG8gaW1w bHkgZGlmZmVyZW50IHRoaW5ncw0KPiBhYm91dCBob3cgTlNIIGlzIGluZGljYXRlZC4NCg0KQWx0 aG91Z2ggd2UgY291bGQgdXNlIGRpZmZlcmVudCBhcHByb2FjaGVzIGZvciBpbmRpY2F0aW5nIHRo ZSBwcmVzZW5jZSBvZiB0aGUgTlNILCB3b3VsZG4ndCBpdCBiZSBiZXR0ZXIgaWYgd2UgY291bGQg ZmluZCBhIHVuaWZpZWQgYW5kIHN1c3RhaW5hYmxlIHdheSB0byBhZGRyZXNzIHRoaXMgTVBMUyBw YXlsb2FkIHR5cGUgaW5kaWNhdGlvbiBpc3N1ZT8NCg0KPiBBcyBmYXIgYXMgSSBjYW4gdGVsbCwg YWxsIG9mIHRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtcyBvcGVyYXRlIG9uIHRoZSBhc3N1bXB0aW9u DQo+IHRoYXQgZm9yd2FyZGluZyBkZXZpY2VzIGJldHdlZW4gU0ZGIHdpbGwgbm90IHNlZSBvciBu ZWVkIHRvIGJlIGF3YXJlIG9mIHRoZQ0KPiBOU0ggaGVhZGVyLiAgVGh1cywgdGhvc2Ugd2lsbCBh bHdheXMgaW50ZXJvcGVyYXRlLg0KPiANCj4gSW4gdGhlIE1QTFMgY2FzZSwgd2hldGhlciBvbmUg dGVybWluYXRlcyB0aGUgTVBMUyBMU1AgYXQgdGhlIGZpcnN0IFNGRiwgb3INCj4gYWxsb3dzIHRv IHRvIGNyb3NzIHNldmVyYWwgU0ZGIGFmZmVjdHMgaG93IGlkZW50aWZpY2F0aW9uIGlzIGRvbmUu DQo+IEFsc28sIGlmIHNlZ21lbnQgcm91dGluZyBpcyB1c2VkIHRoZW4gdGhlcmUgYXJlIG90aGVy IG9wdGlvbnMgc3VjaCBhcyB0aGUgdXNlIG9mDQo+IGRlZGljYXRlZCBsb2NhbCBzZXJ2aWNlIGxh YmVscyBmb3IgTlNIIGRlbGl2ZXJ5LiAgKERvaW5nIHRoYXQgd2l0aCBjb252ZW50aW9uYWwNCj4g TVBMUyBpcyBtb3JlIGNvbXBsZXgsIGJ1dCBsaWtlbHkgY2FuIGFsc28gYmUgZG9uZS4pDQoNCkRp ZCB5b3UgbWVhbiB1c2luZyBhIGxhYmVsIHN0YWNrIHRvIHJlcHJlc2VudCBhbiBTRlAgYnkgc2F5 aW5nICJpZiBzZWdtZW50IHJvdXRpbmcgaXMgdXNlZCIsIElmIHNvLCBzaW5jZSBlYWNoIFNGIG5v ZGUgYWxvbmcgdGhlIFNGUCB3b3VsZCBuZWVkIHRvIGtub3cgdGhlIE1QTFMgcGF5bG9hZCB0eXBl IGZvciBwZXJmb3JtaW5nIHRoZSBjb3JyZXNwb25kaW5nIHNlcnZpY2UgZnVuY3Rpb24gb24gdGhl IG9yaWdpbmFsIHBheWxvYWQsIGl0IHdvdWxkIHJlcXVpcmUgU0Ygbm9kZXMgdG8gYWxsb2NhdGUg YSBkZWRpY2F0ZWQgbG9jYWwgbGFiZWwgcGVyIHBheWxvYWQgdHlwZSBmb3IgYSBnaXZlbiBTRi4g UHJvdmlkZWQgd2UgaGF2ZSBhIHVuaWZpZWQgd2F5IGZvciBpbmRpY2F0aW5nIHRoZSBNUExTIHBh eWxvYWQgdHlwZSwgU0Ygbm9kZXMgb25seSBuZWVkIHRvIGFsbG9jYXRlIGEgc2luZ2xlIGxhYmVs IGZvciBhIGdpdmVuIFNGIHJlZ2FyZGxlc3Mgb2YgdGhlIHBheWxvYWQgdHlwZS4NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCj4gWW91cnMsDQo+IEpvZWwNCj4gDQo+IE9uIDEvMjcvMTUgMTo0 NSBBTSwgWHV4aWFvaHUgd3JvdGU6DQo+ID4gSGkgU2FzaGEsDQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0 bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gPj4gU2VudDogTW9uZGF5LCBK YW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0NCj4gPj4gVG86IFh1eGlhb2h1OyBodXViYXR3b3JrQGdt YWlsLmNvbQ0KPiA+PiBDYzogc2ZjQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+ID4+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4g TVBMUyBwYWNrZXQ/DQo+ID4+DQo+ID4+IFhpYW9odSwgSHV1YiwNCj4gPj4gSSBkbyBub3QgZm9s bG93IHRoZSBTRkMgd29yayBjbG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZA0K PiA+PiB3aGV0aGVyIHRoZSBOU0ggc2hvdWxkIGJlIGNhcHR1cmVkIGJ5ICB0cmFuc2l0IExTUnMg b24gdGhlIExTUCAtIG9yDQo+ID4+IGp1c3QgYnkgdGhlIExFUiBhY3RpbmcgYXMgdGhlIExTUCB0 YWlsLWVuZD8NCj4gPj4NCj4gPj4gSWYgdGhlIGxhdHRlciBpcyBjb3JyZWN0LCB0aGUgc2ltcGxl c3Qgd2F5IHRvIGluZGljYXRlIHByZXNlbmNlIG9mDQo+ID4+IHRoZSBOU0ggaW4gdGhlIE1QTFMg cGF5bG9hZCB3b3VsZCBiZSBieSBhbGxvY2F0aW5nIGFuICJhcHBsaWNhdGlvbg0KPiA+PiBsYWJl bCIgaW5kaWNhdGluZyBpdHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5z ZXJ0aW5nDQo+ID4+IGl0IGF0IHRoZSBib3R0b20gb2YgdGhlIGxhYmVsIHN0YWNrIGJ5IHRoZSBo ZWFkLWVuZCBMRVIgLSBzaW1pbGFyIHRvDQo+ID4+IHdoYXQgaXMgZG9uZSBmb3IgTDIvTDNWUE4u ICBXaXRoaW4gdGhpcw0KPiA+DQo+ID4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3QsIHRoZSBh Ym92ZSBhcHByb2FjaCBpcyB0aGUgc2FtZSBhcyBvcHRpb24gMQ0KPiA+IGFzIEkgbWVudGlvbmVk IGluIHRoZSBlYXJsaWVyIGVtYWlsIChpLmUuLCBtYWtpbmcgZWFjaCBTRkYgdG8gYWxsb2NhdGUg YSB1bmlxdWUNCj4gbGFiZWwgZm9yIGluZGljYXRpbmcgdGhlIHByZXNlbmNlIG9mIE5TSCkuDQo+ ID4NCj4gPj4gYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRlbXVsdGlwbGV4aW5nIG9mICBwYWNr ZXRzIHdpdGggTlNIIGluIHRoZQ0KPiA+PiBNUExTIHBheWxvYWQgaXMgbm90IHJlcXVpcmVkLCB5 b3UgY291bGQgcmVxdWVzdCBhbGxvY2F0aW9uIG9mIGEgbmV3DQo+ID4+IHNwZWNpYWwgcHVycG9z ZSBsYWJlbCBmcm9tIHRoZSBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2VzIGxhYmVsIHNwYWNlDQo+ ID4+IGFzIHBlciBSRkMgNzI3NCwgYW5kIHRvIGluc2VydCBzdWNoIGEgbGFiZWwgKHByZWNlZGVk IGJ5IHRoZSBFeHRlbnNpb24gTGFiZWwgKQ0KPiBhdCB0aGUgQm9TLg0KPiA+DQo+ID4gV2hhdCdz IHRoZSBwdXJwb3NlIG9mIGluc2VydGluZyBhIHBhcnRpY3VsYXIgRVNQIGxhYmVsIGF0IHRoZSBC b1M/DQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPj4gSWYgdGhl IGZvcm1lciBpcyBjb3JyZWN0LCB0aGUgcHJvY2VzcyBhYm92ZSBzdGlsbCBoYXMgdG8gYmUgdXNl ZCBidXQgaXQgaGFzIHRvIGJlDQo+ID4+IGF1Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBB bGVydCBMYWJlbCAgIGF0IHRoZSB0b3Agb2YgdGhlIGxhYmVsIHN0YWNrLg0KPiA+Pg0KPiA+PiAg RnJvbSBteSBQT1YgdGhlc2Ugc3VnZ2VzdGlvbnMgYXJlIGluIGxpbmUgd2l0aCB0aGUgcHJvdmlz aW9ucyBvZg0KPiA+PiBTZWN0aW9uIDIuMiBvZiBSRkMgMzAzMiAiRGV0ZXJtaW5pbmcgdGhlIE5l dHdvcmsgTGF5ZXIgUHJvdG9jb2wiIHRoYXQNCj4gc3RhdGVzOg0KPiA+Pg0KPiA+PiA8cXVvdGU+ DQo+ID4+ICAgICBXaGVuIHRoZSBsYXN0IGxhYmVsIGlzIHBvcHBlZCBmcm9tIGEgcGFja2V0J3Mg bGFiZWwgc3RhY2sgKHJlc3VsdGluZw0KPiA+PiAgICAgaW4gdGhlIHN0YWNrIGJlaW5nIGVtcHRp ZWQpLCBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBhY2tldCBpcw0KPiA+PiAgICAgYmFzZWQg b24gdGhlIHBhY2tldCdzIG5ldHdvcmsgbGF5ZXIgaGVhZGVyLiAgVGhlIExTUiB3aGljaCBwb3Bz IHRoZQ0KPiA+PiAgICAgbGFzdCBsYWJlbCBvZmYgdGhlIHN0YWNrIG11c3QgdGhlcmVmb3JlIGJl IGFibGUgdG8gaWRlbnRpZnkgdGhlDQo+ID4+ICAgICBwYWNrZXQncyBuZXR3b3JrIGxheWVyIHBy b3RvY29sLiAgSG93ZXZlciwgdGhlIGxhYmVsIHN0YWNrIGRvZXMgbm90DQo+ID4+ICAgICBjb250 YWluIGFueSBmaWVsZCB3aGljaCBleHBsaWNpdGx5IGlkZW50aWZpZXMgdGhlIG5ldHdvcmsgbGF5 ZXINCj4gPj4gICAgIHByb3RvY29sLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBpZGVudGl0eSBvZiB0 aGUgbmV0d29yayBsYXllciBwcm90b2NvbA0KPiA+PiAgICAgbXVzdCBiZSBpbmZlcmFibGUgZnJv bSB0aGUgdmFsdWUgb2YgdGhlIGxhYmVsIHdoaWNoIGlzIHBvcHBlZCBmcm9tDQo+ID4+ICAgICB0 aGUgYm90dG9tIG9mIHRoZSBzdGFjaywgcG9zc2libHkgYWxvbmcgd2l0aCB0aGUgY29udGVudHMg b2YgdGhlDQo+ID4+ICAgICBuZXR3b3JrIGxheWVyIGhlYWRlciBpdHNlbGYuDQo+ID4+IDxlbmQg cXVvdGU+DQo+ID4+DQo+ID4+IE15IDJjLA0KPiA+PiBTYXNoYQ0KPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IEZyb206IG1wbHMgPG1wbHMtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFh1eGlhb2h1DQo+ID4+IDx4dXhpYW9odUBodWF3ZWku Y29tPg0KPiA+PiBTZW50OiBNb25kYXksIEphbnVhcnkgMjYsIDIwMTUgNTowNSBBTQ0KPiA+PiBU bzogaHV1YmF0d29ya0BnbWFpbC5jb207IHNmY0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KPiA+ PiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNI IGluIGFuIE1QTFMgcGFja2V0Pw0KPiA+Pg0KPiA+PiBIaSBIdXViLA0KPiA+Pg0KPiA+PiBUaGUg YWx0ZXIgbGFiZWwgaXRzZWxmIGNvdWxkbqGvdCBtYWtlIHRoZSByZWNlaXZpbmcgTFNSIHRvIGRl dGVybWluZQ0KPiA+PiB0aGUgTVBMUyBwYXlsb2FkIHR5cGUgYnkgZXhhbWluaW5nIHRoZSBNUExT IHBheWxvYWQuDQo+ID4+DQo+ID4+IEJlc3QgcmVnYXJkcywNCj4gPj4gWGlhb2h1DQo+ID4+DQo+ ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogSHV1YiB2YW4gSGVs dm9vcnQgW21haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbV0NCj4gPj4+IFNlbnQ6IEZyaWRheSwg SmFudWFyeSAyMywgMjAxNSA2OjI4IFBNDQo+ID4+PiBUbzogWHV4aWFvaHU7IHNmY0BpZXRmLm9y ZzsgbXBsc0BpZXRmLm9yZw0KPiA+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5kaWNh dGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8NCj4gPj4+DQo+ID4+PiBY dXhpYW9odSDE+rrDo6ENCj4gPj4+DQo+ID4+PiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdy b25nOg0KPiA+Pj4NCj4gPj4+IEl0IGhhcyBhbHdheXMgYmVlbiBteSB1bmRlcnN0YW5kaW5nIHRo YXQgdGhlIE1QTFMgaGVhZGVyL2xhYmVsIHdhcw0KPiA+Pj4gaW5kZXBlbmRlbnQgb2YgdGhlIHBy b3RvY29sL3BheWxvYWQuDQo+ID4+PiBTbyBubyBpbmRpY2F0aW9uIG9mIHRoZSBhY3R1YWwgcGF5 bG9hZCBjb250ZW50IHdhcyBuZWNlc3NhcnkuDQo+ID4+Pg0KPiA+Pj4gSU1ITyB5b3UgY291bGQg dXNlIHRoZSBhbGVydCBsYWJlbCAxIHRvIGluZGljYXRlIHRvIHRoZSBMU1IgdGhhdCBpdA0KPiA+ Pj4gaGFzIHRvIGZ1cnRoZXIgZXhhbWluZSB0aGUgY29udGVudCBvZiBhIHBhY2tldC4NCj4gPj4+ DQo+ID4+PiBSZWdhcmRzLCBIdXViLg0KPiA+Pj4NCj4gPj4+ID09PT09PT09DQo+ID4+Pg0KPiA+ Pj4+IEl0IHNhaWQgaW4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1z ZmMtbnNoLTA0KToNCj4gPj4+Pg0KPiA+Pj4+ICAgICAgVGhlIHNlcnZpY2UgaGVhZGVyIGlzIGlu ZGVwZW5kZW50IG9mIHRoZSBlbmNhcHN1bGF0aW9uIHVzZWQgYW5kIGlzDQo+ID4+Pj4gICAgICBl bmNhcHN1bGF0ZWQgaW4gZXhpc3RpbmcgdHJhbnNwb3J0cy4gIFRoZSBwcmVzZW5jZSBvZiBOU0gg aXMNCj4gPj4+PiAgICAgIGluZGljYXRlZCB2aWEgcHJvdG9jb2wgdHlwZSBvciBvdGhlciBpbmRp Y2F0b3IgaW4gdGhlIG91dGVyDQo+ID4+Pj4gICAgICBlbmNhcHN1bGF0aW9uLg0KPiA+Pj4+DQo+ ID4+Pj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gaXMgYW4gTVBM UyBMU1AsIGhvdyB0bw0KPiA+Pj4+IGluZGljYXRlIHRoZQ0KPiA+Pj4gcHJlc2VuY2Ugb2YgTlNI IHNpbmNlIHRoZSBNUExTIGVuY2Fwc3VsYXRpb24gaGFzIG5vIGV4cGxpY2l0DQo+ID4+PiBwcm90 b2NvbCBpZGVudGlmaWVyIGZpZWxkIHRvIGluZGljYXRlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRo ZSBNUExTIHBheWxvYWQ/DQo+ID4+PiBTaG91bGQgd2UgbWFrZSBlYWNoIFNGRiB0byBhbGxvY2F0 ZSBhIHVuaXF1ZSBsYWJlbCBmb3IgaW5kaWNhdGluZw0KPiA+Pj4gdGhlIHByZXNlbmNlIG9mIE5T SD8gT3Igc2hvdWxkIHdlIHVzZSB0aGUgY29udHJvbCB3b3JkIHRvIGluZGljYXRlDQo+ID4+PiBp dD8gT3Igc2hvdWxkIHdlIHJlY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhbiBl eHBsaWNpdA0KPiA+Pj4gcHJvdG9jb2wgaWRlbnRpZmllciBmaWVsZCB0byB0aGUgTVBMUyBlbmNh cHN1bGF0aW9uIHNvIGFzIHRvIHNvbHZlDQo+ID4+PiBzdWNoIGtpbmQgb2YgaXNzdWVzDQo+ID4+ IG9uY2UgYW5kIGZvciBhbGw/DQo+ID4+Pj4NCj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4g WGlhb2h1DQo+ID4+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0NCj4gPj4+DQo+ID4+DQo+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCj4gPj4+ICoqKioNCj4gPj4+ICAgICAgICAgICAgICAgICDH67zH16GjrMTjyse2wNK7zt62 /rXEo6y+zc/xxuTL+8O/0ru49sjL0rvR+Q0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+PiBtcGxz QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiBtcGxzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4NCg== From nobody Tue Jan 27 18:39:28 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDFE1ACC87; Tue, 27 Jan 2015 18:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2BwD8UtMocg; Tue, 27 Jan 2015 18:39:24 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2EA1A1AE0; Tue, 27 Jan 2015 18:39:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 77D21240D97; Tue, 27 Jan 2015 18:39:24 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9C3452405A5; Tue, 27 Jan 2015 18:39:22 -0800 (PST) Message-ID: <54C84BD8.6060504@joelhalpern.com> Date: Tue, 27 Jan 2015 21:39:20 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Xuxiaohu , Alexander Vainshtein , "huubatwork@gmail.com" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> <54C7B084.3090709@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083025EF@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083025EF@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 02:39:26 -0000 If one uses service labels (as in segment routing), one would not have a service label per payload type but rather one per services. Since the SFC services will be different from any other use of labels, those labels will be distinct. Since they are local, it does not even matter how many there are. The point is that the different deployments of MPLS for service chaining lead to different identification needs. If the needs were identical then I would agree that a common identification scheme would be appropriate. Yours, Joel On 1/27/15 9:34 PM, Xuxiaohu wrote: > Hi Joel, > > Thanks a lot for your comments. Please see my response inline. > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, January 27, 2015 11:37 PM >> To: Xuxiaohu; Alexander Vainshtein; huubatwork@gmail.com >> Cc: mpls@ietf.org; sfc@ietf.org >> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >> >> I am a bit concerned by the tone of this which assumes that there is only one >> way to use MPLS as a transport for NSH. There are several different >> MPLS-based transport architectures that will work. As far as I can tell, most of >> them will even interoperate with each other. But they do imply different things >> about how NSH is indicated. > > Although we could use different approaches for indicating the presence of the NSH, wouldn't it be better if we could find a unified and sustainable way to address this MPLS payload type indication issue? > >> As far as I can tell, all of the transport mechanisms operate on the assumption >> that forwarding devices between SFF will not see or need to be aware of the >> NSH header. Thus, those will always interoperate. >> >> In the MPLS case, whether one terminates the MPLS LSP at the first SFF, or >> allows to to cross several SFF affects how identification is done. >> Also, if segment routing is used then there are other options such as the use of >> dedicated local service labels for NSH delivery. (Doing that with conventional >> MPLS is more complex, but likely can also be done.) > > Did you mean using a label stack to represent an SFP by saying "if segment routing is used", If so, since each SF node along the SFP would need to know the MPLS payload type for performing the corresponding service function on the original payload, it would require SF nodes to allocate a dedicated local label per payload type for a given SF. Provided we have a unified way for indicating the MPLS payload type, SF nodes only need to allocate a single label for a given SF regardless of the payload type. > > Best regards, > Xiaohu > >> Yours, >> Joel >> >> On 1/27/15 1:45 AM, Xuxiaohu wrote: >>> Hi Sasha, >>> >>>> -----Original Message----- >>>> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >>>> Sent: Monday, January 26, 2015 2:22 PM >>>> To: Xuxiaohu; huubatwork@gmail.com >>>> Cc: sfc@ietf.org; mpls@ietf.org >>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >>>> >>>> Xiaohu, Huub, >>>> I do not follow the SFC work closely, so I would like to understand >>>> whether the NSH should be captured by transit LSRs on the LSP - or >>>> just by the LER acting as the LSP tail-end? >>>> >>>> If the latter is correct, the simplest way to indicate presence of >>>> the NSH in the MPLS payload would be by allocating an "application >>>> label" indicating its presence by the tail-end LER and by inserting >>>> it at the bottom of the label stack by the head-end LER - similar to >>>> what is done for L2/L3VPN. Within this >>> >>> If I understand it correct, the above approach is the same as option 1 >>> as I mentioned in the earlier email (i.e., making each SFF to allocate a unique >> label for indicating the presence of NSH). >>> >>>> approach, if label-based demultiplexing of packets with NSH in the >>>> MPLS payload is not required, you could request allocation of a new >>>> special purpose label from the extended special purposes label space >>>> as per RFC 7274, and to insert such a label (preceded by the Extension Label ) >> at the BoS. >>> >>> What's the purpose of inserting a particular ESP label at the BoS? >>> >>> Best regards, >>> Xiaohu >>> >>>> If the former is correct, the process above still has to be used but it has to be >>>> augmented by adding the Router Alert Label at the top of the label stack. >>>> >>>> From my POV these suggestions are in line with the provisions of >>>> Section 2.2 of RFC 3032 "Determining the Network Layer Protocol" that >> states: >>>> >>>> >>>> When the last label is popped from a packet's label stack (resulting >>>> in the stack being emptied), further processing of the packet is >>>> based on the packet's network layer header. The LSR which pops the >>>> last label off the stack must therefore be able to identify the >>>> packet's network layer protocol. However, the label stack does not >>>> contain any field which explicitly identifies the network layer >>>> protocol. This means that the identity of the network layer protocol >>>> must be inferable from the value of the label which is popped from >>>> the bottom of the stack, possibly along with the contents of the >>>> network layer header itself. >>>> >>>> >>>> My 2c, >>>> Sasha >>>> ________________________________________ >>>> From: mpls on behalf of Xuxiaohu >>>> >>>> Sent: Monday, January 26, 2015 5:05 AM >>>> To: huubatwork@gmail.com; sfc@ietf.org; mpls@ietf.org >>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >>>> >>>> Hi Huub, >>>> >>>> The alter label itself couldn¡¯t make the receiving LSR to determine >>>> the MPLS payload type by examining the MPLS payload. >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>>> -----Original Message----- >>>>> From: Huub van Helvoort [mailto:huubatwork@gmail.com] >>>>> Sent: Friday, January 23, 2015 6:28 PM >>>>> To: Xuxiaohu; sfc@ietf.org; mpls@ietf.org >>>>> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? >>>>> >>>>> Xuxiaohu ÄúºÃ£¡ >>>>> >>>>> Please correct me if I am wrong: >>>>> >>>>> It has always been my understanding that the MPLS header/label was >>>>> independent of the protocol/payload. >>>>> So no indication of the actual payload content was necessary. >>>>> >>>>> IMHO you could use the alert label 1 to indicate to the LSR that it >>>>> has to further examine the content of a packet. >>>>> >>>>> Regards, Huub. >>>>> >>>>> ======== >>>>> >>>>>> It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04): >>>>>> >>>>>> The service header is independent of the encapsulation used and is >>>>>> encapsulated in existing transports. The presence of NSH is >>>>>> indicated via protocol type or other indicator in the outer >>>>>> encapsulation. >>>>>> >>>>>> In the case where the outer encapsulation is an MPLS LSP, how to >>>>>> indicate the >>>>> presence of NSH since the MPLS encapsulation has no explicit >>>>> protocol identifier field to indicate the protocol type of the MPLS payload? >>>>> Should we make each SFF to allocate a unique label for indicating >>>>> the presence of NSH? Or should we use the control word to indicate >>>>> it? Or should we reconsider the possibility of adding an explicit >>>>> protocol identifier field to the MPLS encapsulation so as to solve >>>>> such kind of issues >>>> once and for all? >>>>>> >>>>>> Best regards, >>>>>> Xiaohu >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>> >> ************************************************************* >>>>> **** >>>>> Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> From nobody Tue Jan 27 19:29:43 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C30B1A1B7C; Tue, 27 Jan 2015 19:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_711=0.243, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWavByZARk3v; Tue, 27 Jan 2015 19:29:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7067E1A1B78; Tue, 27 Jan 2015 19:29:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOM60703; Wed, 28 Jan 2015 03:29:33 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 03:29:31 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 28 Jan 2015 11:29:27 +0800 From: Xuxiaohu To: "Joel M. Halpern" , Alexander Vainshtein , "huubatwork@gmail.com" Thread-Topic: [mpls] How to indicate the presence of NSH in an MPLS packet? Thread-Index: AdA2srbV3yAzCRj8QR6/iozFYqdSegAAYPUAAJf3dfD//7JaAP/94nYAgARK9AD//sdrIIAB8b8A//9uXbA= Date: Wed, 28 Jan 2015 03:29:27 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830261F@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FD4B5@NKGEML512-MBS.china.huawei.com> <54C2223A.3080605@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082FDB1D@NKGEML512-MBS.china.huawei.com> <1422253291241.41262@ecitele.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830202B@NKGEML512-MBS.china.huawei.com> <54C7B084.3090709@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083025EF@NKGEML512-MBS.china.huawei.com> <54C84BD8.6060504@joelhalpern.com> In-Reply-To: <54C84BD8.6060504@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 03:29:40 -0000 SGkgSm9lbCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2VsIE0u IEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiBTZW50OiBXZWRuZXNkYXks IEphbnVhcnkgMjgsIDIwMTUgMTA6MzkgQU0NCj4gVG86IFh1eGlhb2h1OyBBbGV4YW5kZXIgVmFp bnNodGVpbjsgaHV1YmF0d29ya0BnbWFpbC5jb20NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHNmY0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRpY2F0ZSB0aGUgcHJlc2Vu Y2Ugb2YgTlNIIGluIGFuIE1QTFMgcGFja2V0Pw0KPiANCj4gSWYgb25lIHVzZXMgc2VydmljZSBs YWJlbHMgKGFzIGluIHNlZ21lbnQgcm91dGluZyksIG9uZSB3b3VsZCBub3QgaGF2ZSBhIHNlcnZp Y2UNCj4gbGFiZWwgcGVyIHBheWxvYWQgdHlwZSBidXQgcmF0aGVyIG9uZSBwZXIgc2VydmljZXMu ICBTaW5jZSB0aGUgU0ZDIHNlcnZpY2VzIHdpbGwNCj4gYmUgZGlmZmVyZW50IGZyb20gYW55IG90 aGVyIHVzZSBvZiBsYWJlbHMsIHRob3NlIGxhYmVscyB3aWxsIGJlIGRpc3RpbmN0LiAgU2luY2UN Cj4gdGhleSBhcmUgbG9jYWwsIGl0IGRvZXMgbm90IGV2ZW4gbWF0dGVyIGhvdyBtYW55IHRoZXJl IGFyZS4NCg0KU2luY2UgdGhlIE1QTFMgcGF5bG9hZCBjb3VsZCBiZSBJUHY0IHBhY2tldCwgSVB2 NiBwYWNrZXQsIEV0aGVybmV0IGZyYW1lIG9yIGV2ZW4gTlNIIChhcyBhIG1ldGFkYXRhIGNvbnRh aW5lciBvbmx5KSBpbiB0aGUgTVBMUy1TUFJJTkctYmFzZWQgU0ZDIGFwcHJvYWNoLCBob3cgY291 bGQgdGhlIFNGIG9yIHRoZSBTRkMtcHJveHkgZGV0ZXJtaW5lIHRoZSBNUExTIHBheWxvYWQgdHlw ZSBpZiBvbmUgbGFiZWwgcGVyIHNlcnZpY2UgaXMgYWxsb2NhdGVkLg0KDQo+IFRoZSBwb2ludCBp cyB0aGF0IHRoZSBkaWZmZXJlbnQgZGVwbG95bWVudHMgb2YgTVBMUyBmb3Igc2VydmljZSBjaGFp bmluZyBsZWFkIHRvDQo+IGRpZmZlcmVudCBpZGVudGlmaWNhdGlvbiBuZWVkcy4gIElmIHRoZSBu ZWVkcyB3ZXJlIGlkZW50aWNhbCB0aGVuIEkgd291bGQgYWdyZWUNCj4gdGhhdCBhIGNvbW1vbiBp ZGVudGlmaWNhdGlvbiBzY2hlbWUgd291bGQgYmUgYXBwcm9wcmlhdGUuDQoNCklNSE8sIGFsdGhv dWdoIHRoZSBTRlAvU0ZDIGlkZW50aWZpY2F0aW9uIG5lZWRzIGFyZSBkaWZmZXJlbnQsIHRoZSBN UExTIHBheWxvYWQgdHlwZSBpZGVudGlmaWNhdGlvbiBuZWVkcyBhcmUgYWxtb3N0IHRoZSBzYW1l Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gT24g MS8yNy8xNSA5OjM0IFBNLCBYdXhpYW9odSB3cm90ZToNCj4gPiBIaSBKb2VsLA0KPiA+DQo+ID4g VGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGlu bGluZS4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBK b2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiA+PiBTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDExOjM3IFBNDQo+ID4+IFRvOiBYdXhpYW9odTsgQWxl eGFuZGVyIFZhaW5zaHRlaW47IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+ID4+IENjOiBtcGxzQGll dGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBIb3cgdG8gaW5k aWNhdGUgdGhlIHByZXNlbmNlIG9mIE5TSCBpbiBhbiBNUExTIHBhY2tldD8NCj4gPj4NCj4gPj4g SSBhbSBhIGJpdCBjb25jZXJuZWQgYnkgdGhlIHRvbmUgb2YgdGhpcyB3aGljaCBhc3N1bWVzIHRo YXQgdGhlcmUgaXMNCj4gPj4gb25seSBvbmUgd2F5IHRvIHVzZSBNUExTIGFzIGEgdHJhbnNwb3J0 IGZvciBOU0guICBUaGVyZSBhcmUgc2V2ZXJhbA0KPiA+PiBkaWZmZXJlbnQgTVBMUy1iYXNlZCB0 cmFuc3BvcnQgYXJjaGl0ZWN0dXJlcyB0aGF0IHdpbGwgd29yay4gIEFzIGZhcg0KPiA+PiBhcyBJ IGNhbiB0ZWxsLCBtb3N0IG9mIHRoZW0gd2lsbCBldmVuIGludGVyb3BlcmF0ZSB3aXRoIGVhY2gg b3RoZXIuDQo+ID4+IEJ1dCB0aGV5IGRvIGltcGx5IGRpZmZlcmVudCB0aGluZ3MgYWJvdXQgaG93 IE5TSCBpcyBpbmRpY2F0ZWQuDQo+ID4NCj4gPiBBbHRob3VnaCB3ZSBjb3VsZCB1c2UgZGlmZmVy ZW50IGFwcHJvYWNoZXMgZm9yIGluZGljYXRpbmcgdGhlIHByZXNlbmNlIG9mIHRoZQ0KPiBOU0gs IHdvdWxkbid0IGl0IGJlIGJldHRlciBpZiB3ZSBjb3VsZCBmaW5kIGEgdW5pZmllZCBhbmQgc3Vz dGFpbmFibGUgd2F5IHRvDQo+IGFkZHJlc3MgdGhpcyBNUExTIHBheWxvYWQgdHlwZSBpbmRpY2F0 aW9uIGlzc3VlPw0KPiA+DQo+ID4+IEFzIGZhciBhcyBJIGNhbiB0ZWxsLCBhbGwgb2YgdGhlIHRy YW5zcG9ydCBtZWNoYW5pc21zIG9wZXJhdGUgb24gdGhlDQo+ID4+IGFzc3VtcHRpb24gdGhhdCBm b3J3YXJkaW5nIGRldmljZXMgYmV0d2VlbiBTRkYgd2lsbCBub3Qgc2VlIG9yIG5lZWQNCj4gPj4g dG8gYmUgYXdhcmUgb2YgdGhlIE5TSCBoZWFkZXIuICBUaHVzLCB0aG9zZSB3aWxsIGFsd2F5cyBp bnRlcm9wZXJhdGUuDQo+ID4+DQo+ID4+IEluIHRoZSBNUExTIGNhc2UsIHdoZXRoZXIgb25lIHRl cm1pbmF0ZXMgdGhlIE1QTFMgTFNQIGF0IHRoZSBmaXJzdA0KPiA+PiBTRkYsIG9yIGFsbG93cyB0 byB0byBjcm9zcyBzZXZlcmFsIFNGRiBhZmZlY3RzIGhvdyBpZGVudGlmaWNhdGlvbiBpcyBkb25l Lg0KPiA+PiBBbHNvLCBpZiBzZWdtZW50IHJvdXRpbmcgaXMgdXNlZCB0aGVuIHRoZXJlIGFyZSBv dGhlciBvcHRpb25zIHN1Y2ggYXMNCj4gPj4gdGhlIHVzZSBvZiBkZWRpY2F0ZWQgbG9jYWwgc2Vy dmljZSBsYWJlbHMgZm9yIE5TSCBkZWxpdmVyeS4gIChEb2luZw0KPiA+PiB0aGF0IHdpdGggY29u dmVudGlvbmFsIE1QTFMgaXMgbW9yZSBjb21wbGV4LCBidXQgbGlrZWx5IGNhbiBhbHNvIGJlDQo+ ID4+IGRvbmUuKQ0KPiA+DQo+ID4gRGlkIHlvdSBtZWFuIHVzaW5nIGEgbGFiZWwgc3RhY2sgdG8g cmVwcmVzZW50IGFuIFNGUCBieSBzYXlpbmcgImlmIHNlZ21lbnQNCj4gcm91dGluZyBpcyB1c2Vk IiwgSWYgc28sIHNpbmNlIGVhY2ggU0Ygbm9kZSBhbG9uZyB0aGUgU0ZQIHdvdWxkIG5lZWQgdG8g a25vdyB0aGUNCj4gTVBMUyBwYXlsb2FkIHR5cGUgZm9yIHBlcmZvcm1pbmcgdGhlIGNvcnJlc3Bv bmRpbmcgc2VydmljZSBmdW5jdGlvbiBvbiB0aGUNCj4gb3JpZ2luYWwgcGF5bG9hZCwgaXQgd291 bGQgcmVxdWlyZSBTRiBub2RlcyB0byBhbGxvY2F0ZSBhIGRlZGljYXRlZCBsb2NhbCBsYWJlbCBw ZXINCj4gcGF5bG9hZCB0eXBlIGZvciBhIGdpdmVuIFNGLiBQcm92aWRlZCB3ZSBoYXZlIGEgdW5p ZmllZCB3YXkgZm9yIGluZGljYXRpbmcgdGhlDQo+IE1QTFMgcGF5bG9hZCB0eXBlLCBTRiBub2Rl cyBvbmx5IG5lZWQgdG8gYWxsb2NhdGUgYSBzaW5nbGUgbGFiZWwgZm9yIGEgZ2l2ZW4gU0YNCj4g cmVnYXJkbGVzcyBvZiB0aGUgcGF5bG9hZCB0eXBlLg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0K PiA+IFhpYW9odQ0KPiA+DQo+ID4+IFlvdXJzLA0KPiA+PiBKb2VsDQo+ID4+DQo+ID4+IE9uIDEv MjcvMTUgMTo0NSBBTSwgWHV4aWFvaHUgd3JvdGU6DQo+ID4+PiBIaSBTYXNoYSwNCj4gPj4+DQo+ ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBBbGV4YW5kZXIg VmFpbnNodGVpbg0KPiA+Pj4+IFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b21dDQo+ID4+Pj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDI6MjIgUE0NCj4gPj4+ PiBUbzogWHV4aWFvaHU7IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+ID4+Pj4gQ2M6IHNmY0BpZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGlu ZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiBwYWNrZXQ/DQo+ID4+Pj4N Cj4gPj4+PiBYaWFvaHUsIEh1dWIsDQo+ID4+Pj4gSSBkbyBub3QgZm9sbG93IHRoZSBTRkMgd29y ayBjbG9zZWx5LCBzbyBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZA0KPiA+Pj4+IHdoZXRoZXIg dGhlIE5TSCBzaG91bGQgYmUgY2FwdHVyZWQgYnkgIHRyYW5zaXQgTFNScyBvbiB0aGUgTFNQIC0g b3INCj4gPj4+PiBqdXN0IGJ5IHRoZSBMRVIgYWN0aW5nIGFzIHRoZSBMU1AgdGFpbC1lbmQ/DQo+ ID4+Pj4NCj4gPj4+PiBJZiB0aGUgbGF0dGVyIGlzIGNvcnJlY3QsIHRoZSBzaW1wbGVzdCB3YXkg dG8gaW5kaWNhdGUgcHJlc2VuY2Ugb2YNCj4gPj4+PiB0aGUgTlNIIGluIHRoZSBNUExTIHBheWxv YWQgd291bGQgYmUgYnkgYWxsb2NhdGluZyBhbiAiYXBwbGljYXRpb24NCj4gPj4+PiBsYWJlbCIg aW5kaWNhdGluZyBpdHMgcHJlc2VuY2UgYnkgdGhlIHRhaWwtZW5kIExFUiBhbmQgYnkgaW5zZXJ0 aW5nDQo+ID4+Pj4gaXQgYXQgdGhlIGJvdHRvbSBvZiB0aGUgbGFiZWwgc3RhY2sgYnkgdGhlIGhl YWQtZW5kIExFUiAtIHNpbWlsYXINCj4gPj4+PiB0byB3aGF0IGlzIGRvbmUgZm9yIEwyL0wzVlBO LiAgV2l0aGluIHRoaXMNCj4gPj4+DQo+ID4+PiBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdCwg dGhlIGFib3ZlIGFwcHJvYWNoIGlzIHRoZSBzYW1lIGFzIG9wdGlvbg0KPiA+Pj4gMSBhcyBJIG1l bnRpb25lZCBpbiB0aGUgZWFybGllciBlbWFpbCAoaS5lLiwgbWFraW5nIGVhY2ggU0ZGIHRvDQo+ ID4+PiBhbGxvY2F0ZSBhIHVuaXF1ZQ0KPiA+PiBsYWJlbCBmb3IgaW5kaWNhdGluZyB0aGUgcHJl c2VuY2Ugb2YgTlNIKS4NCj4gPj4+DQo+ID4+Pj4gYXBwcm9hY2gsIGlmIGxhYmVsLWJhc2VkIGRl bXVsdGlwbGV4aW5nIG9mICBwYWNrZXRzIHdpdGggTlNIIGluIHRoZQ0KPiA+Pj4+IE1QTFMgcGF5 bG9hZCBpcyBub3QgcmVxdWlyZWQsIHlvdSBjb3VsZCByZXF1ZXN0IGFsbG9jYXRpb24gb2YgYSBu ZXcNCj4gPj4+PiBzcGVjaWFsIHB1cnBvc2UgbGFiZWwgZnJvbSB0aGUgZXh0ZW5kZWQgc3BlY2lh bCBwdXJwb3NlcyBsYWJlbA0KPiA+Pj4+IHNwYWNlIGFzIHBlciBSRkMgNzI3NCwgYW5kIHRvIGlu c2VydCBzdWNoIGEgbGFiZWwgKHByZWNlZGVkIGJ5IHRoZQ0KPiA+Pj4+IEV4dGVuc2lvbiBMYWJl bCApDQo+ID4+IGF0IHRoZSBCb1MuDQo+ID4+Pg0KPiA+Pj4gV2hhdCdzIHRoZSBwdXJwb3NlIG9m IGluc2VydGluZyBhIHBhcnRpY3VsYXIgRVNQIGxhYmVsIGF0IHRoZSBCb1M/DQo+ID4+Pg0KPiA+ Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4gWGlhb2h1DQo+ID4+Pg0KPiA+Pj4+IElmIHRoZSBmb3Jt ZXIgaXMgY29ycmVjdCwgdGhlIHByb2Nlc3MgYWJvdmUgc3RpbGwgaGFzIHRvIGJlIHVzZWQgYnV0 IGl0IGhhcyB0bw0KPiBiZQ0KPiA+Pj4+IGF1Z21lbnRlZCBieSBhZGRpbmcgdGhlIFJvdXRlciBB bGVydCBMYWJlbCAgIGF0IHRoZSB0b3Agb2YgdGhlIGxhYmVsDQo+IHN0YWNrLg0KPiA+Pj4+DQo+ ID4+Pj4gICBGcm9tIG15IFBPViB0aGVzZSBzdWdnZXN0aW9ucyBhcmUgaW4gbGluZSB3aXRoIHRo ZSBwcm92aXNpb25zIG9mDQo+ID4+Pj4gU2VjdGlvbiAyLjIgb2YgUkZDIDMwMzIgIkRldGVybWlu aW5nIHRoZSBOZXR3b3JrIExheWVyIFByb3RvY29sIg0KPiA+Pj4+IHRoYXQNCj4gPj4gc3RhdGVz Og0KPiA+Pj4+DQo+ID4+Pj4gPHF1b3RlPg0KPiA+Pj4+ICAgICAgV2hlbiB0aGUgbGFzdCBsYWJl bCBpcyBwb3BwZWQgZnJvbSBhIHBhY2tldCdzIGxhYmVsIHN0YWNrIChyZXN1bHRpbmcNCj4gPj4+ PiAgICAgIGluIHRoZSBzdGFjayBiZWluZyBlbXB0aWVkKSwgZnVydGhlciBwcm9jZXNzaW5nIG9m IHRoZSBwYWNrZXQgaXMNCj4gPj4+PiAgICAgIGJhc2VkIG9uIHRoZSBwYWNrZXQncyBuZXR3b3Jr IGxheWVyIGhlYWRlci4gIFRoZSBMU1Igd2hpY2ggcG9wcw0KPiB0aGUNCj4gPj4+PiAgICAgIGxh c3QgbGFiZWwgb2ZmIHRoZSBzdGFjayBtdXN0IHRoZXJlZm9yZSBiZSBhYmxlIHRvIGlkZW50aWZ5 IHRoZQ0KPiA+Pj4+ICAgICAgcGFja2V0J3MgbmV0d29yayBsYXllciBwcm90b2NvbC4gIEhvd2V2 ZXIsIHRoZSBsYWJlbCBzdGFjayBkb2VzIG5vdA0KPiA+Pj4+ICAgICAgY29udGFpbiBhbnkgZmll bGQgd2hpY2ggZXhwbGljaXRseSBpZGVudGlmaWVzIHRoZSBuZXR3b3JrIGxheWVyDQo+ID4+Pj4g ICAgICBwcm90b2NvbC4gIFRoaXMgbWVhbnMgdGhhdCB0aGUgaWRlbnRpdHkgb2YgdGhlIG5ldHdv cmsgbGF5ZXINCj4gcHJvdG9jb2wNCj4gPj4+PiAgICAgIG11c3QgYmUgaW5mZXJhYmxlIGZyb20g dGhlIHZhbHVlIG9mIHRoZSBsYWJlbCB3aGljaCBpcyBwb3BwZWQgZnJvbQ0KPiA+Pj4+ICAgICAg dGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3NpYmx5IGFsb25nIHdpdGggdGhlIGNvbnRlbnRz IG9mIHRoZQ0KPiA+Pj4+ICAgICAgbmV0d29yayBsYXllciBoZWFkZXIgaXRzZWxmLg0KPiA+Pj4+ IDxlbmQgcXVvdGU+DQo+ID4+Pj4NCj4gPj4+PiBNeSAyYywNCj4gPj4+PiBTYXNoYQ0KPiA+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBGcm9tOiBt cGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBYdXhpYW9odQ0KPiA+Pj4+ IDx4dXhpYW9odUBodWF3ZWkuY29tPg0KPiA+Pj4+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNiwg MjAxNSA1OjA1IEFNDQo+ID4+Pj4gVG86IGh1dWJhdHdvcmtAZ21haWwuY29tOyBzZmNAaWV0Zi5v cmc7IG1wbHNAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW21wbHNdIEhvdyB0byBpbmRp Y2F0ZSB0aGUgcHJlc2VuY2Ugb2YgTlNIIGluIGFuIE1QTFMNCj4gcGFja2V0Pw0KPiA+Pj4+DQo+ ID4+Pj4gSGkgSHV1YiwNCj4gPj4+Pg0KPiA+Pj4+IFRoZSBhbHRlciBsYWJlbCBpdHNlbGYgY291 bGRuoa90IG1ha2UgdGhlIHJlY2VpdmluZyBMU1IgdG8gZGV0ZXJtaW5lDQo+ID4+Pj4gdGhlIE1Q TFMgcGF5bG9hZCB0eXBlIGJ5IGV4YW1pbmluZyB0aGUgTVBMUyBwYXlsb2FkLg0KPiA+Pj4+DQo+ ID4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+IFhpYW9odQ0KPiA+Pj4+DQo+ID4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+IEZyb206IEh1dWIgdmFuIEhlbHZvb3J0IFtt YWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb21dDQo+ID4+Pj4+IFNlbnQ6IEZyaWRheSwgSmFudWFy eSAyMywgMjAxNSA2OjI4IFBNDQo+ID4+Pj4+IFRvOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnOyBt cGxzQGlldGYub3JnDQo+ID4+Pj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gSG93IHRvIGluZGljYXRl IHRoZSBwcmVzZW5jZSBvZiBOU0ggaW4gYW4gTVBMUw0KPiBwYWNrZXQ/DQo+ID4+Pj4+DQo+ID4+ Pj4+IFh1eGlhb2h1IMT6usOjoQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBQbGVhc2UgY29ycmVjdCBtZSBp ZiBJIGFtIHdyb25nOg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJdCBoYXMgYWx3YXlzIGJlZW4gbXkgdW5k ZXJzdGFuZGluZyB0aGF0IHRoZSBNUExTIGhlYWRlci9sYWJlbCB3YXMNCj4gPj4+Pj4gaW5kZXBl bmRlbnQgb2YgdGhlIHByb3RvY29sL3BheWxvYWQuDQo+ID4+Pj4+IFNvIG5vIGluZGljYXRpb24g b2YgdGhlIGFjdHVhbCBwYXlsb2FkIGNvbnRlbnQgd2FzIG5lY2Vzc2FyeS4NCj4gPj4+Pj4NCj4g Pj4+Pj4gSU1ITyB5b3UgY291bGQgdXNlIHRoZSBhbGVydCBsYWJlbCAxIHRvIGluZGljYXRlIHRv IHRoZSBMU1IgdGhhdA0KPiA+Pj4+PiBpdCBoYXMgdG8gZnVydGhlciBleGFtaW5lIHRoZSBjb250 ZW50IG9mIGEgcGFja2V0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBSZWdhcmRzLCBIdXViLg0KPiA+Pj4+ Pg0KPiA+Pj4+PiA9PT09PT09PQ0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gSXQgc2FpZCBpbiAoaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtMDQpOg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+ICAgICAgIFRoZSBzZXJ2aWNlIGhlYWRlciBpcyBpbmRlcGVuZGVudCBvZiB0aGUg ZW5jYXBzdWxhdGlvbiB1c2VkDQo+IGFuZCBpcw0KPiA+Pj4+Pj4gICAgICAgZW5jYXBzdWxhdGVk IGluIGV4aXN0aW5nIHRyYW5zcG9ydHMuICBUaGUgcHJlc2VuY2Ugb2YgTlNIIGlzDQo+ID4+Pj4+ PiAgICAgICBpbmRpY2F0ZWQgdmlhIHByb3RvY29sIHR5cGUgb3Igb3RoZXIgaW5kaWNhdG9yIGlu IHRoZSBvdXRlcg0KPiA+Pj4+Pj4gICAgICAgZW5jYXBzdWxhdGlvbi4NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBJbiB0aGUgY2FzZSB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBpcyBhbiBNUExT IExTUCwgaG93IHRvDQo+ID4+Pj4+PiBpbmRpY2F0ZSB0aGUNCj4gPj4+Pj4gcHJlc2VuY2Ugb2Yg TlNIIHNpbmNlIHRoZSBNUExTIGVuY2Fwc3VsYXRpb24gaGFzIG5vIGV4cGxpY2l0DQo+ID4+Pj4+ IHByb3RvY29sIGlkZW50aWZpZXIgZmllbGQgdG8gaW5kaWNhdGUgdGhlIHByb3RvY29sIHR5cGUg b2YgdGhlIE1QTFMNCj4gcGF5bG9hZD8NCj4gPj4+Pj4gU2hvdWxkIHdlIG1ha2UgZWFjaCBTRkYg dG8gYWxsb2NhdGUgYSB1bmlxdWUgbGFiZWwgZm9yIGluZGljYXRpbmcNCj4gPj4+Pj4gdGhlIHBy ZXNlbmNlIG9mIE5TSD8gT3Igc2hvdWxkIHdlIHVzZSB0aGUgY29udHJvbCB3b3JkIHRvIGluZGlj YXRlDQo+ID4+Pj4+IGl0PyBPciBzaG91bGQgd2UgcmVjb25zaWRlciB0aGUgcG9zc2liaWxpdHkg b2YgYWRkaW5nIGFuIGV4cGxpY2l0DQo+ID4+Pj4+IHByb3RvY29sIGlkZW50aWZpZXIgZmllbGQg dG8gdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiBzbyBhcyB0byBzb2x2ZQ0KPiA+Pj4+PiBzdWNoIGtp bmQgb2YgaXNzdWVzDQo+ID4+Pj4gb25jZSBhbmQgZm9yIGFsbD8NCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4+DQo+ID4+Pj4+DQo+ID4+ Pj4+DQo+ID4+Pj4+IC0tDQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4NCj4gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+Pj4+PiAq KioqDQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOsvs3P 8cbky/vDv9K7uPbIy9K7DQo+INH5DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+IG1w bHNAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4gbXBsc0BpZXRmLm9yZw0KPiA+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pg0K From nobody Tue Jan 27 21:48:54 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06991A0021; Tue, 27 Jan 2015 21:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 769qS7dtsIlr; Tue, 27 Jan 2015 21:48:50 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019771A001B; Tue, 27 Jan 2015 21:48:49 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 96E4418029FB; Wed, 28 Jan 2015 06:48:44 +0100 (CET) Message-ID: <54C87836.7020800@pi.nu> Date: Wed, 28 Jan 2015 13:48:38 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "teas-chairs@ietf.org" , draft-ietf-mpls-te-express-path@tools.ietf.org, TEAS WG Subject: [mpls] future for draft-ietf-mpls-te-express-path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 05:48:52 -0000 Working Groups, The MPLS working group has an informal expired draft - draft-ietf-mpls- te-express-path. When working drafts expire the wg chair check why this is so and take the actions needed. In this case the result was - the authors are interested to revive the document; since - the query gave the result that at least some find this informational document useful; however - it seems that after the re-tuning of the rtg area this document no longer belongs in the mpls working but in teas. The teas chairs need to decide what to do with the document, but if you belong to those who think it is useful it would be good if you said so on the list(s). /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jan 27 22:02:02 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644D51A0025 for ; Tue, 27 Jan 2015 22:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.161 X-Spam-Level: ** X-Spam-Status: No, score=2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, MIME_CHARSET_FARAWAY=2.45, MISSING_HEADERS=1.021, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIRbvrcIb7ga for ; Tue, 27 Jan 2015 22:01:58 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23BEF1A0024 for ; Tue, 27 Jan 2015 22:01:57 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 640DD18029FB; Wed, 28 Jan 2015 07:01:54 +0100 (CET) Message-ID: <54C87B4E.5070500@pi.nu> Date: Wed, 28 Jan 2015 14:01:50 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08302599@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08302599@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" Subject: [mpls] Advice on draft-etf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 06:02:01 -0000 Folks, This mail to Alia (as responsible AD), Adrian (with experience from progressing a lot of documents) and the mpls wg co-chairs. I became Document Shepherd rather late in the process. Ross did the "repeated wglc" on this draft on version -07, the document was updated after wglc as version -08. After that there has been discussions on different parts of the document and it has been updated twice. And a third version (-11) is in the pipe. I've not seen version -11 yet, but among the authors there are talk about "brand new issues". My concerns are that we are introducing to big changes without keeping the working group in the loop. Can you help evaluate if we need to take the document through a new wglc, or if we are good to go? /Loa On 2015-01-28 09:14, Xuxiaohu wrote: > Hi David, > > The text looks good to me. Thanks for your excellent work. > > Best regards, > Xiaohu > >> -----Original Message----- >> From: Black, David [mailto:david.black@emc.com] >> Sent: Tuesday, January 27, 2015 7:51 PM >> To: Xuxiaohu >> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; adrian@olddog.co.uk; >> Black, David >> Subject: MPLS/UDP: Section 3.1 item 3 - rewrite >> >> Here's my initial attempt to clarify Section 3.1 item 3 wrt Eric Rosen's concern >> that the source IPv6 address is the context identifier for upstream-assigned >> context labels for multicast traffic. I found a way to do this without talking >> about "point" or "multipoint" characteristics of tunnel ingress/egress. >> >> OLD >> e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for >> each MPLS-in-UDP tunnel that uses UDP zero-checksum mode >> regardless of receiver in order to strengthen the receiver's >> check of the IPv6 source address. When this is not possible, it >> is RECOMMENDED to use each source IPv6 address for as few UDP >> zero-checksum mode MPLS-in-UDP tunnels as is feasible. >> NEW >> e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for >> each MPLS-in-UDP tunnel that uses UDP zero-checksum mode >> regardless of receiver in order to strengthen the receiver's >> check of the IPv6 source address (i.e., the same IPv6 source >> address SHOULD NOT be used with more than one IPv6 destination >> address, independent of whether that destination address is a >> unicast or multicast address). When this is not possible, it >> is RECOMMENDED to use each source IPv6 address for as few UDP >> zero-checksum mode MPLS-in-UDP tunnels (i.e., with as few >> destination IPv6 addresses) as is feasible. >> >> How does that look? >> >> Thanks, >> --David >> >>> -----Original Message----- >>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>> Sent: Monday, January 26, 2015 11:01 AM >>> To: Black, David >>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>> adrian@olddog.co.uk >>> Subject: Re: [mpls] ID Tracker State Update Notice: >>> >>> >>> Hi David, >>> >>> After a careful consideration, I think it should be OK for an >>> encapsulator to use different tunnel source addresses for different >>> UDP tunnels if these tunnels are manually configured. Sorry for that >>> confusion. In addition, since item e has a sentence "When this is not >>> possible,...", I believe the current text is OK for the P2P UDP tunnel >>> case. It seems that you only need to add some text about the P2MP UDP >> tunnel, just as what you have mentioned before. >>> >>> Best regards, >>> Xiaohu >>> >>> ________________________________________ >>> ·¢¼þÈË: Black, David [david.black@emc.com] >>> ·¢ËÍʱ¼ä: 2015Äê1ÔÂ26ÈÕ 18:40 >>> ÊÕ¼þÈË: Xuxiaohu >>> ³­ËÍ: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>> adrian@olddog.co.uk; Black, David >>> Ö÷Ìâ: RE: [mpls] ID Tracker State Update Notice: >>> >>> >>> First, this is a brand new concern that has not been raised previously >>> - it's definitely different from Eric Rosen's concern, which I >>> understand and will write clarifying text for. >>> >>> Second, a VPN ought to be seriously concerned with misdelivery >>> prevention, and there's text in the security considerations section on >>> this topic. Item e in section 3.1 is one of the important things that >>> this draft does towards misdelivery prevention when UDP zero checksums are >> used with IPv6. >>> >>> My starting point would be - if L3VPNs have a problem with using a >>> different >>> IPv6 address as the source of each tunnel, then that's one more reason >>> for L3VPNs to use UDP checksums with IPv6. >>> >>> I'll defer to L3VPN experts on how L3VPN address signaling currently >>> works and the impacts of additional IPv6 addresses on that. I'm not >>> the right person to write L3VPN-specific text (on this or any other topic). >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>>> Sent: Monday, January 26, 2015 4:42 AM >>>> To: Black, David >>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>> adrian@olddog.co.uk >>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>> >>>> >>>> Hi David, >>>> >>>> Just take the BGP/MPLS IP VPN with RR enabled as an example, if it >>>> requires the tunnel encapsulator (i.e., ingress PE) to use different >>>> source IP addresses for different tunnels, should ingress PEs notify >>>> the address to be used as the tunnel source address to each egress >>>> PE. Otherwise, how could egress PEs verify that the packets are received >> from valid ingress PEs? >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>>> -----Original Message----- >>>>> From: Black, David [mailto:david.black@emc.com] >>>>> Sent: Saturday, January 24, 2015 3:15 AM >>>>> To: Xuxiaohu >>>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>> adrian@olddog.co.uk; >>>>> Black, David >>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>> >>>>> >>>>> Xiaohu, >>>>> >>>>> I'm missing something here. >>>>> >>>>> Eric's concern stems from the requirement that when >>>>> upstream-assigned >>> labels >>>>> are in use, the source IP address identifies the label context, >>>>> and hence >>>> that >>>>> source IP address has to be common across all traffic to a destination. >>>> Eric was >>>>> concerned that Section 3.1 item e might conflict with that requirement. >>>>> >>>>> The clarifying text will indicate that there is no problem here; >>>>> when the destination IP address is a multicast address, the sender >>>>> sends one >>> packet, >>>> the >>>>> receivers each get a copy and that 1:n multicast fan-out is a >>>>> single >>>> "tunnel" wrt >>>>> Section 3.1 item e. >>>>> Every packet delivered to every receiver in that tunnel uses the >>>>> same >>> source >>>> IP >>>>> address, so there's a single label context. >>>>> >>>>> I do not understand the RPF and signaling concerns below. >>>>> >>>>> Thanks, >>>>> --David >>>>> >>>>>> -----Original Message----- >>>>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>>>>> Sent: Thursday, January 22, 2015 8:40 PM >>>>>> To: Black, David >>>>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>>>> adrian@olddog.co.uk >>>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>>> >>>>>> >>>>>> Hi David, >>>>>> >>>>>> I'm looking forwarding to seeing your updated text. By the way, >>>>>> I hope you could take into account potential concerns as follows: >>>>>> >>>>>> 1) will it make the RPF check performed by tunnel decapsulators >>>>>> (e.g., to determine the upstream PE of the received multicast >>>>>> packet in the multicast VPN context) difficult when requiring a >>>>>> tunnel encapsulator to use different tunnel source addresses for >>>>>> different tunnels; >>>>>> 2) does it require the encapsulator of a particular MPLS-in-UDP >>>>>> tunnel to notify the decapsulator(s) of its possible addresses >>>>>> to be used as the source address of that tunnel. >>>>>> >>>>>> Best regards, >>>>>> Xiaohu >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Black, David [mailto:david.black@emc.com] >>>>>>> Sent: Thursday, January 22, 2015 11:15 PM >>>>>>> To: Xuxiaohu >>>>>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>>>> adrian@olddog.co.uk; >>>>>>> Black, David >>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>>>> >>>>>>> >>>>>>> Xiaohu, >>>>>>> >>>>>>>> Since the requirement item e would introduce additional and >>>>>>>> unexpected complexities and difficulties for the deployment, >>>>>>>> I suggest that it'd better to remove that item. >>>>>>> >>>>>>> I strongly disagree. That requirement is important to the >>>>>>> overall design >>>>>> goal of >>>>>>> requiring an offsetting corruption to cause misdelivery (i.e., >>>>>>> a single >>>>>> corruption >>>>>>> should usually not result in misdelivery). >>>>>>> >>>>>>> There is not an actual problem here - item e is correct wrt >>>>>>> Eric's concern, >>>>>> but not >>>>>>> explained clearly. I can write the sentence or two that will be >>>> needed to >>>>>>> clarify >>>>>>> how requirement e applies to P2MP UDP tunnels (i.e., >>>>>>> destination IP address >>>>>> is a >>>>>>> multicast address) *after* the upstream vs. downstream label >>>>>>> assignment discussion is sorted out. >>>>>>> >>>>>>>> By the way, I feel it would be better to uniformly replace >>>>>>>> "MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP >>>>>>>> sender" by "tunnel decapsulator" and "tunnel encapsulator" >>>>>>>> respectively in the whole >>>>>>> doc. >>>>>>> >>>>>>> I'll defer to others on terminology, although I find the >>>>>>> MPLS-in-UDP >>>>>> terminology >>>>>>> clearer because it indicates exactly which tunnel is involved. >>>>>>> >>>>>>> Thanks, >>>>>>> --David >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>>>>>>> Sent: Wednesday, January 21, 2015 10:22 PM >>>>>>>> To: Black, David >>>>>>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>>>>>> adrian@olddog.co.uk >>>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>>>>> >>>>>>>> >>>>>>>> Hi David and all, >>>>>>>> >>>>>>>> Since the requirement item e would introduce additional and >>>>>>>> unexpected complexities and difficulties for the deployment, >>>>>>>> I suggest that it'd better to remove that item. >>>>>>>> >>>>>>>> By the way, I feel it would be better to uniformly replace >>>>>>>> "MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP >>>>>>>> sender" by "tunnel decapsulator" and "tunnel encapsulator" >>>>>>>> respectively in the whole >>>>>>> doc. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Xiaohu >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Black, David [mailto:david.black@emc.com] >>>>>>>>> Sent: Thursday, January 22, 2015 3:17 AM >>>>>>>>> To: Eric C Rosen; Alia Atlas; Xuxiaohu >>>>>>>>> Cc: Loa Andersson; ; >>>>>>>>> mpls-chairs@tools.ietf.org; >>>>>>>>> draft-ietf-mpls-in-udp@tools.ietf.org; >>>>>>>>> IJsbrand Wijnands; Black, David >>>>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>>>>>> >>>>>>>>> >>>>>>>>> Eric, >>>>>>>>> >>>>>>>>> On the further issue ... >>>>>>>>> >>>>>>>>>> There is one further issue for you to consider. >>>>>>>>>> >>>>>>>>>> When an MPLS packet with an upstream-assigned label is >>>>>>>>>> received through a particular tunnel, the "context" in >>>>>>>>>> which the label is interpreted is determined by the IP >>>>>>>>>> address of the >>>> root of >>>>> the tunnel. >>>>>>>>>> (See section 7 of RFC5331.) For a UDP tunnel, this >>>>>>>>>> would mean that the label space is identified by the Source IP >> address. >>>>>>>>>> So if a particular router is using MPLS-in-UDP to send >>>>>>>>>> MPLS packets with upstream-assigned labels, it's really >>>>>>>>>> important for it to use the same IP >>>>>>>> source >>>>>>>>> address in all >>>>>>>>>> MPLS-in-UDP packets that have the same destination address. >> I >>>> can't >>>>>>>>>> quite tell whether this is compatible with item e. in >>>>>>>>>> section >>>>>>>>>> 3.1 of the draft. >>>>>>>>> >>>>>>>>> That is compatible with item e., but the draft doesn't say >>>>>>>>> much about P2MP >>>>>>>> UDP >>>>>>>>> tunnels. In particular, I would view that source IP >>>>>>>>> address as the source >>>>>>>> IP >>>>>>>>> address for a (one) P2MP tunnel, and it's probably a good >>>>>>>>> idea to add some >>>>>>>> text >>>>>>>>> on P2MP UDP tunnels to make this clear. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> --David >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Eric C Rosen [mailto:erosen@juniper.net] >>>>>>>>>> Sent: Wednesday, January 21, 2015 11:26 AM >>>>>>>>>> To: Alia Atlas; Xuxiaohu >>>>>>>>>> Cc: erosen@juniper.net; Black, David; Loa Andersson; >>>>>>>>>> ; mpls-chairs@tools.ietf.org; >>>>>>>>>> draft-ietf-mpls-in- udp@tools.ietf.org; IJsbrand >>>>>>>>>> Wijnands >>>>>>>>>> Subject: Re: [mpls] ID Tracker State Update Notice: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Folks, >>>>>>>>>> >>>>>>>>>> I'll be happy to throw in my much belated two cents. >>>>>>>>>> >>>>>>>>>> If I understand correctly, the issue at hand is how one >>>>>>>>>> determines, when receiving an MPLS-in-UDP packet, >>>>>>>>>> whether the top MPLS label is upstream-assigned or >> downstream-assigned. >>>>>>>>>> >>>>>>>>>> Draft-ietf-mpls-in-udp-10 has the following text: >>>>>>>>>> >>>>>>>>>> As for whether the top label in the MPLS label stack is >>>>>>>>>> downstream-assigned or upstream-assigned, it SHOULD >>>>>>>>>> be >>>>>>> determined >>>>>>>>>> based on the tunnel destination IP address. That is >>>>>>>>>> to say, if >>>>>> the >>>>>>>>>> destination IP address is a multicast address, the >>>>>>>>>> top label >>>>>> SHOULD >>>>>>>>>> be upstream-assigned, otherwise if the destination >>>>>>>>>> IP >>> address >>>> is a >>>>>>>>>> unicast address, it SHOULD be downstream-assigned. >>>>>>>>>> >>>>>>>>>> I believe this text is incorrect, as it is inconsistent >>>>>>>>>> with RFCs >>>>>>>>>> 5332 and 5331, which are the RFCs that introduce the >>>>>>>>>> notion of "upstream-assigned labels". >>>>>>>>>> >>>>>>>>>> Of particular relevance is Section 3 of RFC 5332, which >>>>>>>>>> discusses how one determines, when an MPLS packet is >>>>>>>>>> being sent through a tunnel, whether the top label of >>>>>>>>>> the encapsulated packet is upstream or >>>>>>>> downstream. >>>>>>>>>> >>>>>>>>>> To make a long story short, basically what that section >>>>>>>>>> says is that the tunnel must be known a priori to have >>>>>>>>>> one of the following three >>>>>>>>> properties: >>>>>>>>>> >>>>>>>>>> 1. The top label of all encapsulated packets is >>>>>>>>>> downstream- >>>> assigned. >>>>>>>>>> >>>>>>>>>> 2. The top label of all encapsulated packets is >>>>>>>>>> upstream- >>> assigned. >>>>>>>>>> >>>>>>>>>> 3. The top label of some encapsulated packets is >>>>>>>>>> downstream-assigned, but the top label of some >>>>>>>>>> encapsulated packets is >>>>>>> upstream-assigned. >>>>>>>>>> >>>>>>>>>> How it is known which property the tunnel has is out of >>>>>>>>>> scope (i.e., it depends on the higher layer). >>>>>>>>>> >>>>>>>>>> Only tunnels with the third property need to contain a >>>>>>>>>> codepoint that specifies whether the label is >>>>>>>>>> upstream-assigned or >>>>>>> downstream-assigned. >>>>>>>>>> >>>>>>>>>> So what does all this mean for the mpls-in-udp encapsulation? >>>>>>>>>> I would suggest that you say the following: >>>>>>>>>> >>>>>>>>>> - Have IANA assign a single UDP port number for MPLS-in-UDP. >>>>>>>>>> >>>>>>>>>> - In the absence of any other knowledge, a UDP packet >>>>>>>>>> with the MPLS-in-UDP port number in destination port >>>>>>>>>> field is assumed to be carrying an MPLS packet whose top >>>>>>>>>> label is >>>>> downstream-assigned. >>>>>>>>>> >>>>>>>>>> - Higher layers may negotiate the use of particular UDP >>>>>>>>>> tunnels to carry MPLS packets whose top labels are >>>>>>>>>> upstream-assigned. The procedures for such negotiation >>>>>>>>>> are out of scope of the current document. By a >>>>>>>>>> "particluar UDP tunnel", I mean a UDP tunnel with a >>>>>>>>>> particular >>>>>>>>> destination >>>>>>>>>> port> triple. The destination port may be the standard >>>>>>>>>> (IANA-assigned) port number for MPLS-in-UDP, but it may >>>>>>>>>> also be any other port number that is negotiated by the higher >> layer. >>>>>>>>>> >>>>>>>>>> - For a particular UDP tunnel (i.e., a particular >>>>>>>>>> >>>>>>>>>> triple), all the encapsulated MPLS packets must have the >>>>>>>>>> same type of label at the top >>>>>> of >>>>>>> the stack. >>>>>>>>>> >>>>>>>>>> - Remove any suggestion that the type of the label can >>>>>>>>>> be inferred from the type of the IP destination address. >>>>>>>>>> >>>>>>>>>> I think this will make the draft compatible with RFCs >>>>>>>>>> 5332 and 5331, and it does not require IANA to allocate >>>>>>>>>> a second port >>>> number. >>>>>>>>>> >>>>>>>>>> Note, by the way, that if we are going to allow the >>>>>>>>>> higher layers to negotiate the destination port number, >>>>>>>>>> we should probably caution implementers not to hard code >>>>>>>>>> (or hard wire) a particular port >>>>>>> number. >>>>>>>>>> >>>>>>>>>> There is one further issue for you to consider. >>>>>>>>>> >>>>>>>>>> When an MPLS packet with an upstream-assigned label is >>>>>>>>>> received through a particular tunnel, the "context" in >>>>>>>>>> which the label is interpreted is determined by the IP >>>>>>>>>> address of the >>>> root of >>>>> the tunnel. >>>>>>>>>> (See section 7 of RFC5331.) For a UDP tunnel, this >>>>>>>>>> would mean that the label space is identified by the Source IP >> address. >>>>>>>>>> So if a particular router is using MPLS-in-UDP to send >>>>>>>>>> MPLS packets with upstream-assigned labels, it's really >>>>>>>>>> important for it to use the same IP >>>>>>>> source >>>>>>>>> address in all >>>>>>>>>> MPLS-in-UDP packets that have the same destination address. >> I >>>> can't >>>>>>>>>> quite tell whether this is compatible with item e. in >>>>>>>>>> section >>>>>>>>>> 3.1 of the draft. >>>>>>>>>> >>>>>>>>>> Eric >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jan 28 03:06:17 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365801A1A31; Wed, 28 Jan 2015 03:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfbriHGV6ouX; Wed, 28 Jan 2015 03:06:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5119D1A1A2D; Wed, 28 Jan 2015 03:06:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BON01810; Wed, 28 Jan 2015 11:06:08 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 11:06:07 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 28 Jan 2015 19:06:02 +0800 From: Lizhenbin To: Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AdA6Iy10hnzSmHMYSNeVsID5YDgzbAABb2SAADAnQIE= Date: Wed, 28 Jan 2015 11:06:01 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> In-Reply-To: <20150127200101.GA21477@hannes-mba.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNl?= =?gb2312?b?Z21lbnQgUm91dGluZyg3KTogTVRVIENoYWxsZW5nZXMgZm9yIFNS?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 11:06:14 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpJIGhhdmUgZXZlciB0aG91Z2h0IGFib3V0IHRoZSBwb3NzaWJsZSBzb2x1 dGlvbnMgYmFzZWQgb24gdGhlIGZsb29kZWQgTVRVIGluZm9ybWF0aW9uIHRocm91Z2ggSUdQLg0K DQpUaGVyZSBhcmUgc3RpbGwgdHdvIHBvc3NpYmxlIGlzc3VlczoNCg0KMS4gSW50ZXItYXJlYSBm b3IgU1ItVEUgcGF0aDogTWF5YmUgd2Ugbm90IG9ubHkgaW50cm9kdWNlIHRoZSBJR1AgZXh0ZW5z aW9ucywgYnV0IGFsc28gUENFUCBleHRlbnNpb25zLg0KDQoyLiBGb3IgU1ItQkUgcGF0aCwgaXQg aGFzIHRvIGludHJvZHVjZSB0aGUgVEUtbGlrZSBlbmQtdG8tZW5kIHBhdGggY2FsY3VsYXRpb24g YXQgdGhlIGluZ3Jlc3Mgbm9kZS4NCg0KDQoNCk15IGNvbmNlcm4gaXMgbm90IGp1c3QgZm9yIHRo ZSBwb3NzaWJsZSBzb2x1dGlvbnMsIGJ1dCB0byBleHBsb3JlIHRoZSBlc3NlbmNlIG9mIFNSIHdo aWNoIG1heSBoYXMgbXVjaA0KDQplZmZlY3Qgb24gaXRzIGRlcGxveW1lbnQgY29tcGFyaW5nIHdp dGggdGhlIGV4aXN0aW5nIE1QTFMgcHJvdG9jb2wuIEl0IHdpbGwgYmUgZXhwbGFpbmVkIGluDQoN CnRoZSBuZXh0IGNvbW1lbnRzLg0KDQoNCg0KDQoNClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoN Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjL OiBIYW5uZXMgR3JlZGxlciBbaGFubmVzQGp1bmlwZXIubmV0XQ0Kt6LLzcqxvOQ6IDIwMTXE6jHU wjI4yNUgNDowMQ0KytW8/sjLOiBMaXpoZW5iaW4NCrOty806IHNwcmluZ0BpZXRmLm9yZzsgbXBs c0BpZXRmLm9yZzsgdGVhc0BpZXRmLm9yZw0K1vfM4jogUmU6IFtzcHJpbmddIE5ldyBDb21tZW50 cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1UVSBDaGFsbGVuZ2VzIGZvciBTUg0KDQpvbmx5IGNh biBzcGVhayBmb3IgSVMtSVMgLQ0KYWZhaWsgdGhlIFRyaWxsIGV4dGVuc2lvbnMgZ2F2ZSB1cyBh IHdheSBvZiBzaWduYWxpbmcgdGhlIE1UVSBvZiBhIGxpbmsgLi4uDQoNCnNvIHdoYXQgd2UgY291 bGQgZG8gaXMgdG8gYWR2ZXJ0aXNlIHRoZSBNVFUgZm9yIGVhY2ggYWRqYWNlbmN5IGFuZCBpbXBs ZW1lbnQNCnByb3BlciBmcmFnbWVudGF0aW9uIGF0IHRoZSBURSB0dW5uZWwgaW5ncmVzcy4NCg0K L2hhbm5lcw0KDQpPbiBUdWUsIEphbiAyNywgMjAxNSBhdCAxMToyNDoyM0FNICswMDAwLCBMaXpo ZW5iaW4gd3JvdGU6DQp8ICAgIEhpIGFsbCBhdXRob3JzIG9mIHNlZ21lbnQgcm91dGluZywNCnwN CnwgICAgVGhpcyBpcyB0aGUgc2V2ZW50aCBjb21tZW5zLiBUaGUgaXNzdWVzIHByb3Bvc2VkIGhl cmUgYXJlIGZvciBib3RoIFNSLVRFDQp8ICAgIHBhdGggYW5kIFNSLUJFIHBhdGguDQp8DQp8DQp8 DQp8ICAgICAgICAgICAgIDEgICAgICAgICAgICAgIDEgICAgICAgICAgIDEgICAgICAgICAgICAx DQp8ICAgICAgUzExLS0tLS0tLS0tLS1TMTItLS0tLS0tLS0tUzEzLS0tLS0tLS0tUzE0LS0tLS0t LS0tUzE1DQp8ICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwg ICAgICAgICAgIHwNCnwgICAgICAxfCAgICAgICAgICAgIDF8ICAgICAgICAgICAxfCAgICAgICAg ICAxfCAgICAgICAgICAxfA0KfCAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAg ICAgICAgICB8ICAgICAgICAgICB8DQp8ICAgICAgUzIxLS0tLS0tLS0tLS1TMjItLS0tLS0tLS0t UzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1DQp8ICAgICAgICAgICAgIDQgICAgICAgICAgICAg IDQgICAgICAgICAgIDQgICAgICAgICAgICA0DQp8DQp8DQp8DQp8ICAgIFN0aWxsIHRha2UgdGhl IHRvcG9sb2d5IGluIHRoZSBjb21tZW50IDYgYXMgdGhlIGV4YW1wbGUuIE5vIG1hdHRlciB0aGUN CnwgICAgbG9vc2UgZXhwbGljaXQgcGF0aCBvcg0KfA0KfCAgICB0aGUgc3RyaWN0IGV4cGxpY2l0 IHBhdGggZm9yIHRoZSBsb29zZSBob3AsIGFzc3VtZSB0aGUgTVRVIG9mIHRoZQ0KfCAgICBpbnRl cmZhY2UgaXMgdGhlIHNhbWUsDQp8DQp8ICAgIHNpbmNlIHRoZSBkZXB0aCBvZiB0aGUgbGFiZWwg c3RhY2tzIGZvciB0aGUgcHJpbWFyeSBwYXRoIGFuZCB0aGUgYmFja3VwDQp8ICAgIHBhdGggYXJl IGRpZmZlcmVudC4NCnwNCnwgICAgVGhlcmUgaXMgdGhlIHJpc2sgdGhhdCB0aGUgZWZmZXRpdmUg cGF5bG9hZCBtYXkgdHJhbnNtaXQgdGhyb3VnaCB0aGUNCnwgICAgcHJpbWFyeSBwYXRoLCBidXQg bWF5IGJlDQp8DQp8ICAgIGZyYWdtZW50ZWQgb3IgZHJvcHBlZCBpbiB0aGUgYmFja3VwIHBhdGgu IEFzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlDQp8ICAgIGxhYmVsIHN0YWNrcyBvZiB0aGUN CnwNCnwgICAgcHJpbWFyeSBwYXRoIGFuZCB0aGUgYmFja3VwIHBhdGggaW5jcmVhc2UsIHRoZSBy aXNrIHdpbGwgaW5jcmVhc2UuDQp8DQp8DQp8DQp8ICAgIEZyb20gdGhlIGNhc2UsIHdlIGNhbiBk ZWR1Y2UgdGhhdCB0aGUgcmlzayBtYXkgZXhpc3RzIGZvciBhbnkgc2NlbmFyaW9zIGluDQp8ICAg IHdoaWNoIHRoZSBzYW1lIHRyYWZmaWMNCnwNCnwgICAgIG1heSBzd2l0Y2ggZnJvbSBvbmUgU1Ig cGF0aCB0byB0aGUgb3RoZXIgU1IgcGF0aC4gVGhlIFNSIHBhdGggaW5jbHVkZXMNCnwgICAgU1It VEUgcGF0aCBzdWNoIGFzIE1QTFMgVEUNCnwNCnwgICAgaG90c3RhbmRieS9yZW9wdGltaXphdGlv biBhbmQgU1ItQkUgcGF0aCBzdWNoIGFzIFRJLUZSUi4NCnwNCnwNCnwNCnwgICAgQmVzaWRlcyBh Ym92ZSBpc3N1ZXMsIExEUC9SU1ZQLVRFIGNhbiBzdXBwb3J0IHRoZSBwYXRoIE1UVSB0byB0cmFj ayB0aGUNCnwgICAgTVRVIGluZm9ybWFpdG9uIGFsb25nIHRoZQ0KfA0KfCAgICBMU1AgdGhyb3Vn aCBzaWduYWxsaW5nLiBUaGVuIHRoZSByZWFzb25hYmxlIE1UVSBpbmZvIHdpbGwgYmUgYWRvcHRl ZCBpbg0KfCAgICB0aGUgaW5ncmVzcyBub2RlLiBGb3IgYm90aA0KfA0KfCAgICAgU1ItVEUgcGF0 aCAoaWYgUENFIGlzIG5vdCB1c2VkKSBhbmQgU1ItQkUgcGF0aCwgc2luY2UgdGhlcmUgaXMgbm8N CnwgICAgc2lnbmFsbGluZyB0byBhZHZlcnRpc2UNCnwNCnwgICAgdGhlIGluZm9ybWF0aW9uLiBI b3cgdG8gaW1wbGVtZW50IHRoZSBmZWF0dXJlPyBPciB0aGVyZSBtYXliZSB0aGUgcmlzaw0KfCAg ICB0aGF0IHRoZSBwYWNrZXQgbWF5IGJlDQp8DQp8ICAgIGRyb3BwZWQgYnkgdGhlIG5vZGVzIGFs b25nIHRoZSBMU1AuDQp8DQp8DQp8DQp8DQp8DQp8DQp8DQp8ICAgIFJlZ2FyZHMsDQp8DQp8ICAg IFJvYmluDQoNCnwgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnwgc3ByaW5nIG1haWxpbmcgbGlzdA0KfCBzcHJpbmdAaWV0Zi5vcmcNCnwgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Hannes,

I have ever thought about the possible solutions = based on the flooded MTU information through IGP.

There are still two possible issues:

1. Inter-area for SR-TE path: Maybe we not only i= ntroduce the IGP extensions, but also PCEP extensions.

2. For SR-BE path, it has to introduce the TE-lik= e end-to-end path calculation at the ingress node.

 

My concern is not just for the possible solutions= , but to explore the essence of SR which may has much

effect on its deployment comparing wit= h the existing MPLS protocol. It will be explained in

the next comments.

 

 

Regards,

Robin

 

 

 



________________________________________
=B7=A2=BC=FE=C8=CB: Hannes Gredler [hannes@juniper.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C228=C8=D5 4:01
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: spring@ietf.org; mpls@ietf.org; teas@ietf.org
=D6=F7=CC=E2: Re: [spring] New Comments on Segment Routing(7): MTU Challeng= es for SR

only can speak for IS-IS -
afaik the Trill extensions gave us a way of signaling the MTU of a link ...=

so what we could do is to advertise the MTU for each adjacency and implemen= t
proper fragmentation at the TE tunnel ingress.

/hannes

On Tue, Jan 27, 2015 at 11:24:23AM +0000, Lizhenbin wrote:
|    Hi all authors of segment routing,
|
|    This is the seventh commens. The issues proposed here a= re for both SR-TE
|    path and SR-BE path.
|
|
|
|             1=             &nb= sp; 1           1 &n= bsp;          1
|      S11-----------S12----------S13---------S14-= --------S15
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      1|       = ;     1|        = ;   1|          1|&n= bsp;         1|
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      S21-----------S22----------S23---------S24-= --------S25
|             4=             &nb= sp; 4           4 &n= bsp;          4
|
|
|
|    Still take the topology in the comment 6 as the example= . No matter the
|    loose explicit path or
|
|    the strict explicit path for the loose hop, assume the = MTU of the
|    interface is the same,
|
|    since the depth of the label stacks for the primary pat= h and the backup
|    path are different.
|
|    There is the risk that the effetive payload may transmi= t through the
|    primary path, but may be
|
|    fragmented or dropped in the backup path. As the differ= ence between the
|    label stacks of the
|
|    primary path and the backup path increase, the risk wil= l increase.
|
|
|
|    From the case, we can deduce that the risk may exists f= or any scenarios in
|    which the same traffic
|
|     may switch from one SR path to the other SR path.= The SR path includes
|    SR-TE path such as MPLS TE
|
|    hotstandby/reoptimization and SR-BE path such as TI-FRR= .
|
|
|
|    Besides above issues, LDP/RSVP-TE can support the path = MTU to track the
|    MTU informaiton along the
|
|    LSP through signalling. Then the reasonable MTU info wi= ll be adopted in
|    the ingress node. For both
|
|     SR-TE path (if PCE is not used) and SR-BE path, s= ince there is no
|    signalling to advertise
|
|    the information. How to implement the feature? Or there= maybe the risk
|    that the packet may be
|
|    dropped by the nodes along the LSP.
|
|
|
|
|
|
|
|    Regards,
|
|    Robin

| _______________________________________________
| spring mailing list
| spring@ietf.org
| https://www.ietf.org/mailman/listinfo/spring

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845nkgeml506mbxchi_-- From nobody Wed Jan 28 03:26:25 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C481A9165; Tue, 27 Jan 2015 15:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MuwCkh9hyvD; Tue, 27 Jan 2015 15:40:25 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1461A914D; Tue, 27 Jan 2015 15:40:25 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t0RNeP98020948; Tue, 27 Jan 2015 23:40:25 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 5F6C7C2054B; Tue, 27 Jan 2015 23:40:25 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150121232241.12288.2566.idtracker@ietfa.amsl.com> References: <20150121232241.12288.2566.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #805002 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 27 Jan 2015 23:40:25 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 28 Jan 2015 03:26:23 -0800 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-oam-ipv6-rao.all@tools.ietf.org, iesg@ietf.org Subject: [mpls] [IANA #805002] Last Call: (IPv6 Router Alert Option for MPLS OAM) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 23:40:28 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-oam-ipv6-rao-02. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the IPv6 Router Alert Option Values registry located at: http://www.iana.org/assignments/ipv6-routeralert-values/ a new option value is to be registered as follows: Value: [ TBD-at-registration ] Description: MPLS OAM Reference: [ RFC-to-be ] IANA understands that this is the only action that needs to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Wed Jan 21 23:23:08 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'IPv6 Router Alert Option for MPLS OAM' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-02-04. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > RFC 4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the > Router Alert Option MUST be set in the IP header of the MPLS Echo > Request messages, and may conditionally be set in the IP header of > the MPLS Echo Reply messages depending on the Reply Mode used. While > a generic "Router shall examine packet" Option Value is used for the > IPv4 Router Alert Option (RAO), there is no generic Router Alert > Option Value defined for IPv6 that can be used. This document > allocates a new generic IPv6 Router Alert Option Value that can be > used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo > Reply messages for MPLS in IPv6 environments. Consequently, it > updates RFC 4379. > > The initial motivation to request an IPv6 Router Alert Option (RAO) > code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. > However, this code point is applicable to all MPLS OAM and not > limited to MPLS LSP Ping/Traceroute. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > From nobody Wed Jan 28 03:31:21 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3D91A1AC8; Wed, 28 Jan 2015 03:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuF5q09_p7rZ; Wed, 28 Jan 2015 03:31:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C4B1A1A97; Wed, 28 Jan 2015 03:30:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRV25484; Wed, 28 Jan 2015 11:30:45 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 11:30:44 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 28 Jan 2015 19:30:36 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR Thread-Index: AdA66yE5259u7U/sTZCfhnmR4h4dmw== Date: Wed, 28 Jan 2015 11:30:35 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [mpls] New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 11:31:18 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgZWln aHRoIGNvbW1lbnRzLiBUaGUgaXNzdWVzIHByb3Bvc2VkIGhlcmUgYXBwbHkgdG8gYm90aCBTUi1U RSBwYXRoIGFuZCBTUi1CRSBwYXRoLg0KDQoNCg0KRm9yIExEUCBhbmQgUlNWUC1URSwgdGhlcmUg aXMgdGhlIGxvb3AgcHJldmVudGlvbiBtZWNoYW5pc20gd2hlbiBzZXR1cCBMU1AuIEZvciB0aGUg U1IsIHRoZSBTUiBwYXRoIGlzIGFsd2F5cw0KDQpzZXR1cCBhdCB0aGUgaW5ncmVzcyBub2RlLiBJ dCBpcyBkaWZmaWN1bHQgdG8gZGV0ZWN0IHRoZSBwb3NzaWJsZSBsb29wIGluIHRoZSBuZXR3b3Jr LiBGb3IgZXhhbXBsZSwgaWYgdGhlDQoNCm1pY3JvbG9vcCBvZiByb3V0ZSBoYXBwZW5zLCB0aGUg bG9vcCBwcmV2ZW50aW9uIG1lY2hhbmlzbSB3aWxsIHByZXZlbnQgTERQIHRvIHNldHVwIExTUC4g QnV0IGZvciB0aGUgc2VnbWVudA0KDQpyb3V0aW5nLCBvbmNlIHRoZSBpbmdyZXNzIG5vZGUgZG93 bmxvYWRzIHRoZSBmb3J3YXJkaW5nIGVudHJ5IGFuZCB0aGUgdHJhZmZpYyB3aWxsIGV4cGVyaWVu Y2UgdGhlIG1pY3JvbG9vcC4NCg0KSG93IGNhbiBTUiB0byBjb3BlIHdpdGggdGhlIGlzc3VlIG9y IGp1c3QgbGVhdmUgaXQgYXMgdGhlIHRyYWRpdGlvbmFsIHJvdXRpbmc/DQoNCg0KDQpGb3IgTERQ IGFuZCBSU1ZQLVRFLCB0aGVyZSBpcyB0aGUgZXJyb3Igbm90aWZpY2F0aW9uIG1lY2hhbmlzbSBi YXNlZCBvbiB0aGUgTERQIG5vdGlmaWNhdGlvbiBtZXNzYWdlIG9yIHRoZQ0KDQpSU1ZQLVRFIFBh dGhFcnIvUmVzdiBtZXNzYWdlcy4gQmFzZWQgb24gdGhlIGVycm9yIG5vdGlmaWNhdGlvbiwgdGhl IG5vZGVzIGFsb25nIHRoZSBMU1AgY2FuIHRha2UgcG9zc2libGUNCg0KYWN0aW9ucyBhZ2FpbnN0 IHRoZSBwb3NzaWJsZSBlcnJvcnMuIEJ1dCBmb3IgU1IsIHRoZXJlIGlzIG5vIHN1Y2ggaW5mb3Jt YXRpb24gY29tbXVuaWNhdGVkIGFtb25nIHRoZSBub2Rlcw0KDQphbG9uZyB0aGUgU1IgUGF0aC4g VGhlIHJlc3VsdCB3aWxsIGJlIHRoYXQgb25jZSB0aGUgcGFja2V0IGlzIGZvcndhcmRlZCBieSB0 aGUgaW5ncmVzcyBub2RlLCB0aGV5IG1heQ0KDQpleHBlcmllbmNlIHRoZSBwb3NzaWJsZSBlcnJv cnMgd2hpY2ggbWF5IGJlIHByZXZlbnRlZCBieSB0aGUgbmVnb3RpYXRpb24gaW4gdGhlIGNvbnRy b2wgcGxhbmUuDQoNCg0KDQpGcm9tIHRoZSBwcmV2aW91cyBjb21tZW50cywgd2UgY2FuIHNlZSB0 aGF0IGluIHRoZSB0cmFkaXRpb25hbCBMU1AsIHRoZSBMU1Agc2V0dXAgaXMgbmVnb3RpYXRlZCB0 aHJvdWdoDQoNCnRoZSBzaWduYWxsaW5nIGJldHdlZW4gdGhlIHVwc3RyZWFtIG5vZGUgYW5kIHRo ZSBkb3duc3RyZWFtIG5vZGUuIER1cmluZyB0aGUgbmVnb3RpYXRpb24sIGl0IGlzIG5vdCBvbmx5 IHRvDQoNCnNldCB1cCB0aGUgZm9yd2FyZGluZyB0aGUgZW50cnkgZm9yIHRoZSBwdXJwb3NlIG9m IHJlYWNoYWJsaXR5LCBidXQgYWxzbyBpbmNsdWRlcyBtYW55IGFzcGVjdHMgKEkgY2FsbCB0aGVt DQoNCmFzIHRoZSBvcGVyYXRpb24gYW5kIG1haW50ZW5lbmNlIG9mIHRoZSBMU1AuIEhvcGUgaXQg aXMgYXBwcm9wcmlhdGUuICkgc3VjaCBhcyB0aGUgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkNCg0K dmVyaWZpY2F0aW9uLCB0aGUgbG9vcCBwcmV2ZW50aW9uLCBwYXRoIE1UVSwgbmVnb3RpYXRpb24s IHBhdGggcmVjb3JkaW5nLCBlcnJvciBub3RpZmljYXRpb24gYW5kIGhhbmRsaW5nLA0KDQpldGMu IFRob3VnaCBTUiBhbHdheXMgcHJvcG9zZXMgaXRzIGFkdmFudGFnZSwgaW4gbXkgb3Bpbmlvbiwg dGhlc2UgYWR2YW50YWdlcyBhcmUgZnJvbSB0aGUgcmVhY2hhYmlsaXR5DQoNCnBhcnQgc3VjaCBh cyB0aGUgYWR2YW50YWdlIHRoYXQgdGhlIGxhYmVsIHN0YXRjayBpbiB0aGUgaW5ncmVzcyBub2Rl IHJlZHVjZXMgdGhlIHN0YXRlcyBpbiB0aGUgbmV0d29yay4NCg0KQnV0IHRoZSByZXF1aXJlbWVu dHMgb2YgdGhlIG9wZXJhdGlvbmFsIGFuZCBtYWludGVuYW5jZSBmb3IgdGhlIHRyYWRpdGlvbmFs IExTUCBzdGlsbCBleGlzdC4gVGFraW5nIGludG8NCg0KYWNjb3VudCB0aGF0IHRoZSBmbG9vZGlu ZyBtb2RlIG9mIHRoZSBJR1AsIGl0IHN0b3BzIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhl IG5vZGVzIGFsb25nIHRoZSBwYXRoLA0KDQp0aGUgd29yayBtYXkgYmVjb21lIG1vcmUgY29tcGxl eC4gQWNjb3JkaW5nIHRvIHRoZSBwYXN0IGV4cGVyaWVuY2UsIHRoZSBwb3NzaWJsZSB3YXlzIEkg Y291bGQgdGhpbmsgb3V0IGFyZQ0KDQphcyBmb2xsb3dzOg0KMSkgRGVwZW5kIG9uIHRoZSB0aGly ZC1wYXJ0eSBtZWNoYW5pc21zLiBCdXQgdGhlIHByb2JsZW0gaXMgdGhhdCB0aGVyZSBtYXkgaW52 b2x2ZSBtb3JlIG1lY2hhbmlzbXMgYW5kIHRoZXJlDQoNCm1heSBiZSBubyBtZWNoYW5pc21zLiBG b3IgZXhhbXBsZSwgTFNQIFBpbmcgY2FuIGJlIGFkb3B0ZWQgdG8gY2hlY2sgdGhlIGVuZC10by1l bmQgY29ubmVjdGl2aXR5IG9yIGxvb3AgZm9yDQoNCnRoZSBTUi1CRSBwYXRoLCBidXQgaXQgY2Fu bm90IGJlIHVzZWQgZm9yIHBhdGggTVRVIG5lZ290aWF0aW9uLiBGb3IgdGhlIGVuZC10by1lbmQg cGF0aCByZWNvcmRpbmcsIExTUCBUcmFjZXJ0DQoNCm1heSBoYXZlIHRvIGJlIGludHJvZHVjZWQu IElmIHRoZXNlIHJlcXVpcmVtZW50cyBhbmQgbWVjaGFuaXNtcyBhcmUgY29uc2lkZXJlZCwgaXQg bWVhbnMgU1IgZG9lcyBub3QgcmVkdWNlDQoNCnRoZSBjb21wZXhpdHkuIEluc3RlYWQgaXQganVz dCB0cmFuc2ZlcnMgbW9yZSBjb21wbGV4aXR5IHRvIHRoZSBvdGhlciBwb3NzaWJsZSBzaWduYWxs aW5ncy4NCjIpIERlcGVuZCBvbiBvbmUgbm9kZXMgdG8gaW1wbGVtZW50IHRoZSBwb3NzaWJsZSBm dW5jdGlvbnMuIEZvciBleGFtcGxlLCBmb3IgU1ItVEUgcGF0aCwgaXQgY2FuIGRlcGVuZCBvbiB0 aGUNCg0KUENFIG9yIHRoZSBpbmdyZXNzIG5vZGUgdG8gY29sbGVjdCBhbGwgcGF0aCBpbmZvIHBy b3Bvc2VkIGJ5IHBhdGggcmVjb3JkaW5nIG9yIGV2ZW4gcGF0aCBNVFUgbmVnb3RpYXRpb24uIEV2 ZW4gc28sDQoNCnRoZXJlIGlzIHN0aWxsIHNvbWUgZHJhd2JhY2tzIGZvciBzb21lIHNjZW5hcmlv cyBpZiBvbmx5IGRlcGVuZCBvbiB0aGUgaW5ncmVzcyBub2RlLiBNb3Jlb3ZlciB0aGVzZSBtZXRo b2RzDQpjYW5ub3QgYXBwbHkgdG8gU1ItQkUgcGF0aC5JZiB0aGUgcG9zc2libGUgd29yayBpcyBk b25lIHRocm91Z2ggdGhlIGluZ3Jlc3Mgbm9kZSwgaXQgd2lsbCBiZWdpbiB0byBjaGFuZ2UgdGhl DQoNCmVzc2VuY2Ugb2YgU1ItQkUgYW5kIGJlY29tZSB0aGUgU1ItVEUuDQozKSBMZWF2ZSBhcyBp dCBpcy4gVGhhdCBpcywgdGhlc2UgaXNzdWVzIGFyZSBub3Qgc29sdmVkIGZvciBTUiBwYXRoLiBJ biBteSBvd24gb3BpbmlvbiwgMjAgeWVhcnMgYWdvLCBvbmx5DQoNCnNvbHZpbmcgdGhlIHJlYWNo YWJpbGl0eSBpc3N1ZXMgbWF5IGJlIGFjY2VwdGVkLiBCdXQgdG9kYXksIGFzIHRoZSBjb25jZXB0 IG9mIGNhcnJpZXItZ3JhZGUgSVAgbmV0d29yayBoYXMgYmVlbg0KDQp3aWRlbHkgYWNjZXB0ZWQg YW5kIHRoZXNlIGZlYXR1cmVzIG1lbnRpb25lZCBoYXMgYmVlbiBkZXBsb3llZCBpbiB0aGUgdHJh ZGl0aW9uYWwgTVBMUyBuZXR3b3JrLCBJIGRvbid0IHRoaW5rDQoNCnRoZXkgY2FuIGJlIHJlbW92 ZWQgZWFzaWx5Lg0KDQpJbiBvbmUgd29yZCwgdGhvdWdoIHNvbWUgYWR2YW50YWdlIGRyaXZlbiBm cm9tIHRoZSByZWFjaGJpbGl0eSBvZiBTUiBpcyBhcHBhcmVudCwgdGhlIGNvbXBsZXhpdHkgaW50 cm9jdWRlZCBieQ0KDQp0aGUgc3ludGhlc2l6ZWQgcmVxdWlyZW1lbnRzIGFyZSBub3QgcmVkdWNl ZC4gQW5kIGl0IG1heSBiZWNvbWUgbW9yZSBjb21wbGV4IGZvciBTUi4NCg0KDQoNCg0KDQoNCg0K DQoNClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the eighth comments. The issues proposed = here apply to both SR-TE path and SR-BE path.

 

For LDP and RSVP-TE, there is the loop prevention= mechanism when setup LSP. For the SR, the SR path is always

setup at the ingress node. It is difficult to det= ect the possible loop in the network. For example, if the

microloop of route happens, the loop prevention m= echanism will prevent LDP to setup LSP. But for the segment

routing, once the ingress node downloads the forw= arding entry and the traffic will experience the microloop.

How can SR to cope with the issue or just leave i= t as the traditional routing?

 

For LDP and RSVP-TE, there is the error notificat= ion mechanism based on the LDP notification message or the

RSVP-TE PathErr/Resv messages. Based on the error= notification, the nodes along the LSP can take possible

actions against the possible errors. But for SR, = there is no such information communicated among the nodes

along the SR Path. The result will be that once t= he packet is forwarded by the ingress node, they may

experience the possible errors which may be preve= nted by the negotiation in the control plane.

 

From the previous comments, we can see that in th= e traditional LSP, the LSP setup is negotiated through

the signalling between the upstream node and the = downstream node. During the negotiation, it is not only to

set up the forwarding the entry for the purpose o= f reachablity, but also includes many aspects (I call them

as the operation and maintenence of the LSP. Hope= it is appropriate. ) such as the end-to-end connectivity

verification, the loop prevention, path MTU, nego= tiation, path recording, error notification and handling,

etc. Though SR always proposes its advantage, in = my opinion, these advantages are from the reachability

part such as the advantage that the label statck = in the ingress node reduces the states in the network. 

But the requirements of the operational and maint= enance for the traditional LSP still exist. Taking into

account that the flooding mode of the IGP, it sto= ps the communication between the nodes along the path,

the work may become more complex. According to th= e past experience, the possible ways I could think out are

as follows:
1) Depend on the third-party mechanisms. But the problem is that there may = involve more mechanisms and there

may be no mechanisms. For example, LSP Ping can b= e adopted to check the end-to-end connectivity or loop for

the SR-BE path, but it cannot be used for path MT= U negotiation. For the end-to-end path recording, LSP Tracert

may have to be introduced. If these requirements = and mechanisms are considered, it means SR does not reduce

the compexity. Instead it just transfers mor= e complexity to the other possible signallings.
2) Depend on one nodes to implement the possible functions. For example, fo= r SR-TE path, it can depend on the

PCE or the ingress node to collect all path info = proposed by path recording or even path MTU negotiation. Even so,

there is still some drawbacks for some scenarios = if only depend on the ingress node. Moreover these methods
cannot apply to SR-BE path.If the possible wo= rk is done through the ingress node, it will begin to change the

essence of SR-BE and become the SR-TE.
3) Leave as it is. That is, these issues are not solved for SR path. In my = own opinion, 20 years ago, only

solving the reachability issues may be accepted. = But today, as the concept of carrier-grade IP network has been

widely accepted and= these features mentioned has been deployed in the traditional MPLS network= , I don't think

they can be removed easily.

In one word, though some advantage driven from th= e reachbility of SR is apparent, the complexity introcuded by

the synthesized requirements are not reduced. And= it may become more complex for SR.

 

 

 

 

Regards,

Robin

 

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863nkgeml506mbxchi_-- From nobody Wed Jan 28 04:54:53 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFF51A701A; Wed, 28 Jan 2015 04:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6LmEm6n8dWC; Wed, 28 Jan 2015 04:54:48 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681AB1A6FF9; Wed, 28 Jan 2015 04:54:48 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so10368677igq.0; Wed, 28 Jan 2015 04:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U55L7z0pNx58nuVTIOPGTNJ4PM6zqFwvj0e5KmNzzBU=; b=cj+vynFAn4TL6ba/lACfDWSvFQEEFW3K80omEQM9wliX0fMK22VYTOY22YpIbzx2gX qYOPGQiaNCbDUeXRJ1RM+oP0xYbT1sdxn7MWHKm8jQi6vj0ssIXZcSHlp044GV6PKjUR KDyrboQZvt48xOW+5DI5TtXNlKmfhgZ7iXp7ynDG+DfZ2wTyWkIgjBHQkb5pBE8wmyJQ WE5taAG6oLWXz/fiaZT4cW5M7z9ncvLyEYKqm6IM9EC8tbnGJkFByauZSqLzFOXOpkAE mnxzdMa9kTrY2e5db0YAECJ8moASPH3fWscVipnXhVU36MXQacXReRbQOThYqz1X/Wt3 MGgg== MIME-Version: 1.0 X-Received: by 10.50.142.38 with SMTP id rt6mr3319775igb.17.1422449687546; Wed, 28 Jan 2015 04:54:47 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.157.69 with HTTP; Wed, 28 Jan 2015 04:54:47 -0800 (PST) In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863@nkgeml506-mbx.china.huawei.com> Date: Wed, 28 Jan 2015 13:54:47 +0100 X-Google-Sender-Auth: AGdXyhykkaTUsvqxr_YVEBjhuG4 Message-ID: From: Robert Raszuk To: Lizhenbin Content-Type: multipart/alternative; boundary=001a11c3a9505650a1050db5e059 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: Re: [mpls] [spring] New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 12:54:51 -0000 --001a11c3a9505650a1050db5e059 Content-Type: text/plain; charset=UTF-8 Robin, Most if not of your observations circle around idea to use segment routing as MPLS label signalling mechanism. I do not think this is that interesting scenario. Personally I would not deploy it for such purpose of hop by hop MPLS switching. We have LDP for that. Contrary I would use SR for controlled packet steering where responsibility is take to make the right header (be it label or extension headers) upon operator or his controller. To the point of the loop .. note that you may have valid cases to traverse given appliance (SFC use case) more then onces hence I would claim it is not aa architecture spec problem, but if so deployment bug. Best, r. On Wed, Jan 28, 2015 at 12:30 PM, Lizhenbin wrote: > Hi all authors of segment routing, > > > > This is the eighth comments. The issues proposed here apply to both SR-TE > path and SR-BE path. > > > > For LDP and RSVP-TE, there is the loop prevention mechanism when setup > LSP. For the SR, the SR path is always > > setup at the ingress node. It is difficult to detect the possible loop in > the network. For example, if the > > microloop of route happens, the loop prevention mechanism will prevent LDP > to setup LSP. But for the segment > > routing, once the ingress node downloads the forwarding entry and the > traffic will experience the microloop. > > How can SR to cope with the issue or just leave it as the traditional > routing? > > > > For LDP and RSVP-TE, there is the error notification mechanism based on > the LDP notification message or the > > RSVP-TE PathErr/Resv messages. Based on the error notification, the nodes > along the LSP can take possible > > actions against the possible errors. But for SR, there is no such > information communicated among the nodes > > along the SR Path. The result will be that once the packet is forwarded by > the ingress node, they may > > experience the possible errors which may be prevented by the negotiation > in the control plane. > > > > From the previous comments, we can see that in the traditional LSP, the > LSP setup is negotiated through > > the signalling between the upstream node and the downstream node. During > the negotiation, it is not only to > > set up the forwarding the entry for the purpose of reachablity, but also > includes many aspects (I call them > > as the operation and maintenence of the LSP. Hope it is appropriate. ) > such as the end-to-end connectivity > > verification, the loop prevention, path MTU, negotiation, path recording, > error notification and handling, > > etc. Though SR always proposes its advantage, in my opinion, these > advantages are from the reachability > > part such as the advantage that the label statck in the ingress node > reduces the states in the network. > > But the requirements of the operational and maintenance for the > traditional LSP still exist. Taking into > > account that the flooding mode of the IGP, it stops the communication > between the nodes along the path, > > the work may become more complex. According to the past experience, the > possible ways I could think out are > > as follows: > 1) Depend on the third-party mechanisms. But the problem is that there may > involve more mechanisms and there > > may be no mechanisms. For example, LSP Ping can be adopted to check the > end-to-end connectivity or loop for > > the SR-BE path, but it cannot be used for path MTU negotiation. For the > end-to-end path recording, LSP Tracert > > may have to be introduced. If these requirements and mechanisms are > considered, it means SR does not reduce > > the compexity. Instead it just transfers more complexity to the other > possible signallings. > 2) Depend on one nodes to implement the possible functions. For example, > for SR-TE path, it can depend on the > > PCE or the ingress node to collect all path info proposed by path > recording or even path MTU negotiation. Even so, > > there is still some drawbacks for some scenarios if only depend on the > ingress node. Moreover these methods > cannot apply to SR-BE path.If the possible work is done through the > ingress node, it will begin to change the > > essence of SR-BE and become the SR-TE. > 3) Leave as it is. That is, these issues are not solved for SR path. In my > own opinion, 20 years ago, only > > solving the reachability issues may be accepted. But today, as the concept > of carrier-grade IP network has been > > widely accepted and these features mentioned has been deployed in the > traditional MPLS network, I don't think > > they can be removed easily. > > In one word, though some advantage driven from the reachbility of SR is > apparent, the complexity introcuded by > > the synthesized requirements are not reduced. And it may become more > complex for SR. > > > > > > > > > > Regards, > > Robin > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --001a11c3a9505650a1050db5e059 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robin,

Most if not of your observations circle around idea to use segment ro= uting as MPLS label signalling mechanism. I do not think this is that inter= esting scenario. Personally I would not deploy it for such purpose of hop b= y hop MPLS switching. We have LDP for that.

Contrary I would use SR for controlled packet steering where re= sponsibility is take to make the right header (be it label or extension hea= ders) upon operator or his controller.=C2=A0

<= div class=3D"gmail_default" style=3D"font-family:courier new,monospace;font= -size:small">To the point of the loop .. note that you may have valid cases= to traverse given appliance (SFC use case) more then onces hence I would c= laim it is not aa architecture spec problem, but if so deployment bug.

Best,
r.

=C2=A0

On Wed, Jan 28, 2015 at 12:30 PM, Lizhe= nbin <lizhenbin@huawei.com> wrote:

Hi all authors of segment routing,

=C2=A0

This is the eighth comments. The issues proposed = here apply to both SR-TE path and SR-BE path.

=C2=A0

For LDP and RSVP-TE, there is the loop prevention= mechanism when setup LSP. For the SR, the SR path is always

setup at the ingress node. It is difficult to det= ect the possible loop in the network. For example, if the

microloop of route happens, the loop prevention m= echanism will prevent LDP to setup LSP. But for the segment

routing, once the ingress node downloads the forw= arding entry and the traffic will experience the microloop.

How can SR to cope with the issue or just leave i= t as the traditional routing?

=C2=A0

For LDP and RSVP-TE, there is the error notificat= ion mechanism based on the LDP notification message or the

RSVP-TE PathErr/Resv messages. Based on the error= notification, the nodes along the LSP can take possible

actions against the possible errors. But for SR, = there is no such information communicated among=C2=A0the nodes

along the SR Path. The result will be that once t= he packet is forwarded by the ingress node, they may

experience the possible errors which may be preve= nted by the negotiation in the control plane.

=C2=A0

From the previous comments, we can see that in th= e traditional LSP, the LSP setup is negotiated through

the signalling between the upstream node and the = downstream node. During the negotiation, it is not only to

set up the forwarding the entry for the purpose o= f reachablity, but also includes many aspects (I call them

as the operation and maintenence of the LSP. Hope= it is appropriate. ) such as the end-to-end connectivity

verification, the loop prevention, path MTU, nego= tiation, path recording, error notification and handling,

etc. Though SR always proposes its advantage, in = my opinion, these advantages=C2=A0are=C2=A0from the reachability

part such as the advantage that the label statck = in the ingress node reduces the states in the network.=C2=A0

But the requirements of the operational and maint= enance for the traditional LSP still exist. Taking into

account that the flooding mode of the IGP, it sto= ps the communication between the nodes along the path,

the work may become more complex. According to th= e past experience, the possible ways I could think out=C2=A0are

as follows:
1) Depend on the third-party mechanisms. But the problem is that there may = involve more mechanisms and there

may be no mechanisms. For example, LSP Ping can b= e adopted to check the end-to-end connectivity or loop for

the SR-BE path, but it cannot be used for path MT= U negotiation. For the end-to-end path recording, LSP Tracert

may have to be introduced. If these requirements = and mechanisms are considered,=C2=A0it means SR does not reduce

the compexity. Instead=C2=A0it just transfers mor= e complexity to the other possible signallings.
2) Depend on one nodes to implement the possible functions. For example, fo= r SR-TE path, it can depend on the

PCE or the ingress node to collect all path info = proposed by path recording or even path MTU negotiation. Even so,

there is still some drawbacks for some scenarios = if only depend on the ingress node. Moreover these methods
cannot apply to SR-BE path.If the possible wo= rk is done through the ingress node, it will begin to change the

essence of SR-BE and become the SR-TE.
3) Leave as it is. That is, these issues are not solved for SR path. In my = own opinion, 20 years ago, only

solving the reachability issues may be accepted. = But today, as the concept of carrier-grade IP network has been

widely accepted and= these features mentioned has been deployed in the traditional MPLS network= , I don't think

they can be removed easily.

In one word, though some advantage driven from th= e reachbility of SR is apparent, the complexity introcuded by

the synthesized requirements are not reduced. And= it may become more complex for SR.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Regards,

Robin

=C2=A0

=C2=A0


_______________________________________________
spring mailing list
spring@ietf.org
= https://www.ietf.org/mailman/listinfo/spring


--001a11c3a9505650a1050db5e059-- From nobody Wed Jan 28 07:31:45 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B0B1A870A for ; Wed, 28 Jan 2015 07:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.389 X-Spam-Level: X-Spam-Status: No, score=-101.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLUAX-hId9DF for ; Wed, 28 Jan 2015 07:31:36 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA2E1A6EF4 for ; Wed, 28 Jan 2015 07:31:35 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id v1so9008860yhn.8 for ; Wed, 28 Jan 2015 07:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lgoj/7IZrJqeu2KfsR+keOy6Echm9YGhZmI+pyhGE4E=; b=mg33ce4P8HYCfZCqZOrweuxWHhUpal+57IdiYl/3sQNkj+ePrqpxc0Oxyve981s+eJ jPl7yWa/lv3YySPXjDiij1JvlF6ujjE2TNx3U8xLOqC0FEqX5zErle3Sdk5AFfhhXi5m kX5ucW7msrk75Qsppv9Ncu5LJZBwRt5HJp00Rv8e7YMqfz/FynqQn+hjlmQvTvf60Gyj kPcGPNqDw7SrHK3EUjkPC7gP9BcEX9tpqKm5RCAL1ywL/MbG2Jf1bCe2pq1T0VbPrth2 bU0KG7/k9UY5nn/RIBb5ZaQ+cPahBfldyz1N73PPFNwtK8X6bM2wzfNOIDVZKGdAEUPy IwLg== MIME-Version: 1.0 X-Received: by 10.236.203.108 with SMTP id e72mr1550235yho.48.1422459094988; Wed, 28 Jan 2015 07:31:34 -0800 (PST) Received: by 10.170.133.80 with HTTP; Wed, 28 Jan 2015 07:31:34 -0800 (PST) In-Reply-To: <54C87B4E.5070500@pi.nu> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08302599@NKGEML512-MBS.china.huawei.com> <54C87B4E.5070500@pi.nu> Date: Wed, 28 Jan 2015 10:31:34 -0500 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=089e0160b506108022050db8112f Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Advice on draft-etf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 15:31:42 -0000 --089e0160b506108022050db8112f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Loa, On Wed, Jan 28, 2015 at 1:01 AM, Loa Andersson wrote: > Folks, > > This mail to Alia (as responsible AD), Adrian (with experience from > progressing a lot of documents) and the mpls wg co-chairs. > > I became Document Shepherd rather late in the process. Ross did the > "repeated wglc" on this draft on version -07, the document was updated > after wglc as version -08. After that there has been discussions on > different parts of the document and it has been updated twice. And a > third version (-11) is in the pipe. I've not seen version -11 yet, but > among the authors there are talk about "brand new issues". > > My concerns are that we are introducing to big changes without keeping > the working group in the loop. Can you help evaluate if we need to take > the document through a new wglc, or if we are good to go? > I am keeping a close eye on this question. So far, I think that we are good to go once the discusses and upstream labels questions are addressed. On the latter, I believe it is resolving to behavior as specified in the draft from WGLC - but with the clarification that in the future some signalling might indicate whether the labels are not upstream assigned even if the IP destination address is multicast. The two discusses are not, IMHO, changing any technical details but rather clarifying details. For instance, there isn't a listener at the UDP source port on the ingress of the UDP tunnel. For another instance, clarifying the DTL= S behavior in terms of number of expected sessions. I do hope to see an updated draft that addresses the discusses very soon and would encourage prodding by the shepherd ;-) Thanks, Alia /Loa > > On 2015-01-28 09:14, Xuxiaohu wrote: > >> Hi David, >> >> The text looks good to me. Thanks for your excellent work. >> >> Best regards, >> Xiaohu >> >> -----Original Message----- >>> From: Black, David [mailto:david.black@emc.com] >>> Sent: Tuesday, January 27, 2015 7:51 PM >>> To: Xuxiaohu >>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>> adrian@olddog.co.uk; >>> Black, David >>> Subject: MPLS/UDP: Section 3.1 item 3 - rewrite >>> >>> Here's my initial attempt to clarify Section 3.1 item 3 wrt Eric Rosen'= s >>> concern >>> that the source IPv6 address is the context identifier for >>> upstream-assigned >>> context labels for multicast traffic. I found a way to do this without >>> talking >>> about "point" or "multipoint" characteristics of tunnel ingress/egress. >>> >>> OLD >>> e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for >>> each MPLS-in-UDP tunnel that uses UDP zero-checksum mode >>> regardless of receiver in order to strengthen the receiver's >>> check of the IPv6 source address. When this is not possible, i= t >>> is RECOMMENDED to use each source IPv6 address for as few UDP >>> zero-checksum mode MPLS-in-UDP tunnels as is feasible. >>> NEW >>> e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for >>> each MPLS-in-UDP tunnel that uses UDP zero-checksum mode >>> regardless of receiver in order to strengthen the receiver's >>> check of the IPv6 source address (i.e., the same IPv6 source >>> address SHOULD NOT be used with more than one IPv6 destination >>> address, independent of whether that destination address is a >>> unicast or multicast address). When this is not possible, it >>> is RECOMMENDED to use each source IPv6 address for as few UDP >>> zero-checksum mode MPLS-in-UDP tunnels (i.e., with as few >>> destination IPv6 addresses) as is feasible. >>> >>> How does that look? >>> >>> Thanks, >>> --David >>> >>> -----Original Message----- >>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>>> Sent: Monday, January 26, 2015 11:01 AM >>>> To: Black, David >>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>> adrian@olddog.co.uk >>>> Subject: Re: [mpls] ID Tracker State Update Notice: >>>> >>>> >>>> Hi David, >>>> >>>> After a careful consideration, I think it should be OK for an >>>> encapsulator to use different tunnel source addresses for different >>>> UDP tunnels if these tunnels are manually configured. Sorry for that >>>> confusion. In addition, since item e has a sentence "When this is not >>>> possible,...", I believe the current text is OK for the P2P UDP tunnel >>>> case. It seems that you only need to add some text about the P2MP UDP >>>> >>> tunnel, just as what you have mentioned before. >>> >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>> ________________________________________ >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Black, David [david.black@emc.com] >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B41=E6=9C=8826=E6=97= =A5 18:40 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu >>>> =E6=8A=84=E9=80=81: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.o= rg; >>>> adrian@olddog.co.uk; Black, David >>>> =E4=B8=BB=E9=A2=98: RE: [mpls] ID Tracker State Update Notice: >>>> >>>> >>>> First, this is a brand new concern that has not been raised previously >>>> - it's definitely different from Eric Rosen's concern, which I >>>> understand and will write clarifying text for. >>>> >>>> Second, a VPN ought to be seriously concerned with misdelivery >>>> prevention, and there's text in the security considerations section on >>>> this topic. Item e in section 3.1 is one of the important things that >>>> this draft does towards misdelivery prevention when UDP zero checksums >>>> are >>>> >>> used with IPv6. >>> >>>> >>>> My starting point would be - if L3VPNs have a problem with using a >>>> different >>>> IPv6 address as the source of each tunnel, then that's one more reason >>>> for L3VPNs to use UDP checksums with IPv6. >>>> >>>> I'll defer to L3VPN experts on how L3VPN address signaling currently >>>> works and the impacts of additional IPv6 addresses on that. I'm not >>>> the right person to write L3VPN-specific text (on this or any other >>>> topic). >>>> >>>> Thanks, >>>> --David >>>> >>>> -----Original Message----- >>>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>>>> Sent: Monday, January 26, 2015 4:42 AM >>>>> To: Black, David >>>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>>> >>>> adrian@olddog.co.uk >>>> >>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>> >>>>> >>>>> Hi David, >>>>> >>>>> Just take the BGP/MPLS IP VPN with RR enabled as an example, if it >>>>> requires the tunnel encapsulator (i.e., ingress PE) to use different >>>>> source IP addresses for different tunnels, should ingress PEs notify >>>>> the address to be used as the tunnel source address to each egress >>>>> PE. Otherwise, how could egress PEs verify that the packets are >>>>> received >>>>> >>>> from valid ingress PEs? >>> >>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>> -----Original Message----- >>>>>> From: Black, David [mailto:david.black@emc.com] >>>>>> Sent: Saturday, January 24, 2015 3:15 AM >>>>>> To: Xuxiaohu >>>>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>>>> >>>>> adrian@olddog.co.uk; >>>>> >>>>>> Black, David >>>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>>> >>>>>> >>>>>> Xiaohu, >>>>>> >>>>>> I'm missing something here. >>>>>> >>>>>> Eric's concern stems from the requirement that when >>>>>> upstream-assigned >>>>>> >>>>> labels >>>> >>>>> are in use, the source IP address identifies the label context, >>>>>> and hence >>>>>> >>>>> that >>>>> >>>>>> source IP address has to be common across all traffic to a >>>>>> destination. >>>>>> >>>>> Eric was >>>>> >>>>>> concerned that Section 3.1 item e might conflict with that >>>>>> requirement. >>>>>> >>>>>> The clarifying text will indicate that there is no problem here; >>>>>> when the destination IP address is a multicast address, the sender >>>>>> sends one >>>>>> >>>>> packet, >>>> >>>>> the >>>>> >>>>>> receivers each get a copy and that 1:n multicast fan-out is a >>>>>> single >>>>>> >>>>> "tunnel" wrt >>>>> >>>>>> Section 3.1 item e. >>>>>> Every packet delivered to every receiver in that tunnel uses the >>>>>> same >>>>>> >>>>> source >>>> >>>>> IP >>>>> >>>>>> address, so there's a single label context. >>>>>> >>>>>> I do not understand the RPF and signaling concerns below. >>>>>> >>>>>> Thanks, >>>>>> --David >>>>>> >>>>>> -----Original Message----- >>>>>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>>>>>> Sent: Thursday, January 22, 2015 8:40 PM >>>>>>> To: Black, David >>>>>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>>>>> adrian@olddog.co.uk >>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>>>> >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> I'm looking forwarding to seeing your updated text. By the way, >>>>>>> I hope you could take into account potential concerns as follows: >>>>>>> >>>>>>> 1) will it make the RPF check performed by tunnel decapsulators >>>>>>> (e.g., to determine the upstream PE of the received multicast >>>>>>> packet in the multicast VPN context) difficult when requiring a >>>>>>> tunnel encapsulator to use different tunnel source addresses for >>>>>>> different tunnels; >>>>>>> 2) does it require the encapsulator of a particular MPLS-in-UDP >>>>>>> tunnel to notify the decapsulator(s) of its possible addresses >>>>>>> to be used as the source address of that tunnel. >>>>>>> >>>>>>> Best regards, >>>>>>> Xiaohu >>>>>>> >>>>>>> -----Original Message----- >>>>>>>> From: Black, David [mailto:david.black@emc.com] >>>>>>>> Sent: Thursday, January 22, 2015 11:15 PM >>>>>>>> To: Xuxiaohu >>>>>>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>>>>>> >>>>>>> adrian@olddog.co.uk; >>>>>>> >>>>>>>> Black, David >>>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>>>>> >>>>>>>> >>>>>>>> Xiaohu, >>>>>>>> >>>>>>>> Since the requirement item e would introduce additional and >>>>>>>>> unexpected complexities and difficulties for the deployment, >>>>>>>>> I suggest that it'd better to remove that item. >>>>>>>>> >>>>>>>> >>>>>>>> I strongly disagree. That requirement is important to the >>>>>>>> overall design >>>>>>>> >>>>>>> goal of >>>>>>> >>>>>>>> requiring an offsetting corruption to cause misdelivery (i.e., >>>>>>>> a single >>>>>>>> >>>>>>> corruption >>>>>>> >>>>>>>> should usually not result in misdelivery). >>>>>>>> >>>>>>>> There is not an actual problem here - item e is correct wrt >>>>>>>> Eric's concern, >>>>>>>> >>>>>>> but not >>>>>>> >>>>>>>> explained clearly. I can write the sentence or two that will be >>>>>>>> >>>>>>> needed to >>>>> >>>>>> clarify >>>>>>>> how requirement e applies to P2MP UDP tunnels (i.e., >>>>>>>> destination IP address >>>>>>>> >>>>>>> is a >>>>>>> >>>>>>>> multicast address) *after* the upstream vs. downstream label >>>>>>>> assignment discussion is sorted out. >>>>>>>> >>>>>>>> By the way, I feel it would be better to uniformly replace >>>>>>>>> "MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP >>>>>>>>> sender" by "tunnel decapsulator" and "tunnel encapsulator" >>>>>>>>> respectively in the whole >>>>>>>>> >>>>>>>> doc. >>>>>>>> >>>>>>>> I'll defer to others on terminology, although I find the >>>>>>>> MPLS-in-UDP >>>>>>>> >>>>>>> terminology >>>>>>> >>>>>>>> clearer because it indicates exactly which tunnel is involved. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> --David >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>>>>>>>> Sent: Wednesday, January 21, 2015 10:22 PM >>>>>>>>> To: Black, David >>>>>>>>> Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; >>>>>>>>> adrian@olddog.co.uk >>>>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi David and all, >>>>>>>>> >>>>>>>>> Since the requirement item e would introduce additional and >>>>>>>>> unexpected complexities and difficulties for the deployment, >>>>>>>>> I suggest that it'd better to remove that item. >>>>>>>>> >>>>>>>>> By the way, I feel it would be better to uniformly replace >>>>>>>>> "MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP >>>>>>>>> sender" by "tunnel decapsulator" and "tunnel encapsulator" >>>>>>>>> respectively in the whole >>>>>>>>> >>>>>>>> doc. >>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Xiaohu >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>>> From: Black, David [mailto:david.black@emc.com] >>>>>>>>>> Sent: Thursday, January 22, 2015 3:17 AM >>>>>>>>>> To: Eric C Rosen; Alia Atlas; Xuxiaohu >>>>>>>>>> Cc: Loa Andersson; ; >>>>>>>>>> mpls-chairs@tools.ietf.org; >>>>>>>>>> draft-ietf-mpls-in-udp@tools.ietf.org; >>>>>>>>>> IJsbrand Wijnands; Black, David >>>>>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Eric, >>>>>>>>>> >>>>>>>>>> On the further issue ... >>>>>>>>>> >>>>>>>>>> There is one further issue for you to consider. >>>>>>>>>>> >>>>>>>>>>> When an MPLS packet with an upstream-assigned label is >>>>>>>>>>> received through a particular tunnel, the "context" in >>>>>>>>>>> which the label is interpreted is determined by the IP >>>>>>>>>>> address of the >>>>>>>>>>> >>>>>>>>>> root of >>>>> >>>>>> the tunnel. >>>>>> >>>>>>> (See section 7 of RFC5331.) For a UDP tunnel, this >>>>>>>>>>> would mean that the label space is identified by the Source IP >>>>>>>>>>> >>>>>>>>>> address. >>> >>>> So if a particular router is using MPLS-in-UDP to send >>>>>>>>>>> MPLS packets with upstream-assigned labels, it's really >>>>>>>>>>> important for it to use the same IP >>>>>>>>>>> >>>>>>>>>> source >>>>>>>>> >>>>>>>>>> address in all >>>>>>>>>> >>>>>>>>>>> MPLS-in-UDP packets that have the same destination address. >>>>>>>>>>> >>>>>>>>>> I >>> >>>> can't >>>>> >>>>>> quite tell whether this is compatible with item e. in >>>>>>>>>>> section >>>>>>>>>>> 3.1 of the draft. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That is compatible with item e., but the draft doesn't say >>>>>>>>>> much about P2MP >>>>>>>>>> >>>>>>>>> UDP >>>>>>>>> >>>>>>>>>> tunnels. In particular, I would view that source IP >>>>>>>>>> address as the source >>>>>>>>>> >>>>>>>>> IP >>>>>>>>> >>>>>>>>>> address for a (one) P2MP tunnel, and it's probably a good >>>>>>>>>> idea to add some >>>>>>>>>> >>>>>>>>> text >>>>>>>>> >>>>>>>>>> on P2MP UDP tunnels to make this clear. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> --David >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Eric C Rosen [mailto:erosen@juniper.net] >>>>>>>>>>> Sent: Wednesday, January 21, 2015 11:26 AM >>>>>>>>>>> To: Alia Atlas; Xuxiaohu >>>>>>>>>>> Cc: erosen@juniper.net; Black, David; Loa Andersson; >>>>>>>>>>> ; mpls-chairs@tools.ietf.org; >>>>>>>>>>> draft-ietf-mpls-in- udp@tools.ietf.org; IJsbrand >>>>>>>>>>> Wijnands >>>>>>>>>>> Subject: Re: [mpls] ID Tracker State Update Notice: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Folks, >>>>>>>>>>> >>>>>>>>>>> I'll be happy to throw in my much belated two cents. >>>>>>>>>>> >>>>>>>>>>> If I understand correctly, the issue at hand is how one >>>>>>>>>>> determines, when receiving an MPLS-in-UDP packet, >>>>>>>>>>> whether the top MPLS label is upstream-assigned or >>>>>>>>>>> >>>>>>>>>> downstream-assigned. >>> >>>> >>>>>>>>>>> Draft-ietf-mpls-in-udp-10 has the following text: >>>>>>>>>>> >>>>>>>>>>> As for whether the top label in the MPLS label stack is >>>>>>>>>>> downstream-assigned or upstream-assigned, it SHOULD >>>>>>>>>>> be >>>>>>>>>>> >>>>>>>>>> determined >>>>>>>> >>>>>>>>> based on the tunnel destination IP address. That is >>>>>>>>>>> to say, if >>>>>>>>>>> >>>>>>>>>> the >>>>>>> >>>>>>>> destination IP address is a multicast address, the >>>>>>>>>>> top label >>>>>>>>>>> >>>>>>>>>> SHOULD >>>>>>> >>>>>>>> be upstream-assigned, otherwise if the destination >>>>>>>>>>> IP >>>>>>>>>>> >>>>>>>>>> address >>>> >>>>> is a >>>>> >>>>>> unicast address, it SHOULD be downstream-assigned. >>>>>>>>>>> >>>>>>>>>>> I believe this text is incorrect, as it is inconsistent >>>>>>>>>>> with RFCs >>>>>>>>>>> 5332 and 5331, which are the RFCs that introduce the >>>>>>>>>>> notion of "upstream-assigned labels". >>>>>>>>>>> >>>>>>>>>>> Of particular relevance is Section 3 of RFC 5332, which >>>>>>>>>>> discusses how one determines, when an MPLS packet is >>>>>>>>>>> being sent through a tunnel, whether the top label of >>>>>>>>>>> the encapsulated packet is upstream or >>>>>>>>>>> >>>>>>>>>> downstream. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> To make a long story short, basically what that section >>>>>>>>>>> says is that the tunnel must be known a priori to have >>>>>>>>>>> one of the following three >>>>>>>>>>> >>>>>>>>>> properties: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. The top label of all encapsulated packets is >>>>>>>>>>> downstream- >>>>>>>>>>> >>>>>>>>>> assigned. >>>>> >>>>>> >>>>>>>>>>> 2. The top label of all encapsulated packets is >>>>>>>>>>> upstream- >>>>>>>>>>> >>>>>>>>>> assigned. >>>> >>>>> >>>>>>>>>>> 3. The top label of some encapsulated packets is >>>>>>>>>>> downstream-assigned, but the top label of some >>>>>>>>>>> encapsulated packets is >>>>>>>>>>> >>>>>>>>>> upstream-assigned. >>>>>>>> >>>>>>>>> >>>>>>>>>>> How it is known which property the tunnel has is out of >>>>>>>>>>> scope (i.e., it depends on the higher layer). >>>>>>>>>>> >>>>>>>>>>> Only tunnels with the third property need to contain a >>>>>>>>>>> codepoint that specifies whether the label is >>>>>>>>>>> upstream-assigned or >>>>>>>>>>> >>>>>>>>>> downstream-assigned. >>>>>>>> >>>>>>>>> >>>>>>>>>>> So what does all this mean for the mpls-in-udp encapsulation? >>>>>>>>>>> I would suggest that you say the following: >>>>>>>>>>> >>>>>>>>>>> - Have IANA assign a single UDP port number for MPLS-in-UDP. >>>>>>>>>>> >>>>>>>>>>> - In the absence of any other knowledge, a UDP packet >>>>>>>>>>> with the MPLS-in-UDP port number in destination port >>>>>>>>>>> field is assumed to be carrying an MPLS packet whose top >>>>>>>>>>> label is >>>>>>>>>>> >>>>>>>>>> downstream-assigned. >>>>>> >>>>>>> >>>>>>>>>>> - Higher layers may negotiate the use of particular UDP >>>>>>>>>>> tunnels to carry MPLS packets whose top labels are >>>>>>>>>>> upstream-assigned. The procedures for such negotiation >>>>>>>>>>> are out of scope of the current document. By a >>>>>>>>>>> "particluar UDP tunnel", I mean a UDP tunnel with a >>>>>>>>>>> particular >>>>>>>>>> destination >>>>>>>>>>> port> triple. The destination port may be the standard >>>>>>>>>>> (IANA-assigned) port number for MPLS-in-UDP, but it may >>>>>>>>>>> also be any other port number that is negotiated by the higher >>>>>>>>>>> >>>>>>>>>> layer. >>> >>>> >>>>>>>>>>> - For a particular UDP tunnel (i.e., a particular >>>>>>>>>>> >>>>>>>>>>> triple), all the encapsulated MPLS packets must have the >>>>>>>>>>> same type of label at the top >>>>>>>>>>> >>>>>>>>>> of >>>>>>> >>>>>>>> the stack. >>>>>>>> >>>>>>>>> >>>>>>>>>>> - Remove any suggestion that the type of the label can >>>>>>>>>>> be inferred from the type of the IP destination address. >>>>>>>>>>> >>>>>>>>>>> I think this will make the draft compatible with RFCs >>>>>>>>>>> 5332 and 5331, and it does not require IANA to allocate >>>>>>>>>>> a second port >>>>>>>>>>> >>>>>>>>>> number. >>>>> >>>>>> >>>>>>>>>>> Note, by the way, that if we are going to allow the >>>>>>>>>>> higher layers to negotiate the destination port number, >>>>>>>>>>> we should probably caution implementers not to hard code >>>>>>>>>>> (or hard wire) a particular port >>>>>>>>>>> >>>>>>>>>> number. >>>>>>>> >>>>>>>>> >>>>>>>>>>> There is one further issue for you to consider. >>>>>>>>>>> >>>>>>>>>>> When an MPLS packet with an upstream-assigned label is >>>>>>>>>>> received through a particular tunnel, the "context" in >>>>>>>>>>> which the label is interpreted is determined by the IP >>>>>>>>>>> address of the >>>>>>>>>>> >>>>>>>>>> root of >>>>> >>>>>> the tunnel. >>>>>> >>>>>>> (See section 7 of RFC5331.) For a UDP tunnel, this >>>>>>>>>>> would mean that the label space is identified by the Source IP >>>>>>>>>>> >>>>>>>>>> address. >>> >>>> So if a particular router is using MPLS-in-UDP to send >>>>>>>>>>> MPLS packets with upstream-assigned labels, it's really >>>>>>>>>>> important for it to use the same IP >>>>>>>>>>> >>>>>>>>>> source >>>>>>>>> >>>>>>>>>> address in all >>>>>>>>>> >>>>>>>>>>> MPLS-in-UDP packets that have the same destination address. >>>>>>>>>>> >>>>>>>>>> I >>> >>>> can't >>>>> >>>>>> quite tell whether this is compatible with item e. in >>>>>>>>>>> section >>>>>>>>>>> 3.1 of the draft. >>>>>>>>>>> >>>>>>>>>>> Eric >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --089e0160b506108022050db8112f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Loa,

On Wed, Jan 28, 2015 at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
Folks,

This mail to Alia (as responsible AD), Adrian (with experience from progres= sing a lot of documents) and the mpls wg co-chairs.

I became Document Shepherd rather late in the process. Ross did the
"repeated wglc" on this draft on version -07, the document was up= dated
after wglc as version -08. After that there has been discussions on
different parts of the document and it has been updated twice. And a
third version (-11) is in the pipe. I've not seen version -11 yet, but<= br> among the authors there are talk about "brand new issues".

My concerns are that we are introducing to big changes without keeping
the=C2=A0 working group in the loop. Can you help evaluate if we need to ta= ke
the document through a new wglc, or if we are good to go?
<= div>
I am keeping a close eye on this question. So far, I thi= nk that we are good to
go once the discusses and upstream labels = questions are addressed.

On the latter, =C2=A0I be= lieve it is resolving to behavior as specified in the draft
from = WGLC - but with the clarification that in the future some signalling might<= /div>
indicate whether the labels are not upstream assigned even if the= IP destination
address is multicast.

Th= e two discusses are not, IMHO, changing any technical details but rather
clarifying details.=C2=A0 For instance, there isn't a listener = at the UDP source port
on the ingress of the UDP tunnel.=C2=A0 Fo= r another instance, clarifying the DTLS
behavior in terms of numb= er of expected sessions.

I do hope to see an updat= ed draft that addresses the discusses very soon
and would encoura= ge prodding by the shepherd ;-)
=C2=A0
Thanks,
Alia

/Loa

On 2015-01-28 09:14, Xuxiaohu wrote:
Hi David,

The text looks good to me. Thanks for your excellent work.

Best regards,
Xiaohu

-----Original Message-----
From: Black, David [mailto:david.black@emc.com]
Sent: Tuesday, January 27, 2015 7:51 PM
To: Xuxiaohu
Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org; adrian@olddog.co.uk;=
Black, David
Subject: MPLS/UDP: Section 3.1 item 3 - rewrite

Here's my initial attempt to clarify Section 3.1 item 3 wrt Eric Rosen&= #39;s concern
that the source IPv6 address is the context identifier for upstream-assigne= d
context labels for multicast traffic.=C2=A0 I found a way to do this withou= t talking
about "point" or "multipoint" characteristics of tunnel= ingress/egress.

OLD
=C2=A0 =C2=A0 e.=C2=A0 An MPLS-in-UDP sender SHOULD use different IPv6 addr= esses for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 each MPLS-in-UDP tunnel that uses UDP zero-chec= ksum mode
=C2=A0 =C2=A0 =C2=A0 =C2=A0 regardless of receiver in order to strengthen t= he receiver's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 check of the IPv6 source address.=C2=A0 When th= is is not possible, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is RECOMMENDED to use each source IPv6 address = for as few UDP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 zero-checksum mode MPLS-in-UDP tunnels as is fe= asible.
NEW
=C2=A0 =C2=A0 e.=C2=A0 An MPLS-in-UDP sender SHOULD use different IPv6 addr= esses for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 each MPLS-in-UDP tunnel that uses UDP zero-chec= ksum mode
=C2=A0 =C2=A0 =C2=A0 =C2=A0 regardless of receiver in order to strengthen t= he receiver's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 check of the IPv6 source address (i.e., the sam= e IPv6 source
=C2=A0 =C2=A0 =C2=A0 =C2=A0 address SHOULD NOT be used with more than one I= Pv6 destination
=C2=A0 =C2=A0 =C2=A0 =C2=A0 address, independent of whether that destinatio= n address is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 unicast or multicast address).=C2=A0 When this = is not possible, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is RECOMMENDED to use each source IPv6 address = for as few UDP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 zero-checksum mode MPLS-in-UDP tunnels (i.e., w= ith as few
=C2=A0 =C2=A0 =C2=A0 =C2=A0 destination IPv6 addresses) as is feasible.

How does that look?

Thanks,
--David

-----Original Message-----
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: Monday, January 26, 2015 11:01 AM
To: Black, David
Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org;
adrian@olddog.co.u= k
Subject: Re: [mpls] ID Tracker State Update Notice:
<draft-ietf-mpls-in-udp- 09.txt>

Hi David,

After a careful consideration, I think it should be OK for an
encapsulator to use different tunnel source addresses for different
UDP tunnels if these tunnels are manually configured. Sorry for that
confusion. In addition, since item e has a sentence "When this is not<= br> possible,...", I believe the current text is OK for the P2P UDP tunnel=
case. It seems that you only need to add some text about the P2MP UDP
tunnel, just as what you have mentioned before.

Best regards,
Xiaohu

________________________________________
=E5=8F=91=E4=BB=B6=E4=BA=BA: Black, David [david.black@emc.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B41=E6=9C=8826=E6=97=A5 18= :40
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu
=E6=8A=84=E9=80=81: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf= .org;
adrian@olddog.co.u= k; Black, David
=E4=B8=BB=E9=A2=98: RE: [mpls] ID Tracker State Update Notice:
<draft-ietf-mpls-in-udp- 09.txt>

First, this is a brand new concern that has not been raised previously
- it's definitely different from Eric Rosen's concern, which I
understand and will write clarifying text for.

Second, a VPN ought to be seriously concerned with misdelivery
prevention, and there's text in the security considerations section on<= br> this topic.=C2=A0 Item e in section 3.1 is one of the important things that=
this draft does towards misdelivery prevention when UDP zero checksums are<= br>
used with IPv6.

My starting point would be - if L3VPNs have a problem with using a
different
IPv6 address as the source of each tunnel, then that's one more reason<= br> for L3VPNs to use UDP checksums with IPv6.

I'll defer to L3VPN experts on how L3VPN address signaling currently works and the impacts of additional IPv6 addresses on that.=C2=A0 I'm n= ot
the right person to write L3VPN-specific text (on this or any other topic).=

Thanks,
--David

-----Original Message-----
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: Monday, January 26, 2015 4:42 AM
To: Black, David
Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org;
adrian@olddog.co.u= k
Subject: RE: [mpls] ID Tracker State Update Notice:
<draft-ietf-mpls-in-udp- 09.txt>

Hi David,

Just take the BGP/MPLS IP VPN with RR enabled as an example, if it
requires the tunnel encapsulator (i.e., ingress PE) to use different
source IP addresses for different tunnels, should ingress PEs notify
the address to be used as the tunnel source address to each egress
PE. Otherwise, how could egress PEs verify that the packets are received
from valid ingress PEs?

Best regards,
Xiaohu

-----Original Message-----
From: Black, David [mailto:david.black@emc.com]
Sent: Saturday, January 24, 2015 3:15 AM
To: Xuxiaohu
Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org;
adrian@olddog.co.u= k;
Black, David
Subject: RE: [mpls] ID Tracker State Update Notice:
<draft-ietf-mpls-in-udp-09.txt>

Xiaohu,

I'm missing something here.

Eric's concern stems from the requirement that when
upstream-assigned
labels
are in use, the source IP address identifies the label context,
and hence
that
source IP address has to be common across all traffic to a destination.
Eric was
concerned that Section 3.1 item e might conflict with that requirement.

The clarifying text will indicate that there is no problem here;
when the destination IP address is a multicast address, the sender
sends one
packet,
the
receivers each get a copy and that 1:n multicast fan-out is a
single
"tunnel" wrt
Section 3.1 item e.
Every packet delivered to every receiver in that tunnel uses the
same
source
IP
address, so there's a single label context.

I do not understand the RPF and signaling concerns below.

Thanks,
--David

-----Original Message-----
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: Thursday, January 22, 2015 8:40 PM
To: Black, David
Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org;
adrian@olddog.co.u= k
Subject: RE: [mpls] ID Tracker State Update Notice:
<draft-ietf-mpls-in-udp- 09.txt>

Hi David,

I'm looking forwarding to seeing your updated text. By the way,
I hope you could take into account potential concerns as follows:

1) will it make the RPF check performed by tunnel decapsulators
(e.g., to determine the upstream PE of the received multicast
packet in the multicast VPN context) difficult when requiring a
tunnel encapsulator to use different tunnel source addresses for
different tunnels;
2) does it require the encapsulator of a particular MPLS-in-UDP
tunnel to notify the decapsulator(s) of its possible addresses
to be used as the source address of that tunnel.

Best regards,
Xiaohu

-----Original Message-----
From: Black, David [mailto:david.black@emc.com]
Sent: Thursday, January 22, 2015 11:15 PM
To: Xuxiaohu
Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org;
adrian@olddog.co.u= k;
Black, David
Subject: RE: [mpls] ID Tracker State Update Notice:
<draft-ietf-mpls-in-udp-09.txt>

Xiaohu,

Since the requirement item e would introduce additional and
unexpected complexities and difficulties for the deployment,
I suggest that it'd better to remove that item.

I strongly disagree.=C2=A0 That requirement is important to the
overall design
goal of
requiring an offsetting corruption to cause misdelivery (i.e.,
a single
corruption
should usually not result in misdelivery).

There is not an actual problem here - item e is correct wrt
Eric's concern,
but not
explained clearly.=C2=A0 =C2=A0 I can write the sentence or two that will b= e
needed to
clarify
how requirement e applies to P2MP UDP tunnels (i.e.,
destination IP address
is a
multicast address) *after* the upstream vs. downstream label
assignment discussion is sorted out.

By the way, I feel it would be better to uniformly replace
"MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP
sender" by "tunnel decapsulator" and "tunnel encapsulat= or"
respectively in the whole
doc.

I'll defer to others on terminology, although I find the
MPLS-in-UDP
terminology
clearer because it indicates exactly which tunnel is involved.

Thanks,
--David


-----Original Message-----
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: Wednesday, January 21, 2015 10:22 PM
To: Black, David
Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org;
adrian@olddog.co.u= k
Subject: RE: [mpls] ID Tracker State Update Notice:
<draft-ietf-mpls-in-udp- 09.txt>

Hi David and all,

Since the requirement item e would introduce additional and
unexpected complexities and difficulties for the deployment,
I suggest that it'd better to remove that item.

By the way, I feel it would be better to uniformly replace
"MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP
sender" by "tunnel decapsulator" and "tunnel encapsulat= or"
respectively in the whole
doc.

Best regards,
Xiaohu

-----Original Message-----
From: Black, David [mailto:david.black@emc.com]
Sent: Thursday, January 22, 2015 3:17 AM
To: Eric C Rosen; Alia Atlas; Xuxiaohu
Cc: Loa Andersson; <mpls-ads@tools.ietf.org>;
mpls-chairs= @tools.ietf.org;
= draft-ietf-mpls-in-udp@tools.ietf.org;
IJsbrand Wijnands; Black, David
Subject: RE: [mpls] ID Tracker State Update Notice:
<draft-ietf-mpls-in-udp-09.txt>

Eric,

On the further issue ...

There is one further issue for you to consider.

When an MPLS packet with an upstream-assigned label is
received through a particular tunnel, the "context" in
which the label is interpreted is determined by the IP
address of the
root of
the tunnel.
(See section 7 of RFC5331.)=C2=A0 For a UDP tunnel, this
would mean that the label space is identified by the Source IP
address.
So if a particular router is using MPLS-in-UDP to send
MPLS packets with upstream-assigned labels, it's really
important for it to use the same IP
source
address in all
MPLS-in-UDP packets that have the same destination address.
I
can't
quite tell whether this is compatible with item e. in
section
3.1 of the draft.

That is compatible with item e., but the draft doesn't say
much about P2MP
UDP
tunnels.=C2=A0 In particular, I would view that source IP
address as the source
IP
address for a (one) P2MP tunnel, and it's probably a good
idea to add some
text
on P2MP UDP tunnels to make this clear.

Thanks,
--David

-----Original Message-----
From: Eric C Rosen [mailto:erosen@juniper.net]
Sent: Wednesday, January 21, 2015 11:26 AM
To: Alia Atlas; Xuxiaohu
Cc: erosen@juniper.= net; Black, David; Loa Andersson;
<mpls- ads@tools= .ietf.org>; mpls-chairs@tools.ietf.org;
draft-ietf-mpls-in- udp@tools.ietf.org; IJsbrand
Wijnands
Subject: Re: [mpls] ID Tracker State Update Notice:
<draft-ietf-mpls-in-udp- 09.txt>

Folks,

I'll be happy to throw in my much belated two cents.

If I understand correctly, the issue at hand is how one
determines, when receiving an MPLS-in-UDP packet,
whether the top MPLS label is upstream-assigned or
downstream-assigned.

Draft-ietf-mpls-in-udp-10 has the following text:

=C2=A0 =C2=A0 =C2=A0As for whether the top label in the MPLS label stack is=
=C2=A0 =C2=A0 =C2=A0downstream-assigned or upstream-assigned, it SHOULD
be
determined
=C2=A0 =C2=A0 =C2=A0based on the tunnel destination IP address.=C2=A0 That = is
to say, if
the
=C2=A0 =C2=A0 =C2=A0destination IP address is a multicast address, the
top label
SHOULD
=C2=A0 =C2=A0 =C2=A0be upstream-assigned, otherwise if the destination
IP
address
is a
=C2=A0 =C2=A0 =C2=A0unicast address, it SHOULD be downstream-assigned.

I believe this text is incorrect, as it is inconsistent
with RFCs
5332 and 5331, which are the RFCs that introduce the
notion of "upstream-assigned labels".

Of particular relevance is Section 3 of RFC 5332, which
discusses how one determines, when an MPLS packet is
being sent through a tunnel, whether the top label of
the encapsulated packet is upstream or
downstream.

To make a long story short, basically what that section
says is that the tunnel must be known a priori to have
one of the following three
properties:

1. The top label of all encapsulated packets is
downstream-
assigned.

2. The top label of all encapsulated packets is
upstream-
assigned.

3. The top label of some encapsulated packets is
downstream-assigned, but the top label of some
encapsulated packets is
upstream-assigned.

How it is known which property the tunnel has is out of
scope (i.e., it depends on the higher layer).

Only tunnels with the third property need to contain a
codepoint that specifies whether the label is
upstream-assigned or
downstream-assigned.

So what does all this mean for the mpls-in-udp encapsulation?
I would suggest that you say the following:

- Have IANA assign a single UDP port number for MPLS-in-UDP.

- In the absence of any other knowledge, a UDP packet
with the MPLS-in-UDP port number in destination port
field is assumed to be carrying an MPLS packet whose top
label is
downstream-assigned.

- Higher layers may negotiate the use of particular UDP
tunnels to carry MPLS packets whose top labels are
upstream-assigned.=C2=A0 The procedures for such negotiation
are out of scope of the current document.=C2=A0 By a
"particluar UDP tunnel", I mean a UDP tunnel with a
particular <source IP address, destination IP address,
destination
port> triple.=C2=A0 The destination port may be the standard
(IANA-assigned) port number for MPLS-in-UDP, but it may
also be any other port number that is negotiated by the higher
layer.

- For a particular UDP tunnel (i.e., a particular
<source address, destination address, destination port>
triple), all the encapsulated MPLS packets must have the
same type of label at the top
of
the stack.

- Remove any suggestion that the type of the label can
be inferred from the type of the IP destination address.

I think this will make the draft compatible with RFCs
5332 and 5331, and it does not require IANA to allocate
a second port
number.

Note, by the way, that if we are going to allow the
higher layers to negotiate the destination port number,
we should probably caution implementers not to hard code
(or hard wire) a particular port
number.

There is one further issue for you to consider.

When an MPLS packet with an upstream-assigned label is
received through a particular tunnel, the "context" in
which the label is interpreted is determined by the IP
address of the
root of
the tunnel.
(See section 7 of RFC5331.)=C2=A0 For a UDP tunnel, this
would mean that the label space is identified by the Source IP
address.
So if a particular router is using MPLS-in-UDP to send
MPLS packets with upstream-assigned labels, it's really
important for it to use the same IP
source
address in all
MPLS-in-UDP packets that have the same destination address.
I
can't
quite tell whether this is compatible with item e. in
section
3.1 of the draft.

Eric







--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--089e0160b506108022050db8112f-- From nobody Wed Jan 28 09:09:45 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7621A8757 for ; Wed, 28 Jan 2015 09:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIA-xIRMliBA for ; Wed, 28 Jan 2015 09:09:36 -0800 (PST) Received: from smtp06.msg.oleane.net (smtp06.msg.oleane.net [62.161.4.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2148C1A870B for ; Wed, 28 Jan 2015 09:09:34 -0800 (PST) Received: from MGosseDellM6800 (LMontsouris-656-1-5-162.w80-12.abo.wanadoo.fr [80.12.94.162]) (authenticated) by smtp06.msg.oleane.net (MSA) with ESMTP id t0SH4h86003535 for ; Wed, 28 Jan 2015 18:04:43 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Wed, 28 Jan 2015 18:09:32 +0100 Message-ID: <004001d03b1d$2f874930$8e95db90$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01D03B25.914D37D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdA7HN29yitbfgDLT6S1UGvVZy+kIQ== Content-Language: fr X-Backend: vm-smtp-sophos21 X-PMX-Spam: Probability=11% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.28.170030 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: Subject: [mpls] MPLS SDN World 2015: Standards versus open source X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 17:09:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0041_01D03B25.914D37D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 17th Edition of MPLS SDN World Congress and the 4th Edition of NFV & SDN Summit, will take place in Paris next 17 to 20 March, 2015. The two events will share a common first day. MPLS SDN World Congress 2015: Standards versus open source, segment routing progress, resilience, protection & restoration, SDN migration, datacenter. NFV & SDN Summit 2015: PoCs reports, orchestration, use cases. More info: http://www.uppersideconferences.com/mpls-sdn/mpls_sdn_2015_agenda_conference _day_1.html ------=_NextPart_000_0041_01D03B25.914D37D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = 17th Edition = of MPLS SDN World = Congress and the = 4th Edition = of NFV & SDN = Summit, will take place in = Paris next 17 to 20 March, 2015. 


The two events will share a = common first day.

 

MPLS SDN World  Congress 2015: Standards versus open = source, segment routing progress, resilience, protection & = restoration, SDN migration, datacenter.


NFV & SDN = Summit 2015:  PoCs reports, = orchestration, use cases.

 

More = info:

http://www.uppersideconferences.com/mpls-sdn/mpls= _sdn_2015_agenda_conference_day_1.html

 

------=_NextPart_000_0041_01D03B25.914D37D0-- From nobody Wed Jan 28 09:35:27 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CB11A00F6 for ; Wed, 28 Jan 2015 09:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqhu6BqDapn9 for ; Wed, 28 Jan 2015 09:35:19 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ACD41A1B69 for ; Wed, 28 Jan 2015 09:35:17 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0SHZDjf023624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2015 12:35:15 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t0SHZDjf023624 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1422466515; bh=ISJ8at5LR+3/PziimlkZcVYhyqQ=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=itnMrSR8DnYPtrM9ypdHFN8Tmfl3upTVwIe1yUVhffAZv2aCJx+5wEaaA6nBLOvV7 BYXi8IMcjUIHSvk4xz27Jo6gn7TWEzX3sSu3/q0GFDI4YaVFX9say/254Eay7BMD9Z aXKVlRIRvkcQOvi9pmp8o8+ibKLUejYjFujLDJj8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t0SHZDjf023624 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd53.lss.emc.com (RSA Interceptor); Wed, 28 Jan 2015 12:32:12 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0SHZ1s5022872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Jan 2015 12:35:02 -0500 Received: from MXHUB207.corp.emc.com (10.253.68.33) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 28 Jan 2015 12:35:01 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB207.corp.emc.com ([10.253.68.33]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 12:35:01 -0500 From: "Black, David" To: Alia Atlas , Loa Andersson Thread-Topic: [mpls] Advice on draft-ietf-mpls-in-udp Thread-Index: AdA7ILpwQCR8qA8DRgCykgpAqZZg6A== Date: Wed, 28 Jan 2015 17:34:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.76.191.26] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D2432779493631E810MX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Advice on draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 17:35:26 -0000 --_000_CE03DB3D7B45C245BCA0D2432779493631E810MX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9hLA0KDQpGaXJzdCBvZiBhbGwsIHRoYW5rcyBmb3IgZXZlcnl0aGluZyB5b3XigJl2ZSBi ZWVuIGRvaW5nIGZvciB0aGlzIGRyYWZ0LiAgSW4gc29tZSBzZW5zZSwgd2UgdGhyZXcgeW91IGlu IGF0IHRoZSBkZWVwIGVuZCBvZiB0aGUgcG9vbCB3aGVuIHlvdSBiZWNhbWUgc2hlcGhlcmQgbGF0 ZSBpbiB0aGUgcHJvY2VzcywgYWx0aG91Z2ggdGhhdOKAmXMgYmVlbiB0aGUgZXhwZXJpZW5jZSBv ZiBtb3N0IG9mIHVzIHdob+KAmXZlIGJlZW4gd29ya2luZyBvbiB0aGlzIGRyYWZ0IGZvciB0aGUg cGFzdCA2IG1vbnRoczsgdGhlcmXigJlzIGEgbG90IG1vcmUgZ29pbmcgb24gaGVyZSB0aGFuIGFu eSBvZiB1cyBpbml0aWFsbHkgZXhwZWN0ZWQuDQoNClRoYXQgc2FpZCwgQWxpYeKAmXMgdGFrZSBv biB0aGlzIGRyYWZ04oCZcyBzdGF0ZSBhbmQgdGhlIHRocmVhZCBiZWxvdyBtYXRjaGVzIG1pbmUg LSB0aGVyZeKAmXMgYSBidW5jaCBvZiBzbWFsbCBjbGFyaWZpY2F0aW9ucyBpbiBwcm9ncmVzcyBi dXQgbm90aGluZyBiaWcuICBJbiB0aGUgdGhyZWFkIGJlbG93LCBYaWFvaHUgYW5kIEkgd2luZCB1 cCBhZ3JlZWluZyB0aGF0IHRoZXJlIGlzIG5vdCBhbiBMM1ZQTi1yZWxhdGVkIHByb2JsZW0gdGhh dCB0aGlzIGRyYWZ0IG5lZWRzIHRvIGFkZHJlc3MuICBUaGUgcmVzdWx0aW5nIGNsYXJpZmljYXRp b24gaW4gdGhlIGFkZGl0aW9uYWwgdGV4dCBpcyBmYWlybHkgc2ltcGxlIChhbmQgd2FzIGFsd2F5 cyBpbnRlbmRlZCBieSB0aGUgY3VycmVudCB0ZXh0KSAtIGFuIE1QTFMtaW4tVURQIHR1bm5lbCBp cyBpZGVudGlmaWVkIGJ5IGl0cyBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIElQIGFkZHJlc3NlcyAo SVB2NiBpbiB0aGUgYWRkZWQgdGV4dCBiZWxvdyBjb3VydGVzeSBvZiB3aGVyZSBpdCBvY2N1cnMg aW4gdGhlIGRyYWZ0KS4gIFRoZSBVRFAgcG9ydHMgZG8gbm90IHByb3ZpZGUgYW55IGFkZGl0aW9u YWwgaWRlbnRpZmljYXRpb24gYmVjYXVzZSB0aGUgZGVzdGluYXRpb24gcG9ydCBpcyBhIGNvbnN0 YW50LCBhbmQgdGhlIHNvdXJjZSBwb3J0IGlzIHVzZWQgc29sZWx5IHRvIGluamVjdCBlbnRyb3B5 IChlLmcuLCBmb3IgbXVsdGlwYXRoaW5nKS4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQpGcm9tOiBt cGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxpYSBBdGxh cw0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI4LCAyMDE1IDEwOjMyIEFNDQpUbzogTG9hIEFu ZGVyc3Nvbg0KQ2M6IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gQWR2aWNlIG9u IGRyYWZ0LWV0Zi1tcGxzLWluLXVkcA0KDQpIaSBMb2EsDQoNCk9uIFdlZCwgSmFuIDI4LCAyMDE1 IGF0IDE6MDEgQU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4g d3JvdGU6DQpGb2xrcywNCg0KVGhpcyBtYWlsIHRvIEFsaWEgKGFzIHJlc3BvbnNpYmxlIEFEKSwg QWRyaWFuICh3aXRoIGV4cGVyaWVuY2UgZnJvbSBwcm9ncmVzc2luZyBhIGxvdCBvZiBkb2N1bWVu dHMpIGFuZCB0aGUgbXBscyB3ZyBjby1jaGFpcnMuDQoNCkkgYmVjYW1lIERvY3VtZW50IFNoZXBo ZXJkIHJhdGhlciBsYXRlIGluIHRoZSBwcm9jZXNzLiBSb3NzIGRpZCB0aGUNCiJyZXBlYXRlZCB3 Z2xjIiBvbiB0aGlzIGRyYWZ0IG9uIHZlcnNpb24gLTA3LCB0aGUgZG9jdW1lbnQgd2FzIHVwZGF0 ZWQNCmFmdGVyIHdnbGMgYXMgdmVyc2lvbiAtMDguIEFmdGVyIHRoYXQgdGhlcmUgaGFzIGJlZW4g ZGlzY3Vzc2lvbnMgb24NCmRpZmZlcmVudCBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQgYW5kIGl0IGhh cyBiZWVuIHVwZGF0ZWQgdHdpY2UuIEFuZCBhDQp0aGlyZCB2ZXJzaW9uICgtMTEpIGlzIGluIHRo ZSBwaXBlLiBJJ3ZlIG5vdCBzZWVuIHZlcnNpb24gLTExIHlldCwgYnV0DQphbW9uZyB0aGUgYXV0 aG9ycyB0aGVyZSBhcmUgdGFsayBhYm91dCAiYnJhbmQgbmV3IGlzc3VlcyIuDQoNCk15IGNvbmNl cm5zIGFyZSB0aGF0IHdlIGFyZSBpbnRyb2R1Y2luZyB0byBiaWcgY2hhbmdlcyB3aXRob3V0IGtl ZXBpbmcNCnRoZSAgd29ya2luZyBncm91cCBpbiB0aGUgbG9vcC4gQ2FuIHlvdSBoZWxwIGV2YWx1 YXRlIGlmIHdlIG5lZWQgdG8gdGFrZQ0KdGhlIGRvY3VtZW50IHRocm91Z2ggYSBuZXcgd2dsYywg b3IgaWYgd2UgYXJlIGdvb2QgdG8gZ28/DQoNCkkgYW0ga2VlcGluZyBhIGNsb3NlIGV5ZSBvbiB0 aGlzIHF1ZXN0aW9uLiBTbyBmYXIsIEkgdGhpbmsgdGhhdCB3ZSBhcmUgZ29vZCB0bw0KZ28gb25j ZSB0aGUgZGlzY3Vzc2VzIGFuZCB1cHN0cmVhbSBsYWJlbHMgcXVlc3Rpb25zIGFyZSBhZGRyZXNz ZWQuDQoNCk9uIHRoZSBsYXR0ZXIsICBJIGJlbGlldmUgaXQgaXMgcmVzb2x2aW5nIHRvIGJlaGF2 aW9yIGFzIHNwZWNpZmllZCBpbiB0aGUgZHJhZnQNCmZyb20gV0dMQyAtIGJ1dCB3aXRoIHRoZSBj bGFyaWZpY2F0aW9uIHRoYXQgaW4gdGhlIGZ1dHVyZSBzb21lIHNpZ25hbGxpbmcgbWlnaHQNCmlu ZGljYXRlIHdoZXRoZXIgdGhlIGxhYmVscyBhcmUgbm90IHVwc3RyZWFtIGFzc2lnbmVkIGV2ZW4g aWYgdGhlIElQIGRlc3RpbmF0aW9uDQphZGRyZXNzIGlzIG11bHRpY2FzdC4NCg0KVGhlIHR3byBk aXNjdXNzZXMgYXJlIG5vdCwgSU1ITywgY2hhbmdpbmcgYW55IHRlY2huaWNhbCBkZXRhaWxzIGJ1 dCByYXRoZXINCmNsYXJpZnlpbmcgZGV0YWlscy4gIEZvciBpbnN0YW5jZSwgdGhlcmUgaXNuJ3Qg YSBsaXN0ZW5lciBhdCB0aGUgVURQIHNvdXJjZSBwb3J0DQpvbiB0aGUgaW5ncmVzcyBvZiB0aGUg VURQIHR1bm5lbC4gIEZvciBhbm90aGVyIGluc3RhbmNlLCBjbGFyaWZ5aW5nIHRoZSBEVExTDQpi ZWhhdmlvciBpbiB0ZXJtcyBvZiBudW1iZXIgb2YgZXhwZWN0ZWQgc2Vzc2lvbnMuDQoNCkkgZG8g aG9wZSB0byBzZWUgYW4gdXBkYXRlZCBkcmFmdCB0aGF0IGFkZHJlc3NlcyB0aGUgZGlzY3Vzc2Vz IHZlcnkgc29vbg0KYW5kIHdvdWxkIGVuY291cmFnZSBwcm9kZGluZyBieSB0aGUgc2hlcGhlcmQg Oy0pDQoNClRoYW5rcywNCkFsaWENCg0KL0xvYQ0KDQpPbiAyMDE1LTAxLTI4IDA5OjE0LCBYdXhp YW9odSB3cm90ZToNCkhpIERhdmlkLA0KDQpUaGUgdGV4dCBsb29rcyBnb29kIHRvIG1lLiBUaGFu a3MgZm9yIHlvdXIgZXhjZWxsZW50IHdvcmsuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJsYWNrLCBEYXZpZCBbbWFpbHRvOmRhdmlk LmJsYWNrQGVtYy5jb208bWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20+XQ0KU2VudDogVHVlc2Rh eSwgSmFudWFyeSAyNywgMjAxNSA3OjUxIFBNDQpUbzogWHV4aWFvaHUNCkNjOiBMb2EgQW5kZXJz c29uOyBkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPjsgYWRyaWFuQG9sZGRvZy5jby51azxtYWls dG86YWRyaWFuQG9sZGRvZy5jby51az47DQpCbGFjaywgRGF2aWQNClN1YmplY3Q6IE1QTFMvVURQ OiBTZWN0aW9uIDMuMSBpdGVtIDMgLSByZXdyaXRlDQoNCkhlcmUncyBteSBpbml0aWFsIGF0dGVt cHQgdG8gY2xhcmlmeSBTZWN0aW9uIDMuMSBpdGVtIDMgd3J0IEVyaWMgUm9zZW4ncyBjb25jZXJu DQp0aGF0IHRoZSBzb3VyY2UgSVB2NiBhZGRyZXNzIGlzIHRoZSBjb250ZXh0IGlkZW50aWZpZXIg Zm9yIHVwc3RyZWFtLWFzc2lnbmVkDQpjb250ZXh0IGxhYmVscyBmb3IgbXVsdGljYXN0IHRyYWZm aWMuICBJIGZvdW5kIGEgd2F5IHRvIGRvIHRoaXMgd2l0aG91dCB0YWxraW5nDQphYm91dCAicG9p bnQiIG9yICJtdWx0aXBvaW50IiBjaGFyYWN0ZXJpc3RpY3Mgb2YgdHVubmVsIGluZ3Jlc3MvZWdy ZXNzLg0KDQpPTEQNCiAgICBlLiAgQW4gTVBMUy1pbi1VRFAgc2VuZGVyIFNIT1VMRCB1c2UgZGlm ZmVyZW50IElQdjYgYWRkcmVzc2VzIGZvcg0KICAgICAgICBlYWNoIE1QTFMtaW4tVURQIHR1bm5l bCB0aGF0IHVzZXMgVURQIHplcm8tY2hlY2tzdW0gbW9kZQ0KICAgICAgICByZWdhcmRsZXNzIG9m IHJlY2VpdmVyIGluIG9yZGVyIHRvIHN0cmVuZ3RoZW4gdGhlIHJlY2VpdmVyJ3MNCiAgICAgICAg Y2hlY2sgb2YgdGhlIElQdjYgc291cmNlIGFkZHJlc3MuICBXaGVuIHRoaXMgaXMgbm90IHBvc3Np YmxlLCBpdA0KICAgICAgICBpcyBSRUNPTU1FTkRFRCB0byB1c2UgZWFjaCBzb3VyY2UgSVB2NiBh ZGRyZXNzIGZvciBhcyBmZXcgVURQDQogICAgICAgIHplcm8tY2hlY2tzdW0gbW9kZSBNUExTLWlu LVVEUCB0dW5uZWxzIGFzIGlzIGZlYXNpYmxlLg0KTkVXDQogICAgZS4gIEFuIE1QTFMtaW4tVURQ IHNlbmRlciBTSE9VTEQgdXNlIGRpZmZlcmVudCBJUHY2IGFkZHJlc3NlcyBmb3INCiAgICAgICAg ZWFjaCBNUExTLWluLVVEUCB0dW5uZWwgdGhhdCB1c2VzIFVEUCB6ZXJvLWNoZWNrc3VtIG1vZGUN CiAgICAgICAgcmVnYXJkbGVzcyBvZiByZWNlaXZlciBpbiBvcmRlciB0byBzdHJlbmd0aGVuIHRo ZSByZWNlaXZlcidzDQogICAgICAgIGNoZWNrIG9mIHRoZSBJUHY2IHNvdXJjZSBhZGRyZXNzIChp LmUuLCB0aGUgc2FtZSBJUHY2IHNvdXJjZQ0KICAgICAgICBhZGRyZXNzIFNIT1VMRCBOT1QgYmUg dXNlZCB3aXRoIG1vcmUgdGhhbiBvbmUgSVB2NiBkZXN0aW5hdGlvbg0KICAgICAgICBhZGRyZXNz LCBpbmRlcGVuZGVudCBvZiB3aGV0aGVyIHRoYXQgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhDQog ICAgICAgIHVuaWNhc3Qgb3IgbXVsdGljYXN0IGFkZHJlc3MpLiAgV2hlbiB0aGlzIGlzIG5vdCBw b3NzaWJsZSwgaXQNCiAgICAgICAgaXMgUkVDT01NRU5ERUQgdG8gdXNlIGVhY2ggc291cmNlIElQ djYgYWRkcmVzcyBmb3IgYXMgZmV3IFVEUA0KICAgICAgICB6ZXJvLWNoZWNrc3VtIG1vZGUgTVBM Uy1pbi1VRFAgdHVubmVscyAoaS5lLiwgd2l0aCBhcyBmZXcNCiAgICAgICAgZGVzdGluYXRpb24g SVB2NiBhZGRyZXNzZXMpIGFzIGlzIGZlYXNpYmxlLg0KDQpIb3cgZG9lcyB0aGF0IGxvb2s/DQoN ClRoYW5rcywNCi0tRGF2aWQNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBYdXhp YW9odSBbbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5j b20+XQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDExOjAxIEFNDQpUbzogQmxhY2ss IERhdmlkDQpDYzogTG9hIEFuZGVyc3NvbjsgZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29scy5p ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47DQph ZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPg0KU3ViamVjdDog UmU6IFttcGxzXSBJRCBUcmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6DQo8ZHJhZnQtaWV0Zi1t cGxzLWluLXVkcC0gMDkudHh0Pg0KDQpIaSBEYXZpZCwNCg0KQWZ0ZXIgYSBjYXJlZnVsIGNvbnNp ZGVyYXRpb24sIEkgdGhpbmsgaXQgc2hvdWxkIGJlIE9LIGZvciBhbg0KZW5jYXBzdWxhdG9yIHRv IHVzZSBkaWZmZXJlbnQgdHVubmVsIHNvdXJjZSBhZGRyZXNzZXMgZm9yIGRpZmZlcmVudA0KVURQ IHR1bm5lbHMgaWYgdGhlc2UgdHVubmVscyBhcmUgbWFudWFsbHkgY29uZmlndXJlZC4gU29ycnkg Zm9yIHRoYXQNCmNvbmZ1c2lvbi4gSW4gYWRkaXRpb24sIHNpbmNlIGl0ZW0gZSBoYXMgYSBzZW50 ZW5jZSAiV2hlbiB0aGlzIGlzIG5vdA0KcG9zc2libGUsLi4uIiwgSSBiZWxpZXZlIHRoZSBjdXJy ZW50IHRleHQgaXMgT0sgZm9yIHRoZSBQMlAgVURQIHR1bm5lbA0KY2FzZS4gSXQgc2VlbXMgdGhh dCB5b3Ugb25seSBuZWVkIHRvIGFkZCBzb21lIHRleHQgYWJvdXQgdGhlIFAyTVAgVURQDQp0dW5u ZWwsIGp1c3QgYXMgd2hhdCB5b3UgaGF2ZSBtZW50aW9uZWQgYmVmb3JlLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K 5Y+R5Lu25Lq6OiBCbGFjaywgRGF2aWQgW2RhdmlkLmJsYWNrQGVtYy5jb208bWFpbHRvOmRhdmlk LmJsYWNrQGVtYy5jb20+XQ0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0MeaciDI25pelIDE4OjQwDQrm lLbku7bkuro6IFh1eGlhb2h1DQrmioTpgIE6IExvYSBBbmRlcnNzb247IGRyYWZ0LWlldGYtbXBs cy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy1pbi11ZHBAdG9v bHMuaWV0Zi5vcmc+Ow0KYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5j by51az47IEJsYWNrLCBEYXZpZA0K5Li76aKYOiBSRTogW21wbHNdIElEIFRyYWNrZXIgU3RhdGUg VXBkYXRlIE5vdGljZToNCjxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLSAwOS50eHQ+DQoNCkZpcnN0 LCB0aGlzIGlzIGEgYnJhbmQgbmV3IGNvbmNlcm4gdGhhdCBoYXMgbm90IGJlZW4gcmFpc2VkIHBy ZXZpb3VzbHkNCi0gaXQncyBkZWZpbml0ZWx5IGRpZmZlcmVudCBmcm9tIEVyaWMgUm9zZW4ncyBj b25jZXJuLCB3aGljaCBJDQp1bmRlcnN0YW5kIGFuZCB3aWxsIHdyaXRlIGNsYXJpZnlpbmcgdGV4 dCBmb3IuDQoNClNlY29uZCwgYSBWUE4gb3VnaHQgdG8gYmUgc2VyaW91c2x5IGNvbmNlcm5lZCB3 aXRoIG1pc2RlbGl2ZXJ5DQpwcmV2ZW50aW9uLCBhbmQgdGhlcmUncyB0ZXh0IGluIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9uDQp0aGlzIHRvcGljLiAgSXRlbSBlIGluIHNl Y3Rpb24gMy4xIGlzIG9uZSBvZiB0aGUgaW1wb3J0YW50IHRoaW5ncyB0aGF0DQp0aGlzIGRyYWZ0 IGRvZXMgdG93YXJkcyBtaXNkZWxpdmVyeSBwcmV2ZW50aW9uIHdoZW4gVURQIHplcm8gY2hlY2tz dW1zIGFyZQ0KdXNlZCB3aXRoIElQdjYuDQoNCk15IHN0YXJ0aW5nIHBvaW50IHdvdWxkIGJlIC0g aWYgTDNWUE5zIGhhdmUgYSBwcm9ibGVtIHdpdGggdXNpbmcgYQ0KZGlmZmVyZW50DQpJUHY2IGFk ZHJlc3MgYXMgdGhlIHNvdXJjZSBvZiBlYWNoIHR1bm5lbCwgdGhlbiB0aGF0J3Mgb25lIG1vcmUg cmVhc29uDQpmb3IgTDNWUE5zIHRvIHVzZSBVRFAgY2hlY2tzdW1zIHdpdGggSVB2Ni4NCg0KSSds bCBkZWZlciB0byBMM1ZQTiBleHBlcnRzIG9uIGhvdyBMM1ZQTiBhZGRyZXNzIHNpZ25hbGluZyBj dXJyZW50bHkNCndvcmtzIGFuZCB0aGUgaW1wYWN0cyBvZiBhZGRpdGlvbmFsIElQdjYgYWRkcmVz c2VzIG9uIHRoYXQuICBJJ20gbm90DQp0aGUgcmlnaHQgcGVyc29uIHRvIHdyaXRlIEwzVlBOLXNw ZWNpZmljIHRleHQgKG9uIHRoaXMgb3IgYW55IG90aGVyIHRvcGljKS4NCg0KVGhhbmtzLA0KLS1E YXZpZA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFh1eGlhb2h1IFttYWlsdG86 eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT5dDQpTZW50OiBN b25kYXksIEphbnVhcnkgMjYsIDIwMTUgNDo0MiBBTQ0KVG86IEJsYWNrLCBEYXZpZA0KQ2M6IExv YSBBbmRlcnNzb247IGRyYWZ0LWlldGYtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+Ow0KYWRyaWFuQG9sZGRvZy5j by51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4NClN1YmplY3Q6IFJFOiBbbXBsc10gSUQg VHJhY2tlciBTdGF0ZSBVcGRhdGUgTm90aWNlOg0KPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtIDA5 LnR4dD4NCg0KSGkgRGF2aWQsDQoNCkp1c3QgdGFrZSB0aGUgQkdQL01QTFMgSVAgVlBOIHdpdGgg UlIgZW5hYmxlZCBhcyBhbiBleGFtcGxlLCBpZiBpdA0KcmVxdWlyZXMgdGhlIHR1bm5lbCBlbmNh cHN1bGF0b3IgKGkuZS4sIGluZ3Jlc3MgUEUpIHRvIHVzZSBkaWZmZXJlbnQNCnNvdXJjZSBJUCBh ZGRyZXNzZXMgZm9yIGRpZmZlcmVudCB0dW5uZWxzLCBzaG91bGQgaW5ncmVzcyBQRXMgbm90aWZ5 DQp0aGUgYWRkcmVzcyB0byBiZSB1c2VkIGFzIHRoZSB0dW5uZWwgc291cmNlIGFkZHJlc3MgdG8g ZWFjaCBlZ3Jlc3MNClBFLiBPdGhlcndpc2UsIGhvdyBjb3VsZCBlZ3Jlc3MgUEVzIHZlcmlmeSB0 aGF0IHRoZSBwYWNrZXRzIGFyZSByZWNlaXZlZA0KZnJvbSB2YWxpZCBpbmdyZXNzIFBFcz8NCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog QmxhY2ssIERhdmlkIFttYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86ZGF2aWQuYmxh Y2tAZW1jLmNvbT5dDQpTZW50OiBTYXR1cmRheSwgSmFudWFyeSAyNCwgMjAxNSAzOjE1IEFNDQpU bzogWHV4aWFvaHUNCkNjOiBMb2EgQW5kZXJzc29uOyBkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRv b2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3Jn PjsNCmFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+Ow0KQmxh Y2ssIERhdmlkDQpTdWJqZWN0OiBSRTogW21wbHNdIElEIFRyYWNrZXIgU3RhdGUgVXBkYXRlIE5v dGljZToNCjxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA5LnR4dD4NCg0KWGlhb2h1LA0KDQpJJ20g bWlzc2luZyBzb21ldGhpbmcgaGVyZS4NCg0KRXJpYydzIGNvbmNlcm4gc3RlbXMgZnJvbSB0aGUg cmVxdWlyZW1lbnQgdGhhdCB3aGVuDQp1cHN0cmVhbS1hc3NpZ25lZA0KbGFiZWxzDQphcmUgaW4g dXNlLCB0aGUgc291cmNlIElQIGFkZHJlc3MgaWRlbnRpZmllcyB0aGUgbGFiZWwgY29udGV4dCwN CmFuZCBoZW5jZQ0KdGhhdA0Kc291cmNlIElQIGFkZHJlc3MgaGFzIHRvIGJlIGNvbW1vbiBhY3Jv c3MgYWxsIHRyYWZmaWMgdG8gYSBkZXN0aW5hdGlvbi4NCkVyaWMgd2FzDQpjb25jZXJuZWQgdGhh dCBTZWN0aW9uIDMuMSBpdGVtIGUgbWlnaHQgY29uZmxpY3Qgd2l0aCB0aGF0IHJlcXVpcmVtZW50 Lg0KDQpUaGUgY2xhcmlmeWluZyB0ZXh0IHdpbGwgaW5kaWNhdGUgdGhhdCB0aGVyZSBpcyBubyBw cm9ibGVtIGhlcmU7DQp3aGVuIHRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIGlzIGEgbXVsdGlj YXN0IGFkZHJlc3MsIHRoZSBzZW5kZXINCnNlbmRzIG9uZQ0KcGFja2V0LA0KdGhlDQpyZWNlaXZl cnMgZWFjaCBnZXQgYSBjb3B5IGFuZCB0aGF0IDE6biBtdWx0aWNhc3QgZmFuLW91dCBpcyBhDQpz aW5nbGUNCiJ0dW5uZWwiIHdydA0KU2VjdGlvbiAzLjEgaXRlbSBlLg0KRXZlcnkgcGFja2V0IGRl bGl2ZXJlZCB0byBldmVyeSByZWNlaXZlciBpbiB0aGF0IHR1bm5lbCB1c2VzIHRoZQ0Kc2FtZQ0K c291cmNlDQpJUA0KYWRkcmVzcywgc28gdGhlcmUncyBhIHNpbmdsZSBsYWJlbCBjb250ZXh0Lg0K DQpJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBSUEYgYW5kIHNpZ25hbGluZyBjb25jZXJucyBiZWxv dy4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVh d2VpLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyMiwgMjAxNSA4OjQwIFBNDQpUbzog QmxhY2ssIERhdmlkDQpDYzogTG9hIEFuZGVyc3NvbjsgZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0 b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9y Zz47DQphZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPg0KU3Vi amVjdDogUkU6IFttcGxzXSBJRCBUcmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6DQo8ZHJhZnQt aWV0Zi1tcGxzLWluLXVkcC0gMDkudHh0Pg0KDQpIaSBEYXZpZCwNCg0KSSdtIGxvb2tpbmcgZm9y d2FyZGluZyB0byBzZWVpbmcgeW91ciB1cGRhdGVkIHRleHQuIEJ5IHRoZSB3YXksDQpJIGhvcGUg eW91IGNvdWxkIHRha2UgaW50byBhY2NvdW50IHBvdGVudGlhbCBjb25jZXJucyBhcyBmb2xsb3dz Og0KDQoxKSB3aWxsIGl0IG1ha2UgdGhlIFJQRiBjaGVjayBwZXJmb3JtZWQgYnkgdHVubmVsIGRl Y2Fwc3VsYXRvcnMNCihlLmcuLCB0byBkZXRlcm1pbmUgdGhlIHVwc3RyZWFtIFBFIG9mIHRoZSBy ZWNlaXZlZCBtdWx0aWNhc3QNCnBhY2tldCBpbiB0aGUgbXVsdGljYXN0IFZQTiBjb250ZXh0KSBk aWZmaWN1bHQgd2hlbiByZXF1aXJpbmcgYQ0KdHVubmVsIGVuY2Fwc3VsYXRvciB0byB1c2UgZGlm ZmVyZW50IHR1bm5lbCBzb3VyY2UgYWRkcmVzc2VzIGZvcg0KZGlmZmVyZW50IHR1bm5lbHM7DQoy KSBkb2VzIGl0IHJlcXVpcmUgdGhlIGVuY2Fwc3VsYXRvciBvZiBhIHBhcnRpY3VsYXIgTVBMUy1p bi1VRFANCnR1bm5lbCB0byBub3RpZnkgdGhlIGRlY2Fwc3VsYXRvcihzKSBvZiBpdHMgcG9zc2li bGUgYWRkcmVzc2VzDQp0byBiZSB1c2VkIGFzIHRoZSBzb3VyY2UgYWRkcmVzcyBvZiB0aGF0IHR1 bm5lbC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogQmxhY2ssIERhdmlkIFttYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86 ZGF2aWQuYmxhY2tAZW1jLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyMiwgMjAxNSAx MToxNSBQTQ0KVG86IFh1eGlhb2h1DQpDYzogTG9hIEFuZGVyc3NvbjsgZHJhZnQtaWV0Zi1tcGxz LWluLXVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29s cy5pZXRmLm9yZz47DQphZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNv LnVrPjsNCkJsYWNrLCBEYXZpZA0KU3ViamVjdDogUkU6IFttcGxzXSBJRCBUcmFja2VyIFN0YXRl IFVwZGF0ZSBOb3RpY2U6DQo8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wOS50eHQ+DQoNClhpYW9o dSwNClNpbmNlIHRoZSByZXF1aXJlbWVudCBpdGVtIGUgd291bGQgaW50cm9kdWNlIGFkZGl0aW9u YWwgYW5kDQp1bmV4cGVjdGVkIGNvbXBsZXhpdGllcyBhbmQgZGlmZmljdWx0aWVzIGZvciB0aGUg ZGVwbG95bWVudCwNCkkgc3VnZ2VzdCB0aGF0IGl0J2QgYmV0dGVyIHRvIHJlbW92ZSB0aGF0IGl0 ZW0uDQoNCkkgc3Ryb25nbHkgZGlzYWdyZWUuICBUaGF0IHJlcXVpcmVtZW50IGlzIGltcG9ydGFu dCB0byB0aGUNCm92ZXJhbGwgZGVzaWduDQpnb2FsIG9mDQpyZXF1aXJpbmcgYW4gb2Zmc2V0dGlu ZyBjb3JydXB0aW9uIHRvIGNhdXNlIG1pc2RlbGl2ZXJ5IChpLmUuLA0KYSBzaW5nbGUNCmNvcnJ1 cHRpb24NCnNob3VsZCB1c3VhbGx5IG5vdCByZXN1bHQgaW4gbWlzZGVsaXZlcnkpLg0KDQpUaGVy ZSBpcyBub3QgYW4gYWN0dWFsIHByb2JsZW0gaGVyZSAtIGl0ZW0gZSBpcyBjb3JyZWN0IHdydA0K RXJpYydzIGNvbmNlcm4sDQpidXQgbm90DQpleHBsYWluZWQgY2xlYXJseS4gICAgSSBjYW4gd3Jp dGUgdGhlIHNlbnRlbmNlIG9yIHR3byB0aGF0IHdpbGwgYmUNCm5lZWRlZCB0bw0KY2xhcmlmeQ0K aG93IHJlcXVpcmVtZW50IGUgYXBwbGllcyB0byBQMk1QIFVEUCB0dW5uZWxzIChpLmUuLA0KZGVz dGluYXRpb24gSVAgYWRkcmVzcw0KaXMgYQ0KbXVsdGljYXN0IGFkZHJlc3MpICphZnRlciogdGhl IHVwc3RyZWFtIHZzLiBkb3duc3RyZWFtIGxhYmVsDQphc3NpZ25tZW50IGRpc2N1c3Npb24gaXMg c29ydGVkIG91dC4NCkJ5IHRoZSB3YXksIEkgZmVlbCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gdW5p Zm9ybWx5IHJlcGxhY2UNCiJNUExTLWluLVVEUCByZWNlaXZlci9yZWNlaXZlciBub2RlIiBhbmQg Ik1QTFMtaW4tVURQDQpzZW5kZXIiIGJ5ICJ0dW5uZWwgZGVjYXBzdWxhdG9yIiBhbmQgInR1bm5l bCBlbmNhcHN1bGF0b3IiDQpyZXNwZWN0aXZlbHkgaW4gdGhlIHdob2xlDQpkb2MuDQoNCkknbGwg ZGVmZXIgdG8gb3RoZXJzIG9uIHRlcm1pbm9sb2d5LCBhbHRob3VnaCBJIGZpbmQgdGhlDQpNUExT LWluLVVEUA0KdGVybWlub2xvZ3kNCmNsZWFyZXIgYmVjYXVzZSBpdCBpbmRpY2F0ZXMgZXhhY3Rs eSB3aGljaCB0dW5uZWwgaXMgaW52b2x2ZWQuDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVh d2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIEph bnVhcnkgMjEsIDIwMTUgMTA6MjIgUE0NClRvOiBCbGFjaywgRGF2aWQNCkNjOiBMb2EgQW5kZXJz c29uOyBkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPjsNCmFkcmlhbkBvbGRkb2cuY28udWs8bWFp bHRvOmFkcmlhbkBvbGRkb2cuY28udWs+DQpTdWJqZWN0OiBSRTogW21wbHNdIElEIFRyYWNrZXIg U3RhdGUgVXBkYXRlIE5vdGljZToNCjxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLSAwOS50eHQ+DQoN CkhpIERhdmlkIGFuZCBhbGwsDQoNClNpbmNlIHRoZSByZXF1aXJlbWVudCBpdGVtIGUgd291bGQg aW50cm9kdWNlIGFkZGl0aW9uYWwgYW5kDQp1bmV4cGVjdGVkIGNvbXBsZXhpdGllcyBhbmQgZGlm ZmljdWx0aWVzIGZvciB0aGUgZGVwbG95bWVudCwNCkkgc3VnZ2VzdCB0aGF0IGl0J2QgYmV0dGVy IHRvIHJlbW92ZSB0aGF0IGl0ZW0uDQoNCkJ5IHRoZSB3YXksIEkgZmVlbCBpdCB3b3VsZCBiZSBi ZXR0ZXIgdG8gdW5pZm9ybWx5IHJlcGxhY2UNCiJNUExTLWluLVVEUCByZWNlaXZlci9yZWNlaXZl ciBub2RlIiBhbmQgIk1QTFMtaW4tVURQDQpzZW5kZXIiIGJ5ICJ0dW5uZWwgZGVjYXBzdWxhdG9y IiBhbmQgInR1bm5lbCBlbmNhcHN1bGF0b3IiDQpyZXNwZWN0aXZlbHkgaW4gdGhlIHdob2xlDQpk b2MuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEJsYWNrLCBEYXZpZCBbbWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb208bWFpbHRvOmRh dmlkLmJsYWNrQGVtYy5jb20+XQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjIsIDIwMTUgMzox NyBBTQ0KVG86IEVyaWMgQyBSb3NlbjsgQWxpYSBBdGxhczsgWHV4aWFvaHUNCkNjOiBMb2EgQW5k ZXJzc29uOyA8bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYWRzQHRvb2xzLmll dGYub3JnPj47DQptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc+Ow0KZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47DQpJSnNicmFuZCBX aWpuYW5kczsgQmxhY2ssIERhdmlkDQpTdWJqZWN0OiBSRTogW21wbHNdIElEIFRyYWNrZXIgU3Rh dGUgVXBkYXRlIE5vdGljZToNCjxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA5LnR4dD4NCg0KRXJp YywNCg0KT24gdGhlIGZ1cnRoZXIgaXNzdWUgLi4uDQpUaGVyZSBpcyBvbmUgZnVydGhlciBpc3N1 ZSBmb3IgeW91IHRvIGNvbnNpZGVyLg0KDQpXaGVuIGFuIE1QTFMgcGFja2V0IHdpdGggYW4gdXBz dHJlYW0tYXNzaWduZWQgbGFiZWwgaXMNCnJlY2VpdmVkIHRocm91Z2ggYSBwYXJ0aWN1bGFyIHR1 bm5lbCwgdGhlICJjb250ZXh0IiBpbg0Kd2hpY2ggdGhlIGxhYmVsIGlzIGludGVycHJldGVkIGlz IGRldGVybWluZWQgYnkgdGhlIElQDQphZGRyZXNzIG9mIHRoZQ0Kcm9vdCBvZg0KdGhlIHR1bm5l bC4NCihTZWUgc2VjdGlvbiA3IG9mIFJGQzUzMzEuKSAgRm9yIGEgVURQIHR1bm5lbCwgdGhpcw0K d291bGQgbWVhbiB0aGF0IHRoZSBsYWJlbCBzcGFjZSBpcyBpZGVudGlmaWVkIGJ5IHRoZSBTb3Vy Y2UgSVANCmFkZHJlc3MuDQpTbyBpZiBhIHBhcnRpY3VsYXIgcm91dGVyIGlzIHVzaW5nIE1QTFMt aW4tVURQIHRvIHNlbmQNCk1QTFMgcGFja2V0cyB3aXRoIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVs cywgaXQncyByZWFsbHkNCmltcG9ydGFudCBmb3IgaXQgdG8gdXNlIHRoZSBzYW1lIElQDQpzb3Vy Y2UNCmFkZHJlc3MgaW4gYWxsDQpNUExTLWluLVVEUCBwYWNrZXRzIHRoYXQgaGF2ZSB0aGUgc2Ft ZSBkZXN0aW5hdGlvbiBhZGRyZXNzLg0KSQ0KY2FuJ3QNCnF1aXRlIHRlbGwgd2hldGhlciB0aGlz IGlzIGNvbXBhdGlibGUgd2l0aCBpdGVtIGUuIGluDQpzZWN0aW9uDQozLjEgb2YgdGhlIGRyYWZ0 Lg0KDQpUaGF0IGlzIGNvbXBhdGlibGUgd2l0aCBpdGVtIGUuLCBidXQgdGhlIGRyYWZ0IGRvZXNu J3Qgc2F5DQptdWNoIGFib3V0IFAyTVANClVEUA0KdHVubmVscy4gIEluIHBhcnRpY3VsYXIsIEkg d291bGQgdmlldyB0aGF0IHNvdXJjZSBJUA0KYWRkcmVzcyBhcyB0aGUgc291cmNlDQpJUA0KYWRk cmVzcyBmb3IgYSAob25lKSBQMk1QIHR1bm5lbCwgYW5kIGl0J3MgcHJvYmFibHkgYSBnb29kDQpp ZGVhIHRvIGFkZCBzb21lDQp0ZXh0DQpvbiBQMk1QIFVEUCB0dW5uZWxzIHRvIG1ha2UgdGhpcyBj bGVhci4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEVyaWMgQyBSb3NlbiBbbWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5ldDxtYWlsdG86ZXJvc2Vu QGp1bmlwZXIubmV0Pl0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMSwgMjAxNSAxMToyNiBB TQ0KVG86IEFsaWEgQXRsYXM7IFh1eGlhb2h1DQpDYzogZXJvc2VuQGp1bmlwZXIubmV0PG1haWx0 bzplcm9zZW5AanVuaXBlci5uZXQ+OyBCbGFjaywgRGF2aWQ7IExvYSBBbmRlcnNzb247DQo8bXBs cy0gYWRzQHRvb2xzLmlldGYub3JnPG1haWx0bzphZHNAdG9vbHMuaWV0Zi5vcmc+PjsgbXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPjsN CmRyYWZ0LWlldGYtbXBscy1pbi0gdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzp1ZHBAdG9vbHMu aWV0Zi5vcmc+OyBJSnNicmFuZA0KV2lqbmFuZHMNClN1YmplY3Q6IFJlOiBbbXBsc10gSUQgVHJh Y2tlciBTdGF0ZSBVcGRhdGUgTm90aWNlOg0KPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtIDA5LnR4 dD4NCg0KRm9sa3MsDQoNCkknbGwgYmUgaGFwcHkgdG8gdGhyb3cgaW4gbXkgbXVjaCBiZWxhdGVk IHR3byBjZW50cy4NCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIGlzc3VlIGF0IGhh bmQgaXMgaG93IG9uZQ0KZGV0ZXJtaW5lcywgd2hlbiByZWNlaXZpbmcgYW4gTVBMUy1pbi1VRFAg cGFja2V0LA0Kd2hldGhlciB0aGUgdG9wIE1QTFMgbGFiZWwgaXMgdXBzdHJlYW0tYXNzaWduZWQg b3INCmRvd25zdHJlYW0tYXNzaWduZWQuDQoNCkRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMTAgaGFz IHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KICAgICBBcyBmb3Igd2hldGhlciB0aGUgdG9wIGxhYmVs IGluIHRoZSBNUExTIGxhYmVsIHN0YWNrIGlzDQogICAgIGRvd25zdHJlYW0tYXNzaWduZWQgb3Ig dXBzdHJlYW0tYXNzaWduZWQsIGl0IFNIT1VMRA0KYmUNCmRldGVybWluZWQNCiAgICAgYmFzZWQg b24gdGhlIHR1bm5lbCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzLiAgVGhhdCBpcw0KdG8gc2F5LCBp Zg0KdGhlDQogICAgIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MgaXMgYSBtdWx0aWNhc3QgYWRkcmVz cywgdGhlDQp0b3AgbGFiZWwNClNIT1VMRA0KICAgICBiZSB1cHN0cmVhbS1hc3NpZ25lZCwgb3Ro ZXJ3aXNlIGlmIHRoZSBkZXN0aW5hdGlvbg0KSVANCmFkZHJlc3MNCmlzIGENCiAgICAgdW5pY2Fz dCBhZGRyZXNzLCBpdCBTSE9VTEQgYmUgZG93bnN0cmVhbS1hc3NpZ25lZC4NCg0KSSBiZWxpZXZl IHRoaXMgdGV4dCBpcyBpbmNvcnJlY3QsIGFzIGl0IGlzIGluY29uc2lzdGVudA0Kd2l0aCBSRkNz DQo1MzMyIGFuZCA1MzMxLCB3aGljaCBhcmUgdGhlIFJGQ3MgdGhhdCBpbnRyb2R1Y2UgdGhlDQpu b3Rpb24gb2YgInVwc3RyZWFtLWFzc2lnbmVkIGxhYmVscyIuDQoNCk9mIHBhcnRpY3VsYXIgcmVs ZXZhbmNlIGlzIFNlY3Rpb24gMyBvZiBSRkMgNTMzMiwgd2hpY2gNCmRpc2N1c3NlcyBob3cgb25l IGRldGVybWluZXMsIHdoZW4gYW4gTVBMUyBwYWNrZXQgaXMNCmJlaW5nIHNlbnQgdGhyb3VnaCBh IHR1bm5lbCwgd2hldGhlciB0aGUgdG9wIGxhYmVsIG9mDQp0aGUgZW5jYXBzdWxhdGVkIHBhY2tl dCBpcyB1cHN0cmVhbSBvcg0KZG93bnN0cmVhbS4NCg0KVG8gbWFrZSBhIGxvbmcgc3Rvcnkgc2hv cnQsIGJhc2ljYWxseSB3aGF0IHRoYXQgc2VjdGlvbg0Kc2F5cyBpcyB0aGF0IHRoZSB0dW5uZWwg bXVzdCBiZSBrbm93biBhIHByaW9yaSB0byBoYXZlDQpvbmUgb2YgdGhlIGZvbGxvd2luZyB0aHJl ZQ0KcHJvcGVydGllczoNCg0KMS4gVGhlIHRvcCBsYWJlbCBvZiBhbGwgZW5jYXBzdWxhdGVkIHBh Y2tldHMgaXMNCmRvd25zdHJlYW0tDQphc3NpZ25lZC4NCg0KMi4gVGhlIHRvcCBsYWJlbCBvZiBh bGwgZW5jYXBzdWxhdGVkIHBhY2tldHMgaXMNCnVwc3RyZWFtLQ0KYXNzaWduZWQuDQoNCjMuIFRo ZSB0b3AgbGFiZWwgb2Ygc29tZSBlbmNhcHN1bGF0ZWQgcGFja2V0cyBpcw0KZG93bnN0cmVhbS1h c3NpZ25lZCwgYnV0IHRoZSB0b3AgbGFiZWwgb2Ygc29tZQ0KZW5jYXBzdWxhdGVkIHBhY2tldHMg aXMNCnVwc3RyZWFtLWFzc2lnbmVkLg0KDQpIb3cgaXQgaXMga25vd24gd2hpY2ggcHJvcGVydHkg dGhlIHR1bm5lbCBoYXMgaXMgb3V0IG9mDQpzY29wZSAoaS5lLiwgaXQgZGVwZW5kcyBvbiB0aGUg aGlnaGVyIGxheWVyKS4NCg0KT25seSB0dW5uZWxzIHdpdGggdGhlIHRoaXJkIHByb3BlcnR5IG5l ZWQgdG8gY29udGFpbiBhDQpjb2RlcG9pbnQgdGhhdCBzcGVjaWZpZXMgd2hldGhlciB0aGUgbGFi ZWwgaXMNCnVwc3RyZWFtLWFzc2lnbmVkIG9yDQpkb3duc3RyZWFtLWFzc2lnbmVkLg0KDQpTbyB3 aGF0IGRvZXMgYWxsIHRoaXMgbWVhbiBmb3IgdGhlIG1wbHMtaW4tdWRwIGVuY2Fwc3VsYXRpb24/ DQpJIHdvdWxkIHN1Z2dlc3QgdGhhdCB5b3Ugc2F5IHRoZSBmb2xsb3dpbmc6DQoNCi0gSGF2ZSBJ QU5BIGFzc2lnbiBhIHNpbmdsZSBVRFAgcG9ydCBudW1iZXIgZm9yIE1QTFMtaW4tVURQLg0KDQot IEluIHRoZSBhYnNlbmNlIG9mIGFueSBvdGhlciBrbm93bGVkZ2UsIGEgVURQIHBhY2tldA0Kd2l0 aCB0aGUgTVBMUy1pbi1VRFAgcG9ydCBudW1iZXIgaW4gZGVzdGluYXRpb24gcG9ydA0KZmllbGQg aXMgYXNzdW1lZCB0byBiZSBjYXJyeWluZyBhbiBNUExTIHBhY2tldCB3aG9zZSB0b3ANCmxhYmVs IGlzDQpkb3duc3RyZWFtLWFzc2lnbmVkLg0KDQotIEhpZ2hlciBsYXllcnMgbWF5IG5lZ290aWF0 ZSB0aGUgdXNlIG9mIHBhcnRpY3VsYXIgVURQDQp0dW5uZWxzIHRvIGNhcnJ5IE1QTFMgcGFja2V0 cyB3aG9zZSB0b3AgbGFiZWxzIGFyZQ0KdXBzdHJlYW0tYXNzaWduZWQuICBUaGUgcHJvY2VkdXJl cyBmb3Igc3VjaCBuZWdvdGlhdGlvbg0KYXJlIG91dCBvZiBzY29wZSBvZiB0aGUgY3VycmVudCBk b2N1bWVudC4gIEJ5IGENCiJwYXJ0aWNsdWFyIFVEUCB0dW5uZWwiLCBJIG1lYW4gYSBVRFAgdHVu bmVsIHdpdGggYQ0KcGFydGljdWxhciA8c291cmNlIElQIGFkZHJlc3MsIGRlc3RpbmF0aW9uIElQ IGFkZHJlc3MsDQpkZXN0aW5hdGlvbg0KcG9ydD4gdHJpcGxlLiAgVGhlIGRlc3RpbmF0aW9uIHBv cnQgbWF5IGJlIHRoZSBzdGFuZGFyZA0KKElBTkEtYXNzaWduZWQpIHBvcnQgbnVtYmVyIGZvciBN UExTLWluLVVEUCwgYnV0IGl0IG1heQ0KYWxzbyBiZSBhbnkgb3RoZXIgcG9ydCBudW1iZXIgdGhh dCBpcyBuZWdvdGlhdGVkIGJ5IHRoZSBoaWdoZXINCmxheWVyLg0KDQotIEZvciBhIHBhcnRpY3Vs YXIgVURQIHR1bm5lbCAoaS5lLiwgYSBwYXJ0aWN1bGFyDQo8c291cmNlIGFkZHJlc3MsIGRlc3Rp bmF0aW9uIGFkZHJlc3MsIGRlc3RpbmF0aW9uIHBvcnQ+DQp0cmlwbGUpLCBhbGwgdGhlIGVuY2Fw c3VsYXRlZCBNUExTIHBhY2tldHMgbXVzdCBoYXZlIHRoZQ0Kc2FtZSB0eXBlIG9mIGxhYmVsIGF0 IHRoZSB0b3ANCm9mDQp0aGUgc3RhY2suDQoNCi0gUmVtb3ZlIGFueSBzdWdnZXN0aW9uIHRoYXQg dGhlIHR5cGUgb2YgdGhlIGxhYmVsIGNhbg0KYmUgaW5mZXJyZWQgZnJvbSB0aGUgdHlwZSBvZiB0 aGUgSVAgZGVzdGluYXRpb24gYWRkcmVzcy4NCg0KSSB0aGluayB0aGlzIHdpbGwgbWFrZSB0aGUg ZHJhZnQgY29tcGF0aWJsZSB3aXRoIFJGQ3MNCjUzMzIgYW5kIDUzMzEsIGFuZCBpdCBkb2VzIG5v dCByZXF1aXJlIElBTkEgdG8gYWxsb2NhdGUNCmEgc2Vjb25kIHBvcnQNCm51bWJlci4NCg0KTm90 ZSwgYnkgdGhlIHdheSwgdGhhdCBpZiB3ZSBhcmUgZ29pbmcgdG8gYWxsb3cgdGhlDQpoaWdoZXIg bGF5ZXJzIHRvIG5lZ290aWF0ZSB0aGUgZGVzdGluYXRpb24gcG9ydCBudW1iZXIsDQp3ZSBzaG91 bGQgcHJvYmFibHkgY2F1dGlvbiBpbXBsZW1lbnRlcnMgbm90IHRvIGhhcmQgY29kZQ0KKG9yIGhh cmQgd2lyZSkgYSBwYXJ0aWN1bGFyIHBvcnQNCm51bWJlci4NCg0KVGhlcmUgaXMgb25lIGZ1cnRo ZXIgaXNzdWUgZm9yIHlvdSB0byBjb25zaWRlci4NCg0KV2hlbiBhbiBNUExTIHBhY2tldCB3aXRo IGFuIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVsIGlzDQpyZWNlaXZlZCB0aHJvdWdoIGEgcGFydGlj dWxhciB0dW5uZWwsIHRoZSAiY29udGV4dCIgaW4NCndoaWNoIHRoZSBsYWJlbCBpcyBpbnRlcnBy ZXRlZCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBJUA0KYWRkcmVzcyBvZiB0aGUNCnJvb3Qgb2YNCnRo ZSB0dW5uZWwuDQooU2VlIHNlY3Rpb24gNyBvZiBSRkM1MzMxLikgIEZvciBhIFVEUCB0dW5uZWws IHRoaXMNCndvdWxkIG1lYW4gdGhhdCB0aGUgbGFiZWwgc3BhY2UgaXMgaWRlbnRpZmllZCBieSB0 aGUgU291cmNlIElQDQphZGRyZXNzLg0KU28gaWYgYSBwYXJ0aWN1bGFyIHJvdXRlciBpcyB1c2lu ZyBNUExTLWluLVVEUCB0byBzZW5kDQpNUExTIHBhY2tldHMgd2l0aCB1cHN0cmVhbS1hc3NpZ25l ZCBsYWJlbHMsIGl0J3MgcmVhbGx5DQppbXBvcnRhbnQgZm9yIGl0IHRvIHVzZSB0aGUgc2FtZSBJ UA0Kc291cmNlDQphZGRyZXNzIGluIGFsbA0KTVBMUy1pbi1VRFAgcGFja2V0cyB0aGF0IGhhdmUg dGhlIHNhbWUgZGVzdGluYXRpb24gYWRkcmVzcy4NCkkNCmNhbid0DQpxdWl0ZSB0ZWxsIHdoZXRo ZXIgdGhpcyBpcyBjb21wYXRpYmxlIHdpdGggaXRlbSBlLiBpbg0Kc2VjdGlvbg0KMy4xIG9mIHRo ZSBkcmFmdC4NCg0KRXJpYw0KDQoNCg0KDQoNCg0KLS0NCg0KDQpMb2EgQW5kZXJzc29uICAgICAg ICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxtYWlsdG86bG9h QG1haWwwMS5odWF3ZWkuY29tPg0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAg ICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCkh1YXdlaSBUZWNobm9sb2dpZXMg KGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NDx0ZWw6JTJCNDYlMjA3Mzkl MjA4MSUyMDIxJTIwNjQ+DQoNCg== --_000_CE03DB3D7B45C245BCA0D2432779493631E810MX104CL02corpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiAzIDkgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiAzIDkg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFo b21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IlxATWluZ0xpVSI7DQoJcGFub3NlLTE6MiAyIDMgOSAwIDAgMCAwIDAgMDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2 IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFt ZTpob2VuemI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBMb2EsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5GaXJzdCBvZiBhbGwsIHRoYW5rcyBmb3IgZXZlcnl0aGlu ZyB5b3XigJl2ZSBiZWVuIGRvaW5nIGZvciB0aGlzIGRyYWZ0LiZuYnNwOyBJbiBzb21lIHNlbnNl LCB3ZSB0aHJldyB5b3UgaW4gYXQgdGhlIGRlZXAgZW5kIG9mIHRoZSBwb29sIHdoZW4geW91IGJl Y2FtZSBzaGVwaGVyZCBsYXRlIGluIHRoZQ0KIHByb2Nlc3MsIGFsdGhvdWdoIHRoYXTigJlzIGJl ZW4gdGhlIGV4cGVyaWVuY2Ugb2YgbW9zdCBvZiB1cyB3aG/igJl2ZSBiZWVuIHdvcmtpbmcgb24g dGhpcyBkcmFmdCBmb3IgdGhlIHBhc3QgNiBtb250aHM7IHRoZXJl4oCZcyBhIGxvdCBtb3JlIGdv aW5nIG9uIGhlcmUgdGhhbiBhbnkgb2YgdXMgaW5pdGlhbGx5IGV4cGVjdGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+VGhhdCBzYWlkLCBBbGlh4oCZcyB0YWtlIG9uIHRoaXMgZHJhZnTigJlz IHN0YXRlIGFuZCB0aGUgdGhyZWFkIGJlbG93IG1hdGNoZXMgbWluZSAtIHRoZXJl4oCZcyBhIGJ1 bmNoIG9mIHNtYWxsIGNsYXJpZmljYXRpb25zIGluIHByb2dyZXNzIGJ1dCBub3RoaW5nIGJpZy4m bmJzcDsgSW4gdGhlIHRocmVhZCBiZWxvdywNCiBYaWFvaHUgYW5kIEkgd2luZCB1cCBhZ3JlZWlu ZyB0aGF0IHRoZXJlIGlzIG5vdCBhbiBMM1ZQTi1yZWxhdGVkIHByb2JsZW0gdGhhdCB0aGlzIGRy YWZ0IG5lZWRzIHRvIGFkZHJlc3MuJm5ic3A7IFRoZSByZXN1bHRpbmcgY2xhcmlmaWNhdGlvbiBp biB0aGUgYWRkaXRpb25hbCB0ZXh0IGlzIGZhaXJseSBzaW1wbGUgKGFuZCB3YXMgYWx3YXlzIGlu dGVuZGVkIGJ5IHRoZSBjdXJyZW50IHRleHQpIC0gYW4gTVBMUy1pbi1VRFAgdHVubmVsIGlzIGlk ZW50aWZpZWQNCiBieSBpdHMgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMgKElQ djYgaW4gdGhlIGFkZGVkIHRleHQgYmVsb3cgY291cnRlc3kgb2Ygd2hlcmUgaXQgb2NjdXJzIGlu IHRoZSBkcmFmdCkuJm5ic3A7IFRoZSBVRFAgcG9ydHMgZG8gbm90IHByb3ZpZGUgYW55IGFkZGl0 aW9uYWwgaWRlbnRpZmljYXRpb24gYmVjYXVzZSB0aGUgZGVzdGluYXRpb24gcG9ydCBpcyBhIGNv bnN0YW50LCBhbmQgdGhlIHNvdXJjZSBwb3J0IGlzIHVzZWQgc29sZWx5IHRvDQogaW5qZWN0IGVu dHJvcHkgKGUuZy4sIGZvciBtdWx0aXBhdGhpbmcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlRoYW5rcyw8YnI+DQotLURhdmlkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbGlhIEF0bGFzPGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyOCwgMjAxNSAxMDozMiBBTTxicj4NCjxiPlRvOjwvYj4g TG9hIEFuZGVyc3Nvbjxicj4NCjxiPkNjOjwvYj4gbXBsc0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW21wbHNdIEFkdmljZSBvbiBkcmFmdC1ldGYtbXBscy1pbi11ZHA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTG9hLDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDI4LCAyMDE1 IGF0IDE6MDEgQU0sIExvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUi IHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvbGtzLDxicj4NCjxicj4NClRoaXMgbWFpbCB0byBBbGlh IChhcyByZXNwb25zaWJsZSBBRCksIEFkcmlhbiAod2l0aCBleHBlcmllbmNlIGZyb20gcHJvZ3Jl c3NpbmcgYSBsb3Qgb2YgZG9jdW1lbnRzKSBhbmQgdGhlIG1wbHMgd2cgY28tY2hhaXJzLjxicj4N Cjxicj4NCkkgYmVjYW1lIERvY3VtZW50IFNoZXBoZXJkIHJhdGhlciBsYXRlIGluIHRoZSBwcm9j ZXNzLiBSb3NzIGRpZCB0aGU8YnI+DQomcXVvdDtyZXBlYXRlZCB3Z2xjJnF1b3Q7IG9uIHRoaXMg ZHJhZnQgb24gdmVyc2lvbiAtMDcsIHRoZSBkb2N1bWVudCB3YXMgdXBkYXRlZDxicj4NCmFmdGVy IHdnbGMgYXMgdmVyc2lvbiAtMDguIEFmdGVyIHRoYXQgdGhlcmUgaGFzIGJlZW4gZGlzY3Vzc2lv bnMgb248YnI+DQpkaWZmZXJlbnQgcGFydHMgb2YgdGhlIGRvY3VtZW50IGFuZCBpdCBoYXMgYmVl biB1cGRhdGVkIHR3aWNlLiBBbmQgYTxicj4NCnRoaXJkIHZlcnNpb24gKC0xMSkgaXMgaW4gdGhl IHBpcGUuIEkndmUgbm90IHNlZW4gdmVyc2lvbiAtMTEgeWV0LCBidXQ8YnI+DQphbW9uZyB0aGUg YXV0aG9ycyB0aGVyZSBhcmUgdGFsayBhYm91dCAmcXVvdDticmFuZCBuZXcgaXNzdWVzJnF1b3Q7 Ljxicj4NCjxicj4NCk15IGNvbmNlcm5zIGFyZSB0aGF0IHdlIGFyZSBpbnRyb2R1Y2luZyB0byBi aWcgY2hhbmdlcyB3aXRob3V0IGtlZXBpbmc8YnI+DQp0aGUmbmJzcDsgd29ya2luZyBncm91cCBp biB0aGUgbG9vcC4gQ2FuIHlvdSBoZWxwIGV2YWx1YXRlIGlmIHdlIG5lZWQgdG8gdGFrZTxicj4N CnRoZSBkb2N1bWVudCB0aHJvdWdoIGEgbmV3IHdnbGMsIG9yIGlmIHdlIGFyZSBnb29kIHRvIGdv PzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBrZWVw aW5nIGEgY2xvc2UgZXllIG9uIHRoaXMgcXVlc3Rpb24uIFNvIGZhciwgSSB0aGluayB0aGF0IHdl IGFyZSBnb29kIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5nbyBvbmNlIHRoZSBkaXNjdXNzZXMgYW5kIHVwc3RyZWFtIGxhYmVscyBxdWVzdGlv bnMgYXJlIGFkZHJlc3NlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gdGhlIGxhdHRlciwgJm5ic3A7SSBiZWxpZXZlIGl0IGlzIHJlc29s dmluZyB0byBiZWhhdmlvciBhcyBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mcm9tIFdHTEMgLSBidXQgd2l0 aCB0aGUgY2xhcmlmaWNhdGlvbiB0aGF0IGluIHRoZSBmdXR1cmUgc29tZSBzaWduYWxsaW5nIG1p Z2h0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5p bmRpY2F0ZSB3aGV0aGVyIHRoZSBsYWJlbHMgYXJlIG5vdCB1cHN0cmVhbSBhc3NpZ25lZCBldmVu IGlmIHRoZSBJUCBkZXN0aW5hdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+YWRkcmVzcyBpcyBtdWx0aWNhc3QuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0d28gZGlzY3Vzc2VzIGFy ZSBub3QsIElNSE8sIGNoYW5naW5nIGFueSB0ZWNobmljYWwgZGV0YWlscyBidXQgcmF0aGVyPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jbGFyaWZ5 aW5nIGRldGFpbHMuJm5ic3A7IEZvciBpbnN0YW5jZSwgdGhlcmUgaXNuJ3QgYSBsaXN0ZW5lciBh dCB0aGUgVURQIHNvdXJjZSBwb3J0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5vbiB0aGUgaW5ncmVzcyBvZiB0aGUgVURQIHR1bm5lbC4mbmJzcDsg Rm9yIGFub3RoZXIgaW5zdGFuY2UsIGNsYXJpZnlpbmcgdGhlIERUTFM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJlaGF2aW9yIGluIHRlcm1zIG9m IG51bWJlciBvZiBleHBlY3RlZCBzZXNzaW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBob3BlIHRvIHNlZSBhbiB1cGRhdGVkIGRy YWZ0IHRoYXQgYWRkcmVzc2VzIHRoZSBkaXNjdXNzZXMgdmVyeSBzb29uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgd291bGQgZW5jb3VyYWdl IHByb2RkaW5nIGJ5IHRoZSBzaGVwaGVyZCA7LSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxpYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vTG9hPGJyPg0KPGJyPg0KT24g MjAxNS0wMS0yOCAwOToxNCwgWHV4aWFvaHUgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIERhdmlkLDxicj4N Cjxicj4NClRoZSB0ZXh0IGxvb2tzIGdvb2QgdG8gbWUuIFRoYW5rcyBmb3IgeW91ciBleGNlbGxl bnQgd29yay48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KWGlhb2h1PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQmxhY2ssIERhdmlkIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20iIHRhcmdldD0iX2JsYW5rIj5kYXZp ZC5ibGFja0BlbWMuY29tPC9hPl08YnI+DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1 IDc6NTEgUE08YnI+DQpUbzogWHV4aWFvaHU8YnI+DQpDYzogTG9hIEFuZGVyc3NvbjsgPGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCmRyYWZ0LWlldGYtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPg0KYWRyaWFu QG9sZGRvZy5jby51azwvYT47PGJyPg0KQmxhY2ssIERhdmlkPGJyPg0KU3ViamVjdDogTVBMUy9V RFA6IFNlY3Rpb24gMy4xIGl0ZW0gMyAtIHJld3JpdGU8YnI+DQo8YnI+DQpIZXJlJ3MgbXkgaW5p dGlhbCBhdHRlbXB0IHRvIGNsYXJpZnkgU2VjdGlvbiAzLjEgaXRlbSAzIHdydCBFcmljIFJvc2Vu J3MgY29uY2Vybjxicj4NCnRoYXQgdGhlIHNvdXJjZSBJUHY2IGFkZHJlc3MgaXMgdGhlIGNvbnRl eHQgaWRlbnRpZmllciBmb3IgdXBzdHJlYW0tYXNzaWduZWQ8YnI+DQpjb250ZXh0IGxhYmVscyBm b3IgbXVsdGljYXN0IHRyYWZmaWMuJm5ic3A7IEkgZm91bmQgYSB3YXkgdG8gZG8gdGhpcyB3aXRo b3V0IHRhbGtpbmc8YnI+DQphYm91dCAmcXVvdDtwb2ludCZxdW90OyBvciAmcXVvdDttdWx0aXBv aW50JnF1b3Q7IGNoYXJhY3RlcmlzdGljcyBvZiB0dW5uZWwgaW5ncmVzcy9lZ3Jlc3MuPGJyPg0K PGJyPg0KT0xEPGJyPg0KJm5ic3A7ICZuYnNwOyBlLiZuYnNwOyBBbiBNUExTLWluLVVEUCBzZW5k ZXIgU0hPVUxEIHVzZSBkaWZmZXJlbnQgSVB2NiBhZGRyZXNzZXMgZm9yPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGVhY2ggTVBMUy1pbi1VRFAgdHVubmVsIHRoYXQgdXNlcyBVRFAg emVyby1jaGVja3N1bSBtb2RlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlZ2Fy ZGxlc3Mgb2YgcmVjZWl2ZXIgaW4gb3JkZXIgdG8gc3RyZW5ndGhlbiB0aGUgcmVjZWl2ZXInczxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjaGVjayBvZiB0aGUgSVB2NiBzb3VyY2Ug YWRkcmVzcy4mbmJzcDsgV2hlbiB0aGlzIGlzIG5vdCBwb3NzaWJsZSwgaXQ8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaXMgUkVDT01NRU5ERUQgdG8gdXNlIGVhY2ggc291cmNlIElQ djYgYWRkcmVzcyBmb3IgYXMgZmV3IFVEUDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB6ZXJvLWNoZWNrc3VtIG1vZGUgTVBMUy1pbi1VRFAgdHVubmVscyBhcyBpcyBmZWFzaWJsZS48 YnI+DQpORVc8YnI+DQombmJzcDsgJm5ic3A7IGUuJm5ic3A7IEFuIE1QTFMtaW4tVURQIHNlbmRl ciBTSE9VTEQgdXNlIGRpZmZlcmVudCBJUHY2IGFkZHJlc3NlcyBmb3I8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgZWFjaCBNUExTLWluLVVEUCB0dW5uZWwgdGhhdCB1c2VzIFVEUCB6 ZXJvLWNoZWNrc3VtIG1vZGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVnYXJk bGVzcyBvZiByZWNlaXZlciBpbiBvcmRlciB0byBzdHJlbmd0aGVuIHRoZSByZWNlaXZlcidzPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNoZWNrIG9mIHRoZSBJUHY2IHNvdXJjZSBh ZGRyZXNzIChpLmUuLCB0aGUgc2FtZSBJUHY2IHNvdXJjZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBhZGRyZXNzIFNIT1VMRCBOT1QgYmUgdXNlZCB3aXRoIG1vcmUgdGhhbiBvbmUg SVB2NiBkZXN0aW5hdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhZGRyZXNz LCBpbmRlcGVuZGVudCBvZiB3aGV0aGVyIHRoYXQgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVuaWNhc3Qgb3IgbXVsdGljYXN0IGFkZHJl c3MpLiZuYnNwOyBXaGVuIHRoaXMgaXMgbm90IHBvc3NpYmxlLCBpdDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBpcyBSRUNPTU1FTkRFRCB0byB1c2UgZWFjaCBzb3VyY2UgSVB2NiBh ZGRyZXNzIGZvciBhcyBmZXcgVURQPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHpl cm8tY2hlY2tzdW0gbW9kZSBNUExTLWluLVVEUCB0dW5uZWxzIChpLmUuLCB3aXRoIGFzIGZldzxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXN0aW5hdGlvbiBJUHY2IGFkZHJlc3Nl cykgYXMgaXMgZmVhc2libGUuPGJyPg0KPGJyPg0KSG93IGRvZXMgdGhhdCBsb29rPzxicj4NCjxi cj4NClRoYW5rcyw8YnI+DQotLURhdmlkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFh1eGlhb2h1IFttYWls dG86PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj54 dXhpYW9odUBodWF3ZWkuY29tPC9hPl08YnI+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMjYsIDIw MTUgMTE6MDEgQU08YnI+DQpUbzogQmxhY2ssIERhdmlkPGJyPg0KQ2M6IExvYSBBbmRlcnNzb247 IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPC9h Pjs8YnI+DQo8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFyZ2V0PSJfYmxh bmsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+PGJyPg0KU3ViamVjdDogUmU6IFttcGxzXSBJRCBU cmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6PGJyPg0KJmx0O2RyYWZ0LWlldGYtbXBscy1pbi11 ZHAtIDA5LnR4dCZndDs8YnI+DQo8YnI+DQpIaSBEYXZpZCw8YnI+DQo8YnI+DQpBZnRlciBhIGNh cmVmdWwgY29uc2lkZXJhdGlvbiwgSSB0aGluayBpdCBzaG91bGQgYmUgT0sgZm9yIGFuPGJyPg0K ZW5jYXBzdWxhdG9yIHRvIHVzZSBkaWZmZXJlbnQgdHVubmVsIHNvdXJjZSBhZGRyZXNzZXMgZm9y IGRpZmZlcmVudDxicj4NClVEUCB0dW5uZWxzIGlmIHRoZXNlIHR1bm5lbHMgYXJlIG1hbnVhbGx5 IGNvbmZpZ3VyZWQuIFNvcnJ5IGZvciB0aGF0PGJyPg0KY29uZnVzaW9uLiBJbiBhZGRpdGlvbiwg c2luY2UgaXRlbSBlIGhhcyBhIHNlbnRlbmNlICZxdW90O1doZW4gdGhpcyBpcyBub3Q8YnI+DQpw b3NzaWJsZSwuLi4mcXVvdDssIEkgYmVsaWV2ZSB0aGUgY3VycmVudCB0ZXh0IGlzIE9LIGZvciB0 aGUgUDJQIFVEUCB0dW5uZWw8YnI+DQpjYXNlLiBJdCBzZWVtcyB0aGF0IHlvdSBvbmx5IG5lZWQg dG8gYWRkIHNvbWUgdGV4dCBhYm91dCB0aGUgUDJNUCBVRFA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnR1bm5lbCwganVzdCBhcyB3aGF0IHlvdSBoYXZlIG1lbnRpb25lZCBi ZWZvcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpCZXN0IHJl Z2FyZHMsPGJyPg0KWGlhb2h1PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlVIj7lj5Hk u7bkuro8L3NwYW4+OiBCbGFjaywgRGF2aWQgWzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0Bl bWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYmxhY2tAZW1jLmNvbTwvYT5dPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1pbmdMaVUiPuWPkemAgeaXtumXtDwvc3Bhbj46IDIwMTU8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7lubQ8L3NwYW4+ MTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bh bj4yNjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaXpTwv c3Bhbj4gMTg6NDA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj JnF1b3Q7Ij7mlLbku7bkuro8L3NwYW4+OiBYdXhpYW9odTxicj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaKhOmAgTwvc3Bhbj46IExvYSBBbmRlcnNz b247IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3Jn PC9hPjs8YnI+DQo8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFyZ2V0PSJf YmxhbmsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+OyBCbGFjaywgRGF2aWQ8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5Ok1pbmdMaVUiPumimDwvc3Bhbj46IFJFOiBbbXBsc10gSUQgVHJh Y2tlciBTdGF0ZSBVcGRhdGUgTm90aWNlOjxicj4NCiZsdDtkcmFmdC1pZXRmLW1wbHMtaW4tdWRw LSAwOS50eHQmZ3Q7PGJyPg0KPGJyPg0KRmlyc3QsIHRoaXMgaXMgYSBicmFuZCBuZXcgY29uY2Vy biB0aGF0IGhhcyBub3QgYmVlbiByYWlzZWQgcHJldmlvdXNseTxicj4NCi0gaXQncyBkZWZpbml0 ZWx5IGRpZmZlcmVudCBmcm9tIEVyaWMgUm9zZW4ncyBjb25jZXJuLCB3aGljaCBJPGJyPg0KdW5k ZXJzdGFuZCBhbmQgd2lsbCB3cml0ZSBjbGFyaWZ5aW5nIHRleHQgZm9yLjxicj4NCjxicj4NClNl Y29uZCwgYSBWUE4gb3VnaHQgdG8gYmUgc2VyaW91c2x5IGNvbmNlcm5lZCB3aXRoIG1pc2RlbGl2 ZXJ5PGJyPg0KcHJldmVudGlvbiwgYW5kIHRoZXJlJ3MgdGV4dCBpbiB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc2VjdGlvbiBvbjxicj4NCnRoaXMgdG9waWMuJm5ic3A7IEl0ZW0gZSBpbiBz ZWN0aW9uIDMuMSBpcyBvbmUgb2YgdGhlIGltcG9ydGFudCB0aGluZ3MgdGhhdDxicj4NCnRoaXMg ZHJhZnQgZG9lcyB0b3dhcmRzIG1pc2RlbGl2ZXJ5IHByZXZlbnRpb24gd2hlbiBVRFAgemVybyBj aGVja3N1bXMgYXJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj51c2VkIHdp dGggSVB2Ni48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KTXkgc3RhcnRpbmcgcG9pbnQgd291bGQgYmUgLSBpZiBM M1ZQTnMgaGF2ZSBhIHByb2JsZW0gd2l0aCB1c2luZyBhPGJyPg0KZGlmZmVyZW50PGJyPg0KSVB2 NiBhZGRyZXNzIGFzIHRoZSBzb3VyY2Ugb2YgZWFjaCB0dW5uZWwsIHRoZW4gdGhhdCdzIG9uZSBt b3JlIHJlYXNvbjxicj4NCmZvciBMM1ZQTnMgdG8gdXNlIFVEUCBjaGVja3N1bXMgd2l0aCBJUHY2 Ljxicj4NCjxicj4NCkknbGwgZGVmZXIgdG8gTDNWUE4gZXhwZXJ0cyBvbiBob3cgTDNWUE4gYWRk cmVzcyBzaWduYWxpbmcgY3VycmVudGx5PGJyPg0Kd29ya3MgYW5kIHRoZSBpbXBhY3RzIG9mIGFk ZGl0aW9uYWwgSVB2NiBhZGRyZXNzZXMgb24gdGhhdC4mbmJzcDsgSSdtIG5vdDxicj4NCnRoZSBy aWdodCBwZXJzb24gdG8gd3JpdGUgTDNWUE4tc3BlY2lmaWMgdGV4dCAob24gdGhpcyBvciBhbnkg b3RoZXIgdG9waWMpLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQotLURhdmlkPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IFh1eGlhb2h1IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5j b20iIHRhcmdldD0iX2JsYW5rIj54dXhpYW9odUBodWF3ZWkuY29tPC9hPl08YnI+DQpTZW50OiBN b25kYXksIEphbnVhcnkgMjYsIDIwMTUgNDo0MiBBTTxicj4NClRvOiBCbGFjaywgRGF2aWQ8YnI+ DQpDYzogTG9hIEFuZGVyc3NvbjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy1pbi11 ZHBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtbXBscy1pbi11 ZHBAdG9vbHMuaWV0Zi5vcmc8L2E+OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiIHRhcmdldD0iX2JsYW5rIj5h ZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U3ViamVjdDogUkU6IFttcGxzXSBJRCBUcmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6PGJy Pg0KJmx0O2RyYWZ0LWlldGYtbXBscy1pbi11ZHAtIDA5LnR4dCZndDs8YnI+DQo8YnI+DQpIaSBE YXZpZCw8YnI+DQo8YnI+DQpKdXN0IHRha2UgdGhlIEJHUC9NUExTIElQIFZQTiB3aXRoIFJSIGVu YWJsZWQgYXMgYW4gZXhhbXBsZSwgaWYgaXQ8YnI+DQpyZXF1aXJlcyB0aGUgdHVubmVsIGVuY2Fw c3VsYXRvciAoaS5lLiwgaW5ncmVzcyBQRSkgdG8gdXNlIGRpZmZlcmVudDxicj4NCnNvdXJjZSBJ UCBhZGRyZXNzZXMgZm9yIGRpZmZlcmVudCB0dW5uZWxzLCBzaG91bGQgaW5ncmVzcyBQRXMgbm90 aWZ5PGJyPg0KdGhlIGFkZHJlc3MgdG8gYmUgdXNlZCBhcyB0aGUgdHVubmVsIHNvdXJjZSBhZGRy ZXNzIHRvIGVhY2ggZWdyZXNzPGJyPg0KUEUuIE90aGVyd2lzZSwgaG93IGNvdWxkIGVncmVzcyBQ RXMgdmVyaWZ5IHRoYXQgdGhlIHBhY2tldHMgYXJlIHJlY2VpdmVkPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5mcm9tIHZhbGlkIGluZ3Jlc3MgUEVzPzxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KQmVzdCByZWdhcmRzLDxicj4NClhpYW9odTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9t OiBCbGFjaywgRGF2aWQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLmJsYWNrQGVtYy5jb208L2E+XTxicj4NClNlbnQ6IFNh dHVyZGF5LCBKYW51YXJ5IDI0LCAyMDE1IDM6MTUgQU08YnI+DQpUbzogWHV4aWFvaHU8YnI+DQpD YzogTG9hIEFuZGVyc3NvbjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy1pbi11ZHBA dG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtbXBscy1pbi11ZHBA dG9vbHMuaWV0Zi5vcmc8L2E+OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiIHRhcmdldD0iX2JsYW5rIj5hZHJp YW5Ab2xkZG9nLmNvLnVrPC9hPjs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJsYWNrLCBEYXZpZDxicj4NClN1YmplY3Q6IFJFOiBbbXBsc10gSUQgVHJhY2tlciBTdGF0ZSBV cGRhdGUgTm90aWNlOjxicj4NCiZsdDtkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA5LnR4dCZndDs8 YnI+DQo8YnI+DQpYaWFvaHUsPGJyPg0KPGJyPg0KSSdtIG1pc3Npbmcgc29tZXRoaW5nIGhlcmUu PGJyPg0KPGJyPg0KRXJpYydzIGNvbmNlcm4gc3RlbXMgZnJvbSB0aGUgcmVxdWlyZW1lbnQgdGhh dCB3aGVuPGJyPg0KdXBzdHJlYW0tYXNzaWduZWQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxhYmVsczxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFyZSBpbiB1c2UsIHRoZSBzb3VyY2UgSVAgYWRkcmVz cyBpZGVudGlmaWVzIHRoZSBsYWJlbCBjb250ZXh0LDxicj4NCmFuZCBoZW5jZTxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c291cmNlIElQIGFkZHJlc3MgaGFzIHRvIGJlIGNv bW1vbiBhY3Jvc3MgYWxsIHRyYWZmaWMgdG8gYSBkZXN0aW5hdGlvbi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVyaWMgd2FzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5jb25jZXJuZWQgdGhhdCBTZWN0aW9uIDMuMSBpdGVtIGUgbWlnaHQgY29uZmxp Y3Qgd2l0aCB0aGF0IHJlcXVpcmVtZW50Ljxicj4NCjxicj4NClRoZSBjbGFyaWZ5aW5nIHRleHQg d2lsbCBpbmRpY2F0ZSB0aGF0IHRoZXJlIGlzIG5vIHByb2JsZW0gaGVyZTs8YnI+DQp3aGVuIHRo ZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIGlzIGEgbXVsdGljYXN0IGFkZHJlc3MsIHRoZSBzZW5k ZXI8YnI+DQpzZW5kcyBvbmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBh Y2tldCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVjZWl2ZXJzIGVhY2ggZ2V0IGEgY29weSBhbmQg dGhhdCAxOm4gbXVsdGljYXN0IGZhbi1vdXQgaXMgYTxicj4NCnNpbmdsZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7dHVubmVsJnF1b3Q7IHdydDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAzLjEgaXRlbSBlLjxicj4NCkV2ZXJ5 IHBhY2tldCBkZWxpdmVyZWQgdG8gZXZlcnkgcmVjZWl2ZXIgaW4gdGhhdCB0dW5uZWwgdXNlcyB0 aGU8YnI+DQpzYW1lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zb3VyY2U8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklQPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPmFkZHJlc3Ms IHNvIHRoZXJlJ3MgYSBzaW5nbGUgbGFiZWwgY29udGV4dC48YnI+DQo8YnI+DQpJIGRvIG5vdCB1 bmRlcnN0YW5kIHRoZSBSUEYgYW5kIHNpZ25hbGluZyBjb25jZXJucyBiZWxvdy48YnI+DQo8YnI+ DQpUaGFua3MsPGJyPg0KLS1EYXZpZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IFh1eGlhb2h1IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1 YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj54dXhpYW9odUBodWF3ZWkuY29tPC9hPl08YnI+DQpT ZW50OiBUaHVyc2RheSwgSmFudWFyeSAyMiwgMjAxNSA4OjQwIFBNPGJyPg0KVG86IEJsYWNrLCBE YXZpZDxicj4NCkNjOiBMb2EgQW5kZXJzc29uOyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1t cGxzLWluLXVkcEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0Zi1t cGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzwvYT47PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmFkcmlh bkBvbGRkb2cuY28udWsiIHRhcmdldD0iX2JsYW5rIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjxi cj4NClN1YmplY3Q6IFJFOiBbbXBsc10gSUQgVHJhY2tlciBTdGF0ZSBVcGRhdGUgTm90aWNlOjxi cj4NCiZsdDtkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLSAwOS50eHQmZ3Q7PGJyPg0KPGJyPg0KSGkg RGF2aWQsPGJyPg0KPGJyPg0KSSdtIGxvb2tpbmcgZm9yd2FyZGluZyB0byBzZWVpbmcgeW91ciB1 cGRhdGVkIHRleHQuIEJ5IHRoZSB3YXksPGJyPg0KSSBob3BlIHlvdSBjb3VsZCB0YWtlIGludG8g YWNjb3VudCBwb3RlbnRpYWwgY29uY2VybnMgYXMgZm9sbG93czo8YnI+DQo8YnI+DQoxKSB3aWxs IGl0IG1ha2UgdGhlIFJQRiBjaGVjayBwZXJmb3JtZWQgYnkgdHVubmVsIGRlY2Fwc3VsYXRvcnM8 YnI+DQooZS5nLiwgdG8gZGV0ZXJtaW5lIHRoZSB1cHN0cmVhbSBQRSBvZiB0aGUgcmVjZWl2ZWQg bXVsdGljYXN0PGJyPg0KcGFja2V0IGluIHRoZSBtdWx0aWNhc3QgVlBOIGNvbnRleHQpIGRpZmZp Y3VsdCB3aGVuIHJlcXVpcmluZyBhPGJyPg0KdHVubmVsIGVuY2Fwc3VsYXRvciB0byB1c2UgZGlm ZmVyZW50IHR1bm5lbCBzb3VyY2UgYWRkcmVzc2VzIGZvcjxicj4NCmRpZmZlcmVudCB0dW5uZWxz Ozxicj4NCjIpIGRvZXMgaXQgcmVxdWlyZSB0aGUgZW5jYXBzdWxhdG9yIG9mIGEgcGFydGljdWxh ciBNUExTLWluLVVEUDxicj4NCnR1bm5lbCB0byBub3RpZnkgdGhlIGRlY2Fwc3VsYXRvcihzKSBv ZiBpdHMgcG9zc2libGUgYWRkcmVzc2VzPGJyPg0KdG8gYmUgdXNlZCBhcyB0aGUgc291cmNlIGFk ZHJlc3Mgb2YgdGhhdCB0dW5uZWwuPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NClhpYW9o dTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBCbGFjaywgRGF2aWQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 ZGF2aWQuYmxhY2tAZW1jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLmJsYWNrQGVtYy5jb208 L2E+XTxicj4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIyLCAyMDE1IDExOjE1IFBNPGJyPg0K VG86IFh1eGlhb2h1PGJyPg0KQ2M6IExvYSBBbmRlcnNzb247IDxhIGhyZWY9Im1haWx0bzpkcmFm dC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFm dC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPC9hPjs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0 YXJnZXQ9Il9ibGFuayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT47PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkJsYWNrLCBE YXZpZDxicj4NClN1YmplY3Q6IFJFOiBbbXBsc10gSUQgVHJhY2tlciBTdGF0ZSBVcGRhdGUgTm90 aWNlOjxicj4NCiZsdDtkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA5LnR4dCZndDs8YnI+DQo8YnI+ DQpYaWFvaHUsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSB0aGUg cmVxdWlyZW1lbnQgaXRlbSBlIHdvdWxkIGludHJvZHVjZSBhZGRpdGlvbmFsIGFuZDxicj4NCnVu ZXhwZWN0ZWQgY29tcGxleGl0aWVzIGFuZCBkaWZmaWN1bHRpZXMgZm9yIHRoZSBkZXBsb3ltZW50 LDxicj4NCkkgc3VnZ2VzdCB0aGF0IGl0J2QgYmV0dGVyIHRvIHJlbW92ZSB0aGF0IGl0ZW0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIHN0cm9uZ2x5IGRpc2Fn cmVlLiZuYnNwOyBUaGF0IHJlcXVpcmVtZW50IGlzIGltcG9ydGFudCB0byB0aGU8YnI+DQpvdmVy YWxsIGRlc2lnbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Z29hbCBvZjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVxdWlyaW5nIGFuIG9mZnNldHRp bmcgY29ycnVwdGlvbiB0byBjYXVzZSBtaXNkZWxpdmVyeSAoaS5lLiw8YnI+DQphIHNpbmdsZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29ycnVwdGlvbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2hvdWxkIHVzdWFsbHkgbm90IHJlc3VsdCBpbiBt aXNkZWxpdmVyeSkuPGJyPg0KPGJyPg0KVGhlcmUgaXMgbm90IGFuIGFjdHVhbCBwcm9ibGVtIGhl cmUgLSBpdGVtIGUgaXMgY29ycmVjdCB3cnQ8YnI+DQpFcmljJ3MgY29uY2Vybiw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBub3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmV4cGxhaW5lZCBjbGVhcmx5LiZuYnNwOyAmbmJzcDsgSSBjYW4gd3Jp dGUgdGhlIHNlbnRlbmNlIG9yIHR3byB0aGF0IHdpbGwgYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPm5lZWRlZCB0bzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jbGFyaWZ5PGJyPg0KaG93IHJlcXVpcmVt ZW50IGUgYXBwbGllcyB0byBQMk1QIFVEUCB0dW5uZWxzIChpLmUuLDxicj4NCmRlc3RpbmF0aW9u IElQIGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmlzIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+bXVsdGljYXN0IGFkZHJlc3MpICphZnRlciogdGhlIHVwc3Ry ZWFtIHZzLiBkb3duc3RyZWFtIGxhYmVsPGJyPg0KYXNzaWdubWVudCBkaXNjdXNzaW9uIGlzIHNv cnRlZCBvdXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CeSB0aGUgd2F5 LCBJIGZlZWwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHVuaWZvcm1seSByZXBsYWNlPGJyPg0KJnF1 b3Q7TVBMUy1pbi1VRFAgcmVjZWl2ZXIvcmVjZWl2ZXIgbm9kZSZxdW90OyBhbmQgJnF1b3Q7TVBM Uy1pbi1VRFA8YnI+DQpzZW5kZXImcXVvdDsgYnkgJnF1b3Q7dHVubmVsIGRlY2Fwc3VsYXRvciZx dW90OyBhbmQgJnF1b3Q7dHVubmVsIGVuY2Fwc3VsYXRvciZxdW90Ozxicj4NCnJlc3BlY3RpdmVs eSBpbiB0aGUgd2hvbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRvYy48 YnI+DQo8YnI+DQpJJ2xsIGRlZmVyIHRvIG90aGVycyBvbiB0ZXJtaW5vbG9neSwgYWx0aG91Z2gg SSBmaW5kIHRoZTxicj4NCk1QTFMtaW4tVURQPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj50ZXJtaW5vbG9neTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5jbGVhcmVyIGJlY2F1c2UgaXQgaW5kaWNhdGVz IGV4YWN0bHkgd2hpY2ggdHVubmVsIGlzIGludm9sdmVkLjxicj4NCjxicj4NClRoYW5rcyw8YnI+ DQotLURhdmlkPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFh1eGlhb2h1IFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj54dXhp YW9odUBodWF3ZWkuY29tPC9hPl08YnI+DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjEsIDIw MTUgMTA6MjIgUE08YnI+DQpUbzogQmxhY2ssIERhdmlkPGJyPg0KQ2M6IExvYSBBbmRlcnNzb247 IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPC9h Pjs8YnI+DQo8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFyZ2V0PSJfYmxh bmsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+PGJyPg0KU3ViamVjdDogUkU6IFttcGxzXSBJRCBU cmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6PGJyPg0KJmx0O2RyYWZ0LWlldGYtbXBscy1pbi11 ZHAtIDA5LnR4dCZndDs8YnI+DQo8YnI+DQpIaSBEYXZpZCBhbmQgYWxsLDxicj4NCjxicj4NClNp bmNlIHRoZSByZXF1aXJlbWVudCBpdGVtIGUgd291bGQgaW50cm9kdWNlIGFkZGl0aW9uYWwgYW5k PGJyPg0KdW5leHBlY3RlZCBjb21wbGV4aXRpZXMgYW5kIGRpZmZpY3VsdGllcyBmb3IgdGhlIGRl cGxveW1lbnQsPGJyPg0KSSBzdWdnZXN0IHRoYXQgaXQnZCBiZXR0ZXIgdG8gcmVtb3ZlIHRoYXQg aXRlbS48YnI+DQo8YnI+DQpCeSB0aGUgd2F5LCBJIGZlZWwgaXQgd291bGQgYmUgYmV0dGVyIHRv IHVuaWZvcm1seSByZXBsYWNlPGJyPg0KJnF1b3Q7TVBMUy1pbi1VRFAgcmVjZWl2ZXIvcmVjZWl2 ZXIgbm9kZSZxdW90OyBhbmQgJnF1b3Q7TVBMUy1pbi1VRFA8YnI+DQpzZW5kZXImcXVvdDsgYnkg JnF1b3Q7dHVubmVsIGRlY2Fwc3VsYXRvciZxdW90OyBhbmQgJnF1b3Q7dHVubmVsIGVuY2Fwc3Vs YXRvciZxdW90Ozxicj4NCnJlc3BlY3RpdmVseSBpbiB0aGUgd2hvbGU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRvYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQmVzdCByZWdhcmRzLDxi cj4NClhpYW9odTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IEJsYWNrLCBEYXZpZCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYmxhY2tAZW1jLmNvbTwvYT5dPGJyPg0KU2VudDogVGh1 cnNkYXksIEphbnVhcnkgMjIsIDIwMTUgMzoxNyBBTTxicj4NClRvOiBFcmljIEMgUm9zZW47IEFs aWEgQXRsYXM7IFh1eGlhb2h1PGJyPg0KQ2M6IExvYSBBbmRlcnNzb247ICZsdDs8YSBocmVmPSJt YWlsdG86bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWFkc0B0 b29scy5pZXRmLm9yZzwvYT4mZ3Q7Ozxicj4NCjxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PC9hPjs8YnI+DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29scy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtbXBscy1pbi11ZHBAdG9vbHMuaWV0 Zi5vcmc8L2E+Ozxicj4NCklKc2JyYW5kIFdpam5hbmRzOyBCbGFjaywgRGF2aWQ8YnI+DQpTdWJq ZWN0OiBSRTogW21wbHNdIElEIFRyYWNrZXIgU3RhdGUgVXBkYXRlIE5vdGljZTo8YnI+DQombHQ7 ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wOS50eHQmZ3Q7PGJyPg0KPGJyPg0KRXJpYyw8YnI+DQo8 YnI+DQpPbiB0aGUgZnVydGhlciBpc3N1ZSAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlIGlzIG9uZSBmdXJ0aGVyIGlzc3VlIGZvciB5b3UgdG8gY29uc2lkZXIu PGJyPg0KPGJyPg0KV2hlbiBhbiBNUExTIHBhY2tldCB3aXRoIGFuIHVwc3RyZWFtLWFzc2lnbmVk IGxhYmVsIGlzPGJyPg0KcmVjZWl2ZWQgdGhyb3VnaCBhIHBhcnRpY3VsYXIgdHVubmVsLCB0aGUg JnF1b3Q7Y29udGV4dCZxdW90OyBpbjxicj4NCndoaWNoIHRoZSBsYWJlbCBpcyBpbnRlcnByZXRl ZCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBJUDxicj4NCmFkZHJlc3Mgb2YgdGhlPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yb290IG9mPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgdHVubmVsLjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPihTZWUgc2VjdGlvbiA3IG9mIFJGQzUzMzEuKSZuYnNwOyBGb3IgYSBV RFAgdHVubmVsLCB0aGlzPGJyPg0Kd291bGQgbWVhbiB0aGF0IHRoZSBsYWJlbCBzcGFjZSBpcyBp ZGVudGlmaWVkIGJ5IHRoZSBTb3VyY2UgSVA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmFkZHJlc3MuPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gaWYgYSBwYXJ0aWN1bGFyIHJvdXRl ciBpcyB1c2luZyBNUExTLWluLVVEUCB0byBzZW5kPGJyPg0KTVBMUyBwYWNrZXRzIHdpdGggdXBz dHJlYW0tYXNzaWduZWQgbGFiZWxzLCBpdCdzIHJlYWxseTxicj4NCmltcG9ydGFudCBmb3IgaXQg dG8gdXNlIHRoZSBzYW1lIElQPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zb3VyY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmFkZHJlc3MgaW4gYWxsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NUExTLWluLVVEUCBwYWNrZXRzIHRoYXQgaGF2ZSB0aGUgc2FtZSBkZXN0aW5h dGlvbiBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+STxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmNhbid0PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnF1aXRlIHRlbGwgd2hldGhlciB0aGlzIGlzIGNvbXBhdGlibGUgd2l0aCBpdGVtIGUuIGluPGJy Pg0Kc2VjdGlvbjxicj4NCjMuMSBvZiB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGF0IGlzIGNvbXBhdGlibGUgd2l0 aCBpdGVtIGUuLCBidXQgdGhlIGRyYWZ0IGRvZXNuJ3Qgc2F5PGJyPg0KbXVjaCBhYm91dCBQMk1Q PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VRFA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnR1bm5lbHMuJm5ic3A7IEluIHBh cnRpY3VsYXIsIEkgd291bGQgdmlldyB0aGF0IHNvdXJjZSBJUDxicj4NCmFkZHJlc3MgYXMgdGhl IHNvdXJjZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SVA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFkZHJlc3MgZm9yIGEgKG9uZSkgUDJNUCB0dW5u ZWwsIGFuZCBpdCdzIHByb2JhYmx5IGEgZ29vZDxicj4NCmlkZWEgdG8gYWRkIHNvbWU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRleHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+b24gUDJNUCBVRFAg dHVubmVscyB0byBtYWtlIHRoaXMgY2xlYXIuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCi0tRGF2 aWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KRnJvbTogRXJpYyBDIFJvc2VuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmVyb3NlbkBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmVyb3NlbkBqdW5pcGVyLm5ldDwv YT5dPGJyPg0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIxLCAyMDE1IDExOjI2IEFNPGJyPg0K VG86IEFsaWEgQXRsYXM7IFh1eGlhb2h1PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzplcm9zZW5A anVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5lcm9zZW5AanVuaXBlci5uZXQ8L2E+OyBCbGFj aywgRGF2aWQ7IExvYSBBbmRlcnNzb247PGJyPg0KJmx0O21wbHMtIDxhIGhyZWY9Im1haWx0bzph ZHNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hZHNAdG9vbHMuaWV0Zi5vcmc8L2E+ Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjs8YnI+DQpkcmFmdC1pZXRm LW1wbHMtaW4tIDxhIGhyZWY9Im1haWx0bzp1ZHBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj51ZHBAdG9vbHMuaWV0Zi5vcmc8L2E+OyBJSnNicmFuZDxicj4NCldpam5hbmRzPGJyPg0K U3ViamVjdDogUmU6IFttcGxzXSBJRCBUcmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6PGJyPg0K Jmx0O2RyYWZ0LWlldGYtbXBscy1pbi11ZHAtIDA5LnR4dCZndDs8YnI+DQo8YnI+DQpGb2xrcyw8 YnI+DQo8YnI+DQpJJ2xsIGJlIGhhcHB5IHRvIHRocm93IGluIG15IG11Y2ggYmVsYXRlZCB0d28g Y2VudHMuPGJyPg0KPGJyPg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIGlzc3VlIGF0 IGhhbmQgaXMgaG93IG9uZTxicj4NCmRldGVybWluZXMsIHdoZW4gcmVjZWl2aW5nIGFuIE1QTFMt aW4tVURQIHBhY2tldCw8YnI+DQp3aGV0aGVyIHRoZSB0b3AgTVBMUyBsYWJlbCBpcyB1cHN0cmVh bS1hc3NpZ25lZCBvcjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZG93 bnN0cmVhbS1hc3NpZ25lZC48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpEcmFmdC1pZXRmLW1wbHMtaW4t dWRwLTEwIGhhcyB0aGUgZm9sbG93aW5nIHRleHQ6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDtBcyBmb3Igd2hldGhlciB0aGUgdG9wIGxhYmVsIGluIHRoZSBNUExTIGxhYmVsIHN0YWNr IGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtkb3duc3RyZWFtLWFzc2lnbmVkIG9yIHVwc3Ry ZWFtLWFzc2lnbmVkLCBpdCBTSE9VTEQ8YnI+DQpiZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ ZGV0ZXJtaW5lZDxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2Jhc2VkIG9uIHRoZSB0dW5uZWwg ZGVzdGluYXRpb24gSVAgYWRkcmVzcy4mbmJzcDsgVGhhdCBpczxicj4NCnRvIHNheSwgaWY8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZTxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDtkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIGlzIGEgbXVsdGljYXN0IGFkZHJlc3MsIHRo ZTxicj4NCnRvcCBsYWJlbDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U0hPVUxEPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2JlIHVwc3RyZWFtLWFzc2lnbmVkLCBvdGhl cndpc2UgaWYgdGhlIGRlc3RpbmF0aW9uPGJyPg0KSVA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFkZHJlc3M8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlzIGE8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDt1bmljYXN0IGFk ZHJlc3MsIGl0IFNIT1VMRCBiZSBkb3duc3RyZWFtLWFzc2lnbmVkLjxicj4NCjxicj4NCkkgYmVs aWV2ZSB0aGlzIHRleHQgaXMgaW5jb3JyZWN0LCBhcyBpdCBpcyBpbmNvbnNpc3RlbnQ8YnI+DQp3 aXRoIFJGQ3M8YnI+DQo1MzMyIGFuZCA1MzMxLCB3aGljaCBhcmUgdGhlIFJGQ3MgdGhhdCBpbnRy b2R1Y2UgdGhlPGJyPg0Kbm90aW9uIG9mICZxdW90O3Vwc3RyZWFtLWFzc2lnbmVkIGxhYmVscyZx dW90Oy48YnI+DQo8YnI+DQpPZiBwYXJ0aWN1bGFyIHJlbGV2YW5jZSBpcyBTZWN0aW9uIDMgb2Yg UkZDIDUzMzIsIHdoaWNoPGJyPg0KZGlzY3Vzc2VzIGhvdyBvbmUgZGV0ZXJtaW5lcywgd2hlbiBh biBNUExTIHBhY2tldCBpczxicj4NCmJlaW5nIHNlbnQgdGhyb3VnaCBhIHR1bm5lbCwgd2hldGhl ciB0aGUgdG9wIGxhYmVsIG9mPGJyPg0KdGhlIGVuY2Fwc3VsYXRlZCBwYWNrZXQgaXMgdXBzdHJl YW0gb3I8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmRvd25zdHJlYW0uPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVG8gbWFrZSBhIGxvbmcgc3Rvcnkgc2hvcnQsIGJh c2ljYWxseSB3aGF0IHRoYXQgc2VjdGlvbjxicj4NCnNheXMgaXMgdGhhdCB0aGUgdHVubmVsIG11 c3QgYmUga25vd24gYSBwcmlvcmkgdG8gaGF2ZTxicj4NCm9uZSBvZiB0aGUgZm9sbG93aW5nIHRo cmVlPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5w cm9wZXJ0aWVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KMS4g VGhlIHRvcCBsYWJlbCBvZiBhbGwgZW5jYXBzdWxhdGVkIHBhY2tldHMgaXM8YnI+DQpkb3duc3Ry ZWFtLTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXNzaWduZWQuPG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjIuIFRoZSB0b3AgbGFiZWwgb2YgYWxs IGVuY2Fwc3VsYXRlZCBwYWNrZXRzIGlzPGJyPg0KdXBzdHJlYW0tPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hc3NpZ25lZC48bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjMu IFRoZSB0b3AgbGFiZWwgb2Ygc29tZSBlbmNhcHN1bGF0ZWQgcGFja2V0cyBpczxicj4NCmRvd25z dHJlYW0tYXNzaWduZWQsIGJ1dCB0aGUgdG9wIGxhYmVsIG9mIHNvbWU8YnI+DQplbmNhcHN1bGF0 ZWQgcGFja2V0cyBpczxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dXBzdHJlYW0tYXNzaWduZWQu PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCkhvdyBpdCBpcyBrbm93biB3aGljaCBwcm9wZXJ0eSB0aGUgdHVubmVsIGhh cyBpcyBvdXQgb2Y8YnI+DQpzY29wZSAoaS5lLiwgaXQgZGVwZW5kcyBvbiB0aGUgaGlnaGVyIGxh eWVyKS48YnI+DQo8YnI+DQpPbmx5IHR1bm5lbHMgd2l0aCB0aGUgdGhpcmQgcHJvcGVydHkgbmVl ZCB0byBjb250YWluIGE8YnI+DQpjb2RlcG9pbnQgdGhhdCBzcGVjaWZpZXMgd2hldGhlciB0aGUg bGFiZWwgaXM8YnI+DQp1cHN0cmVhbS1hc3NpZ25lZCBvcjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZG93bnN0cmVhbS1h c3NpZ25lZC48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KU28gd2hhdCBkb2VzIGFsbCB0aGlzIG1lYW4gZm9yIHRoZSBt cGxzLWluLXVkcCBlbmNhcHN1bGF0aW9uPzxicj4NCkkgd291bGQgc3VnZ2VzdCB0aGF0IHlvdSBz YXkgdGhlIGZvbGxvd2luZzo8YnI+DQo8YnI+DQotIEhhdmUgSUFOQSBhc3NpZ24gYSBzaW5nbGUg VURQIHBvcnQgbnVtYmVyIGZvciBNUExTLWluLVVEUC48YnI+DQo8YnI+DQotIEluIHRoZSBhYnNl bmNlIG9mIGFueSBvdGhlciBrbm93bGVkZ2UsIGEgVURQIHBhY2tldDxicj4NCndpdGggdGhlIE1Q TFMtaW4tVURQIHBvcnQgbnVtYmVyIGluIGRlc3RpbmF0aW9uIHBvcnQ8YnI+DQpmaWVsZCBpcyBh c3N1bWVkIHRvIGJlIGNhcnJ5aW5nIGFuIE1QTFMgcGFja2V0IHdob3NlIHRvcDxicj4NCmxhYmVs IGlzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kb3duc3RyZWFtLWFz c2lnbmVkLjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0gSGlnaGVyIGxh eWVycyBtYXkgbmVnb3RpYXRlIHRoZSB1c2Ugb2YgcGFydGljdWxhciBVRFA8YnI+DQp0dW5uZWxz IHRvIGNhcnJ5IE1QTFMgcGFja2V0cyB3aG9zZSB0b3AgbGFiZWxzIGFyZTxicj4NCnVwc3RyZWFt LWFzc2lnbmVkLiZuYnNwOyBUaGUgcHJvY2VkdXJlcyBmb3Igc3VjaCBuZWdvdGlhdGlvbjxicj4N CmFyZSBvdXQgb2Ygc2NvcGUgb2YgdGhlIGN1cnJlbnQgZG9jdW1lbnQuJm5ic3A7IEJ5IGE8YnI+ DQomcXVvdDtwYXJ0aWNsdWFyIFVEUCB0dW5uZWwmcXVvdDssIEkgbWVhbiBhIFVEUCB0dW5uZWwg d2l0aCBhPGJyPg0KcGFydGljdWxhciAmbHQ7c291cmNlIElQIGFkZHJlc3MsIGRlc3RpbmF0aW9u IElQIGFkZHJlc3MsPGJyPg0KZGVzdGluYXRpb248YnI+DQpwb3J0Jmd0OyB0cmlwbGUuJm5ic3A7 IFRoZSBkZXN0aW5hdGlvbiBwb3J0IG1heSBiZSB0aGUgc3RhbmRhcmQ8YnI+DQooSUFOQS1hc3Np Z25lZCkgcG9ydCBudW1iZXIgZm9yIE1QTFMtaW4tVURQLCBidXQgaXQgbWF5PGJyPg0KYWxzbyBi ZSBhbnkgb3RoZXIgcG9ydCBudW1iZXIgdGhhdCBpcyBuZWdvdGlhdGVkIGJ5IHRoZSBoaWdoZXI8 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxh eWVyLjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0gRm9yIGEgcGFydGljdWxhciBVRFAgdHVubmVsIChp LmUuLCBhIHBhcnRpY3VsYXI8YnI+DQombHQ7c291cmNlIGFkZHJlc3MsIGRlc3RpbmF0aW9uIGFk ZHJlc3MsIGRlc3RpbmF0aW9uIHBvcnQmZ3Q7PGJyPg0KdHJpcGxlKSwgYWxsIHRoZSBlbmNhcHN1 bGF0ZWQgTVBMUyBwYWNrZXRzIG11c3QgaGF2ZSB0aGU8YnI+DQpzYW1lIHR5cGUgb2YgbGFiZWwg YXQgdGhlIHRvcDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b2Y8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBzdGFjay48bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K LSBSZW1vdmUgYW55IHN1Z2dlc3Rpb24gdGhhdCB0aGUgdHlwZSBvZiB0aGUgbGFiZWwgY2FuPGJy Pg0KYmUgaW5mZXJyZWQgZnJvbSB0aGUgdHlwZSBvZiB0aGUgSVAgZGVzdGluYXRpb24gYWRkcmVz cy48YnI+DQo8YnI+DQpJIHRoaW5rIHRoaXMgd2lsbCBtYWtlIHRoZSBkcmFmdCBjb21wYXRpYmxl IHdpdGggUkZDczxicj4NCjUzMzIgYW5kIDUzMzEsIGFuZCBpdCBkb2VzIG5vdCByZXF1aXJlIElB TkEgdG8gYWxsb2NhdGU8YnI+DQphIHNlY29uZCBwb3J0PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5udW1iZXIuPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCk5vdGUsIGJ5IHRoZSB3YXksIHRoYXQgaWYgd2UgYXJlIGdvaW5n IHRvIGFsbG93IHRoZTxicj4NCmhpZ2hlciBsYXllcnMgdG8gbmVnb3RpYXRlIHRoZSBkZXN0aW5h dGlvbiBwb3J0IG51bWJlciw8YnI+DQp3ZSBzaG91bGQgcHJvYmFibHkgY2F1dGlvbiBpbXBsZW1l bnRlcnMgbm90IHRvIGhhcmQgY29kZTxicj4NCihvciBoYXJkIHdpcmUpIGEgcGFydGljdWxhciBw b3J0PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5udW1iZXIuPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZXJlIGlz IG9uZSBmdXJ0aGVyIGlzc3VlIGZvciB5b3UgdG8gY29uc2lkZXIuPGJyPg0KPGJyPg0KV2hlbiBh biBNUExTIHBhY2tldCB3aXRoIGFuIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVsIGlzPGJyPg0KcmVj ZWl2ZWQgdGhyb3VnaCBhIHBhcnRpY3VsYXIgdHVubmVsLCB0aGUgJnF1b3Q7Y29udGV4dCZxdW90 OyBpbjxicj4NCndoaWNoIHRoZSBsYWJlbCBpcyBpbnRlcnByZXRlZCBpcyBkZXRlcm1pbmVkIGJ5 IHRoZSBJUDxicj4NCmFkZHJlc3Mgb2YgdGhlPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5yb290IG9mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50 aGUgdHVubmVsLjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihTZWUgc2VjdGlvbiA3 IG9mIFJGQzUzMzEuKSZuYnNwOyBGb3IgYSBVRFAgdHVubmVsLCB0aGlzPGJyPg0Kd291bGQgbWVh biB0aGF0IHRoZSBsYWJlbCBzcGFjZSBpcyBpZGVudGlmaWVkIGJ5IHRoZSBTb3VyY2UgSVA8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFkZHJl c3MuPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U28gaWYgYSBwYXJ0aWN1bGFyIHJvdXRlciBpcyB1c2luZyBNUExT LWluLVVEUCB0byBzZW5kPGJyPg0KTVBMUyBwYWNrZXRzIHdpdGggdXBzdHJlYW0tYXNzaWduZWQg bGFiZWxzLCBpdCdzIHJlYWxseTxicj4NCmltcG9ydGFudCBmb3IgaXQgdG8gdXNlIHRoZSBzYW1l IElQPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5zb3VyY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmFkZHJlc3MgaW4gYWxsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NUExT LWluLVVEUCBwYWNrZXRzIHRoYXQgaGF2ZSB0aGUgc2FtZSBkZXN0aW5hdGlvbiBhZGRyZXNzLjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+STxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNhbid0PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+cXVpdGUgdGVsbCB3aGV0aGVyIHRoaXMgaXMgY29tcGF0aWJsZSB3aXRo IGl0ZW0gZS4gaW48YnI+DQpzZWN0aW9uPGJyPg0KMy4xIG9mIHRoZSBkcmFmdC48YnI+DQo8YnI+ DQpFcmljPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS0g PC9zcGFuPjxicj4NCjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkxvYSBBbmRlcnNz b24mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBt YWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWwwMS5odWF3ZWkuY29t PC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5TZW5pb3IgTVBMUyBFeHBlcnQm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5u dSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQHBpLm51PC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFz cz0iaG9lbnpiIj5IdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSZuYnNwOyAmbmJzcDsg Jm5ic3A7cGhvbmU6IDxhIGhyZWY9InRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2NCIgdGFy Z2V0PSJfYmxhbmsiPg0KJiM0Mzs0NiA3MzkgODEgMjEgNjQ8L2E+PC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_CE03DB3D7B45C245BCA0D2432779493631E810MX104CL02corpemcc_-- From nobody Wed Jan 28 15:27:12 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B1A1A6F0B; Wed, 28 Jan 2015 15:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR_RyiFBj8l8; Wed, 28 Jan 2015 15:27:02 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A6A1A6F05; Wed, 28 Jan 2015 15:27:02 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-3b-54c9112ce250 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 21.AB.25146.C2119C45; Wed, 28 Jan 2015 17:41:17 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 18:27:00 -0500 From: Gregory Mirsky To: Lizhenbin , Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AQHQOupzE7zeG6qIGUSmi4k6SnvYQZzWLOLQ Date: Wed, 28 Jan 2015 23:26:58 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8E9553@eusaamb103.ericsson.se> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8E9553eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonRFdX8GSIQUsXu0X/vSdsFrsb/7Bb 3Fq6ktXi+IXfjBatP3awOLB6tBx5y+qxZMlPJo/rTVfZA5ijuGxSUnMyy1KL9O0SuDK+37zC UnDqGGPFlynz2RoYVxxk7GLk5JAQMJH41baaHcIWk7hwbz1bFyMXh5DAEUaJIw8mMUE4yxkl Pi+ZzgRSxSZgJPFiYw9Yh4iAp8Sbe7NYQWxmgWyJry8usIHYwgKBEse/LAaq4QCqCZJY/lgB otxI4tzx84wgYRYBVYmVHSUgYV4BX4ltj4+zQKw6zyjx4X8PK0gNp0CYxLRZoSA1jEC3fT+1 hglik7jErSfzmSBuFpBYsuc8M4QtKvHy8T9WCFtRYl//dHaI+nyJxdNvMkHsEpQ4OfMJywRG 0VlIRs1CUjYLSdksoCuYBTQl1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypGjtLi1LLcdCPD TYzA6Dsmwea4g3HBJ8tDjAIcjEo8vAYPjocIsSaWFVfmHmKU5mBREuctu3IwREggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVANjS48p+7nvhxf9OTa7ymbb3YTURe8qE5r+PFpd+ddUcCXP0U0H XC7Ufm3pFfrZ9/r7t7ksF/8wlczr+lwrFOJ2QiHmRfj9dpZZ09c8FWnXnR6bIW//f27OV1v9 naZPOQTz+fjnVJzVnrNyW4dv7jIbgzsbTjt9WLUklqNmx6HLCYxLjpzb4HnlrxJLcUaioRZz UXEiAGEejwqfAgAA Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: Re: [mpls] [spring] New Comments on Segment Routing(7): MTU Challenges for SR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 23:27:05 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8E9553eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iaW4sIGV0LiBhbCwNCnBhcmRvbiBteSBuYcOvdmUgcXVlc3Rpb24gV2h5IFBhdGggTVRV IERpc2NvdmVyeSBpcyBub3Qgc3VmZmljaWVudD8gSSB0aGluayB0aGF0IHdpdGggU2VnbWVudCBS b3V0aW5nIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGNvbnN0cnVjdCB0aGUgTVRVIFNpemUgbWF0 cml4IG9mIHRoZSBwYXJ0aWN1bGFyIGRvbWFpbi4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMs DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogVGVhcyBbbWFp bHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpemhlbmJpbg0KU2VudDog V2VkbmVzZGF5LCBKYW51YXJ5IDI4LCAyMDE1IDM6MDYgQU0NClRvOiBIYW5uZXMgR3JlZGxlcg0K Q2M6IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgdGVhc0BpZXRmLm9yZw0KU3ViamVj dDogW1RlYXNdIOetlOWkjTogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNlZ21lbnQgUm91dGlu Zyg3KTogTVRVIENoYWxsZW5nZXMgZm9yIFNSDQoNCg0KSGkgSGFubmVzLA0KDQpJIGhhdmUgZXZl ciB0aG91Z2h0IGFib3V0IHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMgYmFzZWQgb24gdGhlIGZsb29k ZWQgTVRVIGluZm9ybWF0aW9uIHRocm91Z2ggSUdQLg0KDQpUaGVyZSBhcmUgc3RpbGwgdHdvIHBv c3NpYmxlIGlzc3VlczoNCg0KMS4gSW50ZXItYXJlYSBmb3IgU1ItVEUgcGF0aDogTWF5YmUgd2Ug bm90IG9ubHkgaW50cm9kdWNlIHRoZSBJR1AgZXh0ZW5zaW9ucywgYnV0IGFsc28gUENFUCBleHRl bnNpb25zLg0KDQoyLiBGb3IgU1ItQkUgcGF0aCwgaXQgaGFzIHRvIGludHJvZHVjZSB0aGUgVEUt bGlrZSBlbmQtdG8tZW5kIHBhdGggY2FsY3VsYXRpb24gYXQgdGhlIGluZ3Jlc3Mgbm9kZS4NCg0K DQoNCk15IGNvbmNlcm4gaXMgbm90IGp1c3QgZm9yIHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMsIGJ1 dCB0byBleHBsb3JlIHRoZSBlc3NlbmNlIG9mIFNSIHdoaWNoIG1heSBoYXMgbXVjaA0KDQplZmZl Y3Qgb24gaXRzIGRlcGxveW1lbnQgY29tcGFyaW5nIHdpdGggdGhlIGV4aXN0aW5nIE1QTFMgcHJv dG9jb2wuIEl0IHdpbGwgYmUgZXhwbGFpbmVkIGluDQoNCnRoZSBuZXh0IGNvbW1lbnRzLg0KDQoN Cg0KDQoNClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0K5Y+R5Lu25Lq6OiBIYW5uZXMgR3JlZGxlciBbaGFu bmVzQGp1bmlwZXIubmV0XQ0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0MeaciDI45pelIDQ6MDENCuaU tuS7tuS6ujogTGl6aGVuYmluDQrmioTpgIE6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHRlYXNAaWV0 Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+DQrkuLvpopg6IFJlOiBbc3ByaW5nXSBOZXcgQ29t bWVudHMgb24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0Kb25s eSBjYW4gc3BlYWsgZm9yIElTLUlTIC0NCmFmYWlrIHRoZSBUcmlsbCBleHRlbnNpb25zIGdhdmUg dXMgYSB3YXkgb2Ygc2lnbmFsaW5nIHRoZSBNVFUgb2YgYSBsaW5rIC4uLg0KDQpzbyB3aGF0IHdl IGNvdWxkIGRvIGlzIHRvIGFkdmVydGlzZSB0aGUgTVRVIGZvciBlYWNoIGFkamFjZW5jeSBhbmQg aW1wbGVtZW50DQpwcm9wZXIgZnJhZ21lbnRhdGlvbiBhdCB0aGUgVEUgdHVubmVsIGluZ3Jlc3Mu DQoNCi9oYW5uZXMNCg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSArMDAwMCwg TGl6aGVuYmluIHdyb3RlOg0KfCAgICBIaSBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRpbmcs DQp8DQp8ICAgIFRoaXMgaXMgdGhlIHNldmVudGggY29tbWVucy4gVGhlIGlzc3VlcyBwcm9wb3Nl ZCBoZXJlIGFyZSBmb3IgYm90aCBTUi1URQ0KfCAgICBwYXRoIGFuZCBTUi1CRSBwYXRoLg0KfA0K fA0KfA0KfCAgICAgICAgICAgICAxICAgICAgICAgICAgICAxICAgICAgICAgICAxICAgICAgICAg ICAgMQ0KfCAgICAgIFMxMS0tLS0tLS0tLS0tUzEyLS0tLS0tLS0tLVMxMy0tLS0tLS0tLVMxNC0t LS0tLS0tLVMxNQ0KfCAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAg ICB8ICAgICAgICAgICB8DQp8ICAgICAgMXwgICAgICAgICAgICAxfCAgICAgICAgICAgMXwgICAg ICAgICAgMXwgICAgICAgICAgMXwNCnwgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg fCAgICAgICAgICAgfCAgICAgICAgICAgfA0KfCAgICAgIFMyMS0tLS0tLS0tLS0tUzIyLS0tLS0t LS0tLVMyMy0tLS0tLS0tLVMyNC0tLS0tLS0tLVMyNQ0KfCAgICAgICAgICAgICA0ICAgICAgICAg ICAgICA0ICAgICAgICAgICA0ICAgICAgICAgICAgNA0KfA0KfA0KfA0KfCAgICBTdGlsbCB0YWtl IHRoZSB0b3BvbG9neSBpbiB0aGUgY29tbWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIg dGhlDQp8ICAgIGxvb3NlIGV4cGxpY2l0IHBhdGggb3INCnwNCnwgICAgdGhlIHN0cmljdCBleHBs aWNpdCBwYXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUgdGhlIE1UVSBvZiB0aGUNCnwgICAg aW50ZXJmYWNlIGlzIHRoZSBzYW1lLA0KfA0KfCAgICBzaW5jZSB0aGUgZGVwdGggb2YgdGhlIGxh YmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cA0KfCAgICBwYXRo IGFyZSBkaWZmZXJlbnQuDQp8DQp8ICAgIFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0 aXZlIHBheWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlDQp8ICAgIHByaW1hcnkgcGF0aCwg YnV0IG1heSBiZQ0KfA0KfCAgICBmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBw YXRoLiBBcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZQ0KfCAgICBsYWJlbCBzdGFja3Mgb2Yg dGhlDQp8DQp8ICAgIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0 aGUgcmlzayB3aWxsIGluY3JlYXNlLg0KfA0KfA0KfA0KfCAgICBGcm9tIHRoZSBjYXNlLCB3ZSBj YW4gZGVkdWNlIHRoYXQgdGhlIHJpc2sgbWF5IGV4aXN0cyBmb3IgYW55IHNjZW5hcmlvcyBpbg0K fCAgICB3aGljaCB0aGUgc2FtZSB0cmFmZmljDQp8DQp8ICAgICBtYXkgc3dpdGNoIGZyb20gb25l IFNSIHBhdGggdG8gdGhlIG90aGVyIFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzDQp8ICAg IFNSLVRFIHBhdGggc3VjaCBhcyBNUExTIFRFDQp8DQp8ICAgIGhvdHN0YW5kYnkvcmVvcHRpbWl6 YXRpb24gYW5kIFNSLUJFIHBhdGggc3VjaCBhcyBUSS1GUlIuDQp8DQp8DQp8DQp8ICAgIEJlc2lk ZXMgYWJvdmUgaXNzdWVzLCBMRFAvUlNWUC1URSBjYW4gc3VwcG9ydCB0aGUgcGF0aCBNVFUgdG8g dHJhY2sgdGhlDQp8ICAgIE1UVSBpbmZvcm1haXRvbiBhbG9uZyB0aGUNCnwNCnwgICAgTFNQIHRo cm91Z2ggc2lnbmFsbGluZy4gVGhlbiB0aGUgcmVhc29uYWJsZSBNVFUgaW5mbyB3aWxsIGJlIGFk b3B0ZWQgaW4NCnwgICAgdGhlIGluZ3Jlc3Mgbm9kZS4gRm9yIGJvdGgNCnwNCnwgICAgIFNSLVRF IHBhdGggKGlmIFBDRSBpcyBub3QgdXNlZCkgYW5kIFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlz IG5vDQp8ICAgIHNpZ25hbGxpbmcgdG8gYWR2ZXJ0aXNlDQp8DQp8ICAgIHRoZSBpbmZvcm1hdGlv bi4gSG93IHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZT8gT3IgdGhlcmUgbWF5YmUgdGhlIHJpc2sN CnwgICAgdGhhdCB0aGUgcGFja2V0IG1heSBiZQ0KfA0KfCAgICBkcm9wcGVkIGJ5IHRoZSBub2Rl cyBhbG9uZyB0aGUgTFNQLg0KfA0KfA0KfA0KfA0KfA0KfA0KfA0KfCAgICBSZWdhcmRzLA0KfA0K fCAgICBSb2Jpbg0KDQp8IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp8IHNwcmluZyBtYWlsaW5nIGxpc3QNCnwgc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQp8IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nDQo= --_000_7347100B5761DC41A166AC17F22DF1121B8E9553eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7 DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2lt U3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6U2ltU3VuOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D Tjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGkgUm9iaW4sIGV0LiBhbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+cGFyZG9uIG15IG5hw692ZSBxdWVzdGlvbiBXaHkgUGF0aCBNVFUgRGlzY292ZXJ5IGlzIG5v dCBzdWZmaWNpZW50PyBJIHRoaW5rIHRoYXQgd2l0aCBTZWdtZW50IFJvdXRpbmcgaXQgd291bGQg YmUgcG9zc2libGUgdG8gY29uc3RydWN0IHRoZSBNVFUgU2l6ZSBtYXRyaXggb2YNCiB0aGUgcGFy dGljdWxhciBkb21haW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5MaXpoZW5iaW48YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBKYW51YXJ5IDI4LCAyMDE1IDM6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBH cmVkbGVyPGJyPg0KPGI+Q2M6PC9iPiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IHRl YXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1RlYXNdIDwvc3Bhbj48c3BhbiBsYW5n PSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuetlOWkjTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+OiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2VnbWVudCBSb3V0 aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayI+SGkgSGFubmVzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+SSBoYXZlIGV2 ZXIgdGhvdWdodCBhYm91dCB0aGUgcG9zc2libGUgc29sdXRpb25zIGJhc2VkIG9uIHRoZSBmbG9v ZGVkIE1UVSBpbmZvcm1hdGlvbiB0aHJvdWdoIElHUC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPlRo ZXJlIGFyZSBzdGlsbCB0d28gcG9zc2libGUgaXNzdWVzOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ MS4gSW50ZXItYXJlYSBmb3IgU1ItVEUgcGF0aDogTWF5YmUgd2Ugbm90IG9ubHkgaW50cm9kdWNl IHRoZSBJR1AgZXh0ZW5zaW9ucywgYnV0IGFsc28gUENFUCBleHRlbnNpb25zLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtj b2xvcjpibGFjayI+Mi4gRm9yIFNSLUJFIHBhdGgsIGl0IGhhcyB0byBpbnRyb2R1Y2UgdGhlIFRF LWxpa2UgZW5kLXRvLWVuZCBwYXRoIGNhbGN1bGF0aW9uIGF0IHRoZSBpbmdyZXNzIG5vZGUuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+TXkgY29uY2VybiBpcyBub3QganVz dCBmb3IgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ug b2YgU1INCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFj ayI+d2hpY2ggbWF5IGhhcyBtdWNoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ZWZmZWN0IG9uIGl0cyBkZXBsb3ltZW50IGNvbXBh cmluZyB3aXRoIHRoZSBleGlzdGluZyBNUExTIHByb3RvY29sLiBJdCB3aWxsIGJlIGV4cGxhaW5l ZCBpbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29s b3I6YmxhY2siPnRoZSBuZXh0IGNvbW1lbnRzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xv cjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5Sb2Jpbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9y OmJsYWNrIj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjogSGFubmVzIEdyZWRsZXIgW2hh bm5lc0BqdW5pcGVyLm5ldF08YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7lj5HpgIHml7bpl7Q8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+OiAy MDE1PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xv cjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjE8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+Mjg8L3NwYW4+ PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7m l6U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayI+DQogNDowMTxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPuaUtuS7tuS6ujwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj46 IExpemhlbmJpbjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6YmxhY2siPuaKhOmAgTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj46DQo8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 bXBsc0BpZXRmLm9yZyI+DQptcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRlYXNA aWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNO IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+5Li76aKYPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2si PjogUmU6IFtzcHJpbmddIE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1UVSBD aGFsbGVuZ2VzIGZvciBTUjxicj4NCjxicj4NCm9ubHkgY2FuIHNwZWFrIGZvciBJUy1JUyAtPGJy Pg0KYWZhaWsgdGhlIFRyaWxsIGV4dGVuc2lvbnMgZ2F2ZSB1cyBhIHdheSBvZiBzaWduYWxpbmcg dGhlIE1UVSBvZiBhIGxpbmsgLi4uPGJyPg0KPGJyPg0Kc28gd2hhdCB3ZSBjb3VsZCBkbyBpcyB0 byBhZHZlcnRpc2UgdGhlIE1UVSBmb3IgZWFjaCBhZGphY2VuY3kgYW5kIGltcGxlbWVudDxicj4N CnByb3BlciBmcmFnbWVudGF0aW9uIGF0IHRoZSBURSB0dW5uZWwgaW5ncmVzcy48YnI+DQo8YnI+ DQovaGFubmVzPGJyPg0KPGJyPg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSAm IzQzOzAwMDAsIExpemhlbmJpbiB3cm90ZTo8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpIGFs bCBhdXRob3JzIG9mIHNlZ21lbnQgcm91dGluZyw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZu YnNwOyBUaGlzIGlzIHRoZSBzZXZlbnRoIGNvbW1lbnMuIFRoZSBpc3N1ZXMgcHJvcG9zZWQgaGVy ZSBhcmUgZm9yIGJvdGggU1ItVEU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhdGggYW5kIFNS LUJFIHBhdGguPGJyPg0KfDxicj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxPGJyPg0KfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBTMTEtLS0tLS0tLS0tLVMxMi0tLS0tLS0tLS1TMTMtLS0tLS0tLS1T MTQtLS0tLS0tLS1TMTU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCnwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMXw8YnI+DQp8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUzIxLS0tLS0t LS0tLS1TMjItLS0tLS0tLS0tUzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1PGJyPg0KfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0PGJyPg0K fDxicj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBTdGlsbCB0YWtlIHRoZSB0 b3BvbG9neSBpbiB0aGUgY29tbWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIgdGhlPGJy Pg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBsb29zZSBleHBsaWNpdCBwYXRoIG9yPGJyPg0KfDxicj4N CnwmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHN0cmljdCBleHBsaWNpdCBwYXRoIGZvciB0aGUgbG9v c2UgaG9wLCBhc3N1bWUgdGhlIE1UVSBvZiB0aGU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlu dGVyZmFjZSBpcyB0aGUgc2FtZSw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBzaW5j ZSB0aGUgZGVwdGggb2YgdGhlIGxhYmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQg dGhlIGJhY2t1cDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgcGF0aCBhcmUgZGlmZmVyZW50Ljxi cj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhl IGVmZmV0aXZlIHBheWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlPGJyPg0KfCZuYnNwOyZu YnNwOyZuYnNwOyBwcmltYXJ5IHBhdGgsIGJ1dCBtYXkgYmU8YnI+DQp8PGJyPg0KfCZuYnNwOyZu YnNwOyZuYnNwOyBmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBwYXRoLiBBcyB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZTxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgbGFiZWwg c3RhY2tzIG9mIHRoZTxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByaW1hcnkgcGF0 aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0aGUgcmlzayB3aWxsIGluY3JlYXNlLjxi cj4NCnw8YnI+DQp8PGJyPg0KfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgRnJvbSB0aGUgY2Fz ZSwgd2UgY2FuIGRlZHVjZSB0aGF0IHRoZSByaXNrIG1heSBleGlzdHMgZm9yIGFueSBzY2VuYXJp b3MgaW48YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIHRoZSBzYW1lIHRyYWZmaWM8YnI+ DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYXkgc3dpdGNoIGZyb20gb25lIFNS IHBhdGggdG8gdGhlIG90aGVyIFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzPGJyPg0KfCZu YnNwOyZuYnNwOyZuYnNwOyBTUi1URSBwYXRoIHN1Y2ggYXMgTVBMUyBURTxicj4NCnw8YnI+DQp8 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhvdHN0YW5kYnkvcmVvcHRpbWl6YXRpb24gYW5kIFNSLUJFIHBh dGggc3VjaCBhcyBUSS1GUlIuPGJyPg0KfDxicj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNw OyZuYnNwOyBCZXNpZGVzIGFib3ZlIGlzc3VlcywgTERQL1JTVlAtVEUgY2FuIHN1cHBvcnQgdGhl IHBhdGggTVRVIHRvIHRyYWNrIHRoZTxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgTVRVIGluZm9y bWFpdG9uIGFsb25nIHRoZTxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IExTUCB0aHJv dWdoIHNpZ25hbGxpbmcuIFRoZW4gdGhlIHJlYXNvbmFibGUgTVRVIGluZm8gd2lsbCBiZSBhZG9w dGVkIGluPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgaW5ncmVzcyBub2RlLiBGb3IgYm90 aDxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNSLVRFIHBhdGggKGlmIFBD RSBpcyBub3QgdXNlZCkgYW5kIFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlzIG5vPGJyPg0KfCZu YnNwOyZuYnNwOyZuYnNwOyBzaWduYWxsaW5nIHRvIGFkdmVydGlzZTxicj4NCnw8YnI+DQp8Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZSBpbmZvcm1hdGlvbi4gSG93IHRvIGltcGxlbWVudCB0aGUgZmVh dHVyZT8gT3IgdGhlcmUgbWF5YmUgdGhlIHJpc2s8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo YXQgdGhlIHBhY2tldCBtYXkgYmU8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBkcm9w cGVkIGJ5IHRoZSBub2RlcyBhbG9uZyB0aGUgTFNQLjxicj4NCnw8YnI+DQp8PGJyPg0KfDxicj4N Cnw8YnI+DQp8PGJyPg0KfDxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMs PGJyPg0KfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgUm9iaW48YnI+DQo8YnI+DQp8IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KfCBzcHJpbmcg bWFpbGluZyBsaXN0PGJyPg0KfCA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJp bmdAaWV0Zi5vcmc8L2E+PGJyPg0KfCA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmc8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7347100B5761DC41A166AC17F22DF1121B8E9553eusaamb103erics_-- From nobody Wed Jan 28 20:02:18 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6BC1A1B51; Wed, 28 Jan 2015 20:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt-o83XGF6fM; Wed, 28 Jan 2015 20:01:51 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D905A1A1B71; Wed, 28 Jan 2015 20:01:50 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-b1-54c9518be801 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 68.E1.25146.B8159C45; Wed, 28 Jan 2015 22:15:56 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 23:01:40 -0500 From: Uma Chunduri To: Lizhenbin , Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AQHQOup31U+M9g3I+kKNm0uu0XRPvpzWeb9A Date: Thu, 29 Jan 2015 04:01:40 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F55CF49@eusaamb105.ericsson.se> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F55CF49eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLrHT7cn8GSIweJvXBb9956wWexu/MNu cWvpSlaL4xd+M1q0/tjB4sDq0XLkLavHkiU/mTyuN11lD2CO4rJJSc3JLEst0rdL4Mq4PHs+ e8GGJYwVi+ZtYW1gfDudsYuRk0NCwERizaYN7BC2mMSFe+vZuhi5OIQEjjBKLG/pZ4ZwljNK LFv2mAWkik1AT+Lj1J9gHSICnhJv7s1iBbGZBbIlvr64wAZiCwsEShz/shiohgOoJkhi+WMF iHIjiaPP1jOB2CwCqhLfFreAlfAK+Ercn2YMseo8o8SH/z2sIHFOgTCJabNCQcoZgW77fmoN E8QmcYlbT+YzQdwsILFkz3lmCFtU4uXjf6wQtpLEpKXnoC7Ll5i/8QuYzSsgKHFy5hOWCYyi s5CMmoWkbBaSMoi4lsS8ht9QNYoSU7ofskPYmhJXJh+CsrUlli18zbyAkX0VI0dpcWpZbrqR 4SZGYPwdk2Bz3MG44JPlIUYBDkYlHt4NhidDhFgTy4orcw8xSnOwKInzll05GCIkkJ5Ykpqd mlqQWhRfVJqTWnyIkYmDU6qBcX9YYmSN7pSzK4JymXpnBnP/e31m1aqdzyqlCieeZnvE87DL U3cCH1sQ5457Vd6zw20epK9ZdmB1mk/zEr85mzM+zSksq7wxt4a9iD11lkIcP5/TsvOZs+8d qlB5ddzG7dJNgdXTPljfaJEMiI95p/vF5XHn2wsTZv1h3PFCf1+jUSyT3wbBu0osxRmJhlrM RcWJAOOdvD6gAgAA Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: Re: [mpls] [spring] New Comments on Segment Routing(7): MTU Challenges for SR X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 04:01:56 -0000 --_000_1B502206DFA0C544B7A60469152008633F55CF49eusaamb105erics_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iaW4sDQoNCklmIHdlIGhhdmUgTVRVIGlzc3VlcyB3aXRoIGluIGFuIGFyZWEsIEkgc2Vl IHRyb3VibGUgaW4gYmFzaWMgSUdQIGZ1bmN0aW9uaW5nIChmb3IgZXhhbXBsZSBpdKGvcyBhIHNl cmlvdXMgaXNzdWUgd2l0aCBJUy1JUyBmb3IgYmFzaWMgb3BlcmF0aW9uKS4NCkZvciBpbnRlciBh cmVhIGNhc2VzIGRvbqGvdCB5b3UgdGhpbmsgaXShr3MgaW4gUENFL0NvbnRyb2xsZXKhr3Mgc2Nv cGUgdG8gc2V0dXAgcGF0aHMgYmFzZWQgb24gdGhlIGFkdmVydGlzZWQgTVRVICh5ZXMsIGlmIE1U VSBpcyBhZHZlcnRpc2VkIG9uIEFESnMgYXMgcHJvcG9zZWQgYmVsb3cpLg0KDQotLQ0KVW1hIEMu DQoNCkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMaXpoZW5iaW4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyOCwgMjAxNSAzOjA2IEFNDQpU bzogSGFubmVzIEdyZWRsZXINCkNjOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IHRl YXNAaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSC08Li0OiBbc3ByaW5nXSBOZXcgQ29tbWVudHMg b24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0KDQpIaSBIYW5u ZXMsDQoNCkkgaGF2ZSBldmVyIHRob3VnaHQgYWJvdXQgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucyBi YXNlZCBvbiB0aGUgZmxvb2RlZCBNVFUgaW5mb3JtYXRpb24gdGhyb3VnaCBJR1AuDQoNClRoZXJl IGFyZSBzdGlsbCB0d28gcG9zc2libGUgaXNzdWVzOg0KDQoxLiBJbnRlci1hcmVhIGZvciBTUi1U RSBwYXRoOiBNYXliZSB3ZSBub3Qgb25seSBpbnRyb2R1Y2UgdGhlIElHUCBleHRlbnNpb25zLCBi dXQgYWxzbyBQQ0VQIGV4dGVuc2lvbnMuDQoNCjIuIEZvciBTUi1CRSBwYXRoLCBpdCBoYXMgdG8g aW50cm9kdWNlIHRoZSBURS1saWtlIGVuZC10by1lbmQgcGF0aCBjYWxjdWxhdGlvbiBhdCB0aGUg aW5ncmVzcyBub2RlLg0KDQoNCg0KTXkgY29uY2VybiBpcyBub3QganVzdCBmb3IgdGhlIHBvc3Np YmxlIHNvbHV0aW9ucywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ugb2YgU1Igd2hpY2ggbWF5 IGhhcyBtdWNoDQoNCmVmZmVjdCBvbiBpdHMgZGVwbG95bWVudCBjb21wYXJpbmcgd2l0aCB0aGUg ZXhpc3RpbmcgTVBMUyBwcm90b2NvbC4gSXQgd2lsbCBiZSBleHBsYWluZWQgaW4NCg0KdGhlIG5l eHQgY29tbWVudHMuDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQoNCg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEhhbm5l cyBHcmVkbGVyIFtoYW5uZXNAanVuaXBlci5uZXRdDQq3osvNyrG85DogMjAxNcTqMdTCMjjI1SA0 OjAxDQrK1bz+yMs6IExpemhlbmJpbg0Ks63LzTogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgdGVhc0Bp ZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NCtb3zOI6IFJlOiBbc3ByaW5nXSBOZXcgQ29t bWVudHMgb24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0Kb25s eSBjYW4gc3BlYWsgZm9yIElTLUlTIC0NCmFmYWlrIHRoZSBUcmlsbCBleHRlbnNpb25zIGdhdmUg dXMgYSB3YXkgb2Ygc2lnbmFsaW5nIHRoZSBNVFUgb2YgYSBsaW5rIC4uLg0KDQpzbyB3aGF0IHdl IGNvdWxkIGRvIGlzIHRvIGFkdmVydGlzZSB0aGUgTVRVIGZvciBlYWNoIGFkamFjZW5jeSBhbmQg aW1wbGVtZW50DQpwcm9wZXIgZnJhZ21lbnRhdGlvbiBhdCB0aGUgVEUgdHVubmVsIGluZ3Jlc3Mu DQoNCi9oYW5uZXMNCg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSArMDAwMCwg TGl6aGVuYmluIHdyb3RlOg0KfCAgICBIaSBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRpbmcs DQp8DQp8ICAgIFRoaXMgaXMgdGhlIHNldmVudGggY29tbWVucy4gVGhlIGlzc3VlcyBwcm9wb3Nl ZCBoZXJlIGFyZSBmb3IgYm90aCBTUi1URQ0KfCAgICBwYXRoIGFuZCBTUi1CRSBwYXRoLg0KfA0K fA0KfA0KfCAgICAgICAgICAgICAxICAgICAgICAgICAgICAxICAgICAgICAgICAxICAgICAgICAg ICAgMQ0KfCAgICAgIFMxMS0tLS0tLS0tLS0tUzEyLS0tLS0tLS0tLVMxMy0tLS0tLS0tLVMxNC0t LS0tLS0tLVMxNQ0KfCAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAg ICB8ICAgICAgICAgICB8DQp8ICAgICAgMXwgICAgICAgICAgICAxfCAgICAgICAgICAgMXwgICAg ICAgICAgMXwgICAgICAgICAgMXwNCnwgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg fCAgICAgICAgICAgfCAgICAgICAgICAgfA0KfCAgICAgIFMyMS0tLS0tLS0tLS0tUzIyLS0tLS0t LS0tLVMyMy0tLS0tLS0tLVMyNC0tLS0tLS0tLVMyNQ0KfCAgICAgICAgICAgICA0ICAgICAgICAg ICAgICA0ICAgICAgICAgICA0ICAgICAgICAgICAgNA0KfA0KfA0KfA0KfCAgICBTdGlsbCB0YWtl IHRoZSB0b3BvbG9neSBpbiB0aGUgY29tbWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIg dGhlDQp8ICAgIGxvb3NlIGV4cGxpY2l0IHBhdGggb3INCnwNCnwgICAgdGhlIHN0cmljdCBleHBs aWNpdCBwYXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUgdGhlIE1UVSBvZiB0aGUNCnwgICAg aW50ZXJmYWNlIGlzIHRoZSBzYW1lLA0KfA0KfCAgICBzaW5jZSB0aGUgZGVwdGggb2YgdGhlIGxh YmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cA0KfCAgICBwYXRo IGFyZSBkaWZmZXJlbnQuDQp8DQp8ICAgIFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0 aXZlIHBheWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlDQp8ICAgIHByaW1hcnkgcGF0aCwg YnV0IG1heSBiZQ0KfA0KfCAgICBmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBw YXRoLiBBcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZQ0KfCAgICBsYWJlbCBzdGFja3Mgb2Yg dGhlDQp8DQp8ICAgIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0 aGUgcmlzayB3aWxsIGluY3JlYXNlLg0KfA0KfA0KfA0KfCAgICBGcm9tIHRoZSBjYXNlLCB3ZSBj YW4gZGVkdWNlIHRoYXQgdGhlIHJpc2sgbWF5IGV4aXN0cyBmb3IgYW55IHNjZW5hcmlvcyBpbg0K fCAgICB3aGljaCB0aGUgc2FtZSB0cmFmZmljDQp8DQp8ICAgICBtYXkgc3dpdGNoIGZyb20gb25l IFNSIHBhdGggdG8gdGhlIG90aGVyIFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzDQp8ICAg IFNSLVRFIHBhdGggc3VjaCBhcyBNUExTIFRFDQp8DQp8ICAgIGhvdHN0YW5kYnkvcmVvcHRpbWl6 YXRpb24gYW5kIFNSLUJFIHBhdGggc3VjaCBhcyBUSS1GUlIuDQp8DQp8DQp8DQp8ICAgIEJlc2lk ZXMgYWJvdmUgaXNzdWVzLCBMRFAvUlNWUC1URSBjYW4gc3VwcG9ydCB0aGUgcGF0aCBNVFUgdG8g dHJhY2sgdGhlDQp8ICAgIE1UVSBpbmZvcm1haXRvbiBhbG9uZyB0aGUNCnwNCnwgICAgTFNQIHRo cm91Z2ggc2lnbmFsbGluZy4gVGhlbiB0aGUgcmVhc29uYWJsZSBNVFUgaW5mbyB3aWxsIGJlIGFk b3B0ZWQgaW4NCnwgICAgdGhlIGluZ3Jlc3Mgbm9kZS4gRm9yIGJvdGgNCnwNCnwgICAgIFNSLVRF IHBhdGggKGlmIFBDRSBpcyBub3QgdXNlZCkgYW5kIFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlz IG5vDQp8ICAgIHNpZ25hbGxpbmcgdG8gYWR2ZXJ0aXNlDQp8DQp8ICAgIHRoZSBpbmZvcm1hdGlv bi4gSG93IHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZT8gT3IgdGhlcmUgbWF5YmUgdGhlIHJpc2sN CnwgICAgdGhhdCB0aGUgcGFja2V0IG1heSBiZQ0KfA0KfCAgICBkcm9wcGVkIGJ5IHRoZSBub2Rl cyBhbG9uZyB0aGUgTFNQLg0KfA0KfA0KfA0KfA0KfA0KfA0KfA0KfCAgICBSZWdhcmRzLA0KfA0K fCAgICBSb2Jpbg0KDQp8IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp8IHNwcmluZyBtYWlsaW5nIGxpc3QNCnwgc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQp8IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nDQo= --_000_1B502206DFA0C544B7A60469152008633F55CF49eusaamb105erics_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Robin,

 <= /p>

If we have MTU issues wit= h in an area, I see trouble in basic IGP functioning (for example it=A1=AFs= a serious issue with IS-IS for basic operation).

For inter area cases don= =A1=AFt you think it=A1=AFs in PCE/Controller=A1=AFs scope to setup paths b= ased on the advertised MTU (yes, if MTU is advertised on ADJs as proposed below).

 <= /p>

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Wednesday, January 28, 2015 3:06 AM
To: Hannes Gredler
Cc: mpls@ietf.org; spring@ietf.org; teas@ietf.org
Subject: [mpls] =B4=F0=B8=B4: [spring] New Comments on Segment Routin= g(7): MTU Challenges for SR

 

Hi Hann= es,

I have = ever thought about the possible solutions based on the flooded MTU informat= ion through IGP.

There a= re still two possible issues:

1. Inte= r-area for SR-TE path: Maybe we not only introduce the IGP extensions, but = also PCEP extensions.

2. For = SR-BE path, it has to introduce the TE-like end-to-end path calculation at = the ingress node.

 

My conc= ern is not just for the possible solutions, but to explore the essence of S= R which may has much

effect on its deployment= comparing with the existing MPLS protocol. It will be explained in<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:black">

the next comments.

 

 

Regards,

Robin

 

 

 <= o:p>



________________________________________
=B7=A2= =BC=FE=C8=CB: Hannes Gredler [hannes@juniper.net]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C228=C8=D5 4:01
=CA=D5= =BC=FE=C8=CB: Lizhenbin
=B3=AD= =CB=CD: spring@ietf.org; mpls@ietf.org; teas@ietf.org
=D6=F7= =CC=E2: Re: [spring] New Comments on Segment Routing(7): MTU Challenges for SR=

only can speak for IS-IS -
afaik the Trill extensions gave us a way of signaling the MTU of a link ...=

so what we could do is to advertise the MTU for each adjacency and implemen= t
proper fragmentation at the TE tunnel ingress.

/hannes

On Tue, Jan 27, 2015 at 11:24:23AM +0000, Lizhenbin wrote:
|    Hi all authors of segment routing,
|
|    This is the seventh commens. The issues proposed here a= re for both SR-TE
|    path and SR-BE path.
|
|
|
|             1=             &nb= sp; 1           1 &n= bsp;          1
|      S11-----------S12----------S13---------S14-= --------S15
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      1|       = ;     1|        = ;   1|          1|&n= bsp;         1|
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      S21-----------S22----------S23---------S24-= --------S25
|             4=             &nb= sp; 4           4 &n= bsp;          4
|
|
|
|    Still take the topology in the comment 6 as the example= . No matter the
|    loose explicit path or
|
|    the strict explicit path for the loose hop, assume the = MTU of the
|    interface is the same,
|
|    since the depth of the label stacks for the primary pat= h and the backup
|    path are different.
|
|    There is the risk that the effetive payload may transmi= t through the
|    primary path, but may be
|
|    fragmented or dropped in the backup path. As the differ= ence between the
|    label stacks of the
|
|    primary path and the backup path increase, the risk wil= l increase.
|
|
|
|    From the case, we can deduce that the risk may exists f= or any scenarios in
|    which the same traffic
|
|     may switch from one SR path to the other SR path.= The SR path includes
|    SR-TE path such as MPLS TE
|
|    hotstandby/reoptimization and SR-BE path such as TI-FRR= .
|
|
|
|    Besides above issues, LDP/RSVP-TE can support the path = MTU to track the
|    MTU informaiton along the
|
|    LSP through signalling. Then the reasonable MTU info wi= ll be adopted in
|    the ingress node. For both
|
|     SR-TE path (if PCE is not used) and SR-BE path, s= ince there is no
|    signalling to advertise
|
|    the information. How to implement the feature? Or there= maybe the risk
|    that the packet may be
|
|    dropped by the nodes along the LSP.
|
|
|
|
|
|
|
|    Regards,
|
|    Robin

| _______________________________________________
| spring mailing list
| spring@ietf.org
| https://www.ietf= .org/mailman/listinfo/spring<= /span>

--_000_1B502206DFA0C544B7A60469152008633F55CF49eusaamb105erics_-- From nobody Wed Jan 28 20:04:05 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7B31A1B55 for ; Wed, 28 Jan 2015 20:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrNmcbOdjxXD for ; Wed, 28 Jan 2015 20:03:54 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688C01A1AB4 for ; Wed, 28 Jan 2015 20:03:54 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-c7-54c9520f39a0 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E0.F1.25146.F0259C45; Wed, 28 Jan 2015 22:18:07 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 23:03:52 -0500 From: Uma Chunduri To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4g5tkJK6AgABd/QCAADiAgIAAFPfggAEzewCAAC4IgIAGNx+wgAGluwCAIVq8UA== Date: Thu, 29 Jan 2015 04:03:52 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F55CF65@eusaamb105.ericsson.se> References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se> <065a01d02a99$71490c80$53db2580$@olddog.co.uk> In-Reply-To: <065a01d02a99$71490c80$53db2580$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXRPuC5/0MkQg3db5C1+9Nxgtri1dCWr A5PHkiU/mTxWbF7JGMAUxWWTkpqTWZZapG+XwJXx5Hsfc0GfSMXlr2+YGxhn8XUxcnJICJhI TH2/kx3CFpO4cG89WxcjF4eQwBFGif5Xu5hAEkICyxklZn2MALHZBPQkPk79CdYgIhAkseVR GyuILSyQLrFg/Uw2iHiGxOolz1gg7CyJ71P+g9ksAqoSqx7tBavhFfCVaNx0iQVi2XwWiQ1f V4IlOAWsJdY92QdmMwJd9P3UGrAjmAXEJW49mc8EcamAxJI955khbFGJl4//sULYShKTlp5j hajXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkaO0uLUstx0 I8NNjMB4OCbB5riDccEny0OMAhyMSjy8GwxPhgixJpYVV+YeYpTmYFES5y27cjBESCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA6MLV93PL7/mTIsJeHJE5VcGx/li78SlgSemGqub//7IxFZU eWz38//PlAylFNfXbzv+WblUvsKaz2Lvw01ed9i2OhWn9h6ZoXo95brk/zsHZb/3lwrEXl0k ECu8qKUo4EX3mqSmT2oLjxzxk1k/1fXJ/IdHzjeKhgldz2lXD+731J1mFm7tNU+JpTgj0VCL uag4EQB0EFXyaAIAAA== Archived-At: Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 04:04:02 -0000 Hi Adrian, In-line [Uma1]: =3D=3D=3D Uma>> 1. Is it on every hop/LSR along the path the whole packet with label= stack had >> to be decrypted and encrypted with Mel? If yes, I= MO this is really >> bad w.r.t performance (issues of key exchange fo= r thousands of LSPs=20 >> and load associated would be insignificant in com= parison perhaps?). >> From this PoV content in section 1.2 is critical. >The text in the introduction: >MPLS opportunistic security can be achieved between adjacent Label >Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and >also between end points of an LSP....was intended to say that there = are two options: >1. encrypt between two adjacent LSRs on an LSP 2. encrypt between th= e end-points of=20 >an LSP In the latter case you would not encrypt and decrypt at each h= op (and indeed would=20 >not be able to since the keys would only be known at the end points). [Uma1]: Exactly and I got that.=20 In case 1, above its pretty much each LSR has to decrypt th= e packet to get the top label and encrypt it=20 again with the keys exchanged with neighbor. In case 2, thi= s process could be reduced a bit as you may=20 eliminate few LSRs as keys would be known between the end po= ints. But the important point here is - packet is getting encrypte= d and decrypted=20 multiple times; which is not TRUE if IPsec is used between = the entry and exit ASBRs (transport mode). It's good to capture this. =20 [Uma1]: Also, case2 assumption may not hold good, if labels are learnt = Via IGPs (Segment routing cases) as the end points may=20 not be neighbors and hence no key exchanging session. Thi= s need to be clarified a bit in the document.=20 >You are right to point at section 1.2 (and we do need to write that = section :-) because L2=20 >solutions (such as MACsec) are typically used on a hop-by-hop basis.= I am not clear that MACsec=20 >used in this way is a significant performance issue (I think chips c= an do L2 security at line speed), >although it might cause additional power consumption. [Uma1]: It's good to see, but in comparison to transport mode IPSec, IMO, = it's significant forwarding=20 burden on each LSR, even crypto functionality is done in h= ardware. From nobody Wed Jan 28 20:16:06 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E091A1B71; Wed, 28 Jan 2015 20:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKjFyXGxkO1P; Wed, 28 Jan 2015 20:15:55 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C0F1A1B61; Wed, 28 Jan 2015 20:15:54 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-36-54c954df46b3 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C7.12.25146.FD459C45; Wed, 28 Jan 2015 22:30:07 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 23:15:52 -0500 From: Uma Chunduri To: Lizhenbin , "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment Thread-Index: AdAwwguGjUBqe0n9TwWjptOjDFAVZwAFpwMgAIEUtV0ACVGPwABdgjZRAcAYFTA= Date: Thu, 29 Jan 2015 04:15:52 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F55CF8F@eusaamb105.ericsson.se> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D2C6A7430@nkgeml506-mbx.china.huawei.com>, <11734_1421337421_54B7E34C_11734_7840_1_53C29892C857584299CBF5D05346208A0EB05CE7@PEXCVZYM11.corporate.adroot.infra.ftgroup> <5A5B4DE12C0DAC44AF501CD9A2B01A8D477269D7@nkgeml506-mbx.china.huawei.com>, <25686_1421575981_54BB872D_25686_9686_1_53C29892C857584299CBF5D05346208A0EB085CD@PEXCVZYM11.corporate.adroot.infra.ftgroup> <5A5B4DE12C0DAC44AF501CD9A2B01A8D47727D4A@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D47727D4A@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F55CF8Feusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLrHW/d+yMkQg0cH1C1+7JjDbLG78Q+7 xa2lK1ktjl/4zejA4tFy5C2rx5IlP5k8Wp6dZAtgjuKySUnNySxLLdK3S+DKuHt6BVPBn1Ms Fd8nv2FvYPwxn6WLkYNDQsBE4m+bdxcjJ5ApJnHh3nq2LkYuDiGBI4wSPT+fM0E4yxklfu49 xghSxSagJ/Fx6k92kISIQAujxJqT61lBJjELKEucuisDUiMsUCZx4E0zG4gtIlAucevLE1YI 20/i7JTP7CA2i4CqxMu1b8BsXgFfiQPzt0Ite8Ms0dB4HizBKRAm0fb3HJjNCHTe91NrmEBs ZgFxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rBC2ksSkpedYIerzJd5ueswCsUxQ4uTMJywTGEVn IRk1C0nZLCRlEHEtiXkNv6FqFCWmdD9kh7A1Ja5MPgRla0ssW/iaeQEj+ypGjtLi1LLcdCPD TYzAyDsmwea4g3HBJ8tDjAIcjEo8vBsMT4YIsSaWFVfmHmKU5mBREuctu3IwREggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVAPjbPH0qx67JKYkJjyTOGWcVjPD/sgLx7WrxbvOrtsw5UvBacW+ YKM9E1v/XXkxLfzV7JhDO+OPK4RsCFeMf6IUeFDf8hR73Vo3r7uVd/Zm35Fjune0OWbF4Uw3 s90bTaIr56z7mnBj8fy3EtvOCm1gza6qLJ87tfzHB5ND0UoGH3K6hLclvPGdp8RSnJFoqMVc VJwIAP9m4B6dAgAA Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 04:16:01 -0000 --_000_1B502206DFA0C544B7A60469152008633F55CF8Feusaamb105erics_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iaW4sDQoNCg0KPkFzIHRvIHlvdXIgc3VnZ2VzdGVkIHNvbHV0aW9uIG9mIHRoZSBjb250 cm9sIHBsYW5lLCBpdCBjYW4gYmUgZG9uZSwgYnV0IGl0IGhhcyBiZWVuIHRoZSBlbmQtdG8tZW5k IHBhdGgNCg0KPmNhbGN1bGF0aW9uIGxpa2UgVEUgaW5zdGVhZCBvZiB0aGUgdHJhZGl0aW9uYWwg cm91dGUgcGF0aCBjYWxjdWxhdGlvbi4NCg0KR29uZSB0aHJvdWdoIHRoZSBleGNoYW5nZSBiZWxv dy4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3QgqEMNCklNTywgaXShr3MgYSBkZXBsb3ltZW50IGlz c3VlIGlmIFMxMyBkb2VzbqGvdCBzdXBwb3J0IG5laXRoZXIgU1Igbm9yIExEUC4gSWYgTERQIGlz IHN1cHBvcnRlZCBzdGl0Y2hpbmcgc2hvdWxkIGhhcHBlbiBvbiBTMTIgZnJvbSBTUiB0byBMRFAu DQpOb3csIGluZ3Jlc3Mgbm9kZSBuZWVkIG5vdCBoYXZlIGFuIGlkZWEgb2YgdGhlIHN0aXRjaGlu ZyAgZXZlbiBpZiBTMTQgaXMgbm9uLVNSICwgYXMgbG9uZyBhcyBpdKGvcyBsYWJlbC9pbmRleCBp cyBhZHZlcnRpc2VkIHRocm91Z2ggYmluZGluZyBTSURzLg0KDQpUaGUgbWlzc2luZyBwb2ludCBB RkFJQ1QgaXMgb24gobBleHBsYW5hdGlvbqGxIG9mIHByb2Nlc3Npbmcgb2YgYmluZGluZyBTSURz IChmb3IgbWFwcGluZyBzZXJ2ZXIgZnVuY3Rpb25hbGl0eSkgYXQgaW5ncmVzcyBub2RlICAtDQpp LmUuLCBub3Qgb25seSBTMTIgd2hpY2ggcmVhbGl6ZXMgUzEzIChub24tU1IgY2FwYWJsZSBhbmQg ZG8gdGhlIHJpZ2h0IHRoaW5nKSBidXQgUzExIHNob3VsZCBhbHNvIGNvbXB1dGUgYW5kIGFkZA0K TFNQIGZvciB0aGUgYmluZGluZyBTSUQgZm9yIFMxNCBpbmRleCB3aXRoIGJlc3QgcGF0aCBuZXh0 LWhvcCAgKHdoaWNoIGlzIGFuIFNSIG5vZGUpLg0KDQpJcyB5b3VyIGlzc3VlcyBhZGRyZXNzZWQg d2l0aCB0aGlzPw0KLS0NClVtYSBDLg0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpemhlbmJpbg0KU2VudDogTW9uZGF5LCBKYW51 YXJ5IDE5LCAyMDE1IDEwOjQyIFBNDQpUbzogYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTsgc3By aW5nQGlldGYub3JnDQpTdWJqZWN0OiBbc3ByaW5nXSC08Li0OiBOZXcgQ29tbWVudHMgb24gU2Vn bWVudCBSb3V0aW5nKDEpOiBDaGFsbGVuZ2Ugb2YgT3JkZXJlZCBtb2RlIGZvciBTUi1CRSBQYXRo IGFuZCBJbmNyZW1lbnRhbCBEZXBsb3ltZW50DQoNCg0KSGkgQnJ1bm8sDQoNClBsZWFzZSByZWZl ciB0byBteSBpbmxpbmUgY29tbWVudHMgaWRlbnRpZmllZCB3aXRoICdbUm9iaW5dJy4NCg0KDQoN ClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCreivP7IyzogYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbT4gW2JydW5vLmRlY3JhZW5lQG9yYW5nZS5jb21dDQq3osvNyrG85Dog MjAxNcTqMdTCMTjI1SAxODoxMw0KytW8/sjLOiBMaXpoZW5iaW47IHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0K1vfM4jogUkU6IE5ldyBDb21tZW50cyBvbiBTZWdtZW50 IFJvdXRpbmcoMSk6IENoYWxsZW5nZSBvZiBPcmRlcmVkIG1vZGUgZm9yIFNSLUJFIFBhdGggYW5k IEluY3JlbWVudGFsIERlcGxveW1lbnQNCkhpIFJvYmluLA0KDQpQbGVhc2Ugc2VlIGlubGluZSBb QnJ1bm8yXQ0KDQpSZWdhcmRzLA0KQnJ1bm8NCg0KRnJvbTogTGl6aGVuYmluIFttYWlsdG86bGl6 aGVuYmluQGh1YXdlaS5jb21dDQpTZW50OiBTdW5kYXksIEphbnVhcnkgMTgsIDIwMTUgNjo0MSBB TQ0KVG86IERFQ1JBRU5FIEJydW5vIElNVC9PTE47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3By aW5nQGlldGYub3JnPg0KU3ViamVjdDogPz86IE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRp bmcoMSk6IENoYWxsZW5nZSBvZiBPcmRlcmVkIG1vZGUgZm9yIFNSLUJFIFBhdGggYW5kIEluY3Jl bWVudGFsIERlcGxveW1lbnQNCg0KDQpIaSBCcnVubywNCg0KUGxlYXNlIHJlZmVyIHRvIG15IGNv bW1lbnRzIGlubGluZSBpZGVudGlmaWVkIGJ5ICdbUm9iaW5dJy4NCg0KRm9yIExEUCwgdGhlcmUg YXJlIHR3byBMRFAgY29udHJvbCBtb2RlczoNCg0KLS0gT3JkZXJlZCBtb2RlOiBEZXBlbmQgb24g dGhlIGVncmVzcyBhbmQgdGhlIGRvd25zdHJlYW0gbm9kZQ0KDQotLSBJbmRlcGVuZGVudCBtb2Rl OiBEZXBlbmQgb24gdGhlIGRvd25zdHJlYW0gbm9kZS4NCg0KSW4gZmFjdCwgU1IgaXMgYmFzZWQg b24gSUdQIGFuZCBpbnRyb2R1Y2VzIG9uZSB0b3RhbGx5IGRpZmZlcmVudCBtb2RlIHdoaWNoIEkg Y2FsbGVkIGFzIGZsb29kaW5nIG1vZGUuDQoNCi0tIEZsb29kaW5nIG1vZGU6IERlcGVuZCB0aGUg bm9kZSdzIHNlbGYNCg0KW0JydW5vMl0gSaGvbSBub3Qgc3VyZSB0byBzZWUgd2hhdCB5b3UgbWVh biBieSChsGRlcGVuZKGxLg0KDQpJbiBMRFAgb3JkZXJlZCBtb2RlLCB0aGVyZSBpcyBhIHNpZ25h bGluZyBlbmQgdG8gZW5kIGZyb20gdGhlIGVncmVzcyB0byB0aGUgaW5ncmVzcywgcm91Z2hseSBh IGxhIKGwZGlzdGFuY2UgdmVjdG9yobEuDQoNCkluIExEUCBpbmRlcGVuZGVudCBtb2RlLCB0aGUg c2lnbmFsaW5nIGlzIGxpbWl0ZWQgdG8gYmUgMiBhZGphY2VudCBub2RlcyAobWUsIG15IGRvd25z dHJlYW0pLiBTbyByb3VnaGx5IG5vIHNpZ25hbGluZy4NCg0KSW4gU1BSSU5HLCB0aGUgTGluayBT dGF0ZSBwYXJhZGlnbSBpcyB1c2VkLiBZb3Uga25vdyB0aGUgc3RhdHVzIG9mIHRoZSBlZ3Jlc3Mg YW5kIGFsbCB0aGUgbGlua3MgICYgbm9kZXMuDQoNCltSb2Jpbl0NCg0KMS4gVGhlICdkZXBlbmQn IG1lYW5zIHRoZSBsYWJlbCBiaW5kaW5nIGZvciB0aGUgbm9kZXMgaW4gc2VnbWVudCByb3V0aW5n IGlzIHN0YWJsZSwgYWZ0ZXIgdGhlIGxhYmVsIGJpbmRpbmcgYXJlIGZsb29kZWQsIGZvcg0KDQpl dmVyeSBub2RlcyBpbiB0aGUgbmV0d29yaywgIG9uY2UgdGhlcmUgYXJlIHRoZSByb3V0ZXMgdG8g dGhlIGRlc3RpbmF0aW9uIG5vZGVzIGFkZHJlc3MsIHRoZSBpbmdyZXNzIExTUCBjYW4gYmUgc2V0 dXAgdG8gYmUgdXNlZA0KDQpmb3IgVlBOLCBldGMuIEZvciBMRFAgaW5kZXBlbmRlbnQsIGV2ZW4g aWYgdGhlIHJvdXRlIGlzIGF2YWlsYWJsZSwgaXQgaGFzIHRvIHdhaXQgZm9yIHRoZSBsYWJlbCBt YXBwaW5nIGZyb20gdGhlIGRvd25zdHJlYW0gdG8NCg0Kc2V0dXAgdGhlIGluZ3Jlc3MgTERQIHRv IGJlIHVzZWQgZm9yIFZQTiwgZXRjLg0KDQoyLiBJIGFtIG5vdCBzdXJlIHdoYXQncyB0aGUgbGlu ayBzdGF0ZSBwYXJhZGlnbSB5b3UgbWVhbj8gRm9yIExEUCwgaXQgZGVwZW5kcyBvbiBJR1AsIGl0 IGNhbiBhbHNvIHVzZSB0aGUgbGluayBzdGF0ZSBwYXJhZGlnbS4NCg0KVGhlIG9ubHkgZGlmZmVy ZW5jZSBpcyB0aGF0IHRoZSBzZWdtZW50IHJvdXRpbmcgY2FuIHVzZSBpdCBjb252ZW5pZW50bHkg c2luY2UgdGhlIGxhYmVsIGJpbmRpbmcgY29leGlzdHMgd2l0aCBsaW5rIHN0YXRlIHBhcmFkaWdt Lg0KDQoNCg0KDQoNCg0KDQoNCg0KQ29tcGFyaW5nIHRoZSB0aGVyZSBtb2RlLCB0aGUgZmxvb2Rp bmcgbW9kZSBpcyBtb3JlIGluZGVwZW5kZW50LiBUaGlzIG1lYW5zIGl0IGlzIHRoZSBlc3NpZXN0 IG9uZSB0bw0KDQpzZXQgdXAgdGhlIGludGVycnVwdGVkIExTUCBhbmQgbGVhayB0aGUgdXNlbGVz cyB0cmFmZmljIGludG8gdGhlIG5ldHdvcmsgd2hpY2ggd2lsbCBoYXZlIG5lZ2F0aXZlIGVmZmVj dA0KDQpvbiB0aGUgbm9ybWFsIHRyYWZmaWMgaW4gdGhlIG5ldHdvcmsuDQoNCltCcnVubzJdIEkg ZGlzYWdyZWUuIFlvdSBoYXZlIHRoZSBsaW5rIHN0YXRlIHZpc2lvbiBvZiB0aGUgd2hvbGUgU1BS SU5HIG5ldHdvcmsuIFRoYXShr3MgdGhlIKGwbW9kZaGxIHdoaWNoIHByb3ZpZGVzIHRoZSBtb3Jl IGluZm9ybWF0aW9uLiBTcGVjaWZpY2FsbHksDQoNCiBZb3Uga25vdyB0aGF0IHRoZSBlZ3Jlc3Mg aXMgobB1cKGxIGFuZCB0aGF0IGFsbCBub2RlcyBvbiB0aGUgd2F5IGFyZSBhbHNvIKGwdXChsSBh bmQgcmVhZHkgKEkgZG8gbWVhbiBmcm9tIGEgU1BSSU5HL01QTFMgc3RhbmRwb2ludCkuDQoNCk9i dmlvdXNseSwgdGhpcyBpcyBhIGNvbnRyb2wgcGxhbiB2aXNpb24gb25seS4gSWYgeW91IHdhbnQg dG8gY2hlY2sgdGhlIEZJQiwgeW91IHdpbGwgbmVlZCB0byB0ZXN0IGl0IChlLmcuIExTUCBQaW5n KQ0KDQpbUm9iaW5dDQoNCkkgdW5kZXJzdGFuZCB5b3VyIHBvaW50IGFib3V0IHRoZSBjb250cm9s IHBsYW5lIHNvbHV0aW9uIHRvIHNvbWUgZXh0ZW50LiBJbiBmYWN0LCBJIGhhdmUgYWxzbyB0aG91 Z2h0IGFib3V0IHNvbHV0aW9ucyBmb3IgdGhlIHRoZSBwb3NzaWJsZQ0KDQppbnRlcnJ1cHRpb24g aXNzdWVzIGZvciBTUi1CRSBwYXRoLiBBcyB0byB5b3VyIHN1Z2dlc3RlZCBzb2x1dGlvbiBvZiB0 aGUgY29udHJvbCBwbGFuZSwgaXQgY2FuIGJlIGRvbmUsIGJ1dCBpdCBoYXMgYmVlbiB0aGUgZW5k LXRvLWVuZCBwYXRoDQoNCmNhbGN1bGF0aW9uIGxpa2UgVEUgaW5zdGVhZCBvZiB0aGUgdHJhZGl0 aW9uYWwgcm91dGUgcGF0aCBjYWxjdWxhdGlvbi4NCg0KDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoN ClJvYmluDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7I yzogYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3Jhbmdl LmNvbT4gW2JydW5vLmRlY3JhZW5lQG9yYW5nZS5jb21dDQq3osvNyrG85DogMjAxNcTqMdTCMTXI 1SAyMzo1Ng0KytW8/sjLOiBMaXpoZW5iaW47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPg0K1vfM4jogUkU6IE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoMSk6 IENoYWxsZW5nZSBvZiBPcmRlcmVkIG1vZGUgZm9yIFNSLUJFIFBhdGggYW5kIEluY3JlbWVudGFs IERlcGxveW1lbnQNCkhpIFJvYmluLA0KDQpUaGFua3MgZm9yIHlvdXIgaW50ZXJlc3Qgb24gU1Iv U1BSSU5HLg0KUGxlYXNlIHNlZSBpbmxpbmUuIFtCcnVub10NCg0KRnJvbTogc3ByaW5nIFttYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaXpoZW5iaW4NClNlbnQ6 IFRodXJzZGF5LCBKYW51YXJ5IDE1LCAyMDE1IDI6MTIgUE0NClRvOiBzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzcHJpbmddIE5ldyBDb21tZW50cyBv biBTZWdtZW50IFJvdXRpbmcoMSk6IENoYWxsZW5nZSBvZiBPcmRlcmVkIG1vZGUgZm9yIFNSLUJF IFBhdGggYW5kIEluY3JlbWVudGFsIERlcGxveW1lbnQNCg0KDQpIaSBhbGwgYXV0aG9ycyBvZiBz ZWdtZW50IHJvdXRpbmcsDQoNCg0KDQpXaGVuIHdlIGRpZCByZXNlYXJjaCBvbiBzZWdtZW50IHJv dXRpbmcgYW5kIGZvdW5kIHNvbWUgbmV3IGlzc3Vlcy4gQ291bGQgeW91IGhlbHAgY2xhcmlmeSBp ZiB0aGUgYW5hbHlzaXMgaXMgcmlnaHQgYW5kDQoNCmhvdyB3aWxsIHRoZXkgYmUgdGFrZW4gaW50 byBhY2NvdW50IGluIHRoZSBkZXNpZ24gb2YgU1IuDQoNCg0KDQpUaGlzIGlzIHRoZSBmaXJzdCBp c3N1ZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKE5vbi1TUikNCiAgUzExLS0tLS0t LS0tLS1TMTItLS0tLS0tLS0tUzEzLS0tLS0tLS0tUzE0DQogICB8ICAgICAgICAgICAgIHwgICAg ICAgICAgICB8ICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAg ICAgICAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8DQog IFMyMS0tLS0tLS0tLS0tUzIyLS0tLS0tLS0tLVMyMy0tLS0tLS0tLVMyNA0KDQpBcyBhYm92ZSB0 b3BvbG9ieSwgdGhlcmUgYXJlIDggbm9kZXMgYW5kIGFzc3VtZSBhbGwgdGhlIG1ldGljcyBvZiB0 aGUgbGlua3MgYXJlIDEgYW5kIFZQTnMgYXJlIGRlcGxveWVkDQpvbiBTMTEvUzIxL1MxNC9TMjQu DQoNCklmIExEUCBpcyB1c2VkIGFzIHRoZSB0dW5uZWwgZm9yIFZQTiBvbiBTMTEvUzE0LCBzaW5j ZSBMRFAgY2FuIHN1cHBvcnQgdGhlIG9yZGVyZWQgbW9kZS4gVGhlIExTUCBmb3IgdGhlIFMxNCB3 aWxsIGJlDQpzZXR1cCBhcyB0aGUgb3JkZXIgUzE0LT5TMTMtPlMxMi0+UzExIGZvciBkaXN0cmli dXRpb24gb2YgbGFiZWwgbWFwcGluZy4gQW5kIHRoZSBzaG9ydGVzdCBwYXRoIGZvciByb3V0ZXMN CnRvIFMxNCBpcyBhbHNvIFMxMS0+UzEyLT5TMTMtPlMxNC4gU28gdGhlIGVuZC10by1lbmQgTFNQ IHRvIFMxNCBpcyBzZXR1cC4gSWYgb25lIG5vZGUgKGUuZy4gUzEzKSBkb2VzIG5vdA0Kc3VwcG9y dCBMRFAsIGFjY29yZGluZyB0byBMRFAgb3JkZXJlZCBtb2RlLCB0aGUgZW5kLXRvLWVuZCBMU1Ag Y2Fubm90IHNldHVwIHNpbmNlIFMxMiBkb2VzIG5vdCByZWNlaXZlIHRoZSBsYWJlbA0KbWFwcGlu ZyBmcm9tIHRoZSBleGFjdCBuZXh0aG9wIG9mIHRoZSByb3V0ZSwgUzEzIGFuZCBpdCB3aWxsIG5v dCBkaXN0cmlidXRlIHRoZSBsYWJlbCBtYXBwaW5nIHRvIFMxMS4gQW5kIHRoZQ0KDQpyZXN1bHQg aXMgdGhhdCB0aGUgVlBOIG9uIFMxMSBjYW5ub3QgdGFrZSB0aGUgTFNQIHNpbmNlIHRoZSBMU1Ag Y2Fubm90IHNldHVwIG9uIFMxMS4NCg0KW0JydW5vXQ0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mIHlv dXIgY2FzZSBpcyB0aGUgZm9sbG93aW5nLCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJoa9tIHdyb25n Og0KDQpUaGVyZSBpcyBubyBTUFJJTkcvU1IuIEFsbCBub2RlcyBzdXBwb3J0IExEUC4gUzExLCBT MTIsIFMxNCB1c2Ugb3JkZXJlZCBtb2RlLiBTMTMgdXNlIGluZGVwZW5kZW50IG1vZGUuDQoNCg0K DQpGaXJzdCwgc3VjaCBjYXNlcyBoYXBwZW4gdG9kYXkgaW4gbXVsdGlwbGUgdmVuZG9yIG5ldHdv cmtzIHNpbmNlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbiB1c2VkIGRpZmZlcmVudCBvcHRpb25z Lg0KDQpUaGVuLCBJIGJlbGlldmUgdGhhdCB5b3VyIHVuZGVyc3RhbmRpbmcgb2YgTERQIGluZGVw ZW5kYW50IG1vZGUgIGlzIGluY29ycmVjdC4gSW4gaW5kZXBlbmRlbnQgbW9kZSwgUzEzIGFsd2F5 cyBhZHZlcnRpc2VzIHRoZSBTMTQgRkVDIHRvIGl0cyBuZWlnaGJvciwgZXZlbiBpZiBpdCBkb26h r3QgZ2V0cyBhIGxhYmVsIG1hcHBpbmcgZnJvbSBpdHMgZG93bnN0cmVhbSBTMTQuIFRoaXMgRkVD IGlzIHRoZW4gcHJvcGFnYXRlZCB0byBTMTEgaW4gb3JkZXJlZCBtb2RlLg0KDQpBcyBhIHJlc3Vs dCwgUzExIGdldHMgYSBsYWJlbCBmb3IgUzE0IGFuZCB3aWxsIHVzZSBTMTQgZm9yIHRoZSBWUE4u IEhvd2V2ZXIgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUgdGhlIHRyYWZmaWMgd2lsbCBiZSBkcm9w cGVkIG9uIFMxMy4NCg0KW1JvYmluXSBJdCBoYXMgZXhwbGFpbmVkIGluIHRoZSBwcmV2aW91cyBt YWlsLiBQbGVhc2UgcmV0aGluayB0aGUgY2FzZSB0aGF0IFMxMyBkb2VzIG5vdCBzdXBwb3J0IExE UCBpbnN0ZWFkIG9mIHRoYXQgUzEzIHN1cHBvcnQgaW5kZXBlbmRlbnQgbW9kZS4NCg0KDQoNCg0K DQoNCg0KSWYgU1ItQkUgcGF0aCBpcyB1c2VkIGFzIHRoZSB0dW5uZWwgZm9yIFZQTiBvbiBTMTEv UzE0IGFuZCBhc3N1bWUgdGhlIFMxMyBjYW5ub3Qgc3VwcG9ydCB0aGUgU1IsIGFjY29yZGluZyB0 byBteQ0KdW5kZXJzdGFuZGluZywgdGhlcmUgd2lsbCBiZSBhbiBTUi1CRSBwYXRoIGZvciB0aGUg ZGVzdGluYXRpb24gUzE0IHdoaWNoIGlzIGludGVycnVwdGVkIGF0IFMxMi4gVGhpcyBpcyBzaW1p bGFyIGFzDQp0aGUgaW5kZXBlbmRlbnQgbW9kZSBvZiBMRFAuIElmIHRoaXMgVlBOIHRha2VzIHRo aXMgU1ItQkUgUGF0aCBhdCBTMTEsIHRoZSBWUE4gdHJhZmZpYyB3aWxsIGJlIGRyb3BwZWQgYXQg UzEyLg0KDQpJZiB0aGUgYW5hbHlzaXMgaXMgcmlnaHQuIEkgaGF2ZSB0d28gcXVlc3Rpb25zOg0K MS4gSG93IHdpbGwgU1IgYXZvaWQgc3VjaCByaXNrPyBTb21lIGVuaGFuY2VtZW50IG9uIFNSIG9y IGp1c3QgbGVhdmUgaXQgdG8gdGhlIGxvY2FsIGltcGxtZW50YXRpb24gKEZvciBleGFtcGxlLA0K TFNQIHBpbmcgaXMgZmlyc3RseSB1c2VkIHRvIGNoZWNrIHRoZSBjb25uZWN0aXZpdHkpPw0KDQpb QnJ1bm9dIEEgcHJpb3JpLCBJIGNvdWxkIHNlZSAzIGFuc3dlcnMNCg0KLWEtIEkgZ3Vlc3Mgb25l IGNvdWxkIHVzZSBJR1AgbXVsdGktdG9wb2xvZ3kgdG8gaGFuZGxlIGEgZGlmZmVyZW50IHRvcG9s b2d5IGJldHdlZW4gdGhlIElQIGFuZCB0aGUgTVBMUyBvbmUuIFRoaXMgaXMgc2ltaWxhciB0byBJ UHY2IGludHJvZHVjdGlvbiBpbiBhIElQdjQgbmV0d29yay4NCg0KLWItIEFub3RoZXIgb3B0aW9u IGlzIHRvIGVuYWJsZSBpbnRlcndvcmtpbmcgYmV0d2VlbiBMRFAgYW5kIFNSL1NQUklORyB0byBo YW5kbGUgc3VjaCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50LiBQbGVhc2Ugc2VlIHRoZSBmb2xsb3dp bmcgZHJhZnQgZm9yIGFuIGludHJvZHVjdGlvbiBvbiB0aGlzIGludGVyd29ya2luZzogaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpbHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRp bmctbGRwLWludGVyb3AtMDIgQ29tbWVudHMgYXJlIHdlbGNvbWVkIGFzIEkgYWdyZWUgd2l0aCB5 b3UgdGhhdKGvcyBhbiBpbXBvcnRhbnQgdG9waWMgZm9yIGJyb3duZmllbGQgaW5jcmVtZW50YWwg ZGVwbG95bWVudA0KDQpbUm9iaW5dIEkgZG8gbm90IHRoaW5rIG11bHRpLXRvcG9sb3R5IGFuZCBT Ui1MRFAgaW50ZXJvcCB3aWxsIHByb3Bvc2UgY2FuIG5vdCBzb2x2ZWQgdGhlIGlzc3VlZC4NCg0K W0JydW5vMl0gTm90IHN1cmUgd2h5IHlvdSB1c2UgZG91YmxlIG5lZ2F0aW9uLiBCdXQgaW4gc2hv cnQsIHlvdSBhbHNvIGJlbGlldmUgdGhpcyBzaG91bGQgd29yay4NCg0KDQoNCltSb2Jpbl0NCg0K QnV0IHRoZSBwcmljZSBpcyBoaWdoLiBJbiBmYWN0LCBJIGhhdmUgcmVhZCB0aGUgZHJhZnQuIEJ1 dCBJIGRvIG5vdCB0aGluayB0aGluayBpdCBpcyBhbiBlYXN5IHdvcmsgYWNjb3JkaW5nIHRvIHRo ZSBwYXN0IGV4cGVyaWVuY2UgaW4gdGhlIE1QTFMgd29ybGQuIEkgd2lsbCBleHBsYWluIHRoZSBw b3NzaWJsZSB3b3JrIHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQgaW4gdGhlIHN1YnNlcXVl bnQgY29tbWVudHMuIEEgc21hbGwgZXhhbXBsZSwgU1IgY2xhaW1lZCBpdCBjYW4gcmVwbGFjZSB0 aGUgSUdQLUxEUCBzeW5jLiBCdXQgYXMgYSBkZXZlbG9wZXIsIEkgYW0gc3VyZSB0aGF0IHRoZSBl ZmZvcnQgb2YgaW1wbGVtZW50YXRpb24gb2YgU1ItTERQIGludGVyb3AgaXMgbXVjaCBtb3JlIHRo YW4gSUdQLUxEUCBzeW5jLiBDYW4gSSBzYXkgdGhhdCBpbiBmYWN0IFNSIGRvZXMgbm90IHNhdmUg b3VyIGVmZm9ydCwgYnV0IG1ha2UgbW9yZSB0cm91YmxlPw0KDQpbQnJ1bm8yXSBUaGUgdXNlIG9m IFNSLUxEUCBpbnRlcndvcmsgYWxsb3dzIGluY3JlbWVudGFsIGRlcGxveW1lbnQgb2YgU1Igd2l0 aCBpbmNyZW1lbnRhbCBiZW5lZml0IGJ1dCBpcyBpbmRlZWQgYW4gYWRkaXRpb25hbCB3b3JrLiBJ dCBpcyBvbmx5IG5lZWRlZCBpbiBhIG11bHRpLXZlbmRvci9wbGF0ZWZvcm0gbmV0d29yayB3aGVu IGFsbCBub2RlcyBkbyBub3Qgc3VwcG9ydCBTUiwgZm9yIGEgbGltaXRlZCBkdXJhdGlvbi4gSXSh r3Mgbm90IGxvbmcgdGVybSBmZWF0dXJlLiBJZiB5b3UgYXNrIG1lLCBJIHdvdWxkIHJhdGhlciBu b3QgaGF2ZSB0byB1c2UgaXQsIGJ1dCBpdCBkZXBlbmRzIG9uIHRoZSB3aWxsaW5nIG9mIHZlbmRv cnMgdG8gaW1wbGVtZW50IHRoZSByZXF1aXJlZCBJR1Agc3ViLVRMVnMuIElmIHdlIGFsbCBhZ3Jl ZSB0aGF0IGltcGxlbWVudGluZyBzdWNoIHN1Yi1UTFYgaXMgZWFzaWVyIGFuZCBiZXR0ZXIgKG9y IGlmIHlvdSBhc3N1bWUgbW9ubyB2ZW5kb3IgZGVwbG95bWVudCwgd2hpY2ggSSBkb26hr3QpIHdl IHdvbqGvdCBuZWVkIHRvIGRlcGxveS9pbXBsZW1lbnQgTERQLVNQUklORyBpbnRlcndvcmtpbmcu IFRoaXMgaXMgYSByb2FkbWFwIHZlcnN1cyBkZXBsb3ltZW50IGRhdGUgaXNzdWUsIHNvIGEgYml0 IG91dCBvZiBzY29wZSBvZiB0aGlzIG1haWxpbmcgbGlzdC4gSG93ZXZlciwgZnJvbSB0aGUgbWFp bGluZyBsaXN0IHN0YW5kcG9pbnQsIHRoZSBwb2ludCBpcyB0aGF0IHRoaXMgY2FuIGJlIGRvbmUg KHNwZWNpZmllZCBhbmQgaW1wbGVtZW50ZWQpDQoNCg0KDQotYy0gQW5vdGhlciBvcHRpb24gaXMg dG8gaW5jcmVtZW50YWxseSBkZXBsb3kgU1IgaW4gYWRkaXRpb24gdG8gTERQIGFuZCB0byBwcmVm ZXIgTERQIGZvciBlbmQgdG8gZW5kIExTUCAodXNpbmcgYWRtaW5pc3RyYXRpdmUgZGlzdGFuY2Up LiBUaGVuIGl0oa9zIHVwIHRvIGVhY2ggU1IgYXBwbGljYXRpb24gdG8gc2VlIGhvdyBtdWNoIHRo ZXkgY2FuIHRha2UgYmVuZWZpdCBvZiBwYXJ0aWFsIFNSIGRlcGxveW1lbnQuIGUuZy4gRlJSIChU SS1MRkEsIFJMRkEgb3IgRExGQSkgbWF5L3Nob3VsZCBiZSBhYmxlIHRvIGJlbmVmaXQgZnJvbSBw YXJ0aWFsIGRlcGxveW1lbnQuDQoNCltSb2Jpbl0gVGhlIGRpZmZpY3VsdHkgaXMgdGhhdCB0aGUg aW5ncmVzcyBub2RlIGNhbm5vdCBkZXRlcm1pbmUgaWYgdGhlIFNSLUJFIHBhdGggaXMgZW5kLXRv LWVuZCB3aXRob3V0IGV4dHJhIG1ldGhvZHMgd2hpY2ggaXMgdW5uZWNlc3NhcnkgZm9yIHRoZSBM RFAgYWxyZWFkeSBkZXBsb3llZCBpbiB0aGUgd2hvbGUgbmV0d29yay4NCg0KW0JydW5vMl0gQWdh aW4sIE5vLiBwbGVhc2Ugc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnMtMDMjc2VjdGlvbi0zIFRoZSBpbmdyZXNz IGtub3dzLCB3aXRoaW4gaXRzIElHUCBhcmVhL2xldmVsLCBhbGwgbm9kZXMgd2hpY2ggc3VwcG9y dHMgU1BSSU5HIG9yIG5vdC4gVGhpcyBpbmNsdWRlcyBub2RlcyBvbiB0aGUgU1BUIHRvIHRoZSBl Z3Jlc3MuDQoNCg0KDQoNCg0KDQoNCkZZSSwgYXMgb2YgdG9kYXkvbXlzZWxmIEkgc2F5IHRoYXQg obBiobEgaXMgcmVxdWlyZWQgYW5kIKGwY6GxIGlzIG5pY2UgdG8gaGF2ZS4NCg0KMi4gQXNzdW1l IExEUCBpcyBhbHJlYWR5IGRlcGxveWVkIG9uIGFsbCBub2RlcyBpbiB0aGUgbmV0d29yayB0byBi ZWFyIFZQTiB0cmFmZmljLiBXaGVuIFNSLUJFIHBhdGggaXMgYWRvcHRlZCBpbiB0aGUNCm5ldHdv cmsgdG8gcmVwbGFjZSBMRFAgTFNQLCBzaW5jZSB0aGVyZSBpcyB0aGUgcG9zc2libGUgcmlzayBw cm9wb3NlZCBieSBpbnRlcnJ1cHRlZCBTUi1CRSBwYXRoIGFuZCBJIGRvIG5vdCB0aGluayBpdA0K DQppcyBpbXBvc3NpYmxlIHRvIGNhcmVmdWxseSBkZXRlcm1pbmUgdGhlIHVwZ3JhZGVkIG5vZGVz Lg0KDQpbQnJ1bm9dIEmhr20gbm90IHN1cmUgdG8gY29ycmVjdGx5IHVuZGVyc3RhbmQgeW91ciBs YXN0IHNlbnRlbmNlLiBXaXRoaW4gYW4gQVMgKHdlbGwgYXJlYS9sZXZlbCkgSXQgaXMgcG9zc2li bGUgdG8gaWRlbnRpZnkgbm9kZXMgd2hpY2ggYXJlIFNSL1NQUklORyBjb21wbGlhbnQgKG9yIG5v biBjb21wbGlhbnQpIGFzIHRoZXkgYWR2ZXJ0aXNlIHRoaXMgaW4gdGhlIGxpbmsgc3RhdGUgSUdQ Lg0KDQpbUm9iaW5dIEkgYWdyZWUgeW91ciBwcm9wb3NlZCB0aGUgaW5jcmVtZW50YWwgZGVwbG95 bWVudCBtZXRob2QgYnkgSUdQIGV4dGVuc2lvbiB0byBpZGVudGlmZWQgdGhlIFNSLW5vZGUuIFRo aXMgaXMgbm90IHdoYXQgbXkgb2JqZWN0aXZlLiBNeSBjYXNlIGlzIHRvIHNob3cgdGhhdCB0aGUg c2NvcGUgb2YgZW5kLXRvLWVuZCBMU1AgYW5kIHRoZSBzY29wZSBvZiB0aGUgU1Igbm9kZXMgaXMg ZGlmZmVyZW50LiBUaGUgaW5jcmVtZW50YWwgZGVwbG95bWVudCBvZiBTUiBjYXVzZSB0aGUgaXNz dWUgZm9yIHRoZSBlbmQtdG8tZW5kIExTUC4NCg0KIFtCcnVubzJdIEmhr20gbm90IHN1cmUgdG8g c2VlIHlvdXIgcG9pbnQuIEluIHBhcnRpY3VsYXIgYnkgobBlbmQtdG8tZW5kobEgdG8geW91IG1l YW4gd2l0aGluIGFuIGFyZWEvbGV2ZWwsIG9yIGFjcm9zcyBBU2VzPyBCZWNhdXNlIGFzIFNQUklO RyB1c2VzIHRoZSBJR1AsIElHUCBmcm9udGllcnMgbWFrZXMgYSBkaWZmZXJlbmNlLiBDYW4geW91 IHBsZWFzZSByZXBocmFzZSBvciBicmluZyBhbiBub24td29ya2luZyBleGFtcGxlPw0KDQoNCg0K U28gdGhlIG9ubHkgY2hvaWNlIGlzIHRvIHVwZ3JhZGUgYWxsIG5vZGVzIHRvIHN1cHBvcnQgU1Ig YWxsIGF0IG9uY2UuDQoNCltCcnVub10gTm8uDQoNCltSb2Jpbl0gSSBjYW4gYWdyZWUgeW91IHRo YXQgaXQgbWF5IGJlIG5lY2Vzc2FyeS4gQnV0IG1vcmUgZGV0YWlscyBiZSB0YWtlbiBpbnRvIGFj Y291bnQgYW5kIHRoZSBwcmljZSBtYXkgYmUgaGlnaCBhbmQgLg0KDQoNCg0KaXMgdGhhdCByaWdo dCB0aGF0IHRoZSBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IG9mIFNSIGluIHN1Y2ggc2NlbmFyaW8g aXMgZGlmZmljdWx0IHRvIGFkb3B0Pw0KDQoNCg0KDQoNCg0KDQpSZWdhcmRzLA0KDQpaaGVuYmlu KFJvYmluKQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5r IHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5 b3UuDQo= --_000_1B502206DFA0C544B7A60469152008633F55CF8Feusaamb105erics_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Robin,

 <= /p>

>As to your suggested solution of the cont= rol plane, it can be done, but it has been the end-to-end path

>calculation like TE instead of the tradit= ional route path calculation.

 <= /p>

Gone through the exchange= below. If I understand correct =A8C

IMO, it=A1=AFs a deployme= nt issue if S13 doesn=A1=AFt support neither SR nor LDP. If LDP is supporte= d stitching should happen on S12 from SR to LDP.

Now, ingress node need no= t have an idea of the stitching  even if S14 is non-SR , as long as it= =A1=AFs label/index is advertised through binding SIDs.

 <= /p>

The missing point AFAICT = is on =A1=B0explanation=A1=B1 of processing of binding SIDs (for mapping se= rver functionality) at ingress node  -

i.e., not only S12 which = realizes S13 (non-SR capable and do the right thing) but S11 should also co= mpute and add

LSP for the binding SID f= or S14 index with best path next-hop  (which is an SR node).

 <= /p>

Is your issues addressed = with this?

 <= /p>

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Monday, January 19, 2015 10:42 PM
To: bruno.decraene@orange.com; spring@ietf.org
Subject: [spring] =B4=F0=B8=B4: New Comments on Segment Routing(1): C= hallenge of Ordered mode for SR-BE Path and Incremental Deployment

 

Hi Bruno,

Please refer to my inline comments i= dentified with '[Robin]'.

 

Regards,

Robin

 

 

=B7=A2=BC=FE=C8=CB<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif";color:black">: bruno.decraene@orange.com = [bruno.decraene@orange.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2015=C4= =EA1=D4=C218=C8=D5 18:13
=CA= =D5=BC=FE=C8=CB: Lizhenbin; spring@ietf.org
=D6= =F7=CC=E2: RE: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-B= E Path and Incremental Deployment<= /span>

Hi Robin,

 <= /o:p>

Please see inline [Bruno2= ]

 <= /o:p>

Regards,

Bruno

 <= /o:p>

From:<= /b> Lizhenbin [mailto:lizhenbin@huawei.com]
Sent: Sunday, January 18, 2015 6:41 AM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: ??: New Comments on Segment Routing(1): Challenge of Ordere= d mode for SR-BE Path and Incremental Deployment

 <= /o:p>

Hi Bruno,

Please refer to my comments inline i= dentified by '[Robin]'.

For LDP, there are two LDP control m= odes:

-- Ordered mode: Depend on the = egress and the downstream node

-- Independent mode: Depend on the d= ownstream node.

In fact, SR is based on IGP and intr= oduces one totally different mode which I called as flooding mode.

-- Flooding mode: Depend the node's = self

[Bruno2] I=A1=AFm not sure to see what you me= an by =A1=B0depend=A1=B1.

In LDP ordered mode, there is a signaling end= to end from the egress to the ingress, roughly a la =A1=B0distance vector= =A1=B1.

In LDP independent mode, the signaling is lim= ited to be 2 adjacent nodes (me, my downstream). So roughly no signaling.

In SPRING, the Link State paradigm is used. Y= ou know the status of the egress and all the links  & nodes.

[Robin]

1. The 'depend' means the label binding for t= he nodes in segment routing is stable, after the label binding are flooded,=  for 

every nodes in the network,  once t= here are the routes to the destination nodes address, the ingress LSP can b= e setup to be used

for VPN, etc. For LDP independent, even if th= e route is available, it has to wait for the label mapping from the downstr= eam to

setup the ingress LDP to be used for VPN, etc= .

2. I am not sure what's the link state paradi= gm you mean? For LDP, it depends on IGP, it can also use the link state par= adigm.

The only difference is that the segment routi= ng can use it conveniently since the label binding coexists with link state= paradigm.

 

 

 

 

Comparing the there mode, the flooding mode is m= ore independent. This means it is the essiest one= to

set up the interrupted LSP and leak = the useless traffic into the network which will have negative effect

on the normal traffic in the network= .

[Bruno2] I disagree. You have the link state = vision of the whole SPRING network. That=A1=AFs the =A1=B0mode=A1=B1 which = provides the more information. <= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:#1F497D">Specifically,

 You know = that the egress is =A1=B0up=A1=B1 and that all nodes on the way are also = =A1=B0up=A1=B1 and ready (I do mean from a SPRING/MPLS standpoint).=

Obviously, this is a control plan vision only= . If you want to check the FIB, you will need to test it (e.g. LSP Ping)

[Robin]

I understand your point about the control pla= ne solution to some extent. In fact, I have also thought about solutions fo= r the the possible

interruption issues for SR-BE path. As t= o your suggested solution of the control plane, it can be done, but it has = been the end-to-end path

calculation like TE instead of the traditiona= l route path calculation.

 

 

Best Regards,=

Robin

 

 

=B7=A2=BC=FE=C8=CB<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:black">: bruno.decraene@orange.c= om [bruno.decraene@orange.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2015=C4= =EA1=D4=C215=C8=D5 23:56
=CA= =D5=BC=FE=C8=CB: Lizhenbin; spring@iet= f.org
=D6= =F7=CC=E2: RE: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-B= E Path and Incremental Deployment

Hi Robin,

 <= /o:p>

Thanks for your interest = on SR/SPRING.

Please see in= line. [Bruno]

 <= /o:p>

From:<= /b> spring [mailto:spring-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Thursday, January 15, 2015 2:12 PM
To: spring@ietf= .org
Subject: [spring] New Comments on Segment Routing(1): Challenge of O= rdered mode for SR-BE Path and Incremental Deployment

 <= /o:p>

Hi all authors of segment routing,<= /o:p>

 

When we did research on segment routing and found some new issues. Cou= ld you help clarify if the analysis is right and

how will they be taken into account in the design of SR.

 

This is the first issue.

           &nbs= p;            &= nbsp;  (Non-SR)
  S11-----------S12----------S13---------S14
   |          &= nbsp;  |          &n= bsp; |           |
   |          &= nbsp;  |          &n= bsp; |           |
   |          &= nbsp;  |          &n= bsp; |           |
  S21-----------S22----------S23---------S24
 
As above topoloby, there are 8 nodes and assume all the metics of the links= are 1 and VPNs are deployed
on S11/S21/S14/S24.


If LDP is used as the tunnel for VPN on S11/S14, since LDP can support the = ordered mode. The LSP for the S14 will be
setup as the order S14->S13->S12->S11 for distribution of label ma= pping. And the shortest path for routes
to S14 is also S11->S12->S13->S14. So the end-to-end LSP to S14 is= setup. If one node (e.g. S13) does not
support LDP, according to LDP ordered mode, the end-to-end LSP cannot setup= since S12 does not receive the label
mapping from the exact nexthop of the route, S13 and it will not distribute= the label mapping to S11. And the

result is that the VPN on S11 cannot take the LSP since the LSP c= annot setup on S11. 

[Bruno]

My understanding of your case is the followin= g, please correct me if I=A1=AFm wrong:<= /o:p>

There is no SPRING/SR. All nodes support LDP.= S11, S12, S14 use ordered mode. S13 use independent mode.

 

First, such cases happen today in multiple ve= ndor networks since different implementation used different options.=

Then, I believe that your understanding of LD= P independant mode  is incorrect. In independent mode, S13 always adve= rtises the S14 FEC to its neighbor, even if it don=A1=AFt gets a label mapping from its downstream S14. This FEC is then propagated to S11 = in ordered mode.

As a result, S11 gets a label for S14 and wil= l use S14 for the VPN. However in the forwarding plane the traffic will be = dropped on S13.

[Robin] It has explained in the previous mail= . Please rethink the case that S13 does not support LDP instead of that S13= support independent mode.<= /p>

 

 

 

If SR-B= E path is used as the tunnel for VPN on S11/S14 and assume the S13 cannot support the SR, according to my
understanding, there will be an SR-BE path for the destination S14 which is= interrupted at S12. This is similar as
the independent mode of LDP. If this VPN takes this SR-BE Path at S11, the = VPN traffic will be dropped at S12.

If the analysis is right. I have two questions:
1. How will SR avoid such risk? Some enhancement on SR or just leave it to = the local implmentation (For example,
LSP ping is firstly used to check the connectivity)?

[Bruno] A priori, I could see 3 answers

-a- I guess one could use IGP multi-topology = to handle a different topology between the IP and the MPLS one. This is sim= ilar to IPv6 introduction in a IPv4 network.=

-b- Another option is to enable interworking = between LDP and SR/SPRING to handle such incremental deployment. Please see= the following draft for an introduction on this interworking: https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-ldp-inter= op-02 Comments are welcomed as I agree with you that=A1=AFs an importan= t topic for brownfield incremental deployment=

[Robin] I do not think multi-topoloty and SR-= LDP interop will propose can not solved the issued.

[Bruno2] Not sure why you use double negation= . But in short, you also believe this should work.

 

[Robin]

But the price is high. In fact, I have read t= he draft. But I do not think think it is an easy work according to the past= experience in the MPLS world. I will explain the possible work should be taken into account in the subsequent comments. A small exam= ple, SR claimed it can replace the IGP-LDP sync. But as a developer, I am s= ure that the effort of implementation of SR-LDP interop is much more t= han IGP-LDP sync. Can I say that in fact SR does not save our effort, but make more trouble?

[Bruno2] The use of SR-LDP interwork allows i= ncremental deployment of SR with incremental benefit but is indeed an addit= ional work. It is only needed in a multi-vendor/plateform network when all nodes do not support SR, for a limited duration. It= =A1=AFs not long term feature. If you ask me, I would rather not have to us= e it, but it depends on the willing of vendors to implement the required IG= P sub-TLVs. If we all agree that implementing such sub-TLV is easier and better (or if you assume mono vendor deployment= , which I don=A1=AFt) we won=A1=AFt need to deploy/implement LDP-SPRING int= erworking. This is a roadmap versus deployment date issue, so a bit out of = scope of this mailing list. However, from the mailing list standpoint, the point is that this can be done (specified= and implemented)

 

-c- Another option is to incrementally deploy= SR in addition to LDP and to prefer LDP for end to end LSP (using administ= rative distance). Then it=A1=AFs up to each SR application to see how much they can take benefit of partial SR deployment. e.g. FRR (= TI-LFA, RLFA or DLFA) may/should be able to benefit from partial deployment= .

[Robin] The difficulty is that the ingress no= de cannot determine if the SR-BE path is end-to-end without extra methods w= hich is unnecessary for the LDP already deployed in the whole network.

[Bruno2] Again, No. please see https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-03#s= ection-3 The ingress knows, within its IGP area/level, all nodes which = supports SPRING or not. This includes nodes on the SPT to the egress.

 

 

 

FYI, as of today/myself I say that =A1=B0b=A1= =B1 is required and =A1=B0c=A1=B1 is nice to have.


2. Assume LDP is already deployed on all nodes in the network to bear VPN t= raffic. When SR-BE path is adopted in the
network to replace LDP LSP, since there is the possible risk proposed by in= terrupted SR-BE path and I do not think it

is impossible to carefully determine the upgraded nodes.

[Bruno] I=A1=AFm not sure to correctly unders= tand your last sentence. Within an AS (well area/level) It is possible to i= dentify nodes which are SR/SPRING compliant (or non compliant) as they advertise this in the link state IGP.

[Robin] I agree your proposed the increm= ental deployment method by IGP extension to identifed the SR-node. This is = not what my objective. My case is to show that the scope of end-to-end LSP and the scope of the SR nodes is different. The incremental= deployment of SR cause the issue for the end-to-end LSP.

 [Bruno2] I=A1=AFm not= sure to see your point. In particular by =A1=B0end-to-end=A1=B1 to you mea= n within an area/level, or across ASes? Because as SPRING uses the IGP, IGP frontiers makes a diff= erence. Can you please rephrase or bring an non-working example?

 

So the = only choice is to upgrade all nodes to support SR all at once.

[Bruno] No.

[Robin] I can agree you that it may be necess= ary. But more details be taken into account and the price may be high and .=

 

is that= right that the incremental deployment of SR in such scenario is difficult = to adopt?

 

 

 

Regards,Zhenbin(Robin)

______________________________=
___________________________________________________________________________=
________________
 
Ce message et ses pieces joint=
es peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc
pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez le signaler
a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant susceptibles=
 d'alteration,
Orange decline toute responsab=
ilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachmen=
ts may contain confidential or privileged information that may be protected=
 by law;
they should not be distributed=
, used or copied without authorisation.
If you have received this emai=
l in error, please notify the sender and delete this message and its attach=
ments.
As emails may be altered, Oran=
ge is not liable for messages that have been modified, changed or falsified=
.
Thank you.

______________________________=
___________________________________________________________________________=
________________
 
Ce message et ses pieces joint=
es peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc
pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez le signaler
a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant susceptibles=
 d'alteration,
Orange decline toute responsab=
ilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachmen=
ts may contain confidential or privileged information that may be protected=
 by law;
they should not be distributed=
, used or copied without authorisation.
If you have received this emai=
l in error, please notify the sender and delete this message and its attach=
ments.
As emails may be altered, Oran=
ge is not liable for messages that have been modified, changed or falsified=
.
Thank you.
--_000_1B502206DFA0C544B7A60469152008633F55CF8Feusaamb105erics_-- From nobody Wed Jan 28 20:36:14 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4007B1A8AFC for ; Wed, 28 Jan 2015 20:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjSFWWH89Lvf for ; Wed, 28 Jan 2015 20:36:07 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A76F1A8AF8 for ; Wed, 28 Jan 2015 20:36:06 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 541DD1801127; Thu, 29 Jan 2015 05:36:01 +0100 (CET) Message-ID: <54C9B8AD.2070709@pi.nu> Date: Thu, 29 Jan 2015 12:35:57 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Black, David" , Alia Atlas References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Advice on draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 04:36:11 -0000 All, Tnx - I wanted to bring this (too many changes concern) up now rather than just prior to the telechat. I'm on the same page as Alia and David, good to go, once discusses are resolved. /Loa On 2015-01-29 01:34, Black, David wrote: > Hi Loa, > > First of all, thanks for everything you’ve been doing for this draft. > In some sense, we threw you in at the deep end of the pool when you > became shepherd late in the process, although that’s been the experience > of most of us who’ve been working on this draft for the past 6 months; > there’s a lot more going on here than any of us initially expected. > > That said, Alia’s take on this draft’s state and the thread below > matches mine - there’s a bunch of small clarifications in progress but > nothing big. In the thread below, Xiaohu and I wind up agreeing that > there is not an L3VPN-related problem that this draft needs to address. > The resulting clarification in the additional text is fairly simple (and > was always intended by the current text) - an MPLS-in-UDP tunnel is > identified by its source and destination IP addresses (IPv6 in the added > text below courtesy of where it occurs in the draft). The UDP ports do > not provide any additional identification because the destination port > is a constant, and the source port is used solely to inject entropy > (e.g., for multipathing). > > Thanks, > --David > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Alia Atlas > *Sent:* Wednesday, January 28, 2015 10:32 AM > *To:* Loa Andersson > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Advice on draft-etf-mpls-in-udp > > Hi Loa, > > On Wed, Jan 28, 2015 at 1:01 AM, Loa Andersson > wrote: > > Folks, > > This mail to Alia (as responsible AD), Adrian (with experience from > progressing a lot of documents) and the mpls wg co-chairs. > > I became Document Shepherd rather late in the process. Ross did the > "repeated wglc" on this draft on version -07, the document was updated > after wglc as version -08. After that there has been discussions on > different parts of the document and it has been updated twice. And a > third version (-11) is in the pipe. I've not seen version -11 yet, but > among the authors there are talk about "brand new issues". > > My concerns are that we are introducing to big changes without keeping > the working group in the loop. Can you help evaluate if we need to take > the document through a new wglc, or if we are good to go? > > I am keeping a close eye on this question. So far, I think that we are > good to > > go once the discusses and upstream labels questions are addressed. > > On the latter, I believe it is resolving to behavior as specified in > the draft > > from WGLC - but with the clarification that in the future some > signalling might > > indicate whether the labels are not upstream assigned even if the IP > destination > > address is multicast. > > The two discusses are not, IMHO, changing any technical details but rather > > clarifying details. For instance, there isn't a listener at the UDP > source port > > on the ingress of the UDP tunnel. For another instance, clarifying the DTLS > > behavior in terms of number of expected sessions. > > I do hope to see an updated draft that addresses the discusses very soon > > and would encourage prodding by the shepherd ;-) > > Thanks, > > Alia > > /Loa > > On 2015-01-28 09:14, Xuxiaohu wrote: > > Hi David, > > The text looks good to me. Thanks for your excellent work. > > Best regards, > Xiaohu > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com > ] > Sent: Tuesday, January 27, 2015 7:51 PM > To: Xuxiaohu > Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org > ; adrian@olddog.co.uk > ; > Black, David > Subject: MPLS/UDP: Section 3.1 item 3 - rewrite > > Here's my initial attempt to clarify Section 3.1 item 3 wrt Eric > Rosen's concern > that the source IPv6 address is the context identifier for > upstream-assigned > context labels for multicast traffic. I found a way to do this > without talking > about "point" or "multipoint" characteristics of tunnel ingress/egress. > > OLD > e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for > each MPLS-in-UDP tunnel that uses UDP zero-checksum mode > regardless of receiver in order to strengthen the receiver's > check of the IPv6 source address. When this is not > possible, it > is RECOMMENDED to use each source IPv6 address for as few UDP > zero-checksum mode MPLS-in-UDP tunnels as is feasible. > NEW > e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for > each MPLS-in-UDP tunnel that uses UDP zero-checksum mode > regardless of receiver in order to strengthen the receiver's > check of the IPv6 source address (i.e., the same IPv6 source > address SHOULD NOT be used with more than one IPv6 destination > address, independent of whether that destination address is a > unicast or multicast address). When this is not possible, it > is RECOMMENDED to use each source IPv6 address for as few UDP > zero-checksum mode MPLS-in-UDP tunnels (i.e., with as few > destination IPv6 addresses) as is feasible. > > How does that look? > > Thanks, > --David > > -----Original Message----- > From: Xuxiaohu [mailto:xuxiaohu@huawei.com ] > Sent: Monday, January 26, 2015 11:01 AM > To: Black, David > Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org > ; > adrian@olddog.co.uk > Subject: Re: [mpls] ID Tracker State Update Notice: > > > Hi David, > > After a careful consideration, I think it should be OK for an > encapsulator to use different tunnel source addresses for different > UDP tunnels if these tunnels are manually configured. Sorry for that > confusion. In addition, since item e has a sentence "When this is not > possible,...", I believe the current text is OK for the P2P UDP tunnel > case. It seems that you only need to add some text about the P2MP UDP > > tunnel, just as what you have mentioned before. > > > Best regards, > Xiaohu > > ________________________________________ > å‘件人: Black, David [david.black@emc.com ] > å‘é€æ—¶é—´: 2015å¹´1月26æ—¥ 18:40 > 收件人: Xuxiaohu > 抄é€: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org > ; > adrian@olddog.co.uk ; Black, David > 主题: RE: [mpls] ID Tracker State Update Notice: > > > First, this is a brand new concern that has not been raised previously > - it's definitely different from Eric Rosen's concern, which I > understand and will write clarifying text for. > > Second, a VPN ought to be seriously concerned with misdelivery > prevention, and there's text in the security considerations section on > this topic. Item e in section 3.1 is one of the important things that > this draft does towards misdelivery prevention when UDP zero > checksums are > > used with IPv6. > > > My starting point would be - if L3VPNs have a problem with using a > different > IPv6 address as the source of each tunnel, then that's one more reason > for L3VPNs to use UDP checksums with IPv6. > > I'll defer to L3VPN experts on how L3VPN address signaling currently > works and the impacts of additional IPv6 addresses on that. I'm not > the right person to write L3VPN-specific text (on this or any other > topic). > > Thanks, > --David > > -----Original Message----- > From: Xuxiaohu [mailto:xuxiaohu@huawei.com ] > Sent: Monday, January 26, 2015 4:42 AM > To: Black, David > Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org > ; > > adrian@olddog.co.uk > > Subject: RE: [mpls] ID Tracker State Update Notice: > > > Hi David, > > Just take the BGP/MPLS IP VPN with RR enabled as an example, if it > requires the tunnel encapsulator (i.e., ingress PE) to use different > source IP addresses for different tunnels, should ingress PEs notify > the address to be used as the tunnel source address to each egress > PE. Otherwise, how could egress PEs verify that the packets are received > > from valid ingress PEs? > > > Best regards, > Xiaohu > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com > ] > Sent: Saturday, January 24, 2015 3:15 AM > To: Xuxiaohu > Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org > ; > > adrian@olddog.co.uk ; > > Black, David > Subject: RE: [mpls] ID Tracker State Update Notice: > > > Xiaohu, > > I'm missing something here. > > Eric's concern stems from the requirement that when > upstream-assigned > > labels > > are in use, the source IP address identifies the label context, > and hence > > that > > source IP address has to be common across all traffic to a destination. > > Eric was > > concerned that Section 3.1 item e might conflict with that requirement. > > The clarifying text will indicate that there is no problem here; > when the destination IP address is a multicast address, the sender > sends one > > packet, > > the > > receivers each get a copy and that 1:n multicast fan-out is a > single > > "tunnel" wrt > > Section 3.1 item e. > Every packet delivered to every receiver in that tunnel uses the > same > > source > > IP > > address, so there's a single label context. > > I do not understand the RPF and signaling concerns below. > > Thanks, > --David > > -----Original Message----- > From: Xuxiaohu [mailto:xuxiaohu@huawei.com ] > Sent: Thursday, January 22, 2015 8:40 PM > To: Black, David > Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org > ; > adrian@olddog.co.uk > Subject: RE: [mpls] ID Tracker State Update Notice: > > > Hi David, > > I'm looking forwarding to seeing your updated text. By the way, > I hope you could take into account potential concerns as follows: > > 1) will it make the RPF check performed by tunnel decapsulators > (e.g., to determine the upstream PE of the received multicast > packet in the multicast VPN context) difficult when requiring a > tunnel encapsulator to use different tunnel source addresses for > different tunnels; > 2) does it require the encapsulator of a particular MPLS-in-UDP > tunnel to notify the decapsulator(s) of its possible addresses > to be used as the source address of that tunnel. > > Best regards, > Xiaohu > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com > ] > Sent: Thursday, January 22, 2015 11:15 PM > To: Xuxiaohu > Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org > ; > > adrian@olddog.co.uk ; > > Black, David > Subject: RE: [mpls] ID Tracker State Update Notice: > > > Xiaohu, > > Since the requirement item e would introduce additional and > unexpected complexities and difficulties for the deployment, > I suggest that it'd better to remove that item. > > > I strongly disagree. That requirement is important to the > overall design > > goal of > > requiring an offsetting corruption to cause misdelivery (i.e., > a single > > corruption > > should usually not result in misdelivery). > > There is not an actual problem here - item e is correct wrt > Eric's concern, > > but not > > explained clearly. I can write the sentence or two that will be > > needed to > > clarify > how requirement e applies to P2MP UDP tunnels (i.e., > destination IP address > > is a > > multicast address) *after* the upstream vs. downstream label > assignment discussion is sorted out. > > By the way, I feel it would be better to uniformly replace > "MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP > sender" by "tunnel decapsulator" and "tunnel encapsulator" > respectively in the whole > > doc. > > I'll defer to others on terminology, although I find the > MPLS-in-UDP > > terminology > > clearer because it indicates exactly which tunnel is involved. > > Thanks, > --David > > -----Original Message----- > From: Xuxiaohu [mailto:xuxiaohu@huawei.com > ] > Sent: Wednesday, January 21, 2015 10:22 PM > To: Black, David > Cc: Loa Andersson; draft-ietf-mpls-in-udp@tools.ietf.org > ; > adrian@olddog.co.uk > Subject: RE: [mpls] ID Tracker State Update Notice: > > > Hi David and all, > > Since the requirement item e would introduce additional and > unexpected complexities and difficulties for the deployment, > I suggest that it'd better to remove that item. > > By the way, I feel it would be better to uniformly replace > "MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP > sender" by "tunnel decapsulator" and "tunnel encapsulator" > respectively in the whole > > doc. > > > Best regards, > Xiaohu > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com > ] > Sent: Thursday, January 22, 2015 3:17 AM > To: Eric C Rosen; Alia Atlas; Xuxiaohu > Cc: Loa Andersson; >; > mpls-chairs@tools.ietf.org ; > draft-ietf-mpls-in-udp@tools.ietf.org > ; > IJsbrand Wijnands; Black, David > Subject: RE: [mpls] ID Tracker State Update Notice: > > > Eric, > > On the further issue ... > > There is one further issue for you to consider. > > When an MPLS packet with an upstream-assigned label is > received through a particular tunnel, the "context" in > which the label is interpreted is determined by the IP > address of the > > root of > > the tunnel. > > (See section 7 of RFC5331.) For a UDP tunnel, this > would mean that the label space is identified by the > Source IP > > address. > > So if a particular router is using > MPLS-in-UDP to send > MPLS packets with upstream-assigned > labels, it's really > important for it to use the same IP > > source > > address in all > > MPLS-in-UDP packets that have the same > destination address. > > I > > can't > > quite tell whether this is compatible with > item e. in > section > 3.1 of the draft. > > > That is compatible with item e., but the draft > doesn't say > much about P2MP > > UDP > > tunnels. In particular, I would view that source IP > address as the source > > IP > > address for a (one) P2MP tunnel, and it's probably a > good > idea to add some > > text > > on P2MP UDP tunnels to make this clear. > > Thanks, > --David > > -----Original Message----- > From: Eric C Rosen [mailto:erosen@juniper.net > ] > Sent: Wednesday, January 21, 2015 11:26 AM > To: Alia Atlas; Xuxiaohu > Cc: erosen@juniper.net ; > Black, David; Loa Andersson; > >; > mpls-chairs@tools.ietf.org > ; > draft-ietf-mpls-in- udp@tools.ietf.org > ; IJsbrand > Wijnands > Subject: Re: [mpls] ID Tracker State Update Notice: > > > Folks, > > I'll be happy to throw in my much belated two cents. > > If I understand correctly, the issue at hand is how one > determines, when receiving an MPLS-in-UDP packet, > whether the top MPLS label is upstream-assigned or > > downstream-assigned. > > > Draft-ietf-mpls-in-udp-10 has the > following text: > > As for whether the top label in > the MPLS label stack is > downstream-assigned or > upstream-assigned, it SHOULD > be > > determined > > based on the tunnel destination IP > address. That is > to say, if > > the > > destination IP address is a multicast > address, the > top label > > SHOULD > > be upstream-assigned, otherwise if the > destination > IP > > address > > is a > > unicast address, it SHOULD be > downstream-assigned. > > I believe this text is incorrect, as it is > inconsistent > with RFCs > 5332 and 5331, which are the RFCs that introduce the > notion of "upstream-assigned labels". > > Of particular relevance is Section 3 of RFC > 5332, which > discusses how one determines, when an MPLS packet is > being sent through a tunnel, whether the top > label of > the encapsulated packet is upstream or > > downstream. > > > To make a long story short, basically what that section > says is that the tunnel must be known a priori to have > one of the following three > > properties: > > > 1. The top label of all encapsulated packets is > downstream- > > assigned. > > > 2. The top label of all encapsulated packets is > upstream- > > assigned. > > > 3. The top label of some encapsulated packets is > downstream-assigned, but the top label of some > encapsulated packets is > > upstream-assigned. > > > How it is known which property the tunnel has is > out of > scope (i.e., it depends on the higher layer). > > Only tunnels with the third property need to > contain a > codepoint that specifies whether the label is > upstream-assigned or > > downstream-assigned. > > > So what does all this mean for the mpls-in-udp > encapsulation? > I would suggest that you say the following: > > - Have IANA assign a single UDP port number for > MPLS-in-UDP. > > - In the absence of any other knowledge, a UDP > packet > with the MPLS-in-UDP port number in destination port > field is assumed to be carrying an MPLS packet > whose top > label is > > downstream-assigned. > > > - Higher layers may negotiate the use of > particular UDP > tunnels to carry MPLS packets whose top labels are > upstream-assigned. The procedures for such > negotiation > are out of scope of the current document. By a > "particluar UDP tunnel", I mean a UDP tunnel with a > particular address, > destination > port> triple. The destination port may be the > standard > (IANA-assigned) port number for MPLS-in-UDP, but > it may > also be any other port number that is negotiated > by the higher > > layer. > > > - For a particular UDP tunnel (i.e., a > particular > destination port> > triple), all the encapsulated MPLS > packets must have the > same type of label at the top > > of > > the stack. > > > - Remove any suggestion that the type of the > label can > be inferred from the type of the IP destination > address. > > I think this will make the draft compatible with > RFCs > 5332 and 5331, and it does not require IANA to > allocate > a second port > > number. > > > Note, by the way, that if we are going to > allow the > higher layers to negotiate the destination > port number, > we should probably caution implementers not > to hard code > (or hard wire) a particular port > > number. > > > There is one further issue for you to consider. > > When an MPLS packet with an upstream-assigned > label is > received through a particular tunnel, the > "context" in > which the label is interpreted is determined by > the IP > address of the > > root of > > the tunnel. > > (See section 7 of RFC5331.) For a UDP tunnel, this > would mean that the label space is identified by > the Source IP > > address. > > So if a particular router is using > MPLS-in-UDP to send > MPLS packets with upstream-assigned > labels, it's really > important for it to use the same IP > > source > > address in all > > MPLS-in-UDP packets that have the same > destination address. > > I > > can't > > quite tell whether this is compatible with > item e. in > section > 3.1 of the draft. > > Eric > > > > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jan 28 22:46:53 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874111A8F39; Wed, 28 Jan 2015 22:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX8uMARLtzhi; Wed, 28 Jan 2015 22:46:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D402F1A8F34; Wed, 28 Jan 2015 22:46:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BON78927; Thu, 29 Jan 2015 06:46:38 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 06:46:25 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 14:46:19 +0800 From: Lizhenbin To: Gregory Mirsky , Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AdA6Iy10hnzSmHMYSNeVsID5YDgzbAABb2SAADAnQIEACVSxAAAf89Kl Date: Thu, 29 Jan 2015 06:46:18 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAAC@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com>, <7347100B5761DC41A166AC17F22DF1121B8E9553@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8E9553@eusaamb103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAACnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: [mpls] =?utf-8?b?562U5aSNOiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2Vn?= =?utf-8?q?ment_Routing=287=29=3A_MTU_Challenges_for_SR?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 06:46:45 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAACnkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KUGxlYXNlIHJlZmVyIHRvIG15IGlubGluZSBjb21tZW50cy4NCg0KDQoNClJl Z2FyZHMsDQoNClJvYmluDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K 5Y+R5Lu25Lq6OiBHcmVnb3J5IE1pcnNreSBbZ3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tXQ0K 5Y+R6YCB5pe26Ze0OiAyMDE15bm0MeaciDI55pelIDc6MjYNCuaUtuS7tuS6ujogTGl6aGVuYmlu OyBIYW5uZXMgR3JlZGxlcg0K5oqE6YCBOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7 IHRlYXNAaWV0Zi5vcmcNCuS4u+mimDogUkU6IFtzcHJpbmddIE5ldyBDb21tZW50cyBvbiBTZWdt ZW50IFJvdXRpbmcoNyk6IE1UVSBDaGFsbGVuZ2VzIGZvciBTUg0KDQpIaSBSb2JpbiwgZXQuIGFs LA0KcGFyZG9uIG15IG5hw692ZSBxdWVzdGlvbiBXaHkgUGF0aCBNVFUgRGlzY292ZXJ5IGlzIG5v dCBzdWZmaWNpZW50PyBJIHRoaW5rIHRoYXQgd2l0aCBTZWdtZW50IFJvdXRpbmcgaXQgd291bGQg YmUgcG9zc2libGUgdG8gY29uc3RydWN0IHRoZSBNVFUgU2l6ZSBtYXRyaXggb2YgdGhlIHBhcnRp Y3VsYXIgZG9tYWluLg0KW1JvYmluXSBNeSBvcGluaW9uIGlzIHRoYXQgdGhlIHRoZXJlIGlzIGxp bWl0YXRpb24gZm9yIHRoZSBwYXRoIE1UVSBkaXNjb3ZlcnkgYmFzZWQgb24gSUdQLiAgRm9yIHRo ZSBpbnRlci1hcmVhIGFuZCBTUi1CRSBwYXRoIHNjZW5hcmlvcywgdGhlcmVzdGlsbCAgbmVlZCBl eHRyYSBtZWNoYW5pc21zLiBGb3IgdGhlIGZpcnN0IHNjZW5hcmlvLCBpdCB3aWxsIGluY3JlYXNl IHRoZSBjb21wbGV4aXR5IG9mIHRoZSBzb2x1dGlvbnMuIEZvciB0aGUgc2Vjb25kIHNjZW5hcmlv LCBpdCBtYXkgaHVydCBmYXN0IGNvbnZlcmdlbmNlIG9mIGJlc3QtZWZmb3J0IHBhdGguDQoNCg0K DQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgR3JlZw0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTGl6aGVuYmluDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjgsIDIwMTUgMzow NiBBTQ0KVG86IEhhbm5lcyBHcmVkbGVyDQpDYzogbXBsc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYu b3JnOyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBbVGVhc10g562U5aSNOiBbc3ByaW5nXSBOZXcg Q29tbWVudHMgb24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0K DQpIaSBIYW5uZXMsDQoNCkkgaGF2ZSBldmVyIHRob3VnaHQgYWJvdXQgdGhlIHBvc3NpYmxlIHNv bHV0aW9ucyBiYXNlZCBvbiB0aGUgZmxvb2RlZCBNVFUgaW5mb3JtYXRpb24gdGhyb3VnaCBJR1Au DQoNClRoZXJlIGFyZSBzdGlsbCB0d28gcG9zc2libGUgaXNzdWVzOg0KDQoxLiBJbnRlci1hcmVh IGZvciBTUi1URSBwYXRoOiBNYXliZSB3ZSBub3Qgb25seSBpbnRyb2R1Y2UgdGhlIElHUCBleHRl bnNpb25zLCBidXQgYWxzbyBQQ0VQIGV4dGVuc2lvbnMuDQoNCjIuIEZvciBTUi1CRSBwYXRoLCBp dCBoYXMgdG8gaW50cm9kdWNlIHRoZSBURS1saWtlIGVuZC10by1lbmQgcGF0aCBjYWxjdWxhdGlv biBhdCB0aGUgaW5ncmVzcyBub2RlLg0KDQoNCg0KTXkgY29uY2VybiBpcyBub3QganVzdCBmb3Ig dGhlIHBvc3NpYmxlIHNvbHV0aW9ucywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ugb2YgU1Ig d2hpY2ggbWF5IGhhcyBtdWNoDQoNCmVmZmVjdCBvbiBpdHMgZGVwbG95bWVudCBjb21wYXJpbmcg d2l0aCB0aGUgZXhpc3RpbmcgTVBMUyBwcm90b2NvbC4gSXQgd2lsbCBiZSBleHBsYWluZWQgaW4N Cg0KdGhlIG5leHQgY29tbWVudHMuDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQoN Cg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrlj5Hk u7bkuro6IEhhbm5lcyBHcmVkbGVyIFtoYW5uZXNAanVuaXBlci5uZXRdDQrlj5HpgIHml7bpl7Q6 IDIwMTXlubQx5pyIMjjml6UgNDowMQ0K5pS25Lu25Lq6OiBMaXpoZW5iaW4NCuaKhOmAgTogc3By aW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPjsgdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NCuS4 u+mimDogUmU6IFtzcHJpbmddIE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1U VSBDaGFsbGVuZ2VzIGZvciBTUg0KDQpvbmx5IGNhbiBzcGVhayBmb3IgSVMtSVMgLQ0KYWZhaWsg dGhlIFRyaWxsIGV4dGVuc2lvbnMgZ2F2ZSB1cyBhIHdheSBvZiBzaWduYWxpbmcgdGhlIE1UVSBv ZiBhIGxpbmsgLi4uDQoNCnNvIHdoYXQgd2UgY291bGQgZG8gaXMgdG8gYWR2ZXJ0aXNlIHRoZSBN VFUgZm9yIGVhY2ggYWRqYWNlbmN5IGFuZCBpbXBsZW1lbnQNCnByb3BlciBmcmFnbWVudGF0aW9u IGF0IHRoZSBURSB0dW5uZWwgaW5ncmVzcy4NCg0KL2hhbm5lcw0KDQpPbiBUdWUsIEphbiAyNywg MjAxNSBhdCAxMToyNDoyM0FNICswMDAwLCBMaXpoZW5iaW4gd3JvdGU6DQp8ICAgIEhpIGFsbCBh dXRob3JzIG9mIHNlZ21lbnQgcm91dGluZywNCnwNCnwgICAgVGhpcyBpcyB0aGUgc2V2ZW50aCBj b21tZW5zLiBUaGUgaXNzdWVzIHByb3Bvc2VkIGhlcmUgYXJlIGZvciBib3RoIFNSLVRFDQp8ICAg IHBhdGggYW5kIFNSLUJFIHBhdGguDQp8DQp8DQp8DQp8ICAgICAgICAgICAgIDEgICAgICAgICAg ICAgIDEgICAgICAgICAgIDEgICAgICAgICAgICAxDQp8ICAgICAgUzExLS0tLS0tLS0tLS1TMTIt LS0tLS0tLS0tUzEzLS0tLS0tLS0tUzE0LS0tLS0tLS0tUzE1DQp8ICAgICAgIHwgICAgICAgICAg ICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwNCnwgICAgICAxfCAgICAg ICAgICAgIDF8ICAgICAgICAgICAxfCAgICAgICAgICAxfCAgICAgICAgICAxfA0KfCAgICAgICB8 ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICB8DQp8ICAg ICAgUzIxLS0tLS0tLS0tLS1TMjItLS0tLS0tLS0tUzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1 DQp8ICAgICAgICAgICAgIDQgICAgICAgICAgICAgIDQgICAgICAgICAgIDQgICAgICAgICAgICA0 DQp8DQp8DQp8DQp8ICAgIFN0aWxsIHRha2UgdGhlIHRvcG9sb2d5IGluIHRoZSBjb21tZW50IDYg YXMgdGhlIGV4YW1wbGUuIE5vIG1hdHRlciB0aGUNCnwgICAgbG9vc2UgZXhwbGljaXQgcGF0aCBv cg0KfA0KfCAgICB0aGUgc3RyaWN0IGV4cGxpY2l0IHBhdGggZm9yIHRoZSBsb29zZSBob3AsIGFz c3VtZSB0aGUgTVRVIG9mIHRoZQ0KfCAgICBpbnRlcmZhY2UgaXMgdGhlIHNhbWUsDQp8DQp8ICAg IHNpbmNlIHRoZSBkZXB0aCBvZiB0aGUgbGFiZWwgc3RhY2tzIGZvciB0aGUgcHJpbWFyeSBwYXRo IGFuZCB0aGUgYmFja3VwDQp8ICAgIHBhdGggYXJlIGRpZmZlcmVudC4NCnwNCnwgICAgVGhlcmUg aXMgdGhlIHJpc2sgdGhhdCB0aGUgZWZmZXRpdmUgcGF5bG9hZCBtYXkgdHJhbnNtaXQgdGhyb3Vn aCB0aGUNCnwgICAgcHJpbWFyeSBwYXRoLCBidXQgbWF5IGJlDQp8DQp8ICAgIGZyYWdtZW50ZWQg b3IgZHJvcHBlZCBpbiB0aGUgYmFja3VwIHBhdGguIEFzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g dGhlDQp8ICAgIGxhYmVsIHN0YWNrcyBvZiB0aGUNCnwNCnwgICAgcHJpbWFyeSBwYXRoIGFuZCB0 aGUgYmFja3VwIHBhdGggaW5jcmVhc2UsIHRoZSByaXNrIHdpbGwgaW5jcmVhc2UuDQp8DQp8DQp8 DQp8ICAgIEZyb20gdGhlIGNhc2UsIHdlIGNhbiBkZWR1Y2UgdGhhdCB0aGUgcmlzayBtYXkgZXhp c3RzIGZvciBhbnkgc2NlbmFyaW9zIGluDQp8ICAgIHdoaWNoIHRoZSBzYW1lIHRyYWZmaWMNCnwN CnwgICAgIG1heSBzd2l0Y2ggZnJvbSBvbmUgU1IgcGF0aCB0byB0aGUgb3RoZXIgU1IgcGF0aC4g VGhlIFNSIHBhdGggaW5jbHVkZXMNCnwgICAgU1ItVEUgcGF0aCBzdWNoIGFzIE1QTFMgVEUNCnwN CnwgICAgaG90c3RhbmRieS9yZW9wdGltaXphdGlvbiBhbmQgU1ItQkUgcGF0aCBzdWNoIGFzIFRJ LUZSUi4NCnwNCnwNCnwNCnwgICAgQmVzaWRlcyBhYm92ZSBpc3N1ZXMsIExEUC9SU1ZQLVRFIGNh biBzdXBwb3J0IHRoZSBwYXRoIE1UVSB0byB0cmFjayB0aGUNCnwgICAgTVRVIGluZm9ybWFpdG9u IGFsb25nIHRoZQ0KfA0KfCAgICBMU1AgdGhyb3VnaCBzaWduYWxsaW5nLiBUaGVuIHRoZSByZWFz b25hYmxlIE1UVSBpbmZvIHdpbGwgYmUgYWRvcHRlZCBpbg0KfCAgICB0aGUgaW5ncmVzcyBub2Rl LiBGb3IgYm90aA0KfA0KfCAgICAgU1ItVEUgcGF0aCAoaWYgUENFIGlzIG5vdCB1c2VkKSBhbmQg U1ItQkUgcGF0aCwgc2luY2UgdGhlcmUgaXMgbm8NCnwgICAgc2lnbmFsbGluZyB0byBhZHZlcnRp c2UNCnwNCnwgICAgdGhlIGluZm9ybWF0aW9uLiBIb3cgdG8gaW1wbGVtZW50IHRoZSBmZWF0dXJl PyBPciB0aGVyZSBtYXliZSB0aGUgcmlzaw0KfCAgICB0aGF0IHRoZSBwYWNrZXQgbWF5IGJlDQp8 DQp8ICAgIGRyb3BwZWQgYnkgdGhlIG5vZGVzIGFsb25nIHRoZSBMU1AuDQp8DQp8DQp8DQp8DQp8 DQp8DQp8DQp8ICAgIFJlZ2FyZHMsDQp8DQp8ICAgIFJvYmluDQoNCnwgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnwgc3ByaW5nIG1haWxpbmcgbGlzdA0K fCBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCnwgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAACnkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGU+QGZvbnQtZmFjZSB7 DQoJZm9udC1mYW1pbHk6IENvdXJpZXI7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTog U2ltU3VuOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFNpbVN1bjsNCn0NCkBmb250 LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBDYWxpYnJpOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1m YW1pbHk6IFRhaG9tYTsNCn0NCkBwYWdlIFdvcmRTZWN0aW9uMSB7bWFyZ2luOiAxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjsgfQ0KUC5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZP TlQtRkFNSUxZOiBTaW1TdW47IEZPTlQtU0laRTogMTJwdA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglN QVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogU2ltU3VuOyBGT05ULVNJWkU6IDEycHQN Cn0NCkRJVi5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiBT aW1TdW47IEZPTlQtU0laRTogMTJwdA0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1 ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1 cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9s bG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpQ Lk1zb0FjZXRhdGUgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiVGFob21h Iiwic2Fucy1zZXJpZiI7IEZPTlQtU0laRTogOHB0DQp9DQpMSS5Nc29BY2V0YXRlIHsNCglNQVJH SU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRhaG9tYSIsInNhbnMtc2VyaWYiOyBGT05U LVNJWkU6IDhwdA0KfQ0KRElWLk1zb0FjZXRhdGUgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZP TlQtRkFNSUxZOiAiVGFob21hIiwic2Fucy1zZXJpZiI7IEZPTlQtU0laRTogOHB0DQp9DQpTUEFO LkVtYWlsU3R5bGUxOCB7DQoJRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IENP TE9SOiAjMWY0OTdkDQp9DQpTUEFOLkJhbGxvb25UZXh0Q2hhciB7DQoJRk9OVC1GQU1JTFk6ICJU YWhvbWEiLCJzYW5zLXNlcmlmIg0KfQ0KLk1zb0NocERlZmF1bHQgew0KCUZPTlQtU0laRTogMTBw dA0KfQ0KPC9zdHlsZT48c3R5bGUgaWQ9Im93YVBhcmFTdHlsZSI+UCB7DQoJTUFSR0lOLVRPUDog MHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgZlBTdHlsZT0iMSIgb2NzaT0iMCI+ DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjtmb250LWZhbWlseTogVGFob21hO2NvbG9yOiAj MDAwMDAwO2ZvbnQtc2l6ZTogMTBwdDsiPg0KPHA+SGkgR3JlZyw8L3A+DQo8cD5QbGVhc2UgcmVm ZXIgdG8gbXkgaW5saW5lIGNvbW1lbnRzLjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPlJlZ2FyZHMs PC9wPg0KPHA+Um9iaW48L3A+DQo8cD4mbmJzcDs8L3A+DQo8ZGl2IHN0eWxlPSJGT05ULUZBTUlM WTogVGltZXMgTmV3IFJvbWFuOyBDT0xPUjogIzAwMDAwMDsgRk9OVC1TSVpFOiAxNnB4Ij4NCjxo ciB0YWJpbmRleD0iLTEiPg0KPGRpdiBzdHlsZT0iRElSRUNUSU9OOiBsdHIiIGlkPSJkaXZScEY4 ODg5ODUiPjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxiPuWP keS7tuS6ujo8L2I+IEdyZWdvcnkgTWlyc2t5IFtncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb21d PGJyPg0KPGI+5Y+R6YCB5pe26Ze0OjwvYj4gMjAxNeW5tDHmnIgyOeaXpSA3OjI2PGJyPg0KPGI+ 5pS25Lu25Lq6OjwvYj4gTGl6aGVuYmluOyBIYW5uZXMgR3JlZGxlcjxicj4NCjxiPuaKhOmAgTo8 L2I+IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgdGVhc0BpZXRmLm9yZzxicj4NCjxi PuS4u+mimDo8L2I+IFJFOiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2VnbWVudCBSb3V0aW5n KDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1I8YnI+DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2 PjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7 IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkhpIFJvYmluLCBldC4gYWwsPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nh bGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+cGFy ZG9uIG15IG5hw692ZSBxdWVzdGlvbiBXaHkgUGF0aCBNVFUgRGlzY292ZXJ5IGlzIG5vdCBzdWZm aWNpZW50PyBJIHRoaW5rIHRoYXQgd2l0aCBTZWdtZW50IFJvdXRpbmcgaXQgd291bGQgYmUgcG9z c2libGUgdG8gY29uc3RydWN0IHRoZSBNVFUgU2l6ZSBtYXRyaXgNCiBvZiB0aGUgcGFydGljdWxh ciBkb21haW4uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQt U0laRTogMTFwdCI+W1JvYmluXSZuYnNwO015IG9waW5pb24mbmJzcDtpcyZuYnNwO3RoYXQmbmJz cDt0aGUgdGhlcmUgaXMgbGltaXRhdGlvbiBmb3IgdGhlIHBhdGggTVRVIGRpc2NvdmVyeSBiYXNl ZCBvbiBJR1AuJm5ic3A7IEZvciB0aGUgaW50ZXItYXJlYSBhbmQgU1ItQkUgcGF0aCBzY2VuYXJp b3MsIHRoZXJlc3RpbGwgJm5ic3A7bmVlZA0KIGV4dHJhIG1lY2hhbmlzbXMuIEZvciB0aGUgZmly c3Qgc2NlbmFyaW8sIGl0IHdpbGwgaW5jcmVhc2UgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIHNvbHV0 aW9ucy4gRm9yIHRoZSBzZWNvbmQgc2NlbmFyaW8sIGl0IG1heSBodXJ0IGZhc3QgY29udmVyZ2Vu Y2Ugb2YgYmVzdC1lZmZvcnQgcGF0aC48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0 Ij48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3Nh bnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2Fs aWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3Nw YW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAx MXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgR3JlZzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBG T05ULVNJWkU6IDExcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iQk9S REVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElO Ry1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9S REVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBB RERJTkctVE9QOiAzcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYn OyBGT05ULVNJWkU6IDEwcHQiPiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5MaXpoZW5iaW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBKYW51YXJ5IDI4LCAyMDE1IDM6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBHcmVkbGVy PGJyPg0KPGI+Q2M6PC9iPiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IHRlYXNAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1RlYXNdIDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0IiBsYW5nPSJaSC1DTiI+562U5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPjogW3Nwcmlu Z10gTmV3IENvbW1lbnRzIG9uIFNlZ21lbnQgUm91dGluZyg3KTogTVRVIENoYWxsZW5nZXMgZm9y IFNSPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xP UjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+SGkgSGFubmVzLDwvc3Bhbj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJ WkU6IDEwcHQiPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJp ZXI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij5JIGhhdmUgZXZlciB0aG91Z2h0IGFi b3V0IHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMgYmFzZWQgb24gdGhlIGZsb29kZWQgTVRVIGluZm9y bWF0aW9uIHRocm91Z2ggSUdQLjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBibGFjazsg Rk9OVC1TSVpFOiAxMHB0Ij5UaGVyZSBhcmUgc3RpbGwgdHdvIHBvc3NpYmxlIGlzc3Vlczo8L3Nw YW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9S OiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+MS4gSW50 ZXItYXJlYSBmb3IgU1ItVEUgcGF0aDogTWF5YmUgd2Ugbm90IG9ubHkgaW50cm9kdWNlIHRoZSBJ R1AgZXh0ZW5zaW9ucywgYnV0IGFsc28gUENFUCBleHRlbnNpb25zLjwvc3Bhbj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05U LVNJWkU6IDEwcHQiPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENv dXJpZXI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij4yLiBGb3IgU1ItQkUgcGF0aCwg aXQgaGFzIHRvIGludHJvZHVjZSB0aGUgVEUtbGlrZSBlbmQtdG8tZW5kIHBhdGggY2FsY3VsYXRp b24gYXQgdGhlIGluZ3Jlc3Mgbm9kZS48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn VGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp Zic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0la RTogMTBwdCI+TXkgY29uY2VybiBpcyBub3QganVzdCBmb3IgdGhlIHBvc3NpYmxlIHNvbHV0aW9u cywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ugb2YgU1INCjwvc3Bhbj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBibGFjayI+d2hpY2ggbWF5IGhhcyBtdWNoPC9z cGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xP UjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogQ291cmllcjsgQ09MT1I6IGJsYWNrIj5lZmZlY3Qgb24gaXRzIGRlcGxveW1l bnQgY29tcGFyaW5nIHdpdGggdGhlIGV4aXN0aW5nIE1QTFMgcHJvdG9jb2wuIEl0IHdpbGwgYmUg ZXhwbGFpbmVkIGluPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3Nh bnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsgQ09MT1I6IGJsYWNrIj50aGUgbmV4 dCBjb21tZW50cy48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fu cy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBi bGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1T SVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiBDb3VyaWVyOyBDT0xPUjogYmxhY2siPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTog MTBwdCI+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsg Q09MT1I6IGJsYWNrIj5Sb2Jpbjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsg Q09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cD48c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNr OyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+ Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjog YmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNr OyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNOIj7lj5Hku7bkuro8L3NwYW4+PHNwYW4gc3R5 bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+ OiBIYW5uZXMgR3JlZGxlciBbaGFubmVzQGp1bmlwZXIubmV0XTxicj4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNOIj7lj5HpgIHm l7bpl7Q8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxh Y2s7IEZPTlQtU0laRTogMTBwdCI+OiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxh Y2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij4xPC9z cGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgt Q04iPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBi bGFjazsgRk9OVC1TSVpFOiAxMHB0Ij4yODwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNr OyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNOIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+DQogNDow MTxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQi IGxhbmc9IlpILUNOIj7mlLbku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBD b3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+OiBMaXpoZW5iaW48YnI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJa SC1DTiI+5oqE6YCBPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsgQ09M T1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjoNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBsc0BpZXRmLm9yZzwvYT47IDxh IGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGVhc0BpZXRmLm9y ZzwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAx MHB0IiBsYW5nPSJaSC1DTiI+5Li76aKYPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog Q291cmllcjsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjogUmU6IFtzcHJpbmddIE5l dyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1UVSBDaGFsbGVuZ2VzIGZvciBTUjxi cj4NCjxicj4NCm9ubHkgY2FuIHNwZWFrIGZvciBJUy1JUyAtPGJyPg0KYWZhaWsgdGhlIFRyaWxs IGV4dGVuc2lvbnMgZ2F2ZSB1cyBhIHdheSBvZiBzaWduYWxpbmcgdGhlIE1UVSBvZiBhIGxpbmsg Li4uPGJyPg0KPGJyPg0Kc28gd2hhdCB3ZSBjb3VsZCBkbyBpcyB0byBhZHZlcnRpc2UgdGhlIE1U VSBmb3IgZWFjaCBhZGphY2VuY3kgYW5kIGltcGxlbWVudDxicj4NCnByb3BlciBmcmFnbWVudGF0 aW9uIGF0IHRoZSBURSB0dW5uZWwgaW5ncmVzcy48YnI+DQo8YnI+DQovaGFubmVzPGJyPg0KPGJy Pg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSAmIzQzOzAwMDAsIExpemhlbmJp biB3cm90ZTo8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpIGFsbCBhdXRob3JzIG9mIHNlZ21l bnQgcm91dGluZyw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGlzIHRoZSBz ZXZlbnRoIGNvbW1lbnMuIFRoZSBpc3N1ZXMgcHJvcG9zZWQgaGVyZSBhcmUgZm9yIGJvdGggU1It VEU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhdGggYW5kIFNSLUJFIHBhdGguPGJyPg0KfDxi cj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAxPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBT MTEtLS0tLS0tLS0tLVMxMi0tLS0tLS0tLS1TMTMtLS0tLS0tLS1TMTQtLS0tLS0tLS1TMTU8YnI+ DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMXw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCnwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUzIxLS0tLS0tLS0tLS1TMjItLS0tLS0tLS0t UzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgNCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0PGJyPg0KfDxicj4NCnw8YnI+DQp8PGJy Pg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBTdGlsbCB0YWtlIHRoZSB0b3BvbG9neSBpbiB0aGUgY29t bWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIgdGhlPGJyPg0KfCZuYnNwOyZuYnNwOyZu YnNwOyBsb29zZSBleHBsaWNpdCBwYXRoIG9yPGJyPg0KfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJz cDsgdGhlIHN0cmljdCBleHBsaWNpdCBwYXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUgdGhl IE1UVSBvZiB0aGU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVyZmFjZSBpcyB0aGUgc2Ft ZSw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBzaW5jZSB0aGUgZGVwdGggb2YgdGhl IGxhYmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cDxicj4NCnwm bmJzcDsmbmJzcDsmbmJzcDsgcGF0aCBhcmUgZGlmZmVyZW50Ljxicj4NCnw8YnI+DQp8Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0aXZlIHBheWxvYWQg bWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBwcmltYXJ5 IHBhdGgsIGJ1dCBtYXkgYmU8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBmcmFnbWVu dGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBwYXRoLiBBcyB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIHRoZTxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgbGFiZWwgc3RhY2tzIG9mIHRoZTxicj4N Cnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBw YXRoIGluY3JlYXNlLCB0aGUgcmlzayB3aWxsIGluY3JlYXNlLjxicj4NCnw8YnI+DQp8PGJyPg0K fDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgRnJvbSB0aGUgY2FzZSwgd2UgY2FuIGRlZHVjZSB0 aGF0IHRoZSByaXNrIG1heSBleGlzdHMgZm9yIGFueSBzY2VuYXJpb3MgaW48YnI+DQp8Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHdoaWNoIHRoZSBzYW1lIHRyYWZmaWM8YnI+DQp8PGJyPg0KfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBtYXkgc3dpdGNoIGZyb20gb25lIFNSIHBhdGggdG8gdGhlIG90aGVy IFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBT Ui1URSBwYXRoIHN1Y2ggYXMgTVBMUyBURTxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGhvdHN0YW5kYnkvcmVvcHRpbWl6YXRpb24gYW5kIFNSLUJFIHBhdGggc3VjaCBhcyBUSS1GUlIu PGJyPg0KfDxicj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBCZXNpZGVzIGFi b3ZlIGlzc3VlcywgTERQL1JTVlAtVEUgY2FuIHN1cHBvcnQgdGhlIHBhdGggTVRVIHRvIHRyYWNr IHRoZTxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgTVRVIGluZm9ybWFpdG9uIGFsb25nIHRoZTxi cj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IExTUCB0aHJvdWdoIHNpZ25hbGxpbmcuIFRo ZW4gdGhlIHJlYXNvbmFibGUgTVRVIGluZm8gd2lsbCBiZSBhZG9wdGVkIGluPGJyPg0KfCZuYnNw OyZuYnNwOyZuYnNwOyB0aGUgaW5ncmVzcyBub2RlLiBGb3IgYm90aDxicj4NCnw8YnI+DQp8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNSLVRFIHBhdGggKGlmIFBDRSBpcyBub3QgdXNlZCkgYW5k IFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlzIG5vPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBz aWduYWxsaW5nIHRvIGFkdmVydGlzZTxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo ZSBpbmZvcm1hdGlvbi4gSG93IHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZT8gT3IgdGhlcmUgbWF5 YmUgdGhlIHJpc2s8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIHBhY2tldCBtYXkg YmU8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBkcm9wcGVkIGJ5IHRoZSBub2RlcyBh bG9uZyB0aGUgTFNQLjxicj4NCnw8YnI+DQp8PGJyPg0KfDxicj4NCnw8YnI+DQp8PGJyPg0KfDxi cj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPGJyPg0KfDxicj4NCnwmbmJz cDsmbmJzcDsmbmJzcDsgUm9iaW48YnI+DQo8YnI+DQp8IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KfCBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0K fCA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n QGlldGYub3JnPC9hPjxicj4NCnwgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAACnkgeml506mbxchi_-- From nobody Wed Jan 28 23:06:44 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D181A8AFA; Wed, 28 Jan 2015 23:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.133 X-Spam-Level: **** X-Spam-Status: No, score=4.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGp9pLkWnI0F; Wed, 28 Jan 2015 23:06:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78FB1A1B51; Wed, 28 Jan 2015 23:06:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRW04070; Thu, 29 Jan 2015 07:06:35 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 07:06:34 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 15:06:29 +0800 From: Lizhenbin To: Uma Chunduri , Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AdA6Iy10hnzSmHMYSNeVsID5YDgzbAABb2SAADAnQIEAEuyzAAAWqcJr Date: Thu, 29 Jan 2015 07:06:28 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACE@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com>, <1B502206DFA0C544B7A60469152008633F55CF49@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F55CF49@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACEnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNl?= =?gb2312?b?Z21lbnQgUm91dGluZyg3KTogTVRVIENoYWxsZW5nZXMgZm9yIFNS?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 07:06:40 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACEnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVW1hLA0KDQpQbGVhc2UgcmVmZXIgdG8gbXkgaW5saW5lIGNvbW1lbnRzLg0KDQoNCg0KUmVn YXJkcywNCg0KUm9iaW4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IFVtYSBDaHVuZHVyaSBbdW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbV0NCreiy83Ksbzk OiAyMDE1xOox1MIyOcjVIDEyOjAxDQrK1bz+yMs6IExpemhlbmJpbjsgSGFubmVzIEdyZWRsZXIN CrOty806IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgdGVhc0BpZXRmLm9yZw0K1vfM 4jogUkU6IFtzcHJpbmddIE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1UVSBD aGFsbGVuZ2VzIGZvciBTUg0KDQpIaSBSb2JpbiwNCg0KSWYgd2UgaGF2ZSBNVFUgaXNzdWVzIHdp dGggaW4gYW4gYXJlYSwgSSBzZWUgdHJvdWJsZSBpbiBiYXNpYyBJR1AgZnVuY3Rpb25pbmcgKGZv ciBleGFtcGxlIGl0oa9zIGEgc2VyaW91cyBpc3N1ZSB3aXRoIElTLUlTIGZvciBiYXNpYyBvcGVy YXRpb24pLg0KW1JvYmluXSBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlcmUgZXhpc3RzIHRoZSBN VFUgaXNzdWUgZm9yIHRoZSByb3V0aW5nIGZ1bmN0aW9uaW5nLiBCdXQgdGhlIE1UVSBpc3N1ZSBj YW4gYmUgc29sdmVkIGJ5IHRoZSBwYXRoIE1UVSBtZWNoYW5pc20gcHJvdmlkZWQgYnkgTERQL1JT VlAtVEUuIE15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgU1IgcGF0aCBiYXNlZCBvbiB0aGUgTVBMUyBm b3J3YXJkaW5nIHBsYW5lIGlzIHRoZSBjb21wYXJhdGl2ZSB3aXRoIHRoZSByb3V0aW5nIG9yIE1Q TFMgTFNQLg0KDQpGb3IgaW50ZXIgYXJlYSBjYXNlcyBkb26hr3QgeW91IHRoaW5rIGl0oa9zIGlu IFBDRS9Db250cm9sbGVyoa9zIHNjb3BlIHRvIHNldHVwIHBhdGhzIGJhc2VkIG9uIHRoZSBhZHZl cnRpc2VkIE1UVSAoeWVzLCBpZiBNVFUgaXMgYWR2ZXJ0aXNlZCBvbiBBREpzIGFzIHByb3Bvc2Vk IGJlbG93KS4NCltSb2Jpbl0gSW4gZmFjdCwgaW4gdGhlIGNvbW1lbnRzICg4KSBJIGhhdmUgZXhw bGFpbmVkIHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMuIERvIHlvdSB0aGluayB0aGUgc29sdXRpb24g aXMgdG9vIGNvbXBsZXggZm9yIHRoZSBwYXRoIE1UVSBvZiBTUiB3aGljaCBjb3VsZCBoYXZlIGJl IHNvbHZlZCBieSB0aGUgcGF0aCBNVFUgaW5mb3JtYXRpb24gZXhjaGFuZ2UgdGhyb3VnaCBvbmx5 IExEUCBvciBSU1ZQLVRFIHdoaWxlIGZvciB0aGUgU1IgcGF0aCBpdCBoYXMgdG8gaW50cm9kdWNl IElHUC1iYXNlZCBNVFUgYWR2ZXJ0aXNlbWVudCwgdGhlIGVuZC10by1lbmQgcGF0aCBNVFUgY29t cHV0YXRpb24gaW4gdGhlIGluZ3Jlc3Mgbm9kZSwgYW5kIFBDRS1iYXNlZCBlbmQtdG8tZW5kIE1U VSBpbmZvcm1hdGlvbiBjb2xsZWN0aW9uPyAgRXZlbiBzbywgZm9yIFNSLUJFIHBhdGgsIHRoZXJl IGlzIHN0aWxsIGNoYWxsZW5nZXMgZm9yIHRoZSBwYXRoIE1UVS4gTW9yZW92ZXIsIHRoaXMgaXMg anVzdCBmb3IgdGhlIHBhdGggTVRVLiBUYWtpbmcgaW50byBhY2NvdW50IG1vcmUgc2NlbmFyaW9z IHdoaWNoIG5lZWRzIHRoZSBpbmZvcm1hdGlvbiBleGNoYW5naW5nIGFsb25nIHRoZSBub2RlcyBv ZiBMU1Agc3VjaCBhcyBwYXRoIHJlY29yZGluZywgbG9vcCBwcmV2ZW50aW9uLCBlcnJvciBoYW5k bGluZyBhbmQgb3RoZXIgZXhpc3RpbmcgZmVhdHVyZXMgb2YgTERQL1JTVlAtVEUsIHdoYXQgaXMg cG9zc2libGUgY29tcGxleGl0eSBmb3IgU1Igc29sdXRpb25zPw0KDQotLQ0KVW1hIEMuDQoNCkZy b206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaXpo ZW5iaW4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyOCwgMjAxNSAzOjA2IEFNDQpUbzogSGFu bmVzIEdyZWRsZXINCkNjOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IHRlYXNAaWV0 Zi5vcmcNClN1YmplY3Q6IFttcGxzXSC08Li0OiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2Vn bWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0KDQpIaSBIYW5uZXMsDQoN CkkgaGF2ZSBldmVyIHRob3VnaHQgYWJvdXQgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucyBiYXNlZCBv biB0aGUgZmxvb2RlZCBNVFUgaW5mb3JtYXRpb24gdGhyb3VnaCBJR1AuDQoNClRoZXJlIGFyZSBz dGlsbCB0d28gcG9zc2libGUgaXNzdWVzOg0KDQoxLiBJbnRlci1hcmVhIGZvciBTUi1URSBwYXRo OiBNYXliZSB3ZSBub3Qgb25seSBpbnRyb2R1Y2UgdGhlIElHUCBleHRlbnNpb25zLCBidXQgYWxz byBQQ0VQIGV4dGVuc2lvbnMuDQoNCjIuIEZvciBTUi1CRSBwYXRoLCBpdCBoYXMgdG8gaW50cm9k dWNlIHRoZSBURS1saWtlIGVuZC10by1lbmQgcGF0aCBjYWxjdWxhdGlvbiBhdCB0aGUgaW5ncmVz cyBub2RlLg0KDQoNCg0KTXkgY29uY2VybiBpcyBub3QganVzdCBmb3IgdGhlIHBvc3NpYmxlIHNv bHV0aW9ucywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ugb2YgU1Igd2hpY2ggbWF5IGhhcyBt dWNoDQoNCmVmZmVjdCBvbiBpdHMgZGVwbG95bWVudCBjb21wYXJpbmcgd2l0aCB0aGUgZXhpc3Rp bmcgTVBMUyBwcm90b2NvbC4gSXQgd2lsbCBiZSBleHBsYWluZWQgaW4NCg0KdGhlIG5leHQgY29t bWVudHMuDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQoNCg0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEhhbm5lcyBHcmVk bGVyIFtoYW5uZXNAanVuaXBlci5uZXRdDQq3osvNyrG85DogMjAxNcTqMdTCMjjI1SA0OjAxDQrK 1bz+yMs6IExpemhlbmJpbg0Ks63LzTogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgdGVhc0BpZXRmLm9y ZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NCtb3zOI6IFJlOiBbc3ByaW5nXSBOZXcgQ29tbWVudHMg b24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0Kb25seSBjYW4g c3BlYWsgZm9yIElTLUlTIC0NCmFmYWlrIHRoZSBUcmlsbCBleHRlbnNpb25zIGdhdmUgdXMgYSB3 YXkgb2Ygc2lnbmFsaW5nIHRoZSBNVFUgb2YgYSBsaW5rIC4uLg0KDQpzbyB3aGF0IHdlIGNvdWxk IGRvIGlzIHRvIGFkdmVydGlzZSB0aGUgTVRVIGZvciBlYWNoIGFkamFjZW5jeSBhbmQgaW1wbGVt ZW50DQpwcm9wZXIgZnJhZ21lbnRhdGlvbiBhdCB0aGUgVEUgdHVubmVsIGluZ3Jlc3MuDQoNCi9o YW5uZXMNCg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSArMDAwMCwgTGl6aGVu YmluIHdyb3RlOg0KfCAgICBIaSBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRpbmcsDQp8DQp8 ICAgIFRoaXMgaXMgdGhlIHNldmVudGggY29tbWVucy4gVGhlIGlzc3VlcyBwcm9wb3NlZCBoZXJl IGFyZSBmb3IgYm90aCBTUi1URQ0KfCAgICBwYXRoIGFuZCBTUi1CRSBwYXRoLg0KfA0KfA0KfA0K fCAgICAgICAgICAgICAxICAgICAgICAgICAgICAxICAgICAgICAgICAxICAgICAgICAgICAgMQ0K fCAgICAgIFMxMS0tLS0tLS0tLS0tUzEyLS0tLS0tLS0tLVMxMy0tLS0tLS0tLVMxNC0tLS0tLS0t LVMxNQ0KfCAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8ICAg ICAgICAgICB8DQp8ICAgICAgMXwgICAgICAgICAgICAxfCAgICAgICAgICAgMXwgICAgICAgICAg MXwgICAgICAgICAgMXwNCnwgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgfCAgICAgICAgICAgfA0KfCAgICAgIFMyMS0tLS0tLS0tLS0tUzIyLS0tLS0tLS0tLVMy My0tLS0tLS0tLVMyNC0tLS0tLS0tLVMyNQ0KfCAgICAgICAgICAgICA0ICAgICAgICAgICAgICA0 ICAgICAgICAgICA0ICAgICAgICAgICAgNA0KfA0KfA0KfA0KfCAgICBTdGlsbCB0YWtlIHRoZSB0 b3BvbG9neSBpbiB0aGUgY29tbWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIgdGhlDQp8 ICAgIGxvb3NlIGV4cGxpY2l0IHBhdGggb3INCnwNCnwgICAgdGhlIHN0cmljdCBleHBsaWNpdCBw YXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUgdGhlIE1UVSBvZiB0aGUNCnwgICAgaW50ZXJm YWNlIGlzIHRoZSBzYW1lLA0KfA0KfCAgICBzaW5jZSB0aGUgZGVwdGggb2YgdGhlIGxhYmVsIHN0 YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cA0KfCAgICBwYXRoIGFyZSBk aWZmZXJlbnQuDQp8DQp8ICAgIFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0aXZlIHBh eWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlDQp8ICAgIHByaW1hcnkgcGF0aCwgYnV0IG1h eSBiZQ0KfA0KfCAgICBmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBwYXRoLiBB cyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZQ0KfCAgICBsYWJlbCBzdGFja3Mgb2YgdGhlDQp8 DQp8ICAgIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0aGUgcmlz ayB3aWxsIGluY3JlYXNlLg0KfA0KfA0KfA0KfCAgICBGcm9tIHRoZSBjYXNlLCB3ZSBjYW4gZGVk dWNlIHRoYXQgdGhlIHJpc2sgbWF5IGV4aXN0cyBmb3IgYW55IHNjZW5hcmlvcyBpbg0KfCAgICB3 aGljaCB0aGUgc2FtZSB0cmFmZmljDQp8DQp8ICAgICBtYXkgc3dpdGNoIGZyb20gb25lIFNSIHBh dGggdG8gdGhlIG90aGVyIFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzDQp8ICAgIFNSLVRF IHBhdGggc3VjaCBhcyBNUExTIFRFDQp8DQp8ICAgIGhvdHN0YW5kYnkvcmVvcHRpbWl6YXRpb24g YW5kIFNSLUJFIHBhdGggc3VjaCBhcyBUSS1GUlIuDQp8DQp8DQp8DQp8ICAgIEJlc2lkZXMgYWJv dmUgaXNzdWVzLCBMRFAvUlNWUC1URSBjYW4gc3VwcG9ydCB0aGUgcGF0aCBNVFUgdG8gdHJhY2sg dGhlDQp8ICAgIE1UVSBpbmZvcm1haXRvbiBhbG9uZyB0aGUNCnwNCnwgICAgTFNQIHRocm91Z2gg c2lnbmFsbGluZy4gVGhlbiB0aGUgcmVhc29uYWJsZSBNVFUgaW5mbyB3aWxsIGJlIGFkb3B0ZWQg aW4NCnwgICAgdGhlIGluZ3Jlc3Mgbm9kZS4gRm9yIGJvdGgNCnwNCnwgICAgIFNSLVRFIHBhdGgg KGlmIFBDRSBpcyBub3QgdXNlZCkgYW5kIFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlzIG5vDQp8 ICAgIHNpZ25hbGxpbmcgdG8gYWR2ZXJ0aXNlDQp8DQp8ICAgIHRoZSBpbmZvcm1hdGlvbi4gSG93 IHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZT8gT3IgdGhlcmUgbWF5YmUgdGhlIHJpc2sNCnwgICAg dGhhdCB0aGUgcGFja2V0IG1heSBiZQ0KfA0KfCAgICBkcm9wcGVkIGJ5IHRoZSBub2RlcyBhbG9u ZyB0aGUgTFNQLg0KfA0KfA0KfA0KfA0KfA0KfA0KfA0KfCAgICBSZWdhcmRzLA0KfA0KfCAgICBS b2Jpbg0KDQp8IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQp8IHNwcmluZyBtYWlsaW5nIGxpc3QNCnwgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+DQp8IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n DQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACEnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Uma,

Please refer to my inline comments.

 

Regards,

Robin

 

=B7=A2=BC=FE=C8=CB: Uma Chunduri [uma.chun= duri@ericsson.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C229=C8=D5 12:01
=CA=D5=BC=FE=C8=CB: Lizhenbin; Hannes Gredler
=B3=AD=CB=CD: mpls@ietf.org; spring@ietf.org; teas@ietf.org
=D6=F7=CC=E2: RE: [spring] New Comments on Segment Routing(7): MTU C= hallenges for SR

Hi Robin,

 

If we have MTU issues with in an area, I s= ee trouble in basic IGP functioning (for example it=A1=AFs a serious issue = with IS-IS for basic operation).

[Robin] I agree with you that there exists= the MTU issue for the routing functioning. But the MTU issue can be solved= by the path MTU mechanism provided by LDP/RSVP-TE. My question is whether SR path based on the MPLS forwardin= g plane is the comparative with the routing or MPLS LSP.

 

For inter area cases don=A1=AFt you think = it=A1=AFs in PCE/Controller=A1=AFs scope to setup paths based on the advert= ised MTU (yes, if MTU is advertised on ADJs as proposed below).

[Robin] In fact, in the comments (8) I hav= e explained the possible solutions. Do you think the solution is too comple= x for the path MTU of SR which could have be solved by the path MTU information exchange through only LDP = or RSVP-TE while for the SR path it has to introduce IGP-based MTU advertis= ement, the end-to-end path MTU computation in the ingress node, and PCE-bas= ed end-to-end MTU information collection?  Even so, for SR-BE path, there is still challenges for the path MTU. Moreo= ver, this is just for the path MTU. Taking into account more scenarios whic= h needs the information exchanging along the nodes of LSP such as path reco= rding, loop prevention, error handling and other existing features of LDP/RSVP-TE, what is possible complexity fo= r SR solutions?

 

--

Uma C.

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Wednesday, January 28, 2015 3:06 AM
To: Hannes Gredler
Cc: mpls@ietf.org; spring@ietf.org; teas@ietf.org
Subject: [mpls] =B4=F0=B8=B4: [spring] New Comments on Segment Routing(7): MTU Challenges= for SR

 

Hi H= annes,

I ha= ve ever thought about the possible solutions based on the flooded MTU infor= mation through IGP.

Ther= e are still two possible issues:

1. I= nter-area for SR-TE path: Maybe we not only introduce the IGP extensions, b= ut also PCEP extensions.

2. F= or SR-BE path, it has to introduce the TE-like end-to-end path calculation = at the ingress node. 

My c= oncern is not just for the possible solutions, but to explore the essence o= f SR which may has muc= h

effect on its deploym= ent comparing with the existing MPLS protocol. It will be explained in

the next comments.

 

 

Regards,

Robin

 

 

 



________________________________________
=B7=A2= =BC=FE=C8=CB: Hannes Gredler [hannes@juniper.net]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C228=C8=D5 4:01
=CA=D5= =BC=FE=C8=CB: Lizhenbin
=B3=AD= =CB=CD: spring@ietf.org; <= a href=3D"mailto:mpls@ietf.org" target=3D"_blank"> mpls@ietf.org; teas@= ietf.org
=D6=F7= =CC=E2: Re: [spring] New Comments on Segment Routing(7): MTU Challenges for= SR

only can speak for IS-IS -
afaik the Trill extensions gave us a way of signaling the MTU of a link ...=

so what we could do is to advertise the MTU for each adjacency and implemen= t
proper fragmentation at the TE tunnel ingress.

/hannes

On Tue, Jan 27, 2015 at 11:24:23AM +0000, Lizhenbin wrote:
|    Hi all authors of segment routing,
|
|    This is the seventh commens. The issues proposed here a= re for both SR-TE
|    path and SR-BE path.
|
|
|
|             1=             &nb= sp; 1           1 &n= bsp;          1
|      S11-----------S12----------S13---------S14-= --------S15
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      1|       = ;     1|        = ;   1|          1|&n= bsp;         1|
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      S21-----------S22----------S23---------S24-= --------S25
|             4=             &nb= sp; 4           4 &n= bsp;          4
|
|
|
|    Still take the topology in the comment 6 as the example= . No matter the
|    loose explicit path or
|
|    the strict explicit path for the loose hop, assume the = MTU of the
|    interface is the same,
|
|    since the depth of the label stacks for the primary pat= h and the backup
|    path are different.
|
|    There is the risk that the effetive payload may transmi= t through the
|    primary path, but may be
|
|    fragmented or dropped in the backup path. As the differ= ence between the
|    label stacks of the
|
|    primary path and the backup path increase, the risk wil= l increase.
|
|
|
|    From the case, we can deduce that the risk may exists f= or any scenarios in
|    which the same traffic
|
|     may switch from one SR path to the other SR path.= The SR path includes
|    SR-TE path such as MPLS TE
|
|    hotstandby/reoptimization and SR-BE path such as TI-FRR= .
|
|
|
|    Besides above issues, LDP/RSVP-TE can support the path = MTU to track the
|    MTU informaiton along the
|
|    LSP through signalling. Then the reasonable MTU info wi= ll be adopted in
|    the ingress node. For both
|
|     SR-TE path (if PCE is not used) and SR-BE path, s= ince there is no
|    signalling to advertise
|
|    the information. How to implement the feature? Or there= maybe the risk
|    that the packet may be
|
|    dropped by the nodes along the LSP.
|
|
|
|
|
|
|
|    Regards,
|
|    Robin

| _______________________________________________
| spring mailing list
| spring@ietf.org<= br> | https://www.ietf.org/mailman/listinfo/spring

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACEnkgeml506mbxchi_-- From nobody Wed Jan 28 23:47:43 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC51A8FD6; Wed, 28 Jan 2015 23:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytq7iLJdVYab; Wed, 28 Jan 2015 23:47:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43411A0006; Wed, 28 Jan 2015 23:47:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRW08063; Thu, 29 Jan 2015 07:47:30 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 07:47:28 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 15:47:17 +0800 From: Lizhenbin To: Robert Raszuk Thread-Topic: [spring] New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR Thread-Index: AdA66yE5259u7U/sTZCfhnmR4h4dm///ltGAgAG6xBA= Date: Thu, 29 Jan 2015 07:47:17 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863@nkgeml506-mbx.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNl?= =?gb2312?b?Z21lbnQgUm91dGluZyg4KTogTG9vcCBQcmV2ZW50aW9uIGFuZCBFcnJvciBI?= =?gb2312?b?YW5kbGluZyBmb3IgU1I=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 07:47:38 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpQbGVhc2VyIHJlZmVyIHRvIG15IGlubGluZSBjb21tZW50cy4NCg0KDQoN Cg0KDQpSZWdhcmRzLA0KDQpSb2Jpbg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQq3orz+yMs6IHJyYXN6dWtAZ21haWwuY29tIFtycmFzenVrQGdtYWlsLmNvbV0g tPqx7SBSb2JlcnQgUmFzenVrIFtyb2JlcnRAcmFzenVrLm5ldF0NCreiy83KsbzkOiAyMDE1xOox 1MIyOMjVIDIwOjU0DQrK1bz+yMs6IExpemhlbmJpbg0Ks63LzTogc3ByaW5nQGlldGYub3JnOyBt cGxzQGlldGYub3JnOyB0ZWFzQGlldGYub3JnDQrW98ziOiBSZTogW3NwcmluZ10gTmV3IENvbW1l bnRzIG9uIFNlZ21lbnQgUm91dGluZyg4KTogTG9vcCBQcmV2ZW50aW9uIGFuZCBFcnJvciBIYW5k bGluZyBmb3IgU1INCg0KUm9iaW4sDQoNCk1vc3QgaWYgbm90IG9mIHlvdXIgb2JzZXJ2YXRpb25z IGNpcmNsZSBhcm91bmQgaWRlYSB0byB1c2Ugc2VnbWVudCByb3V0aW5nIGFzIE1QTFMgbGFiZWwg c2lnbmFsbGluZyBtZWNoYW5pc20uIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgdGhhdCBpbnRlcmVz dGluZyBzY2VuYXJpby4gUGVyc29uYWxseSBJIHdvdWxkIG5vdCBkZXBsb3kgaXQgZm9yIHN1Y2gg cHVycG9zZSBvZiBob3AgYnkgaG9wIE1QTFMgc3dpdGNoaW5nLiBXZSBoYXZlIExEUCBmb3IgdGhh dC4NCg0KW1JvYmluXQ0KMS4gSSB3b25kZXIgd2hldGhlciB0aGlzIGlzIHlvdXIgb3duIGlkZWEg b3IgdGhlIHdlbGwtYWNjZXB0ZWQgaWRlYSBvZiBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRp bmcuIEZyb20gdGhlIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWlu dGVyb3AtMDIvZHJhZnQtZnJhbmNvaXMtc3ByaW5nLXNlZ21lbnQtcm91dGluZy10aS1sZmEtMDEs IGl0IHNlZW1zIHRoYXQgdGhlIFNSLUJFIHBhdGggaXMgdGhlIHJlcGxhY2VtZW50IG9mIExEUC4g RnJvbSB0aGUgZHJhZnQtaWV0Zi1wY2Utc2VnbWVudC1yb3V0aW5nLTAwLCBpdCBzZWVtcyB0aGF0 IHRoZSBTUi1URSBwYXRoIGlzIHRoZSByZXBsYWNlbWVudCBvZiBSU1ZQLVRFLg0KMi4gSSB0aGlu ayB0aGUgcGFja2V0IHN0ZWVyaW5nIGlzIHRydWx5IGFuIGFtYmlndW91cyBjb25jZXB0LiBJIGFn cmVlIHdpdGggeW91ciB1c2VjYXNlcy4gV2UgYWxzbyBhcHByZWNpYXRlZCB0aGUgcG9zc2libGUg Y2hhbmNlcyBwcm9wb3NlZCBieSB0aGUgU1IgYW5kIHByb21vdGUgdGhlIGlkZWEgaW4gbXkgZHJh ZnQgZHJhZnQtbGktc3ByaW5nLW1wbHMtcGF0aC1wcm9ncmFtbWluZy0wMCB0aGF0IE1QTFMgbGFi ZWwgaXMgYmVjb21pbmcgdGhlIGluZGljYXRvciBiZXlvbmQgdGhlIHJlYWNoYWJpbGl0eSBhbmQg Y2FuIGJlIHVzZWQgYXMgdGhlIHJlcHJlc2VudGF0aW9uIG9mIGZsZXhpYmxlIHNlcnZpY2VzIGNv bWJpbmF0aW9uLiBJIHRoaW5rIHRoZXNlIHRvcGljcyBjYW4gZGV2ZWxvcCB0aGUgZXhpc3Rpbmcg SVAvTVBMUyB3b3JsZCBpbnRvIHNvbWUgbmV3IGZpZWxkcy4gQnV0IHRoZSBhbWJpZ3VvdXMgdGhp bmcgaXMgdGhhdCB0aGUgdHJhZGl0aW9uYWwgcm91dGluZyBhbmQgTVBMUyB0cmFmZmljIGVuZ2ll ZXJpbmcgY2FuIGFsc28gYmUgc2VlbiBhcyBzb21lIHR5cGVzIG9mIHRyYWZmaWMgc3RlZXJpbmcu IEkgdGhpbmsgdGhpcyB3aWxsIGJlIHJlcGVhdGVkIHdvcmsgaWYgU1IncyBvYmplY3RpdmUgdG8g c29sdmUgdGhlIGludGVybmFsIGVuZC10by1lbmQgcmVhY2hhYmlsaXR5IGlzc3VlLiBNeSBjb21t ZW50cyBpcyBqdXN0IHRvIGV4cGxhaW4gdGhlIHBvc3NpYmxlIGNoYWxsZW5nZXMgYW5kIGNvbXBs ZXhpdHkgZm9yIElHUC1iYXNlZCBTUiBwYXRoIGNvbXBhcmluZyB3aXRoIHRoZSBleGlzdGluZyBM RFAvUlNWUC1URS4gQW5kIEkgZG8gbm90IHRoaW5rIFNSIGNhbiBzb2x2ZSB0aGUgaXNzdWVzIGJl dHRlciB0aGFuIExEUC9SU1ZQLVRFIHRob3VnaCB0aGVyZSBtYXliZSBzb21lIGFkdmFudGFnZS4g SWYgd2UgY2FuIGJlIGF3YXJlIG9mIHRoaXMsIHdlIHNob3VsZCBzdG9wIHRoZSBjb21wbGV4IHBy b3RvY29sIGV4dGVuc2lvbnMgd29yayBmb3IgU1IgaW4gdGhpcyBmaWVsZC4gT3IgZWxzZSwgaXQg aXMganVzdCB0byBtYWtlIG1lc3MgaW4gdGhlIE1QTFMgd29ybGQgYW5kIHByb2R1Y2UgY29tcGxl eGl0eSBmb3IgdGhlIHNlcnZpY2UgcHJvdmlkZXJzLg0KDQoNClRoaXMgaXMgdGhlIHJlYXNvbiB0 aGF0IHRoZSBTUiBwcm9wb3NlcyB0b28gbWFueSBhbWJpZ3VvdXMgdGhpbmdzIHdoaWNoIEkgd2ls bCBleHBsYWluIGxhdGVyLg0KDQoNCg0KQ29udHJhcnkgSSB3b3VsZCB1c2UgU1IgZm9yIGNvbnRy b2xsZWQgcGFja2V0IHN0ZWVyaW5nIHdoZXJlIHJlc3BvbnNpYmlsaXR5IGlzIHRha2UgdG8gbWFr ZSB0aGUgcmlnaHQgaGVhZGVyIChiZSBpdCBsYWJlbCBvciBleHRlbnNpb24gaGVhZGVycykgdXBv biBvcGVyYXRvciBvciBoaXMgY29udHJvbGxlci4NCg0KVG8gdGhlIHBvaW50IG9mIHRoZSBsb29w IC4uIG5vdGUgdGhhdCB5b3UgbWF5IGhhdmUgdmFsaWQgY2FzZXMgdG8gdHJhdmVyc2UgZ2l2ZW4g YXBwbGlhbmNlIChTRkMgdXNlIGNhc2UpIG1vcmUgdGhlbiBvbmNlcyBoZW5jZSBJIHdvdWxkIGNs YWltIGl0IGlzIG5vdCBhYSBhcmNoaXRlY3R1cmUgc3BlYyBwcm9ibGVtLCBidXQgaWYgc28gZGVw bG95bWVudCBidWcuDQoNCkJlc3QsDQpyLg0KDQoNCg0KT24gV2VkLCBKYW4gMjgsIDIwMTUgYXQg MTI6MzAgUE0sIExpemhlbmJpbiA8bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRvOmxpemhlbmJp bkBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCkhpIGFsbCBhdXRob3JzIG9mIHNlZ21lbnQgcm91dGlu ZywNCg0KDQoNClRoaXMgaXMgdGhlIGVpZ2h0aCBjb21tZW50cy4gVGhlIGlzc3VlcyBwcm9wb3Nl ZCBoZXJlIGFwcGx5IHRvIGJvdGggU1ItVEUgcGF0aCBhbmQgU1ItQkUgcGF0aC4NCg0KDQoNCkZv ciBMRFAgYW5kIFJTVlAtVEUsIHRoZXJlIGlzIHRoZSBsb29wIHByZXZlbnRpb24gbWVjaGFuaXNt IHdoZW4gc2V0dXAgTFNQLiBGb3IgdGhlIFNSLCB0aGUgU1IgcGF0aCBpcyBhbHdheXMNCg0Kc2V0 dXAgYXQgdGhlIGluZ3Jlc3Mgbm9kZS4gSXQgaXMgZGlmZmljdWx0IHRvIGRldGVjdCB0aGUgcG9z c2libGUgbG9vcCBpbiB0aGUgbmV0d29yay4gRm9yIGV4YW1wbGUsIGlmIHRoZQ0KDQptaWNyb2xv b3Agb2Ygcm91dGUgaGFwcGVucywgdGhlIGxvb3AgcHJldmVudGlvbiBtZWNoYW5pc20gd2lsbCBw cmV2ZW50IExEUCB0byBzZXR1cCBMU1AuIEJ1dCBmb3IgdGhlIHNlZ21lbnQNCg0Kcm91dGluZywg b25jZSB0aGUgaW5ncmVzcyBub2RlIGRvd25sb2FkcyB0aGUgZm9yd2FyZGluZyBlbnRyeSBhbmQg dGhlIHRyYWZmaWMgd2lsbCBleHBlcmllbmNlIHRoZSBtaWNyb2xvb3AuDQoNCkhvdyBjYW4gU1Ig dG8gY29wZSB3aXRoIHRoZSBpc3N1ZSBvciBqdXN0IGxlYXZlIGl0IGFzIHRoZSB0cmFkaXRpb25h bCByb3V0aW5nPw0KDQoNCg0KRm9yIExEUCBhbmQgUlNWUC1URSwgdGhlcmUgaXMgdGhlIGVycm9y IG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gYmFzZWQgb24gdGhlIExEUCBub3RpZmljYXRpb24gbWVz c2FnZSBvciB0aGUNCg0KUlNWUC1URSBQYXRoRXJyL1Jlc3YgbWVzc2FnZXMuIEJhc2VkIG9uIHRo ZSBlcnJvciBub3RpZmljYXRpb24sIHRoZSBub2RlcyBhbG9uZyB0aGUgTFNQIGNhbiB0YWtlIHBv c3NpYmxlDQoNCmFjdGlvbnMgYWdhaW5zdCB0aGUgcG9zc2libGUgZXJyb3JzLiBCdXQgZm9yIFNS LCB0aGVyZSBpcyBubyBzdWNoIGluZm9ybWF0aW9uIGNvbW11bmljYXRlZCBhbW9uZyB0aGUgbm9k ZXMNCg0KYWxvbmcgdGhlIFNSIFBhdGguIFRoZSByZXN1bHQgd2lsbCBiZSB0aGF0IG9uY2UgdGhl IHBhY2tldCBpcyBmb3J3YXJkZWQgYnkgdGhlIGluZ3Jlc3Mgbm9kZSwgdGhleSBtYXkNCg0KZXhw ZXJpZW5jZSB0aGUgcG9zc2libGUgZXJyb3JzIHdoaWNoIG1heSBiZSBwcmV2ZW50ZWQgYnkgdGhl IG5lZ290aWF0aW9uIGluIHRoZSBjb250cm9sIHBsYW5lLg0KDQoNCg0KRnJvbSB0aGUgcHJldmlv dXMgY29tbWVudHMsIHdlIGNhbiBzZWUgdGhhdCBpbiB0aGUgdHJhZGl0aW9uYWwgTFNQLCB0aGUg TFNQIHNldHVwIGlzIG5lZ290aWF0ZWQgdGhyb3VnaA0KDQp0aGUgc2lnbmFsbGluZyBiZXR3ZWVu IHRoZSB1cHN0cmVhbSBub2RlIGFuZCB0aGUgZG93bnN0cmVhbSBub2RlLiBEdXJpbmcgdGhlIG5l Z290aWF0aW9uLCBpdCBpcyBub3Qgb25seSB0bw0KDQpzZXQgdXAgdGhlIGZvcndhcmRpbmcgdGhl IGVudHJ5IGZvciB0aGUgcHVycG9zZSBvZiByZWFjaGFibGl0eSwgYnV0IGFsc28gaW5jbHVkZXMg bWFueSBhc3BlY3RzIChJIGNhbGwgdGhlbQ0KDQphcyB0aGUgb3BlcmF0aW9uIGFuZCBtYWludGVu ZW5jZSBvZiB0aGUgTFNQLiBIb3BlIGl0IGlzIGFwcHJvcHJpYXRlLiApIHN1Y2ggYXMgdGhlIGVu ZC10by1lbmQgY29ubmVjdGl2aXR5DQoNCnZlcmlmaWNhdGlvbiwgdGhlIGxvb3AgcHJldmVudGlv biwgcGF0aCBNVFUsIG5lZ290aWF0aW9uLCBwYXRoIHJlY29yZGluZywgZXJyb3Igbm90aWZpY2F0 aW9uIGFuZCBoYW5kbGluZywNCg0KZXRjLiBUaG91Z2ggU1IgYWx3YXlzIHByb3Bvc2VzIGl0cyBh ZHZhbnRhZ2UsIGluIG15IG9waW5pb24sIHRoZXNlIGFkdmFudGFnZXMgYXJlIGZyb20gdGhlIHJl YWNoYWJpbGl0eQ0KDQpwYXJ0IHN1Y2ggYXMgdGhlIGFkdmFudGFnZSB0aGF0IHRoZSBsYWJlbCBz dGF0Y2sgaW4gdGhlIGluZ3Jlc3Mgbm9kZSByZWR1Y2VzIHRoZSBzdGF0ZXMgaW4gdGhlIG5ldHdv cmsuDQoNCkJ1dCB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBvcGVyYXRpb25hbCBhbmQgbWFpbnRl bmFuY2UgZm9yIHRoZSB0cmFkaXRpb25hbCBMU1Agc3RpbGwgZXhpc3QuIFRha2luZyBpbnRvDQoN CmFjY291bnQgdGhhdCB0aGUgZmxvb2RpbmcgbW9kZSBvZiB0aGUgSUdQLCBpdCBzdG9wcyB0aGUg Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBub2RlcyBhbG9uZyB0aGUgcGF0aCwNCg0KdGhlIHdv cmsgbWF5IGJlY29tZSBtb3JlIGNvbXBsZXguIEFjY29yZGluZyB0byB0aGUgcGFzdCBleHBlcmll bmNlLCB0aGUgcG9zc2libGUgd2F5cyBJIGNvdWxkIHRoaW5rIG91dCBhcmUNCg0KYXMgZm9sbG93 czoNCjEpIERlcGVuZCBvbiB0aGUgdGhpcmQtcGFydHkgbWVjaGFuaXNtcy4gQnV0IHRoZSBwcm9i bGVtIGlzIHRoYXQgdGhlcmUgbWF5IGludm9sdmUgbW9yZSBtZWNoYW5pc21zIGFuZCB0aGVyZQ0K DQptYXkgYmUgbm8gbWVjaGFuaXNtcy4gRm9yIGV4YW1wbGUsIExTUCBQaW5nIGNhbiBiZSBhZG9w dGVkIHRvIGNoZWNrIHRoZSBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eSBvciBsb29wIGZvcg0KDQp0 aGUgU1ItQkUgcGF0aCwgYnV0IGl0IGNhbm5vdCBiZSB1c2VkIGZvciBwYXRoIE1UVSBuZWdvdGlh dGlvbi4gRm9yIHRoZSBlbmQtdG8tZW5kIHBhdGggcmVjb3JkaW5nLCBMU1AgVHJhY2VydA0KDQpt YXkgaGF2ZSB0byBiZSBpbnRyb2R1Y2VkLiBJZiB0aGVzZSByZXF1aXJlbWVudHMgYW5kIG1lY2hh bmlzbXMgYXJlIGNvbnNpZGVyZWQsIGl0IG1lYW5zIFNSIGRvZXMgbm90IHJlZHVjZQ0KDQp0aGUg Y29tcGV4aXR5LiBJbnN0ZWFkIGl0IGp1c3QgdHJhbnNmZXJzIG1vcmUgY29tcGxleGl0eSB0byB0 aGUgb3RoZXIgcG9zc2libGUgc2lnbmFsbGluZ3MuDQoyKSBEZXBlbmQgb24gb25lIG5vZGVzIHRv IGltcGxlbWVudCB0aGUgcG9zc2libGUgZnVuY3Rpb25zLiBGb3IgZXhhbXBsZSwgZm9yIFNSLVRF IHBhdGgsIGl0IGNhbiBkZXBlbmQgb24gdGhlDQoNClBDRSBvciB0aGUgaW5ncmVzcyBub2RlIHRv IGNvbGxlY3QgYWxsIHBhdGggaW5mbyBwcm9wb3NlZCBieSBwYXRoIHJlY29yZGluZyBvciBldmVu IHBhdGggTVRVIG5lZ290aWF0aW9uLiBFdmVuIHNvLA0KDQp0aGVyZSBpcyBzdGlsbCBzb21lIGRy YXdiYWNrcyBmb3Igc29tZSBzY2VuYXJpb3MgaWYgb25seSBkZXBlbmQgb24gdGhlIGluZ3Jlc3Mg bm9kZS4gTW9yZW92ZXIgdGhlc2UgbWV0aG9kcw0KY2Fubm90IGFwcGx5IHRvIFNSLUJFIHBhdGgu SWYgdGhlIHBvc3NpYmxlIHdvcmsgaXMgZG9uZSB0aHJvdWdoIHRoZSBpbmdyZXNzIG5vZGUsIGl0 IHdpbGwgYmVnaW4gdG8gY2hhbmdlIHRoZQ0KDQplc3NlbmNlIG9mIFNSLUJFIGFuZCBiZWNvbWUg dGhlIFNSLVRFLg0KMykgTGVhdmUgYXMgaXQgaXMuIFRoYXQgaXMsIHRoZXNlIGlzc3VlcyBhcmUg bm90IHNvbHZlZCBmb3IgU1IgcGF0aC4gSW4gbXkgb3duIG9waW5pb24sIDIwIHllYXJzIGFnbywg b25seQ0KDQpzb2x2aW5nIHRoZSByZWFjaGFiaWxpdHkgaXNzdWVzIG1heSBiZSBhY2NlcHRlZC4g QnV0IHRvZGF5LCBhcyB0aGUgY29uY2VwdCBvZiBjYXJyaWVyLWdyYWRlIElQIG5ldHdvcmsgaGFz IGJlZW4NCg0Kd2lkZWx5IGFjY2VwdGVkIGFuZCB0aGVzZSBmZWF0dXJlcyBtZW50aW9uZWQgaGFz IGJlZW4gZGVwbG95ZWQgaW4gdGhlIHRyYWRpdGlvbmFsIE1QTFMgbmV0d29yaywgSSBkb24ndCB0 aGluaw0KDQp0aGV5IGNhbiBiZSByZW1vdmVkIGVhc2lseS4NCg0KSW4gb25lIHdvcmQsIHRob3Vn aCBzb21lIGFkdmFudGFnZSBkcml2ZW4gZnJvbSB0aGUgcmVhY2hiaWxpdHkgb2YgU1IgaXMgYXBw YXJlbnQsIHRoZSBjb21wbGV4aXR5IGludHJvY3VkZWQgYnkNCg0KdGhlIHN5bnRoZXNpemVkIHJl cXVpcmVtZW50cyBhcmUgbm90IHJlZHVjZWQuIEFuZCBpdCBtYXkgYmVjb21lIG1vcmUgY29tcGxl eCBmb3IgU1IuDQoNCg0KDQoNCg0KDQoNCg0KDQpSZWdhcmRzLA0KDQpSb2Jpbg0KDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcg bWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg0K --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Robert,

Pleaser refer to my inline comments.

 

 

Regards,

Robin

 

 

=B7=A2=BC=FE=C8=CB: rraszuk@gmail.com [rra= szuk@gmail.com] =B4=FA=B1=ED Robert Raszuk [robert@raszuk.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C228=C8=D5 20:54
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: spring@ietf.org; mpls@ietf.org; teas@ietf.org
=D6=F7=CC=E2: Re: [spring] New Comments on Segment Routing(8): Loop = Prevention and Error Handling for SR

Robin,

Most if not of your observations circle around idea to use segment routing = as MPLS label signalling mechanism. I do not think this is that interesting= scenario. Personally I would not deploy it for such purpose of hop by hop = MPLS switching. We have LDP for that.
 
[Robin]
1. I wonder whether this is your own idea or the well-accepted idea of all = authors of segment routing. From the draft-filsfils-spring-segment-routing-= ldp-interop-02/draft-francois-spring-segment-routing-ti-lfa-01, it seems th= at the SR-BE path is the replacement of LDP. From the draft-ietf-pce-segment-routing-00, it seems that the SR-T= E path is the replacement of RSVP-TE.
2. I think the packet steering is truly an ambiguous concept. I agree with = your usecases. We also appreciated the possible chances proposed by the SR = and promote the idea in my draft draft-li-spring-mpls-path-programming-00&n= bsp;that MPLS label is becoming the indicator beyond the reachability and can be used as the representation of flex= ible services combination. I think these topics can develop the existi= ng IP/MPLS world into some new fields. But the ambiguous thing is that the = traditional routing and MPLS traffic engieering can also be seen as some types of traffic steering. I think this will= be repeated work if SR's objective to solve the internal end-to-end reacha= bility issue. My comments is just to explain the possible challenges and co= mplexity for IGP-based SR path comparing with the existing LDP/RSVP-TE. And I do not think SR c= an solve the issues better than LDP/RSVP-TE though there maybe some ad= vantage. If we can be aware of this, we should stop the complex p= rotocol extensions work for SR in this field. Or else, it is just to make mess in the MPLS world and produce complexity for the service provide= rs.
 
 
This is the reason that the SR proposes too many ambiguous things which I w= ill explain later.
 
 

Contrary I would use SR for controlled packet steering where responsibility= is take to make the right header (be it label or extension headers) upon o= perator or his controller. 

To the point of the loop .. note that you may have valid cases to traverse = given appliance (SFC use case) more then onces hence I would claim it is no= t aa architecture spec problem, but if so deployment bug.

Best,
r.

 

On Wed, Jan 28, 2015 at 12:30 PM, Lizhenbin <lizhenbin@hua= wei.com> wrote:

Hi all authors of segment routing,

 

This is the eighth comments. The issues proposed = here apply to both SR-TE path and SR-BE path.

 

For LDP and RSVP-TE, there is the loop prevention= mechanism when setup LSP. For the SR, the SR path is always

setup at the ingress node. It is difficult to det= ect the possible loop in the network. For example, if the

microloop of route happens, the loop prevention m= echanism will prevent LDP to setup LSP. But for the segment

routing, once the ingress node downloads the forw= arding entry and the traffic will experience the microloop.

How can SR to cope with the issue or just leave i= t as the traditional routing?

 

For LDP and RSVP-TE, there is the error notificat= ion mechanism based on the LDP notification message or the

RSVP-TE PathErr/Resv messages. Based on the error= notification, the nodes along the LSP can take possible

actions against the possible errors. But for SR, = there is no such information communicated among the nodes

along the SR Path. The result will be that once t= he packet is forwarded by the ingress node, they may

experience the possible errors which may be preve= nted by the negotiation in the control plane.

 

From the previous comments, we can see that in th= e traditional LSP, the LSP setup is negotiated through

the signalling between the upstream node and the = downstream node. During the negotiation, it is not only to

set up the forwarding the entry for the purpose o= f reachablity, but also includes many aspects (I call them

as the operation and maintenence of the LSP. Hope= it is appropriate. ) such as the end-to-end connectivity

verification, the loop prevention, path MTU, nego= tiation, path recording, error notification and handling,

etc. Though SR always proposes its advantage, in = my opinion, these advantages are from the reachability

part such as the advantage that the label statck = in the ingress node reduces the states in the network. 

But the requirements of the operational and maint= enance for the traditional LSP still exist. Taking into

account that the flooding mode of the IGP, it sto= ps the communication between the nodes along the path,

the work may become more complex. According to th= e past experience, the possible ways I could think out are

as follows:
1) Depend on the third-party mechanisms. But the problem is that there may = involve more mechanisms and there

may be no mechanisms. For example, LSP Ping can b= e adopted to check the end-to-end connectivity or loop for

the SR-BE path, but it cannot be used for path MT= U negotiation. For the end-to-end path recording, LSP Tracert

may have to be introduced. If these requirements = and mechanisms are considered, it means SR does not reduce

the compexity. Instead it just transfers mor= e complexity to the other possible signallings.
2) Depend on one nodes to implement the possible functions. For example, fo= r SR-TE path, it can depend on the

PCE or the ingress node to collect all path info = proposed by path recording or even path MTU negotiation. Even so,

there is still some drawbacks for some scenarios = if only depend on the ingress node. Moreover these methods
cannot apply to SR-BE path.If the possible wo= rk is done through the ingress node, it will begin to change the

essence of SR-BE and become the SR-TE.
3) Leave as it is. That is, these issues are not solved for SR path. In my = own opinion, 20 years ago, only

solving the reachability issues may be accepted. = But today, as the concept of carrier-grade IP network has been

widely accepted and= these features mentioned has been deployed in the traditional MPLS network= , I don't think

they can be removed easily.

In one word, though some advantage driven from th= e reachbility of SR is apparent, the complexity introcuded by

the synthesized requirements are not reduced. And= it may become more complex for SR.

 

 

 

 

Regards,

Robin

 

 


_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring


--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03nkgeml506mbxchi_-- From nobody Thu Jan 29 03:00:24 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B061A01F6; Thu, 29 Jan 2015 03:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp-IcE9Cst3N; Thu, 29 Jan 2015 03:00:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147B51A0151; Thu, 29 Jan 2015 03:00:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRW30253; Thu, 29 Jan 2015 11:00:02 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 11:00:01 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 18:59:54 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(9): Challenge of Interoperability of SR with LDP Thread-Index: AdA7rl9TBP+3cFRkTrmNFT7kI3h8ow== Date: Thu, 29 Jan 2015 10:59:54 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6A@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6Ankgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [mpls] New Comments on Segment Routing(9): Challenge of Interoperability of SR with LDP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 11:00:10 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6Ankgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgbmlu dGggY29tbWVudHMgdG8gZGlzY3VzcyB0aGUgcG9zc2libGUgaXNzdWVzIHByb3Bvc2VkIGJ5IHRo ZSBpbnRlcm9wZXJhYmlsaXR5IG9mIFNSIHdpdGggTERQLg0KDQoNCg0KSW4gZmFjdCwgSSBoYXZl IG5vdCByZWFkIHRoZSBkcmFmdCBkcmFmdC1maWxzZmlscy1zcHJpbmctc2VnbWVudC1yb3V0aW5n LWxkcC1pbnRlcm9wLTAyIHlldC4gQWNjb3JkaW5nIHRvDQoNCnRoZSBwYXN0IGV4cGVyaWVuY2Us IEkgdGhpbmsgdGhlIHBvc3NpbGJlIGNob2ljZSBpcyBubyBvdGhlciB0aGFuIGhpZXJhcmNoeSBv ciBzdGl0Y2hpbmcuDQoNCkkgcHJvcG9zZSB0aGUgZmlyc3QgY2FzZSBhcyB0aGUgZm9sbG93aW5n IHNjZW5hcmlvLA0KDQoNCg0KICAgICAgICAgIFNSICAgICAgICAgIExEUCAgICAgICAgICBMRFAg ICAgICAgICAgU1INCiAgUzExLS0tLS0tLS0tLS1TMTItLS0tLS0tLS0tUzEzLS0tLS0tLS0tUzE0 LS0tLS0tLS0tUzE1DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgICB8DQogIFMyMS0tLS0tLS0tLS0tUzIyLS0tLS0tLS0tLVMyMy0tLS0tLS0tLVMy NC0tLS0tLS0tLVMyNQ0KDQpBc3N1bWUgYWxsIG90aGVyIG5vZGVzIHN1cHBvcnQgU1IgYW5kIG9u bHkgUzEyL1MxMy9TMTQgc3VwcG9ydCBMRFAuIElmIHRoZSBMU1Agc3RpdGNoaW5nIGlzIGFkb3B0 ZWQsIHRoZXJlIHdpbGwNCg0KYmUgZm9sbG93aW5nIHByb2Nlc3M6DQotLSBJbiBTMTIsIHRoZSBl Z3Jlc3MgU1ItQkUgcGF0aCB3aWxsIHN0aXRjaCB0aGUgaW5ncmVzcyBMRFAgTFNQLCBJZiB0aGUg bGluayBiZXR3ZWVuIHRoZSBTMTIgYW5kIFMxMyBmYWlscw0KDQpmaXJzdGx5LCB0aGVuIHJlc3Rv cmVkLCB0aGUgSUdQLUxEUCBzeW5jIGlzIGFsc28gbmVjZXNzYXJ5Lg0KLS0gSW4gUzE0LCB0aGUg ZWdyZXNzIExEUCBMU1Agd2lsbCBzdGl0Y2ggdGhlIGluZ3Jlc3MgU1ItQkUgcGF0aC4NCg0KDQoN Ck1vcmV2b2VyLCBpZiB0aGUgc2NlbmFyaW8gaXMgY2hhbmdlcyB0byB0aGUgb3Bwb3NpdGUgd2F5 LCB0aGF0IGlzIGFsbCBvdGhlciBub2RlcyBzdXBwb3J0IExEUCBhbmQgb25seSBTMTIvUzEzL1Mx NA0KDQpzdXBwb3J0IFNSLCBpdCBoYXMgdG8gaW50cm9kdWNlIHRoZSBwcm94eSBlZ3Jlc3MgZm9y IFNSLUJFIHBhdGggd2hpY2ggaGFzIGV4cGxhaW5lZCBpbiB0aGUgcHJldmlvdXMgY29tbWVudHMg dGhhdA0KDQppdCB3aWxsIGJlIGRpZmZpY3VsdCB0byBiZSBzdXBwb3J0ZWQgYnkgdGhlIFNSLg0K DQoNCg0KRnJvbSB0aGUgY2FzZSwgY291bGQgSSBzYXkgdGhhdCB0aGUgU1ItTERQIGludGVyb3Bl cmFiaWxpdHkgaXNzdWUgaXMgbW9yZSBkaWZmaWN1bHQgdGhhdCB0aGUgSUdQLUxEUCBzeW5jDQoN CndoaWNoIGNvdWxkIGJlIHJlbW92ZWQgYnkgU1IgYXMgY2xhaW1lZD8NCg0KDQoNCg0KDQpJIHBy b3Bvc2UgdGhlIHNlY29uZCBjYXNlIGFzIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW8sDQoNCg0KDQog ICAgICAgICAgTERQICAgICAgICAgIExEUA0KICBTMTEtLS0tLS0tLS0tLVMxMi0tLS0tLS0tLS1T MTMNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiBTUnwgICAgICAgICAgICAgICAg ICAgICAgICAgIHxTUg0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICBTMjEtLS0t LS0tLS0tLVMyMi0tLS0tLS0tLS1TMjMNCiAgICAgICAgU1IgICAgICAgICAgICAgU1INCg0KDQoN CkFzc3VtZSBTMTEvUzEyL1MxMyBzdXBwb3J0IExEUCBhbmQgUzExL1MyMS9TMjIvUzIzL1MxMyBz dXBwb3J0IFNSLiBJZiB0aGUgcHJpbWFyeSBwYXRoIHRvIFMxMyBpcyBTMTEtPlMxMi0+UzEzDQoN CmlzIGJhc2VkIG9uIExEUCBMU1AuIEluIG9yZGVyIHRvIGFjaGlldmUgdGhlIDEwMCUgbmV0d29y ayBjb3ZlcmFnZSwgTERQIHJlbW90ZSBwZWVyIGNhbiBiZSBzZXQgdXAgYmV0d2VlbiBTMTENCg0K YW5kIFMxMyB0byBhZHZlcnRpc2UgbGFiZWwgbWFwcGluZyBkaXJlY3RseSBmcm9tIHRoZSBTMTMg dG8gUzExLiBUaGUgdGhlIGJhY2t1cCBwYXRoIGNhbiBiZTogdGhlIGJhY2t1cCBMRFANCg0KbGFi ZWwgZ29lcyB0aHJvdWdoIHRoZSBTUiBwYXRoIFMxMS0+UzIxLT5TMjItPlMyMy0+UzEzLiBUaGlz IG1lYW5zIHRoYXQgdGhlIFJlbW90ZSBMRkEgbXVzdCBjby1leGlzdCB3aXRoIFRJLUxGQS4NCg0K Q291bGQgSSBzYXkgdGhhdCB0aGUgY29tYmluZWQgRlJSIHNvbHV0aW9ucyBpcyBtb3JlIGNvbXBs ZXggdGhhbiBvbmUgb2YgdGhlc2UgRlJSIHNvbHV0aW9ucz8NCg0KDQoNCkZyb20gdGhlIHBlcnZp b3VzIGNvbW1lbnRzLCB3ZSBjYW4gc2VlIHRoYXQgc29tZSBvZiB0aGUgZXhpc3RpbmcgTERQIHNj ZW5hcmlvcyBjYW5ub3QgYmUgc3VwcG9ydGVkIGJ5IFNSLUJFIHBhdGguDQoNClRoaXMgbWVhbnMg aWYgU1IgaXMgYWRvcHRlZCwgaXQgaGFzIHRvIGNvLWV4aXN0IHdpdGggTERQIGluIHRoZXNlIHNj ZW5hcmlvcy4gRm9yIHRoZSBsZWdhY3kgbmV0d29yayB1c2luZyBMRFAsDQoNCmlmIFNSIGlzIGFk b3B0ZWQgdG8gcmVwbGFjZSB0aGUgTERQLCBpdCBpcyBhbHNvIGluZXZpdGFibGUgdGhhdCB0aGUg U1IgaGFzIHRvIGNvLWV4aXN0IHdpdGggTERQLg0KDQoNCg0KSWYgdGhlc2Ugc2NlbmFyaW9zIGhh cHBlbnMsIHRoZXJlIHdpbGwgYmUgYSBtZXNzIG9mIHNvbHV0aW9ucyBpbiB0aGUgbmV0d29yay4g SW4gZmFjdCwgdGhpcyBpcyBub3QgYSBuZXcgb25lLg0KDQpBbG1vc3QgdGVuIHllYXJzIGFnbywg d2hlbiB3ZSBpbXBsZW1lbnRlZCB0aGUgTERQLCB3ZSBhc3N1bWVkIHRoYXQgdGhlcmUgY2FuIGJl IG9uZSBuZXR3b3JrIGluIHdoaWNoIHNvbWUgbm9kZXMNCg0KcnVuIExEUCBEb0QsIG90aGVycyBy dW4gTERQIERVLCBzb21lIG5vZGVzIHJ1biBMRFAgT3JkZXJlZCwgb3RoZXJzIHJ1biBMRFAgSW5k ZXBlbmRlbnQsIHNvbWUgbm9kZXMgcnVuIExEUCBsaWJlcmFsLA0KDQpvdGhlcnMgcnVuIExEUCBj b25zZXJ2YXRpdmUuIEZpbmFsbHkgd2UgZm91bmQgdGhlIGlzc3VlcyBjb3VsZCBub3QgY29udmVy Z2UgYXQgYWxsLiBBdCBsYXN0IHdlIGhhZCB0byBnaXZlIHVwDQoNCmFuZCBwcm92aWRlZCB0aGUg c3BlY2lmaWNhdGlvbiBmb3IgYW55IG5ldHdvcmsgdGhlcmUgaXMgb25seSBvbmUgbGFiZWwgYWR2 ZXJ0aXNlbWVudCBtb2RlLCBvbmx5IG9uZSBsYWJlbA0KDQpkaXN0cmlidXRpb24gbW9kZSwgb25s eSBvbmUgbGFiZWwgcmV0ZW50aW9uIG1vZGUuIFVudGlsIHRvZGF5IERVICsgT3JkZXJlZCArIExp YmVyYWwgYmVjb21lcyBhbG1vc3QgdGhlIG1vc3QNCg0KcG9wdWxhciBjaG9pY2UuDQoNCg0KDQpC dXQgZm9yIFNSLCBpdCB3b3JrcyBpbiB0aGUgdG90YWxseSBkaWZmZXJlbnQgd2F5IGZyb20gdGhl IExEUCBpbiBtYW55IGFzcGVjdHMuIElmIFNSIGFuZCBMRFAgY28tZXhpc3QgaW4gb25lDQoNCm5l dHdvcmsgYW5kIHRoZSBiZWhhdmlvcnMgY291bGQgbm90IGJlIHVuaWZ5ZWQgdGhyb3VnaCB0aGUg dW5pZnlpbmcgY29uZmlndXJhdGlvbiwgdGhlIG1lc3Mgb2YgdGhlIHNvbHV0aW9ucw0KDQppcyBp bmV2aXRhYmxlLiBUYWtpbmcgaW50byBhY2NvdW50IFNSJ3MgaW50ZXJ3b3JraW5nIHdpdGggTERQ J3MgdHdvIExTUCBhZHZlcnRpc2VtZW50IG1vZGUsIHR3byBMU1AgZGlzdHJpYnV0aW9uDQoNCm1v ZGUsIHR3byBsYWJlbCByZXRlbnNpb24gbW9kZSwgdHdvIHR5cGVzIG9mIExEUCBwZWVyIGFzIHdl bGwgYXMgbmV3IElHUC1MRFAgc3RpY2hpbmcvaGllcmFyY2h5L3N5bmMgYW5kIHRoZQ0KDQppbnR3 b3JraW5nIExGQS9SLUxGQSBGUlIgZm9yIExEUCB3aXRoIHRoZSBUSS1MRkEgZm9yIFNSLCBJIGRv bid0IHRoaW5rIHRoaXMgaXMgYW4gZWFzeSB3b3JrIHRvIGNsYXJpZnkgYWxsDQoNCnBvc3NpYmxl IGRldGFpbHMgaW4gb25lIGRyYWZ0IGFuZCBtdWNoIG9mIHRoZSBkZXRhaWxzIG1heWJlIGltcGxl bWVudGF0aW9uIHNwZWNpZmljIGFuZCBwb3RlbnRpYWwgcmlzayBmb3IgdGhlDQppbnRlcm9wZXJh YmlsaXR5LiBNb3Jlb3ZlciwgYmFzZWQgb24gdGhlIGFuYWx5c2lzIGluIHRoZSBwcmV2aW91cyBj b21tZW50cywgdGhlcmUgaXMgc29tZSByZXF1aXJlbWVudHMgb2YgTERQDQoNCndoaWNoIGNhbm5v dCBiZSBzdXBwb3J0ZWQgYnkgU1ItQkUgcGF0aCB5ZXQgbm93LiBJZiB0aGVzZSBpc3N1ZXMgYXJl IG5vdCBzb2x2ZWQsIHRoZSBpbnRyb2R1Y2luZyBvZiBTUiBpbiB0aGUNCg0KTERQIG5ldHdvcmsg d2lsbCBhZmZlY3QgdGhlIG5vcm1hbCBwcm9jZXNzIG9mIExEUC4NCg0KDQoNCkFjY29yZGluZyB0 byB0aGUgYWJvdmUgYW5hbHlpc2lzLCBteSByZWNvbW1lbmRhdGlvbiBmb3IgdGhlIG5ldHdvcmsg dHJhbnNpdGlvbiBpcyB0aGF0IGlmIHRoZXJlIGlzIHRoZSBzY2VuYXJpbw0KDQppbiB3aGljaCBT Ui1CRSBwYXRoIGlzIHRydWx5IGFwcGxpY2FibGUsIGl0IGlzIGJldHRlciB0byByZXBsYWNlIHRo ZSBleGlzdGluZyBMRFAgYWxsIGF0IG9uY2UgdG8gYXZvaWQgdGhlIHBvc3NpYmxlDQoNCmludGVy b3BlcmFiaWxpdHkgaXNzdWUuDQoNCg0KDQpSZWdhcmRpbmcgdGhlIGludGVyb3BlcmFiaWxpdHkg b2YgU1ItVEUgcGF0aCB3aXRoIFJTVlAtVEUsIHRoZSBnZW5lcmFsIHByb2JsZW0gaXMgdGhhdCBi b3RoIFNSLVRFIHBhdGggYW5kIFJTVlAtVEUNCg0KY2Fubm90IHN1cHBvcnQgcHJveHkgZWdyZXNz IG5vdyBhbmQgdGhlIHN0aXRjaGluZyB3b3VsZCBub3Qgd29yayBhdCBhbGwuIFRoZSBvbmx5IHdh eSBpcyBqdXN0IHRvIHJlcGxhY2UgdGhlIHdob2xlDQoNClJTVlAtVEUgTFNQIHdpdGggdGhlIFNS LVRFIHBhdGggaWYgdGhlIFNSLVRFIHBhdGggaXMgdHJ1bHkgYXBwbGljYWJsZS4NCg0KDQoNCg0K DQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6Ankgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the ninth comments to discuss the possibl= e issues proposed by the interoperability of SR with LDP.

 

In fact, I have not read the draft draft-filsfils= -spring-segment-routing-ldp-interop-02 yet. According to

the past experience, I think the possilbe choice = is no other than hierarchy or stitching.


I propose the first case as the following scenario,<= /font>

 

        &= nbsp; SR          LDP &nb= sp;        LDP    &n= bsp;     SR
  S11-----------S12----------S13---------S14---------S15
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  S21-----------S22----------S23---------S24---------S25

Assume all other nodes support SR and o= nly S12/S13/S14 support LDP. If the LSP stitching is adopted, there will

be following process:
-- In S12, the egress SR-BE path will stitch the ingress LDP LSP, If the li= nk between the S12 and S13 fails

firstly, then restored, the IGP-LDP sync is = also necessary.
-- In S14, the egress LDP LSP will stitch the ingress SR-BE path.

 

Morevoer, if the scenario is changes to the oppos= ite way, that is all other nodes support LDP and only S12/S13/= S14

support SR, it has to introduce the proxy egress = for SR-BE path which has explained in the previous comments that <= /font>

it will be difficult to be supported by the SR.

 

From the case, could I say that the SR-LDP intero= perability issue is more difficult that the IGP-LDP sync

which could be removed by SR as claimed? <= /p>

 

 


I propose the second case as the following scenario,=

 

        &= nbsp; LDP          LDP &n= bsp;   
  S11-----------S12----------S13
   |          &= nbsp;           &nbs= p;   |
 SR|           =             &nb= sp;  |SR
   |          &= nbsp;           &nbs= p;   |
  S21-----------S22----------S23
        SR     =         SR

 

Assume S11/S12/S13 support LDP and S11/S21/S22/S2= 3/S13 support SR. If the primary path to S13 is S11->S12->S13

is based on LDP LSP. In order to achieve the 100%= network coverage, LDP remote peer can be set up between S11

and S13 to advertise label mapping directly from = the S13 to S11. The the backup path can be: the backup LDP

label goes through the SR path S11->S21->S2= 2->S23->S13. This means that the Remote LFA must co-exist with TI-LFA= .

Could I say that the combined FRR solutions is mo= re complex than one of these FRR solutions?

 

From the pervious comments, we can see that some = of the existing LDP scenarios cannot be supported by SR-BE path.

This means if SR is adopted, it has to co-exist w= ith LDP in these scenarios. For the legacy network using LDP,

if SR is adopted to replace the LDP, it is also i= nevitable that the SR has to co-exist with LDP.

 

If these scenarios happens, there will be a mess = of solutions in the network. In fact, this is not a new one.

Almost ten years ago, when we implemented the LDP= , we assumed that there can be one network in which some nodes

run LDP DoD, others run LDP DU, some nodes run LD= P Ordered, others run LDP Independent, some nodes run LDP liberal,

others run LDP conservative. Finally we found the= issues could not converge at all. At last we had to give up

and provided the specification for any network th= ere is only one label advertisement mode, only one label

distribution mode, only one label retention mode.= Until today DU + Ordered + Liberal becomes almost the most

popular choice.

 

But for SR, it works in the totally dif= ferent way from the LDP in many aspects. If SR and LDP co-exist in one

network and the behaviors could not be unifyed th= rough the unifying configuration, the mess of the solutions

is inevitable. Taking into account SR's interwork= ing with LDP's two LSP advertisement mode, two LSP distribution

mode, two label retension mode, two types of LDP = peer as well as new IGP-LDP stiching/hierarchy/sync and the

intworking LFA/R-LFA FRR for LDP with the TI-LFA = for SR, I don't think this is an easy work to clarify all

possible details in one draft and much of the det= ails maybe implementation specific and potential risk for the
interoperability. Moreover, based on the analysis in the previous comments,= there is some requirements of LDP

which cannot be supported by SR-BE path yet now. = If these issues are not solved, the introducing of SR in the

LDP network will affect the normal process of LDP= .

 

According to the above analyisis, my recommendati= on for the network transition is that if there is the scenario

in which SR-BE path is truly applicable, it is be= tter to replace the existing LDP all at once to avoid the possible

interoperability issue.

 

Regarding the interoperability of SR-TE path with= RSVP-TE, the general problem is that both SR-TE path and RSVP-TE

cannot support proxy egress now and the stitching= would not work at all. The only way is just to replace the whole

RSVP-TE LSP with the SR-TE path if the SR-TE path= is truly applicable.

 

 

 

Regards,

Robin

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6Ankgeml506mbxchi_-- From nobody Thu Jan 29 03:32:55 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DC11A0204 for ; Thu, 29 Jan 2015 03:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C47AE_X8if7x for ; Thu, 29 Jan 2015 03:32:50 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FED1A0203 for ; Thu, 29 Jan 2015 03:32:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4DB4FBE47; Thu, 29 Jan 2015 11:33:21 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1Cc_z8OutVG; Thu, 29 Jan 2015 11:33:20 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.18.232]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB2E6BE35; Thu, 29 Jan 2015 11:33:19 +0000 (GMT) Message-ID: <54CA1A5D.3050801@cs.tcd.ie> Date: Thu, 29 Jan 2015 11:32:45 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Uma Chunduri , "adrian@olddog.co.uk" , "mpls@ietf.org" References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se> <065a01d02a99$71490c80$53db2580$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F55CF65@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F55CF65@eusaamb105.ericsson.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 11:32:52 -0000 On 29/01/15 04:03, Uma Chunduri wrote: > But the important point here is - packet is getting encrypted and decrypted > multiple times; Sorry, but that is not the case. The packet is encrypted once and decrypted once when following this specification. And the packet can traverse LSRs whilst encrypted without those having to decrypt and then re-encrypt. The entire e2e path of a packet may cause it to traverse more than one encrypt/decrypt but that is as true for IPsec as it is for this. That is, one can arrange that the endpoints of cryptographic protection are wherever you want. S. From nobody Thu Jan 29 10:10:41 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676421A1BC3; Thu, 29 Jan 2015 10:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuGc-OlP9hJI; Thu, 29 Jan 2015 10:10:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C043B1A1BB0; Thu, 29 Jan 2015 10:10:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129181035.22698.73757.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 10:10:35 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-proxy-lsp-ping-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 18:10:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Proxy MPLS Echo Request Authors : George Swallow Vanson Lim Sam Aldrin Filename : draft-ietf-mpls-proxy-lsp-ping-03.txt Pages : 24 Date : 2015-01-29 Abstract: This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. A MPLS proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/root tracing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-proxy-lsp-ping-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-proxy-lsp-ping-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 29 11:40:51 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0961A6FF5; Thu, 29 Jan 2015 11:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbbRkzP9hxc1; Thu, 29 Jan 2015 11:40:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8121A049A; Thu, 29 Jan 2015 11:40:38 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150129194038.5769.49401.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 11:40:38 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] Last Call: (Proxy MPLS Echo Request) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 19:40:42 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proxy MPLS Echo Request' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. A MPLS proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/root tracing. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/778/ http://datatracker.ietf.org/ipr/2164/ http://datatracker.ietf.org/ipr/2087/ From nobody Thu Jan 29 17:42:04 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1E21A88D6 for ; Thu, 29 Jan 2015 17:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSkhwRSu0_Ge for ; Thu, 29 Jan 2015 17:42:00 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2121A88CF for ; Thu, 29 Jan 2015 17:42:00 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-d6-54ca824006bc Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 36.03.25146.0428AC45; Thu, 29 Jan 2015 19:56:00 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 20:41:58 -0500 From: Uma Chunduri To: Stephen Farrell , "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt Thread-Index: AQJzvBS/xUxOeeIyvKQcjxJu+FS4g5tkJK6AgABd/QCAADiAgIAAFPfggAEzewCAAC4IgIAGNx+wgAGluwCAIVq8UIAA4QeAgACXeLA= Date: Fri, 30 Jan 2015 01:41:57 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F55D6B7@eusaamb105.ericsson.se> References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se> <065a01d02a99$71490c80$53db2580$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F55CF65@eusaamb105.ericsson.se> <54CA1A5D.3050801@cs.tcd.ie> In-Reply-To: <54CA1A5D.3050801@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F55D6B7eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXSPt65D06kQgxdfTCx+9Nxgtri1dCWr xfS919gdmD3Wdl9l81iy5CeTx4rNKxkDmKO4bFJSczLLUov07RK4Mg4f7GIq2OZXcXTHFOYG xgU+XYycHBICJhLNzR+ZIGwxiQv31rN1MXJxCAkcYZQ4e/gtK4SznFFiafNLNpAqNgE9iY9T f7KD2CIC9RKfjrcwgtjCAukSC9bPZIOIZ0isXvKMBcIuk+j7vgqsnkVAVeLA/0awel4BX4mj Ox5DLWhklXhy/gVQgoODU0BT4sGZBJAaRqCLvp9aA3Yds4C4xK0n86EuFZBYsuc8M4QtKvHy 8T9WCFtJYtLSc6wQ9fkSny61MkHsEpQ4OfMJywRGkVlIRs1CUjYLSdksoCuYga5Yv0sfokRR Ykr3Q3YIW0Oidc5cdmTxBYzsqxg5SotTy3LTjQw3MQIj6pgEm+MOxgWfLA8xCnAwKvHwbjA8 GSLEmlhWXJl7iFGag0VJnLfsysEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYy5rM8ve93X dTDnqKlW0X5mHdgS77vX1aGTx/n7tvNTF/WZnZx2OuBkmZRnhOyvmKbd9syv9+epB/b1LLLx 7jXe2iYSf3Wa5srpqbZmkUdrG9oLyt76/Ni5+YfD2xuS37TL2OZM2ba2qolxrZHV9560Ax/P eTRN+xWnOqvqsvTNTrONN8ry4pRYijMSDbWYi4oTAd1BXKeJAgAA Archived-At: Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 01:42:03 -0000 --_000_1B502206DFA0C544B7A60469152008633F55D6B7eusaamb105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlcGhlbiwNCg0KSW4tbGluZSBbVW1hXToNCg0KLS0NClVtYSBDLg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVu LmZhcnJlbGxAY3MudGNkLmllXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjksIDIwMTUgMzoz MyBBTQ0KVG86IFVtYSBDaHVuZHVyaTsgYWRyaWFuQG9sZGRvZy5jby51azsgbXBsc0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFttcGxzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1mYXJyZWxsbC1tcGxzLW9wcG9ydHVuaXN0aWMtZW5jcnlwdC0wNC50eHQNCg0KDQoNCk9u IDI5LzAxLzE1IDA0OjAzLCBVbWEgQ2h1bmR1cmkgd3JvdGU6DQo+ICBCdXQgdGhlIGltcG9ydGFu dCBwb2ludCBoZXJlIGlzIC0gcGFja2V0IGlzIGdldHRpbmcgZW5jcnlwdGVkIGFuZCBkZWNyeXB0 ZWQNCj4gICAgICAgICAgICAgICAgbXVsdGlwbGUgdGltZXM7DQoNClNvcnJ5LCBidXQgdGhhdCBp cyBub3QgdGhlIGNhc2UuIFRoZSBwYWNrZXQgaXMgZW5jcnlwdGVkIG9uY2UgYW5kIGRlY3J5cHRl ZCBvbmNlIHdoZW4gZm9sbG93aW5nIHRoaXMgc3BlY2lmaWNhdGlvbi4gQW5kIHRoZSBwYWNrZXQg Y2FuIHRyYXZlcnNlIExTUnMgd2hpbHN0IGVuY3J5cHRlZCB3aXRob3V0IHRob3NlIGhhdmluZyB0 byBkZWNyeXB0IGFuZCB0aGVuIHJlLWVuY3J5cHQuDQoNCltVbWFdOiBJIGFtIHN1cmUgdGhlbiB0 aGVyZSBpcyBzb21lIGdhcCAoaW4gbXkgdW5kZXJzdGFuZGluZyBwZXJoYXBzPz8pLCBidXQgZnJv bSB0aGUgZHJhZnQgSSBjbGVhcmx5IHNlZSB0aGlzLQ0KDQpGcm9tIFNlY3Rpb24gMzoNCg0KICAg ICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLSAuICAgICAgLS0tLS0tLS0tLS0NCiAgICAgICAg ICAgICAgICAgICB8IFRvcCBMYWJlbCB8IC4gICAgfCBMYWJlbCAxNSAgfA0KICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLSsgIC4gICArLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAg ICAgfCAgIExhYmVsICAgfCAgIC4gIHwgTUVMICAgUz0xIHwNCiAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0rICAgIC4gKy0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgIHwgTGFi ZWwgUz0xIHwgICAgIC58IEN0cmwgV29yZCB8DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tKyAgICAgICstLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgfCAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgIH4gIFBheWxvYWQgIH4gICAg ICB+IEVuY3J5cHRlZCB+DQogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgIHwg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0uLi4uLi4uLi0tLS0t LS0tLS0tDQoNCiAgICAgICAgRmlndXJlIDEgOiBUaGUgVXNlIG9mIHRoZSBNRUwgZm9yIEhvcC1i eS1Ib3AgRW5jcnlwdGlvbg0KDQoNCkVhY2ggTFNSIGhhcyB0byBkZWNyeXB0IGZpcnN0IHRvIGdl dCB0aGUgdG9wIGxhYmVsIGFuZCBhdCB0aGUgZWdyZXNzIHN3YXAgaXQgd2l0aG91dCBsYWJlbCBl bmNyeXB0IHdpdGgga2V5cyBmb3IgdGhlIG5laWdoYm9yLCBwdXQgTUVMIGFuZCBzZW5kIG91dCwg cmlnaHQ/IEFuZCB0aGUgc2FtZSBzaG91bGQgaGFwcGVuIGF0IGVhY2ggTFNSLi5pc27igJl0IGl0 Pz8NCg0KDQoNClRoZSBlbnRpcmUgZTJlIHBhdGggb2YgYSBwYWNrZXQgbWF5IGNhdXNlIGl0IHRv IHRyYXZlcnNlIG1vcmUgdGhhbiBvbmUgZW5jcnlwdC9kZWNyeXB0IGJ1dCB0aGF0IGlzIGFzIHRy dWUgZm9yIElQc2VjIGFzIGl0IGlzIGZvciB0aGlzLiBUaGF0IGlzLCBvbmUgY2FuIGFycmFuZ2Ug dGhhdCB0aGUgZW5kcG9pbnRzIG9mIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbiBhcmUgd2hlcmV2 ZXIgeW91IHdhbnQuDQoNClMuDQoNCg== --_000_1B502206DFA0C544B7A60469152008633F55D6B7eusaamb105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SGkgU3RlcGhlbiw8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PkluLWxpbmUgW1VtYV06PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRp dj4tLTwvZGl2Pg0KPGRpdj5VbWEgQy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCg0KRnJvbTog U3RlcGhlbiBGYXJyZWxsIFs8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZSI+bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+XQ0KPGJyPg0KDQpTZW50OiBU aHVyc2RheSwgSmFudWFyeSAyOSwgMjAxNSAzOjMzIEFNPGJyPg0KDQpUbzogVW1hIENodW5kdXJp OyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBtcGxzQGlldGYub3JnPGJyPg0KDQpTdWJqZWN0OiBSZTog W21wbHNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZhcnJlbGxsLW1w bHMtb3Bwb3J0dW5pc3RpYy1lbmNyeXB0LTA0LnR4dDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5PbiAyOS8wMS8xNSAw NDowMywgVW1hIENodW5kdXJpIHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IEJ1dCB0aGUg aW1wb3J0YW50IHBvaW50IGhlcmUgaXMgLSBwYWNrZXQgaXMgZ2V0dGluZyBlbmNyeXB0ZWQgYW5k IGRlY3J5cHRlZCA8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBtdWx0aXBsZSB0aW1lczs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlNvcnJ5 LCBidXQgdGhhdCBpcyBub3QgdGhlIGNhc2UuIFRoZSBwYWNrZXQgaXMgZW5jcnlwdGVkIG9uY2Ug YW5kIGRlY3J5cHRlZCBvbmNlIHdoZW4gZm9sbG93aW5nIHRoaXMgc3BlY2lmaWNhdGlvbi4gQW5k IHRoZSBwYWNrZXQgY2FuIHRyYXZlcnNlIExTUnMgd2hpbHN0IGVuY3J5cHRlZCB3aXRob3V0IHRo b3NlIGhhdmluZyB0byBkZWNyeXB0IGFuZCB0aGVuIHJlLWVuY3J5cHQuPC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj5bVW1hXTogSSBhbSBzdXJlIHRoZW4gdGhlcmUgaXMgc29tZSBnYXAg KGluIG15IHVuZGVyc3RhbmRpbmcgcGVyaGFwcz8/KSwgYnV0IGZyb20gdGhlIGRyYWZ0IEkgY2xl YXJseSBzZWUgdGhpcy08L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkZyb20gU2VjdGlv biAzOjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBO ZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLS0tLS0tLS0tLSAuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0t LS0tPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgVG9wIExhYmVsIHwg LiZuYnNwOyZuYnNwOyZuYnNwOyB8IExhYmVsIDE1Jm5ic3A7IHw8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7Jm5ic3A7IC4mbmJzcDsm bmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgTGFiZWwmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAu Jm5ic3A7IHwgTUVMJm5ic3A7Jm5ic3A7IFM9MSB8PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyAuICYj NDM7LS0tLS0tLS0tLS0mIzQzOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8IExhYmVsIFM9MSB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC58IEN0cmwgV29yZCB8PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0mIzQz OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291 cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB+Jm5ic3A7IFBheWxvYWQmbmJzcDsgfiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB+IEVuY3J5cHRlZCB+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0uLi4uLi4uLi0tLS0tLS0t LS0tPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSAxIDogVGhlIFVzZSBvZiB0aGUgTUVM IGZvciBIb3AtYnktSG9wIEVuY3J5cHRpb248L2ZvbnQ+PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPkVhY2gg TFNSIGhhcyB0byBkZWNyeXB0IGZpcnN0IHRvIGdldCB0aGUgdG9wIGxhYmVsIGFuZCBhdCB0aGUg ZWdyZXNzIHN3YXAgaXQgd2l0aG91dCBsYWJlbCBlbmNyeXB0IHdpdGgga2V5cyBmb3IgdGhlIG5l aWdoYm9yLCBwdXQgTUVMIGFuZCBzZW5kIG91dCwgcmlnaHQ/IEFuZCB0aGUgc2FtZSBzaG91bGQg aGFwcGVuIGF0IGVhY2ggTFNSLi5pc27igJl0IGl0Pz88L2ZvbnQ+PC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoZSBl bnRpcmUgZTJlIHBhdGggb2YgYSBwYWNrZXQgbWF5IGNhdXNlIGl0IHRvIHRyYXZlcnNlIG1vcmUg dGhhbiBvbmUgZW5jcnlwdC9kZWNyeXB0IGJ1dCB0aGF0IGlzIGFzIHRydWUgZm9yIElQc2VjIGFz IGl0IGlzIGZvciB0aGlzLiBUaGF0IGlzLCBvbmUgY2FuIGFycmFuZ2UgdGhhdCB0aGUgZW5kcG9p bnRzIG9mIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbiBhcmUgd2hlcmV2ZXIgeW91IHdhbnQuPC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5TLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N Cjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1B502206DFA0C544B7A60469152008633F55D6B7eusaamb105erics_-- From nobody Thu Jan 29 20:28:53 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6523B1A8952 for ; Thu, 29 Jan 2015 20:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL1mtWM7brDI for ; Thu, 29 Jan 2015 20:28:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C76E01A8954 for ; Thu, 29 Jan 2015 20:28:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130042845.16572.52260.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 20:28:45 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 04:28:48 -0000 Changed milestone "Submit draft-ietf-mpls-proxy-lsp-ping fpr publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu Jan 29 20:32:42 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344851A8951 for ; Thu, 29 Jan 2015 20:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRJkTM4gnJb4 for ; Thu, 29 Jan 2015 20:32:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C62E1A8952 for ; Thu, 29 Jan 2015 20:32:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130043239.16590.66580.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 20:32:39 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 04:32:41 -0000 Changed milestone "** Progress draft-ietf-mpls-pim-sm-over-mldp to publication", added draft-ietf-mpls-pim-sm-over-mldp to milestone. Changed milestone "++ Progress draft-ietf-mpls-proxy-lsp-ping to publication", added draft-ietf-mpls-proxy-lsp-ping to milestone. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Jan 30 00:01:45 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED31A89AC for ; Fri, 30 Jan 2015 00:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-nv5R-M2XbN for ; Fri, 30 Jan 2015 00:01:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8992D1A89AE for ; Fri, 30 Jan 2015 00:01:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130080140.15566.31597.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 00:01:40 -0800 From: IETF Secretariat Archived-At: Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 08:01:43 -0000 Changed milestone "++ Progress draft-ietf-mpls-proxy-lsp-ping to publication", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Jan 30 03:33:56 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2051A8BC3 for ; Fri, 30 Jan 2015 03:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZLBvJEGjboc for ; Fri, 30 Jan 2015 03:33:53 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A08B1A8BB5 for ; Fri, 30 Jan 2015 03:33:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 34F73BE8B; Fri, 30 Jan 2015 11:34:24 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukc3SnAxGvMf; Fri, 30 Jan 2015 11:34:24 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D80FBE88; Fri, 30 Jan 2015 11:34:24 +0000 (GMT) Message-ID: <54CB6C20.7030907@cs.tcd.ie> Date: Fri, 30 Jan 2015 11:33:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Uma Chunduri , "adrian@olddog.co.uk" , "mpls@ietf.org" References: <20150101142218.19294.18617.idtracker@ietfa.amsl.com> <006801d025cf$13a93a60$3afbaf20$@olddog.co.uk>, <54A560C2.9050803@cs.tcd.ie>, , <009501d026ab$004724f0$00d56ed0$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F51B22F@eusaamb105.ericsson.se> <065a01d02a99$71490c80$53db2580$@olddog.co.uk> <1B502206DFA0C544B7A60469152008633F55CF65@eusaamb105.ericsson.se> <54CA1A5D.3050801@cs.tcd.ie> <1B502206DFA0C544B7A60469152008633F55D6B7@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F55D6B7@eusaamb105.ericsson.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 11:33:55 -0000 Hiya, On 30/01/15 01:41, Uma Chunduri wrote: > Hi Stephen, > > In-line [Uma]: > > -- > Uma C. > > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, January 29, 2015 3:33 AM > To: Uma Chunduri; adrian@olddog.co.uk; mpls@ietf.org > Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt > > > > On 29/01/15 04:03, Uma Chunduri wrote: >> But the important point here is - packet is getting encrypted and decrypted >> multiple times; > > Sorry, but that is not the case. The packet is encrypted once and decrypted once when following this specification. And the packet can traverse LSRs whilst encrypted without those having to decrypt and then re-encrypt. > > [Uma]: I am sure then there is some gap (in my understanding perhaps??), but from the draft I clearly see this- > > From Section 3: > > ----------- . ----------- > | Top Label | . | Label 15 | > +-----------+ . +-----------+ > | Label | . | MEL S=1 | > +-----------+ . +-----------+ > | Label S=1 | .| Ctrl Word | > +-----------+ +-----------+ > | | | | > ~ Payload ~ ~ Encrypted ~ > | | | | > -----------........----------- > > Figure 1 : The Use of the MEL for Hop-by-Hop Encryption > > > Each LSR has to decrypt first to get the top label and at the egress swap it without label encrypt with keys for the neighbor, put MEL and send out, right? And the same should happen at each LSR..isn’t it?? > I'm afraid not. Figure 1 is about hop-by-hop (as it says in the Figure caption copied above). There is only one hop and hence no repeated en/decryption. And (if we look down the page a few centimeters:-) we also have Figure 2: ----------- ----------- | Top Label | | Top Label | +-----------+ +-----------+ | Label | | Label | +-----------+. +-----------+ | Label | . | Label 15 | +-----------+ . +-----------+ | Label | . | MEL S=1 | +-----------+ . +-----------+ | Label S=1 | .| Ctrl Word | +-----------+ +-----------+ | | | | ~ Payload ~ ~ Encrypted ~ | | | | -----------........----------- Figure 2 : The Use of the MEL for End-to-End Encryption Which I think makes things quite clear - the top label is present in clear as required. It just would not make any sense (and it simply wouldn't work) for this specification to require such repeated en/decryptions of the same payload. If there is any text that implies one does that, then that text needs fixing and I'd be delighted to see OLD/NEW form corrections offered. But I do not see any such text to be honest. Cheers, S. > > The entire e2e path of a packet may cause it to traverse more than one encrypt/decrypt but that is as true for IPsec as it is for this. That is, one can arrange that the endpoints of cryptographic protection are wherever you want. > > S. > From nobody Fri Jan 30 09:01:03 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191161A037F for ; Fri, 30 Jan 2015 09:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNFCKEVPSyxY for ; Fri, 30 Jan 2015 09:01:00 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3421A1B2E for ; Fri, 30 Jan 2015 09:00:58 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 30 Jan 2015 17:00:36 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0075.002; Fri, 30 Jan 2015 17:00:36 +0000 From: Ross Callon To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 Thread-Index: AQHQPK5EL/wTreaM+UuOx72+Nl/Gkw== Date: Fri, 30 Jan 2015 17:00:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BY1PR0501MB1430; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1430; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51444003)(164054003)(2656002)(122556002)(87936001)(2501002)(86362001)(19609705001)(19300405004)(40100003)(106116001)(66066001)(16236675004)(19580405001)(77156002)(19580395003)(62966003)(92566002)(19625215002)(76176999)(50986999)(46102003)(18717965001)(54356999)(15975445007)(74316001)(102836002)(33656002)(230783001)(54606007)(2950100001)(2900100001)(54206007)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1430; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB14307184E781220FEB2E49A3A5310BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2015 17:00:36.1749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1430 Archived-At: Cc: "" , "draft-ietf-mpls-lsp-ping-registry@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-registry-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 17:01:02 -0000 --_000_BY1PR0501MB14307184E781220FEB2E49A3A5310BY1PR0501MB1430_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This working group last call has ended with sufficient support and no oppos= ition. I will continue with the publication process. There were editorial comments from Julien, but I think that these are minor= enough that we can fix them along with any AD and/or IETF last call commen= ts received during the publication process. Thanks, Ross From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, January 14, 2015 11:31 PM To: mpls@ietf.org Cc: ; draft-ietf-mpls-lsp-ping-registry@tools.i= etf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-regist= ry-00 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-lsp-ping-registry-00. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have stated on the working group mailing list that they are not aware of any IPR that relates to this draft. This working group last call ends January 29, 2015. Ross for the MPLS wg chairs --_000_BY1PR0501MB14307184E781220FEB2E49A3A5310BY1PR0501MB1430_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This working group last c= all has ended with sufficient support and no opposition. I will continue wi= th the publication process.

 <= /p>

There were editorial comm= ents from Julien, but I think that these are minor enough that we can fix t= hem along with any AD and/or IETF last call comments received during the publication process.

 <= /p>

Thanks, Ross

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, January 14, 2015 11:31 PM
To: mpls@ietf.org
Cc: <mpls-chairs@tools.ietf.org>; draft-ietf-mpls-lsp-ping-reg= istry@tools.ietf.org
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping= -registry-00

 

Working Group,

 

This is to initiate a two week working = group last call on

draft-ietf-mpls-lsp-ping-registry-00.

 

Please send your comments to the mpls w= g mailing list (mpls@ietf.org).

 

There are no IPR disclosures against th= is document. All the authors have

stated on the working group mailing lis= t that they are not aware of any

IPR that relates to this draft.

 

This working group last call ends Janua= ry 29, 2015. 

 

Ross

for the MPLS wg chairs

 

--_000_BY1PR0501MB14307184E781220FEB2E49A3A5310BY1PR0501MB1430_-- From nobody Fri Jan 30 21:04:35 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F60F1A8872 for ; Fri, 30 Jan 2015 21:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyNybQAPUD7e for ; Fri, 30 Jan 2015 21:04:29 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7531A1B1B for ; Fri, 30 Jan 2015 21:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8228; q=dns/txt; s=iport; t=1422680670; x=1423890270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KBCBOkBchYL2we8yZ3uPbtHfQmpl8Ekie8RkRxpO/v4=; b=W75eQQwzvj8qbb8CUotKxecYHvHtNxEmA6UY4RVtnCZuhbb4A+DVW16S BU12YbYSnkj2C6XTrFsJrPskdEab6MZ4+rNK9/dEZo56hUUC2X/z2Q/Yx clY0ArR4aDJBYB+ij8kjDplQg/MEHmpHzXR/XhHNpWg3Qo1mF7d6ocYbY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BeBQDXYcxU/4sNJK1bgwZSWQSCfcFjCoVxAhx6QwEBAQEBfYQNAQEEAQEBIAQNNwMLDgICAQgOCgICJgICAhkMCxUQAgQBDQWILA29XpVhAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEgR2NdREBHRgbB4JogUEFjwGFW4NKgReDA4gIgnyDPSKDbm+BCzl+AQEB X-IronPort-AV: E=Sophos;i="5.09,495,1418083200"; d="scan'208";a="119252738" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 31 Jan 2015 05:04:29 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0V54S6i019140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 31 Jan 2015 05:04:28 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.210]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 30 Jan 2015 23:04:28 -0600 From: "Tarek Saad (tsaad)" To: Santosh Esale , "mpls@ietf.org" Thread-Topic: [mpls] MPLS-RT review of draft-esale-mpls-app-aware-tldp Thread-Index: AQHQKVLhLdk1xXgDvkqFOfkFmFRZfZzZ5OGA Date: Sat, 31 Jan 2015 05:04:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.86.250.225] Content-Type: text/plain; charset="utf-8" Content-ID: <5D9097CAF4BFC34D8A0A6E6F85F225A2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Lizhong Jin Subject: Re: [mpls] MPLS-RT review of draft-esale-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 05:04:32 -0000 VGhhbmtzIFNhbnRvc2guIEkgYW0gT0sgd2l0aCB0aGUgcmV2aXNlZCBjaGFuZ2VzLg0KDQpSZWdh cmRzLA0KVGFyZWsNCg0KT24gMjAxNS0wMS0wNiwgNzo1OSBQTSwgIlNhbnRvc2ggRXNhbGUiIDxz ZXNhbGVAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+SGkgVGFyZWssDQo+ICAgICAgICBUaGFuayB5 b3UgZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRzLg0KPg0KPlBsZWFzZSBmaW5kIHNvbWUgcmVz cG9uc2VzIGlubGluZS4NCj5PbiAxMi84LzE0LCAxMDoxNCBQTSwgIlRhcmVrIFNhYWQgKHRzYWFk KSIgPHRzYWFkQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+PkhpLA0KPj4NCj4+YmVsb3cgaXMgbXkg TVBMUy1SVCByZXZpZXc6DQo+Pg0KPj4tIGlzIHRoZSBkb2N1bWVudCBjb2hlcmVudD8NCj4+WWVz LCBpbiBnZW5lcmFsLCBidXQgY2FuIGJlbmVmaXQgZnJvbSBhbm90aGVyIGVkaXRvcmlhbCByb3Vu ZC4NCj4+DQo+Pi0gaXMgaXQgdXNlZnVsPw0KPj5ZZXMsIGJlaW5nIGFibGUgdG8gY29udHJvbCBU LUxEUCBzZXNzaW9uIGVzdGFibGlzaG1lbnQgb24tZGVtYW5kIHVzaW5nDQo+Pm5ldw0KPj50YXJn ZXRlZCBhcHBsaWNhdGlvbiBjYXBhYmlsaXR5IFRMViBpcyB1c2VmdWwuDQo+Pg0KPj4tIGlzIGl0 IHRlY2huaWNhbGx5IHNvdW5kPw0KPj5ZZXMsIGJ1dCBjYW4gYmVuZWZpdCBmcm9tIGJlaW5nIG1v cmUgZXhwbGljaXQgb24gaG93IGl0IGNvbXBsZW1lbnRzIGFuZA0KPj5wb3NzaWJseSBjby1leGlz dHMgd2l0aCB3b3JrIGRlZmluZWQgaW4NCj4+ZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcC1wdy1jYXBh YmlsaXR5Lg0KPlNlY3Rpb24gNSBkZXNjcmliZXMgaW50ZXJ3b3JraW5nIG9mIHRoaXMgZHJhZnQg d2l0aA0KPmRyYWZ0LWlldGYtbXBscy1sZHAtaXAtcHctY2FwYWJpbGl0eS4gV2UgaGF2ZSBhZGRl ZCBtb3JlIGV4cGxpY2l0DQo+dGV4dCB0byB0aGlzIHNlY3Rpb24gaW4gdmVyc2lvbiAwMywgd2hp Y2ggd2lsbCBiZSBwdWJsaXNoZWQgc2hvcnRseS4NCj4NCj4NCj4+Rm9yIGV4YW1wbGUsIHdoZW4g Y29uZmxpY3RpbmcNCj4+VEFDL1NBQyBhcmUgdXNlZCBhbmQgaG93IGl0IGNhbiBiZSBpbnRlcnBy ZXRlZD8NCj5TZWN0aW9uIDUsIHBhcmFncmFwaCA0IGFuZCA1IGRlc2NyaWJlIHRoZSBwcm9jZWR1 cmFsIHByZWZlcmVuY2VzIGZvcg0KPnRoZSBjby1leGlzdGVuY2Ugb2YgVEFDL1NBQyBhbmQgZm9y IHRoZSBhdm9pZGFuY2Ugb2YgY29uZmxpY3RpbmcNCj5TQUMvVEFDIG9uIHRoZSB0TERQIHNlc3Np b24uIEFkZGVkIOKAmG11c3TigJkga2V5d29yZCBmb3IgdGhlc2UgcHJvY2VkdXJlcy4NCj4gICAN Cj4+QW5vdGhlciAoaWRlYSkgaXMgY2FuIGRvDQo+PndpdGhvdXQgZXh0cmEgbWFwcGluZ3MgZm9y IFRhcmdldGVkIEFwcGxpY2F0aW9uIEVsZW1lbnQgdG8gU3RhdGUNCj4+QWR2ZXJ0aXNlbWVudCBD b250cm9sIChTQUMpIEVsZW1lbnRzIGFzIGRlZmluZWQgaW4NCj4+ZHJhZnQtaWV0Zi1tcGxzLWxk cC1pcC1wdy1jYXBhYmlsaXR5IChjYW4gaXQgYmUgdW5pZmllZCBhcHAtaWQgaW5zdGVhZD8pPw0K PlRoZSBhcHBsaWNhdGlvbiB0eXBlIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcC1w dy1jYXBhYmlsaXR5IG1hcHMNCj50bw0KPkxEUCBGRUMgdHlwZSB3aGlsZSB0aGUgVEEtSWQgZGVm aW5lZCBoZXJlIGlzIHRMRFAgYXBwbGljYXRpb24gSWQsIHdoaWNoDQo+aXMgbmVjZXNzYXJ5IHRv IGNvbnRyb2wgdExEUCBzZXNzaW9uIGVzdGFibGlzaG1lbnQgcGVyIGFwcGxpY2F0aW9uIGFuZCB0 bw0KPmFkdmVydGlzZSBvbmx5IG5lY2Vzc2FyeSBMRFAgRkVDLUxhYmVsIGJpbmRpbmdzIGZvciB0 aGF0IGFwcGxpY2F0aW9uLg0KPg0KPj4NCj4+LSBpcyBpdCByZWFkeSBmb3IgV0cgYWRvcHRpb24/ DQo+PlllcywgYnV0IHJlY29tbWVuZCB1bmRlcmdvaW5nIGFub3RoZXIgcm91bmQgb2YgY2xlYW51 cC9lZGl0aW5nIGJlZm9yZS4NCj4+DQo+Pg0KPj49PT0NCj4+Q29tbWVudHM6DQo+Pg0KPj5TZWN0 aW9uIDI6DQo+PiogVmFsdWUgb2YgVS9GLWJpdHM6IHN1Z2dlc3QgYmVpbmcgZXhwbGljaXQgb24g dGhlIHJlY29tbWVuZGVkIHZhbHVlc+KAuQ0KPj5lLmcuIFRoZSB2YWx1ZSBvZiB0aGUgVS1iaXQg Zm9yIHRoZSBUTFYgTVVTVCBiZSBzZXQgdG8gMSBzbyB0aGF0IGENCj4+cmVjZWl2ZXIgTVVTVCBz aWxlbnRseSBpZ25vcmUgdGhpcyBUTFYgaWYgdW5rbm93biB0byBpdCwgYW5kIGNvbnRpbnVlDQo+ PnByb2Nlc3NpbmcgdGhlIHJlc3Qgb2YgdGhlIG1lc3NhZ2UuIFRoZSB2YWx1ZSBvZiBGLWJpdCBN VVNUIGJlIHNldCB0byAwLA0KPj5zbyB0byBub3QgZm9yd2FyZC4NCj5XZSB3aWxsIG1ha2UgaXQg ZXhwbGljaXQgaW4gdGhlIG5ldyByZXZpc2lvbiAtMDMuDQo+DQo+Pg0KPj4qIChUYXJnZXRlZCBB cHBsaWNhdGlvbiBJZGVudGlmaWVyIChUQS1JZCkpOiB3b3VsZCByZWNvbW1lbmQgbWFraW5nIEUt Yml0DQo+PmJlIGF0IHBvc2l0aW9uIDAgdG8gYmUgY29uc2lzdGVudCB3aXRoIG90aGVyIGRlZmlu aXRpb25zLg0KPlRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24sIFdlIHdpbGwgY2hhbmdlIGl0Lg0K Pg0KPj5TZWN0aW9uIDM6IA0KPj4qIGl0IE1VU1QgdGVhcmQgZG93biAtPiBpdCBNVVNUIHRlYXIg ZG93bg0KPj4qIHdpdGhkcmFsIC0+IHdpdGhkcmF3YWwNCj5Eb25lLg0KPg0KPj4qIHJlcGVhdGVk IFRBLUlkcy9UQUVzIG9uIHJlY2VpdmUgbWF5IGJlIGNvbnNpZGVyZWQgbWFsZm9ybWVkICg/KSB0 byBiZQ0KPj5jb25zaXRlbnQgd2l0aCBwcm9jZWR1cmVzIGluIGRyYWZ0LWlldGYtbXBscy1sZHAt aXAtcHctY2FwYWJpbGl0eT8NCj5XZSB0aG91Z2h0IG92ZXIgaXQgYW5kIGFycml2ZWQgYXQgYSBj b25jbHVzaW9uIHRvIGlnbm9yZSBkdXBsaWNhdGVzDQo+cmF0aGVyIHRoZW4gdG8gY29uc2lkZXIg dGhlbSBhcyBtYWxmb3JtZWQgdG8gYXZvaWQgdExEUCBzZXNzaW9uIGZsYXAuDQo+DQo+PiogY2Fu IGVsYWJvcmF0ZSBvbiB0aGUgbmV3IHJlcXVpcmVtZW50IGJlbG93Li4gV2hhdCBhcmUgaW1wbGlj YXRpb25zIG9mDQo+Pm5vdCBhY2NlcHRpbmcgYnkgZGVmYXVsdD8NCj4+ICAgICAgIkFsc28sIGN1 cnJlbnRseSB0aGUgcmVtb3RlIExTUiBhY2NlcHRzIGFzeW1tZXRyaWMgZXh0ZW5kZWQgSGVsbG9z DQo+PmJ5DQo+PiAgIGRlZmF1bHQgb3IgYnkgYXBwcm9wcmlhdGUgY29uZmlndXJhdGlvbi4gV2l0 aCB0aGlzIGRvY3VtZW50LCBpdA0KPj4gICBzaG91bGQgYWNjZXB0IGJ5IGRlZmF1bHQgaW4gb3Jk ZXIgdG8gdGhlbiBhY2NlcHQgb3IgcmVqZWN0IHRoZSB0TERQDQo+PiAgIHNlc3Npb24gYmFzZWQg b24gdGhlIGFwcGxpY2F0aW9uIGluZm9ybWF0aW9uLsKyDQo+SWYgdGhlIHJlY2VpdmluZyBMU1Ig ZG9lcyBub3QgYWNjZXB0IGFzeW1tZXRyaWMgdExEUCBoZWxsb3MsIGFzeW1tZXRyaWMNCj50TERQ IHNlc3Npb25zIGNhbm5vdCBiZSBlc3RhYmxpc2hlZCB0byB0aGF0IExTUi4gU28gYXV0b21hdGlj IGFwcGxpY2F0aW9ucw0KPnN1Y2ggYXMgUmVtb3RlIExGQSwgQkdQIGF1dG8tZGlzY292ZXJlZCBw c2V1ZG93aXJlLCBtTERQIG5vZGUgcHJvdGVjdGlvbg0KPmV0YyBtYXkgbm90IHdvcmsuDQo+DQo+ Pg0KPj5TZWN0aW9uIDQ6DQo+Piogcy9hbiBMU1IgTUFZIHVzaW5nL2FuIExTUiBNQVkgdXNlDQo+ Pg0KPj5TZWN0aW9uIDU6DQo+PiogIlRoZSBFLWJpdCBvZiB0aGUgVGFyZ2V0ZWQgQXBwbGljYXRp b24gRWxlbWVudCBNVVNUIGJlIHNldCB0byAxIHRvDQo+PmVuYWJsZSBUYXJnZXRlZCBhcHBsaWNh dGlvbi7Csi4gSG93IHRvIGhhbmRsZSB3aGVuIEUtYml0IGlzIDAgb24gUlgsIGlzIGl0DQo+Pm1h bGZvcm1lZCwgb3IgaWdub3JlZD8NCj5JdCBpcyBpZ25vcmVkLiBBZGRlZCBpbiB0aGUgbmV3IHZl cnNpb24uDQo+DQo+PiogY2FuIGJlIG1vcmUgZWxhYm9yYXRpdmUgb24gaGFuZGxpbmcgVEFDIHVw ZGF0ZSBpbiBMRFAgY2FwYWJpbGl0eQ0KPj5tZXNzYWdlLi4NCj5Pa2llLg0KPg0KPj4qIHMvZGlz YmFsZWQvZGlzYWJsZWQNCj4+KiBzL3VkcGF0ZXMvdXBkYXRlcw0KPkRvbmUuDQo+DQo+PiogIlRo ZSBMU1IgTUFZIGFkZCBhIGRpZmZlcmVudCBLZWVwQWxpdmUgVGltZcKyLCB3aHk/IG5vdCBjbGVh ciBob3cNCj4+cmVsYXRlZD8NCj5SZW1vdmVkLg0KPg0KPj5TZWN0aW9uIDY6DQo+Piogcy9pbml0 aWFsYXphdGlvbi9pbml0aWFsaXphdGlvbg0KPj4qIHMvcHJvY2NlZHMvcHJvY2VlZHMNCj4+KiBz L2VzdGFibGlzaGVtdC9lc3RhYmxpc2htZW50DQo+RG9uZS4NCj4NCj5UaGFua3MsDQo+U2FudG9z aA0KPj4NCj4+DQo+Pk9uIDIwMTQtMTEtMjQsIDI6NDAgQU0sICJMb2EgQW5kZXJzc29uIiA8bG9h QHBpLm51PiB3cm90ZToNCj4+DQo+Pj5UYXJlaywgVGhvbWFzIGFuZCBMaXpob25nLA0KPj4+DQo+ Pj5Zb3UgaGF2ZSBiZSBzZWxlY3RlZCBhcyBNUExTLVJUIHJldmlld2VycyBmb3IgZHJhZnQtZXNh bGUtbXBscy1hcHAtDQo+Pj5hd2FyZS10bGRwLg0KPj4+DQo+Pj5Ob3RlIHRvIGF1dGhvcnM6IFlv dSBoYXZlIGJlZW4gQ0MnZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93DQo+Pj50 aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJldmll dyB5b3VyIG93bg0KPj4+ZG9jdW1lbnQuDQo+Pj4NCj4+PlJldmlld3Mgc2hvdWxkIGNvbW1lbnQg b24gd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0DQo+Pj51c2VmdWwgKGll LCBpcyBpdCBsaWtlbHkgdG8gYmUgYWN0dWFsbHkgdXNlZnVsIGluIG9wZXJhdGlvbmFsDQo+Pj5u ZXR3b3JrcyksIGFuZCBpcyB0aGUgZG9jdW1lbnQgdGVjaG5pY2FsbHkgc291bmQ/ICBXZSBhcmUg aW50ZXJlc3RlZA0KPj4+aW4ga25vd2luZyB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyByZWFkeSB0 byBiZSBjb25zaWRlcmVkIGZvciBXRw0KPj4+YWRvcHRpb24gKGllLCBpdCBkb2Vzbid0IGhhdmUg dG8gYmUgcGVyZmVjdCBhdCB0aGlzIHBvaW50LCBidXQgc2hvdWxkIGJlDQo+Pj5hIGdvb2Qgc3Rh cnQpLg0KPj4+DQo+Pj5SZXZpZXdzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBhdXRo b3JzLCBXRyBjby1jaGFpcnMgYW5kDQo+Pj5XRyBzZWNyZXRhcnksIGFuZCBDQydkIHRvIHRoZSBN UExTIFdHIGVtYWlsIGxpc3QuIElmIG5lY2Vzc2FyeSwgY29tbWVudHMNCj4+Pm1heSBiZSBzZW50 IHByaXZhdGVseSB0byBvbmx5IHRoZSBXRyBjaGFpcnMuDQo+Pj4NCj4+PklmIHlvdSBoYXZlIHRl Y2huaWNhbCBjb21tZW50cyB5b3Ugc2hvdWxkIHRyeSB0byBiZSBleHBsaWNpdCBhYm91dCB3aGF0 DQo+Pj4qcmVhbGx5KiBuZWVkIHRvIGJlIHJlc29sdmVkIGJlZm9yZSBhZG9wdGluZyBpdCBhcyBh IHdvcmtpbmcgZ3JvdXANCj4+PmRvY3VtZW50LCBhbmQgd2hhdCBjYW4gd2FpdCB1bnRpbCB0aGUg ZG9jdW1lbnQgaXMgYSB3b3JraW5nIGdyb3VwDQo+Pj5kb2N1bWVudCBhbmQgdGhlIHdvcmtpbmcg Z3JvdXAgaGFzIHRoZSByZXZpc2lvbiBjb250cm9sLg0KPj4+DQo+Pj5BcmUgeW91IGFibGUgdG8g cmV2aWV3IHRoaXMgZHJhZnQgYnkgRGVjIDksIDIwMTQ/IFBsZWFzZSByZXNwb25kIGluIGENCj4+ PnRpbWVseSBmYXNoaW9uLg0KPj4+DQo+Pj4NCj4+PlRoYW5rcywgTG9hDQo+Pj4oYXMgTVBMUyBX RyBjaGFpcikNCj4+Pi0tIA0KPj4+DQo+Pj4NCj4+PkxvYSBBbmRlcnNzb24gICAgICAgICAgICAg ICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+Pj5TZW5pb3IgTVBMUyBF eHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPj4+SHVhd2VpIFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+Pg0KPj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5tcGxzIG1h aWxpbmcgbGlzdA0KPj5tcGxzQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscw0KPg0KPg0KDQo= From nobody Fri Jan 30 23:02:10 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20E31A88BA for ; Fri, 30 Jan 2015 23:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBOEbABIJy1m for ; Fri, 30 Jan 2015 23:02:07 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18A01A88AC for ; Fri, 30 Jan 2015 23:02:07 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B6C21180159D; Sat, 31 Jan 2015 08:02:03 +0100 (CET) Message-ID: <54CC7DE5.2030104@pi.nu> Date: Sat, 31 Jan 2015 15:01:57 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR poll on draft-esale-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 07:02:09 -0000 Working group, An adoption poll will be started on draft-esale-mpls-app-aware-tldp. We will run the IPR poll in parallel. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-esale-mpls-app- aware-tldp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are currently 1 IPR disclosure that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa mpls wg co-chair -- -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Jan 30 23:10:31 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C541A8847 for ; Fri, 30 Jan 2015 23:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqNcGyzGJQmO for ; Fri, 30 Jan 2015 23:10:28 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046D11A6FFB for ; Fri, 30 Jan 2015 23:10:27 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id ADBAC180159D; Sat, 31 Jan 2015 08:10:24 +0100 (CET) Message-ID: <54CC7FDB.40801@pi.nu> Date: Sat, 31 Jan 2015 15:10:19 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] poll to see if we have consensus tp adopt draft-esale-mpls-app-aware-tldp as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 07:10:29 -0000 Working Group, This is to start a two week poll on adopting draft-esale-mpls-app- aware-tldp-03 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There is 1 IPR disclosure against this document. An IPR has been started in parallel to the adoption poll, and the adoption poll will not be closed before we have responses from all authors. If you are on the the mpls working group mailing list and aware of IPR that relates to this draft, you should respond to the IPR poll. This poll ends February 14, 2015. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jan 31 02:28:18 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9441A8945; Sat, 31 Jan 2015 02:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrX1RKUb_vSH; Sat, 31 Jan 2015 02:28:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B498D1A8938; Sat, 31 Jan 2015 02:28:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150131102811.24621.34567.idtracker@ietfa.amsl.com> Date: Sat, 31 Jan 2015 02:28:11 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 10:28:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Encapsulating MPLS in UDP Authors : Xiaohu Xu Nischal Sheth Lucy Yong Ross Callon David Black Filename : draft-ietf-mpls-in-udp-11.txt Pages : 18 Date : 2015-01-31 Abstract: This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol) for situations where UDP encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. The MPLS-in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of co-operating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in- UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 31 02:28:20 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA5D1A8945 for ; Sat, 31 Jan 2015 02:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlSVIVAsvpNb; Sat, 31 Jan 2015 02:28:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F09291A893E; Sat, 31 Jan 2015 02:28:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, "Loa Andersson" , mpls@ietf.org, akatlas@gmail.com, stephen.farrell@cs.tcd.ie, mls.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150131102811.24621.78297.idtracker@ietfa.amsl.com> Date: Sat, 31 Jan 2015 02:28:11 -0800 Archived-At: Subject: [mpls] New Version Notification - draft-ietf-mpls-in-udp-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 10:28:14 -0000 A new version (-11) has been submitted for draft-ietf-mpls-in-udp: http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-udp-11.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Sat Jan 31 02:52:26 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0E51A894E; Sat, 31 Jan 2015 02:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL-D-j5uH5XD; Sat, 31 Jan 2015 02:52:19 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909AC1A894B; Sat, 31 Jan 2015 02:52:19 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0VAqCDe025170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2015 05:52:12 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t0VAqCDe025170 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1422701532; bh=N9LIfXEtE6yTxVz+CzWMfysO3Os=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=l+oexPIYZH5ATeeoe8rxdwL6EIABLIZULpL0u3zbSUfqTtckBZLnaIXWKGKjjyBn9 JXBFnMaE05HRDpiza0kvbbD2dg6cxosZ9FgvZ0+sDSOi7/ciqUoKieltRpIFwhfr4N D1XldKkFHyi60aNxxJlwSmKKCRv9iYtcqnSb+Vak= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t0VAqCDe025170 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd04.lss.emc.com (RSA Interceptor); Sat, 31 Jan 2015 05:51:16 -0500 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0VApn2A003425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 31 Jan 2015 05:51:49 -0500 Received: from MXHUB102.corp.emc.com (10.253.58.15) by mxhub14.corp.emc.com (128.222.70.235) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sat, 31 Jan 2015 05:51:49 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB102.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Sat, 31 Jan 2015 05:51:49 -0500 From: "Black, David" To: "stephen.farrell@cs.tcd.ie" , "mls.ietf@gmail.com" Thread-Topic: New Version Notification - draft-ietf-mpls-in-udp-11.txt Thread-Index: AQHQPUCoKOdUIISBd0ai5sOSs6XfdpzaDGSQ Date: Sat, 31 Jan 2015 10:51:48 +0000 Message-ID: References: <20150131102811.24621.78297.idtracker@ietfa.amsl.com> In-Reply-To: <20150131102811.24621.78297.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.61.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-in-udp@tools.ietf.org" , "internet-drafts@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] New Version Notification - draft-ietf-mpls-in-udp-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 10:52:22 -0000 TWFydGluIGFuZCBTdGVwaGVuLA0KDQpUaGlzIC0xMSBkcmFmdCB2ZXJzaW9uIGNvbnRhaW5zIHRl eHQgdGhhdCBzaG91bGQgYmUgc3VmZmljaWVudCB0byByZXNvbHZlDQp5b3VyIERpc2N1c3MgY29u Y2VybnMuICBQbGVhc2UgY2hlY2sgdGhhdCB0ZXh0IGFuZCBjbGVhciB0aGUgRGlzY3Vzcw0KcG9z aXRpb25zIGlmIHRoZSB0ZXh0IGlzIHN1ZmZpY2llbnQgdG8gcmVzb2x2ZSB5b3VyIGNvbmNlcm5z Lg0KDQpUaGFua3MsDQotLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiBTZW50OiBTYXR1cmRheSwgSmFudWFyeSAzMSwgMjAxNSA1OjI4IEFNDQo+IFRv OiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29s cy5pZXRmLm9yZzsgTG9hDQo+IEFuZGVyc3NvbjsgbXBsc0BpZXRmLm9yZzsgYWthdGxhc0BnbWFp bC5jb207IHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU7DQo+IG1scy5pZXRmQGdtYWlsLmNvbQ0K PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLW1wbHMtaW4t dWRwLTExLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gKC0xMSkgaGFzIGJlZW4gc3VibWl0 dGVkIGZvciBkcmFmdC1pZXRmLW1wbHMtaW4tdWRwOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTExLnR4dA0KPiANCj4gU3ViIHN0 YXRlIGhhcyBiZWVuIGNoYW5nZWQgdG8gQUQgRm9sbG93dXAgZnJvbSBSZXZpc2VkIElEIE5lZWRl ZA0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHBhZ2UgZm9yIHRoaXMgSW50ZXJuZXQt RHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt bXBscy1pbi11ZHAvDQo+IA0KPiBEaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbjoNCj4gaHR0cDov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0xMQ0KPiAN Cj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSUVURiBTZWNyZXRh cmlhdC4NCg0K From nobody Sat Jan 31 03:23:53 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA93C1A8965 for ; Sat, 31 Jan 2015 03:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO6Io0Z7HAUD for ; Sat, 31 Jan 2015 03:23:50 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BABB1A8957 for ; Sat, 31 Jan 2015 03:23:50 -0800 (PST) Received: from DM2PR0501MB1312.namprd05.prod.outlook.com (25.160.130.153) by DM2PR0501MB1325.namprd05.prod.outlook.com (25.160.130.154) with Microsoft SMTP Server (TLS) id 15.1.75.20; Sat, 31 Jan 2015 11:23:28 +0000 Received: from DM2PR0501MB1310.namprd05.prod.outlook.com (25.160.130.151) by DM2PR0501MB1312.namprd05.prod.outlook.com (25.160.130.153) with Microsoft SMTP Server (TLS) id 15.1.75.20; Sat, 31 Jan 2015 11:23:27 +0000 Received: from DM2PR0501MB1310.namprd05.prod.outlook.com ([25.160.130.151]) by DM2PR0501MB1310.namprd05.prod.outlook.com ([25.160.130.151]) with mapi id 15.01.0075.002; Sat, 31 Jan 2015 11:23:27 +0000 From: Raveendra Torvi To: Loa Andersson Thread-Topic: poll to see if we have consensus tp adopt draft-esale-mpls-app-aware-tldp as an MPLS wg document Thread-Index: AQHQPSUCj4iODQqVs0yCaEwlCkGjlJzaFl+g Date: Sat, 31 Jan 2015 11:23:26 +0000 Message-ID: <0D9AD2B1-FAF1-4FC3-8C79-371044E96AE0@juniper.net> References: <54CC7FDB.40801@pi.nu> In-Reply-To: <54CC7FDB.40801@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.218.20.33] authentication-results: pi.nu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1312;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1312; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(252514010)(377454003)(24454002)(51704005)(76176999)(86362001)(83716003)(36756003)(102836002)(2950100001)(33656002)(54356999)(50986999)(19580395003)(92566002)(19580405001)(110136001)(106116001)(230783001)(122556002)(82746002)(46102003)(77156002)(40100003)(66066001)(2900100001)(62966003)(99286002)(87936001)(2656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1312; H:DM2PR0501MB1310.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2015 11:23:26.7041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1312 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1325; X-OriginatorOrg: juniper.net Archived-At: Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus tp adopt draft-esale-mpls-app-aware-tldp as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 11:23:53 -0000 As a co-author, I support "draft-esale-mpls-app-aware-tldp-03" for WG adopt= ion. I am not aware of any other IPR that relates to this draft. -Ravi > On Jan 31, 2015, at 2:10 AM, Loa Andersson wrote: >=20 > Working Group, >=20 > This is to start a two week poll on adopting draft-esale-mpls-app- > aware-tldp-03 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > There is 1 IPR disclosure against this document. An IPR has been > started in parallel to the adoption poll, and the adoption > poll will not be closed before we have responses from all authors. >=20 > If you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, you should respond to the > IPR poll. >=20 > This poll ends February 14, 2015. >=20 > /Loa > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jan 31 06:36:19 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE9E1A88D6 for ; Sat, 31 Jan 2015 06:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkv2SnZYSkfw for ; Sat, 31 Jan 2015 06:36:16 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3299A1A7013 for ; Sat, 31 Jan 2015 06:36:16 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id p6so24618651qcv.8 for ; Sat, 31 Jan 2015 06:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5gFEP+/GZ4ywcm60IazyKh4a3mmCnN4K3vKZTs49tKU=; b=DRhVDa4LGFgrkRPxLB+MMT4dayesE6ADdC6sbAoZSIrDpqLydONVdxe/Eh5m5Z4ThY Au3A45NUK+mA4UuXeuqDrLTMCK8uhqKDcVzc9yHPAeaigrZX6V+jitIpgUd5xilfNUd8 iV0/n7JtjRo7Vh48In8QwZ9veSlFMUEuYFYP3oW7kPOoNz5odnj6PF5fpTbzMDvBTx5q OPN6Uw9SWcT2IBx8WFwjIbl4psmxflbGGD5lpxO0LdbXmejCgHQ3sRXTHVpiFXnxlG8K p9WyPxexn0W1eJBOgcgIpOoxi1xaLaxrgG2NOcvEJsivw+VrbOXCJQKezz/MbuthAoIY TAEQ== MIME-Version: 1.0 X-Received: by 10.224.40.136 with SMTP id k8mr22883821qae.28.1422714975347; Sat, 31 Jan 2015 06:36:15 -0800 (PST) Received: by 10.140.85.227 with HTTP; Sat, 31 Jan 2015 06:36:15 -0800 (PST) In-Reply-To: <0D9AD2B1-FAF1-4FC3-8C79-371044E96AE0@juniper.net> References: <54CC7FDB.40801@pi.nu> <0D9AD2B1-FAF1-4FC3-8C79-371044E96AE0@juniper.net> Date: Sat, 31 Jan 2015 09:36:15 -0500 Message-ID: From: Vishnu Pavan Beeram To: Raveendra Torvi Content-Type: multipart/alternative; boundary=047d7bf0e73cb8e729050df3a48b Archived-At: Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus tp adopt draft-esale-mpls-app-aware-tldp as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 14:36:18 -0000 --047d7bf0e73cb8e729050df3a48b Content-Type: text/plain; charset=UTF-8 Support. -Pavan On Sat, Jan 31, 2015 at 6:23 AM, Raveendra Torvi wrote: > As a co-author, I support "draft-esale-mpls-app-aware-tldp-03" for WG > adoption. > > I am not aware of any other IPR that relates to this draft. > > -Ravi > > > On Jan 31, 2015, at 2:10 AM, Loa Andersson wrote: > > > > Working Group, > > > > This is to start a two week poll on adopting draft-esale-mpls-app- > > aware-tldp-03 as an MPLS working group document. > > > > Please send your comments (support/not support) to the mpls working > > group mailing list (mpls@ietf.org). Please give a technical > > motivation for your support/not support, especially if you think that > > the document should not be adopted as a working group document. > > > > There is 1 IPR disclosure against this document. An IPR has been > > started in parallel to the adoption poll, and the adoption > > poll will not be closed before we have responses from all authors. > > > > If you are on the the mpls working group mailing list and > > aware of IPR that relates to this draft, you should respond to the > > IPR poll. > > > > This poll ends February 14, 2015. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7bf0e73cb8e729050df3a48b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support.

-Pavan

On Sat, Jan 31, 2015 at 6:23 AM,= Raveendra Torvi <rtorvi@juniper.net> wrote:
As a co-author, I support "draft-esale-mpls-app-aw= are-tldp-03" for WG adoption.

I am not aware of any other IPR that relates to this draft.

-Ravi

> On Jan 31, 2015, at 2:10 AM, Loa Andersson <loa@pi.nu> wrote:
>
> Working Group,
>
> This is to start a two week poll on adopting draft-esale-mpls-app-
> aware-tldp-03 as an MPLS working group document.
>
> Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org= ). Please give a technical
> motivation for your support/not support, especially if you think that<= br> > the document should not be adopted as a working group document.
>
> There is 1 IPR disclosure against this document. An IPR has been
> started in parallel to the adoption poll, and the adoption
> poll will not be closed before we have responses from all authors.
>
> If you are on the the mpls working group mailing list and
> aware of IPR that relates to this draft, you should respond to the
> IPR poll.
>
> This poll ends February 14, 2015.
>
> /Loa
> --
>
>
> Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
> Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.= nu
> Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=

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

--047d7bf0e73cb8e729050df3a48b-- From nobody Sat Jan 31 06:52:48 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E321A8928 for ; Sat, 31 Jan 2015 06:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cRiF3N69Jt9 for ; Sat, 31 Jan 2015 06:52:44 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B371A88D6 for ; Sat, 31 Jan 2015 06:52:44 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id nt9so7268001obb.3 for ; Sat, 31 Jan 2015 06:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2vALwlLc6TUe/6LUtZH5wP5iCrtKMVe+xEtMD+IEr/s=; b=uw6fViviOobuBilpVThNBApsE1ZcLip3TH00B523zi31ieaAdOU/Zil4TLBuK+AZ5B +Jp41/g9POCkQgboPluP4igvm2M91yr24/si3ZTNi/Vqf4euJrENnALV2jfpNJT9i3sJ w/RyXD98HcmTdnhx3g9k8NblY24h6VwViundxxnn6fGzc3ezE9Gg3rKCJmObGNy3Osx+ mftSeapzgWUtj2+WaMyypS4P3Jdot9cG8d2LC6l0cgzrjCa8o1FdSz0tpkhxuuLeZbue EC2rWphpGVuOF3X1sTUPj2kxC2IAWF7v9qn3LJcAeuatC2eWtfDmLm2a0UycawuR90AP PTGg== MIME-Version: 1.0 X-Received: by 10.182.44.132 with SMTP id e4mr6943853obm.86.1422715963786; Sat, 31 Jan 2015 06:52:43 -0800 (PST) Received: by 10.182.128.10 with HTTP; Sat, 31 Jan 2015 06:52:43 -0800 (PST) Received: by 10.182.128.10 with HTTP; Sat, 31 Jan 2015 06:52:43 -0800 (PST) In-Reply-To: <54CC7DE5.2030104@pi.nu> References: <54CC7DE5.2030104@pi.nu> Date: Sat, 31 Jan 2015 06:52:43 -0800 Message-ID: From: Luay Jalil To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11c2f49aa35177050df3df83 Archived-At: Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" , "mpls@ietf.org" , mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-esale-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 14:52:46 -0000 --001a11c2f49aa35177050df3df83 Content-Type: text/plain; charset=UTF-8 I am not aware of any IPR that relates to this draft Regards, Luay On Jan 31, 2015 1:02 AM, "Loa Andersson" wrote: > Working group, > > An adoption poll will be started on draft-esale-mpls-app-aware-tldp. > We will run the IPR poll in parallel. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-esale-mpls-app- > aware-tldp? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are currently 1 IPR disclosure that relates to this > document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. > > *The response needs to be sent to the MPLS wg mailing list.* > > The document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > mpls wg co-chair > -- > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11c2f49aa35177050df3df83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR that relates to this draft

Regards,
Luay

On Jan 31, 2015 1:02 AM, "Loa Andersson&quo= t; <loa@pi.nu> wrote:
Working group,

An adoption poll will be started on draft-esale-mpls-app-aware-tldp.=
We will run the IPR poll in parallel.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-esale-mpls-app-
aware-tldp?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

Currently there are currently 1 IPR disclosure that relates to this
document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR.

*The response needs to be sent to the MPLS wg mailing list.*

The document will not advance to the next stage until a response has been r= eceived from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Loa
mpls wg co-chair
--
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
--001a11c2f49aa35177050df3df83-- From nobody Sat Jan 31 06:54:30 2015 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD2A1A8952 for ; Sat, 31 Jan 2015 06:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI4lvD7e6I6S for ; Sat, 31 Jan 2015 06:54:25 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761A11A8928 for ; Sat, 31 Jan 2015 06:54:24 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id x69so38761479oia.10 for ; Sat, 31 Jan 2015 06:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OxtSaN12dz6Avd1KHPh9lKqezESIGEsocBydXAt7cc8=; b=VB6WUtGS4HetC8aavmgc95p+17S4Zl0h6KqpIlujhEnSoKufNVa9NAwTFYdV3vtfij X7B2BRmuB7p0nV/gGoPLokAdTFmFxBHvgBzFVDp0nHXkjVMXXi8iegH++j+9p+0S5XzB H9G1qvd/VU/IYbIe/elZir6qYzAAsQmATtkup5WyRYeO9T5I08+JkO0cjteNm+doyZCn On13SueyM/0q2rLHmxJe5mORvlmGJF92phMBYJ7bUAxasZF0+sJVxamFKWxts6zBjW7p xIuwvmbtggyAAXtYD7MdWTrKoLzr2L/4I2FP1y90pr6hiS7LJ0dFhAt/7A0IshgSjGvn RrTQ== MIME-Version: 1.0 X-Received: by 10.60.125.163 with SMTP id mr3mr6803395oeb.69.1422716063786; Sat, 31 Jan 2015 06:54:23 -0800 (PST) Received: by 10.182.128.10 with HTTP; Sat, 31 Jan 2015 06:54:23 -0800 (PST) Received: by 10.182.128.10 with HTTP; Sat, 31 Jan 2015 06:54:23 -0800 (PST) In-Reply-To: <54CC7FDB.40801@pi.nu> References: <54CC7FDB.40801@pi.nu> Date: Sat, 31 Jan 2015 06:54:23 -0800 Message-ID: From: Luay Jalil To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7b33cb7a992b13050df3e56f Archived-At: Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" , "mpls@ietf.org" , mpls-chairs@tools.ietf.org Subject: Re: [mpls] poll to see if we have consensus tp adopt draft-esale-mpls-app-aware-tldp as an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 14:54:27 -0000 --047d7b33cb7a992b13050df3e56f Content-Type: text/plain; charset=UTF-8 Support (co-author) Regards, Luay On Jan 31, 2015 1:10 AM, "Loa Andersson" wrote: > Working Group, > > This is to start a two week poll on adopting draft-esale-mpls-app- > aware-tldp-03 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is 1 IPR disclosure against this document. An IPR has been > started in parallel to the adoption poll, and the adoption > poll will not be closed before we have responses from all authors. > > If you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, you should respond to the > IPR poll. > > This poll ends February 14, 2015. > > /Loa > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7b33cb7a992b13050df3e56f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Support (co-author)

Regards,
Luay

On Jan 31, 2015 1:10 AM, "Loa Andersson&quo= t; <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting draft-esale-mpls-app-
aware-tldp-03 as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There is 1 IPR disclosure against this document. An IPR has been
started in parallel to the adoption poll, and the adoption
poll will not be closed before we have responses from all authors.

If you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, you should respond to the
IPR poll.

This poll ends February 14, 2015.

/Loa
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
--047d7b33cb7a992b13050df3e56f--