From nobody Thu Sep 4 14:44:34 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CFD1A01A5; Thu, 4 Sep 2014 14:44:33 -0700 (PDT) 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 gMlejebDoq4L; Thu, 4 Sep 2014 14:44:31 -0700 (PDT) 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 6C9991A019B; Thu, 4 Sep 2014 14:44:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 528752406A2; Thu, 4 Sep 2014 14:44:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-41.clppva.east.verizon.net [70.106.135.41]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C844724058C; Thu, 4 Sep 2014 14:44:30 -0700 (PDT) Message-ID: <5408DD3F.9060709@joelhalpern.com> Date: Thu, 04 Sep 2014 17:44:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "idr@ietf.org List" , "rtg-dir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Ub_95vv4eY9BSDsv2Z0f_B8c2DQ Subject: [RTG-DIR] QA review of http://tools.ietf.org/html/draft-ietf-idr-error-handling-14 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 21:44:33 -0000 As requested, this is a QA review of the IDR Error Handling revision. This reviewer finds no issues with this document. It seems to be ready for IETF LC. Yours, Joel From nobody Mon Sep 8 07:23:23 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD141A8841 for ; Mon, 8 Sep 2014 07:23:19 -0700 (PDT) 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=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Czo2hlX2TQYs for ; Mon, 8 Sep 2014 07:23:17 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC37D1A8837 for ; Mon, 8 Sep 2014 07:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=nabil.n.bitar@verizon.com; q=dns/txt; s=corp; t=1410186196; x=1441722196; h=from:to:cc:date:subject:message-id:mime-version; bh=nYLoA1yWyi+vhqQQo8vkvE2KJdilzQR6kNZFrurS9a4=; b=h2I9Yw80NnnVUfKNvui9egqNfg2yli0koUuQ4C8YW9sEk010xT0uOXMd drPbqyLDAhQ0KhsLGyC1P6yfk8QOvkx679FqpV3GuaA3eh2RNSYWAf4jP t8jKd4L71Dhv6J8yRdcjxhAUHPkorlyXYeM4+k02rtBmB3UocIBOlLeGY M=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe01.verizonbusiness.com with ESMTP; 08 Sep 2014 14:23:11 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="5.04,486,1406592000"; d="scan'208,217";a="846569184" Received: from fldp1lumxc7hb04.verizon.com (HELO FLDP1LUMXC7HB04.us.one.verizon.com) ([166.68.75.83]) by fldsmtpi01.verizon.com with ESMTP; 08 Sep 2014 14:23:02 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB04.us.one.verizon.com ([166.68.75.83]) with mapi; Mon, 8 Sep 2014 10:22:58 -0400 To: "rtg-ads@tools.ietf.org" Date: Mon, 8 Sep 2014 10:22:50 -0400 Thread-Topic: [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00 Thread-Index: Ac/LcGM0jurTjP6ZQBSQTWGaoKK0kA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D03333FA5F551nabilnbitaroneverizoncom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/LvHq6GPsQ5Jqe19r3HUl2TMLZik Cc: "rtg-dir@ietf.org" , "db3546@att.com" , "jhaas@juniper.net" , 'Jonathan Hardwick' , "jgs@juniper.net" , "shares@ndzh.com" Subject: [RTG-DIR] [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 14:23:20 -0000 --_000_D03333FA5F551nabilnbitaroneverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/t= rac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-idr-flowspec-redirect-rt-bis-00.txt Reviewer: Nabil Bitar Review Date: 09/07/2014 Draft had passed WG LC Intended Status: Standards Track Summary: This document addresses an issue in the definition of the redirect= extended community in RFC 5575. I have somme comments pertaining to the cl= arity of this document that I think they should be resolved before publicat= ion. Major Issues: No major issues found. Minor Issues: Following are suggested edits. Abstract: Change: originally documented in RFC 5575 --> originally documented in RFC= 5575 (Dissemination of Flow Specification Rules) - Page 3, last sentence a common interpretation of the Redirect Extended Community=92s "6-byte Rout= e Target" has been to look for any matching Route Target sharing the same V= alue portion of its Extended Community. Thus, multiple Route Targets provis= ioned in a router=92s VRFs might match even though the format was different= . Suggested new text: a common interpretation of the redirect extended community=92s "6-byte rout= e target" has been to look, at a receiving router, for a route target value= that matches the route target value in the received redirect extended comm= unity, and import the advertised route to the corresponding VRF instance su= bject to the rules defined in RFC 5575 [RFC 5575]. However, because the rou= te target format in the redirect extended community is not clearly defined,= the wrong match may occur. - Page 4, second paragraph: This "Value wildcard" behavior does not matched deployed implementations of= BGP Flowspec. Suggested new text: This "value wildcard" matching behavior, that does not take into account th= e format of the route target defined for a local VRF and may result in the = wrong matching decision, does not match deployed implementations of BGP flo= wspec. Deployed implementations of BGP flowspec solves this problem by defi= ning different redirect extended communities that are specific to the forma= t of the route target value. This document defines the following redirect e= xtended communities: - Page 4, first sentence under table: It should be noted that the low-order nybble of the Redirect=92s type field corresponds to the Route Target Extended Community = format field (Type). (See [RFC4360], Secs. 3.1, 3.2 and [RFC5668], Sec. 2.)= The low order octet (Sub-Type) of the Redirect Extended Community remains = 0x08, contrasted to 0x02 for Route Targets. Question: Why is the reference to RFC 4360 section 3.1 and 3.2, and RFC 56= 68 section 2? See to be the wrong references. Did you mean to refer to RFC = 4360 section 4? Suggested new text: It should be noted that the low-order nybble of the High-order octet of the redirect extended community yype field in Table 1 c= orresponds to that in the high-order octet of the route target extended com= munity type field. The low order octet (sub-type) of the redirect extended = Community remains 0x08, contrasted to 0x02 for route targets (see [RFC4360]= section 4). - Note: I suggest that you add text on matching the newly defined redirect= extended communities to route targets defined for VRF=92s to update what i= s in RFC 5575. Section 2 IANA Considerations (minor comments): - 0x81 "Generic Transitive Experimental Extended Community Part 2 Sub-Types" Regis= try ------------------- Change: Experimental =E0 Experimental Use - 0x82 "Generic Transitive Experimental Extended Community Part 3 Sub-Types" ------------------- Change: Experimental =E0 Experimental Use - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL EXTENDED = COMMUNITY PART 2 SUB-TYPES registry. It should be seeded with the following= Sub-Type Change: Experimental =E0 Experimental Use - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL EXTENDED = COMMUNITY PART 3 SUB-TYPES registry. It should be seeded with the following= Sub-Type Change: Experimental =E0 Experimental Use Nits: None noticed. Thanks, Nabil --_000_D03333FA5F551nabilnbitaroneverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts a= s they pass through IETF last call and IESG review. The purpose of the review= is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.= org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comm= ents that you receive, and strive to resolve them through discussion or by updat= ing the draft.

Document: draft-ietf-idr-flowspec-redirect-rt-bis-00.txt

Reviewer: Nabil Bitar

Review Date: 09/07/2014

Draft had passed WG LC

Intended Status: Standards Track

Summary:=20 This document addresses an issue in the definition of the redirect extended community in = RFC 5575. I have somme comments pertaining to the clarity of this document that= I think they should be resolved before publication.

Major Issues: No major issues found.

Minor Issues:

Following are = suggested edits.

Abstract:

Change:  originally doc= umented in RFC 5575 =E0=  originally documented in RFC 5575 (Dissemination of Flo= w Specification Rules)

- Page 3, last sentence

a common interpretation of the Redirec= t Extended Community=92s "6-byte Route Target" has been to look for any matching Route Tar= get sharing the same Value portion of its Extended Community. Thus, multiple Ro= ute Targets provisioned in a router=92s VRFs might match even though the format= was different.

 

Suggested new text: =

a common interpretation of the redirec= t extended community=92s "6-byte route target" has been to look, at a receiving router, fo= r a route target value that matches the route target value in the received redi= rect extended community, and import the advertised route to the corresponding VR= F instance subject to the rules defined in RFC 5575 [RFC 5575]. However, beca= use the route target format in the redirect extended community is not clearly defined, the wrong match may occur.

 

- Page 4, second paragraph:=

 

This "Value wildcard" behavi= or does not matched deployed implementations of BGP Flowspec.

 

Suggested new text:<= /p>

This "value wildcard" matchi= ng behavior, that does not take into account the format of the route target defined for a local VR= F and may result in the wrong matching decision, does not match deployed implementations of BGP flowspec. Deployed implementations of BGP flowspec solves this problem by defining different redirect extended communities tha= t are specific to the format of the route target value. This document defines= the following redirect extended communities:

 

<Keep table here>

 

- Page 4, first sentence under table:<= o:p>

 

It should be noted that the low-order = nybble of the

Redirect=92s type field corresponds to= the Route Target Extended Community format field (Type). (See [RFC4360], Secs. 3.1, 3.2 and [RFC5668], Sec. 2.) The low order octet (Sub-Type) of the Redirect Extended Community remains 0x08, contrasted to 0x02 for Route Targets.

 

Question:  Why is the reference to RFC 4360 section 3.1 and 3.2, and RFC 5668 section 2? See to b= e the wrong references. Did you mean to refer to RFC 4360 section 4?

 

Suggested new text:<= /p>

It should be noted that the low-order = nybble of the

High-order octet of the redirect exten= ded community yype field in Table 1 corresponds to that in the high-order octet of the route target extended community type field. The low order octet (sub-type) of the redirect extended Community remains 0x08, contrasted to 0x02 for route targ= ets (see [RFC4360] section 4).

 

- Note:  I suggest that you add text on matching the newly defined redirect extended communiti= es to route targets defined for VRF=92s to update what is in RFC 5575.=

 

 

Section 2 IANA Considerations (minor c= omments):

 

- 0x81

"Generic Transitive Experimental = Extended Community Part 2 Sub-Types" Registry

 = ;            &n= bsp;            = ;           -------------------

 

Change: Experimental =E0 Experimental Use

 

- 0x82

"Generic Transitive Experimental = Extended Community Part 3 Sub-Types"

 = ;            &n= bsp;            = ;           -------------------

 

Change: Experimental =E0 Experimental Use

 

- IANA is requested to create the GENE= RIC TRANSITIVE EXPERIMENTAL EXTENDED COMMUNITY PART 2 SUB-TYPES registry. It should be see= ded with the following Sub-Type

 

Change: Experimental =E0 Experimental Use

 

 

- IANA is requested to create the GENE= RIC TRANSITIVE EXPERIMENTAL EXTENDED COMMUNITY PART 3 SUB-TYPES registry. It should be see= ded with the following Sub-Type

 

 

Change: Experimental =E0 Experimental Use

 

 

Nits: 

None noticed.



Thanks,

Nabil

 

--_000_D03333FA5F551nabilnbitaroneverizoncom_-- From nobody Wed Sep 10 17:54:03 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E241A011D for ; Wed, 10 Sep 2014 17:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 oYUewqLebRhd for ; Wed, 10 Sep 2014 17:53:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0841A01A5 for ; Wed, 10 Sep 2014 17:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12654; q=dns/txt; s=iport; t=1410396837; x=1411606437; h=from:to:subject:date:message-id:references:mime-version; bh=LtNSa7xlzJuED1F3EV91Xy1AYByREUsQNMhgTUQAZrU=; b=EfEu6IGxq6jTUIyQhb8n5TWIQnES2G6tdMxE8bqr0HSqzaLaZsTVGCp1 52bngJ3r1wyfbJQzsMfymTk5YM3Izx8lyTQvz3t/yp58E+Bkiod9WyOEd R3mSl8HiradSetOOTnkMCC4ueaKmABKm1CvUM2a8aU7RmS3KhQPAAk3M5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAADyEFStJV2P/2dsb2JhbABggw1TW8hdgV8BCYdNAYERFniEAwEBAQQBAQFrGwIBGQMBAiQEBycLFAcCCAIEARKIQg2/RAEXjAuBPIE1AQE+FweDKYEdBZFJhDCHA4Ffk1qCG4FGbAGBDjmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,502,1406592000"; d="scan'208,217";a="354238949" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 11 Sep 2014 00:53:56 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s8B0rtoX010521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 00:53:55 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 19:53:55 -0500 From: "Acee Lindem (acee)" To: Jonathan Hardwick , Deborah Brungard , Routing Directorate Thread-Topic: [Idr] Routing Directorate Review of BGP Link-State Implementation Report - draft-ietf-idr-ls-distribution-impl-00 (Authors copied) Thread-Index: AQHPzVpOuz3l3Rp4nE6jG0zHGw01Qg== Date: Thu, 11 Sep 2014 00:53:54 +0000 Message-ID: References: <06858FA6-EE4D-4A42-9E51-51CD061B6BE4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.198] Content-Type: multipart/alternative; boundary="_000_F2665E625AD3406E94322539FC646151ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/KSRvGOptKkbe8nG-ZB-TqB9Vlyo Subject: [RTG-DIR] Fwd: [Idr] Routing Directorate Review of BGP Link-State Implementation Report - draft-ietf-idr-ls-distribution-impl-00 (Authors copied) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:53:59 -0000 --_000_F2665E625AD3406E94322539FC646151ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Forwarding rather than resending to avoid spamming the IDR list again (had = a bad Apple Mail cached address for rtg-dir@ietf.org)=85 Begin forwarded message: From: "Acee Lindem (acee)" > Subject: [Idr] Routing Directorate Review of BGP Link-State Implementation = Report - draft-ietf-idr-ls-distribution-impl-00 (Authors copied) Date: September 10, 2014 at 8:49:51 PM EDT To: Routing ADs > Cc: Routing Directorate >, IDR WG= List >, "Hannes Gredler" >, Balaji Rajagopalan >, Saikat Ray >, Manish Bhardwaj > Hi, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/t= rac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: BGP Link-State Information Distribution Implementation Report - = draft-ietf-idr-ls-distribution-impl-00 Reviewer: Acee Lindem Review Date: 09/10/2014 Current WG Document Intended Status: Informational Summary: This is an implementation report for the BGP LS protocol mechanism= s. The vendors were Cisco IOS-XR, Juniper JUNOS, and OpenDayLight. Basicall= y, the document is ready for informational publication. Major Issues: None Minor Issues: It would be good to state the scope of the test in the "Introduction" secti= on. At least, there should be a statement that solely the BGP advertisement= of Link-State information and its successful reception were tested. This i= s apparent from the testing results in the subsequent sections but it would= be good to state this up front. Nits: *** draft-ietf-idr-ls-distribution-impl-00.txt 2014-09-10 18:13:08.0000000= 00 -0400 --- draft-ietf-idr-ls-distribution-impl-acee.txt 2014-09-10 20:22= :21.000000000 -0400 *************** *** 621,627 **** Juniper: The Juniper Networks, Inc. JUNOS implementation should be interoperable with other vendor BGP-LS Protocol implementations. In ! particular, we have tested our interoperability with Cisco Systems, Inc. IOS-XR implementation and the Opendaylight implementation. 7.3. OpenDaylight Implementation --- 621,627 ---- Juniper: The Juniper Networks, Inc. JUNOS implementation should be interoperable with other vendor BGP-LS Protocol implementations. In ! particular, we have tested our interoperability with the Cisco Systems= , Inc. IOS-XR implementation and the Opendaylight implementation. 7.3. OpenDaylight Implementation *************** *** 630,637 **** with other vendor BGP-LS Protocol implementations. In particular, we have tested our interoperability with Juniper's JUNOS implementation and the Cisco Systems, Inc. IOS-XR implementation. BGP receiver is ! implemented in OpenDaylight Hydrogen release. BGP sender ! functionality is planned in upcoming Helium release. 8. IANA Considerations --- 630,637 ---- with other vendor BGP-LS Protocol implementations. In particular, we have tested our interoperability with Juniper's JUNOS implementation and the Cisco Systems, Inc. IOS-XR implementation. BGP receiver is ! implemented in the OpenDaylight Hydrogen release. BGP sender ! functionality is planned in the upcoming Helium release. 8. IANA Considerations *************** *** 645,651 **** 9. Security considerations ! No new security issues are introduced to the BGP Link-State Information Distribution Protocol defined in [I-D.ietf-idr-ls-distribution]. --- 645,651 ---- 9. Security considerations ! No new security issues are introduced by the BGP Link-State Information Distribution Protocol defined in [I-D.ietf-idr-ls-distribution]. Thanks, Acee _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_F2665E625AD3406E94322539FC646151ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <977EB04088DC7840819D001C70DD130B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Forwarding rather than resending to avoid spamming the IDR list again (had = a bad Apple Mail cached address for rtg-dir@ietf.org)=85 

Begin forwarded message:

From:= "Acee Lindem (ace= e)" <acee@cisco.com>
Subje= ct: [Idr] Routing Directorat= e Review of BGP Link-State Implementation Report - draft-ietf-idr-ls-distri= bution-impl-00 (Authors copied)
Date:= September 10, 2014 at = 8:49:51 PM EDT
To: <= /b>Routing ADs <rtg-ads@tools.ietf.org>
Cc: <= /b>Routing Directorate <= rtr-dir@ietf.org>, IDR WG List &= lt;idr@ietf.org>, "Hannes Gredler" <hanne= s@juniper.net>, Balaji Rajagopalan <balajir@juniper.net>, Saikat Ray <sairay@cisco.com>, Manish Bhardwaj <manbhard@cisco.com>

Hi,

I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information about the Routing Directorate, pleas= e see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.

Document:  BGP Link-State Information Distribution Implementation Repo= rt - draft-ietf-idr-ls-distribution-impl-00

Reviewer: Acee Lindem

Review Date: 09/10/2014

Current WG Document

Intended Status: Informational

Summary: This is an implementation report for the BGP LS protocol mechanism= s. The vendors were Cisco IOS-XR, Juniper JUNOS, and OpenDayLight. Basicall= y, the document is ready for informational publication.

Major Issues: None

Minor Issues:

It would be good to state the scope of the test in the "Introduction&q= uot; section. At least, there should be a statement that solely the BGP adv= ertisement of Link-State information and its successful reception were test= ed. This is apparent from the testing results in the subsequent sections but it would be good to state this up front.

Nits:
*** draft-ietf-idr-ls-distribution-impl-00.txt  2014-09-10 18:13:08.00= 0000000 -0400
--- draft-ietf-idr-ls-distribution-impl-acee.txt     &n= bsp;     2014-09-10 20:22:21.000000000 -0400
***************
*** 621,627 ****

   Juniper: The Juniper Networks, Inc. JUNOS implementation = should be
   interoperable with other vendor BGP-LS Protocol implement= ations.  In
!    particular, we have tested our interoperability with Ci= sco Systems,
   Inc. IOS-XR implementation and the Opendaylight implement= ation.

7.3.  OpenDaylight Implementation
--- 621,627 ----

   Juniper: The Juniper Networks, Inc. JUNOS implementation = should be
   interoperable with other vendor BGP-LS Protocol implement= ations.  In
!    particular, we have tested our interoperability with th= e Cisco Systems,
   Inc. IOS-XR implementation and the Opendaylight implement= ation.

7.3.  OpenDaylight Implementation
***************
*** 630,637 ****
   with other vendor BGP-LS Protocol implementations.  = In particular, we
   have tested our interoperability with Juniper's JUNOS imp= lementation
   and the Cisco Systems, Inc. IOS-XR implementation.  = BGP receiver is
!    implemented in OpenDaylight Hydrogen release.  BGP= sender
!    functionality is planned in upcoming Helium release.

8.  IANA Considerations
--- 630,637 ----
   with other vendor BGP-LS Protocol implementations.  = In particular, we
   have tested our interoperability with Juniper's JUNOS imp= lementation
   and the Cisco Systems, Inc. IOS-XR implementation.  = BGP receiver is
!    implemented in the OpenDaylight Hydrogen release.  = ;BGP sender
!    functionality is planned in the upcoming Helium release= .


8.  IANA Considerations
***************
*** 645,651 ****

9.  Security considerations

!    No new security issues are introduced to the BGP Link-S= tate
   Information Distribution Protocol defined in
   [I-D.ietf-idr-ls-distribution].

--- 645,651 ----

9.  Security considerations

!    No new security issues are introduced by the BGP Link-S= tate
   Information Distribution Protocol defined in
   [I-D.ietf-idr-ls-distribution].

Thanks,
Acee

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--_000_F2665E625AD3406E94322539FC646151ciscocom_-- From nobody Thu Sep 11 11:00:20 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25BB1A8A89; Thu, 11 Sep 2014 11:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 D2PpfNgzlUcq; Thu, 11 Sep 2014 11:00:12 -0700 (PDT) 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 2D4AB1A8A06; Thu, 11 Sep 2014 10:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38278; q=dns/txt; s=iport; t=1410458317; x=1411667917; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=KL0dmv6rTqe0FesPuoObcY6UFxhzoq5NAG2TFYGIZEg=; b=cWIyhfZ6h8F4m2h0lJJ7okgkpXSnK9cvfxW1lUPQqtqeFdEt2EtTGjZZ jAFjbufKN7I681EGRHtxbCXPyAXUHLm6PVpqt6sbdtxyWf6qdi4MvM7Qm SwIcIiJF6dzqMuMy0dnPq8QcPiCSqm1wTIzECkaldpqe9WKdV26UPkVtR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFADjiEVStJV2b/2dsb2JhbABVCoMNU1cEgnjFUYdNGngWeIQEAQEEGhozEhIBCBgEKAQwJwQOBRuIJw2MYpw9BpVTAReBJohahHEFJBgbgnqBWQWRS4ZwhEaVO4FnCBYWgUZsAQGBBUGBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,506,1406592000"; d="scan'208";a="354572052" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 11 Sep 2014 17:58:35 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8BHwZor022038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 17:58:35 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 12:58:35 -0500 From: "Acee Lindem (acee)" To: Hannes Gredler Thread-Topic: Routing Directorate Review of draft-ietf-idr-ls-distribution-05.txt (Reply to this one) Thread-Index: AQHPzeoBVo5C9YidS0GyR46JmNf+XQ== Date: Thu, 11 Sep 2014 17:58:34 +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: text/plain; charset="euc-kr" Content-ID: <43DF6EB10C3D7348853E1D238E3B21A2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/SA-1CvWw0chdlIqM-4Sqd8jpWH8 Cc: IDR WG List , Deborah Brungard , Routing Directorate , Adrian Farrel , "Jan Medved \(jmedved\)" , "Stefano Previdi \(sprevidi\)" , Routing ADs , Jonathan Hardwick , "Saikat Ray \(sairay\)" Subject: Re: [RTG-DIR] Routing Directorate Review of draft-ietf-idr-ls-distribution-05.txt (Reply to this one) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 18:00:17 -0000 SGkgSGFubmVzLCANCg0KT24gOS8xMC8xNCwgMzoyMCBBTSwgIkhhbm5lcyBHcmVkbGVyIiA8aGFu bmVzQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPmhpIGFjZWUsDQo+DQo+dGhhbmtzIGZvciByZXZp ZXdpbmcgdGhlIGRvY3VtZW50IHRob3JvdWdobHkuIHNlZSBjb21tZW50cy9yZXNwb25zZXMNCj5p bmxpbmUuDQo+DQo+T24gVHVlLCBTZXAgMDksIDIwMTQgYXQgMTE6MzM6MTBQTSArMDAwMCwgQWNl ZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPnwgTWFqb3IgSXNzdWVzOg0KPnwgDQo+fCAgIDEuIFRo ZSBkcmFmdCBzaG91bGQgaW5kaWNhdGUgdGhlIG92ZXJhbGwgZ29hbCBvZiB0cmFuc2xhdGluZyB0 aGUgSUdQDQo+bGluayBzdGF0ZSBkYXRhYmFzZSBhbmQgVEUgRGF0YWJhc2UgaW50byBhIGdlbmVy aWMgcmVwcmVzZW50YXRpb24uIEl0DQo+c2hvdWxkIGFsc28gYmV0dGVyIGVudW1lcmF0ZSB0aGUg cmVxdWlyZW1lbnRzIGZvciB0aGlzIHRyYW5zbGF0aW9uLg0KPg0KPm1haW4gcmVhc29uIGlzIHRv IHNwYXJlIHRoZSBjb250cm9sbGVycyB0aGUgbmVlZCBvZiBhbHd5cyByZXF1aXJpbmcgdG8NCj51 bmRlcnN0YW5kIHR3byBwcm90b2NvbHMuDQo+QUk6IGknbGwgYWRkIGEgbm90ZS4NCg0KQWxzbywg YSBzaW5nbGUgcmVwcmVzZW50YXRpb24gd2lsbCBlbmFibGUgcG9saWN5IG9uIHRoZSByZWNlaXZl ci4NCg0KDQoNCj4NCj58ICAgMi4gVGhlIGRyYWZ0IGluY2x1ZGVzIG9wYXF1ZSBhdHRyaWJ1dGUg VExWcyBmb3IgYWR2ZXJ0aXNpbmcNCj5wcm90b2NvbC1zcGVjaWZpYyBpbmZvcm1hdGlvbiAobm9k ZSwgbGluaywgYW5kIHByZWZpeCkuIEhvd2V2ZXIsIHRoZXJlIGlzDQo+bm8gaW5kaWNhdGlvbiBv biBob3cgdGhpcyBpbmZvcm1hdGlvbiBpcyBlbmNvZGVkIG9yIGlkZW50aWZpZWQuIEhlbmNlLA0K PnRoZXJlIGNhbiBiZSBubyBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gaW1wbGVtZW50YXRpb25z Lg0KPg0KPndlIGhhdmUgZGVmaW5lZCBvcGFxdWUgY29udGFpbmVycyBmb3IgdGhlIGRvY3VtZW50 IGxhZyBiZXR3ZWVuIGRlZmluaW5nDQo+DQo+MSkgYSBuZXcgSUdQIGV4dGVuc2lvbg0KPjIpIHRo ZSBCR1AgZXh0ZW5zaW9uIGJlaW5nIHB1Ymxpc2hlZA0KPg0KPml0IGlzIGV4cGVjdGVkIHRoYXQg dGhvc2Ugb3BhcXVlIGNhcnJpZXJzIGFyZSBvbmx5IHVzZWQNCj5pbiB2ZW5kb3IgcHJpdmF0ZSBl eHRlbnNpb25zLg0KPkFJOiBpJ2xsIGFkZCBhIG5vdGUNCg0KR3JlYXQuIA0KDQoNCg0KPg0KPnwg ICAzLiBUaGUgZHJhZnQgaXMgYmFzZWQgbWFpbmx5IG9uIElTSVMgZW5jb2RpbmcgYW5kIGRvZXMg YSBwb29yIGpvYiBvZg0KPnJlcHJlc2VudGluZyB0aGUgT1NQRi4gRXhhbXBsZXMgaW5jbHVkZToN Cj4NCj50aGUgZHJhZnQgaXMgYSAicHJvdG9jb2wgbmV1dHJhbCIgcmVwcmVzZW50YXRpb24gb2Yg bm9kZS9saW5rcyBhbmQNCj5wcmVmaXhlcy4NCj53aGVyZXZlciBwb3NzaWJsZSB3ZSBoYXZlIHB1 dCBpbiByZWZlcmVuY2UgdG8gdGhlIG1lc3NhZ2UgZm9ybWF0DQo+b2YgdGhlIG9yaWdpbmFsIElT LUlTIHNwZWMgYXMgd2UgZm91bmQgaXQgZ2VuZXJhbGx5IGVhc2llciB0byByZWFkIChzb3JyeQ0K PmFjZWUpLg0KPnRoZXJlIGlzIG5vIHBvaW50IG9mIGFkZGluZyBhIHNlY29uZCBwb2ludGVyIHRv IHRoZSByZWx2YW50IE9TUEYgc3BlYy4NCj5hcyBzb21ldGltZXMgdGhlIGZvcm1hdCBvZiB0aG9z ZSBPU1BGLVRMVnMgZGlmZmVycyBmcm9tIElTLUlTDQo+DQo+fCAgICAgQS4gUGFnZSAxMCAtIFRo ZXJlIGlzIG5vIHByb3RvY29sLWlkIGZvciBPU1BGdjMuDQo+DQo+QUk6IGknbGwgYWRkIGEgcHJv dG9jb2wgY29kZSBmb3IgaXQuDQo+DQo+fCAgICAgQi4gUGFnZSAxMSAtIFdoeSBpcyBSRkMgNjgy MiBub3JtYXRpdmUgYW5kIFJGQyA2NTQ5IGluZm9ybWF0aW9uYWw/DQo+DQo+QUk6IGknbGwgbW92 ZSBpdCBpbnRvIG5vcm1hdGl2ZS4NCj4NCj58ICAgICBDLiBQc3VlZG9ub2RlIFJlcHJlc2VudGF0 aW9uIC0gVGhlIGFic2VuY2Ugb2YgYSBjb25kZW5zZWQgZm9ybWF0DQo+Zm9yIHRoZSBwc2V1ZG9u b2RlIGZvbGxvd2luZyB0aGUgT1NQRiBtb2RlbC4NCj4NCj5BSTogaSdsbCBhZGQgYW4gT1NQRiBl eGFtcGxlIGFmdGVyIHNlY3Rpb24gMy42Lg0KDQpUaGUgZXhhbXBsZSB3b3VsZCByZXN1bHQgaW4g dGhlIHNhbWUgQkdQIExTLiBNeSBwb2ludCB3YXMgdGhhdCBPU1BGqfZzDQpOZXR3b3JrLUxTQSBy ZXByZXNlbnRhdGlvbiBpcyBzaWduaWZpY2FudGx5IG1vcmUgY29tcGFjdCBhbmQgc2F0aXNmaWVz IHRoZQ0KcHNldWRvbm9kZSByZXF1aXJlbWVudC4NCg0KDQoNCj4NCj58ICAgICBELiBQYWdlIDE1 IC0gUmVsZXZhbnQgT1NQRiBSRkNzIHNob3VsZCBiZSByZWZlcmVuY2VkIGZvciBUTFYgY29kZQ0K PnBvaW50cy4NCj4NCj50aGVyZSBpcyBubyBzaW5nbGUgT1NQRiBSRkMgcmVwcmVzZW50aW5nIHRo ZSBpbmZvcm1hdGlvbiB3aGljaCBpcyBlbmNvZGVkDQo+aGVyZS4NCj5hZ2FpbiAtIHRoaXMgaXMg bm90IGEgbGV0cyB3cmFwIE9TUEYgYW5kIElTLUlTIHNwZWMgLSBpdCBpcyBhIHByb3RvY29sDQo+ bmV1dHJhbCByZXByZXNlbnRhdGlvbiBvZiBub2RlcywgbGlua3MgYW5kIHByZWZpeGVzIC0gaWYg dGhlIEJHUC1MUw0KPm1lc3NhZ2UgZm9ybWF0IGlzIGlkZW50aWNhbCB0byBJUy1JUyB3ZSBoYXZl IHBpY2tlZCBJU19JUyBhcyBhIHJlZmVyZW5jZS4NCj4NCj58ICAgICBFLiBQYWdlIDE4IC0gV2h5 IGFuIElTSVMgQXJlYSBpZGVudGlmaWVyIGFuZCBub3QgYW4gT1NQRiBBcmVhDQo+aWRlbnRpZmll cj8NCj4NCj50aGVyZSBpcyAtIHNlZSBUTFYgNTE0DQo+QUk6IGknbGwgcmVuYW1lIDUxNCBhcyAn T1NQRiBBcmVhLUlEJw0KPg0KPnwgICAgIEYuIFBhZ2UgMTggLSAnRScgaXMgZm9yIGFuIEFTQlIg YW5kICdCJyBpcyBmb3IgQUJSLg0KPg0KPkFJOiBjaGFuZ2UgdGhlIG5hbWUgYnV0IGtlZXAgdGhl IGJpdCB2YWx1ZS4NCg0KU3VyZSAtIHRoZXNlIHNob3VsZCBtYXRjaCBSRkMgMjMyOC4NCg0KPg0K PnwgICAgIEcuIFBhZ2UgMTkgLSBSRkMgNTY0MiBpcyB0aGUgT1NQRiBOb2RlIE5hbWUgUkZDLg0K Pg0KPnNlZSBhbnN3ZXIgdG8gY29tbWVudCAzKS4NCj4NCj58ICAgICBILiBQYWdlIDIxIC0gU2hv dWxkIGJlIHJlZmVyZW5jZXMgdG8gT1NQRiBSRkMsIFJGQyAzNjMwLCBSRkMgNDIwMywNCj5hbmQg UkZDIDUzMjkuIA0KPg0KPnNlZSBhbnN3ZXIgdG8gY29tbWVudCAzKS4NCj4NCj58ICAgICBJLiBQ YWdlIDIyIC0gT1NQRiBMaW5rIG1ldHJpY3MgYXJlIDIgYnl0ZXMgYnV0IE9TUEYgcHJlZml4IG1l dHJpY3MNCj5hcmUgMyBieXRlcy4NCj4NCj50aGF0cyB3aHkgdGhlICdJR1AgbWV0cmljJyBpcyB2 YXJpYWJsZSBsZW5ndGguDQoNClRoYXQgZG9lc26p9nQgbWVhbiB0aGUgZHJhZnQgc2hvdWxkIGhh dmUgaW5jb3JyZWN0IGluZm9ybWF0aW9uLg0KDQoNCg0KPg0KPnwgICAgIEouIFBhZ2UgMjUgLSBP U1BGIFByZWZpeCBPcHRpb25zIGFyZSBkZWZpbmVkIGluIFJGQyA1MzQwLCBBLjQuMS4xLg0KPkl0 IG5vdCBjbGVhciB3aGljaCBuZWVkIHRvIGJlIGFkdmVydGlzZWQuDQo+DQo+Z29vZCBwb2ludCAt IA0KPkFJOiBhZGQgYSByZWZlcmVuY2UgdG8gcmZjNTM0MCBhbmQgY29weSB0ZWggZmxhZ3MgZGVz Y3JpcHRpb25zDQo+DQo+fCAgICAgSy4gUGFnZSAyNiAtIEZvcndhcmRpbmcgQWRkcmVzcyBmb3Ig T1NQRnYzIHNob3VsZCByZWZlcmVuY2UgUkZDDQo+NTM0MCBhcyB3ZWxsLg0KPg0KPkFJOiBhZGQg cmVmZXJlbmNlDQo+DQo+fCAgIDQuIFNlY3Rpb24gMy4yLjE1IC0gV2h5IGRvIHlvdSBsaW1pdCBh IGxpbmsgb3IgcHJlZml4IHRvIGEgc2luZ2xlDQo+TVQtSUQ/IExpbmtzIGFuZCBwcmVmaXhlcyBj YW4gYmUgcmVhY2hhYmxlIGluIG11bHRpcGxlIHRvcG9sb2dpZXMgd2l0aA0KPmRpZmZlcmVudCBt ZXRyaWNzLiBJcyB0aGlzIHNpbXBseSBhIHR5cG8/DQo+DQo+dGhlcmUgaXMgbm8gbGltaXQgdG8g YSBzaW5nbGUgTVQtSUQsIHRoZSBwcm92aWRlZCByZWZlcmVuY2VzIGFzIHdlbGwNCj5hcyB0aGUg VExWIHNpemlpbmcgKE4qIC4uLikgaW5kaWNhdGUgdGhhdCB0aGlzIGlzIGEgdmFyaWFibGUNCj5s ZW5ndGggVExWLg0KPg0KPkFJOiBhZGQgdGV4dCB0byBzYXkgdGhhdCB0aGlzIFRMViBpcyB1c2Vk IHRvIGFkdmVydGlzZSBtZW1lYmVyc2hpcCBpbg0KPidvbmUgb3IgbW9yZScgDQo+ICAgIHRvcG9s b2dpZXMuDQoNClRoaXMgd2FzIGluIHJlc3BvbnNlIHRvIHRoaXMgdGV4dDoNCg0KICAgVGhlIE1U LUlEIFRMViBNQVkgYmUgcHJlc2VudCBpbiBhIExpbmsgRGVzY3JpcHRvciwgYSBQcmVmaXgNCiAg IERlc2NyaXB0b3IsIG9yIGluIHRoZSBCR1AtTFMgYXR0cmlidXRlIG9mIGEgbm9kZSBOTFJJLiBJ biBMaW5rIG9yDQogICBQcmVmaXggRGVzY3JpcHRvciwgb25seSBvbmUgTVQtSUQgVExWIGNvbnRh aW5pbmcgb25seSB0aGUgTVQtSUQgb2YNCiAgIHRoZSB0b3BvbG9neSB3aGVyZSB0aGUgbGluayBv ciB0aGUgcHJlZml4IGJlbG9uZ3MgaXMgYWxsb3dlZC4NCg0KDQpIb3dldmVyLCBpZiB5b3UgY2hh bmdlIHRoaXMsIGl0IHN0aWxsIGRvZXNuqfZ0IHNvbHZlIHRoZSBzYXRpc2Z5IHRoZQ0KcmVxdWly ZW1lbnQgb2YgYSBzZXBhcmF0ZSBtZXRyaWMgcGVyIHRvcG9sb2d5IGZvciBsaW5rcyBhbmQgcHJl Zml4ZXMuDQoNCj4NCj58IE1pbm9yIElzc3VlczoNCj58ICAgMS4gRmlndXJlcyBhbmQgdGFibGVz IGFyZSByZWZlcmVuY2VkIGJ5IG51bWJlciwgeWV0IHRob3NlIGZpZ3VyZXMgYW5kDQo+dGFibGVz IGFyZSBub3QgbnVtYmVyZWQuDQo+DQo+dGhhdHMgYW4gYXJ0aWZhY3Qgb2YgeG1sMnJmYyBvbiBt YWMgLSBpJ2xsIHJlbmRlciB0aGUgbmV4dCB2ZXJzaW9uIHVuZGVyDQo+dW5peCB3aGljaCBoYXMg Z290dGVuIGl0IHJpZ2h0Lg0KDQpJIGRvbqn2dCB0aGluayB0aGlzIGlzIGEgcHJvYmxlbSB3aXRo IG1hYyAtIGl0IGlzIGp1c3QgYSB0Y2wgc2NyaXB0LiBTbywNCnVubGVzcyB5b3UgaGF2ZSBhIHZl cnkgb2xkIFhjb2RlIHBhY2thZ2UgaW5zdGFsbGVkIGFuZCB0aGVyZSBpcyBhIHRjbCBidWcsDQpp dCBpcyBzaG91bGQgbm90IGJlIGEgcHJvYmxlbS4gWW91IGNhbiBkb3dubG9hZCB0aGUgbGF0ZXN0 IHZlcnNpb24gb2YNCnhtbDJyZmMgdGhvdWdoLiANCg0KDQo+DQo+fCAgIDIuIFNldmVyYWwgYWNy b255bW5zIHRoYXQgYXJlIG5vdCBkZXNpZ25hdGVkIGFzIHdlbGwta25vd24gYXJlIG5vdA0KPmV4 cGFuZGVkIHdpdGggdGhlIGZpcnN0IHVzYWdlLiBFeGFtcGxlcyBpbmNsdWRlIExTREIgYW5kIFRF RC4gUmVmZXIgdG8NCj5odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy1zdHlsZS1ndWlkZS9h YmJyZXYuZXhwYW5zaW9uLnR4dC4NCj4NCj5BSTogbGV0IG1lIGZpeCB0aGF0DQo+DQo+fCAgIDMu IFBhZ2UgMTEgLSBUaGUgdGFibGUgbWVudGlvbnMgTDEgb3B0aWNhbCB0b3BvbG9neSBidXQgdGhl cmUgYXJlIGFyZQ0KPm5vIG9wdGljYWwgYXR0cmlidXRlcy4gVGhpcyBzZWVtcyBsaWtlIGl0IHNo b3VsZCBiZSByZW1vdmVkIGFuZCBhZGRlZA0KPndoZW4gR01QTFMgaW5mb3JtYXRpb24gaXMgZGVm aW5lZCBmb3IgQkdQIExTLg0KPg0KPndlIGRpZCB3YW50IHRvIGxvY2sgdGhlIGNvZGVwb2ludCBh cyBzb21lIGFyZSBtb2NraW5nIHdpdGggQkdQLUxTIGFzIGFuDQo+Tk5JIHByb3RvY29sIA0KPmZv ciBvcHRpY2FsLiAtDQoNClRoZW4geW91IHNob3VsZCBhZGQgYSByZWdpc3RyeSBmb3IgdGhlIHBy b3RvY29sIElEcy4gU2luY2UgdGhpcyBpcyBhIG5ldw0KZmllbGQsIHlvdSBkb26p9nQgaGF2ZSB0 byB3b3JyeSBhYm91dCBvdGhlcnMgYXNzaWduaW5nIHZhbHVlcy4NCg0KDQoNCj4gDQo+DQo+fCAg IDQuIFBhZ2UgMTEgLSBUaGUgQkdQLUxTIElkZW50aWZpZXIgaXMgcmVmZXJlbmNlZCBiZWZvcmUg aXQgaXMNCj5kZWZpbmVkLiANCj4NCj5BSTogYWRkIGEgZm9yd2FyZCByZWZlcmVuY2UgaW4gc2Vj dGlvbiAzLjIuMS40DQo+DQo+fCAgIDUuIFBhZ2UgMTcgLSBJbiB0aGUgY29udGV4dCBvZiB0aGlz IE5STEksIHdoYXQgcHVycG9zZSBkb2VzIHRoZSBuZXh0DQo+aG9wIGFkZHJlc3Mgc2VydmU/IElm IG5vbmUsIGNvdWxkbid0IHdlIGp1c3QgYWR2ZXJ0aXNlIGEgMCBsZW5ndGggbmV0d29yaw0KPmFk ZHJlc3M/IA0KPg0KPkFJOiBhZGQgY2xhcmlmaWNhdGlvbiB0ZXh0IHRoYXQgdGhlIEJHUC1OSCBz ZXJ2ZXMgc29sZWx5IHRoZSBwdXJwb3NlIG9mDQo+QkdQIHBhdGggdGllLWJyZWFraW5nDQo+ICAg IGJhc2VkIG9uIElHUCBkaXN0YW5jZS4NCj4NCj58ICAgNi4gUGFnZSAxOCAtIFdoeSBpc24ndCB0 aGUgSVMtSVMgQXJlYSBJZGVudGlmaWVyIGFwcGxpY2FibGUgdG8NCj5wcmVmaXhlcz8gT1NQRiBj YW4gc2NvcGUgcHJlZml4ZXMgdG8gYXJlYXMgKHVubGVzcyB0aGV5IEFTLUV4dGVybmFsKS4NCj4N Cj5kaWZmZXJlbnQgc2NoZW1hcyAtIGluIElTLUlTIGFuIEFyZWEgaXMgYW4gYXR0cmlidXRlIG9m IGEgbm9kZSwgdnMuIGluDQo+T1NQRiBpdHMgYW4gYXR0cmlidXRlIG9mIGFuIGludGVyZmFjZS4N Cg0KQnV0IGFib3ZlIHlvdSBzYWlkIHlvdSB3ZXJlIGdvaW5nIHRvIG1ha2UgdGhpcyBhbiBPU1BG IEFyZWEgSUQgVExWPw0KDQoNCj4NCj58ICAgNy4gRm9yIEZRRE4gbm9kZS9saW5rIG5hbWUgcmVj b21tZW5kYXRpb24gLSBzaG91bGQgdXNhZ2UgZGljdGF0ZQ0KPiJSRUNPTU1FTkRFRCIgcmF0aGVy IHRoYW4gInJlY29tbWVuZGVkqfc/DQo+DQo+QUk6IFJFQ09NTUVOREUNCj4NCj58ICAgOC4gUGFn ZSAyMSAtIElzIGtub3dpbmcgd2hldGhlciBNUExTIHNpZ25hbGluZyBpcyBlbmFibGVkIG9uIGEg bGluaw0KPmFsbCB0aGF0IGlzIG5lZWRlZCBieSB0aGUgYXBwbGljYXRpb25zPyBUaGlzIHNlZW1z IHNvbWV3aGF0IG91dCBvZiBwbGFjZQ0KPndpdGggdGhlIExTREIgYW5kIFRFIGRhdGEuDQo+DQo+ dGhhdHMgdXNlIHdoZW4gdGhlIEJHUC1MUyBkYXRhIGFyZSBub3QgZ2VuZXJhdGVkIGJ5IHJlZGlz dGlidXRpb24gb2YgYW4NCj5MU0RCIG9yIFRFRCBidXQNCj5yYXRoZXIgaXMgZ2VuZXJhdGVkICdk aXJlY3QnICh1c2luZyBwcm90b2NvbCBjb2RlICdkaXJlY3QnKSAtIGkuZS4gZXZlcnkNCj5ub2Rl DQo+aW5hIGFuIElHUCBkb21haW4gYmVjb21lcyBhIHB1Ymxpc2hlciBvZiBpdHMgbG9jYWwgbGlu ay1zdGF0ZSBkYXRhLg0KPg0KPkFJOiBhZGQgYSBub3RlIHRoYXQgdGhpcyBvbmx5IGFwcGxpZXMg Zm9yIGdlbmVyYXRpb24gb2YgdXNpbmcgcHJvdG9jb2wNCj4nZGlyZWN0Jw0KDQpPaw0KDQpUaGFu a3MsDQpBY2VlIA0KDQoNCg0KPg0KPnwgTml0czogDQo+fCANCj58ICoqKioqKioqKioqKioqKg0K PnwgKioqIDIxLDI3ICoqKioNCj58ICAgICAgY2FsbGVkIHVwb24gdG8gcGVyZm9ybSBjb21wdXRh dGlvbnMgYmFzZWQgb24gdGhlIG5ldHdvcmsgdG9wb2xvZ3kNCj5hbmQNCj58ICAgICAgY3VycmVu dCBzdGF0ZSBvZiB0aGUgY29ubmVjdGlvbnMgd2l0aGluIHRoZSBuZXR3b3JrLCBpbmNsdWRpbmcN Cj58ICAgICAgdHJhZmZpYyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbi4gIFRoaXMgaXMgaW5mb3Jt YXRpb24gdHlwaWNhbGx5DQo+fCAhICAgIGRpc3RyaWJ1dGVkIGJ5IElHUCByb3V0aW5nIHByb3Rv Y29scyB3aXRoaW4gdGhlIG5ldHdvcmsNCj58ICAgDQo+fCAgICAgIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIGxpbmtzIHN0YXRlIGFuZA0KPnRyYWZmaWMNCj58 ICAgICAgZW5naW5lZXJpbmcgaW5mb3JtYXRpb24gY2FuIGJlIGNvbGxlY3RlZCBmcm9tIG5ldHdv cmtzIGFuZCBzaGFyZWQNCj58IC0tLSAyMSwyNyAtLS0tDQo+fCAgICAgIGNhbGxlZCB1cG9uIHRv IHBlcmZvcm0gY29tcHV0YXRpb25zIGJhc2VkIG9uIHRoZSBuZXR3b3JrIHRvcG9sb2d5DQo+YW5k DQo+fCAgICAgIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGNvbm5lY3Rpb25zIHdpdGhpbiB0aGUgbmV0 d29yaywgaW5jbHVkaW5nDQo+fCAgICAgIHRyYWZmaWMgZW5naW5lZXJpbmcgaW5mb3JtYXRpb24u ICBUaGlzIGlzIGluZm9ybWF0aW9uIHR5cGljYWxseQ0KPnwgISAgICBkaXN0cmlidXRlZCBieSBJ R1Agcm91dGluZyBwcm90b2NvbHMgd2l0aGluIHRoZSBuZXR3b3JrLg0KPnwgICANCj58ICAgICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gYnkgd2hpY2ggbGlua3Mgc3RhdGUg YW5kDQo+dHJhZmZpYw0KPnwgICAgICBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbiBjYW4gYmUgY29s bGVjdGVkIGZyb20gbmV0d29ya3MgYW5kIHNoYXJlZA0KPnwgKioqKioqKioqKioqKioqDQo+fCAq KiogMjQ2LDI1MiAqKioqDQo+fCAgICAgIHJvdXRlcnMgaW4gYSBQT1AuIEFic3RyYWN0ZWQgdG9w b2xvZ3kgY2FuIGFsc28gYmUgYSBtaXggb2YgcGh5c2ljYWwNCj58ICAgICAgYW5kIHZpcnR1YWwg bm9kZXMgYW5kIHBoeXNpY2FsIGFuZCB2aXJ0dWFsIGxpbmtzLiAgRnVydGhlcm1vcmUsIHRoZQ0K PnwgICAgICBCR1AgU3BlYWtlciBjYW4gYXBwbHkgcG9saWN5IHRvIGRldGVybWluZSB3aGVuIGlu Zm9ybWF0aW9uIGlzDQo+dXBkYXRlZA0KPnwgISAgICB0byB0aGUgY29uc3VtZXIgc28gdGhhdCB0 aGVyZSBpcyByZWR1Y3Rpb24gb2YgaW5mb3JtYXRpb24gZmxvdyBmb3JtDQo+fCAgICAgIHRoZSBu ZXR3b3JrIHRvIHRoZSBjb25zdW1lcnMuICBNZWNoYW5pc21zIHRocm91Z2ggd2hpY2ggdG9wb2xv Z2llcw0KPnwgICAgICBjYW4gYmUgYWdncmVnYXRlZCBvciB2aXJ0dWFsaXplZCBhcmUgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpcw0KPnwgICAgICBkb2N1bWVudA0KPnwgLS0tIDI0NiwyNTIgLS0t LQ0KPnwgICAgICByb3V0ZXJzIGluIGEgUE9QLiBBYnN0cmFjdGVkIHRvcG9sb2d5IGNhbiBhbHNv IGJlIGEgbWl4IG9mIHBoeXNpY2FsDQo+fCAgICAgIGFuZCB2aXJ0dWFsIG5vZGVzIGFuZCBwaHlz aWNhbCBhbmQgdmlydHVhbCBsaW5rcy4gIEZ1cnRoZXJtb3JlLCB0aGUNCj58ICAgICAgQkdQIFNw ZWFrZXIgY2FuIGFwcGx5IHBvbGljeSB0byBkZXRlcm1pbmUgd2hlbiBpbmZvcm1hdGlvbiBpcw0K PnVwZGF0ZWQNCj58ICEgICAgdG8gdGhlIGNvbnN1bWVyIHNvIHRoYXQgdGhlcmUgaXMgcmVkdWN0 aW9uIG9mIGluZm9ybWF0aW9uIGZsb3cgZnJvbQ0KPnwgICAgICB0aGUgbmV0d29yayB0byB0aGUg Y29uc3VtZXJzLiAgTWVjaGFuaXNtcyB0aHJvdWdoIHdoaWNoIHRvcG9sb2dpZXMNCj58ICAgICAg Y2FuIGJlIGFnZ3JlZ2F0ZWQgb3IgdmlydHVhbGl6ZWQgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMNCj58ICAgICAgZG9jdW1lbnQNCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDI2Nywy NzggKioqKg0KPnwgICAgICAgICBwb2xpY3kgY29udHJvbCBhbmQgYWxnb3JpdGhtcywgYW5kIGNv b3JkaW5hdGlvbiBvZiBjb21wdXRhdGlvbg0KPnwgICAgICAgICBhY3Jvc3MgdGhlIHdob2xlIGFy ZWEuDQo+fCAgIA0KPnwgISAgICBvICBJZiBhIHJvdXRlciB3YW50cyB0byBjb21wdXRlIGEgTVBM Uy1URSBwYXRoIGFjcm9zcyBJR1AgYXJlYXMgaXRzDQo+fCAgICAgICAgIG93biBURUQgbGFja3Mg dmlzaWJpbGl0eSBvZiB0aGUgY29tcGxldGUgdG9wb2xvZ3kuICBUaGF0IG1lYW5zDQo+fCAgICAg ICAgIHRoYXQgdGhlIHJvdXRlciBjYW5ub3QgZGV0ZXJtaW5lIHRoZSBlbmQtdG8tZW5kIHBhdGgs IGFuZCBjYW5ub3QNCj58ICAgICAgICAgZXZlbiBzZWxlY3QgdGhlIHJpZ2h0IGV4aXQgcm91dGVy IChBcmVhIEJvcmRlciBSb3V0ZXIgLSBBQlIpIGZvcg0KPnwgICAgICAgICBhbiBvcHRpbWFsIHBh dGguICBUaGlzIGlzIGFuIGlzc3VlIGZvciBsYXJnZS1zY2FsZSBuZXR3b3JrcyB0aGF0DQo+fCAh ICAgICAgIG5lZWQgdG8gc2VnbWVudCB0aGVpciBjb3JlIG5ldHdvcmtzIGludG8gZGlzdGluY3Qg YXJlYXMsIGJ1dA0KPndoaWNoDQo+fCAgICAgICAgIHN0aWxsIHdhbnQgdG8gdGFrZSBhZHZhbnRh Z2Ugb2YgTVBMUy1URS4NCj58ICAgDQo+fCAgICAgIFByZXZpb3VzIHNvbHV0aW9ucyB1c2VkIHBl ci1kb21haW4gcGF0aCBjb21wdXRhdGlvbiBbUkZDNTE1Ml0uICBUaGUNCj58IC0tLSAyNjcsMjc5 IC0tLS0NCj58ICAgICAgICAgcG9saWN5IGNvbnRyb2wgYW5kIGFsZ29yaXRobXMsIGFuZCBjb29y ZGluYXRpb24gb2YgY29tcHV0YXRpb24NCj58ICAgICAgICAgYWNyb3NzIHRoZSB3aG9sZSBhcmVh Lg0KPnwgICANCj58ICEgICAgbyAgSWYgYSByb3V0ZXIgd2FudHMgdG8gY29tcHV0ZSBhbiBNUExT LVRFIHBhdGggYWNyb3NzIG11bHRpcGxlDQo+SUdQIA0KPnwgISAgICAgICBhcmVhcywgdGhlbiBp dHMNCj58ICAgICAgICAgb3duIFRFRCBsYWNrcyB2aXNpYmlsaXR5IG9mIHRoZSBjb21wbGV0ZSB0 b3BvbG9neS4gIFRoYXQgbWVhbnMNCj58ICAgICAgICAgdGhhdCB0aGUgcm91dGVyIGNhbm5vdCBk ZXRlcm1pbmUgdGhlIGVuZC10by1lbmQgcGF0aCwgYW5kIGNhbm5vdA0KPnwgICAgICAgICBldmVu IHNlbGVjdCB0aGUgcmlnaHQgZXhpdCByb3V0ZXIgKEFyZWEgQm9yZGVyIFJvdXRlciAtIEFCUikg Zm9yDQo+fCAgICAgICAgIGFuIG9wdGltYWwgcGF0aC4gIFRoaXMgaXMgYW4gaXNzdWUgZm9yIGxh cmdlLXNjYWxlIG5ldHdvcmtzIHRoYXQNCj58ICEgICAgICAgbmVlZCB0byBzZWdtZW50IHRoZWly IGNvcmUgbmV0d29ya3MgaW50byBkaXN0aW5jdCBhcmVhcywgYnV0DQo+fCAgICAgICAgIHN0aWxs IHdhbnQgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgTVBMUy1URS4NCj58ICAgDQo+fCAgICAgIFByZXZp b3VzIHNvbHV0aW9ucyB1c2VkIHBlci1kb21haW4gcGF0aCBjb21wdXRhdGlvbiBbUkZDNTE1Ml0u ICBUaGUNCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDQyNiw0MzQgKioqKg0KPnwgICAgICAo dGh1cyBhIFRMViB3aXRoIG5vIHZhbHVlIHBvcnRpb24gd291bGQgaGF2ZSBhIGxlbmd0aCBvZiB6 ZXJvKS4gVGhlDQo+fCAgICAgIFRMViBpcyBub3QgcGFkZGVkIHRvIGZvdXItb2N0ZXQgYWxpZ25t ZW50LiAgVW5yZWNvZ25pemVkIHR5cGVzIGFyZQ0KPnwgICAgICBwcmVzZXJ2ZWQgYW5kIHByb3Bh Z2F0ZWQuICBJbiBvcmRlciB0byBjb21wYXJlIE5MUklzIHdpdGggdW5rbm93bg0KPnwgISAgICBU TFZzIGFsbCBUTFZzIE1VU1QgYmUgb3JkZXJlZCBpbiBhc2NlbmRpbmcgb3JkZXIuICBJZiB0aGVy ZSBhcmUNCj5tb3JlDQo+fCAgICAgIFRMVnMgb2YgdGhlIHNhbWUgdHlwZSwgdGhlbiB0aGUgVExW cyBNVVNUIGJlIG9yZGVyZWQgaW4gYXNjZW5kaW5nDQo+fCAhICAgIG9yZGVyIG9mIHRoZSBUTFYg dmFsdWUgd2l0aGluIHRoZSBzZXQgb2YgVExWcyB3aXRoIHRoZSBzYW1lIHR5cGUuDQo+fCAgICAg IEFsbCBUTFZzIHRoYXQgYXJlIG5vdCBzcGVjaWZpZWQgYXMgbWFuZGF0b3J5IGFyZSBjb25zaWRl cmVkDQo+b3B0aW9uYWwuDQo+fCAgIA0KPnwgICAzLjIuICBUaGUgTGluay1TdGF0ZSBOTFJJDQo+ fCAtLS0gNDI3LDQzNSAtLS0tDQo+fCAgICAgICh0aHVzIGEgVExWIHdpdGggbm8gdmFsdWUgcG9y dGlvbiB3b3VsZCBoYXZlIGEgbGVuZ3RoIG9mIHplcm8pLiBUaGUNCj58ICAgICAgVExWIGlzIG5v dCBwYWRkZWQgdG8gZm91ci1vY3RldCBhbGlnbm1lbnQuICBVbnJlY29nbml6ZWQgdHlwZXMgYXJl DQo+fCAgICAgIHByZXNlcnZlZCBhbmQgcHJvcGFnYXRlZC4gIEluIG9yZGVyIHRvIGNvbXBhcmUg TkxSSXMgd2l0aCB1bmtub3duDQo+fCAhICAgIFRMVnMsIGFsbCBUTFZzIE1VU1QgYmUgaW4gYXNj ZW5kaW5nIG9yZGVyIGJ5IFRMViB0eXBlLiAgSWYgdGhlcmUNCj5hcmUgbXVsdGlwbGUNCj58ICAg ICAgVExWcyBvZiB0aGUgc2FtZSB0eXBlLCB0aGVuIHRoZSBUTFZzIE1VU1QgYmUgb3JkZXJlZCBp biBhc2NlbmRpbmcNCj58ICEgICAgb3JkZXIgb2YgdGhlIFRMViB2YWx1ZSB3aXRoaW4gdGhlIFRM VnMgd2l0aCB0aGUgc2FtZSB0eXBlLg0KPnwgICAgICBBbGwgVExWcyB0aGF0IGFyZSBub3Qgc3Bl Y2lmaWVkIGFzIG1hbmRhdG9yeSBhcmUgY29uc2lkZXJlZA0KPm9wdGlvbmFsLg0KPnwgICANCj58 ICAgMy4yLiAgVGhlIExpbmstU3RhdGUgTkxSSQ0KPnwgKioqKioqKioqKioqKioqDQo+fCAqKiog NDkwLDQ5NiAqKioqDQo+fCAgIA0KPnwgICAgICBUaGUgJ1RvdGFsIE5MUkkgTGVuZ3RoJyBmaWVs ZCBjb250YWlucyB0aGUgY3VtdWxhdGl2ZSBsZW5ndGgsIGluDQo+fCAgICAgIG9jdGV0cywgb2Yg cmVzdCBvZiB0aGUgTkxSSSBub3QgaW5jbHVkaW5nIHRoZSBOTFJJIFR5cGUgZmllbGQgb3INCj58 ICEgICAgaXRzZWxmLiAgRm9yIFZQTiBhcHBsaWNhdGlvbnMgaXQgYWxzbyBpbmNsdWRlcyB0aGUg bGVuZ3RoIG9mIHRoZQ0KPnwgICAgICBSb3V0ZSBEaXN0aW5ndWlzaGVyLg0KPnwgICANCj58ICAg ICAgVGhlICdOTFJJIFR5cGUnIGZpZWxkIGNhbiBjb250YWluIG9uZSBvZiB0aGUgZm9sbG93aW5n IHZhbHVlczoNCj58IC0tLSA0OTEsNDk3IC0tLS0NCj58ICAgDQo+fCAgICAgIFRoZSAnVG90YWwg TkxSSSBMZW5ndGgnIGZpZWxkIGNvbnRhaW5zIHRoZSBjdW11bGF0aXZlIGxlbmd0aCwgaW4NCj58 ICAgICAgb2N0ZXRzLCBvZiByZXN0IG9mIHRoZSBOTFJJIG5vdCBpbmNsdWRpbmcgdGhlIE5MUkkg VHlwZSBmaWVsZCBvcg0KPnwgISAgICBpdHNlbGYuICBGb3IgVlBOIGFwcGxpY2F0aW9ucywgaXQg YWxzbyBpbmNsdWRlcyB0aGUgbGVuZ3RoIG9mIHRoZQ0KPnwgICAgICBSb3V0ZSBEaXN0aW5ndWlz aGVyLg0KPnwgICANCj58ICAgICAgVGhlICdOTFJJIFR5cGUnIGZpZWxkIGNhbiBjb250YWluIG9u ZSBvZiB0aGUgZm9sbG93aW5nIHZhbHVlczoNCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDY2 NSw2NzEgKioqKg0KPnwgICAgICB0cmFuc2l0aW9ucyBpdCBtYXkgaGFwcGVuIHRoYXQgdHdvIHJl ZHVuZGFudCBJR1BzIGFyZSBpbiBwbGFjZS4NCj58ICAgDQo+fCAgICAgIEluIHNlY3Rpb24gU2Vj dGlvbiAzLjIuMS40IGEgc2V0IG9mIHN1Yi1UTFZzIGlzIGRlc2NyaWJlZCwgd2hpY2gNCj58ICEg ICAgYWxsb3dzIHRvIHNwZWNpZnkgYSBmbGV4aWJsZSBrZXkgZm9yIGFueSBnaXZlbiBOb2RlL0xp bmsNCj5pbmZvcm1hdGlvbg0KPnwgICAgICBzdWNoIHRoYXQgZ2xvYmFsIHVuaXF1ZW5lc3Mgb2Yg dGhlIE5MUkkgaXMgZW5zdXJlZC4NCj58ICAgDQo+fCAgIDMuMi4xLjIuICBMb2NhbCBOb2RlIERl c2NyaXB0b3JzDQo+fCAtLS0gNjY2LDY3MiAtLS0tDQo+fCAgICAgIHRyYW5zaXRpb25zIGl0IG1h eSBoYXBwZW4gdGhhdCB0d28gcmVkdW5kYW50IElHUHMgYXJlIGluIHBsYWNlLg0KPnwgICANCj58 ICAgICAgSW4gc2VjdGlvbiBTZWN0aW9uIDMuMi4xLjQgYSBzZXQgb2Ygc3ViLVRMVnMgaXMgZGVz Y3JpYmVkLCB3aGljaA0KPnwgISAgICBhbGxvd3Mgc3BlY2lmaWNhdGlvbiBvZiBhIGZsZXhpYmxl IGtleSBmb3IgYW55IGdpdmVuIE5vZGUvTGluaw0KPmluZm9ybWF0aW9uDQo+fCAgICAgIHN1Y2gg dGhhdCBnbG9iYWwgdW5pcXVlbmVzcyBvZiB0aGUgTkxSSSBpcyBlbnN1cmVkLg0KPnwgICANCj58 ICAgMy4yLjEuMi4gIExvY2FsIE5vZGUgRGVzY3JpcHRvcnMNCj58ICoqKioqKioqKioqKioqKg0K PnwgKioqIDc0OSw3NjIgKioqKg0KPnwgICAgICAgICBub24tUHNldWRvbm9kZSwgdGhpcyBjb250 YWlucyA2IG9jdGV0IElTTyBub2RlLUlEIChJU08NCj5zeXN0ZW0tSUQpLg0KPnwgICAgICAgICBG b3IgYW4gSVMtSVMgUHNldWRvbm9kZSBjb3JyZXNwb25kaW5nIHRvIGEgTEFOLCB0aGlzIGNvbnRh aW5zIDYNCj58ICAgICAgICAgb2N0ZXQgSVNPIG5vZGUtSUQgb2YgdGhlICJEZXNpZ25hdGVkIElu dGVybWVkaWF0ZSBTeXN0ZW0iIChESVMpDQo+fCAhICAgICAgIGZvbGxvd2VkIGJ5IG9uZSBvY3Rl dCBub256ZXJvIFBTTiBpZGVudGlmaWVyICg3IG9jdGV0IGluIHRvdGFsKS4NCj58ICEgICAgICAg Rm9yIGFuIE9TUEZ2MiBvciBPU1BGdjMgbm9uLSJQc2V1ZG9ub2RlIiwgdGhpcyBjb250YWlucyA0 IG9jdGV0DQo+fCAgICAgICAgIFJvdXRlci1JRC4gIEZvciBhbiBPU1BGdjIgIlBzZXVkb25vZGUi IHJlcHJlc2VudGluZyBhIExBTiwgdGhpcw0KPnwgISAgICAgICBjb250YWlucyA0IG9jdGV0IFJv dXRlci1JRCBvZiB0aGUgZGVzaWduYXRlZCByb3V0ZXIgKERSKQ0KPmZvbGxvd2VkDQo+fCAhICAg ICAgIGJ5IDQgb2N0ZXQgSVB2NCBhZGRyZXNzIG9mIHRoZSBEUidzIGludGVyZmFjZSB0byB0aGUg TEFOICg4DQo+b2N0ZXQNCj58ICEgICAgICAgaW4gdG90YWwpLiBTaW1pbGFybHksIGZvciBhbiBP U1BGdjMgIlBzZXVkb25vZGUiLCB0aGlzIGNvbnRhaW5zDQo+NA0KPnwgISAgICAgICBvY3RldCBS b3V0ZXItSUQgb2YgdGhlIERSIGZvbGxvd2VkIGJ5IDQgb2N0ZXQgaW50ZXJmYWNlDQo+aWRlbnRp Zmllcg0KPnwgISAgICAgICBvZiB0aGUgRFIncyBpbnRlcmZhY2UgdG8gdGhlIExBTiAoOCBvY3Rl dCBpbiB0b3RhbCkuIFRoZSBUTFYNCj5zaXplDQo+fCAgICAgICAgIGluIGNvbWJpbmF0aW9uIHdp dGggcHJvdG9jb2wgaWRlbnRpZmllciBlbmFibGVzIHRoZSBkZWNvZGVyIHRvDQo+fCAgICAgICAg IGRldGVybWluZSB0aGUgdHlwZSBvZiB0aGUgbm9kZS4NCj58ICAgDQo+fCAtLS0gNzUwLDc2MyAt LS0tDQo+fCAgICAgICAgIG5vbi1Qc2V1ZG9ub2RlLCB0aGlzIGNvbnRhaW5zIDYgb2N0ZXQgSVNP IG5vZGUtSUQgKElTTw0KPnN5c3RlbS1JRCkuDQo+fCAgICAgICAgIEZvciBhbiBJUy1JUyBQc2V1 ZG9ub2RlIGNvcnJlc3BvbmRpbmcgdG8gYSBMQU4sIHRoaXMgY29udGFpbnMgNg0KPnwgICAgICAg ICBvY3RldCBJU08gbm9kZS1JRCBvZiB0aGUgIkRlc2lnbmF0ZWQgSW50ZXJtZWRpYXRlIFN5c3Rl bSIgKERJUykNCj58ICEgICAgICAgZm9sbG93ZWQgYnkgb25lIG9jdGV0IG5vbnplcm8gUFNOIGlk ZW50aWZpZXIgKDcgb2N0ZXRzIGluDQo+dG90YWwpLg0KPnwgISAgICAgICBGb3IgYW4gT1NQRnYy IG9yIE9TUEZ2MyBub24tIlBzZXVkb25vZGUiLCB0aGlzIGNvbnRhaW5zIHRoZSA0DQo+b2N0ZXQN Cj58ICAgICAgICAgUm91dGVyLUlELiAgRm9yIGFuIE9TUEZ2MiAiUHNldWRvbm9kZSIgcmVwcmVz ZW50aW5nIGEgTEFOLCB0aGlzDQo+fCAhICAgICAgIGNvbnRhaW5zIHRoZSA0IG9jdGV0IFJvdXRl ci1JRCBvZiB0aGUgZGVzaWduYXRlZCByb3V0ZXIgKERSKQ0KPmZvbGxvd2VkDQo+fCAhICAgICAg IGJ5IHRoZSA0IG9jdGV0IElQdjQgYWRkcmVzcyBvZiB0aGUgRFIncyBpbnRlcmZhY2UgdG8gdGhl IExBTiAoOA0KPm9jdGV0cw0KPnwgISAgICAgICBpbiB0b3RhbCkuIFNpbWlsYXJseSwgZm9yIGFu IE9TUEZ2MyAiUHNldWRvbm9kZSIsIHRoaXMgY29udGFpbnMNCj50aGUgNA0KPnwgISAgICAgICBv Y3RldCBSb3V0ZXItSUQgb2YgdGhlIERSIGZvbGxvd2VkIGJ5IHRoZSA0IG9jdGV0IGludGVyZmFj ZQ0KPmlkZW50aWZpZXINCj58ICEgICAgICAgb2YgdGhlIERSJ3MgaW50ZXJmYWNlIHRvIHRoZSBM QU4gKDggb2N0ZXRzIGluIHRvdGFsKS4gVGhlIFRMVg0KPnNpemUNCj58ICAgICAgICAgaW4gY29t YmluYXRpb24gd2l0aCBwcm90b2NvbCBpZGVudGlmaWVyIGVuYWJsZXMgdGhlIGRlY29kZXIgdG8N Cj58ICAgICAgICAgZGV0ZXJtaW5lIHRoZSB0eXBlIG9mIHRoZSBub2RlLg0KPnwgICANCj58ICoq KioqKioqKioqKioqKg0KPnwgKioqIDc3MCw3NzcgKioqKg0KPnwgICANCj58ICAgDQo+fCAgICAg ICAgIFRoZXJlIGNhbiBiZSBhdCBtb3N0IG9uZSBpbnN0YW5jZSBvZiBlYWNoIHN1Yi1UTFYgdHlw ZSBwcmVzZW50DQo+aW4NCj58ICEgICAgICAgYW55IE5vZGUgRGVzY3JpcHRvci4gIFRoZSBUTFYg b3JkZXJpbmcgd2l0aGluIGEgTm9kZSBkZXNjcmlwdG9yDQo+fCAhICAgICAgIE1VU1QgYmUga2Vw dCBpbiBvcmRlciBvZiBpbmNyZWFzaW5nIG51bWVyaWMgdmFsdWUgb2YgdHlwZS4gIFRoaXMNCj58 ICAgICAgICAgbmVlZHMgdG8gYmUgZG9uZSBpbiBvcmRlciB0byBjb21wYXJlIE5MUklzLCBldmVu IHdoZW4gYW4NCj58ICAgICAgICAgaW1wbGVtZW50YXRpb24gZW5jb3VudGVycyBhbiB1bmtub3du IHN1Yi1UTFYuIFVzaW5nIHN0YWJsZQ0KPnNvcnRpbmcNCj58ICAgICAgICAgYW4gaW1wbGVtZW50 YXRpb24gY2FuIGRvIGJpbmFyeSBjb21wYXJpc29uIG9mIE5MUklzIGFuZCBoZW5jZQ0KPnwgLS0t IDc3MSw3NzggLS0tLQ0KPnwgICANCj58ICAgDQo+fCAgICAgICAgIFRoZXJlIGNhbiBiZSBhdCBt b3N0IG9uZSBpbnN0YW5jZSBvZiBlYWNoIHN1Yi1UTFYgdHlwZSBwcmVzZW50DQo+aW4NCj58ICEg ICAgICAgYW55IE5vZGUgRGVzY3JpcHRvci4gIFRoZSBzdWItVExWcyB3aXRoaW4gYSBOb2RlIGRl c2NyaXB0b3INCj58ICEgICAgICAgTVVTVCBiZSBhcnJhbmdlZCBpbiBhc2NlbmRpbmcgb3JkZXIg Ynkgc3ViLVRMViB0eXBlLiBUaGlzDQo+fCAgICAgICAgIG5lZWRzIHRvIGJlIGRvbmUgaW4gb3Jk ZXIgdG8gY29tcGFyZSBOTFJJcywgZXZlbiB3aGVuIGFuDQo+fCAgICAgICAgIGltcGxlbWVudGF0 aW9uIGVuY291bnRlcnMgYW4gdW5rbm93biBzdWItVExWLiBVc2luZyBzdGFibGUNCj5zb3J0aW5n DQo+fCAgICAgICAgIGFuIGltcGxlbWVudGF0aW9uIGNhbiBkbyBiaW5hcnkgY29tcGFyaXNvbiBv ZiBOTFJJcyBhbmQgaGVuY2UNCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDgwNCw4MTIgKioq Kg0KPnwgICAgICBjYXJyaWVkIGluIHRoZSBUTFYuDQo+fCAgIA0KPnwgICAgICBUaGUgTVQtSUQg VExWIE1BWSBiZSBwcmVzZW50IGluIGEgTGluayBEZXNjcmlwdG9yLCBhIFByZWZpeA0KPnwgISAg ICBEZXNjcmlwdG9yLCBvciBpbiB0aGUgQkdQLUxTIGF0dHJpYnV0ZSBvZiBhIG5vZGUgTkxSSS4g SW4gTGluayBvcg0KPnwgISAgICBQcmVmaXggRGVzY3JpcHRvciwgb25seSBvbmUgTVQtSUQgVExW IGNvbnRhaW5pbmcgb25seSB0aGUgTVQtSUQgb2YNCj58ICEgICAgdGhlIHRvcG9sb2d5IHdoZXJl IHRoZSBsaW5rIG9yIHRoZSBwcmVmaXggYmVsb25ncyBpcyBhbGxvd2VkLiAgSW4NCj50aGUNCj58 ICAgDQo+fCAgIA0KPnwgICANCj58IC0tLSA4MDUsODEzIC0tLS0NCj58ICAgICAgY2FycmllZCBp biB0aGUgVExWLg0KPnwgICANCj58ICAgICAgVGhlIE1ULUlEIFRMViBNQVkgYmUgcHJlc2VudCBp biBhIExpbmsgRGVzY3JpcHRvciwgYSBQcmVmaXgNCj58ICEgICAgRGVzY3JpcHRvciwgb3IgaW4g dGhlIEJHUC1MUyBhdHRyaWJ1dGUgb2YgYSBub2RlIE5MUkkuIEluIGEgTGluayBvcg0KPnwgISAg ICBQcmVmaXggRGVzY3JpcHRvciwgb25seSBhIHNpbmdsZSBNVC1JRCBUTFYgY29udGFpbmluZyB0 aGUgTVQtSUQgb2YNCj58ICEgICAgdGhlIHRvcG9sb2d5IHdoZXJlIHRoZSBsaW5rIG9yIHRoZSBw cmVmaXggaXMgcmVhY2hhYmxlIGlzIGFsbG93ZWQuDQo+IEluIHRoZQ0KPnwgICANCj58ICAgDQo+ fCAgIA0KPnwgKioqKioqKioqKioqKioqDQo+fCAqKiogODI4LDgzNCAqKioqDQo+fCAgIEludGVy bmV0LURyYWZ0ICAgTGluay1TdGF0ZSBJbmZvIERpc3RyaWJ1dGlvbiB1c2luZyBCR1AgICAgICAg ICBNYXkNCj4yMDE0DQo+fCAgIA0KPnwgICAgICBCR1AtTFMgYXR0cmlidXRlIG9mIGEgbm9kZSBO TFJJLCBvbmUgTVQtSUQgVExWIGNvbnRhaW5pbmcgdGhlIGFycmF5DQo+fCAhICAgIG9mIE1ULUlE cyBvZiBhbGwgdG9wb2xvZ2llcyB3aGVyZSB0aGUgbm9kZSBiZWxvbmdzIGNhbiBiZSBwcmVzZW50 Lg0KPnwgICANCj58ICAgMy4yLjIuICBMaW5rIERlc2NyaXB0b3JzDQo+fCAgIA0KPnwgLS0tIDgy OSw4MzUgLS0tLQ0KPnwgICBJbnRlcm5ldC1EcmFmdCAgIExpbmstU3RhdGUgSW5mbyBEaXN0cmli dXRpb24gdXNpbmcgQkdQICAgICAgICAgTWF5DQo+MjAxNA0KPnwgICANCj58ICAgICAgQkdQLUxT IGF0dHJpYnV0ZSBvZiBhIG5vZGUgTkxSSSwgb25lIE1ULUlEIFRMViBjb250YWluaW5nIHRoZSBh cnJheQ0KPnwgISAgICBvZiBNVC1JRHMgb2YgYWxsIHRvcG9sb2dpZXMgd2hlcmUgdGhlIG5vZGUg aXMgcmVhY2hhYmxlIGlzIGFsbG93ZWQuDQo+fCAgIA0KPnwgICAzLjIuMi4gIExpbmsgRGVzY3Jp cHRvcnMNCj58ICAgDQo+fCAqKioqKioqKioqKioqKioNCj58ICoqKiA4MzgsODQ1ICoqKioNCj58 ICAgICAgbGlua3MgYmV0d2VlbiBhIHBhaXIgb2YgYW5jaG9yIHJvdXRlcnMuICBBIGxpbmsgZGVz Y3JpYmVkIGJ5IHRoZQ0KPkxpbmsNCj58ICAgICAgZGVzY3JpcHRvciBUTFZzIGFjdHVhbGx5IGlz IGEgImhhbGYtbGluayIsIGEgdW5pZGlyZWN0aW9uYWwNCj58ICAgICAgcmVwcmVzZW50YXRpb24g b2YgYSBsb2dpY2FsIGxpbmsuICBJbiBvcmRlciB0byBmdWxseSBkZXNjcmliZSBhDQo+fCAhICAg IHNpbmdsZSBsb2dpY2FsIGxpbmsgdHdvIG9yaWdpbmF0aW5nIHJvdXRlcnMgYWR2ZXJ0aXNlIGEg aGFsZi1saW5rDQo+fCAhICAgIGVhY2gsIGkuZS4gIHR3byBsaW5rIE5MUklzIGFyZSBhZHZlcnRp c2VkIGZvciBhIGdpdmVuDQo+cG9pbnQtdG8tcG9pbnQNCj58ICAgICAgbGluay4NCj58ICAgDQo+ fCAgICAgIFRoZSBmb3JtYXQgYW5kIHNlbWFudGljcyBvZiB0aGUgJ3ZhbHVlJyBmaWVsZHMgaW4g bW9zdCAnTGluaw0KPnwgLS0tIDgzOSw4NDYgLS0tLQ0KPnwgICAgICBsaW5rcyBiZXR3ZWVuIGEg cGFpciBvZiBhbmNob3Igcm91dGVycy4gIEEgbGluayBkZXNjcmliZWQgYnkgdGhlDQo+TGluaw0K PnwgICAgICBkZXNjcmlwdG9yIFRMVnMgYWN0dWFsbHkgaXMgYSAiaGFsZi1saW5rIiwgYSB1bmlk aXJlY3Rpb25hbA0KPnwgICAgICByZXByZXNlbnRhdGlvbiBvZiBhIGxvZ2ljYWwgbGluay4gIElu IG9yZGVyIHRvIGZ1bGx5IGRlc2NyaWJlIGENCj58ICEgICAgc2luZ2xlIGxvZ2ljYWwgbGluaywg dHdvIG9yaWdpbmF0aW5nIHJvdXRlcnMgYWR2ZXJ0aXNlIGEgaGFsZi1saW5rDQo+fCAhICAgIGVh Y2gsIGkuZS4sIHR3byBsaW5rIE5MUklzIGFyZSBhZHZlcnRpc2VkIGZvciBhIGdpdmVuDQo+cG9p bnQtdG8tcG9pbnQNCj58ICAgICAgbGluay4NCj58ICAgDQo+fCAgICAgIFRoZSBmb3JtYXQgYW5k IHNlbWFudGljcyBvZiB0aGUgJ3ZhbHVlJyBmaWVsZHMgaW4gbW9zdCAnTGluaw0KPnwgKioqKioq KioqKioqKioqDQo+fCAqKiogODg4LDg5NCAqKioqDQo+fCAgIA0KPnwgICAgICAgICBJZiBpbnRl cmZhY2UgYW5kIG5laWdoYm9yIGFkZHJlc3NlcyBhcmUgbm90IHByZXNlbnQgYW5kIHRoZSBsaW5r DQo+fCAgICAgICAgIGxvY2FsL3JlbW90ZSBpZGVudGlmaWVycyBhcmUgcHJlc2VudCwgdGhlbiB0 aGUgbGluayBsb2NhbC9yZW1vdGUNCj58ICEgICAgICAgSWRlbnRpZmllciBUTFYgaXMgaW5jbHVk ZWQgaW4gbGluayBkZXNjcmlwdG9yLg0KPnwgICANCj58ICAgICAgICAgVGhlIE11bHRpLVRvcG9s b2d5IElkZW50aWZpZXIgVExWIGlzIGluY2x1ZGVkIGluIGxpbmsgZGVzY3JpcHRvcg0KPnwgICAg ICAgICBpZiB0aGF0IGluZm9ybWF0aW9uIGlzIHByZXNlbnQuDQo+fCAtLS0gODg5LDg5NSAtLS0t DQo+fCAgIA0KPnwgICAgICAgICBJZiBpbnRlcmZhY2UgYW5kIG5laWdoYm9yIGFkZHJlc3NlcyBh cmUgbm90IHByZXNlbnQgYW5kIHRoZSBsaW5rDQo+fCAgICAgICAgIGxvY2FsL3JlbW90ZSBpZGVu dGlmaWVycyBhcmUgcHJlc2VudCwgdGhlbiB0aGUgbGluayBsb2NhbC9yZW1vdGUNCj58ICEgICAg ICAgSWRlbnRpZmllciBUTFYgaXMgaW5jbHVkZWQgaW4gdGhlIGxpbmsgZGVzY3JpcHRvci4NCj58 ICAgDQo+fCAgICAgICAgIFRoZSBNdWx0aS1Ub3BvbG9neSBJZGVudGlmaWVyIFRMViBpcyBpbmNs dWRlZCBpbiBsaW5rIGRlc2NyaXB0b3INCj58ICAgICAgICAgaWYgdGhhdCBpbmZvcm1hdGlvbiBp cyBwcmVzZW50Lg0KPnwgKioqKioqKioqKioqKioqDQo+fCAqKiogOTE3LDkyNCAqKioqDQo+fCAg ICAgIE9TUEYgUm91dGUgVHlwZSBpcyBhbiBvcHRpb25hbCBUTFYgdGhhdCBNQVkgYmUgcHJlc2Vu dCBpbiBQcmVmaXgNCj58ICAgICAgTkxSSXMuICBJdCBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBP U1BGIHJvdXRlLXR5cGUgb2YgdGhlIHByZWZpeC4NCj5JdA0KPnwgICAgICBpcyB1c2VkIHdoZW4g YW4gT1NQRiBwcmVmaXggaXMgYWR2ZXJ0aXNlZCBpbiB0aGUgT1NQRiBkb21haW4gd2l0aA0KPnwg ISAgICBtdWx0aXBsZSBkaWZmZXJlbnQgcm91dGUtdHlwZXMuICBUaGUgUm91dGUgVHlwZSBUTFYg YWxsb3dzIHRvDQo+fCAhICAgIGRpc2NyaW1pbmF0ZSB0aGVzZSBhZHZlcnRpc2VtZW50cy4gIFRo ZSBmb3JtYXQgb2YgdGhlIE9TUEYgUm91dGUNCj5UeXBlDQo+fCAgICAgIFRMViBpcyBzaG93biBp biB0aGUgZm9sbG93aW5nIGZpZ3VyZS4NCj58ICAgDQo+fCAgICAgICAwICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+fCAtLS0gOTE4 LDkyNSAtLS0tDQo+fCAgICAgIE9TUEYgUm91dGUgVHlwZSBpcyBhbiBvcHRpb25hbCBUTFYgdGhh dCBNQVkgYmUgcHJlc2VudCBpbiBQcmVmaXgNCj58ICAgICAgTkxSSXMuICBJdCBpcyB1c2VkIHRv IGlkZW50aWZ5IHRoZSBPU1BGIHJvdXRlLXR5cGUgb2YgdGhlIHByZWZpeC4NCj5JdA0KPnwgICAg ICBpcyB1c2VkIHdoZW4gYW4gT1NQRiBwcmVmaXggaXMgYWR2ZXJ0aXNlZCBpbiB0aGUgT1NQRiBk b21haW4gd2l0aA0KPnwgISAgICBtdWx0aXBsZSByb3V0ZS10eXBlcy4gIFRoZSBSb3V0ZSBUeXBl IFRMViBhbGxvd3MgZGlzY3JpbWluYXRpb24gb2YNCj58ICEgICAgdGhlc2UgYWR2ZXJ0aXNlbWVu dHMuICBUaGUgZm9ybWF0IG9mIHRoZSBPU1BGIFJvdXRlIFR5cGUNCj58ICAgICAgVExWIGlzIHNo b3duIGluIHRoZSBmb2xsb3dpbmcgZmlndXJlLg0KPnwgICANCj58ICAgICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj58ICoq KioqKioqKioqKioqKg0KPnwgKioqIDk1Nyw5NjMgKioqKg0KPnwgICANCj58ICAgICAgVGhlIElQ IFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiBpcyBhIG1hbmRhdG9yeSBUTFYgdGhhdCBjb250YWlu cw0KPm9uZQ0KPnwgICAgICBJUCBhZGRyZXNzIHByZWZpeCAoSVB2NCBvciBJUHY2KSBvcmlnaW5h bGx5IGFkdmVydGlzZWQgaW4gdGhlIElHUA0KPnwgISAgICB0b3BvbG9neS4gIEl0cyBwdXJwb3Nl IGlzIHRvIGdsdWUgYSBwYXJ0aWN1bGFyIEJHUCBzZXJ2aWNlIE5MUkkgdmkNCj58ICAgICAgdmly dHVlIG9mIGl0cyBCR1AgbmV4dC1ob3AgdG8gYSBnaXZlbiBOb2RlIGluIHRoZSBMU0RCLiBBIHJv dXRlcg0KPnwgICAgICBTSE9VTEQgYWR2ZXJ0aXNlIGFuIElQIFByZWZpeCBOTFJJIGZvciBlYWNo IG9mIGl0cyBCR1AgTmV4dC1ob3BzLg0KPnwgICAgICBUaGUgZm9ybWF0IG9mIHRoZSBJUCBSZWFj aGFiaWxpdHkgSW5mb3JtYXRpb24gVExWIGlzIHNob3duIGluIHRoZQ0KPnwgLS0tIDk1OCw5NjQg LS0tLQ0KPnwgICANCj58ICAgICAgVGhlIElQIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiBpcyBh IG1hbmRhdG9yeSBUTFYgdGhhdCBjb250YWlucw0KPm9uZQ0KPnwgICAgICBJUCBhZGRyZXNzIHBy ZWZpeCAoSVB2NCBvciBJUHY2KSBvcmlnaW5hbGx5IGFkdmVydGlzZWQgaW4gdGhlIElHUA0KPnwg ISAgICB0b3BvbG9neS4gIEl0cyBwdXJwb3NlIGlzIHRvIGdsdWUgYSBwYXJ0aWN1bGFyIEJHUCBz ZXJ2aWNlIE5MUkkgYnkNCj58ICAgICAgdmlydHVlIG9mIGl0cyBCR1AgbmV4dC1ob3AgdG8gYSBn aXZlbiBOb2RlIGluIHRoZSBMU0RCLiBBIHJvdXRlcg0KPnwgICAgICBTSE9VTEQgYWR2ZXJ0aXNl IGFuIElQIFByZWZpeCBOTFJJIGZvciBlYWNoIG9mIGl0cyBCR1AgTmV4dC1ob3BzLg0KPnwgICAg ICBUaGUgZm9ybWF0IG9mIHRoZSBJUCBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gVExWIGlzIHNo b3duIGluIHRoZQ0KPnwgKioqKioqKioqKioqKioqDQo+fCAqKiogMTA1MiwxMDYxICoqKioNCj58 ICAgMy4zLjEuMi4gIElTLUlTIEFyZWEgSWRlbnRpZmllciBUTFYNCj58ICAgDQo+fCAgICAgIEFu IElTLUlTIG5vZGUgY2FuIGJlIHBhcnQgb2Ygb25lIG9yIG1vcmUgSVMtSVMgYXJlYXMuICBFYWNo IG9mDQo+dGhlc2UNCj58ICEgICAgYXJlYSBhZGRyZXNzZXMgaXMgY2FycmllZCBpbiB0aGUgSVMt SVMgQXJlYSBJZGVudGlmaWVyIFRMVi4gSWYgbW9yZQ0KPnwgISAgICB0aGFuIG9uZSBBcmVhIEFk ZHJlc3NlcyBhcmUgcHJlc2VudCwgbXVsdGlwbGUgVExWcyBhcmUgdXNlZCB0bw0KPmVuY29kZQ0K PnwgICAgICB0aGVtLiAgVGhlIElTLUlTIEFyZWEgSWRlbnRpZmllciBUTFYgbWF5IGJlIHByZXNl bnQgaW4gdGhlIEJHUC1MUw0KPnwgISAgICBhdHRyaWJ1dGUgb25seSB3aXRoIHRoZSBMaW5rLVN0 YXRlIE5vZGUgTkxSSS4NCj58ICAgDQo+fCAgIA0KPnwgICANCj58IC0tLSAxMDUzLDEwNjIgLS0t LQ0KPnwgICAzLjMuMS4yLiAgSVMtSVMgQXJlYSBJZGVudGlmaWVyIFRMVg0KPnwgICANCj58ICAg ICAgQW4gSVMtSVMgbm9kZSBjYW4gYmUgcGFydCBvZiBvbmUgb3IgbW9yZSBJUy1JUyBhcmVhcy4g IEVhY2ggb2YNCj50aGVzZQ0KPnwgISAgICBhcmVhIGFkZHJlc3NlcyBpcyBjYXJyaWVkIGluIHRo ZSBJUy1JUyBBcmVhIElkZW50aWZpZXIgVExWLiBJZg0KPm11bHRpcGxlDQo+fCAhICAgIEFyZWEg QWRkcmVzc2VzIGFyZSBwcmVzZW50LCBtdWx0aXBsZSBUTFZzIGFyZSB1c2VkIHRvIGVuY29kZQ0K PnwgICAgICB0aGVtLiAgVGhlIElTLUlTIEFyZWEgSWRlbnRpZmllciBUTFYgbWF5IGJlIHByZXNl bnQgaW4gdGhlIEJHUC1MUw0KPnwgISAgICBhdHRyaWJ1dGUgb25seSB3aGVuIGFkdmVydGlzZWQg aW4gdGhlIExpbmstU3RhdGUgTm9kZSBOTFJJLg0KPnwgICANCj58ICAgDQo+fCAgIA0KPnwgKioq KioqKioqKioqKioqDQo+fCAqKiogMTA4NywxMDkzICoqKioNCj58ICAgICAgVG9Vbmljb2RlIGFs Z29yaXRobSBhcyBkZXNjcmliZWQgaW4gW1JGQzU4OTBdIHRvIGFjaGlldmUgdGhlDQo+Y29ycmVj dA0KPnwgICAgICBmb3JtYXQgZm9yIHRyYW5zbWlzc2lvbiBvciBkaXNwbGF5Lg0KPnwgICANCj58 ICEgICAgQWx0b3VnaCBbUkZDNTMwMV0gaXMgYSBJUy1JUyBzcGVjaWZpYyBleHRlbnNpb24sIHVz YWdlIG9mIHRoZSBOb2RlDQo+fCAgICAgIE5hbWUgVExWIGlzIHBvc3NpYmxlIGZvciBhbGwgcHJv dG9jb2xzLiAgSG93IGEgcm91dGVyIGRlcml2ZXMgYW5kDQo+fCAgICAgIGluamVjdHMgbm9kZSBu YW1lcyBmb3IgZS5nLiAgT1NQRiBub2RlcywgaXMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YNCj58 ICAgICAgdGhpcyBkb2N1bWVudC4NCj58IC0tLSAxMDg4LDEwOTQgLS0tLQ0KPnwgICAgICBUb1Vu aWNvZGUgYWxnb3JpdGhtIGFzIGRlc2NyaWJlZCBpbiBbUkZDNTg5MF0gdG8gYWNoaWV2ZSB0aGUN Cj5jb3JyZWN0DQo+fCAgICAgIGZvcm1hdCBmb3IgdHJhbnNtaXNzaW9uIG9yIGRpc3BsYXkuDQo+ fCAgIA0KPnwgISAgICBBbHRvdWdoIFtSRkM1MzAxXSBpcyBhbiBJUy1JUyBzcGVjaWZpYyBleHRl bnNpb24sIHVzYWdlIG9mIHRoZSBOb2RlDQo+fCAgICAgIE5hbWUgVExWIGlzIHBvc3NpYmxlIGZv ciBhbGwgcHJvdG9jb2xzLiAgSG93IGEgcm91dGVyIGRlcml2ZXMgYW5kDQo+fCAgICAgIGluamVj dHMgbm9kZSBuYW1lcyBmb3IgZS5nLiAgT1NQRiBub2RlcywgaXMgb3V0c2lkZSBvZiB0aGUgc2Nv cGUgb2YNCj58ICAgICAgdGhpcyBkb2N1bWVudC4NCj58ICoqKioqKioqKioqKioqKg0KPnwgKioq IDEyODEsMTI4OCAqKioqDQo+fCAgICAgIFRoZSBJR1AgTWV0cmljIFRMViBjYXJyaWVzIHRoZSBt ZXRyaWMgZm9yIHRoaXMgbGluay4gIFRoZSBsZW5ndGggb2YNCj58ICAgICAgdGhpcyBUTFYgaXMg dmFyaWFibGUsIGRlcGVuZGluZyBvbiB0aGUgbWV0cmljIHdpZHRoIG9mIHRoZQ0KPnVuZGVybHlp bmcNCj58ICAgICAgcHJvdG9jb2wuICBJUy1JUyBzbWFsbCBtZXRyaWNzIGhhdmUgYSBsZW5ndGgg b2YgMSBvY3RldCAodGhlIHR3bw0KPm1vc3QNCj58ICEgICAgc2lnbmlmaWNhbnQgYml0cyBhcmUg aWdub3JlZCkuICBPU1BGIG1ldHJpY3MgaGF2ZSBhIGxlbmd0aCBvZiB0d28NCj58ICEgICAgb2N0 ZWN0cy4gIElTLUlTIHdpZGUtbWV0cmljcyBoYXZlIGEgbGVuZ3RoIG9mIHRocmVlIG9jdGV0cy4N Cj58ICAgDQo+fCAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAg MiAgICAgICAgICAgICAgICAgICAzDQo+fCAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj58IC0tLSAxMjgyLDEyODkg LS0tLQ0KPnwgICAgICBUaGUgSUdQIE1ldHJpYyBUTFYgY2FycmllcyB0aGUgbWV0cmljIGZvciB0 aGlzIGxpbmsuICBUaGUgbGVuZ3RoIG9mDQo+fCAgICAgIHRoaXMgVExWIGlzIHZhcmlhYmxlLCBk ZXBlbmRpbmcgb24gdGhlIG1ldHJpYyB3aWR0aCBvZiB0aGUNCj51bmRlcmx5aW5nDQo+fCAgICAg IHByb3RvY29sLiAgSVMtSVMgc21hbGwgbWV0cmljcyBoYXZlIGEgbGVuZ3RoIG9mIDEgb2N0ZXQg KHRoZSB0d28NCj5tb3N0DQo+fCAhICAgIHNpZ25pZmljYW50IGJpdHMgYXJlIGlnbm9yZWQpLiAg T1NQRiBsaW5rIG1ldHJpY3MgaGF2ZSBhIGxlbmd0aCBvZg0KPnR3bw0KPnwgISAgICBvY3RldHMu ICBJUy1JUyB3aWRlLW1ldHJpY3MgaGF2ZSBhIGxlbmd0aCBvZiB0aHJlZSBvY3RldHMuDQo+fCAg IA0KPnwgICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMw0KPnwgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQo+fCAqKioqKioqKioqKioqKioNCj58 ICoqKiAxNTQyLDE1NDkgKioqKg0KPnwgICANCj58ICAgICAgQkdQIGxpbmstc3RhdGUgaW5mb3Jt YXRpb24gZm9yIGJvdGggSVB2NCBhbmQgSVB2NiBuZXR3b3JrcyBjYW4gYmUNCj58ICAgICAgY2Fy cmllZCBvdmVyIGVpdGhlciBhbiBJUHY0IEJHUCBzZXNzaW9uLCBvciBhbiBJUHY2IEJHUCBzZXNz aW9uLg0KPklmDQo+fCAhICAgIElQdjQgQkdQIHNlc3Npb24gaXMgdXNlZCwgdGhlbiB0aGUgbmV4 dCBob3AgaW4gdGhlIE1QX1JFQUNIX05MUkkNCj58ICEgICAgU0hPVUxEIGJlIGFuIElQdjQgYWRk cmVzcy4gIFNpbWlsYXJseSwgaWYgSVB2NiBCR1Agc2Vzc2lvbiBpcyB1c2VkLA0KPnwgICAgICB0 aGVuIHRoZSBuZXh0IGhvcCBpbiB0aGUgTVBfUkVBQ0hfTkxSSSBTSE9VTEQgYmUgYW4gSVB2NiBh ZGRyZXNzLg0KPnwgICAgICBVc3VhbGx5IHRoZSBuZXh0IGhvcCB3aWxsIGJlIHNldCB0byB0aGUg bG9jYWwgZW5kLXBvaW50IGFkZHJlc3Mgb2YNCj58ICAgICAgdGhlIEJHUCBzZXNzaW9uLiAgVGhl IG5leHQgaG9wIGFkZHJlc3MgTVVTVCBiZSBlbmNvZGVkIGFzIGRlc2NyaWJlZA0KPnwgLS0tIDE1 NDMsMTU1MCAtLS0tDQo+fCAgIA0KPnwgICAgICBCR1AgbGluay1zdGF0ZSBpbmZvcm1hdGlvbiBm b3IgYm90aCBJUHY0IGFuZCBJUHY2IG5ldHdvcmtzIGNhbiBiZQ0KPnwgICAgICBjYXJyaWVkIG92 ZXIgZWl0aGVyIGFuIElQdjQgQkdQIHNlc3Npb24sIG9yIGFuIElQdjYgQkdQIHNlc3Npb24uDQo+ SWYNCj58ICEgICAgYW4gSVB2NCBCR1Agc2Vzc2lvbiBpcyB1c2VkLCB0aGVuIHRoZSBuZXh0IGhv cCBpbiB0aGUgTVBfUkVBQ0hfTkxSSQ0KPnwgISAgICBTSE9VTEQgYmUgYW4gSVB2NCBhZGRyZXNz LiAgU2ltaWxhcmx5LCBpZiBhbiBJUHY2IEJHUCBzZXNzaW9uIGlzDQo+dXNlZCwNCj58ICAgICAg dGhlbiB0aGUgbmV4dCBob3AgaW4gdGhlIE1QX1JFQUNIX05MUkkgU0hPVUxEIGJlIGFuIElQdjYg YWRkcmVzcy4NCj58ICAgICAgVXN1YWxseSB0aGUgbmV4dCBob3Agd2lsbCBiZSBzZXQgdG8gdGhl IGxvY2FsIGVuZC1wb2ludCBhZGRyZXNzIG9mDQo+fCAgICAgIHRoZSBCR1Agc2Vzc2lvbi4gIFRo ZSBuZXh0IGhvcCBhZGRyZXNzIE1VU1QgYmUgZW5jb2RlZCBhcyBkZXNjcmliZWQNCj58ICoqKioq KioqKioqKioqKg0KPnwgKioqIDE4MzMsMTgzOSAqKioqDQo+fCAgIA0KPnwgICAgICBBbiBpbXBs ZW1lbnRhdGlvbiBTSE9VTEQgYWxsb3cgdGhlIG9wZXJhdG9yIHRvIHNwZWNpZnkgdGhlIG1heGlt dW0NCj58ICAgICAgcmF0ZSBhdCB3aGljaCBMaW5rLVN0YXRlIE5MUklzIHdpbGwgYmUgYWR2ZXJ0 aXNlZC93aXRoZHJhd24gZnJvbQ0KPnwgISAgICBuZWlnaGJvcnMNCj58ICAgDQo+fCAgICAgIEFu IGltcGxlbWVudGF0aW9uIFNIT1VMRCBhbGxvdyB0aGUgb3BlcmF0b3IgdG8gc3BlY2lmeSB0aGUg bWF4aW11bQ0KPnwgICAgICBudW1iZXIgb2YgTGluay1TdGF0ZSBOTFJJcyBzdG9yZWQgaW4gcm91 dGVyJ3MgUklCLg0KPnwgLS0tIDE4MzQsMTg0MCAtLS0tDQo+fCAgIA0KPnwgICAgICBBbiBpbXBs ZW1lbnRhdGlvbiBTSE9VTEQgYWxsb3cgdGhlIG9wZXJhdG9yIHRvIHNwZWNpZnkgdGhlIG1heGlt dW0NCj58ICAgICAgcmF0ZSBhdCB3aGljaCBMaW5rLVN0YXRlIE5MUklzIHdpbGwgYmUgYWR2ZXJ0 aXNlZC93aXRoZHJhd24gZnJvbQ0KPnwgISAgICBuZWlnaGJvcnMuDQo+fCAgIA0KPnwgICAgICBB biBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgYWxsb3cgdGhlIG9wZXJhdG9yIHRvIHNwZWNpZnkgdGhl IG1heGltdW0NCj58ICAgICAgbnVtYmVyIG9mIExpbmstU3RhdGUgTkxSSXMgc3RvcmVkIGluIHJv dXRlcidzIFJJQi4NCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDE4NDYsMTg1MiAqKioqDQo+ fCAgICAgIGluc3RhbmNlIElELg0KPnwgICANCj58ICAgICAgQW4gaW1wbGVtZW50YXRpb24gU0hP VUxEIGFsbG93IHRoZSBvcGVyYXRvciB0byBjb25maWd1cmUgYSBwYWlyIG9mDQo+fCAhICAgIEFT TiBhbmQgQkdQLUxTIGlkZW50aWZpZXIgcGVyIGZsb29kaW5nIHNldCB0aGUgbm9kZSBwYXJ0aWNp cGF0ZXMNCj5pbi4NCj58ICAgDQo+fCAgIDYuMi40LiAgQWNjb3VudGluZyBNYW5hZ2VtZW50DQo+ fCAgIA0KPnwgLS0tIDE4NDcsMTg1MyAtLS0tDQo+fCAgICAgIGluc3RhbmNlIElELg0KPnwgICAN Cj58ICAgICAgQW4gaW1wbGVtZW50YXRpb24gU0hPVUxEIGFsbG93IHRoZSBvcGVyYXRvciB0byBj b25maWd1cmUgYSBwYWlyIG9mDQo+fCAhICAgIEFTTiBhbmQgQkdQLUxTIGlkZW50aWZpZXJzIHBl ciBmbG9vZGluZyBzZXQgaW4gd2hpY2ggdGhlIG5vZGUNCj5wYXJ0aWNpcGF0ZXMuDQo+fCAgIA0K PnwgICA2LjIuNC4gIEFjY291bnRpbmcgTWFuYWdlbWVudA0KPnwgICANCj58ICoqKioqKioqKioq KioqKg0KPnwgKioqIDE5ODEsMTk4NyAqKioqDQo+fCAgICAgIFNwZWFrZXIuDQo+fCAgIA0KPnwg ICAgICBBbiBvcGVyYXRvciBTSE9VTEQgZW1wbG95IGEgbWVjaGFuaXNtIHRvIHByb3RlY3QgYSBC R1AgU3BlYWtlcg0KPnwgISAgICBhZ2FpbnN0IERET1MgYXR0YWNrcyBmcm9tIENvbnN1bWVycy4g IFRoZSBwcmluY2lwYWwgYXR0YWNrIGENCj5jb25zdW1lcg0KPnwgICAgICBtYXkgYXBwbHkgaXMg dG8gYXR0ZW1wdCB0byBzdGFydCBtdWx0aXBsZSBzZXNzaW9ucyBlaXRoZXINCj58ICAgICAgc2Vx dWVudGlhbGx5IG9yIHNpbXVsdGFuZW91c2x5LiAgUHJvdGVjdGlvbiBjYW4gYmUgYXBwbGllZCBi eQ0KPnwgICAgICBpbXBvc2luZyByYXRlIGxpbWl0cy4NCj58IC0tLSAxOTgyLDE5ODggLS0tLQ0K PnwgICAgICBTcGVha2VyLg0KPnwgICANCj58ICAgICAgQW4gb3BlcmF0b3IgU0hPVUxEIGVtcGxv eSBhIG1lY2hhbmlzbSB0byBwcm90ZWN0IGEgQkdQIFNwZWFrZXINCj58ICEgICAgYWdhaW5zdCBE RG9TIGF0dGFja3MgZnJvbSBDb25zdW1lcnMuICBUaGUgcHJpbmNpcGFsIGF0dGFjayBhDQo+Y29u c3VtZXINCj58ICAgICAgbWF5IGFwcGx5IGlzIHRvIGF0dGVtcHQgdG8gc3RhcnQgbXVsdGlwbGUg c2Vzc2lvbnMgZWl0aGVyDQo+fCAgICAgIHNlcXVlbnRpYWxseSBvciBzaW11bHRhbmVvdXNseS4g IFByb3RlY3Rpb24gY2FuIGJlIGFwcGxpZWQgYnkNCj58ICAgICAgaW1wb3NpbmcgcmF0ZSBsaW1p dHMuDQo+fCANCj58IFRoYW5rcywNCj58IEFjZWUgDQo+fCANCg0KDQo= From nobody Fri Sep 12 02:38:56 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BD51A06C3; Fri, 12 Sep 2014 02:38:52 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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 flLpp4YsV6UX; Fri, 12 Sep 2014 02:38:49 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c: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 B21C31A069A; Fri, 12 Sep 2014 02:38:48 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id em10so257404wid.12 for ; Fri, 12 Sep 2014 02:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=VvddJCbRB49QZzfq0edJwMnI/PTbuEFojH3oJCpJBvc=; b=lCg/EjY+CcrjIHbnYQrJD1RxZ69hVdcQvk99pfp5ig2UISASaQpdaYZRho0bYn5McJ ykqII12t13+udgqhAvqD1FwT9i9PgPhClkOVksA7f/IgEJI/mZqlnl/M6GB33Vi7V5SI 8e8jKqEV0DPthd7e/zDLvPI3/K/opJU6ShDMR9G9eIeAldLG2DR1QEWTSDrouqoE3mPY 2bpjyJWMuIej+GFbgcjqyP+ECqCeRGIGKjhqkVhjiV0b9O3GSsbcbarrxQ3uIdvbujLu FS4efSvYPu10kgfoyuaTBbc1AGNQ71ADOsx+5JaHyoZHfTg9EJ433F5Jw5tA8ouyeWhf CIVA== X-Received: by 10.194.172.137 with SMTP id bc9mr9659116wjc.72.1410514725085; Fri, 12 Sep 2014 02:38:45 -0700 (PDT) Received: from [127.0.0.1] (ARennes-652-1-175-135.w81-53.abo.wanadoo.fr. [81.53.190.135]) by mx.google.com with ESMTPSA id y5sm3928321wje.32.2014.09.12.02.38.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 02:38:44 -0700 (PDT) Sender: Thomas Morin Message-ID: <5412BF1F.7030206@orange.com> Date: Fri, 12 Sep 2014 11:38:39 +0200 From: Thomas Morin Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: idr@ietf.org, "rtg-ads@tools.ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/4gK5r52_nagtsFUIu2VXoFtdKLI Cc: "rtg-dir@ietf.org" , draft-ietf-idr-as-migration.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 09:38:52 -0000 Hello, In the context of Routing Area QA reviews (see https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ), I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​ http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-idr-as-migration-02 Reviewer: Thomas Morin Review Date: 2014-09-11 Intended Status: standards track *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments: * This is overall a very well written document, with a clear goal and concisely addressing its target goal.* * Although it is all about local behavior, it makes sense to make a standard track document that (a) can be used as a reference for implementors and deployers to implement this properly, and (b) keep track of these features in future evolutions of the protocol (as motivated in the Conclusion section of the document).* * *Major Issues:* No major issues found *Minor Issues: * A) The introduction says: In particular the ISP would have to encourage those customers to change their CE router configs to use the new ASN in a very short period of time, when the customer has no business incentive to do so. Thus, it becomes critical to allow the ISP to make this process a bit more asymmetric, so that it could seamlessly migrate the ASN within its network(s), but not disturb existing customers, and allow the customers to gradually migrate to the ISP's new ASN at their leisure. However, I did not understand which part of the specs would allow the customer to change its CE configuration without coordinating a maintenance window with the ISP. Procedures in section 3, as described, won't let the customer CE connect to the router with the new ASN. See, in particular in the second § of section 3.3: "The speaker MUST NOT use the ASN configured globally within the BGP process as the value sent in MY ASN in the OPEN message. ". It seems that the goal specified in the intro will thus not be met fully. Two things would be possible: fixing the intro to state a slightly different goal, or change the procedures to let a router establish a session with the globally assigned new AS, even when 'local-as old-AS" is configured. I'm not expert enough to know if the latter would work. B) still about the intro: it seems that this intro is focused on the motivation for eBGP-related features described in section 3, but silent on iBGP and section 4 C) in section 3, second §, there is a discussion about changing the AS_PATH length ; it seems to me that there is a hidden assumption on what interconnection exist between ISP A and ISP B prior to the migration ; the text says "whereas the same RIB on ISP A' would contain AS_PATH: 64510 64496, which is an increase in AS_PATH length from previously" which seems to indicate that ISP A and ISP B are peering with each other. If this is correct, this should be stated clearly in section 2, and not be a hidden assumption. D) in section 3: " Thus, within Loc-RIB on ISP B' the AS_PATH toward customer C would appear as: 64510". I would have thought that the AS_PATH of routes learned by PE routers of ISP B in this situation (if local-as no-prepend is not used), would be "64496" or "64510 64496" rather than "64510" alone... but I could just be wrong. E) In section 2, third paragraph: First, ISP B, will change the global BGP ASN used by a PE router, from ASN 64510 to 64500. At this point, the router will no longer be able to establish eBGP sessions toward the existing CE devices that are attached to it and still using AS 64510. Second, ISP B will configure two separate, but related ASN migration features discussed in this document on all eBGP sessions toward all CE devices. These features modify the AS_PATH attribute received from a CE device when advertising it further, and modify AS_PATH when transmitted toward CE devices to achieve the desired effect of not increasing the length of the AS_PATH. This high level description of the procedures in 3 is I think missing a description of the fact that, among the features of step 2 there is also a feature, not related to fixing the as path, that aims at allowing BGP sessions to be established using ASN 64510. I would suggest rewriting the last sentence as: These features allow the establishment of sessions with the legacy ASN 64510, modify the AS_PATH attribute received from a CE device when advertising it further, and modify AS_PATH when transmitted toward CE devices to achieve the desired effect of not increasing the length of the AS_PATH. F) section 3.1: it would be worth mentioning it explicitly, at the end of the first paragraph, that alone, this change results in an interruption of service G) the naming given to ASs and routers along the document**could I think be largely improved to make the document easier to read. I would suggest the following: * In the figures 3 and 4 of section 3.1 and 3.2: invert the figure left-right to have AS64499 on the left like in figures 1 and 2 * In the figures 3 and 4 of section 3.1 and 3.2, and associated text: instead of naming the PEs and CEs with 1 and 2, name them with A and B to match the ISP they are into (PE-A,CE-A,PE-B,CE-B instead of PE-2,CE-2,PE-1,CE-1) * modify figures 1 and 2 to make PE-A,CE-A,PE-B,CE-B appear on the figures * preferring "ISP A PE routers" to "ISP A's PE routers" to increase readability, or just "PE-A" or "PE-B" which is even shorter and less confusing (as an illustration section 3.2 says "Specifically, with 'Local AS No Prepend' enabled on ISP A's PE-1, it automatically causes..." , but does it mean "ISP A PE-1" or "ISP A' PE-1"...? given that PE-1 is actually in ISP B (==ISP A'), this is probably the second which is true, but here incorrectly written as "ISP A's PE-1"...) * section 3.1 mentions ISP B' ("within Loc-RIB on ISP B' the AS_PATH toward...") , but what ISP B' can only be guessed, you may want to define it in section 2(the set of routers in ISP B after the AS migration) H) section 3.2 says "Instead, only the historical (or legacy) AS will be prepended in the outbound BGP UPDATE toward customer's network, restoring the AS_PATH length to what it what was before AS Migration occurred." ; I would suggest adding ", as configured with the 'Local AS' feature described in section 3.1," before "will be prepended" I) I know the 'PE'/'CE' terminology to be widely used in the context of BPG-based VPNs, but, unless it is also widely used for non-VPN use cases, I would think that defining these terms would make sense (I don't know these terms to be widely used outside VPN use cases, but well, they might be in which case nothing is needed) J) the last § of section 3.1 looks to me as very much redundant to what is said in the rest of the section K) section 4.1 "NB: Cisco doesn't have an exact equivalent to "Internal BGP Alias", but the combination of the Cisco features iBGP local-AS and dual-as provides similar functionality." -- This sentence would be better-placed in section 10, IMO. L) section 4.1, itemized list, item 4: a reference to section 3 would be nice M) section 10: it would be interesting to indicate, for each vendor, what are the feature names corresponding to what is described in sections 3.1, 3.2 and 4 *Nits:* - In the abstract: s/feaures/features/ - In the abstract: the title would be more readable without "(AS)"; introducing this acronym, along with "ASN" can be done for instance in the introduction - in 3.1: "ISP B needs to do this without coordinating the change of its ASN with all of its eBGP peers, simultaneously." is not very easy to read (maybe "ISP B needs to be able to do this without coordinating a simultaneous change... peers" would be better?) - in 3.1: "Within the context of ISP B's PE router, The second effect ..." -> s/The/the/ Best, -Thomas From nobody Fri Sep 12 11:55:36 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C8D1A86E5 for ; Fri, 12 Sep 2014 11:12:42 -0700 (PDT) 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 TM64orubRCGR for ; Fri, 12 Sep 2014 11:12:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::710]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4224B1A86DD for ; Fri, 12 Sep 2014 11:11:03 -0700 (PDT) Received: from sreinhardt-sslvpn-nc.jnpr.net (66.129.241.14) by BL2PR05MB147.namprd05.prod.outlook.com (10.242.198.22) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 12 Sep 2014 18:10:29 +0000 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_6B7AF93C-D553-41B3-9F15-BEB50F30094D" From: Jeff Haas In-Reply-To: Date: Fri, 12 Sep 2014 14:09:03 -0400 Message-ID: <5FA68A99-8400-4279-9491-139DC014C6FD@juniper.net> References: To: "Bitar, Nabil N" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: DM2PR11CA0017.namprd11.prod.outlook.com (25.160.91.27) To BL2PR05MB147.namprd05.prod.outlook.com (10.242.198.22) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0332AACBC3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(199003)(189002)(377454003)(51704005)(164054003)(24454002)(69596002)(82746002)(71186001)(105586002)(97736003)(62966002)(81542001)(81342001)(83322001)(19580405001)(19580395003)(84326002)(85852003)(83072002)(79102001)(99396002)(90102001)(87976001)(88136002)(230783001)(77156001)(89996001)(20776003)(102836001)(110136001)(104166001)(80022001)(66066001)(81156004)(106356001)(512944002)(64706001)(107046002)(36756003)(33656002)(31966008)(46102001)(42186005)(57306001)(74502001)(74662001)(21056001)(95666004)(101416001)(76482001)(53416004)(87286001)(77096002)(50226001)(86362001)(93916002)(85306004)(4396001)(50986999)(76176999)(77982001)(92726001)(92566001)(83716003)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB147; H:sreinhardt-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/HluukL8vh_44d8k3V_OmsZ4Rd-E X-Mailman-Approved-At: Fri, 12 Sep 2014 11:55:35 -0700 Cc: "rtg-dir@ietf.org" , "db3546@att.com" , "rtg-ads@tools.ietf.org" , Jonathan Hardwick , "jgs@juniper.net" , Susan Hares Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 18:12:42 -0000 --Apple-Mail=_6B7AF93C-D553-41B3-9F15-BEB50F30094D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" Nabil, Thanks for your review! As seen below, I have accepted the majority of your changes but have yet = to issue an updated draft. There is one topic requiring some further = discussion. Once we've resolved that, I'll issue an updated I-D. -- Jeff On Sep 8, 2014, at 10:22 AM, Bitar, Nabil N = wrote: > Minor Issues: >=20 > Following are suggested edits. >=20 >=20 > Abstract: > Change: originally documented in RFC 5575 =E0 originally documented = in RFC 5575 (Dissemination of Flow Specification Rules) Done. >=20 > - Page 3, last sentence > a common interpretation of the Redirect Extended Community=92s "6-byte = Route Target" has been to look for any matching Route Target sharing the = same Value portion of its Extended Community. Thus, multiple Route = Targets provisioned in a router=92s VRFs might match even though the = format was different. > =20 > Suggested new text: > a common interpretation of the redirect extended community=92s "6-byte = route target" has been to look, at a receiving router, for a route = target value that matches the route target value in the received = redirect extended community, and import the advertised route to the = corresponding VRF instance subject to the rules defined in RFC 5575 [RFC = 5575]. However, because the route target format in the redirect extended = community is not clearly defined, the wrong match may occur. Accepted. > =20 > - Page 4, second paragraph: > =20 > This "Value wildcard" behavior does not matched deployed = implementations of BGP Flowspec. > =20 >=20 > Suggested new text: > This "value wildcard" matching behavior, that does not take into = account the format of the route target defined for a local VRF and may = result in the wrong matching decision, does not match deployed = implementations of BGP flowspec. Deployed implementations of BGP = flowspec solves this problem by defining different redirect extended = communities that are specific to the format of the route target value. = This document defines the following redirect extended communities: Accepted. > =20 > > =20 > - Page 4, first sentence under table: > =20 > It should be noted that the low-order nybble of the > Redirect=92s type field corresponds to the Route Target Extended = Community format field (Type). (See [RFC4360], Secs. 3.1, 3.2 and = [RFC5668], Sec. 2.) The low order octet (Sub-Type) of the Redirect = Extended Community remains 0x08, contrasted to 0x02 for Route Targets. > =20 > Question: Why is the reference to RFC 4360 section 3.1 and 3.2, and = RFC 5668 section 2? See to be the wrong references. Did you mean to = refer to RFC 4360 section 4? The reference is basically to draw attention to the structural history = for why this was coded the way it was. The above references demonstrate = where that structure is defined. > =20 > Suggested new text: > It should be noted that the low-order nybble of the > High-order octet of the redirect extended community yype field in = Table 1 corresponds to that in the high-order octet of the route target = extended community type field. The low order octet (sub-type) of the = redirect extended Community remains 0x08, contrasted to 0x02 for route = targets (see [RFC4360] section 4). See above. If you'd like to further clarify, let's talk about it in the = above context. > =20 > - Note: I suggest that you add text on matching the newly defined = redirect extended communities to route targets defined for VRF=92s to = update what is in RFC 5575. I am unclear what you're asking here. If the idea is that there should = be text in this draft saying "route-targets exist and if they match this = RT in the flowspec redirect, install it in the relevant VRF", I'd rather = defer to the underlying base behavior in 5575. > =20 > =20 > Section 2 IANA Considerations (minor comments): > =20 > - 0x81 > "Generic Transitive Experimental Extended Community Part 2 Sub-Types" = Registry > ------------------- > =20 > Change: Experimental =E0 Experimental Use > =20 > - 0x82 > "Generic Transitive Experimental Extended Community Part 3 Sub-Types" > ------------------- > =20 > Change: Experimental =E0 Experimental Use > =20 > - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL = EXTENDED COMMUNITY PART 2 SUB-TYPES registry. It should be seeded with = the following Sub-Type > =20 > Change: Experimental =E0 Experimental Use > =20 > =20 > - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL = EXTENDED COMMUNITY PART 3 SUB-TYPES registry. It should be seeded with = the following Sub-Type > =20 > =20 > Change: Experimental =E0 Experimental Use All accepted. > =20 > =20 >=20 > Nits:=20 >=20 > None noticed. >=20 >=20 >=20 > Thanks, > Nabil > =20 --Apple-Mail=_6B7AF93C-D553-41B3-9F15-BEB50F30094D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" Nabil,

Thanks for your = review!

As seen below, I have accepted the = majority of your changes but have yet to issue an updated draft. =  There is one topic requiring some further discussion.  Once = we've resolved that, I'll issue an updated = I-D.

-- = Jeff

On Sep 8, 2014, at 10:22 AM, = Bitar, Nabil N <nabil.n.bitar@verizon.com>= ; wrote:

Minor = Issues:

Following are suggested = edits.


Abstract:
Change:  originally = documented in RFC 5575 =E0 originally documented in RFC = 5575 (Dissemination of Flow Specification = Rules)

Done.

<= blockquote type=3D"cite">

- Page = 3, last sentence
a common interpretation of the = Redirect Extended Community=92s "6-byte Route Target" has been to look = for any matching Route Target sharing the same Value portion of its = Extended Community. Thus, multiple Route Targets provisioned in a = router=92s VRFs might match even though the format was = different.
 
Suggested new text:
a = common interpretation of the redirect extended community=92s "6-byte = route target" has been to look, at a receiving router, for a route = target value that matches the route target value in the received = redirect extended community, and import the advertised route to the = corresponding VRF instance subject to the rules defined in RFC 5575 [RFC = 5575]. However, because the route target format in the redirect extended = community is not clearly defined, the wrong match may = occur.

Accepted.
<= br>
 
- Page = 4, second paragraph:
 
This "Value wildcard" behavior = does not matched deployed implementations of BGP = Flowspec.

 

Suggested new text:
This = "value wildcard" matching behavior, that does not take into account the = format of the route target defined for a local VRF and may result in the = wrong matching decision, does not match deployed implementations of BGP = flowspec. Deployed implementations of BGP flowspec solves this problem = by defining different redirect extended communities that are specific to = the format of the route target value. This document defines the = following redirect extended = communities:

Accepted.
=

 
<Keep= table here>
 
- Page = 4, first sentence under table:
 
It should be noted that the = low-order nybble of the
Redirect=92s type field = corresponds to the Route Target Extended Community format field (Type). = (See [RFC4360], Secs. 3.1, 3.2 and [RFC5668], Sec. 2.) The low order = octet (Sub-Type) of the Redirect Extended Community remains 0x08, = contrasted to 0x02 for Route Targets.
 
Question:  Why is = the reference to RFC 4360 section 3.1 and 3.2, and RFC 5668 section 2? = See to be the wrong references. Did you mean to refer to RFC 4360 = section 4?

The reference = is basically to draw attention to the structural history for why this = was coded the way it was.  The above references demonstrate where = that structure is defined.

 
Suggested new text:
It = should be noted that the low-order nybble of = the
High-order octet of the redirect = extended community yype field in Table 1 corresponds to that in the = high-order octet of the route target extended community type field. The = low order octet (sub-type) of the redirect extended Community remains = 0x08, contrasted to 0x02 for route targets (see [RFC4360] section = 4).

See above.  If = you'd like to further clarify, let's talk about it in the above = context.

 
- = Note:  I = suggest that you add text on matching the newly defined redirect = extended communities to route targets defined for VRF=92s to update what = is in RFC 5575.

I am = unclear what you're asking here.  If the idea is that there should = be text in this draft saying "route-targets exist and if they match this = RT in the flowspec redirect, install it in the relevant VRF", I'd rather = defer to the underlying base behavior in 5575.

 
 
Section 2 IANA Considerations = (minor comments):
 
- = 0x81
"Generic Transitive Experimental = Extended Community Part 2 Sub-Types" = Registry
         &nb= sp;            = ;            &= nbsp;  -------------------
 
Change: = Experimental =E0 Experimental = Use
 
- = 0x82
"Generic Transitive Experimental = Extended Community Part 3 Sub-Types"
         &nb= sp;            = ;            &= nbsp;  -------------------
 
Change: = Experimental =E0 Experimental = Use
 
- IANA = is requested to create the GENERIC TRANSITIVE EXPERIMENTAL EXTENDED = COMMUNITY PART 2 SUB-TYPES registry. It should be seeded with the = following Sub-Type
 
Change: = Experimental =E0 Experimental = Use
 
 
- IANA is requested to create the = GENERIC TRANSITIVE EXPERIMENTAL EXTENDED COMMUNITY PART 3 SUB-TYPES = registry. It should be seeded with the following = Sub-Type
 
 
Change: Experimental =E0 Experimental = Use

All = accepted.

 

 

Nits: 

None = noticed.



Thanks,
Nabil
 

= --Apple-Mail=_6B7AF93C-D553-41B3-9F15-BEB50F30094D-- From nobody Mon Sep 15 07:43:57 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007BA1A036A; Mon, 15 Sep 2014 07:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, 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 l8NgaB8fqWNq; Mon, 15 Sep 2014 07:43:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4453D1A036B; Mon, 15 Sep 2014 07:43:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 85A76C245; Mon, 15 Sep 2014 10:43:52 -0400 (EDT) Date: Mon, 15 Sep 2014 10:43:52 -0400 From: Jeffrey Haas To: Thomas Morin Message-ID: <20140915144352.GC14947@pfrc> References: <5412BF1F.7030206@orange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5412BF1F.7030206@orange.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/1jiONgWAaX4Bik6wCln_wEui6g8 Cc: idr@ietf.org, draft-ietf-idr-as-migration.all@tools.ietf.org, "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 14:43:56 -0000 On Fri, Sep 12, 2014 at 11:38:39AM +0200, Thomas Morin wrote: > Although it is all about local behavior, it makes sense to make a > standard track document that (a) can be used as a reference for > implementors and deployers to implement this properly, and (b) keep > track of these features in future evolutions of the protocol (as > motivated in the Conclusion section of the document).* My personal concern about making this a proposed standard is several of these mechanisms are not fully implemented even across the surveyed vendors. In many cases, there are differing implementations that serve similar needs but are slightly different to accommodate the implementation. This is despite the fact that, from a vendor standpoint, the features are internally mature. If there were strong motivations to move to a specific other-vendor transitional mechanism, it likely would have been done by now. To some extent, a proposed standard suggests that a given mechanism should be implemented. The current informational status says "this is what has been done". -- Jeff From nobody Mon Sep 15 08:02:20 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0A1A036A; Mon, 15 Sep 2014 08:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 qvrK2xEl8cfe; Mon, 15 Sep 2014 08:02:15 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 949101A037D; Mon, 15 Sep 2014 08:02:15 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,528,1406606400"; d="scan'208";a="516702003" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Sep 2014 10:59:47 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 15 Sep 2014 11:02:14 -0400 From: "George, Wes" To: Jeffrey Haas , Thomas Morin Date: Mon, 15 Sep 2014 11:02:13 -0400 Thread-Topic: [Idr] RtgDir review: draft-ietf-idr-as-migration-02 Thread-Index: Ac/Q9giEOLBKG/g3SxOVXm/nCMrgMw== Message-ID: References: <5412BF1F.7030206@orange.com> <20140915144352.GC14947@pfrc> In-Reply-To: <20140915144352.GC14947@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/zxpy1tER75PHPbbFURYwagU9i_s Cc: "idr@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-idr-as-migration.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:02:17 -0000 T24gOS8xNS8xNCwgMTA6NDMgQU0sICJKZWZmcmV5IEhhYXMiIDxqaGFhc0BwZnJjLm9yZz4gd3Jv dGU6DQoNCg0KPk15IHBlcnNvbmFsIGNvbmNlcm4gYWJvdXQgbWFraW5nIHRoaXMgYSBwcm9wb3Nl ZCBzdGFuZGFyZCBpcyBzZXZlcmFsIG9mDQo+dGhlc2UgbWVjaGFuaXNtcyBhcmUgbm90IGZ1bGx5 IGltcGxlbWVudGVkIGV2ZW4gYWNyb3NzIHRoZSBzdXJ2ZXllZA0KPnZlbmRvcnMuDQo+SW4gbWFu eSBjYXNlcywgdGhlcmUgYXJlIGRpZmZlcmluZyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzZXJ2ZSBz aW1pbGFyDQo+bmVlZHMNCj5idXQgYXJlIHNsaWdodGx5IGRpZmZlcmVudCB0byBhY2NvbW1vZGF0 ZSB0aGUgaW1wbGVtZW50YXRpb24uICBUaGlzIGlzDQo+ZGVzcGl0ZSB0aGUgZmFjdCB0aGF0LCBm cm9tIGEgdmVuZG9yIHN0YW5kcG9pbnQsIHRoZSBmZWF0dXJlcyBhcmUNCj5pbnRlcm5hbGx5DQo+ bWF0dXJlLiAgSWYgdGhlcmUgd2VyZSBzdHJvbmcgbW90aXZhdGlvbnMgdG8gbW92ZSB0byBhIHNw ZWNpZmljDQo+b3RoZXItdmVuZG9yDQo+dHJhbnNpdGlvbmFsIG1lY2hhbmlzbSwgaXQgbGlrZWx5 IHdvdWxkIGhhdmUgYmVlbiBkb25lIGJ5IG5vdy4NCj4NCj5UbyBzb21lIGV4dGVudCwgYSBwcm9w b3NlZCBzdGFuZGFyZCBzdWdnZXN0cyB0aGF0IGEgZ2l2ZW4gbWVjaGFuaXNtIHNob3VsZA0KPmJl IGltcGxlbWVudGVkLiAgVGhlIGN1cnJlbnQgaW5mb3JtYXRpb25hbCBzdGF0dXMgc2F5cyAidGhp cyBpcyB3aGF0IGhhcw0KPmJlZW4gZG9uZSIuDQoNCldHXSBJJ3ZlIHN0cnVnZ2xlZCB3aXRoIHRo aXMgcHJvYmxlbSB0aHJvdWdob3V0IHRoZSB3cml0aW5nIG9mIHRoaXMgZHJhZnQuDQpBcyBJIG5v dGVkIGluIFRvcm9udG8sIHRoZXJlIHdhcyBzaWduaWZpY2FudCBkaXNjdXNzaW9uIGFtb25nIGEg Y291cGxlIG9mDQpteSBvZmZsaW5lIHJldmlld2VycyBhYm91dCB0aGUgdGVybWlub2xvZ3kgdXNl ZCwgc2luY2Ugc29tZSBvZiBpdCBpcw0Kc3BlY2lmaWMgdG8gb25lIHZlbmRvciB2cyBhbm90aGVy LiBJIGJlbGlldmUgdGhlIGRvY3VtZW50IGNhcHR1cmVzIHdoYXQNCndvdWxkIGJlIG5lY2Vzc2Fy eSBmb3IgYSAqbmV3KiBpbXBsZW1lbnRhdGlvbi4gV2hpbGUgbm90IGFsbCBleGlzdGluZw0KaW1w bGVtZW50YXRpb25zIG1heSBoYXZlIGltcGxlbWVudGVkIGFsbCBvZiB0aGUgZmVhdHVyZXMgZXhh Y3RseSBhcw0KZGVzY3JpYmVkIGhlcmUsIGlmIG9uZSB3ZXJlIGltcGxlbWVudGluZyBmcm9tIHNj cmF0Y2gsIGl0IG1heSBiZSBlYXNpZXIgdG8NCnVzZSB0aGlzIGFzIGEgYmFzZWxpbmUgaW5zdGVh ZCBvZiB0cnlpbmcgdG8gY29weSBvciByZXZlcnNlLWVuZ2luZWVyIGENCnZlbmRvci1zcGVjZmlj IGltcGxlbWVudGF0aW9uLg0KSSdtIG9wZW4gdG8gYWRkaW5nIHNvbWUgYWRkaXRpb25hbCB0ZXh0 IHRvIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGlzIGlzDQpzaW1wbHkgZG9jdW1lbnRpbmcgYSByZWZl cmVuY2UgaW1wbGVtZW50YXRpb24gdGhhdCBjYW4gYmUgdXNlZCBmb3IgbmV3DQppbXBsZW1lbnRh dGlvbnMsIGJ1dCB0aGF0IGl0IGRvZXMgbm90IGltcGx5IGEgcmVxdWlyZW1lbnQgdG8gbW9kaWZ5 DQpleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdG8gaGFybW9uaXplIHRoZW0gd2l0aCB0aGlzIHN0 YW5kYXJkLg0KVGhlIGRvY3VtZW50IGRvZXMgc2F5IGluIG1vcmUgdGhhbiBvbmUgcGxhY2UgdGhh dCBpbnRlcm9wZXJhYmlsaXR5IGlzIG5vdA0KYSByZXF1aXJlbWVudCBiZWNhdXNlIHRoZSBmZWF0 dXJlcyBhcmUgYWxsIGxvY2FsbHkgc2lnbmlmaWNhbnQsIGJ1dCBpZiB5b3UNCmhhdmUgYSBzdWdn ZXN0aW9uIGZvciB0ZXh0IHRvIG1ha2UgdGhpcyBjbGVhcmVyLCBJJ20gaGFwcHkgdG8gaW5jb3Jw b3JhdGUNCml0Lg0KVGhlIG9ubHkgb3RoZXIgdGhpbmcgSSBjYW4gdGhpbmsgb2YgaGVyZSB3b3Vs ZCBiZSB0byBoYXZlIGEgbW9yZSBpbi1kZXB0aA0KY29tcGFyaXNvbiBiZXR3ZWVuIHRoZSBkaWZm ZXJlbnQgdmVuZG9yIGltcGxlbWVudGF0aW9ucywgYnV0IEkgZG9uJ3Qgc2VlDQp0aGUgcG9pbnQg aW4gZG9pbmcgdGhhdCBzaW5jZSBJJ20gYWxyZWFkeSBwb2ludGluZyB0byB0aGUgdmVuZG9yDQpk b2N1bWVudGF0aW9uLCBhbmQgY29tcGFyaW5nIGltcGxlbWVudGF0aW9ucyBkb2Vzbid0IHNlZW0g YXBwcm9wcmlhdGUgZm9yDQphIGRvY3VtZW50IGxpa2UgdGhpcy4NCg0KVGhhbmtzLA0KDQpXZXMN Cg0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFu eeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0t LS0NCg0KDQoNCg0KDQoNCg0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9u LCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJp Z2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGlj aCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg b2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9u IHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0 aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Mon Sep 15 10:24:09 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34F11A0699; Mon, 15 Sep 2014 10:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 EyD8qEpYTtNg; Mon, 15 Sep 2014 10:23:59 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 799AA1A700C; Mon, 15 Sep 2014 09:44:37 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,529,1406606400"; d="scan'208";a="516818528" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Sep 2014 12:42:08 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 15 Sep 2014 12:44:36 -0400 From: "George, Wes" To: Thomas Morin , "idr@ietf.org" , "rtg-ads@tools.ietf.org" Date: Mon, 15 Sep 2014 12:44:36 -0400 Thread-Topic: [Idr] RtgDir review: draft-ietf-idr-as-migration-02 Thread-Index: Ac/RBFWUjh2dA4e9Qpyu+3t3ycoanQ== Message-ID: References: <5412BF1F.7030206@orange.com> In-Reply-To: <5412BF1F.7030206@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Uw9JMb_eelNrU1i-Hd6MxzbDYyk Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-as-migration.all@tools.ietf.org" Subject: Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:24:05 -0000 VGhhbmtzIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LiBNeSByZXNwb25zZXMgYmVsb3cgaW5saW5l Lg0KDQpPbiA5LzEyLzE0LCA1OjM4IEFNLCAiVGhvbWFzIE1vcmluIiA8dGhvbWFzLm1vcmluQG9y YW5nZS5jb20+IHdyb3RlOg0KDQoNCj5BKSBUaGUgaW50cm9kdWN0aW9uIHNheXM6DQo+DQo+ICAg IEluIHBhcnRpY3VsYXINCj4gICAgdGhlIElTUCB3b3VsZCBoYXZlIHRvIGVuY291cmFnZSB0aG9z ZSBjdXN0b21lcnMgdG8gY2hhbmdlIHRoZWlyIENFDQo+ICAgIHJvdXRlciBjb25maWdzIHRvIHVz ZSB0aGUgbmV3IEFTTiBpbiBhIHZlcnkgc2hvcnQgcGVyaW9kIG9mIHRpbWUsDQo+ICAgIHdoZW4g dGhlIGN1c3RvbWVyIGhhcyBubyBidXNpbmVzcyBpbmNlbnRpdmUgdG8gZG8gc28uICBUaHVzLCBp dA0KPiAgICBiZWNvbWVzIGNyaXRpY2FsIHRvIGFsbG93IHRoZSBJU1AgdG8gbWFrZSB0aGlzIHBy b2Nlc3MgYSBiaXQgbW9yZQ0KPiAgICBhc3ltbWV0cmljLCBzbyB0aGF0IGl0IGNvdWxkIHNlYW1s ZXNzbHkgbWlncmF0ZSB0aGUgQVNOIHdpdGhpbiBpdHMNCj4gICAgbmV0d29yayhzKSwgYnV0IG5v dCBkaXN0dXJiIGV4aXN0aW5nIGN1c3RvbWVycywgYW5kIGFsbG93IHRoZQ0KPiAgICBjdXN0b21l cnMgdG8gZ3JhZHVhbGx5IG1pZ3JhdGUgdG8gdGhlIElTUCdzIG5ldyBBU04gYXQgdGhlaXIgbGVp c3VyZS4NCj4NCj5Ib3dldmVyLCBJIGRpZCBub3QgdW5kZXJzdGFuZCB3aGljaCBwYXJ0IG9mIHRo ZSBzcGVjcyB3b3VsZCBhbGxvdyB0aGUNCj5jdXN0b21lciB0byBjaGFuZ2UgaXRzIENFDQo+Y29u ZmlndXJhdGlvbiB3aXRob3V0IGNvb3JkaW5hdGluZyBhIG1haW50ZW5hbmNlIHdpbmRvdyB3aXRo IHRoZSBJU1AuDQoNCldHXSB3ZWxsLCB0aGF0IGlzIG5vdCBleGFjdGx5IHdoYXQgdGhlIGFib3Zl IHNheXMuIFRoZSBpZGVhIHdhcyB0byBtYWtlIGENCmRpc3RpbmN0aW9uIGJldHdlZW4gYSBnbG9i YWxseSBjb29yZGluYXRlZCB3aW5kb3cgYmV0d2VlbiBhbGwgY3VzdG9tZXJzIG9uDQp0aGUgcm91 dGVyIChzeW1tZXRyaWMgY2hhbmdlKSB2cyBiZWluZyBhYmxlIHRvIGNvb3JkaW5hdGUgaW5kaXZp ZHVhbGx5DQooYXN5bW1ldHJpYykuIEkgZG8gc2VlIHlvdXIgcG9pbnQgdGhvdWdoLCBhbmQgSSBj YW4gbWFrZSBpdCBtb3JlIGV4cGxpY2l0Lg0KDQo+DQo+UHJvY2VkdXJlcyBpbiBzZWN0aW9uIDMs IGFzICBkZXNjcmliZWQsIHdvbid0IGxldCB0aGUgY3VzdG9tZXIgQ0UNCj5jb25uZWN0IHRvIHRo ZSByb3V0ZXIgd2l0aCB0aGUgbmV3IEFTTi4gU2VlLCBpbiBwYXJ0aWN1bGFyIGluIHRoZSBzZWNv bmQNCj7CpyBvZiBzZWN0aW9uIDMuMzogIlRoZSBzcGVha2VyIE1VU1QgTk9UIHVzZSB0aGUgQVNO IGNvbmZpZ3VyZWQgZ2xvYmFsbHkNCj53aXRoaW4gdGhlIEJHUCBwcm9jZXNzIGFzIHRoZSB2YWx1 ZSBzZW50IGluIE1ZIEFTTiBpbiB0aGUgT1BFTiBtZXNzYWdlLg0KPiIuIEl0IHNlZW1zIHRoYXQg dGhlIGdvYWwgc3BlY2lmaWVkIGluIHRoZSBpbnRybyB3aWxsIHRodXMgbm90IGJlIG1ldA0KPmZ1 bGx5Lg0KPg0KPlR3byB0aGluZ3Mgd291bGQgYmUgcG9zc2libGU6IGZpeGluZyB0aGUgaW50cm8g dG8gc3RhdGUgYSBzbGlnaHRseQ0KPmRpZmZlcmVudCBnb2FsLCBvciBjaGFuZ2UgdGhlIHByb2Nl ZHVyZXMgdG8gbGV0IGEgcm91dGVyIGVzdGFibGlzaCBhDQo+c2Vzc2lvbiB3aXRoIHRoZSBnbG9i YWxseSBhc3NpZ25lZCBuZXcgQVMsIGV2ZW4gd2hlbiAnbG9jYWwtYXMgb2xkLUFTIg0KPmlzIGNv bmZpZ3VyZWQuIEknbSBub3QgZXhwZXJ0IGVub3VnaCB0byBrbm93IGlmIHRoZSBsYXR0ZXIgd291 bGQgd29yay4NCg0KV0ddIEknZCByZWZlciB5b3UgdG8gc2VjdGlvbiA0LjIsIHdoaWNoIGFsbG93 cyBhIG1vcmUgZmxleGlibGUNCmNvbmZpZ3VyYXRpb24gdGhhdCBjYW4gZXN0YWJsaXNoIGEgc2Vz c2lvbiB1c2luZyBlaXRoZXIgb2xkIG9yIG5ldyBBU04uDQpXaGlsZSBpdCdzIGRpc2N1c3NlZCBp biB0aGUgaUJHUCBzZWN0aW9uLCB0aGUgdGV4dCBkb2VzIG5vdGUgdGhhdCB0aGlzDQpjb3VsZCBi ZSBkb25lIHdoZXRoZXIgaW4gaUJHUCBvciBlQkdQLg0KDQoNCj4NCj5CKSBzdGlsbCBhYm91dCB0 aGUgaW50cm86IGl0IHNlZW1zIHRoYXQgdGhpcyBpbnRybyBpcyBmb2N1c2VkIG9uIHRoZQ0KPm1v dGl2YXRpb24gZm9yIGVCR1AtcmVsYXRlZCBmZWF0dXJlcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAz LCBidXQgc2lsZW50DQo+b24gaUJHUCBhbmQgc2VjdGlvbiA0DQpXR10gSW4gbXkgbWluZCwgZUJH UCBpcyB0aGUgcHJpbWFyeSBtb3RpdmF0b3IgZm9yIHRoaXMgZHJhZnQgZHVlIHRvIHRoZQ0KZXh0 ZXJuYWwgY29vcmRpbmF0aW9uL0FTLXBhdGggbGVuZ3RoZW5pbmcgcHJvYmxlbXMuIGlCR1AgaXMg YSBoYXBweSB1cHNob3QNCnRvIHRoZSBmdW5jdGlvbmFsaXR5LCBzbyBJIGRpZG4ndCBzZWUgdGhl IG5lZWQgdG8gYWRkIHRoYXQgaW4gdGhlIGludHJvLg0KSSdsbCBtYWtlIGEgcGFzcyB0aHJvdWdo IHRvIHNlZSBpZiBJIGNhbiBmaXggdGhpcyB3aXRoIGEgbWluaW1hbCBhZGRpdGlvbi4NCg0KPg0K PkMpIGluIHNlY3Rpb24gMywgc2Vjb25kIMKnLCB0aGVyZSBpcyBhIGRpc2N1c3Npb24gYWJvdXQg Y2hhbmdpbmcgdGhlDQo+QVNfUEFUSCBsZW5ndGggOyBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZXJl IGlzIGEgaGlkZGVuIGFzc3VtcHRpb24gb24NCj53aGF0IGludGVyY29ubmVjdGlvbiBleGlzdCBi ZXR3ZWVuIElTUCBBIGFuZCBJU1AgQiBwcmlvciB0byB0aGUNCj5taWdyYXRpb24gOyB0aGUgdGV4 dCBzYXlzICJ3aGVyZWFzIHRoZSBzYW1lIFJJQiBvbiBJU1AgQScgd291bGQgY29udGFpbg0KPkFT X1BBVEg6IDY0NTEwIDY0NDk2LCB3aGljaCBpcyBhbiBpbmNyZWFzZSBpbiBBU19QQVRIIGxlbmd0 aCBmcm9tDQo+cHJldmlvdXNseSIgd2hpY2ggc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCBJU1AgQSBh bmQgSVNQIEIgYXJlIHBlZXJpbmcNCj53aXRoIGVhY2ggb3RoZXIuIElmIHRoaXMgaXMgY29ycmVj dCwgdGhpcyBzaG91bGQgYmUgc3RhdGVkIGNsZWFybHkgaW4NCj5zZWN0aW9uIDIsIGFuZCBub3Qg YmUgYSBoaWRkZW4gYXNzdW1wdGlvbi4NCg0KV0ddIGFjaywgbmVlZCB0byBtYWtlIGl0IGNsZWFy IHdoYXQgd2UgbWVhbiBieSAicHJldmlvdXNseSINCg0KPg0KPkQpIGluIHNlY3Rpb24gMzogIiBU aHVzLCB3aXRoaW4gTG9jLVJJQiBvbiBJU1AgQicgdGhlIEFTX1BBVEggdG93YXJkDQo+Y3VzdG9t ZXIgQyB3b3VsZCBhcHBlYXIgYXM6IDY0NTEwIi4gSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhhdCB0 aGUNCj5BU19QQVRIIG9mIHJvdXRlcyBsZWFybmVkIGJ5IFBFIHJvdXRlcnMgb2YgSVNQIEIgaW4g dGhpcyBzaXR1YXRpb24gKGlmDQo+bG9jYWwtYXMgbm8tcHJlcGVuZCBpcyBub3QgdXNlZCksIHdv dWxkIGJlICI2NDQ5NiIgb3IgIjY0NTEwIDY0NDk2Ig0KPnJhdGhlciB0aGFuICI2NDUxMCIgYWxv bmUuLi4gYnV0IEkgY291bGQganVzdCBiZSB3cm9uZy4NCg0KV0ddIFRoaXMgaXMgZGVzY3JpYmlu ZyB0aGUgQVNfUEFUSCBwcmUtbWlncmF0aW9uLCBhbmQgdGhlbiBzaG93aW5nIHdoYXQNCmhhcHBl bnMgZHVyaW5nIG1pZ3JhdGlvbi4gSSB0aGluayBJIGNhbiBjbGFyaWZ5Lg0KDQo+DQo+RSkgSW4g c2VjdGlvbiAyLCB0aGlyZCBwYXJhZ3JhcGg6DQo+DQo+VGhpcyBoaWdoIGxldmVsIGRlc2NyaXB0 aW9uIG9mIHRoZSBwcm9jZWR1cmVzIGluIDMgaXMgSSB0aGluayBtaXNzaW5nIGENCj5kZXNjcmlw dGlvbiBvZiB0aGUgZmFjdCB0aGF0LCBhbW9uZyB0aGUgZmVhdHVyZXMgb2Ygc3RlcCAyIHRoZXJl IGlzIGFsc28NCj5hIGZlYXR1cmUsIG5vdCByZWxhdGVkIHRvIGZpeGluZyB0aGUgYXMgcGF0aCwg dGhhdCBhaW1zIGF0IGFsbG93aW5nIEJHUA0KPnNlc3Npb25zIHRvIGJlIGVzdGFibGlzaGVkIHVz aW5nIEFTTiA2NDUxMC4NCj5JIHdvdWxkIHN1Z2dlc3QgcmV3cml0aW5nIHRoZSBsYXN0IHNlbnRl bmNlIGFzOg0KPg0KPiAgICBUaGVzZSBmZWF0dXJlcyBhbGxvdyB0aGUgZXN0YWJsaXNobWVudCBv ZiBzZXNzaW9ucyB3aXRoIHRoZSBsZWdhY3kNCj5BU04gNjQ1MTAsDQo+ICAgIG1vZGlmeSB0aGUg QVNfUEFUSCBhdHRyaWJ1dGUgcmVjZWl2ZWQgZnJvbSBhIENFIGRldmljZSB3aGVuDQo+YWR2ZXJ0 aXNpbmcgaXQgZnVydGhlciwNCj4gICAgYW5kIG1vZGlmeSBBU19QQVRIIHdoZW4gdHJhbnNtaXR0 ZWQgdG93YXJkIENFIGRldmljZXMgdG8gYWNoaWV2ZSB0aGUNCj5kZXNpcmVkIGVmZmVjdCBvZiBu b3QNCj4gICAgaW5jcmVhc2luZyB0aGUgbGVuZ3RoIG9mIHRoZSBBU19QQVRILg0KDQpXR10gYWNr DQo+DQo+Rikgc2VjdGlvbiAzLjE6IGl0IHdvdWxkIGJlIHdvcnRoIG1lbnRpb25pbmcgaXQgZXhw bGljaXRseSwgYXQgdGhlIGVuZA0KPm9mIHRoZSBmaXJzdCBwYXJhZ3JhcGgsIHRoYXQgYWxvbmUs IHRoaXMgY2hhbmdlIHJlc3VsdHMgaW4gYW4NCj5pbnRlcnJ1cHRpb24gb2Ygc2VydmljZQ0KDQpX R10gYWNrDQo+DQo+RykgdGhlIG5hbWluZyBnaXZlbiB0byBBU3MgYW5kIHJvdXRlcnMgYWxvbmcg dGhlIGRvY3VtZW50Kipjb3VsZCBJIHRoaW5rDQo+YmUgbGFyZ2VseSBpbXByb3ZlZCB0byBtYWtl IHRoZSBkb2N1bWVudCBlYXNpZXIgdG8gcmVhZC4gSSB3b3VsZCBzdWdnZXN0DQo+dGhlIGZvbGxv d2luZzoNCj4qIEluIHRoZSBmaWd1cmVzIDMgYW5kIDQgb2Ygc2VjdGlvbiAzLjEgYW5kIDMuMjog IGludmVydCB0aGUgZmlndXJlDQo+bGVmdC1yaWdodCB0byBoYXZlIEFTNjQ0OTkgb24gdGhlIGxl ZnQgbGlrZSBpbiBmaWd1cmVzIDEgYW5kIDINCldHXSBJIHVuZGVyc3RhbmQgdGhlIHBhcmFsbGVs aXNtL3N5bW1ldHJ5IHRoYXQgeW91J3JlIHN1Z2dlc3RpbmcsIGJ1dA0KZmxpcHBpbmcgdGhlIEFT TnMgd291bGQgcmVxdWlyZSByZXdyaXRpbmcgYSBzdWJzdGFudGlhbCBhbW91bnQgb2YgdGhlDQpl eGFtcGxlLiBJIHRoaW5rIHlvdSdyZSBzdWdnZXN0aW5nIG1pcnJvciBpbWFnZSwgd2hpY2ggd291 bGQgbGVhdmUgdGhlDQpleGFtcGxlIHRleHQgdW5jaGFuZ2VkLCBidXQgYXNzdW1lcyB0aGF0IGV2 ZXJ5b25lIGlzIG9rIHdpdGggdGhlIGFycm93cw0KcG9pbnRpbmcgcmlnaHQgdG8gbGVmdCBpbiBm aWcgMywgYW5kIHRoZW4gbGVmdCB0byByaWdodCBpbiBmaWcgNCwgYXMgd2VsbA0KYXMgUEUyL0NF MiBzaG93aW5nIG9uIHRoZSBsZWZ0LCBQRTEvQ0UxIG9uIHRoZSByaWdodCBpbiBib3RoLCB3aGlj aCBpcw0Kc29ydCBvZiBiYWNrd2FyZCBmcm9tIHdlc3Rlcm4gY29udmVudGlvbiBhbmQgY29uZnVz aW5nIGZvciBhIGRpZmZlcmVudA0KcmVhc29uLiBJIHRoaW5rIEknbSBnb2luZyB0byBvZmZlbmQg YSBkaWZmZXJlbnQgc2V0IG9mIGFlc3RoZXRpY3Mgd2l0aA0KZWl0aGVyIG9uZSwgYW5kIEknbSBu b3Qgc3VyZSBpdCBtYWtlcyBhIGdyZWF0IGRlYWwgb2YgZGlmZmVyZW5jZSBpbiB0aGUNCnJlYWRh YmlsaXR5IG9mIHRoZSBmaWd1cmVzLiBPcGVuIGZvciBmdXJ0aGVyIGRpc2N1c3Npb24uDQoNCj4q IEluIHRoZSBmaWd1cmVzIDMgYW5kIDQgb2Ygc2VjdGlvbiAzLjEgYW5kIDMuMiwgYW5kIGFzc29j aWF0ZWQgdGV4dDoNCj5pbnN0ZWFkIG9mIG5hbWluZyB0aGUgUEVzIGFuZCBDRXMgIHdpdGggMSBh bmQgMiwgbmFtZSB0aGVtIHdpdGggQSBhbmQgQg0KPnRvIG1hdGNoIHRoZSBJU1AgdGhleSBhcmUg aW50byAoUEUtQSxDRS1BLFBFLUIsQ0UtQiBpbnN0ZWFkIG9mDQo+UEUtMixDRS0yLFBFLTEsQ0Ut MSkNCj4qIG1vZGlmeSBmaWd1cmVzIDEgYW5kIDIgdG8gbWFrZSBQRS1BLENFLUEsUEUtQixDRS1C IGFwcGVhciBvbiB0aGUgZmlndXJlcw0KDQpXR10gSSBkb24ndCB0aGluayB0aGF0IHRoaXMgd291 bGQgYmUgaGVscGZ1bCBzaW5jZSB5b3UncmUgbm90IGNvbnNpc3RlbnRseQ0KZGVhbGluZyB3aXRo IElTUCBBIG9yIEIgZHVyaW5nIHRoZSBtaWdyYXRpb24sIGJ1dCByYXRoZXIgQScsIHdoaWNoIGlz IGFuDQphbWFsZ2FtIG9mIGFsbCBvZiBJU1AgQSBhbmQgdGhlIHBhcnQgb2YgSVNQIEIgdGhhdCBo YXMgYmVlbiBzdWJzdW1lZCBieQ0KSVNQIEEuIEkgdGhpbmsgdXNpbmcgQSBvciBCIHdvdWxkIGNv bmZ1c2UgdGhpbmdzLCBzaW5jZSBpbiBwb3N0LW1pZ3JhdGlvbg0Kd2hhdCB5b3UgZW5kIHVwIHdp dGggaXMgMiBQRXMgaW4gdGhlIHNhbWUgSVNQLg0KDQoNCj4qIHByZWZlcnJpbmcgIklTUCBBIFBF IHJvdXRlcnMiIHRvICAiSVNQIEEncyBQRSByb3V0ZXJzIiB0byBpbmNyZWFzZQ0KPnJlYWRhYmls aXR5LCBvciBqdXN0ICJQRS1BIiBvciAiUEUtQiIgIHdoaWNoIGlzIGV2ZW4gc2hvcnRlciBhbmQg bGVzcw0KPmNvbmZ1c2luZyAgKGFzIGFuIGlsbHVzdHJhdGlvbiBzZWN0aW9uIDMuMiBzYXlzICJT cGVjaWZpY2FsbHksIHdpdGgNCj4nTG9jYWwgQVMgTm8gUHJlcGVuZCcgZW5hYmxlZCBvbiBJU1Ag QSdzIFBFLTEsIGl0IGF1dG9tYXRpY2FsbHkNCj5jYXVzZXMuLi4iICwgYnV0IGRvZXMgaXQgbWVh biAiSVNQIEEgUEUtMSIgb3IgIklTUCBBJyBQRS0xIi4uLj8gZ2l2ZW4NCj50aGF0IFBFLTEgaXMg YWN0dWFsbHkgaW4gSVNQIEIgKD09SVNQIEEnKSwgdGhpcyBpcyBwcm9iYWJseSB0aGUgc2Vjb25k DQo+d2hpY2ggaXMgdHJ1ZSwgYnV0IGhlcmUgaW5jb3JyZWN0bHkgd3JpdHRlbiBhcyAiSVNQIEEn cyBQRS0xIi4uLikNCldHXSBnb29kIHBvaW50LiBJJ2xsIG1ha2UgYSBwYXNzIHRocm91Z2ggdG8g ZWxpbWluYXRlIHRoZSB1c2Ugb2YNCnBvc3Nlc3NpdmUgKEEncykgd2hlbiBJJ20gYWxzbyB0YWxr aW5nIGFib3V0IElTUCBBIHByaW1lIChBJykgdG8gcmVkdWNlDQp0aGUgY29uZnVzaW9uLg0KDQo+ KiBzZWN0aW9uIDMuMSBtZW50aW9ucyBJU1AgQicgKCJ3aXRoaW4gTG9jLVJJQiBvbiBJU1AgQicg dGhlIEFTX1BBVEgNCj50b3dhcmQuLi4iKSAsIGJ1dCB3aGF0IElTUCBCJyBjYW4gb25seSBiZSBn dWVzc2VkLCB5b3UgbWF5IHdhbnQgdG8NCj5kZWZpbmUgaXQgaW4gc2VjdGlvbiAyKHRoZSBzZXQg b2Ygcm91dGVycyBpbiBJU1AgQiBhZnRlciB0aGUgQVMgbWlncmF0aW9uKQ0KDQpXR10gdGhhdCdz IGFuIGVkaXRpbmcgZXJyb3IsIG9yaWdpbmFsbHkgdGhlIHNlbnRlbmNlIHdhcyAiSVNQIEIncy4u LiINCihwb3NzZXNzaXZlKSBhbmQgdGhlIGFwb3N0cm9waGUgYXBwZWFycyB0byBoYXZlIGJlZW4g bGVmdCBiZWhpbmQgd2hlbiB0aGUNCnNlbnRlbmNlIHdhcyByZXdvcmRlZCB0byBlbGltaW5hdGUg dGhlIHBvc3Nlc3NpdmUuDQoNCj4NCj5IKSBzZWN0aW9uIDMuMiBzYXlzICJJbnN0ZWFkLCBvbmx5 IHRoZSBoaXN0b3JpY2FsIChvciBsZWdhY3kpIEFTIHdpbGwgYmUNCj5wcmVwZW5kZWQgaW4gdGhl IG91dGJvdW5kIEJHUCBVUERBVEUgdG93YXJkIGN1c3RvbWVyJ3MgbmV0d29yaywNCj5yZXN0b3Jp bmcgdGhlIEFTX1BBVEggbGVuZ3RoIHRvIHdoYXQgaXQgd2hhdCB3YXMgYmVmb3JlIEFTIE1pZ3Jh dGlvbg0KPm9jY3VycmVkLiIgOyBJIHdvdWxkIHN1Z2dlc3QgYWRkaW5nICIsIGFzIGNvbmZpZ3Vy ZWQgd2l0aCB0aGUgJ0xvY2FsIEFTJw0KPmZlYXR1cmUgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4x LCIgICBiZWZvcmUgIndpbGwgYmUgcHJlcGVuZGVkIg0KV0ddIGFjaw0KPg0KPkkpIEkga25vdyB0 aGUgJ1BFJy8nQ0UnIHRlcm1pbm9sb2d5IHRvIGJlIHdpZGVseSB1c2VkIGluIHRoZSBjb250ZXh0 IG9mDQo+QlBHLWJhc2VkIFZQTnMsIGJ1dCwgdW5sZXNzIGl0IGlzIGFsc28gd2lkZWx5IHVzZWQg Zm9yIG5vbi1WUE4gdXNlDQo+Y2FzZXMsIEkgd291bGQgdGhpbmsgdGhhdCBkZWZpbmluZyB0aGVz ZSB0ZXJtcyB3b3VsZCBtYWtlIHNlbnNlIChJIGRvbid0DQo+a25vdyB0aGVzZSB0ZXJtcyB0byBi ZSB3aWRlbHkgdXNlZCBvdXRzaWRlIFZQTiB1c2UgY2FzZXMsIGJ1dCB3ZWxsLCB0aGV5DQo+bWln aHQgYmUgaW4gd2hpY2ggY2FzZSBub3RoaW5nIGlzIG5lZWRlZCkNCldHXSBJIGNhbiBjZXJ0YWlu bHkgZXhwbG9kZSB0aGUgYWNyb255bSBvbiBmaXJzdCB1c2UgKGluIHNlY3Rpb24gMikgYnV0DQp0 aGUgdXNlIG9mIHRob3NlIHRlcm1zIGlzbid0IGludGVuZGVkIHRvIGludm9rZSBhbnkgc3BlY2lh bCBWUE4gZnVuY3Rpb25zLA0KbWVyZWx5IHRvIHJlcHJlc2VudCB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIHRoZSBwcm92aWRlcidzIHJvdXRlciAoUHJvdmlkZXINCkVkZ2UpIGFuZCB0aGUgY3VzdG9t ZXIncyAoQ3VzdG9tZXIgRWRnZSkuIElzIHRoZXJlIGFuIGFsdGVybmF0ZSBzZXQgb2YNCnRlcm1z IHRoYXQgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZT8NCg0KPg0KPkopIHRoZSBsYXN0IMKnIG9m IHNlY3Rpb24gMy4xIGxvb2tzIHRvIG1lIGFzIHZlcnkgbXVjaCByZWR1bmRhbnQgdG8gd2hhdA0K PmlzIHNhaWQgaW4gdGhlIHJlc3Qgb2YgdGhlIHNlY3Rpb24NCldHXSBJIGNvbnNpZGVyIHRoaXMg KCJBcyBhIHJlc3VsdC4uLiIpIHBhcnQgb2YgdGhlIGV4YW1wbGUgYW5kIHRleHQNCnN1cHBvcnRp bmcgdGhlIGZpZ3VyZSwgc28gSSB0aGluayBpdCBzaG91bGQgcHJvYmFibHkgc3RheSB0aGVyZS4g SSBkbyBzZWUNCnRoZSByZXBldGl0aW9uIHdpdGggdGhlIGVhcmxpZXIgcGFyYWdyYXBoIChiZWdp bm5pbmcgd2l0aCAiQXMgc3RhdGVkDQpwcmV2aW91c2x5Li4uIikgc28gSSB0aGluayBhY3R1YWxs eSBJIHNob3VsZCBwdWxsIHRoZSAiQXMgc3RhdGVkDQpwcmV2aW91c2x5IiBwYXJhZ3JhcGggaW5z dGVhZC4gSSBnb3Qgc29tZSBvZmZsaW5lIGZlZWRiYWNrIHRoYXQgdGhpcyBkcmFmdA0KaXMgd29y ZHksIHNvIEkgd2lsbCB0cnkgdG8gbWFrZSBhbiBlZGl0aW5nIHBhc3Mgd2l0aCB0aGlzIGluIG1p bmQgb25jZQ0KSSd2ZSBpbmNvcnBvcmF0ZWQgdGhlIG90aGVyIGZlZWRiYWNrLg0KDQo+DQo+Sykg c2VjdGlvbiA0LjEgICJOQjogQ2lzY28gZG9lc24ndCBoYXZlIGFuIGV4YWN0IGVxdWl2YWxlbnQg dG8gIkludGVybmFsDQo+QkdQIEFsaWFzIiwgYnV0IHRoZSBjb21iaW5hdGlvbiBvZiB0aGUgQ2lz Y28gZmVhdHVyZXMgaUJHUCBsb2NhbC1BUyBhbmQNCj5kdWFsLWFzIHByb3ZpZGVzIHNpbWlsYXIg ZnVuY3Rpb25hbGl0eS4iICAtLSBUaGlzIHNlbnRlbmNlIHdvdWxkIGJlDQo+YmV0dGVyLXBsYWNl ZCBpbiBzZWN0aW9uIDEwLCBJTU8uDQpXR10gdGhpcyBpcyBjYWxsZWQgb3V0IGhlcmUgZm9yIGNs YXJpZmljYXRpb24gYmVjYXVzZSBpbiBtYW55IG9mIHRoZQ0KZXhhbXBsZXMsIGNpc2NvIHRlcm1p bm9sb2d5IGFuZCBDTEkgYXJlIHVzZWQsIGJ1dCBjb3VsZCBub3QgYmUgdXNlZCBoZXJlLg0KDQo+ DQo+TCkgc2VjdGlvbiA0LjEsIGl0ZW1pemVkIGxpc3QsIGl0ZW0gNDogYSByZWZlcmVuY2UgdG8g c2VjdGlvbiAzIHdvdWxkIGJlDQo+bmljZQ0KV0ddIGFjaw0KPg0KPk0pIHNlY3Rpb24gMTA6IGl0 IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGluZGljYXRlLCBmb3IgZWFjaCB2ZW5kb3IsDQo+d2hh dCBhcmUgdGhlIGZlYXR1cmUgbmFtZXMgY29ycmVzcG9uZGluZyB0byB3aGF0IGlzIGRlc2NyaWJl ZCBpbg0KPnNlY3Rpb25zIDMuMSwgMy4yIGFuZCA0DQpXR10gaW50ZXJlc3RpbmcgcGVyaGFwcywg YnV0IHVubGVzcyB0aGUgV0cgcmVhbGx5IGJlbGlldmVzIGl0J3MgbmVjZXNzYXJ5LA0KSSBkb24n dCB0aGluayB0aGF0J3Mgc29tZXRoaW5nIEkgd2FudCB0byB1bmRlcnRha2UgaGVyZSwgc2luY2Ug SU1PIGl0IGFkZHMNCmxpdHRsZSB0byB0aGUgb2JqZWN0aXZlIG9mIHRoZSBkcmFmdCAoZG9jdW1l bnRpbmcgdGhlIGZlYXR1cmUgc28gdGhhdCBpdA0KY291bGQgYmUgaW1wbGVtZW50ZWQgYnkgc29t ZW9uZSB0aGF0IGRvZXNuJ3QgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbg0KYWxyZWFkeSwgYW5kIGZv cm1hbGl6aW5nIGl0IGFzIGEgcGFydCBvZiBCR1Agc28gdGhlIGZlYXR1cmUgZG9lc24ndCBnZXQN CmJyb2tlbiBieSBmdXR1cmUgY2hhbmdlcyB0byBCR1ApLiBUaGUgdmVuZG9ycyBhcmUgb2YgY291 cnNlIGZyZWUgdG8gZWl0aGVyDQp3cml0ZSB0aGVpciBvd24gZG9jdW1lbnRhdGlvbiBtYXBwaW5n IHRoaW5ncyB0byB0aGlzIGRvY3VtZW50LCBvciB0bw0KcHJvdmlkZSB0ZXh0IGZvciBtZSB0byBh ZGQgaGVyZSA7LSkNCg0KPg0KPipOaXRzOioNCj4NCj4tIEluIHRoZSBhYnN0cmFjdDogcy9mZWF1 cmVzL2ZlYXR1cmVzLw0KPi0gSW4gdGhlIGFic3RyYWN0OiB0aGUgdGl0bGUgd291bGQgYmUgbW9y ZSByZWFkYWJsZSB3aXRob3V0ICIoQVMpIjsNCj5pbnRyb2R1Y2luZyB0aGlzIGFjcm9ueW0sIGFs b25nIHdpdGggIkFTTiIgY2FuIGJlIGRvbmUgZm9yIGluc3RhbmNlIGluDQo+dGhlIGludHJvZHVj dGlvbg0KPi0gaW4gMy4xOiAgIklTUCBCIG5lZWRzIHRvIGRvIHRoaXMgd2l0aG91dCBjb29yZGlu YXRpbmcgdGhlIGNoYW5nZSBvZg0KPml0cyBBU04gd2l0aCBhbGwgb2YgaXRzIGVCR1AgcGVlcnMs IHNpbXVsdGFuZW91c2x5LiIgIGlzIG5vdCB2ZXJ5IGVhc3kNCj50byByZWFkIChtYXliZSAiSVNQ IEIgbmVlZHMgdG8gYmUgYWJsZSB0byBkbyB0aGlzIHdpdGhvdXQgY29vcmRpbmF0aW5nIGENCj5z aW11bHRhbmVvdXMgY2hhbmdlLi4uIHBlZXJzIiB3b3VsZCBiZSBiZXR0ZXI/KQ0KPi0gaW4gMy4x OiAiV2l0aGluIHRoZSBjb250ZXh0IG9mIElTUCBCJ3MgUEUgcm91dGVyLCBUaGUgc2Vjb25kIGVm ZmVjdA0KPi4uLiIgIC0+IHMvVGhlL3RoZS8NCldHXSBhY2sNCg0KDQoNClRoYW5rcywNCg0KV2Vz IEdlb3JnZQ0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkg Y29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0t LS0tLS0tLS0NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUg Y29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Tue Sep 16 02:13:27 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CE91A048D; Tue, 16 Sep 2014 02:13:22 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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 q8ZDhw966ugM; Tue, 16 Sep 2014 02:13:20 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3801A0484; Tue, 16 Sep 2014 02:12:54 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id x13so5086583wgg.11 for ; Tue, 16 Sep 2014 02:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=drOcZLKsdZGztCTXrYagsSJLu8uFB8S4vk3/8vwwnqY=; b=lceTGj74a5413GKoc44jXUclKY1K6ir28TE6jDttUKDEfMv8z21LcN0Flzhc/w1RQb szhY9zikPyc8gxoKhPRA80iSCooYHn4+9EbZP6T4RG0/DdHtdDH4ki9aD6vkCYmqrxrH dJyPcM/TJ/wqXn6DNzBxPII0FbTnhwUGfV6DTmQ9D9Qf902EdQA9Y/qrPK3E3gA676Qx PbJY4jv9YVcb6D5XwCUOAc3zaglJehuq74hNABEDxPEbxE9rDn6w2MEPT7PmAbAcj2Gl /3HCGglM/YlT9UHXFgTxPTWfs9KUS7/PZpHwpcKZ1QR8Nm65g3p0krRj3C5Aim90zuc9 f0wg== X-Received: by 10.194.122.6 with SMTP id lo6mr40893419wjb.17.1410858771832; Tue, 16 Sep 2014 02:12:51 -0700 (PDT) Received: from [127.0.0.1] (ARennes-652-1-59-226.w2-11.abo.wanadoo.fr. [2.11.58.226]) by mx.google.com with ESMTPSA id lq8sm17628480wjb.49.2014.09.16.02.12.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Sep 2014 02:12:51 -0700 (PDT) Sender: Thomas Morin Message-ID: <5417FF0F.9040506@orange.com> Date: Tue, 16 Sep 2014 11:12:47 +0200 From: Thomas Morin Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "George, Wes" , "idr@ietf.org" , "rtg-ads@tools.ietf.org" References: <5412BF1F.7030206@orange.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/6Wn3qG9u7uO-pRszs_ScQdWbRK0 Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-as-migration.all@tools.ietf.org" Subject: Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 09:13:22 -0000 Hi George, 2014-09-15, George, Wes: > Thanks for the thorough review. My responses below inline. Comments below. (skipping stuff that is ok already) > On 9/12/14, 5:38 AM, "Thomas Morin" wrote: >> A) The introduction says: >> >> In particular >> the ISP would have to encourage those customers to change their CE >> router configs to use the new ASN in a very short period of time, >> when the customer has no business incentive to do so. Thus, it >> becomes critical to allow the ISP to make this process a bit more >> asymmetric, so that it could seamlessly migrate the ASN within its >> network(s), but not disturb existing customers, and allow the >> customers to gradually migrate to the ISP's new ASN at their leisure. >> >> However, I did not understand which part of the specs would allow the >> customer to change its CE >> configuration without coordinating a maintenance window with the ISP. > > WG] well, that is not exactly what the above says. The idea was to make a > distinction between a globally coordinated window between all customers on > the router (symmetric change) vs being able to coordinate individually > (asymmetric). I do see your point though, and I can make it more explicit. > >> Procedures in section 3, as described, won't let the customer CE >> connect to the router with the new ASN. See, in particular in the second >> § of section 3.3: "The speaker MUST NOT use the ASN configured globally >> within the BGP process as the value sent in MY ASN in the OPEN message. >> ". It seems that the goal specified in the intro will thus not be met >> fully. >> >> Two things would be possible: fixing the intro to state a slightly >> different goal, or change the procedures to let a router establish a >> session with the globally assigned new AS, even when 'local-as old-AS" >> is configured. I'm not expert enough to know if the latter would work. > > WG] I'd refer you to section 4.2, which allows a more flexible > configuration that can establish a session using either old or new ASN. > While it's discussed in the iBGP section, the text does note that this > could be done whether in iBGP or eBGP. Well, referring me, in this email, to section 4.2 won't improve the document itself. :) This question of avoiding any coordinated maintenance window between two eBGP peers is I think important enough to deserve being explicitly addressed as a target in the intro, and with a solution mentioned in section 3 (which could say, at the right place: "At this step, to let CEs still configured with the legacy ASN establish sessions, the PE can be configured to enable the 'Internal BGP Alias' function described in section 4.2"). >> D) in section 3: " Thus, within Loc-RIB on ISP B' the AS_PATH toward >> customer C would appear as: 64510". I would have thought that the >> AS_PATH of routes learned by PE routers of ISP B in this situation (if >> local-as no-prepend is not used), would be "64496" or "64510 64496" >> rather than "64510" alone... but I could just be wrong. > > WG] This is describing the AS_PATH pre-migration, and then showing what > happens during migration. I think I can clarify. (Note that given the position in the text, the context of this quoted does *not* seem to be pre-migration, but rather during migration.) >> G) the naming given to ASs and routers along the document**could I think >> be largely improved to make the document easier to read. I would suggest >> the following: >> * In the figures 3 and 4 of section 3.1 and 3.2: invert the figure >> left-right to have AS64499 on the left like in figures 1 and 2 > > WG] I understand the parallelism/symmetry that you're suggesting, but > flipping the ASNs would require rewriting a substantial amount of the > example. I think you're suggesting mirror image, which would leave the > example text unchanged, but assumes that everyone is ok with the arrows > pointing right to left in fig 3, and then left to right in fig 4, as well > as PE2/CE2 showing on the left, PE1/CE1 on the right in both, which is > sort of backward from western convention and confusing for a different > reason. I think I'm going to offend a different set of aesthetics with > either one, and I'm not sure it makes a great deal of difference in the > readability of the figures. Open for further discussion. If I may insist: having left and right inverted between fig 1/2 and fig 3/4 is (a) really confusing at first, (b) independent of any left-to-right convention, and (c) bogus for every reasonable sense of aesthetics. Inverting left-to-right in fig.1 and fig.2 would just consist in changing 8 chars total, and would fix that. (changing the direction of arrows in 3.1 and 3.2 would be IMHO an acceptable alternative: I don't think there's anything backward wrt. to any western convention in that) >> * In the figures 3 and 4 of section 3.1 and 3.2, and associated text: >> instead of naming the PEs and CEs with 1 and 2, name them with A and B >> to match the ISP they are into (PE-A,CE-A,PE-B,CE-B instead of >> PE-2,CE-2,PE-1,CE-1) >> * modify figures 1 and 2 to make PE-A,CE-A,PE-B,CE-B appear on the figures > > WG] I don't think that this would be helpful since you're not consistently > dealing with ISP A or B during the migration, but rather A', which is an > amalgam of all of ISP A and the part of ISP B that has been subsumed by > ISP A. I think using A or B would confuse things, since in post-migration > what you end up with is 2 PEs in the same ISP. Having to refer to the figure, while reading the text, to find out which of PE1/PE2 was in ISP B/ISP A was a significant overhead for me. If it is written clearly that PE-A/PE-B are respectively PEs that were before migration in ISP A/ISP-B, I think the confusion with respect to the ISP A' notation will go away. >> * preferring "ISP A PE routers" to "ISP A's PE routers" to increase >> readability, or just "PE-A" or "PE-B" which is even shorter and less >> confusing (as an illustration section 3.2 says "Specifically, with >> 'Local AS No Prepend' enabled on ISP A's PE-1, it automatically >> causes..." , but does it mean "ISP A PE-1" or "ISP A' PE-1"...? given >> that PE-1 is actually in ISP B (==ISP A'), this is probably the second >> which is true, but here incorrectly written as "ISP A's PE-1"...) > > WG] good point. I'll make a pass through to eliminate the use of > possessive (A's) when I'm also talking about ISP A prime (A') to reduce > the confusion. I think you should remove the possessive "'s" in all occurrences . >> I) I know the 'PE'/'CE' terminology to be widely used in the context of >> BPG-based VPNs, but, unless it is also widely used for non-VPN use >> cases, I would think that defining these terms would make sense (I don't >> know these terms to be widely used outside VPN use cases, but well, they >> might be in which case nothing is needed) > > WG] I can certainly explode the acronym on first use (in section 2) but > the use of those terms isn't intended to invoke any special VPN functions, > merely to represent the difference between the provider's router (Provider > Edge) and the customer's (Customer Edge). Is there an alternate set of > terms that would be more appropriate? I guess the right term would be ASBR, but that is symmetric, and not a helpful terminology for your examples. Expanding on first use, and explaining that you re-use terminology from RFC4364 by convenience would I think be good enough. >> J) the last § of section 3.1 looks to me as very much redundant to what >> is said in the rest of the section > > WG] I consider this ("As a result...") part of the example and text > supporting the figure, so I think it should probably stay there. I do see > the repetition with the earlier paragraph (beginning with "As stated > previously...") so I think actually I should pull the "As stated > previously" paragraph instead. I got some offline feedback that this draft > is wordy, so I will try to make an editing pass with this in mind once > I've incorporated the other feedback. Yes, these sections are very wordy; the document will be better if you can avoid repeats. >> K) section 4.1 "NB: Cisco doesn't have an exact equivalent to "Internal >> BGP Alias", but the combination of the Cisco features iBGP local-AS and >> dual-as provides similar functionality." -- This sentence would be >> better-placed in section 10, IMO. > > WG] this is called out here for clarification because in many of the > examples, cisco terminology and CLI are used, but could not be used here. If I read correctly, section 3 uses a Cisco feature name "local-as" and section 4 a Juniper feature name. However, Section 2 says "The examples cited below use Cisco IOS CLI for ease of illustration purposes only.". You could sort this out by saying, section 2 "The examples cited below use specfic vendors CLI feature names for ease of illustration purposes only (Cisco IOS in Section 3, Juniper JunOS in Section 4)". And then move the "NB" note in section 10... ? >> M) section 10: it would be interesting to indicate, for each vendor, >> what are the feature names corresponding to what is described in >> sections 3.1, 3.2 and 4 > WG] interesting perhaps, but unless the WG really believes it's necessary, > I don't think that's something I want to undertake here, since IMO it adds > little to the objective of the draft (documenting the feature so that it > could be implemented by someone that doesn't have an implementation > already, and formalizing it as a part of BGP so the feature doesn't get > broken by future changes to BGP). The vendors are of course free to either > write their own documentation mapping things to this document, or to > provide text for me to add here ;-) Ok, fair enough. -Thomas From nobody Thu Sep 18 13:50:37 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFF41A8924; Thu, 18 Sep 2014 13:50:26 -0700 (PDT) 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 R04uCctlwSia; Thu, 18 Sep 2014 13:50:22 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1801A8930; Thu, 18 Sep 2014 13:50:22 -0700 (PDT) Received: from djustice-sslvpn-nc.jnpr.net (66.129.241.10) by BLUPR05MB723.namprd05.prod.outlook.com (10.141.207.153) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Thu, 18 Sep 2014 20:50:17 +0000 From: John G.Scudder Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Sep 2014 16:50:30 -0400 Message-ID: To: MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BY1PR0201CA0011.namprd02.prod.outlook.com (25.160.191.149) To BLUPR05MB723.namprd05.prod.outlook.com (10.141.207.153) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB723; X-Forefront-PRVS: 033857D0BD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(189002)(164054003)(43544003)(199003)(64706001)(77156001)(21056001)(77096002)(20776003)(50466002)(53416004)(42186005)(62966002)(36756003)(95666004)(47776003)(66066001)(97736003)(110136001)(19580395003)(83322001)(101416001)(81156004)(106356001)(82746002)(69596002)(105586002)(15975445006)(76482002)(50226001)(4396001)(15202345003)(92566001)(230783001)(92726001)(229853001)(104166001)(85852003)(89996001)(80022003)(79102003)(88136002)(57306001)(2351001)(107046002)(83072002)(83716003)(77982003)(87976001)(74662003)(81342003)(74502003)(81542003)(46102003)(87286001)(93916002)(31966008)(90102001)(85306004)(99396002)(86362001)(561924002)(23676002)(50986999)(33656002)(104396001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB723; H:djustice-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/5BC8dvulx_rjlBBcuXQqTjzQXAg Cc: rtg-dir@ietf.org, grow@ietf.org, draft-ietf-grow-ix-bgp-route-server-operations@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-grow-ix-bgp-route-server-operations-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 20:50:26 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Thanks, --John Document: draft-ietf-grow-ix-bgp-route-server-operations-03.txt Reviewer: John Scudder Review Date: 2014-09-18 IETF LC End Date: 2014-09-22=20 Intended Status: Informational Summary:=20 =E2=80=A2 I have some minor concerns about this document that I = think should be resolved before publication. Comments: This is overall a good document and worth publishing, although I have = found a number of minor issues I would like the authors to address = before the document progresses. I initially flagged the first two issues = as "major" but on consideration I've moved them to the "minor" list. = With the noted exceptions, I think the document is very good in terms of = its readability and fitness for publication without major editing. Major Issues: - None identified. Minor Issues: - Throughout the document, various terms are used to describe what RFC = 4271 calls a "route". The definition given in RFC 4271 is: Route A unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destinations are systems whose IP addresses are contained in one IP address prefix carried in the Network Layer Reachability Information (NLRI) field of an UPDATE message. The path is the information reported in the path attributes field of the same UPDATE message. That is, one NLRI plus its path attributes, as carried in an UPDATE, is = a "route". I would suggest adopting this term, or "BGP route" if you = prefer, instead of terms such as "NLRI UPDATE message", "NLRI message", = "prefix UPDATE message", and even just plain "NLRI" and "message". Also = some, but not all, of the uses of "prefix". I think doing so will make = the document clearer, more readable, and more technically accurate. A = simple search for the terms I've called out should show most of them so = I won't enumerate them here unless you ask me to (feel free, if you = want).=20 - Reference [RS-ARCH] is a dead link. I found a live copy at = http://www.cs.usc.edu/assets/003/83191.pdf. It might be worth checking = with the authors of RS-ARCH to ask what a good archival reference is. - S. 4.2 talks about scaling. I'm trying to make sense of the analysis: Regardless of any Loc-RIB optimization technique is implemented, the route server's control plane bandwidth requirements will scale according to O(P * N), where P is the total number of unique paths received by the route server and N is the total number of route server clients. =20 So far so good. (Except nit: there seems to be a word missing, such as = "whether" as in "Regardless of whether any Loc-RIB...") In the case where P_avg (the arithmetic mean number of unique paths received per route server client) remains roughly constant even as the number of connected clients increases, this relationship can be rewritten as O((P_avg * N) * N) or O(N^2). =20 I don't see where the second factor of N comes from. You're basically = expanding the P in the first expression as P_avg * N -- but why? I think = this would only apply if add-path all-paths was chosen as the path = hiding mitigation strategy -- but this is not touched on in = route-server-operations, only in ix-bgp-route-server, and besides that = the beginning of the paragraph implies you're analyzing the multiple = Loc-RIB strategy, so I don't guess all-path is what you were thinking = of. If you're not doing all-path, the O(N^2) analysis is wrong AFAICT. = To see this, consider that the inbound routes require O(P_avg * N) which = is just O(N), but the number of routes you're going to advertise is = bounded by the size of the Internet routing table, which is a constant = for purposes of this analysis, so also O(N). In and out are summed, not = multiplied, so the whole thing works out to be O(N), not O(N^2). So I think this needs to either be corrected, or the assumptions need to = be better explained. Moving on: This quadratic upper bound on the network traffic requirements indicates that the route server model will not scale to arbitrarily large sizes. If you continue to think this sentence is warranted, I think it should = be better quantified. Of course nothing can scale to *arbitrarily* large = sizes, but that still leaves a lot to the imagination. I would think it = would be beneficial for an IX operator reading this document to be able = to have some idea of how practical the limitation is. Since the analysis = in question is looking at control traffic bandwidth consumption, it = wouldn't be too onerous to throw some simple assumptions up against it = -- for example, "if we suppose a RS receives on average 100,000 routes = from each client with a rate of change of 10 routes/second, sends on = average 1,000,000 routes to each client with a rate of change of 100 = routes/second, and that each route consumes on average 50 bytes in a BGP = UPDATE message, simple arithmetic shows that a GigE connection to that = RS will be fully saturated by the time the number of clients reaches = 25,000." (Which does not seem like a very practical limitation, the RS = will hit a CPU or memory bottleneck first.) Anyway, maybe you will decide on reconsideration of the big-O analysis = that this bit is not needed at all, which would be OK with me. - S 4.2.2.1,=20 If the route server operator has prior knowledge of interconnection relationships between route server clients, then the operator may configure separate Loc- RIBs only for route server clients with unique outbound routing policies. It wasn't obvious to me what "outbound" applies to -- the client? The = RS? -- and for that matter why an inbound policy (on the RS) might not = apply. Possibly this could be remedied by simply dropping the adjective = "outbound". - S. 4.2.1.2, destination splitting would require significant co-ordination between the route server operator and each route server client It's not clear to me why it would "require significant co-ordination", = depending on what resource you're trying to conserve. Two examples of = how you could avoid coordination while still getting benefit: You could = have clients send all their routes to all the RSes, but have RSes filter = out the prefixes they don't care about. This gives the RS most of the = CPU benefit it would have gotten had the client done the filtering = (prefix filtering is cheap), almost all the memory benefit (the filtered = routes need not be retained in the Adj-RIB-In), and around half the = control traffic bandwidth benefit. The client incurs cost to send = duplicate routes that are going to be discarded by the RS, but the = client is presumably not the bottleneck resource. Or better still, the = RS could use ORF towards the clients to control what routes the clients = will send. - S. 4.6.1, OLD: Prefixes sent to the route server are tagged with specific [RFC1997] or [RFC4360] BGP community attributes I don't think the naked references scan well as adjectives in this = context. I suggest NEW: Prefixes sent to the route server are tagged with specific standard = [RFC1997] or extended [RFC4360] BGP community attributes - Also in S. 4.6.1, OLD: As both standard and extended BGP communities values are restricted to 6 octets Actually standard communities are restricted to less than that. Perhaps = reword as NEW: As both standard and extended BGP communities values are restricted to 6 octets or fewer - Also in S. 4.6.1, route server operator should take care to ensure that the predefined BGP community values mechanism used on their route server is compatible with [RFC4893] 4-octet autonomous system numbers. I suspect an RS operator reading this might be left scratching his or = her head and asking "what does it mean for me to be compatible with = RFC4893 in this context"? It would be kind to offer them some guidance, = since after all this is a guidance document. - S. 4.7: Where you say "non-commutative" I think you mean = "non-transitive". - S. 4.7: Problems of this form can be dealt with using [RFC5881] bidirectional forwarding detection. It's not clear to me how certain non-transitive forwarding failures can = be dealt with using BFD. To take an example, suppose clients A, B and C = peer with RS. The IX fabric has a failure such that A and B can both = reach RS, but not each other. C has connectivity to everyone. Prefix X = is advertised to RS by both B and C. For whatever reason, RS selects X = via B to advertise to A. Even if A runs BFD towards B, at best A can = determine that the route from RS can't be used. A isn't able to fail = over to C's route as it would in the full-mesh case, since it's not = aware of it. Depending on A's other connectivity, this may result in = sub-optimal routing towards X, or complete loss of connectivity to X. It's beyond the scope of the draft to solve this problem, but the text = could be made more accurate. A minimal fix would be Problems of this form can be partially mitigated using [RFC5881] = bidirectional forwarding detection. although you might want to go on a bit longer to explain what problems = can't be mitigated. - S. 4.8: This problem is not specific to route servers and it can also be implemented using bilateral peering sessions. However, the potential damage is amplified by route servers because a single BGP session can be used to affect many networks simultaneously. This is true, but there is a more severe way RSes aggravate the problem: = In a full mesh, a router can (and usually does) directly enforce a "no = third-party next hops" policy against its peers. An RS peer by = definition cannot enforce this policy against the RS, so the RS is the = only place it can be enforced. - S. 4.8: Route server operators SHOULD check that the BGP NEXT_HOP attribute for NLRIs received from a route server client matches the interface address of the client. If the route server receives an NLRI where these addresses are different so far so good (modulo my first comment about the use of "NLRI", of = course), but: and where the announcing route server client is in a different autonomous system to the route server client which uses the next hop address,=20 Is the RS sincerely expected to enforce the above? I suppose it could be = implemented automatically although imperfectly, by noticing that = multiple clients are in the same neighbor AS and noticing when they use = each other as third-party next hops, but AFAIK people generally don't = try to figure this out, they just do what you've said in the preceding = sentence -- make sure the NH matches the interface address. If you = really do propose that the RS should allow third-party next hops but = only from clients in a common AS, I think you should talk about it = specifically and in more detail. If you didn't really mean that, then I = suggest you drop the clause.=20 - S. 5: On route server installations which do not employ path hiding mitigation techniques, the path hiding problem outlined in section Section 4.1 can be used in certain circumstances to proactively block third party prefix announcements from other route server clients. I don't understand what this means. Specifically, I don't know what it = means to "proactively block third party prefix announcements" or for = that matter, even what you mean by "third party prefix announcements" in = this context. (As a term of art, I normally understand "third party = announcement" in a BGP context to mean announcing a third-party next hop = as you discuss in S. 4.8). I also don't know what the "certain = circumstances" are, quite likely these should be given at least a little = color if not entirely spelled out. Also, a nit -- the xref expansion has put "section section" into your = text. - S. 7: BIRD, OpenBGPD and Quagga, whose open source BGP implementations include route server capabilities=20 Great, cool, but: which are compliant with this document. I'm not sure what it actually means to be "compliant" with a document = that "describes operational considerations". Perhaps just drop the = phrase? Nits: - In S. 2,=20 OLD: BGP sessions between each participant router NEW: BGP sessions between each pair of participant routers - In S. 4.2.1.1,=20 OLD: In this situation, the multiple Loc-RIB views required by each client are merged into a single view. As written, this implies that each client requires multiple Loc-RIB = views, which I don't think is what was intended. I suggest: NEW: In this situation, multiple Loc-RIB views are merged into a single view. - I personally am strongly put off by the neologism "granular" to mean = "fine-grained" and suggest the latter instead. I realize it's not an = unusual usage so by all means disregard if you feel strongly about it. - S. 4.6.2: OLD: server operators to implement construct per-client routing policies. NEW: server operators to construct per-client routing policies.= From nobody Mon Sep 22 00:19:53 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840FE1A1A42; Mon, 22 Sep 2014 00:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 DMydZZtYJIqN; Mon, 22 Sep 2014 00:19:47 -0700 (PDT) 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 04C481A1A40; Mon, 22 Sep 2014 00:19:46 -0700 (PDT) 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 BJR91121; Mon, 22 Sep 2014 07:19:45 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 22 Sep 2014 08:19:43 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Mon, 22 Sep 2014 15:19:40 +0800 From: Mach Chen To: "idr@ietf.org" , "draft-ietf-idr-bgp-gr-notification@tools.ietf.org" Thread-Topic: RtgDir QA review on draft-ietf-idr-bgp-gr-notification-03 Thread-Index: Ac/WNY9hijUo731zTvqx4ERfOezi8Q== Date: Mon, 22 Sep 2014 07:19:39 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/E3ngJKUjPZmeAsaXzqCAgBKIMzA Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] RtgDir QA review on draft-ietf-idr-bgp-gr-notification-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 07:19:50 -0000 Hi Authors, I was assigned to do a QA review on draft-ietf-idr-bgp-gr-notification-03. = For more detail what's is RtgDir QA review, please refer to https://trac.to= ols.ietf.org/area/rtg/trac/wiki/RtgDirDocQa=20 Overall, the document is well-written and clear, after review, I have the f= ollowing comments.=20 1. Abstract s/BGP NOTIFICATION Message/ BGP NOTIFICATION message; 2. Section 2: " Flags for Address Family: This field contains bit flags relating to routes that were advertised with the given AFI and SAFI. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|N| Reserved | +-+-+-+-+-+-+-+-+ The usage of second most significant bit "N" is deprecated. This bit MUST be advertised as 0 and MUST be ignored upon receipt. " The "N" bit was firstly introduced in a previous version of this document, = but deprecated in later version. I don't understand why a document need dep= recate a functionality introduced by itself, why not just remove it? In addition, since there is no changes to the AF related flags, the last se= ntence of the first paragraph of section 2 should be changed as bellow: OLD: "the Restart flags field and the Flags field for Address Family are augment= ed as follows:" New: "the Restart flags field are augmented as follows:" 3. Section 3.1 "Subcode is a BGP Error Subcode (as documented in the IANA BGP Error Subcodes registry) as appropriate for the ErrCode. Similarly, Data is as appropriate for the ErrCode and Subcode." This is just an introduction to the Subcode itself, it's better to explicit= ly state that the subcode should be set to the Hard Reset (9). 4. Section 4 "Once the session is re-established, both BGP speakers SHOULD set their "Forwarding State" bit to 1." Here it implies that the speakers are required to set the "Forwarding State= " no matter what the speakers have the ability to preserve the forwarding s= tate. Is it the intention? =20 I guess it's not, if so, some text may needed to clarify this. 5. I run idnits tool and found the following nits: =3D=3D Unused Reference: 'RFC3392' is defined on line 269, but no explicit = reference was found in the text. Best regards, Mach From nobody Tue Sep 23 13:52:53 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7171A88E0 for ; Tue, 23 Sep 2014 13:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 YSLAlUVVbSns for ; Tue, 23 Sep 2014 13:52:47 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 49F881A88F4 for ; Tue, 23 Sep 2014 13:52:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Jeff Haas'" , "'Bitar, Nabil N'" References: <5FA68A99-8400-4279-9491-139DC014C6FD@juniper.net> In-Reply-To: <5FA68A99-8400-4279-9491-139DC014C6FD@juniper.net> Date: Tue, 23 Sep 2014 16:52:42 -0400 Message-ID: <014201cfd770$52458330$f6d08990$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0143_01CFD74E.CB396170" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCvaouNGjF8Jm93JLb1wbdX+93KGAGFLHTunkPhmWA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/nIXH2UP3W8TF2sVorD8zPRPjgb4 Cc: rtg-dir@ietf.org, 'Mach Chen' , db3546@att.com, rtg-ads@tools.ietf.org, 'Jonathan Hardwick' , jgs@juniper.net Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 20:52:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0143_01CFD74E.CB396170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jeff and Nabil: =20 I=92ve not seen any further conversation on this topic? Is the = resolution pending offline? Or can we complete this topic? I would like to push = this draft through the process.=20 =20 Please note Mach Chen has agreed to be the shepherd on this draft, but = it=92s his first IDR shepherding so you WG co-chair is helping keep the ball rolling. =20 =20 Sue=20 =20 From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Jeff Haas Sent: Friday, September 12, 2014 2:09 PM To: Bitar, Nabil N Cc: rtg-dir@ietf.org; db3546@att.com; rtg-ads@tools.ietf.org; Jonathan Hardwick; jgs@juniper.net; Susan Hares Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00 =20 Nabil, =20 Thanks for your review! =20 As seen below, I have accepted the majority of your changes but have yet = to issue an updated draft. There is one topic requiring some further discussion. Once we've resolved that, I'll issue an updated I-D. =20 -- Jeff =20 On Sep 8, 2014, at 10:22 AM, Bitar, Nabil N wrote: Minor Issues: Following are suggested edits. =20 Abstract: Change: originally documented in RFC 5575 =E0 originally documented in = RFC 5575 (Dissemination of Flow Specification Rules) =20 Done. =20 - Page 3, last sentence a common interpretation of the Redirect Extended Community=92s "6-byte = Route Target" has been to look for any matching Route Target sharing the same Value portion of its Extended Community. Thus, multiple Route Targets provisioned in a router=92s VRFs might match even though the format was different. =20 Suggested new text: a common interpretation of the redirect extended community=92s "6-byte = route target" has been to look, at a receiving router, for a route target = value that matches the route target value in the received redirect extended community, and import the advertised route to the corresponding VRF = instance subject to the rules defined in RFC 5575 [RFC 5575]. However, because = the route target format in the redirect extended community is not clearly defined, the wrong match may occur. =20 Accepted. =20 - Page 4, second paragraph: =20 This "Value wildcard" behavior does not matched deployed implementations = of BGP Flowspec. =20 Suggested new text: This "value wildcard" matching behavior, that does not take into account = the format of the route target defined for a local VRF and may result in the wrong matching decision, does not match deployed implementations of BGP flowspec. Deployed implementations of BGP flowspec solves this problem = by defining different redirect extended communities that are specific to = the format of the route target value. This document defines the following redirect extended communities: =20 Accepted. =20 =20 - Page 4, first sentence under table: =20 It should be noted that the low-order nybble of the Redirect=92s type field corresponds to the Route Target Extended = Community format field (Type). (See [RFC4360], Secs. 3.1, 3.2 and [RFC5668], Sec. = 2.) The low order octet (Sub-Type) of the Redirect Extended Community = remains 0x08, contrasted to 0x02 for Route Targets. =20 Question: Why is the reference to RFC 4360 section 3.1 and 3.2, and RFC 5668 section 2? See to be the wrong references. Did you mean to refer to = RFC 4360 section 4? =20 The reference is basically to draw attention to the structural history = for why this was coded the way it was. The above references demonstrate = where that structure is defined. =20 Suggested new text: It should be noted that the low-order nybble of the High-order octet of the redirect extended community yype field in Table = 1 corresponds to that in the high-order octet of the route target extended community type field. The low order octet (sub-type) of the redirect extended Community remains 0x08, contrasted to 0x02 for route targets = (see [RFC4360] section 4). =20 See above. If you'd like to further clarify, let's talk about it in the above context. =20 - Note: I suggest that you add text on matching the newly defined = redirect extended communities to route targets defined for VRF=92s to update what = is in RFC 5575. =20 I am unclear what you're asking here. If the idea is that there should = be text in this draft saying "route-targets exist and if they match this RT = in the flowspec redirect, install it in the relevant VRF", I'd rather defer = to the underlying base behavior in 5575. =20 =20 Section 2 IANA Considerations (minor comments): =20 - 0x81 "Generic Transitive Experimental Extended Community Part 2 Sub-Types" Registry ------------------- =20 Change: Experimental =E0 Experimental Use =20 - 0x82 "Generic Transitive Experimental Extended Community Part 3 Sub-Types" ------------------- =20 Change: Experimental =E0 Experimental Use =20 - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL = EXTENDED COMMUNITY PART 2 SUB-TYPES registry. It should be seeded with the = following Sub-Type =20 Change: Experimental =E0 Experimental Use =20 =20 - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL = EXTENDED COMMUNITY PART 3 SUB-TYPES registry. It should be seeded with the = following Sub-Type =20 =20 Change: Experimental =E0 Experimental Use =20 All accepted. =20 =20 Nits:=20 None noticed. =20 =20 Thanks, Nabil =20 =20 ------=_NextPart_000_0143_01CFD74E.CB396170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jeff and Nabil:

 

I’ve not seen any further conversation on this topic?=A0 Is the = resolution pending offline? Or can we complete this topic?=A0 I would = like to push this draft through the process.

 

Please note Mach Chen has agreed to be the shepherd on this draft, = but it’s his first IDR shepherding so you WG co-chair is helping = keep the ball rolling.=A0

 

Sue

 

From:= = rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Jeff = Haas
Sent: Friday, September 12, 2014 2:09 PM
To: = Bitar, Nabil N
Cc: rtg-dir@ietf.org; db3546@att.com; = rtg-ads@tools.ietf.org; Jonathan Hardwick; jgs@juniper.net; Susan = Hares
Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review: = draft-ietf-idr-flowspec-redirect-rt-bis-00

 

Nabil,

 

Thanks for your review!

 

As seen below, I have accepted the majority of your = changes but have yet to issue an updated draft.  There is one topic = requiring some further discussion.  Once we've resolved that, I'll = issue an updated I-D.

 

-- Jeff

 

On Sep 8, 2014, at 10:22 AM, Bitar, Nabil N <nabil.n.bitar@verizon.com&g= t; wrote:

Minor Issues:

Following are suggested = edits.

 

=

Abstract:<= /p>

Change:  originally = documented in RFC 5575 =E0 originally documented = in RFC 5575 (Dissemination of Flow Specification = Rules)

 

Done.



&nbs= p;

- Page 3, last = sentence

a common interpretation of = the Redirect Extended Community’s "6-byte Route Target" = has been to look for any matching Route Target sharing the same Value = portion of its Extended Community. Thus, multiple Route Targets = provisioned in a router’s VRFs might match even though the format = was different.

 

=

Suggested new = text:

a common interpretation of = the redirect extended community’s "6-byte route target" = has been to look, at a receiving router, for a route target value that = matches the route target value in the received redirect extended = community, and import the advertised route to the corresponding VRF = instance subject to the rules defined in RFC 5575 [RFC 5575]. However, = because the route target format in the redirect extended community is = not clearly defined, the wrong match may = occur.

 

Accepted.



 

=

- Page 4, second = paragraph:

 

=

This "Value = wildcard" behavior does not matched deployed implementations of BGP = Flowspec.

 

<= p class=3DMsoNormal>Suggested new = text:

This "value = wildcard" matching behavior, that does not take into account the = format of the route target defined for a local VRF and may result in the = wrong matching decision, does not match deployed implementations of BGP = flowspec. Deployed implementations of BGP flowspec solves this problem = by defining different redirect extended communities that are specific to = the format of the route target value. This document defines the = following redirect extended = communities:

 

Accepted.



 

=

<Keep table = here>

 

=

- Page 4, first sentence = under table:

 

=

It should be noted that the = low-order nybble of the

Redirect’s type field = corresponds to the Route Target Extended Community format field (Type). = (See [RFC4360], Secs. 3.1, 3.2 and [RFC5668], Sec. 2.) The low order = octet (Sub-Type) of the Redirect Extended Community remains 0x08, = contrasted to 0x02 for Route Targets.

 

=

Question:  Why is the reference to = RFC 4360 section 3.1 and 3.2, and RFC 5668 section 2? See to be the = wrong references. Did you mean to refer to RFC 4360 section = 4?

 

The = reference is basically to draw attention to the structural history for = why this was coded the way it was.  The above references = demonstrate where that structure is defined.



 

=

Suggested new = text:

It should be noted that the = low-order nybble of the

High-order octet of the = redirect extended community yype field in Table 1 corresponds to that in = the high-order octet of the route target extended community type field. = The low order octet (sub-type) of the redirect extended Community = remains 0x08, contrasted to 0x02 for route targets (see [RFC4360] = section 4).

 

See = above.  If you'd like to further clarify, let's talk about it in = the above context.



 

=

- Note:  I suggest that you add = text on matching the newly defined redirect extended communities to = route targets defined for VRF’s to update what is in RFC = 5575.

 

I am = unclear what you're asking here.  If the idea is that there should = be text in this draft saying "route-targets exist and if they match = this RT in the flowspec redirect, install it in the relevant VRF", = I'd rather defer to the underlying base behavior in = 5575.



 

=

 

=

Section 2 IANA = Considerations (minor comments):

 

=

- = 0x81

"Generic Transitive = Experimental Extended Community Part 2 Sub-Types" = Registry

    &nbs= p;            = ;            =         -------------------=

 

=

Change: Experimental =E0 Experimental = Use

 

=

- = 0x82

"Generic Transitive = Experimental Extended Community Part 3 = Sub-Types"

    &nbs= p;            = ;            =         -------------------=

 

=

Change: Experimental =E0 Experimental = Use

 

=

- IANA is requested to = create the GENERIC TRANSITIVE EXPERIMENTAL EXTENDED COMMUNITY PART 2 = SUB-TYPES registry. It should be seeded with the following = Sub-Type

 

=

Change: Experimental =E0 Experimental = Use

 

=

 

=

- IANA is requested to = create the GENERIC TRANSITIVE EXPERIMENTAL EXTENDED COMMUNITY PART 3 = SUB-TYPES registry. It should be seeded with the following = Sub-Type

 

=

 

=

Change: Experimental =E0 Experimental = Use

 

All = accepted.



 

=

 

Nits: 

None noticed.

<= p class=3DMsoNormal> 

=

 

=

Thanks,

Nabil

<= /div>

 

=

 

------=_NextPart_000_0143_01CFD74E.CB396170-- From nobody Tue Sep 23 20:03:31 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A3C1A1B4A for ; Tue, 23 Sep 2014 20:03:27 -0700 (PDT) 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 FVRM5Hv9L0VY for ; Tue, 23 Sep 2014 20:03:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:792]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4B81A07BD for ; Tue, 23 Sep 2014 20:03:23 -0700 (PDT) Received: from [172.29.35.146] (66.129.241.12) by BLUPR05MB150.namprd05.prod.outlook.com (10.255.190.151) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Wed, 24 Sep 2014 03:02:46 +0000 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_23149EFE-7632-4B88-B59A-3BB2A2F9E7AE" From: Jeff Haas In-Reply-To: <014201cfd770$52458330$f6d08990$@ndzh.com> Date: Tue, 23 Sep 2014 23:02:10 -0400 Message-ID: References: <5FA68A99-8400-4279-9491-139DC014C6FD@juniper.net> <014201cfd770$52458330$f6d08990$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BY1PR0201CA0027.namprd02.prod.outlook.com (25.160.191.165) To BLUPR05MB150.namprd05.prod.outlook.com (10.255.190.151) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB150; X-Forefront-PRVS: 03449D5DD1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(51704005)(164054003)(189002)(377454003)(199003)(24454002)(36756003)(92726001)(110136001)(92566001)(83322001)(86362001)(82746002)(93916002)(19580405001)(85306004)(31966008)(76482002)(10300001)(87286001)(87976001)(104166001)(42186005)(95666004)(84326002)(230783001)(33656002)(83716003)(50986999)(46102003)(77982003)(77096002)(20776003)(50226001)(62966002)(74662003)(105586002)(106356001)(97736003)(512944002)(64706001)(101416001)(85852003)(88136002)(66066001)(81342003)(57306001)(102836001)(107046002)(83072002)(19580395003)(69556001)(76176999)(77156001)(99396002)(80022003)(74502003)(120916001)(21056001)(4396001)(81542003)(71186001)(89996001)(79102003)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB150; H:[172.29.35.146]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/IWzz3fi-ogR4cIOPb_3cYFwkmkA Cc: rtg-dir@ietf.org, Mach Chen , db3546@att.com, "Bitar, Nabil N" , rtg-ads@tools.ietf.org, Jonathan Hardwick , jgs@juniper.net Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 03:03:28 -0000 --Apple-Mail=_23149EFE-7632-4B88-B59A-3BB2A2F9E7AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" Sue, I'm still waiting to hear back from Nabil about the one open point. -- Jeff On Sep 23, 2014, at 4:52 PM, Susan Hares wrote: > Jeff and Nabil: > =20 > I=92ve not seen any further conversation on this topic? Is the = resolution pending offline? Or can we complete this topic? I would like = to push this draft through the process. > =20 > Please note Mach Chen has agreed to be the shepherd on this draft, but = it=92s his first IDR shepherding so you WG co-chair is helping keep the = ball rolling.=20 > =20 > Sue > =20 > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Jeff Haas > Sent: Friday, September 12, 2014 2:09 PM > To: Bitar, Nabil N > Cc: rtg-dir@ietf.org; db3546@att.com; rtg-ads@tools.ietf.org; Jonathan = Hardwick; jgs@juniper.net; Susan Hares > Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review: = draft-ietf-idr-flowspec-redirect-rt-bis-00 > =20 > Nabil, > =20 > Thanks for your review! > =20 > As seen below, I have accepted the majority of your changes but have = yet to issue an updated draft. There is one topic requiring some = further discussion. Once we've resolved that, I'll issue an updated = I-D. > =20 > -- Jeff > =20 > On Sep 8, 2014, at 10:22 AM, Bitar, Nabil N = wrote: > Minor Issues: >=20 > Following are suggested edits. >=20 > =20 > Abstract: > Change: originally documented in RFC 5575 =E0 originally documented = in RFC 5575 (Dissemination of Flow Specification Rules) > =20 > Done. >=20 >=20 > =20 > - Page 3, last sentence > a common interpretation of the Redirect Extended Community=92s "6-byte = Route Target" has been to look for any matching Route Target sharing the = same Value portion of its Extended Community. Thus, multiple Route = Targets provisioned in a router=92s VRFs might match even though the = format was different. > =20 > Suggested new text: > a common interpretation of the redirect extended community=92s "6-byte = route target" has been to look, at a receiving router, for a route = target value that matches the route target value in the received = redirect extended community, and import the advertised route to the = corresponding VRF instance subject to the rules defined in RFC 5575 [RFC = 5575]. However, because the route target format in the redirect extended = community is not clearly defined, the wrong match may occur. > =20 > Accepted. >=20 >=20 > =20 > - Page 4, second paragraph: > =20 > This "Value wildcard" behavior does not matched deployed = implementations of BGP Flowspec. > =20 >=20 > Suggested new text: > This "value wildcard" matching behavior, that does not take into = account the format of the route target defined for a local VRF and may = result in the wrong matching decision, does not match deployed = implementations of BGP flowspec. Deployed implementations of BGP = flowspec solves this problem by defining different redirect extended = communities that are specific to the format of the route target value. = This document defines the following redirect extended communities: > =20 > Accepted. >=20 >=20 > =20 > > =20 > - Page 4, first sentence under table: > =20 > It should be noted that the low-order nybble of the > Redirect=92s type field corresponds to the Route Target Extended = Community format field (Type). (See [RFC4360], Secs. 3.1, 3.2 and = [RFC5668], Sec. 2.) The low order octet (Sub-Type) of the Redirect = Extended Community remains 0x08, contrasted to 0x02 for Route Targets. > =20 > Question: Why is the reference to RFC 4360 section 3.1 and 3.2, and = RFC 5668 section 2? See to be the wrong references. Did you mean to = refer to RFC 4360 section 4? > =20 > The reference is basically to draw attention to the structural history = for why this was coded the way it was. The above references demonstrate = where that structure is defined. >=20 >=20 > =20 > Suggested new text: > It should be noted that the low-order nybble of the > High-order octet of the redirect extended community yype field in = Table 1 corresponds to that in the high-order octet of the route target = extended community type field. The low order octet (sub-type) of the = redirect extended Community remains 0x08, contrasted to 0x02 for route = targets (see [RFC4360] section 4). > =20 > See above. If you'd like to further clarify, let's talk about it in = the above context. >=20 >=20 > =20 > - Note: I suggest that you add text on matching the newly defined = redirect extended communities to route targets defined for VRF=92s to = update what is in RFC 5575. > =20 > I am unclear what you're asking here. If the idea is that there = should be text in this draft saying "route-targets exist and if they = match this RT in the flowspec redirect, install it in the relevant VRF", = I'd rather defer to the underlying base behavior in 5575. >=20 >=20 > =20 > =20 > Section 2 IANA Considerations (minor comments): > =20 > - 0x81 > "Generic Transitive Experimental Extended Community Part 2 Sub-Types" = Registry > ------------------- > =20 > Change: Experimental =E0 Experimental Use > =20 > - 0x82 > "Generic Transitive Experimental Extended Community Part 3 Sub-Types" > ------------------- > =20 > Change: Experimental =E0 Experimental Use > =20 > - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL = EXTENDED COMMUNITY PART 2 SUB-TYPES registry. It should be seeded with = the following Sub-Type > =20 > Change: Experimental =E0 Experimental Use > =20 > =20 > - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL = EXTENDED COMMUNITY PART 3 SUB-TYPES registry. It should be seeded with = the following Sub-Type > =20 > =20 > Change: Experimental =E0 Experimental Use > =20 > All accepted. >=20 >=20 > =20 > =20 >=20 > Nits:=20 >=20 > None noticed. >=20 > =20 > =20 > Thanks, > Nabil --Apple-Mail=_23149EFE-7632-4B88-B59A-3BB2A2F9E7AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" Sue,

I'm still waiting to hear = back from Nabil about the one open point.

-- = Jeff

On Sep 23, 2014, at 4:52 PM, Susan Hares = <shares@ndzh.com> = wrote:

Jeff and = Nabil:
 
I=92ve not seen any further conversation on this = topic?  Is the resolution pending offline? Or can we complete this = topic?  I would like to push this draft through the = process.
 
Please note Mach Chen has agreed to be the shepherd = on this draft, but it=92s his first IDR shepherding so you WG co-chair = is helping keep the ball rolling. 
 
Sue
 
From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Jeff = Haas
Sent: Friday, September 12, 2014 = 2:09 PM
To: Bitar, Nabil = N
Cc: rtg-dir@ietf.org; db3546@att.com; rtg-ads@tools.ietf.org; Jonathan = Hardwick; jgs@juniper.net; Susan Hares
Subject: Re: [RTG-DIR] [RTG-DIR} = RtgDir review: = draft-ietf-idr-flowspec-redirect-rt-bis-00
 
Nabil,
 
Thanks for your review!
 
As seen below, I have accepted the majority of your = changes but have yet to issue an updated draft.  There is one topic = requiring some further discussion.  Once we've resolved that, I'll = issue an updated I-D.
 
-- = Jeff
 
On Sep 8, 2014, at 10:22 AM, Bitar, Nabil N <nabil.n.bitar@verizon.com> = wrote:

Minor = Issues:

Following are suggested edits.

 
Abstract:
Change:  originally documented in RFC = 5575 =E0 originally documented = in RFC 5575 (Dissemination of Flow Specification = Rules)
 
Done.


 
- Page 3, last = sentence
a common interpretation of = the Redirect Extended Community=92s "6-byte Route Target" has been to = look for any matching Route Target sharing the same Value portion of its = Extended Community. Thus, multiple Route Targets provisioned in a = router=92s VRFs might match even though the format was = different.
 
Suggested new text:
a = common interpretation of the redirect extended community=92s "6-byte = route target" has been to look, at a receiving router, for a route = target value that matches the route target value in the received = redirect extended community, and import the advertised route to the = corresponding VRF instance subject to the rules defined in RFC 5575 [RFC = 5575]. However, because the route target format in the redirect extended = community is not clearly defined, the wrong match may = occur.
 
Accepted.


 
- = Page 4, second paragraph:
 
This "Value wildcard" behavior does not matched deployed = implementations of BGP Flowspec.

 

Suggested new = text:
This "value wildcard" = matching behavior, that does not take into account the format of the = route target defined for a local VRF and may result in the wrong = matching decision, does not match deployed implementations of BGP = flowspec. Deployed implementations of BGP flowspec solves this problem = by defining different redirect extended communities that are specific to = the format of the route target value. This document defines the = following redirect extended = communities:
 
Accepted.


 
<Keep table = here>
 
- = Page 4, first sentence under = table:
 
It = should be noted that the low-order nybble of = the
Redirect=92s type field = corresponds to the Route Target Extended Community format field (Type). = (See [RFC4360], Secs. 3.1, 3.2 and [RFC5668], Sec. 2.) The low order = octet (Sub-Type) of the Redirect Extended Community remains 0x08, = contrasted to 0x02 for Route = Targets.
 
Question:  Why is the reference = to RFC 4360 section 3.1 and 3.2, and RFC 5668 section 2? See to be the = wrong references. Did you mean to refer to RFC 4360 section = 4?
 
The = reference is basically to draw attention to the structural history for = why this was coded the way it was.  The above references = demonstrate where that structure is = defined.


 
Suggested new text:
It = should be noted that the low-order nybble of = the
High-order octet of the = redirect extended community yype field in Table 1 corresponds to that in = the high-order octet of the route target extended community type field. = The low order octet (sub-type) of the redirect extended Community = remains 0x08, contrasted to 0x02 for route targets (see [RFC4360] = section 4).
 
See = above.  If you'd like to further clarify, let's talk about it in = the above context.


 
- = Note:  I suggest = that you add text on matching the newly defined redirect extended = communities to route targets defined for VRF=92s to update what is in = RFC 5575.
 
I am = unclear what you're asking here.  If the idea is that there should = be text in this draft saying "route-targets exist and if they match this = RT in the flowspec redirect, install it in the relevant VRF", I'd rather = defer to the underlying base behavior in = 5575.


 
 
Section 2 IANA Considerations (minor = comments):
 
- = 0x81
"Generic Transitive = Experimental Extended Community Part 2 Sub-Types" = Registry
          &= nbsp;           &nb= sp;            = ;  -------------------
 
Change: Experimental =E0 Experimental Use
 
- = 0x82
"Generic Transitive = Experimental Extended Community Part 3 = Sub-Types"
          &= nbsp;           &nb= sp;            = ;  -------------------
 
Change: Experimental =E0 Experimental Use
 
- = IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL EXTENDED = COMMUNITY PART 2 SUB-TYPES registry. It should be seeded with the = following Sub-Type
 
Change: Experimental =E0 Experimental Use
 
 
- = IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL EXTENDED = COMMUNITY PART 3 SUB-TYPES registry. It should be seeded with the = following Sub-Type
 
 
Change: Experimental =E0 Experimental = Use
 
All = accepted.


 

 

Nits: 

None noticed.

 
 
Thanks,
Nabil

= --Apple-Mail=_23149EFE-7632-4B88-B59A-3BB2A2F9E7AE-- From nobody Fri Sep 26 05:08:12 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F3E1A1B68; Fri, 26 Sep 2014 05:08:09 -0700 (PDT) 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 ygBZA1K314uF; Fri, 26 Sep 2014 05:08:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32671A1B3D; Fri, 26 Sep 2014 05:08:07 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 26 Sep 2014 12:08:06 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.1039.011; Fri, 26 Sep 2014 12:08:06 +0000 From: John E Drake To: "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ospf-bfd-discriminator-00.txt Thread-Index: Ac/ZgP9Z/cIFEsLbSMmxt7VD3T5ggw== Date: Fri, 26 Sep 2014 12:08:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB562; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(90102001)(83072002)(20776003)(83322001)(10300001)(99396003)(120916001)(19580395003)(33646002)(85852003)(21056001)(92566001)(86362001)(64706001)(54356999)(105586002)(50986999)(2351001)(4396001)(229853001)(95666004)(108616004)(230783001)(99286002)(87936001)(106356001)(2656002)(110136001)(85306004)(79102003)(77982003)(101416001)(66066001)(46102003)(74662003)(80022003)(74502003)(74316001)(81542003)(81342003)(76482002)(107046002)(15975445006)(76576001)(31966008)(97736003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB562; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/3OQH0-GX1Lr7qPrv6k-q4gcDn-c Cc: "rtg-dir@ietf.org" , "draft-ietf-ospf-bfd-discriminator.all@ietf.org" , OSPF WG List Subject: [RTG-DIR] RtgDir review: draft-ietf-ospf-bfd-discriminator-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 12:08:09 -0000 Hi I've been selected as the routing directorate QA reviewer for draft-ietf-os= pf-bfd-discriminator-00. This is part of the QA process described at https:= //trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa = =20 The document is in good shape. It is very readable and I don't see any iss= ues with it.=20 Yours Irrespectively, John From nobody Mon Sep 29 03:56:07 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B6B1A0386; Mon, 29 Sep 2014 03:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 X-BdBRWiRWIu; Mon, 29 Sep 2014 03:55:58 -0700 (PDT) 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 F0A2A1A020A; Mon, 29 Sep 2014 03:55:57 -0700 (PDT) Received: from [192.168.0.100] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 29A171801256; Mon, 29 Sep 2014 12:55:56 +0200 (CEST) Message-ID: <54293ABE.5000407@pi.nu> Date: Mon, 29 Sep 2014 12:55:58 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/elAVBNxQY_URE5lNLq7KMYLjzo4 Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , draft-filsfils-spring-segment-routing-mpls@tools.ietf.org, "" , "mpls-chairs@tools.ietf.org" Subject: [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 10:56:00 -0000 Hello, I have been selected as the Routing Directorate QA reviewer for draft-filsfils-spring-segment-routing-mpls-03.txt. The Routing Directorate QA reviews are intended to be a support to improve the quality of RTG Area documents as the pass through the IETF process. This is the QA review at the time of wg document adoption poll. Document: draft-filsfils-spring-segment-routing-mpls-03.txt Reviewer: Loa Andersson Review Date: 2014-09-28 Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: Standards Track Please find the review at: http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%202014 /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 Mon Sep 29 05:29:10 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51661A3BA4; Mon, 29 Sep 2014 05:29:04 -0700 (PDT) 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 0JICebDxwZpT; Mon, 29 Sep 2014 05:29:02 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::762]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DB01A3B9E; Mon, 29 Sep 2014 05:29:01 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 29 Sep 2014 12:28:38 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.1034.003; Mon, 29 Sep 2014 12:28:38 +0000 From: Alexander Vainshtein To: Loa Andersson Thread-Topic: [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP29P4IT/IjiSa90674LLz0cqIbpwYBOUw Date: Mon, 29 Sep 2014 12:28:38 +0000 Message-ID: References: <54293ABE.5000407@pi.nu> In-Reply-To: <54293ABE.5000407@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB609; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(377424004)(252514010)(189002)(51444003)(51704005)(97736003)(77982003)(120916001)(21056001)(106356001)(74502003)(81542003)(2656002)(101416001)(107046002)(74316001)(20776003)(74662003)(76576001)(81342003)(10300001)(108616004)(80022003)(87936001)(46102003)(83072002)(15975445006)(19580405001)(31966008)(85306004)(76176999)(95666004)(90102001)(86362001)(105586002)(54356999)(33646002)(64706001)(15202345003)(92566001)(230783001)(79102003)(83322001)(66066001)(50986999)(4396001)(76482002)(106116001)(85852003)(99396003)(19580395003)(110136001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/1J79lQFzqB0cJVh-P0Sv_7YPxio Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 12:29:04 -0000 Loa, and all, I have read the draft and your review on the Wiki page, and I think that yo= ur question about domain-wide labels is worth detailed discussion. In Section 2 "Illustration", the draft says that: - PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its attache= d node segment 102 - PE1 installs the VPN prefix Z in the appropriate VRF and resolves the ne= xt-hop onto the node segment 102. =20 Upon receiving a packet from A destined to Z, PE1 pushes two labels on= to the packet: the top label is 102, the bottom label is LZ.=20 102 identifies the node segment to PE2 and hence transports the packet a= long the ECMP-aware shortest- path to PE2. To me this strongly suggests that label 102 is understood by P1, P2, P3 and= P4 as a domain-wide label for an LSP that terminates in PE2. This looks di= fferent from the downstream label allocation process as defined in RFC 3031= and RFC 5331.=20 RFC 5331 clearly states in Section 4 "Upstream Label Assignment" that If the binding between L and F was made by a third party, say R3, and t= hen advertised to both Ru and Rd, we also refer to the label binding as=20 "upstream-assigned". In our case it seems that assignment of label 102 and its binding to FEC th= at is represented by Segment 102 is performed by PE2, so P1, P2, P3 and P4 = should all treat this label as upstream-assigned. But this is never mention= ed in the draft. I concur with you that this requires discussion in the MPLS WG, and I am no= t sure such a discussion should be postponed until the SPRING WG LC. I must admit that I did not read other SPRING documents (including one on i= nteroperability with existing label distribution protocols), and hence I ca= n be wrong in my conclusions. But the MPLS WG looks to me like exactly the = place where this should be clarified. My 2c, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Monday, September 29, 2014 1:56 PM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; draft-filsfils-spri= ng- > segment-routing-mpls@tools.ietf.org; ; mpls= - > chairs@tools.ietf.org > Subject: [spring] Routing Directorate QA review of draft-filsfils-spring- > segment-routing-mpls >=20 > Hello, >=20 > I have been selected as the Routing Directorate QA reviewer for draft-fil= sfils- > spring-segment-routing-mpls-03.txt. >=20 > The Routing Directorate QA reviews are intended to be a support to improv= e > the quality of RTG Area documents as the pass through the IETF process. >=20 > This is the QA review at the time of wg document adoption poll. >=20 > Document: draft-filsfils-spring-segment-routing-mpls-03.txt > Reviewer: Loa Andersson > Review Date: 2014-09-28 > Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: > Standards Track >=20 > Please find the review at: >=20 > http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%202014 >=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 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Sep 29 06:03:17 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208FB1A1BA9; Mon, 29 Sep 2014 06:02:57 -0700 (PDT) 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 Ywbbd4S7vDfl; Mon, 29 Sep 2014 06:02:55 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::714]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82AD41A6F8F; Mon, 29 Sep 2014 06:02:42 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB610.eurprd03.prod.outlook.com (10.242.109.27) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 29 Sep 2014 13:02:19 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.1034.003; Mon, 29 Sep 2014 13:02:19 +0000 From: Alexander Vainshtein To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP29P4IT/IjiSa90674LLz0cqIbpwYBOUwgAAM3ICAAABk4A== Date: Mon, 29 Sep 2014 13:02:18 +0000 Message-ID: <8d34f502f77b4c709473f4e043db7345@AM3PR03MB612.eurprd03.prod.outlook.com> References: <54293ABE.5000407@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB610; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(24454002)(51444003)(252514010)(13464003)(377454003)(189002)(377424004)(19580405001)(85306004)(83072002)(81342003)(110136001)(33646002)(20776003)(74662003)(81542003)(90102001)(85852003)(64706001)(15202345003)(86362001)(31966008)(66066001)(54356999)(83322001)(107046002)(92566001)(2656002)(87936001)(10300001)(74316001)(120916001)(74502003)(77982003)(21056001)(108616004)(50986999)(79102003)(80022003)(76482002)(95666004)(76576001)(76176999)(97736003)(19580395003)(15975445006)(46102003)(230783001)(106356001)(4396001)(106116001)(105586002)(101416001)(99396003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/c9DrjotAHBi1Zk8PHq_Z2WXqHzw Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 13:02:57 -0000 Stefano, Lots of thanks for a prompt and detailed response. If, as you say, the SID is just a global index into the local label space = of each LSR, then the statement "PE1 pushes two label on the packet: the to= p one is 102" (for SID=3D102) is grossly misleading IMO, and should be chan= ged. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > Sent: Monday, September 29, 2014 3:56 PM > To: Alexander Vainshtein > Cc: Loa Andersson; rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; rtg- > ads@tools.ietf.org; draft-filsfils-spring-segment-routing-mpls@tools.ietf= .org; > ; mpls-chairs@tools.ietf.org > Subject: Re: [spring] Routing Directorate QA review of draft-filsfils-spr= ing- > segment-routing-mpls >=20 > Sasha, >=20 > SIDs are globally allocated and distributed. So, the answer to your quest= ion > about P1, P2, P3 and P4 knowledge of the SID representing PE2 is "yes". > Routers within the domain must know the SID representing PE2 (e.g.: 102). >=20 > Now, when it comes to the dataplane, it has to be understood that the lab= el > on top of the packet MAY have local significance and therefore MAY change > at each hop according to mpls architecture. It is explained (succinctly, = I admit) > in section 3. >=20 > This because the SID represents an index into a label space, not a label = value. > IOW, there is no requirement from SR to have globally assigned labels. Th= e > SR architecture makes use of globally assigned indexes onto locally scope= d > label space. This is, btw, what been implemented and currently (interop) > tested. >=20 > s. >=20 >=20 > On Sep 29, 2014, at 2:28 PM, Alexander Vainshtein wrote: > > Loa, and all, > > I have read the draft and your review on the Wiki page, and I think tha= t > your question about domain-wide labels is worth detailed discussion. > > In Section 2 "Illustration", the draft says that: > > - PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its > > attached node segment 102 > > - PE1 installs the VPN prefix Z in the appropriate VRF and resolves the > next-hop onto the node segment 102. > > Upon receiving a packet from A destined to Z, PE1 pushes two labels= onto > the packet: the top label is 102, the bottom label is LZ. > > 102 identifies the node segment to PE2 and hence transports the packe= t > along the ECMP-aware shortest- path to PE2. > > > > To me this strongly suggests that label 102 is understood by P1, P2, P3= and > P4 as a domain-wide label for an LSP that terminates in PE2. This looks > different from the downstream label allocation process as defined in RFC > 3031 and RFC 5331. > > RFC 5331 clearly states in Section 4 "Upstream Label Assignment" that > > > > If the binding between L and F was made by a third party, say R3, > > and then advertised to both Ru and Rd, we also refer to the label bind= ing > as "upstream-assigned". > > > > > > In our case it seems that assignment of label 102 and its binding to FE= C that > is represented by Segment 102 is performed by PE2, so P1, P2, P3 and P4 > should all treat this label as upstream-assigned. But this is never menti= oned > in the draft. > > > > I concur with you that this requires discussion in the MPLS WG, and I a= m > not sure such a discussion should be postponed until the SPRING WG LC. > > > > I must admit that I did not read other SPRING documents (including one = on > interoperability with existing label distribution protocols), and hence I= can be > wrong in my conclusions. But the MPLS WG looks to me like exactly the pl= ace > where this should be clarified. > > > > My 2c, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > >> -----Original Message----- > >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Loa > >> Andersson > >> Sent: Monday, September 29, 2014 1:56 PM > >> To: rtg-ads@tools.ietf.org > >> Cc: rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; > >> draft-filsfils-spring- segment-routing-mpls@tools.ietf.org; > >> ; mpls- chairs@tools.ietf.org > >> Subject: [spring] Routing Directorate QA review of > >> draft-filsfils-spring- segment-routing-mpls > >> > >> Hello, > >> > >> I have been selected as the Routing Directorate QA reviewer for > >> draft-filsfils- spring-segment-routing-mpls-03.txt. > >> > >> The Routing Directorate QA reviews are intended to be a support to > >> improve the quality of RTG Area documents as the pass through the IETF > process. > >> > >> This is the QA review at the time of wg document adoption poll. > >> > >> Document: draft-filsfils-spring-segment-routing-mpls-03.txt > >> Reviewer: Loa Andersson > >> Review Date: 2014-09-28 > >> Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: > >> Standards Track > >> > >> Please find the review at: > >> > >> http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%20201 > >> 4 > >> > >> /Loa > >> > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Sep 29 06:52:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11EB1A1AD5; Mon, 29 Sep 2014 06:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 UcZAvk2tD_1F; Mon, 29 Sep 2014 06:52:17 -0700 (PDT) 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 759981A6F8D; Mon, 29 Sep 2014 06:52:17 -0700 (PDT) Received: from [192.168.0.113] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 094BC180131A; Mon, 29 Sep 2014 15:52:16 +0200 (CEST) Message-ID: <54296411.8060304@pi.nu> Date: Mon, 29 Sep 2014 15:52:17 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alexander Vainshtein References: <54293ABE.5000407@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/8Q5bFc8rwy8WTCwYLPgeIJPBbNs Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 13:52:18 -0000 Sasha, I did NOT mean to imply that this discussion in the MPLS wg should wait until the SPRING wg last call, on the contrary if the answer to my question is that this a domain wide label, then it has to be brought to the MPLS wg BEFORE this is adopted as a SPRING wg document. /Loa On 2014-09-29 14:28, Alexander Vainshtein wrote: > I concur with you that this requires discussion in the MPLS WG, and I am not sure such a discussion should be postponed until the SPRING WG LC. -- 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 Sep 29 06:56:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238611A6FAB; Mon, 29 Sep 2014 06:56:19 -0700 (PDT) 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 p3WMvcN2kWCd; Mon, 29 Sep 2014 06:56:17 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::700]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CEB1A1AFF; Mon, 29 Sep 2014 06:56:17 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB611.eurprd03.prod.outlook.com (10.242.109.28) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 29 Sep 2014 13:55:54 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.1034.003; Mon, 29 Sep 2014 13:55:53 +0000 From: Alexander Vainshtein To: Loa Andersson Thread-Topic: [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP29P4IT/IjiSa90674LLz0cqIbpwYBOUwgAAcnICAAADKMA== Date: Mon, 29 Sep 2014 13:55:53 +0000 Message-ID: References: <54293ABE.5000407@pi.nu> <54296411.8060304@pi.nu> In-Reply-To: <54296411.8060304@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB611; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377424004)(24454002)(51704005)(189002)(252514010)(377454003)(199003)(83072002)(97736003)(90102001)(66066001)(101416001)(31966008)(106356001)(76576001)(79102003)(33646002)(50986999)(64706001)(85852003)(107046002)(110136001)(108616004)(105586002)(85306004)(83322001)(74662003)(86362001)(81342003)(19580405001)(74502003)(46102003)(76176999)(81542003)(4396001)(80022003)(77982003)(21056001)(120916001)(54356999)(87936001)(92566001)(74316001)(95666004)(10300001)(99396003)(2656002)(230783001)(20776003)(19580395003)(76482002)(106116001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB611; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/jIdQA08er9FJs9mTI9r-2i1S-P4 Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 13:56:19 -0000 Loa, Seems we are in sync on this matter. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Loa Andersso= n > Sent: Monday, September 29, 2014 4:52 PM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; chairs@tools.ietf.org>; draft-filsfils-spring-segment-routing- > mpls@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [RTG-DIR] [spring] Routing Directorate QA review of draft-fi= lsfils- > spring-segment-routing-mpls >=20 > Sasha, >=20 > I did NOT mean to imply that this discussion in the MPLS wg should wait u= ntil > the SPRING wg last call, on the contrary if the answer to my question is = that > this a domain wide label, then it has to be brought to the MPLS wg BEFORE > this is adopted as a SPRING wg document. >=20 > /Loa >=20 > On 2014-09-29 14:28, Alexander Vainshtein wrote: > > I concur with you that this requires discussion in the MPLS WG, and I a= m > not sure such a discussion should be postponed until the SPRING WG LC. >=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 Mon Sep 29 07:02:34 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBA81A872A; Mon, 29 Sep 2014 05:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 M_4T88bFoXRu; Mon, 29 Sep 2014 05:55:57 -0700 (PDT) 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 818671A8727; Mon, 29 Sep 2014 05:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4691; q=dns/txt; s=iport; t=1411995357; x=1413204957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hqP18WRhHoIeaamVxk06L+FsuVM38yVza84PU7kLKOc=; b=Xc9yH1Vn4hQq/Vb8xDOP/L8NDLWLub2dBT6kQroWLkncuO5avLaBVzmG jfEz6o1HZk1xXmFZZs1zNL0WGnMURNJldeXwIgeiszeZ0KVuntYaa+dco Tpl+5LtzORoH0zI47jKv4XwEB1gi6s8JErwKpJEE9RZZseaUF378PvEfF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAL9VKVStJA2L/2dsb2JhbABggw5TW8oJCoZ6VAKBDRYBe4QDAQEBBAEBATcxAwsMAgICAQgRAQIBAQEBHgkHGwwLFAMGCAIEDgWIPg2/KgEXBI84EQEdMwcGgyiBHQWRZYQ6hwmBYpN7gXIYFoFDbAGBDjmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,620,1406592000"; d="scan'208";a="359151523" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP; 29 Sep 2014 12:55:56 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8TCtusM012358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 12:55:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.174]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 07:55:56 -0500 From: "Stefano Previdi (sprevidi)" To: Alexander Vainshtein Thread-Topic: [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP29P6mpNjXcNynEqOMeDwWEw/7ZwYXfMAgAAHnoA= Date: Mon, 29 Sep 2014 12:55:55 +0000 Message-ID: References: <54293ABE.5000407@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.147.74.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <7FC9028C075B3042BF0CEA7DCF62B4BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/0hm9chCQHxMw6sYnOQdyBmHgnJU X-Mailman-Approved-At: Mon, 29 Sep 2014 07:02:32 -0700 Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 12:55:59 -0000 Sasha, SIDs are globally allocated and distributed. So, the answer to your questio= n about P1, P2, P3 and P4 knowledge of the SID representing PE2 is "yes". R= outers within the domain must know the SID representing PE2 (e.g.: 102). Now, when it comes to the dataplane, it has to be understood that the label= on top of the packet MAY have local significance and therefore MAY change = at each hop according to mpls architecture. It is explained (succinctly, I = admit) in section 3. This because the SID represents an index into a label space, not a label va= lue. IOW, there is no requirement from SR to have globally assigned labels= . The SR architecture makes use of globally assigned indexes onto locally s= coped label space. This is, btw, what been implemented and currently (inter= op) tested. s. On Sep 29, 2014, at 2:28 PM, Alexander Vainshtein wrote: > Loa, and all, > I have read the draft and your review on the Wiki page, and I think that = your question about domain-wide labels is worth detailed discussion. > In Section 2 "Illustration", the draft says that: > - PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its attac= hed node segment 102 > - PE1 installs the VPN prefix Z in the appropriate VRF and resolves the = next-hop onto the node segment 102. =20 > Upon receiving a packet from A destined to Z, PE1 pushes two labels o= nto the packet: the top label is 102, the bottom label is LZ.=20 > 102 identifies the node segment to PE2 and hence transports the packet = along the ECMP-aware shortest- path to PE2. >=20 > To me this strongly suggests that label 102 is understood by P1, P2, P3 a= nd P4 as a domain-wide label for an LSP that terminates in PE2. This looks = different from the downstream label allocation process as defined in RFC 30= 31 and RFC 5331.=20 > RFC 5331 clearly states in Section 4 "Upstream Label Assignment" that > > If the binding between L and F was made by a third party, say R3, and = then advertised to both Ru and Rd, we also refer to the label binding as=20 > "upstream-assigned". > >=20 > In our case it seems that assignment of label 102 and its binding to FEC = that is represented by Segment 102 is performed by PE2, so P1, P2, P3 and P= 4 should all treat this label as upstream-assigned. But this is never menti= oned in the draft. >=20 > I concur with you that this requires discussion in the MPLS WG, and I am = not sure such a discussion should be postponed until the SPRING WG LC. >=20 > I must admit that I did not read other SPRING documents (including one on= interoperability with existing label distribution protocols), and hence I = can be wrong in my conclusions. But the MPLS WG looks to me like exactly th= e place where this should be clarified. >=20 > My 2c, > Sasha=20 > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 >=20 >> -----Original Message----- >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Monday, September 29, 2014 1:56 PM >> To: rtg-ads@tools.ietf.org >> Cc: rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; draft-filsfils-spr= ing- >> segment-routing-mpls@tools.ietf.org; ; mpl= s- >> chairs@tools.ietf.org >> Subject: [spring] Routing Directorate QA review of draft-filsfils-spring= - >> segment-routing-mpls >>=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate QA reviewer for draft-fi= lsfils- >> spring-segment-routing-mpls-03.txt. >>=20 >> The Routing Directorate QA reviews are intended to be a support to impro= ve >> the quality of RTG Area documents as the pass through the IETF process. >>=20 >> This is the QA review at the time of wg document adoption poll. >>=20 >> Document: draft-filsfils-spring-segment-routing-mpls-03.txt >> Reviewer: Loa Andersson >> Review Date: 2014-09-28 >> Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: >> Standards Track >>=20 >> Please find the review at: >>=20 >> http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%202014 >>=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 >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Sep 29 07:02:35 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2400A1A1AD5; Mon, 29 Sep 2014 07:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 ZMlOz_CAmteI; Mon, 29 Sep 2014 07:00:59 -0700 (PDT) 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 801961A0395; Mon, 29 Sep 2014 07:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1113; q=dns/txt; s=iport; t=1411999260; x=1413208860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L5vURmzUqYhr5WCXOXRtQ1bKwGALQMytFEn3gtcB3WE=; b=iFzPoswafIz0uelvoFUnyaqfWR61bEfPDx/Xg64Zu84Nyh0Eqt7oAt0h kvj0WPvbbQSsARWHpadlMZEtiuVXjjOLiprpXpZ0yRkRJB6x+c2KceuOh yqGmtkr6ZaqKvpRIKHulBUBmKiOusTjn4yaj6vEbFT2aHeGWMJqFfCFBY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANplKVStJV2Z/2dsb2JhbABggw5TW8oJCoZ6VAKBDhYBe4QEAQEEAQEBNzEDCw4CAgEIGB4QGwwLJQIEDgWIPg2/MwETBASPOBEBHTMHgy6BHQWRZYtDlV2CIIFDbIEPOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,620,1406592000"; d="scan'208";a="82361045" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 29 Sep 2014 14:00:59 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8TE0wj0007832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 14:00:58 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.174]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 09:00:58 -0500 From: "Stefano Previdi (sprevidi)" To: Loa Andersson Thread-Topic: [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP2+ydV7DaNVEy4kS4FgFgzYomJJwYd4uA Date: Mon, 29 Sep 2014 14:00:58 +0000 Message-ID: References: <54293ABE.5000407@pi.nu> <54296411.8060304@pi.nu> In-Reply-To: <54296411.8060304@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.196.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <495538B27EC7274ABA4B341AE71D5FAB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/awQgnz-L_3Db4C5g6iimCQhrt5g X-Mailman-Approved-At: Mon, 29 Sep 2014 07:02:33 -0700 Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , Alexander Vainshtein , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:01:01 -0000 On Sep 29, 2014, at 3:52 PM, Loa Andersson wrote: > Sasha, >=20 > I did NOT mean to imply that this discussion in the MPLS wg should > wait until the SPRING wg last call, on the contrary if the answer to > my question is that this a domain wide label, then it has to be brought > to the MPLS wg BEFORE this is adopted as a SPRING wg document. I agree with you and the answer is "no" we don't want to bring a discussion= about domain-wide labels because this is not a requirement of segment rout= ing. s. >=20 > /Loa >=20 > On 2014-09-29 14:28, Alexander Vainshtein wrote: >> I concur with you that this requires discussion in the MPLS WG, and I am= not sure such a discussion should be postponed until the SPRING WG LC. >=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 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Sep 29 07:10:22 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D166A1A1ABA; Mon, 29 Sep 2014 07:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 weCFFI2RKiUu; Mon, 29 Sep 2014 07:10:07 -0700 (PDT) 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 038EF1A1A9E; Mon, 29 Sep 2014 07:10:07 -0700 (PDT) Received: from [192.168.0.113] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 86F37180131A; Mon, 29 Sep 2014 16:10:05 +0200 (CEST) Message-ID: <5429683E.8040103@pi.nu> Date: Mon, 29 Sep 2014 16:10:06 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stefano Previdi (sprevidi)" References: <54293ABE.5000407@pi.nu> <54296411.8060304@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/BMZGN6GFUkfJYtl37KLgpffCSRo Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , Alexander Vainshtein , "mpls@ietf.org" , "" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:10:13 -0000 Stefano, I'm fine with that, but I guess that the SPRING wg chairs and/or the rtg AD's need to make the consensus call on that. /Loa On 2014-09-29 16:00, Stefano Previdi (sprevidi) wrote: > On Sep 29, 2014, at 3:52 PM, Loa Andersson wrote: >> Sasha, >> >> I did NOT mean to imply that this discussion in the MPLS wg should >> wait until the SPRING wg last call, on the contrary if the answer to >> my question is that this a domain wide label, then it has to be brought >> to the MPLS wg BEFORE this is adopted as a SPRING wg document. > > > I agree with you and the answer is "no" we don't want to bring a discussion about domain-wide labels because this is not a requirement of segment routing. > > s. > > >> >> /Loa >> >> On 2014-09-29 14:28, Alexander Vainshtein wrote: >>> I concur with you that this requires discussion in the MPLS WG, and I am not sure such a discussion should be postponed until the SPRING WG LC. >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64