From nobody Fri Aug 1 03:48:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F011A0323 for ; Fri, 1 Aug 2014 03:48:02 -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, RP_MATCHES_RCVD=-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 Bd_OXEga6BDL for ; Fri, 1 Aug 2014 03:48:00 -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 3BAF81A0033 for ; Fri, 1 Aug 2014 03:48:00 -0700 (PDT) Received: from [192.168.1.133] (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 BAE571802AB1; Fri, 1 Aug 2014 12:47:58 +0200 (CEST) Message-ID: <53DB705E.2000508@pi.nu> Date: Fri, 01 Aug 2014 12:47: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: "Sami Boutros (sboutros)" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <001201cface4$33eaf1b0$9bc0d510$@olddog.co.uk> <40746B2300A8FC4AB04EE722A593182B76F4F63A@ONWVEXCHMB04.ciena.com> <003e01cface9$d1783ff0$7468bfd0$@olddog.co.uk> <96A58928-2B10-48FC-B627-A73D6C959B93@cisco.com> In-Reply-To: <96A58928-2B10-48FC-B627-A73D6C959B93@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UkcbEYdZdWyb5BuvaDQ3uDC0OSk Cc: "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" Subject: Re: [mpls] Request for Early allocation from LSP Parameters TLVs Registry for draft-ietf-mpls-lsp-ping-ttl-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 10:48:02 -0000 Sami, After consulting with Adrian, we have agreed that the easiest way forward is for this time only and under the directive from the responsible AD and document shepherd you should post a new version of the draft can put the code point you want in the IANA section. /Loa On 2014-08-01 02:21, Sami Boutros (sboutros) wrote: > Hi, > > IANA is requested to assign TLV type value to the following TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry. > > The value requested is 32769. > > Thanks, > > Sami > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 1 07:52:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A601B1B27B4 for ; Fri, 1 Aug 2014 07:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 g85yZHlWbnud for ; Fri, 1 Aug 2014 07:52:49 -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 12BCE1B27B3 for ; Fri, 1 Aug 2014 07:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1139; q=dns/txt; s=iport; t=1406904769; x=1408114369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/oxzl1ZjsZ0uXBmJcU4+R/XJZA4cNRCKoip3UcSokPk=; b=VhEHaiwKX0RK9dmF8m0OPCLeimNIUvm8Ufag+vO5NNtkDER3rZp3Q4vF 2tNXmvmOPKy1O5N3FdhFlkKK6+KkxmiDLhDJDFLmLSW1ELI5lOGDik1uW ACNVDdIAnjO8gXmXbp5rO19kaaVpzsDzFsE23V+9TOAW76NSKfyecJia2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAHao21OtJV2S/2dsb2JhbABbgw1SVwTMAQqHTAGBCRZ3hAMBAQEDAQEBAWgDCwUJAgIBCBIGIwsbDAsXDgIEDgWIOggNyW8TBASOZhEBHTMHgy+BHAWKTpEslFqCA4FGbIEMOQ X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="344399303" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 01 Aug 2014 14:52:48 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s71Eqm7N008853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 14:52:48 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 09:52:47 -0500 From: "Sami Boutros (sboutros)" To: Loa Andersson Thread-Topic: [mpls] Request for Early allocation from LSP Parameters TLVs Registry for draft-ietf-mpls-lsp-ping-ttl-tlv Thread-Index: AQHPrR6bGn0bFnUfZ02B+UUe+jKiX5u75bEAgABEYwA= Date: Fri, 1 Aug 2014 14:52:46 +0000 Message-ID: References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <001201cface4$33eaf1b0$9bc0d510$@olddog.co.uk> <40746B2300A8FC4AB04EE722A593182B76F4F63A@ONWVEXCHMB04.ciena.com> <003e01cface9$d1783ff0$7468bfd0$@olddog.co.uk> <96A58928-2B10-48FC-B627-A73D6C959B93@cisco.com> <53DB705E.2000508@pi.nu> In-Reply-To: <53DB705E.2000508@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.232.195] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0FD467933396434BA8EFFC3427E23C72@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JrhOZ9YA702tLe8YW6huqibHfUA Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" Subject: Re: [mpls] Request for Early allocation from LSP Parameters TLVs Registry for draft-ietf-mpls-lsp-ping-ttl-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 14:52:50 -0000 Sure will do Loa, Thanks, Sami On Aug 1, 2014, at 3:47 AM, Loa Andersson wrote: > Sami, >=20 > After consulting with Adrian, we have agreed that the easiest way > forward is for this time only and under the directive from > the responsible AD and document shepherd you should post a new version > of the draft can put the code point you want in the IANA section. >=20 > /Loa >=20 >=20 > On 2014-08-01 02:21, Sami Boutros (sboutros) wrote: >> Hi, >>=20 >> IANA is requested to assign TLV type value to the following TLV from the= "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (L= SPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry. >>=20 >> The value requested is 32769. >>=20 >> Thanks, >>=20 >> Sami >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 1 09:49:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029C71B2828 for ; Fri, 1 Aug 2014 09:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.603 X-Spam-Level: X-Spam-Status: No, score=-10.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 YINGfEouf0aL for ; Fri, 1 Aug 2014 09:49:06 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5867F1B2827 for ; Fri, 1 Aug 2014 09:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5898; q=dns/txt; s=iport; t=1406911746; x=1408121346; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=iNSq5L8OuXLpxPu+LV347DbKr0ES+cIVnpGrjzsWYvE=; b=JLrMDT9XvRqLoo571aySkq+j990/qQ78RsmGeTsPkwT08ZxWr2s4JjUs ZudFvicrqMzidY/hm00Vst4c0bAcr0aov3twN58Y5RazaMsCFkce0iMzw UMXaif2FIphqX20atKAVuIeQ0yP8FHn8NH53LlmAjLwXapdU0FP3CVdNi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FABvE21OtJV2d/2dsb2JhbABYA4MNUlcEzASHVIEMFneECgwbUg4EAQ9aFycEAQ0FG4gnyggXBI5xRxAYhDoFm3qBVJMGg0lsgQRB X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="65827425" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 01 Aug 2014 16:49:05 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s71Gn5J1021165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 16:49:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.94]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 11:49:05 -0500 From: "Kamran Raza (skraza)" To: "draft-esale-mpls-appl-aware-ldp-targeted-session@tools.ietf.org" , "sesale@juniper.net" Thread-Topic: Comments on draft-esale-mpls-appl-aware-ldp-targeted-session-00 Thread-Index: AQHPraiAF7Ke1x0I7EilIPI/pA/9YQ== Date: Fri, 1 Aug 2014 16:49:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.86.242.233] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/B7HMC4JQiGsk_mC4SsPUkf8iQns Cc: "mpls@ietf.org" Subject: [mpls] Comments on draft-esale-mpls-appl-aware-ldp-targeted-session-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:49:14 -0000 Hello Santosh/authors, Refer to our chat during IETF90, I have few comments, observations, and questions on this new I.D. General =3D=3D=3D=3D=3D=3D=3D - This I.D states the App-aware-TLDP as a solution to following two problem statements: (a) Control acceptance of TLDP session for asymmetric config cases (like rLFA) (b) Advertise only necessary FEC bindings over a session Ref (a): It is bit misleading as the document is NOT addressing the issue of acceptance of TLDP Hellos for such asymmetric cases; Instead, it is trying to just control the session establishment/progress (for resource control/limit reasons etc) and seems to assume that T-hello acceptance is already handled (e.g. Via passive side accept config etc). If this is the case, then document should state this assumption explicitly. On the same topic, I think that it would serve better if this TLDP capability was sent in a Hellos rather than post-session; This way you could even control formation of=20 unnecessary tgt-adj + avoid overhead of session estab (and teardown of non-acceptable sessions) Ref (b): This is trying to solve a problem which has already being addressed in other existing drafts (ip-pw-capability, ldp-ipv6) etc. The scope of this I.D., however, is just TLDP sessions when compared to earlier I.D + It adds TLDP-app knowledge to peers. This I.D. has some intersections with the other I.Ds and need careful analysis of interworking. =20 Section 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D - Can this Tgt-App Capability (TAC) advertised only on a TLDP session ? What are procedures if it is rxd on a non-tldp session ? What are procedures if a session type changes from tldp -> non-tldp and vice versa. - Regarding Targeted-Application Identifiers (TA-Id): (i) The ID is missing ICCP and Session Protection applications from the list. (ii) The ID is also missing P2MP PW FEC 130 (in case p2mp-pw I.D. Still progresses) (iii) For an LSR which has NONE of the listed applications configured but can still establish/permit A tLDP session (e.g. as a pure passive LSR accepting T-Hellos), there should be a TA-ID to cover such case. I suggest =B3Passive=B2 as the type. - Since TAC is a list of the Apps, the I.D. Needs to clarify how is an update constructed/decoded ? i.e. if an App changes, whether the update is just incremental or a snap-shot of all negotiated apps ? Section 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D - Is TAE is an indicative of a =B3supported=B2 or =B3cfged=B2 type ? I re= ad it as =B3cfged=B2.=20 The document is bit fuzzy about this important detail and needs some elaboration. =20 - re: "If the receiver LSR receives the same TA-Id in more than one TAE element, it MUST discard the TAC TLV And behave as if TAC TLV is not received.=B2. Q: Why not just process the 1st such element and ignore all duplicates/conflicting one. Why are we penalizing the entire TLV ? =20 - re: "On the receipt of a valid TAC TLV, an LSR MUST generate its own TAC TLV=B2. I am not sure this is doable at INIT time though; I.e. An LSR should generate its own TAC TLV without depending on receipt from other LSR. =20 - re: "The sender LSR playing the passive role in LDP session establishment MAY destroy the corresponding targeted adjacency.=B2 Q: Did you not mean to say =B3destroy the corresponding session=B2 ? - re: "When it detects a change in the sender LSR configuration or local configuration pertaining to TAC TLV..=B2 Q: How does an LSR detect change in sender LSR configuration ? If this is through Cfg Seq No, then ID needs to explictly state so. - re: "After an LDP session has been established with TAC capability, the sender and receiver LSR MUST distribute FEC label bindings for the negotiated applications only.=B2 I suggest to add a section mapping your TA-types to FEC-types. Note there could be multiple TA associated with the same FEC type (example: LDP tunneling, rLFA) - re: "This MAY lead to advertisements or withdrawals of certain FEC types=B2 I suggest use =B3This may lead to =8A." =20 Section 4: SAC and TAC capability interworking =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - re: "The TAC mechanism takes precedence over the SAC mechanism with respect to enabling applications for which state information will be advertised.=B2 I am not sure I agree (as a SAC author). Note that SAC scope for IP/PW capability is wider than TAC as it applies to both TLDP and non-TLDP. We will need to discuss more and close later. =20 =20 Section 5.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Could you elaborate more on different holdtime value for an automatic tgt session ?=20 =20 Section 5.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Seems like this TAC capability can NOT be withdrawn (as S-bit is always set to 1).=20 I understand that you control your withdrawal of T-App by =B3E=B2 bit = but I still think=20 That there is a value in allowing S=3D0 (with no TAC elements) in the TLV - which could indicate wildcard disaable for all such T-Apps. Section 7.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Use case LDPoTE + rLFA session: Not sure practicality of this use case because if u have TE tunnel terminating on remote [PQ] node, that node typically becomes your local LFA peer and not a remote/PQ LFA peer. Section 9: IANA =3D=3D=3D=3D=3D=3D=3D=3D=3D - The new registry for TA-type has range of 0-65535 though TA-ID that can be specified in the signaling is Only 8 bits. Should the range for this type not be 0-255. =20 Rgds, =8B Kamran Raza skraza@cisco.com Phone: +1 613 254 4520 Cisco.com From nobody Mon Aug 4 09:17:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5CE1A037A; Mon, 4 Aug 2014 09:17:17 -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] 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 utaOGPuSZ6Oq; Mon, 4 Aug 2014 09:17:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 717411A0359; Mon, 4 Aug 2014 09:17:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804161715.25485.78387.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 09:17:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UMN6lf2n6Xj9dxsE6VB_cQKKVak Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-ttl-tlv-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:17:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definition of Time-to-Live TLV for LSP-Ping Mechanisms Authors : Sami Boutros Siva Sivabalan George Swallow Shaleen Saxena Vishwas Manral Sam Aldrin Filename : draft-ietf-mpls-lsp-ping-ttl-tlv-09.txt Pages : 8 Date : 2014-08-04 Abstract: LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) and/or bidirectional co-routed LSP from any node on the path of the MS-PW and/or bidirectional co-routed LSP. This document defines a TLV to address this shortcoming. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ttl-tlv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-ttl-tlv-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-ttl-tlv-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 4 09:18:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41AE1B2B5B for ; Mon, 4 Aug 2014 09:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 dLQ98qPIES6F for ; Mon, 4 Aug 2014 09:18:34 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34561B2B8F for ; Mon, 4 Aug 2014 09:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1173; q=dns/txt; s=iport; t=1407169107; x=1408378707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VSnz4QIT3pHpw7Fem2tNJ+4t11uQC9yOm8QOWpKsl9g=; b=lbYncO2sQVf76CcU180xqCALbgj/icXtknW3bGk+JDKhRLEeG017vnZu cSO+NO5R0965Q+oCVIDHHf0I3X2Gj1oG9JE+V/9oCJ3ffjWhaPkEo71sW EHv8FBwR9xjJyPOihuiBcXhtlu4mlA3CdBxLp1A4L0quM+aqJYrO/PZpj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAAuy31OtJV2U/2dsb2JhbABbgw1SVwTMKgqHSgGBERZ3hAMBAQEDAQEBAWgDCwUJAgIBCBIGIwsbDAsXDgIEDgWIOggNxRoTBASOZhEBHTMHgy+BHAWKVZExlF+CB4FGbIENOQ X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="341869523" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 04 Aug 2014 16:18:26 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s74GIQuG024413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 16:18:26 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 11:18:25 -0500 From: "Sami Boutros (sboutros)" To: Loa Andersson Thread-Topic: [mpls] Request for Early allocation from LSP Parameters TLVs Registry for draft-ietf-mpls-lsp-ping-ttl-tlv Thread-Index: AQHPrR6bGn0bFnUfZ02B+UUe+jKiX5u75bEAgAUTUQA= Date: Mon, 4 Aug 2014 16:18:24 +0000 Message-ID: <3B7D6AB6-DD03-434D-A755-1CDA9BF20BEC@cisco.com> References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <001201cface4$33eaf1b0$9bc0d510$@olddog.co.uk> <40746B2300A8FC4AB04EE722A593182B76F4F63A@ONWVEXCHMB04.ciena.com> <003e01cface9$d1783ff0$7468bfd0$@olddog.co.uk> <96A58928-2B10-48FC-B627-A73D6C959B93@cisco.com> <53DB705E.2000508@pi.nu> In-Reply-To: <53DB705E.2000508@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.247] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mpmpiW-DoBA2jpOOyOsvpzOJsDc Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" Subject: Re: [mpls] Request for Early allocation from LSP Parameters TLVs Registry for draft-ietf-mpls-lsp-ping-ttl-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:18:39 -0000 Just submitted version 09 with the value requested. Thanks, Sami On Aug 1, 2014, at 3:47 AM, Loa Andersson wrote: > Sami, >=20 > After consulting with Adrian, we have agreed that the easiest way > forward is for this time only and under the directive from > the responsible AD and document shepherd you should post a new version > of the draft can put the code point you want in the IANA section. >=20 > /Loa >=20 >=20 > On 2014-08-01 02:21, Sami Boutros (sboutros) wrote: >> Hi, >>=20 >> IANA is requested to assign TLV type value to the following TLV from the= "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (L= SPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry. >>=20 >> The value requested is 32769. >>=20 >> Thanks, >>=20 >> Sami >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Aug 5 03:56:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2391B2951; Tue, 5 Aug 2014 03:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 Rako0jRyObZ7; Tue, 5 Aug 2014 03:56:38 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820001B2949; Tue, 5 Aug 2014 03:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=77147; q=dns/txt; s=iport; t=1407236193; x=1408445793; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uUWtCVdFp0m1LcucDwNkBmPFfMoE6tMl4GXjl/OSTGw=; b=DtGmlUg3tuAYIxtFwl8MVDPf8t/9mVg7KoENuaPwBavm2Cnx0B9mEb7M S7tb1jcibGKUJbNzPvth66reMRl58nEIbyK4i492HzIRkRoDwhcAQIvqs N436Fj8dtHH64g+mHGvtWIfPvqhhLDGYJYWFh/RMa/ucBv1pWK4NRutkL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgEAG+34FOtJssW/2dsb2JhbABSCYNfV4J4yHQKh0oBgSp3hAMBAQEDAQEBARcBAgYEES8GAQoBBQcECw4DAQMBAQECAgUWCAMCAgkDAgECARUfAwYIBgEMAQUCAQEXiB8IDawFhn+QIheBLIhThGIQAwEkER0FBwaCc4FSAQSGCZFUhCyHI408g05rAYEDAQEeBAI X-IronPort-AV: E=Sophos;i="5.01,804,1400025600"; d="scan'208";a="128958708" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 05 Aug 2014 10:56:28 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s75AuRt3020736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2014 10:56:27 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s75AuQkf010009; Tue, 5 Aug 2014 11:56:26 +0100 (BST) Message-ID: <53E0B85B.8060707@cisco.com> Date: Tue, 05 Aug 2014 11:56:27 +0100 From: Stewart Bryant 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: Yimin Shen , pwe3 , "pwe3-chairs@tools.ietf.org" References: <53D7B569.60400@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6IDs2BZHpSVR4B9QINayP6iwAWs Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 10:56:48 -0000 On 30/07/2014 20:07, Yimin Shen wrote: > Hi Stewart, > > Thanks very much for the detailed review and comments. I'd like to highlight a few things below about this draft, and then respond to your comments inline. Hope you could give the draft another closer look. Yimin, Having read your reply and having looked at the text again, and talked to a few folks I think I now understand the top level view of what is proposed. However that is in itself an indication that the draft needs considerable work before publication. Note that it was not initially obvious that you supported both LDP and RSVP-TE PSNs, nor was it initially obvious that you were using the PSN to protect the PWs and not looking further down the stack. Indeed I think there is some text in the draft that positively leads you in that direction since someone else picked it it during an MPLS review. To summarize: what you are doing is construct repairs at the PSN layer that map to each combination of PW + PW repair, which I think multiples the number of PSN tunnels by three times the dispersion factor where the dispersion factor is some factor defining the average number of PEs that the PWs addressed to a single PE need to be dispersed to. This leads to two questions that the WG needs to think about: 1) This is trading increased PSN state for response time. Given that PSN state was a critical factor in the choice of the Martini design over the CCC design this needs to be made clear up front in the text and the WG needs to decide that this is acceptable. 2) This increased state and the complexity of introducing context labels and protection routers to the PWE3 architecture is directly traceable to the need to do xPE node protection, and is not required for link protection including the egress AC. This desire to build the design around node protection (which always adds significant complexity to FRR) is in contrast to the IPFRR situation where link protection is of overwhelming importance and node protection seems to be of secondary importance. An alternative design, which would require less change to the existing PWE3 design would be to provide redundant connection to the xPEs and allow FRR link protection in the PSN to deal with link failures and then to protect the egress AC by making the T-PE a special type of S-PE that preferred to act as a T-PE but if the AC was down forwarded to an alternate T-PE for that PW. If the WG prefers to introduce the cross layer scheme you have proposed, then fine, we need to do the full set of updates needed. However first I think that we need to have rough consensus that the use cases and requirements justify the increased complexity compared of node protection compared to the alternative of providing link and AC protection. > > [1] This draft is completely based on the PWE3 and the MS-PW architecture. It is also based on RFC 5331 " MPLS Upstream Label Assignment and Context-Specific Label Space". So ideally readers should be familiar with that RFC. As far as I can see context labels have not been introduced into the PWE3 architecture. There is some reference to their use for P2MP PWs, but not in the P2P case. Indeed I think that RFC4447 notes explicitly that in the case where the configuration of PWs is signaled by LDP the platform label space must be used. The least that you need to do is to update RFC4447. Something that I noticed in a second pass through the text is that you seem to have changed the PW FEC data structure from the one specified by PWE3 to a variant of one used in LSP Ping. This seems unnecessary and may lead to confusion and difficulty if these get changed at some time in the future. A better design is surely to leave the PWE3 signalling system completely unchanged except to add an additional TLV specifying the context information if indeed we continue on that path. Apropos this, it may be the way that the document was written, but I did not see anything about the need to signal the PW interface parameters to the alternative PE. Also I did not see anything specifying the error handling as a result of parameter issues. A comment below that was not picked up is that the signalling design supports IPv4 only, and as I recall there is an IESG policy of not standardizing any IPv4 only solutions, so perhaps we should introduce IPv6 at the same time as harmonizing the normal and context label data structures. The LDP signalling of PWs with context labels need a more complete review for both completeness and correctness and to ensure that this text provides a description that is sufficiently complete that this new feature can be implemented solely from this text and the associated references. > > [2] The draft mentions two important roles of routers, PLR (point of local repair) and protector. You need a clearer definition of a PLR and protector. I think that a protector is a new type of SPE and needs a clearer architectural definition. The concept of a PLR taking action at one layer within the context of another is new in PWE3. Perhaps it is defined in MPLS in which case a reference would be appropriate. > > [3] PLR performs local repair in dataplane, based on pre-installed backup forwarding state pointing to a bypass tunnel. There is no control-plane involvement in local repair. Specifically in the initiation of the local repair, it is in the configuration of course. > This is similar to the existing IP/MPLS fast-reroute mechanisms. Therefore, it can achieve restore traffic with a similar performance to those mechanisms. That is the main goal of this draft. IP/MPLS FRR normally operates solely for the benefit of its own dataplane. You have this configured to act for the benefit of the client dataplane. > > [4] When doing local repair, the PLR only swaps the top label (i.e. tunnel label) to a bypass tunnel's label, and keeps the PW label (allocated by primary/protected PE) intact. The PLR doesn't need to know or understand the PW label. Indeed this is clearer now, and needs to be made much clearer in the text. However so do the implications for the system as a whole of this mode of operation. > > [5] The protector is the router at the other end of the bypass tunnel. It is responsible for forwarding the traffic further, so that the traffic can eventually reach the target CE. The protector must understand the PW label allocated by the primary PE. The use of the work primary PE is slightly confusing. Presumably you mean the ingress PE of the segment rather than the ingress PE from the point of view of the ingress AC. > This is achieved by using the context label forwarding paradigm specified in RFC 5331. This draft defines some LDP extensions to allow the primary PE to advertise PW labels to the protector. The protector locally maintains a label space for these PW labels of the protected PE, and looks up the PW label in this label space. The bypass tunnel serves as the pointer to this label space. Now I understand that. Please make this much clearer earlier in the text. Note my earlier concern about the design of those extensions. > > [6] This draft also introduces the concept of "context ID". A context ID is an IP address identifying a pair of . The use of an IP address rather than some identifier taken from the PW context is a design assumption not properly shared with the reader and needs to be clarified in the text. > It serves as the destination of transport tunnel. PWs carried by the tunnel will be redirected to the protector X during local repair. PWs to the same primary PE but protected by a different protector Y cannot be carried by this tunnel. Rather, they must be carried by a tunnel destined for context ID of . Indeed, but that needs to be made clearer, particularly as this seemingly has scaling consequences. > > [7] A PLR may be any router in the network, including P or PE router. The draft assumes that it doesn't know or care about PW info. > > [8] A protector is a PE router Within a PE context I am not sure that the properties of a PE router are defined. > in the "co-located" model. It may be a P router in the "centralized" model. For the later case, the draft describes how to use the new LDP extensions for the protector to learn and assoicate primary PW and backup PW and install forwarding entries in the context label table. So when you run the centralized protector, how does the PW parameter signaling and interface parameter verification work? Surely the centralized protector needs to be some form of PE rather than a variant of an MPLS P router? I have a bunch of comments on your answer below, put perhaps we can start by working through the comments above and the cycle back to the comments below within the resultant context. I will comment on our exchange below when we have reached some level of consensus on the preamble. Given the concerns that I have raised and those raised by Sasha I think that the chairs need consider taking this back to the WG for further work. - Stewart > > Thanks, > > /Yimin > > > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Tuesday, July 29, 2014 10:53 AM > To: pwe3; pwe3-chairs@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 > > > > I do not support the publication of this draft without: > > 1) An assurance that MPLS WG has reviewed it and is happy > with the extensions that seem to be made to the MPLS architecture > > 2) A formal description of those extensions or a pointer > to those extensions in another RFC. > > 3) Significant clarification of how the detail of this > mechanism works. > > For this to work you need to have co-ordinated label spaces > in multiple PEs which is something that was investigated > by the SPRING WG and found not to work, particularly when > different manufacturers equipments were involved. > > [yshen] This draft does not rely on label space coordination. Rather, it is based on context label forwarding paradigm specified in RFC 5331. > > > As far as I can see you also need to peek below the top > of stack to do a fast reroute operation which is not > a currently defined MPLS operation. > > There seem to be a lot of details and clarifications missing > that need to be provided, and I am not entirely convinced > that all of the items declared out of scope are legitimately > out of scope and not needed in order for a multi-vendor > solution to be implemented. > > It would be useful to me (and I suspect to other readers) > to see what the dataplane looks like at various points > in the normal and repair path to verify that all parties > have the right information for this to work under normal > and various fault conditions. > > I have a number of comments inline that need to be addressed > before this can proceed. > > > - Stewart > > > PW Endpoint Fast Failure Protection > draft-ietf-pwe3-endpoint-fast-protection-01 > > Abstract > > This document specifies a fast mechanism for protecting pseudowires > against egress endpoint failures, including egress attachment circuit > failure, egress PE failure, multi-segment PW terminating PE failure, > and multi-segment PW switching PE failure. Designed on the basis of > multi-homed CE, PW redundancy, upstream label assignment and context > specific label switching, the mechanism enables local repair to be > performed by the router upstream adjacent to a failure. > > In > particular, the router can restore PW traffic in the order of tens of > milliseconds, > > SB> Not sure it's wise to specify a performance claim in a standards > SB> track RFC. > > [yshen] If this is viewed as inappropriate, we can remove it. > > by transmitting the traffic to a protector through a > pre-established bypass tunnel. Therefore, the mechanism can reduce > traffic loss before global repair reacts to the failure and the > network converges on the topology changes due to the failure. > > > > === > > > 1. Introduction > > Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segment > can be thought of as a connection between a pair of forwarders hosted > by two PEs, carrying an emulated layer-2 service over a packet > switched network (PSN). In the single-segment PW (SS-PW) case, a > forwarder binds a PW to an attachment circuit (AC). In the multi- > segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds > a PW segment to an AC, while a forwarder on a switching PE (S-PE) > binds one PW segment to another PW segment. In each direction > between the PEs, PW packets are transported by a PSN tunnel, which is > called a transport tunnel. > > SB> Did we ever your the term transport tunnel before? > > [yshen] This is mainly for clarity. We could change it to " which is > called a transport tunnel *in this document*". Or we can completely replace "transport tunnel" with just "tunnel". > > 3. Reference Models and Failure Cases > > The mechanism in this document intends to > use these topologies for local repair purposes. > > SB> The toplology is not a mechanism. Are you saying that the mechanims > SB> only works in this topology? > > [yshen] No, these topologies are only examples for use by subsequent sections to describe the mechanisms. The mechanisms should equally work for other topologies as well. > > This SHALL enable > local repair and global repair to work in tandem to achieve broader > coverage of protection for services. > > SB> I have no idea how a SHALL in capitals applies here. > > [yshen] Will fix this. > > 3.1. Single-Segment PW > > > > |<-------------- PW1 --------------->| > > - PE1 -------------- P1 ---------------- PE2 - > / \ > / \ > CE1 CE2 > \ / > \ / > - PE3 -------------- P2 ---------------- PE4 - > > |<-------------- PW2 --------------->| > > Figure 1 > > > Each CE is multi-homed to two PEs. Hence, there are two divergent > paths between the CEs. > > SB> It does not follow that the paths are divergent! Who knows > SB> what happens in the IP layer and the underlying transport > SB> network. > > > [yshen] We could rephrase this and remove "divergent". All we want to say here is that there are two distinct sets of AC-PW-AC between the CEs. > > At any given time, each CE sends traffic via only one AC and receives > traffic via only one AC. The two ACs MAY or MAY NOT be the same. > > SB> May not be the same what? If they are actually the same AC you > SB> have no redundancy. > > [yshen] Will rephrase it. All we want to say is that at a given time, the CE may send traffic over one AC and receive traffic over another AC. > > The AC used to send traffic is determined by the CE, and MAY rely on > an end-to-end OAM mechanism between the CEs. The AC used for the CE > to receive traffic is determined by the state of the network and the > protection mechanism in use, as described later in this document. > > From the perspective of traffic flowing towards a given CE, the set > of PWs, PEs and ACs involved can be viewed to serve primary and > backup (or active and standby) roles. When the network is in a > steady state, the PW that is intended to carry the traffic is > referred to as a primary PW. The PE at the egress of the primary PW > is a primary PE. The AC connecting the CE and the primary PE is a > primary AC. The other PW may be used to carry the traffic upon a > network failure, and is referred to as a backup PW. The PE at the > egress of the backup PW is a backup PE. The AC connecting the CE and > the backup PE is a backup AC. > > In this document, the following primary and backup roles are assigned > for the traffic going from CE1 to CE2: > > Primary PW: PW1 > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 5] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > Primary PE: PE2 > > Primary AC: CE2-PE2 > > Backup PW: PW2 > > Backup PE: PE4 > > Backup AC: CE2-PE4 > > In this case, an egress AC failure refers to the failure of the AC > CE2-PE2. An egress node failure refers to the failure of PE2. > > The backup PE, backup PW and backup AC may be used to carry traffic > after a PW endpoint failure, when CE1 and CE2 switches traffic to PW2 > in local repair or global repair, as described later in this > document. > > |<-------------- PW1 --------------->| > > ------------- P1 ---------------- PE2 - > / \ > / \ > CE1 -- PE1 CE2 > \ / > \ / > ------------- P2 ---------------- PE4 - > > |<-------------- PW2 --------------->| > > Figure 2 > > Figure 2 shows another possible scenario, where CE1 is single-homed > to PE1, while CE2 remains multi-homed to PE2 and PE4. From the > perspective of egress protection for the traffic from CE1 to CE2, > this topology is not much different than Figure 1. However, for the > > SB> "not much different than Figure 1" is not helpful, either it is the > same, or you need to explain the difference. > > [yshen] Will rephrase. The difference is actually described after "However...". > > > traffic in the direction from CE2 to CE1, PE1 must anticipate traffic > on both PW1 and PW2, and sends it to CE1 over the AC CE1-PE1. > > SB> What does it mean to anticipate traffic. > > [yshen] To anticipate incoming traffic over either PW1 or PW2. Will rephrase. > > 3.2. Multi-Segment PW > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 6] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > |<--------------- PW1 --------------->| > |<----- SEG1 ----->|<----- SEG2 ----->| > > - TPE1 -------------- SPE1 --------------- TPE2 - > / \ > / \ > CE1 CE2 > \ / > \ / > - TPE3 -------------- SPE2 --------------- TPE4 - > > |<----- SEG3 ----->|<----- SEG4 ----->| > |<--------------- PW2 --------------->| > > Figure 3 > > Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW > environment. PW1 and PW2 are both MS-PWs. PW1 is established > between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at > SPE1. PW2 is established between TPE3 and TPE4, and switched between > segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TPE3. > CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the PW > segments are not shown in this figure for clarity. > > In this document, the following primary and backup roles are assigned > for the traffic going from CE1 to CE2: > > Primary PW: PW1 > > Primary T-PE: TPE2 > > Primary S-PE: SPE1 > > Primary AC: CE2-TPE2 > > Backup PW: PW2 > > Backup T-PE: TPE4 > > Backup S-PE: SPE2 > > Backup AC: CE2-TPE4 > > In this case, an egress AC failure refers to the failure of the AC > CE2-TPE2. An egress node failure refers to the failure of TPE2. An > S-PE failure refers to the failure of SPE1. > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 7] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > The backup T-PE, backup PW and backup AC are used for protecting the > primary PW against egress AC failure and egress node failure. The > backup S-PE and the backup PW are used for protecting the primary PW > against S-PE failure, as described later in this document. > > For consistency with the SS-PW scenario, primary T-PEs and a primary > S-PEs may simply be referred to as primary PEs in this document, > where specifics is not required. Similarly, backup T-PEs and backup > S-PEs may be referred to as backup PEs. > > 4. Theory of Operation > > The fast protection mechanism in this document provides three types > of protection for PWs, corresponding to the three types of failures > described in Section 1. > > a. Egress AC protection > > b. Egress (T-)PE node protection > > c. S-PE node protection > > The mechanism assumes a multi-homed CE with connectivity to a primary > PE and a backup PE, and the existence of a backup PW in the network. > In S-PE node protection, it also assumes the existence of a backup > S-PE on the backup PW. > > > SB> Do the PWs need to be symmetric - could you have more > S-PEs on one that you have on the other? > > [yshen] You could. For a given S-PE, as long as you can find another PE to serve as protector, it will work. > > 4.1. Local Repair and Protector > > The mechanism relies on local repair to be performed by routers > SB> Do you mean routers or PEs? Routers of more likely LSRs > operate at a different layer and have no business knowing about > PWs. > > [yshen] routers (LSRs). Yes, they have no idea about PWs. This draft doesn't assume they know or care about PWs. > > SB> Has this work been reviewed my MPLS WG? I am concerned > that you are doing a bunch of layer violation without explaining > the how this is achieved or whether it is acceptable within the > MPLS architecture. > > [yshen] There is no layer violation. The PLR simply redirect traffic from the original tunnel to a bypass tunnel, by doing a top label swap, without touching, changing or knowing the PW label. Please take a close look at the text. > > upstream adjacent to failures. Each of these routers is referred to > as a "point of local repair" (PLR). A PLR MUST be able to detect a > failure by using a rapid mechanism, such as physical layer failure > detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc. In > anticipation of the failure, the PLR MUST also pre-establish a bypass > PSN tunnel to a "protector", and pre-install a bypass route in the > data plane. The bypass tunnel MUST have the property that it will > not be affected by the topology changes in the event of the failure. > > SB> This is far too imprecise - you need to separate operations and > topologies in the PW layer from operations and topologies in the > PSN layer > > [yshen] Similar to existing IP/MPLS fast-reroute RFCs, this draft doesn't restrict local repair trigger to any specific failure detection mechanisms. Any mechanism will work. > > SB> In each case you need to be clear how you are detecting failure > by specifying the MEPs and MIPs you are testing. > > Upon detecting the failure, the PLR MUST invoke the bypass route in > the data plane, and reroute PW traffic to the protector through the > bypass tunnel. The protector MUST in turn send the traffic to the > target CE. > > SB> No the protector knows nothing about CEs - they are in the client > layer, and you can only protect at the server layer or the server's > server layer. > > [yshen] In collocated model, the protector is a PE. In the centralized model, the protector may be an LSR , and it needs to participate in LDP PW signaling to understand PWs. See the related sections and LDP extensions in this draft. This centralized model is optional. > > This procedure is referred to as local repair. > > Different routers may serve as PLR and protector in different > scenarios. > > SB> Remember they are not routers - they are xPEs or LSRs. > > [yshen] Again, in collocated model, the protector is a PE. In the centralized model, the protector may be an LSR , and it needs to participate in LDP PW signaling to understand PWs. See the related sections and LDP extensions in this draft. But this centralized model is optional. > [yshen] PLRs may be LSRs, but they don't need to know PWs, because all they do is to swap top label (tunnel label) to a bypass tunnel's label. > > SB> In each of the following we need to note that these are > not RFC3985 PEs, even if they take no part in the protection > such as the PEs on the left. Indeed I am wondering if you need > to update RFC3985 and RFC5659 > > [yshen] There is no need to update RFC3985 and RFC5659. > > Yimin Shen, et al. Expires January 25, 2015 [Page 8] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > o In egress AC protection, the PLR is the primary PE that terminates > the primary PW and hosts the primary AC, and the protector is the > backup PE (Figure 4). > > |<-------------- PW1 --------------->| > > - PE1 -------------- P1 ---------------- PE2 - > / PLR \ > / | \ > CE1 bypass| CE2 > \ | / > \ | / > - PE3 -------------- P2 ---------------- PE4 - > protector > > |<-------------- PW2 --------------->| > > Figure 4 > > > o In egress PE node protection, the PLR is the penultimate hop > router of the transport tunnel of the primary PW, and the > protector is the backup PE (Figure 5). > > |<-------------- PW1 --------------->| > > - PE1 -------------- P1 ------- P3 ----- PE2 - > / PLR \ \ > / \ \ > CE1 bypass\ CE2 > \ \ / > \ \ / > - PE3 -------------- P2 ---------------- PE4 - > protector > > |<-------------- PW2 --------------->| > > Figure 5 > > SB> Note that it is nothing like as clean as this, if as you later have, > some of P3's traffic needs to go to PE4 and some to PE5. > Also what about the > > [yshen] Note that we are talking about a single PW, rather than multiple PWs carried by a single tunnel. > > o In S-PE node protection, the PLR is the penultimate hop router of > the transport tunnel of the primary PW segment, and the protector > is the backup S-PE (Figure 6). > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 9] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > |<--------------- PW1 --------------->| > |<----- SEG1 ----->|<----- SEG2 ----->| > > - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - > / PLR \ \ > / \ \ > CE1 bypass\ CE2 > \ \ / > \ \ / > - TPE3 --------------- SPE2 -------------- TPE4 - > protector > > |<----- SEG3 ----->|<----- SEG4 ----->| > |<--------------- PW2 --------------->| > > Figure 6 > > A PLR can realize its role based on configuration or the signaling of > transport tunnel. For example, in the case where the transport > tunnel is signaled by RSVP, the penultimate hop router could realize > > SB> Could realize is not sufficient. The mechanism needs to be > unconditional. > > [yshen] Will rephrase. > > that it is the PLR for egress (T-)PE or S-PE failure based on the RRO > in Resv message, which should indicate that the router is one hop > away from the PE. The detail of how this could be achieved on a per- > protocol basis is out of the scope of this document. > > SB> So where is it in scope? How do I find out how to do it? > > In all scenarios, when a PLR reroutes traffic through a bypass tunnel > to a protector during local repair, it MUST keep the label of the > primary PW intact in the packets. This obviates the need for the PLR > to maintain bypass routes on a per-PW basis, and allows a single > bypass tunnel to carry traffic for multiple PWs. > > SB> OK, but didn't I read something about PE protecting subsets of the > egress traffic of other PEs? How would that work without per PW information? > > [yshen] PWs to a given PE may be protected by multiple protectors. A set of PWs sharing the same protector X can be carried by the same tunnel (destined to the context ID of ). PWs protected by a different protector Y must be carried by different tunnel (destined to the context ID of ). The PLR of each tunnel doesn't need to know PW info. All it does is to swap tunnel label to a bypass tunnel's label, and the bypass tunnel will guide the traffic to the intended protector. > > The procedure also requires that the protector SHOULD be able to > forward the traffic based on a PW label that is assigned by the > primary PE, and ensure the traffic to eventually reach the target CE. > From the protector's perspective, this PW label is an upstream > assigned label (RFC 5331). > > SB> .. but the protector may be a P router and know nothing about > PWs. > > [yshen] Again, in collocated model, the protector is a PE. In the centralized model, the protector may be an LSR , and it needs to participate in LDP PW signaling to understand PWs. See the related sections and LDP extensions in this draft. But this centralized model is optional. > > > To accomplish this, the protector SHOULD > learning the PW label from the primary PE prior to the failure, and > install proper forwarding state for the PW label in a dedicated label > space for the primary PE. > > SB> This is a new PE to P router protocol > > [yshen] The LDP extension is defined in a subsequent section. > > During local repair, the protector SHOULD > perform PW label lookup in this label space. > > SB> This has to be signed off by MPLS WG > SB> How can this only be a SHOULD - why is it not a MUST? > > [yshen] Will rephrase. > > SB> What do you do to ensure that they even have compatible label managers? > > [yshen] The LDP extensions defined in this draft covers how to negotiate the capability. > > > SB> Doesn't this mean a P router looking up two labels to do > the repair? > > [yshen] PLR only swaps the top label (i.e. tunnel label) to bypass label table, when doing the local repair. > > The above examples have shown the scenarios where the protectors are > backup (T/S-)PEs. In other scenarios, a protector may be a dedicated > router that assumes such role, separate from the backup (T/S-)PE of a > primary PW. During local repair, the PLR MUST still reroute traffic > to the protector through a bypass tunnel. The protector MUST in turn > send the traffic to the backup (T/S-)PE, which MUST then send the > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 10] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > traffic to the target CE via a backup AC or a backup PW segment. > More detail will be described in Section 4.3. > > 4.2. Context Identifier > > A protector MAY protect multiple primary PEs. > > SB> This requires that a P router knows about PWs - how does > it do that? > > [yshen] The protector will perform context label forwarding. The bypass tunnel points to a context label table, and the protector looks up the PW label in that table. > > The protector MUST > maintain a separate label space for each primary PE. Likewise, the > PWs terminated on a primary PE MAY be protected by multiple > protectors, each for a subset of the PWs. In any case, a given > primary PW SHOULD be associated with one and only one pair of > {primary PE, protector}. > > An IPv4/v6 address is assigned to each ordered pair of {primary PE, > protector} to facilitate protection establishment. This address is > referred to as a "context identifier". It MUST be globally unique, > or unique in the address space of the network where the primary PE > and the protector reside. > > SB> I think you need to make clear that this is not backwards compatible > with existing PW PEs. > > [yshen] PEs will need to support the extensions defined by this draft. > > SB> You also need to explain how the IP based context identifier > mechanism works. Is it in the control plane or the data plane? > > 4.2.1. Semantics > > The semantics of a context identifier is twofold. > > o It identifies a primary PE and an associated protector. In other > words, it identifies a primary PE on a per protector basis. A > given primary PE may be protected by multiple protectors, each for > a subset of the primary PWs terminated on the primary PE. A > distinct context identifier MUST be assigned to the primary PE and > each protector. > > For each primary PW, its ingress PE MUST set up or resolve a > transport tunnel with destination as the context identifier of the > {primary PE, protector}, rather than a private IP address of the > primary PE. This not only allows the transport tunnel to reach > the primary PE, but also conveys the identity of the protector to > the PLR(s) along the transport tunnel. Each PLR can in turn use > this information to set up a bypass tunnel to the protector > without relying on local configuration. > > o It indentifies the primary PE's label space on the protector. The > protector may protect PWs for multiple primary PEs. For each > primary PE, it MUST maintain a separate label space to store the > PW labels assigned by that primary PE. It MUST associate a PW > label with a label space via the context identifier of the > {primary PE, protector}, as described below. > > SB> Is this context identifier an IP address or an MPLS label? Where > is it carried? > > [yshen] a context identifier is an IP address. If the tunnel is IP tunnel, it is carried in IP header as dest address. If the tunnel is MPLS tunnel, it is indicated by the label. > > In addition to the normal LDP PW signaling, the primary PE MUST > have a targeted LDP session with the protector, and advertise PW > labels to the protector via LDP Label Mapping messages (See > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 11] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > Section 5 for detail). The primary PE MUST attach the context > identifier to each message. Upon receiving the message, the > protector MUST install the advertised PW label in the label space > identified by the context identifier. > > SB> I am currently confused about how a data packet carries the PW > label provided by another PE. > > When a PLR sets up or resolve a bypass tunnel to the protector, it > MUST set the destination to the context identifier, rather than a > private IP address of the protector. Once established, the bypass > tunnel, with either its MPLS label or IP tunnel destination > address, is used as the identifier of label space. On the > protector, all PW packets received on the bypass tunnel MUST be > forwarded based on a label lookup in that label space. > > SB> I do not understand the data plane structure that the above sentence > is describing. > > [yshen] This is basically the context label forwarding paradigm (RFC 5331). From the protector's perspective, the bypass tunnel serves as a context, and indicates the label space of the primary PE where the PW label must be looked up. > > > 4.2.2. Advertisement and Path Computation > > Using a context identifier as destination for both transport tunnel > and bypass tunnel requires both the primary PE and the protector to > advertise the context identifier via IGP as an IP address reachable > through both routers in routing domain and/or TE domain. This > imposes the following requirements on path computation for these > tunnels. > > o For the transport tunnel, the ingress PE MUST choose the primary > PE as the actual endpoint. > > o For the bypass tunnel, the PLR MUST choose the protector as the > actual endpoint. In egress (T-)PE node protection and S-PE node > protection, the bypass tunnel MUST avoid the primary (S-)PE. > > The detail of how the primary PE and the protector may advertise a > context identifier is independent of this mechanism and out of the > scope of this document. > > SB> Given that you give signalling data structures later, I am confused > as to how this can be out of scope of this text. Surely this is needed > to implement an interoperable solution? > > [yshen] There is no new extension needed for IGP. Both PEs advertise the context ID. That's it. Will rephrase it. > > One approach would be to advertise it as a > virtual proxy node connected to both routers, with the link between > the proxy node and the primary PE having a more preferable IGP or TE > metric than the link between the proxy node and the protector. The > ultimate goal is for a path computation algorithm, such as CSPF > (constrained shortest path first), LFA (RFC 5286) and MRT ([IP-LDP- > FRR-MRT]), to be able to compute the paths that meet the above > requirements. > > 4.3. Protection Models > > There are two protection models based on the location of a protector. > A network MAY use either model, or a combination of both. > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 12] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > 4.3.1. Co-located Protector > > In this model, the protector is a backup PE that is directly > connected to the target CE via a backup AC, or it is a backup S-PE on > a backup PW. That is, the protector is co-located with the backup > (S-)PE. Examples of this model have been introduced in Figure 4, > Figure 5 and Figure 6 in Section 4.1. > > In egress AC protection and egress PE node protection, when a > protector receives traffic from the PLR, it forwards the traffic to > the CE via the backup AC. This is shown in Figure 7, where PE2 is > the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 > (the backup PE) is the protector. > > |<-------------- PW1 --------------->| > > - PE1 -------------- P1 ------- P3 ----- PE2 ---- > / PLR \ PLR \ > / \ | \ > CE1 bypass\ |bypass CE2 > \ \ | / > \ \ | / > - PE3 -------------- P2 ---------------- PE4 ---- > protector > > |<-------------- PW2 --------------->| > > Figure 7 > > In S-PE node protection, when a protector receives traffic from the > PLR, it MUST forward the traffic via the next segment of the backup > PW. The T-PE of the backup PW MUST in turn forward the traffic to > the CE via a backup AC. This is shown in Figure 8, where P4 is the > PLR for SPE1 failure, and SPE2 (the backup S-PE) is the protector for > SPE1. > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 13] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > |<--------------- PW1 --------------->| > |<----- SEG1 ----->|<----- SEG2 ----->| > > - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - > / PLR \ \ > / \ \ > CE1 bypass\ CE2 > \ \ / > \ \ / > - TPE3 --------------- SPE2 -------------- TPE4 - > protector > > |<----- SEG3 ----->|<----- SEG4 ----->| > |<--------------- PW2 --------------->| > > Figure 8 > > In the co-located protector model, the number of context identifiers > needed by a network is the number of distinct {primary PE, backup PE} > pairs. From the perspective of scalability, the model is suitable > for networks where the number of backup PEs for any given primary PE > is relatively small. > > 4.3.2. Centralized Protector > > In this model, the protector is a dedicated P router or PE router > that serves the role. In egress AC protection and egress PE node > protection, the protector MAY or MAY NOT be a backup PE with a direct > connection to the target CE. In S-PE node protection, the protector > MAY or MAY NOT be a backup S-PE on the backup PW. > > In egress AC protection and egress PE node protection, when the > protector receives traffic from the PLR, if the protector has a > direct connection (i.e. backup AC) to the CE, it MUST forward the > traffic to the CE via the backup AC, which is similar to Figure 7. > Otherwise, it MUST forward the traffic to a backup PE, which MUST > then forward the traffic to the CE via a backup AC. This is shown in > Figure 9, where the protector receives traffic from P3 (the PLR for > egress PE failure) or PE2 (the PLR for egress AC failure) and > forwards the traffic to PE4 (the backup PE). The protector may be > protecting other PWs as well, which is not shown in this figure for > clarity. > > SB> If you are going to cover the shared case, I think you need to > make it much clearer how the PWs are identified from the received > data packets. > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 14] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > |<------------- PW1 --------------->| > > - PE1 ------------- P1 ------- P3 ----- PE2 -- > / PLR \ PLR \ > / \ / \ > / bypass\ /bypass \ > / \ / \ > CE1 protector CE2 > \ \ / > \ \ / > \ \ / > \ \ / > - PE3 ------------- P2 -----------------PE4 -- > > |<------------- PW2 --------------->| > > Figure 9 > > In S-PE node protection, when the protector receives traffic from the > PLR, if the protector is a backup S-PE of the backup PW, it MUST > forward the traffic via the next segment of the backup PW, and the > T-PE of the backup PW MUST forward the traffic to the CE via a backup > AC, which is similar to Figure 8. Otherwise, the protector MUST > first forward the traffic to the backup S-PE, which MUST then forward > the traffic via the next segment of the backup PW. Finally, the T-PE > of the backup PW MUST forward the traffic to the CE via a backup AC. > This is shown in Figure 10, where the protector forwards traffic to > SPE2 (the backup S-PE), SPE2 forwards the traffic to TPE4 via SEG4, > and TPE4 finally forwards traffic to CE2. The protector may be > protecting other PW segments as well, which is not shown in this > figure for clarity. > > > > > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 15] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > |<--------------- PW1 --------------->| > |<----- SEG1 ----->|<----- SEG2 ----->| > > - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - > / PLR \ \ > / \ \ > / bypass\ \ > / \ \ > CE1 protector CE2 > \ \ / > \ \ / > \ \ / > \ \ / > - TPE3 --------------- SPE2 -------------- TPE4 - > > |<----- SEG3 ----->|<----- SEG4 ----->| > |<--------------- PW2 --------------->| > > Figure 10 > > The centralized protector model provides the convenience for multiple > primary PEs to share one protector. Each primary PE MAY only need > the one protector to protect all of its PWs. From the perspective of > scalability, the number of context identifiers needed by a network > MAY be bound to the number of primary PEs. > > 4.4. Transport Tunnel > > The ingress PE of a primary PW associates the PW with the primary > egress PE through LDP signaling. In addition, as mentioned in > Section 4.2.1, the ingress PE MUST associate the transport tunnel of > the PW with the context identifier of the {primary PE, protector}, > and set up or resolve the transport tunnel by using the context > identifier as destination. This not only ensures that PW traffic be > transported to the primary PE, but also facilitates bypass tunnel > establishment at PLR(s), as the context identifier implies the > identity of the protector as well. This is also the case for a > multi-segment PW, where the ingress PE and egress PE are T/S-PEs. > > The association between the transport tunnel and the context > identifier at the ingress PE MAY be achieved by configuration or an > auto-discovery mechanism. In the later case, the ingress PE MAY > learn the context identifier from the primary (egress) PE, if the > primary PE advertises the context identifier as "third party next > hop" in IPv4/v6 Interface_ID (RFC 3471, RFC 3472) in the LDP > Label Mapping message of the primary PW. > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 16] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > 4.5. Bypass Tunnel > > A PLR may protect multiple PWs associated with one or multiple pairs > of {primary PE, protector}. The PLR MUST establish a bypass tunnel to > each protector for each distinct context identifier associated with > that protector. The destination of the bypass tunnel MUST be the > context identifier (Section 4.2.1). The PLR may derive the context > identifier from the destination of the transport tunnel that > traverses it. > > For examples, in Figure 7 and Figure 9, a bypass tunnel is > established from PE2 (PLR for egress AC failure) to the protector, > and another bypass tunnel is established from P3 (PLR for egress node > failure) to the protector. In Figure 8 and Figure 10, a bypass > tunnel is established from P4 (PLR for S-PE failure) to the > protector. > > During local repair, the PLR reroutes traffic to the protector > through a bypass tunnel with PW label intact in the packets. This > normally involves pushing a label to the label stack, if the bypass > tunnel is an MPLS tunnel, or pushing an IP header to the packets, if > the bypass tunnel is an IP tunnel. > > SB> Surely it is normally a swap? > > [yshen] yes, this is just a label swap of the top label, from tunnel label to bypass tunnel label. > > SB> I am somewhat confused about what this all looks like when this is > IP. The only PS/IP other than for SATOP are defined by L2TPv3 WG. > There is no IP MS-PW definition that I am aware of. I think you need > to be much clearer about what is going on when you discuss PW over IP > egress repair. > > The protector MUST in turn > forward the traffic based on the PW label. To achieve such kind of > forwarding, the protector MUST rely on the bypass tunnel as a context > to determine the primary PE's label space. If the bypass tunnel is > an MPLS tunnel, the protector MUST have assigned a non-reserved label > to the bypass tunnel during the establishment of the bypass tunnel, > and hence this label can serve as the context. If the bypass tunnel > is an IP tunnel, the protector can simply rely on the context > identifier carried as the destination address in IP header. > > A bypass tunnel MUST have the property that it is not affected by the > topology changes caused by the failure. Therefore, it can be used to > transmit traffic for local repair. It SHOULD remain effective, until > the traffic is moved to another fully functional egress AC, PW and/or > transport tunnel. > > 4.6. Forwarding State on Protector > > A protector MUST learn PW labels from all the primary PEs that it > protects (Section 5.2), and maintain the PW labels in respective > label spaces of the primary PEs. In the control plane, a label space > is identified by the context identifier of a pair of {primary PE, > protector}. In the forwarding plane, it is indicated by the bypass > tunnel(s) destined for the context identifier. > > SB> Are you saying that this mechanism mandates no PHP? > > [yshen] It mandates PHP for bypass tunnels only, as their labels serve as contexts on protectors. This is not mandatory for normal tunnels. > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 17] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > 4.6.1. Examples of Co-located Protector > > In Figure 7, PE4 is a co-located protector that protects PW1 against > egress AC failure and egress node failure. It maintains a label > space for PE2, which is identified by the context identifier of {PE2, > PE4}. It learns PW1's label from PE2, and installs an forwarding > entry for the label in that label space. The nexthop of the > forwarding entry indicates a label pop with outgoing interface > pointing to the backup AC CE2-PE4. > > SB> I am not sure what you are describing in the above. Is this an > MPLS operation or a PW operation. If the latter it is not a simple > label pop. > > [yshen] It is PW label pop. > > In Figure 8, SPE2 is a co-located protector that protects PW1 against > S-PE failure. It maintains a label space for SPE1, which is > identified by the context identifier of {SPE1, SPE2}. It learns > SEG1's label from SPE1, and installs a forwarding entry in the label > space. The nexthop of the forwarding entry indicates a label swap to > SEG4's label. > > 4.6.2. Examples of Centralized Protector > > In the centralized protector model, for each primary PW of which the > protector is not a backup (S-)PE, the protector MUST also learn the > label of the backup PW from the backup (S-)PE (Section 5.3). This is > the backup (S-)PE that the protector will forward traffic to. The > protector MUST install a forwarding entry with label swap from the > primary PW's label to the backup PW's label. > > In Figure 9, the protector is a centralized protector that protects > PW1 against egress AC failure and egress node failure. It maintains > a label space for PE2, which is identified by the context identifier > of {PE2, protector}. It learns PW1's label from PE2, and PW2's label > from PE4. It installs a forwarding entry for PW1's label in the > label space. The nexthop of the forwarding entry indicates a label > swap to PW2's label. > > In Figure 10, the protector is a centralized protector that protects > the PW segment SEG1 of PW1 against the node failure of SPE1. It > maintains a label space for SPE1, which is identified by the context > identifier of {SPE1, protector}. It learns SEG1's label from SPE1, > and learns SEG3's label from SPE2. It installs a forwarding entry > for SEG1's label in the label space. The nexthop of the forwarding > entry indicates a label swap to SEG3's label. > > 5. LDP Extensions > > As described in previous sections, a targeted LDP session MUST be > established between each pair of primary PE and protector. The > primary PE sends Label Mapping message over this session to advertise > primary PW labels to the protector. In the centralized protector > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 18] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > model, a targeted LDP session MUST also be established between a > backup (S-)PE and a protector. The backup PE sends Label Mapping > message over this session to advertise backup PW labels to the > protector. > > To facilitate the procedures, this document defines a new "Protection > FEC Element" TLV. The Label Mapping messages of both the LDP > sessions above MUST carry this TLV to indicate the identity of a > primary PW. Specifically, in the centralized protector model, the > Protection FEC Element TLV advertised by a backup (S-)PE MUST match > the one advertised by the primary PE, so that the protector can > associate the primary PW's label with the backup PW's label, and > perform a label swap. > > This document also defines the encoding of Capability Parameter TLV > (RFC 5561) for a new "Egress Protection Capability", to allow a > protector to announce its capability of processing the above > Protection FEC Element TLV and performing context specific label > switching for PW labels. > > The procedures in this section are only applicable, if the protector > advertises the Egress Protection Capability, the primary PE supports > the advertisement of the Protection FEC Element TLV, and in the > centralized protector model, the backup PE also supports the > advertisement of the Protection FEC Element TLV. > > 5.1. Egress Protection Capability TLV > > A protector MUST advertise the Egress Protection Capability TLV in > its Initialization message and Capability message, over the LDP > session with a primary PE. In the centralized protector model, the > protector MUST also advertise the TLV over the LDP session with a > backup PE. The TLV carries one or multiple context identifiers. To > the primary PE, the TLV SHOULD carry the context identifier of the > {primary PE, protector}. In the centralized protector model, the TLV > SHOULD carry to the backup PE multiple context identifiers, one for > each {primary PE, protector} where the backup PE serves as a backup > for the primary PE. This TLV SHOULD NOT be advertised by the primary > PE or the backup PE to the protector. > > The processing of the Egress Protection Capability TLV by a receiving > router SHOULD follow the procedures defined in RFC 5561. In > particular, the router SHOULD advertise PW information to the > protector by using the Protection FEC Element TLV, only after it has > received the Egress Protection Capability TLV from the protector. It > SHOULD validate each context identifier included in the TLV, and > advertise the information of only those PWs that are associated with > the context identifier. It SHOULD withdraw previously advertised > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 19] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > Protection FEC TLVs, when the protector has withdrawn a previously > advertised context identifier or the entire Egress Protection > Capability TLV via Capability message. > > The encoding of the Egress Protection Capability TLV is defined as > below. It conforms to the format of Capability Parameter TLV > specified in RFC 5561. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |U|F| Egress Protection (TBD) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |S| Reserved | | > +-+-+-+-+-+-+-+-+ | > | | > ~ Capability Data = context identifier(s) ~ > | | > | +-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 11 > > The U-bit MUST be set to 1 so that a receiver MUST silently ignore > this TLV if unknown to it, and continue processing the rest of the > message. > > The F-bit MUST be set to 0 since this TLV is sent only in > Initialization and Capability messages, which are not forwarded. > > The TLV Code Point is TBD. It needs to be assigned by IANA. > > The S-bit indicates whether the sender is advertising (S=1) or > withdrawing (S=0) the capability. > > The "Capability Data" is encoded with the context identifier of the > {primary PE, protector}. > > SB> where is the structure of {primary PE, protector} defined? > > [yshen] The Protection FEC Element TLV carries the context ID of {primary PE, protector}. The {primary PE, protector} tuple itself is not encoded. > > 5.2. PW Label Distribution from Primary PE to Protector > > A primary PE SHOULD advertise a primary PW's label to a protector by > sending a Label Mapping message. The message includes a Protection > FEC Element TLV (see Section 5.4 for encoding), and an Upstream- > Assigned Label TLV (RFC 6389) encoded with the PW's label. The > combination of the Protection FEC Element TLV and the PW label > represents the primary PE's forwarding state for the PW. The Label > Mapping message SHOULD also carry an IPv4/v6 Interface_ID TLV (RFC > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 20] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > 6389, RFC 3471) encoded with the context identifier of the {primary > PE, protector}. > > The protector that receives this Label Mapping message SHOULD install > a forwarding entry for the PW label in the label space identified by > the context identifier. The nexthop of the forwarding entry SHOULD > ensure packets to be sent towards the target CE via a backup AC or a > backup (S-)PE, depending on the protection scenario. The protector > SHOULD silently discard a Label Mapping message if the included > context identifier is unknown to it. > > 5.3. PW Label Distribution from Backup PE to Protector > > In the centralized protector model, a backup PE SHOULD advertise a > backup PW's label to a protector by sending a Label Mapping message. > The message includes a Protection FEC Element TLV and a Generic Label > TLV encoded with the backup PW's label. This Protection FEC Element > MUST be identical to the Protection FEC Element TLV that the primary > PE advertises to the protector (Section 5.2). The context identifier > SHOULD NOT be encoded in Interface_ID TLV in this message. > > The protector that receives this Label Mapping message SHOULD > associate the backup PW with the primary PW, based on the common > Protection FEC Element TLV. It SHOULD distinguish between the Label > Mapping message from the primary PE and the Label Mapping message > from the backup PE based on the respective presence and absence of > context identifier in Interface_ID TLV. It SHOULD install a > forwarding entry for the primary PW's label in the label space > identified by the context identifier. The nexthop of the forwarding > entry SHOULD indicate a label swap to the backup PW's label, followed > by a label push or IP header push for a transport tunnel to the > backup PE. > > 5.4. Protection FEC Element TLV > > The Protection FEC Element TLV has type 0x83. Its format is defined > as below: > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 21] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type(0x83) | Reserved | Encoding Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | | > ~ PW Information ~ > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12 > > - Encoding Type > > Type of format that PW Information field is encoded. > > - Length > > Length of PW Information field in octets. > > - PW Information > > Field of variable length that specifies a PW > > For Encoding Type, 1 is defined for the PWid FEC Element format, and > 2 is defined for the Generalized PWid FEC Element format (RFC 4447). > > > 5.4.1. Encoding Format for PWid > > > > > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 22] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type(0x83) | Reserved | Enc Type(1) | Length(16) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ingress PE Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Egress PE Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Group ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |C| PW Type | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13 > > - Ingress PE Address > > IP address of the ingress PE of PW. > > - Egress PE Address > > IP address of the egress PE of PW. > > SB> How does this work for IPv6? > > - Group ID > > An arbitrary 32-bit value that represents a group of PWs and that > is used to create groups in the PW space. > > - PW ID > > A non-zero 32-bit connection ID that, together with the PW Type > field, identifies a particular PW. > > - Control word bit (C) > > A bit that flags the presence of a control word on this PW. If C > = 1, control word is present; If C = 0, control word is not > present. > > - PW Type > > A 15-bit quantity that represents the type of PW. > > SB> Needs a ref > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 23] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > 5.4.2. Encoding Format for Generalized PWid > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type(0x83) | Reserved | Enc Type(2) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ingress PE Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Egress PE Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |C| PW Type | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AGI Type | Length | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ AGI Value (contd.) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AII Type | Length | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ SAII Value (contd.) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AII Type | Length | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ TAII Value (contd.) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14 > > - Ingress PE Address > > IP address of the ingress PE of PW. > > - Egress PE Address > > IP address of the egress PE of PW. > > SB> IPv6? > > - Control word bit (C) > > A bit that flags the presence of a control word on this PW. If C > = 1, control word is present; If C = 0, control word is not > present. > > - PW Type > > A 15-bit quantity that represents the type of PW. > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 24] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > - AGI Type, Length, Value, AGI Value > > Attachment Group Identifier of PW. > > - SAII Type, Length, Value, SAII Value > > Source Attachment Individual Identifier of PW. > > - TAII Type, Length, Value, TAII Value > > Target Attachment Individual Identifier of PW. > > 6. Revertive Behavior > > Subsequent to local repair, there are three strategies for the > network to restore traffic to a fully functional PW. > > o Global revertive mode > > If the ingress CE is multi-homed (Figure 1), it MAY switch the > traffic to a backup AC which is bound to a backup PW. > Alternatively, if the ingress PE hosts a backup PW (Figure 2), the > ingress PE MAY switch the traffic to the backup PW. These > procedures are referred to as global repair. Possible triggers of > a global repair include PW status, OAM, and BFD. > > o Control plane revertive mode > > In egress PE node protection and S-PE node protection, it is > possible that the failure is limited to the link between the PLR > and the primary (S-)PE, whereas the primary (S-)PE is still up. > In this case, the PLR or an upstream router along the transport > tunnel MAY reroute the tunnel around the failed link via an > alternative path. Thus, the transport tunnel can continue to be > used to carry the PW traffic to the primary (S-)PE. This > procedure is driven by control plane convergence, and is referred > to as control plane repair. > > o Local revertive mode > > The PLR MAY move traffic back to the primary PW, after the failure > is resolved. In egress AC protection, upon detecting that the > primary AC is restored, the PLR MAY start forwarding traffic over > the AC again. Likewise, in egress PE node protection and S-PE > node protection, upon detecting that the primary PE is restored, > the PLR MAY re-establish the primary transport tunnel through the > primary PE, and move the traffic from the bypass tunnel back to > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 25] > > > Internet-Draft PW Endpoint Fast Failure Protection July 2014 > > > the transport tunnel. These procedures are referred to as local > reversion. > > The fast protection mechanism in this document SHOULD be used in > tandem with the global revertive mode. Particularly in the case of > egress (S-)PE failure, if the ingress PE or the protector loses > communication with the (S-)PE for an extensive period of time, the > LDP session between them may go down. Consequently, the ingress PE > may bring down the primary PW, or the protector may remove the > forwarding entry of the primary PW label. In either case, the > service will be disrupted. In other words, although the fast > protection can temporarily repair traffic, control plane state may > eventually be timed out if the failure persists. Therefore, it is > recommended that the global revertive mode SHOULD be set up in > advance, so that traffic can be moved to a fully functional backup PW > shortly after the local repair. > > The control plane revertive mode may always happen as part of the > convergence of control plane protocols. However, it is only > applicable to the specific scenarios described above. > > The local revertive mode is optional. In the circumstances where the > failure is caused by resource flapping, local reversion MAY be > dampened to limit potential disruptions. Local revertive mode MAY be > disabled completely by configuration. > > 7. IANA Considerations > > This document defines the encoding of the Capability Parameter TLV > for the new "Egress Protection Capability" in Section 5. This would > require IANA to assign a TLV Code Point to it. > > This document defines a new LDP Protection FEC Element TLV in > Section 5. IANA has assigned the type value 0x83 to it. > > SB> I am very confused about what explicit actions you are asking IANA > to take. Are you saying that there are no IANA actions? > > [yshen] Need IANA to assign a TLV code to "Egress Protection Capability", as said above. > > 8. Security Considerations > > The security considerations discussed in RFC 5036, RFC 5331, RFC > 3209, and RFC 4090 apply to this document. > > SB> Are there any PW security considerations that apply? > > SB> This is a new PW operational mode, so I am surprised that there are > no new security considerations. An early security review might be useful. > > > [yshen] Not sure about any specific security issues. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Tue Aug 5 04:14:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8711B29A3; Tue, 5 Aug 2014 04:14:23 -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 a1VumMyoGbJw; Tue, 5 Aug 2014 04:14:11 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0082.outbound.protection.outlook.com [213.199.154.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62A21B2AA1; Tue, 5 Aug 2014 04:14:09 -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.995.14; Tue, 5 Aug 2014 11:14:06 +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.0995.014; Tue, 5 Aug 2014 11:14:06 +0000 From: Alexander Vainshtein To: "stbryant@cisco.com" , Yimin Shen Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqzzbveYGLBru1kCsLuzIRj9tdJu4/J4AgAjkt4CAAAF6sA== Date: Tue, 5 Aug 2014 11:14:05 +0000 Message-ID: References: <53D7B569.60400@cisco.com> <53E0B85B.8060707@cisco.com> In-Reply-To: <53E0B85B.8060707@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02945962BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(51704005)(24454002)(199002)(252514010)(189002)(164054003)(37854004)(479174003)(377454003)(106356001)(77982001)(80022001)(81342001)(74316001)(19580395003)(79102001)(81542001)(15202345003)(85852003)(46102001)(31966008)(105586002)(4396001)(50986999)(106116001)(64706001)(92566001)(19580405001)(66066001)(54356999)(95666004)(74502001)(83072002)(99396002)(86362001)(2656002)(20776003)(74662001)(101416001)(83322001)(33646002)(76482001)(87936001)(76176999)(76576001)(107046002)(21056001)(15975445006)(85306004)(24736002)(108616003)(559001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; 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/mpls/hNh5LArLJVv-Hjp6CZgPWSq73rU Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 11:14:24 -0000 Stewart, Yimin and all, A couple of comments/questions inline below. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Tuesday, August 05, 2014 1:56 PM > To: Yimin Shen; pwe3; pwe3-chairs@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 >=20 > On 30/07/2014 20:07, Yimin Shen wrote: > > Hi Stewart, > > > > Thanks very much for the detailed review and comments. I'd like to > highlight a few things below about this draft, and then respond to your > comments inline. Hope you could give the draft another closer look. > Yimin, >=20 > Having read your reply and having looked at the text again, > and talked to a few folks I think I now understand the top > level view of what is proposed. However that is in itself > an indication that the draft needs considerable work > before publication. Note that it was not initially obvious > that you supported both LDP and RSVP-TE PSNs, nor > was it initially obvious that you were using the PSN to > protect the PWs and not looking further down the stack. [[Sasha]] I still have serious doubts regarding LDP-based MPLS PSN - at lea= st without some extensions to LDP. > Indeed I think there is some text in the draft that positively > leads you in that direction since someone else picked > it it during an MPLS review. >=20 > To summarize: what you are doing is construct repairs > at the PSN layer that map to each combination of PW + PW repair, > which I think multiples the number of PSN tunnels by three times > the dispersion factor where the dispersion factor is some factor > defining the average number of PEs that the PWs addressed to > a single PE need to be dispersed to. >=20 > This leads to two questions that the WG needs to think about: >=20 > 1) This is trading increased PSN state for response time. > Given that PSN state was a critical factor in the choice of the Martini > design over the CCC design this needs to be made clear up front > in the text and the WG needs to decide that this is acceptable. >=20 > 2) This increased state and the complexity of introducing > context labels and protection routers to the PWE3 architecture > is directly traceable to the need to do xPE node protection, > and is not required for link protection including the egress AC. >=20 > This desire to build the design around node protection (which > always adds significant complexity to FRR) is in contrast to > the IPFRR situation where link protection is of overwhelming > importance and node protection seems to be of secondary > importance. >=20 > An alternative design, which would require less change to the > existing PWE3 design would be to provide redundant connection > to the xPEs and allow FRR link protection in the PSN to > deal with link failures and then to protect the egress AC by > making the T-PE a special type of S-PE that preferred to > act as a T-PE but if the AC was down forwarded to an alternate > T-PE for that PW. >=20 > If the WG prefers to introduce the cross layer scheme you have > proposed, then fine, we need to do the full set of updates needed. > However first I think that we need to have rough consensus that > the use cases and requirements justify the increased complexity > compared of node protection compared to the alternative of > providing link and AC protection. > > > > [1] This draft is completely based on the PWE3 and the MS-PW > architecture. It is also based on RFC 5331 " MPLS Upstream Label Assignme= nt > and Context-Specific Label Space". So ideally readers should be familiar = with > that RFC. > As far as I can see context labels have not been introduced > into the PWE3 architecture. There is some reference to their use for > P2MP PWs, but not in the P2P case. Indeed I think that RFC4447 > notes explicitly that in the case where the configuration of PWs > is signaled by LDP the platform label space must be used. The > least that you need to do is to update RFC4447. > [[Sasha]] yes, RFC 4447 explicitly requires the PW labels to be allocated f= rom the per-platform label space.=20 And according to RFC 5331 per-platform label space is a special case of the= label context. =20 >=20 > Something that I noticed in a second pass through the text is that > you seem to have changed the PW FEC data structure from the > one specified by PWE3 to a variant of one used in LSP Ping. This > seems unnecessary and may lead to confusion and difficulty if > these get changed at some time in the future. A better design > is surely to leave the PWE3 signalling system completely unchanged > except to add an additional TLV specifying the context information > if indeed we continue on that path. Apropos this, it may be the > way that the document was written, but I did not see anything about > the need to signal the PW interface parameters to the alternative > PE. Also I did not see anything specifying the error handling > as a result of parameter issues. >=20 > A comment below that was not picked up is that the signalling > design supports IPv4 only, and as I recall there is an IESG policy > of not standardizing any IPv4 only solutions, so perhaps we should > introduce IPv6 at the same time as harmonizing the normal and > context label data structures. >=20 > The LDP signalling of PWs with context labels need a more > complete review for both completeness and correctness and > to ensure that this text provides a description that is sufficiently > complete that this new feature can be implemented solely from > this text and the associated references. >=20 [[Sasha]] How is the router supposed to differentiate between an IP address= used as the context ID and an IP address used as the PE ID? > > > [2] The draft mentions two important roles of routers, PLR (point of lo= cal > repair) and protector. > You need a clearer definition of a PLR and protector. I think that > a protector is a new type of SPE and needs a clearer architectural > definition. >=20 > The concept of a PLR taking action at one layer within the context > of another is new in PWE3. Perhaps it is defined in MPLS in which > case a reference would be appropriate. > > > > [3] PLR performs local repair in dataplane, based on pre-installed back= up > forwarding state pointing to a bypass tunnel. There is no control-plane > involvement in local repair. > Specifically in the initiation of the local repair, it is in the > configuration > of course. > > This is similar to the existing IP/MPLS fast-reroute mechanisms. Theref= ore, > it can achieve restore traffic with a similar performance to those > mechanisms. That is the main goal of this draft. > IP/MPLS FRR normally operates solely for the benefit of its own > dataplane. You have this configured to act for the benefit of the > client dataplane. > > > > [4] When doing local repair, the PLR only swaps the top label (i.e. tun= nel > label) to a bypass tunnel's label, and keeps the PW label (allocated by > primary/protected PE) intact. The PLR doesn't need to know or understand > the PW label. > Indeed this is clearer now, and needs to be made much clearer in > the text. >=20 > However so do the implications for the system as a whole of this > mode of operation. > > > > [5] The protector is the router at the other end of the bypass tunnel. = It is > responsible for forwarding the traffic further, so that the traffic can > eventually reach the target CE. The protector must understand the PW labe= l > allocated by the primary PE. > The use of the work primary PE is slightly confusing. Presumably > you mean the ingress PE of the segment rather than the ingress > PE from the point of view of the ingress AC. > > This is achieved by using the context label forwarding paradigm specifi= ed in > RFC 5331. This draft defines some LDP extensions to allow the primary PE = to > advertise PW labels to the protector. The protector locally maintains a l= abel > space for these PW labels of the protected PE, and looks up the PW label = in > this label space. The bypass tunnel serves as the pointer to this label s= pace. > Now I understand that. Please make this much clearer > earlier in the text. >=20 > Note my earlier concern about the design of those extensions. > > > > [6] This draft also introduces the concept of "context ID". A context I= D is an > IP address identifying a pair of . > The use of an IP address rather than some identifier taken from > the PW context is a design assumption not properly shared with the > reader and needs to be clarified in the text. >=20 > > It serves as the destination of transport tunnel. PWs carried by the tu= nnel > will be redirected to the protector X during local repair. PWs to the sam= e > primary PE but protected by a different protector Y cannot be carried by = this > tunnel. Rather, they must be carried by a tunnel destined for context ID = of > . > Indeed, but that needs to be made clearer, particularly as this > seemingly has scaling consequences. > > > > [7] A PLR may be any router in the network, including P or PE router. T= he > draft assumes that it doesn't know or care about PW info. > > > > [8] A protector is a PE router > Within a PE context I am not sure that the properties of a PE router > are defined. > > in the "co-located" model. It may be a P router in the "centralized" mo= del. > For the later case, the draft describes how to use the new LDP extensions= for > the protector to learn and assoicate primary PW and backup PW and install > forwarding entries in the context label table. > So when you run the centralized protector, how does the > PW parameter signaling and interface parameter verification > work? Surely the centralized protector needs to be some > form of PE rather than a variant of an MPLS P router? >=20 > I have a bunch of comments on your answer below, put perhaps we > can start by working through the comments above and the cycle > back to the comments below within the resultant context. >=20 > I will comment on our exchange below when we have reached > some level of consensus on the preamble. >=20 > Given the concerns that I have raised and those raised by Sasha > I think that the chairs need consider taking this back to the WG > for further work. >=20 > - Stewart > > > > Thanks, > > > > /Yimin > > > > > > -----Original Message----- > > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant > > Sent: Tuesday, July 29, 2014 10:53 AM > > To: pwe3; pwe3-chairs@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 > > > > > > > > I do not support the publication of this draft without: > > > > 1) An assurance that MPLS WG has reviewed it and is happy > > with the extensions that seem to be made to the MPLS architecture > > > > 2) A formal description of those extensions or a pointer > > to those extensions in another RFC. > > > > 3) Significant clarification of how the detail of this > > mechanism works. > > > > For this to work you need to have co-ordinated label spaces > > in multiple PEs which is something that was investigated > > by the SPRING WG and found not to work, particularly when > > different manufacturers equipments were involved. > > > > [yshen] This draft does not rely on label space coordination. Rather, i= t is > based on context label forwarding paradigm specified in RFC 5331. > > > > > > As far as I can see you also need to peek below the top > > of stack to do a fast reroute operation which is not > > a currently defined MPLS operation. > > > > There seem to be a lot of details and clarifications missing > > that need to be provided, and I am not entirely convinced > > that all of the items declared out of scope are legitimately > > out of scope and not needed in order for a multi-vendor > > solution to be implemented. > > > > It would be useful to me (and I suspect to other readers) > > to see what the dataplane looks like at various points > > in the normal and repair path to verify that all parties > > have the right information for this to work under normal > > and various fault conditions. > > > > I have a number of comments inline that need to be addressed > > before this can proceed. > > > > > > - Stewart > > > > > > PW Endpoint Fast Failure Protection > > draft-ietf-pwe3-endpoint-fast-protection-01 > > > > Abstract > > > > This document specifies a fast mechanism for protecting pseudowire= s > > against egress endpoint failures, including egress attachment circ= uit > > failure, egress PE failure, multi-segment PW terminating PE failur= e, > > and multi-segment PW switching PE failure. Designed on the basis = of > > multi-homed CE, PW redundancy, upstream label assignment and > context > > specific label switching, the mechanism enables local repair to be > > performed by the router upstream adjacent to a failure. > > > > In > > particular, the router can restore PW traffic in the order of tens= of > > milliseconds, > > > > SB> Not sure it's wise to specify a performance claim in a standards > > SB> track RFC. > > > > [yshen] If this is viewed as inappropriate, we can remove it. > > > > by transmitting the traffic to a protector through a > > pre-established bypass tunnel. Therefore, the mechanism can reduc= e > > traffic loss before global repair reacts to the failure and the > > network converges on the topology changes due to the failure. > > > > > > > > =3D=3D=3D > > > > > > 1. Introduction > > > > Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segme= nt > > can be thought of as a connection between a pair of forwarders hos= ted > > by two PEs, carrying an emulated layer-2 service over a packet > > switched network (PSN). In the single-segment PW (SS-PW) case, a > > forwarder binds a PW to an attachment circuit (AC). In the multi- > > segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) bi= nds > > a PW segment to an AC, while a forwarder on a switching PE (S-PE) > > binds one PW segment to another PW segment. In each direction > > between the PEs, PW packets are transported by a PSN tunnel, which= is > > called a transport tunnel. > > > > SB> Did we ever your the term transport tunnel before? > > > > [yshen] This is mainly for clarity. We could change it to " which is > > called a transport tunnel *in this document*". Or we can completel= y > replace "transport tunnel" with just "tunnel". > > > > 3. Reference Models and Failure Cases > > > > The mechanism in this document intends to > > use these topologies for local repair purposes. > > > > SB> The toplology is not a mechanism. Are you saying that the mechanims > > SB> only works in this topology? > > > > [yshen] No, these topologies are only examples for use by subsequent > sections to describe the mechanisms. The mechanisms should equally work > for other topologies as well. > > > > This SHALL enable > > local repair and global repair to work in tandem to achieve broade= r > > coverage of protection for services. > > > > SB> I have no idea how a SHALL in capitals applies here. > > > > [yshen] Will fix this. > > > > 3.1. Single-Segment PW > > > > > > > > |<-------------- PW1 --------------->| > > > > - PE1 -------------- P1 ---------------- PE2 - > > / \ > > / \ > > CE1 CE2 > > \ / > > \ / > > - PE3 -------------- P2 ---------------- PE4 - > > > > |<-------------- PW2 --------------->| > > > > Figure 1 > > > > > > Each CE is multi-homed to two PEs. Hence, there are two divergent > > paths between the CEs. > > > > SB> It does not follow that the paths are divergent! Who knows > > SB> what happens in the IP layer and the underlying transport > > SB> network. > > > > > > [yshen] We could rephrase this and remove "divergent". All we want to s= ay > here is that there are two distinct sets of AC-PW-AC between the CEs. > > > > At any given time, each CE sends traffic via only one AC and recei= ves > > traffic via only one AC. The two ACs MAY or MAY NOT be the same. > > > > SB> May not be the same what? If they are actually the same AC you > > SB> have no redundancy. > > > > [yshen] Will rephrase it. All we want to say is that at a given time, t= he CE > may send traffic over one AC and receive traffic over another AC. > > > > The AC used to send traffic is determined by the CE, and MAY rely = on > > an end-to-end OAM mechanism between the CEs. The AC used for the > CE > > to receive traffic is determined by the state of the network and t= he > > protection mechanism in use, as described later in this document. > > > > From the perspective of traffic flowing towards a given CE, the se= t > > of PWs, PEs and ACs involved can be viewed to serve primary and > > backup (or active and standby) roles. When the network is in a > > steady state, the PW that is intended to carry the traffic is > > referred to as a primary PW. The PE at the egress of the primary = PW > > is a primary PE. The AC connecting the CE and the primary PE is a > > primary AC. The other PW may be used to carry the traffic upon a > > network failure, and is referred to as a backup PW. The PE at the > > egress of the backup PW is a backup PE. The AC connecting the CE = and > > the backup PE is a backup AC. > > > > In this document, the following primary and backup roles are assig= ned > > for the traffic going from CE1 to CE2: > > > > Primary PW: PW1 > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 5= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > Primary PE: PE2 > > > > Primary AC: CE2-PE2 > > > > Backup PW: PW2 > > > > Backup PE: PE4 > > > > Backup AC: CE2-PE4 > > > > In this case, an egress AC failure refers to the failure of the AC > > CE2-PE2. An egress node failure refers to the failure of PE2. > > > > The backup PE, backup PW and backup AC may be used to carry traffi= c > > after a PW endpoint failure, when CE1 and CE2 switches traffic to = PW2 > > in local repair or global repair, as described later in this > > document. > > > > |<-------------- PW1 --------------->| > > > > ------------- P1 ---------------- PE2 - > > / \ > > / \ > > CE1 -- PE1 CE2 > > \ / > > \ / > > ------------- P2 ---------------- PE4 - > > > > |<-------------- PW2 --------------->| > > > > Figure 2 > > > > Figure 2 shows another possible scenario, where CE1 is single-home= d > > to PE1, while CE2 remains multi-homed to PE2 and PE4. From the > > perspective of egress protection for the traffic from CE1 to CE2, > > this topology is not much different than Figure 1. However, for t= he > > > > SB> "not much different than Figure 1" is not helpful, either it is the > > same, or you need to explain the difference. > > > > [yshen] Will rephrase. The difference is actually described after > "However...". > > > > > > traffic in the direction from CE2 to CE1, PE1 must anticipate traf= fic > > on both PW1 and PW2, and sends it to CE1 over the AC CE1-PE1. > > > > SB> What does it mean to anticipate traffic. > > > > [yshen] To anticipate incoming traffic over either PW1 or PW2. Will > rephrase. > > > > 3.2. Multi-Segment PW > > > > > > > > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 6= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > |<--------------- PW1 --------------->| > > |<----- SEG1 ----->|<----- SEG2 ----->| > > > > - TPE1 -------------- SPE1 --------------- TPE2 - > > / \ > > / \ > > CE1 CE2 > > \ / > > \ / > > - TPE3 -------------- SPE2 --------------- TPE4 - > > > > |<----- SEG3 ----->|<----- SEG4 ----->| > > |<--------------- PW2 --------------->| > > > > Figure 3 > > > > Figure 3 shows a topology that is similar to Figure 1 but in an MS= -PW > > environment. PW1 and PW2 are both MS-PWs. PW1 is established > > between TPE1 and TPE2, and switched between segments SEG1 and > SEG2 at > > SPE1. PW2 is established between TPE3 and TPE4, and switched > between > > segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TP= E3. > > CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the= PW > > segments are not shown in this figure for clarity. > > > > In this document, the following primary and backup roles are assig= ned > > for the traffic going from CE1 to CE2: > > > > Primary PW: PW1 > > > > Primary T-PE: TPE2 > > > > Primary S-PE: SPE1 > > > > Primary AC: CE2-TPE2 > > > > Backup PW: PW2 > > > > Backup T-PE: TPE4 > > > > Backup S-PE: SPE2 > > > > Backup AC: CE2-TPE4 > > > > In this case, an egress AC failure refers to the failure of the AC > > CE2-TPE2. An egress node failure refers to the failure of TPE2. = An > > S-PE failure refers to the failure of SPE1. > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 7= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > The backup T-PE, backup PW and backup AC are used for protecting t= he > > primary PW against egress AC failure and egress node failure. The > > backup S-PE and the backup PW are used for protecting the primary = PW > > against S-PE failure, as described later in this document. > > > > For consistency with the SS-PW scenario, primary T-PEs and a prima= ry > > S-PEs may simply be referred to as primary PEs in this document, > > where specifics is not required. Similarly, backup T-PEs and back= up > > S-PEs may be referred to as backup PEs. > > > > 4. Theory of Operation > > > > The fast protection mechanism in this document provides three type= s > > of protection for PWs, corresponding to the three types of failure= s > > described in Section 1. > > > > a. Egress AC protection > > > > b. Egress (T-)PE node protection > > > > c. S-PE node protection > > > > The mechanism assumes a multi-homed CE with connectivity to a > primary > > PE and a backup PE, and the existence of a backup PW in the networ= k. > > In S-PE node protection, it also assumes the existence of a backup > > S-PE on the backup PW. > > > > > > SB> Do the PWs need to be symmetric - could you have more > > S-PEs on one that you have on the other? > > > > [yshen] You could. For a given S-PE, as long as you can find another PE= to > serve as protector, it will work. > > > > 4.1. Local Repair and Protector > > > > The mechanism relies on local repair to be performed by routers > > SB> Do you mean routers or PEs? Routers of more likely LSRs > > operate at a different layer and have no business knowing about > > PWs. > > > > [yshen] routers (LSRs). Yes, they have no idea about PWs. This draft > doesn't assume they know or care about PWs. > > > > SB> Has this work been reviewed my MPLS WG? I am concerned > > that you are doing a bunch of layer violation without explaining > > the how this is achieved or whether it is acceptable within the > > MPLS architecture. > > > > [yshen] There is no layer violation. The PLR simply redirect traffic fr= om the > original tunnel to a bypass tunnel, by doing a top label swap, without > touching, changing or knowing the PW label. Please take a close look at t= he > text. > > > > upstream adjacent to failures. Each of these routers is referred = to > > as a "point of local repair" (PLR). A PLR MUST be able to detect = a > > failure by using a rapid mechanism, such as physical layer failure > > detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc. = In > > anticipation of the failure, the PLR MUST also pre-establish a byp= ass > > PSN tunnel to a "protector", and pre-install a bypass route in the > > data plane. The bypass tunnel MUST have the property that it will > > not be affected by the topology changes in the event of the failur= e. [[Sasha]] Does this mean that the bypass tunnel MUST NOT use the link betwe= en the PLR and the protected PE? If yes, then how can this be done by normal LDP? Or do you intend to use so= me parts of CR-LDP for this? > > > > SB> This is far too imprecise - you need to separate operations and > > topologies in the PW layer from operations and topologies in the > > PSN layer > > > > [yshen] Similar to existing IP/MPLS fast-reroute RFCs, this draft doesn= 't > restrict local repair trigger to any specific failure detection mechanism= s. Any > mechanism will work. > > > > SB> In each case you need to be clear how you are detecting failure > > by specifying the MEPs and MIPs you are testing. > > > > Upon detecting the failure, the PLR MUST invoke the bypass route i= n > > the data plane, and reroute PW traffic to the protector through th= e > > bypass tunnel. The protector MUST in turn send the traffic to the > > target CE. > > > > SB> No the protector knows nothing about CEs - they are in the client > > layer, and you can only protect at the server layer or the server's > > server layer. > > > > [yshen] In collocated model, the protector is a PE. In the centralized = model, > the protector may be an LSR , and it needs to participate in LDP PW signa= ling > to understand PWs. See the related sections and LDP extensions in this dr= aft. > This centralized model is optional. > > > > This procedure is referred to as local repair. > > > > Different routers may serve as PLR and protector in different > > scenarios. > > > > SB> Remember they are not routers - they are xPEs or LSRs. > > > > [yshen] Again, in collocated model, the protector is a PE. In the centr= alized > model, the protector may be an LSR , and it needs to participate in LDP P= W > signaling to understand PWs. See the related sections and LDP extensions = in > this draft. But this centralized model is optional. > > [yshen] PLRs may be LSRs, but they don't need to know PWs, because all > they do is to swap top label (tunnel label) to a bypass tunnel's label. > > > > SB> In each of the following we need to note that these are > > not RFC3985 PEs, even if they take no part in the protection > > such as the PEs on the left. Indeed I am wondering if you need > > to update RFC3985 and RFC5659 > > > > [yshen] There is no need to update RFC3985 and RFC5659. > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 8= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > o In egress AC protection, the PLR is the primary PE that termina= tes > > the primary PW and hosts the primary AC, and the protector is t= he > > backup PE (Figure 4). > > > > |<-------------- PW1 --------------->| > > > > - PE1 -------------- P1 ---------------- PE2 - > > / PLR \ > > / | \ > > CE1 bypass| CE2 > > \ | / > > \ | / > > - PE3 -------------- P2 ---------------- PE4 - > > protector > > > > |<-------------- PW2 --------------->| > > > > Figure 4 > > > > > > o In egress PE node protection, the PLR is the penultimate hop > > router of the transport tunnel of the primary PW, and the > > protector is the backup PE (Figure 5). > > > > |<-------------- PW1 --------------->| > > > > - PE1 -------------- P1 ------- P3 ----- PE2 - > > / PLR \ \ > > / \ \ > > CE1 bypass\ CE2 > > \ \ / > > \ \ / > > - PE3 -------------- P2 ---------------- PE4 - > > protector > > > > |<-------------- PW2 --------------->| > > > > Figure 5 > > > > SB> Note that it is nothing like as clean as this, if as you later have= , > > some of P3's traffic needs to go to PE4 and some to PE5. > > Also what about the > > > > [yshen] Note that we are talking about a single PW, rather than multipl= e > PWs carried by a single tunnel. > > > > o In S-PE node protection, the PLR is the penultimate hop router = of > > the transport tunnel of the primary PW segment, and the protect= or > > is the backup S-PE (Figure 6). > > > > > > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 9= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > |<--------------- PW1 --------------->| > > |<----- SEG1 ----->|<----- SEG2 ----->| > > > > - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - > > / PLR \ \ > > / \ \ > > CE1 bypass\ CE2 > > \ \ / > > \ \ / > > - TPE3 --------------- SPE2 -------------- TPE4 - > > protector > > > > |<----- SEG3 ----->|<----- SEG4 ----->| > > |<--------------- PW2 --------------->| > > > > Figure 6 > > > > A PLR can realize its role based on configuration or the signaling= of > > transport tunnel. For example, in the case where the transport > > tunnel is signaled by RSVP, the penultimate hop router could reali= ze > > > > SB> Could realize is not sufficient. The mechanism needs to be > > unconditional. > > > > [yshen] Will rephrase. > > > > that it is the PLR for egress (T-)PE or S-PE failure based on the = RRO > > in Resv message, which should indicate that the router is one hop > > away from the PE. The detail of how this could be achieved on a p= er- > > protocol basis is out of the scope of this document. > > > > SB> So where is it in scope? How do I find out how to do it? > > > > In all scenarios, when a PLR reroutes traffic through a bypass tun= nel > > to a protector during local repair, it MUST keep the label of the > > primary PW intact in the packets. This obviates the need for the = PLR > > to maintain bypass routes on a per-PW basis, and allows a single > > bypass tunnel to carry traffic for multiple PWs. > > > > SB> OK, but didn't I read something about PE protecting subsets of the > > egress traffic of other PEs? How would that work without per PW > information? > > > > [yshen] PWs to a given PE may be protected by multiple protectors. A se= t > of PWs sharing the same protector X can be carried by the same tunnel > (destined to the context ID of ). PWs protected by a diffe= rent > protector Y must be carried by different tunnel (destined to the context = ID of > ). The PLR of each tunnel doesn't need to know PW info. Al= l it > does is to swap tunnel label to a bypass tunnel's label, and the bypass t= unnel > will guide the traffic to the intended protector. > > > > The procedure also requires that the protector SHOULD be able to > > forward the traffic based on a PW label that is assigned by the > > primary PE, and ensure the traffic to eventually reach the target = CE. > > From the protector's perspective, this PW label is an upstream > > assigned label (RFC 5331). > > > > SB> .. but the protector may be a P router and know nothing about > > PWs. > > > > [yshen] Again, in collocated model, the protector is a PE. In the centr= alized > model, the protector may be an LSR , and it needs to participate in LDP P= W > signaling to understand PWs. See the related sections and LDP extensions = in > this draft. But this centralized model is optional. > > > > > > To accomplish this, the protector SHOULD > > learning the PW label from the primary PE prior to the failure, an= d > > install proper forwarding state for the PW label in a dedicated la= bel > > space for the primary PE. > > > > SB> This is a new PE to P router protocol > > > > [yshen] The LDP extension is defined in a subsequent section. > > > > During local repair, the protector SHOULD > > perform PW label lookup in this label space. > > > > SB> This has to be signed off by MPLS WG > > SB> How can this only be a SHOULD - why is it not a MUST? > > > > [yshen] Will rephrase. > > > > SB> What do you do to ensure that they even have compatible label > managers? > > > > [yshen] The LDP extensions defined in this draft covers how to negotiat= e > the capability. > > > > > > SB> Doesn't this mean a P router looking up two labels to do > > the repair? > > > > [yshen] PLR only swaps the top label (i.e. tunnel label) to bypass labe= l > table, when doing the local repair. > > > > The above examples have shown the scenarios where the protectors a= re > > backup (T/S-)PEs. In other scenarios, a protector may be a dedica= ted > > router that assumes such role, separate from the backup (T/S-)PE o= f a > > primary PW. During local repair, the PLR MUST still reroute traff= ic > > to the protector through a bypass tunnel. The protector MUST in t= urn > > send the traffic to the backup (T/S-)PE, which MUST then send the > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 10= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > traffic to the target CE via a backup AC or a backup PW segment. > > More detail will be described in Section 4.3. > > > > 4.2. Context Identifier > > > > A protector MAY protect multiple primary PEs. > > > > SB> This requires that a P router knows about PWs - how does > > it do that? > > > > [yshen] The protector will perform context label forwarding. The bypass > tunnel points to a context label table, and the protector looks up the PW > label in that table. > > > > The protector MUST > > maintain a separate label space for each primary PE. Likewise, th= e > > PWs terminated on a primary PE MAY be protected by multiple > > protectors, each for a subset of the PWs. In any case, a given > > primary PW SHOULD be associated with one and only one pair of > > {primary PE, protector}. > > > > An IPv4/v6 address is assigned to each ordered pair of {primary PE= , > > protector} to facilitate protection establishment. This address i= s > > referred to as a "context identifier". It MUST be globally unique= , > > or unique in the address space of the network where the primary PE > > and the protector reside. > > > > SB> I think you need to make clear that this is not backwards compatibl= e > > with existing PW PEs. > > > > [yshen] PEs will need to support the extensions defined by this draft. > > > > SB> You also need to explain how the IP based context identifier > > mechanism works. Is it in the control plane or the data plane? > > > > 4.2.1. Semantics > > > > The semantics of a context identifier is twofold. > > > > o It identifies a primary PE and an associated protector. In oth= er > > words, it identifies a primary PE on a per protector basis. A > > given primary PE may be protected by multiple protectors, each = for > > a subset of the primary PWs terminated on the primary PE. A > > distinct context identifier MUST be assigned to the primary PE = and > > each protector. > > > > For each primary PW, its ingress PE MUST set up or resolve a > > transport tunnel with destination as the context identifier of = the > > {primary PE, protector}, rather than a private IP address of th= e > > primary PE. This not only allows the transport tunnel to reach > > the primary PE, but also conveys the identity of the protector = to > > the PLR(s) along the transport tunnel. Each PLR can in turn us= e > > this information to set up a bypass tunnel to the protector > > without relying on local configuration. > > > > o It indentifies the primary PE's label space on the protector. = The > > protector may protect PWs for multiple primary PEs. For each > > primary PE, it MUST maintain a separate label space to store th= e > > PW labels assigned by that primary PE. It MUST associate a PW > > label with a label space via the context identifier of the > > {primary PE, protector}, as described below. > > > > SB> Is this context identifier an IP address or an MPLS label? Where > > is it carried? > > > > [yshen] a context identifier is an IP address. If the tunnel is IP tunn= el, it is > carried in IP header as dest address. If the tunnel is MPLS tunnel, it is > indicated by the label. > > > > In addition to the normal LDP PW signaling, the primary PE MUST > > have a targeted LDP session with the protector, and advertise P= W > > labels to the protector via LDP Label Mapping messages (See > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 11= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > Section 5 for detail). The primary PE MUST attach the context > > identifier to each message. Upon receiving the message, the > > protector MUST install the advertised PW label in the label spa= ce > > identified by the context identifier. > > > > SB> I am currently confused about how a data packet carries the PW > > label provided by another PE. > > > > When a PLR sets up or resolve a bypass tunnel to the protector,= it > > MUST set the destination to the context identifier, rather than= a > > private IP address of the protector. Once established, the byp= ass > > tunnel, with either its MPLS label or IP tunnel destination > > address, is used as the identifier of label space. On the > > protector, all PW packets received on the bypass tunnel MUST be > > forwarded based on a label lookup in that label space. > > > > SB> I do not understand the data plane structure that the above sentenc= e > > is describing. > > > > [yshen] This is basically the context label forwarding paradigm (RFC 53= 31). > From the protector's perspective, the bypass tunnel serves as a context, = and > indicates the label space of the primary PE where the PW label must be > looked up. > > > > > > 4.2.2. Advertisement and Path Computation > > > > Using a context identifier as destination for both transport tunne= l > > and bypass tunnel requires both the primary PE and the protector t= o > > advertise the context identifier via IGP as an IP address reachabl= e > > through both routers in routing domain and/or TE domain. This > > imposes the following requirements on path computation for these > > tunnels. > > > > o For the transport tunnel, the ingress PE MUST choose the primar= y > > PE as the actual endpoint. > > > > o For the bypass tunnel, the PLR MUST choose the protector as the > > actual endpoint. In egress (T-)PE node protection and S-PE nod= e > > protection, the bypass tunnel MUST avoid the primary (S-)PE. > > > > The detail of how the primary PE and the protector may advertise a > > context identifier is independent of this mechanism and out of the > > scope of this document. > > > > SB> Given that you give signalling data structures later, I am confused > > as to how this can be out of scope of this text. Surely this is needed > > to implement an interoperable solution? > > > > [yshen] There is no new extension needed for IGP. Both PEs advertise th= e > context ID. That's it. Will rephrase it. > > > > One approach would be to advertise it as a > > virtual proxy node connected to both routers, with the link betwee= n > > the proxy node and the primary PE having a more preferable IGP or = TE > > metric than the link between the proxy node and the protector. Th= e > > ultimate goal is for a path computation algorithm, such as CSPF > > (constrained shortest path first), LFA (RFC 5286) and MRT ([IP-LDP= - > > FRR-MRT]), to be able to compute the paths that meet the above > > requirements. > > > > 4.3. Protection Models > > > > There are two protection models based on the location of a protect= or. > > A network MAY use either model, or a combination of both. > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 12= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > 4.3.1. Co-located Protector > > > > In this model, the protector is a backup PE that is directly > > connected to the target CE via a backup AC, or it is a backup S-PE= on > > a backup PW. That is, the protector is co-located with the backup > > (S-)PE. Examples of this model have been introduced in Figure 4, > > Figure 5 and Figure 6 in Section 4.1. > > > > In egress AC protection and egress PE node protection, when a > > protector receives traffic from the PLR, it forwards the traffic t= o > > the CE via the backup AC. This is shown in Figure 7, where PE2 is > > the PLR for egress AC failure, P3 is the PLR for PE2 failure, and = PE4 > > (the backup PE) is the protector. > > > > |<-------------- PW1 --------------->| > > > > - PE1 -------------- P1 ------- P3 ----- PE2 ---- > > / PLR \ PLR \ > > / \ | \ > > CE1 bypass\ |bypass CE2 > > \ \ | / > > \ \ | / > > - PE3 -------------- P2 ---------------- PE4 ---- > > protector > > > > |<-------------- PW2 --------------->| > > > > Figure 7 > > > > In S-PE node protection, when a protector receives traffic from th= e > > PLR, it MUST forward the traffic via the next segment of the backu= p > > PW. The T-PE of the backup PW MUST in turn forward the traffic to > > the CE via a backup AC. This is shown in Figure 8, where P4 is th= e > > PLR for SPE1 failure, and SPE2 (the backup S-PE) is the protector = for > > SPE1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 13= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > |<--------------- PW1 --------------->| > > |<----- SEG1 ----->|<----- SEG2 ----->| > > > > - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - > > / PLR \ \ > > / \ \ > > CE1 bypass\ CE2 > > \ \ / > > \ \ / > > - TPE3 --------------- SPE2 -------------- TPE4 - > > protector > > > > |<----- SEG3 ----->|<----- SEG4 ----->| > > |<--------------- PW2 --------------->| > > > > Figure 8 > > > > In the co-located protector model, the number of context identifie= rs > > needed by a network is the number of distinct {primary PE, backup = PE} > > pairs. From the perspective of scalability, the model is suitable > > for networks where the number of backup PEs for any given primary = PE > > is relatively small. > > > > 4.3.2. Centralized Protector > > > > In this model, the protector is a dedicated P router or PE router > > that serves the role. In egress AC protection and egress PE node > > protection, the protector MAY or MAY NOT be a backup PE with a dir= ect > > connection to the target CE. In S-PE node protection, the protect= or > > MAY or MAY NOT be a backup S-PE on the backup PW. > > > > In egress AC protection and egress PE node protection, when the > > protector receives traffic from the PLR, if the protector has a > > direct connection (i.e. backup AC) to the CE, it MUST forward the > > traffic to the CE via the backup AC, which is similar to Figure 7. > > Otherwise, it MUST forward the traffic to a backup PE, which MUST > > then forward the traffic to the CE via a backup AC. This is shown= in > > Figure 9, where the protector receives traffic from P3 (the PLR fo= r > > egress PE failure) or PE2 (the PLR for egress AC failure) and > > forwards the traffic to PE4 (the backup PE). The protector may be > > protecting other PWs as well, which is not shown in this figure fo= r > > clarity. > > > > SB> If you are going to cover the shared case, I think you need to > > make it much clearer how the PWs are identified from the received > > data packets. > > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 14= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > |<------------- PW1 --------------->| > > > > - PE1 ------------- P1 ------- P3 ----- PE2 -- > > / PLR \ PLR \ > > / \ / \ > > / bypass\ /bypass \ > > / \ / \ > > CE1 protector CE2 > > \ \ / > > \ \ / > > \ \ / > > \ \ / > > - PE3 ------------- P2 -----------------PE4 -- > > > > |<------------- PW2 --------------->| > > > > Figure 9 > > > > In S-PE node protection, when the protector receives traffic from = the > > PLR, if the protector is a backup S-PE of the backup PW, it MUST > > forward the traffic via the next segment of the backup PW, and the > > T-PE of the backup PW MUST forward the traffic to the CE via a bac= kup > > AC, which is similar to Figure 8. Otherwise, the protector MUST > > first forward the traffic to the backup S-PE, which MUST then forw= ard > > the traffic via the next segment of the backup PW. Finally, the T= -PE > > of the backup PW MUST forward the traffic to the CE via a backup A= C. > > This is shown in Figure 10, where the protector forwards traffic t= o > > SPE2 (the backup S-PE), SPE2 forwards the traffic to TPE4 via SEG4= , > > and TPE4 finally forwards traffic to CE2. The protector may be > > protecting other PW segments as well, which is not shown in this > > figure for clarity. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 15= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > |<--------------- PW1 --------------->| > > |<----- SEG1 ----->|<----- SEG2 ----->| > > > > - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - > > / PLR \ \ > > / \ \ > > / bypass\ \ > > / \ \ > > CE1 protector CE2 > > \ \ / > > \ \ / > > \ \ / > > \ \ / > > - TPE3 --------------- SPE2 -------------- TPE4 - > > > > |<----- SEG3 ----->|<----- SEG4 ----->| > > |<--------------- PW2 --------------->| > > > > Figure 10 > > > > The centralized protector model provides the convenience for multi= ple > > primary PEs to share one protector. Each primary PE MAY only need > > the one protector to protect all of its PWs. From the perspective= of > > scalability, the number of context identifiers needed by a network > > MAY be bound to the number of primary PEs. > > > > 4.4. Transport Tunnel > > > > The ingress PE of a primary PW associates the PW with the primary > > egress PE through LDP signaling. In addition, as mentioned in > > Section 4.2.1, the ingress PE MUST associate the transport tunnel = of > > the PW with the context identifier of the {primary PE, protector}, > > and set up or resolve the transport tunnel by using the context > > identifier as destination. This not only ensures that PW traffic = be > > transported to the primary PE, but also facilitates bypass tunnel > > establishment at PLR(s), as the context identifier implies the > > identity of the protector as well. This is also the case for a > > multi-segment PW, where the ingress PE and egress PE are T/S-PEs. > > > > The association between the transport tunnel and the context > > identifier at the ingress PE MAY be achieved by configuration or a= n > > auto-discovery mechanism. In the later case, the ingress PE MAY > > learn the context identifier from the primary (egress) PE, if the > > primary PE advertises the context identifier as "third party next > > hop" in IPv4/v6 Interface_ID (RFC 3471, RFC 3472) in the LDP > > Label Mapping message of the primary PW. > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 16= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > 4.5. Bypass Tunnel > > > > A PLR may protect multiple PWs associated with one or multiple pai= rs > > of {primary PE, protector}. The PLR MUST establish a bypass tunnel= to > > each protector for each distinct context identifier associated wit= h > > that protector. The destination of the bypass tunnel MUST be the > > context identifier (Section 4.2.1). The PLR may derive the contex= t > > identifier from the destination of the transport tunnel that > > traverses it. > > > > For examples, in Figure 7 and Figure 9, a bypass tunnel is > > established from PE2 (PLR for egress AC failure) to the protector, > > and another bypass tunnel is established from P3 (PLR for egress n= ode > > failure) to the protector. In Figure 8 and Figure 10, a bypass > > tunnel is established from P4 (PLR for S-PE failure) to the > > protector. > > > > During local repair, the PLR reroutes traffic to the protector > > through a bypass tunnel with PW label intact in the packets. This > > normally involves pushing a label to the label stack, if the bypas= s > > tunnel is an MPLS tunnel, or pushing an IP header to the packets, = if > > the bypass tunnel is an IP tunnel. > > > > SB> Surely it is normally a swap? > > > > [yshen] yes, this is just a label swap of the top label, from tunnel la= bel to > bypass tunnel label. > > > > SB> I am somewhat confused about what this all looks like when this is > > IP. The only PS/IP other than for SATOP are defined by L2TPv3 WG. > > There is no IP MS-PW definition that I am aware of. I think you need > > to be much clearer about what is going on when you discuss PW over IP > > egress repair. > > > > The protector MUST in turn > > forward the traffic based on the PW label. To achieve such kind o= f > > forwarding, the protector MUST rely on the bypass tunnel as a cont= ext > > to determine the primary PE's label space. If the bypass tunnel i= s > > an MPLS tunnel, the protector MUST have assigned a non-reserved la= bel > > to the bypass tunnel during the establishment of the bypass tunnel= , > > and hence this label can serve as the context. If the bypass tunn= el > > is an IP tunnel, the protector can simply rely on the context > > identifier carried as the destination address in IP header. > > > > A bypass tunnel MUST have the property that it is not affected by = the > > topology changes caused by the failure. Therefore, it can be used= to > > transmit traffic for local repair. It SHOULD remain effective, un= til > > the traffic is moved to another fully functional egress AC, PW and= /or > > transport tunnel. > > > > 4.6. Forwarding State on Protector > > > > A protector MUST learn PW labels from all the primary PEs that it > > protects (Section 5.2), and maintain the PW labels in respective > > label spaces of the primary PEs. In the control plane, a label sp= ace > > is identified by the context identifier of a pair of {primary PE, > > protector}. In the forwarding plane, it is indicated by the bypass > > tunnel(s) destined for the context identifier. > > > > SB> Are you saying that this mechanism mandates no PHP? > > > > [yshen] It mandates PHP for bypass tunnels only, as their labels serve = as > contexts on protectors. This is not mandatory for normal tunnels. > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 17= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > 4.6.1. Examples of Co-located Protector > > > > In Figure 7, PE4 is a co-located protector that protects PW1 again= st > > egress AC failure and egress node failure. It maintains a label > > space for PE2, which is identified by the context identifier of {P= E2, > > PE4}. It learns PW1's label from PE2, and installs an forwarding > > entry for the label in that label space. The nexthop of the > > forwarding entry indicates a label pop with outgoing interface > > pointing to the backup AC CE2-PE4. > > > > SB> I am not sure what you are describing in the above. Is this an > > MPLS operation or a PW operation. If the latter it is not a simple > > label pop. > > > > [yshen] It is PW label pop. > > > > In Figure 8, SPE2 is a co-located protector that protects PW1 agai= nst > > S-PE failure. It maintains a label space for SPE1, which is > > identified by the context identifier of {SPE1, SPE2}. It learns > > SEG1's label from SPE1, and installs a forwarding entry in the lab= el > > space. The nexthop of the forwarding entry indicates a label swap= to > > SEG4's label. > > > > 4.6.2. Examples of Centralized Protector > > > > In the centralized protector model, for each primary PW of which t= he > > protector is not a backup (S-)PE, the protector MUST also learn th= e > > label of the backup PW from the backup (S-)PE (Section 5.3). This= is > > the backup (S-)PE that the protector will forward traffic to. The > > protector MUST install a forwarding entry with label swap from the > > primary PW's label to the backup PW's label. > > > > In Figure 9, the protector is a centralized protector that protect= s > > PW1 against egress AC failure and egress node failure. It maintai= ns > > a label space for PE2, which is identified by the context identifi= er > > of {PE2, protector}. It learns PW1's label from PE2, and PW2's lab= el > > from PE4. It installs a forwarding entry for PW1's label in the > > label space. The nexthop of the forwarding entry indicates a labe= l > > swap to PW2's label. > > > > In Figure 10, the protector is a centralized protector that protec= ts > > the PW segment SEG1 of PW1 against the node failure of SPE1. It > > maintains a label space for SPE1, which is identified by the conte= xt > > identifier of {SPE1, protector}. It learns SEG1's label from SPE1, > > and learns SEG3's label from SPE2. It installs a forwarding entry > > for SEG1's label in the label space. The nexthop of the forwardin= g > > entry indicates a label swap to SEG3's label. > > > > 5. LDP Extensions > > > > As described in previous sections, a targeted LDP session MUST be > > established between each pair of primary PE and protector. The > > primary PE sends Label Mapping message over this session to advert= ise > > primary PW labels to the protector. In the centralized protector > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 18= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > model, a targeted LDP session MUST also be established between a > > backup (S-)PE and a protector. The backup PE sends Label Mapping > > message over this session to advertise backup PW labels to the > > protector. > > > > To facilitate the procedures, this document defines a new "Protect= ion > > FEC Element" TLV. The Label Mapping messages of both the LDP > > sessions above MUST carry this TLV to indicate the identity of a > > primary PW. Specifically, in the centralized protector model, the > > Protection FEC Element TLV advertised by a backup (S-)PE MUST matc= h > > the one advertised by the primary PE, so that the protector can > > associate the primary PW's label with the backup PW's label, and > > perform a label swap. > > > > This document also defines the encoding of Capability Parameter TL= V > > (RFC 5561) for a new "Egress Protection Capability", to allow a > > protector to announce its capability of processing the above > > Protection FEC Element TLV and performing context specific label > > switching for PW labels. > > > > The procedures in this section are only applicable, if the protect= or > > advertises the Egress Protection Capability, the primary PE suppor= ts > > the advertisement of the Protection FEC Element TLV, and in the > > centralized protector model, the backup PE also supports the > > advertisement of the Protection FEC Element TLV. > > > > 5.1. Egress Protection Capability TLV > > > > A protector MUST advertise the Egress Protection Capability TLV in > > its Initialization message and Capability message, over the LDP > > session with a primary PE. In the centralized protector model, th= e > > protector MUST also advertise the TLV over the LDP session with a > > backup PE. The TLV carries one or multiple context identifiers. = To > > the primary PE, the TLV SHOULD carry the context identifier of the > > {primary PE, protector}. In the centralized protector model, the T= LV > > SHOULD carry to the backup PE multiple context identifiers, one fo= r > > each {primary PE, protector} where the backup PE serves as a backu= p > > for the primary PE. This TLV SHOULD NOT be advertised by the prim= ary > > PE or the backup PE to the protector. > > > > The processing of the Egress Protection Capability TLV by a receiv= ing > > router SHOULD follow the procedures defined in RFC 5561. In > > particular, the router SHOULD advertise PW information to the > > protector by using the Protection FEC Element TLV, only after it h= as > > received the Egress Protection Capability TLV from the protector. = It > > SHOULD validate each context identifier included in the TLV, and > > advertise the information of only those PWs that are associated wi= th > > the context identifier. It SHOULD withdraw previously advertised > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 19= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > Protection FEC TLVs, when the protector has withdrawn a previously > > advertised context identifier or the entire Egress Protection > > Capability TLV via Capability message. > > > > The encoding of the Egress Protection Capability TLV is defined as > > below. It conforms to the format of Capability Parameter TLV > > specified in RFC 5561. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > |U|F| Egress Protection (TBD) | Length = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > |S| Reserved | = | > > +-+-+-+-+-+-+-+-+ = | > > | = | > > ~ Capability Data =3D context identifier(s) = ~ > > | = | > > | +-+-+-+-+-+-+-+-= + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 11 > > > > The U-bit MUST be set to 1 so that a receiver MUST silently ignore > > this TLV if unknown to it, and continue processing the rest of the > > message. > > > > The F-bit MUST be set to 0 since this TLV is sent only in > > Initialization and Capability messages, which are not forwarded. > > > > The TLV Code Point is TBD. It needs to be assigned by IANA. > > > > The S-bit indicates whether the sender is advertising (S=3D1) or > > withdrawing (S=3D0) the capability. > > > > The "Capability Data" is encoded with the context identifier of th= e > > {primary PE, protector}. > > > > SB> where is the structure of {primary PE, protector} defined? > > > > [yshen] The Protection FEC Element TLV carries the context ID of {prima= ry > PE, protector}. The {primary PE, protector} tuple itself is not encoded. > > > > 5.2. PW Label Distribution from Primary PE to Protector > > > > A primary PE SHOULD advertise a primary PW's label to a protector = by > > sending a Label Mapping message. The message includes a Protectio= n > > FEC Element TLV (see Section 5.4 for encoding), and an Upstream- > > Assigned Label TLV (RFC 6389) encoded with the PW's label. The > > combination of the Protection FEC Element TLV and the PW label > > represents the primary PE's forwarding state for the PW. The Labe= l > > Mapping message SHOULD also carry an IPv4/v6 Interface_ID TLV (RFC > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 20= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > 6389, RFC 3471) encoded with the context identifier of the {primar= y > > PE, protector}. > > > > The protector that receives this Label Mapping message SHOULD inst= all > > a forwarding entry for the PW label in the label space identified = by > > the context identifier. The nexthop of the forwarding entry SHOUL= D > > ensure packets to be sent towards the target CE via a backup AC or= a > > backup (S-)PE, depending on the protection scenario. The protecto= r > > SHOULD silently discard a Label Mapping message if the included > > context identifier is unknown to it. > > > > 5.3. PW Label Distribution from Backup PE to Protector > > > > In the centralized protector model, a backup PE SHOULD advertise a > > backup PW's label to a protector by sending a Label Mapping messag= e. > > The message includes a Protection FEC Element TLV and a Generic La= bel > > TLV encoded with the backup PW's label. This Protection FEC Eleme= nt > > MUST be identical to the Protection FEC Element TLV that the prima= ry > > PE advertises to the protector (Section 5.2). The context identif= ier > > SHOULD NOT be encoded in Interface_ID TLV in this message. > > > > The protector that receives this Label Mapping message SHOULD > > associate the backup PW with the primary PW, based on the common > > Protection FEC Element TLV. It SHOULD distinguish between the Lab= el > > Mapping message from the primary PE and the Label Mapping message > > from the backup PE based on the respective presence and absence of > > context identifier in Interface_ID TLV. It SHOULD install a > > forwarding entry for the primary PW's label in the label space > > identified by the context identifier. The nexthop of the forwardi= ng > > entry SHOULD indicate a label swap to the backup PW's label, follo= wed > > by a label push or IP header push for a transport tunnel to the > > backup PE. > > > > 5.4. Protection FEC Element TLV > > > > The Protection FEC Element TLV has type 0x83. Its format is defin= ed > > as below: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 21= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | Type(0x83) | Reserved | Encoding Type | Length = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | = | > > | = | > > ~ PW Information = ~ > > | = | > > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 12 > > > > - Encoding Type > > > > Type of format that PW Information field is encoded. > > > > - Length > > > > Length of PW Information field in octets. > > > > - PW Information > > > > Field of variable length that specifies a PW > > > > For Encoding Type, 1 is defined for the PWid FEC Element format, a= nd > > 2 is defined for the Generalized PWid FEC Element format (RFC 4447= ). > > > > > > 5.4.1. Encoding Format for PWid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 22= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | Type(0x83) | Reserved | Enc Type(1) | Length(16) = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | Ingress PE Address = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | Egress PE Address = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | Group ID = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | PW ID = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > |C| PW Type | Reserved = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > > > Figure 13 > > > > - Ingress PE Address > > > > IP address of the ingress PE of PW. > > > > - Egress PE Address > > > > IP address of the egress PE of PW. > > > > SB> How does this work for IPv6? > > > > - Group ID > > > > An arbitrary 32-bit value that represents a group of PWs and th= at > > is used to create groups in the PW space. > > > > - PW ID > > > > A non-zero 32-bit connection ID that, together with the PW Type > > field, identifies a particular PW. > > > > - Control word bit (C) > > > > A bit that flags the presence of a control word on this PW. If= C > > =3D 1, control word is present; If C =3D 0, control word is not > > present. > > > > - PW Type > > > > A 15-bit quantity that represents the type of PW. > > > > SB> Needs a ref > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 23= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > 5.4.2. Encoding Format for Generalized PWid > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | Type(0x83) | Reserved | Enc Type(2) | Length = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | Ingress PE Address = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | Egress PE Address = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > |C| PW Type | Reserved = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | AGI Type | Length | Value = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > ~ AGI Value (contd.) = ~ > > | = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | AII Type | Length | Value = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > ~ SAII Value (contd.) = ~ > > | = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > | AII Type | Length | Value = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > ~ TAII Value (contd.) = ~ > > | = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > > > Figure 14 > > > > - Ingress PE Address > > > > IP address of the ingress PE of PW. > > > > - Egress PE Address > > > > IP address of the egress PE of PW. > > > > SB> IPv6? > > > > - Control word bit (C) > > > > A bit that flags the presence of a control word on this PW. If= C > > =3D 1, control word is present; If C =3D 0, control word is not > > present. > > > > - PW Type > > > > A 15-bit quantity that represents the type of PW. > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 24= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > - AGI Type, Length, Value, AGI Value > > > > Attachment Group Identifier of PW. > > > > - SAII Type, Length, Value, SAII Value > > > > Source Attachment Individual Identifier of PW. > > > > - TAII Type, Length, Value, TAII Value > > > > Target Attachment Individual Identifier of PW. > > > > 6. Revertive Behavior > > > > Subsequent to local repair, there are three strategies for the > > network to restore traffic to a fully functional PW. > > > > o Global revertive mode > > > > If the ingress CE is multi-homed (Figure 1), it MAY switch the > > traffic to a backup AC which is bound to a backup PW. > > Alternatively, if the ingress PE hosts a backup PW (Figure 2), = the > > ingress PE MAY switch the traffic to the backup PW. These > > procedures are referred to as global repair. Possible triggers= of > > a global repair include PW status, OAM, and BFD. > > > > o Control plane revertive mode > > > > In egress PE node protection and S-PE node protection, it is > > possible that the failure is limited to the link between the PL= R > > and the primary (S-)PE, whereas the primary (S-)PE is still up. > > In this case, the PLR or an upstream router along the transport > > tunnel MAY reroute the tunnel around the failed link via an > > alternative path. Thus, the transport tunnel can continue to b= e > > used to carry the PW traffic to the primary (S-)PE. This > > procedure is driven by control plane convergence, and is referr= ed > > to as control plane repair. > > > > o Local revertive mode > > > > The PLR MAY move traffic back to the primary PW, after the fail= ure > > is resolved. In egress AC protection, upon detecting that the > > primary AC is restored, the PLR MAY start forwarding traffic ov= er > > the AC again. Likewise, in egress PE node protection and S-PE > > node protection, upon detecting that the primary PE is restored= , > > the PLR MAY re-establish the primary transport tunnel through t= he > > primary PE, and move the traffic from the bypass tunnel back to > > > > > > > > > > Yimin Shen, et al. Expires January 25, 2015 [Page 25= ] > > > > > > Internet-Draft PW Endpoint Fast Failure Protection July 201= 4 > > > > > > the transport tunnel. These procedures are referred to as loca= l > > reversion. > > > > The fast protection mechanism in this document SHOULD be used in > > tandem with the global revertive mode. Particularly in the case o= f > > egress (S-)PE failure, if the ingress PE or the protector loses > > communication with the (S-)PE for an extensive period of time, the > > LDP session between them may go down. Consequently, the ingress P= E > > may bring down the primary PW, or the protector may remove the > > forwarding entry of the primary PW label. In either case, the > > service will be disrupted. In other words, although the fast > > protection can temporarily repair traffic, control plane state may > > eventually be timed out if the failure persists. Therefore, it is > > recommended that the global revertive mode SHOULD be set up in > > advance, so that traffic can be moved to a fully functional backup= PW > > shortly after the local repair. > > > > The control plane revertive mode may always happen as part of the > > convergence of control plane protocols. However, it is only > > applicable to the specific scenarios described above. > > > > The local revertive mode is optional. In the circumstances where = the > > failure is caused by resource flapping, local reversion MAY be > > dampened to limit potential disruptions. Local revertive mode MAY= be > > disabled completely by configuration. > > > > 7. IANA Considerations > > > > This document defines the encoding of the Capability Parameter TLV > > for the new "Egress Protection Capability" in Section 5. This wou= ld > > require IANA to assign a TLV Code Point to it. > > > > This document defines a new LDP Protection FEC Element TLV in > > Section 5. IANA has assigned the type value 0x83 to it. > > > > SB> I am very confused about what explicit actions you are asking IANA > > to take. Are you saying that there are no IANA actions? > > > > [yshen] Need IANA to assign a TLV code to "Egress Protection Capability= ", > as said above. > > > > 8. Security Considerations > > > > The security considerations discussed in RFC 5036, RFC 5331, RFC > > 3209, and RFC 4090 apply to this document. > > > > SB> Are there any PW security considerations that apply? > > > > SB> This is a new PW operational mode, so I am surprised that there are > > no new security considerations. An early security review might be usefu= l. > > > > > > [yshen] Not sure about any specific security issues. > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > . > > >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Aug 5 06:38:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490471B27D1; Tue, 5 Aug 2014 06:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 YwloADJvZ1WZ; Tue, 5 Aug 2014 06:38:10 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636721A8BB5; Tue, 5 Aug 2014 06:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=997; q=dns/txt; s=iport; t=1407245891; x=1408455491; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=157zYB1qYYIXEXD7Szi0I4m9qtzFzogede/B9V6gN1c=; b=Md9bM+5Yn4wcJu5RJsWHlaHtxICZB6mIhdBzodiVI1aXXqbI2uxclkz/ qBJ3dbVouxcAtXWgkBAR0r02jZCAi7vojXuHWe4NJaQ5uhAEImD8akwFD H20chkT6nch2z25AXkfaF852hwFKB8i992K61WlbMBfrRFcTwr/1+FUYw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEACrd4FOtJssW/2dsb2JhbABb13EBgSl3hAQBAQQdG0ABEAsSDxYPCQMCAQIBNw4GAQwBBwEBiD6zB5AeF4wdgy8HhEsBBJwNhyONPoIHgUc X-IronPort-AV: E=Sophos;i="5.01,804,1400025600"; d="scan'208";a="129128835" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 05 Aug 2014 13:38:08 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s75Dc6Ag004210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2014 13:38:06 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s75Dc412009507; Tue, 5 Aug 2014 14:38:05 +0100 (BST) Message-ID: <53E0DE3E.5030901@cisco.com> Date: Tue, 05 Aug 2014 14:38:06 +0100 From: Stewart Bryant 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: Alexander Vainshtein , Yimin Shen References: <53D7B569.60400@cisco.com> <53E0B85B.8060707@cisco.com> 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/mpls/ZNJDJdA6pyIiJb7EKZV2NagXuAM Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 13:38:16 -0000 >>> [1] This draft is completely based on the PWE3 and the MS-PW >> architecture. It is also based on RFC 5331 " MPLS Upstream Label Assignment >> and Context-Specific Label Space". So ideally readers should be familiar with >> that RFC. >> As far as I can see context labels have not been introduced >> into the PWE3 architecture. There is some reference to their use for >> P2MP PWs, but not in the P2P case. Indeed I think that RFC4447 >> notes explicitly that in the case where the configuration of PWs >> is signaled by LDP the platform label space must be used. The >> least that you need to do is to update RFC4447. >> > [[Sasha]] yes, RFC 4447 explicitly requires the PW labels to be allocated from the per-platform label space. > And according to RFC 5331 per-platform label space is a special case of the label context. However RRC5331 does not update RFC4447, so it must be assumed that the original definition of per-platform label space applies to PWs. - Stewart From nobody Tue Aug 5 06:59:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B77D1B27C6; Tue, 5 Aug 2014 06:59: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, 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 G-_8fT1Ea7xE; Tue, 5 Aug 2014 06:59:54 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0082.outbound.protection.outlook.com [213.199.154.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0141B1B27BC; Tue, 5 Aug 2014 06:59:53 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB419.eurprd03.prod.outlook.com (10.242.110.148) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 5 Aug 2014 13:59:52 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 5 Aug 2014 13:59:50 +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.0995.014; Tue, 5 Aug 2014 13:59:50 +0000 From: Alexander Vainshtein To: "stbryant@cisco.com" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 Thread-Index: AQHPsLKATtmDXehXFE2xGhx0gc5WeZvCCNcA Date: Tue, 5 Aug 2014 13:59:49 +0000 Message-ID: <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> References: <53D7B569.60400@cisco.com> <53E0B85B.8060707@cisco.com> <53E0DE3E.5030901@cisco.com> In-Reply-To: <53E0DE3E.5030901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02945962BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(51694002)(189002)(51704005)(13464003)(252514010)(377454003)(101416001)(76576001)(66066001)(74316001)(86362001)(74662001)(83072002)(80022001)(74502001)(20776003)(87936001)(106356001)(105586002)(81542001)(85306004)(106116001)(21056001)(64706001)(46102001)(81342001)(107046002)(85852003)(79102001)(33646002)(4396001)(77982001)(92566001)(110136001)(54356999)(99396002)(50986999)(19580405001)(76176999)(2656002)(2351001)(95666004)(93886004)(83322001)(19580395003)(76482001)(31966008)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB612; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kdYOPGz2a15OoyMi04sKcs1c_Ig Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 13:59:57 -0000 Stewart, I fully agree with you that using PW labels from a label space that is not= a per-platform one requires an explicit update to RFC 4447. My comment on this point has been triggered by your saying that you *think*= that RFC 4447 explicitly requires per-platform label space. Just wanted to clarify that this is indeed the case. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, August 05, 2014 4:38 PM > To: Alexander Vainshtein; Yimin Shen > Cc: mpls@ietf.org; pwe3; pwe3-chairs@tools.ietf.org > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 - RFC4447 >=20 >=20 > >>> [1] This draft is completely based on the PWE3 and the MS-PW > >> architecture. It is also based on RFC 5331 " MPLS Upstream Label > >> Assignment and Context-Specific Label Space". So ideally readers > >> should be familiar with that RFC. > >> As far as I can see context labels have not been introduced into the > >> PWE3 architecture. There is some reference to their use for P2MP PWs, > >> but not in the P2P case. Indeed I think that RFC4447 notes explicitly > >> that in the case where the configuration of PWs is signaled by LDP > >> the platform label space must be used. The least that you need to do > >> is to update RFC4447. > >> > > [[Sasha]] yes, RFC 4447 explicitly requires the PW labels to be allocat= ed > from the per-platform label space. > > And according to RFC 5331 per-platform label space is a special case of= the > label context. > However RRC5331 does not update RFC4447, so it must be assumed that the > original definition of per-platform label space applies to PWs. >=20 > - Stewart >=20 From nobody Tue Aug 5 07:53:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7915E1B2852; Tue, 5 Aug 2014 07:53: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, 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 nwQABhmy5u-L; Tue, 5 Aug 2014 07:53:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2215E1B27F6; Tue, 5 Aug 2014 07:53:51 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 5 Aug 2014 14:53:49 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Tue, 5 Aug 2014 14:53:49 +0000 From: Yimin Shen To: Alexander Vainshtein , "stbryant@cisco.com" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 Thread-Index: AQHPsLKAX28iK6GR00WfEHEZOVjN8pvCCaWAgAAAMWA= Date: Tue, 5 Aug 2014 14:53:49 +0000 Message-ID: <35ea5a386fa84b498eaf682370f7c6d4@BY2PR05MB728.namprd05.prod.outlook.com> References: <53D7B569.60400@cisco.com> <53E0B85B.8060707@cisco.com> <53E0DE3E.5030901@cisco.com> <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02945962BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51694002)(252514010)(189002)(199002)(164054003)(51704005)(377454003)(13464003)(2656002)(77982001)(79102001)(80022001)(105586002)(95666004)(101416001)(66066001)(64706001)(106116001)(99286002)(106356001)(4396001)(81542001)(20776003)(99396002)(74662001)(74316001)(74502001)(85306004)(92566001)(46102001)(21056001)(76576001)(76176999)(31966008)(87936001)(19580395003)(93886004)(81342001)(83322001)(50986999)(83072002)(54356999)(33646002)(85852003)(107046002)(86362001)(76482001)(19580405001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB728; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX: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/mpls/3MD6qihZVrYC3a6M-sd4ZtMygvc Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 14:53:57 -0000 Hi Stewart, Sasha, Every PE allocates PW labels from per-platform label space. This draft does= n't change this. In addition, a protector maintains a separate label table = for each primary/protected PE that it protects. This label table contains t= he PW labels allocated by the primary/protected PE from its own "per-platfo= rm" label space. Hope this clarifies it. Thanks, /Yimin -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Tuesday, August 05, 2014 10:00 AM To: stbryant@cisco.com Cc: mpls@ietf.org; pwe3; pwe3-chairs@tools.ietf.org; Yimin Shen Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protecti= on-01 - RFC4447 Stewart, I fully agree with you that using PW labels from a label space that is not= a per-platform one requires an explicit update to RFC 4447. My comment on this point has been triggered by your saying that you *think*= that RFC 4447 explicitly requires per-platform label space. Just wanted to clarify that this is indeed the case. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, August 05, 2014 4:38 PM > To: Alexander Vainshtein; Yimin Shen > Cc: mpls@ietf.org; pwe3; pwe3-chairs@tools.ietf.org > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 - RFC4447 >=20 >=20 > >>> [1] This draft is completely based on the PWE3 and the MS-PW > >> architecture. It is also based on RFC 5331 " MPLS Upstream Label > >> Assignment and Context-Specific Label Space". So ideally readers > >> should be familiar with that RFC. > >> As far as I can see context labels have not been introduced into the > >> PWE3 architecture. There is some reference to their use for P2MP PWs, > >> but not in the P2P case. Indeed I think that RFC4447 notes explicitly > >> that in the case where the configuration of PWs is signaled by LDP > >> the platform label space must be used. The least that you need to do > >> is to update RFC4447. > >> > > [[Sasha]] yes, RFC 4447 explicitly requires the PW labels to be allocat= ed > from the per-platform label space. > > And according to RFC 5331 per-platform label space is a special case of= the > label context. > However RRC5331 does not update RFC4447, so it must be assumed that the > original definition of per-platform label space applies to PWs. >=20 > - Stewart >=20 From nobody Tue Aug 5 09:12:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66491B2A66; Tue, 5 Aug 2014 09:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 JLhYG2WCcMXA; Tue, 5 Aug 2014 09:12:22 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5981B2A4C; Tue, 5 Aug 2014 09:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2873; q=dns/txt; s=iport; t=1407255142; x=1408464742; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ymRrSg6cUOTCj8PEjinba2PTql7JnrDqg43mtDLneD4=; b=HyW7lr5KXtHaJh4SRXc/q5l+/lkwp4vtvRIumQZ61XLG1Y8aP1FwdzY8 bltLbnzpxPBhvoAnZdCHbvKJTa4OoC+LiucAXBa8cextyWyt1qPDPNDHy 5rvogytSjadw7jgcWa3QJPRdtfTCeqCvgSHuIS/aQVjKzKvG1Eb6W22ae A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEAGkB4VOtJssW/2dsb2JhbABbg19Xy3OHSAGBK3eEAwEBAQQdG0ABDAQLDgMBAwEBAQkWCAcJAwIBAgE0AwYIBgEMAQUCAQGIPg2zKpAhF4wdgk0RAS4iBwaERQEEnA2HI40+ggeBR2sBgQw X-IronPort-AV: E=Sophos;i="5.01,805,1400025600"; d="scan'208";a="129262628" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 05 Aug 2014 16:12:19 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s75GCJxT020864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2014 16:12:19 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s75GCGLN011020; Tue, 5 Aug 2014 17:12:16 +0100 (BST) Message-ID: <53E10263.6040905@cisco.com> Date: Tue, 05 Aug 2014 17:12:19 +0100 From: Stewart Bryant 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: Yimin Shen , Alexander Vainshtein References: <53D7B569.60400@cisco.com> <53E0B85B.8060707@cisco.com> <53E0DE3E.5030901@cisco.com> <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <35ea5a386fa84b498eaf682370f7c6d4@BY2PR05MB728.namprd05.prod.outlook.com> In-Reply-To: <35ea5a386fa84b498eaf682370f7c6d4@BY2PR05MB728.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hw3mdmYQMPmTn2ep-QK5gQ6F1VM Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 16:12:31 -0000 On 05/08/2014 15:53, Yimin Shen wrote: > Hi Stewart, Sasha, > > Every PE allocates PW labels from per-platform label space. This draft doesn't change this. In addition, a protector maintains a separate label table for each primary/protected PE that it protects. This label table contains the PW labels allocated by the primary/protected PE from its own "per-platform" label space. Hope this clarifies it. > > > Thanks, > > /Yimin This all needs to be much clearer in the draft. The protector in this context is I assume the receiving PE, not the protecting PE? S > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, August 05, 2014 10:00 AM > To: stbryant@cisco.com > Cc: mpls@ietf.org; pwe3; pwe3-chairs@tools.ietf.org; Yimin Shen > Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 > > Stewart, > I fully agree with you that using PW labels from a label space that is not a per-platform one requires an explicit update to RFC 4447. > My comment on this point has been triggered by your saying that you *think* that RFC 4447 explicitly requires per-platform label space. > Just wanted to clarify that this is indeed the case. > > Regards, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 > > >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Tuesday, August 05, 2014 4:38 PM >> To: Alexander Vainshtein; Yimin Shen >> Cc: mpls@ietf.org; pwe3; pwe3-chairs@tools.ietf.org >> Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- >> protection-01 - RFC4447 >> >> >>>>> [1] This draft is completely based on the PWE3 and the MS-PW >>>> architecture. It is also based on RFC 5331 " MPLS Upstream Label >>>> Assignment and Context-Specific Label Space". So ideally readers >>>> should be familiar with that RFC. >>>> As far as I can see context labels have not been introduced into the >>>> PWE3 architecture. There is some reference to their use for P2MP PWs, >>>> but not in the P2P case. Indeed I think that RFC4447 notes explicitly >>>> that in the case where the configuration of PWs is signaled by LDP >>>> the platform label space must be used. The least that you need to do >>>> is to update RFC4447. >>>> >>> [[Sasha]] yes, RFC 4447 explicitly requires the PW labels to be allocated >> from the per-platform label space. >>> And according to RFC 5331 per-platform label space is a special case of the >> label context. >> However RRC5331 does not update RFC4447, so it must be assumed that the >> original definition of per-platform label space applies to PWs. >> >> - Stewart >> > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Tue Aug 5 11:44:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C811B2AD4; Tue, 5 Aug 2014 11:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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=-0.001, 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 OkLfPFr0XQys; Tue, 5 Aug 2014 11:44:18 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1869D1B2ACE; Tue, 5 Aug 2014 11:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32592; q=dns/txt; s=iport; t=1407264258; x=1408473858; h=from:to:cc:subject:date:message-id:mime-version; bh=SrHOEkIq+qOBByHZMNgnNJ1VoXwNhgI8PjQgj004b+0=; b=M73yn2vkbNYCsnrag5TOS68Igbq64zY0lWzHg3dpkThuGGJenYsW/jxr PWeGD2GR9SD5Etwk0KU9mRzELeTbWYfIvK5K/o+Ov2fkQTdqC4TqkdhsN YBthjbqZka3gou6s6MDwIBWoqD7V2HqzqRoc2fQV2bgCUB270ZGR6460H I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoHABwl4VOtJV2c/2dsb2JhbABbgkdGUlcBA4JzyH+HSBp9FneECiMEUhIBHCQKAgQwJwQOIIgnDaxLlxYXjUaBdRGDAIFSBY57hi+CN4QsgVSTDYNNbYFF X-IronPort-AV: E=Sophos;i="5.01,806,1400025600"; d="scan'208,217";a="345253569" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 05 Aug 2014 18:44:01 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s75Ii1bK027505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 18:44:01 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.66]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 13:44:01 -0500 From: "Alvaro Retana (aretana)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: AQHPsN05Fz/zKfFp40GaWihT2u/peQ== Date: Tue, 5 Aug 2014 18:44:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_D0069E2E65909aretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/GFTHysQ2iS44WW-eIW0CRwgEXNE Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 18:44:21 -0000 --_000_D0069E2E65909aretanaciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJl dmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3Mg dGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24g c3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUg YXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI+DQoNCkFsdGhvdWdoIHRoZXNlIGNvbW1l bnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3Vs ZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90 aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUg dG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJh ZnQuDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLW1wbHMtaXB2Ni1vbmx5LWdhcC0wMSAoR2FwIEFu YWx5c2lzIGZvciBPcGVyYXRpbmcgSVB2Ni1vbmx5IE1QTFMgTmV0d29ya3MpDQpSZXZpZXdlcjog QWx2YXJvIFJldGFuYQ0KUmV2aWV3IERhdGU6IEF1Zy4gNSwgMjAxNC4NCklFVEYgTEMgRW5kIERh dGU6IEF1Zy4gOCwgMjAxNC4NCkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25hbA0KDQpTdW1t YXJ5Og0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0 IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KQ29tbWVu dHM6DQoNClRoaXMgZHJhZnQgY292ZXJzIGEgd2lkZSB2YXJpZXR5IG9mIHRlY2hub2xvZ3kgdG8g ZmluZCBnYXBzIHRoYXQgbWF5IHByZXZlbnQgdGhlIHVzZSBvZiBJUHY2LW9ubHkgTVBMUyBuZXR3 b3Jrcy4gIEl0IGRvZXMgc28gaW4gYSBjb25jaXNlIGFuZCBjbGVhciBmb3JtLCBhbiBlYXN5IHJl YWQuICBJIGJlbGlldmUgdGhhdCB0aGlzIHdvcmsgaXMgdmVyeSB2YWx1YWJsZSBnaXZlbiwgYXMg dGhlIGRyYWZ0IHB1dHMgaXQsIHRoYXQgIklQdjYgaXMgYW4gaW50ZWdyYWwgcGFydCBvZiBtb2Rl cm4gbmV0d29yayBkZXBsb3ltZW50cyIuDQoNCkkgZG8gaGF2ZSBhIGNvdXBsZSBvZiBoaWdoLWxl dmVsIGl0ZW1zIEkgd2FudCB0byBicmluZyB1cC4gIEJlY2F1c2UgSSBhc3N1bWUgdGhhdCB0aGVz ZSBtYXkgaGF2ZSBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBhcHByb3ByaWF0ZSBXRyhz KSBJJ20gbm90IGxpc3RpbmcgdGhlbSBhcyBtYWpvciBpc3N1ZXMsIGFuZCB3aWxsIGRlZmVyIHRv IHdoYXQgdGhlIGNvbnNlbnN1cyBoYXMgYmVlbiBzbyBmYXIuDQoNCiAgMS4gIFdoeSBkbyB3ZSBu ZWVkIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudD8gIEFzIEkgc2FpZCBhYm92ZSwgSSBiZWxpZXZl IHRoZSB3b3JrIGlzIHZhbHVhYmxlLCBidXQgaXQgY2FwdHVyZXMgdGhlIHN0YXRlIGluIHRpbWUg KHRvZGF5ISkgb2YgdGhlIGdhcHMg4oCUIGl0IHBvaW50cyB0byB3b3JrIHRoYXQgYWxyZWFkeSBz b2x2ZWQgYSBwb3RlbnRpYWwgZ2FwLCBvciBpcyBpbiB0aGUgcHJvY2VzcyBvZiBzb2x2aW5nIHRo ZW0uICBBIHNpZ25pZmljYW50IHBvcnRpb24gb2YgdGhlIGdhcHMgYXJlIGFscmVhZHkgYmVpbmcg YWRkcmVzc2VkLiAgR2l2ZW4gdGhlIGltcG9ydGFuY2Ugb2YgSVB2NiwgaWYgcHVibGlzaGVkLCBz b29uIHRoaXMgZG9jdW1lbnQgd2lsbCBoYXZlIHRvIGJlIHVwZGF0ZWQgdG8gc2F5ICJub3RoaW5n IGJyZWFrcyIuICBBZ2FpbiwgdGhlIHdvcmsgaXMgaW1wb3J0YW50LCBidXQgaXQgbWF5IGJlIGJl dHRlciBzdWl0ZWQgdG8gYmUgYSAibGl2aW5nIGRvY3VtZW50IiBhcyBhIGd1aWRlIGZvciB3aGF0 IHN0aWxsIG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4gIElmIGl0IGlzIHRvIGJlIHB1Ymxpc2hlZCwg SSB3b3VsZCBzdWdnZXN0IGF2b2lkaW5nIGxpbmtzIHRvIHdvcmsgaW4gcHJvZ3Jlc3MsIGJ1dCBs aW1pdGluZyB0aGUgY29udGVudCB0byBpZGVudGlmeWluZyB0aGUgZ2Fwcy4uYW5kIHRoZW4gbGV0 dGluZyB0aGUgc29sdXRpb24gZHJhZnRzL1JGQ3MgcG9pbnQgYmFjayB0byB0aGlzIGRvY3VtZW50 Li4gIChhbGEgcmVxdWlyZW1lbnRzIC0+IHNvbHV0aW9uKQ0KICAyLiAgSXQgaXMgaW50ZXJlc3Rp bmcgdG8gbWUgdGhhdCB0aGlzIGRyYWZ0IGNhbWUgdGhyb3VnaCB0aGUgbXBscyBXRywgYW5kIG5v dCBvbmUgb2YgdGhlIG9wZXJhdGlvbnMtZm9jdXNlZCBncm91cHMuLndoaWNoIHByZXN1bWFibHkg d291bGQgYmUgaW4gYSBiZXR0ZXIgcG9zaXRpb24gdG8gZXZhbHVhdGUgdGhlIG5lZWRzIGRlc2Ny aWJlZC4gIEdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGlzIGFscmVhZHkgaW4gV0cgTGFzdCBDYWxs LCBJJ20gYXNzdW1pbmcgdGhhdCB0aGUgYWxpZ25tZW50IGhhcyBhbHJlYWR5IGJlZW4gZGlzY3Vz c2VkIGFuZCB0aGF0IHByb3BlciBjcm9zcy1XRyByZXZpZXdzIGhhdmUgb2NjdXJyZWQuDQoNCk1h am9yIElzc3VlczoNCg0KTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KDQpNaW5vciBJc3N1ZXM6DQoN CiAgKiAgIFNvbWUgdGVybWlub2xvZ3kgd2FzIG5vdCBleHBhbmRlZCBiZWZvcmUvd2hlbiBpdCB3 YXMgZmlyc3QgdXNlZDogd2UgYWxsIGtub3cgd2hhdCBNUExTIGlzLCBidXQgb3RoZXJzIGxpa2Ug TFNSLCBMRVIsIEZFQywgTDJWUE4sIEVWUE4sIE5HLW1WUE4sIGV0Yy4gc2hvdWxkIGJlIGV4cGFu ZGVkLg0KICAqICAgU2VjdGlvbiAzLjEgKE1QTFMgRGF0YSBQbGFuZSk6ICJJbiB0aGUgY2FzZSB3 aGVyZSBhbiBJUHY0IHByZWZpeCBpcyByZXNvbHZlZCBvdmVyIGFuIElQdjYgTFNQLCBhbiBJUHY2 IEV4cGxpY2l0IE51bGwgbGFiZWwgY2Fubm90IGltbWVkaWF0ZWx5IHByZWNlZWQgYW4gSVB2NCBw YWNrZXQuIiAgSXMgdGhlcmUgYSByZWZlcmVuY2UgZm9yIHRoaXMgc3RhdGVtZW50IG9yIGlzIHRo aXMgYSByZXF1aXJlbWVudCB0byBmaWxsIGluIHRoZSBnYXA/ICBJZiBpdCBpcyBhIHJlcXVpcmVt ZW50LCBkbyB3ZSBuZWVkIHRvIGFkZCAyMTE5IGxhbmd1YWdlPw0KICAqICAgV2hlbiBhIGdhcCBl eGlzdHMsIHlvdSBjbGFzc2lmeSBpdCBhcyAibWFqb3IiIG9yICJtaW5vciIuICBXaGF0IGlzIHRo ZSBjcml0ZXJpYSB1c2VkPyAgSSB3b3VsZCBpbWFnaW5lIHRoYXQgZ2l2ZW4gdGhhdCBpdCBpcyBh IGdhcCBhbmFseXNpcywgdGhlIG9iamVjdGl2ZSBpcyB0byBwb2ludCBvdXQgdGhlIG5lZWRzLCBu b3QgY2hhcmFjdGVyaXplIHRoZW0gKGlmIEkgbmVlZCBhICJtaW5vciIgZ2FwIHRvIGJlIGZpbGxl ZCBpbiBvcmRlciBmb3IgbXkgbmV0d29yayBkZXBsb3ltZW50IHRvIG9wZXJhdGUsIGl0IGJlY29t ZXMgIm1ham9yIiB0byBtZSkuDQogICogICBUaGUgaW50cm9kdWN0aW9uIHRvIHRoZSBkcmFmdCB0 YWxrcyBhYm91dCAiZ2FwcyB0aGF0IG11c3QgYmUgYWRkcmVzc2VkIGluIG9yZGVyIHRvIGFsbG93 IE1QTFMtcmVsYXRlZCBwcm90b2NvbHMgYW5kIGFwcGxpY2F0aW9ucyB0byBiZSB1c2VkIHdpdGgg SVB2Ni1vbmx5IG5ldHdvcmtzIiAoIklQdjYtb25seSAobm8gSVB2NCBwcm92aXNpb25lZCBvbiB0 aGUgZGV2aWNlKSIpLCB3aGljaCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IG5vIElQdjQgaXMg cHJlc2VudCBpbiB0aGUgbmV0d29yayBhdCBhbGwuICAgSG93ZXZlciwgc2V2ZXJhbCBnYXBzIGFy ZSBpZGVudGlmaWVkIHRoYXQgb2NjdXIgaW4gIm1peGVkIiBuZXR3b3Jrcywgd2hlcmUgaXNsYW5k cyBvZiBJUHY0L0lQdjYgZXhpc3QuICBJIHdvdWxkIHN1Z2dlc3QgY2xhcmlmeWluZyB0aGUgc2Nv cGUgb2YgdGhlIGRvY3VtZW50IGluIHRoZSBpbnRyb2R1Y3Rpb24uICBTb21lIG9mIHRoZSBwbGFj ZXMgd2hlcmUgdGhlc2Ugc2NlbmFyaW9zIGFyZSBkaXNjdXNzZWQgaW5jbHVkZTogIDMuMi4yLiAo TXVsdGlwb2ludCBMRFApLCAzLjMuMi4gKEwzVlBOKSwgIDMuNC4xLiAoRXh0ZW5kZWQgSUNNUCkg YW5kIDMuNC4yLiAoTFNQIFBpbmcpLg0KICAqICAgMy4zLjEuMS4gKEVWUE4pICBJZiB0aGUgRVZQ TiB3b3JrIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50LCB0aGVuIHRha2UgaXQg b3V0LiAgQW5vdGhlciBvcHRpb24gbWF5IGJlIHRvIHRhbGsgYWJvdXQgYW55IGdhcHMgaW4gdGhl IGN1cnJlbnQgd29yay4gIFNhbWUgY29tbWVudCBmb3Igc2VjdGlvbiAzLjMuMi40LjMuIChQRS1Q RSBNdWx0aWNhc3QgUm91dGluZyBQcm90b2NvbCkuDQogICogICAzLjMuMi4gKEwzVlBOKSAgdGhl IHRleHQgc2F5cyB0aGF0IHRoZSBnYXBzIGluIFJGQzQzNjQgKG5vIFZQTi1JUHY2IGFkZHJlc3Mg YW5kIGEgMTI4IGJpdCBuZXh0LWhvcCkgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiBSRkMgNDY1OSwg YnV0IGl0IHRoZW4gaWRlbnRpZmllcyB0aGUgZ2FwIGFuZCBzYXlzIHRoYXQgIlJGQzQzNjQgbXVz dCBiZSB1cGRhdGVkIi4gIFdoYXQgd291bGQgdGhhdCB1cGRhdGUgYmU/DQogICogICBTZWN0aW9u cyAzLjMuMi40LjMuIChQRS1QRSBNdWx0aWNhc3QgUm91dGluZyBQcm90b2NvbCksIDMuMy4zLiAo TVBMUy1UUCkgYW5kIDMuNC41LiAoTVBMUy1UUCBPQU0pIGFyZSBpbmNsdWRlZCwgYnV0IG91dCBv ZiBzY29wZS4uICBTaG91bGQgdGhleSBiZSByZW1vdmVkPyAgSWYgbm90LCB0aGVuIGEgc2hvcnQg anVzdGlmaWNhdGlvbiBpbiB0aGUgdGV4dCB3b3VsZCBiZSBuaWNlLg0KICAqICAgMy40LiAoTVBM UyBPQU0pICBUaGlzIHNlbnRlbmNlICJBbGwgb2YgdGhlc2UgbWVjaGFuaXNtcyB3b3JrIGluIHB1 cmUgSVB2NiBlbnZpcm9ubWVudHMuIiBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IGFsbCB0aGUg bWVjaGFuaXNtcyB3b3JrIGNvcnJlY3RseSBhbmQgdGhhdCB0aGVyZSBhcmUgbm8gZ2Fwcy4uYnV0 IHRoZW4gc2V2ZXJhbCBnYXBzIGFyZSBsaXN0ZWQuDQogICogICBUYWJsZSAxOiBJUHY2LW9ubHkg TVBMUyBHYXBzLiAgVGhlIHRhYmxlIGRvZXNuJ3QgaW5jbHVkZSBhbGwgdGhlIGdhcHMgaWRlbnRp ZmllZC4gIEZvciBleGFtcGxlLCAzLjIuMi4gKE11bHRpcG9pbnQgTERQKSBpcyBub3QgaW5jbHVk ZWQgaW4gdGhlIHRhYmxlLCBldmVuIHRob3VnaCBhIG1ham9yIGdhcCB3YXMgaWRlbnRpZmllZC4g IEluIHRoaXMgY2FzZSwgdGhlIHdvcmsgaW4gdGhlIHRhYmxlIGZvciBMRFAgbWF5IGFsc28gYWRk cmVzcyB0aGUgZ2FwIGluIG1MRFAsIGJ1dCB0aGF0IGlzIG5vdCBwb2ludGVkIG91dCBpbiB0aGUg dGFibGUuLiAgSW4gc2hvcnQsIHRoZSB0YWJsZSBpcyBub3QgY29tcGxldGUuDQogICogICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucy4gIFRoaXMgc2VjdGlvbiB0YWxrcyBhYm91dCBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBpbiBjdXJyZW50IHNwZWNpZmljYXRpb25zLi5idXQgaXQgbGVhdmVzIG91 dCBtZW50aW9uIG9mIHRoZSBmYWN0IHRoYXQgbmV3IHNwZWNpZmljYXRpb25zICh0byBjbG9zZSB0 aGUgZ2Fwcykgc2hvdWxkIChNVVNUID8pIGNvbnNpZGVyIHRoZSBlZmZlY3Qgb2YgSVB2Ni4NCg0K Tml0czoNCg0KICAqICAgU2VjdGlvbiAyIChVc2UgQ2FzZSk6ICBzL2F0IGxlYXN0IG9uZS9vbmUg KGdlbmVyYWwpDQogICogICBTZWN0aW9uIDMgKEdhcCBBbmFseXNpcykuICBZb3Ugd3JvdGU6ICJU aGlzIGdhcCBhbmFseXNpcyBhaW1zIHRvIGFuc3dlciB0aGUgcXVlc3Rpb24sICJ3aGF0IGJyZWFr cyB3aGVuIG9uZSBhdHRlbXB0cyB0byB1c2UgTVBMUyBmZWF0dXJlcyBvbiBhIG5ldHdvcmsgb2Yg SVB2Ni1vbmx5IGRldmljZXM/IiAgV2hpbGUgSSB1bmRlcnN0YW5kIHdoYXQgeW91J3JlIGFza2lu ZywgaW4gcmVhbGl0eSB5b3UncmUgdHJ5aW5nIHRvIGFuc3dlciAid2hhdCBkb2Vzbid0IHdvcmsu LiIuICBCcmVha2luZyBpbXBsaWVzIHRoYXQgaXQgbWF5IHdvcmsgZm9yIGEgd2hpbGUgYW5kIHRo ZW4gc3RvcCBkb2luZyBzby4NCiAgKiAgIFNlY3Rpb24gMy4xIChNUExTIERhdGEgUGxhbmUpOiAg cy9wcmVjZWVkL3ByZWNlZGUNCiAgKiAgIDMuMi4yLiAoTXVsdGlwb2ludCBMRFApICBBIHJlZmVy ZW5jZSBiYWNrIHRvIHRoZSBMRFAgc2VjdGlvbiB3b3VsZCBiZSBuaWNlIGluIHBvaW50IDEuDQog ICogICAzLjIuMi4gKE11bHRpcG9pbnQgTERQKSAtIFBvaW50IDIuICBzL2xvb2t1cCBhZ2FpbnN0 IHJvb3QgYWRkcmVzcy9sb29rdXAgYWdhaW5zdCB0aGUgcm9vdCBhZGRyZXNzDQogICogICAzLjIu Mi4gKE11bHRpcG9pbnQgTERQKSBzL3Rocm91Z2ggdGhlIHByb2NlZHVyZXMgc2ltaWxhciB0byBS RkM2NTEyL3Rocm91Z2ggcHJvY2VkdXJlcyBzaW1pbGFyIHRvIFJGQzY1MTIgICAgQlRXLCB0aGUg bGFzdCBzZW50ZW5jZSBpbiB0aGlzIHNhbWUgcGFyYWdyYXBoIHNlZW1zIHJlZHVuZGFudCB0byBt ZS4NCiAgKiAgIDMuMi4zLiAoUlNWUC0gVEUpICBzL3Byb2NlZHVyZXMgJmVuaGFuY2VtZW50cy9w cm9jZWR1cmVzIGFuZCBlbmhhbmNlbWVudHMNCiAgKiAgIDMuMy4yLiAoTDNWUE4pICAgVGhlIGdh cCBzZWN0aW9uIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgdGV4dDogIkRpc2N1c3NlZCBpbiBmdXJ0 aGVyIGRldGFpbCBiZWxvdyIuICBJdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgYW4gYWN0dWFsIHJl ZmVyZW5jZSB0byB0aGUgc2VjdGlvbiBpbnN0ZWFkIG9mIHRoZSB0ZXh0Lg0KICAqICAgRXZlbiB0 aG91Z2ggc2VjdGlvbnMgMy4zLjIuMSBhbmQgMy4zLjIuMiBhcmUgc3Vic2VjdGlvbnMgb2YgMy4z LjIsIHdpdGggc28gbWFueSBzY2VuYXJpb3MgYmVpbmcgY292ZXJlZCwgaXQgZ2V0cyBoYXJkIHRv IGtlZXAgdHJhY2sgb2Ygd2hlcmUgc29tZXRoaW5nIHdhcyBkZXNjcmliZWQuICBJdCB3b3VsZCBi ZSB2ZXJ5IG5pY2UgdG8gaW5jbHVkZSByZWZlcmVuY2VzIHRvIHdoZXJlICJ1c2UgY2FzZSAjMiIg d2FzIGRlZmluZWQgaW4gc2FjIG9mIHRob3NlIHN1YnNlY3Rpb25zLg0KICAqICAgMy4zLjIuNC4g KE5HLU1WUE4pICBzL292ZXIgTVBMUyBWUE4gYmFja2JvbmUvb3ZlciBhbiBNUExTIFZQTiBiYWNr Ym9uZQ0KICAqICAgMy4zLjIuNC4yLiAoUC1UdW5uZWwgSW5zdGFudGlhdGlvbikNCiAgICAgKiAg ICIuIC4gLmNvdmVyZWQgaW4gcHJldmlvdXMgc2VjdGlvbnMiLiAgUmVmZXJlbmNlcyBwbGVhc2Uu DQogICAgICogICAiUElNIFRyZWUgYW5kIEluZ3Jlc3MgUmVwbGljYXRpb24gYXJlIG91dCBvZiB0 aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4uIiBiZWNhdXNlLi4gIEVpdGhlciBleHBsYWluIHdo eSBvciByZW1vdmUgdGhlbSBmcm9tIHRoZSBsaXN0IHJpZ2h0IGJlZm9yZS4NCiAgKiAgIDMuNC4x LiAoRXh0ZW5kZWQgSUNNUCkgIHMvc3VwcG9ydGVkIGJ5IElQdjYtb25seSBpbmZyYXN0cnVjdHVy ZS9zdXBwb3J0ZWQgYnkgYW4gSVB2Ni1vbmx5IGluZnJhc3RydWN0dXJlDQogICoNCjMuNC4yLiAo TFNQIFBpbmcpICBzL0xTUCBQaW5nIHBhY2tldHMgYXJlIFVEUCBwYWNrZXRzIG92ZXIgYm90aCBJ UHY0IGFuZCBJUHY2L0xTUCBQaW5nIHBhY2tldHMgYXJlIFVEUCBwYWNrZXRzIG92ZXIgZWl0aGVy IElQdjQgb3IgSVB2Ng0KICAqICAgVGhlcmUgaXMgc29tZSB1bmV2ZW4gdHJlYXRtZW50IGluIHRo ZSBkZXNjcmlwdGlvbiBvZiB0aGUgc3VwcG9ydC9nYXBzLiAgSXQgd291bGQgYmUgbmljZSB0byBw cm92aWRlIHRoZSBzYW1lIGxldmVsIG9mIGRldGFpbCBldmVyeXdoZXJlIChpZiBuZWVkZWQpLiAg Rm9yIGV4YW1wbGUsIDMuMi4zLjIgKFJTVlAtVEUtUDJNUCkgcGxhaW5seSBtZW50aW9ucyB0aGF0 IFJGQzQ4NzUgY292ZXJzIHRoZSBzdXBwb3J0IGZvciBJUHY2Li53aGlsZSAzLjQuMyAoQkZEIE9B TSkgbWVudGlvbnMgd2hlcmUgSVB2NiBzdXBwb3J0IHVzIGRlZmluZWQgYnV0IGl0IGFsc28gcG9p bnRzIHRvIHRoZSBzcGVjaWZpYyBzZWN0aW9ucy4gIElNSE8sIHRoZSBhZGRpdGlvbmFsIGRldGFp bCBpcyBub3QgbmVlZGVkICh1bmxlc3MgdmVyeSBzcGVjaWZpYyBwb2ludHMgbmVlZCB0byBiZSBt YWRlKS4NCg== --_000_D0069E2E65909aretanaciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <80AEC4F367601B439C17C3F4EE8ABFA5@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxwIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyAiPg0KSGkhPC9wPg0KPHAgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQpJIGhh dmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3Ig dGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCBy b3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVU RiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVx dWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlDQogcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5j ZSB0byB0aGUgUm91dGluZyBBRHMuICZuYnNwO0ZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo8YSBjbGFzcz0iZXh0LWxpbmsiIGhy ZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIi PjxzcGFuIGNsYXNzPSJpY29uIj7igIs8L3NwYW4+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv YXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvYT4NCjwvcD4NCjxwIHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyAiPg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVz ZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNv bnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMg dGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNj dXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCjwvcD4NCjxwIHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyAiPg0KRG9jdW1lbnQ6Jm5ic3A7ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAt MDEgKEdhcCBBbmFseXNpcyBmb3IgT3BlcmF0aW5nIElQdjYtb25seSBNUExTIE5ldHdvcmtzKTxi cj4NClJldmlld2VyOiBBbHZhcm8gUmV0YW5hPGJyPg0KUmV2aWV3IERhdGU6IEF1Zy4gNSwgMjAx NC48YnI+DQpJRVRGIExDIEVuZCBEYXRlOiBBdWcuIDgsIDIwMTQuPGJyPg0KSW50ZW5kZWQgU3Rh dHVzOiZuYnNwO0luZm9ybWF0aW9uYWw8L3A+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4N CjxzdHJvbmc+U3VtbWFyeTo8L3N0cm9uZz4gPGJyPg0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2Vy bnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJl Zm9yZSBwdWJsaWNhdGlvbi48L3A+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzdHJv bmc+Q29tbWVudHM6PC9zdHJvbmc+PC9wPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4N ClRoaXMgZHJhZnQgY292ZXJzIGEgd2lkZSB2YXJpZXR5IG9mIHRlY2hub2xvZ3kgdG8gZmluZCBn YXBzIHRoYXQgbWF5IHByZXZlbnQgdGhlIHVzZSBvZiBJUHY2LW9ubHkgTVBMUyBuZXR3b3Jrcy4g Jm5ic3A7SXQgZG9lcyBzbyBpbiBhIGNvbmNpc2UgYW5kIGNsZWFyIGZvcm0sIGFuIGVhc3kgcmVh ZC4gJm5ic3A7SSBiZWxpZXZlIHRoYXQgdGhpcyB3b3JrIGlzIHZlcnkgdmFsdWFibGUgZ2l2ZW4s IGFzIHRoZSBkcmFmdCBwdXRzIGl0LCB0aGF0ICZxdW90O0lQdjYgaXMgYW4NCiBpbnRlZ3JhbCBw YXJ0IG9mIG1vZGVybiBuZXR3b3JrIGRlcGxveW1lbnRzJnF1b3Q7LjwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsgIj4NCkkgZG8gaGF2ZSBhIGNvdXBsZSBvZiBoaWdoLWxldmVsIGl0ZW1zIEkgd2FudCB0 byBicmluZyB1cC4gJm5ic3A7QmVjYXVzZSBJIGFzc3VtZSB0aGF0IHRoZXNlIG1heSBoYXZlIGFs cmVhZHkgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIGFwcHJvcHJpYXRlIFdHKHMpIEknbSBub3QgbGlz dGluZyB0aGVtIGFzIG1ham9yIGlzc3VlcywgYW5kIHdpbGwgZGVmZXIgdG8gd2hhdCB0aGUgY29u c2Vuc3VzIGhhcyBiZWVuIHNvIGZhci48L2Rpdj4NCjxvbCBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsg Ij4NCjxsaT5XaHkgZG8gd2UgbmVlZCB0byBwdWJsaXNoIHRoaXMgZG9jdW1lbnQ/ICZuYnNwO0Fz IEkgc2FpZCBhYm92ZSwgSSBiZWxpZXZlIHRoZSB3b3JrIGlzIHZhbHVhYmxlLCBidXQgaXQgY2Fw dHVyZXMgdGhlIHN0YXRlIGluIHRpbWUgKHRvZGF5ISkgb2YgdGhlIGdhcHMg4oCUIGl0IHBvaW50 cyB0byB3b3JrIHRoYXQgYWxyZWFkeSBzb2x2ZWQgYSBwb3RlbnRpYWwgZ2FwLCBvciBpcyBpbiB0 aGUgcHJvY2VzcyBvZiBzb2x2aW5nIHRoZW0uICZuYnNwO0Egc2lnbmlmaWNhbnQNCiBwb3J0aW9u IG9mIHRoZSBnYXBzIGFyZSBhbHJlYWR5IGJlaW5nIGFkZHJlc3NlZC4gJm5ic3A7R2l2ZW4gdGhl IGltcG9ydGFuY2Ugb2YgSVB2NiwgaWYgcHVibGlzaGVkLCBzb29uIHRoaXMgZG9jdW1lbnQgd2ls bCBoYXZlIHRvIGJlIHVwZGF0ZWQgdG8gc2F5ICZxdW90O25vdGhpbmcgYnJlYWtzJnF1b3Q7LiAm bmJzcDtBZ2FpbiwgdGhlIHdvcmsgaXMgaW1wb3J0YW50LCBidXQgaXQgbWF5IGJlIGJldHRlciBz dWl0ZWQgdG8gYmUgYSAmcXVvdDtsaXZpbmcgZG9jdW1lbnQmcXVvdDsgYXMgYSBndWlkZQ0KIGZv ciB3aGF0IHN0aWxsIG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4gJm5ic3A7SWYgaXQgaXMgdG8gYmUg cHVibGlzaGVkLCBJIHdvdWxkIHN1Z2dlc3QgYXZvaWRpbmcgbGlua3MgdG8gd29yayBpbiBwcm9n cmVzcywgYnV0IGxpbWl0aW5nIHRoZSBjb250ZW50IHRvIGlkZW50aWZ5aW5nIHRoZSBnYXBzLi5h bmQgdGhlbiBsZXR0aW5nIHRoZSBzb2x1dGlvbiBkcmFmdHMvUkZDcyBwb2ludCBiYWNrIHRvIHRo aXMgZG9jdW1lbnQuLiAmbmJzcDsoYWxhIHJlcXVpcmVtZW50cw0KIC0mZ3Q7IHNvbHV0aW9uKTwv bGk+PGxpPkl0IGlzIGludGVyZXN0aW5nIHRvIG1lIHRoYXQgdGhpcyBkcmFmdCBjYW1lIHRocm91 Z2ggdGhlIG1wbHMgV0csIGFuZCBub3Qgb25lIG9mIHRoZSBvcGVyYXRpb25zLWZvY3VzZWQgZ3Jv dXBzLi53aGljaCBwcmVzdW1hYmx5IHdvdWxkIGJlIGluIGEgYmV0dGVyIHBvc2l0aW9uIHRvIGV2 YWx1YXRlIHRoZSBuZWVkcyBkZXNjcmliZWQuICZuYnNwO0dpdmVuIHRoYXQgdGhlIGRvY3VtZW50 IGlzIGFscmVhZHkgaW4gV0cgTGFzdCBDYWxsLCBJJ20gYXNzdW1pbmcNCiB0aGF0IHRoZSBhbGln bm1lbnQgaGFzIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQgYW5kIHRoYXQgcHJvcGVyIGNyb3NzLVdH IHJldmlld3MgaGF2ZSBvY2N1cnJlZC48L2xpPjwvb2w+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyAiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHN0 cm9uZz5NYWpvciBJc3N1ZXM6PC9zdHJvbmc+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyAiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KTm8g bWFqb3IgaXNzdWVzIGZvdW5kLjwvZGl2Pg0KPHAgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8 c3Ryb25nPk1pbm9yIElzc3Vlczo8L3N0cm9uZz4gPC9wPg0KPHVsPg0KPGxpIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyAiPg0KU29tZSB0ZXJtaW5vbG9neSB3YXMgbm90IGV4cGFuZGVkIGJlZm9yZS93 aGVuIGl0IHdhcyBmaXJzdCB1c2VkOiB3ZSBhbGwga25vdyB3aGF0IE1QTFMgaXMsIGJ1dCBvdGhl cnMgbGlrZSBMU1IsIExFUiwgRkVDLCBMMlZQTiwgRVZQTiwgTkctbVZQTiwgZXRjLiBzaG91bGQg YmUgZXhwYW5kZWQuPC9saT48bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQpTZWN0aW9uIDMu MSAoTVBMUyBEYXRhIFBsYW5lKTogJnF1b3Q7SW4gdGhlIGNhc2Ugd2hlcmUgYW4gSVB2NCBwcmVm aXggaXMgcmVzb2x2ZWQgb3ZlciBhbiBJUHY2IExTUCwgYW4mbmJzcDtJUHY2IEV4cGxpY2l0IE51 bGwgbGFiZWwgY2Fubm90IGltbWVkaWF0ZWx5IHByZWNlZWQgYW4gSVB2NCBwYWNrZXQuJnF1b3Q7 ICZuYnNwO0lzIHRoZXJlIGEgcmVmZXJlbmNlIGZvciB0aGlzIHN0YXRlbWVudCBvciBpcyB0aGlz IGEgcmVxdWlyZW1lbnQgdG8gZmlsbCBpbiB0aGUgZ2FwPyAmbmJzcDtJZg0KIGl0IGlzIGEgcmVx dWlyZW1lbnQsIGRvIHdlIG5lZWQgdG8gYWRkIDIxMTkgbGFuZ3VhZ2U/PC9saT48bGkgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7ICI+DQpXaGVuIGEgZ2FwIGV4aXN0cywgeW91IGNsYXNzaWZ5IGl0IGFz ICZxdW90O21ham9yJnF1b3Q7IG9yICZxdW90O21pbm9yJnF1b3Q7LiAmbmJzcDtXaGF0IGlzIHRo ZSBjcml0ZXJpYSB1c2VkPyAmbmJzcDtJIHdvdWxkIGltYWdpbmUgdGhhdCBnaXZlbiB0aGF0IGl0 IGlzIGEgZ2FwIGFuYWx5c2lzLCB0aGUgb2JqZWN0aXZlIGlzIHRvIHBvaW50IG91dCB0aGUgbmVl ZHMsIG5vdCBjaGFyYWN0ZXJpemUgdGhlbSAoaWYgSSBuZWVkIGEgJnF1b3Q7bWlub3ImcXVvdDsg Z2FwIHRvIGJlIGZpbGxlZCBpbiBvcmRlciBmb3IgbXkNCiBuZXR3b3JrIGRlcGxveW1lbnQgdG8g b3BlcmF0ZSwgaXQgYmVjb21lcyAmcXVvdDttYWpvciZxdW90OyB0byBtZSkuPC9saT48bGk+PGZv bnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPlRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhlIGRyYWZ0 IHRhbGtzIGFib3V0ICZxdW90OzwvZm9udD5nYXBzIHRoYXQgbXVzdCBiZSBhZGRyZXNzZWQgaW4g b3JkZXIgdG8gYWxsb3cgTVBMUy1yZWxhdGVkDQogcHJvdG9jb2xzPGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj4mbmJzcDthbmQgYXBwbGljYXRpb25zIHRvIGJlIHVzZWQgd2l0aCBJUHY2 LW9ubHkgbmV0d29ya3MmcXVvdDsgKCZxdW90O0lQdjYtb25seSAobm8gSVB2NCZuYnNwOzwvZm9u dD48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAi PnByb3Zpc2lvbmVkIG9uIHRoZSBkZXZpY2UpJnF1b3Q7KTwvc3Bhbj48Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+LA0KIHdoaWNo IGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQgbm8gSVB2NCBpcyBwcmVzZW50IGluIHRoZSBuZXR3 b3JrIGF0IGFsbC4gJm5ic3A7Jm5ic3A7SG93ZXZlciwgc2V2ZXJhbCBnYXBzIGFyZSBpZGVudGlm aWVkIHRoYXQgb2NjdXIgaW4gJnF1b3Q7bWl4ZWQmcXVvdDsgbmV0d29ya3MsIHdoZXJlIGlzbGFu ZHMgb2YgSVB2NC9JUHY2IGV4aXN0LiAmbmJzcDtJIHdvdWxkIHN1Z2dlc3QgY2xhcmlmeWluZyB0 aGUgc2NvcGUgb2YgdGhlJm5ic3A7ZG9jdW1lbnQgaW4gdGhlIGludHJvZHVjdGlvbi4gJm5ic3A7 U29tZQ0KIG9mIHRoZSBwbGFjZXMgd2hlcmUgdGhlc2Ugc2NlbmFyaW9zIGFyZSBkaXNjdXNzZWQg aW5jbHVkZTogJm5ic3A7PC9mb250PjMuMi4yLiAoTXVsdGlwb2ludCBMRFApLCZuYnNwOzwvZm9u dD48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiIHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPjMuMy4yLiAoTDNWUE4pLCAmbmJz cDszLjQuMS4gKEV4dGVuZGVkIElDTVApIGFuZCZuYnNwOzMuNC4yLiAoTFNQIFBpbmcpLjwvZm9u dD48L2xpPjxsaSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPjMuMy4xLjEuIChF VlBOKSAmbmJzcDtJZiB0aGUgRVZQTiB3b3JrIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhlIGRv Y3VtZW50LCB0aGVuIHRha2UgaXQgb3V0LiAmbmJzcDtBbm90aGVyIG9wdGlvbiBtYXkgYmUgdG8g dGFsayBhYm91dCBhbnkgZ2FwcyBpbiB0aGUgY3VycmVudCB3b3JrLiAmbmJzcDtTYW1lIGNvbW1l bnQgZm9yIHNlY3Rpb24mbmJzcDszLjMuMi40LjMuDQogKFBFLVBFIE11bHRpY2FzdCBSb3V0aW5n IFByb3RvY29sKS48L3NwYW4+PC9saT48bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7ICI+My4zLjIuIChMM1ZQTikgJm5ic3A7dGhl IHRleHQgc2F5cyB0aGF0IHRoZSBnYXBzIGluIFJGQzQzNjQgKG5vJm5ic3A7VlBOLUlQdjYgYWRk cmVzcyBhbmQgYSZuYnNwOzEyOCBiaXQgbmV4dC1ob3ApIGhhdmUgYmVlbg0KIGFkZHJlc3NlZCBp biBSRkMgNDY1OSwgYnV0IGl0IHRoZW4gaWRlbnRpZmllcyB0aGUgZ2FwIGFuZCBzYXlzIHRoYXQg JnF1b3Q7UkZDNDM2NCBtdXN0IGJlIHVwZGF0ZWQmcXVvdDsuICZuYnNwO1doYXQgd291bGQgdGhh dCB1cGRhdGUgYmU/PC9zcGFuPjwvbGk+PGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyAiPlNlY3Rpb25zIDMuMy4yLjQuMy4gKFBF LVBFIE11bHRpY2FzdCBSb3V0aW5nIFByb3RvY29sKSwmbmJzcDs8L3NwYW4+PGZvbnQgZmFjZT0i Q2FsaWJyaSxzYW5zLXNlcmlmIj4zLjMuMy4gKE1QTFMtVFApDQogYW5kJm5ic3A7My40LjUuIChN UExTLVRQIE9BTSkmbmJzcDthcmUgaW5jbHVkZWQsIGJ1dCBvdXQgb2Ygc2NvcGUuLiAmbmJzcDtT aG91bGQgdGhleSBiZSByZW1vdmVkPyAmbmJzcDtJZiBub3QsIHRoZW4gYSBzaG9ydCBqdXN0aWZp Y2F0aW9uIGluIHRoZSB0ZXh0IHdvdWxkIGJlIG5pY2UuPC9mb250PjwvbGk+PGxpIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyAiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4zLjQuIChN UExTIE9BTSkgJm5ic3A7VGhpcyBzZW50ZW5jZSAmcXVvdDs8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPkFsbCBvZiB0aGVzZSZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+bWVjaGFu aXNtcyB3b3JrIGluIHB1cmUgSVB2NiBlbnZpcm9ubWVudHMuJnF1b3Q7IGdpdmVzIHRoZSBpbXBy ZXNzaW9uIHRoYXQNCiBhbGwgdGhlIG1lY2hhbmlzbXMgd29yayBjb3JyZWN0bHkgYW5kIHRoYXQg dGhlcmUgYXJlIG5vIGdhcHMuLmJ1dCB0aGVuIHNldmVyYWwgZ2FwcyBhcmUgbGlzdGVkLjwvc3Bh bj48L2xpPjxsaSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+VGFibGUgMTogSVB2Ni1vbmx5IE1QTFMgR2Fwcy4gJm5ic3A7VGhlIHRhYmxl IGRvZXNuJ3QgaW5jbHVkZSBhbGwgdGhlIGdhcHMgaWRlbnRpZmllZC4gJm5ic3A7Rm9yIGV4YW1w bGUsJm5ic3A7PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+My4yLjIuIChN dWx0aXBvaW50IExEUCkgaXMgbm90IGluY2x1ZGVkIGluIHRoZSB0YWJsZSwgZXZlbiB0aG91Z2gg YSBtYWpvciBnYXAgd2FzIGlkZW50aWZpZWQuDQogJm5ic3A7SW4gdGhpcyBjYXNlLCB0aGUgd29y ayBpbiB0aGUgdGFibGUgZm9yIExEUCBtYXkgYWxzbyBhZGRyZXNzIHRoZSBnYXAgaW4gbUxEUCwg YnV0IHRoYXQgaXMgbm90IHBvaW50ZWQgb3V0IGluIHRoZSB0YWJsZS4uICZuYnNwO0luIHNob3J0 LCB0aGUgdGFibGUgaXMgbm90Jm5ic3A7Y29tcGxldGUuPC9mb250PjwvbGk+PGxpIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyAiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5TZWN1cml0 eSBDb25zaWRlcmF0aW9ucy4gJm5ic3A7VGhpcyBzZWN0aW9uIHRhbGtzIGFib3V0IHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIGluIGN1cnJlbnQgc3BlY2lmaWNhdGlvbnMuLmJ1dCBpdCBsZWF2ZXMg b3V0IG1lbnRpb24gb2YgdGhlIGZhY3QgdGhhdCBuZXcgc3BlY2lmaWNhdGlvbnMgKHRvIGNsb3Nl IHRoZSBnYXBzKSBzaG91bGQgKE1VU1QgPykgY29uc2lkZXIgdGhlIGVmZmVjdCBvZiBJUHY2Ljwv Zm9udD48L2xpPjwvdWw+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzdHJvbmc+Tml0 czo8L3N0cm9uZz4gPC9wPg0KPHVsIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPGxpIHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyAiPg0KU2VjdGlvbiAyIChVc2UgQ2FzZSk6ICZuYnNwO3MvYXQgbGVh c3Qgb25lL29uZSAoZ2VuZXJhbCkgJm5ic3A7Jm5ic3A7PC9saT48bGkgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7ICI+DQpTZWN0aW9uIDMgKEdhcCBBbmFseXNpcykuICZuYnNwO1lvdSB3cm90ZTogJnF1 b3Q7VGhpcyBnYXAgYW5hbHlzaXMgYWltcyB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uLCAmcXVvdDt3 aGF0IGJyZWFrcyB3aGVuIG9uZSZuYnNwO2F0dGVtcHRzIHRvIHVzZSBNUExTIGZlYXR1cmVzIG9u IGEgbmV0d29yayBvZiBJUHY2LW9ubHkgZGV2aWNlcz8mcXVvdDsgJm5ic3A7V2hpbGUgSSB1bmRl cnN0YW5kIHdoYXQgeW91J3JlIGFza2luZywgaW4gcmVhbGl0eSB5b3UncmUgdHJ5aW5nIHRvIGFu c3dlciAmcXVvdDt3aGF0IGRvZXNuJ3QNCiB3b3JrLi4mcXVvdDsuICZuYnNwO0JyZWFraW5nIGlt cGxpZXMgdGhhdCBpdCBtYXkgd29yayBmb3IgYSB3aGlsZSBhbmQgdGhlbiBzdG9wIGRvaW5nIHNv LjwvbGk+PGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KU2VjdGlvbiAzLjEgKE1QTFMgRGF0 YSBQbGFuZSk6Jm5ic3A7IHMvcHJlY2VlZC9wcmVjZWRlPC9saT48bGkgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7ICI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjMuMi4yLiAoTXVsdGlw b2ludCBMRFApICZuYnNwO0EgcmVmZXJlbmNlIGJhY2sgdG8gdGhlIExEUCBzZWN0aW9uIHdvdWxk IGJlIG5pY2UgaW4gcG9pbnQgMS48L2ZvbnQ+PC9saT48bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiBtZWRpdW07ICI+My4yLjIuIChNdWx0aXBvaW50 IExEUCkmbmJzcDstIFBvaW50IDIuICZuYnNwO3M8L3NwYW4+L2xvb2t1cCBhZ2FpbnN0IHJvb3Qg YWRkcmVzcy9sb29rdXAgYWdhaW5zdCB0aGUgcm9vdCBhZGRyZXNzJm5ic3A7PC9saT48bGkgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiBtZWRpdW07ICI+ My4yLjIuIChNdWx0aXBvaW50IExEUCk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogbWVk aXVtOyAiPiZuYnNwO3MvPC9zcGFuPnRocm91Z2ggdGhlJm5ic3A7cHJvY2VkdXJlcyBzaW1pbGFy IHRvIFJGQzY1MTIvdGhyb3VnaCZuYnNwO3Byb2NlZHVyZXMgc2ltaWxhciB0byBSRkM2NTEyICZu YnNwOyAmbmJzcDtCVFcsIHRoZSBsYXN0IHNlbnRlbmNlIGluIHRoaXMgc2FtZSBwYXJhZ3JhcGgg c2VlbXMgcmVkdW5kYW50IHRvIG1lLjwvbGk+PGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0K PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4zLjIuMy4gKFJTVlAtIFRFKSAmbmJzcDtz LzwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+ cHJvY2VkdXJlcyAmYW1wO2VuaGFuY2VtZW50cy88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPnByb2NlZHVyZXMgYW5kJm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5lbmhhbmNlbWVu dHM8L3NwYW4+PC9saT48bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPjMuMy4yLiAoTDNWUE4pICZuYnNwOyBUaGUgZ2FwIHNlY3Rpb24g aW5jbHVkZXMgdGhlIGZvbGxvd2luZyB0ZXh0OiAmcXVvdDs8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+RGlzY3Vz c2VkIGluIGZ1cnRoZXImbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+ZGV0YWlsDQogYmVsb3cmcXVvdDsu ICZuYnNwO0l0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBhbiBhY3R1YWwgcmVmZXJlbmNlIHRvIHRo ZSBzZWN0aW9uIGluc3RlYWQgb2YgdGhlIHRleHQuPC9zcGFuPjwvbGk+PGxpIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyAiPkV2ZW4g dGhvdWdoIHNlY3Rpb25zIDMuMy4yLjEgYW5kIDMuMy4yLjIgYXJlIHN1YnNlY3Rpb25zIG9mIDMu My4yLCB3aXRoIHNvIG1hbnkgc2NlbmFyaW9zIGJlaW5nIGNvdmVyZWQsIGl0DQogZ2V0cyBoYXJk IHRvIGtlZXAgdHJhY2sgb2Ygd2hlcmUgc29tZXRoaW5nIHdhcyZuYnNwOzwvc3Bhbj48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPmRlc2NyaWJlZC4gJm5ic3A7SXQgd291bGQgYmUgdmVy eSBuaWNlIHRvIGluY2x1ZGUgcmVmZXJlbmNlcyB0byB3aGVyZSAmcXVvdDt1c2UgY2FzZSAjMiZx dW90OyB3YXMgZGVmaW5lZCBpbiZuYnNwO3NhYyZuYnNwO29mIHRob3NlIHN1YnNlY3Rpb25zLjwv Zm9udD48L2xpPjxsaSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+My4zLjIuNC4gKE5HLU1WUE4pICZuYnNwO3MvPC9mb250Pjxmb250IGZh Y2U9IkNhbGlicmksc2Fucy1zZXJpZiI+b3ZlciBNUExTIFZQTiBiYWNrYm9uZS9vdmVyIGFuIE1Q TFMgVlBOIGJhY2tib25lPC9mb250PjwvbGk+PGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0K My4zLjIuNC4yLiAoUC1UdW5uZWwgSW5zdGFudGlhdGlvbikgJm5ic3A7DQo8dWwgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7ICI+DQo8bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mcXVv dDsuIC4gLjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7ICI+Y292ZXJlZCZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7ICI+aW4gcHJldmlvdXMgc2VjdGlvbnMmcXVvdDsuICZuYnNwO1JlZmVy ZW5jZXMgcGxlYXNlLjwvc3Bhbj48L2xpPjxsaT48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7ICI+JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgIj5QSU0gVHJlZSBhbmQgSW5ncmVzcyBSZXBsaWNhdGlvbiBhcmUgb3V0IG9m IHRoZQ0KIHNjb3BlIG9mIHRoaXM8L3NwYW4+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij4mbmJzcDtkb2N1bWVudC4uJnF1b3Q7Jm5ic3A7YmVjYXVzZS4uICZuYnNwO0VpdGhlciBleHBs YWluIHdoeSBvciByZW1vdmUgdGhlbSBmcm9tIHRoZSBsaXN0IHJpZ2h0IGJlZm9yZS48L2ZvbnQ+ PC9saT48L3VsPg0KPC9saT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4zLjQu MS4gKEV4dGVuZGVkIElDTVApICZuYnNwO3Mvc3VwcG9ydGVkIGJ5Jm5ic3A7SVB2Ni1vbmx5IGlu ZnJhc3RydWN0dXJlL3N1cHBvcnRlZCBieSBhbiZuYnNwO0lQdjYtb25seSBpbmZyYXN0cnVjdHVy ZTwvZm9udD48L2xpPjxsaT48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj4z LjQuMi4gKExTUCBQaW5nKSAmbmJzcDtzL0xTUCBQaW5nIHBhY2tldHMgYXJlIFVEUCBwYWNrZXRz IG92ZXIgYm90aCBJUHY0IGFuZCZuYnNwO0lQdjYvTFNQIFBpbmcgcGFja2V0cyBhcmUgVURQIHBh Y2tldHMgb3ZlciBlaXRoZXIgSVB2NCBvciZuYnNwO0lQdjY8L2Rpdj4NCjwvZm9udD48L2xpPjxs aT48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPlRoZXJlIGlzIHNvbWUgdW5ldmVuIHRy ZWF0bWVudCBpbiB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHN1cHBvcnQvZ2Fwcy4gJm5ic3A7SXQg d291bGQgYmUgbmljZSB0byBwcm92aWRlIHRoZSBzYW1lIGxldmVsIG9mIGRldGFpbCBldmVyeXdo ZXJlIChpZiBuZWVkZWQpLiAmbmJzcDtGb3IgZXhhbXBsZSwgMy4yLjMuMiAoPC9mb250PlJTVlAt VEUtUDJNUCkgcGxhaW5seSBtZW50aW9ucyB0aGF0IFJGQzQ4NzUNCiBjb3ZlcnMgdGhlIHN1cHBv cnQgZm9yIElQdjYuLndoaWxlIDMuNC4zIChCRkQgT0FNKSBtZW50aW9ucyB3aGVyZSBJUHY2IHN1 cHBvcnQgdXMgZGVmaW5lZCBidXQgaXQgYWxzbyBwb2ludHMgdG8gdGhlIHNwZWNpZmljIHNlY3Rp b25zLiAmbmJzcDtJTUhPLCB0aGUgYWRkaXRpb25hbCBkZXRhaWwgaXMgbm90IG5lZWRlZCAodW5s ZXNzIHZlcnkgc3BlY2lmaWMgcG9pbnRzIG5lZWQgdG8gYmUgbWFkZSkuPC9saT48L3VsPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_D0069E2E65909aretanaciscocom_-- From nobody Tue Aug 5 13:16:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE8D1A02DC for ; Tue, 5 Aug 2014 13:16:12 -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, RP_MATCHES_RCVD=-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 lGzIHxq8gnI3 for ; Tue, 5 Aug 2014 13:16:08 -0700 (PDT) Received: from ucol19pa15.eemsg.mail.mil (ucol19pa15.eemsg.mail.mil [214.24.24.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED0F1A02DF for ; Tue, 5 Aug 2014 13:15:58 -0700 (PDT) X-EEMSG-Attachment-filename: smime.p7s Received: from edge-mech01.mail.mil ([214.21.130.100]) by ucol19pa15.eemsg.mail.mil with ESMTP; 05 Aug 2014 20:15:52 +0000 Received: from UMECHPAOE.easf.csd.disa.mil (214.21.130.32) by edge-mech01.mail.mil (214.21.130.100) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 5 Aug 2014 20:15:52 +0000 Received: from UMECHPANZ.easf.csd.disa.mil ([169.254.2.149]) by UMECHPAOE.easf.csd.disa.mil ([214.21.130.32]) with mapi id 14.03.0174.001; Tue, 5 Aug 2014 20:15:51 +0000 From: "Venator, Robert H III CIV DISA NS (US)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq96NoXU6cEQ0cU2fJ15jk/IE15vCfC1Q Date: Tue, 5 Aug 2014 20:15:51 +0000 Message-ID: References: <53D8C464.6040403@pi.nu> In-Reply-To: <53D8C464.6040403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [214.21.44.12] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04A0_01CFB0C8.84C38E70" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-fLPorMtN8MmCkcB8sjAYoacufk Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 20:16:13 -0000 ------=_NextPart_000_04A0_01CFB0C8.84C38E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit "Support this draft (as co-author)" Robert Venator -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, July 30, 2014 6:10 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org Subject: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Working Group, This is to start a two week poll on adopting draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There is one IPR claim against this document. The authors and contributors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends August 14, 2014. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 ------=_NextPart_000_04A0_01CFB0C8.84C38E70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISjTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEuDCCA6CgAwIBAgIDFnwZMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzAwHhcNMTIwNzIzMDAwMDAwWhcN MTUwNzIyMjM1OTU5WjB8MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsGA1UECxMERElTQTEoMCYGA1UEAxMfVkVOQVRP Ui5ST0JFUlQuSC5JSUkuMTAyNDg2NTM5NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKyXqrymWWUwcEy0l1PcYZ3S5mXDwEFVz5ZicVKffLVnkGF/i+yp+OqqXlSK9f427YRac+ePWOn0 i+3vBtzGz7Z6ml9iSMIfld4/zF2pE/XYxRmS+YygJtibC7OT2tj55meYBH8qQOVGdrdUiYtam8tw mnPpmjv++6s3pa84RnQss0211ece6bcnil+m3WzeG75cWB/P1GUJCAJLpWvtBB0/F3nOPfEuLKER UhwDrrVXhTgmAY9OrpTHWKL04FrRe/OVM6WK495uxNpQJa3LtuYlQ4w2NLI6adfu53Gm20oN6afT zhaEkNn+bTcwsD2rU1gOORhnJBvCC7h81DN+XpECAwEAAaOCAWAwggFcMB8GA1UdIwQYMBaAFDVh ZigJvFYlW4vMv4FeYSwwOdMhMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwv Y3JsL0RPREVNQUlMQ0FfMzAuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFl AgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFACpUwcDIOVumon8Wy9XYFg698ftMGgGCCsGAQUF BwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0Ff MzAuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAiBgNVHREEGzAZgRdyb2Jl cnQudmVuYXRvckBkaXNhLm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3 DQEBBQUAA4IBAQAM2epFktEq3UYmbzsAD/qKK4v1QtY0bXfCIYE0cFv5YuOFbF0RBnN0BPRp34Es rksDYYWpZuE2UmNb7aS6SnkB07VU2qpMs1/1zijN1fpXWoTmXvFvPth073MUoP7Sdm+bgMaHGCBj DCAsamVV7f/CsOJUv57Osx7Yxgs/S95giqUG9bKpKt+PWgAQ72hdTGMTSOBNIPZ+5cNH9jx1f8E6 92wdfnIUkDJosfdWCPlyJhbSmWea1W+NcSLvVhiPvL18oYYWZzOgVXUfJQNJyNyaGwjFp1aidDMS SFBk8B0Ka8aJhBAMto5zMAoMFIw8azkl94xbOqK5C3USbyTp2fcoMIIFAzCCA+ugAwIBAgIDFnwT MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzAwHhcN MTIwNzIzMDAwMDAwWhcNMTUwNzIyMjM1OTU5WjB8MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5T LiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsGA1UECxMERElTQTEo MCYGA1UEAxMfVkVOQVRPUi5ST0JFUlQuSC5JSUkuMTAyNDg2NTM5NDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMzZdVGUWCd1rGsFgQ4X38dR1Qis6jkjFBlrkdogFEWPDa/gb5bTypv7 q9WLzFvDid97GBX9iegS/RhVPNMopGbKjLRGn/dY0nyJ36nM+7rQoX4KnNrd0uWmseinPiDoG97j Gs1Olvue6nMjjnmO14s9BxPYONGwxoypne+Gpckgh3GVD52EyJt9Jhu79r88LmJzB1Bzj8kTq7PF mF11RDhhLC1VO5sRE60QlytiEp6DtlQ2Jy1XXSudhPs5bm2Hb4nsbXPAQAYQ9cgwFeU4KElIUyui gIN8kWuehpq4b2va6G2f6WXC5TiVwlew9Ihlyp+JgDcPSTljEjwpoUfyDmsCAwEAAaOCAaswggGn MB8GA1UdIwQYMBaAFDVhZigJvFYlW4vMv4FeYSwwOdMhMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6 Ly9jcmwuZGlzYS5taWwvY3JsL0RPREVNQUlMQ0FfMzAuY3JsMA4GA1UdDwEB/wQEAwIGwDAjBgNV HSAEHDAaMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFNW7AmZscjEkeh4inp2A w9iBJP5XMGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9z aWduL0RPREVNQUlMQ0FfMzAuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDBC BgNVHREEOzA5gRdyb2JlcnQudmVuYXRvckBkaXNhLm1pbKAeBgorBgEEAYI3FAIDoBAMDjEwMjQ4 NjUzOTRAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYKKwYBBAGC NxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQBf9LesMnEO72H7p9wH ms+vjj2bREMjw6UVEf1L4BXLpors/fZfN+Ypc6cPPo3G5wpgusJQc3dLuLj4mJajmvF23BgvVJVc nc41A2skKszp6ip8L0sYmMkxFVXB1JCsGo/0Ln7AG6uvZFKP9GZPxGsPgAjAhGyn+V186+7G7XI2 +s9Dzwd5On8rIqbyW8W83U2hz8AX5BVBDgoqorl9A4rESy0s66i8DPrOVA1sIjUtsFK+DYY3kgbm tuMOjiiSu3vOqNkhM+g66qZVNhc9TSoJYVIs84hRETtfZAhnd26O9p7Y4O7OJ2/s9q8aHweN8Fbj PxjZBt91cwjeHlriplFeMIIFUjCCBDqgAwIBAgICAbkwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDURvRCBSb290IENBIDIwHhcNMTEwOTA4MTYwMzA4WhcNMTcwOTA4MTYwMzA4 WjBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMwMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA5iki1BQm0ZgaUl7FhINzfsFgs7PQlL79HJRVv/aELJvJwHRz78zCmfKZ yW3KFNN0/74Q8vctv8u7BqPumFBBZQHhVyy2y+TKHKx+UjQOsY4HJj4yNa+jYQrF5Qi2EnmMVMF6 6fFQH12DOmcwsynbHTpMOSFQ2BgsjQZ17mNyeGitYpx1pJQG0zJrEq8GBym+E6DAp/AlT7f+H7dX 4BgSjSFqFblaVPt3ZdhMP/W6PMA34QZ+wr6eI4wo0ZrXxmc413PJvQcdhW/VlQqa3No6TijwpesJ 3+XbC81Hr4rNu2+UQONZnFCfyQ6pcQK53OlpgDqJO0UFIhgFhLUS8DzAgQIDAQABo4ICHDCCAhgw DgYDVR0PAQH/BAQDAgGGMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DGlcYJgHCWMB0GA1UdDgQW BBQ1YWYoCbxWJVuLzL+BXmEsMDnTITASBgNVHRMBAf8ECDAGAQH/AgEAMAwGA1UdJAQFMAOAAQAw ZgYDVR0gBF8wXTALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELETALBglghkgB ZQIBCxIwCwYJYIZIAWUCAQsTMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzA3BgNVHR8EMDAu MCygKqAohiZodHRwOi8vY3JsLmRpc2EubWlsL2NybC9ET0RST09UQ0EyLmNybDCCAQEGCCsGAQUF BwEBBIH0MIHxMDoGCCsGAQUFBzAChi5odHRwOi8vY3JsLmRpc2EubWlsL2lzc3VlZHRvL0RPRFJP T1RDQTJfSVQucDdjMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBkAYIKwYBBQUH MAKGgYNsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNv dSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2Nyb3Nz Q2VydGlmaWNhdGVQYWlyO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEACohWHKVXJlpiy3XQ3YbF UuIv87wRZD+MLz4R/JhgQPKADSiCmmj+4EhLJ9M6CnuV9gMMgRSRQjpgbOIrUy3s3xGu9VQX8AH5 lwenm6sL26yXiQnG7/kHNBYAqH4RU558L6E4opl5OTRBbn24WDBWiJ7kqmRF2aBEYjq35THTkYDx GxCyZ3DVW6tZtFpIFkLEAkzabGjKUB0xvjeZx89TzEIpVsOdF8oD5xBa8Tk8HMz7G5cKJvMx3+Cr XCSdnt44fQJRZ0b5k3CF7QpVwvTBaFqfCMkde5t23FTvOYwY5QxE7vcGsh/1y+YOvdSh/9T5kQci Unm3wP3ssviF9ET7XDGCA0EwggM9AgEBMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0zMAIDFnwTMAkGBSsOAwIaBQCgggGyMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MDgwNTIwMTU0OFowIwYJKoZIhvcNAQkEMRYEFIIBoHMB1867dTUyK+Mb rd5xWb4/MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHMG CSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0zMAIDFnwZ MHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5t ZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMw AgMWfBkwDQYJKoZIhvcNAQEBBQAEggEAsEsIeC6zu3Ldpe6iDruEB0Yqaru2W9If73S1a1VR3X75 tEInfpORpPE/FPc581yuhOhKKmP2E9snjPKqFOgPOeQoQDZPgaqY7fcAKLrbibG/ojy2T+nNa4xj f+RMc25r+D3/ODZeQEs2JnGh6HRA/IgzVaRG/JyWTReORe8Akozdqgyxi+oHT3MsOQb9QEz8ULaL PWOH0v6V1dF6b67ZGrvd1Xty8MNPpt2JKEiPH0mIMKejHsVT2mwuQ+rUS8od5CbxUP4tWQc0Yc3z rDScQW+1/i0CBlmStVYY6CT1n9ktUBXtF+/vbjp7G95MunLWff05G8Q3TC6946z4zbUkwwAAAAAA AA== ------=_NextPart_000_04A0_01CFB0C8.84C38E70-- From nobody Tue Aug 5 14:28:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F2B1A0332 for ; Tue, 5 Aug 2014 14:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 3_GIc09q0Bf6 for ; Tue, 5 Aug 2014 14:28:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D191B2B89 for ; Tue, 5 Aug 2014 14:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1407274137; x=1408483737; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qJLPjJ8HffLjZ6eNe88iZ368wIShZ5/bynj5KSlO2qE=; b=OGsouu+jKOIq2A1ngDf4+tTycwkNstsrLCp583PE757e4aTZEdhrR+em o9pICIBrmuAisYFCXdUg+uaYfRDavX0mhPnIiKujEHXD4AuDKix6wcX3c QlMB/4B16ImXHN0eObGzmSXKorxKM4HveptmwhqFzd4EwQ3ljRPoiDDRj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAIBL4VOtJA2K/2dsb2JhbABbgw1SVwTLaQqGJ4EhAYEWFneEBAEBBAEBATcxAxkCAgEINgULGwwLJQIEARKIQg3DWxMEBI5mEQFXhEsFnA2UYYIHgUZsgQ05 X-IronPort-AV: E=Sophos;i="5.01,807,1400025600"; d="scan'208";a="342223178" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP; 05 Aug 2014 21:28:55 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s75LSsgo016895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 21:28:54 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.206]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 16:28:54 -0500 From: "Tarek Saad (tsaad)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95qImggRj2O606yVQkBKC47nZvCoYUA Date: Tue, 5 Aug 2014 21:28:54 +0000 Message-ID: References: <53D8C464.6040403@pi.nu> In-Reply-To: <53D8C464.6040403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [161.44.212.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Zk2jk8-iELl4J89UHyRaqCiWGPk Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 21:28:58 -0000 Support as co-author. Regards, Tarek On 2014-07-30, 6:09 AM, "Loa Andersson" wrote: >Working Group, > >This is to start a two week poll on adopting >draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group >document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls@ietf.org). Please give a technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >There is one IPR claim against this document. > >The authors and contributors has stated on the working group mailing >list that they are not aware of any other IPR claims against this draft. > >However if you are on the the mpls working group mailing list and >aware of IPR that relates to this draft, the time to disclose >this is now. > >This poll ends August 14, 2014. > >/Loa > >for the MPLS wg co-chairs >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Aug 5 17:17:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AABD1A03ED for ; Tue, 5 Aug 2014 17:17:15 -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, RP_MATCHES_RCVD=-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 gwgJadxCUwNT for ; Tue, 5 Aug 2014 17:17:12 -0700 (PDT) Received: from mgw010.noc.ntt.com (mgw010.noc.ntt.com [210.160.55.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3031A03E5 for ; Tue, 5 Aug 2014 17:17:11 -0700 (PDT) Received: from c0043i0.coe.ntt.com (c0043i0.nc.agilit-hosting.com [10.18.161.12]) by mgw010.noc.ntt.com (NTT Com MailSV) with ESMTP id DAB9557A0026; Wed, 6 Aug 2014 09:17:10 +0900 (JST) Received: from C0035I0.coe.ntt.com (10.18.160.39) by c0043i0.coe.ntt.com (10.18.161.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 6 Aug 2014 09:17:08 +0900 Received: from C0007I0.coe.ntt.com ([169.254.1.34]) by C0035I0.coe.ntt.com ([10.18.160.39]) with mapi id 14.03.0181.006; Wed, 6 Aug 2014 09:17:10 +0900 From: Yuji Kamite To: "'Tarek Saad (tsaad)'" , Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95mZxntlSJcg0qU9DHacR+t7JvB+ecAgADFA7A= Date: Wed, 6 Aug 2014 00:17:09 +0000 Message-ID: <1A095D7ECD89A64C9D3C77AE2DDE660B5811C538@C0007I0.coe.ntt.com> References: <53D8C464.6040403@pi.nu> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: tsaad@cisco.com, loa@pi.nu, mpls@ietf.org, mpls-chairs@tools.ietf.org, martin.vigoureux@alcatel-lucent.com, draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org x-ccmail-original-cc: y.kamite@ntt.com x-originating-ip: [10.25.129.49] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/okyzztNsvKK_5Jht8YTYQjkO0ts Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 00:17:15 -0000 Support. (as a co-author) Best regards, -Yuji > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad) > Sent: Wednesday, August 06, 2014 6:29 AM > To: Loa Andersson; mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, > MARTIN (MARTIN); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org > Subject: Re: [mpls] poll to see if we have support to make > draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc > > Support as co-author. > > Regards, > Tarek > > On 2014-07-30, 6:09 AM, "Loa Andersson" wrote: > > >Working Group, > > > >This is to start a two week poll on adopting > >draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group > >document. > > > >Please send your comments (support/not support) to the mpls working > >group mailing list (mpls@ietf.org). Please give a technical motivation > >for your support/not support, especially if you think that the document > >should not be adopted as a working group document. > > > >There is one IPR claim against this document. > > > >The authors and contributors has stated on the working group mailing > >list that they are not aware of any other IPR claims against this draft. > > > >However if you are on the the mpls working group mailing list and aware > >of IPR that relates to this draft, the time to disclose this is now. > > > >This poll ends August 14, 2014. > > > >/Loa > > > >for the MPLS wg co-chairs > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Aug 6 06:01:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC4A1B29C6; Wed, 6 Aug 2014 06:01:00 -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, RP_MATCHES_RCVD=-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 FO969kM4_m6A; Wed, 6 Aug 2014 06:00:47 -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 5C4511A0AF6; Wed, 6 Aug 2014 06:00:47 -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 CF8701801586; Wed, 6 Aug 2014 15:00:44 +0200 (CEST) Message-ID: <53E226FC.7020302@pi.nu> Date: Wed, 06 Aug 2014 15:00:44 +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: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" , "mpls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8z_gKUhrunhRlOKLM2JRZhhex34 Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 13:01:01 -0000 PWE3-chairs and authors, I must confess I find this document hard to read, I had to have some help to do so. After going over it carefully I'm convinced that it does not mess with MPLS Architecture. However I also not convinced that this is ready to go, and I'm not really sure what we need to do progress it. In its current form we are probably pushing critical review to ADs, IESG and the RFC Editor. Seems to b e the wrong thing to do. What I think we could do is to invoke the rtg area language review team and do a careful language review. When that is done (hoping that most of the problems disappear) we should run an MPLS architecture / PWE3 concept check up and finish of with a short wg last call. /Loa On 2014-07-25 16:56, Bocci, Matthew (Matthew) wrote: > This email begins a second two week working group last call for > http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 . > > Please review the draft and post any comments to the PWE3 list. > > If you have read the draft, even if you don¹t have any comments, but would > like to see the draft progressed, please can you indicate this to the > list. > > This working group last call will end on Friday August 8th, 2014. > > > Best regards > > > Matthew and Andy > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Aug 6 08:54:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701801B287F; Wed, 6 Aug 2014 08:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 aQXv2XDEJJum; Wed, 6 Aug 2014 08:54:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452171B2869; Wed, 6 Aug 2014 08:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6873; q=dns/txt; s=iport; t=1407340462; x=1408550062; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=sXA0E92JZmqAf67kU5Hf9up5T3nCij+BU4X2SVh8j7c=; b=fCTqFa7i+RJaemDqC/rBf3y8OvfXX4YIfTUSG2Nn3isKqLsE1zRbFoZX KFFpKWH3st/XcQcAHt8nfVM3/rwpNez2YAKYuH2jj+8ZfL07LMeETe9C1 laT2JRFdT4hmAuALtP5JSYkV7loXDoS4zk6t6FIdeVLWJgN4thegGZpZb M=; X-IronPort-AV: E=Sophos;i="5.01,812,1400025600"; d="scan'208";a="345546750" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP; 06 Aug 2014 15:54:21 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s76FsKiJ000624; Wed, 6 Aug 2014 15:54:20 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id E1B74788; Wed, 6 Aug 2014 11:54:19 -0400 (EDT) From: Eric Rosen To: Alexander Vainshtein In-reply-to: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16166.1407340459.1@erosen-lnx> Date: Wed, 06 Aug 2014 11:54:19 -0400 Message-ID: <16167.1407340459@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lKDPNlJTOSMq25eNd-5y4H63nEo Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 15:54:23 -0000 I've looked at this draft, and it seems to me that it does work in LDP-based networks (even with DU mode), and that it does not violate any architectural principles. However, I have made certain assumptions that aren't explicitly stated in the draft. (I am assuming that the draft is intended to be patterned after the "anycast BGP" scheme that I've heard about about, but that is not written up anywhere as far as I know.) Let me say how I think it is intended to work, and the authors can correct me if I'm wrong. For protection against the failure of the "primary" egress PE: - A "primary egress PE" partitions its set of PWs into n sets, where each set is associated with a given "protector". The "protector" is the backup egress PE for those PWs. - Each such set is associated with an IP address. This IP address must be known both to the primary PE and to the protector. * One can think of this address as an "anycast" address that, to routing, denotes both the primary PE and the protector. At the primary PE and the protector, the address denotes a particular set of PWs. * These anycast addresses are distributed by routing, and good old fashioned MPLS labels get assigned to them by LDP. The primary PE MAY bind implicit null to that address, but the protector MUST NOT bind implicit null to that address. * Routing is set up so that (a) if the primary PE is up, traffic to the anycast address always goes to the primary PE, but (b) if the primary PE is down, traffic to the anycast address goes to the protector instead. This can be achieved by messing with the metrics, e.g. - For a given PW, the primary PE informs both the protector and the ingress PE of (a) the label that it (the primary PE) has assigned to that PW, and the "anycast address" that corresponds to that PW. This requires some new signaling (beyond that specified in RFC 4447), but the requisite signaling is specified in the draft. - When sending a packet on the given PW, the ingress PE pushes on the label assigned to the PW by the egress PE. Then the ingress PE pushes on whatever LDP-assigned label it need to use to get the packet to the anycast address that is associated with the PW. - When the protector learns that the egress PE has assigned a given label and anycast address to the PW, it stores that label in a context-specific label space associated with that anycast address. Whenever the protector receives a packet whose top label is the label that the protector has bound to the given anycast address, the protector looks up the next label in the corresponding label space. Let's look at an example: CE1---PE1----PLR----PE2----CE2 | | |-----PE3-----| where PE3 is the protector for a PW connecting CE1 to CE2 (via PE1 and PE2 respectively). Call this pseudowire PW1. Thus there is some IP address, call it A, that PE2 and PE3 both advertise to routing. The metrics are set up so that as long as PE2 is up, it appears to be a better path to A than does PE3. So PE2 assigns label L1 to PW1, and uses T-LDP to inform both PE1 and PE3 of this mapping. To PE1, these are just outgoing labels. To PE3, however, they are incoming labels in a context-specific label space. PE2 and PE3 both assign labels to A (let's call these labels L2 and L3 respectively), and distribute the corresponding label bindings to PLR. PLR also assigns a label to A, and distributes that label binding (L4) to PE1. When PE1 has a packet to send on PW1, it pushes L1, then pushes L4, then sends the packet to PLR. PLR swaps L4 with L2 and sends the packet to PE2. (Note that L2 could be implicit NULL.) PE2 sees label L1, and sends the packet to CE2. Now if PE2 goes down, things happen a bit differently. When PLR gets a packet with L4 on top, it swaps L4 with L3, and sends the packet to PE3. (In this case, of course, L3 cannot be implicit NULL.) PE3 gets the packet, sees L3 on top, looks it up, and then says "L3 is a context label, so I have to pop it and then look up the following label in the L3-specific label table." This context-specific label table contains L1, which has been bound to the PW that leads to CE2. So PE2 pops the label and sends the packet to CE2. I think that's basically it, and the necessary mechanisms do seem to be described in the draft. The draft doesn't actually use the notion of "anycast address" explicitly, but I think the intention is that the "context labels" are definitely bound to anycast addresses. I hope the authors will correct me if I'm wrong. Although the above example shows a PLR that is a neighbor of both PE2 and PE3, this isn't really necessary, one could easily construct an example where PE2 and PE3 have no neighbors in common. The example above doesn't rely on LDP DoD at all, and doesn't make use of any RSVP-TE backup tunnels. However, when protecting against the failure of the egress AC, packets would go first to PE2 then to PE3. This scenario is a bit different, in that: - I think this scenario may require an RSVP-TE backup tunnel (on which PHP is not used) from PE2 to PE3. - PE2 would have to signal PE3 to associate the given PW with the given backup tunnel. - The label that PE3 assigns to that backup tunnel would identify the context in which the PW label is looked up. This is perhaps more detail than is actually in the draft ;-) but if it is an accurate description of the authors' intentions, the scheme seems to work. I don't think this modifies the MPLS architecture at all. It is true that the PE3 needs to maintain a context-specific label table that contains labels assigned by PE2. While one may say that that is a "coordinated label space", it is no more than what is required by the nature of "upstream-assigned labels". I.e., if you can't support this level of coordination, you just can't support upstream-assigned labels. Also, I don't think this draft is an "update" to RFC 4447. You don't need to read this draft to implement RFC 4447, nor does it modify the procedures of RFC 4447. It just introduces some new optional signaling and procedures. I don't think RFC 4447's requirement to use the "platform label space" should be interpreted as prohibiting the use of upstream-assigned labels. The intention of RFC 4447 was to prohibit the use of the interface-specific label space for PW labels. This prohibition was necessary because the ingress PE doesn't know which of the egress PE's network-facing interfaces will actually receive a given packet. This draft doesn't have that problem, as it provides clear procedures for determining the context in which the upstream-assigned labels are looked up. From nobody Wed Aug 6 09:58:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EF71A03EC; Wed, 6 Aug 2014 09:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 1mgOf8mPSg72; Wed, 6 Aug 2014 09:58:35 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED22F1A03F9; Wed, 6 Aug 2014 09:58:34 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB727.namprd05.prod.outlook.com (10.141.223.23) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 16:58:25 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Wed, 6 Aug 2014 16:58:25 +0000 From: Yimin Shen To: "erosen@cisco.com" , Alexander Vainshtein Thread-Topic: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 Thread-Index: AQHPsY61gq4Nx047Wka0XW5Tq3yfmZvDxD8Q Date: Wed, 6 Aug 2014 16:58:24 +0000 Message-ID: References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx> In-Reply-To: <16167.1407340459@erosen-lnx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(164054003)(377454003)(189002)(199002)(37854004)(20776003)(85852003)(92566001)(15975445006)(19580405001)(76482001)(83072002)(99286002)(79102001)(76576001)(21056001)(77982001)(33646002)(99396002)(19580395003)(74502001)(74662001)(64706001)(83322001)(2656002)(87936001)(76176999)(54356999)(50986999)(106356001)(74316001)(106116001)(46102001)(31966008)(107046002)(86362001)(95666004)(4396001)(105586002)(81542001)(81342001)(85306004)(101416001)(66066001)(80022001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB727; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX: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/mpls/7UbT7zX1-z577Klmx4dVFkvqWJ0 Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 16:58:39 -0000 Hi Eric, Thanks very much for your review and comments! What you have described below is very accurate and indeed what this draft i= s basically about -- [1] Primary PE tells protector about PW labels; [2] Pr= otector stores the PW labels in a special place called context label table,= and knows when to look up label in this table; [3] PLR sets up a bypass tu= nnel to protector, and the bypass tunnel (UHP) serves as a hint (i.e. conte= xt) for protector to look up PW label in the context label table. These 3 pieces are glued together by context ID and RFC 5331. Only for [1] = the draft needs to define some LDP extensions. [2] is based on RFC 5331. [3= ] relies on existing IP/MPLS signaling and distribution protocols which are= sufficient, and there doesn't seem to be any difficulty that tunnels and b= ypass tunnels cannot be set up in a scalable way. Regarding why this draft calls the IP address as context ID rather than "an= ycast address", the main reason is that we wanted to emphasize its role of = "context" in context label switching, from forwarding's point of view. A co= ntext ID is owned by both primary PE and protector. When it is advertised b= y both routers via IGP/BGP, yes, it could be viewed as an anycast address i= n terms of reachability. Thanks, /Yimin -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rosen Sent: Wednesday, August 06, 2014 11:54 AM To: Alexander Vainshtein Cc: mpls@ietf.org; pwe3; pwe3-chairs@tools.ietf.org Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-p= rotection-01 - RFC4447 I've looked at this draft, and it seems to me that it does work in LDP-base= d networks (even with DU mode), and that it does not violate any architectu= ral principles. However, I have made certain assumptions that aren't expli= citly stated in the draft. (I am assuming that the draft is intended to be= patterned after the "anycast BGP" scheme that I've heard about about, but = that is not written up anywhere as far as I know.) Let me say how I think = it is intended to work, and the authors can correct me if I'm wrong. For protection against the failure of the "primary" egress PE: - A "primary egress PE" partitions its set of PWs into n sets, where each set is associated with a given "protector". The "protector" is the backu= p egress PE for those PWs. - Each such set is associated with an IP address. This IP address must be known both to the primary PE and to the protector. * One can think of this address as an "anycast" address that, to routing, denotes both the primary PE and the protector. At the primary PE and the protector, the address denotes a particular set of PWs. * These anycast addresses are distributed by routing, and good old fashioned MPLS labels get assigned to them by LDP. The primary PE MAY bind implicit null to that address, but the protector MUST NOT bind implicit null to that address. * Routing is set up so that (a) if the primary PE is up, traffic to the anycast address always goes to the primary PE, but (b) if the primary P= E is down, traffic to the anycast address goes to the protector instead. This can be achieved by messing with the metrics, e.g. - For a given PW, the primary PE informs both the protector and the ingress PE of (a) the label that it (the primary PE) has assigned to that PW, an= d the "anycast address" that corresponds to that PW. =20 This requires some new signaling (beyond that specified in RFC 4447), but the requisite signaling is specified in the draft. - When sending a packet on the given PW, the ingress PE pushes on the label assigned to the PW by the egress PE. Then the ingress PE pushes on whatever LDP-assigned label it need to use to get the packet to the anycast address that is associated with the PW. - When the protector learns that the egress PE has assigned a given label and anycast address to the PW, it stores that label in a context-specific label space associated with that anycast address. Whenever the protector receives a packet whose top label is the label that the protector has bound to the given anycast address, the protector looks up the next label in the corresponding label space. =20 Let's look at an example: CE1---PE1----PLR----PE2----CE2 | | |-----PE3-----| where PE3 is the protector for a PW connecting CE1 to CE2 (via PE1 and PE2 respectively). Call this pseudowire PW1. Thus there is some IP address, call it A, that PE2 and PE3 both advertise t= o routing. The metrics are set up so that as long as PE2 is up, it appears= to be a better path to A than does PE3. So PE2 assigns label L1 to PW1, and uses T-LDP to inform both PE1 and PE3 o= f this mapping. To PE1, these are just outgoing labels. To PE3, however, = they are incoming labels in a context-specific label space. PE2 and PE3 both assign labels to A (let's call these labels L2 and L3 resp= ectively), and distribute the corresponding label bindings to PLR. PLR als= o assigns a label to A, and distributes that label binding (L4) to PE1. When PE1 has a packet to send on PW1, it pushes L1, then pushes L4, then se= nds the packet to PLR. PLR swaps L4 with L2 and sends the packet to PE2. (Note that L2 could be implicit NULL.) PE2 sees label L1, and sends the pa= cket to CE2. Now if PE2 goes down, things happen a bit differently. When PLR gets a pac= ket with L4 on top, it swaps L4 with L3, and sends the packet to PE3. (In = this case, of course, L3 cannot be implicit NULL.) PE3 gets the packet, sees L3 on top, looks it up, and then says "L3 is a co= ntext label, so I have to pop it and then look up the following label in th= e L3-specific label table." This context-specific label table contains L1,= which has been bound to the PW that leads to CE2. So PE2 pops the label a= nd sends the packet to CE2. I think that's basically it, and the necessary mechanisms do seem to be des= cribed in the draft. The draft doesn't actually use the notion of "anycast= address" explicitly, but I think the intention is that the "context labels= " are definitely bound to anycast addresses. I hope the authors will corre= ct me if I'm wrong. Although the above example shows a PLR that is a neighbor of both PE2 and P= E3, this isn't really necessary, one could easily construct an example wher= e PE2 and PE3 have no neighbors in common. The example above doesn't rely on LDP DoD at all, and doesn't make use of a= ny RSVP-TE backup tunnels. However, when protecting against the failure of the egress AC, packets woul= d go first to PE2 then to PE3. This scenario is a bit different, in that: - I think this scenario may require an RSVP-TE backup tunnel (on which PHP is not used) from PE2 to PE3. - PE2 would have to signal PE3 to associate the given PW with the given backup tunnel. - The label that PE3 assigns to that backup tunnel would identify the context in which the PW label is looked up. This is perhaps more detail than is actually in the draft ;-) but if it is = an accurate description of the authors' intentions, the scheme seems to wor= k. I don't think this modifies the MPLS architecture at all. It is true that = the PE3 needs to maintain a context-specific label table that contains labe= ls assigned by PE2. While one may say that that is a "coordinated label sp= ace", it is no more than what is required by the nature of "upstream-assign= ed labels". I.e., if you can't support this level of coordination, you jus= t can't support upstream-assigned labels. Also, I don't think this draft is an "update" to RFC 4447. You don't need = to read this draft to implement RFC 4447, nor does it modify the procedures= of RFC 4447. It just introduces some new optional signaling and procedure= s. I don't think RFC 4447's requirement to use the "platform label space" should be interpreted as prohibiting the use of upstream-assigned labels. The intention of RFC 4447 was to prohibit the use of the interface-specific= label space for PW labels. This prohibition was necessary because the ing= ress PE doesn't know which of the egress PE's network-facing interfaces wil= l actually receive a given packet. This draft doesn't have that problem, a= s it provides clear procedures for determining the context in which the ups= tream-assigned labels are looked up. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Aug 6 15:46:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007EF1B28F8 for ; Wed, 6 Aug 2014 15:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 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.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1wM7j1KRpwK for ; Wed, 6 Aug 2014 15:46:46 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7E21B28AA for ; Wed, 6 Aug 2014 15:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4676; q=dns/txt; s=iport; t=1407365206; x=1408574806; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HjZ4/J2Tib80ZwtfJN9/WWO4w8Ytrh4Y9HSXDxi8v5o=; b=M8jNIdfwmIuurol65yGRVbfcLV932U49yNYxIYCyW+wMLy0m5MoO5H6K 840V0Q8Vt5v1SFR8MPpPn4LuOEypFgeSPkJAi6bDyLCb2Pq7lRJrqONWO vM0bZIEOJJY21GWIJtqrgc+qtW12rhvTeRKMLDCKNAZzpZLGSEHWWjMek E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAImv4lOtJA2E/2dsb2JhbABagmojUlcEzG0KhieBIQGBDhZ3hAMBAQEEAQEBNzEDFwICAgEIEQQBAQsUBQQHGwwLFAkIAgQBEgiIOgEMw3kTBASOZhEBHzgGgymBHAWOfaF8ghGBRmyBDTk X-IronPort-AV: E=Sophos;i="5.01,814,1400025600"; d="scan'208";a="67131077" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 06 Aug 2014 22:46:45 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s76MkjWB001389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Aug 2014 22:46:45 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 17:46:45 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95rvpygwvJHak669hrw561NhZvCdOXg Date: Wed, 6 Aug 2014 22:46:44 +0000 Message-ID: References: <53D8C464.6040403@pi.nu> In-Reply-To: <53D8C464.6040403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VHSsdXu3Ebef_cA6KnFoysgOZwU Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 22:46:49 -0000 Hi Loa, I have read this document and support the adoption as a WG document. Not on= ly does this document reduce signaling messages for P2MP-TE re-evaluation a= nd re-optimization, it allow a mid-point LSR to re-evaluate groups of S2L s= ub-LSPs together without some S2L sub-LSP grouping heuristics, which is qui= te beneficial. I have few suggestions to authors, but all are not at all stoppers before i= ts WG adoption.=20 1. This is a protocol extension that introduces new objects and procedures,= but the document lacks RFC2119 words (i.e. MAY, SHOULD, MUST, etc). It wou= ld be highly beneficial to make use of RFC2119 words where necessary (parti= cularly in Sections 3 and 4). 2. Abstract, first paragraph, last sentence was slightly difficult to read = and had a typo. Suggested new text. [OLD] Existing mechanisms allow the path re-evaluation and the signaling of a the notification of preferred path exists for a single S2L sub-LSP only. [NEW] Existing mechanisms, a mechanism for a head-end LSR to trigger a new path re-evaluation and a mechanism for a mid-point LSR to signal an availability of a preferred path, operate on a single S2L sub-LSP only. 3. Section 3, second paragraph. [snip] An ingress node may select one or more S2L sub-LSP of the P2MP-TE LSP tree to trigger the re-evaluation request(s). [snip] It may be beneficial to clarify the reason behind specifying one or more S2= L sub-LSPs, i.e. to specify the sub-groups. 4. Section 3, third paragraph. I'd like to propose a bit of rephrase in the last portion of this sentence,= for clarification purpose. [OLD] A mid-point LSR that expands loose next-hop(s) for one or more S2L sub-LSP path(s), and that receives a Path message with the "P2MP-TE Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE LSP tree by re-evaluating all S2L sub-LSP(s) expanded paths of the P2MP-TE LSP. [NEW] A mid-point LSR that expands loose next-hop(s) for one or more S2L sub-LSP path(s), and that receives a Path message with the "P2MP-TE Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE LSP tree by re-evaluating all S2L sub-LSP(s) that are expanded paths of the loose next-hop(s) of the P2MP-TE LSP. 5. Section 3, third paragraph (towards the end). [snip] In this case, the mid-point LSR that expands loose next- hop(s) for one or more S2L sub-LSP path(s) may select one or more S2L sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the ingress node. [snip] Similar to comment #3 above, it may be beneficial to clarify the reason beh= ind specifying one or more S2L sub-LSPs, i.e. to specify the sub-groups. 6. There's also a typo in the Security Considerations section. [OLD] it may be desirable for a a mid-point LSR to modify [NEW] it may be desirable for a mid-point LSR to modify [NOTE] s/a a /a / Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Wednesday, July 30, 2014 6:10 AM > To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN > (MARTIN); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org > Subject: [mpls] poll to see if we have support to make draft-tsaad-mpls- > p2mp-loose-path-reopt an mpls wg doc >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group > document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical motivation fo= r > your support/not support, especially if you think that the document shoul= d > not be adopted as a working group document. >=20 > There is one IPR claim against this document. >=20 > The authors and contributors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and aware o= f > IPR that relates to this draft, the time to disclose this is now. >=20 > This poll ends August 14, 2014. >=20 > /Loa >=20 > for the MPLS wg co-chairs > -- >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Aug 6 20:57:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3831A0A96; Wed, 6 Aug 2014 20:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 69_fecizhvne; Wed, 6 Aug 2014 20:57:08 -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 898081A0A86; Wed, 6 Aug 2014 20:57:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKY99311; Thu, 07 Aug 2014 03:57:05 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Aug 2014 04:57:05 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.78]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 7 Aug 2014 11:56:58 +0800 From: Mingui Zhang To: "erosen@cisco.com" , Alexander Vainshtein Thread-Topic: [PWE3] [mpls] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 Thread-Index: AQHPsY7DDiJw7y3ZEk+Q1kSqiialjpvEXftQ Date: Thu, 7 Aug 2014 03:56:57 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx> In-Reply-To: <16167.1407340459@erosen-lnx> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] 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/mpls/rK2ZHoSdMWkCNivUie0Da-RJuMM Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 03:57:14 -0000 Hi Eric,=20 The explanation of the story is very clear. Let me complement a bit. >- A "primary egress PE" partitions its set of PWs into n sets, where each > set is associated with a given "protector". The "protector" is the back= up > egress PE for those PWs. When the backup PE acts as the protector, it is the 'co-located' model. Acc= ording to the text in the draft, the protector can also be any other PEs or= Ps. That is the 'centralized' model. In this model, operators are allowed = to designate the protector. Authors can correct me if I am wrong. >However, when protecting against the failure of the egress AC, packets wou= ld >go first to PE2 then to PE3. This scenario is a bit different, in that: > >- I think this scenario may require an RSVP-TE backup tunnel (on which PHP > is not used) from PE2 to PE3. > >- PE2 would have to signal PE3 to associate the given PW with the given > backup tunnel. > >- The label that PE3 assigns to that backup tunnel would identify the > context in which the PW label is looked up. > >This is perhaps more detail than is actually in the draft ;-) but if it is >an accurate description of the authors' intentions, the scheme seems to >work. I think the failure of the egress AC can't be handled as normal because the= failure does not break the anycast IP address. Since this IP address used = to be set to the loopback IP address of the PE. We know it's alive even tho= se physical interfaces are broken. So I understand why you advise to handle= the AC failures separately using the RSVP-TE backup tunnel. I think we still have the chance to incorporate it into the single LDP base= d scheme: We can replace the anycast IP address with an IP address of a virtual route= r. A link between the primary PE and the virtual router will appear in the = routing. When the primary PE detect the AC failure. It acts as the PLR. It = just translates it into a link failure of the routing and starts to use the= backup tunnel that is prepared in advance for the link failure. One concern is that "do we have scalability issue with these backup tunnels= "? IOW, do we have to set up backup tunnels per AC? The answer is no. Actua= lly, a set of ACs can multiplex the same backup tunnel if their correspondi= ng CEs are multi-homed to the same pair of . Thanks, Mingui >-----Original Message----- >From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Eric Rosen >Sent: Wednesday, August 06, 2014 11:54 PM >To: Alexander Vainshtein >Cc: mpls@ietf.org; pwe3; pwe3-chairs@tools.ietf.org; stbryant@cisco.com >Subject: Re: [PWE3] [mpls] WG Last Call for >draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 > >I've looked at this draft, and it seems to me that it does work in LDP-bas= ed >networks (even with DU mode), and that it does not violate any architectur= al >principles. However, I have made certain assumptions that aren't explicit= ly >stated in the draft. (I am assuming that the draft is intended to be >patterned after the "anycast BGP" scheme that I've heard about about, but >that is not written up anywhere as far as I know.) Let me say how I think >it is intended to work, and the authors can correct me if I'm wrong. > >For protection against the failure of the "primary" egress PE: > >- A "primary egress PE" partitions its set of PWs into n sets, where each > set is associated with a given "protector". The "protector" is the back= up > egress PE for those PWs. > >- Each such set is associated with an IP address. This IP address must be > known both to the primary PE and to the protector. > > * One can think of this address as an "anycast" address that, to routing= , > denotes both the primary PE and the protector. At the primary PE and > the protector, the address denotes a particular set of PWs. > > * These anycast addresses are distributed by routing, and good old > fashioned MPLS labels get assigned to them by LDP. The primary PE MAY > bind implicit null to that address, but the protector MUST NOT bind > implicit null to that address. > > * Routing is set up so that (a) if the primary PE is up, traffic to the > anycast address always goes to the primary PE, but (b) if the primary = PE > is down, traffic to the anycast address goes to the protector instead. > This can be achieved by messing with the metrics, e.g. > >- For a given PW, the primary PE informs both the protector and the ingres= s > PE of (a) the label that it (the primary PE) has assigned to that PW, a= nd > the "anycast address" that corresponds to that PW. > > This requires some new signaling (beyond that specified in RFC 4447), bu= t > the requisite signaling is specified in the draft. > >- When sending a packet on the given PW, the ingress PE pushes on the labe= l > assigned to the PW by the egress PE. Then the ingress PE pushes on > whatever LDP-assigned label it need to use to get the packet to the > anycast address that is associated with the PW. > >- When the protector learns that the egress PE has assigned a given label > and anycast address to the PW, it stores that label in a context-specifi= c > label space associated with that anycast address. Whenever the protecto= r > receives a packet whose top label is the label that the protector has > bound to the given anycast address, the protector looks up the next labe= l > in the corresponding label space. > >Let's look at an example: > >CE1---PE1----PLR----PE2----CE2 > | | > |-----PE3-----| > >where PE3 is the protector for a PW connecting CE1 to CE2 (via PE1 and PE2 >respectively). Call this pseudowire PW1. > >Thus there is some IP address, call it A, that PE2 and PE3 both advertise = to >routing. The metrics are set up so that as long as PE2 is up, it appears = to >be a better path to A than does PE3. > >So PE2 assigns label L1 to PW1, and uses T-LDP to inform both PE1 and PE3 = of >this mapping. To PE1, these are just outgoing labels. To PE3, however, >they are incoming labels in a context-specific label space. > >PE2 and PE3 both assign labels to A (let's call these labels L2 and L3 >respectively), and distribute the corresponding label bindings to PLR. PL= R >also assigns a label to A, and distributes that label binding (L4) to PE1. > >When PE1 has a packet to send on PW1, it pushes L1, then pushes L4, then >sends the packet to PLR. PLR swaps L4 with L2 and sends the packet to PE2= . >(Note that L2 could be implicit NULL.) PE2 sees label L1, and sends the >packet to CE2. > >Now if PE2 goes down, things happen a bit differently. When PLR gets a >packet with L4 on top, it swaps L4 with L3, and sends the packet to PE3. = (In >this case, of course, L3 cannot be implicit NULL.) > >PE3 gets the packet, sees L3 on top, looks it up, and then says "L3 is a >context label, so I have to pop it and then look up the following label in >the L3-specific label table." This context-specific label table contains >L1, which has been bound to the PW that leads to CE2. So PE2 pops the lab= el >and sends the packet to CE2. > >I think that's basically it, and the necessary mechanisms do seem to be >described in the draft. The draft doesn't actually use the notion of >"anycast address" explicitly, but I think the intention is that the "conte= xt >labels" are definitely bound to anycast addresses. I hope the authors wil= l >correct me if I'm wrong. > >Although the above example shows a PLR that is a neighbor of both PE2 and >PE3, this isn't really necessary, one could easily construct an example >where PE2 and PE3 have no neighbors in common. > >The example above doesn't rely on LDP DoD at all, and doesn't make use of >any RSVP-TE backup tunnels. > >However, when protecting against the failure of the egress AC, packets wou= ld >go first to PE2 then to PE3. This scenario is a bit different, in that: > >- I think this scenario may require an RSVP-TE backup tunnel (on which PHP > is not used) from PE2 to PE3. > >- PE2 would have to signal PE3 to associate the given PW with the given > backup tunnel. > >- The label that PE3 assigns to that backup tunnel would identify the > context in which the PW label is looked up. > >This is perhaps more detail than is actually in the draft ;-) but if it is >an accurate description of the authors' intentions, the scheme seems to >work. > >I don't think this modifies the MPLS architecture at all. It is true that >the PE3 needs to maintain a context-specific label table that contains >labels assigned by PE2. While one may say that that is a "coordinated lab= el >space", it is no more than what is required by the nature of >"upstream-assigned labels". I.e., if you can't support this level of >coordination, you just can't support upstream-assigned labels. > >Also, I don't think this draft is an "update" to RFC 4447. You don't need >to read this draft to implement RFC 4447, nor does it modify the procedure= s >of RFC 4447. It just introduces some new optional signaling and procedure= s. >I don't think RFC 4447's requirement to use the "platform label space" >should be interpreted as prohibiting the use of upstream-assigned labels. >The intention of RFC 4447 was to prohibit the use of the interface-specifi= c >label space for PW labels. This prohibition was necessary because the >ingress PE doesn't know which of the egress PE's network-facing interfaces >will actually receive a given packet. This draft doesn't have that proble= m, >as it provides clear procedures for determining the context in which the >upstream-assigned labels are looked up. > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From nobody Thu Aug 7 00:27:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894E31B2855; Thu, 7 Aug 2014 00:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 S86jMkb95Nbb; Thu, 7 Aug 2014 00:26:59 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B4D1B27E0; Thu, 7 Aug 2014 00:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=634; q=dns/txt; s=iport; t=1407396418; x=1408606018; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5KZ22G/ouSAJcq5vd2Bti2HyrxM1KiVw8+pPWdbK6ZE=; b=mi/BbSWmcYZJ+vABruFWDqfszVGgCeeKSaENvbvdaV3pFIMHTbSihl3O i+EJKwxRzWkXhsRZnNCrirpWTNGscURmLGhzb+XS8qwn8lGD3dQwpCd5a 0rwvSHRhrftqt9sIR0h71RojWpqB1Fa1EAwlKxoQQfHZw0Bgt7z2130pg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFABIq41OtJA2B/2dsb2JhbABagw2BKa8KpREBgRMWd4QDAQEBAwEdHT8FCwIBCBgeEDIlAgQOBYg6CMNuF4wdgkQ4MweDL4EcAQScGJRtghGBRmw X-IronPort-AV: E=Sophos;i="5.01,816,1400025600"; d="scan'208";a="67168641" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 07 Aug 2014 07:26:57 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s777Qvfx015491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 07:26:57 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 02:26:57 -0500 From: "Stewart Bryant (stbryant)" To: Mingui Zhang Thread-Topic: [PWE3] [mpls] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 Thread-Index: AQHPsY7DDiJw7y3ZEk+Q1kSqiialjpvEXftQgABg1hg= Date: Thu, 7 Aug 2014 07:26:56 +0000 Message-ID: <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dV8m_2rYDVSyk8TauINfMe73b88 Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 07:27:00 -0000 Sent from my iPad > On 7 Aug 2014, at 04:57, "Mingui Zhang" wrote: >=20 > Hi Eric,=20 >=20 > The explanation of the story is very clear. Let me complement a bit. >=20 >> - A "primary egress PE" partitions its set of PWs into n sets, where eac= h >> set is associated with a given "protector". The "protector" is the back= up >> egress PE for those PWs. >=20 > When the backup PE acts as the protector, it is the 'co-located' model.=20 This case does not however need context labels. It is a form of S-PE and ca= n stitch the PWs just like every existing S-PE already does. Stewart From nobody Thu Aug 7 06:52:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19F61B2B32; Thu, 7 Aug 2014 06:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 e53Ajc-MODFj; Thu, 7 Aug 2014 06:52:30 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0016.outbound.protection.outlook.com [213.199.154.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6584F1B2B1D; Thu, 7 Aug 2014 06:52:29 -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.995.14; Thu, 7 Aug 2014 13:52:27 +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.1005.008; Thu, 7 Aug 2014 13:52:27 +0000 From: Alexander Vainshtein To: "erosen@cisco.com" Thread-Topic: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 Thread-Index: AQHPsY6z5lHYoEzJm0ODJoEdFDIfx5vFBHcg Date: Thu, 7 Aug 2014 13:52:26 +0000 Message-ID: <3be1532ff6644212b98eed535fccce9b@AM3PR03MB612.eurprd03.prod.outlook.com> References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx> In-Reply-To: <16167.1407340459@erosen-lnx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(37854004)(13464003)(189002)(199002)(377454003)(252514010)(51444003)(76482001)(81342001)(2351001)(74502001)(83322001)(66066001)(4396001)(21056001)(77982001)(74316001)(33646002)(2656002)(87936001)(101416001)(74662001)(106356001)(110136001)(81542001)(86362001)(80022001)(76576001)(106116001)(83072002)(76176999)(46102001)(19580405001)(19580395003)(107046002)(20776003)(64706001)(85306004)(95666004)(99396002)(54356999)(50986999)(105586002)(85852003)(2501001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; 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/mpls/rsPYlN9Gy5dhsN92-Rl2KN04xO4 Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 13:52:34 -0000 Eric, Lots of thanks for a very detailed and clear response. It is by far more re= adable (from my point of view) than the original text in the draft. It has = really helped me to understand the intention of the authors and some new po= tential pitfalls with this draft. I agree with most of your comments about fundamental differences between pr= otection against the failure of the Primary PE and protection against the "= egress AC failure". =20 I have some LDP-related questions that stem directly from your responses (I= have added Loa to this thread). You have explained (and the draft also say= s that!) that the "context identifier" IP addresses must be known to both t= he primary PE and the Protector, LDP assigning labels for them and distribu= ting corresponding Label Mappings. 1. I assume that this means that both the Primary PE and the Protector "own= " this IP address, and, as a consequence, include it in the LDP Address mes= sages they send to their respective adjacencies. Is this correct?=20 2. If the answer to the previous question is "Yes", what is supposed to hap= pen if the Primary PE and the Protector have a common adjacent P router? (This would be the case shown in Figure 5 in the draft if P3 were physi= cally connected both to PE2 and PE4). Such a router would see the same IP address in the LDP Address message= s received from two different adjacencies. Can LDP handle such a situation? Is it covered by RFC 5036? 3. If the answer for to my first question is "No", what would cause LDP in = the Primary PE and the Protector to allocate a terminated label (i.e.,=20 a label with action "Pop" in the ILM) to the FEC represented by the co= ntext identifier IP address? And how would the PLR understand that it is th= e penultimate hop towards the Primary PE? =20 I also have some doubts regarding ability to tweak the metrics in the netwo= rk in such a way that, as you've explained: - As long as the Primary PE is up, the PLR sees it as the best Next Hop fo= r the "context identifier" IP address - Once the Primary PE is Down, the PLR sees the Protector as best Next Hop = for the "context identifier" IP address. These doubts are based on the following concerns: 1. Potential impact of ECMP.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Suppose that ECMP is employed in the network, and that, as a consequenc= e, there are multiple penultimate Next Hops=20 On multiple equal cost LSPs between PE1 and the Primary PE2. Is it poss= ible by just playing with the metrics to guarantee that: - As long as the Primary PE2 is Up, each potential PLR would see it as = the best next Hop towards the "context identifier" - Once PE2 is Down, each potential PLR (which would only know that its = own link to the Primary PE has failed ) would treat the Protector as its be= st Next Hop towards the "context identifier"? 2. Potential impact of changes in the network topology.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Suppose that the metrics have been initially tweaked as required. Then = some links between the PLR and the Protector fail so that the cost of the available path betwe= en them increases. Now, when the Primary PE goes Down, the PLR only sees th= at Its link to the Primary PE goes down, but the cost of some alternative = path towards the "context identifier" could now still lead to the Primary P= E.=20 Due to these concerns, my personal bottom line is that operating the propos= ed mechanism over an MPLS network with LSPs instantiated using LDP in DU mo= de is sometimes possible but always tricky. =20 Regards, and,again, lots of thanks, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, August 06, 2014 6:54 PM > To: Alexander Vainshtein > Cc: stbryant@cisco.com; mpls@ietf.org; pwe3; pwe3-chairs@tools.ietf.org > Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast= - > protection-01 - RFC4447 >=20 > I've looked at this draft, and it seems to me that it does work in LDP-ba= sed > networks (even with DU mode), and that it does not violate any architectu= ral > principles. However, I have made certain assumptions that aren't explici= tly > stated in the draft. (I am assuming that the draft is intended to be pat= terned > after the "anycast BGP" scheme that I've heard about about, but that is n= ot > written up anywhere as far as I know.) Let me say how I think it is inte= nded > to work, and the authors can correct me if I'm wrong. >=20 > For protection against the failure of the "primary" egress PE: >=20 > - A "primary egress PE" partitions its set of PWs into n sets, where each > set is associated with a given "protector". The "protector" is the bac= kup > egress PE for those PWs. >=20 > - Each such set is associated with an IP address. This IP address must b= e > known both to the primary PE and to the protector. >=20 > * One can think of this address as an "anycast" address that, to routin= g, > denotes both the primary PE and the protector. At the primary PE and > the protector, the address denotes a particular set of PWs. >=20 > * These anycast addresses are distributed by routing, and good old > fashioned MPLS labels get assigned to them by LDP. The primary PE MA= Y > bind implicit null to that address, but the protector MUST NOT bind > implicit null to that address. >=20 > * Routing is set up so that (a) if the primary PE is up, traffic to the > anycast address always goes to the primary PE, but (b) if the primary= PE > is down, traffic to the anycast address goes to the protector instead= . > This can be achieved by messing with the metrics, e.g. >=20 > - For a given PW, the primary PE informs both the protector and the ingre= ss > PE of (a) the label that it (the primary PE) has assigned to that PW, = and > the "anycast address" that corresponds to that PW. >=20 > This requires some new signaling (beyond that specified in RFC 4447), b= ut > the requisite signaling is specified in the draft. >=20 > - When sending a packet on the given PW, the ingress PE pushes on the lab= el > assigned to the PW by the egress PE. Then the ingress PE pushes on > whatever LDP-assigned label it need to use to get the packet to the > anycast address that is associated with the PW. >=20 > - When the protector learns that the egress PE has assigned a given label > and anycast address to the PW, it stores that label in a context-specif= ic > label space associated with that anycast address. Whenever the protect= or > receives a packet whose top label is the label that the protector has > bound to the given anycast address, the protector looks up the next lab= el > in the corresponding label space. >=20 > Let's look at an example: >=20 > CE1---PE1----PLR----PE2----CE2 > | | > |-----PE3-----| >=20 > where PE3 is the protector for a PW connecting CE1 to CE2 (via PE1 and PE= 2 > respectively). Call this pseudowire PW1. >=20 > Thus there is some IP address, call it A, that PE2 and PE3 both advertise= to > routing. The metrics are set up so that as long as PE2 is up, it appears= to be a > better path to A than does PE3. >=20 > So PE2 assigns label L1 to PW1, and uses T-LDP to inform both PE1 and PE3= of > this mapping. To PE1, these are just outgoing labels. To PE3, however, = they > are incoming labels in a context-specific label space. >=20 > PE2 and PE3 both assign labels to A (let's call these labels L2 and L3 > respectively), and distribute the corresponding label bindings to PLR. P= LR > also assigns a label to A, and distributes that label binding (L4) to PE1= . >=20 > When PE1 has a packet to send on PW1, it pushes L1, then pushes L4, then > sends the packet to PLR. PLR swaps L4 with L2 and sends the packet to PE= 2. > (Note that L2 could be implicit NULL.) PE2 sees label L1, and sends the = packet > to CE2. >=20 > Now if PE2 goes down, things happen a bit differently. When PLR gets a > packet with L4 on top, it swaps L4 with L3, and sends the packet to PE3. = (In > this case, of course, L3 cannot be implicit NULL.) >=20 > PE3 gets the packet, sees L3 on top, looks it up, and then says "L3 is a = context > label, so I have to pop it and then look up the following label in the L3= -specific > label table." This context-specific label table contains L1, which has b= een > bound to the PW that leads to CE2. So PE2 pops the label and sends the > packet to CE2. >=20 > I think that's basically it, and the necessary mechanisms do seem to be > described in the draft. The draft doesn't actually use the notion of "an= ycast > address" explicitly, but I think the intention is that the "context label= s" are > definitely bound to anycast addresses. I hope the authors will correct m= e if > I'm wrong. >=20 > Although the above example shows a PLR that is a neighbor of both PE2 and > PE3, this isn't really necessary, one could easily construct an example w= here > PE2 and PE3 have no neighbors in common. >=20 > The example above doesn't rely on LDP DoD at all, and doesn't make use of > any RSVP-TE backup tunnels. >=20 > However, when protecting against the failure of the egress AC, packets > would go first to PE2 then to PE3. This scenario is a bit different, in = that: >=20 > - I think this scenario may require an RSVP-TE backup tunnel (on which PH= P > is not used) from PE2 to PE3. >=20 > - PE2 would have to signal PE3 to associate the given PW with the given > backup tunnel. >=20 > - The label that PE3 assigns to that backup tunnel would identify the > context in which the PW label is looked up. >=20 > This is perhaps more detail than is actually in the draft ;-) but if it i= s an > accurate description of the authors' intentions, the scheme seems to work= . >=20 > I don't think this modifies the MPLS architecture at all. It is true tha= t the PE3 > needs to maintain a context-specific label table that contains labels ass= igned > by PE2. While one may say that that is a "coordinated label space", it i= s no > more than what is required by the nature of "upstream-assigned labels". > I.e., if you can't support this level of coordination, you just can't sup= port > upstream-assigned labels. >=20 > Also, I don't think this draft is an "update" to RFC 4447. You don't nee= d to > read this draft to implement RFC 4447, nor does it modify the procedures = of > RFC 4447. It just introduces some new optional signaling and procedures. > I don't think RFC 4447's requirement to use the "platform label space" > should be interpreted as prohibiting the use of upstream-assigned labels. > The intention of RFC 4447 was to prohibit the use of the interface-specif= ic > label space for PW labels. This prohibition was necessary because the in= gress > PE doesn't know which of the egress PE's network-facing interfaces will > actually receive a given packet. This draft doesn't have that problem, a= s it > provides clear procedures for determining the context in which the > upstream-assigned labels are looked up. >=20 >=20 From nobody Thu Aug 7 06:56:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DEF1B2B33; Thu, 7 Aug 2014 06:56:43 -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 v5w5T7gUqXHe; Thu, 7 Aug 2014 06:56:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605661B2AF8; Thu, 7 Aug 2014 06:56:40 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB726.namprd05.prod.outlook.com (10.141.223.19) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 7 Aug 2014 13:56:37 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Thu, 7 Aug 2014 13:56:37 +0000 From: Yimin Shen To: Loa Andersson , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" , "mpls@ietf.org" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqBiOFwGKWlhnR0Cl4HRHJXR0fZvDnKwAgAGhqCA= Date: Thu, 7 Aug 2014 13:56:37 +0000 Message-ID: <3fe4383993b8486da7a6a6bb164d492f@BY2PR05MB728.namprd05.prod.outlook.com> References: <53E226FC.7020302@pi.nu> In-Reply-To: <53E226FC.7020302@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(24454002)(164054003)(252514010)(377454003)(377424004)(199002)(85306004)(66066001)(19580395003)(33646002)(20776003)(15202345003)(74316001)(76176999)(81342001)(64706001)(54356999)(81542001)(99396002)(50986999)(80022001)(86362001)(2201001)(101416001)(95666004)(106356001)(87936001)(2656002)(105586002)(106116001)(46102001)(77982001)(107046002)(83072002)(76482001)(19580405001)(4396001)(99286002)(74502001)(74662001)(21056001)(107886001)(15975445006)(76576001)(83322001)(85852003)(2501001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB726; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Klu8UC5QVinfmqy0Y2hAtOnEqOo Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 13:56:44 -0000 Hi Loa, Thanks very much for your review and comments. Thanks, /Yimin -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, August 06, 2014 9:01 AM To: Bocci, Matthew (Matthew); pwe3@ietf.org; mpls@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protecti= on-01 PWE3-chairs and authors, I must confess I find this document hard to read, I had to have some help t= o do so. After going over it carefully I'm convinced that it does not mess with MPLS= Architecture. However I also not convinced that this is ready to go, and I'm not really s= ure what we need to do progress it. In its current form we are probably pus= hing critical review to ADs, IESG and the RFC Editor. Seems to b e the wron= g thing to do. What I think we could do is to invoke the rtg area language review team and= do a careful language review. When that is done (hoping that most of the p= roblems disappear) we should run an MPLS architecture / PWE3 concept check = up and finish of with a short wg last call. /Loa On 2014-07-25 16:56, Bocci, Matthew (Matthew) wrote: > This email begins a second two week working group last call for > http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 . > > Please review the draft and post any comments to the PWE3 list. > > If you have read the draft, even if you don=B9t have any comments, but=20 > would like to see the draft progressed, please can you indicate this=20 > to the list. > > This working group last call will end on Friday August 8th, 2014. > > > Best regards > > > Matthew and Andy > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Thu Aug 7 08:02:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932531B2BF1; Thu, 7 Aug 2014 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 rHLJn6GUxROP; Thu, 7 Aug 2014 08:01:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AB01B2BE1; Thu, 7 Aug 2014 08:01:54 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB726.namprd05.prod.outlook.com (10.141.223.19) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 7 Aug 2014 15:01:51 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Thu, 7 Aug 2014 15:01:51 +0000 From: Yimin Shen To: "stbryant@cisco.com" , pwe3 , "pwe3-chairs@tools.ietf.org" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqzzbzRsIO8QlbkK+kbMBZ9MDf5u4teQwgAkrcYCAA1mgIA== Date: Thu, 7 Aug 2014 15:01:51 +0000 Message-ID: <3fd1f1049aff43c99cbd3ff14e1f6c30@BY2PR05MB728.namprd05.prod.outlook.com> References: <53D7B569.60400@cisco.com> <53E0B85B.8060707@cisco.com> In-Reply-To: <53E0B85B.8060707@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(24454002)(51444003)(164054003)(51704005)(37854004)(377454003)(479174003)(199002)(85306004)(66066001)(19580395003)(33646002)(20776003)(15202345003)(74316001)(76176999)(81342001)(64706001)(54356999)(81542001)(99396002)(50986999)(80022001)(92566001)(86362001)(101416001)(95666004)(106356001)(79102001)(87936001)(2656002)(105586002)(106116001)(46102001)(77982001)(107046002)(83072002)(19580405001)(4396001)(76482001)(99286002)(74502001)(31966008)(21056001)(15975445006)(83322001)(76576001)(85852003)(2501001)(24736002)(108616003)(579004)(559001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB726; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/nZLxRtrF0Z0Ck7rIsardZEDAdGU Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:02:15 -0000 SGkgU3Rld2FydCwNCg0KVGhhbmtzIHZlcnkgbXVjaCBhZ2FpbiBmb3IgdGhlIHJldmlldyBhbmQg ZGV0YWlsZWQgY29tbWVudHMuDQoNCldlIHdpbGwgY29uc2lkZXIgeW91ciBzdWdnZXN0aW9ucyBv biB0aGUgTERQIFRMViBzdHJ1Y3R1cmVzIGRlZmluZWQgaW4gdGhpcyBkcmFmdC4NCg0KUmVnYXJk aW5nIHRoZSB0cmFkZW9mZiBiZXR3ZWVuIHRoZSBuZWVkIGZvciBlZ3Jlc3MgUEUgbm9kZSBwcm90 ZWN0aW9uIGFuZCB0aGUgaW5jcmVhc2VkIHN0YXRlIGFuZCBjb21wbGV4aXR5IGluIFBTTiwgdGhp cyBpcyBhIGNvbW1vbiBjb25zaWRyYXRpb24gZm9yIGFsbCBJUC9NUExTIG5vZGUgcHJvdGVjdGlv biwgbm90IFBXRTMgc3BlY2lmaWMuIFdlIGRvIHNlZSB0aGUgcmVxdWlyZW1lbnQgZnJvbSBzZXJ2 aWNlIHByb3ZpZGVycy4gSSB0aGluayB0aGlzIHNob3VsZCBiZSB0aGVpciBkZWNpc2lvbiBvbiBh IHBlciBuZXR3b3JrIGJhc2lzLiBXaGVuIHRoZXkgZGVjaWRlIHRvIGRvIGl0LCB3ZSBoYXZlIGEg c29sdXRpb24gYXZhaWxhYmxlIGZvciB0aGVtLg0KDQpUaGF0IHNhaWQsIHRoaXMgZHJhZnQgZG9l c24ndCBuZWNlc3NhcmlseSBtdWx0aXBseSB0aGUgbnVtYmVyIG9mIFBTTiB0dW5uZWxzLiBJdCBk b2VzIHJlcXVpcmUgb25lIHR1bm5lbCBwZXIgPHByaW1hcnkgUEUsIHByb3RlY3Rvcj4uIEhvd2V2 ZXIsIGlmIGVhY2ggcHJpbWFyeSBQRSBpcyBwcm90ZWN0ZWQgYnkgb25seSAxIHByb3RlY3Rvciwg dGhlIG51bWJlciBvZiB0dW5uZWwgd2lsbCBiZSB0aGUgbnVtYmVyIG9mIHByaW1hcnkgUEVzLCB3 aGljaCBpcyBiYXNpY2FsbHkgdGhlIHNhbWUgYXMgdGhlIGNhc2Ugd2hlcmUgdGhpcyBtZWNoYW5p c20gaXMgbm90IHVzZWQuIFRoaXMgMToxIHJlbGF0aW9uc2hpcCBpcyBhY2hpZXZhYmxlIHdpdGgg dGhlIGNvLWxvY2F0ZWQgbW9kZWwsIGFuZCBpcyBlc3BlY2lhbGx5IGFjaGlldmFibGUgd2l0aCB0 aGUgY2VudHJhbGl6ZWQgbW9kZWwuIE9mIGNvdXJzZSwgaW4gYSBtb3JlIGdlbmVyYWwgY2FzZSwg aWYgdGhlIGF2YXJhZ2UgUEUtdG8tcHJvdGVjdG9yIHJhdGlvIGlzIDE6TiwgdGhlIG51bWJlciBv ZiB0dW5uZWxzIHdpbGwgYmUgbXVsdGlwbGllZCBieSBOLiBCdXQgb3BlcmF0b3JzIGNhbiBhbHdh eXMgZGVzaWduIHRoZWlyIG5ldHdvcmtzIHRob3VnaHRmdWxseSBhbmQgbWFuYWdlIHRoaXMgTiB0 byBiZSBsb3dldmVyIHRoYW4gdGhlIHRocmVzaG9sZCB0aGF0IG1heSBsZWFkIHRvIHNjYWxhYmls aXR5IHByb2JsZW1zLiAoSGVyZSwgSSdtIG5vdCBjb3VudGluZyBieXBhc3MgdHVubmVscyBpbiwg YmVjYXVzZSBieXBhc3MgdHVubmVscyBleGlzdCBpbiB0aGUgZXhpc3RpbmcgSVAvTVBMUyBmYXN0 LXJlcm91dGUgYXMgd2VsbC4pDQoNClRoYW5rcywNCg0KL1lpbWluDQoNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3Rld2FydCBCcnlhbnQgW21haWx0bzpzdGJyeWFudEBj aXNjby5jb21dIA0KU2VudDogVHVlc2RheSwgQXVndXN0IDA1LCAyMDE0IDY6NTYgQU0NClRvOiBZ aW1pbiBTaGVuOyBwd2UzOyBwd2UzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KQ2M6IG1wbHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbUFdFM10gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXB3 ZTMtZW5kcG9pbnQtZmFzdC1wcm90ZWN0aW9uLTAxDQoNCk9uIDMwLzA3LzIwMTQgMjA6MDcsIFlp bWluIFNoZW4gd3JvdGU6DQo+IEhpIFN0ZXdhcnQsDQo+DQo+IFRoYW5rcyB2ZXJ5IG11Y2ggZm9y IHRoZSBkZXRhaWxlZCByZXZpZXcgYW5kIGNvbW1lbnRzLiBJJ2QgbGlrZSB0byBoaWdobGlnaHQg YSBmZXcgdGhpbmdzIGJlbG93IGFib3V0IHRoaXMgZHJhZnQsIGFuZCB0aGVuIHJlc3BvbmQgdG8g eW91ciBjb21tZW50cyBpbmxpbmUuIEhvcGUgeW91IGNvdWxkIGdpdmUgdGhlIGRyYWZ0IGFub3Ro ZXIgY2xvc2VyIGxvb2suDQpZaW1pbiwNCg0KSGF2aW5nIHJlYWQgeW91ciByZXBseSBhbmQgaGF2 aW5nIGxvb2tlZCBhdCB0aGUgdGV4dCBhZ2FpbiwNCmFuZCB0YWxrZWQgdG8gYSBmZXcgZm9sa3Mg SSB0aGluayBJIG5vdyB1bmRlcnN0YW5kIHRoZSB0b3ANCmxldmVsIHZpZXcgb2Ygd2hhdCBpcyBw cm9wb3NlZC4gSG93ZXZlciB0aGF0IGlzIGluIGl0c2VsZg0KYW4gaW5kaWNhdGlvbiB0aGF0IHRo ZSBkcmFmdCBuZWVkcyBjb25zaWRlcmFibGUgd29yaw0KYmVmb3JlIHB1YmxpY2F0aW9uLiBOb3Rl IHRoYXQgaXQgd2FzIG5vdCBpbml0aWFsbHkgb2J2aW91cw0KdGhhdCB5b3Ugc3VwcG9ydGVkIGJv dGggTERQIGFuZCBSU1ZQLVRFIFBTTnMsIG5vcg0Kd2FzIGl0IGluaXRpYWxseSBvYnZpb3VzIHRo YXQgeW91IHdlcmUgdXNpbmcgdGhlIFBTTiB0bw0KcHJvdGVjdCB0aGUgUFdzIGFuZCBub3QgbG9v a2luZyBmdXJ0aGVyIGRvd24gdGhlIHN0YWNrLg0KSW5kZWVkIEkgdGhpbmsgdGhlcmUgaXMgc29t ZSB0ZXh0IGluIHRoZSBkcmFmdCB0aGF0IHBvc2l0aXZlbHkNCmxlYWRzIHlvdSBpbiB0aGF0IGRp cmVjdGlvbiBzaW5jZSBzb21lb25lIGVsc2UgcGlja2VkDQppdCBpdCBkdXJpbmcgYW4gTVBMUyBy ZXZpZXcuDQoNClRvIHN1bW1hcml6ZTogd2hhdCB5b3UgYXJlIGRvaW5nIGlzIGNvbnN0cnVjdCAg cmVwYWlycw0KYXQgdGhlIFBTTiBsYXllciB0aGF0IG1hcCB0byBlYWNoIGNvbWJpbmF0aW9uIG9m IFBXICsgUFcgcmVwYWlyLA0Kd2hpY2ggSSB0aGluayBtdWx0aXBsZXMgdGhlIG51bWJlciBvZiBQ U04gdHVubmVscyBieSB0aHJlZSB0aW1lcw0KdGhlIGRpc3BlcnNpb24gZmFjdG9yIHdoZXJlIHRo ZSBkaXNwZXJzaW9uIGZhY3RvciBpcyBzb21lIGZhY3Rvcg0KZGVmaW5pbmcgdGhlIGF2ZXJhZ2Ug bnVtYmVyIG9mIFBFcyB0aGF0IHRoZSBQV3MgYWRkcmVzc2VkIHRvDQphIHNpbmdsZSBQRSBuZWVk IHRvIGJlIGRpc3BlcnNlZCB0by4NCg0KVGhpcyBsZWFkcyB0byB0d28gcXVlc3Rpb25zIHRoYXQg dGhlIFdHIG5lZWRzIHRvIHRoaW5rIGFib3V0Og0KDQoxKSBUaGlzIGlzIHRyYWRpbmcgaW5jcmVh c2VkIFBTTiBzdGF0ZSBmb3IgcmVzcG9uc2UgdGltZS4NCkdpdmVuIHRoYXQgUFNOIHN0YXRlIHdh cyBhIGNyaXRpY2FsIGZhY3RvciBpbiB0aGUgY2hvaWNlIG9mIHRoZSBNYXJ0aW5pDQpkZXNpZ24g b3ZlciB0aGUgQ0NDIGRlc2lnbiB0aGlzIG5lZWRzIHRvIGJlIG1hZGUgY2xlYXIgdXAgZnJvbnQN CmluIHRoZSB0ZXh0IGFuZCB0aGUgV0cgbmVlZHMgdG8gZGVjaWRlIHRoYXQgdGhpcyBpcyBhY2Nl cHRhYmxlLg0KDQoyKSBUaGlzIGluY3JlYXNlZCBzdGF0ZSBhbmQgdGhlIGNvbXBsZXhpdHkgb2Yg aW50cm9kdWNpbmcNCmNvbnRleHQgbGFiZWxzIGFuZCBwcm90ZWN0aW9uIHJvdXRlcnMgdG8gdGhl IFBXRTMgYXJjaGl0ZWN0dXJlDQppcyBkaXJlY3RseSB0cmFjZWFibGUgdG8gdGhlIG5lZWQgdG8g ZG8geFBFIG5vZGUgcHJvdGVjdGlvbiwNCmFuZCBpcyBub3QgcmVxdWlyZWQgZm9yIGxpbmsgcHJv dGVjdGlvbiBpbmNsdWRpbmcgdGhlIGVncmVzcyBBQy4NCg0KVGhpcyBkZXNpcmUgdG8gYnVpbGQg dGhlIGRlc2lnbiBhcm91bmQgbm9kZSBwcm90ZWN0aW9uICh3aGljaA0KYWx3YXlzIGFkZHMgc2ln bmlmaWNhbnQgY29tcGxleGl0eSB0byBGUlIpIGlzIGluIGNvbnRyYXN0IHRvDQp0aGUgSVBGUlIg c2l0dWF0aW9uIHdoZXJlIGxpbmsgcHJvdGVjdGlvbiBpcyBvZiBvdmVyd2hlbG1pbmcNCmltcG9y dGFuY2UgYW5kIG5vZGUgcHJvdGVjdGlvbiBzZWVtcyB0byBiZSBvZiBzZWNvbmRhcnkNCmltcG9y dGFuY2UuDQoNCkFuIGFsdGVybmF0aXZlIGRlc2lnbiwgd2hpY2ggd291bGQgcmVxdWlyZSBsZXNz IGNoYW5nZSB0byB0aGUNCmV4aXN0aW5nIFBXRTMgZGVzaWduIHdvdWxkIGJlIHRvIHByb3ZpZGUg cmVkdW5kYW50IGNvbm5lY3Rpb24NCnRvIHRoZSB4UEVzIGFuZCBhbGxvdyBGUlIgbGluayBwcm90 ZWN0aW9uIGluIHRoZSBQU04gdG8NCmRlYWwgd2l0aCBsaW5rIGZhaWx1cmVzIGFuZCB0aGVuIHRv IHByb3RlY3QgdGhlIGVncmVzcyBBQyBieQ0KbWFraW5nIHRoZSBULVBFIGEgc3BlY2lhbCB0eXBl IG9mIFMtUEUgdGhhdCBwcmVmZXJyZWQgdG8NCmFjdCBhcyBhIFQtUEUgYnV0IGlmIHRoZSBBQyB3 YXMgZG93biBmb3J3YXJkZWQgdG8gYW4gYWx0ZXJuYXRlDQpULVBFIGZvciB0aGF0IFBXLg0KDQpJ ZiB0aGUgV0cgcHJlZmVycyB0byBpbnRyb2R1Y2UgdGhlIGNyb3NzIGxheWVyIHNjaGVtZSB5b3Ug aGF2ZQ0KcHJvcG9zZWQsIHRoZW4gZmluZSwgd2UgbmVlZCB0byBkbyB0aGUgZnVsbCBzZXQgb2Yg dXBkYXRlcyBuZWVkZWQuDQpIb3dldmVyIGZpcnN0IEkgdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIGhh dmUgcm91Z2ggY29uc2Vuc3VzIHRoYXQNCnRoZSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBq dXN0aWZ5IHRoZSBpbmNyZWFzZWQgY29tcGxleGl0eQ0KY29tcGFyZWQgb2Ygbm9kZSBwcm90ZWN0 aW9uIGNvbXBhcmVkIHRvIHRoZSBhbHRlcm5hdGl2ZSBvZg0KcHJvdmlkaW5nIGxpbmsgYW5kIEFD IHByb3RlY3Rpb24uDQo+DQo+IFsxXSBUaGlzIGRyYWZ0IGlzIGNvbXBsZXRlbHkgYmFzZWQgb24g dGhlIFBXRTMgYW5kIHRoZSBNUy1QVyBhcmNoaXRlY3R1cmUuIEl0IGlzIGFsc28gYmFzZWQgb24g UkZDIDUzMzEgIiBNUExTIFVwc3RyZWFtIExhYmVsIEFzc2lnbm1lbnQgYW5kIENvbnRleHQtU3Bl Y2lmaWMgTGFiZWwgU3BhY2UiLiBTbyBpZGVhbGx5IHJlYWRlcnMgc2hvdWxkIGJlIGZhbWlsaWFy IHdpdGggdGhhdCBSRkMuDQpBcyBmYXIgYXMgSSBjYW4gc2VlIGNvbnRleHQgbGFiZWxzIGhhdmUg bm90IGJlZW4gaW50cm9kdWNlZA0KaW50byB0aGUgUFdFMyBhcmNoaXRlY3R1cmUuIFRoZXJlIGlz IHNvbWUgcmVmZXJlbmNlIHRvIHRoZWlyIHVzZSBmb3INClAyTVAgUFdzLCBidXQgbm90IGluIHRo ZSBQMlAgY2FzZS4gSW5kZWVkIEkgdGhpbmsgdGhhdCBSRkM0NDQ3DQpub3RlcyBleHBsaWNpdGx5 IHRoYXQgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIGNvbmZpZ3VyYXRpb24gb2YgUFdzDQppcyBzaWdu YWxlZCBieSBMRFAgdGhlIHBsYXRmb3JtIGxhYmVsIHNwYWNlIG11c3QgYmUgdXNlZC4gVGhlDQps ZWFzdCB0aGF0IHlvdSBuZWVkIHRvIGRvIGlzIHRvIHVwZGF0ZSBSRkM0NDQ3Lg0KDQpTb21ldGhp bmcgdGhhdCBJIG5vdGljZWQgaW4gYSBzZWNvbmQgcGFzcyB0aHJvdWdoIHRoZSB0ZXh0IGlzIHRo YXQNCnlvdSBzZWVtIHRvIGhhdmUgY2hhbmdlZCB0aGUgUFcgRkVDIGRhdGEgc3RydWN0dXJlIGZy b20gdGhlDQpvbmUgc3BlY2lmaWVkIGJ5IFBXRTMgdG8gYSB2YXJpYW50IG9mIG9uZSB1c2VkIGlu IExTUCBQaW5nLiBUaGlzDQpzZWVtcyB1bm5lY2Vzc2FyeSBhbmQgbWF5IGxlYWQgdG8gY29uZnVz aW9uIGFuZCBkaWZmaWN1bHR5IGlmDQp0aGVzZSBnZXQgY2hhbmdlZCBhdCBzb21lIHRpbWUgaW4g dGhlIGZ1dHVyZS4gQSBiZXR0ZXIgZGVzaWduDQppcyBzdXJlbHkgdG8gbGVhdmUgdGhlIFBXRTMg c2lnbmFsbGluZyBzeXN0ZW0gY29tcGxldGVseSB1bmNoYW5nZWQNCmV4Y2VwdCB0byBhZGQgYW4g YWRkaXRpb25hbCBUTFYgc3BlY2lmeWluZyB0aGUgY29udGV4dCBpbmZvcm1hdGlvbg0KaWYgaW5k ZWVkIHdlIGNvbnRpbnVlIG9uIHRoYXQgcGF0aC4gQXByb3BvcyB0aGlzLCBpdCBtYXkgYmUgdGhl DQp3YXkgdGhhdCB0aGUgZG9jdW1lbnQgd2FzIHdyaXR0ZW4sIGJ1dCBJIGRpZCBub3Qgc2VlIGFu eXRoaW5nIGFib3V0DQp0aGUgbmVlZCB0byBzaWduYWwgdGhlIFBXIGludGVyZmFjZSBwYXJhbWV0 ZXJzIHRvIHRoZSBhbHRlcm5hdGl2ZQ0KUEUuIEFsc28gSSBkaWQgbm90IHNlZSBhbnl0aGluZyBz cGVjaWZ5aW5nIHRoZSBlcnJvciBoYW5kbGluZw0KYXMgYSByZXN1bHQgb2YgcGFyYW1ldGVyIGlz c3Vlcy4NCg0KQSBjb21tZW50IGJlbG93IHRoYXQgd2FzIG5vdCBwaWNrZWQgdXAgaXMgdGhhdCB0 aGUgc2lnbmFsbGluZw0KZGVzaWduIHN1cHBvcnRzIElQdjQgb25seSwgYW5kIGFzIEkgcmVjYWxs IHRoZXJlIGlzIGFuIElFU0cgcG9saWN5DQpvZiBub3Qgc3RhbmRhcmRpemluZyBhbnkgSVB2NCBv bmx5IHNvbHV0aW9ucywgc28gcGVyaGFwcyB3ZSBzaG91bGQNCmludHJvZHVjZSBJUHY2IGF0IHRo ZSBzYW1lIHRpbWUgYXMgaGFybW9uaXppbmcgdGhlIG5vcm1hbCBhbmQNCmNvbnRleHQgbGFiZWwg ZGF0YSBzdHJ1Y3R1cmVzLg0KDQpUaGUgTERQIHNpZ25hbGxpbmcgb2YgUFdzIHdpdGggY29udGV4 dCBsYWJlbHMgbmVlZCBhIG1vcmUNCmNvbXBsZXRlIHJldmlldyBmb3IgYm90aCBjb21wbGV0ZW5l c3MgYW5kIGNvcnJlY3RuZXNzIGFuZA0KdG8gZW5zdXJlIHRoYXQgdGhpcyB0ZXh0IHByb3ZpZGVz IGEgZGVzY3JpcHRpb24gdGhhdCBpcyBzdWZmaWNpZW50bHkNCmNvbXBsZXRlIHRoYXQgdGhpcyBu ZXcgZmVhdHVyZSBjYW4gYmUgaW1wbGVtZW50ZWQgc29sZWx5IGZyb20NCnRoaXMgdGV4dCBhbmQg dGhlIGFzc29jaWF0ZWQgcmVmZXJlbmNlcy4NCj4NCj4gWzJdIFRoZSBkcmFmdCBtZW50aW9ucyB0 d28gaW1wb3J0YW50IHJvbGVzIG9mIHJvdXRlcnMsIFBMUiAocG9pbnQgb2YgbG9jYWwgcmVwYWly KSBhbmQgcHJvdGVjdG9yLg0KWW91IG5lZWQgYSBjbGVhcmVyIGRlZmluaXRpb24gb2YgYSBQTFIg YW5kIHByb3RlY3Rvci4gSSB0aGluayB0aGF0DQphIHByb3RlY3RvciBpcyBhIG5ldyB0eXBlIG9m IFNQRSBhbmQgbmVlZHMgYSBjbGVhcmVyIGFyY2hpdGVjdHVyYWwNCmRlZmluaXRpb24uDQoNClRo ZSBjb25jZXB0IG9mIGEgUExSIHRha2luZyBhY3Rpb24gYXQgb25lIGxheWVyIHdpdGhpbiB0aGUg Y29udGV4dA0Kb2YgYW5vdGhlciBpcyBuZXcgaW4gUFdFMy4gUGVyaGFwcyBpdCBpcyBkZWZpbmVk IGluIE1QTFMgaW4gd2hpY2gNCmNhc2UgYSByZWZlcmVuY2Ugd291bGQgYmUgYXBwcm9wcmlhdGUu DQo+DQo+IFszXSBQTFIgcGVyZm9ybXMgbG9jYWwgcmVwYWlyIGluIGRhdGFwbGFuZSwgYmFzZWQg b24gcHJlLWluc3RhbGxlZCBiYWNrdXAgZm9yd2FyZGluZyBzdGF0ZSBwb2ludGluZyB0byBhIGJ5 cGFzcyB0dW5uZWwuIFRoZXJlIGlzIG5vIGNvbnRyb2wtcGxhbmUgaW52b2x2ZW1lbnQgaW4gbG9j YWwgcmVwYWlyLg0KU3BlY2lmaWNhbGx5IGluIHRoZSBpbml0aWF0aW9uIG9mIHRoZSBsb2NhbCBy ZXBhaXIsIGl0IGlzIGluIHRoZSANCmNvbmZpZ3VyYXRpb24NCm9mIGNvdXJzZS4NCj4gVGhpcyBp cyBzaW1pbGFyIHRvIHRoZSBleGlzdGluZyBJUC9NUExTIGZhc3QtcmVyb3V0ZSBtZWNoYW5pc21z LiBUaGVyZWZvcmUsIGl0IGNhbiBhY2hpZXZlIHJlc3RvcmUgdHJhZmZpYyB3aXRoIGEgc2ltaWxh ciBwZXJmb3JtYW5jZSB0byB0aG9zZSBtZWNoYW5pc21zLiBUaGF0IGlzIHRoZSBtYWluIGdvYWwg b2YgdGhpcyBkcmFmdC4NCklQL01QTFMgRlJSIG5vcm1hbGx5IG9wZXJhdGVzIHNvbGVseSBmb3Ig dGhlIGJlbmVmaXQgb2YgaXRzIG93bg0KZGF0YXBsYW5lLiBZb3UgaGF2ZSB0aGlzIGNvbmZpZ3Vy ZWQgdG8gYWN0IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUNCmNsaWVudCBkYXRhcGxhbmUuDQo+DQo+ IFs0XSBXaGVuIGRvaW5nIGxvY2FsIHJlcGFpciwgdGhlIFBMUiBvbmx5IHN3YXBzIHRoZSB0b3Ag bGFiZWwgKGkuZS4gdHVubmVsIGxhYmVsKSB0byBhIGJ5cGFzcyB0dW5uZWwncyBsYWJlbCwgYW5k IGtlZXBzIHRoZSBQVyBsYWJlbCAoYWxsb2NhdGVkIGJ5IHByaW1hcnkvcHJvdGVjdGVkIFBFKSBp bnRhY3QuIFRoZSBQTFIgZG9lc24ndCBuZWVkIHRvIGtub3cgb3IgdW5kZXJzdGFuZCB0aGUgUFcg bGFiZWwuDQpJbmRlZWQgdGhpcyBpcyBjbGVhcmVyIG5vdywgYW5kIG5lZWRzIHRvIGJlIG1hZGUg bXVjaCBjbGVhcmVyIGluDQp0aGUgdGV4dC4NCg0KSG93ZXZlciBzbyBkbyB0aGUgaW1wbGljYXRp b25zIGZvciB0aGUgc3lzdGVtIGFzIGEgd2hvbGUgb2YgdGhpcw0KbW9kZSBvZiBvcGVyYXRpb24u DQo+DQo+IFs1XSBUaGUgcHJvdGVjdG9yIGlzIHRoZSByb3V0ZXIgYXQgdGhlIG90aGVyIGVuZCBv ZiB0aGUgYnlwYXNzIHR1bm5lbC4gSXQgaXMgcmVzcG9uc2libGUgZm9yIGZvcndhcmRpbmcgdGhl IHRyYWZmaWMgZnVydGhlciwgc28gdGhhdCB0aGUgdHJhZmZpYyBjYW4gZXZlbnR1YWxseSByZWFj aCB0aGUgdGFyZ2V0IENFLiBUaGUgcHJvdGVjdG9yIG11c3QgdW5kZXJzdGFuZCB0aGUgUFcgbGFi ZWwgYWxsb2NhdGVkIGJ5IHRoZSBwcmltYXJ5IFBFLg0KVGhlIHVzZSBvZiB0aGUgd29yayBwcmlt YXJ5IFBFIGlzIHNsaWdodGx5IGNvbmZ1c2luZy4gUHJlc3VtYWJseQ0KeW91IG1lYW4gdGhlIGlu Z3Jlc3MgUEUgb2YgdGhlIHNlZ21lbnQgcmF0aGVyIHRoYW4gdGhlIGluZ3Jlc3MNClBFIGZyb20g dGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIGluZ3Jlc3MgQUMuDQo+IFRoaXMgaXMgYWNoaWV2ZWQg YnkgdXNpbmcgdGhlIGNvbnRleHQgbGFiZWwgZm9yd2FyZGluZyBwYXJhZGlnbSBzcGVjaWZpZWQg aW4gUkZDIDUzMzEuIFRoaXMgZHJhZnQgZGVmaW5lcyBzb21lIExEUCBleHRlbnNpb25zIHRvIGFs bG93IHRoZSBwcmltYXJ5IFBFIHRvIGFkdmVydGlzZSBQVyBsYWJlbHMgdG8gdGhlIHByb3RlY3Rv ci4gVGhlIHByb3RlY3RvciBsb2NhbGx5IG1haW50YWlucyBhIGxhYmVsIHNwYWNlIGZvciB0aGVz ZSBQVyBsYWJlbHMgb2YgdGhlIHByb3RlY3RlZCBQRSwgYW5kIGxvb2tzIHVwIHRoZSBQVyBsYWJl bCBpbiB0aGlzIGxhYmVsIHNwYWNlLiBUaGUgYnlwYXNzIHR1bm5lbCBzZXJ2ZXMgYXMgdGhlIHBv aW50ZXIgdG8gdGhpcyBsYWJlbCBzcGFjZS4NCk5vdyBJIHVuZGVyc3RhbmQgdGhhdC4gUGxlYXNl IG1ha2UgdGhpcyBtdWNoIGNsZWFyZXINCmVhcmxpZXIgaW4gdGhlIHRleHQuDQoNCk5vdGUgbXkg ZWFybGllciBjb25jZXJuIGFib3V0IHRoZSBkZXNpZ24gb2YgdGhvc2UgZXh0ZW5zaW9ucy4NCj4N Cj4gWzZdIFRoaXMgZHJhZnQgYWxzbyBpbnRyb2R1Y2VzIHRoZSBjb25jZXB0IG9mICJjb250ZXh0 IElEIi4gQSBjb250ZXh0IElEIGlzIGFuIElQIGFkZHJlc3MgaWRlbnRpZnlpbmcgYSBwYWlyIG9m IDxwcmltYXJ5IFBFLCBwcm90ZWN0b3IgWD4uDQpUaGUgdXNlIG9mIGFuIElQIGFkZHJlc3MgcmF0 aGVyIHRoYW4gc29tZSBpZGVudGlmaWVyIHRha2VuIGZyb20NCnRoZSBQVyBjb250ZXh0IGlzIGEg ZGVzaWduIGFzc3VtcHRpb24gbm90IHByb3Blcmx5IHNoYXJlZCB3aXRoIHRoZQ0KcmVhZGVyIGFu ZCBuZWVkcyB0byBiZSBjbGFyaWZpZWQgaW4gdGhlIHRleHQuDQoNCj4gSXQgc2VydmVzIGFzIHRo ZSBkZXN0aW5hdGlvbiBvZiB0cmFuc3BvcnQgdHVubmVsLiBQV3MgY2FycmllZCBieSB0aGUgdHVu bmVsIHdpbGwgYmUgcmVkaXJlY3RlZCB0byB0aGUgcHJvdGVjdG9yIFggZHVyaW5nIGxvY2FsIHJl cGFpci4gUFdzIHRvIHRoZSBzYW1lIHByaW1hcnkgUEUgYnV0IHByb3RlY3RlZCBieSBhIGRpZmZl cmVudCBwcm90ZWN0b3IgWSBjYW5ub3QgYmUgY2FycmllZCBieSB0aGlzIHR1bm5lbC4gUmF0aGVy LCB0aGV5IG11c3QgYmUgY2FycmllZCBieSBhIHR1bm5lbCBkZXN0aW5lZCBmb3IgY29udGV4dCBJ RCBvZiA8cHJpbWFyeSBQRSwgcHJvdGVjdG9yIFk+Lg0KSW5kZWVkLCBidXQgdGhhdCBuZWVkcyB0 byBiZSBtYWRlIGNsZWFyZXIsIHBhcnRpY3VsYXJseSBhcyB0aGlzDQpzZWVtaW5nbHkgaGFzIHNj YWxpbmcgY29uc2VxdWVuY2VzLg0KPg0KPiBbN10gQSBQTFIgbWF5IGJlIGFueSByb3V0ZXIgaW4g dGhlIG5ldHdvcmssIGluY2x1ZGluZyBQIG9yIFBFIHJvdXRlci4gVGhlIGRyYWZ0IGFzc3VtZXMg dGhhdCBpdCBkb2Vzbid0IGtub3cgb3IgY2FyZSBhYm91dCBQVyBpbmZvLg0KPg0KPiBbOF0gQSBw cm90ZWN0b3IgaXMgYSBQRSByb3V0ZXINCldpdGhpbiBhIFBFIGNvbnRleHQgSSBhbSBub3Qgc3Vy ZSB0aGF0IHRoZSBwcm9wZXJ0aWVzIG9mIGEgUEUgcm91dGVyDQphcmUgZGVmaW5lZC4NCj4gaW4g dGhlICJjby1sb2NhdGVkIiBtb2RlbC4gSXQgbWF5IGJlIGEgUCByb3V0ZXIgaW4gdGhlICJjZW50 cmFsaXplZCIgbW9kZWwuIEZvciB0aGUgbGF0ZXIgY2FzZSwgdGhlIGRyYWZ0IGRlc2NyaWJlcyBo b3cgdG8gdXNlIHRoZSBuZXcgTERQIGV4dGVuc2lvbnMgZm9yIHRoZSBwcm90ZWN0b3IgdG8gbGVh cm4gYW5kIGFzc29pY2F0ZSBwcmltYXJ5IFBXIGFuZCBiYWNrdXAgUFcgYW5kIGluc3RhbGwgZm9y d2FyZGluZyBlbnRyaWVzIGluIHRoZSBjb250ZXh0IGxhYmVsIHRhYmxlLg0KU28gd2hlbiB5b3Ug cnVuIHRoZSBjZW50cmFsaXplZCBwcm90ZWN0b3IsIGhvdyBkb2VzIHRoZQ0KUFcgcGFyYW1ldGVy IHNpZ25hbGluZyBhbmQgaW50ZXJmYWNlIHBhcmFtZXRlciB2ZXJpZmljYXRpb24NCndvcms/IFN1 cmVseSB0aGUgY2VudHJhbGl6ZWQgcHJvdGVjdG9yIG5lZWRzIHRvIGJlIHNvbWUNCmZvcm0gb2Yg UEUgcmF0aGVyIHRoYW4gYSB2YXJpYW50IG9mIGFuIE1QTFMgUCByb3V0ZXI/DQoNCkkgaGF2ZSBh IGJ1bmNoIG9mIGNvbW1lbnRzIG9uIHlvdXIgYW5zd2VyIGJlbG93LCBwdXQgcGVyaGFwcyB3ZQ0K Y2FuIHN0YXJ0IGJ5IHdvcmtpbmcgdGhyb3VnaCB0aGUgY29tbWVudHMgYWJvdmUgYW5kIHRoZSBj eWNsZQ0KYmFjayB0byB0aGUgY29tbWVudHMgYmVsb3cgd2l0aGluIHRoZSByZXN1bHRhbnQgY29u dGV4dC4NCg0KSSB3aWxsIGNvbW1lbnQgb24gb3VyIGV4Y2hhbmdlIGJlbG93IHdoZW4gd2UgaGF2 ZSByZWFjaGVkDQpzb21lIGxldmVsIG9mIGNvbnNlbnN1cyBvbiB0aGUgcHJlYW1ibGUuDQoNCkdp dmVuIHRoZSBjb25jZXJucyB0aGF0IEkgaGF2ZSByYWlzZWQgYW5kIHRob3NlIHJhaXNlZCBieSBT YXNoYQ0KSSB0aGluayB0aGF0IHRoZSBjaGFpcnMgbmVlZCBjb25zaWRlciB0YWtpbmcgdGhpcyBi YWNrIHRvIHRoZSBXRw0KZm9yIGZ1cnRoZXIgd29yay4NCg0KLSBTdGV3YXJ0DQo+DQo+IFRoYW5r cywNCj4NCj4gL1lpbWluDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHB3ZTMgW21haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV3 YXJ0IEJyeWFudA0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDEwOjUzIEFNDQo+IFRv OiBwd2UzOyBwd2UzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiBDYzogbXBsc0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW1BXRTNdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1wd2UzLWVu ZHBvaW50LWZhc3QtcHJvdGVjdGlvbi0wMQ0KPg0KPg0KPg0KPiBJIGRvIG5vdCBzdXBwb3J0IHRo ZSBwdWJsaWNhdGlvbiBvZiB0aGlzIGRyYWZ0IHdpdGhvdXQ6DQo+DQo+IDEpIEFuIGFzc3VyYW5j ZSB0aGF0IE1QTFMgV0cgaGFzIHJldmlld2VkIGl0IGFuZCBpcyBoYXBweQ0KPiB3aXRoIHRoZSBl eHRlbnNpb25zIHRoYXQgc2VlbSB0byBiZSBtYWRlIHRvIHRoZSBNUExTIGFyY2hpdGVjdHVyZQ0K Pg0KPiAyKSBBIGZvcm1hbCBkZXNjcmlwdGlvbiBvZiB0aG9zZSBleHRlbnNpb25zIG9yIGEgcG9p bnRlcg0KPiB0byB0aG9zZSBleHRlbnNpb25zIGluIGFub3RoZXIgUkZDLg0KPg0KPiAzKSBTaWdu aWZpY2FudCBjbGFyaWZpY2F0aW9uIG9mIGhvdyB0aGUgZGV0YWlsIG9mIHRoaXMNCj4gbWVjaGFu aXNtIHdvcmtzLg0KPg0KPiBGb3IgdGhpcyB0byB3b3JrIHlvdSBuZWVkIHRvIGhhdmUgY28tb3Jk aW5hdGVkIGxhYmVsIHNwYWNlcw0KPiBpbiBtdWx0aXBsZSBQRXMgd2hpY2ggaXMgc29tZXRoaW5n IHRoYXQgd2FzIGludmVzdGlnYXRlZA0KPiBieSB0aGUgU1BSSU5HIFdHIGFuZCBmb3VuZCBub3Qg dG8gd29yaywgcGFydGljdWxhcmx5IHdoZW4NCj4gZGlmZmVyZW50IG1hbnVmYWN0dXJlcnMgZXF1 aXBtZW50cyB3ZXJlIGludm9sdmVkLg0KPg0KPiBbeXNoZW5dIFRoaXMgZHJhZnQgZG9lcyBub3Qg cmVseSBvbiBsYWJlbCBzcGFjZSBjb29yZGluYXRpb24uIFJhdGhlciwgaXQgaXMgYmFzZWQgb24g Y29udGV4dCBsYWJlbCBmb3J3YXJkaW5nIHBhcmFkaWdtIHNwZWNpZmllZCBpbiBSRkMgNTMzMS4N Cj4NCj4NCj4gQXMgZmFyIGFzIEkgY2FuIHNlZSB5b3UgYWxzbyBuZWVkIHRvIHBlZWsgYmVsb3cg dGhlIHRvcA0KPiBvZiBzdGFjayB0byBkbyBhIGZhc3QgcmVyb3V0ZSBvcGVyYXRpb24gd2hpY2gg aXMgbm90DQo+IGEgY3VycmVudGx5IGRlZmluZWQgTVBMUyBvcGVyYXRpb24uDQo+DQo+IFRoZXJl IHNlZW0gdG8gYmUgYSBsb3Qgb2YgZGV0YWlscyBhbmQgY2xhcmlmaWNhdGlvbnMgbWlzc2luZw0K PiB0aGF0IG5lZWQgdG8gYmUgcHJvdmlkZWQsIGFuZCBJIGFtIG5vdCBlbnRpcmVseSBjb252aW5j ZWQNCj4gdGhhdCBhbGwgb2YgdGhlIGl0ZW1zIGRlY2xhcmVkIG91dCBvZiBzY29wZSBhcmUgbGVn aXRpbWF0ZWx5DQo+IG91dCBvZiBzY29wZSBhbmQgbm90IG5lZWRlZCBpbiBvcmRlciBmb3IgYSBt dWx0aS12ZW5kb3INCj4gc29sdXRpb24gdG8gYmUgaW1wbGVtZW50ZWQuDQo+DQo+IEl0IHdvdWxk IGJlIHVzZWZ1bCB0byBtZSAoYW5kIEkgc3VzcGVjdCB0byBvdGhlciByZWFkZXJzKQ0KPiB0byBz ZWUgd2hhdCB0aGUgZGF0YXBsYW5lIGxvb2tzIGxpa2UgYXQgdmFyaW91cyBwb2ludHMNCj4gaW4g dGhlIG5vcm1hbCBhbmQgcmVwYWlyIHBhdGggdG8gdmVyaWZ5IHRoYXQgYWxsIHBhcnRpZXMNCj4g aGF2ZSB0aGUgcmlnaHQgaW5mb3JtYXRpb24gZm9yIHRoaXMgdG8gd29yayB1bmRlciBub3JtYWwN Cj4gYW5kIHZhcmlvdXMgZmF1bHQgY29uZGl0aW9ucy4NCj4NCj4gSSBoYXZlIGEgbnVtYmVyIG9m IGNvbW1lbnRzIGlubGluZSB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkDQo+IGJlZm9yZSB0aGlz IGNhbiBwcm9jZWVkLg0KPg0KPg0KPiAtIFN0ZXdhcnQNCj4NCj4NCj4gICAgICAgICAgICAgICAg ICAgICBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJvdGVjdGlvbg0KPiAgICAgICAgICAgICAg ICAgZHJhZnQtaWV0Zi1wd2UzLWVuZHBvaW50LWZhc3QtcHJvdGVjdGlvbi0wMQ0KPg0KPiBBYnN0 cmFjdA0KPg0KPiAgICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgZmFzdCBtZWNoYW5pc20g Zm9yIHByb3RlY3RpbmcgcHNldWRvd2lyZXMNCj4gICAgICBhZ2FpbnN0IGVncmVzcyBlbmRwb2lu dCBmYWlsdXJlcywgaW5jbHVkaW5nIGVncmVzcyBhdHRhY2htZW50IGNpcmN1aXQNCj4gICAgICBm YWlsdXJlLCBlZ3Jlc3MgUEUgZmFpbHVyZSwgbXVsdGktc2VnbWVudCBQVyB0ZXJtaW5hdGluZyBQ RSBmYWlsdXJlLA0KPiAgICAgIGFuZCBtdWx0aS1zZWdtZW50IFBXIHN3aXRjaGluZyBQRSBmYWls dXJlLiAgRGVzaWduZWQgb24gdGhlIGJhc2lzIG9mDQo+ICAgICAgbXVsdGktaG9tZWQgQ0UsIFBX IHJlZHVuZGFuY3ksIHVwc3RyZWFtIGxhYmVsIGFzc2lnbm1lbnQgYW5kIGNvbnRleHQNCj4gICAg ICBzcGVjaWZpYyBsYWJlbCBzd2l0Y2hpbmcsIHRoZSBtZWNoYW5pc20gZW5hYmxlcyBsb2NhbCBy ZXBhaXIgdG8gYmUNCj4gICAgICBwZXJmb3JtZWQgYnkgdGhlIHJvdXRlciB1cHN0cmVhbSBhZGph Y2VudCB0byBhIGZhaWx1cmUuDQo+DQo+ICAgICAgSW4NCj4gICAgICBwYXJ0aWN1bGFyLCB0aGUg cm91dGVyIGNhbiByZXN0b3JlIFBXIHRyYWZmaWMgaW4gdGhlIG9yZGVyIG9mIHRlbnMgb2YNCj4g ICAgICBtaWxsaXNlY29uZHMsDQo+DQo+IFNCPiBOb3Qgc3VyZSBpdCdzIHdpc2UgdG8gc3BlY2lm eSBhIHBlcmZvcm1hbmNlIGNsYWltIGluIGEgc3RhbmRhcmRzDQo+IFNCPiB0cmFjayBSRkMuDQo+ DQo+IFt5c2hlbl0gSWYgdGhpcyBpcyB2aWV3ZWQgYXMgaW5hcHByb3ByaWF0ZSwgd2UgY2FuIHJl bW92ZSBpdC4NCj4NCj4gICAgICBieSB0cmFuc21pdHRpbmcgdGhlIHRyYWZmaWMgdG8gYSBwcm90 ZWN0b3IgdGhyb3VnaCBhDQo+ICAgICAgcHJlLWVzdGFibGlzaGVkIGJ5cGFzcyB0dW5uZWwuICBU aGVyZWZvcmUsIHRoZSBtZWNoYW5pc20gY2FuIHJlZHVjZQ0KPiAgICAgIHRyYWZmaWMgbG9zcyBi ZWZvcmUgZ2xvYmFsIHJlcGFpciByZWFjdHMgdG8gdGhlIGZhaWx1cmUgYW5kIHRoZQ0KPiAgICAg IG5ldHdvcmsgY29udmVyZ2VzIG9uIHRoZSB0b3BvbG9neSBjaGFuZ2VzIGR1ZSB0byB0aGUgZmFp bHVyZS4NCj4NCj4NCj4NCj4gPT09DQo+DQo+DQo+IDEuICBJbnRyb2R1Y3Rpb24NCj4NCj4gICAg ICBQZXIgUkZDIDM5ODUsIFJGQyA0NDQ3IGFuZCBSRkMgNTY1OSwgYSBwc2V1ZG93aXJlIChQVykg b3IgUFcgc2VnbWVudA0KPiAgICAgIGNhbiBiZSB0aG91Z2h0IG9mIGFzIGEgY29ubmVjdGlvbiBi ZXR3ZWVuIGEgcGFpciBvZiBmb3J3YXJkZXJzIGhvc3RlZA0KPiAgICAgIGJ5IHR3byBQRXMsIGNh cnJ5aW5nIGFuIGVtdWxhdGVkIGxheWVyLTIgc2VydmljZSBvdmVyIGEgcGFja2V0DQo+ICAgICAg c3dpdGNoZWQgbmV0d29yayAoUFNOKS4gIEluIHRoZSBzaW5nbGUtc2VnbWVudCBQVyAoU1MtUFcp IGNhc2UsIGENCj4gICAgICBmb3J3YXJkZXIgYmluZHMgYSBQVyB0byBhbiBhdHRhY2htZW50IGNp cmN1aXQgKEFDKS4gIEluIHRoZSBtdWx0aS0NCj4gICAgICBzZWdtZW50IFBXIChNUy1QVykgY2Fz ZSwgYSBmb3J3YXJkZXIgb24gYSB0ZXJtaW5hdGluZyBQRSAoVC1QRSkgYmluZHMNCj4gICAgICBh IFBXIHNlZ21lbnQgdG8gYW4gQUMsIHdoaWxlIGEgZm9yd2FyZGVyIG9uIGEgc3dpdGNoaW5nIFBF IChTLVBFKQ0KPiAgICAgIGJpbmRzIG9uZSBQVyBzZWdtZW50IHRvIGFub3RoZXIgUFcgc2VnbWVu dC4gIEluIGVhY2ggZGlyZWN0aW9uDQo+ICAgICAgYmV0d2VlbiB0aGUgUEVzLCBQVyBwYWNrZXRz IGFyZSB0cmFuc3BvcnRlZCBieSBhIFBTTiB0dW5uZWwsIHdoaWNoIGlzDQo+ICAgICAgY2FsbGVk IGEgdHJhbnNwb3J0IHR1bm5lbC4NCj4NCj4gU0I+IERpZCB3ZSBldmVyIHlvdXIgdGhlIHRlcm0g dHJhbnNwb3J0IHR1bm5lbCBiZWZvcmU/DQo+DQo+IFt5c2hlbl0gVGhpcyBpcyBtYWlubHkgZm9y IGNsYXJpdHkuIFdlIGNvdWxkIGNoYW5nZSBpdCB0byAiIHdoaWNoIGlzDQo+ICAgICAgY2FsbGVk IGEgdHJhbnNwb3J0IHR1bm5lbCAqaW4gdGhpcyBkb2N1bWVudCoiLiBPciB3ZSBjYW4gY29tcGxl dGVseSByZXBsYWNlICJ0cmFuc3BvcnQgdHVubmVsIiB3aXRoIGp1c3QgInR1bm5lbCIuDQo+DQo+ IDMuICBSZWZlcmVuY2UgTW9kZWxzIGFuZCBGYWlsdXJlIENhc2VzDQo+DQo+ICAgICAgVGhlIG1l Y2hhbmlzbSBpbiB0aGlzIGRvY3VtZW50IGludGVuZHMgdG8NCj4gICAgICB1c2UgdGhlc2UgdG9w b2xvZ2llcyBmb3IgbG9jYWwgcmVwYWlyIHB1cnBvc2VzLg0KPg0KPiBTQj4gVGhlIHRvcGxvbG9n eSBpcyBub3QgYSBtZWNoYW5pc20uIEFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIG1lY2hhbmltcw0K PiBTQj4gb25seSB3b3JrcyBpbiB0aGlzIHRvcG9sb2d5Pw0KPg0KPiBbeXNoZW5dIE5vLCB0aGVz ZSB0b3BvbG9naWVzIGFyZSBvbmx5IGV4YW1wbGVzIGZvciB1c2UgYnkgc3Vic2VxdWVudCBzZWN0 aW9ucyB0byBkZXNjcmliZSB0aGUgbWVjaGFuaXNtcy4gVGhlIG1lY2hhbmlzbXMgc2hvdWxkIGVx dWFsbHkgd29yayBmb3Igb3RoZXIgdG9wb2xvZ2llcyBhcyB3ZWxsLg0KPg0KPiAgICAgIFRoaXMg U0hBTEwgZW5hYmxlDQo+ICAgICAgbG9jYWwgcmVwYWlyIGFuZCBnbG9iYWwgcmVwYWlyIHRvIHdv cmsgaW4gdGFuZGVtIHRvIGFjaGlldmUgYnJvYWRlcg0KPiAgICAgIGNvdmVyYWdlIG9mIHByb3Rl Y3Rpb24gZm9yIHNlcnZpY2VzLg0KPg0KPiBTQj4gSSBoYXZlIG5vIGlkZWEgaG93IGEgU0hBTEwg aW4gY2FwaXRhbHMgYXBwbGllcyBoZXJlLg0KPg0KPiBbeXNoZW5dIFdpbGwgZml4IHRoaXMuDQo+ DQo+IDMuMS4gIFNpbmdsZS1TZWdtZW50IFBXDQo+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAg ICAgfDwtLS0tLS0tLS0tLS0tLSBQVzEgLS0tLS0tLS0tLS0tLS0tPnwNCj4NCj4gICAgICAgICAg ICAgICAgIC0gUEUxIC0tLS0tLS0tLS0tLS0tIFAxIC0tLS0tLS0tLS0tLS0tLS0gUEUyIC0NCj4g ICAgICAgICAgICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBcDQo+ICAgICAgICAgICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFwNCj4gICAgICAgICAgICBDRTEgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENFMg0KPiAgICAgICAgICAgICAgIFwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQo+ICAgICAgICAgICAg ICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KPiAg ICAgICAgICAgICAgICAgLSBQRTMgLS0tLS0tLS0tLS0tLS0gUDIgLS0tLS0tLS0tLS0tLS0tLSBQ RTQgLQ0KPg0KPiAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0gUFcyIC0tLS0t LS0tLS0tLS0tLT58DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmln dXJlIDENCj4NCj4NCj4gICAgICBFYWNoIENFIGlzIG11bHRpLWhvbWVkIHRvIHR3byBQRXMuICBI ZW5jZSwgdGhlcmUgYXJlIHR3byBkaXZlcmdlbnQNCj4gICAgICBwYXRocyBiZXR3ZWVuIHRoZSBD RXMuDQo+DQo+IFNCPiBJdCBkb2VzIG5vdCBmb2xsb3cgdGhhdCB0aGUgcGF0aHMgYXJlIGRpdmVy Z2VudCEgV2hvIGtub3dzDQo+IFNCPiB3aGF0IGhhcHBlbnMgaW4gdGhlIElQIGxheWVyIGFuZCB0 aGUgdW5kZXJseWluZyB0cmFuc3BvcnQNCj4gU0I+IG5ldHdvcmsuDQo+DQo+DQo+IFt5c2hlbl0g V2UgY291bGQgcmVwaHJhc2UgdGhpcyBhbmQgcmVtb3ZlICJkaXZlcmdlbnQiLiBBbGwgd2Ugd2Fu dCB0byBzYXkgaGVyZSBpcyB0aGF0IHRoZXJlIGFyZSB0d28gZGlzdGluY3Qgc2V0cyBvZiBBQy1Q Vy1BQyBiZXR3ZWVuIHRoZSBDRXMuDQo+DQo+ICAgICAgQXQgYW55IGdpdmVuIHRpbWUsIGVhY2gg Q0Ugc2VuZHMgdHJhZmZpYyB2aWEgb25seSBvbmUgQUMgYW5kIHJlY2VpdmVzDQo+ICAgICAgdHJh ZmZpYyB2aWEgb25seSBvbmUgQUMuICBUaGUgdHdvIEFDcyBNQVkgb3IgTUFZIE5PVCBiZSB0aGUg c2FtZS4NCj4NCj4gU0I+IE1heSBub3QgYmUgdGhlIHNhbWUgd2hhdD8gSWYgdGhleSBhcmUgYWN0 dWFsbHkgdGhlIHNhbWUgQUMgeW91DQo+IFNCPiBoYXZlIG5vIHJlZHVuZGFuY3kuDQo+DQo+IFt5 c2hlbl0gV2lsbCByZXBocmFzZSBpdC4gQWxsIHdlIHdhbnQgdG8gc2F5IGlzIHRoYXQgYXQgYSBn aXZlbiB0aW1lLCB0aGUgQ0UgbWF5IHNlbmQgdHJhZmZpYyBvdmVyIG9uZSBBQyBhbmQgcmVjZWl2 ZSB0cmFmZmljIG92ZXIgYW5vdGhlciBBQy4NCj4NCj4gICAgICBUaGUgQUMgdXNlZCB0byBzZW5k IHRyYWZmaWMgaXMgZGV0ZXJtaW5lZCBieSB0aGUgQ0UsIGFuZCBNQVkgcmVseSBvbg0KPiAgICAg IGFuIGVuZC10by1lbmQgT0FNIG1lY2hhbmlzbSBiZXR3ZWVuIHRoZSBDRXMuICBUaGUgQUMgdXNl ZCBmb3IgdGhlIENFDQo+ICAgICAgdG8gcmVjZWl2ZSB0cmFmZmljIGlzIGRldGVybWluZWQgYnkg dGhlIHN0YXRlIG9mIHRoZSBuZXR3b3JrIGFuZCB0aGUNCj4gICAgICBwcm90ZWN0aW9uIG1lY2hh bmlzbSBpbiB1c2UsIGFzIGRlc2NyaWJlZCBsYXRlciBpbiB0aGlzIGRvY3VtZW50Lg0KPg0KPiAg ICAgIEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRyYWZmaWMgZmxvd2luZyB0b3dhcmRzIGEgZ2l2 ZW4gQ0UsIHRoZSBzZXQNCj4gICAgICBvZiBQV3MsIFBFcyBhbmQgQUNzIGludm9sdmVkIGNhbiBi ZSB2aWV3ZWQgdG8gc2VydmUgcHJpbWFyeSBhbmQNCj4gICAgICBiYWNrdXAgKG9yIGFjdGl2ZSBh bmQgc3RhbmRieSkgcm9sZXMuICBXaGVuIHRoZSBuZXR3b3JrIGlzIGluIGENCj4gICAgICBzdGVh ZHkgc3RhdGUsIHRoZSBQVyB0aGF0IGlzIGludGVuZGVkIHRvIGNhcnJ5IHRoZSB0cmFmZmljIGlz DQo+ICAgICAgcmVmZXJyZWQgdG8gYXMgYSBwcmltYXJ5IFBXLiAgVGhlIFBFIGF0IHRoZSBlZ3Jl c3Mgb2YgdGhlIHByaW1hcnkgUFcNCj4gICAgICBpcyBhIHByaW1hcnkgUEUuICBUaGUgQUMgY29u bmVjdGluZyB0aGUgQ0UgYW5kIHRoZSBwcmltYXJ5IFBFIGlzIGENCj4gICAgICBwcmltYXJ5IEFD LiAgVGhlIG90aGVyIFBXIG1heSBiZSB1c2VkIHRvIGNhcnJ5IHRoZSB0cmFmZmljIHVwb24gYQ0K PiAgICAgIG5ldHdvcmsgZmFpbHVyZSwgYW5kIGlzIHJlZmVycmVkIHRvIGFzIGEgYmFja3VwIFBX LiAgVGhlIFBFIGF0IHRoZQ0KPiAgICAgIGVncmVzcyBvZiB0aGUgYmFja3VwIFBXIGlzIGEgYmFj a3VwIFBFLiAgVGhlIEFDIGNvbm5lY3RpbmcgdGhlIENFIGFuZA0KPiAgICAgIHRoZSBiYWNrdXAg UEUgaXMgYSBiYWNrdXAgQUMuDQo+DQo+ICAgICAgSW4gdGhpcyBkb2N1bWVudCwgdGhlIGZvbGxv d2luZyBwcmltYXJ5IGFuZCBiYWNrdXAgcm9sZXMgYXJlIGFzc2lnbmVkDQo+ICAgICAgZm9yIHRo ZSB0cmFmZmljIGdvaW5nIGZyb20gQ0UxIHRvIENFMjoNCj4NCj4gICAgICAgICBQcmltYXJ5IFBX OiBQVzENCj4NCj4NCj4NCj4gWWltaW4gU2hlbiwgZXQgYWwuICAgICAgRXhwaXJlcyBKYW51YXJ5 IDI1LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDVdDQo+DQo+DQo+IEludGVybmV0LURyYWZ0 ICAgICBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJvdGVjdGlvbiAgICAgICAgIEp1bHkgMjAx NA0KPg0KPg0KPiAgICAgICAgIFByaW1hcnkgUEU6IFBFMg0KPg0KPiAgICAgICAgIFByaW1hcnkg QUM6IENFMi1QRTINCj4NCj4gICAgICAgICBCYWNrdXAgUFc6IFBXMg0KPg0KPiAgICAgICAgIEJh Y2t1cCBQRTogUEU0DQo+DQo+ICAgICAgICAgQmFja3VwIEFDOiBDRTItUEU0DQo+DQo+ICAgICAg SW4gdGhpcyBjYXNlLCBhbiBlZ3Jlc3MgQUMgZmFpbHVyZSByZWZlcnMgdG8gdGhlIGZhaWx1cmUg b2YgdGhlIEFDDQo+ICAgICAgQ0UyLVBFMi4gIEFuIGVncmVzcyBub2RlIGZhaWx1cmUgcmVmZXJz IHRvIHRoZSBmYWlsdXJlIG9mIFBFMi4NCj4NCj4gICAgICBUaGUgYmFja3VwIFBFLCBiYWNrdXAg UFcgYW5kIGJhY2t1cCBBQyBtYXkgYmUgdXNlZCB0byBjYXJyeSB0cmFmZmljDQo+ICAgICAgYWZ0 ZXIgYSBQVyBlbmRwb2ludCBmYWlsdXJlLCB3aGVuIENFMSBhbmQgQ0UyIHN3aXRjaGVzIHRyYWZm aWMgdG8gUFcyDQo+ICAgICAgaW4gbG9jYWwgcmVwYWlyIG9yIGdsb2JhbCByZXBhaXIsIGFzIGRl c2NyaWJlZCBsYXRlciBpbiB0aGlzDQo+ICAgICAgZG9jdW1lbnQuDQo+DQo+ICAgICAgICAgICAg ICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0gUFcxIC0tLS0tLS0tLS0tLS0tLT58DQo+DQo+ICAg ICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0gUDEgLS0tLS0tLS0tLS0tLS0tLSBQ RTIgLQ0KPiAgICAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBcDQo+ICAgICAgICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBcDQo+ICAgICAgICAgICAgIENFMSAtLSBQRTEgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDRTINCj4gICAgICAgICAgICAg ICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8NCj4g ICAgICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tIFAyIC0tLS0t LS0tLS0tLS0tLS0gUEU0IC0NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0t LS0tLS0gUFcyIC0tLS0tLS0tLS0tLS0tLT58DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDINCj4NCj4gICAgICBGaWd1cmUgMiBzaG93cyBhbm90aGVyIHBv c3NpYmxlIHNjZW5hcmlvLCB3aGVyZSBDRTEgaXMgc2luZ2xlLWhvbWVkDQo+ICAgICAgdG8gUEUx LCB3aGlsZSBDRTIgcmVtYWlucyBtdWx0aS1ob21lZCB0byBQRTIgYW5kIFBFNC4gIEZyb20gdGhl DQo+ICAgICAgcGVyc3BlY3RpdmUgb2YgZWdyZXNzIHByb3RlY3Rpb24gZm9yIHRoZSB0cmFmZmlj IGZyb20gQ0UxIHRvIENFMiwNCj4gICAgICB0aGlzIHRvcG9sb2d5IGlzIG5vdCBtdWNoIGRpZmZl cmVudCB0aGFuIEZpZ3VyZSAxLiAgSG93ZXZlciwgZm9yIHRoZQ0KPg0KPiBTQj4gIm5vdCBtdWNo IGRpZmZlcmVudCB0aGFuIEZpZ3VyZSAxIiBpcyBub3QgaGVscGZ1bCwgZWl0aGVyIGl0IGlzIHRo ZQ0KPiBzYW1lLCBvciB5b3UgbmVlZCB0byBleHBsYWluIHRoZSBkaWZmZXJlbmNlLg0KPg0KPiBb eXNoZW5dIFdpbGwgcmVwaHJhc2UuIFRoZSBkaWZmZXJlbmNlIGlzIGFjdHVhbGx5IGRlc2NyaWJl ZCBhZnRlciAiSG93ZXZlci4uLiIuDQo+DQo+DQo+ICAgICAgdHJhZmZpYyBpbiB0aGUgZGlyZWN0 aW9uIGZyb20gQ0UyIHRvIENFMSwgUEUxIG11c3QgYW50aWNpcGF0ZSB0cmFmZmljDQo+ICAgICAg b24gYm90aCBQVzEgYW5kIFBXMiwgYW5kIHNlbmRzIGl0IHRvIENFMSBvdmVyIHRoZSBBQyBDRTEt UEUxLg0KPg0KPiBTQj4gV2hhdCBkb2VzIGl0IG1lYW4gdG8gYW50aWNpcGF0ZSB0cmFmZmljLg0K Pg0KPiBbeXNoZW5dIFRvIGFudGljaXBhdGUgaW5jb21pbmcgdHJhZmZpYyBvdmVyIGVpdGhlciBQ VzEgb3IgUFcyLiBXaWxsIHJlcGhyYXNlLg0KPg0KPiAzLjIuICBNdWx0aS1TZWdtZW50IFBXDQo+ DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IFlpbWluIFNoZW4sIGV0IGFsLiAgICAg IEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KPg0KPg0K PiBJbnRlcm5ldC1EcmFmdCAgICAgUFcgRW5kcG9pbnQgRmFzdCBGYWlsdXJlIFByb3RlY3Rpb24g ICAgICAgICBKdWx5IDIwMTQNCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0t LS0tLS0tLSBQVzEgLS0tLS0tLS0tLS0tLS0tPnwNCj4gICAgICAgICAgICAgICAgICAgICB8PC0t LS0tIFNFRzEgLS0tLS0+fDwtLS0tLSBTRUcyIC0tLS0tPnwNCj4NCj4gICAgICAgICAgICAgICAg LSBUUEUxIC0tLS0tLS0tLS0tLS0tIFNQRTEgLS0tLS0tLS0tLS0tLS0tIFRQRTIgLQ0KPiAgICAg ICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXA0KPiAgICAgICAgICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFwNCj4gICAgICAgICAgIENFMSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ0UyDQo+ICAgICAgICAgICAgICBcICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KPiAgICAgICAg ICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Lw0KPiAgICAgICAgICAgICAgICAtIFRQRTMgLS0tLS0tLS0tLS0tLS0gU1BFMiAtLS0tLS0tLS0t LS0tLS0gVFBFNCAtDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLSBTRUczIC0tLS0t Pnw8LS0tLS0gU0VHNCAtLS0tLT58DQo+ICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0t LS0tLS0gUFcyIC0tLS0tLS0tLS0tLS0tLT58DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDMNCj4NCj4gICAgICBGaWd1cmUgMyBzaG93cyBhIHRvcG9sb2d5 IHRoYXQgaXMgc2ltaWxhciB0byBGaWd1cmUgMSBidXQgaW4gYW4gTVMtUFcNCj4gICAgICBlbnZp cm9ubWVudC4gIFBXMSBhbmQgUFcyIGFyZSBib3RoIE1TLVBXcy4gIFBXMSBpcyBlc3RhYmxpc2hl ZA0KPiAgICAgIGJldHdlZW4gVFBFMSBhbmQgVFBFMiwgYW5kIHN3aXRjaGVkIGJldHdlZW4gc2Vn bWVudHMgU0VHMSBhbmQgU0VHMiBhdA0KPiAgICAgIFNQRTEuICBQVzIgaXMgZXN0YWJsaXNoZWQg YmV0d2VlbiBUUEUzIGFuZCBUUEU0LCBhbmQgc3dpdGNoZWQgYmV0d2Vlbg0KPiAgICAgIHNlZ21l bnRzIFNFRzMgYW5kIFNFRzQgYXQgU1BFMi4gIENFMSBpcyBtdWx0aS1ob21lZCB0byBUUEUxIGFu ZCBUUEUzLg0KPiAgICAgIENFMiBpcyBtdWx0aS1ob21lZCB0byBUUEUyIGFuZCBUUEU0LiAgVGhl IHRyYW5zcG9ydCB0dW5uZWxzIG9mIHRoZSBQVw0KPiAgICAgIHNlZ21lbnRzIGFyZSBub3Qgc2hv d24gaW4gdGhpcyBmaWd1cmUgZm9yIGNsYXJpdHkuDQo+DQo+ICAgICAgSW4gdGhpcyBkb2N1bWVu dCwgdGhlIGZvbGxvd2luZyBwcmltYXJ5IGFuZCBiYWNrdXAgcm9sZXMgYXJlIGFzc2lnbmVkDQo+ ICAgICAgZm9yIHRoZSB0cmFmZmljIGdvaW5nIGZyb20gQ0UxIHRvIENFMjoNCj4NCj4gICAgICAg ICBQcmltYXJ5IFBXOiBQVzENCj4NCj4gICAgICAgICBQcmltYXJ5IFQtUEU6IFRQRTINCj4NCj4g ICAgICAgICBQcmltYXJ5IFMtUEU6IFNQRTENCj4NCj4gICAgICAgICBQcmltYXJ5IEFDOiBDRTIt VFBFMg0KPg0KPiAgICAgICAgIEJhY2t1cCBQVzogUFcyDQo+DQo+ICAgICAgICAgQmFja3VwIFQt UEU6IFRQRTQNCj4NCj4gICAgICAgICBCYWNrdXAgUy1QRTogU1BFMg0KPg0KPiAgICAgICAgIEJh Y2t1cCBBQzogQ0UyLVRQRTQNCj4NCj4gICAgICBJbiB0aGlzIGNhc2UsIGFuIGVncmVzcyBBQyBm YWlsdXJlIHJlZmVycyB0byB0aGUgZmFpbHVyZSBvZiB0aGUgQUMNCj4gICAgICBDRTItVFBFMi4g IEFuIGVncmVzcyBub2RlIGZhaWx1cmUgcmVmZXJzIHRvIHRoZSBmYWlsdXJlIG9mIFRQRTIuICBB bg0KPiAgICAgIFMtUEUgZmFpbHVyZSByZWZlcnMgdG8gdGhlIGZhaWx1cmUgb2YgU1BFMS4NCj4N Cj4NCj4NCj4NCj4NCj4gWWltaW4gU2hlbiwgZXQgYWwuICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1 LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDddDQo+DQo+DQo+IEludGVybmV0LURyYWZ0ICAg ICBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJvdGVjdGlvbiAgICAgICAgIEp1bHkgMjAxNA0K Pg0KPg0KPiAgICAgIFRoZSBiYWNrdXAgVC1QRSwgYmFja3VwIFBXIGFuZCBiYWNrdXAgQUMgYXJl IHVzZWQgZm9yIHByb3RlY3RpbmcgdGhlDQo+ICAgICAgcHJpbWFyeSBQVyBhZ2FpbnN0IGVncmVz cyBBQyBmYWlsdXJlIGFuZCBlZ3Jlc3Mgbm9kZSBmYWlsdXJlLiAgVGhlDQo+ICAgICAgYmFja3Vw IFMtUEUgYW5kIHRoZSBiYWNrdXAgUFcgYXJlIHVzZWQgZm9yIHByb3RlY3RpbmcgdGhlIHByaW1h cnkgUFcNCj4gICAgICBhZ2FpbnN0IFMtUEUgZmFpbHVyZSwgYXMgZGVzY3JpYmVkIGxhdGVyIGlu IHRoaXMgZG9jdW1lbnQuDQo+DQo+ICAgICAgRm9yIGNvbnNpc3RlbmN5IHdpdGggdGhlIFNTLVBX IHNjZW5hcmlvLCBwcmltYXJ5IFQtUEVzIGFuZCBhIHByaW1hcnkNCj4gICAgICBTLVBFcyBtYXkg c2ltcGx5IGJlIHJlZmVycmVkIHRvIGFzIHByaW1hcnkgUEVzIGluIHRoaXMgZG9jdW1lbnQsDQo+ ICAgICAgd2hlcmUgc3BlY2lmaWNzIGlzIG5vdCByZXF1aXJlZC4gIFNpbWlsYXJseSwgYmFja3Vw IFQtUEVzIGFuZCBiYWNrdXANCj4gICAgICBTLVBFcyBtYXkgYmUgcmVmZXJyZWQgdG8gYXMgYmFj a3VwIFBFcy4NCj4NCj4gNC4gIFRoZW9yeSBvZiBPcGVyYXRpb24NCj4NCj4gICAgICBUaGUgZmFz dCBwcm90ZWN0aW9uIG1lY2hhbmlzbSBpbiB0aGlzIGRvY3VtZW50IHByb3ZpZGVzIHRocmVlIHR5 cGVzDQo+ICAgICAgb2YgcHJvdGVjdGlvbiBmb3IgUFdzLCBjb3JyZXNwb25kaW5nIHRvIHRoZSB0 aHJlZSB0eXBlcyBvZiBmYWlsdXJlcw0KPiAgICAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEuDQo+ DQo+ICAgICAgYS4gIEVncmVzcyBBQyBwcm90ZWN0aW9uDQo+DQo+ICAgICAgYi4gIEVncmVzcyAo VC0pUEUgbm9kZSBwcm90ZWN0aW9uDQo+DQo+ICAgICAgYy4gIFMtUEUgbm9kZSBwcm90ZWN0aW9u DQo+DQo+ICAgICAgVGhlIG1lY2hhbmlzbSBhc3N1bWVzIGEgbXVsdGktaG9tZWQgQ0Ugd2l0aCBj b25uZWN0aXZpdHkgdG8gYSBwcmltYXJ5DQo+ICAgICAgUEUgYW5kIGEgYmFja3VwIFBFLCBhbmQg dGhlIGV4aXN0ZW5jZSBvZiBhIGJhY2t1cCBQVyBpbiB0aGUgbmV0d29yay4NCj4gICAgICBJbiBT LVBFIG5vZGUgcHJvdGVjdGlvbiwgaXQgYWxzbyBhc3N1bWVzIHRoZSBleGlzdGVuY2Ugb2YgYSBi YWNrdXANCj4gICAgICBTLVBFIG9uIHRoZSBiYWNrdXAgUFcuDQo+DQo+DQo+IFNCPiBEbyB0aGUg UFdzIG5lZWQgdG8gYmUgc3ltbWV0cmljIC0gY291bGQgeW91IGhhdmUgbW9yZQ0KPiBTLVBFcyBv biBvbmUgdGhhdCB5b3UgaGF2ZSBvbiB0aGUgb3RoZXI/DQo+DQo+IFt5c2hlbl0gWW91IGNvdWxk LiBGb3IgYSBnaXZlbiBTLVBFLCBhcyBsb25nIGFzIHlvdSBjYW4gZmluZCBhbm90aGVyIFBFIHRv IHNlcnZlIGFzIHByb3RlY3RvciwgaXQgd2lsbCB3b3JrLg0KPg0KPiA0LjEuICBMb2NhbCBSZXBh aXIgYW5kIFByb3RlY3Rvcg0KPg0KPiAgICAgIFRoZSBtZWNoYW5pc20gcmVsaWVzIG9uIGxvY2Fs IHJlcGFpciB0byBiZSBwZXJmb3JtZWQgYnkgcm91dGVycw0KPiBTQj4gRG8geW91IG1lYW4gcm91 dGVycyBvciBQRXM/IFJvdXRlcnMgb2YgbW9yZSBsaWtlbHkgTFNScw0KPiBvcGVyYXRlIGF0IGEg ZGlmZmVyZW50IGxheWVyIGFuZCBoYXZlIG5vIGJ1c2luZXNzIGtub3dpbmcgYWJvdXQNCj4gUFdz Lg0KPg0KPiBbeXNoZW5dIHJvdXRlcnMgKExTUnMpLiBZZXMsIHRoZXkgaGF2ZSBubyBpZGVhIGFi b3V0IFBXcy4gVGhpcyBkcmFmdCBkb2Vzbid0IGFzc3VtZSB0aGV5IGtub3cgb3IgY2FyZSBhYm91 dCBQV3MuDQo+DQo+IFNCPiBIYXMgdGhpcyB3b3JrIGJlZW4gcmV2aWV3ZWQgbXkgTVBMUyBXRz8g SSBhbSBjb25jZXJuZWQNCj4gdGhhdCB5b3UgYXJlIGRvaW5nIGEgYnVuY2ggb2YgbGF5ZXIgdmlv bGF0aW9uIHdpdGhvdXQgZXhwbGFpbmluZw0KPiB0aGUgaG93IHRoaXMgaXMgYWNoaWV2ZWQgb3Ig d2hldGhlciBpdCBpcyBhY2NlcHRhYmxlIHdpdGhpbiB0aGUNCj4gTVBMUyBhcmNoaXRlY3R1cmUu DQo+DQo+IFt5c2hlbl0gVGhlcmUgaXMgbm8gbGF5ZXIgdmlvbGF0aW9uLiBUaGUgUExSIHNpbXBs eSByZWRpcmVjdCB0cmFmZmljIGZyb20gdGhlIG9yaWdpbmFsIHR1bm5lbCB0byBhIGJ5cGFzcyB0 dW5uZWwsIGJ5IGRvaW5nIGEgdG9wIGxhYmVsIHN3YXAsIHdpdGhvdXQgdG91Y2hpbmcsIGNoYW5n aW5nIG9yIGtub3dpbmcgdGhlIFBXIGxhYmVsLiBQbGVhc2UgdGFrZSBhIGNsb3NlIGxvb2sgYXQg dGhlIHRleHQuDQo+DQo+ICAgICAgdXBzdHJlYW0gYWRqYWNlbnQgdG8gZmFpbHVyZXMuICBFYWNo IG9mIHRoZXNlIHJvdXRlcnMgaXMgcmVmZXJyZWQgdG8NCj4gICAgICBhcyBhICJwb2ludCBvZiBs b2NhbCByZXBhaXIiIChQTFIpLiAgQSBQTFIgTVVTVCBiZSBhYmxlIHRvIGRldGVjdCBhDQo+ICAg ICAgZmFpbHVyZSBieSB1c2luZyBhIHJhcGlkIG1lY2hhbmlzbSwgc3VjaCBhcyBwaHlzaWNhbCBs YXllciBmYWlsdXJlDQo+ICAgICAgZGV0ZWN0aW9uLCBCaWRpcmVjdGlvbmFsIEZhaWx1cmUgRGV0 ZWN0aW9uIChCRkQpIChSRkMgNTg4MCksIGV0Yy4gIEluDQo+ICAgICAgYW50aWNpcGF0aW9uIG9m IHRoZSBmYWlsdXJlLCB0aGUgUExSIE1VU1QgYWxzbyBwcmUtZXN0YWJsaXNoIGEgYnlwYXNzDQo+ ICAgICAgUFNOIHR1bm5lbCB0byBhICJwcm90ZWN0b3IiLCBhbmQgcHJlLWluc3RhbGwgYSBieXBh c3Mgcm91dGUgaW4gdGhlDQo+ICAgICAgZGF0YSBwbGFuZS4gIFRoZSBieXBhc3MgdHVubmVsIE1V U1QgaGF2ZSB0aGUgcHJvcGVydHkgdGhhdCBpdCB3aWxsDQo+ICAgICAgbm90IGJlIGFmZmVjdGVk IGJ5IHRoZSB0b3BvbG9neSBjaGFuZ2VzIGluIHRoZSBldmVudCBvZiB0aGUgZmFpbHVyZS4NCj4N Cj4gU0I+IFRoaXMgaXMgZmFyIHRvbyBpbXByZWNpc2UgLSB5b3UgbmVlZCB0byBzZXBhcmF0ZSBv cGVyYXRpb25zIGFuZA0KPiB0b3BvbG9naWVzIGluIHRoZSBQVyBsYXllciBmcm9tIG9wZXJhdGlv bnMgYW5kIHRvcG9sb2dpZXMgaW4gdGhlDQo+IFBTTiBsYXllcg0KPg0KPiBbeXNoZW5dIFNpbWls YXIgdG8gZXhpc3RpbmcgSVAvTVBMUyBmYXN0LXJlcm91dGUgUkZDcywgdGhpcyBkcmFmdCBkb2Vz bid0IHJlc3RyaWN0IGxvY2FsIHJlcGFpciB0cmlnZ2VyIHRvIGFueSBzcGVjaWZpYyBmYWlsdXJl IGRldGVjdGlvbiBtZWNoYW5pc21zLiBBbnkgbWVjaGFuaXNtIHdpbGwgd29yay4NCj4NCj4gU0I+ IEluIGVhY2ggY2FzZSB5b3UgbmVlZCB0byBiZSBjbGVhciBob3cgeW91IGFyZSBkZXRlY3Rpbmcg ZmFpbHVyZQ0KPiBieSBzcGVjaWZ5aW5nIHRoZSBNRVBzIGFuZCBNSVBzIHlvdSBhcmUgdGVzdGlu Zy4NCj4NCj4gICAgICBVcG9uIGRldGVjdGluZyB0aGUgZmFpbHVyZSwgdGhlIFBMUiBNVVNUIGlu dm9rZSB0aGUgYnlwYXNzIHJvdXRlIGluDQo+ICAgICAgdGhlIGRhdGEgcGxhbmUsIGFuZCByZXJv dXRlIFBXIHRyYWZmaWMgdG8gdGhlIHByb3RlY3RvciB0aHJvdWdoIHRoZQ0KPiAgICAgIGJ5cGFz cyB0dW5uZWwuICBUaGUgcHJvdGVjdG9yIE1VU1QgaW4gdHVybiBzZW5kIHRoZSB0cmFmZmljIHRv IHRoZQ0KPiAgICAgIHRhcmdldCBDRS4NCj4NCj4gU0I+IE5vIHRoZSBwcm90ZWN0b3Iga25vd3Mg bm90aGluZyBhYm91dCBDRXMgLSB0aGV5IGFyZSBpbiB0aGUgY2xpZW50DQo+IGxheWVyLCBhbmQg eW91IGNhbiBvbmx5IHByb3RlY3QgYXQgdGhlIHNlcnZlciBsYXllciBvciB0aGUgc2VydmVyJ3MN Cj4gc2VydmVyIGxheWVyLg0KPg0KPiBbeXNoZW5dIEluIGNvbGxvY2F0ZWQgbW9kZWwsIHRoZSBw cm90ZWN0b3IgaXMgYSBQRS4gSW4gdGhlIGNlbnRyYWxpemVkIG1vZGVsLCB0aGUgcHJvdGVjdG9y IG1heSBiZSBhbiBMU1IgLCBhbmQgaXQgbmVlZHMgdG8gcGFydGljaXBhdGUgaW4gTERQIFBXIHNp Z25hbGluZyB0byB1bmRlcnN0YW5kIFBXcy4gU2VlIHRoZSByZWxhdGVkIHNlY3Rpb25zIGFuZCBM RFAgZXh0ZW5zaW9ucyBpbiB0aGlzIGRyYWZ0LiBUaGlzIGNlbnRyYWxpemVkIG1vZGVsIGlzIG9w dGlvbmFsLg0KPg0KPiAgICAgIFRoaXMgcHJvY2VkdXJlIGlzIHJlZmVycmVkIHRvIGFzIGxvY2Fs IHJlcGFpci4NCj4NCj4gICAgICBEaWZmZXJlbnQgcm91dGVycyBtYXkgc2VydmUgYXMgUExSIGFu ZCBwcm90ZWN0b3IgaW4gZGlmZmVyZW50DQo+ICAgICAgc2NlbmFyaW9zLg0KPg0KPiBTQj4gUmVt ZW1iZXIgdGhleSBhcmUgbm90IHJvdXRlcnMgLSB0aGV5IGFyZSB4UEVzIG9yIExTUnMuDQo+DQo+ IFt5c2hlbl0gQWdhaW4sIGluIGNvbGxvY2F0ZWQgbW9kZWwsIHRoZSBwcm90ZWN0b3IgaXMgYSBQ RS4gSW4gdGhlIGNlbnRyYWxpemVkIG1vZGVsLCB0aGUgcHJvdGVjdG9yIG1heSBiZSBhbiBMU1Ig LCBhbmQgaXQgbmVlZHMgdG8gcGFydGljaXBhdGUgaW4gTERQIFBXIHNpZ25hbGluZyB0byB1bmRl cnN0YW5kIFBXcy4gU2VlIHRoZSByZWxhdGVkIHNlY3Rpb25zIGFuZCBMRFAgZXh0ZW5zaW9ucyBp biB0aGlzIGRyYWZ0LiBCdXQgdGhpcyBjZW50cmFsaXplZCBtb2RlbCBpcyBvcHRpb25hbC4NCj4g W3lzaGVuXSBQTFJzIG1heSBiZSBMU1JzLCBidXQgdGhleSBkb24ndCBuZWVkIHRvIGtub3cgUFdz LCBiZWNhdXNlIGFsbCB0aGV5IGRvIGlzIHRvIHN3YXAgdG9wIGxhYmVsICh0dW5uZWwgbGFiZWwp IHRvIGEgYnlwYXNzIHR1bm5lbCdzIGxhYmVsLg0KPg0KPiBTQj4gSW4gZWFjaCBvZiB0aGUgZm9s bG93aW5nIHdlIG5lZWQgdG8gbm90ZSB0aGF0IHRoZXNlIGFyZQ0KPiBub3QgUkZDMzk4NSBQRXMs IGV2ZW4gaWYgdGhleSB0YWtlIG5vIHBhcnQgaW4gdGhlIHByb3RlY3Rpb24NCj4gc3VjaCBhcyB0 aGUgUEVzIG9uIHRoZSBsZWZ0LiBJbmRlZWQgSSBhbSB3b25kZXJpbmcgaWYgeW91IG5lZWQNCj4g dG8gdXBkYXRlIFJGQzM5ODUgYW5kIFJGQzU2NTkNCj4NCj4gW3lzaGVuXSBUaGVyZSBpcyBubyBu ZWVkIHRvIHVwZGF0ZSBSRkMzOTg1IGFuZCBSRkM1NjU5Lg0KPg0KPiBZaW1pbiBTaGVuLCBldCBh bC4gICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgOF0N Cj4NCj4NCj4gSW50ZXJuZXQtRHJhZnQgICAgIFBXIEVuZHBvaW50IEZhc3QgRmFpbHVyZSBQcm90 ZWN0aW9uICAgICAgICAgSnVseSAyMDE0DQo+DQo+DQo+ICAgICAgbyAgSW4gZWdyZXNzIEFDIHBy b3RlY3Rpb24sIHRoZSBQTFIgaXMgdGhlIHByaW1hcnkgUEUgdGhhdCB0ZXJtaW5hdGVzDQo+ICAg ICAgICAgdGhlIHByaW1hcnkgUFcgYW5kIGhvc3RzIHRoZSBwcmltYXJ5IEFDLCBhbmQgdGhlIHBy b3RlY3RvciBpcyB0aGUNCj4gICAgICAgICBiYWNrdXAgUEUgKEZpZ3VyZSA0KS4NCj4NCj4gICAg ICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tIFBXMSAtLS0tLS0tLS0tLS0tLS0+fA0K Pg0KPiAgICAgICAgICAgICAgICAgLSBQRTEgLS0tLS0tLS0tLS0tLS0gUDEgLS0tLS0tLS0tLS0t LS0tLSBQRTIgLQ0KPiAgICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBQTFIgIFwNCj4gICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgXA0KPiAgICAgICAgICAgIENFMSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnlwYXNzfCAgICAgQ0UyDQo+ICAgICAgICAg ICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIC8N Cj4gICAgICAgICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAvDQo+ICAgICAgICAgICAgICAgICAtIFBFMyAtLS0tLS0tLS0tLS0tLSBQMiAtLS0t LS0tLS0tLS0tLS0tIFBFNCAtDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHByb3RlY3Rvcg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIHw8 LS0tLS0tLS0tLS0tLS0gUFcyIC0tLS0tLS0tLS0tLS0tLT58DQo+DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDQNCj4NCj4NCj4gICAgICBvICBJbiBlZ3Jlc3Mg UEUgbm9kZSBwcm90ZWN0aW9uLCB0aGUgUExSIGlzIHRoZSBwZW51bHRpbWF0ZSBob3ANCj4gICAg ICAgICByb3V0ZXIgb2YgdGhlIHRyYW5zcG9ydCB0dW5uZWwgb2YgdGhlIHByaW1hcnkgUFcsIGFu ZCB0aGUNCj4gICAgICAgICBwcm90ZWN0b3IgaXMgdGhlIGJhY2t1cCBQRSAoRmlndXJlIDUpLg0K Pg0KPiAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0gUFcxIC0tLS0tLS0tLS0t LS0tLT58DQo+DQo+ICAgICAgICAgICAgICAgICAtIFBFMSAtLS0tLS0tLS0tLS0tLSBQMSAtLS0t LS0tIFAzIC0tLS0tIFBFMiAtDQo+ICAgICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUExSIFwgICAgICAgICAgXA0KPiAgICAgICAgICAgICAgIC8gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAgICBcDQo+ICAgICAgICAgICAgQ0Ux ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnlwYXNzXCAgICAgICAgICBDRTINCj4g ICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAg ICAgICAgLw0KPiAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgXCAgICAgIC8NCj4gICAgICAgICAgICAgICAgIC0gUEUzIC0tLS0tLS0tLS0tLS0t IFAyIC0tLS0tLS0tLS0tLS0tLS0gUEU0IC0NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJvdGVjdG9yDQo+DQo+ICAgICAgICAgICAgICAg ICAgICAgfDwtLS0tLS0tLS0tLS0tLSBQVzIgLS0tLS0tLS0tLS0tLS0tPnwNCj4NCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNQ0KPg0KPiBTQj4gTm90ZSB0aGF0 IGl0IGlzIG5vdGhpbmcgbGlrZSBhcyBjbGVhbiBhcyB0aGlzLCBpZiBhcyB5b3UgbGF0ZXIgaGF2 ZSwNCj4gc29tZSBvZiBQMydzIHRyYWZmaWMgbmVlZHMgdG8gZ28gdG8gUEU0IGFuZCBzb21lIHRv IFBFNS4NCj4gQWxzbyB3aGF0IGFib3V0IHRoZQ0KPg0KPiBbeXNoZW5dIE5vdGUgdGhhdCB3ZSBh cmUgdGFsa2luZyBhYm91dCBhIHNpbmdsZSBQVywgcmF0aGVyIHRoYW4gbXVsdGlwbGUgUFdzIGNh cnJpZWQgYnkgYSBzaW5nbGUgdHVubmVsLg0KPg0KPiAgICAgIG8gIEluIFMtUEUgbm9kZSBwcm90 ZWN0aW9uLCB0aGUgUExSIGlzIHRoZSBwZW51bHRpbWF0ZSBob3Agcm91dGVyIG9mDQo+ICAgICAg ICAgdGhlIHRyYW5zcG9ydCB0dW5uZWwgb2YgdGhlIHByaW1hcnkgUFcgc2VnbWVudCwgYW5kIHRo ZSBwcm90ZWN0b3INCj4gICAgICAgICBpcyB0aGUgYmFja3VwIFMtUEUgKEZpZ3VyZSA2KS4NCj4N Cj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gWWltaW4gU2hlbiwgZXQgYWwuICAgICAgRXhw aXJlcyBKYW51YXJ5IDI1LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDldDQo+DQo+DQo+IElu dGVybmV0LURyYWZ0ICAgICBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJvdGVjdGlvbiAgICAg ICAgIEp1bHkgMjAxNA0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0t LS0tIFBXMSAtLS0tLS0tLS0tLS0tLS0+fA0KPiAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0g U0VHMSAtLS0tLT58PC0tLS0tIFNFRzIgLS0tLS0+fA0KPg0KPiAgICAgICAgICAgICAgICAtIFRQ RTEgLS0tLS0gUDQgIC0tLS0tIFNQRTEgLS0tLS0tLS0tLS0tLS0gVFBFMiAtDQo+ICAgICAgICAg ICAgICAgLyAgICAgICAgICAgICBQTFIgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc DQo+ICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgXA0KPiAgICAgICAgICAgQ0UxICAgICAgICAgICAgICAgYnlwYXNzXCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDRTINCj4gICAgICAgICAgICAgIFwgICAgICAgICAg ICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQo+ICAgICAgICAgICAg ICAgXCAgICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQo+ ICAgICAgICAgICAgICAgIC0gVFBFMyAtLS0tLS0tLS0tLS0tLS0gU1BFMiAtLS0tLS0tLS0tLS0t LSBUUEU0IC0NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcm90ZWN0b3IN Cj4NCj4gICAgICAgICAgICAgICAgICAgICB8PC0tLS0tIFNFRzMgLS0tLS0+fDwtLS0tLSBTRUc0 IC0tLS0tPnwNCj4gICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLSBQVzIgLS0t LS0tLS0tLS0tLS0tPnwNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG aWd1cmUgNg0KPg0KPiAgICAgIEEgUExSIGNhbiByZWFsaXplIGl0cyByb2xlIGJhc2VkIG9uIGNv bmZpZ3VyYXRpb24gb3IgdGhlIHNpZ25hbGluZyBvZg0KPiAgICAgIHRyYW5zcG9ydCB0dW5uZWwu ICBGb3IgZXhhbXBsZSwgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIHRyYW5zcG9ydA0KPiAgICAgIHR1 bm5lbCBpcyBzaWduYWxlZCBieSBSU1ZQLCB0aGUgcGVudWx0aW1hdGUgaG9wIHJvdXRlciBjb3Vs ZCByZWFsaXplDQo+DQo+IFNCPiBDb3VsZCByZWFsaXplIGlzIG5vdCBzdWZmaWNpZW50LiBUaGUg bWVjaGFuaXNtIG5lZWRzIHRvIGJlDQo+IHVuY29uZGl0aW9uYWwuDQo+DQo+IFt5c2hlbl0gV2ls bCByZXBocmFzZS4NCj4NCj4gICAgICB0aGF0IGl0IGlzIHRoZSBQTFIgZm9yIGVncmVzcyAoVC0p UEUgb3IgUy1QRSBmYWlsdXJlIGJhc2VkIG9uIHRoZSBSUk8NCj4gICAgICBpbiBSZXN2IG1lc3Nh Z2UsIHdoaWNoIHNob3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSByb3V0ZXIgaXMgb25lIGhvcA0KPiAg ICAgIGF3YXkgZnJvbSB0aGUgUEUuICBUaGUgZGV0YWlsIG9mIGhvdyB0aGlzIGNvdWxkIGJlIGFj aGlldmVkIG9uIGEgcGVyLQ0KPiAgICAgIHByb3RvY29sIGJhc2lzIGlzIG91dCBvZiB0aGUgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4NCj4NCj4gU0I+IFNvIHdoZXJlIGlzIGl0IGluIHNjb3BlPyBI b3cgZG8gSSBmaW5kIG91dCBob3cgdG8gZG8gaXQ/DQo+DQo+ICAgICAgSW4gYWxsIHNjZW5hcmlv cywgd2hlbiBhIFBMUiByZXJvdXRlcyB0cmFmZmljIHRocm91Z2ggYSBieXBhc3MgdHVubmVsDQo+ ICAgICAgdG8gYSBwcm90ZWN0b3IgZHVyaW5nIGxvY2FsIHJlcGFpciwgaXQgTVVTVCBrZWVwIHRo ZSBsYWJlbCBvZiB0aGUNCj4gICAgICBwcmltYXJ5IFBXIGludGFjdCBpbiB0aGUgcGFja2V0cy4g IFRoaXMgb2J2aWF0ZXMgdGhlIG5lZWQgZm9yIHRoZSBQTFINCj4gICAgICB0byBtYWludGFpbiBi eXBhc3Mgcm91dGVzIG9uIGEgcGVyLVBXIGJhc2lzLCBhbmQgYWxsb3dzIGEgc2luZ2xlDQo+ICAg ICAgYnlwYXNzIHR1bm5lbCB0byBjYXJyeSB0cmFmZmljIGZvciBtdWx0aXBsZSBQV3MuDQo+DQo+ IFNCPiBPSywgYnV0IGRpZG4ndCBJIHJlYWQgc29tZXRoaW5nIGFib3V0IFBFIHByb3RlY3Rpbmcg c3Vic2V0cyBvZiB0aGUNCj4gZWdyZXNzIHRyYWZmaWMgb2Ygb3RoZXIgUEVzPyBIb3cgd291bGQg dGhhdCB3b3JrIHdpdGhvdXQgcGVyIFBXIGluZm9ybWF0aW9uPw0KPg0KPiBbeXNoZW5dIFBXcyB0 byBhIGdpdmVuIFBFIG1heSBiZSBwcm90ZWN0ZWQgYnkgbXVsdGlwbGUgcHJvdGVjdG9ycy4gQSBz ZXQgb2YgUFdzIHNoYXJpbmcgdGhlIHNhbWUgcHJvdGVjdG9yIFggY2FuIGJlIGNhcnJpZWQgYnkg dGhlIHNhbWUgdHVubmVsIChkZXN0aW5lZCB0byB0aGUgY29udGV4dCBJRCBvZiA8cHJpbWFyeSBQ RSwgWD4pLiBQV3MgcHJvdGVjdGVkIGJ5IGEgZGlmZmVyZW50IHByb3RlY3RvciBZIG11c3QgYmUg Y2FycmllZCBieSBkaWZmZXJlbnQgdHVubmVsIChkZXN0aW5lZCB0byB0aGUgY29udGV4dCBJRCBv ZiA8cHJpbWFyeSBQRSwgWT4pLiBUaGUgUExSIG9mIGVhY2ggdHVubmVsIGRvZXNuJ3QgbmVlZCB0 byBrbm93IFBXIGluZm8uIEFsbCBpdCBkb2VzIGlzIHRvIHN3YXAgdHVubmVsIGxhYmVsIHRvIGEg YnlwYXNzIHR1bm5lbCdzIGxhYmVsLCBhbmQgdGhlIGJ5cGFzcyB0dW5uZWwgd2lsbCBndWlkZSB0 aGUgdHJhZmZpYyB0byB0aGUgaW50ZW5kZWQgcHJvdGVjdG9yLg0KPg0KPiAgICAgIFRoZSBwcm9j ZWR1cmUgYWxzbyByZXF1aXJlcyB0aGF0IHRoZSBwcm90ZWN0b3IgU0hPVUxEIGJlIGFibGUgdG8N Cj4gICAgICBmb3J3YXJkIHRoZSB0cmFmZmljIGJhc2VkIG9uIGEgUFcgbGFiZWwgdGhhdCBpcyBh c3NpZ25lZCBieSB0aGUNCj4gICAgICBwcmltYXJ5IFBFLCBhbmQgZW5zdXJlIHRoZSB0cmFmZmlj IHRvIGV2ZW50dWFsbHkgcmVhY2ggdGhlIHRhcmdldCBDRS4NCj4gICAgICBGcm9tIHRoZSBwcm90 ZWN0b3IncyBwZXJzcGVjdGl2ZSwgdGhpcyBQVyBsYWJlbCBpcyBhbiB1cHN0cmVhbQ0KPiAgICAg IGFzc2lnbmVkIGxhYmVsIChSRkMgNTMzMSkuDQo+DQo+IFNCPiAuLiBidXQgdGhlIHByb3RlY3Rv ciBtYXkgYmUgYSBQIHJvdXRlciBhbmQga25vdyBub3RoaW5nIGFib3V0DQo+IFBXcy4NCj4NCj4g W3lzaGVuXSBBZ2FpbiwgaW4gY29sbG9jYXRlZCBtb2RlbCwgdGhlIHByb3RlY3RvciBpcyBhIFBF LiBJbiB0aGUgY2VudHJhbGl6ZWQgbW9kZWwsIHRoZSBwcm90ZWN0b3IgbWF5IGJlIGFuIExTUiAs IGFuZCBpdCBuZWVkcyB0byBwYXJ0aWNpcGF0ZSBpbiBMRFAgUFcgc2lnbmFsaW5nIHRvIHVuZGVy c3RhbmQgUFdzLiBTZWUgdGhlIHJlbGF0ZWQgc2VjdGlvbnMgYW5kIExEUCBleHRlbnNpb25zIGlu IHRoaXMgZHJhZnQuIEJ1dCB0aGlzIGNlbnRyYWxpemVkIG1vZGVsIGlzIG9wdGlvbmFsLg0KPg0K Pg0KPiAgICAgIFRvIGFjY29tcGxpc2ggdGhpcywgdGhlIHByb3RlY3RvciBTSE9VTEQNCj4gICAg ICBsZWFybmluZyB0aGUgUFcgbGFiZWwgZnJvbSB0aGUgcHJpbWFyeSBQRSBwcmlvciB0byB0aGUg ZmFpbHVyZSwgYW5kDQo+ICAgICAgaW5zdGFsbCBwcm9wZXIgZm9yd2FyZGluZyBzdGF0ZSBmb3Ig dGhlIFBXIGxhYmVsIGluIGEgZGVkaWNhdGVkIGxhYmVsDQo+ICAgICAgc3BhY2UgZm9yIHRoZSBw cmltYXJ5IFBFLg0KPg0KPiBTQj4gVGhpcyBpcyBhIG5ldyBQRSB0byBQIHJvdXRlciBwcm90b2Nv bA0KPg0KPiBbeXNoZW5dIFRoZSBMRFAgZXh0ZW5zaW9uIGlzIGRlZmluZWQgaW4gYSBzdWJzZXF1 ZW50IHNlY3Rpb24uDQo+DQo+ICAgICAgRHVyaW5nIGxvY2FsIHJlcGFpciwgdGhlIHByb3RlY3Rv ciBTSE9VTEQNCj4gICAgICBwZXJmb3JtIFBXIGxhYmVsIGxvb2t1cCBpbiB0aGlzIGxhYmVsIHNw YWNlLg0KPg0KPiBTQj4gVGhpcyBoYXMgdG8gYmUgc2lnbmVkIG9mZiBieSBNUExTIFdHDQo+IFNC PiBIb3cgY2FuIHRoaXMgb25seSBiZSBhIFNIT1VMRCAtIHdoeSBpcyBpdCBub3QgYSBNVVNUPw0K Pg0KPiBbeXNoZW5dIFdpbGwgcmVwaHJhc2UuDQo+DQo+IFNCPiBXaGF0IGRvIHlvdSBkbyB0byBl bnN1cmUgdGhhdCB0aGV5IGV2ZW4gaGF2ZSBjb21wYXRpYmxlIGxhYmVsIG1hbmFnZXJzPw0KPg0K PiBbeXNoZW5dIFRoZSBMRFAgZXh0ZW5zaW9ucyBkZWZpbmVkIGluIHRoaXMgZHJhZnQgY292ZXJz IGhvdyB0byBuZWdvdGlhdGUgdGhlIGNhcGFiaWxpdHkuDQo+DQo+DQo+IFNCPiBEb2Vzbid0IHRo aXMgbWVhbiBhIFAgcm91dGVyIGxvb2tpbmcgdXAgdHdvIGxhYmVscyB0byBkbw0KPiB0aGUgcmVw YWlyPw0KPg0KPiBbeXNoZW5dIFBMUiBvbmx5IHN3YXBzIHRoZSB0b3AgbGFiZWwgKGkuZS4gdHVu bmVsIGxhYmVsKSB0byBieXBhc3MgbGFiZWwgdGFibGUsIHdoZW4gZG9pbmcgdGhlIGxvY2FsIHJl cGFpci4NCj4NCj4gICAgICBUaGUgYWJvdmUgZXhhbXBsZXMgaGF2ZSBzaG93biB0aGUgc2NlbmFy aW9zIHdoZXJlIHRoZSBwcm90ZWN0b3JzIGFyZQ0KPiAgICAgIGJhY2t1cCAoVC9TLSlQRXMuICBJ biBvdGhlciBzY2VuYXJpb3MsIGEgcHJvdGVjdG9yIG1heSBiZSBhIGRlZGljYXRlZA0KPiAgICAg IHJvdXRlciB0aGF0IGFzc3VtZXMgc3VjaCByb2xlLCBzZXBhcmF0ZSBmcm9tIHRoZSBiYWNrdXAg KFQvUy0pUEUgb2YgYQ0KPiAgICAgIHByaW1hcnkgUFcuICBEdXJpbmcgbG9jYWwgcmVwYWlyLCB0 aGUgUExSIE1VU1Qgc3RpbGwgcmVyb3V0ZSB0cmFmZmljDQo+ICAgICAgdG8gdGhlIHByb3RlY3Rv ciB0aHJvdWdoIGEgYnlwYXNzIHR1bm5lbC4gIFRoZSBwcm90ZWN0b3IgTVVTVCBpbiB0dXJuDQo+ ICAgICAgc2VuZCB0aGUgdHJhZmZpYyB0byB0aGUgYmFja3VwIChUL1MtKVBFLCB3aGljaCBNVVNU IHRoZW4gc2VuZCB0aGUNCj4NCj4NCj4NCj4NCj4gWWltaW4gU2hlbiwgZXQgYWwuICAgICAgRXhw aXJlcyBKYW51YXJ5IDI1LCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQo+DQo+DQo+IElu dGVybmV0LURyYWZ0ICAgICBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJvdGVjdGlvbiAgICAg ICAgIEp1bHkgMjAxNA0KPg0KPg0KPiAgICAgIHRyYWZmaWMgdG8gdGhlIHRhcmdldCBDRSB2aWEg YSBiYWNrdXAgQUMgb3IgYSBiYWNrdXAgUFcgc2VnbWVudC4NCj4gICAgICBNb3JlIGRldGFpbCB3 aWxsIGJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMy4NCj4NCj4gNC4yLiAgQ29udGV4dCBJZGVu dGlmaWVyDQo+DQo+ICAgICAgQSBwcm90ZWN0b3IgTUFZIHByb3RlY3QgbXVsdGlwbGUgcHJpbWFy eSBQRXMuDQo+DQo+IFNCPiBUaGlzIHJlcXVpcmVzIHRoYXQgYSBQIHJvdXRlciBrbm93cyBhYm91 dCBQV3MgLSBob3cgZG9lcw0KPiBpdCBkbyB0aGF0Pw0KPg0KPiBbeXNoZW5dIFRoZSBwcm90ZWN0 b3Igd2lsbCBwZXJmb3JtIGNvbnRleHQgbGFiZWwgZm9yd2FyZGluZy4gVGhlIGJ5cGFzcyB0dW5u ZWwgcG9pbnRzIHRvIGEgY29udGV4dCBsYWJlbCB0YWJsZSwgYW5kIHRoZSBwcm90ZWN0b3IgbG9v a3MgdXAgdGhlIFBXIGxhYmVsIGluIHRoYXQgdGFibGUuDQo+DQo+ICAgICAgVGhlIHByb3RlY3Rv ciBNVVNUDQo+ICAgICAgbWFpbnRhaW4gYSBzZXBhcmF0ZSBsYWJlbCBzcGFjZSBmb3IgZWFjaCBw cmltYXJ5IFBFLiAgTGlrZXdpc2UsIHRoZQ0KPiAgICAgIFBXcyB0ZXJtaW5hdGVkIG9uIGEgcHJp bWFyeSBQRSBNQVkgYmUgcHJvdGVjdGVkIGJ5IG11bHRpcGxlDQo+ICAgICAgcHJvdGVjdG9ycywg ZWFjaCBmb3IgYSBzdWJzZXQgb2YgdGhlIFBXcy4gIEluIGFueSBjYXNlLCBhIGdpdmVuDQo+ICAg ICAgcHJpbWFyeSBQVyBTSE9VTEQgYmUgYXNzb2NpYXRlZCB3aXRoIG9uZSBhbmQgb25seSBvbmUg cGFpciBvZg0KPiAgICAgIHtwcmltYXJ5IFBFLCBwcm90ZWN0b3J9Lg0KPg0KPiAgICAgIEFuIElQ djQvdjYgYWRkcmVzcyBpcyBhc3NpZ25lZCB0byBlYWNoIG9yZGVyZWQgcGFpciBvZiB7cHJpbWFy eSBQRSwNCj4gICAgICBwcm90ZWN0b3J9IHRvIGZhY2lsaXRhdGUgcHJvdGVjdGlvbiBlc3RhYmxp c2htZW50LiAgVGhpcyBhZGRyZXNzIGlzDQo+ICAgICAgcmVmZXJyZWQgdG8gYXMgYSAiY29udGV4 dCBpZGVudGlmaWVyIi4gIEl0IE1VU1QgYmUgZ2xvYmFsbHkgdW5pcXVlLA0KPiAgICAgIG9yIHVu aXF1ZSBpbiB0aGUgYWRkcmVzcyBzcGFjZSBvZiB0aGUgbmV0d29yayB3aGVyZSB0aGUgcHJpbWFy eSBQRQ0KPiAgICAgIGFuZCB0aGUgcHJvdGVjdG9yIHJlc2lkZS4NCj4NCj4gU0I+IEkgdGhpbmsg eW91IG5lZWQgdG8gbWFrZSBjbGVhciB0aGF0IHRoaXMgaXMgbm90IGJhY2t3YXJkcyBjb21wYXRp YmxlDQo+IHdpdGggZXhpc3RpbmcgUFcgUEVzLg0KPg0KPiBbeXNoZW5dIFBFcyB3aWxsIG5lZWQg dG8gc3VwcG9ydCB0aGUgZXh0ZW5zaW9ucyBkZWZpbmVkIGJ5IHRoaXMgZHJhZnQuDQo+DQo+IFNC PiBZb3UgYWxzbyBuZWVkIHRvIGV4cGxhaW4gaG93IHRoZSBJUCBiYXNlZCBjb250ZXh0IGlkZW50 aWZpZXINCj4gbWVjaGFuaXNtIHdvcmtzLiBJcyBpdCBpbiB0aGUgY29udHJvbCBwbGFuZSBvciB0 aGUgZGF0YSBwbGFuZT8NCj4NCj4gNC4yLjEuICBTZW1hbnRpY3MNCj4NCj4gICAgICBUaGUgc2Vt YW50aWNzIG9mIGEgY29udGV4dCBpZGVudGlmaWVyIGlzIHR3b2ZvbGQuDQo+DQo+ICAgICAgbyAg SXQgaWRlbnRpZmllcyBhIHByaW1hcnkgUEUgYW5kIGFuIGFzc29jaWF0ZWQgcHJvdGVjdG9yLiAg SW4gb3RoZXINCj4gICAgICAgICB3b3JkcywgaXQgaWRlbnRpZmllcyBhIHByaW1hcnkgUEUgb24g YSBwZXIgcHJvdGVjdG9yIGJhc2lzLiAgQQ0KPiAgICAgICAgIGdpdmVuIHByaW1hcnkgUEUgbWF5 IGJlIHByb3RlY3RlZCBieSBtdWx0aXBsZSBwcm90ZWN0b3JzLCBlYWNoIGZvcg0KPiAgICAgICAg IGEgc3Vic2V0IG9mIHRoZSBwcmltYXJ5IFBXcyB0ZXJtaW5hdGVkIG9uIHRoZSBwcmltYXJ5IFBF LiAgQQ0KPiAgICAgICAgIGRpc3RpbmN0IGNvbnRleHQgaWRlbnRpZmllciBNVVNUIGJlIGFzc2ln bmVkIHRvIHRoZSBwcmltYXJ5IFBFIGFuZA0KPiAgICAgICAgIGVhY2ggcHJvdGVjdG9yLg0KPg0K PiAgICAgICAgIEZvciBlYWNoIHByaW1hcnkgUFcsIGl0cyBpbmdyZXNzIFBFIE1VU1Qgc2V0IHVw IG9yIHJlc29sdmUgYQ0KPiAgICAgICAgIHRyYW5zcG9ydCB0dW5uZWwgd2l0aCBkZXN0aW5hdGlv biBhcyB0aGUgY29udGV4dCBpZGVudGlmaWVyIG9mIHRoZQ0KPiAgICAgICAgIHtwcmltYXJ5IFBF LCBwcm90ZWN0b3J9LCByYXRoZXIgdGhhbiBhIHByaXZhdGUgSVAgYWRkcmVzcyBvZiB0aGUNCj4g ICAgICAgICBwcmltYXJ5IFBFLiAgVGhpcyBub3Qgb25seSBhbGxvd3MgdGhlIHRyYW5zcG9ydCB0 dW5uZWwgdG8gcmVhY2gNCj4gICAgICAgICB0aGUgcHJpbWFyeSBQRSwgYnV0IGFsc28gY29udmV5 cyB0aGUgaWRlbnRpdHkgb2YgdGhlIHByb3RlY3RvciB0bw0KPiAgICAgICAgIHRoZSBQTFIocykg YWxvbmcgdGhlIHRyYW5zcG9ydCB0dW5uZWwuICBFYWNoIFBMUiBjYW4gaW4gdHVybiB1c2UNCj4g ICAgICAgICB0aGlzIGluZm9ybWF0aW9uIHRvIHNldCB1cCBhIGJ5cGFzcyB0dW5uZWwgdG8gdGhl IHByb3RlY3Rvcg0KPiAgICAgICAgIHdpdGhvdXQgcmVseWluZyBvbiBsb2NhbCBjb25maWd1cmF0 aW9uLg0KPg0KPiAgICAgIG8gIEl0IGluZGVudGlmaWVzIHRoZSBwcmltYXJ5IFBFJ3MgbGFiZWwg c3BhY2Ugb24gdGhlIHByb3RlY3Rvci4gIFRoZQ0KPiAgICAgICAgIHByb3RlY3RvciBtYXkgcHJv dGVjdCBQV3MgZm9yIG11bHRpcGxlIHByaW1hcnkgUEVzLiAgRm9yIGVhY2gNCj4gICAgICAgICBw cmltYXJ5IFBFLCBpdCBNVVNUIG1haW50YWluIGEgc2VwYXJhdGUgbGFiZWwgc3BhY2UgdG8gc3Rv cmUgdGhlDQo+ICAgICAgICAgUFcgbGFiZWxzIGFzc2lnbmVkIGJ5IHRoYXQgcHJpbWFyeSBQRS4g IEl0IE1VU1QgYXNzb2NpYXRlIGEgUFcNCj4gICAgICAgICBsYWJlbCB3aXRoIGEgbGFiZWwgc3Bh Y2UgdmlhIHRoZSBjb250ZXh0IGlkZW50aWZpZXIgb2YgdGhlDQo+ICAgICAgICAge3ByaW1hcnkg UEUsIHByb3RlY3Rvcn0sIGFzIGRlc2NyaWJlZCBiZWxvdy4NCj4NCj4gU0I+IElzIHRoaXMgY29u dGV4dCBpZGVudGlmaWVyIGFuIElQIGFkZHJlc3Mgb3IgYW4gTVBMUyBsYWJlbD8gV2hlcmUNCj4g aXMgaXQgY2FycmllZD8NCj4NCj4gW3lzaGVuXSBhIGNvbnRleHQgaWRlbnRpZmllciBpcyBhbiBJ UCBhZGRyZXNzLiBJZiB0aGUgdHVubmVsIGlzIElQIHR1bm5lbCwgaXQgaXMgY2FycmllZCBpbiBJ UCBoZWFkZXIgYXMgZGVzdCBhZGRyZXNzLiBJZiB0aGUgdHVubmVsIGlzIE1QTFMgdHVubmVsLCBp dCBpcyBpbmRpY2F0ZWQgYnkgdGhlIGxhYmVsLg0KPg0KPiAgICAgICAgIEluIGFkZGl0aW9uIHRv IHRoZSBub3JtYWwgTERQIFBXIHNpZ25hbGluZywgdGhlIHByaW1hcnkgUEUgTVVTVA0KPiAgICAg ICAgIGhhdmUgYSB0YXJnZXRlZCBMRFAgc2Vzc2lvbiB3aXRoIHRoZSBwcm90ZWN0b3IsIGFuZCBh ZHZlcnRpc2UgUFcNCj4gICAgICAgICBsYWJlbHMgdG8gdGhlIHByb3RlY3RvciB2aWEgTERQIExh YmVsIE1hcHBpbmcgbWVzc2FnZXMgKFNlZQ0KPg0KPg0KPg0KPiBZaW1pbiBTaGVuLCBldCBhbC4g ICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSAxMV0NCj4N Cj4NCj4gSW50ZXJuZXQtRHJhZnQgICAgIFBXIEVuZHBvaW50IEZhc3QgRmFpbHVyZSBQcm90ZWN0 aW9uICAgICAgICAgSnVseSAyMDE0DQo+DQo+DQo+ICAgICAgICAgU2VjdGlvbiA1IGZvciBkZXRh aWwpLiAgVGhlIHByaW1hcnkgUEUgTVVTVCBhdHRhY2ggdGhlIGNvbnRleHQNCj4gICAgICAgICBp ZGVudGlmaWVyIHRvIGVhY2ggbWVzc2FnZS4gIFVwb24gcmVjZWl2aW5nIHRoZSBtZXNzYWdlLCB0 aGUNCj4gICAgICAgICBwcm90ZWN0b3IgTVVTVCBpbnN0YWxsIHRoZSBhZHZlcnRpc2VkIFBXIGxh YmVsIGluIHRoZSBsYWJlbCBzcGFjZQ0KPiAgICAgICAgIGlkZW50aWZpZWQgYnkgdGhlIGNvbnRl eHQgaWRlbnRpZmllci4NCj4NCj4gU0I+IEkgYW0gY3VycmVudGx5IGNvbmZ1c2VkIGFib3V0IGhv dyBhIGRhdGEgcGFja2V0IGNhcnJpZXMgdGhlIFBXDQo+IGxhYmVsIHByb3ZpZGVkIGJ5IGFub3Ro ZXIgUEUuDQo+DQo+ICAgICAgICAgV2hlbiBhIFBMUiBzZXRzIHVwIG9yIHJlc29sdmUgYSBieXBh c3MgdHVubmVsIHRvIHRoZSBwcm90ZWN0b3IsIGl0DQo+ICAgICAgICAgTVVTVCBzZXQgdGhlIGRl c3RpbmF0aW9uIHRvIHRoZSBjb250ZXh0IGlkZW50aWZpZXIsIHJhdGhlciB0aGFuIGENCj4gICAg ICAgICBwcml2YXRlIElQIGFkZHJlc3Mgb2YgdGhlIHByb3RlY3Rvci4gIE9uY2UgZXN0YWJsaXNo ZWQsIHRoZSBieXBhc3MNCj4gICAgICAgICB0dW5uZWwsIHdpdGggZWl0aGVyIGl0cyBNUExTIGxh YmVsIG9yIElQIHR1bm5lbCBkZXN0aW5hdGlvbg0KPiAgICAgICAgIGFkZHJlc3MsIGlzIHVzZWQg YXMgdGhlIGlkZW50aWZpZXIgb2YgbGFiZWwgc3BhY2UuICBPbiB0aGUNCj4gICAgICAgICBwcm90 ZWN0b3IsIGFsbCBQVyBwYWNrZXRzIHJlY2VpdmVkIG9uIHRoZSBieXBhc3MgdHVubmVsIE1VU1Qg YmUNCj4gICAgICAgICBmb3J3YXJkZWQgYmFzZWQgb24gYSBsYWJlbCBsb29rdXAgaW4gdGhhdCBs YWJlbCBzcGFjZS4NCj4NCj4gU0I+IEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIGRhdGEgcGxhbmUg c3RydWN0dXJlIHRoYXQgdGhlIGFib3ZlIHNlbnRlbmNlDQo+IGlzIGRlc2NyaWJpbmcuDQo+DQo+ IFt5c2hlbl0gVGhpcyBpcyBiYXNpY2FsbHkgdGhlIGNvbnRleHQgbGFiZWwgZm9yd2FyZGluZyBw YXJhZGlnbSAoUkZDIDUzMzEpLiBGcm9tIHRoZSBwcm90ZWN0b3IncyBwZXJzcGVjdGl2ZSwgdGhl IGJ5cGFzcyB0dW5uZWwgc2VydmVzIGFzIGEgY29udGV4dCwgYW5kIGluZGljYXRlcyB0aGUgbGFi ZWwgc3BhY2Ugb2YgdGhlIHByaW1hcnkgUEUgd2hlcmUgdGhlIFBXIGxhYmVsIG11c3QgYmUgbG9v a2VkIHVwLg0KPg0KPg0KPiA0LjIuMi4gIEFkdmVydGlzZW1lbnQgYW5kIFBhdGggQ29tcHV0YXRp b24NCj4NCj4gICAgICBVc2luZyBhIGNvbnRleHQgaWRlbnRpZmllciBhcyBkZXN0aW5hdGlvbiBm b3IgYm90aCB0cmFuc3BvcnQgdHVubmVsDQo+ICAgICAgYW5kIGJ5cGFzcyB0dW5uZWwgcmVxdWly ZXMgYm90aCB0aGUgcHJpbWFyeSBQRSBhbmQgdGhlIHByb3RlY3RvciB0bw0KPiAgICAgIGFkdmVy dGlzZSB0aGUgY29udGV4dCBpZGVudGlmaWVyIHZpYSBJR1AgYXMgYW4gSVAgYWRkcmVzcyByZWFj aGFibGUNCj4gICAgICB0aHJvdWdoIGJvdGggcm91dGVycyBpbiByb3V0aW5nIGRvbWFpbiBhbmQv b3IgVEUgZG9tYWluLiAgVGhpcw0KPiAgICAgIGltcG9zZXMgdGhlIGZvbGxvd2luZyByZXF1aXJl bWVudHMgb24gcGF0aCBjb21wdXRhdGlvbiBmb3IgdGhlc2UNCj4gICAgICB0dW5uZWxzLg0KPg0K PiAgICAgIG8gIEZvciB0aGUgdHJhbnNwb3J0IHR1bm5lbCwgdGhlIGluZ3Jlc3MgUEUgTVVTVCBj aG9vc2UgdGhlIHByaW1hcnkNCj4gICAgICAgICBQRSBhcyB0aGUgYWN0dWFsIGVuZHBvaW50Lg0K Pg0KPiAgICAgIG8gIEZvciB0aGUgYnlwYXNzIHR1bm5lbCwgdGhlIFBMUiBNVVNUIGNob29zZSB0 aGUgcHJvdGVjdG9yIGFzIHRoZQ0KPiAgICAgICAgIGFjdHVhbCBlbmRwb2ludC4gIEluIGVncmVz cyAoVC0pUEUgbm9kZSBwcm90ZWN0aW9uIGFuZCBTLVBFIG5vZGUNCj4gICAgICAgICBwcm90ZWN0 aW9uLCB0aGUgYnlwYXNzIHR1bm5lbCBNVVNUIGF2b2lkIHRoZSBwcmltYXJ5IChTLSlQRS4NCj4N Cj4gICAgICBUaGUgZGV0YWlsIG9mIGhvdyB0aGUgcHJpbWFyeSBQRSBhbmQgdGhlIHByb3RlY3Rv ciBtYXkgYWR2ZXJ0aXNlIGENCj4gICAgICBjb250ZXh0IGlkZW50aWZpZXIgaXMgaW5kZXBlbmRl bnQgb2YgdGhpcyBtZWNoYW5pc20gYW5kIG91dCBvZiB0aGUNCj4gICAgICBzY29wZSBvZiB0aGlz IGRvY3VtZW50Lg0KPg0KPiBTQj4gR2l2ZW4gdGhhdCB5b3UgZ2l2ZSBzaWduYWxsaW5nIGRhdGEg c3RydWN0dXJlcyBsYXRlciwgSSBhbSBjb25mdXNlZA0KPiBhcyB0byBob3cgdGhpcyBjYW4gYmUg b3V0IG9mIHNjb3BlIG9mIHRoaXMgdGV4dC4gU3VyZWx5IHRoaXMgaXMgbmVlZGVkDQo+IHRvIGlt cGxlbWVudCBhbiBpbnRlcm9wZXJhYmxlIHNvbHV0aW9uPw0KPg0KPiBbeXNoZW5dIFRoZXJlIGlz IG5vIG5ldyBleHRlbnNpb24gbmVlZGVkIGZvciBJR1AuIEJvdGggUEVzIGFkdmVydGlzZSB0aGUg Y29udGV4dCBJRC4gVGhhdCdzIGl0LiBXaWxsIHJlcGhyYXNlIGl0Lg0KPg0KPiAgICAgIE9uZSBh cHByb2FjaCB3b3VsZCBiZSB0byBhZHZlcnRpc2UgaXQgYXMgYQ0KPiAgICAgIHZpcnR1YWwgcHJv eHkgbm9kZSBjb25uZWN0ZWQgdG8gYm90aCByb3V0ZXJzLCB3aXRoIHRoZSBsaW5rIGJldHdlZW4N Cj4gICAgICB0aGUgcHJveHkgbm9kZSBhbmQgdGhlIHByaW1hcnkgUEUgaGF2aW5nIGEgbW9yZSBw cmVmZXJhYmxlIElHUCBvciBURQ0KPiAgICAgIG1ldHJpYyB0aGFuIHRoZSBsaW5rIGJldHdlZW4g dGhlIHByb3h5IG5vZGUgYW5kIHRoZSBwcm90ZWN0b3IuICBUaGUNCj4gICAgICB1bHRpbWF0ZSBn b2FsIGlzIGZvciBhIHBhdGggY29tcHV0YXRpb24gYWxnb3JpdGhtLCBzdWNoIGFzIENTUEYNCj4g ICAgICAoY29uc3RyYWluZWQgc2hvcnRlc3QgcGF0aCBmaXJzdCksIExGQSAoUkZDIDUyODYpIGFu ZCBNUlQgKFtJUC1MRFAtDQo+ICAgICAgRlJSLU1SVF0pLCB0byBiZSBhYmxlIHRvIGNvbXB1dGUg dGhlIHBhdGhzIHRoYXQgbWVldCB0aGUgYWJvdmUNCj4gICAgICByZXF1aXJlbWVudHMuDQo+DQo+ IDQuMy4gIFByb3RlY3Rpb24gTW9kZWxzDQo+DQo+ICAgICAgVGhlcmUgYXJlIHR3byBwcm90ZWN0 aW9uIG1vZGVscyBiYXNlZCBvbiB0aGUgbG9jYXRpb24gb2YgYSBwcm90ZWN0b3IuDQo+ICAgICAg QSBuZXR3b3JrIE1BWSB1c2UgZWl0aGVyIG1vZGVsLCBvciBhIGNvbWJpbmF0aW9uIG9mIGJvdGgu DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IFlpbWluIFNoZW4sIGV0IGFsLiAgICAgIEV4cGlyZXMg SmFudWFyeSAyNSwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KPg0KPg0KPiBJbnRlcm5l dC1EcmFmdCAgICAgUFcgRW5kcG9pbnQgRmFzdCBGYWlsdXJlIFByb3RlY3Rpb24gICAgICAgICBK dWx5IDIwMTQNCj4NCj4NCj4gNC4zLjEuICBDby1sb2NhdGVkIFByb3RlY3Rvcg0KPg0KPiAgICAg IEluIHRoaXMgbW9kZWwsIHRoZSBwcm90ZWN0b3IgaXMgYSBiYWNrdXAgUEUgdGhhdCBpcyBkaXJl Y3RseQ0KPiAgICAgIGNvbm5lY3RlZCB0byB0aGUgdGFyZ2V0IENFIHZpYSBhIGJhY2t1cCBBQywg b3IgaXQgaXMgYSBiYWNrdXAgUy1QRSBvbg0KPiAgICAgIGEgYmFja3VwIFBXLiAgVGhhdCBpcywg dGhlIHByb3RlY3RvciBpcyBjby1sb2NhdGVkIHdpdGggdGhlIGJhY2t1cA0KPiAgICAgIChTLSlQ RS4gIEV4YW1wbGVzIG9mIHRoaXMgbW9kZWwgaGF2ZSBiZWVuIGludHJvZHVjZWQgaW4gRmlndXJl IDQsDQo+ICAgICAgRmlndXJlIDUgYW5kIEZpZ3VyZSA2IGluIFNlY3Rpb24gNC4xLg0KPg0KPiAg ICAgIEluIGVncmVzcyBBQyBwcm90ZWN0aW9uIGFuZCBlZ3Jlc3MgUEUgbm9kZSBwcm90ZWN0aW9u LCB3aGVuIGENCj4gICAgICBwcm90ZWN0b3IgcmVjZWl2ZXMgdHJhZmZpYyBmcm9tIHRoZSBQTFIs IGl0IGZvcndhcmRzIHRoZSB0cmFmZmljIHRvDQo+ICAgICAgdGhlIENFIHZpYSB0aGUgYmFja3Vw IEFDLiAgVGhpcyBpcyBzaG93biBpbiBGaWd1cmUgNywgd2hlcmUgUEUyIGlzDQo+ICAgICAgdGhl IFBMUiBmb3IgZWdyZXNzIEFDIGZhaWx1cmUsIFAzIGlzIHRoZSBQTFIgZm9yIFBFMiBmYWlsdXJl LCBhbmQgUEU0DQo+ICAgICAgKHRoZSBiYWNrdXAgUEUpIGlzIHRoZSBwcm90ZWN0b3IuDQo+DQo+ ICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tIFBXMSAtLS0tLS0tLS0tLS0tLS0+ fA0KPg0KPiAgICAgICAgICAgICAgICAtIFBFMSAtLS0tLS0tLS0tLS0tLSBQMSAtLS0tLS0tIFAz IC0tLS0tIFBFMiAtLS0tDQo+ICAgICAgICAgICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBQTFIgXCAgICAgUExSICAgICBcDQo+ICAgICAgICAgICAgICAvICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFwgICAgIHwgICAgICAgXA0KPiAgICAgICAgICAgQ0Ux ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnlwYXNzXCAgICB8YnlwYXNzICBDRTIN Cj4gICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc ICAgfCAgICAgICAvDQo+ICAgICAgICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFwgIHwgICAgICAvDQo+ICAgICAgICAgICAgICAgIC0gUEUzIC0tLS0tLS0t LS0tLS0tIFAyIC0tLS0tLS0tLS0tLS0tLS0gUEU0IC0tLS0NCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3RlY3Rvcg0KPg0KPiAgICAgICAgICAg ICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLSBQVzIgLS0tLS0tLS0tLS0tLS0tPnwNCj4NCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNw0KPg0KPiAgICAgIEluIFMt UEUgbm9kZSBwcm90ZWN0aW9uLCB3aGVuIGEgcHJvdGVjdG9yIHJlY2VpdmVzIHRyYWZmaWMgZnJv bSB0aGUNCj4gICAgICBQTFIsIGl0IE1VU1QgZm9yd2FyZCB0aGUgdHJhZmZpYyB2aWEgdGhlIG5l eHQgc2VnbWVudCBvZiB0aGUgYmFja3VwDQo+ICAgICAgUFcuICBUaGUgVC1QRSBvZiB0aGUgYmFj a3VwIFBXIE1VU1QgaW4gdHVybiBmb3J3YXJkIHRoZSB0cmFmZmljIHRvDQo+ICAgICAgdGhlIENF IHZpYSBhIGJhY2t1cCBBQy4gIFRoaXMgaXMgc2hvd24gaW4gRmlndXJlIDgsIHdoZXJlIFA0IGlz IHRoZQ0KPiAgICAgIFBMUiBmb3IgU1BFMSBmYWlsdXJlLCBhbmQgU1BFMiAodGhlIGJhY2t1cCBT LVBFKSBpcyB0aGUgcHJvdGVjdG9yIGZvcg0KPiAgICAgIFNQRTEuDQo+DQo+DQo+DQo+DQo+DQo+ DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IFlpbWluIFNoZW4sIGV0IGFsLiAgICAg IEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KPg0KPg0K PiBJbnRlcm5ldC1EcmFmdCAgICAgUFcgRW5kcG9pbnQgRmFzdCBGYWlsdXJlIFByb3RlY3Rpb24g ICAgICAgICBKdWx5IDIwMTQNCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0t LS0tLS0tLSBQVzEgLS0tLS0tLS0tLS0tLS0tPnwNCj4gICAgICAgICAgICAgICAgICAgICB8PC0t LS0tIFNFRzEgLS0tLS0+fDwtLS0tLSBTRUcyIC0tLS0tPnwNCj4NCj4gICAgICAgICAgICAgICAg LSBUUEUxIC0tLS0tIFA0ICAtLS0tLSBTUEUxIC0tLS0tLS0tLS0tLS0tIFRQRTIgLQ0KPiAgICAg ICAgICAgICAgIC8gICAgICAgICAgICAgUExSIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXA0KPiAgICAgICAgICAgICAgLyAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFwNCj4gICAgICAgICAgIENFMSAgICAgICAgICAgICAgIGJ5cGFzc1wg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ0UyDQo+ICAgICAgICAgICAgICBcICAgICAg ICAgICAgICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KPiAgICAgICAg ICAgICAgIFwgICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAg Lw0KPiAgICAgICAgICAgICAgICAtIFRQRTMgLS0tLS0tLS0tLS0tLS0tIFNQRTIgLS0tLS0tLS0t LS0tLS0gVFBFNCAtDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcm90ZWN0b3IN Cj4NCj4gICAgICAgICAgICAgICAgICAgICB8PC0tLS0tIFNFRzMgLS0tLS0+fDwtLS0tLSBTRUc0 IC0tLS0tPnwNCj4gICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLSBQVzIgLS0t LS0tLS0tLS0tLS0tPnwNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG aWd1cmUgOA0KPg0KPiAgICAgIEluIHRoZSBjby1sb2NhdGVkIHByb3RlY3RvciBtb2RlbCwgdGhl IG51bWJlciBvZiBjb250ZXh0IGlkZW50aWZpZXJzDQo+ICAgICAgbmVlZGVkIGJ5IGEgbmV0d29y ayBpcyB0aGUgbnVtYmVyIG9mIGRpc3RpbmN0IHtwcmltYXJ5IFBFLCBiYWNrdXAgUEV9DQo+ICAg ICAgcGFpcnMuICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBzY2FsYWJpbGl0eSwgdGhlIG1vZGVs IGlzIHN1aXRhYmxlDQo+ICAgICAgZm9yIG5ldHdvcmtzIHdoZXJlIHRoZSBudW1iZXIgb2YgYmFj a3VwIFBFcyBmb3IgYW55IGdpdmVuIHByaW1hcnkgUEUNCj4gICAgICBpcyByZWxhdGl2ZWx5IHNt YWxsLg0KPg0KPiA0LjMuMi4gIENlbnRyYWxpemVkIFByb3RlY3Rvcg0KPg0KPiAgICAgIEluIHRo aXMgbW9kZWwsIHRoZSBwcm90ZWN0b3IgaXMgYSBkZWRpY2F0ZWQgUCByb3V0ZXIgb3IgUEUgcm91 dGVyDQo+ICAgICAgdGhhdCBzZXJ2ZXMgdGhlIHJvbGUuICBJbiBlZ3Jlc3MgQUMgcHJvdGVjdGlv biBhbmQgZWdyZXNzIFBFIG5vZGUNCj4gICAgICBwcm90ZWN0aW9uLCB0aGUgcHJvdGVjdG9yIE1B WSBvciBNQVkgTk9UIGJlIGEgYmFja3VwIFBFIHdpdGggYSBkaXJlY3QNCj4gICAgICBjb25uZWN0 aW9uIHRvIHRoZSB0YXJnZXQgQ0UuICBJbiBTLVBFIG5vZGUgcHJvdGVjdGlvbiwgdGhlIHByb3Rl Y3Rvcg0KPiAgICAgIE1BWSBvciBNQVkgTk9UIGJlIGEgYmFja3VwIFMtUEUgb24gdGhlIGJhY2t1 cCBQVy4NCj4NCj4gICAgICBJbiBlZ3Jlc3MgQUMgcHJvdGVjdGlvbiBhbmQgZWdyZXNzIFBFIG5v ZGUgcHJvdGVjdGlvbiwgd2hlbiB0aGUNCj4gICAgICBwcm90ZWN0b3IgcmVjZWl2ZXMgdHJhZmZp YyBmcm9tIHRoZSBQTFIsIGlmIHRoZSBwcm90ZWN0b3IgaGFzIGENCj4gICAgICBkaXJlY3QgY29u bmVjdGlvbiAoaS5lLiBiYWNrdXAgQUMpIHRvIHRoZSBDRSwgaXQgTVVTVCBmb3J3YXJkIHRoZQ0K PiAgICAgIHRyYWZmaWMgdG8gdGhlIENFIHZpYSB0aGUgYmFja3VwIEFDLCB3aGljaCBpcyBzaW1p bGFyIHRvIEZpZ3VyZSA3Lg0KPiAgICAgIE90aGVyd2lzZSwgaXQgTVVTVCBmb3J3YXJkIHRoZSB0 cmFmZmljIHRvIGEgYmFja3VwIFBFLCB3aGljaCBNVVNUDQo+ICAgICAgdGhlbiBmb3J3YXJkIHRo ZSB0cmFmZmljIHRvIHRoZSBDRSB2aWEgYSBiYWNrdXAgQUMuICBUaGlzIGlzIHNob3duIGluDQo+ ICAgICAgRmlndXJlIDksIHdoZXJlIHRoZSBwcm90ZWN0b3IgcmVjZWl2ZXMgdHJhZmZpYyBmcm9t IFAzICh0aGUgUExSIGZvcg0KPiAgICAgIGVncmVzcyBQRSBmYWlsdXJlKSBvciBQRTIgKHRoZSBQ TFIgZm9yIGVncmVzcyBBQyBmYWlsdXJlKSBhbmQNCj4gICAgICBmb3J3YXJkcyB0aGUgdHJhZmZp YyB0byBQRTQgKHRoZSBiYWNrdXAgUEUpLiAgVGhlIHByb3RlY3RvciBtYXkgYmUNCj4gICAgICBw cm90ZWN0aW5nIG90aGVyIFBXcyBhcyB3ZWxsLCB3aGljaCBpcyBub3Qgc2hvd24gaW4gdGhpcyBm aWd1cmUgZm9yDQo+ICAgICAgY2xhcml0eS4NCj4NCj4gU0I+IElmIHlvdSBhcmUgZ29pbmcgdG8g Y292ZXIgdGhlIHNoYXJlZCBjYXNlLCBJIHRoaW5rIHlvdSBuZWVkIHRvDQo+IG1ha2UgaXQgbXVj aCBjbGVhcmVyIGhvdyB0aGUgUFdzIGFyZSBpZGVudGlmaWVkIGZyb20gdGhlIHJlY2VpdmVkDQo+ IGRhdGEgcGFja2V0cy4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gWWltaW4gU2hlbiwgZXQg YWwuICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgMTRd DQo+DQo+DQo+IEludGVybmV0LURyYWZ0ICAgICBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJv dGVjdGlvbiAgICAgICAgIEp1bHkgMjAxNA0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIHw8 LS0tLS0tLS0tLS0tLSBQVzEgLS0tLS0tLS0tLS0tLS0tPnwNCj4NCj4gICAgICAgICAgICAgICAg IC0gUEUxIC0tLS0tLS0tLS0tLS0gUDEgLS0tLS0tLSBQMyAtLS0tLSBQRTIgLS0NCj4gICAgICAg ICAgICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBMUiBcICAgICBQTFIgICBc DQo+ICAgICAgICAgICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwg ICAgIC8gICAgIFwNCj4gICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGJ5cGFzc1wgICAvYnlwYXNzIFwNCj4gICAgICAgICAgICAgLyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBcIC8gICAgICAgICBcDQo+ICAgICAgICAgIENFMSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJvdGVjdG9yICAgICAgIENFMg0KPiAg ICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcICAg ICAgICAgIC8NCj4gICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFwgICAgICAgIC8NCj4gICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBcICAgICAgLw0KPiAgICAgICAgICAgICAgICBcICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcICAgIC8NCj4gICAgICAgICAgICAg ICAgIC0gUEUzIC0tLS0tLS0tLS0tLS0gUDIgLS0tLS0tLS0tLS0tLS0tLS1QRTQgLS0NCj4NCj4g ICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0gUFcyIC0tLS0tLS0tLS0tLS0tLT58 DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDkNCj4NCj4g ICAgICBJbiBTLVBFIG5vZGUgcHJvdGVjdGlvbiwgd2hlbiB0aGUgcHJvdGVjdG9yIHJlY2VpdmVz IHRyYWZmaWMgZnJvbSB0aGUNCj4gICAgICBQTFIsIGlmIHRoZSBwcm90ZWN0b3IgaXMgYSBiYWNr dXAgUy1QRSBvZiB0aGUgYmFja3VwIFBXLCBpdCBNVVNUDQo+ICAgICAgZm9yd2FyZCB0aGUgdHJh ZmZpYyB2aWEgdGhlIG5leHQgc2VnbWVudCBvZiB0aGUgYmFja3VwIFBXLCBhbmQgdGhlDQo+ICAg ICAgVC1QRSBvZiB0aGUgYmFja3VwIFBXIE1VU1QgZm9yd2FyZCB0aGUgdHJhZmZpYyB0byB0aGUg Q0UgdmlhIGEgYmFja3VwDQo+ICAgICAgQUMsIHdoaWNoIGlzIHNpbWlsYXIgdG8gRmlndXJlIDgu ICBPdGhlcndpc2UsIHRoZSBwcm90ZWN0b3IgTVVTVA0KPiAgICAgIGZpcnN0IGZvcndhcmQgdGhl IHRyYWZmaWMgdG8gdGhlIGJhY2t1cCBTLVBFLCB3aGljaCBNVVNUIHRoZW4gZm9yd2FyZA0KPiAg ICAgIHRoZSB0cmFmZmljIHZpYSB0aGUgbmV4dCBzZWdtZW50IG9mIHRoZSBiYWNrdXAgUFcuICBG aW5hbGx5LCB0aGUgVC1QRQ0KPiAgICAgIG9mIHRoZSBiYWNrdXAgUFcgTVVTVCBmb3J3YXJkIHRo ZSB0cmFmZmljIHRvIHRoZSBDRSB2aWEgYSBiYWNrdXAgQUMuDQo+ICAgICAgVGhpcyBpcyBzaG93 biBpbiBGaWd1cmUgMTAsIHdoZXJlIHRoZSBwcm90ZWN0b3IgZm9yd2FyZHMgdHJhZmZpYyB0bw0K PiAgICAgIFNQRTIgKHRoZSBiYWNrdXAgUy1QRSksIFNQRTIgZm9yd2FyZHMgdGhlIHRyYWZmaWMg dG8gVFBFNCB2aWEgU0VHNCwNCj4gICAgICBhbmQgVFBFNCBmaW5hbGx5IGZvcndhcmRzIHRyYWZm aWMgdG8gQ0UyLiAgVGhlIHByb3RlY3RvciBtYXkgYmUNCj4gICAgICBwcm90ZWN0aW5nIG90aGVy IFBXIHNlZ21lbnRzIGFzIHdlbGwsIHdoaWNoIGlzIG5vdCBzaG93biBpbiB0aGlzDQo+ICAgICAg ZmlndXJlIGZvciBjbGFyaXR5Lg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0K Pg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPiBZaW1pbiBTaGVuLCBldCBhbC4gICAgICBFeHBpcmVz IEphbnVhcnkgMjUsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSAxNV0NCj4NCj4NCj4gSW50ZXJu ZXQtRHJhZnQgICAgIFBXIEVuZHBvaW50IEZhc3QgRmFpbHVyZSBQcm90ZWN0aW9uICAgICAgICAg SnVseSAyMDE0DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0g UFcxIC0tLS0tLS0tLS0tLS0tLT58DQo+ICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLSBTRUcx IC0tLS0tPnw8LS0tLS0gU0VHMiAtLS0tLT58DQo+DQo+ICAgICAgICAgICAgICAgIC0gVFBFMSAt LS0tLSBQNCAgLS0tLS0gU1BFMSAtLS0tLS0tLS0tLS0tLSBUUEUyIC0NCj4gICAgICAgICAgICAg ICAvICAgICAgICAgICAgIFBMUiBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4g ICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBcDQo+ICAgICAgICAgICAgIC8gICAgICAgICAgICAgICBieXBhc3NcICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFwNCj4gICAgICAgICAgICAvICAgICAgICAgICAgICAgICAg ICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4gICAgICAgICBDRTEgICAg ICAgICAgICAgICAgICAgICBwcm90ZWN0b3IgICAgICAgICAgICAgICAgICAgICAgICAgICBDRTIN Cj4gICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC8NCj4gICAgICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgIFwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KPiAgICAgICAgICAgICAgXCAgICAgICAgICAg ICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgIC8NCj4gICAgICAgICAgICAg ICBcICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgIC8NCj4g ICAgICAgICAgICAgICAgLSBUUEUzIC0tLS0tLS0tLS0tLS0tLSBTUEUyIC0tLS0tLS0tLS0tLS0t IFRQRTQgLQ0KPg0KPiAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0gU0VHMyAtLS0tLT58PC0t LS0tIFNFRzQgLS0tLS0+fA0KPiAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0t IFBXMiAtLS0tLS0tLS0tLS0tLS0+fA0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEZpZ3VyZSAxMA0KPg0KPiAgICAgIFRoZSBjZW50cmFsaXplZCBwcm90ZWN0b3IgbW9k ZWwgcHJvdmlkZXMgdGhlIGNvbnZlbmllbmNlIGZvciBtdWx0aXBsZQ0KPiAgICAgIHByaW1hcnkg UEVzIHRvIHNoYXJlIG9uZSBwcm90ZWN0b3IuICBFYWNoIHByaW1hcnkgUEUgTUFZIG9ubHkgbmVl ZA0KPiAgICAgIHRoZSBvbmUgcHJvdGVjdG9yIHRvIHByb3RlY3QgYWxsIG9mIGl0cyBQV3MuICBG cm9tIHRoZSBwZXJzcGVjdGl2ZSBvZg0KPiAgICAgIHNjYWxhYmlsaXR5LCB0aGUgbnVtYmVyIG9m IGNvbnRleHQgaWRlbnRpZmllcnMgbmVlZGVkIGJ5IGEgbmV0d29yaw0KPiAgICAgIE1BWSBiZSBi b3VuZCB0byB0aGUgbnVtYmVyIG9mIHByaW1hcnkgUEVzLg0KPg0KPiA0LjQuICBUcmFuc3BvcnQg VHVubmVsDQo+DQo+ICAgICAgVGhlIGluZ3Jlc3MgUEUgb2YgYSBwcmltYXJ5IFBXIGFzc29jaWF0 ZXMgdGhlIFBXIHdpdGggdGhlIHByaW1hcnkNCj4gICAgICBlZ3Jlc3MgUEUgdGhyb3VnaCBMRFAg c2lnbmFsaW5nLiAgSW4gYWRkaXRpb24sIGFzIG1lbnRpb25lZCBpbg0KPiAgICAgIFNlY3Rpb24g NC4yLjEsIHRoZSBpbmdyZXNzIFBFIE1VU1QgYXNzb2NpYXRlIHRoZSB0cmFuc3BvcnQgdHVubmVs IG9mDQo+ICAgICAgdGhlIFBXIHdpdGggdGhlIGNvbnRleHQgaWRlbnRpZmllciBvZiB0aGUge3By aW1hcnkgUEUsIHByb3RlY3Rvcn0sDQo+ICAgICAgYW5kIHNldCB1cCBvciByZXNvbHZlIHRoZSB0 cmFuc3BvcnQgdHVubmVsIGJ5IHVzaW5nIHRoZSBjb250ZXh0DQo+ICAgICAgaWRlbnRpZmllciBh cyBkZXN0aW5hdGlvbi4gIFRoaXMgbm90IG9ubHkgZW5zdXJlcyB0aGF0IFBXIHRyYWZmaWMgYmUN Cj4gICAgICB0cmFuc3BvcnRlZCB0byB0aGUgcHJpbWFyeSBQRSwgYnV0IGFsc28gZmFjaWxpdGF0 ZXMgYnlwYXNzIHR1bm5lbA0KPiAgICAgIGVzdGFibGlzaG1lbnQgYXQgUExSKHMpLCBhcyB0aGUg Y29udGV4dCBpZGVudGlmaWVyIGltcGxpZXMgdGhlDQo+ICAgICAgaWRlbnRpdHkgb2YgdGhlIHBy b3RlY3RvciBhcyB3ZWxsLiAgVGhpcyBpcyBhbHNvIHRoZSBjYXNlIGZvciBhDQo+ICAgICAgbXVs dGktc2VnbWVudCBQVywgd2hlcmUgdGhlIGluZ3Jlc3MgUEUgYW5kIGVncmVzcyBQRSBhcmUgVC9T LVBFcy4NCj4NCj4gICAgICBUaGUgYXNzb2NpYXRpb24gYmV0d2VlbiB0aGUgdHJhbnNwb3J0IHR1 bm5lbCBhbmQgdGhlIGNvbnRleHQNCj4gICAgICBpZGVudGlmaWVyIGF0IHRoZSBpbmdyZXNzIFBF IE1BWSBiZSBhY2hpZXZlZCBieSBjb25maWd1cmF0aW9uIG9yIGFuDQo+ICAgICAgYXV0by1kaXNj b3ZlcnkgbWVjaGFuaXNtLiAgSW4gdGhlIGxhdGVyIGNhc2UsIHRoZSBpbmdyZXNzIFBFIE1BWQ0K PiAgICAgIGxlYXJuIHRoZSBjb250ZXh0IGlkZW50aWZpZXIgZnJvbSB0aGUgcHJpbWFyeSAoZWdy ZXNzKSBQRSwgaWYgdGhlDQo+ICAgICAgcHJpbWFyeSBQRSBhZHZlcnRpc2VzIHRoZSBjb250ZXh0 IGlkZW50aWZpZXIgYXMgInRoaXJkIHBhcnR5IG5leHQNCj4gICAgICBob3AiIGluIElQdjQvdjYg SW50ZXJmYWNlX0lEICAoUkZDIDM0NzEsIFJGQyAzNDcyKSBpbiB0aGUgTERQDQo+ICAgICAgTGFi ZWwgTWFwcGluZyBtZXNzYWdlIG9mIHRoZSBwcmltYXJ5IFBXLg0KPg0KPg0KPg0KPg0KPg0KPiBZ aW1pbiBTaGVuLCBldCBhbC4gICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTUgICAgICAgICAg ICAgICBbUGFnZSAxNl0NCj4NCj4NCj4gSW50ZXJuZXQtRHJhZnQgICAgIFBXIEVuZHBvaW50IEZh c3QgRmFpbHVyZSBQcm90ZWN0aW9uICAgICAgICAgSnVseSAyMDE0DQo+DQo+DQo+IDQuNS4gIEJ5 cGFzcyBUdW5uZWwNCj4NCj4gICAgICBBIFBMUiBtYXkgcHJvdGVjdCBtdWx0aXBsZSBQV3MgYXNz b2NpYXRlZCB3aXRoIG9uZSBvciBtdWx0aXBsZSBwYWlycw0KPiAgICAgIG9mIHtwcmltYXJ5IFBF LCBwcm90ZWN0b3J9LiBUaGUgUExSIE1VU1QgZXN0YWJsaXNoIGEgYnlwYXNzIHR1bm5lbCB0bw0K PiAgICAgIGVhY2ggcHJvdGVjdG9yIGZvciBlYWNoIGRpc3RpbmN0IGNvbnRleHQgaWRlbnRpZmll ciBhc3NvY2lhdGVkIHdpdGgNCj4gICAgICB0aGF0IHByb3RlY3Rvci4gIFRoZSBkZXN0aW5hdGlv biBvZiB0aGUgYnlwYXNzIHR1bm5lbCBNVVNUIGJlIHRoZQ0KPiAgICAgIGNvbnRleHQgaWRlbnRp ZmllciAoU2VjdGlvbiA0LjIuMSkuICBUaGUgUExSIG1heSBkZXJpdmUgdGhlIGNvbnRleHQNCj4g ICAgICBpZGVudGlmaWVyIGZyb20gdGhlIGRlc3RpbmF0aW9uIG9mIHRoZSB0cmFuc3BvcnQgdHVu bmVsIHRoYXQNCj4gICAgICB0cmF2ZXJzZXMgaXQuDQo+DQo+ICAgICAgRm9yIGV4YW1wbGVzLCBp biBGaWd1cmUgNyBhbmQgRmlndXJlIDksIGEgYnlwYXNzIHR1bm5lbCBpcw0KPiAgICAgIGVzdGFi bGlzaGVkIGZyb20gUEUyIChQTFIgZm9yIGVncmVzcyBBQyBmYWlsdXJlKSB0byB0aGUgcHJvdGVj dG9yLA0KPiAgICAgIGFuZCBhbm90aGVyIGJ5cGFzcyB0dW5uZWwgaXMgZXN0YWJsaXNoZWQgZnJv bSBQMyAoUExSIGZvciBlZ3Jlc3Mgbm9kZQ0KPiAgICAgIGZhaWx1cmUpIHRvIHRoZSBwcm90ZWN0 b3IuICBJbiBGaWd1cmUgOCBhbmQgRmlndXJlIDEwLCBhIGJ5cGFzcw0KPiAgICAgIHR1bm5lbCBp cyBlc3RhYmxpc2hlZCBmcm9tIFA0IChQTFIgZm9yIFMtUEUgZmFpbHVyZSkgdG8gdGhlDQo+ICAg ICAgcHJvdGVjdG9yLg0KPg0KPiAgICAgIER1cmluZyBsb2NhbCByZXBhaXIsIHRoZSBQTFIgcmVy b3V0ZXMgdHJhZmZpYyB0byB0aGUgcHJvdGVjdG9yDQo+ICAgICAgdGhyb3VnaCBhIGJ5cGFzcyB0 dW5uZWwgd2l0aCBQVyBsYWJlbCBpbnRhY3QgaW4gdGhlIHBhY2tldHMuICBUaGlzDQo+ICAgICAg bm9ybWFsbHkgaW52b2x2ZXMgcHVzaGluZyBhIGxhYmVsIHRvIHRoZSBsYWJlbCBzdGFjaywgaWYg dGhlIGJ5cGFzcw0KPiAgICAgIHR1bm5lbCBpcyBhbiBNUExTIHR1bm5lbCwgb3IgcHVzaGluZyBh biBJUCBoZWFkZXIgdG8gdGhlIHBhY2tldHMsIGlmDQo+ICAgICAgdGhlIGJ5cGFzcyB0dW5uZWwg aXMgYW4gSVAgdHVubmVsLg0KPg0KPiBTQj4gU3VyZWx5IGl0IGlzIG5vcm1hbGx5IGEgc3dhcD8N Cj4NCj4gW3lzaGVuXSB5ZXMsIHRoaXMgaXMganVzdCBhIGxhYmVsIHN3YXAgb2YgdGhlIHRvcCBs YWJlbCwgZnJvbSB0dW5uZWwgbGFiZWwgdG8gYnlwYXNzIHR1bm5lbCBsYWJlbC4NCj4NCj4gU0I+ IEkgYW0gc29tZXdoYXQgY29uZnVzZWQgYWJvdXQgd2hhdCB0aGlzIGFsbCBsb29rcyBsaWtlIHdo ZW4gdGhpcyBpcw0KPiBJUC4gVGhlIG9ubHkgUFMvSVAgb3RoZXIgdGhhbiBmb3IgU0FUT1AgYXJl IGRlZmluZWQgYnkgTDJUUHYzIFdHLg0KPiBUaGVyZSBpcyBubyBJUCBNUy1QVyBkZWZpbml0aW9u IHRoYXQgSSBhbSBhd2FyZSBvZi4gSSB0aGluayB5b3UgbmVlZA0KPiB0byBiZSBtdWNoIGNsZWFy ZXIgYWJvdXQgd2hhdCBpcyBnb2luZyBvbiB3aGVuIHlvdSBkaXNjdXNzIFBXIG92ZXIgSVANCj4g ZWdyZXNzIHJlcGFpci4NCj4NCj4gICAgICBUaGUgcHJvdGVjdG9yIE1VU1QgaW4gdHVybg0KPiAg ICAgIGZvcndhcmQgdGhlIHRyYWZmaWMgYmFzZWQgb24gdGhlIFBXIGxhYmVsLiAgVG8gYWNoaWV2 ZSBzdWNoIGtpbmQgb2YNCj4gICAgICBmb3J3YXJkaW5nLCB0aGUgcHJvdGVjdG9yIE1VU1QgcmVs eSBvbiB0aGUgYnlwYXNzIHR1bm5lbCBhcyBhIGNvbnRleHQNCj4gICAgICB0byBkZXRlcm1pbmUg dGhlIHByaW1hcnkgUEUncyBsYWJlbCBzcGFjZS4gIElmIHRoZSBieXBhc3MgdHVubmVsIGlzDQo+ ICAgICAgYW4gTVBMUyB0dW5uZWwsIHRoZSBwcm90ZWN0b3IgTVVTVCBoYXZlIGFzc2lnbmVkIGEg bm9uLXJlc2VydmVkIGxhYmVsDQo+ICAgICAgdG8gdGhlIGJ5cGFzcyB0dW5uZWwgZHVyaW5nIHRo ZSBlc3RhYmxpc2htZW50IG9mIHRoZSBieXBhc3MgdHVubmVsLA0KPiAgICAgIGFuZCBoZW5jZSB0 aGlzIGxhYmVsIGNhbiBzZXJ2ZSBhcyB0aGUgY29udGV4dC4gIElmIHRoZSBieXBhc3MgdHVubmVs DQo+ICAgICAgaXMgYW4gSVAgdHVubmVsLCB0aGUgcHJvdGVjdG9yIGNhbiBzaW1wbHkgcmVseSBv biB0aGUgY29udGV4dA0KPiAgICAgIGlkZW50aWZpZXIgY2FycmllZCBhcyB0aGUgZGVzdGluYXRp b24gYWRkcmVzcyBpbiBJUCBoZWFkZXIuDQo+DQo+ICAgICAgQSBieXBhc3MgdHVubmVsIE1VU1Qg aGF2ZSB0aGUgcHJvcGVydHkgdGhhdCBpdCBpcyBub3QgYWZmZWN0ZWQgYnkgdGhlDQo+ICAgICAg dG9wb2xvZ3kgY2hhbmdlcyBjYXVzZWQgYnkgdGhlIGZhaWx1cmUuICBUaGVyZWZvcmUsIGl0IGNh biBiZSB1c2VkIHRvDQo+ICAgICAgdHJhbnNtaXQgdHJhZmZpYyBmb3IgbG9jYWwgcmVwYWlyLiAg SXQgU0hPVUxEIHJlbWFpbiBlZmZlY3RpdmUsIHVudGlsDQo+ICAgICAgdGhlIHRyYWZmaWMgaXMg bW92ZWQgdG8gYW5vdGhlciBmdWxseSBmdW5jdGlvbmFsIGVncmVzcyBBQywgUFcgYW5kL29yDQo+ ICAgICAgdHJhbnNwb3J0IHR1bm5lbC4NCj4NCj4gNC42LiAgRm9yd2FyZGluZyBTdGF0ZSBvbiBQ cm90ZWN0b3INCj4NCj4gICAgICBBIHByb3RlY3RvciBNVVNUIGxlYXJuIFBXIGxhYmVscyBmcm9t IGFsbCB0aGUgcHJpbWFyeSBQRXMgdGhhdCBpdA0KPiAgICAgIHByb3RlY3RzIChTZWN0aW9uIDUu MiksIGFuZCBtYWludGFpbiB0aGUgUFcgbGFiZWxzIGluIHJlc3BlY3RpdmUNCj4gICAgICBsYWJl bCBzcGFjZXMgb2YgdGhlIHByaW1hcnkgUEVzLiAgSW4gdGhlIGNvbnRyb2wgcGxhbmUsIGEgbGFi ZWwgc3BhY2UNCj4gICAgICBpcyBpZGVudGlmaWVkIGJ5IHRoZSBjb250ZXh0IGlkZW50aWZpZXIg b2YgYSBwYWlyIG9mIHtwcmltYXJ5IFBFLA0KPiAgICAgIHByb3RlY3Rvcn0uIEluIHRoZSBmb3J3 YXJkaW5nIHBsYW5lLCBpdCBpcyBpbmRpY2F0ZWQgYnkgdGhlIGJ5cGFzcw0KPiAgICAgIHR1bm5l bChzKSBkZXN0aW5lZCBmb3IgdGhlIGNvbnRleHQgaWRlbnRpZmllci4NCj4NCj4gU0I+IEFyZSB5 b3Ugc2F5aW5nIHRoYXQgdGhpcyBtZWNoYW5pc20gbWFuZGF0ZXMgbm8gUEhQPw0KPg0KPiBbeXNo ZW5dIEl0IG1hbmRhdGVzIFBIUCBmb3IgYnlwYXNzIHR1bm5lbHMgb25seSwgYXMgdGhlaXIgbGFi ZWxzIHNlcnZlIGFzIGNvbnRleHRzIG9uIHByb3RlY3RvcnMuIFRoaXMgaXMgbm90IG1hbmRhdG9y eSBmb3Igbm9ybWFsIHR1bm5lbHMuDQo+DQo+DQo+DQo+DQo+IFlpbWluIFNoZW4sIGV0IGFsLiAg ICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KPg0K Pg0KPiBJbnRlcm5ldC1EcmFmdCAgICAgUFcgRW5kcG9pbnQgRmFzdCBGYWlsdXJlIFByb3RlY3Rp b24gICAgICAgICBKdWx5IDIwMTQNCj4NCj4NCj4gNC42LjEuICBFeGFtcGxlcyBvZiBDby1sb2Nh dGVkIFByb3RlY3Rvcg0KPg0KPiAgICAgIEluIEZpZ3VyZSA3LCBQRTQgaXMgYSBjby1sb2NhdGVk IHByb3RlY3RvciB0aGF0IHByb3RlY3RzIFBXMSBhZ2FpbnN0DQo+ICAgICAgZWdyZXNzIEFDIGZh aWx1cmUgYW5kIGVncmVzcyBub2RlIGZhaWx1cmUuICBJdCBtYWludGFpbnMgYSBsYWJlbA0KPiAg ICAgIHNwYWNlIGZvciBQRTIsIHdoaWNoIGlzIGlkZW50aWZpZWQgYnkgdGhlIGNvbnRleHQgaWRl bnRpZmllciBvZiB7UEUyLA0KPiAgICAgIFBFNH0uIEl0IGxlYXJucyBQVzEncyBsYWJlbCBmcm9t IFBFMiwgYW5kIGluc3RhbGxzIGFuIGZvcndhcmRpbmcNCj4gICAgICBlbnRyeSBmb3IgdGhlIGxh YmVsIGluIHRoYXQgbGFiZWwgc3BhY2UuICBUaGUgbmV4dGhvcCBvZiB0aGUNCj4gICAgICBmb3J3 YXJkaW5nIGVudHJ5IGluZGljYXRlcyBhIGxhYmVsIHBvcCB3aXRoIG91dGdvaW5nIGludGVyZmFj ZQ0KPiAgICAgIHBvaW50aW5nIHRvIHRoZSBiYWNrdXAgQUMgQ0UyLVBFNC4NCj4NCj4gU0I+IEkg YW0gbm90IHN1cmUgd2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaW4gdGhlIGFib3ZlLiBJcyB0aGlz IGFuDQo+IE1QTFMgb3BlcmF0aW9uIG9yIGEgUFcgb3BlcmF0aW9uLiBJZiB0aGUgbGF0dGVyIGl0 IGlzIG5vdCBhIHNpbXBsZQ0KPiBsYWJlbCBwb3AuDQo+DQo+IFt5c2hlbl0gSXQgaXMgUFcgbGFi ZWwgcG9wLg0KPg0KPiAgICAgIEluIEZpZ3VyZSA4LCBTUEUyIGlzIGEgY28tbG9jYXRlZCBwcm90 ZWN0b3IgdGhhdCBwcm90ZWN0cyBQVzEgYWdhaW5zdA0KPiAgICAgIFMtUEUgZmFpbHVyZS4gIEl0 IG1haW50YWlucyBhIGxhYmVsIHNwYWNlIGZvciBTUEUxLCB3aGljaCBpcw0KPiAgICAgIGlkZW50 aWZpZWQgYnkgdGhlIGNvbnRleHQgaWRlbnRpZmllciBvZiB7U1BFMSwgU1BFMn0uIEl0IGxlYXJu cw0KPiAgICAgIFNFRzEncyBsYWJlbCBmcm9tIFNQRTEsIGFuZCBpbnN0YWxscyBhIGZvcndhcmRp bmcgZW50cnkgaW4gdGhlIGxhYmVsDQo+ICAgICAgc3BhY2UuICBUaGUgbmV4dGhvcCBvZiB0aGUg Zm9yd2FyZGluZyBlbnRyeSBpbmRpY2F0ZXMgYSBsYWJlbCBzd2FwIHRvDQo+ICAgICAgU0VHNCdz IGxhYmVsLg0KPg0KPiA0LjYuMi4gIEV4YW1wbGVzIG9mIENlbnRyYWxpemVkIFByb3RlY3Rvcg0K Pg0KPiAgICAgIEluIHRoZSBjZW50cmFsaXplZCBwcm90ZWN0b3IgbW9kZWwsIGZvciBlYWNoIHBy aW1hcnkgUFcgb2Ygd2hpY2ggdGhlDQo+ICAgICAgcHJvdGVjdG9yIGlzIG5vdCBhIGJhY2t1cCAo Uy0pUEUsIHRoZSBwcm90ZWN0b3IgTVVTVCBhbHNvIGxlYXJuIHRoZQ0KPiAgICAgIGxhYmVsIG9m IHRoZSBiYWNrdXAgUFcgZnJvbSB0aGUgYmFja3VwIChTLSlQRSAoU2VjdGlvbiA1LjMpLiAgVGhp cyBpcw0KPiAgICAgIHRoZSBiYWNrdXAgKFMtKVBFIHRoYXQgdGhlIHByb3RlY3RvciB3aWxsIGZv cndhcmQgdHJhZmZpYyB0by4gIFRoZQ0KPiAgICAgIHByb3RlY3RvciBNVVNUIGluc3RhbGwgYSBm b3J3YXJkaW5nIGVudHJ5IHdpdGggbGFiZWwgc3dhcCBmcm9tIHRoZQ0KPiAgICAgIHByaW1hcnkg UFcncyBsYWJlbCB0byB0aGUgYmFja3VwIFBXJ3MgbGFiZWwuDQo+DQo+ICAgICAgSW4gRmlndXJl IDksIHRoZSBwcm90ZWN0b3IgaXMgYSBjZW50cmFsaXplZCBwcm90ZWN0b3IgdGhhdCBwcm90ZWN0 cw0KPiAgICAgIFBXMSBhZ2FpbnN0IGVncmVzcyBBQyBmYWlsdXJlIGFuZCBlZ3Jlc3Mgbm9kZSBm YWlsdXJlLiAgSXQgbWFpbnRhaW5zDQo+ICAgICAgYSBsYWJlbCBzcGFjZSBmb3IgUEUyLCB3aGlj aCBpcyBpZGVudGlmaWVkIGJ5IHRoZSBjb250ZXh0IGlkZW50aWZpZXINCj4gICAgICBvZiB7UEUy LCBwcm90ZWN0b3J9LiBJdCBsZWFybnMgUFcxJ3MgbGFiZWwgZnJvbSBQRTIsIGFuZCBQVzIncyBs YWJlbA0KPiAgICAgIGZyb20gUEU0LiAgSXQgaW5zdGFsbHMgYSBmb3J3YXJkaW5nIGVudHJ5IGZv ciBQVzEncyBsYWJlbCBpbiB0aGUNCj4gICAgICBsYWJlbCBzcGFjZS4gIFRoZSBuZXh0aG9wIG9m IHRoZSBmb3J3YXJkaW5nIGVudHJ5IGluZGljYXRlcyBhIGxhYmVsDQo+ICAgICAgc3dhcCB0byBQ VzIncyBsYWJlbC4NCj4NCj4gICAgICBJbiBGaWd1cmUgMTAsIHRoZSBwcm90ZWN0b3IgaXMgYSBj ZW50cmFsaXplZCBwcm90ZWN0b3IgdGhhdCBwcm90ZWN0cw0KPiAgICAgIHRoZSBQVyBzZWdtZW50 IFNFRzEgb2YgUFcxIGFnYWluc3QgdGhlIG5vZGUgZmFpbHVyZSBvZiBTUEUxLiAgSXQNCj4gICAg ICBtYWludGFpbnMgYSBsYWJlbCBzcGFjZSBmb3IgU1BFMSwgd2hpY2ggaXMgaWRlbnRpZmllZCBi eSB0aGUgY29udGV4dA0KPiAgICAgIGlkZW50aWZpZXIgb2Yge1NQRTEsIHByb3RlY3Rvcn0uIEl0 IGxlYXJucyBTRUcxJ3MgbGFiZWwgZnJvbSBTUEUxLA0KPiAgICAgIGFuZCBsZWFybnMgU0VHMydz IGxhYmVsIGZyb20gU1BFMi4gIEl0IGluc3RhbGxzIGEgZm9yd2FyZGluZyBlbnRyeQ0KPiAgICAg IGZvciBTRUcxJ3MgbGFiZWwgaW4gdGhlIGxhYmVsIHNwYWNlLiAgVGhlIG5leHRob3Agb2YgdGhl IGZvcndhcmRpbmcNCj4gICAgICBlbnRyeSBpbmRpY2F0ZXMgYSBsYWJlbCBzd2FwIHRvIFNFRzMn cyBsYWJlbC4NCj4NCj4gNS4gIExEUCBFeHRlbnNpb25zDQo+DQo+ICAgICAgQXMgZGVzY3JpYmVk IGluIHByZXZpb3VzIHNlY3Rpb25zLCBhIHRhcmdldGVkIExEUCBzZXNzaW9uIE1VU1QgYmUNCj4g ICAgICBlc3RhYmxpc2hlZCBiZXR3ZWVuIGVhY2ggcGFpciBvZiBwcmltYXJ5IFBFIGFuZCBwcm90 ZWN0b3IuICBUaGUNCj4gICAgICBwcmltYXJ5IFBFIHNlbmRzIExhYmVsIE1hcHBpbmcgbWVzc2Fn ZSBvdmVyIHRoaXMgc2Vzc2lvbiB0byBhZHZlcnRpc2UNCj4gICAgICBwcmltYXJ5IFBXIGxhYmVs cyB0byB0aGUgcHJvdGVjdG9yLiAgSW4gdGhlIGNlbnRyYWxpemVkIHByb3RlY3Rvcg0KPg0KPg0K Pg0KPiBZaW1pbiBTaGVuLCBldCBhbC4gICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTUgICAg ICAgICAgICAgICBbUGFnZSAxOF0NCj4NCj4NCj4gSW50ZXJuZXQtRHJhZnQgICAgIFBXIEVuZHBv aW50IEZhc3QgRmFpbHVyZSBQcm90ZWN0aW9uICAgICAgICAgSnVseSAyMDE0DQo+DQo+DQo+ICAg ICAgbW9kZWwsIGEgdGFyZ2V0ZWQgTERQIHNlc3Npb24gTVVTVCBhbHNvIGJlIGVzdGFibGlzaGVk IGJldHdlZW4gYQ0KPiAgICAgIGJhY2t1cCAoUy0pUEUgYW5kIGEgcHJvdGVjdG9yLiAgVGhlIGJh Y2t1cCBQRSBzZW5kcyBMYWJlbCBNYXBwaW5nDQo+ICAgICAgbWVzc2FnZSBvdmVyIHRoaXMgc2Vz c2lvbiB0byBhZHZlcnRpc2UgYmFja3VwIFBXIGxhYmVscyB0byB0aGUNCj4gICAgICBwcm90ZWN0 b3IuDQo+DQo+ICAgICAgVG8gZmFjaWxpdGF0ZSB0aGUgcHJvY2VkdXJlcywgdGhpcyBkb2N1bWVu dCBkZWZpbmVzIGEgbmV3ICJQcm90ZWN0aW9uDQo+ICAgICAgRkVDIEVsZW1lbnQiIFRMVi4gIFRo ZSBMYWJlbCBNYXBwaW5nIG1lc3NhZ2VzIG9mIGJvdGggdGhlIExEUA0KPiAgICAgIHNlc3Npb25z IGFib3ZlIE1VU1QgY2FycnkgdGhpcyBUTFYgdG8gaW5kaWNhdGUgdGhlIGlkZW50aXR5IG9mIGEN Cj4gICAgICBwcmltYXJ5IFBXLiAgU3BlY2lmaWNhbGx5LCBpbiB0aGUgY2VudHJhbGl6ZWQgcHJv dGVjdG9yIG1vZGVsLCB0aGUNCj4gICAgICBQcm90ZWN0aW9uIEZFQyBFbGVtZW50IFRMViBhZHZl cnRpc2VkIGJ5IGEgYmFja3VwIChTLSlQRSBNVVNUIG1hdGNoDQo+ICAgICAgdGhlIG9uZSBhZHZl cnRpc2VkIGJ5IHRoZSBwcmltYXJ5IFBFLCBzbyB0aGF0IHRoZSBwcm90ZWN0b3IgY2FuDQo+ICAg ICAgYXNzb2NpYXRlIHRoZSBwcmltYXJ5IFBXJ3MgbGFiZWwgd2l0aCB0aGUgYmFja3VwIFBXJ3Mg bGFiZWwsIGFuZA0KPiAgICAgIHBlcmZvcm0gYSBsYWJlbCBzd2FwLg0KPg0KPiAgICAgIFRoaXMg ZG9jdW1lbnQgYWxzbyBkZWZpbmVzIHRoZSBlbmNvZGluZyBvZiBDYXBhYmlsaXR5IFBhcmFtZXRl ciBUTFYNCj4gICAgICAoUkZDIDU1NjEpIGZvciBhIG5ldyAiRWdyZXNzIFByb3RlY3Rpb24gQ2Fw YWJpbGl0eSIsIHRvIGFsbG93IGENCj4gICAgICBwcm90ZWN0b3IgdG8gYW5ub3VuY2UgaXRzIGNh cGFiaWxpdHkgb2YgcHJvY2Vzc2luZyB0aGUgYWJvdmUNCj4gICAgICBQcm90ZWN0aW9uIEZFQyBF bGVtZW50IFRMViBhbmQgcGVyZm9ybWluZyBjb250ZXh0IHNwZWNpZmljIGxhYmVsDQo+ICAgICAg c3dpdGNoaW5nIGZvciBQVyBsYWJlbHMuDQo+DQo+ICAgICAgVGhlIHByb2NlZHVyZXMgaW4gdGhp cyBzZWN0aW9uIGFyZSBvbmx5IGFwcGxpY2FibGUsIGlmIHRoZSBwcm90ZWN0b3INCj4gICAgICBh ZHZlcnRpc2VzIHRoZSBFZ3Jlc3MgUHJvdGVjdGlvbiBDYXBhYmlsaXR5LCB0aGUgcHJpbWFyeSBQ RSBzdXBwb3J0cw0KPiAgICAgIHRoZSBhZHZlcnRpc2VtZW50IG9mIHRoZSBQcm90ZWN0aW9uIEZF QyBFbGVtZW50IFRMViwgYW5kIGluIHRoZQ0KPiAgICAgIGNlbnRyYWxpemVkIHByb3RlY3RvciBt b2RlbCwgdGhlIGJhY2t1cCBQRSBhbHNvIHN1cHBvcnRzIHRoZQ0KPiAgICAgIGFkdmVydGlzZW1l bnQgb2YgdGhlIFByb3RlY3Rpb24gRkVDIEVsZW1lbnQgVExWLg0KPg0KPiA1LjEuICBFZ3Jlc3Mg UHJvdGVjdGlvbiBDYXBhYmlsaXR5IFRMVg0KPg0KPiAgICAgIEEgcHJvdGVjdG9yIE1VU1QgYWR2 ZXJ0aXNlIHRoZSBFZ3Jlc3MgUHJvdGVjdGlvbiBDYXBhYmlsaXR5IFRMViBpbg0KPiAgICAgIGl0 cyBJbml0aWFsaXphdGlvbiBtZXNzYWdlIGFuZCBDYXBhYmlsaXR5IG1lc3NhZ2UsIG92ZXIgdGhl IExEUA0KPiAgICAgIHNlc3Npb24gd2l0aCBhIHByaW1hcnkgUEUuICBJbiB0aGUgY2VudHJhbGl6 ZWQgcHJvdGVjdG9yIG1vZGVsLCB0aGUNCj4gICAgICBwcm90ZWN0b3IgTVVTVCBhbHNvIGFkdmVy dGlzZSB0aGUgVExWIG92ZXIgdGhlIExEUCBzZXNzaW9uIHdpdGggYQ0KPiAgICAgIGJhY2t1cCBQ RS4gIFRoZSBUTFYgY2FycmllcyBvbmUgb3IgbXVsdGlwbGUgY29udGV4dCBpZGVudGlmaWVycy4g IFRvDQo+ICAgICAgdGhlIHByaW1hcnkgUEUsIHRoZSBUTFYgU0hPVUxEIGNhcnJ5IHRoZSBjb250 ZXh0IGlkZW50aWZpZXIgb2YgdGhlDQo+ICAgICAge3ByaW1hcnkgUEUsIHByb3RlY3Rvcn0uIElu IHRoZSBjZW50cmFsaXplZCBwcm90ZWN0b3IgbW9kZWwsIHRoZSBUTFYNCj4gICAgICBTSE9VTEQg Y2FycnkgdG8gdGhlIGJhY2t1cCBQRSBtdWx0aXBsZSBjb250ZXh0IGlkZW50aWZpZXJzLCBvbmUg Zm9yDQo+ICAgICAgZWFjaCB7cHJpbWFyeSBQRSwgcHJvdGVjdG9yfSB3aGVyZSB0aGUgYmFja3Vw IFBFIHNlcnZlcyBhcyBhIGJhY2t1cA0KPiAgICAgIGZvciB0aGUgcHJpbWFyeSBQRS4gIFRoaXMg VExWIFNIT1VMRCBOT1QgYmUgYWR2ZXJ0aXNlZCBieSB0aGUgcHJpbWFyeQ0KPiAgICAgIFBFIG9y IHRoZSBiYWNrdXAgUEUgdG8gdGhlIHByb3RlY3Rvci4NCj4NCj4gICAgICBUaGUgcHJvY2Vzc2lu ZyBvZiB0aGUgRWdyZXNzIFByb3RlY3Rpb24gQ2FwYWJpbGl0eSBUTFYgYnkgYSByZWNlaXZpbmcN Cj4gICAgICByb3V0ZXIgU0hPVUxEIGZvbGxvdyB0aGUgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFJG QyA1NTYxLiAgSW4NCj4gICAgICBwYXJ0aWN1bGFyLCB0aGUgcm91dGVyIFNIT1VMRCBhZHZlcnRp c2UgUFcgaW5mb3JtYXRpb24gdG8gdGhlDQo+ICAgICAgcHJvdGVjdG9yIGJ5IHVzaW5nIHRoZSBQ cm90ZWN0aW9uIEZFQyBFbGVtZW50IFRMViwgb25seSBhZnRlciBpdCBoYXMNCj4gICAgICByZWNl aXZlZCB0aGUgRWdyZXNzIFByb3RlY3Rpb24gQ2FwYWJpbGl0eSBUTFYgZnJvbSB0aGUgcHJvdGVj dG9yLiAgSXQNCj4gICAgICBTSE9VTEQgdmFsaWRhdGUgZWFjaCBjb250ZXh0IGlkZW50aWZpZXIg aW5jbHVkZWQgaW4gdGhlIFRMViwgYW5kDQo+ICAgICAgYWR2ZXJ0aXNlIHRoZSBpbmZvcm1hdGlv biBvZiBvbmx5IHRob3NlIFBXcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGgNCj4gICAgICB0aGUg Y29udGV4dCBpZGVudGlmaWVyLiAgSXQgU0hPVUxEIHdpdGhkcmF3IHByZXZpb3VzbHkgYWR2ZXJ0 aXNlZA0KPg0KPg0KPg0KPiBZaW1pbiBTaGVuLCBldCBhbC4gICAgICBFeHBpcmVzIEphbnVhcnkg MjUsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSAxOV0NCj4NCj4NCj4gSW50ZXJuZXQtRHJhZnQg ICAgIFBXIEVuZHBvaW50IEZhc3QgRmFpbHVyZSBQcm90ZWN0aW9uICAgICAgICAgSnVseSAyMDE0 DQo+DQo+DQo+ICAgICAgUHJvdGVjdGlvbiBGRUMgVExWcywgd2hlbiB0aGUgcHJvdGVjdG9yIGhh cyB3aXRoZHJhd24gYSBwcmV2aW91c2x5DQo+ICAgICAgYWR2ZXJ0aXNlZCBjb250ZXh0IGlkZW50 aWZpZXIgb3IgdGhlIGVudGlyZSBFZ3Jlc3MgUHJvdGVjdGlvbg0KPiAgICAgIENhcGFiaWxpdHkg VExWIHZpYSBDYXBhYmlsaXR5IG1lc3NhZ2UuDQo+DQo+ICAgICAgVGhlIGVuY29kaW5nIG9mIHRo ZSBFZ3Jlc3MgUHJvdGVjdGlvbiBDYXBhYmlsaXR5IFRMViBpcyBkZWZpbmVkIGFzDQo+ICAgICAg YmVsb3cuICBJdCBjb25mb3JtcyB0byB0aGUgZm9ybWF0IG9mIENhcGFiaWxpdHkgUGFyYW1ldGVy IFRMVg0KPiAgICAgIHNwZWNpZmllZCBpbiBSRkMgNTU2MS4NCj4NCj4gICAgICAgICAwICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+ ICAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxDQo+ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAgfFV8RnwgIEVncmVz cyBQcm90ZWN0aW9uIChUQkQpICB8ICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgIHwNCj4g ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQo+ICAgICAgICB8U3wgUmVzZXJ2ZWQgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4g ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQo+ICAgICAgICB+ICAgICAgICAgICAgICAgIENhcGFiaWxpdHkgRGF0 YSA9IGNvbnRleHQgaWRlbnRpZmllcihzKSAgICAgICAgfg0KPiAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4g ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst Ky0rLSstKy0rLSstKy0rDQo+ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRmlndXJlIDExDQo+DQo+ICAgICAgVGhlIFUtYml0IE1VU1QgYmUgc2V0IHRvIDEgc28g dGhhdCBhIHJlY2VpdmVyIE1VU1Qgc2lsZW50bHkgaWdub3JlDQo+ICAgICAgdGhpcyBUTFYgaWYg dW5rbm93biB0byBpdCwgYW5kIGNvbnRpbnVlIHByb2Nlc3NpbmcgdGhlIHJlc3Qgb2YgdGhlDQo+ ICAgICAgbWVzc2FnZS4NCj4NCj4gICAgICBUaGUgRi1iaXQgTVVTVCBiZSBzZXQgdG8gMCBzaW5j ZSB0aGlzIFRMViBpcyBzZW50IG9ubHkgaW4NCj4gICAgICBJbml0aWFsaXphdGlvbiBhbmQgQ2Fw YWJpbGl0eSBtZXNzYWdlcywgd2hpY2ggYXJlIG5vdCBmb3J3YXJkZWQuDQo+DQo+ICAgICAgVGhl IFRMViBDb2RlIFBvaW50IGlzIFRCRC4gIEl0IG5lZWRzIHRvIGJlIGFzc2lnbmVkIGJ5IElBTkEu DQo+DQo+ICAgICAgVGhlIFMtYml0IGluZGljYXRlcyB3aGV0aGVyIHRoZSBzZW5kZXIgaXMgYWR2 ZXJ0aXNpbmcgKFM9MSkgb3INCj4gICAgICB3aXRoZHJhd2luZyAoUz0wKSB0aGUgY2FwYWJpbGl0 eS4NCj4NCj4gICAgICBUaGUgIkNhcGFiaWxpdHkgRGF0YSIgaXMgZW5jb2RlZCB3aXRoIHRoZSBj b250ZXh0IGlkZW50aWZpZXIgb2YgdGhlDQo+ICAgICAge3ByaW1hcnkgUEUsIHByb3RlY3Rvcn0u DQo+DQo+IFNCPiB3aGVyZSBpcyB0aGUgc3RydWN0dXJlIG9mIHtwcmltYXJ5IFBFLCBwcm90ZWN0 b3J9IGRlZmluZWQ/DQo+DQo+IFt5c2hlbl0gVGhlIFByb3RlY3Rpb24gRkVDIEVsZW1lbnQgVExW IGNhcnJpZXMgdGhlIGNvbnRleHQgSUQgb2Yge3ByaW1hcnkgUEUsIHByb3RlY3Rvcn0uIFRoZSB7 cHJpbWFyeSBQRSwgcHJvdGVjdG9yfSB0dXBsZSBpdHNlbGYgaXMgbm90IGVuY29kZWQuDQo+DQo+ IDUuMi4gIFBXIExhYmVsIERpc3RyaWJ1dGlvbiBmcm9tIFByaW1hcnkgUEUgdG8gUHJvdGVjdG9y DQo+DQo+ICAgICAgQSBwcmltYXJ5IFBFIFNIT1VMRCBhZHZlcnRpc2UgYSBwcmltYXJ5IFBXJ3Mg bGFiZWwgdG8gYSBwcm90ZWN0b3IgYnkNCj4gICAgICBzZW5kaW5nIGEgTGFiZWwgTWFwcGluZyBt ZXNzYWdlLiAgVGhlIG1lc3NhZ2UgaW5jbHVkZXMgYSBQcm90ZWN0aW9uDQo+ICAgICAgRkVDIEVs ZW1lbnQgVExWIChzZWUgU2VjdGlvbiA1LjQgZm9yIGVuY29kaW5nKSwgYW5kIGFuIFVwc3RyZWFt LQ0KPiAgICAgIEFzc2lnbmVkIExhYmVsIFRMViAoUkZDIDYzODkpIGVuY29kZWQgd2l0aCB0aGUg UFcncyBsYWJlbC4gIFRoZQ0KPiAgICAgIGNvbWJpbmF0aW9uIG9mIHRoZSBQcm90ZWN0aW9uIEZF QyBFbGVtZW50IFRMViBhbmQgdGhlIFBXIGxhYmVsDQo+ICAgICAgcmVwcmVzZW50cyB0aGUgcHJp bWFyeSBQRSdzIGZvcndhcmRpbmcgc3RhdGUgZm9yIHRoZSBQVy4gIFRoZSBMYWJlbA0KPiAgICAg IE1hcHBpbmcgbWVzc2FnZSBTSE9VTEQgYWxzbyBjYXJyeSBhbiBJUHY0L3Y2IEludGVyZmFjZV9J RCBUTFYgKFJGQw0KPg0KPg0KPg0KPiBZaW1pbiBTaGVuLCBldCBhbC4gICAgICBFeHBpcmVzIEph bnVhcnkgMjUsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSAyMF0NCj4NCj4NCj4gSW50ZXJuZXQt RHJhZnQgICAgIFBXIEVuZHBvaW50IEZhc3QgRmFpbHVyZSBQcm90ZWN0aW9uICAgICAgICAgSnVs eSAyMDE0DQo+DQo+DQo+ICAgICAgNjM4OSwgUkZDIDM0NzEpIGVuY29kZWQgd2l0aCB0aGUgY29u dGV4dCBpZGVudGlmaWVyIG9mIHRoZSB7cHJpbWFyeQ0KPiAgICAgIFBFLCBwcm90ZWN0b3J9Lg0K Pg0KPiAgICAgIFRoZSBwcm90ZWN0b3IgdGhhdCByZWNlaXZlcyB0aGlzIExhYmVsIE1hcHBpbmcg bWVzc2FnZSBTSE9VTEQgaW5zdGFsbA0KPiAgICAgIGEgZm9yd2FyZGluZyBlbnRyeSBmb3IgdGhl IFBXIGxhYmVsIGluIHRoZSBsYWJlbCBzcGFjZSBpZGVudGlmaWVkIGJ5DQo+ICAgICAgdGhlIGNv bnRleHQgaWRlbnRpZmllci4gIFRoZSBuZXh0aG9wIG9mIHRoZSBmb3J3YXJkaW5nIGVudHJ5IFNI T1VMRA0KPiAgICAgIGVuc3VyZSBwYWNrZXRzIHRvIGJlIHNlbnQgdG93YXJkcyB0aGUgdGFyZ2V0 IENFIHZpYSBhIGJhY2t1cCBBQyBvciBhDQo+ICAgICAgYmFja3VwIChTLSlQRSwgZGVwZW5kaW5n IG9uIHRoZSBwcm90ZWN0aW9uIHNjZW5hcmlvLiAgVGhlIHByb3RlY3Rvcg0KPiAgICAgIFNIT1VM RCBzaWxlbnRseSBkaXNjYXJkIGEgTGFiZWwgTWFwcGluZyBtZXNzYWdlIGlmIHRoZSBpbmNsdWRl ZA0KPiAgICAgIGNvbnRleHQgaWRlbnRpZmllciBpcyB1bmtub3duIHRvIGl0Lg0KPg0KPiA1LjMu ICBQVyBMYWJlbCBEaXN0cmlidXRpb24gZnJvbSBCYWNrdXAgUEUgdG8gUHJvdGVjdG9yDQo+DQo+ ICAgICAgSW4gdGhlIGNlbnRyYWxpemVkIHByb3RlY3RvciBtb2RlbCwgYSBiYWNrdXAgUEUgU0hP VUxEIGFkdmVydGlzZSBhDQo+ICAgICAgYmFja3VwIFBXJ3MgbGFiZWwgdG8gYSBwcm90ZWN0b3Ig Ynkgc2VuZGluZyBhIExhYmVsIE1hcHBpbmcgbWVzc2FnZS4NCj4gICAgICBUaGUgbWVzc2FnZSBp bmNsdWRlcyBhIFByb3RlY3Rpb24gRkVDIEVsZW1lbnQgVExWIGFuZCBhIEdlbmVyaWMgTGFiZWwN Cj4gICAgICBUTFYgZW5jb2RlZCB3aXRoIHRoZSBiYWNrdXAgUFcncyBsYWJlbC4gIFRoaXMgUHJv dGVjdGlvbiBGRUMgRWxlbWVudA0KPiAgICAgIE1VU1QgYmUgaWRlbnRpY2FsIHRvIHRoZSBQcm90 ZWN0aW9uIEZFQyBFbGVtZW50IFRMViB0aGF0IHRoZSBwcmltYXJ5DQo+ICAgICAgUEUgYWR2ZXJ0 aXNlcyB0byB0aGUgcHJvdGVjdG9yIChTZWN0aW9uIDUuMikuICBUaGUgY29udGV4dCBpZGVudGlm aWVyDQo+ICAgICAgU0hPVUxEIE5PVCBiZSBlbmNvZGVkIGluIEludGVyZmFjZV9JRCBUTFYgaW4g dGhpcyBtZXNzYWdlLg0KPg0KPiAgICAgIFRoZSBwcm90ZWN0b3IgdGhhdCByZWNlaXZlcyB0aGlz IExhYmVsIE1hcHBpbmcgbWVzc2FnZSBTSE9VTEQNCj4gICAgICBhc3NvY2lhdGUgdGhlIGJhY2t1 cCBQVyB3aXRoIHRoZSBwcmltYXJ5IFBXLCBiYXNlZCBvbiB0aGUgY29tbW9uDQo+ICAgICAgUHJv dGVjdGlvbiBGRUMgRWxlbWVudCBUTFYuICBJdCBTSE9VTEQgZGlzdGluZ3Vpc2ggYmV0d2VlbiB0 aGUgTGFiZWwNCj4gICAgICBNYXBwaW5nIG1lc3NhZ2UgZnJvbSB0aGUgcHJpbWFyeSBQRSBhbmQg dGhlIExhYmVsIE1hcHBpbmcgbWVzc2FnZQ0KPiAgICAgIGZyb20gdGhlIGJhY2t1cCBQRSBiYXNl ZCBvbiB0aGUgcmVzcGVjdGl2ZSBwcmVzZW5jZSBhbmQgYWJzZW5jZSBvZg0KPiAgICAgIGNvbnRl eHQgaWRlbnRpZmllciBpbiBJbnRlcmZhY2VfSUQgVExWLiAgSXQgU0hPVUxEIGluc3RhbGwgYQ0K PiAgICAgIGZvcndhcmRpbmcgZW50cnkgZm9yIHRoZSBwcmltYXJ5IFBXJ3MgbGFiZWwgaW4gdGhl IGxhYmVsIHNwYWNlDQo+ICAgICAgaWRlbnRpZmllZCBieSB0aGUgY29udGV4dCBpZGVudGlmaWVy LiAgVGhlIG5leHRob3Agb2YgdGhlIGZvcndhcmRpbmcNCj4gICAgICBlbnRyeSBTSE9VTEQgaW5k aWNhdGUgYSBsYWJlbCBzd2FwIHRvIHRoZSBiYWNrdXAgUFcncyBsYWJlbCwgZm9sbG93ZWQNCj4g ICAgICBieSBhIGxhYmVsIHB1c2ggb3IgSVAgaGVhZGVyIHB1c2ggZm9yIGEgdHJhbnNwb3J0IHR1 bm5lbCB0byB0aGUNCj4gICAgICBiYWNrdXAgUEUuDQo+DQo+IDUuNC4gIFByb3RlY3Rpb24gRkVD IEVsZW1lbnQgVExWDQo+DQo+ICAgICAgVGhlIFByb3RlY3Rpb24gRkVDIEVsZW1lbnQgVExWIGhh cyB0eXBlIDB4ODMuICBJdHMgZm9ybWF0IGlzIGRlZmluZWQNCj4gICAgICBhcyBiZWxvdzoNCj4N Cj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gWWltaW4gU2hlbiwgZXQg YWwuICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgMjFd DQo+DQo+DQo+IEludGVybmV0LURyYWZ0ICAgICBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJv dGVjdGlvbiAgICAgICAgIEp1bHkgMjAxNA0KPg0KPg0KPiAgICAgICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4gICAgICAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDENCj4gICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICAgICB8ICAgVHlwZSgweDgzKSAgfCAg ICBSZXNlcnZlZCAgIHwgRW5jb2RpbmcgVHlwZSB8ICAgIExlbmd0aCAgICAgfA0KPiAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAg fiAgICAgICAgICAgICAgICAgICAgICAgICBQVyBJbmZvcm1hdGlvbiAgICAgICAgICAgICAgICAg ICAgICAgIH4NCj4gICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgMTINCj4NCj4gICAgICAtIEVuY29kaW5nIFR5cGUNCj4NCj4gICAgICAgICBU eXBlIG9mIGZvcm1hdCB0aGF0IFBXIEluZm9ybWF0aW9uIGZpZWxkIGlzIGVuY29kZWQuDQo+DQo+ ICAgICAgLSBMZW5ndGgNCj4NCj4gICAgICAgICBMZW5ndGggb2YgUFcgSW5mb3JtYXRpb24gZmll bGQgaW4gb2N0ZXRzLg0KPg0KPiAgICAgIC0gUFcgSW5mb3JtYXRpb24NCj4NCj4gICAgICAgICBG aWVsZCBvZiB2YXJpYWJsZSBsZW5ndGggdGhhdCBzcGVjaWZpZXMgYSBQVw0KPg0KPiAgICAgIEZv ciBFbmNvZGluZyBUeXBlLCAxIGlzIGRlZmluZWQgZm9yIHRoZSBQV2lkIEZFQyBFbGVtZW50IGZv cm1hdCwgYW5kDQo+ICAgICAgMiBpcyBkZWZpbmVkIGZvciB0aGUgR2VuZXJhbGl6ZWQgUFdpZCBG RUMgRWxlbWVudCBmb3JtYXQgKFJGQyA0NDQ3KS4NCj4NCj4NCj4gNS40LjEuICBFbmNvZGluZyBG b3JtYXQgZm9yIFBXaWQNCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4N Cj4NCj4NCj4NCj4NCj4NCj4NCj4gWWltaW4gU2hlbiwgZXQgYWwuICAgICAgRXhwaXJlcyBKYW51 YXJ5IDI1LCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgMjJdDQo+DQo+DQo+IEludGVybmV0LURy YWZ0ICAgICBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJvdGVjdGlvbiAgICAgICAgIEp1bHkg MjAxNA0KPg0KPg0KPiAgICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg ICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4gICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gICAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+ICAgICAgICB8ICAgVHlwZSgweDgzKSAgfCAgICBSZXNlcnZlZCAgIHwgIEVuYyBU eXBlKDEpICB8ICAgTGVuZ3RoKDE2KSAgfA0KPiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgSW5ncmVzcyBQRSBBZGRyZXNzICAgICAgICAgICAgICAgICAg ICAgICB8DQo+ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgRWdyZXNzIFBFIEFkZHJlc3MgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyb3VwIElEICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBXIElEICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQo+ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAgfEN8ICAgICAgICAgICBQVyBUeXBl ICAgICAgICAgICB8ICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgIHwNCj4gICAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEz DQo+DQo+ICAgICAgLSBJbmdyZXNzIFBFIEFkZHJlc3MNCj4NCj4gICAgICAgICBJUCBhZGRyZXNz IG9mIHRoZSBpbmdyZXNzIFBFIG9mIFBXLg0KPg0KPiAgICAgIC0gRWdyZXNzIFBFIEFkZHJlc3MN Cj4NCj4gICAgICAgICBJUCBhZGRyZXNzIG9mIHRoZSBlZ3Jlc3MgUEUgb2YgUFcuDQo+DQo+IFNC PiBIb3cgZG9lcyB0aGlzIHdvcmsgZm9yIElQdjY/DQo+DQo+ICAgICAgLSBHcm91cCBJRA0KPg0K PiAgICAgICAgIEFuIGFyYml0cmFyeSAzMi1iaXQgdmFsdWUgdGhhdCByZXByZXNlbnRzIGEgZ3Jv dXAgb2YgUFdzIGFuZCB0aGF0DQo+ICAgICAgICAgaXMgdXNlZCB0byBjcmVhdGUgZ3JvdXBzIGlu IHRoZSBQVyBzcGFjZS4NCj4NCj4gICAgICAtIFBXIElEDQo+DQo+ICAgICAgICAgQSBub24temVy byAzMi1iaXQgY29ubmVjdGlvbiBJRCB0aGF0LCB0b2dldGhlciB3aXRoIHRoZSBQVyBUeXBlDQo+ ICAgICAgICAgZmllbGQsIGlkZW50aWZpZXMgYSBwYXJ0aWN1bGFyIFBXLg0KPg0KPiAgICAgIC0g Q29udHJvbCB3b3JkIGJpdCAoQykNCj4NCj4gICAgICAgICBBIGJpdCB0aGF0IGZsYWdzIHRoZSBw cmVzZW5jZSBvZiBhIGNvbnRyb2wgd29yZCBvbiB0aGlzIFBXLiAgSWYgQw0KPiAgICAgICAgID0g MSwgY29udHJvbCB3b3JkIGlzIHByZXNlbnQ7IElmIEMgPSAwLCBjb250cm9sIHdvcmQgaXMgbm90 DQo+ICAgICAgICAgcHJlc2VudC4NCj4NCj4gICAgICAtIFBXIFR5cGUNCj4NCj4gICAgICAgICBB IDE1LWJpdCBxdWFudGl0eSB0aGF0IHJlcHJlc2VudHMgdGhlIHR5cGUgb2YgUFcuDQo+DQo+IFNC PiBOZWVkcyBhIHJlZg0KPg0KPg0KPg0KPg0KPiBZaW1pbiBTaGVuLCBldCBhbC4gICAgICBFeHBp cmVzIEphbnVhcnkgMjUsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSAyM10NCj4NCj4NCj4gSW50 ZXJuZXQtRHJhZnQgICAgIFBXIEVuZHBvaW50IEZhc3QgRmFpbHVyZSBQcm90ZWN0aW9uICAgICAg ICAgSnVseSAyMDE0DQo+DQo+DQo+IDUuNC4yLiAgRW5jb2RpbmcgRm9ybWF0IGZvciBHZW5lcmFs aXplZCBQV2lkDQo+DQo+ICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAg ICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KPiAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gICAgICAgIHwgICBUeXBlKDB4ODMpICB8ICAgIFJlc2VydmVkICAgfCAgRW5j IFR5cGUoMikgIHwgICBMZW5ndGggICAgICB8DQo+ICAgICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICBJbmdyZXNzIFBFIEFkZHJlc3MgICAgICAgICAgICAgICAg ICAgICAgIHwNCj4gICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICBFZ3Jlc3MgUEUgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gICAgICAgIHxDfCAgICAgICAgICAgUFcgVHlwZSAgICAgICAgICAgfCAgICAg ICAgICAgUmVzZXJ2ZWQgICAgICAgICAgICB8DQo+ICAgICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAg fCAgIEFHSSBUeXBlICAgIHwgICAgTGVuZ3RoICAgICB8ICAgICAgVmFsdWUgICAgICAgICAgICAg ICAgICAgIHwNCj4gICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICAgICB+ICAgICAgICAgICAgICAgICAg ICBBR0kgIFZhbHVlIChjb250ZC4pICAgICAgICAgICAgICAgICAgICAgICAgfg0KPiAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCj4gICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICAgICB8ICAgQUlJIFR5cGUgICAgfCAg ICBMZW5ndGggICAgIHwgICAgICBWYWx1ZSAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gICAgICAgIH4gICAgICAgICAgICAgICAgICAgU0FJSSAgVmFsdWUgKGNvbnRk LikgICAgICAgICAgICAgICAgICAgICAgICB+DQo+ICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gICAgICAgIHwgICBBSUkgVHlwZSAgICB8ICAgIExlbmd0aCAgICAgfCAgICAg IFZhbHVlICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAg fiAgICAgICAgICAgICAgICAgICBUQUlJIFZhbHVlIChjb250ZC4pICAgICAgICAgICAgICAgICAg ICAgICAgIH4NCj4gICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxNA0KPg0KPiAgICAgIC0gSW5n cmVzcyBQRSBBZGRyZXNzDQo+DQo+ICAgICAgICAgSVAgYWRkcmVzcyBvZiB0aGUgaW5ncmVzcyBQ RSBvZiBQVy4NCj4NCj4gICAgICAtIEVncmVzcyBQRSBBZGRyZXNzDQo+DQo+ICAgICAgICAgSVAg YWRkcmVzcyBvZiB0aGUgZWdyZXNzIFBFIG9mIFBXLg0KPg0KPiBTQj4gSVB2Nj8NCj4NCj4gICAg ICAtIENvbnRyb2wgd29yZCBiaXQgKEMpDQo+DQo+ICAgICAgICAgQSBiaXQgdGhhdCBmbGFncyB0 aGUgcHJlc2VuY2Ugb2YgYSBjb250cm9sIHdvcmQgb24gdGhpcyBQVy4gIElmIEMNCj4gICAgICAg ICA9IDEsIGNvbnRyb2wgd29yZCBpcyBwcmVzZW50OyBJZiBDID0gMCwgY29udHJvbCB3b3JkIGlz IG5vdA0KPiAgICAgICAgIHByZXNlbnQuDQo+DQo+ICAgICAgLSBQVyBUeXBlDQo+DQo+ICAgICAg ICAgQSAxNS1iaXQgcXVhbnRpdHkgdGhhdCByZXByZXNlbnRzIHRoZSB0eXBlIG9mIFBXLg0KPg0K Pg0KPg0KPiBZaW1pbiBTaGVuLCBldCBhbC4gICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMTUg ICAgICAgICAgICAgICBbUGFnZSAyNF0NCj4NCj4NCj4gSW50ZXJuZXQtRHJhZnQgICAgIFBXIEVu ZHBvaW50IEZhc3QgRmFpbHVyZSBQcm90ZWN0aW9uICAgICAgICAgSnVseSAyMDE0DQo+DQo+DQo+ ICAgICAgLSBBR0kgVHlwZSwgTGVuZ3RoLCBWYWx1ZSwgQUdJIFZhbHVlDQo+DQo+ICAgICAgICAg QXR0YWNobWVudCBHcm91cCBJZGVudGlmaWVyIG9mIFBXLg0KPg0KPiAgICAgIC0gU0FJSSBUeXBl LCBMZW5ndGgsIFZhbHVlLCBTQUlJIFZhbHVlDQo+DQo+ICAgICAgICAgU291cmNlIEF0dGFjaG1l bnQgSW5kaXZpZHVhbCBJZGVudGlmaWVyIG9mIFBXLg0KPg0KPiAgICAgIC0gVEFJSSBUeXBlLCBM ZW5ndGgsIFZhbHVlLCBUQUlJIFZhbHVlDQo+DQo+ICAgICAgICAgVGFyZ2V0IEF0dGFjaG1lbnQg SW5kaXZpZHVhbCBJZGVudGlmaWVyIG9mIFBXLg0KPg0KPiA2LiAgUmV2ZXJ0aXZlIEJlaGF2aW9y DQo+DQo+ICAgICAgU3Vic2VxdWVudCB0byBsb2NhbCByZXBhaXIsIHRoZXJlIGFyZSB0aHJlZSBz dHJhdGVnaWVzIGZvciB0aGUNCj4gICAgICBuZXR3b3JrIHRvIHJlc3RvcmUgdHJhZmZpYyB0byBh IGZ1bGx5IGZ1bmN0aW9uYWwgUFcuDQo+DQo+ICAgICAgbyAgR2xvYmFsIHJldmVydGl2ZSBtb2Rl DQo+DQo+ICAgICAgICAgSWYgdGhlIGluZ3Jlc3MgQ0UgaXMgbXVsdGktaG9tZWQgKEZpZ3VyZSAx KSwgaXQgTUFZIHN3aXRjaCB0aGUNCj4gICAgICAgICB0cmFmZmljIHRvIGEgYmFja3VwIEFDIHdo aWNoIGlzIGJvdW5kIHRvIGEgYmFja3VwIFBXLg0KPiAgICAgICAgIEFsdGVybmF0aXZlbHksIGlm IHRoZSBpbmdyZXNzIFBFIGhvc3RzIGEgYmFja3VwIFBXIChGaWd1cmUgMiksIHRoZQ0KPiAgICAg ICAgIGluZ3Jlc3MgUEUgTUFZIHN3aXRjaCB0aGUgdHJhZmZpYyB0byB0aGUgYmFja3VwIFBXLiAg VGhlc2UNCj4gICAgICAgICBwcm9jZWR1cmVzIGFyZSByZWZlcnJlZCB0byBhcyBnbG9iYWwgcmVw YWlyLiAgUG9zc2libGUgdHJpZ2dlcnMgb2YNCj4gICAgICAgICBhIGdsb2JhbCByZXBhaXIgaW5j bHVkZSBQVyBzdGF0dXMsIE9BTSwgYW5kIEJGRC4NCj4NCj4gICAgICBvICBDb250cm9sIHBsYW5l IHJldmVydGl2ZSBtb2RlDQo+DQo+ICAgICAgICAgSW4gZWdyZXNzIFBFIG5vZGUgcHJvdGVjdGlv biBhbmQgUy1QRSBub2RlIHByb3RlY3Rpb24sIGl0IGlzDQo+ICAgICAgICAgcG9zc2libGUgdGhh dCB0aGUgZmFpbHVyZSBpcyBsaW1pdGVkIHRvIHRoZSBsaW5rIGJldHdlZW4gdGhlIFBMUg0KPiAg ICAgICAgIGFuZCB0aGUgcHJpbWFyeSAoUy0pUEUsIHdoZXJlYXMgdGhlIHByaW1hcnkgKFMtKVBF IGlzIHN0aWxsIHVwLg0KPiAgICAgICAgIEluIHRoaXMgY2FzZSwgdGhlIFBMUiBvciBhbiB1cHN0 cmVhbSByb3V0ZXIgYWxvbmcgdGhlIHRyYW5zcG9ydA0KPiAgICAgICAgIHR1bm5lbCBNQVkgcmVy b3V0ZSB0aGUgdHVubmVsIGFyb3VuZCB0aGUgZmFpbGVkIGxpbmsgdmlhIGFuDQo+ICAgICAgICAg YWx0ZXJuYXRpdmUgcGF0aC4gIFRodXMsIHRoZSB0cmFuc3BvcnQgdHVubmVsIGNhbiBjb250aW51 ZSB0byBiZQ0KPiAgICAgICAgIHVzZWQgdG8gY2FycnkgdGhlIFBXIHRyYWZmaWMgdG8gdGhlIHBy aW1hcnkgKFMtKVBFLiAgVGhpcw0KPiAgICAgICAgIHByb2NlZHVyZSBpcyBkcml2ZW4gYnkgY29u dHJvbCBwbGFuZSBjb252ZXJnZW5jZSwgYW5kIGlzIHJlZmVycmVkDQo+ICAgICAgICAgdG8gYXMg Y29udHJvbCBwbGFuZSByZXBhaXIuDQo+DQo+ICAgICAgbyAgTG9jYWwgcmV2ZXJ0aXZlIG1vZGUN Cj4NCj4gICAgICAgICBUaGUgUExSIE1BWSBtb3ZlIHRyYWZmaWMgYmFjayB0byB0aGUgcHJpbWFy eSBQVywgYWZ0ZXIgdGhlIGZhaWx1cmUNCj4gICAgICAgICBpcyByZXNvbHZlZC4gIEluIGVncmVz cyBBQyBwcm90ZWN0aW9uLCB1cG9uIGRldGVjdGluZyB0aGF0IHRoZQ0KPiAgICAgICAgIHByaW1h cnkgQUMgaXMgcmVzdG9yZWQsIHRoZSBQTFIgTUFZIHN0YXJ0IGZvcndhcmRpbmcgdHJhZmZpYyBv dmVyDQo+ICAgICAgICAgdGhlIEFDIGFnYWluLiAgTGlrZXdpc2UsIGluIGVncmVzcyBQRSBub2Rl IHByb3RlY3Rpb24gYW5kIFMtUEUNCj4gICAgICAgICBub2RlIHByb3RlY3Rpb24sIHVwb24gZGV0 ZWN0aW5nIHRoYXQgdGhlIHByaW1hcnkgUEUgaXMgcmVzdG9yZWQsDQo+ICAgICAgICAgdGhlIFBM UiBNQVkgcmUtZXN0YWJsaXNoIHRoZSBwcmltYXJ5IHRyYW5zcG9ydCB0dW5uZWwgdGhyb3VnaCB0 aGUNCj4gICAgICAgICBwcmltYXJ5IFBFLCBhbmQgbW92ZSB0aGUgdHJhZmZpYyBmcm9tIHRoZSBi eXBhc3MgdHVubmVsIGJhY2sgdG8NCj4NCj4NCj4NCj4NCj4gWWltaW4gU2hlbiwgZXQgYWwuICAg ICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgMjVdDQo+DQo+ DQo+IEludGVybmV0LURyYWZ0ICAgICBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJvdGVjdGlv biAgICAgICAgIEp1bHkgMjAxNA0KPg0KPg0KPiAgICAgICAgIHRoZSB0cmFuc3BvcnQgdHVubmVs LiAgVGhlc2UgcHJvY2VkdXJlcyBhcmUgcmVmZXJyZWQgdG8gYXMgbG9jYWwNCj4gICAgICAgICBy ZXZlcnNpb24uDQo+DQo+ICAgICAgVGhlIGZhc3QgcHJvdGVjdGlvbiBtZWNoYW5pc20gaW4gdGhp cyBkb2N1bWVudCBTSE9VTEQgYmUgdXNlZCBpbg0KPiAgICAgIHRhbmRlbSB3aXRoIHRoZSBnbG9i YWwgcmV2ZXJ0aXZlIG1vZGUuICBQYXJ0aWN1bGFybHkgaW4gdGhlIGNhc2Ugb2YNCj4gICAgICBl Z3Jlc3MgKFMtKVBFIGZhaWx1cmUsIGlmIHRoZSBpbmdyZXNzIFBFIG9yIHRoZSBwcm90ZWN0b3Ig bG9zZXMNCj4gICAgICBjb21tdW5pY2F0aW9uIHdpdGggdGhlIChTLSlQRSBmb3IgYW4gZXh0ZW5z aXZlIHBlcmlvZCBvZiB0aW1lLCB0aGUNCj4gICAgICBMRFAgc2Vzc2lvbiBiZXR3ZWVuIHRoZW0g bWF5IGdvIGRvd24uICBDb25zZXF1ZW50bHksIHRoZSBpbmdyZXNzIFBFDQo+ICAgICAgbWF5IGJy aW5nIGRvd24gdGhlIHByaW1hcnkgUFcsIG9yIHRoZSBwcm90ZWN0b3IgbWF5IHJlbW92ZSB0aGUN Cj4gICAgICBmb3J3YXJkaW5nIGVudHJ5IG9mIHRoZSBwcmltYXJ5IFBXIGxhYmVsLiAgSW4gZWl0 aGVyIGNhc2UsIHRoZQ0KPiAgICAgIHNlcnZpY2Ugd2lsbCBiZSBkaXNydXB0ZWQuICBJbiBvdGhl ciB3b3JkcywgYWx0aG91Z2ggdGhlIGZhc3QNCj4gICAgICBwcm90ZWN0aW9uIGNhbiB0ZW1wb3Jh cmlseSByZXBhaXIgdHJhZmZpYywgY29udHJvbCBwbGFuZSBzdGF0ZSBtYXkNCj4gICAgICBldmVu dHVhbGx5IGJlIHRpbWVkIG91dCBpZiB0aGUgZmFpbHVyZSBwZXJzaXN0cy4gIFRoZXJlZm9yZSwg aXQgaXMNCj4gICAgICByZWNvbW1lbmRlZCB0aGF0IHRoZSBnbG9iYWwgcmV2ZXJ0aXZlIG1vZGUg U0hPVUxEIGJlIHNldCB1cCBpbg0KPiAgICAgIGFkdmFuY2UsIHNvIHRoYXQgdHJhZmZpYyBjYW4g YmUgbW92ZWQgdG8gYSBmdWxseSBmdW5jdGlvbmFsIGJhY2t1cCBQVw0KPiAgICAgIHNob3J0bHkg YWZ0ZXIgdGhlIGxvY2FsIHJlcGFpci4NCj4NCj4gICAgICBUaGUgY29udHJvbCBwbGFuZSByZXZl cnRpdmUgbW9kZSBtYXkgYWx3YXlzIGhhcHBlbiBhcyBwYXJ0IG9mIHRoZQ0KPiAgICAgIGNvbnZl cmdlbmNlIG9mIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2xzLiAgSG93ZXZlciwgaXQgaXMgb25seQ0K PiAgICAgIGFwcGxpY2FibGUgdG8gdGhlIHNwZWNpZmljIHNjZW5hcmlvcyBkZXNjcmliZWQgYWJv dmUuDQo+DQo+ICAgICAgVGhlIGxvY2FsIHJldmVydGl2ZSBtb2RlIGlzIG9wdGlvbmFsLiAgSW4g dGhlIGNpcmN1bXN0YW5jZXMgd2hlcmUgdGhlDQo+ICAgICAgZmFpbHVyZSBpcyBjYXVzZWQgYnkg cmVzb3VyY2UgZmxhcHBpbmcsIGxvY2FsIHJldmVyc2lvbiBNQVkgYmUNCj4gICAgICBkYW1wZW5l ZCB0byBsaW1pdCBwb3RlbnRpYWwgZGlzcnVwdGlvbnMuICBMb2NhbCByZXZlcnRpdmUgbW9kZSBN QVkgYmUNCj4gICAgICBkaXNhYmxlZCBjb21wbGV0ZWx5IGJ5IGNvbmZpZ3VyYXRpb24uDQo+DQo+ IDcuICBJQU5BIENvbnNpZGVyYXRpb25zDQo+DQo+ICAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVz IHRoZSBlbmNvZGluZyBvZiB0aGUgQ2FwYWJpbGl0eSBQYXJhbWV0ZXIgVExWDQo+ICAgICAgZm9y IHRoZSBuZXcgIkVncmVzcyBQcm90ZWN0aW9uIENhcGFiaWxpdHkiIGluIFNlY3Rpb24gNS4gIFRo aXMgd291bGQNCj4gICAgICByZXF1aXJlIElBTkEgdG8gYXNzaWduIGEgVExWIENvZGUgUG9pbnQg dG8gaXQuDQo+DQo+ICAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IExEUCBQcm90ZWN0 aW9uIEZFQyBFbGVtZW50IFRMViBpbg0KPiAgICAgIFNlY3Rpb24gNS4gIElBTkEgaGFzIGFzc2ln bmVkIHRoZSB0eXBlIHZhbHVlIDB4ODMgdG8gaXQuDQo+DQo+IFNCPiBJIGFtIHZlcnkgY29uZnVz ZWQgYWJvdXQgd2hhdCBleHBsaWNpdCBhY3Rpb25zIHlvdSBhcmUgYXNraW5nIElBTkENCj4gdG8g dGFrZS4gQXJlIHlvdSBzYXlpbmcgdGhhdCB0aGVyZSBhcmUgbm8gSUFOQSBhY3Rpb25zPw0KPg0K PiBbeXNoZW5dIE5lZWQgSUFOQSB0byBhc3NpZ24gYSBUTFYgY29kZSB0byAiRWdyZXNzIFByb3Rl Y3Rpb24gQ2FwYWJpbGl0eSIsIGFzIHNhaWQgYWJvdmUuDQo+DQo+IDguICBTZWN1cml0eSBDb25z aWRlcmF0aW9ucw0KPg0KPiAgICAgIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkaXNjdXNz ZWQgaW4gUkZDIDUwMzYsIFJGQyA1MzMxLCBSRkMNCj4gICAgICAzMjA5LCBhbmQgUkZDIDQwOTAg YXBwbHkgdG8gdGhpcyBkb2N1bWVudC4NCj4NCj4gU0I+IEFyZSB0aGVyZSBhbnkgUFcgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgdGhhdCBhcHBseT8NCj4NCj4gU0I+IFRoaXMgaXMgYSBuZXcgUFcg b3BlcmF0aW9uYWwgbW9kZSwgc28gSSBhbSBzdXJwcmlzZWQgdGhhdCB0aGVyZSBhcmUNCj4gbm8g bmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiBBbiBlYXJseSBzZWN1cml0eSByZXZpZXcgbWln aHQgYmUgdXNlZnVsLg0KPg0KPg0KPiBbeXNoZW5dIE5vdCBzdXJlIGFib3V0IGFueSBzcGVjaWZp YyBzZWN1cml0eSBpc3N1ZXMuDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHB3ZTMgbWFpbGluZyBsaXN0DQo+IHB3ZTNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQo+IC4NCj4NCg0K DQotLSANCkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQoNCmh0dHA6Ly93 d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRt bA0KDQo= From nobody Thu Aug 7 08:43:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679751B2C02; Thu, 7 Aug 2014 08:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 nYmqA4lgq77b; Thu, 7 Aug 2014 08:43:41 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51701B2C1A; Thu, 7 Aug 2014 08:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2343; q=dns/txt; s=iport; t=1407426219; x=1408635819; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iIXm7Ix4K/tBHxgqMAENNyzNdviMk7AWyA3v9cT/T9M=; b=EVOU9GzPtcZuH6dQZFIIVT5ggYCMc5sOgVMSFKtFZDfsiCNjVjIXiLgT bylq8j7Q8j2rvi19Q3MPPbb11b/OAxoWobZS0CSyPkTQZO9HEqHfSbVpG SIC3BkEqdIiPwYtoquZ1CTJFwnLODh7hiezqf4S6/v5tKCPD515fNEwdM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAOCd41OtJssW/2dsb2JhbABahy3ODIMbAYEpd4QDAQEBAwEdBhU6BgEFCwsOCgICBRYLAgIJAwIBAgFFBgEMAQcBAReIHwitZ4Z/j0AXgSyIU4VNB4J5gVIBBJwblHCDWA X-IronPort-AV: E=Sophos;i="5.01,818,1400025600"; d="scan'208";a="136179009" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 07 Aug 2014 15:43:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s77FhaEh013514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2014 15:43:36 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s77FhZXq010368; Thu, 7 Aug 2014 16:43:35 +0100 (BST) Message-ID: <53E39EA8.1040905@cisco.com> Date: Thu, 07 Aug 2014 16:43:36 +0100 From: Stewart Bryant 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: Yimin Shen , pwe3 , "pwe3-chairs@tools.ietf.org" References: <53D7B569.60400@cisco.com> <53E0B85B.8060707@cisco.com> <3fd1f1049aff43c99cbd3ff14e1f6c30@BY2PR05MB728.namprd05.prod.outlook.com> In-Reply-To: <3fd1f1049aff43c99cbd3ff14e1f6c30@BY2PR05MB728.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JoK-tykbqpLfeJ9rMAwjXVM5EaE Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:43:43 -0000 On 07/08/2014 16:01, Yimin Shen wrote: > Hi Stewart, > > Thanks very much again for the review and detailed comments. > > We will consider your suggestions on the LDP TLV structures defined in this draft. > > Regarding the tradeoff between the need for egress PE node protection and the increased state and complexity in PSN, this is a common considration for all IP/MPLS node protection, not PWE3 specific. SB> Agree > We do see the requirement from service providers. I think this should be their decision on a per network basis. When they decide to do it, we have a solution available for them. SB> Sure but what is the view of the WG. Do we want to recommend this approach as the best approach to the industry, or should we recommend a simpler approach that allows better layer separation. Perhaps some operators could comment on what their requirements are so we can better a better feel for how to make the complexity+scale trade off against protection coverage. SB> Remember a standards track RFC is a serious recommendation of good practice. > > That said, this draft doesn't necessarily multiply the number of PSN tunnels. It does require one tunnel per . SB> Surely it requires on per protection group? > However, if each primary PE is protected by only 1 protector, the number of tunnel will be the number of primary PEs, which is basically the same as the case where this mechanism is not used. SB> Not necessarily. This is a consequence of your method. Without context labels you deliver the traffic on the ordinary IP path to the alternative T-PE > This 1:1 relationship is achievable with the co-located model, and is especially achievable with the centralized model. Of course, in a more general case, if the avarage PE-to-protector ratio is 1:N, the number of tunnels will be multiplied by N. SB> With the centralized model - is this a PSN function, or is the centralized protector a type of S-PE? > But operators can always design their networks thoughtfully and manage this N to be lowever than the threshold that may lead to scalability problems. (Here, I'm not counting bypass tunnels in, because bypass tunnels exist in the existing IP/MPLS fast-reroute as well.) SB>Yes, but with some sort PW stitching model this simply does not apply. - Stewart From nobody Thu Aug 7 19:46:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B0E1A0023; Thu, 7 Aug 2014 19:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 yjbsao9Prby6; Thu, 7 Aug 2014 19:46:55 -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 67D321A002E; Thu, 7 Aug 2014 19:46:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIA43629; Fri, 08 Aug 2014 02:46:50 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Aug 2014 03:46:49 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.78]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 10:46:45 +0800 From: Mingui Zhang To: "Stewart Bryant (stbryant)" Thread-Topic: [PWE3] [mpls] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 Thread-Index: AQHPsY7DDiJw7y3ZEk+Q1kSqiialjpvEXftQgABg1hiAACg8oA== Date: Fri, 8 Aug 2014 02:46:44 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> In-Reply-To: <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] 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/mpls/FZuomKWMCkQoGQ3A4WyiW2AFMWI Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 02:46:56 -0000 Hi Stewart, I think authors would say the S-PE stitching method involves the control pl= ane processing during the repair procedure. They emphasized their method us= es data plane & local repair, which can be faster. Here, I want to raise one issue:=20 If the primary PE fails and the PLR redirects the traffic during the flying= of the packets, hoping the backup PE delivers the packets immediately. Thi= s means the AC at the backup PE side is also ACTIVE. So the CE has active-a= ctive connections to both egress PEs. This is obviously different from the = PW-RED's active-standby mechanism [RFC6718]. Will this difference bring us = the frame duplication issue? I think we need to address this in the updated= version.=20 Thanks, Mingui >-----Original Message----- >From: Stewart Bryant (stbryant) [mailto:stbryant@cisco.com] >Sent: Thursday, August 07, 2014 3:27 PM >To: Mingui Zhang >Cc: Eric Rosen (erosen); Alexander Vainshtein; mpls@ietf.org; pwe3; >pwe3-chairs@tools.ietf.org >Subject: Re: [PWE3] [mpls] WG Last Call for >draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 > > > >Sent from my iPad > >> On 7 Aug 2014, at 04:57, "Mingui Zhang" wrote: >> >> Hi Eric, >> >> The explanation of the story is very clear. Let me complement a bit. >> >>> - A "primary egress PE" partitions its set of PWs into n sets, where ea= ch >>> set is associated with a given "protector". The "protector" is the bac= kup >>> egress PE for those PWs. >> >> When the backup PE acts as the protector, it is the 'co-located' model. > >This case does not however need context labels. It is a form of S-PE and c= an >stitch the PWs just like every existing S-PE already does. > >Stewart > From nobody Fri Aug 8 01:15:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D481A0B0F for ; Fri, 8 Aug 2014 01:14:56 -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, RP_MATCHES_RCVD=-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 o5Nd6mYVhUNF for ; Fri, 8 Aug 2014 01:14:52 -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 6CBBD1A0AB6 for ; Fri, 8 Aug 2014 01:14:52 -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 9217218013DA; Fri, 8 Aug 2014 10:14:50 +0200 (CEST) Message-ID: <53E486FC.9060905@pi.nu> Date: Fri, 08 Aug 2014 10:14:52 +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: "mpls@ietf.org" References: <53CFD9E4.1040809@pi.nu> In-Reply-To: <53CFD9E4.1040809@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yLcp3JnDP4wS8sFq-vGyXQHMBqY Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-deprecate-bgp-entropy-label@tools.ietf.org Subject: [mpls] Closed: working group last draft-ietf-mpls-deprecate-bgp-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 08:14:56 -0000 Working Group, This working group last call has been closed; we have only had comments that support of progressing the draft. The working group chairs will continue with requesting publication. /Loa mpls wg co-chair On 2014-07-23 17:51, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-deprecate-bgp-entropy-label-01. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures against this document. The authors have > stated that they are unware of any IPRs related to this document. > > This working group last call ends August 6, 2014. > > /Loa > for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 8 01:44:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7941B2854; Fri, 8 Aug 2014 01:43:59 -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] 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 m8wX8LMG0cTN; Fri, 8 Aug 2014 01:43:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 637C71A034B; Fri, 8 Aug 2014 01:43:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808084358.4493.89733.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 01:43:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zmCUU_UWWD8wKDqEb-aOZIlxD3I Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-linear-protection-mib-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 08:44:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Transport Profile Linear Protection MIB Authors : Kingston Smiler Selvaraj Venkatesan Mahalingam Vishwas Manral Daniel King Sam Aldrin Filename : draft-ietf-mpls-tp-linear-protection-mib-03.txt Pages : 30 Date : 2014-08-08 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing MPLS Transport Profile (MPLS-TP) Linear Protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-linear-protection-mib-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-linear-protection-mib-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 8 02:31:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF1C1A0391; Fri, 8 Aug 2014 02:31:02 -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, RP_MATCHES_RCVD=-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 T67Kow9_5ZB1; Fri, 8 Aug 2014 02:31:00 -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 5D5D21A0344; Fri, 8 Aug 2014 02:31:00 -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 BD1FB18013DA; Fri, 8 Aug 2014 11:30:58 +0200 (CEST) Message-ID: <53E498D4.6000107@pi.nu> Date: Fri, 08 Aug 2014 11:31:00 +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: Mingui Zhang , "Stewart Bryant (stbryant)" References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RJtDQf2laMBJBB-folnkRmZk0eY Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 09:31:03 -0000 Authors, Mingui, Stewart On 2014-08-08 04:46, Mingui Zhang wrote: > Hi Stewart, > > I think authors would say the S-PE stitching method involves the control plane processing during the repair procedure. They emphasized their method uses data plane & local repair, which can be faster. > Here, I want to raise one issue: It seems that we take it for granted that the method proposed on this draft is faster than e.g. the e2e protection a la mpls-tp. Why is that? If we have implementations of both, do we have any real measurements? /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 8 02:54:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B191B29DA; Fri, 8 Aug 2014 02:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 KH9sSgYd1CgG; Fri, 8 Aug 2014 02:54:25 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852221B29D5; Fri, 8 Aug 2014 02:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=673; q=dns/txt; s=iport; t=1407491665; x=1408701265; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QesHiyeJrUPGN5bK6eIQIouA8kDFY5XiyldwV3R4slI=; b=fccJI7foOtoLOI/yXIH9PIPhnOfNfzi6nzWZp4rfwn3aI9EB410PlY9J T8+Av2xhZmqQl+6BgjBffsD61okpnZxSw0E9twXEwMZA5CxwzhIAvm1m2 Ga2Wxz/e0hlbSlx2DLdxKn9bDSsvczMlWWMofE1YwTGaO3amlNiReC7rH Q=; X-IronPort-AV: E=Sophos;i="5.01,824,1400025600"; d="scan'208";a="136958178" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 08 Aug 2014 09:54:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s789sLHe028305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 09:54:22 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s789sJZw014864; Fri, 8 Aug 2014 10:54:19 +0100 (BST) Message-ID: <53E49E4D.4040905@cisco.com> Date: Fri, 08 Aug 2014 10:54:21 +0100 From: Stewart Bryant 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: Mingui Zhang References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/V-IfCewMNtsSSXKvT9I99S1BJl4 Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 09:54:26 -0000 On 08/08/2014 03:46, Mingui Zhang wrote: > Hi Stewart, > > I think authors would say the S-PE stitching method involves the control plane processing during the repair procedure. Then they would be incorrect. The update of the PW entry in the FIB of an SPE is identical to the operation needed to update the FIB for any other FIB entry when FRR is triggered. Now there are more entries to update, but the degree of difficult presented will be implementation specific, but then so is the availability of context labels. > They emphasized their method uses data plane & local repair, which can be faster. So would an FRR repair in the PW plane. Stewart From nobody Fri Aug 8 07:00:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61791B2A31; Fri, 8 Aug 2014 07:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dZtueEZFWAf6; Fri, 8 Aug 2014 07:00:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBC71B29CD; Fri, 8 Aug 2014 07:00:38 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 14:00:29 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 14:00:29 +0000 From: Yimin Shen To: Loa Andersson , Mingui Zhang , "Stewart Bryant (stbryant)" Thread-Topic: [PWE3] [mpls] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 Thread-Index: AQHPsut9xMpTT3UKUUu7y8CePcLxcpvGtyQQ Date: Fri, 8 Aug 2014 14:00:28 +0000 Message-ID: <496a2c137775477c8c78c7e8d5463c6e@BY2PR05MB728.namprd05.prod.outlook.com> References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> <53E498D4.6000107@pi.nu> In-Reply-To: <53E498D4.6000107@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377424004)(252514010)(164054003)(51704005)(13464003)(189002)(199002)(24454002)(377454003)(76576001)(50986999)(99396002)(74662001)(81342001)(106356001)(106116001)(76176999)(54356999)(33646002)(93886004)(74316001)(80022001)(85306004)(79102001)(66066001)(105586002)(81542001)(99286002)(95666004)(64706001)(20776003)(4396001)(83322001)(76482001)(19580405001)(15975445006)(74502001)(86362001)(2656002)(46102001)(107046002)(21056001)(19580395003)(85852003)(87936001)(77982001)(101416001)(83072002)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB728; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX: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/mpls/LLo1ogndzZEffbfrcsRLiV_YaZk Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:00:42 -0000 Hi Loa, This draft assumes decoupled control plane and dataplane architecture of ro= uters, and it requires that the backup path (or backup forwarding state) be= pre-programmed in the dataplane on PLR. Hence when the dataplane (of PLR) = detects a failure, it is able to restore traffic locally and independently = by redirecting traffic over the preprogrammed backup path. This is generall= y assumed to be faster that mechanisms that involve control plane protocols= , or end-to-end messaging or OAM, because there is no event propagation del= ay. I believe this is a common assumption for all IP/MPLS FRR mechanisms. It will not be a problem if this mechanism and an e2e mechanism are both im= plemented in a network. As described in the draft, this mechanism provides = local repair, and it is viewed as a temporary repair. The draft strongly re= commend this mechanism to be used in tandem with an e2e or global repair me= chanism, so that the later can eventually move traffic from the locally rep= aired PW over to a fully functional PW, as a permanent repair. Thanks, /Yimin -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Friday, August 08, 2014 5:31 AM To: Mingui Zhang; Stewart Bryant (stbryant) Cc: mpls@ietf.org; Eric Rosen (erosen); pwe3; pwe3-chairs@tools.ietf.org Subject: Re: [PWE3] [mpls] WG Last Call for draft-ietf-pwe3-endpoint-fast-p= rotection-01 - RFC4447 Authors, Mingui, Stewart On 2014-08-08 04:46, Mingui Zhang wrote: > Hi Stewart, > > I think authors would say the S-PE stitching method involves the control = plane processing during the repair procedure. They emphasized their method = uses data plane & local repair, which can be faster. > Here, I want to raise one issue: It seems that we take it for granted that the method proposed on this draft= is faster than e.g. the e2e protection a la mpls-tp. Why is that? If we have implementations of both, do we have any real measurements? /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Fri Aug 8 07:02:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0AE1B29E1; Fri, 8 Aug 2014 07:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ynowV0AuPLsV; Fri, 8 Aug 2014 07:02:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E2A1B2A54; Fri, 8 Aug 2014 07:02:52 -0700 (PDT) Received: from BLUPR05CA0074.namprd05.prod.outlook.com (10.141.20.44) by DM2PR05MB733.namprd05.prod.outlook.com (10.141.178.18) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 14:02:50 +0000 Received: from BL2FFO11FD044.protection.gbl (2a01:111:f400:7c09::130) by BLUPR05CA0074.outlook.office365.com (2a01:111:e400:855::44) with Microsoft SMTP Server (TLS) id 15.0.1005.10 via Frontend Transport; Fri, 8 Aug 2014 14:02:49 +0000 Received: from P-EMF01-SAC.jnpr.net (66.129.239.15) by BL2FFO11FD044.mail.protection.outlook.com (10.173.161.140) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Fri, 8 Aug 2014 14:02:49 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 8 Aug 2014 07:02:47 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s78E2kn63116; Fri, 8 Aug 2014 07:02:46 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201408081402.s78E2kn63116@magenta.juniper.net> To: Loa Andersson In-Reply-To: <53E498D4.6000107@pi.nu> References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> <53E498D4.6000107@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Fri, 08 Aug 2014 11:31:00 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95677.1407506566.1@juniper.net> Date: Fri, 8 Aug 2014 07:02:46 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.15; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(377424004)(199002)(189002)(24454002)(51704005)(81156004)(50986999)(110136001)(99396002)(102836001)(76482001)(77982001)(16796002)(107046002)(95666004)(54356999)(76176999)(93886004)(106466001)(105596002)(21056001)(85306004)(74662001)(44976005)(46406003)(97756001)(74502001)(97736001)(79102001)(81542001)(46102001)(64706001)(20776003)(68736004)(69596002)(4396001)(81342001)(80022001)(86362001)(83322001)(47776003)(23726002)(87936001)(6806004)(83072002)(50466002)(92726001)(84676001)(85852003); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB733; H:P-EMF01-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02973C87BC Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ry10InJWfOKJ_nAseexu5mYyGek Cc: "mpls@ietf.org" , "pwe3-chairs@tools.ietf.org" , pwe3 Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:02:53 -0000 Loa, > Authors, Mingui, Stewart > > On 2014-08-08 04:46, Mingui Zhang wrote: > > Hi Stewart, > > > > I think authors would say the S-PE stitching method involves > > the control plane processing during the repair procedure. They > > emphasized their method uses data plane & local repair, which > > can be faster. > > Here, I want to raise one issue: > > It seems that we take it for granted that the method proposed on this > draft is faster than e.g. the e2e protection a la mpls-tp. Why is that? To answer your question let me quote from "Network Recovery" by JP Vasseur, Mario Pickavet, Piet Demeester (Section 5.8.1, page 336): With global protection, rerouting is performed by the head-end LSR, which means that this requires for the head-end LSR to receive the failure indication to reroute the affected traffic onto their respective backup paths (whose paths have been precomputed and signaled). So in terms of recovery time, the delta between global and local protection is the failure indication signal propagation time to the head-end LSR. Yakov. From nobody Fri Aug 8 07:15:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CD31B2AF4 for ; Fri, 8 Aug 2014 07:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 KzXZlR9Ei36N for ; Fri, 8 Aug 2014 07:15:42 -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 2123A1B29C5 for ; Fri, 8 Aug 2014 07:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5153; q=dns/txt; s=iport; t=1407507342; x=1408716942; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=yNGkzg6iNpVfdqFyrB0C/5gND8MyU88MRcbJyycNw7g=; b=E89dervqa4QMm/ZJn1aAATTH38hNINBJ1ZrB9LrRsgi+V27FB0FlH6oO uxoIroWho3QYwrwcrZeZfIceptT31QwJpJxgvbD2rSwlRSKktRAiDStXD j6jWqHcMaAVsie4JlQ/GPYolyG6xO1dFuvfuqrxtAX6T1nUZUDbNi1qYw E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAMna5FOtJV2d/2dsb2JhbABagw1SVwTMYAqGJ4EhAYETFneEAwEBAQQBAQE3MQMXAgQBCBEEAQEfBQQiDAsUCQgCBAESiEINxWATBASOZhEBVwaERQWRFIsRlHKCEYFGbIENOQ X-IronPort-AV: E=Sophos;i="5.01,825,1400025600"; d="scan'208";a="67644760" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 08 Aug 2014 14:15:41 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s78EFecP012409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 14:15:40 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.246]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 09:15:40 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Nobo Akiya (nobo)" , Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPschXiHIc3yovg0SKQvXLklkTc5vG06cA Date: Fri, 8 Aug 2014 14:15:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [161.44.213.29] Content-Type: text/plain; charset="us-ascii" Content-ID: <5350B9F1C8B92E4DAEF66ADEA722B680@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/OhRP0Oyz5z9oH6HQBgkQ7PJCyak Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:15:45 -0000 Thank you Nobo for the review of this draft. Agree with your comments and we will incorporate it in the next revision. Thanks again, Rakesh On 2014-08-06 6:46 PM, "Nobo Akiya (nobo)" wrote: >Hi Loa, > >I have read this document and support the adoption as a WG document. Not >only does this document reduce signaling messages for P2MP-TE >re-evaluation and re-optimization, it allow a mid-point LSR to >re-evaluate groups of S2L sub-LSPs together without some S2L sub-LSP >grouping heuristics, which is quite beneficial. > >I have few suggestions to authors, but all are not at all stoppers before >its WG adoption.=20 > > >1. This is a protocol extension that introduces new objects and >procedures, but the document lacks RFC2119 words (i.e. MAY, SHOULD, MUST, >etc). It would be highly beneficial to make use of RFC2119 words where >necessary (particularly in Sections 3 and 4). > > >2. Abstract, first paragraph, last sentence was slightly difficult to >read and had a typo. Suggested new text. > >[OLD] > Existing mechanisms allow the path re-evaluation and the > signaling of a the notification of preferred path exists for a single > S2L sub-LSP only. > >[NEW] > Existing mechanisms, a mechanism for a head-end LSR to > trigger a new path re-evaluation and a mechanism for a mid-point LSR > to signal an availability of a preferred path, operate on a single > S2L sub-LSP only. > > >3. Section 3, second paragraph. > >[snip] > An > ingress node may select one or more S2L sub-LSP of the P2MP-TE LSP > tree to trigger the re-evaluation request(s). >[snip] > >It may be beneficial to clarify the reason behind specifying one or more >S2L sub-LSPs, i.e. to specify the sub-groups. > > >4. Section 3, third paragraph. > >I'd like to propose a bit of rephrase in the last portion of this >sentence, for clarification purpose. > >[OLD] > A mid-point LSR that expands loose next-hop(s) for one or more S2L > sub-LSP path(s), and that receives a Path message with the "P2MP-TE > Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE > LSP tree by re-evaluating all S2L sub-LSP(s) expanded paths of the > P2MP-TE LSP. > >[NEW] > A mid-point LSR that expands loose next-hop(s) for one or more S2L > sub-LSP path(s), and that receives a Path message with the "P2MP-TE > Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE > LSP tree by re-evaluating all S2L sub-LSP(s) that are expanded paths > of the loose next-hop(s) of the P2MP-TE LSP. > > >5. Section 3, third paragraph (towards the end). > >[snip] > In this case, the mid-point LSR that expands loose next- > hop(s) for one or more S2L sub-LSP path(s) may select one or more S2L > sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to > the ingress node. >[snip] > >Similar to comment #3 above, it may be beneficial to clarify the reason >behind specifying one or more S2L sub-LSPs, i.e. to specify the >sub-groups. > > >6. There's also a typo in the Security Considerations section. > >[OLD] >it may be desirable for a a mid-point LSR to modify > >[NEW] >it may be desirable for a mid-point LSR to modify > >[NOTE] >s/a a /a / > > >Thanks! > >-Nobo > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Wednesday, July 30, 2014 6:10 AM >> To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN >> (MARTIN); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org >> Subject: [mpls] poll to see if we have support to make draft-tsaad-mpls- >> p2mp-loose-path-reopt an mpls wg doc >>=20 >> Working Group, >>=20 >> This is to start a two week poll on adopting >> draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group >> document. >>=20 >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls@ietf.org). Please give a technical motivation >>for >> your support/not support, especially if you think that the document >>should >> not be adopted as a working group document. >>=20 >> There is one IPR claim against this document. >>=20 >> The authors and contributors has stated on the working group mailing >>list >> that they are not aware of any other IPR claims against this draft. >>=20 >> However if you are on the the mpls working group mailing list and aware >>of >> IPR that relates to this draft, the time to disclose this is now. >>=20 >> This poll ends August 14, 2014. >>=20 >> /Loa >>=20 >> for the MPLS wg co-chairs >> -- >>=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 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From nobody Fri Aug 8 07:40:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F021B2ACA; Fri, 8 Aug 2014 07:40:48 -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, RP_MATCHES_RCVD=-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 MFdm5kTJm4ho; Fri, 8 Aug 2014 07:40:46 -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 F30481B2C08; Fri, 8 Aug 2014 07:40:45 -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 890211801586; Fri, 8 Aug 2014 16:40:44 +0200 (CEST) Message-ID: <53E4E16E.7050206@pi.nu> Date: Fri, 08 Aug 2014 16:40:46 +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: Yakov Rekhter References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> <53E498D4.6000107@pi.nu> <201408081402.s78E2kn63116@magenta.juniper.net> In-Reply-To: <201408081402.s78E2kn63116@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/826B8Vjy23X-pb8nlH9UTS5jn_Y Cc: "mpls@ietf.org" , "pwe3-chairs@tools.ietf.org" , pwe3 Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:40:48 -0000 Yakov, On 2014-08-08 16:02, Yakov Rekhter wrote: > Loa, > >> Authors, Mingui, Stewart >> >> On 2014-08-08 04:46, Mingui Zhang wrote: >>> Hi Stewart, >>> >>> I think authors would say the S-PE stitching method involves >>> the control plane processing during the repair procedure. They >>> emphasized their method uses data plane & local repair, which >>> can be faster. >>> Here, I want to raise one issue: >> >> It seems that we take it for granted that the method proposed on this >> draft is faster than e.g. the e2e protection a la mpls-tp. Why is that? > > To answer your question let me quote from "Network Recovery" by JP > Vasseur, Mario Pickavet, Piet Demeester (Section 5.8.1, page 336): > > With global protection, rerouting is performed by the head-end > LSR, which means that this requires for the head-end LSR to receive > the failure indication to reroute the affected traffic onto their > respective backup paths (whose paths have been precomputed and > signaled). So in terms of recovery time, the delta between global > and local protection is the failure indication signal propagation > time to the head-end LSR. > > Yakov. > Well, I won't argue that this is what is said in the book, but it is not what I asked about. mpls-tp runs e.g. 1:1 or 1:n, i.e. 1 working lsp (or pw) is protected by one or more pre-established lsp's or pw's. detection time can be as low as 10ms and the switch over is far shorter. While I understand that the draft is much more resource conservative, what is the foundation to claim that is faster? /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 8 08:04:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABC21B2C31; Fri, 8 Aug 2014 08:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNBgJB3LqGVa; Fri, 8 Aug 2014 08:04:35 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA011B2C2D; Fri, 8 Aug 2014 08:04:35 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id z10so7192917pdj.2 for ; Fri, 08 Aug 2014 08:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:mime-version:message-id:content-type; bh=vEATZZqdjzN+1yG7/hcqqxHwQzkK3tN0rYLxOh/GvQU=; b=Tutq1vXA+EPl09ryBV2UNw0KD1mDPS9OzXNNc5Wibc1Uz/WWMci0p58ER6kRZl9KwD QlYXJeR9O2eiQNsxS3ERFit98Nsgy5NpXzm5rH7yb2a2cb0jxyeZnRwndvr2ibUTHjE2 7AsCkCAchKN383Hg/7rLmPYuObyXRSQU9wpAkaXYyoWS7wnI3XdR7auQN8fDHhNhu9pU K//0IP1JKCKCcTdGMHAes8KqusQ4b8zTTnMB7N3uEukZNP5R85XenzYG+JHc1cq2oce4 oxkZbtc7ZztMkmrZ0w9rMIvxi+eIVQYxP30NRVvnOGb8EczjkzmiJCmerxwz4j7TIvKK H1lg== X-Received: by 10.70.118.9 with SMTP id ki9mr24843304pdb.104.1407510274971; Fri, 08 Aug 2014 08:04:34 -0700 (PDT) Received: from Lizhong-PC ([114.62.200.249]) by mx.google.com with ESMTPSA id qt2sm3283511pbb.29.2014.08.08.08.04.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Aug 2014 08:04:34 -0700 (PDT) Date: Fri, 8 Aug 2014 23:04:32 +0800 From: "Lizhong Jin" To: rtg-ads X-Priority: 3 X-GUID: 7AB829CD-0C92-4D4B-AEFF-DB1711572CCD X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2014080822341929710226@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart125340167708_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jpyP7vaoRa-MbG6_5zb2diD9bB8 Cc: draft-ietf-mpls-mldp-in-band-wildcard-encoding , rtg-dir , mpls Subject: [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 15:04:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart125340167708_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8NCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJl dmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3Mg dGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24g c3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUg YXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyDQpBbHRob3VnaCB0aGVzZSBjb21t ZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291 bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBv dGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZl IHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRy YWZ0Lg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbXBscy1tbGRwLWluLWJhbmQtd2lsZGNhcmQtZW5j b2RpbmctMDEgKG1MRFAgSW4tQmFuZCBTaWduYWxpbmcgd2l0aCBXaWxkY2FyZHMpDQpSZXZpZXdl cjogTGl6aG9uZyBKaW4NClJldmlldyBEYXRlOiBBdWcuIDgsIDIwMTQuDQpJRVRGIExDIEVuZCBE YXRlOiBBdWcuIDgsIDIwMTQuDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KU3Vt bWFyeToNCkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhh dCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQoNCkNvbW1l bnRzOg0KQmVmb3JlIFdHIGRyYWZ0IGFkb3B0aW9uLCBJIGFsc28gcmV2aWV3ZWQgdGhpcyBkcmFm dCBhcyBNUExTIFJUIHJldmlldy4gVGhpcyBkcmFmdCBzb2x2ZXMgYSByZWFsIHByb2JsZW0sIGFu ZCBpdCBpcyBlYXN5IHRvIHJlYWQgYW5kIHVuZGVyc3RhbmQuIEkgb25seSBoYXZlIHNvbWUgbWlu b3IgY29uY2VybnMgYW5kIHNvbWUgZWRpdG9yaWFsIGlzc3Vlcy4gDQoNCk1ham9yIElzc3VlczoN Ck5vbmUuDQoNCk1pbm9yIElzc3VlczogDQpTZWN0aW9uIDEgDQpXaGVuIGFuIE1QLUxTUCBpcyBi ZWluZyBzZXQgdXAsIHRoZSBwcm9jZWR1cmVzIG9mIFtSRkM2ODI2XSBhbmQgDQpbSS1ELmlldGYt bDN2cG4tbWxkcC12cmYtaW4tYmFuZC1zaWduYWxpbmddICwga25vd24gYXMgIm1MRFAgSW4tQmFu ZCANClNpZ25hbGluZyIsIGFsbG93IHRoZSBFZ3Jlc3MgTFNScyBvZiB0aGUgTVAtTFNQIHRvIGVu Y29kZSB0aGUgDQppZGVudGlmaWVyIG9mIGFuIElQIG11bHRpY2FzdCB0cmVlIGluIHRoZSAiT3Bh cXVlIFZhbHVlIiBmaWVsZCBvZiB0aGUgDQptTERQIEZFQyBFbGVtZW50IHRoYXQgaWRlbnRpZmll cyB0aGUgTVAtTFNQLiANCltMaXpob25nXSBUaGUgcmVmZXJlbmNlIFtJLUQuaWV0Zi1sM3Zwbi1t bGRwLXZyZi1pbi1iYW5kLXNpZ25hbGluZ10gc2hvdWxkIGJlIG1vdmVkIHRvIHRoZSBuZXh0IHNl Y3Rpb24sIHJpZ2h0PyBUaGlzIHNlY3Rpb24gaXMgdGFsa2luZyBhYm91dCBSRkM2ODI2LiANCg0K U2VjdGlvbiAzLjIgDQpQbGVhc2Ugbm90ZSB0aGF0LCBhcyBhbHdheXMsIHRoZSBzdHJ1Y3R1cmUg b2YgdGhlIE9wYXF1ZSANClZhbHVlIFRMVnMgZG9lcyBub3QgYWN0dWFsbHkgYWZmZWN0IHRoZSBv cGVyYXRpb24gb2YgbUxEUCwgYnV0IG9ubHkgDQphZmZlY3RzIHRoZSBpbnRlcmZhY2UgYmV0d2Vl biBtTERQIGFuZCBJUCBtdWx0aWNhc3QgYXQgdGhlIEluZ3Jlc3MgDQpMU1IuIA0KW0xpemhvbmdd IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBtTERQIGFuZCBJUCBtdWx0aWNhc3QgYXQgdGhlIGVncmVz cyBMU1IgaXMgYWxzbyBhZmZlY3RlZC4gU28gaXQgaXMgYmV0dGVyIHRvIHNheSAiLi4uYXQgdGhl IEluZ3Jlc3MgYW5kIEVncmVzcyBMU1IiLiANCg0KU2VjdGlvbiAzLjIgDQpOb3RlIHRoYXQgdGhl IEJpZGlyIFRMVnMgZG8gbm90IGhhdmUgYSAiU291cmNlIEFkZHJlc3MiIHN1Yi1maWVsZCwgDQph bmQgaGVuY2UgdGhlIG5vdGlvbiBvZiBhIHdpbGRjYXJkIHNvdXJjZSBpcyBub3QgYXBwbGljYWJs ZSB0byB0aGVtLiANCltMaXpob25nXSBzaW5jZSBCaWRpciBUTFYgaXMgb3V0IG9mIHRoZSBzY29w ZSwgdGhlbiBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIGhhdmUgdGhlIGFib3ZlIG5vdGUuIA0KDQpT ZWN0aW9uIDMuMyANCkhvd2V2ZXIsIGlmIGFuIEluZ3Jlc3MgTFNSIHN1cHBvcnRzIA0KW1JGQzY4 MjZdIGFuZC9vciBbSS1ELmlldGYtbDN2cG4tbWxkcC12cmYtaW4tYmFuZC1zaWduYWxpbmddLCBi dXQgDQpkb2VzIG5vdCBzdXBwb3J0IHRoaXMgZG9jdW1lbnQsIGl0IGhhcyBubyBjaG9pY2UgYnV0 IHRvIHRyZWF0IGFueSANCnN1Y2ggcmVjZWl2ZWQgRkVDIGVsZW1lbnRzIGFzIGludmFsaWQ7IHRo ZSBwcm9jZWR1cmVzIHNwZWNpZmllZCBpbiANCltSRkM2ODI2XSBhbmQgW0ktRC5pZXRmLWwzdnBu LW1sZHAtdnJmLWluLWJhbmQtc2lnbmFsaW5nXSBkbyBub3Qgd29yayANCndoZW4gdGhlIE9wYXF1 ZSB2YWx1ZXMgY29udGFpbiB6ZXJvZXMgaW4gdGhlIFNvdXJjZSBBZGRyZXNzIG9yIEdyb3VwIA0K QWRkcmVzcyBzdWItZmllbGRzLiANCltMaXpob25nXSBJIHdlbnQgdGhyb3VnaHQgUkZDNjgyNiBh bmQgUkZDNzI0NiwgdGhlcmUgaXMgbm8gZGVmaW5pdGlvbiBvZiAiemVyb2VzIi4gVGhlbiB0aGUg YWJvdmUgc3RhdGVtZW50IHdpbGwgYmUgdHJlYXRlZCBhcyBhbiB1cGRhdGUgdG8gUkZDNjgyNiBh bmQgUkZDNzI0Ni4gSWYgdGhhdCBpcyB0cnVlLCB0aGVuIHRoZSBkcmFmdCBoZWFkZXIgbmVlZHMg dG8gaW5kaWNhdGUgdGhhdCB1cGRhdGUuIA0KDQpTZWN0aW9uIDUuIA0KSWYgUElNIGlzIG5vdCBl bmFibGVkIGZvciB0aGUgaWRlbnRpZmllZCBncm91cCwgdGhlIEluZ3Jlc3MgTFNSIA0KYWN0cyBh cyBpZiBpdCBoYWQgcmVjZWl2ZWQgYSAoKixHKSBJR01QL01MRCByZXBvcnQgZnJvbSBhIA0KZG93 bnN0cmVhbSBub2RlLCBhbmQgdGhlIHByb2NlZHVyZXMgYXMgZGVmaW5lZCBpbiBbUkZDNDYwNV0g YXJlIA0KZm9sbG93ZWQuDQpbTGl6aG9uZ10gSXQgc2VlbXMgdGhlIGRhdGFwbGFuZSBwcm9jZXNz aW5nIGlzIG1pc3NpbmcgaGVyZS4gRS5nLiwgYWRkIHNvbWV0aGluZyBsaWtlLCB0aGUgaW5ncmVz cyBMU1Igc2hvdWxkIGZvcndhcmQgdGhlIHNwZWNpZmllZCBtdWx0aWNhc3Qgc3RyZWFtIHRvIHRo ZSBkb3duc3RyZWFtIG5vZGUgdGhyb3VnaCB0aGUgTVAtTFNQIGlkZW50aWZpZWQgYnkgdGhlIE9w YXF1ZSBWYWx1ZSBUTFYuIFRoYXQgaXMgbm90IGRlc2NyaWJlZCBpbiBSRkM0NjA1Lg0KDQpOaXRz Og0KU2VjdGlvbiAxLg0Kcy91c2luZy91c2UNCg0KU2VjdGlvbiAxIGlzIGEgYml0IHRvbyBsb25n LCBhbmQgaW5jbHVkZSBib3RoIGludHJvZHVjdGlvbiBhbmQgcHJvYmxlbSBzdGF0ZW1lbnQuIEl0 IGlzIHN1Z2dlc3RlZCB0byBzZXBhcmF0ZSB0d28gc2VjdGlvbnMuIEJ1dCBJIHdpbGwgbm90IG9i amVjdCBpZiB5b3Ugd2FudCB0byBrZWVwIGl0LiANCg0KU2VjdGlvbiA0LjINCnMvbmVzc2VzYXJ5 L25lY2Vzc2FyeQ0KIA0KUmVnYXJkcw0KTGl6aG9uZyBKaW4NCg== ------=_001_NextPart125340167708_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
=

Hello

I hav= e been selected as the Routing Directorate reviewer for this draft. The Ro= uting Directorate seeks to review all routing or routing-related drafts as= they pass through IETF last call and IESG review, and sometimes on specia= l request. The purpose of the review is to provide assistance to the Routi= ng ADs.  For more information about the Routing Directorate, please s= ee =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/Rt= gDir

Although these= comments are primarily for the use of the Routing ADs, it would be helpfu= l 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 upda= ting the draft.

Documen= t: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01 (mLDP In-Band Signaling with Wildcards)
= Reviewer: Lizhong Jin
Review Date: Aug. 8, 2014.
IETF LC End Date: A= ug. 8, 2014.
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I thi= nk should be resolved before publication.

<= br>

Comments:

Before WG draft adoption, I also reviewed this draft as MPLS RT = review. This draft solves a real problem, and it is easy to read and under= stand. I only have some minor concerns and some editorial issues. 


Major Issues:

None.

Minor Issues: 

Section 1=0A
When an MP-LSP is being set up, the procedures of [RFC6= 826] and=0A
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] , known as "= mLDP In-Band=0A
Signaling", allow the Egress LSRs of the MP-LSP to e= ncode the=0A
identifier of an IP multicast tree in the "Opaque Value= " field of the=0A
mLDP FEC Element that identifies the MP-LSP.=0A[Lizhong] The reference [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] shoul= d be moved to the next section, right? This section is talking about RFC68= 26.=0A
=0A
Section 3.2=0A
Please note that, as always, the struct= ure of the Opaque=0A
Value TLVs does not actually affect the operati= on of mLDP, but only=0A
affects the interface between mLDP and IP mu= lticast at the Ingress =0A
LSR.=0A
[Lizhong] the interface betwee= n mLDP and IP multicast at the egress LSR is also affected. So it is bette= r to say "...at the Ingress and Egress LSR".=0A
=0A
Section 3.2=0A Note that the Bidir TLVs do not have a "Source Address" sub-field,=0A=
and hence the notion of a wildcard source is not applicable to them= .=0A
[Lizhong] since Bidir TLV is out of the scope, then it is not nece= ssary to have the above note.=0A
=0A
Section 3.3=0A
However, if a= n Ingress LSR supports=0A
[RFC6826] and/or [I-D.ietf-l3vpn-mldp-vrf-= in-band-signaling], but=0A
does not support this document, it has no= choice but to treat any=0A
such received FEC elements as invalid; t= he procedures specified in=0A
[RFC6826] and [I-D.ietf-l3vpn-mldp-vrf= -in-band-signaling] do not work=0A
when the Opaque values contain ze= roes in the Source Address or Group=0A
Address sub-fields.=0A
[Li= zhong] I went throught RFC6826 and RFC7246, there is no definition of "zer= oes". Then the above statement will be treated as an update to RFC6826 and= RFC7246. If that is true, then the draft header needs to indicate that up= date.=0A
=0A
Section 5.=0A
If PIM is= not enabled for the identified group, the Ingress LSR 

= acts as if it had received a (*,G) IGMP/MLD report from a=0A
= downstream node, and the procedures as defined in [RFC4605] are=0A
= followed.

[Lizhong] It seems the dataplane p= rocessing is missing here. E.g., add something like, the ingress LSR shoul= d forward the specified multicast stream to the downstream node through th= e MP-LSP identified by the Opaque Value TLV. That is not = described in RFC4605.

=0A


Nits:

Section 1.

s/using/use

Section 1 is a bit too long, and = include both introduction and problem statement. It is suggested to separa= te two sections. But I will not object if you want to keep it. 


Section 4.2

s/nessesary/necessary

<= p class=3D"MsoCommentText" style=3D"margin: 0px 0cm; font-size: 10.5pt; fo= nt-family: Calibri, sans-serif;"> 

=0A
=0A
=0A
= Regards
Lizhong= Jin
=0A ------=_001_NextPart125340167708_=------ From nobody Fri Aug 8 08:37:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1011B2BA6; Fri, 8 Aug 2014 08:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 RqrPOp7kYTeF; Fri, 8 Aug 2014 08:37:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4073A1B2AF2; Fri, 8 Aug 2014 08:37:27 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 8 Aug 2014 15:37:25 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 15:37:25 +0000 From: Yimin Shen To: Mingui Zhang , "Stewart Bryant (stbryant)" Thread-Topic: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 Thread-Index: AQHPshD/uYiweJIOHUOm1CPA/rtgVpvGAdgAgADUDSA= Date: Fri, 8 Aug 2014 15:37:24 +0000 Message-ID: <35b809ce6fa34dd09844dddce13a6203@BY2PR05MB728.namprd05.prod.outlook.com> References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(13464003)(377454003)(51704005)(189002)(24454002)(199002)(20776003)(15975445006)(95666004)(107046002)(76482001)(105586002)(33646002)(93886004)(2656002)(83072002)(87936001)(81342001)(85852003)(80022001)(92566001)(64706001)(86362001)(106356001)(74316001)(106116001)(79102001)(85306004)(77982001)(101416001)(99286002)(46102001)(81542001)(21056001)(74662001)(31966008)(74502001)(50986999)(99396002)(76176999)(54356999)(76576001)(19580405001)(83322001)(66066001)(19580395003)(4396001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB725; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX: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/mpls/KfbDUfhvhsDZAUxjd7-vRBCDsk0 Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 15:37:29 -0000 Hi Mingui, Thanks for the comments. Please see inline... Thanks, /Yimin -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mingui Zhang Sent: Thursday, August 07, 2014 10:47 PM To: Stewart Bryant (stbryant) Cc: mpls@ietf.org; pwe3; pwe3-chairs@tools.ietf.org Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-p= rotection-01 - RFC4447 Hi Stewart, I think authors would say the S-PE stitching method involves the control pl= ane processing during the repair procedure. They emphasized their method us= es data plane & local repair, which can be faster. Here, I want to raise one issue:=20 If the primary PE fails and the PLR redirects the traffic during the flying= of the packets, hoping the backup PE delivers the packets immediately. Thi= s means the AC at the backup PE side is also ACTIVE. So the CE has active-a= ctive connections to both egress PEs. This is obviously different from the = PW-RED's active-standby mechanism [RFC6718]. Will this difference bring us = the frame duplication issue? I think we need to address this in the updated= version.=20 [yshen] Don't confuse the backup PW in this document with the standby PW in= RFC 6718. Each active or standby PW in RFC 6718 could be protected by a ba= ckup PW specified in this draft, if that's intended. There shouldn't be any= packet duplication during local repair, because PLR only sends packets to = protector. Thanks, Mingui >-----Original Message----- >From: Stewart Bryant (stbryant) [mailto:stbryant@cisco.com] >Sent: Thursday, August 07, 2014 3:27 PM >To: Mingui Zhang >Cc: Eric Rosen (erosen); Alexander Vainshtein; mpls@ietf.org; pwe3;=20 >pwe3-chairs@tools.ietf.org >Subject: Re: [PWE3] [mpls] WG Last Call for >draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 > > > >Sent from my iPad > >> On 7 Aug 2014, at 04:57, "Mingui Zhang" wrote: >> >> Hi Eric, >> >> The explanation of the story is very clear. Let me complement a bit. >> >>> - A "primary egress PE" partitions its set of PWs into n sets, where=20 >>> each set is associated with a given "protector". The "protector" is=20 >>> the backup egress PE for those PWs. >> >> When the backup PE acts as the protector, it is the 'co-located' model. > >This case does not however need context labels. It is a form of S-PE=20 >and can stitch the PWs just like every existing S-PE already does. > >Stewart > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Aug 8 10:19:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C778F1B2B72 for ; Fri, 8 Aug 2014 10:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 ZQjbU934kjsF for ; Fri, 8 Aug 2014 10:19:31 -0700 (PDT) Received: from server.isocore.com (server.isocore.com [192.163.204.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834D21B2866 for ; Fri, 8 Aug 2014 10:19:31 -0700 (PDT) Received: from c-69-255-21-48.hsd1.va.comcast.net ([69.255.21.48]:52294 helo=adminPCR) by server.isocore.com with esmtpa (Exim 4.82) (envelope-from ) id 1XFnpB-00029A-A7 for mpls@ietf.org; Fri, 08 Aug 2014 17:19:30 +0000 From: "Shamjhana" To: Date: Fri, 8 Aug 2014 13:19:26 -0400 Message-ID: <001801cfb32c$e88a62b0$b99f2810$@isocore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CFB30B.6179D420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+zLNzNrOQooK5mQU2NPFq1WLFqbA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.isocore.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Get-Message-Sender-Via: server.isocore.com: authenticated_id: spokharel@isocore.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/O0fuY0uiThLX-HOGPd5eAWOI5_M Subject: [mpls] SDN/MPLS 2014 Conference Information X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:19:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01CFB30B.6179D420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SDN/MPLS 2014 Conference program has already been posted. It is available at http://www.isocore.com/sdn-mpls/ or specifically at: Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions.htm The conference will take place November 2-5 in Washington DC and will include an extensive four day program consisting of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this year's conference include: Virtualization, SDN, Cloud and Data Centers, NFV, PCE, Mobility, Traffic Engineering Transport SDN, Orchestration, multi-play applications across common infrastructure and other Emerging Technologies. The conference hotel is the Marriott Wardman Park in Washington DC. Please note that there are only a limited number of rooms available this year at a reduced rate. Please make reservations at: https://resweb.passkey.com/Resweb.do?mode=welcome_gi_new &groupID=25088120 ------=_NextPart_000_0019_01CFB30B.6179D420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = SDN/MPLS 2014 Conference program has already been posted. It is = available
 at http://www.isocore.com/sdn-mpls= /   or specifically at:

Tutorials (Sunday): = http://www.isocore= .com/sdn-mpls/tutorials.htm
Technical sessions (Mon- Wed): = http://ww= w.isocore.com/sdn-mpls/technical_sessions.htm

The conference = will take place November 2-5 in Washington DC and will
include an = extensive four day program consisting of tutorials, = technical
sessions, panels, and exhibits. The key topics to be = discussed at this
year's conference include: Virtualization, SDN, = Cloud and Data Centers, NFV,
PCE, Mobility, Traffic Engineering = Transport SDN, Orchestration,
multi-play applications across common = infrastructure and other Emerging Technologies.

The conference = hotel is the Marriott Wardman Park in Washington DC. Please
note that = there are only a limited number of rooms available this year at = a
reduced rate. Please make reservations at:
https://resweb.passkey.com/Resweb.do?mode=3Dwelcome_gi_= new&groupID=3D25088120


------=_NextPart_000_0019_01CFB30B.6179D420-- From nobody Fri Aug 8 11:21:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41581A0019 for ; Fri, 8 Aug 2014 11:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Wr-pLdnluoMl for ; Fri, 8 Aug 2014 11:21:19 -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 B69C71A002C for ; Fri, 8 Aug 2014 11:19:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIB11147; Fri, 08 Aug 2014 18:19:56 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Aug 2014 19:19:55 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 11:19:51 -0700 From: Huaimo Chen To: "Nobo Akiya (nobo)" , Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95rImggRj2O606yVQkBKC47nZvCdOXggAScpWA= Date: Fri, 8 Aug 2014 18:19:51 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C90A7C@SJCEML702-CHM.china.huawei.com> References: <53D8C464.6040403@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.212.244.66] 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/mpls/6e1PDZaxnxvZjoVkCqcZJeFfTbg Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:21:23 -0000 Support it. Best Regards, Huaimo -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo) Sent: Wednesday, August 06, 2014 6:47 PM To: Loa Andersson; mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MA= RTIN (MARTIN); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls= -p2mp-loose-path-reopt an mpls wg doc Hi Loa, I have read this document and support the adoption as a WG document. Not on= ly does this document reduce signaling messages for P2MP-TE re-evaluation a= nd re-optimization, it allow a mid-point LSR to re-evaluate groups of S2L s= ub-LSPs together without some S2L sub-LSP grouping heuristics, which is qui= te beneficial. I have few suggestions to authors, but all are not at all stoppers before i= ts WG adoption.=20 1. This is a protocol extension that introduces new objects and procedures,= but the document lacks RFC2119 words (i.e. MAY, SHOULD, MUST, etc). It wou= ld be highly beneficial to make use of RFC2119 words where necessary (parti= cularly in Sections 3 and 4). 2. Abstract, first paragraph, last sentence was slightly difficult to read = and had a typo. Suggested new text. [OLD] Existing mechanisms allow the path re-evaluation and the signaling of a the notification of preferred path exists for a single S2L sub-LSP only. [NEW] Existing mechanisms, a mechanism for a head-end LSR to trigger a new path re-evaluation and a mechanism for a mid-point LSR to signal an availability of a preferred path, operate on a single S2L sub-LSP only. 3. Section 3, second paragraph. [snip] An ingress node may select one or more S2L sub-LSP of the P2MP-TE LSP tree to trigger the re-evaluation request(s). [snip] It may be beneficial to clarify the reason behind specifying one or more S2= L sub-LSPs, i.e. to specify the sub-groups. 4. Section 3, third paragraph. I'd like to propose a bit of rephrase in the last portion of this sentence,= for clarification purpose. [OLD] A mid-point LSR that expands loose next-hop(s) for one or more S2L sub-LSP path(s), and that receives a Path message with the "P2MP-TE Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE LSP tree by re-evaluating all S2L sub-LSP(s) expanded paths of the P2MP-TE LSP. [NEW] A mid-point LSR that expands loose next-hop(s) for one or more S2L sub-LSP path(s), and that receives a Path message with the "P2MP-TE Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE LSP tree by re-evaluating all S2L sub-LSP(s) that are expanded paths of the loose next-hop(s) of the P2MP-TE LSP. 5. Section 3, third paragraph (towards the end). [snip] In this case, the mid-point LSR that expands loose next- hop(s) for one or more S2L sub-LSP path(s) may select one or more S2L sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the ingress node. [snip] Similar to comment #3 above, it may be beneficial to clarify the reason beh= ind specifying one or more S2L sub-LSPs, i.e. to specify the sub-groups. 6. There's also a typo in the Security Considerations section. [OLD] it may be desirable for a a mid-point LSR to modify [NEW] it may be desirable for a mid-point LSR to modify [NOTE] s/a a /a / Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Wednesday, July 30, 2014 6:10 AM > To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN=20 > (MARTIN); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org > Subject: [mpls] poll to see if we have support to make=20 > draft-tsaad-mpls- p2mp-loose-path-reopt an mpls wg doc >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group=20 > document. >=20 > Please send your comments (support/not support) to the mpls working=20 > group mailing list (mpls@ietf.org). Please give a technical motivation=20 > for your support/not support, especially if you think that the=20 > document should not be adopted as a working group document. >=20 > There is one IPR claim against this document. >=20 > The authors and contributors has stated on the working group mailing=20 > list that they are not aware of any other IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and=20 > aware of IPR that relates to this draft, the time to disclose this is now= . >=20 > This poll ends August 14, 2014. >=20 > /Loa >=20 > for the MPLS wg co-chairs > -- >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Aug 8 11:46:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7621A00AE for ; Fri, 8 Aug 2014 11:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 mIN4Q8Bxy6vD for ; Fri, 8 Aug 2014 11:46:31 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA9A1A00AF for ; Fri, 8 Aug 2014 11:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1268; q=dns/txt; s=iport; t=1407523589; x=1408733189; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fD427Pv7YpkaRrpN/6Q2wpSF7ypLrstndEknU+E1cuE=; b=O7PVz0m37itAvSflOzGtRWdswhkOXteK0tDtNuNtk/Rr/1Ay0ybeUUXg xEiNWRxsV0dAMg/qXQKg9KHGr3Rs7hYgu4YU9oiVVhikwLDtPRe4Ktm8W Cr4iTD2zottbTPpV/ZlN6sqYDhZWKJB1OcL7HcSQJWl1iTdmcjfUtJ/ze o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFABca5VOtJV2d/2dsb2JhbABagw1SVwTMYgqGJ4EhAYEVFneEBAEBAwEBAQE3MQMLBQkCAgEIIhQFCxsMCyUCBAENBQiIMggNxXATBASOZhEBHzEHgy+BHAWRFqALghGBRmyBDjk X-IronPort-AV: E=Sophos;i="5.01,826,1400025600"; d="scan'208";a="346151683" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 08 Aug 2014 18:46:28 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s78IkSZ9005809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 18:46:28 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.65]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 13:46:27 -0500 From: "Matt Hartley (mhartley)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95rRdaBc1hWp0SwrWziVfLJYZvHGiFw Date: Fri, 8 Aug 2014 18:46:27 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC14A18036@xmb-rcd-x03.cisco.com> References: <53D8C464.6040403@pi.nu> In-Reply-To: <53D8C464.6040403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dLZaAuGzGJOuFRUg-8R4oJ3qCIA Cc: "Matt Hartley \(mhartley\)" Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:46:38 -0000 Support Cheers Matt > Working Group, >=20 > This is to start a two week poll on adopting > draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group > document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > There is one IPR claim against this document. >=20 > The authors and contributors has stated on the working group mailing > list that they are not aware of any other IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. >=20 > This poll ends August 14, 2014. >=20 > /Loa >=20 > for the MPLS wg co-chairs > -- >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Aug 8 11:49:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B310E1A00E7 for ; Fri, 8 Aug 2014 11:49:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpYWculbK-bL for ; Fri, 8 Aug 2014 11:49:29 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181A21A00C2 for ; Fri, 8 Aug 2014 11:49:29 -0700 (PDT) Received: from [216.82.242.131:33801] by server-4.bemta-8.messagelabs.com id 24/CC-02474-7BB15E35; Fri, 08 Aug 2014 18:49:27 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-7.tower-76.messagelabs.com!1407523766!42034644!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8280 invoked from network); 8 Aug 2014 18:49:27 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-7.tower-76.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Aug 2014 18:49:27 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02", Issuer "USIDCWVEHT02" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 84EFB1DED0; Fri, 8 Aug 2014 18:49:26 +0000 (GMT) Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by USIDCWVEHT02.corp.global.level3.com ([::1]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 12:49:26 -0600 From: "Osborne, Eric" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95lBoeHEJmVsUq/9opHJpGxMpvHGydg Date: Fri, 8 Aug 2014 18:49:26 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDF0DA4F@USIDCWVEMBX08.corp.global.level3.com> References: <53D8C464.6040403@pi.nu> In-Reply-To: <53D8C464.6040403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.141.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BYplM2YJsaP1PCFM3ovWS6fku1c Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:49:36 -0000 Support; this solves a real problem. eric -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, July 30, 2014 6:10 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); = draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org Subject: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2m= p-loose-path-reopt an mpls wg doc Working Group, This is to start a two week poll on adopting draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group document= . Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. There is one IPR claim against this document. The authors and contributors has stated on the working group mailing list t= hat they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends August 14, 2014. /Loa for the MPLS wg co-chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Aug 8 12:28:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE001A038C; Fri, 8 Aug 2014 12:28:15 -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 6UBwx2DhBaGB; Fri, 8 Aug 2014 12:28:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628421A0380; Fri, 8 Aug 2014 12:28:13 -0700 (PDT) Received: from BL2PR05CA0013.namprd05.prod.outlook.com (10.255.226.13) by BY2PR05MB727.namprd05.prod.outlook.com (10.141.223.23) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 8 Aug 2014 19:28:10 +0000 Received: from BY2FFO11FD023.protection.gbl (2a01:111:f400:7c0c::189) by BL2PR05CA0013.outlook.office365.com (2a01:111:e400:c04::13) with Microsoft SMTP Server (TLS) id 15.0.1005.10 via Frontend Transport; Fri, 8 Aug 2014 19:28:09 +0000 Received: from P-EMF01-SAC.jnpr.net (66.129.239.15) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Fri, 8 Aug 2014 19:28:09 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 8 Aug 2014 12:27:34 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s78JRXn08948; Fri, 8 Aug 2014 12:27:33 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201408081927.s78JRXn08948@magenta.juniper.net> To: Loa Andersson In-Reply-To: <53E4E16E.7050206@pi.nu> References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> <53E498D4.6000107@pi.nu> <201408081402.s78E2kn63116@magenta.juniper.net> <53E4E16E.7050206@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Fri, 08 Aug 2014 16:40:46 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4085.1407526053.1@juniper.net> Date: Fri, 8 Aug 2014 12:27:33 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.15; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(51704005)(377424004)(24454002)(199002)(189002)(4396001)(102836001)(81156004)(106466001)(105596002)(95666004)(6806004)(107046002)(69596002)(110136001)(80022001)(81342001)(44976005)(76482001)(83322001)(77982001)(92566001)(68736004)(83072002)(84676001)(85852003)(21056001)(23726002)(31966008)(16796002)(87936001)(46406003)(97736001)(97756001)(79102001)(81542001)(50986999)(47776003)(54356999)(76176999)(99396002)(92726001)(46102001)(74502001)(74662001)(86362001)(85306004)(93886004)(64706001)(20776003)(50466002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB727; H:P-EMF01-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 02973C87BC Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kYAj85oXZJRSoT9rosslQJFjx0g Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:28:15 -0000 Loa, > Yakov, > > On 2014-08-08 16:02, Yakov Rekhter wrote: > > Loa, > > > >> Authors, Mingui, Stewart > >> > >> On 2014-08-08 04:46, Mingui Zhang wrote: > >>> Hi Stewart, > >>> > >>> I think authors would say the S-PE stitching method involves > >>> the control plane processing during the repair procedure. They > >>> emphasized their method uses data plane & local repair, which > >>> can be faster. > >>> Here, I want to raise one issue: > >> > >> It seems that we take it for granted that the method proposed on this > >> draft is faster than e.g. the e2e protection a la mpls-tp. Why is that? > > > > To answer your question let me quote from "Network Recovery" by JP > > Vasseur, Mario Pickavet, Piet Demeester (Section 5.8.1, page 336): > > > > With global protection, rerouting is performed by the head-end > > LSR, which means that this requires for the head-end LSR to receive > > the failure indication to reroute the affected traffic onto their > > respective backup paths (whose paths have been precomputed and > > signaled). So in terms of recovery time, the delta between global > > and local protection is the failure indication signal propagation > > time to the head-end LSR. > > > > Yakov. > > > > Well, I won't argue that this is what is said in the book, but it is > not what I asked about. > > mpls-tp runs e.g. 1:1 or 1:n, i.e. 1 working lsp (or pw) is protected > by one or more pre-established lsp's or pw's. detection time can be > as low as 10ms and the switch over is far shorter. > > While I understand that the draft is much more resource conservative, > what is the foundation to claim that is faster? Local protection does not involve propagating failure indication beyond the point of failure. Do you think that the detection time at the head-end can be less than the time it takes to propagate failure indication from the point of failure to the head-end ? Furhermore, even if we assume that for some topologies the propagation time could be 10ms, could it be 10ms irrespective of the distance and the number of hops spanned by a PW ? Yakov. From nobody Fri Aug 8 12:45:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4102A1A038C for ; Fri, 8 Aug 2014 12:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dkOQZQCzflFM for ; Fri, 8 Aug 2014 12:45:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD781A034E for ; Fri, 8 Aug 2014 12:45:14 -0700 (PDT) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 19:45:12 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.210]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.210]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 19:45:12 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "huaimo.chen@huawei.com" Thread-Topic: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt Thread-Index: Ac+zQNp9tF2TFdkGTPisCwwe9MXEzg== Date: Fri, 8 Aug 2014 19:45:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(229853001)(21056001)(107046002)(2351001)(4396001)(99396002)(33646002)(92566001)(87936001)(85852003)(77096002)(95666004)(85306004)(83072002)(50986999)(106356001)(54356999)(105586002)(99286002)(101416001)(76576001)(20776003)(74316001)(66066001)(77982001)(64706001)(81342001)(46102001)(79102001)(80022001)(74502001)(31966008)(2656002)(110136001)(83322001)(81542001)(76482001)(86362001)(74662001)(2501001)(24736002)(108616003)(554374003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB079; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX: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/mpls/TWDYfScXIyU5rGaKZXpe8Xba74w Cc: "mpls@ietf.org" Subject: [mpls] Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:45:16 -0000 Huaimo, I have some questions and comments on the draft. I only started looking int= o this now so some of these might have been discussed before. In that case,= you can just refer me to some old email in the archive for me to go throug= h. One big question I have is about the following: After receiving the Path message with the EGRESS_BACKUP, the primary egress includes the information about the primary LSP label in the Resv message with an EGRESS_BACKUP object as UA label. When the PLR receives the Resv message with the information about the UA label, it includes the information in the Path message for the backup LSP to the backup egress. Thus the primary LSP label as UA label is sent to the backup egress from the primary egress. When the PLR detects the failure of the primary egress, it redirects the packets from the primary LSP into the backup LSP to backup egress using the primary LSP label from the primary egress as an inner label. The backup egress delivers the packets to the same destinations as the primary egress using the backup LSP label as context label and the inner label as UA label. In the above text, the inner label is not service label like VPN/PWE3 label= . It is the transport label assigned by the primary egress and relayed by t= he PLR to egress. How does the backup know what to do with that transport l= abel and the application (e.g. vpn) label that follows it? In other places, it talks about using BGP or some other protocols to distri= bute service labels and that seems reasonable. I suppose the above text is = not correct? The other big question is, compared to ingress signaling those additional f= lags and backup egress address via PATH messages, wouldn't it be easier for= the primary egress to signal via RESV message to the PLR that it wants egr= ess protection, and optionally specify the backup egress address? That way,= the ingress and transit nodes are not bothered at all. I'll leave out some smaller questions/comments for now. Thanks. Jeffrey From nobody Sat Aug 9 01:51:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553761A0564 for ; Sat, 9 Aug 2014 01:51:56 -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, RP_MATCHES_RCVD=-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 hRqV2Iljq_i4 for ; Sat, 9 Aug 2014 01:51:54 -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 254141A036F for ; Sat, 9 Aug 2014 01:51:53 -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 014A91801586; Sat, 9 Aug 2014 10:51:51 +0200 (CEST) Message-ID: <53E5E12A.9090107@pi.nu> Date: Sat, 09 Aug 2014 10:51:54 +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: "mpls@ietf.org" References: <53D16CD2.1090702@pi.nu> In-Reply-To: <53D16CD2.1090702@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/u_4r4ojz63a2QyrjSZdPQ9PdauI Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ipv6-only-gap@tools.ietf.org" Subject: Re: [mpls] draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 08:51:56 -0000 Working Group, This last call has been closed! There have been comments, can the authors please address the comments and post a new version of the document. /Loa mpls wg co-chair On 2014-07-24 22:30, Loa Andersson wrote: > > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-ipv6-only-gap-01. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures against this document. The authors have > stated that they are unaware of any IPRs related to this document. > > This working group last call ends August 8, 2014.. > > We have requested a routing area directorate review that has the same > target date. > > /Loa > for the MPLS wg chairs > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Aug 9 04:22:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7421B27B7; Sat, 9 Aug 2014 04:22:16 -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, RP_MATCHES_RCVD=-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 MqYPAMrS9X8c; Sat, 9 Aug 2014 04:22:14 -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 3A1ED1B27B2; Sat, 9 Aug 2014 04:22:14 -0700 (PDT) Received: from [192.168.0.123] (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 C456A1801586; Sat, 9 Aug 2014 13:22:12 +0200 (CEST) Message-ID: <53E60466.9000008@pi.nu> Date: Sat, 09 Aug 2014 13:22:14 +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: Yakov Rekhter References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> <53E498D4.6000107@pi.nu> <201408081402.s78E2kn63116@magenta.juniper.net> <53E4E16E.7050206@pi.nu> <201408081927.s78JRXn08948@magenta.juniper.net> In-Reply-To: <201408081927.s78JRXn08948@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_IppYU_CeDy_2g8Ka84zlrDci9U Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 11:22:16 -0000 Yakov, On 2014-08-08 21:27, Yakov Rekhter wrote: > Loa, > >> Yakov, >> >> On 2014-08-08 16:02, Yakov Rekhter wrote: >>> Loa, >>> >>>> Authors, Mingui, Stewart >>>> >>>> On 2014-08-08 04:46, Mingui Zhang wrote: >>>>> Hi Stewart, >>>>> >>>>> I think authors would say the S-PE stitching method involves >>>>> the control plane processing during the repair procedure. They >>>>> emphasized their method uses data plane & local repair, which >>>>> can be faster. >>>>> Here, I want to raise one issue: >>>> >>>> It seems that we take it for granted that the method proposed on this >>>> draft is faster than e.g. the e2e protection a la mpls-tp. Why is that? >>> >>> To answer your question let me quote from "Network Recovery" by JP >>> Vasseur, Mario Pickavet, Piet Demeester (Section 5.8.1, page 336): >>> >>> With global protection, rerouting is performed by the head-end >>> LSR, which means that this requires for the head-end LSR to receive >>> the failure indication to reroute the affected traffic onto their >>> respective backup paths (whose paths have been precomputed and >>> signaled). So in terms of recovery time, the delta between global >>> and local protection is the failure indication signal propagation >>> time to the head-end LSR. >>> >>> Yakov. >>> >> >> Well, I won't argue that this is what is said in the book, but it is >> not what I asked about. >> >> mpls-tp runs e.g. 1:1 or 1:n, i.e. 1 working lsp (or pw) is protected >> by one or more pre-established lsp's or pw's. detection time can be >> as low as 10ms and the switch over is far shorter. >> >> While I understand that the draft is much more resource conservative, >> what is the foundation to claim that is faster? > > Local protection does not involve propagating failure indication > beyond the point of failure. > > Do you think that the detection time at the head-end can be less > than the time it takes to propagate failure indication from the > point of failure to the head-end ? > > Furhermore, even if we assume that for some topologies the propagation > time could be 10ms, could it be 10ms irrespective of the distance > and the number of hops spanned by a PW ? > > Yakov. > MPLS-TP style protection does not involve propagating (i.e. does not involve sending a a failure indication from the point of detection to the head end). The failure at the head end is e.g. detected if you loose three consecutive keep alive message traveling in the data plane. If you send one keep-alive message every 3.3 msec, you can reach a time to repair this is - detection time (approximately 10 ms) - transfer time (typically usec's) - switchover time (good guess is approximately 10 ms) MPLS-TP protection was designed to met the 50 msec requirement, it is my guess that is about the same as what this draft achieves. Note that I'm not say that the protection mechanism described is "bad" or "slow", to the contrary I think it is both useful and fast, only that we are talking of time to repair for the to mechanisms. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Aug 9 04:40:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86DB1B27C4; Sat, 9 Aug 2014 04:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1y-oKcmJiig; Sat, 9 Aug 2014 04:40:46 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D145D1B27C2; Sat, 9 Aug 2014 04:40:45 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so6612912wes.35 for ; Sat, 09 Aug 2014 04:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=t+A3WbV2KaW3YExBhGJ/005Ye8CexWp7rz5HGveB6s0=; b=Ly2BTjTL9/AQGLB7/Wm0ZvIx2w7vNnbrI5aCu+7l5mbhfsuZ4iRLVjg96GnbztfSWn GM3MkyMBnIqXsxwQjxJhy8IiiuX4HRspqVwt2bEhG5YlOHIy/Is13xRlTQBEOuwxW4re Zr7X8RNi52L/D09yjuBSRqgv6FK+0ZAtzus7O/UgLpWay/6PHG3rbtdBiJtQ1JttEhCz G+cw6U11vbrwoo30CQ0u59sGK6v2hry7QsEBff8hORKspo28GNNOb97knBgqJZc9EAP3 xhktBuF1HBnaHAo1cV+ikt+49RVTi49eu5MmMmQDPlWrivOPSSVK9acgO1F1B0mc4jeq 5c7A== X-Received: by 10.194.237.194 with SMTP id ve2mr38930416wjc.89.1407584444349; Sat, 09 Aug 2014 04:40:44 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id w14sm1016678wij.2.2014.08.09.04.40.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Aug 2014 04:40:43 -0700 (PDT) Message-ID: <53E608B8.3060203@gmail.com> Date: Sat, 09 Aug 2014 13:40:40 +0200 From: Huub van Helvoort 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: Yimin Shen References: Your message of Tue, 05 Aug 2014 13:59:49 -0000. <9696d0db139d46ffaad7be11340215e8@AM3PR03MB612.eurprd03.prod.outlook.com> <16167.1407340459@erosen-lnx>, <4552F0907735844E9204A62BBDD325E76AAAA7F4@nkgeml512-mbx.china.huawei.com> <22D4AECA-2D36-4F79-98CB-96E4B9BDC126@cisco.com> <4552F0907735844E9204A62BBDD325E76AAAB6F9@nkgeml512-mbx.china.huawei.com> <53E498D4.6000107@pi.nu> <496a2c137775477c8c78c7e8d5463c6e@BY2PR05MB728.namprd05.prod.outlook.com> In-Reply-To: <496a2c137775477c8c78c7e8d5463c6e@BY2PR05MB728.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UHOVGkMmoD4Cb-M37h_420FtlBY Cc: "mpls@ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 11:40:48 -0000 Hello Yimin, You wrote: > It will not be a problem if this mechanism and an e2e mechanism > are both implemented in a network. As described in the draft, > this mechanism provides local repair, and it is viewed as a > temporary repair. The draft strongly recommend this mechanism > to be used in tandem with an e2e or global repair mechanism, > so that the later can eventually move traffic from the locally > repaired PW over to a fully functional PW, as a permanent repair. How do you warrant that all the repair mechanisms present do not decide to switch at the same time? This would result in unpredictable repairs. So some coordination between the repair mechanisms is required. regards, Huub. > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, August 08, 2014 5:31 AM > To: Mingui Zhang; Stewart Bryant (stbryant) > Cc: mpls@ietf.org; Eric Rosen (erosen); pwe3; pwe3-chairs@tools.ietf.org > Subject: Re: [PWE3] [mpls] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 - RFC4447 > > Authors, Mingui, Stewart > > On 2014-08-08 04:46, Mingui Zhang wrote: >> Hi Stewart, >> >> I think authors would say the S-PE stitching method involves the control plane processing during the repair procedure. They emphasized their method uses data plane & local repair, which can be faster. >> Here, I want to raise one issue: > > It seems that we take it for granted that the method proposed on this draft is faster than e.g. the e2e protection a la mpls-tp. Why is that? > If we have implementations of both, do we have any real measurements? > > /Loa > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From nobody Sat Aug 9 16:22:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04131A03AA; Sat, 9 Aug 2014 16:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.469 X-Spam-Level: X-Spam-Status: No, score=-12.469 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 vJgZiz0LbFWM; Sat, 9 Aug 2014 16:22:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BC21A03A9; Sat, 9 Aug 2014 16:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3681; q=dns/txt; s=iport; t=1407626564; x=1408836164; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=0dDeHoJOwVBj39qeOurbrc9D2/15AJtk4jgbuqbHTaQ=; b=ALm7ClWaeNeGSGSrOTeF9ctjWU71ytiGfehXcn72gBb3dYNbVEj2WnHg wxeZuTr53S/N9ZidYMAkVAFnn06wNxnVex3fB8EqybjunXl+GLkPMysme EllusaGJ+m8CaxP8YWYbBhXxv5kEu3cdlywNgydjsCSJYyL74LPSRFKwW 0=; X-IronPort-AV: E=Sophos;i="5.01,834,1400025600"; d="scan'208";a="346356153" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2014 23:22:43 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s79NMhpq015675; Sat, 9 Aug 2014 23:22:43 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id E8FF6748; Sat, 9 Aug 2014 19:22:42 -0400 (EDT) From: Eric Rosen To: Lizhong Jin In-reply-to: Your message of Fri, 08 Aug 2014 23:04:32 +0800. <2014080822341929710226@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15747.1407626562.1@erosen-lnx> Date: Sat, 09 Aug 2014 19:22:42 -0400 Message-ID: <15748.1407626562@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/p96Syx6jj5otuX7AQ_kKd1OWLRY Cc: draft-ietf-mpls-mldp-in-band-wildcard-encoding , rtg-dir , mpls , rtg-ads Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 23:22:50 -0000 Many thanks for your review and comments! Section 1 When an MP-LSP is being set up, the procedures of [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] , known as "mLDP In-Band Signaling", allow the Egress LSRs of the MP-LSP to encode the identifier of an IP multicast tree in the "Opaque Value" field of the mLDP FEC Element that identifies the MP-LSP. Lizhong> The reference [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] should be Lizhong> moved to the next section, right? This section is talking about Lizhong> RFC6826. I think the material in this paragraph is applicable in VRF context as well as in non-VRF context. Thus it is appropriate to reference both RFC 6826 (which discusses in-band signaling in non-VRF context) and RFC 7246 (formerly draft-ietf-l3vpn-mldp-vrf-in-band-signaling), which discusses in-band signaling in VRF context. The material in the following paragraph only applies in VRF context. I will add a reference to RFC 7246 to that paragraph. Section 3.2 Please note that, as always, the structure of the Opaque Value TLVs does not actually affect the operation of mLDP, but only affects the interface between mLDP and IP multicast at the Ingress LSR. Lizhong> the interface between mLDP and IP multicast at the egress LSR is Lizhong> also affected. So it is better to say "...at the Ingress and Egress Lizhong> LSR". How about: Please note that, as always, the structure of an Opaque Value TLV does not affect the operation of mLDP. The structure is meaningful only to the IP multicast modules at the ingress and egress LSRs. Section 3.2 Note that the Bidir TLVs do not have a "Source Address" sub-field, and hence the notion of a wildcard source is not applicable to them. Lizhong> since Bidir TLV is out of the scope, then it is not necessary to Lizhong> have the above note. Section 3.2 states earlier that procedures for the use of the wildcard group in the Bidir TLVs are out of scope. The sentence cited above says that the Bidir TLVs cannot have a wildcard source. I think it is useful to make both statements, since neither one implies the other. Section 3.3 However, if an Ingress LSR supports [RFC6826] and/or [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling], but does not support this document, it has no choice but to treat any such received FEC elements as invalid; the procedures specified in [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] do not work when the Opaque values contain zeroes in the Source Address or Group Address sub-fields. Lizhong> I went throught RFC6826 and RFC7246, there is no definition of Lizhong> "zeroes". Then the above statement will be treated as an update to Lizhong> RFC6826 and RFC7246. If that is true, then the draft header needs Lizhong> to indicate that update. I believe you are correct. I will add this to the draft header and the abstract. Section 5. If PIM is not enabled for the identified group, the Ingress LSR acts as if it had received a (*,G) IGMP/MLD report from a downstream node, and the procedures as defined in [RFC4605] are followed. Lizhong> It seems the dataplane processing is missing here. E.g., add Lizhong> something like, the ingress LSR should forward the specified Lizhong> multicast stream to the downstream node through the MP-LSP Lizhong> identified by the Opaque Value TLV. That is not described in Lizhong> RFC4605. This is discussed in section 4.2 of the document; I think it will be adequate to just add a reference here to section 4.2. From nobody Sat Aug 9 23:02:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A3C1A064D; Sat, 9 Aug 2014 23:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, 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 I7HVR9UNt7i2; Sat, 9 Aug 2014 23:02:37 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE5F1A064B; Sat, 9 Aug 2014 23:02:37 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so9290578pad.24 for ; Sat, 09 Aug 2014 23:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=MqcGKxiL151WCv0IF0Il17Wj6cKk7Ih7o+YKKOIC41g=; b=Dbu7GTzSj8FHOYqS8Q7YiB4EZQGnxzSS9gvtKv/WmqC1f59buCReVcaNOSrEkmN5fb MwN/MlYKB92r6WIW8Zi6orWhvUyeIL4lj/mhLXLYvbhVoPRJf7aABgNrpDfpEeMTPM29 BbUcd05sy0uiCWY4H1odonWvHUW457ak3pcIzjZgEHPuM1bxFvE0Ar5TLLdKHle+uI8b aRWbem4CUhkfu1v3ZuWp1ztUYJw+uIcaUsBnKLZG7hSrwESdgIbnmmuh7lhGwysYZ7dc b9F6KtmTGQUwJkJknUwxFgX5RqrudzUNFVqNv1lkmFY7j1HsM1sdlOGKgdbkp4zPHk1T e/5Q== X-Received: by 10.69.31.234 with SMTP id kp10mr91592pbd.138.1407650556713; Sat, 09 Aug 2014 23:02:36 -0700 (PDT) Received: from LIZHONGJ ([140.206.240.94]) by mx.google.com with ESMTPSA id h10sm43391190pat.11.2014.08.09.23.02.32 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Aug 2014 23:02:35 -0700 (PDT) From: "Lizhong Jin" To: References: Your message of Fri, 08 Aug 2014 23:04:32 +0800. <2014080822341929710226@gmail.com> <15748.1407626562@erosen-lnx> In-Reply-To: <15748.1407626562@erosen-lnx> Date: Sun, 10 Aug 2014 14:02:24 +0800 Message-ID: <00de01cfb460$ad881330$08983990$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFIqxe5Dba3fqCarBZcv6GMRQA8ApzXZMYQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7U07v-bngcFsTZuU1VFGpF7Nn_E Cc: 'draft-ietf-mpls-mldp-in-band-wildcard-encoding' , 'rtg-dir' , 'mpls' , 'rtg-ads' Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 06:02:39 -0000 Hi Eric, Thanks for the prompt reply. See inline below. Regards Lizhong > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 2014=C4=EA8=D4=C210=C8=D5 7:23 > To: Lizhong Jin > Cc: rtg-ads; draft-ietf-mpls-mldp-in-band-wildcard-encoding; rtg-dir; = mpls > Subject: Re: [mpls] RtgDir review: = draft-ietf-mpls-mldp-in-band-wildcard- > encoding-01.txt >=20 > Many thanks for your review and comments! >=20 > Section 1 >=20 > When an MP-LSP is being set up, the procedures of [RFC6826] and > [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] , known as "mLDP = In-Band > Signaling", allow the Egress LSRs of the MP-LSP to encode the identifier > of an IP multicast tree in the "Opaque Value" field of the mLDP = FEC > Element that identifies the MP-LSP. >=20 > Lizhong> The reference [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] > Lizhong> should be moved to the next section, right? This section is > Lizhong> talking about RFC6826. >=20 > I think the material in this paragraph is applicable in VRF context as well as in > non-VRF context. Thus it is appropriate to reference both RFC 6826 = (which > discusses in-band signaling in non-VRF context) and RFC 7246 (formerly draft- > ietf-l3vpn-mldp-vrf-in-band-signaling), which discusses in-band = signaling in > VRF context. >=20 > The material in the following paragraph only applies in VRF context. = I will add > a reference to RFC 7246 to that paragraph. [Lizhong] OK >=20 >=20 > Section 3.2 >=20 > Please note that, as always, the structure of the Opaque Value = TLVs does > not actually affect the operation of mLDP, but only affects the > interface between mLDP and IP multicast at the Ingress LSR. >=20 > Lizhong> the interface between mLDP and IP multicast at the egress LSR > Lizhong> is also affected. So it is better to say "...at the Ingress = and > Lizhong> Egress LSR". >=20 > How about: >=20 > Please note that, as always, the structure of an Opaque Value TLV = does > not affect the operation of mLDP. The structure is meaningful = only to > the IP multicast modules at the ingress and egress LSRs. [Lizhong] OK with that. >=20 >=20 > Section 3.2 >=20 > Note that the Bidir TLVs do not have a "Source Address" sub-field, = and > hence the notion of a wildcard source is not applicable to them. >=20 > Lizhong> since Bidir TLV is out of the scope, then it is not necessary > Lizhong> to have the above note. >=20 > Section 3.2 states earlier that procedures for the use of the wildcard group in > the Bidir TLVs are out of scope. The sentence cited above says that = the Bidir > TLVs cannot have a wildcard source. I think it is useful to make both > statements, since neither one implies the other. [Lizhong] OK >=20 > Section 3.3 >=20 > However, if an Ingress LSR supports [RFC6826] and/or > [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling], but does not support = this > document, it has no choice but to treat any such received FEC = elements > as invalid; the procedures specified in [RFC6826] and > [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] do not work when the Opaque > values contain zeroes in the Source Address or Group Address sub-fields. >=20 > Lizhong> I went throught RFC6826 and RFC7246, there is no definition = of > Lizhong> "zeroes". Then the above statement will be treated as an = update > Lizhong> to > Lizhong> RFC6826 and RFC7246. If that is true, then the draft header > Lizhong> needs to indicate that update. >=20 > I believe you are correct. I will add this to the draft header and = the abstract. [Lizhong] OK >=20 > Section 5. >=20 > If PIM is not enabled for the identified group, the Ingress LSR = acts as > if it had received a (*,G) IGMP/MLD report from a downstream node, = and > the procedures as defined in [RFC4605] are followed. >=20 > Lizhong> It seems the dataplane processing is missing here. E.g., add > Lizhong> something like, the ingress LSR should forward the specified > Lizhong> multicast stream to the downstream node through the MP-LSP > Lizhong> identified by the Opaque Value TLV. That is not described in > Lizhong> RFC4605. >=20 > This is discussed in section 4.2 of the document; I think it will be adequate to > just add a reference here to section 4.2. [Lizhong] The description in section 4.2 is also implicit for the packet forwarding behavior. Did I miss something? Section 6 has very clear description:=20 All these streams SHOULD be forwarded down the MP-LSP identified by the Opaque Value TLV. Regards Lizhong From nobody Sun Aug 10 12:59:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B361A010A for ; Sun, 10 Aug 2014 12:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 2bfSFD7lEO8V for ; Sun, 10 Aug 2014 12:59:18 -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 69B891A0103 for ; Sun, 10 Aug 2014 12:59:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLB92030; Sun, 10 Aug 2014 19:59:15 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 10 Aug 2014 20:59:14 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML701-CHM.china.huawei.com ([169.254.3.190]) with mapi id 14.03.0158.001; Sun, 10 Aug 2014 12:59:10 -0700 From: Huaimo Chen To: "Jeffrey (Zhaohui) Zhang" Thread-Topic: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt Thread-Index: Ac+zQNp9tF2TFdkGTPisCwwe9MXEzgBgiGLg Date: Sun, 10 Aug 2014 19:59:08 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C928AB@SJCEML702-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.191] 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/mpls/mmTcHW-MV5mK2Da8WdyeVe1aSJ8 Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 19:59:20 -0000 Hi Jeffrey, Thanks very much for your questions and comments! My answers/explanations are inline below. Best Regards, Huaimo -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]=20 Sent: Friday, August 08, 2014 3:45 PM To: Huaimo Chen Cc: mpls@ietf.org Subject: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-0= 1.txt Huaimo, I have some questions and comments on the draft. I only started looking int= o this now so some of these might have been discussed before. In that case,= you can just refer me to some old email in the archive for me to go throug= h. One big question I have is about the following: After receiving the Path message with the EGRESS_BACKUP, the primary egress includes the information about the primary LSP label in the Resv message with an EGRESS_BACKUP object as UA label. When the PLR receives the Resv message with the information about the UA label, it includes the information in the Path message for the backup LSP to the backup egress. Thus the primary LSP label as UA label is sent to the backup egress from the primary egress. When the PLR detects the failure of the primary egress, it redirects the packets from the primary LSP into the backup LSP to backup egress using the primary LSP label from the primary egress as an inner label. The backup egress delivers the packets to the same destinations as the primary egress using the backup LSP label as context label and the inner label as UA label. In the above text, the inner label is not service label like VPN/PWE3 label= . It is the transport label assigned by the primary egress and relayed by t= he PLR to egress. How does the backup know what to do with that transport l= abel and the application (e.g. vpn) label that follows it? Huaimo: The inner label here is not service label such as VPN label. It is = the transport label allocated by the primary egress for the primary LSP. Th= is part is added according to some comments. At the primary egress, the tra= nsport label may be used for some things. For example, it may be used for c= ounting the number of packets received from the LSP. Thus it is better to s= tack the transport label for the primary LSP in the backup LSP when the pri= mary egress fails if the label is used for some purposes. In the backup LSP= , there may be three labels: the backup LSP label, the transport label for = the primary LSP, and the service label such as VPN label. At the backup egress, the backup LSP label is used as a context label, unde= r this context, the transport label for the primary LSP and the service lab= el are processed as upstream assigned labels.=20 In other places, it talks about using BGP or some other protocols to distri= bute service labels and that seems reasonable. I suppose the above text is = not correct? Huaimo: The above text talks about sending the transport label allocated by= the primary egress for primary LSP to the backup egress as a UA label. The= re may be two UA labels in a backup LSP: one is the transport label, the ot= her is the service label under the transport label. The other big question is, compared to ingress signaling those additional f= lags and backup egress address via PATH messages, wouldn't it be easier for= the primary egress to signal via RESV message to the PLR that it wants egr= ess protection, and optionally specify the backup egress address? That way,= the ingress and transit nodes are not bothered at all. Huaimo: This is a good question. Currently controlling and signaling the at= tributes (including flags) of backup LSPs for protecting a primary LSP agai= nst link and intermediate node failures starts from the ingress of the prim= ary LSP via PATH messages. We follow this for the egress protection.=20 There may be some advantages for the primary egress to signal/driven the eg= ress protection. But there may be some disadvantages. For example, to prote= ct a primary LSP against intermediate node and egress node failures, we nee= d to do configurations on multiple places: one is on the ingress to configu= re intermediate node protection, the others are on the egresses to configur= e egress node protection. We can discuss on this in more details.=20 It seems that some people proposed that a primary LSP set up is signaled/dr= iven by the egress of the LSP. In this case, the egress protection signaled= /driven by the egress seems a very good fit. I'll leave out some smaller questions/comments for now. Thanks. Jeffrey From nobody Mon Aug 11 08:27:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFABA1A04B8; Mon, 11 Aug 2014 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 I5DSL-AWmz8C; Mon, 11 Aug 2014 08:26:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47FD1A04F6; Mon, 11 Aug 2014 08:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=449; q=dns/txt; s=iport; t=1407770808; x=1408980408; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=Vp59Ap44VzBiknVktuVl/abR3WH5ErubG4VSjtxTOm0=; b=R8MYEJPTDZN6eKR6QeOWS583FKhoHYe5kl8r0sn3bbgLXkBm8CMuY/oB U/66DrnEaz7Hv1ibN2mkVtmdpkMHT7E5UXzKXU51HZp+J7wrICpxct51S 8McNPa7URETNfk9DptM5KvFybENgIo2A6RacQdclOHmuNu3KM+PXRxIQR g=; X-IronPort-AV: E=Sophos;i="5.01,842,1400025600"; d="scan'208";a="343535869" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 11 Aug 2014 15:26:48 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7BFQlJj003079; Mon, 11 Aug 2014 15:26:48 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id AD8EC756; Mon, 11 Aug 2014 11:26:47 -0400 (EDT) From: Eric Rosen To: Lizhong Jin In-reply-to: Your message of Sun, 10 Aug 2014 14:02:24 +0800. <00de01cfb460$ad881330$08983990$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13787.1407770807.1@erosen-lnx> Date: Mon, 11 Aug 2014 11:26:47 -0400 Message-ID: <13788.1407770807@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IFctLB4FwJgQuCyMuEBbyHAwJSQ Cc: 'draft-ietf-mpls-mldp-in-band-wildcard-encoding' , 'rtg-dir' , 'mpls' , 'rtg-ads' Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:26:54 -0000 How about if I change bullet point 3 of section 5 to: 3. If PIM is not enabled for the identified group, the Ingress LSR acts as if it had received a (*,G) IGMP/MLD report from a downstream node, and the procedures as defined in [RFC4605] are followed. The ingress LSR should forward the (*,G) packets to the egress LSR through the MP-LSP identified by the Opaque Value TLV. (See also Section 4.2.) From nobody Mon Aug 11 12:20:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3331A04F8 for ; Mon, 11 Aug 2014 12:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.997 X-Spam-Level: * X-Spam-Status: No, score=1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa0l72Lt6-0T for ; Mon, 11 Aug 2014 12:20:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358611A0465 for ; Mon, 11 Aug 2014 12:20:27 -0700 (PDT) Received: from BY2PR05MB192.namprd05.prod.outlook.com (10.242.39.149) by BY2PR05MB190.namprd05.prod.outlook.com (10.242.39.139) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 19:20:24 +0000 Received: from BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.163]) by BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.163]) with mapi id 15.00.0995.014; Mon, 11 Aug 2014 19:20:24 +0000 From: Santosh Esale To: "Kamran Raza (skraza)" , "draft-esale-mpls-appl-aware-ldp-targeted-session@tools.ietf.org" Thread-Topic: Comments on draft-esale-mpls-appl-aware-ldp-targeted-session-00 Thread-Index: AQHPraiAF7Ke1x0I7EilIPI/pA/9YZvLYhCA Date: Mon, 11 Aug 2014 19:20:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.239.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(51704005)(24454002)(51914003)(377454003)(479174003)(199002)(189002)(19580405001)(21056001)(20776003)(79102001)(85306004)(46102001)(64706001)(83506001)(83322001)(19580395003)(31966008)(77096002)(74662001)(74502001)(4396001)(76482001)(77982001)(105586002)(83072002)(85852003)(106116001)(81542001)(81342001)(101416001)(106356001)(95666004)(87936001)(2656002)(99286002)(54356999)(76176999)(50986999)(92566001)(92726001)(36756003)(86362001)(107046002)(99396002)(66066001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB190; H:BY2PR05MB192.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <2EBE44492C72F046A53BFB4F1D67F9E0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/iARhwOW5HV1IcEcEQiRHe1Tkxwk Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-esale-mpls-appl-aware-ldp-targeted-session-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 19:20:30 -0000 SGkgS2FtcmFuLA0KICAgICAgICAgIFRoYW5rcyBmb3IgdGhlIGRldGFpbCByZXZpZXcuIFBsZWFz ZSBzZWUgaW5saW5lDQpmb3Igc29tZSBhbnN3ZXJzLg0KDQpPbiA4LzEvMTQsIDk6NDkgQU0sICJL YW1yYW4gUmF6YSAoc2tyYXphKSIgPHNrcmF6YUBjaXNjby5jb20+IHdyb3RlOg0KDQo+SGVsbG8g U2FudG9zaC9hdXRob3JzLA0KPg0KPlJlZmVyIHRvIG91ciBjaGF0IGR1cmluZyBJRVRGOTAsIEkg aGF2ZSBmZXcgY29tbWVudHMsIG9ic2VydmF0aW9ucywgYW5kDQo+cXVlc3Rpb25zIG9uIHRoaXMg bmV3IEkuRC4NCj4NCj5HZW5lcmFsDQo+PT09PT09PQ0KPi0gVGhpcyBJLkQgc3RhdGVzIHRoZSBB cHAtYXdhcmUtVExEUCBhcyBhIHNvbHV0aW9uIHRvIGZvbGxvd2luZyB0d28NCj5wcm9ibGVtIHN0 YXRlbWVudHM6DQo+ICAgKGEpIENvbnRyb2wgYWNjZXB0YW5jZSBvZiBUTERQIHNlc3Npb24gZm9y IGFzeW1tZXRyaWMgY29uZmlnIGNhc2VzDQo+KGxpa2UgckxGQSkNCj4gICAoYikgQWR2ZXJ0aXNl IG9ubHkgbmVjZXNzYXJ5IEZFQyBiaW5kaW5ncyBvdmVyIGEgc2Vzc2lvbg0KPg0KPiAgUmVmIChh KTogSXQgaXMgYml0IG1pc2xlYWRpbmcgYXMgdGhlIGRvY3VtZW50IGlzIE5PVCBhZGRyZXNzaW5n IHRoZQ0KPmlzc3VlIG9mIGFjY2VwdGFuY2Ugb2YNCj4gICAgIFRMRFAgSGVsbG9zIGZvciBzdWNo IGFzeW1tZXRyaWMgY2FzZXM7IEluc3RlYWQsIGl0IGlzIHRyeWluZyB0byBqdXN0DQo+Y29udHJv bCB0aGUNCj4gICAgIHNlc3Npb24gZXN0YWJsaXNobWVudC9wcm9ncmVzcyAoZm9yIHJlc291cmNl IGNvbnRyb2wvbGltaXQgcmVhc29ucw0KPmV0YykgYW5kIHNlZW1zIHRvIGFzc3VtZSB0aGF0DQo+ ICAgICBULWhlbGxvIGFjY2VwdGFuY2UgaXMgYWxyZWFkeSBoYW5kbGVkIChlLmcuIFZpYSBwYXNz aXZlIHNpZGUgYWNjZXB0DQo+Y29uZmlnIGV0YykuDQo+ICAgICBJZiB0aGlzIGlzIHRoZSBjYXNl LCB0aGVuIGRvY3VtZW50IHNob3VsZCBzdGF0ZSB0aGlzIGFzc3VtcHRpb24NCj5leHBsaWNpdGx5 Lg0KVGhlIGFzeW1tZXRyaWMgVExEUCBoZWxsb3MgYXJlIGFjY2VwdGVkIGJ5IHNpbXBsZSBPbi9P ZmYgY29udHJvbCBvbg0KdGhlIHJlY2VpdmVyIExTUi4gQ3VycmVudGx5LCBpdCBpcyBhIGltcGxl bWVudGF0aW9uIGNob2ljZSB0byBoYXZlIGl0DQpPbiBvciBPZmYgYXMgYSBkZWZhdWx0IGJlaGF2 aW9yLiBTb21lIGltcGxlbWVudGF0aW9ucyBjaG9vc2UgdG8gZG8NCnRoZSBmb3JtZXIgd2hpbGUg ZmV3IG90aGVycyBkbyB0aGUgbGF0ZXIuIFdpdGggdGhpcyBkcmFmdCwgaXQgc2hvdWxkDQpiZSBP biBieSBkZWZhdWx0LiBJZiB5b3UgZmVlbCB0aGF0IGl0IG5lZWRzIHRvIGJlIHNwZWxsZWQgb3V0 IGV4cGxpY2l0bHksDQppIGFtIGZpbmUgd2l0aCBpdC4NCg0KPiAgICAgT24gdGhlIHNhbWUgdG9w aWMsIEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBzZXJ2ZSBiZXR0ZXIgaWYgdGhpcyBUTERQDQo+Y2Fw YWJpbGl0eSB3YXMgc2VudA0KPiAgICBpbiBhIEhlbGxvcyByYXRoZXIgdGhhbiBwb3N0LXNlc3Np b247IFRoaXMgd2F5IHlvdSBjb3VsZCBldmVuIGNvbnRyb2wNCj5mb3JtYXRpb24gb2YgDQo+ICAg IHVubmVjZXNzYXJ5IHRndC1hZGogKyBhdm9pZCBvdmVyaGVhZCBvZiBzZXNzaW9uIGVzdGFiIChh bmQgdGVhcmRvd24gb2YNCj5ub24tYWNjZXB0YWJsZSBzZXNzaW9ucykNCkNvdXBsZSBvZiByZWFz b25zIHRvIG5lZ290aWF0ZSBUYXJnZXRlZCBhcHBsaWNhdGlvbiBjYXBhYmlsaXR5IG9uDQphIFRM RFAgVENQIHNlc3Npb24gYW5kIG5vdCBVRFAgSGVsbG9zIC0NCigxKSBIZWxsb3MgYXJlIGxlc3Mg c2VjdXJlZC4NCigyKSBFdmVyeSBIZWxsbyBtZXNzYWdlIG5lZWRzIHRvIGNhcnJ5IHRoZSBUQUMg Y2FwYWJpbGl0eSBUTFYsIHdoaWNoIGlzDQp1bm5lY2Vzc2FyeS4NCg0KVGhlIG5ldyBwcm9jZWR1 cmVzIGFyZSB1c2VkIGR1cmluZyBzZXNzaW9uIGluaXRpYWxpemF0aW9uLiBJZiB0aGUgVEFDDQpu ZWdvdGlhdGlvbiBmYWlscyBkdXJpbmcgaW5pdGlhbGl6YXRpb24sIHRoZSBzZXNzaW9uIGlzIG5v dCBmb3JtZWQgYW5kDQp0aGUgY29ycmVzcG9uZGluZyB0YXJnZXRlZCBhZGphY2VuY3kgbWF5IGJl IGRlc3Ryb3llZC4gSWYgdGhlIFRBQw0KbmVnb3RpYXRpb25zIGZhaWxzIGFmdGVyIHNlc3Npb24g ZXN0YWJsaXNobWVudCB3aXRoIHRoZSByZWNlaXB0IG9mIGENCmNhcGFiaWxpdHkgbWVzc2FnZSwg dGhlIHNlc3Npb24gaXMgdGVhcmRvd24gYW5kIHRoZSBjb3JyZXNwb25kaW5nDQp0YXJnZXRlZCBh ZGphY2VuY3kgbWF5IGJlIGRlc3Ryb3llZC4NCg0KPiAgUmVmIChiKTogVGhpcyBpcyB0cnlpbmcg dG8gc29sdmUgYSBwcm9ibGVtIHdoaWNoIGhhcyBhbHJlYWR5IGJlaW5nDQo+YWRkcmVzc2VkDQo+ ICAgICBpbiBvdGhlciBleGlzdGluZyBkcmFmdHMgKGlwLXB3LWNhcGFiaWxpdHksIGxkcC1pcHY2 KSBldGMuIFRoZQ0KPnNjb3BlDQo+b2YgdGhpcyBJLkQuLCBob3dldmVyLA0KPiAgICAgaXMganVz dCBUTERQIHNlc3Npb25zIHdoZW4gY29tcGFyZWQgdG8gZWFybGllciBJLkQgKyBJdCBhZGRzIFRM RFAtYXBwDQo+a25vd2xlZGdlIHRvIHBlZXJzLg0KPiAgICAgVGhpcyBJLkQuIGhhcyBzb21lIGlu dGVyc2VjdGlvbnMgd2l0aCB0aGUgb3RoZXIgSS5EcyBhbmQgbmVlZCBjYXJlZnVsDQo+YW5hbHlz aXMgb2YgaW50ZXJ3b3JraW5nLg0KVGhlIEkuRCBjb252ZXlzIHRoZSBhcHBsaWNhdGlvbiBpbmZv cm1hdGlvbiB0byB0aGUgcmVjZWl2ZXIgTFNSDQphbmQgdXNlcyBpdCB0byBhZHZlcnRpc2UgdGhl IG5lY2Vzc2FyeSBGRUNzLiBJbnRlcndvcmtpbmcgZGV0YWlscw0Kd2l0aCBpcC1wdy1jYXBhYmls aXR5IGFyZSBkZXNjcmliZWQgaW4gc2VjdGlvbiA0Lg0KDQo+U2VjdGlvbiAyDQo+PT09PT09PT09 DQo+ICAtIENhbiB0aGlzIFRndC1BcHAgQ2FwYWJpbGl0eSAoVEFDKSBhZHZlcnRpc2VkIG9ubHkg b24gYSBUTERQIHNlc3Npb24gPw0KPldoYXQgYXJlIHByb2NlZHVyZXMgaWYNCj4gICAgaXQgaXMg cnhkIG9uIGEgbm9uLXRsZHAgc2Vzc2lvbiA/IFdoYXQgYXJlIHByb2NlZHVyZXMgaWYgYSBzZXNz aW9uDQo+dHlwZSBjaGFuZ2VzIGZyb20NCj4gICAgdGxkcCAtPiBub24tdGxkcCBhbmQgdmljZSB2 ZXJzYS4NClRoZSBUYXJnZXRlZCBBcHAgY2FwYWJpbGl0eSBpcyBhZHZlcnRpc2VkIG9uIFRMRFAg c2Vzc2lvbiBvbmx5Lg0KVGhlIExTUiBzaG91bGQgc2lsZW50bHkgaWdub3JlIGl0IG9uIGxpbmsg c2Vzc2lvbi4gVGhlIExTUiBzaG91bGQNCnVzZSBkeW5hbWljIGNhcGFiaWxpdHkgYW5kIGNhcGFi aWxpdHkgbWVzc2FnZSB0byBuZWdvdGlhdGUgdGhlDQpUYXJnZXRlZCBBcHAgY2FwYWJpbGl0eSB3 aGVuIHRoZSBzZXNzaW9uIHR5cGUgY2hhbmdlcyBmcm9tIG5vbi10bGRwDQp0byB0bGRwLiBXZSB3 aWxsIGNsYXJpZnkgaXQgaW4gbmV4dCB2ZXJzaW9uLg0KDQo+IC0gUmVnYXJkaW5nIFRhcmdldGVk LUFwcGxpY2F0aW9uIElkZW50aWZpZXJzIChUQS1JZCk6DQo+ICAgICAoaSkgVGhlIElEIGlzIG1p c3NpbmcgSUNDUCBhbmQgU2Vzc2lvbiBQcm90ZWN0aW9uIGFwcGxpY2F0aW9ucyBmcm9tDQo+dGhl IGxpc3QuDQo+ICAgICAoaWkpIFRoZSBJRCBpcyBhbHNvIG1pc3NpbmcgUDJNUCBQVyBGRUMgMTMw IChpbiBjYXNlIHAybXAtcHcgSS5ELg0KPlN0aWxsIHByb2dyZXNzZXMpDQo+ICAgICAoaWlpKSBG b3IgYW4gTFNSIHdoaWNoIGhhcyBOT05FIG9mIHRoZSBsaXN0ZWQgYXBwbGljYXRpb25zIGNvbmZp Z3VyZWQNCj5idXQgY2FuIHN0aWxsIGVzdGFibGlzaC9wZXJtaXQNCj4gICAgICAgQSB0TERQIHNl c3Npb24gKGUuZy4gYXMgYSBwdXJlIHBhc3NpdmUgTFNSIGFjY2VwdGluZyBULUhlbGxvcyksDQo+ dGhlcmUgc2hvdWxkIGJlIGEgVEEtSUQgdG8gY292ZXIgc3VjaCBjYXNlLg0KPiAgICAgICBJIHN1 Z2dlc3QgwrNQYXNzaXZlwrIgYXMgdGhlIHR5cGUuDQooaSkgKGlpKSB0aGFua3MuIFdlIHdpbGwg aW5jbHVkZSB0aGVtIGluIHRoZSBuZXh0IHJldmlzaW9uLg0KKGlpaSkgQSBMU1Igc2hvdWxkIGZv cm0gdGhlIGxpc3Qgb2YgYXBwbGljYXRpb25zIGlkcyB0aGF0IGl0IGNhbg0KICAgICAgc3VwcG9y dCBvdmVyIHRoZSBzZXNzaW9uLiBJZiB0aGUgc3VnZ2VzdGlvbiBpcyB0byBhZGQgYSBwYXNzaXZl DQogICAgICBiaXQgdG8gdGhlIFRBRSBlbGVtZW50IHRvIGluZGljYXRlIHRoYXQgdGhlIExTUiBp cyBub3QgY29uZmlndXJlZA0KICAgICAgZm9yIGl0LCB3ZSB3aWxsIHRoaW5rIHRoaXMgdGhyb3Vn aCBhbmQgZ2V0IGJhY2suDQoNCj4gLSBTaW5jZSBUQUMgaXMgYSBsaXN0IG9mIHRoZSBBcHBzLCB0 aGUgSS5ELiBOZWVkcyB0byBjbGFyaWZ5IGhvdyBpcyBhbg0KPnVwZGF0ZSBjb25zdHJ1Y3RlZC9k ZWNvZGVkID8NCj4gICBpLmUuIGlmIGFuIEFwcCBjaGFuZ2VzLCB3aGV0aGVyIHRoZSB1cGRhdGUg aXMganVzdCBpbmNyZW1lbnRhbCBvciBhDQo+c25hcC1zaG90IG9mIGFsbCBuZWdvdGlhdGVkIGFw cHMgPw0KIEl0IGlzIGp1c3QgaW5jcmVtZW50YWwuDQoNCj5TZWN0aW9uIDMNCj49PT09PT09PT0N Cj4gIC0gSXMgVEFFIGlzIGFuIGluZGljYXRpdmUgb2YgYSDCs3N1cHBvcnRlZMKyIG9yIMKzY2Zn ZWTCsiB0eXBlID8gSSByZWFkIGl0DQo+YXMgwrNjZmdlZMKyLiANCj4gICAgVGhlIGRvY3VtZW50 IGlzIGJpdCBmdXp6eSBhYm91dCB0aGlzIGltcG9ydGFudCBkZXRhaWwgYW5kIG5lZWRzIHNvbWUN Cj5lbGFib3JhdGlvbi4NClRoZSBUQUUgaW5kaWNhdGVzIHRoYXQgYSBMU1Igc3VwcG9ydHMgdGhl IHNwZWNpZmljIGFwcGxpY2F0aW9uIG92ZXINClRoZSBUTERQIHNlc3Npb24uIEZvciBpbnN0YW5j ZSwgdXNlIGNhc2UgNy4xLiBXZSB3b3VsZCBjbGFyaWZ5IGl0Lg0KICANCj4gIC0gcmU6ICJJZiB0 aGUgcmVjZWl2ZXIgTFNSIHJlY2VpdmVzIHRoZSBzYW1lIFRBLUlkIGluIG1vcmUgdGhhbiBvbmUg VEFFDQo+ZWxlbWVudCwgaXQgTVVTVCBkaXNjYXJkIHRoZSBUQUMgVExWDQo+ICAgIEFuZCBiZWhh dmUgYXMgaWYgVEFDIFRMViBpcyBub3QgcmVjZWl2ZWQuwrIuDQo+ICAgIFE6IFdoeSBub3QganVz dCBwcm9jZXNzIHRoZSAxc3Qgc3VjaCBlbGVtZW50IGFuZCBpZ25vcmUgYWxsDQo+ZHVwbGljYXRl cy9jb25mbGljdGluZyBvbmUuDQo+ICAgIFdoeSBhcmUgd2UgcGVuYWxpemluZyB0aGUgZW50aXJl IFRMViA/DQpHb29kIHN1Z2dlc3Rpb24uIFdlIHdpbGwgY2hhbmdlIGl0IGluIHRoZSBuZXh0IHJl dmlzaW9uLg0KDQo+IA0KPiAgLSByZTogIk9uIHRoZSByZWNlaXB0IG9mIGEgdmFsaWQgVEFDIFRM ViwgYW4gTFNSIE1VU1QgZ2VuZXJhdGUgaXRzIG93bg0KPlRBQyBUTFbCsi4NCj4gICAgSSBhbSBu b3Qgc3VyZSB0aGlzIGlzIGRvYWJsZSBhdCBJTklUIHRpbWUgdGhvdWdoOyBJLmUuIEFuIExTUiAg c2hvdWxkDQo+Z2VuZXJhdGUgaXRzIG93biBUQUMgVExWIHdpdGhvdXQNCj4gICAgZGVwZW5kaW5n IG9uIHJlY2VpcHQgZnJvbSBvdGhlciBMU1IuDQpBIExTUiBoYXMgdG8gdXBkYXRlIGl0cyBvd24g VEFDIFRMViBiYXNlZCBvbiB0aGUgY29uZmlndXJhdGlvbiBhbmQgbnVtYmVyDQpvZiBhbHJlYWR5 IGVzdGFibGlzaGVkIHNlc3Npb25zIGZvciBkaWZmZXJlbnQgYXBwbGljYXRpb25zLiBGb3IgaW5z dGFuY2UsDQpJZiB0aGUgbGFzdCBzZXNzaW9uIGVzdGFibGlzaGVkIHdhcyAxMDB0aCBSZW1vdGUg TEZBIHNlc3Npb24gYW5kIGlmIHRoZQ0KTFNSIGlzIGNvbmZpZ3VyZWQgdG8gYWNjZXB0IDEwMCBz dWNoIHNlc3Npb25zLCBpdCBoYXMgdG8gZ2VuZXJhdGUvdXBkYXRlDQppdHMgVEFDIFRMViB3aXRo b3V0IFJlbW90ZSBMRkEgYXBwbGljYXRpb24gc28gdGhhdCBpdCBkb2VzIG5vdCBhY2NlcHQgdGhl DQoxMDF0aCByZW1vdGUgTEZBIHNlc3Npb24uIEVpdGhlciBpdCBjYW4gZ2VuZXJhdGUgdGhlIFRB QyBUTFYgYWZ0ZXIgdGhlDQplc3RhYmxpc2htZW50IG9mIGxhc3Qgc2Vzc2lvbiBvciBkdXJpbmcg YWNjZXB0YW5jZS9pbml0aWFsaXphdGlvbiBvZiBhDQpuZXcgc2Vzc2lvbi4gV2UgaGF2ZSBjaG9z ZW4gdGhlIGxhdGVyLCBidXQgaSBhbSBva2llIHdpdGggZm9ybWVyIHRvby4NCg0KPiANCj4gIC0g cmU6ICJUaGUgc2VuZGVyIExTUiBwbGF5aW5nIHRoZSBwYXNzaXZlIHJvbGUgaW4gTERQIHNlc3Np b24NCj5lc3RhYmxpc2htZW50IE1BWSBkZXN0cm95IHRoZSBjb3JyZXNwb25kaW5nIHRhcmdldGVk IGFkamFjZW5jeS7Csg0KPiAgICBROiBEaWQgeW91IG5vdCBtZWFuIHRvIHNheSDCs2Rlc3Ryb3kg dGhlIGNvcnJlc3BvbmRpbmcgc2Vzc2lvbsKyID8NCk5vLiBTdXBwb3NlIHRoZSBzZW5kZXIgTFNS IGhhcyBpbml0aWF0ZWQgYSBhc3ltbWV0cmljIHRhcmdldGVkIGRpc2NvdmVyeQ0KdG8gdGhlIHJl Y2VpdmVyIExTUi4gRnVydGhlciwgc3VwcG9zZSB0aGUgc2VuZGVyIExTUiBpcyBwbGF5aW5nIGEg cGFzc2l2ZQ0Kcm9sZSBpbiBMRFAgc2Vzc2lvbiBlc3RhYmxpc2htZW50LiBBZnRlciB0aGUgcmVj ZWlwdCBvZiBpbml0aWFsaXphdGlvbg0KbWVzc2FnZSB3aXRoIGEgVEFDIFRMViBmcm9tIGEgcmVj ZWl2ZXIgTFNSLCBpZiB0aGUgc2VuZGVyIExTUiBkb2VzIG5vdA0KZmluZCB0aGUgYXBwLWlkIHRo YXQgaXQgaW50ZW5kcyB0byBlc3RhYmxpc2ggdGhlIHNlc3Npb24gZm9yLCBpdCB3aWxsDQpzZW5k IEEgJ1Nlc3Npb24gUmVqZWN0ZWQvVGFyZ2V0ZWQgQXBwbGljYXRpb24gQ2FwYWJpbGl0eSBNaXMt TWF0Y2jigJkNCk5vdGlmaWNhdGlvbiBNZXNzYWdlLiBBbHNvLCBpdCBtYXkgZGVjaWRlIHRvIGRl c3Ryb3kgdGhlIGNvcnJlc3BvbmRpbmcNCnRhcmdldGVkIGFkamFjZW5jeSB0aGF0IGl0IGhhcyBp bml0aWF0ZWQuDQoNCj4NCj4gIC0gcmU6ICJXaGVuIGl0IGRldGVjdHMgYSBjaGFuZ2UgaW4gdGhl IHNlbmRlciBMU1IgY29uZmlndXJhdGlvbiBvciBsb2NhbA0KPmNvbmZpZ3VyYXRpb24gcGVydGFp bmluZyB0byBUQUMgVExWLi7Csg0KPiAgIFE6IEhvdyBkb2VzIGFuIExTUiBkZXRlY3QgY2hhbmdl IGluIHNlbmRlciBMU1IgY29uZmlndXJhdGlvbiA/IElmIHRoaXMNCj5pcyB0aHJvdWdoIENmZyBT ZXEgTm8sIHRoZW4gSUQgbmVlZHMgdG8gZXhwbGljdGx5DQo+ICAgICAgc3RhdGUgc28uDQpPa2ll LiBXZSB3aWxsIHN0YXRlIGl0IGV4cGxpY2l0bHkuDQoNCj4gICAtIHJlOiAiQWZ0ZXIgYW4gTERQ IHNlc3Npb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQgd2l0aCBUQUMgY2FwYWJpbGl0eSwNCj50aGUg c2VuZGVyIGFuZCByZWNlaXZlciBMU1IgTVVTVCBkaXN0cmlidXRlDQo+ICAgICAgICAgIEZFQyBs YWJlbCBiaW5kaW5ncyBmb3IgdGhlIG5lZ290aWF0ZWQgYXBwbGljYXRpb25zIG9ubHkuwrINCj4g ICAgSSBzdWdnZXN0IHRvIGFkZCBhIHNlY3Rpb24gbWFwcGluZyB5b3VyIFRBLXR5cGVzIHRvIEZF Qy10eXBlcy4gTm90ZQ0KPnRoZXJlIGNvdWxkIGJlIG11bHRpcGxlIFRBIGFzc29jaWF0ZWQgd2l0 aCB0aGUNCj4gICAgc2FtZSBGRUMgdHlwZSAoZXhhbXBsZTogTERQIHR1bm5lbGluZywgckxGQSkN ClNlY3Rpb24gNCBjb3ZlcnMgaXQuDQoNCj4NCj4gICAtIHJlOiAiVGhpcyBNQVkgbGVhZCB0byBh ZHZlcnRpc2VtZW50cyBvciB3aXRoZHJhd2FscyBvZiBjZXJ0YWluIEZFQw0KPnR5cGVzwrINCj4g ICBJIHN1Z2dlc3QgdXNlIMKzVGhpcyBtYXkgbGVhZCB0byDFoC4iDQpPa2llLg0KDQo+U2VjdGlv biA0OiBTQUMgYW5kIFRBQyBjYXBhYmlsaXR5IGludGVyd29ya2luZw0KPj09PT09PT09PT0NCj4g ICAtIHJlOiAiVGhlIFRBQyBtZWNoYW5pc20gdGFrZXMgcHJlY2VkZW5jZSBvdmVyIHRoZSBTQUMg bWVjaGFuaXNtIHdpdGgNCj5yZXNwZWN0IHRvIGVuYWJsaW5nDQo+ICAgICBhcHBsaWNhdGlvbnMg Zm9yIHdoaWNoIHN0YXRlIGluZm9ybWF0aW9uIHdpbGwgYmUgYWR2ZXJ0aXNlZC7Csg0KPg0KPiAg ICBJIGFtIG5vdCBzdXJlIEkgYWdyZWUgKGFzIGEgU0FDIGF1dGhvcikuIE5vdGUgdGhhdCBTQUMg c2NvcGUgZm9yIElQL1BXDQo+Y2FwYWJpbGl0eSBpcyB3aWRlciB0aGFuDQo+ICAgIFRBQyBhcyBp dCBhcHBsaWVzIHRvIGJvdGggVExEUCBhbmQgbm9uLVRMRFAuIFdlIHdpbGwgbmVlZCB0byBkaXNj dXNzDQo+bW9yZSBhbmQgY2xvc2UgbGF0ZXIuDQpXZSBoYXZlIGRlc2NyaWJlZCB0aGUgaW50ZXJz ZWN0aW9uIGJldHdlZW4gdGhlIHR3byBkcmFmdHMuIFN1cmUsIFdlIGNhbg0KZGlzY3VzcyBhbmQg Y2xvc2Ugb24gaXQuDQoNCj5TZWN0aW9uIDUuMQ0KPj09PT09PT09PT09DQo+ICAgLSBDb3VsZCB5 b3UgZWxhYm9yYXRlIG1vcmUgb24gZGlmZmVyZW50IGhvbGR0aW1lIHZhbHVlIGZvciBhbiBhdXRv bWF0aWMNCj50Z3Qgc2Vzc2lvbiA/DQpDdXJyZW50bHksIHNvbWUgaW1wbGVtZW50YXRpb24gYWxs b3dzIGEgY29tbW9uIGhvbGR0aW1lIHZhbHVlIGZvciBhbGwNClRMRFAgc2Vzc2lvbnMuIFRoZSBp bnRlbnRpb24gaXMgdG8gc3RhdGUgdGhhdCB0aGUgYXV0b21hdGljIHRhcmdldGVkDQpzZXNzaW9u cyBhcmUgZGlmZmVyZW50LiBTbywgaWYgbmVlZGVkLCBhIFRMRFAgaG9sZHRpbWUgdmFsdWUgY2Fu IGJlDQpkaWZmZXJlbnQgZm9yIHN1Y2ggYSBzZXNzaW9uLg0KDQo+U2VjdGlvbiA1LjINCj49PT09 PT09PT09PQ0KPiAgIC0gU2VlbXMgbGlrZSB0aGlzIFRBQyBjYXBhYmlsaXR5IGNhbiBOT1QgYmUg d2l0aGRyYXduIChhcyBTLWJpdCBpcw0KPmFsd2F5cyBzZXQgdG8gMSkuIA0KPiAgICAgSSB1bmRl cnN0YW5kIHRoYXQgeW91IGNvbnRyb2wgeW91ciB3aXRoZHJhd2FsIG9mIFQtQXBwIGJ5IMKzRcKy IGJpdCBidXQNCj5JIHN0aWxsIHRoaW5rIA0KPiAgICBUaGF0IHRoZXJlIGlzIGEgdmFsdWUgaW4g YWxsb3dpbmcgUz0wICh3aXRoIG5vIFRBQyBlbGVtZW50cykgaW4gdGhlDQo+VExWIC0gd2hpY2gg Y291bGQgaW5kaWNhdGUNCj4gICAgIHdpbGRjYXJkIGRpc2FhYmxlIGZvciBhbGwgc3VjaCBULUFw cHMuDQpBbGwgdGhlIFQtQXBwcyBhcmUgZGlzYWJsZWQgYnkgbGlzdGVuaW5nIGVhY2ggb2YgdGhl bSBpbmRpdmlkdWFsbHkgd2l0aA0KRS1iaXQgb2ZmLiBJZiB5b3UgdGhpbmsgaXQgaXMgZ29vZCB0 byBwcm92aWRlIGEgd2lsZGNhcmQgVC1BcHBzDQp3aXRoZHJhd2FsLCBzdXJlLg0KDQo+U2VjdGlv biA3LjMNCj49PT09PT09PT09PQ0KPiAgIC0gVXNlIGNhc2UgTERQb1RFICsgckxGQSBzZXNzaW9u OiBOb3Qgc3VyZSBwcmFjdGljYWxpdHkgb2YgdGhpcyB1c2UNCj5jYXNlIGJlY2F1c2UgaWYgdSBo YXZlIFRFIHR1bm5lbCB0ZXJtaW5hdGluZyBvbiByZW1vdGUgW1BRXSBub2RlLA0KPiAgICB0aGF0 IG5vZGUgdHlwaWNhbGx5IGJlY29tZXMgeW91ciBsb2NhbCBMRkEgcGVlciBhbmQgbm90IGEgcmVt b3RlL1BRDQo+TEZBIHBlZXIuDQpVc2VyIGNhbiBwcmVmZXIgUmVtb3RlIExGQSBvdmVyIExGQSBv ciB2aWNlIHZlcnNhIGJhc2VkIG9uIGNvbmZpZ3VyYXRpb24uDQoNCj5TZWN0aW9uIDk6IElBTkEN Cj49PT09PT09PT0NCj4gIC0gVGhlIG5ldyByZWdpc3RyeSBmb3IgVEEtdHlwZSBoYXMgcmFuZ2Ug b2YgMC02NTUzNSB0aG91Z2ggVEEtSUQgdGhhdA0KPmNhbiBiZSBzcGVjaWZpZWQgaW4gdGhlIHNp Z25hbGluZyBpcw0KPiAgIE9ubHkgOCBiaXRzLiBTaG91bGQgdGhlIHJhbmdlIGZvciB0aGlzIHR5 cGUgbm90IGJlIDAtMjU1Lg0KV2Ugd2lsbCBjaGFuZ2UgaXQuDQoNCg0KVGhhbmtzLA0KU2FudG9z aA0KDQo= From nobody Mon Aug 11 18:53:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415551A005C; Mon, 11 Aug 2014 18:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, 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 wvDcSK-oThC9; Mon, 11 Aug 2014 18:53:05 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28E61A0056; Mon, 11 Aug 2014 18:53:04 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so11761938pdj.28 for ; Mon, 11 Aug 2014 18:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=EX9z/sqzrwOWejokaypKdIplwvPDk675H1Vlc2Vuz8o=; b=z7yNeT726raX/j4ANpjVtICVfx3LmeUJXiDd6mmpZWSVDzPn2d63zhEQJdivbjJhhr USqj+84czZxzt4n/wPSIndosHTAjIrYd8kIYtAkohIvo2TcqG7WK9vZe8Xiswltv7z+Z GwH8bpWcB9i4ygZIjP/FjaAW57shBQqpiogTTbQJbpo3NuGzThuHQ1OjwgtOM6yucuX7 p5h48fY15Miu2W10viJDRPHp0vnBwUs7KFbSYi8jSIBE99gDyWD06boEtQKksIvqyO+3 FU8xyWQR26Bn1Kd/vyx85CvGYco+GXjhEgbN4Gi+8rhgNXtvowXqR/DorqneKQMkg+oX PjPg== X-Received: by 10.66.161.41 with SMTP id xp9mr1460166pab.120.1407808384521; Mon, 11 Aug 2014 18:53:04 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id fs6sm1434318pdb.60.2014.08.11.18.53.01 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Aug 2014 18:53:03 -0700 (PDT) From: "Lizhong Jin" To: References: Your message of Sun, 10 Aug 2014 14:02:24 +0800. <00de01cfb460$ad881330$08983990$@gmail.com> <13788.1407770807@erosen-lnx> In-Reply-To: <13788.1407770807@erosen-lnx> Date: Tue, 12 Aug 2014 09:52:58 +0800 Message-ID: <001f01cfb5d0$2736c6c0$75a45440$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGJG4ckmN2t+jshHptfO2YxqmI8oJxZaQQQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/N33vYhG7p_q18VmvxSiNQGJbsWA Cc: 'draft-ietf-mpls-mldp-in-band-wildcard-encoding' , 'rtg-dir' , 'mpls' , 'rtg-ads' Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 01:53:10 -0000 I am fine with the new text. Thank you, Eric. Regards Lizhong > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 2014=C4=EA8=D4=C211=C8=D5 23:27 > To: Lizhong Jin > Cc: 'rtg-ads'; 'draft-ietf-mpls-mldp-in-band-wildcard-encoding'; 'rtg-dir'; > 'mpls' > Subject: Re: [mpls] RtgDir review: = draft-ietf-mpls-mldp-in-band-wildcard- > encoding-01.txt >=20 > How about if I change bullet point 3 of section 5 to: >=20 > 3. If PIM is not enabled for the identified group, the Ingress LSR > acts as if it had received a (*,G) IGMP/MLD report from a > downstream node, and the procedures as defined in [RFC4605] are > followed. The ingress LSR should forward the (*,G) packets to > the egress LSR through the MP-LSP identified by the Opaque = Value > TLV. (See also Section 4.2.) From nobody Tue Aug 12 01:55:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910B31A07A3 for ; Tue, 12 Aug 2014 01:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 jGxJhSKCMfbi for ; Tue, 12 Aug 2014 01:55:46 -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 12BBB1A0369 for ; Tue, 12 Aug 2014 01:55:46 -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 999011801586; Tue, 12 Aug 2014 10:55:44 +0200 (CEST) Message-ID: <53E9D693.7020100@pi.nu> Date: Tue, 12 Aug 2014 10:55:47 +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: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/r7FpIoh33C67YIl_ajApdw5EhSM Cc: draft-ietf-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: [mpls] Implementation oll on draft-ietf-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 08:55:48 -0000 Working Group, The working group last call on draft-ietf-mpls-mldp-in-band-wildcard- encoding has been closed and the authors are working with the reviewers that made the comments to update the draft. We expect to see the new version of the draft posted shortly. This means that it is time to start preparing the publication request. As a step in these preparations we need to know about implementations of this draft. If you have or are aware of existing implementations of draft-ietf-mpls- mldp-in-band-wildcard-encoding please send this information to the working group mailing list or directly to the working group chairs. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Aug 12 03:16:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584241A082A for ; Tue, 12 Aug 2014 03:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 fMVMxwdLIlza for ; Tue, 12 Aug 2014 03:16:56 -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 9B0041A03A5 for ; Tue, 12 Aug 2014 03:16:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD54436; Tue, 12 Aug 2014 10:16:53 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Aug 2014 11:16:53 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Tue, 12 Aug 2014 18:16:47 +0800 From: Mach Chen To: "George Swallow (swallow)" , "mpls-chairs@tools.ietf.org" Thread-Topic: Some questions about the "MPLS Architectural Principles" presentation Thread-Index: Ac+2FoSMCG0+zdZvTW6JeJdjmd6gDQ== Date: Tue, 12 Aug 2014 10:16:46 +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/mpls/Wd2U0llot_fRNZg-T54MJ4Nmnuw Cc: "mpls@ietf.org" Subject: [mpls] Some questions about the "MPLS Architectural Principles" presentation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 10:16:57 -0000 Hi George, wg chairs, Thanks for a very interesting presentation at the MPLS working group meetin= g, I basically agree the principle that past decisions and positions needs = to be taken into consideration when new work is accepted. However, there is one point that I have a question about, when you say that= the source label has been proposed over and over again, but I can't find e= vidence to support that statement. As far as I can see there have been no d= rafts submitted or discussions on the mailing list or at wg meetings. Could= you please point me to where this discussion took place? Further, the way we propose the source label, there is no indication in you= r presentation that the source label in fact breaks the MPLS architecture, = and I think this is true. Thanks, Mach From nobody Tue Aug 12 06:07:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0D71A089E for ; Tue, 12 Aug 2014 06:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 9FRvtw61lslc for ; Tue, 12 Aug 2014 06:07: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 AC7B81A0891 for ; Tue, 12 Aug 2014 06:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1407848831; x=1409058431; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nmyUoK34GOEIXfbZpgFCpfzhJeHUrAcxVsdwjYwdGfg=; b=LvQaeNGZbr1/gencPWgICVifiXCUUaqI2ZmeolLhzM639ul29rus0B2p 6BF9Cs1FY+2jVdoKFxcCYzvEE+PKTzEszRMKlmjGRDWGk4xLNq3DZ2eK6 vpFHDeE4lHW7Ckht9WN3SAoUKr0DrTRbKCgA6e5RsXuUaUaoYb0jPKOCy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAJIQ6lOtJV2P/2dsb2JhbABagw1SV65YBQFunWYKh0gBgRUWd4QDAQEBAwEBAQE3MQMLBQkCAgEIGB4QGwwLJQIEDgWIOggNxHwTBASFeIhuEQEdMweDL4EdBZEdixyUfoNcbIEP X-IronPort-AV: E=Sophos;i="5.01,849,1400025600"; d="scan'208";a="346978035" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP; 12 Aug 2014 13:07:10 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7CD788W006150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Aug 2014 13:07:08 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.91]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 08:07:07 -0500 From: "IJsbrand Wijnands (iwijnand)" To: Loa Andersson Thread-Topic: [mpls] Implementation oll on draft-ietf-mpls-mldp-in-band-wildcard-encoding Thread-Index: AQHPtgs6XX+HTa5yrk+wmBIumKicS5vM8I2q Date: Tue, 12 Aug 2014 13:07:07 +0000 Message-ID: <7E263024-EEB2-4FBC-BA52-8EA7D2E56168@cisco.com> References: <53E9D693.7020100@pi.nu> In-Reply-To: <53E9D693.7020100@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/u5c58-HDeEBgtiMnJchQ1zBEmJw Cc: "draft-ietf-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Implementation oll on draft-ietf-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 13:07:19 -0000 Dear WG, Cisco has implemented this draft and it is available in an released version= of IOS. Thx, Ice. > On 12 Aug 2014, at 10:55, "Loa Andersson" wrote: >=20 > Working Group, >=20 > The working group last call on draft-ietf-mpls-mldp-in-band-wildcard- > encoding has been closed and the authors are working with the reviewers > that made the comments to update the draft. We expect to see the new > version of the draft posted shortly. >=20 > This means that it is time to start preparing the publication request. > As a step in these preparations we need to know about implementations > of this draft. >=20 > If you have or are aware of existing implementations of draft-ietf-mpls- > mldp-in-band-wildcard-encoding please send this information to the > working group mailing list or directly to the working group chairs. >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Aug 12 07:35:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5A51A08EE; Tue, 12 Aug 2014 07:35:07 -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] 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 5dU-gcROuqRH; Tue, 12 Aug 2014 07:35:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1D51A06E4; Tue, 12 Aug 2014 07:35:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140812143506.14832.83742.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 07:35:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EBEMNiTK1vbuRvD5ZkYZbabmW_8 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-in-band-wildcard-encoding-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 14:35:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : mLDP In-Band Signaling with Wildcards Authors : IJsbrand Wijnands Eric Rosen Arkadiy Gulko Uwe Joorde Jeff Tantsura Filename : draft-ietf-mpls-mldp-in-band-wildcard-encoding-02.txt Pages : 15 Date : 2014-08-12 Abstract: There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" to an MPLS multipoint label switched path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either "Source-Specific Multicast" trees or "Bidirectional Multicast" trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP "Any Source Multicast" trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP "Any Source Multicast" trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-wildcard-encoding/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-mldp-in-band-wildcard-encoding-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-mldp-in-band-wildcard-encoding-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 12 08:44:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B3D1A0994 for ; Tue, 12 Aug 2014 08:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 SvOdbRQB3yfH for ; Tue, 12 Aug 2014 08:44:41 -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 4E2C41A0990 for ; Tue, 12 Aug 2014 08:44:37 -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 C79F71802244; Tue, 12 Aug 2014 17:44:35 +0200 (CEST) Message-ID: <53EA3666.2040004@pi.nu> Date: Tue, 12 Aug 2014 17:44:38 +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: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@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/mpls/7zeC27m3noK9IrS8yw-yWPdPbT4 Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 15:44:44 -0000 Working Group, During what we thought would be a short wglc on draft-ietf-mpls-ldp-ipv6 http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html we had a comment that stopped us from continuing progressing the draft. The short working group last call is now closed! The comment we refer to was raised in a private mail to the working group chairs and the draft authors. It says that there are a problem with some RFC 5036 non-compliant implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no detailed description of the exact problems. We strongly encourage the people that made the comment(s) to write-up the problem, either as - a new draft (preferred); or - in a mail to the working group mailing list Once we an agreement to write a new draft or the write-up to the mailing, we will continue to ask the working group to see if we can agree to a way to progress. We like to see this write-up before September 1. Failing this we will continue to progress the draft-ietf-mpls-ldp-ipv6 as is. /Loa for the working group chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Aug 12 17:30:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F299D1A0B17 for ; Tue, 12 Aug 2014 17:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74J2wyCk9XYn for ; Tue, 12 Aug 2014 17:30:41 -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 A5E131A0A8B for ; Tue, 12 Aug 2014 17:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3342; q=dns/txt; s=iport; t=1407889841; x=1409099441; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3Bfza0bsmQZRXS9gtMnfWHud6SG6kfyNP4AfSDTOpI4=; b=K8r7w6iUlsjRy9NTBNZOyJXqNUuWgxU63aj8BvTdJp/jkMMD6HYKHQyu G3drLc2SboxvBpG7nkhrrb5KpsOTMGbEFOeHZZc7GoaU1ZAEZ3y0S4quS Q52z+34oW30iBmCcD8woQiOENJp2XxnwFtoNw2fKoAW5TpI8IsFsk9wqg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAGex6lOtJA2I/2dsb2JhbABagmojUlMEBIJ1ykCHRgEZdxZ3hAMBAQEEIxE3DA4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIAYg5AQcFr0CVUBeBLI1vDykGgnM2gR0FjwqCE4QmiE2TJ4NcbAGBRw X-IronPort-AV: E=Sophos;i="5.01,853,1400025600"; d="scan'208";a="347147030" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 13 Aug 2014 00:30:25 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7D0UPj2010611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Aug 2014 00:30:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 19:30:24 -0500 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-01.txt Thread-Index: AQHPtoxezg0CEwIxLE+FhKW1yUFV8JvNrKLQ Date: Wed, 13 Aug 2014 00:30:24 +0000 Message-ID: References: <20140813002014.30339.72672.idtracker@ietfa.amsl.com> In-Reply-To: <20140813002014.30339.72672.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KBaQFtnziKQBI7ZVIzakrglZ4WA Subject: [mpls] FW: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 00:30:44 -0000 RGVhciBNUExTIFdHLA0KDQpXZSBoYXZlIHB1Ymxpc2hlZCByZXZpc2lvbiAwMSBvZiBkcmFmdC1h a2l5YS1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGgsIGFkZHJlc3NpbmcgY29tbWVudHMgcmVj ZWl2ZWQuDQoNCldlIGJlbGlldmUgdGhpcyBpcyBhIHVzZWZ1bCBleHRlbnNpb24gdG8gdGhlIExT UCBQaW5nL1RyYWNlIHRvb2xzIHRvIGVtcG93ZXIgdXMgdG8gZGV0ZWN0IHRyYWZmaWMgYmxhY2sg aG9sZSBvbiBNUExTIG5ldHdvcmtzLg0KDQpQcmVzZW50YXRpb24gb2YgdGhpcyBkb2N1bWVudCBh dCBJRVRGOTAgZGVzY3JpYmVzLCBhdCBoaWdoIGxldmVsLCB3aHkgYW5kIGhvdy4NCg0KaHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9zbGlkZXMvc2xpZGVzLTkwLW1wbHMtNC5wcHR4 DQoNClJlcXVlc3RpbmcgKGFuZCBob3BpbmcpIG1vcmUgTVBMUyBleHBlcnRzIHRvIHJlYWQgYW5k IHByb3ZpZGUgY29tbWVudCAoZG9jIGxpbmtzIGJlbG93KS4NCg0KVGhhbmtzIQ0KDQotTm9ibywg b24gYmVoYWxmIG9mIGF1dGhvcnMNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddDQo+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxMiwgMjAxNCA4OjIwIFBNDQo+IFRvOiBK b2huIEUuIERyYWtlOyBOb2JvIEFraXlhIChub2JvKTsgR2VvcmdlIFN3YWxsb3cgKHN3YWxsb3cp OyBHZW9yZ2UNCj4gU3dhbGxvdyAoc3dhbGxvdyk7IEJydW5vIERlY3JhZW5lOyBTdGVwaGFuZSBM aXRrb3dza2k7IEJydW5vIERlY3JhZW5lOw0KPiBOb2JvIEFraXlhIChub2JvKTsgSm9obiBEcmFr ZTsgU3RlcGhhbmUgTGl0a293c2tpDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1sYWctDQo+IG11bHRpcGF0aC0wMS50eHQN Cj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYWtpeWEtbXBscy1sc3AtcGlu Zy1sYWctbXVsdGlwYXRoLTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IE5vYm8gQWtpeWEgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiAN Cj4gTmFtZToJCWRyYWZ0LWFraXlhLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aA0KPiBSZXZp c2lvbjoJMDENCj4gVGl0bGU6CQlMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIFBpbmcvVHJhY2Ug TXVsdGlwYXRoIFN1cHBvcnQgZm9yDQo+IExpbmsgQWdncmVnYXRpb24gR3JvdXAgKExBRykgSW50 ZXJmYWNlcw0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA4LTEyDQo+IEdyb3VwOgkJSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMjENCj4gVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFraXlhLW1wbHMtbHNwLXBpbmctbGFnLW11 bHRpcGF0aC0wMS50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC8NCj4gSHRt bGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFraXlhLW1wbHMt bHNwLXBpbmctbGFnLW11bHRpcGF0aC0wMQ0KPiBEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1sYWctbXVsdGlw YXRoLTAxPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRl bnNpb24gdG8gdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwNCj4gICAgU3dpdGNoaW5nIChNUExTKSBM YWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIFBpbmcgYW5kIFRyYWNlcm91dGUgdG8NCj4gICAgZGVz Y3JpYmUgTXVsdGlwYXRoIEluZm9ybWF0aW9uIGZvciBMaW5rIEFnZ3JlZ2F0aW9uIChMQUcpIG1l bWJlcg0KPiAgICBsaW5rcyBzZXBhcmF0ZWx5LCB0aHVzIGFsbG93aW5nIE1QTFMgTFNQIFBpbmcg YW5kIFRyYWNlcm91dGUgdG8NCj4gICAgZGlzY292ZXIgYW5kIGV4ZXJjaXNlIHNwZWNpZmljIHBh dGhzIG9mIGxheWVyIDIgKEwyKSBFcXVhbC1Db3N0DQo+ICAgIE11bHRpcGF0aCAoRUNNUCkgb3Zl ciBMQUcgaW50ZXJmYWNlcy4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM0Mzc5 IGFuZCBSRkM2NDI0Lg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Aug 13 07:18:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A281A03EC for ; Wed, 13 Aug 2014 07:18:54 -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 soHnFVpAGEOd for ; Wed, 13 Aug 2014 07:18:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4759A1A0373 for ; Wed, 13 Aug 2014 07:18:51 -0700 (PDT) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB080.namprd05.prod.outlook.com (10.242.38.17) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Wed, 13 Aug 2014 14:18:48 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.3]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.203]) with mapi id 15.00.1005.008; Wed, 13 Aug 2014 14:18:47 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Huaimo Chen Thread-Topic: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt Thread-Index: Ac+zQNp9tF2TFdkGTPisCwwe9MXEzgBgiGLgAI8TpTA= Date: Wed, 13 Aug 2014 14:18:47 +0000 Message-ID: <4f4cc894c09e459f85111b514d9096a0@BY2PR05MB079.namprd05.prod.outlook.com> References: <5316A0AB3C851246A7CA5758973207D445C928AB@SJCEML702-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C928AB@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(37854004)(377454003)(13464003)(25584003)(199003)(189002)(2656002)(4396001)(19580405001)(31966008)(85852003)(83072002)(19580395003)(83322001)(20776003)(64706001)(80022001)(50986999)(101416001)(54356999)(99396002)(87936001)(74316001)(21056001)(46102001)(74662001)(76176999)(86362001)(74502001)(76482001)(92566001)(33646002)(110136001)(76576001)(77096002)(106356001)(95666004)(105586002)(77982001)(66066001)(85306004)(99286002)(108616004)(79102001)(107046002)(81542001)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB080; H:BY2PR05MB079.namprd05.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: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dkpZZKJggzFfLeCbg-DGGRY82xs Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 14:18:54 -0000 Huaimo, Please see below. > -----Original Message----- > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > Sent: Sunday, August 10, 2014 3:59 PM > To: Jeffrey (Zhaohui) Zhang > Cc: mpls@ietf.org > Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress- > protection-01.txt >=20 > Hi Jeffrey, >=20 > Thanks very much for your questions and comments! > My answers/explanations are inline below. >=20 > Best Regards, > Huaimo > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Friday, August 08, 2014 3:45 PM > To: Huaimo Chen > Cc: mpls@ietf.org > Subject: Questions and comments on draft-ietf-mpls-rsvp-egress- > protection-01.txt >=20 > Huaimo, >=20 > I have some questions and comments on the draft. I only started looking > into this now so some of these might have been discussed before. In that > case, you can just refer me to some old email in the archive for me to > go through. >=20 > One big question I have is about the following: >=20 > After receiving the Path message with the EGRESS_BACKUP, the primary > egress includes the information about the primary LSP label in the > Resv message with an EGRESS_BACKUP object as UA label. When the PLR > receives the Resv message with the information about the UA label, it > includes the information in the Path message for the backup LSP to > the backup egress. Thus the primary LSP label as UA label is sent to > the backup egress from the primary egress. >=20 > When the PLR detects the failure of the primary egress, it redirects > the packets from the primary LSP into the backup LSP to backup egress > using the primary LSP label from the primary egress as an inner > label. The backup egress delivers the packets to the same > destinations as the primary egress using the backup LSP label as > context label and the inner label as UA label. >=20 > In the above text, the inner label is not service label like VPN/PWE3 > label. It is the transport label assigned by the primary egress and > relayed by the PLR to egress. How does the backup know what to do with > that transport label and the application (e.g. vpn) label that follows > it? >=20 > Huaimo: The inner label here is not service label such as VPN label. It > is the transport label allocated by the primary egress for the primary > LSP. This part is added according to some comments. At the primary > egress, the transport label may be used for some things. For example, it > may be used for counting the number of packets received from the LSP. > Thus it is better to stack the transport label for the primary LSP in > the backup LSP when the primary egress fails if the label is used for > some purposes. In the backup LSP, there may be three labels: the backup > LSP label, the transport label for the primary LSP, and the service > label such as VPN label. > At the backup egress, the backup LSP label is used as a context label, > under this context, the transport label for the primary LSP and the > service label are processed as upstream assigned labels. >=20 >=20 > In other places, it talks about using BGP or some other protocols to > distribute service labels and that seems reasonable. I suppose the above > text is not correct? >=20 > Huaimo: The above text talks about sending the transport label allocated > by the primary egress for primary LSP to the backup egress as a UA label. > There may be two UA labels in a backup LSP: one is the transport label, > the other is the service label under the transport label. While the PLR can relay the transport label from the primary egress to the = backup egress, the forwarding behavior is not (at least not according to th= e spec). For example, in VPN case, the backup egress learns from the primar= y egress not just the values of VPN labels but also how to forward based on= those labels (i.e. label to prefix bindings). If there will be a separate mechanism outside the scope of this doc to be u= sed, then there is no need for the PLR to relay the label via RSVP? >=20 >=20 > The other big question is, compared to ingress signaling those > additional flags and backup egress address via PATH messages, wouldn't > it be easier for the primary egress to signal via RESV message to the > PLR that it wants egress protection, and optionally specify the backup > egress address? That way, the ingress and transit nodes are not bothered > at all. >=20 > Huaimo: This is a good question. Currently controlling and signaling the > attributes (including flags) of backup LSPs for protecting a primary LSP > against link and intermediate node failures starts from the ingress of > the primary LSP via PATH messages. We follow this for the egress > protection. > There may be some advantages for the primary egress to signal/driven the > egress protection. But there may be some disadvantages. For example, to > protect a primary LSP against intermediate node and egress node failures, > we need to do configurations on multiple places: one is on the ingress > to configure intermediate node protection, the others are on the > egresses to configure egress node protection. We can discuss on this in > more details. Egress protection really has to be tied to the service so there likely to b= e service related configuration on the egress after all (and the ingress wo= uld need to learn/configure that). Using the ingress configuration for the = regular link/node protection but limit egress protection configuration and = signaling to the egress would be better. > Huaimo: It seems that some people proposed that a primary LSP set up is > signaled/driven by the egress of the LSP. In this case, the egress > protection signaled/driven by the egress seems a very good fit. The two topics should be separated :-) Jeffrey >=20 >=20 > I'll leave out some smaller questions/comments for now. >=20 > Thanks. > Jeffrey From nobody Thu Aug 14 16:51:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167701A8992 for ; Thu, 14 Aug 2014 16:51:08 -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 nzEmFRGf4ZPe for ; Thu, 14 Aug 2014 16:51:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE3B1A0137 for ; Thu, 14 Aug 2014 16:51:04 -0700 (PDT) Received: from BY2PR05MB192.namprd05.prod.outlook.com (10.242.39.149) by BY2PR05MB190.namprd05.prod.outlook.com (10.242.39.139) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Thu, 14 Aug 2014 23:51:01 +0000 Received: from BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.215]) by BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.215]) with mapi id 15.00.1005.008; Thu, 14 Aug 2014 23:51:01 +0000 From: Santosh Esale To: Uma Chunduri , "draft-esale-mpls-appl-aware-ldp-targeted-session@tools.ietf.org" Thread-Topic: Quick review for - http://tools.ietf.org/html/draft-esale-mpls-appl-aware-ldp-targeted-session-00 Thread-Index: Ac+o7YWiHIysncmgSBm+2NoGEQr+ygO8nuwA Date: Thu, 14 Aug 2014 23:51:01 +0000 Message-ID: References: <1B502206DFA0C544B7A60469152008633F31655E@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F31655E@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.239.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(51914003)(24454002)(51704005)(199003)(189002)(479174003)(377454003)(107046002)(81342001)(87936001)(95666004)(220493001)(77982001)(101416001)(76176999)(79102001)(83506001)(2656002)(92566001)(54356999)(81542001)(85852003)(86362001)(83072002)(21056001)(92726001)(76482001)(99286002)(4396001)(64706001)(46102001)(77096002)(20776003)(19580395003)(36756003)(85306004)(83322001)(80022001)(99396002)(50986999)(74662001)(31966008)(74502001)(66066001)(106356001)(105586002)(19580405001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB190; H:BY2PR05MB192.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sesale@juniper.net; Content-Type: text/plain; charset="utf-8" Content-ID: <964E053B8D91DB49B835E66D502F6EF7@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/t3zeR8fy3GJkiGU4DihW3NoWkdg Cc: "mpls@ietf.org" Subject: Re: [mpls] Quick review for - http://tools.ietf.org/html/draft-esale-mpls-appl-aware-ldp-targeted-session-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 23:51:08 -0000 SGVsbG8gVW1hLA0KICAgICAgICAgVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBQbGVhc2Ugc2VlIG15 IGNvbW1lbnRzIGlubGluZS4NCg0KT24gNy8yNi8xNCwgOToyNCBBTSwgIlVtYSBDaHVuZHVyaSIg PHVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPkhpIFNhbnRvc2gsDQo+IA0KPkp1 c3QgZ29uZSB0aHJvdWdoIHRoZSBkb2N1bWVudCBhbmQgc29tZSBxdWljayByZXZpZXcgY29tbWVu dHMuDQo+SXTigJlzIGEgZ29vZCBkb2N1bWVudCBhbmQgZ2VuZXJhbGl6ZXMgU0FDIGFuZCBnaXZl cyBtb3JlIGNvbnRyb2wgYXQNCj5yZWNlaXZpbmcgTFNSLg0KPiANCj49PT0NCj4gDQo+MS4gU2Vj dGlvbiAxDQo+ICAgIkluIHRoZXNlIGFwcGxpY2F0aW9ucywgdGhlIHJlbW90ZSBMU1IgaXMgbm90 DQo+ICAgZXhwbGljaXRseSBjb25maWd1cmVkIHdpdGggdGhlIHNvdXJjZSBMU1IgYWRkcmVzcywg c28gdGhlIHJlbW90ZSBMU1INCj4gICBlaXRoZXIgcmVzcG9uZHMgdG8gYWxsIExEUCByZXF1ZXN0 cyBvciBpZ25vcmVzIGFsbCBMRFAgcmVxdWVzdHMuIg0KPiANCj4gICBUaGVyZSBpcyBzb21lIGNv bmZpZ3VyYXRpb24gbmVlZGVkIG9uIHJlbW90ZSBMU1IgdG8gYWNjZXB0IG9uIHRoZSBmbHkNCj5z ZXNzaW9uIGZyb20gaW5jb21pbmcgTFNScy4NCj4NCj4gICBTbyB0aGlzIGlzIGltcGxlbWVudGF0 aW9uIHNwZWNpZmljLg0KPiAgIFNvIHRoZSBzdGF0ZW1lbnQgIm5vdCBleHBsaWNpdGx5IGNvbmZp Z3VyZWQiIGlzIHBhcnRpYWxseSBjb3JyZWN0Lg0KPk5lZWQgdG8gaW1wcm92ZSB0aGUgbGFuZ3Vh Z2UgaGVyZSBwZXJoYXBzLg0KWWVzLCBXZSB3aWxsIHJlLXBocmFzZSBpdCBpbiB0aGUgbmV4dCB2 ZXJzaW9uLg0KDQo+IA0KPjIuIFNlY3Rpb24gMSAtICJBbHNvLCB0aGUgcmVjZWl2ZXIgTFNSIGRv ZXMgbm90IGtub3cgd2hldGhlciB0aGUNCj4gICBzb3VyY2UgTFNSIGlzIGVzdGFibGlzaGluZyB0 aGUgc2Vzc2lvbiBmb3IgYSBjb25maWd1cmVkIG9yIGFuDQo+ICAgYXV0b21hdGljIGFwcGxpY2F0 aW9uLiINCj4gDQo+ICAgVGhpcyBpcyBvbmUgb2YgdGhlIG1vc3QgY3JpdGljYWwgcGllY2Ugb2Yg dGhlIGRvY3VtZW50LCBhcGFydCBmcm9tDQo+YWR2ZXJ0aXNpbmcgYXZvaWRpbmcgdW5uZWNlc3Nh cnkgRkVDcyENCj4gDQo+My4gU2VjdGlvbiAyOg0KPiAgIFBsZWFzZSBhZGQgNTU2MSByZWZlcmVu Y2Ugb25lIG1vcmUgdGltZSAodG8gc2VlIHdoYXQgYXJlIHRob3NlIGZvcikNCj5qdXN0IGJlZm9y ZSBVL0YvUyBiaXRzIGRlc2NyaXB0aW9uIGZvciBUQUMuDQpPa2llLg0KDQo+IA0KPjQuIFNlY3Rp b24gMzoNCj4gICAiVGhlIFRBQyBUTFYncw0KPiAgICAgIENhcGFiaWxpdHkgZGF0YSBNVVNUIGNv bnNpc3RzIG9mIG5vbmUsIG9uZSBvciBtb3JlIFRhcmdldGVkDQo+ICAgICAgQXBwbGljYXRpb24g RWxlbWVudChUQUUpIGVhY2ggcGVydGFpbmluZyB0byBhIHVuaXF1ZSBUYXJnZXRlZA0KPiAgICAg IEFwcGxpY2F0aW9uIElkZW50aWZpZXIoVEEtSWQpLiINCj4gDQo+ICAgIFdoeSBOT05FPyANCkNv bnNpZGVyIGEgc2VuZGVyIExTUiB0aGF0IHdhbnRzIHRvIGVzdGFibGlzaCBhIGF1dG9tYXRpYyB0 YXJnZXRlZA0Kc2Vzc2lvbiB0byB0aGUgcmVjZWl2ZXIgTFNSIGZvciBSZW1vdGUgTEZBLiBGdXJ0 aGVyLCBzdXBwb3NlIHRoZSBzZW5kZXINCmFuZCByZWNlaXZlciBMU1IgcGxheXMgcGFzc2l2ZSBh bmQgYWN0aXZlIHJvbGVzIHJlc3BlY3RpdmVseSBpbiBMRFANCnNlc3Npb24gZXN0YWJsaXNobWVu dC4gQWxzbywgYXNzdW1lIHRoZSByZWNlaXZlciBMU1LigJlzIGFkbWluaXN0cmF0aXZlDQpwb2xp Y3kgb3IgY2VydGFpbiBjb25maWd1cmVkIGF1dG9tYXRpYyBzZXNzaW9uIGxpbWl0cyByZWplY3Rz IHRoaXMNCnNlc3Npb24uIFNvIGEgcmVjZWl2ZXIgTFNSIHRoYXQgcGxheXMgYWN0aXZlIHJvbGUg aW4gTERQIHNlc3Npb24NCmVzdGFibGlzaG1lbnQgbWF5IHNlbmQgYSBpbml0aWFsaXphdGlvbiBt ZXNzYWdlIHdpdGggVEFDIFRMViBjb25zaXN0aW5nDQpvZiBubyBUQUUgZWxlbWVudHMuIEFmdGVy IHJlY2VpcHQgb2YgdGhpcyBpbml0aWFsaXphdGlvbiBtZXNzYWdlLCBhDQpzZW5kZXIgTFNSIGRl dGVybWluZXMgdGhhdCBhIGF1dG9tYXRpYyB0YXJnZXRlZCBzZXNzaW9uIGZvciByZW1vdGUgTEZB DQpjYW5ub3QgYmUgZXN0YWJsaXNoZWQuIFNvLCBpdCBzZW5kcyBhICdTZXNzaW9uIFJlamVjdGVk L1RhcmdldGVkDQpBcHBsaWNhdGlvbiBDYXBhYmlsaXR5IE1pcy1NYXRjaOKAmSBub3RpZmljYXRp b24gbWVzc2FnZSB0byB0aGUgcmVjZWl2ZXINCkxTUi4gQWxzbywgSXQgbWF5IGRlc3Ryb3kgdGhl IHRhcmdldGVkIGFkamFjZW5jeSB0aGF0IGl0IGhhcyBlc3RhYmxpc2hlZA0Kd2l0aCB0aGUgcmVj ZWl2ZXIgTFNSLiBJdCBtYXkgYWxzbyBpbmZvcm0gdGhlIGxvY2FsIElHUHMgdG8gY2hvb3NlIGEN CmRpZmZlcmVudCBQUSBub2RlIGZvciBhIHNldCBvZiByb3V0ZXMuDQoNCj4gDQo+NS4gU2VjdGlv biAzDQo+ICAgIklmIHRoZSByZWNlaXZlciBMU1IgcmVjZWl2ZXMgdGhlIHNhbWUNCj4gICAgICBU QS1JZCBpbiBtb3JlIHRoYW4gb25lIFRBRSBlbGVtZW50LCBpdCBNVVNUIGRpc2NhcmQgdGhlIFRB QyBUTFYgYW5kDQo+ICAgICAgYmVoYXZlIGFzIGlmIFRBQyBUTFYgaXMgbm90IHJlY2VpdmVkLiBJ ZiB0aGUgcmVjZWl2ZXIgTFNSIHJlY2VpdmVzDQo+YW4NCj4gICAgICB1bmtub3duIFRBLUlkIGlu IGEgVEFFIGVsZW1lbnQsIGl0IFNIT1VMRCBzaWxlbnRseSBpZ25vcmUgc3VjaCBhIFRBRQ0KPiAg ICAgIGVsZW1lbnQgYW5kIGNvbnRpbnVlIHByb2Nlc3NpbmcgdGhlIHJlc3Qgb2YgdGhlIFRMVi4i DQo+IA0KPiAgIEFsc28gaXQncyBiZXR0ZXIgdG8gaW5kaWNhdGUgc2VuZGVyIE1VU1Qgbm90IHNl bmQgbW9yZSB0aGFuIG9uZSBzYW1lDQo+VEEtSXMvVEFFLiBBbHNvIGNvbnNpZGVyIFNIT1VMRCA9 PT4gTVVTVCBpbiAgICB0aGUNCj5sYXRlciBzZW50ZW5jZSwgYXMgaXQncyBjcml0aWNhbCBmb3Ig ZnV0dXJlIFRBRSBleHRlbnNpYmlsaXR5Lg0KQWdyZWUuIEthbXJhbiBoYXMgYWxzbyBzdWdnZXN0 ZWQgYSBjaGFuZ2UgaGVyZS4gV2Ugd2lsbCBhZGRyZXNzIGJvdGgNCnRoZSBjb21tZW50cy4NCg0K PiANCj42LiBTZWN0aW9uIDMuDQo+ICAgIlNpbWlsYXJseSwgYSBMU1IgTVVTVCByZXF1ZXN0DQo+ ICAgICAgRkVDIGxhYmVsIGJpbmRpbmdzIGZvciB0aGUgbmVnb3RpYXRlZCBhcHBsaWNhdGlvbnMg b25seS4iDQo+ICAgIEkgZGlkbid0IHVuZGVyc3RhbmQgdGhpcyBzdGF0ZW1lbnQuIEhvdyB0aGlz IGhhcHBlbnMgdGhyb3VnaCBUQUM/DQpUaGlzIHRleHQgcmVmZXJzIHRvIGRvd25zdHJlYW0tb24t ZGVtYW5kIG1vZGUgbGFiZWwgcmVxdWVzdC4NCldlIHdpbGwgY2xhcmlmeSBpdC4NCg0KPiANCj43 LiBTZWN0aW9uIDUNCj4gICAgLSBZb3UgY2FuIHB1dCBhIHJlZmVyZW5jZSB0byBTZWN0aW9uIDMN Ck9raWUuDQoNCj4gDQo+IA0KPjguIFNlY3Rpb24gNw0KPiAgICAtIFRvIG1ha2Ugc3VyZSBmb3Ig YmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaXQncyBiZXR0ZXIgdG8gcHV0IGENCj5zdGF0ZW1lbnQg dG8gaW5kaWNhdGUNCj5pZiB0aGUgcmVjZWl2aW5nIExTUiBkb2Vzbid0DQo+DQo+DQo+dW5kZXJz dGFuZCBUQUMgVExWIGl0IGNhbiBpZ25vcmUgYW5kIHRoZXJlIGlzIG5vIGNoYW5nZSBpbiBleGlz dGluZw0KPnByb2NlZHVyZXMuIE15IHdvcnJ5IGlzIHRoZSBzZWxlY3RlZCBQUSBub2RlIGZyb20N Cj4NCj4NCj5JR1Avb3IgRkVDMTI5L2V0Yywgd2hpY2ggY2FuJ3QgcHJvY2VzcyBUQUMgVExWIG11 c3QgY29udGludWUgdG8gd2hhdCBpdA0KPmlzIGRvaW5nIHRvZGF5Lg0KU3VyZS4gV2Ugd2lsbCBh ZGQgbW9yZSB0ZXh0Lg0KDQoNClNhbnRvc2gNCg0K From nobody Thu Aug 14 19:09:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A711A06E5 for ; Thu, 14 Aug 2014 19:09:04 -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, 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 G0QD5XtLm9qN for ; Thu, 14 Aug 2014 19:09:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F069D1A07B3 for ; Thu, 14 Aug 2014 19:09:01 -0700 (PDT) Received: from CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) by CO2PR05MB586.namprd05.prod.outlook.com (10.141.197.145) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 15 Aug 2014 02:08:59 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 15 Aug 2014 02:08:58 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.1010.016; Fri, 15 Aug 2014 02:08:58 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Thread-Topic: IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac+4Ld0q8LjZgJCaSWC2mPffCRW61w== Date: Fri, 15 Aug 2014 02:08:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(189002)(199003)(46102001)(76576001)(19580395003)(92566001)(2656002)(4396001)(85306004)(50986999)(108616004)(15975445006)(95666004)(74316001)(101416001)(81542001)(99286002)(31966008)(64706001)(81342001)(33646002)(74502001)(106356001)(79102001)(80022001)(66066001)(575784001)(76482001)(229853001)(83072002)(21056001)(87936001)(99396002)(20776003)(54356999)(107046002)(15202345003)(85852003)(86362001)(77982001)(83322001)(74662001)(105586002)(2501001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_ab32bb98538e4b4394a7e5bb1f21543bCO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yJv3yiNR6LRL939AQN-5Rl5mXwo Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 02:09:04 -0000 --_000_ab32bb98538e4b4394a7e5bb1f21543bCO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, The authors of draft-akiya-mpls-lsp-ping-reply-mode-simple have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-akiya-mpls-lsp-ping-reply-mode-simple? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and each contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_ab32bb98538e4b4394a7e5bb1f21543bCO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
The authors of draft-akiya-mpls-lsp-ping-reply-mode-simple have told t= he
working group chairs that the draft is ready to be adopted as a workin= g
group document.
 
Before starting the poll to see if we have consensus to make this a
working group document we need to do an IPR poll.
 
This mail starts that IPR poll.
 
Are you aware of any IPR that applies to
draft-akiya-mpls-lsp-ping-reply-mode-simple?
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
 
If you are listed as a document author or contributor please respond t= o
this email regardless of whether or not you are aware of any relevant<= /div>
IPR. The response needs to be sent to the MPLS wg mailing list. The
documents will not advance to the next stage until a response
has been received from each author and each contributor.
 
If you are on the MPLS WG email list but are not listed as an author o= r
contributor, then please explicitly respond only if you are aware of a= ny
IPR that has not yet been disclosed in conformance with IETF rules.
 
Thanks, Ross
(as MPLS WG co-chair)
 
 --_000_ab32bb98538e4b4394a7e5bb1f21543bCO2PR05MB636namprd05pro_-- From nobody Thu Aug 14 22:22:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D7E1A8A15 for ; Thu, 14 Aug 2014 22:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 SfZjcwENV2V5 for ; Thu, 14 Aug 2014 22:22:24 -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 6AE201A8A0F for ; Thu, 14 Aug 2014 22:22:24 -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 CFB331801586; Fri, 15 Aug 2014 07:22:22 +0200 (CEST) Message-ID: <53ED9913.3040109@pi.nu> Date: Fri, 15 Aug 2014 07:22:27 +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: Ross Callon , "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" References: 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/mpls/QN359-V-58Ms9aJ8Nagz1ACq_xg Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 05:22:26 -0000 Ross, Working Group, I#m not aware of any IPR that applies to draft-akiya-mpls-lsp- ping-reply-mode-simple. /Loa On 2014-08-15 04:08, Ross Callon wrote: > Working Group, > The authors of draft-akiya-mpls-lsp-ping-reply-mode-simple have told the > working group chairs that the draft is ready to be adopted as a working > group document. > Before starting the poll to see if we have consensus to make this a > working group document we need to do an IPR poll. > This mail starts that IPR poll. > Are you aware of any IPR that applies to > draft-akiya-mpls-lsp-ping-reply-mode-simple? > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. The response needs to be sent to the MPLS wg mailing list. The > documents will not advance to the next stage until a response > has been received from each author and each contributor. > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > Thanks, Ross > (as MPLS WG co-chair) > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 15 05:11:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E301A0A27 for ; Fri, 15 Aug 2014 05:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.168 X-Spam-Level: X-Spam-Status: No, score=-115.168 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjoHe-TpyYkq for ; Fri, 15 Aug 2014 05:11:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03491A0A1D for ; Fri, 15 Aug 2014 05:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12129; q=dns/txt; s=iport; t=1408104717; x=1409314317; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nXYeRmv/qmFn6rfBvV+84vbSUf4yBJitCyHDVwU/y/8=; b=ko57SqXpmEzljr00eWgEKBG4b+FtHQQLiwcLj6RCu8v8fYxt1+uSESzm r2TfY940zUvpIz8u/gPbJNyBzo5WU2oyIh3/b5xzxWMZQl0hzdyHgrFyr 8Ze1vSAUdmzX+ziIGPgxwWAVzCKxyRIk447V+YKE3L53ADrbV82XtKHvS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUFAMn37VOtJV2Q/2dsb2JhbABZgkcjI1NXBNVWAYETFneEAwEBAQQtQQYFEAIBCA4DBAEBCx0HMhQJCAEBBAENBQiIOgHDZheOahACAR4xBgGDL4EdBY8KghOgG4NcbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,869,1400025600"; d="scan'208,217";a="347778748" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP; 15 Aug 2014 12:11:56 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7FCBu6g028284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Aug 2014 12:11:56 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 07:11:55 -0500 From: "Nobo Akiya (nobo)" To: Ross Callon , "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Thread-Topic: IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac+4Ld0q8LjZgJCaSWC2mPffCRW61wAU6Gtg Date: Fri, 15 Aug 2014 12:11:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.92] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943A3AB09Dxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6B9z5myIvEl6aR8BpHuURf7C8PY Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 12:11:58 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943A3AB09Dxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, I am not aware of any IPRs that apply to draft-akiya-mpls-lsp-ping-reply-mo= de-simple. Thanks! -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, August 14, 2014 10:09 PM To: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.o= rg Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple Working Group, The authors of draft-akiya-mpls-lsp-ping-reply-mode-simple have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-akiya-mpls-lsp-ping-reply-mode-simple? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and each contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_CECE764681BE964CBE1DFF78F3CDD3943A3AB09Dxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 <= /p>

I am not aware of any IPR= s that apply to draft-akiya-mpls-lsp-ping-reply-mode-simple.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, August 14, 2014 10:09 PM
To: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode-simple@tools= .ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-si= mple

 

Working Group,

 

The authors of draft-akiya-mpls-lsp-pin= g-reply-mode-simple have told the

working group chairs that the draft is = ready to be adopted as a working

group document.

 

Before starting the poll to see if we h= ave consensus to make this a

working group document we need to do an= IPR poll.

 

This mail starts that IPR poll.

 

Are you aware of any IPR that applies t= o

draft-akiya-mpls-lsp-ping-reply-mode-si= mple?

 

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

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

 

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

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

IPR. The response needs to be sent to t= he MPLS wg mailing list. The

documents will not advance to the next = stage until a response

has been received from each author and = each contributor.

 

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

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

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

 

Thanks, Ross

(as MPLS WG co-chair)=

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943A3AB09Dxmbalnx01ciscoc_-- From nobody Fri Aug 15 05:58:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293791A0A95 for ; Fri, 15 Aug 2014 05:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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=-0.668, 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 KcmNJOEE8FfQ for ; Fri, 15 Aug 2014 05:58:46 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12C01A0A91 for ; Fri, 15 Aug 2014 05:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4871; q=dns/txt; s=iport; t=1408107526; x=1409317126; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=B+XXApfwoD7N6b1+yD1ogFBxDdN8ChackuguNrW7l6o=; b=T5t5LnivP7cq9kSR7N1Ncx45uthChIBBHiBprCXm89deaxHya4gIPOlb IFgxEYoVyrhv9MjjlQkJp1gVH1h3Wj68Sl9l7ZoNJsmSEv++nSPgEihRG sKCK74cqGRgCEWiLRteiRehjS0yZHKQNsuvmO3WYr1+hz63wz40GWi34k M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgFAPgC7lOtJA2L/2dsb2JhbABZgkcjI1NXBM4DAQmHSQGBEBZ3hAQBAQQBAQFrBgUQAgEIBAoxBycLFBEBAQQOBYhCAQzDZhMEjmoQAgFLBAeDL4EdBY8KghOLHZR+g1xsgUiBBwEBAQ X-IronPort-AV: E=Sophos; i="5.01,870,1400025600"; d="scan'208,217"; a="69539515" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 15 Aug 2014 12:58:44 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7FCwiar026873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Aug 2014 12:58:44 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 07:58:44 -0500 From: "Carlos Pignataro (cpignata)" To: Ross Callon Thread-Topic: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac+4Ld0q8LjZgJCaSWC2mPffCRW61wAhLE+A Date: Fri, 15 Aug 2014 12:58:43 +0000 Message-ID: <9076DA8B-BC7F-48EA-96D3-07BE9FE47A2F@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.31] Content-Type: multipart/alternative; boundary="_000_9076DA8BBC7F48EA96D307BE9FE47A2Fciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/X5Ia3bSoGA38uN0AazkID-_EDcw Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 12:58:48 -0000 --_000_9076DA8BBC7F48EA96D307BE9FE47A2Fciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ross, I am not aware of any IPR that applies to draft-akiya-mpls-lsp-ping-reply-m= ode-simple. Thanks, Carlos. On Aug 14, 2014, at 10:08 PM, Ross Callon > wrote: Working Group, The authors of draft-akiya-mpls-lsp-ping-reply-mode-simple have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-akiya-mpls-lsp-ping-reply-mode-simple? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and each contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_9076DA8BBC7F48EA96D307BE9FE47A2Fciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Ross,

I am not aware of any IPR that applies to draft-akiya-mpls-lsp-pi= ng-reply-mode-simple.

Thanks,

Carlos.

On Aug 14, 2014, at 10:08 PM, Ross Callon <rcallon@juniper.net> wrote:

Working Group,
 
The authors of draft-akiya-mpls-lsp-ping-reply-mode-simple have told t= he
working group chairs that the draft is ready to be adopted as a workin= g
group document.
 
Before starting the poll to see if we have consensus to make this a
working group document we need to do an IPR poll.
 
This mail starts that IPR poll.
 
Are you aware of any IPR that applies to
draft-akiya-mpls-lsp-ping-reply-mode-simple?
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
 
If you are listed as a document author or contributor please respond t= o
this email regardless of whether or not you are aware of any relevant<= /div>
IPR. The response needs to be sent to the MPLS wg mailing list. The
documents will not advance to the next stage until a response
has been received from each author and each contributor.
 
If you are on the MPLS WG email list but are not listed as an author o= r
contributor, then please explicitly respond only if you are aware of a= ny
IPR that has not yet been disclosed in conformance with IETF rules.
 
Thanks, Ross
(as MPLS WG co-chair)
 
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls

--_000_9076DA8BBC7F48EA96D307BE9FE47A2Fciscocom_-- From nobody Sun Aug 17 09:05:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6508F1A6EEE for ; Sun, 17 Aug 2014 09:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq1H1zj2VdqZ for ; Sun, 17 Aug 2014 09:05:17 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B6B1A0ADB for ; Sun, 17 Aug 2014 09:05:16 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7HG5FrR002913; Sun, 17 Aug 2014 17:05:15 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7HG5DTs002888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Aug 2014 17:05:14 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" Date: Sun, 17 Aug 2014 17:05:13 +0100 Message-ID: <06c701cfba35$07ded1f0$179c75d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+6NNdQYMZuUb/PRAyV4479vSjwGw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20888.000 X-TM-AS-Result: No--18.015-10.0-31-10 X-imss-scan-details: No--18.015-10.0-31-10 X-TMASE-MatchedRID: PL66URbwWA95X0FJZbmEpuKz6mYKsvd3I5K4Cd+0ao+JxYfvjC/4gXAz y9YCNvJNQx95p3GYmc/30M4BlQhibSbZZYAQu9H5RlqShqb35p5A8JZETQujwm3D6f6IpbLIIQu L2QZAP/ZEIDB0955iH9koYjZ1VU10wp/mM9QGaq0UEm127/0kJnCvKh73RRywm3Hpsj8Q7hpHD+ SkpO+ot9oJzHox6CmW0bURCJymuzDdWSaa0iXMMIzb2GR6Ttd3h8Ytn75ClDOlyfbzMrA/whx+V qz4tnVruTPW3ZB/ST2zzbH1Vt8BVGKplHd7ThK1Q1OcCEvT+beAfODDLypXmnZakP/I6lpU6ZSX gqg5qssxcSfgz4Zxa1PsHSOl9OEqGHMruoCVNItCvapcIkxJX0J1RkW+/L6QnSPw4pGdVDwHam+ XwtBHJTIkYUj5XXPlXonTEt217jWVhIWL9FEuN3C+Q0h5+aC3C4rWEiK1IgdizP0XgUsFMI73c7 ZtNgNX4vM1YF6AJbZcLc3sLtjOt1ZFWWuOwo7w3QfwsVk0UbslCGssfkpInQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yH7gNlxhFFO2aa0eRQXpmMgSoa8 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-ipv6@tools.ietf.org Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 16:05:19 -0000 Loa, Thank you for bringing this to the attention of the working group. Of course, concerns that there may be problems with a specification are very important. And, furthermore, worries that a new draft may interact badly with a published specification need to be thought through. However, there are a few points of process here: - The IETF does not evaluate conformance to IETF specifications. There are test labs that do this, and operators will make their own evaluations. - Private comments can't have a lot of impact on a working group last call. If there are private comments that the chairs consider to be actionable, they may bring them to the list as part of the last call, but in this case the comments don't appear to contain anything that anyone can work on. - Empty "there is a problem" comments are actually disruptive to progress in the IETF. They raise the worry level, but don't supply something that we can address. In fact, they harmful because we can't even refute the comments. So I must ask that if you have a concern about an RFC or an Internet-Draft you substantiate your issue, or not raise it at all. So, Loa, I think you have been really generous in offering until September 1st for your anonymous correspondent to supply more information. You *are* right to spend some time trying to understand what the issue is, but you do not currently have anything (as far as I can see) that justifies holding up a working group draft. I would like to see the issue raised publically within the next few days (it is surely as simple as a sequence of message exchanges in a particular topology), and I would like to see the working group work move forward without further delay. Thanks, Adrian > Working Group, > > During what we thought would be a short wglc on draft-ietf-mpls-ldp-ipv6 > http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html > we had a comment that stopped us from continuing progressing the > draft. > > The short working group last call is now closed! > > The comment we refer to was raised in a private mail to the working > group chairs and the draft authors. > > It says that there are a problem with some RFC 5036 non-compliant > implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no > detailed description of the exact problems. > > We strongly encourage the people that made the comment(s) to write-up > the problem, either as > > - a new draft (preferred); or > - in a mail to the working group mailing list > > Once we an agreement to write a new draft or the write-up to the > mailing, we will continue to ask the working group to see if we > can agree to a way to progress. We like to see this > write-up before September 1. Failing this we will continue to > progress the draft-ietf-mpls-ldp-ipv6 as is. > > /Loa > for the working group chairs From nobody Sun Aug 17 09:41:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7230E1A0AF1 for ; Sun, 17 Aug 2014 09:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 L90D3yq5XEx6 for ; Sun, 17 Aug 2014 09:41:30 -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 F30041A0AF0 for ; Sun, 17 Aug 2014 09:41:29 -0700 (PDT) Received: from [192.168.0.152] (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 217AF1801586; Sun, 17 Aug 2014 18:41:28 +0200 (CEST) Message-ID: <53F0DB3C.2010403@pi.nu> Date: Sun, 17 Aug 2014 18:41:32 +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: adrian@olddog.co.uk References: <06c701cfba35$07ded1f0$179c75d0$@olddog.co.uk> In-Reply-To: <06c701cfba35$07ded1f0$179c75d0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FNospDkpDhMTMNk3Vu8265dNPLI Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-ipv6@tools.ietf.org Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 16:41:32 -0000 Adrian, I'm not happy delay things unless necessary. What I did was to use my normal method to allocate time - allow for two weeks and then go to the next Monday. However I agree with you about the core of your message - the comments that were made private to the wg chairs needs to be brought out in the open. I hope that all the time I allowed for is not necessary. /Loa On 2014-08-17 18:05, Adrian Farrel wrote: > Loa, > > Thank you for bringing this to the attention of the working group. > > Of course, concerns that there may be problems with a specification are very > important. And, furthermore, worries that a new draft may interact badly with a > published specification need to be thought through. > > However, there are a few points of process here: > > - The IETF does not evaluate conformance to IETF specifications. > There are test labs that do this, and operators will make their > own evaluations. > - Private comments can't have a lot of impact on a working group > last call. If there are private comments that the chairs consider to > be actionable, they may bring them to the list as part of the last > call, but in this case the comments don't appear to contain anything > that anyone can work on. > - Empty "there is a problem" comments are actually disruptive to > progress in the IETF. They raise the worry level, but don't supply > something that we can address. In fact, they harmful because we > can't even refute the comments. So I must ask that if you have a > concern about an RFC or an Internet-Draft you substantiate your > issue, or not raise it at all. > > So, Loa, I think you have been really generous in offering until September 1st > for your anonymous correspondent to supply more information. You *are* right to > spend some time trying to understand what the issue is, but you do not currently > have anything (as far as I can see) that justifies holding up a working group > draft. I would like to see the issue raised publically within the next few days > (it is surely as simple as a sequence of message exchanges in a particular > topology), and I would like to see the working group work move forward without > further delay. > > Thanks, > Adrian > >> Working Group, >> >> During what we thought would be a short wglc on draft-ietf-mpls-ldp-ipv6 >> http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html >> we had a comment that stopped us from continuing progressing the >> draft. >> >> The short working group last call is now closed! >> >> The comment we refer to was raised in a private mail to the working >> group chairs and the draft authors. >> >> It says that there are a problem with some RFC 5036 non-compliant >> implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no >> detailed description of the exact problems. >> >> We strongly encourage the people that made the comment(s) to write-up >> the problem, either as >> >> - a new draft (preferred); or >> - in a mail to the working group mailing list >> >> Once we an agreement to write a new draft or the write-up to the >> mailing, we will continue to ask the working group to see if we >> can agree to a way to progress. We like to see this >> write-up before September 1. Failing this we will continue to >> progress the draft-ietf-mpls-ldp-ipv6 as is. >> >> /Loa >> for the working group chairs > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Aug 17 11:22:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D551D1A6EE5 for ; Sun, 17 Aug 2014 11:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG3kr1fbbSLV for ; Sun, 17 Aug 2014 11:22:06 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4921A6EDE for ; Sun, 17 Aug 2014 11:22:05 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7HI5xUL012152; Sun, 17 Aug 2014 19:05:59 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7HI5vOe012137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Aug 2014 19:05:58 +0100 From: "Adrian Farrel" To: Date: Sun, 17 Aug 2014 19:22:02 +0100 Message-ID: <06e201cfba48$24b3f9a0$6e1bece0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+6R3RLWxhNzQFXRc+TIr3TW5VCYg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20888.001 X-TM-AS-Result: No--29.636-10.0-31-10 X-imss-scan-details: No--29.636-10.0-31-10 X-TMASE-MatchedRID: rR9SQp8n2dxwewo1JL58DpRrnSy7UTtbXArLpqs9pJeW6aHRAuYExuln +pgUTqXBJKelhEebHIrnFWX1H4WVLOyBTqRThUr4zfqlpbtmcWh+S5m2/8VLmgDqzaYhcjeQYeX iJQtwbqjNfhMgDv/TiugAXWK39NLrxk7kOw4baTy8coKUcaOOveEpCHUsKYYG58v7MqNbTw/+tn MvnQl+U0ZPa0R9xjYKYgmUdNZEqvomWgeLnf+I3sRS0pbiOfKbwx0jRRxcQfNb6PBUqmq+UhIa2 MQc6yOtA+1Cw+zo9m8aW3+/a2cKO2d1WQDtWDTe9iItFUn3XkMsCc2iFTIxrYhlq83HEbL+kWfo M00aVNWc+vypK/WgT4Pw2ImgZOS97pBy5pcTJk5/HPKCjG4GGCT0t/+p7zHHut/GVGOoEnfB7Rx JsavfmNSjf9BU2enRxOT4OGpRn+JKpIM6MfwkGtIxRgow+5HIQrO4XR6BRQNV84HrPxCfbN8lZU Js+jSVyRrQJ+IvwCF3sqgIgdNXCIqtuuQ+CE7v1yMJs9mBCcWWesyrtKuK7f5haBSHR9bSgUqye +KycddEHijcdv8wMGNgTjvv/dCebTSwI/A2DvAHTkHUtPYzxYEcpMn6x9cZbJknz+3f3aWfWSIE J+NgXck+095v7bSMoSWcn13UXYgI77GTXnM5dM54hX4xV6jOBdebOqawiLvavz7oGUu5YWl+DC5 61taOmKgXX6uw1Drm3aJkBiqr2SqDVw6LinnH8pNSxwfBkFuimsR6hkcJAvgnJH5vm2+gFtnjZo nmoTd8FhDt6fPste8jeyPPWZz1o28kkGKrXVqeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07QKmARN5PTKc Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NhkVYH5Tbswu-7S32FZM0kFljHM Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 18:22:09 -0000 Hello, Thanks for this draft. It completes another piece of the puzzle. I have done my normal AD review to respond to the publication request. I didn't find any show-stoppers, but I have a number of minor issues and questions. As is usual, you should feel free (you are actively encouraged!) to tell me I am wrong or that a change does not need to be made. I await your response either through email or with a revised I-D. Thanks for the work, Adrian === Do you really need the pre-RFC5378 disclaimer? --- Please check for acronym expansions. I see: LSR --- A little inconsistency in "a LSP" and "an LSP". --- Section 2 would be enhanced by a figure. Something like... R3--R5---egress1 / / ingress---R1---R2--Proxy--R6---egress2 / \ / \ / R7--R8---egress3 / \ R4 \ / R9--egress4 / \ / \ initiator egress5 Together with some explanatory text. --- In 3.2 you have An MPLS proxy ping reply message MAY be sent with a Return Code of , "Proxy Ping not authorized". Should read --- Looking back at 4379, it is not clear to me how a legacy implementation listening on port 3503 will react to receiving the new message type for a proxy message. The text is phrased in terms of the ability to parse an echo request/reply, and clearly the new message is neither of these. So do you believe this is covered by 4379 section 4.4 1. General packet sanity is verified. If the packet is not well- formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code set to "Malformed echo request received" and the Subcode to zero. You could make a case for that, although it is inside a section that implies that the message type has already been determined and immediately follows the text... An LSR X that receives an MPLS echo request then processes it as follows. (Also compare with section 4.6). Anyway, you should include text on backward compatibility. 1. The case just described 2. The case where a targetted proxy doesn't support LSP ping at all. --- Section 3.2 If not, it sets the Return Code set to "Malformed echo request received" or "TLV not understood" (as appropriate) Delete "set" Worry about "as appropriate" because it assumes that the reader will make the right choice where you probably want to be more prescriptive. --- Section 3.2 If the Reply Mode of the message header is not 1(Do not reply), an MPLS proxy ping reply message SHOULD be sent as described below. In the latter case, the misunderstood TLVs (only) are included in an Errored TLVs TLV. "the latter case"? --- 3.2 If not, it sets the Return Code set to "Malformed echo request received" and the Subcode set to zero. Delete "set" --- 3.2.1 has some lower case "should". Probably worth checking the whole document for consistent 2119 usage. --- 3.2.2. When the Proxy LSR is a transit or bud node, downstream maps corresponding to how the packet is transited can not be supplied unless an ingress interface for the MPLS Echo Request is specified, since this information is not available and since all valid output paths are of interest, the Proxy LSR should include DS/DDMAP(s) to describe the entire set of paths that the packet can be replicated, like in the case where an LSP ping is initiated at the Proxy LSR. Is that two sentences with "...specified. Since..."? I'm not sure what purpose Section 4.1 serves. I don't like that you have created a second (normative?) description of the message format. Couldn't you just say: The format of MPLS LSP Ping messages is defined in [RFC4379]. This document defines two new message types as follows: Type Message ---- ------- TBA-1 MPLS proxy ping request (Pending IANA assignment) TBA-2 MPLS proxy ping reply (Pending IANA assignment) --- The security considerations say: If such a network also carries Internet traffic, or permits IP access from other administrations, MPLS proxy ping message SHOULD be discarded at those points. This can be accomplished by filtering on source address or by filtering all MPLS ping messages on UDP port. I think that the mechanisms you describe here would also prohibit normal LSP ping from transiting the network boundary. This is probably what you intend, but I note that 4379 does not make this recommendation so the filtering you suggest here for proxy ping would have an effect on all LSP ping function and changes the behavior of 4379. The way to handle this, I think, is to paint it red. That is, say that this is an additional filter compared to the advice in 4379, but it is a damn fine idea. Alternatively, you need to step back slightly and call on the border nodes to look into the message type field. --- It seems that proxy ping messages would be relatively easy to spoof. This, combined with the fact that the receipt of a proxy ping causes the proxy to retain state and to issue echo requests to the network looks like two DoS vectors for the price of one. So, I think you need: - discussion of authentication for proxy requests - recommendation to rate limit receipt of proxy requests - recommendation to discard "duplicate" proxy requests --- I'm not quite sure about the initiator being allowed to instruct the proxy about which source port it must use in an echo request. (Incidentally, Section 3.2 doesn't restate that this has to happen although 3.2.4.1 does restate it). What happens if the proxy request asks for a reserved port number to be used? What if the port is already in use by the proxy for something else? Why does it matter which source port the proxy uses? Why does the proxy need to be able to control that? Why can't the proxy select its own source port? --- Should the point from 3.2.4.2 be echoed in the Security Considerations? If any additional labels are pushed onto the stack, their TTLs are set to 255. This will ensure that the requestor will not have control over tunnels not relevant to the FEC being tested. From nobody Sun Aug 17 18:23:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38431A011B for ; Sun, 17 Aug 2014 18:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 LLU0XWMpzMI1 for ; Sun, 17 Aug 2014 18:23:52 -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 479201A0115 for ; Sun, 17 Aug 2014 18:23:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLJ13501; Mon, 18 Aug 2014 01:23:49 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Aug 2014 02:23:48 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 18 Aug 2014 09:23:42 +0800 From: Mach Chen To: Ross Callon , "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Thread-Topic: IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac+4Ld0q8LjZgJCaSWC2mPffCRW61wCVQO/w Date: Mon, 18 Aug 2014 01:23:41 +0000 Message-ID: References: In-Reply-To: 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: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA8954ASZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2vkB6YRs9x3uNdPTMLClBBKCOz8 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 01:23:55 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA8954ASZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, I'm not aware of any IPR that applies to this draft. Best regards, Mach From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, August 15, 2014 10:09 AM To: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.o= rg Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple Working Group, The authors of draft-akiya-mpls-lsp-ping-reply-mode-simple have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-akiya-mpls-lsp-ping-reply-mode-simple? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and each contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA8954ASZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Ross,=

=  

= I’m not aware of any IPR th= at applies to this draft.

=  

= Best regards,

= Mach

=  

From: mpls [mailto:mpls-bounces@ietf.org] On= Behalf Of Ross Callon
Sent: Friday, August 15, 201= 4 10:09 AM
To: mpls@ietf.org; draft-aki= ya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org
Cc: mpls-chairs@tools.ietf.o= rg
Subject: [mpls] IPR poll for= draft-akiya-mpls-lsp-ping-reply-mode-simple

 

Working Group= ,

 

The authors o= f draft-akiya-mpls-lsp-ping-reply-mode-simple have told the

working group= chairs that the draft is ready to be adopted as a working

group documen= t.

 

Before starti= ng the poll to see if we have consensus to make this a

working group= document we need to do an IPR poll.

 

This mail sta= rts that IPR poll.

 

Are you aware= of any IPR that applies to

draft-akiya-m= pls-lsp-ping-reply-mode-simple?

 

If so, has th= is IPR been disclosed in compliance with IETF IPR rules

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

 

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

this email re= gardless of whether or not you are aware of any relevant<= /font>

IPR. The resp= onse needs to be sent to the MPLS wg mailing list. The

documents wil= l not advance to the next stage until a response

has been rece= ived from each author and each contributor.

 

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

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

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

 

Thanks, Ross<= o:p>

(as MPLS WG c= o-chair)

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA8954ASZXEMA510MBXchi_-- From nobody Mon Aug 18 13:05:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DFE1A6F2A for ; Mon, 18 Aug 2014 13:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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=-0.668, 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 q-yvAWJf2VRu for ; Mon, 18 Aug 2014 13:05:14 -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 BA73B1A6F2B for ; Mon, 18 Aug 2014 13:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17456; q=dns/txt; s=iport; t=1408392313; x=1409601913; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9XL64nVT2HWfk8mZ2F9k+hHcDP9XRyLF9VANX+Ihd1c=; b=eibN5WgZ3i6BjgvYIkZYvy2d5b7WwxweFo9XBLrl3Bc5FRtHyiyETGzU duXJ/jVY+7VV2hJ4Mw2/TAsCJAZiBzsSYZmeEtGiLYk5M2aE8g/c++S5J ujR+pe4gnAempLYIgOJKPW0tK3S/pvPXdBgs2iadtxCMlUkWayMGS4p3r M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAKVb8lOtJV2Z/2dsb2JhbABZgkdGU1cEgnjRYAEZgQYWd4QDAQEBBCMKQQYFEAIBCA4DAwEBASgDAgICMBQJCAEBBAENBYhCrC6VLxeOahACATQKEQYBgnmBUwWPEoITix2VA4NdbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,888,1400025600"; d="scan'208,217";a="348495335" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 18 Aug 2014 20:05:12 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7IK5CSG006715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 20:05:12 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 15:05:12 -0500 From: "Shaleen Saxena (ssaxena)" To: Ross Callon , "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Thread-Topic: IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac+4Ld0q8LjZgJCaSWC2mPffCRW61wCWwuaQACfLxIA= Date: Mon, 18 Aug 2014 20:05:11 +0000 Message-ID: References: <19a022b6473142b3af5b246833db3cad@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <19a022b6473142b3af5b246833db3cad@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [161.44.71.102] Content-Type: multipart/alternative; boundary="_000_D017D478396DAssaxenaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6MtrXB9HO6p4CKOJkqssRejDJ_o Cc: "mpls-chairs@tools.ietf.org" , "Shaleen Saxena \(ssaxena\)" Subject: Re: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 20:05:29 -0000 --_000_D017D478396DAssaxenaciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9zcywNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdC4NCg0KUmVnYXJkcywNClNoYWxlZW4NCg0KDQpGcm9tOiBSb3NzIENhbGxvbiA8cmNh bGxvbkBqdW5pcGVyLm5ldDxtYWlsdG86cmNhbGxvbkBqdW5pcGVyLm5ldD4+DQpEYXRlOiBTdW5k YXksIEF1Z3VzdCAxNywgMjAxNCBhdCAxMDowOCBQTQ0KVG86IFNoYWxlZW4gU2F4ZW5hIDxzc2F4 ZW5hQGNpc2NvLmNvbTxtYWlsdG86c3NheGVuYUBjaXNjby5jb20+PiwgIkdlb3JnZSBTd2FsbG93 IChzd2FsbG93KSIgPHN3YWxsb3dAY2lzY28uY29tPG1haWx0bzpzd2FsbG93QGNpc2NvLmNvbT4+ DQpDYzogUm9zcyBDYWxsb24gPHJjYWxsb25AanVuaXBlci5uZXQ8bWFpbHRvOnJjYWxsb25AanVu aXBlci5uZXQ+Pg0KU3ViamVjdDogRlc6IElQUiBwb2xsIGZvciBkcmFmdC1ha2l5YS1tcGxzLWxz cC1waW5nLXJlcGx5LW1vZGUtc2ltcGxlDQoNClNoYWxlZW47DQoNCllvdSBhcmUgbGlzdGVkIGFz IGEg4oCcQ29udHJpYnV0aW5nIEF1dGhvcuKAnSB0byB0aGlzIGRyYWZ0LiBBcyBzdWNoIHlvdSBh bHNvIG5lZWQgdG8gcmVzcG9uZCB0byB0aGUgSVBSIHBvbGwgKGFzIGRvZXMgR2VvcmdlKSBiZWZv cmUgd2UgdGFrZSB0aGUgbmV4dCBzdGVwIOKAkyB3aGljaCB3aWxsIGJlIHN0YXJ0aW5nIHRoZSBX RyBwb2xsIGZvciBhZG9wdGlvbi4NCg0KVGhhbmtzLCBSb3NzDQoNCkZyb206IG1wbHMgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb3NzIENhbGxvbg0KU2VudDog VGh1cnNkYXksIEF1Z3VzdCAxNCwgMjAxNCAxMDowOSBQTQ0KVG86IG1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+OyBkcmFmdC1ha2l5YS1tcGxzLWxzcC1waW5nLXJlcGx5LW1vZGUt c2ltcGxlQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1ha2l5YS1tcGxzLWxzcC1waW5nLXJl cGx5LW1vZGUtc2ltcGxlQHRvb2xzLmlldGYub3JnPg0KQ2M6IG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFttcGxz XSBJUFIgcG9sbCBmb3IgZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1yZXBseS1tb2RlLXNpbXBs ZQ0KDQpXb3JraW5nIEdyb3VwLA0KDQpUaGUgYXV0aG9ycyBvZiBkcmFmdC1ha2l5YS1tcGxzLWxz cC1waW5nLXJlcGx5LW1vZGUtc2ltcGxlIGhhdmUgdG9sZCB0aGUNCndvcmtpbmcgZ3JvdXAgY2hh aXJzIHRoYXQgdGhlIGRyYWZ0IGlzIHJlYWR5IHRvIGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nDQpn cm91cCBkb2N1bWVudC4NCg0KQmVmb3JlIHN0YXJ0aW5nIHRoZSBwb2xsIHRvIHNlZSBpZiB3ZSBo YXZlIGNvbnNlbnN1cyB0byBtYWtlIHRoaXMgYQ0Kd29ya2luZyBncm91cCBkb2N1bWVudCB3ZSBu ZWVkIHRvIGRvIGFuIElQUiBwb2xsLg0KDQpUaGlzIG1haWwgc3RhcnRzIHRoYXQgSVBSIHBvbGwu DQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8NCmRyYWZ0LWFraXlh LW1wbHMtbHNwLXBpbmctcmVwbHktbW9kZS1zaW1wbGU/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIg YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJG Q3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KSWYgeW91 IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJl c3BvbmQgdG8NCnRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJl IGF3YXJlIG9mIGFueSByZWxldmFudA0KSVBSLiBUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2Vu dCB0byB0aGUgTVBMUyB3ZyBtYWlsaW5nIGxpc3QuIFRoZQ0KZG9jdW1lbnRzIHdpbGwgbm90IGFk dmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZQ0KaGFzIGJlZW4gcmVjZWl2 ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgZWFjaCBjb250cmlidXRvci4NCg0KSWYgeW91IGFyZSBv biB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Ig b3INCmNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5 b3UgYXJlIGF3YXJlIG9mIGFueQ0KSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQg aW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQpUaGFua3MsIFJvc3MNCihhcyBNUExT IFdHIGNvLWNoYWlyKQ0KDQo= --_000_D017D478396DAssaxenaciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb3NzLDwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0 aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PlNoYWxlZW48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxl ZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6 IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFE RElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJ R0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPlJvc3MgQ2FsbG9uICZsdDs8YSBocmVmPSJtYWlsdG86 cmNhbGxvbkBqdW5pcGVyLm5ldCI+cmNhbGxvbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5TdW5kYXksIEF1Z3VzdCAx NywgMjAxNCBhdCAxMDowOCBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzogPC9zcGFuPlNoYWxlZW4gU2F4ZW5hICZsdDs8YSBocmVmPSJtYWlsdG86c3NheGVuYUBjaXNj by5jb20iPnNzYXhlbmFAY2lzY28uY29tPC9hPiZndDssICZxdW90O0dlb3JnZSBTd2FsbG93IChz d2FsbG93KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN3YWxsb3dAY2lzY28uY29tIj5zd2Fs bG93QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkNjOiA8L3NwYW4+Um9zcyBDYWxsb24gJmx0OzxhIGhyZWY9Im1haWx0bzpyY2FsbG9uQGp1bmlw ZXIubmV0Ij5yY2FsbG9uQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPkZXOiBJUFIgcG9sbCBmb3IgZHJhZnQtYWtp eWEtbXBscy1sc3AtcGluZy1yZXBseS1tb2RlLXNpbXBsZTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHht bG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0i dXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3 dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBG b250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLmVtYWlscXVvdGUsIGxp LmVtYWlscXVvdGUsIGRpdi5lbWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1lOmVtYWlscXVvdGU7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDoxLjBwdDsNCglib3JkZXI6bm9uZTsN CglwYWRkaW5nOjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlNoYWxlZW47 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+WW91IGFyZSBs aXN0ZWQgYXMgYSDigJxDb250cmlidXRpbmcgQXV0aG9y4oCdIHRvIHRoaXMgZHJhZnQuIEFzIHN1 Y2ggeW91IGFsc28gbmVlZCB0byByZXNwb25kIHRvIHRoZSBJUFIgcG9sbCAoYXMgZG9lcyBHZW9y Z2UpIGJlZm9yZSB3ZSB0YWtlIHRoZSBuZXh0DQogc3RlcCDigJMgd2hpY2ggd2lsbCBiZSBzdGFy dGluZyB0aGUgV0cgcG9sbCBmb3IgYWRvcHRpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPlRoYW5rcywgUm9zczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7 Ij4gbXBscyBbPGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvc3MgQ2FsbG9u PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMTQsIDIwMTQgMTA6MDkgUE08YnI+ DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWFraXlhLW1wbHMtbHNwLXBpbmctcmVwbHktbW9k ZS1zaW1wbGVAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1yZXBs eS1tb2RlLXNpbXBsZUB0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+bXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFttcGxzXSBJUFIgcG9sbCBmb3IgZHJhZnQt YWtpeWEtbXBscy1sc3AtcGluZy1yZXBseS1tb2RlLXNpbXBsZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPldvcmtpbmcgR3JvdXAs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPlRoZSBhdXRob3JzIG9mIGRyYWZ0LWFraXlhLW1w bHMtbHNwLXBpbmctcmVwbHktbW9kZS1zaW1wbGUgaGF2ZSB0b2xkIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+d29y a2luZyBncm91cCBjaGFpcnMgdGhhdCB0aGUgZHJhZnQgaXMgcmVhZHkgdG8gYmUgYWRvcHRlZCBh cyBhIHdvcmtpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPmdyb3VwIGRvY3VtZW50Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPkJlZm9yZSBzdGFydGluZyB0aGUgcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25z ZW5zdXMgdG8gbWFrZSB0aGlzIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPndvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgd2Ug bmVlZCB0byBkbyBhbiBJUFIgcG9sbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+VGhpcyBt YWlsIHN0YXJ0cyB0aGF0IElQUiBwb2xsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5BcmUg eW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPmRyYWZ0LWFr aXlhLW1wbHMtbHNwLXBpbmctcmVwbHktbW9kZS1zaW1wbGU/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiPklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3 aXRoIElFVEYgSVBSIHJ1bGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4oc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBh bmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+SWYg eW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNl IHJlc3BvbmQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPnRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9y IG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+SVBSLiBUaGUgcmVz cG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTVBMUyB3ZyBtYWlsaW5nIGxpc3QuIFRoZQ0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij5kb2N1bWVudHMgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1 bnRpbCBhIHJlc3BvbnNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5oYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0 aG9yIGFuZCBlYWNoIGNvbnRyaWJ1dG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5JZiB5 b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFu IGF1dGhvciBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyI+Y29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkg cmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5JUFIgdGhhdCBo YXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPlRoYW5rcywgUm9zczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+KGFzIE1Q TFMgV0cgY28tY2hhaXIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D017D478396DAssaxenaciscocom_-- From nobody Tue Aug 19 00:19:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28971A014F for ; Tue, 19 Aug 2014 00:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 nDqH915OeYra for ; Tue, 19 Aug 2014 00:19:00 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EC21A87A7 for ; Tue, 19 Aug 2014 00:18:57 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 465B233444692; Tue, 19 Aug 2014 07:18:55 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s7J7Ispc010085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Aug 2014 03:18:54 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 19 Aug 2014 03:18:54 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "mpls@ietf.org" Thread-Topic: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) Thread-Index: AQHPtkReGJe0hsllSUWt55jdwggY6ZvXguRQ Date: Tue, 19 Aug 2014 07:18:53 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <53EA3666.2040004@pi.nu> In-Reply-To: <53EA3666.2040004@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/W_4RqFehgEZz5-pQ3WB7MSxbc5w Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 07:19:03 -0000 Dear all, The following are the details of the issue we found and the proposed soluti= on. We shared this first with the authors to get initial feedback. When an LSR which supports LDP IPv6 according to this draft is in a LAN wit= h a broadcast interface, it can peer with LSRs which support this draft and= LSRs which do not. When it peers using IPv4 LDP control plane with an LSR = which does not support this draft, we have seen during our testing an issue= that the advertisement of IPv6 addresses or IPv6 FECs to that peer will ca= use it to bring down the IPv4 LDP session. In other words, there are deployed LDP implementations which are compliant = to RFC 5036 for LDP IPv4 but are not compliant to RFC 5036 when it comes to= handling IPv6 address or IPv6 FECs over an LDP IPv4 session. This is makin= g us very concerned that when users enable dual-stack LDP IPv4/IPv6, they w= ill bring down LDP IPv4 sessions which have been working in a multi-vendor = environments for so many years. The proposed solution is to have implementations complying to this draft ad= vertise the IPv6 prefix state advertisement control capability (draft-ietf-= mpls-ldp-ip-pw-capability-07) in the initialization message explicitly indi= cating support for LDP IPv6. Without the peer advertising this capability, = an LSR must not send IPv6 addresses and FECs to that peer.=20 This approach is safer and has been followed when mLDP FEC was introduced a= s explained in Section 2.1 of RFC 6388. Also, this does not introduce any n= ew TLV to draft-ietf-mpls-ldp-ipv6. It just makes the exchange of LDP IPv6 = addresses and FECs conditional to both peers explicitly indicating support = for IPv6 capability during LDP session initialization.=20 We do not feel such a simple change justifies writing a new draft and havin= g to deal with backward compatibility of implementations across two drafts.= =20 We appreciate your comments on this matter. Regards, Mustapha. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, August 12, 2014 11:45 AM=09 > To: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-ipv6@t= ools.ietf.org > Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc clos= ed) >=20 > Working Group, >=20 > During what we thought would be a short wglc on draft-ietf-mpls-ldp-ipv6 > http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html > we had a comment that stopped us from continuing progressing the draft. >=20 > The short working group last call is now closed! >=20 > The comment we refer to was raised in a private mail to the working group= chairs > and the draft authors. >=20 > It says that there are a problem with some RFC 5036 non-compliant > implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no detail= ed > description of the exact problems. >=20 > We strongly encourage the people that made the comment(s) to write-up the > problem, either as >=20 > - a new draft (preferred); or > - in a mail to the working group mailing list >=20 > Once we an agreement to write a new draft or the write-up to the mailing,= we will > continue to ask the working group to see if we can agree to a way to prog= ress. We > like to see this write-up before September 1. Failing this we will contin= ue to progress > the draft-ietf-mpls-ldp-ipv6 as is. >=20 > /Loa > for the working group chairs > -- >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Aug 19 13:49:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9131A6F2E for ; Tue, 19 Aug 2014 13:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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=-0.668, 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 1qsSy-10OArG for ; Tue, 19 Aug 2014 13:48:48 -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 E16D11A013B for ; Tue, 19 Aug 2014 13:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14408; q=dns/txt; s=iport; t=1408481323; x=1409690923; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=OTOQLj6nudptM32YT4XYkzxzoXo1bd5U4YpnbgDQmfM=; b=SHwhjirQGgZ84giAIbYJGGLKWpV7UHSLaSMo0nwBCYSDo4nn6xjokHn5 d0SYkhkoNIPDhLugRh/6PAzUAbCCCmXrlX0UCOywOzEwuAC1Q7ayIC4g0 M0sdocQ4512oBLb5Tc4J1/w+UtpyuXp1gm2s187Tkjjbe2lYhW/tkomS5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FANO381OtJV2U/2dsb2JhbABagkdGU1cE1EgBgQwWd4QDAQEBBC1BBgUSAQgRAwEBASg5FAkIAQEEAQ0FiELBDBeOahACAT4RBgGETAWPEoITix2VA4NdbIFIgQcBAQE X-IronPort-AV: E=Sophos; i="5.01,897,1400025600"; d="scan'208,217"; a="70638445" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP; 19 Aug 2014 20:48:24 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7JKmO05021688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Aug 2014 20:48:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 19 Aug 2014 15:48:24 -0500 From: "George Swallow (swallow)" To: "Nobo Akiya (nobo)" , Ross Callon , "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Thread-Topic: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac+4Ld0q8LjZgJCaSWC2mPffCRW61wAU6GtgAN1y8QA= Date: Tue, 19 Aug 2014 20:48:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.86.253.50] Content-Type: multipart/alternative; boundary="_000_D019302220576swallowciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/o5coAUcX8Kx-Cvyn7Vvxajknej4 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 20:48:52 -0000 --_000_D019302220576swallowciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ross - I am not aware of any IPR for the subject draft. George From: "Nobo Akiya (nobo)" > Date: Friday, August 15, 2014 8:11 AM To: Ross Callon >, "mpls@ie= tf.org" >, "draft= -akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" > Cc: "mpls-chairs@tools.ietf.org" > Subject: Re: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simpl= e Hi Ross, I am not aware of any IPRs that apply to draft-akiya-mpls-lsp-ping-reply-mo= de-simple. Thanks! -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, August 14, 2014 10:09 PM To: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mo= de-simple@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-simple Working Group, The authors of draft-akiya-mpls-lsp-ping-reply-mode-simple have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-akiya-mpls-lsp-ping-reply-mode-simple? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and each contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_D019302220576swallowciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Ross -

I am not aware of any IPR for the subject draft.

George

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Friday, August 15, 2014 8:11 = AM
To: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, "draft-akiya-mpls-lsp-ping-reply-mode-sim= ple@tools.ietf.org" <draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org><= br> Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] IPR poll for dr= aft-akiya-mpls-lsp-ping-reply-mode-simple

Hi Ross,

 

I am not aware of any IPRs that ap= ply to draft-akiya-mpls-lsp-ping-reply-mode-simple.

 

Thanks!

 

-Nobo

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, August 14, 2014 10:09 PM
To: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] IPR poll for draft-akiya-mpls-lsp-ping-reply-mode-si= mple

 

Working Group,

 

The authors of draft-akiya-mpls-lsp-ping-reply-mode-simple = have told the

working group chairs that the draft is ready to be adopted = as a working

group document.

 

Before starting the poll to see if we have consensus to mak= e this a

working group document we need to do an IPR poll.

 

This mail starts that IPR poll.

 

Are you aware of any IPR that applies to

draft-akiya-mpls-lsp-ping-reply-mode-simple?

 

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

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

 

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

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

IPR. The response needs to be sent to the MPLS wg mailing l= ist. The

documents will not advance to the next stage until a respon= se

has been received from each author and each contributor.

 

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

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

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

 

Thanks, Ross

(as MPLS WG co-chair)

 

 --_000_D019302220576swallowciscocom_-- From nobody Tue Aug 19 15:19:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809001A017E; Tue, 19 Aug 2014 15:19:03 -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] 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 uRSlhfUTM9MO; Tue, 19 Aug 2014 15:19:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E92061A06F4; Tue, 19 Aug 2014 15:19:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819221901.19667.28110.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 15:19:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FJKSmqkKpa_4GwAa6Q4GKV-m9qU Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-ttl-tlv-10.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 22:19:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definition of Time-to-Live TLV for LSP-Ping Mechanisms Authors : Sami Boutros Siva Sivabalan George Swallow Shaleen Saxena Vishwas Manral Sam Aldrin Filename : draft-ietf-mpls-lsp-ping-ttl-tlv-10.txt Pages : 8 Date : 2014-08-19 Abstract: LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) and/or bidirectional co-routed LSP from any node on the path of the MS-PW and/or bidirectional co-routed LSP. This document defines a TLV to address this shortcoming. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ttl-tlv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-ttl-tlv-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-ttl-tlv-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 19 19:07:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85DC1A701D for ; Tue, 19 Aug 2014 19:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 9SR675l2sCwf for ; Tue, 19 Aug 2014 19:07:23 -0700 (PDT) Received: from the-host.seacom.mu (ge-2.ln-01-mrs.fr.seacomnet.com [105.16.180.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A06A1A6FB4 for ; Tue, 19 Aug 2014 19:07:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1XJvIY-0001a3-GT; Wed, 20 Aug 2014 04:06:50 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Wed, 20 Aug 2014 04:06:45 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <53EA3666.2040004@pi.nu> <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2042522.52ln5XaSSr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201408200406.45290.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/okJBo7HnEfSvXEkHxs9Zit_BB8w Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 02:07:25 -0000 --nextPart2042522.52ln5XaSSr Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday, August 19, 2014 09:18:53 AM Aissaoui, Mustapha=20 (Mustapha) wrote: > The proposed solution is to have implementations > complying to this draft advertise the IPv6 prefix state > advertisement control capability > (draft-ietf-mpls-ldp-ip-pw-capability-07) in the > initialization message explicitly indicating support for > LDP IPv6. Without the peer advertising this capability, > an LSR must not send IPv6 addresses and FECs to that > peer. I would support such a capability check, because for me, I=20 have always held the view that the ability to signal LDPv6=20 control plane also means the ability to signal LDPv6 FEC's=20 and prefix information. It is risky to signal IPv6 FEC's across an LDPv4 session=20 just for its sake, and vice versa. And I'd support this both for broadcast and point-to-point=20 links. Meanwhile, very happy to hear that ALU have code for this=20 currently being tested. It's very encouraging to see. Mark. --nextPart2042522.52ln5XaSSr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJT9AK1AAoJEGcZuYTeKm+G2swP/iK5k2slTuevFHOjqKPT/5la Md0Akiu0MllgZQEP7Y4TMlas71NoOhonyfEmZNm6pMJkAlMRPXPpgt5X3zcDcrSg pVfxb5U+kjOMbpItKL6ovPqPZUL0CrlXhHwo6K8g8uo38nzL1PDapc1mGw7iwnyp 5KRiMNkW4dqyU2O/Xpmps27l5rozqSNKc+DFC1TXGC55QgtrKLjTFHI9+Ra8eS73 jQd8aWqA6WhVqqfjZTEOaij0QY6ZX+iz6jA8/70CFIwNypSE345N/+TJX0iwoPka OXxOLqGfeOLcjh/I19jhMpYkbg40igNr6AHKmQJFDTn2SAReNodIJk7hTIhO4se5 4kexZG0mENRW8lm/1CUMs4+CD2Owd11gpFhXuEceU7lw5fBYjwl60p2jCuDYvj80 0X9cfDMxXAWKPfkZfKxZK+B8A+107ZxIrk5fsVYlZ3uR/rBb1kReH4LKrd0HI5vD ClIbu7UTiPCpqKMZwXkw/jN+uyGZZxgDcZm88In1QzDM48E0wN0nsX3va5v7mxkn eDBAcJrvZDH2tN8c/mV27jwSUfQYg8E0dXqHvX7ISxK827yx+U4L2FYqULgwpv1S jl9uVvO6jk21yD9KxsFR6fyFsFuig4AJ2s5xUH+LBIgwr1pPY1FyVpCZexRJ5uTG eu7fc468g3aPpJzOn4Q6 =tS2U -----END PGP SIGNATURE----- --nextPart2042522.52ln5XaSSr-- From nobody Wed Aug 20 08:21:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FAB1A064D for ; Wed, 20 Aug 2014 08:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 uArvLz1dayUt for ; Wed, 20 Aug 2014 08:20:57 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118121A0503 for ; Wed, 20 Aug 2014 08:20:56 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Wed, 20 Aug 2014 15:20:54 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.1010.016; Wed, 20 Aug 2014 15:20:54 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+8ilRUv/hpET0IRlGIeWYgr95o5A== Date: Wed, 20 Aug 2014 15:20:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(164054003)(189002)(33646002)(87936001)(575784001)(79102001)(106356001)(20776003)(64706001)(2351001)(229853001)(85306004)(15202345003)(107046002)(74662001)(74502001)(31966008)(99396002)(80022001)(101416001)(74316001)(76482001)(19580405001)(83322001)(81342001)(86362001)(110136001)(50986999)(46102001)(2656002)(108616004)(76576001)(19580395003)(92566001)(77982001)(81542001)(66066001)(95666004)(4396001)(83072002)(230783001)(99286002)(54356999)(15975445006)(85852003)(21056001)(105586002)(2501001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_e4da58f21f34427686e7385f90354ec1CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RKThgk4LHV5KD3ox9KcGX72rskQ Cc: "'mpls-chairs@tools.ietf.org'" Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:20:59 -0000 --_000_e4da58f21f34427686e7385f90354ec1CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross --_000_e4da58f21f34427686e7385f90354ec1CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping= -reply-mode-simple-02
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working gr= oup
mailing list (mpls@ietf.org).
 
This poll will end Thursday September 4, 2014.
 
Thanks, Ross
 
 --_000_e4da58f21f34427686e7385f90354ec1CO2PR05MB636namprd05pro_-- From nobody Wed Aug 20 08:39:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AE11A0AD7; Wed, 20 Aug 2014 08:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.268 X-Spam-Level: ** X-Spam-Status: No, score=2.268 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J98uhEiTf81z; Wed, 20 Aug 2014 08:39:14 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D7A991A0AE5; Wed, 20 Aug 2014 08:38:54 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,903,1400040000"; d="scan'208,217";a="464403407" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 20 Aug 2014 11:38:35 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 20 Aug 2014 11:38:53 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "rtg-ads@tools.ietf.org" Date: Wed, 20 Aug 2014 11:38:57 -0400 Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D019124D2BF6Dwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3z_tEwEHeuceCUpmngEBolVjpzo Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:39:18 -0000 --_000_D019124D2BF6Dwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx2YXJvLCB0aGFuayB5b3UgZm9yIHRoZSB0aG9yb3VnaCByZXZpZXcuIFBsZWFzZSBmaW5kIG15 IHJlc3BvbnNlcyBiZWxvdyBpbmxpbmUgb24gYmVoYWxmIG9mIHRoZSBhdXRob3IgdGVhbS4gV2Ug aGF2ZSBhbiB1cGRhdGUgaW4gdGhlIGVkaXQgYnVmZmVyLCBhd2FpdGluZyBhIGZldyB1cGRhdGVz IHRvIHRoZSBFVlBOIHNlY3Rpb24gYW5kIHBvc3NpYmx5IHRoZSBMMlZQTiBzZWN0aW9uICh0byBp bmNvcnBvcmF0ZSBhbnkgbmVjZXNzYXJ5IGRpc2N1c3Npb24gb2YgUkZDIDcxMTcpLCBidXQgSSB3 YW50ZWQgdG8gZ28gYWhlYWQgYW5kIHJlc3BvbmQgbm93IHRoYXQgbW9zdCBvZiB0aGUgY29tbWVu dHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiBvdXIgZWRpdHMgYXQgbGVhc3QuDQoNClRoYW5rcywN Cg0KV2VzIEdlb3JnZQ0KDQpGcm9tOiAiQWx2YXJvIFJldGFuYSAoYXJldGFuYSkiIDxhcmV0YW5h QGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+Pg0KRGF0ZTogVHVlc2RheSwgQXVn dXN0IDUsIDIwMTQgYXQgMjo0NCBQTQ0KVG86ICJydGctYWRzQHRvb2xzLmlldGYub3JnPG1haWx0 bzpydGctYWRzQHRvb2xzLmlldGYub3JnPiIgPHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OnJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc+Pg0KQ2M6ICJydGctZGlyQGlldGYub3JnPG1haWx0bzpy dGctZGlyQGlldGYub3JnPiIgPHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5v cmc+PiwgImRyYWZ0LWlldGYtbXBscy1pcHY2LW9ubHktZ2FwLmFsbEB0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAuYWxsQHRvb2xzLmlldGYub3JnPiIg PGRyYWZ0LWlldGYtbXBscy1pcHY2LW9ubHktZ2FwLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86 ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAuYWxsQHRvb2xzLmlldGYub3JnPj4sICJtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiIgPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYt bXBscy1pcHY2LW9ubHktZ2FwLTAxDQoNCg0KQ29tbWVudHM6DQoNCkkgZG8gaGF2ZSBhIGNvdXBs ZSBvZiBoaWdoLWxldmVsIGl0ZW1zIEkgd2FudCB0byBicmluZyB1cC4gIEJlY2F1c2UgSSBhc3N1 bWUgdGhhdCB0aGVzZSBtYXkgaGF2ZSBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBhcHBy b3ByaWF0ZSBXRyhzKSBJJ20gbm90IGxpc3RpbmcgdGhlbSBhcyBtYWpvciBpc3N1ZXMsIGFuZCB3 aWxsIGRlZmVyIHRvIHdoYXQgdGhlIGNvbnNlbnN1cyBoYXMgYmVlbiBzbyBmYXIuDQoNCiAxLiAg V2h5IGRvIHdlIG5lZWQgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50PyAgQXMgSSBzYWlkIGFib3Zl LCBJIGJlbGlldmUgdGhlIHdvcmsgaXMgdmFsdWFibGUsIGJ1dCBpdCBjYXB0dXJlcyB0aGUgc3Rh dGUgaW4gdGltZSAodG9kYXkhKSBvZiB0aGUgZ2FwcyDigJQgaXQgcG9pbnRzIHRvIHdvcmsgdGhh dCBhbHJlYWR5IHNvbHZlZCBhIHBvdGVudGlhbCBnYXAsIG9yIGlzIGluIHRoZSBwcm9jZXNzIG9m IHNvbHZpbmcgdGhlbS4gIEEgc2lnbmlmaWNhbnQgcG9ydGlvbiBvZiB0aGUgZ2FwcyBhcmUgYWxy ZWFkeSBiZWluZyBhZGRyZXNzZWQuICBHaXZlbiB0aGUgaW1wb3J0YW5jZSBvZiBJUHY2LCBpZiBw dWJsaXNoZWQsIHNvb24gdGhpcyBkb2N1bWVudCB3aWxsIGhhdmUgdG8gYmUgdXBkYXRlZCB0byBz YXkgIm5vdGhpbmcgYnJlYWtzIi4gIEFnYWluLCB0aGUgd29yayBpcyBpbXBvcnRhbnQsIGJ1dCBp dCBtYXkgYmUgYmV0dGVyIHN1aXRlZCB0byBiZSBhICJsaXZpbmcgZG9jdW1lbnQiIGFzIGEgZ3Vp ZGUgZm9yIHdoYXQgc3RpbGwgbmVlZHMgdG8gYmUgYWRkcmVzc2VkLiAgSWYgaXQgaXMgdG8gYmUg cHVibGlzaGVkLCBJIHdvdWxkIHN1Z2dlc3QgYXZvaWRpbmcgbGlua3MgdG8gd29yayBpbiBwcm9n cmVzcywgYnV0IGxpbWl0aW5nIHRoZSBjb250ZW50IHRvIGlkZW50aWZ5aW5nIHRoZSBnYXBzLi5h bmQgdGhlbiBsZXR0aW5nIHRoZSBzb2x1dGlvbiBkcmFmdHMvUkZDcyBwb2ludCBiYWNrIHRvIHRo aXMgZG9jdW1lbnQuLiAgKGFsYSByZXF1aXJlbWVudHMgLT4gc29sdXRpb24pDQogMi4gIEl0IGlz IGludGVyZXN0aW5nIHRvIG1lIHRoYXQgdGhpcyBkcmFmdCBjYW1lIHRocm91Z2ggdGhlIG1wbHMg V0csIGFuZCBub3Qgb25lIG9mIHRoZSBvcGVyYXRpb25zLWZvY3VzZWQgZ3JvdXBzLi53aGljaCBw cmVzdW1hYmx5IHdvdWxkIGJlIGluIGEgYmV0dGVyIHBvc2l0aW9uIHRvIGV2YWx1YXRlIHRoZSBu ZWVkcyBkZXNjcmliZWQuICBHaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBpcyBhbHJlYWR5IGluIFdH IExhc3QgQ2FsbCwgSSdtIGFzc3VtaW5nIHRoYXQgdGhlIGFsaWdubWVudCBoYXMgYWxyZWFkeSBi ZWVuIGRpc2N1c3NlZCBhbmQgdGhhdCBwcm9wZXIgY3Jvc3MtV0cgcmV2aWV3cyBoYXZlIG9jY3Vy cmVkLg0KDQpXR10gQ3Jvc3MtV0cgcmV2aWV3cyBoYXZlbid0IG9jY3VycmVkLCBidXQgd2Ugdmll dyBNUExTJ3MgYWN0aXZlIHBhcnRpY2lwYW50cyBhcyBhIHN1cGVyc2V0IG9mIHRoZSBwYXJ0aWNp cGFudHMgb2YgbW9zdCBvZiB0aGUgTVBMUy1kZXBlbmRlbnQgV0dzLCBhbmQgYWxzbyBhIGdvb2Qg c291cmNlIG9mIGNyb3NzLVdHIGdlbmVyYWxpc3RzIGFuZCBleHBlcnRzIG9uIE1QTFMuIEl0J3Mg dW5jbGVhciB0byBtZSB3aGF0IG5lZWRzIHNob3VsZCBiZSBldmFsdWF0ZWQgYnkgdGhlIG9wZXJh dGlvbnMtZm9jdXNlZCBXR3MsIGdpdmVuIHRoYXQgdGhlIGlzc3VlIGNhbWUgZnJvbSBhIHByb2Js ZW0gdGhhdCBhbiBhY3R1YWwgb3BlcmF0b3IgZXhwZXJpZW5jZWQgKG5hbWVseSwgbWUpIGFuZCBJ IGRvbid0IHRoaW5rIHRoYXQgdGhlIG5lZWQgZm9yIE1QTFMgdG8gd29yayBvbiBhbiBJUHY2LW9u bHkgb3IgSVB2Ni1wcmltYXJ5IG5ldHdvcmsgaXMgcGFydGljdWxhcmx5IGNvbnRyb3ZlcnNpYWwg YW55d2F5LiBJZiBwZW9wbGUgYmVsaWV2ZSB0aGF0IHRoZXJlIGlzbid0IGVub3VnaCBvdmVybGFw LCB3ZSBjYW4gY2VydGFpbmx5IHNvbGljaXQgcmV2aWV3cyBmcm9tIHNvbWUgb2YgdGhlIG90aGVy IFdHcyBpbnZvbHZlZC4gQXdhaXRpbmcgQUQvV0cgY2hhaXIgZ3VpZGFuY2UuDQoNCldlJ3ZlIGRp c2N1c3NlZCB0aGlzIHF1ZXN0aW9uIGFib3V0IHdoZXRoZXIgdG8gcHVibGlzaCBhIGdhcCBhbmFs eXNpcyBhdCBhbGwgc29tZXdoYXQgb2ZmbGluZSwgYnV0IEknbSBpbmNsdWRpbmcgYSBmZXcgcG9p bnRzIGZvciB0aGUgcmVjb3JkIGFuZCBmb3IgV0cgY29tbWVudCBoZXJlLiBGaXJzdCwgbXkgZXhw ZWN0YXRpb24gaXMgdGhhdCB0aGUgZ2FwIGFuYWx5c2lzIHNob3VsZG4ndCBwcm9jZWVkIHRvIFJG QyB1bnRpbCBhIGNvbnNlbnN1cyBleGlzdHMgdGhhdCB3ZSBoYXZlIHJlYXNvbmFibHkgY2FwdHVy ZWQgYWxsIG9mIHRoZSBleGlzdGluZyBnYXBzLiBJbiBvdGhlciB3b3JkcywgdGhpcyBpcyBhIGRv Y3VtZW50YXRpb24gb2YgYWxsIG9mIHRoZSBnYXBzIHRoYXQgd2UgYXMgYSBjb2xsZWN0aXZlIGdy b3VwIG9mIHRoZSBTbWFydCBQZW9wbGUgV2hvIEtub3cgQWJvdXQgU3VjaCBUaGluZ3MgY291bGQg dGhpbmsgb2YsIGFuZCBleHBsaWNpdCBkb2N1bWVudGF0aW9uIG9mIGFyZWFzIHdpdGhvdXQgZ2Fw cyB0byBjb25maXJtIHRoYXQgd2UgcmV2aWV3ZWQgdGhlbSB0byB2YWxpZGF0ZSB0aGlzLiBOZXcg Z2FwcyBTSE9VTEQgTk9UIGRldmVsb3AsIGFzIG9uY2UgYSBnYXAgYW5hbHlzaXMgbGlrZSB0aGlz IGlzIHBlcmZvcm1lZCwgaXQgcmFpc2VzIGF3YXJlbmVzcyBzbyB0aGF0IHBlb3BsZSBpbiB0aGUg V0cgKGFuZCBBRHMpIHdpbGwgYXNrIG9mIGZ1dHVyZSB3b3JrLCAiZG9lcyB0aGlzIHdvcmsgb24g YW4gSVB2Ni1vbmx5IE1QTFMgbmV0d29yaywgZG9lcyBpdCBkZXBlbmQgb24ga25vd24gZ2FwcyBk b2N1bWVudGVkIGluIFJGQ25ubm4gYmVpbmcgYWRkcmVzc2VkLCBvciBhcmUgYWRkaXRpb25hbCBj aGFuZ2VzIG5lY2Vzc2FyeSB0byBtYWtlIHRoaXMgd29yayBwcm9wZXJseSBvbiBJUHY2LW9ubHk/ Ig0KU2Vjb25kLCBJIHRoaW5rIHRoaXMgZ2VuZXJhbGx5IGhpZ2hsaWdodHMgYSBwcm9ibGVtIElF VEYtd2lkZSB3aGVuIGl0IGNvbWVzIHRvIGdhcCBhbmFseXNlcy4gRWl0aGVyIHRoZSB3b3JrIGlz IGFscmVhZHkgaW4gcHJvZ3Jlc3MsIGFuZCBpdCBzZXJ2ZXMgYXMgYSBtZXRob2QgdG8gY2F0YWxv ZyB0aGUgaXNzdWVzIHRvIG1ha2Ugc3VyZSB3ZSBoYXZlIHRoZW0gYWxsIGJlaW5nIGFkZHJlc3Nl ZCwgb3IgaXQgc2VydmVzIHRvIGlkZW50aWZ5IHBsYWNlcyB3aGVyZSBmdXR1cmUgd29yayBpcyBu ZWVkZWQuIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIElFVEYgaGFzIG5vIG1ldGhvZCBkZWZpbmVk IHRvIGZvbGxvdyB1cCBvbiBnYXAgYW5hbHlzZXMgdG8gZW5zdXJlIHRoYXQgZnV0dXJlIHdvcmsg aWRlbnRpZmllZCBhY3R1YWxseSBnZXRzIGNvbXBsZXRlZCwgc2hvcnQgb2YgdGhlIFdHIGFkZGlu ZyBpdGVtcyB0byBpdHMgY2hhcnRlciB0byBleHBsaWNpdGx5IGFkZHJlc3MgdGhlc2UgdGhpbmdz LiBJZiB0aGUgZ2FwIGFuYWx5c2lzIHNwYW5zIFdHcywgb3IgdGhlcmUgaXNuJ3QgYW55b25lIGlu dGVyZXN0ZWQgaW4gYWRkcmVzc2luZyB0aGUgaWRlbnRpZmllZCBnYXAsIGl0IGNhbiBzb3J0IG9m IHJvdCBpbnNpZGUgdGhlIGFuYWx5c2lzIGFuZCBncmFkdWFsbHkgYmUgZm9yZ290dGVuLiBXZSdy ZSBkZWFsaW5nIHdpdGggdGhpcyBxdWVzdGlvbiBpbiBzdW5zZXQ0IG9uIHRoZSBvcmlnaW5hbCBz ZXQgb2YgSVB2NiBnYXAgYW5hbHlzZXMgdGhhdCB3ZXJlIGRvbmUgb24gUkZDcyAzNzkwLTk2LCBi ZWNhdXNlIG5vIG9uZSBoYXMgYSBnb29kIHNlbnNlIGZvciB3aGV0aGVyIGFsbCBvZiB0aGUgZ2Fw cyBpZGVudGlmaWVkIGluIHRob3NlIGRvY3VtZW50cyB3ZXJlIGFkZHJlc3NlZCwgb3IgYXJlIGlu ZGVlZCBzdGlsbCByZWxldmFudC4gVGhpcyBkcmFmdCBjYXRhbG9ncyBnYXBzIHdpdGggcG9pbnRl cnMgdG8gd2hlcmUgdGhlIGF1dGhvcnMga25vdyB0aGVyZSBpcyBhbHJlYWR5IHdvcmsgYmVpbmcg ZG9uZSwgd2hpY2ggc2VydmVzIHRvIGxpbmsgdGhlIHR3bywgYW5kIGVuc3VyZXMgdGhhdCBpdCdz IGFzIGNsZWFyIGFzIHBvc3NpYmxlIHdoZXJlIHRoZXJlIGFyZSBzdGlsbCBvdXRzdGFuZGluZyBn YXBzIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQsIGFuZCBpdCdkIGJlIHJlYXNvbmFibGUgdG8g ZXhwZWN0IGFueSBmb2xsb3ctb24gZG9jdW1lbnRzIHRoYXQgYWRkcmVzcyBnYXBzIGlkZW50aWZp ZWQgYXMgVEJEIGluIHRoaXMgZG9jdW1lbnQgdG8gZm9ybWFsbHkgdXBkYXRlIHRoaXMgZG9jdW1l bnQgc28gdGhhdCB0aGUgbGluayBpcyBwcmVzZW50IGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQg dGhlIGZ1dHVyZSBkb2N1bWVudHMgYWRkcmVzc2luZyBzb21lIG9mIHRoZSBnYXBzIHRoYXQgaXQg aWRlbnRpZmllZCBhcyBub3QgaGF2aW5nIGZpeGVzIGluIHByb2dyZXNzLiBJdCdzIHRoZSBiZXN0 IHdlIGNhbiBkbyB3aXRoICJmcm96ZW4gaW4gdGltZSIgZG9jdW1lbnRzIGxpa2UgdGhpcywgYnV0 IEkgdGhpbmsgaXQncyBhY2NlcHRhYmxlLg0KVWx0aW1hdGVseSwgSSB0aGluayB5b3VyIHF1ZXN0 aW9uIGlzIGEgbGFyZ2VyIGlzc3VlIGFuZCB0aGlzIGdhcCBhbmFseXNpcyBpcyBubyBkaWZmZXJl bnQgdGhhbiBhbnkgb3RoZXIg4oCTIHRoZSBxdWVzdGlvbiBvZiAic2hvdWxkIHdlIHB1Ymxpc2gi IGlzIHJlYWxseSAic2hvdWxkIHdlIHB1Ymxpc2ggYW55IGdhcCBhbmFseXNpcyBhcyBhbiBSRkMg Z2l2ZW4gdGhlIGxpbWl0YXRpb25zIG9mIHRoZSBzZXJpZXM/IiBhbmQgdGhhdCdzIG5vdCBzb21l dGhpbmcgd2UncmUgZ29pbmcgdG8gc29sdmUgaGVyZSwgc28gSSB0aGluayBpdCdzIGEgbWF0dGVy IG9mIHB1Ymxpc2hpbmcgdGhlIGRvY3VtZW50IGlmIHRoZSBjb250ZW50IGlzIGhlbHBmdWwuDQoN Cg0KTWlub3IgSXNzdWVzOg0KDQogKiAgIFNvbWUgdGVybWlub2xvZ3kgd2FzIG5vdCBleHBhbmRl ZCBiZWZvcmUvd2hlbiBpdCB3YXMgZmlyc3QgdXNlZDogd2UgYWxsIGtub3cgd2hhdCBNUExTIGlz LCBidXQgb3RoZXJzIGxpa2UgTFNSLCBMRVIsIEZFQywgTDJWUE4sIEVWUE4sIE5HLW1WUE4sIGV0 Yy4gc2hvdWxkIGJlIGV4cGFuZGVkLg0KDQpXR10gSSBiZWxpZXZlIHRoaXMgaXMgZml4ZWQgbm93 DQoNCiAqICAgU2VjdGlvbiAzLjEgKE1QTFMgRGF0YSBQbGFuZSk6ICJJbiB0aGUgY2FzZSB3aGVy ZSBhbiBJUHY0IHByZWZpeCBpcyByZXNvbHZlZCBvdmVyIGFuIElQdjYgTFNQLCBhbiBJUHY2IEV4 cGxpY2l0IE51bGwgbGFiZWwgY2Fubm90IGltbWVkaWF0ZWx5IHByZWNlZWQgYW4gSVB2NCBwYWNr ZXQuIiAgSXMgdGhlcmUgYSByZWZlcmVuY2UgZm9yIHRoaXMgc3RhdGVtZW50IG9yIGlzIHRoaXMg YSByZXF1aXJlbWVudCB0byBmaWxsIGluIHRoZSBnYXA/ICBJZiBpdCBpcyBhIHJlcXVpcmVtZW50 LCBkbyB3ZSBuZWVkIHRvIGFkZCAyMTE5IGxhbmd1YWdlPw0KDQotLUl0IHJlYWxseSBjb21lcyBm cm9tIFJGQyAzMDMyLCBhbmQgdGhlbiBSRkMgNDE4Mi4gT25lIGV4YW1wbGUgaXMgcHJlc2VudCBp biBSRkM0Nzk4DQoNCkhvd2V2ZXIsIGFmdGVyIHJldmlldywgd2UndmUgcmVtb3ZlZCB0aGlzIHRl eHQsIGJlY2F1c2Ugd2UgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIGFjdHVhbGx5IGEgZ2FwLCBh bmQgdGhlIHRleHQgd2FzIGNvbmZ1c2luZyAoZXZlbiB0byB5b3VyIGh1bWJsZSBlZGl0b3IpLg0K DQogKiAgIFdoZW4gYSBnYXAgZXhpc3RzLCB5b3UgY2xhc3NpZnkgaXQgYXMgIm1ham9yIiBvciAi bWlub3IiLiAgV2hhdCBpcyB0aGUgY3JpdGVyaWEgdXNlZD8gIEkgd291bGQgaW1hZ2luZSB0aGF0 IGdpdmVuIHRoYXQgaXQgaXMgYSBnYXAgYW5hbHlzaXMsIHRoZSBvYmplY3RpdmUgaXMgdG8gcG9p bnQgb3V0IHRoZSBuZWVkcywgbm90IGNoYXJhY3Rlcml6ZSB0aGVtIChpZiBJIG5lZWQgYSAibWlu b3IiIGdhcCB0byBiZSBmaWxsZWQgaW4gb3JkZXIgZm9yIG15IG5ldHdvcmsgZGVwbG95bWVudCB0 byBvcGVyYXRlLCBpdCBiZWNvbWVzICJtYWpvciIgdG8gbWUpLg0KDQpXR10gQWRkZWQgdGV4dCB0 byB0aGUgYmVnaW5uaW5nIG9mIHNlY3Rpb24gMyBleHBsYWluaW5nIHRoZSB0ZXJtczoNCg0KIkEg bm90ZSBhYm91dCB0ZXJtaW5vbG9neTogR2FwcyBhcmUgdHlwaWNhbGx5IGNoYXJhY3Rlcml6ZWQg YXMgIk1ham9yIiwgIk1pbm9yIiBvciAibm9uZSIuIE1ham9yIGdhcHMgcmVmZXIgdG8gc2lnbmlm aWNhbnQgY2hhbmdlcyBuZWNlc3NhcnkgaW4gb25lIG9yIG1vcmUgc3RhbmRhcmRzIHRvIGFkZHJl c3MgdGhlIGdhcCBkdWUgdG8gZXhpc3Rpbmcgc3RhbmRhcmRzIGxhbmd1YWdlIGhhdmluZyBlaXRo ZXIgbWlzc2luZyBmdW5jdGlvbmFsaXR5IGZvciBJUHY2LW9ubHkgb3BlcmF0aW9uIG9yIGV4cGxp Y2l0IGxhbmd1Z2UgcmVxdWlyaW5nIHRoZSB1c2Ugb2YgSVB2NCB3aXRoIG5vIElQdjYgYWx0ZXJu YXRpdmVzIGRlZmluZWQuIE1pbm9yIGdhcHMgcmVmZXIgdG8gY2hhbmdlcyBuZWNlc3NhcnkgcHJp bWFyaWx5IHRvIGNsYXJpZnkgZXhpc3Rpbmcgc3RhbmRhcmRzIGxhbmd1YWdlLiBVc3VhbGx5IHRo ZXNlIGNoYW5nZXMgYXJlIG5lZWRlZCBpbiBvcmRlciB0byBleHBsaWNpdGx5IGNvZGlmeSBJUHY2 IHN1cHBvcnQgaW4gcGxhY2VzIHdoZXJlIGl0IGlzIGVpdGhlciBpbXBsaWNpdCBvciBvbWl0dGVk IHRvZGF5LCBidXQgdGhlIG9taXNzaW9uIGlzIHVubGlrZWx5IHRvIHByZXZlbnQgSVB2Ni1vbmx5 IG9wZXJhdGlvbi4iDQoNCg0KICogICBUaGUgaW50cm9kdWN0aW9uIHRvIHRoZSBkcmFmdCB0YWxr cyBhYm91dCAiZ2FwcyB0aGF0IG11c3QgYmUgYWRkcmVzc2VkIGluIG9yZGVyIHRvIGFsbG93IE1Q TFMtcmVsYXRlZCBwcm90b2NvbHMgYW5kIGFwcGxpY2F0aW9ucyB0byBiZSB1c2VkIHdpdGggSVB2 Ni1vbmx5IG5ldHdvcmtzIiAoIklQdjYtb25seSAobm8gSVB2NCBwcm92aXNpb25lZCBvbiB0aGUg ZGV2aWNlKSIpLCB3aGljaCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IG5vIElQdjQgaXMgcHJl c2VudCBpbiB0aGUgbmV0d29yayBhdCBhbGwuICAgSG93ZXZlciwgc2V2ZXJhbCBnYXBzIGFyZSBp ZGVudGlmaWVkIHRoYXQgb2NjdXIgaW4gIm1peGVkIiBuZXR3b3Jrcywgd2hlcmUgaXNsYW5kcyBv ZiBJUHY0L0lQdjYgZXhpc3QuICBJIHdvdWxkIHN1Z2dlc3QgY2xhcmlmeWluZyB0aGUgc2NvcGUg b2YgdGhlIGRvY3VtZW50IGluIHRoZSBpbnRyb2R1Y3Rpb24uICBTb21lIG9mIHRoZSBwbGFjZXMg d2hlcmUgdGhlc2Ugc2NlbmFyaW9zIGFyZSBkaXNjdXNzZWQgaW5jbHVkZTogIDMuMi4yLiAoTXVs dGlwb2ludCBMRFApLCAzLjMuMi4gKEwzVlBOKSwgIDMuNC4xLiAoRXh0ZW5kZWQgSUNNUCkgYW5k IDMuNC4yLiAoTFNQIFBpbmcpLg0KDQpXR10gYSBmZXcgc2VudGVuY2VzIGJlZm9yZSwgdGhlIGRv Y3VtZW50IHNheXMgImFueSBuZXR3b3JrcyB3aWxsIG5lZWQgdG8gc3RhcnQgb3BlcmF0aW5nIHNv bWUgb3IgYWxsIG9mIHRoZWlyIG5ldHdvcmsgbm9kZXMgZWl0aGVyIGFzIHByaW1hcmlseSBJUHY2 IChtb3N0IGZ1bmN0aW9ucyB1c2UgSVB2NiwgYSBmZXcgbGVnYWN5IGZlYXR1cmVzIHVzZSBJUHY0 KSwgb3IgYXMgSVB2Ni1vbmx5IChubyBJUHY0IHByb3Zpc2lvbmVkIG9uIHRoZSBkZXZpY2UpIiBE byB3ZSBzaW1wbHkgbmVlZCB0byBhZGQgc2ltaWxhciBsYW5ndWFnZSB0byB0aGUgbmV4dC10by1s YXN0IHNlbnRlbmNlLCBkb2VzIHRoZSBleGlzdGluZyB0ZXh0IG1ha2UgaXQgY2xlYXIgbm93IHRo YXQgSSd2ZSBoaWdobGlnaHRlZCBpdCwgb3IgaXMgbW9yZSByZXF1aXJlZD8NCg0KDQogKiAgIDMu My4xLjEuIChFVlBOKSAgSWYgdGhlIEVWUE4gd29yayBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRo ZSBkb2N1bWVudCwgdGhlbiB0YWtlIGl0IG91dC4gIEFub3RoZXIgb3B0aW9uIG1heSBiZSB0byB0 YWxrIGFib3V0IGFueSBnYXBzIGluIHRoZSBjdXJyZW50IHdvcmsuICBTYW1lIGNvbW1lbnQgZm9y IHNlY3Rpb24gMy4zLjIuNC4zLiAoUEUtUEUgTXVsdGljYXN0IFJvdXRpbmcgUHJvdG9jb2wpLg0K DQpXR10gRVZQTiBkcmFmdCBpcyBwZW5kaW5nIElFU0cvSUVURiBMQywgc28gaXQncyBub3Qgc28g bXVjaCBvZiBhIHdvcmsgaW4gcHJvZ3Jlc3MgYW55bW9yZSwgYW5kIHdpbGwgbGlrZWx5IGhpdCBw dWJsaWNhdGlvbiBwcmlvciB0byB0aGlzIGRvY3VtZW50LiBJIGhhdmUgZW1haWxlZCBFVlBOIGF1 dGhvcnMgdG8gcmVxdWVzdCB0aGF0IHRoZXkgY29uc2lkZXIgRVZQTiBpbiB0aGUgSVB2Ni1vbmx5 IG9wZXJhdGlvbiBjb250ZXh0IG9mIHRoaXMgZHJhZnQsIGFuZCBlaXRoZXIgY29uZmlybSB0aGF0 IHRoZXJlIGFyZSBubyBnYXBzLCB0aGF0IHRoZXJlIGFyZSBkZXBlbmRlbmNpZXMgb24gZ2FwcyBh bHJlYWR5IGlkZW50aWZpZWQsIG9yIHJlc29sdmUgYW55IGdhcHMgcHJlc2VudCB0aGF0IGFyZSB1 bmlxdWUgdG8gRVZQTiBwcmlvciB0byBMQy4gVGhlIHNlY3Rpb24gd2lsbCBiZSB1cGRhdGVkIGFj Y29yZGluZ2x5IHRvIHJlbW92ZSB0aGUgY29tbWVudHMgYWJvdXQgaXQgYmVpbmcgb3V0IG9mIHNj b3BlIGFuZCBhZGQgYSBicmllZiBnYXAgYW5hbHlzaXMgYmFzZWQgb24gdGhlIHJlc3VsdHMgb2Yg dGhhdCBkaXNjdXNzaW9uLg0KDQoNCiAqICAgMy4zLjIuIChMM1ZQTikgIHRoZSB0ZXh0IHNheXMg dGhhdCB0aGUgZ2FwcyBpbiBSRkM0MzY0IChubyBWUE4tSVB2NiBhZGRyZXNzIGFuZCBhIDEyOCBi aXQgbmV4dC1ob3ApIGhhdmUgYmVlbiBhZGRyZXNzZWQgaW4gUkZDIDQ2NTksIGJ1dCBpdCB0aGVu IGlkZW50aWZpZXMgdGhlIGdhcCBhbmQgc2F5cyB0aGF0ICJSRkM0MzY0IG11c3QgYmUgdXBkYXRl ZCIuICBXaGF0IHdvdWxkIHRoYXQgdXBkYXRlIGJlPw0KDQpXR10gWW91J3JlIHJpZ2h0LCB0aGlz IHdhcyByZWFsbHkgY29uZnVzaW5nIGFzIHdyaXR0ZW4uIE1hZGUgc2lnbmlmaWNhbnQgY2hhbmdl cyB0byB0aGlzIHNlY3Rpb24uIFRoZXJlIGFyZSBubyBnYXBzIGluIDQzNjQuIFRoZSByZWFsIHBy b2JsZW0gaXMgdGhhdCA0NjU5IHVwZGF0ZXMgNDM2NCBhbmQgZml4ZXMgdGhvc2UgZ2FwcywgYnV0 IGl0IGRvZXNuJ3QgZm9ybWFsbHkgdXBkYXRlIDQzNjQgaW4gdGhlIG1ldGFkYXRhLCBzbyBpdCBs b29rcyBsaWtlIHRoZXJlIGFyZSBnYXBzIGV4dGFudCBpbiA0MzY0LiBJdCBhbHNvIGV4cGxpY2l0 bHkgY2FsbHMgdXNlIGNhc2UgIzIgb3V0IG9mIHNjb3BlLg0KDQpJIGZpbGVkIGFuIGVycmF0dW0g dG8gZml4IDQ2NTkncyBtZXRhZGF0YTogaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFf c2VhcmNoLnBocD9yZmM9NDY1OSZlaWQ9NDA4Nw0KDQoNCiAqICAgU2VjdGlvbnMgMy4zLjIuNC4z LiAoUEUtUEUgTXVsdGljYXN0IFJvdXRpbmcgUHJvdG9jb2wpLCAzLjMuMy4gKE1QTFMtVFApIGFu ZCAzLjQuNS4gKE1QTFMtVFAgT0FNKSBhcmUgaW5jbHVkZWQsIGJ1dCBvdXQgb2Ygc2NvcGUuLiAg U2hvdWxkIHRoZXkgYmUgcmVtb3ZlZD8gIElmIG5vdCwgdGhlbiBhIHNob3J0IGp1c3RpZmljYXRp b24gaW4gdGhlIHRleHQgd291bGQgYmUgbmljZS4NCg0KV0ddIGNsYXJpZmllZA0KDQoNCiAqICAg My40LiAoTVBMUyBPQU0pICBUaGlzIHNlbnRlbmNlICJBbGwgb2YgdGhlc2UgbWVjaGFuaXNtcyB3 b3JrIGluIHB1cmUgSVB2NiBlbnZpcm9ubWVudHMuIiBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0 IGFsbCB0aGUgbWVjaGFuaXNtcyB3b3JrIGNvcnJlY3RseSBhbmQgdGhhdCB0aGVyZSBhcmUgbm8g Z2Fwcy4uYnV0IHRoZW4gc2V2ZXJhbCBnYXBzIGFyZSBsaXN0ZWQuDQoNCldHXSBNYWRlIHNvbWUg d29yZGluZyBjaGFuZ2VzIGluIDMuNCBhbmQgTFNQIHBpbmcgc2VjdGlvbiAzLjQuMiBmb3IgY2xh cml0eS4NCg0KDQogKiAgIFRhYmxlIDE6IElQdjYtb25seSBNUExTIEdhcHMuICBUaGUgdGFibGUg ZG9lc24ndCBpbmNsdWRlIGFsbCB0aGUgZ2FwcyBpZGVudGlmaWVkLiAgRm9yIGV4YW1wbGUsIDMu Mi4yLiAoTXVsdGlwb2ludCBMRFApIGlzIG5vdCBpbmNsdWRlZCBpbiB0aGUgdGFibGUsIGV2ZW4g dGhvdWdoIGEgbWFqb3IgZ2FwIHdhcyBpZGVudGlmaWVkLiAgSW4gdGhpcyBjYXNlLCB0aGUgd29y ayBpbiB0aGUgdGFibGUgZm9yIExEUCBtYXkgYWxzbyBhZGRyZXNzIHRoZSBnYXAgaW4gbUxEUCwg YnV0IHRoYXQgaXMgbm90IHBvaW50ZWQgb3V0IGluIHRoZSB0YWJsZS4uICBJbiBzaG9ydCwgdGhl IHRhYmxlIGlzIG5vdCBjb21wbGV0ZS4NCg0KV0ddIEZpeGVkDQoNCg0KICogICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucy4gIFRoaXMgc2VjdGlvbiB0YWxrcyBhYm91dCBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBpbiBjdXJyZW50IHNwZWNpZmljYXRpb25zLi5idXQgaXQgbGVhdmVzIG91dCBtZW50 aW9uIG9mIHRoZSBmYWN0IHRoYXQgbmV3IHNwZWNpZmljYXRpb25zICh0byBjbG9zZSB0aGUgZ2Fw cykgc2hvdWxkIChNVVNUID8pIGNvbnNpZGVyIHRoZSBlZmZlY3Qgb2YgSVB2Ni4NCg0KV0ddIEZp eGVkDQoNCg0KTml0czoNCg0KR2xvYmFsIEFDSy4gQ291cGxlIG9mIHNwZWNpZmljIGNvbW1lbnRz Og0KDQogKiAgIFNlY3Rpb24gMyAoR2FwIEFuYWx5c2lzKS4gIFlvdSB3cm90ZTogIlRoaXMgZ2Fw IGFuYWx5c2lzIGFpbXMgdG8gYW5zd2VyIHRoZSBxdWVzdGlvbiwgIndoYXQgYnJlYWtzIHdoZW4g b25lIGF0dGVtcHRzIHRvIHVzZSBNUExTIGZlYXR1cmVzIG9uIGEgbmV0d29yayBvZiBJUHY2LW9u bHkgZGV2aWNlcz8iICBXaGlsZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3UncmUgYXNraW5nLCBpbiBy ZWFsaXR5IHlvdSdyZSB0cnlpbmcgdG8gYW5zd2VyICJ3aGF0IGRvZXNuJ3Qgd29yay4uIi4gIEJy ZWFraW5nIGltcGxpZXMgdGhhdCBpdCBtYXkgd29yayBmb3IgYSB3aGlsZSBhbmQgdGhlbiBzdG9w IGRvaW5nIHNvLg0KDQpXR10gY2hhbmdlZCB0byBmYWlscw0KDQoNCiAqICAgMy4zLjIuIChMM1ZQ TikgICBUaGUgZ2FwIHNlY3Rpb24gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyB0ZXh0OiAiRGlzY3Vz c2VkIGluIGZ1cnRoZXIgZGV0YWlsIGJlbG93Ii4gIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBh biBhY3R1YWwgcmVmZXJlbmNlIHRvIHRoZSBzZWN0aW9uIGluc3RlYWQgb2YgdGhlIHRleHQuDQoN CldHXSBJdCdzIGluIHRoZSBuZXh0IHBhcmFncmFwaCwgaXMgZnVydGhlciBndWlkYW5jZSByZWFs bHkgbmVjZXNzYXJ5Pw0KDQogKiAgIEV2ZW4gdGhvdWdoIHNlY3Rpb25zIDMuMy4yLjEgYW5kIDMu My4yLjIgYXJlIHN1YnNlY3Rpb25zIG9mIDMuMy4yLCB3aXRoIHNvIG1hbnkgc2NlbmFyaW9zIGJl aW5nIGNvdmVyZWQsIGl0IGdldHMgaGFyZCB0byBrZWVwIHRyYWNrIG9mIHdoZXJlIHNvbWV0aGlu ZyB3YXMgZGVzY3JpYmVkLiAgSXQgd291bGQgYmUgdmVyeSBuaWNlIHRvIGluY2x1ZGUgcmVmZXJl bmNlcyB0byB3aGVyZSAidXNlIGNhc2UgIzIiIHdhcyBkZWZpbmVkIGluIHNhYyBvZiB0aG9zZSBz dWJzZWN0aW9ucy4NCg0KV0ddIHdoaWxlIHRoZXNlIHJlZmVyZW5jZXMgY291bGQgYmUgYWRkZWQs IGl0IGNvdmVycyBsZXNzIHRoYW4gYSBwYWdlIG9mIHRleHQgd2l0aGluIG9uZSBzdWJzZWN0aW9u LiBJJ20gbm90IGNvbnZpbmNlZCB0aGlzIGlzIGFuIGFjdHVhbCBwcm9ibGVtDQoNCg0KICogICAz LjMuMi40LjIuIChQLVR1bm5lbCBJbnN0YW50aWF0aW9uKQ0KICAgICogICAiLiAuIC5jb3ZlcmVk IGluIHByZXZpb3VzIHNlY3Rpb25zIi4gIFJlZmVyZW5jZXMgcGxlYXNlLg0KDQpXR10gYWNrDQoN CiAgICAqICAgIlBJTSBUcmVlIGFuZCBJbmdyZXNzIFJlcGxpY2F0aW9uIGFyZSBvdXQgb2YgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuLiIgYmVjYXVzZS4uICBFaXRoZXIgZXhwbGFpbiB3aHkg b3IgcmVtb3ZlIHRoZW0gZnJvbSB0aGUgbGlzdCByaWdodCBiZWZvcmUuDQoNCldHXSBmaXhlZCwg ZGlzY3Vzc2lvbiBhZGRlZA0KDQoNCiAqICAgMy40LjIuIChMU1AgUGluZykgIHMvTFNQIFBpbmcg cGFja2V0cyBhcmUgVURQIHBhY2tldHMgb3ZlciBib3RoIElQdjQgYW5kIElQdjYvTFNQIFBpbmcg cGFja2V0cyBhcmUgVURQIHBhY2tldHMgb3ZlciBlaXRoZXIgSVB2NCBvciBJUHY2DQoNCldHXSBh Y2sNCg0KICogICBUaGVyZSBpcyBzb21lIHVuZXZlbiB0cmVhdG1lbnQgaW4gdGhlIGRlc2NyaXB0 aW9uIG9mIHRoZSBzdXBwb3J0L2dhcHMuICBJdCB3b3VsZCBiZSBuaWNlIHRvIHByb3ZpZGUgdGhl IHNhbWUgbGV2ZWwgb2YgZGV0YWlsIGV2ZXJ5d2hlcmUgKGlmIG5lZWRlZCkuICBGb3IgZXhhbXBs ZSwgMy4yLjMuMiAoUlNWUC1URS1QMk1QKSBwbGFpbmx5IG1lbnRpb25zIHRoYXQgUkZDNDg3NSBj b3ZlcnMgdGhlIHN1cHBvcnQgZm9yIElQdjYuLndoaWxlIDMuNC4zIChCRkQgT0FNKSBtZW50aW9u cyB3aGVyZSBJUHY2IHN1cHBvcnQgdXMgZGVmaW5lZCBidXQgaXQgYWxzbyBwb2ludHMgdG8gdGhl IHNwZWNpZmljIHNlY3Rpb25zLiAgSU1ITywgdGhlIGFkZGl0aW9uYWwgZGV0YWlsIGlzIG5vdCBu ZWVkZWQgKHVubGVzcyB2ZXJ5IHNwZWNpZmljIHBvaW50cyBuZWVkIHRvIGJlIG1hZGUpLg0KDQpX R10gYXV0aG9ycyBiZWxpZXZlIHRoYXQgdGhlIGRldGFpbCBpcyBwcm9iYWJseSBub3QgYWJzb2x1 dGVseSBuZWNlc3NhcnksIGJ1dCBkbyBzZWUgaXQgYXMgdXNlZnVsIGFuZCB0aGVyZWZvcmUgbm8g cmVhc29uIHRvIHJlbW92ZSBpdC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUg V2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2Vk LCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1l IFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBh cmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwg Y29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBh bmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQg bWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBk ZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHBy aW50b3V0Lg0K --_000_D019124D2BF6Dwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkFsdmFybywgdGhhbmsgeW91IGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LiBQbGVhc2UgZmlu ZCBteSByZXNwb25zZXMgYmVsb3cgaW5saW5lIG9uIGJlaGFsZiBvZiB0aGUgYXV0aG9yIHRlYW0u IFdlIGhhdmUgYW4gdXBkYXRlIGluIHRoZSBlZGl0IGJ1ZmZlciwgYXdhaXRpbmcgYSBmZXcgdXBk YXRlcyB0byB0aGUgRVZQTiBzZWN0aW9uIGFuZCBwb3NzaWJseSB0aGUgTDJWUE4gc2VjdGlvbiAo dG8gaW5jb3Jwb3JhdGUgYW55IG5lY2Vzc2FyeQ0KIGRpc2N1c3Npb24gb2YgUkZDIDcxMTcpLCBi dXQgSSB3YW50ZWQgdG8gZ28gYWhlYWQgYW5kIHJlc3BvbmQgbm93IHRoYXQgbW9zdCBvZiB0aGUg Y29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiBvdXIgZWRpdHMgYXQgbGVhc3QuJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyI+V2VzIEdlb3JnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9u dC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw aW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDog M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7 QWx2YXJvIFJldGFuYSAoYXJldGFuYSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphcmV0YW5h QGNpc2NvLmNvbSI+YXJldGFuYUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgQXVndXN0IDUsIDIwMTQgYXQg Mjo0NCBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZx dW90OzxhIGhyZWY9Im1haWx0bzpydGctYWRzQHRvb2xzLmlldGYub3JnIj5ydGctYWRzQHRvb2xz LmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1hZHNAdG9vbHMuaWV0 Zi5vcmciPnJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpydGctZGly QGlldGYub3JnIj5ydGctZGlyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJ0Zy1kaXJAaWV0Zi5vcmciPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy1pcHY2LW9ubHktZ2FwLmFsbEB0b29scy5pZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAuYWxsQHRvb2xzLmlldGYub3JnPC9hPiZx dW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAu YWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLW1wbHMtaXB2Ni1vbmx5LWdhcC5hbGxAdG9v bHMuaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmci Pm1wbHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9y ZyI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5bbXBsc10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tcGxz LWlwdjYtb25seS1nYXAtMDE8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 ICI+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzdHJvbmc+Q29tbWVudHM6PC9zdHJv bmc+PC9wPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCkkgZG8gaGF2ZSBhIGNvdXBs ZSBvZiBoaWdoLWxldmVsIGl0ZW1zIEkgd2FudCB0byBicmluZyB1cC4gJm5ic3A7QmVjYXVzZSBJ IGFzc3VtZSB0aGF0IHRoZXNlIG1heSBoYXZlIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQgaW4gdGhl IGFwcHJvcHJpYXRlIFdHKHMpIEknbSBub3QgbGlzdGluZyB0aGVtIGFzIG1ham9yIGlzc3Vlcywg YW5kIHdpbGwgZGVmZXIgdG8gd2hhdCB0aGUgY29uc2Vuc3VzIGhhcyBiZWVuIHNvIGZhci48L2Rp dj4NCjxvbCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxsaT5XaHkgZG8gd2UgbmVlZCB0byBw dWJsaXNoIHRoaXMgZG9jdW1lbnQ/ICZuYnNwO0FzIEkgc2FpZCBhYm92ZSwgSSBiZWxpZXZlIHRo ZSB3b3JrIGlzIHZhbHVhYmxlLCBidXQgaXQgY2FwdHVyZXMgdGhlIHN0YXRlIGluIHRpbWUgKHRv ZGF5ISkgb2YgdGhlIGdhcHMg4oCUIGl0IHBvaW50cyB0byB3b3JrIHRoYXQgYWxyZWFkeSBzb2x2 ZWQgYSBwb3RlbnRpYWwgZ2FwLCBvciBpcyBpbiB0aGUgcHJvY2VzcyBvZiBzb2x2aW5nIHRoZW0u ICZuYnNwO0Egc2lnbmlmaWNhbnQNCiBwb3J0aW9uIG9mIHRoZSBnYXBzIGFyZSBhbHJlYWR5IGJl aW5nIGFkZHJlc3NlZC4gJm5ic3A7R2l2ZW4gdGhlIGltcG9ydGFuY2Ugb2YgSVB2NiwgaWYgcHVi bGlzaGVkLCBzb29uIHRoaXMgZG9jdW1lbnQgd2lsbCBoYXZlIHRvIGJlIHVwZGF0ZWQgdG8gc2F5 ICZxdW90O25vdGhpbmcgYnJlYWtzJnF1b3Q7LiAmbmJzcDtBZ2FpbiwgdGhlIHdvcmsgaXMgaW1w b3J0YW50LCBidXQgaXQgbWF5IGJlIGJldHRlciBzdWl0ZWQgdG8gYmUgYSAmcXVvdDtsaXZpbmcg ZG9jdW1lbnQmcXVvdDsgYXMgYSBndWlkZQ0KIGZvciB3aGF0IHN0aWxsIG5lZWRzIHRvIGJlIGFk ZHJlc3NlZC4gJm5ic3A7SWYgaXQgaXMgdG8gYmUgcHVibGlzaGVkLCBJIHdvdWxkIHN1Z2dlc3Qg YXZvaWRpbmcgbGlua3MgdG8gd29yayBpbiBwcm9ncmVzcywgYnV0IGxpbWl0aW5nIHRoZSBjb250 ZW50IHRvIGlkZW50aWZ5aW5nIHRoZSBnYXBzLi5hbmQgdGhlbiBsZXR0aW5nIHRoZSBzb2x1dGlv biBkcmFmdHMvUkZDcyBwb2ludCBiYWNrIHRvIHRoaXMgZG9jdW1lbnQuLiAmbmJzcDsoYWxhIHJl cXVpcmVtZW50cw0KIC0mZ3Q7IHNvbHV0aW9uKTwvbGk+PGxpPkl0IGlzIGludGVyZXN0aW5nIHRv IG1lIHRoYXQgdGhpcyBkcmFmdCBjYW1lIHRocm91Z2ggdGhlIG1wbHMgV0csIGFuZCBub3Qgb25l IG9mIHRoZSBvcGVyYXRpb25zLWZvY3VzZWQgZ3JvdXBzLi53aGljaCBwcmVzdW1hYmx5IHdvdWxk IGJlIGluIGEgYmV0dGVyIHBvc2l0aW9uIHRvIGV2YWx1YXRlIHRoZSBuZWVkcyBkZXNjcmliZWQu ICZuYnNwO0dpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGlzIGFscmVhZHkgaW4gV0cgTGFzdCBDYWxs LCBJJ20gYXNzdW1pbmcNCiB0aGF0IHRoZSBhbGlnbm1lbnQgaGFzIGFscmVhZHkgYmVlbiBkaXNj dXNzZWQgYW5kIHRoYXQgcHJvcGVyIGNyb3NzLVdHIHJldmlld3MgaGF2ZSBvY2N1cnJlZC48L2xp Pjwvb2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10gQ3Jvc3MtV0cgcmV2aWV3 cyBoYXZlbid0IG9jY3VycmVkLCBidXQgd2UgdmlldyBNUExTJ3MgYWN0aXZlIHBhcnRpY2lwYW50 cyBhcyBhIHN1cGVyc2V0IG9mIHRoZSBwYXJ0aWNpcGFudHMgb2YgbW9zdCBvZiB0aGUgTVBMUy1k ZXBlbmRlbnQgV0dzLCBhbmQgYWxzbyBhIGdvb2Qgc291cmNlIG9mIGNyb3NzLVdHIGdlbmVyYWxp c3RzIGFuZCBleHBlcnRzIG9uIE1QTFMuIEl0J3MgdW5jbGVhciB0byBtZSB3aGF0IG5lZWRzIHNo b3VsZA0KIGJlIGV2YWx1YXRlZCBieSB0aGUgb3BlcmF0aW9ucy1mb2N1c2VkIFdHcywgZ2l2ZW4g dGhhdCB0aGUgaXNzdWUgY2FtZSBmcm9tIGEgcHJvYmxlbSB0aGF0IGFuIGFjdHVhbCBvcGVyYXRv ciBleHBlcmllbmNlZCAobmFtZWx5LCBtZSkgYW5kIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgbmVl ZCBmb3IgTVBMUyB0byB3b3JrIG9uIGFuIElQdjYtb25seSBvciBJUHY2LXByaW1hcnkgbmV0d29y ayBpcyBwYXJ0aWN1bGFybHkgY29udHJvdmVyc2lhbCBhbnl3YXkuDQogSWYgcGVvcGxlIGJlbGll dmUgdGhhdCB0aGVyZSBpc24ndCBlbm91Z2ggb3ZlcmxhcCwgd2UgY2FuIGNlcnRhaW5seSBzb2xp Y2l0IHJldmlld3MgZnJvbSBzb21lIG9mIHRoZSBvdGhlciBXR3MgaW52b2x2ZWQuIEF3YWl0aW5n IEFEL1dHIGNoYWlyIGd1aWRhbmNlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2Un dmUgZGlzY3Vzc2VkIHRoaXMgcXVlc3Rpb24gYWJvdXQgd2hldGhlciB0byBwdWJsaXNoIGEgZ2Fw IGFuYWx5c2lzIGF0IGFsbCBzb21ld2hhdCBvZmZsaW5lLCBidXQgSSdtIGluY2x1ZGluZyBhIGZl dyBwb2ludHMgZm9yIHRoZSByZWNvcmQgYW5kIGZvciBXRyBjb21tZW50IGhlcmUuIEZpcnN0LCBt eSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZSBnYXAgYW5hbHlzaXMgc2hvdWxkbid0IHByb2NlZWQg dG8gUkZDIHVudGlsIGEgY29uc2Vuc3VzDQogZXhpc3RzIHRoYXQgd2UgaGF2ZSByZWFzb25hYmx5 IGNhcHR1cmVkIGFsbCBvZiB0aGUgZXhpc3RpbmcgZ2Fwcy4gSW4gb3RoZXIgd29yZHMsIHRoaXMg aXMgYSBkb2N1bWVudGF0aW9uIG9mIGFsbCBvZiB0aGUgZ2FwcyB0aGF0IHdlIGFzIGEgY29sbGVj dGl2ZSBncm91cCBvZiB0aGUgU21hcnQgUGVvcGxlIFdobyBLbm93IEFib3V0IFN1Y2ggVGhpbmdz IGNvdWxkIHRoaW5rIG9mLCBhbmQgZXhwbGljaXQgZG9jdW1lbnRhdGlvbiBvZiBhcmVhcyB3aXRo b3V0DQogZ2FwcyB0byBjb25maXJtIHRoYXQgd2UgcmV2aWV3ZWQgdGhlbSB0byB2YWxpZGF0ZSB0 aGlzLiBOZXcgZ2FwcyBTSE9VTEQgTk9UIGRldmVsb3AsIGFzIG9uY2UgYSBnYXAgYW5hbHlzaXMg bGlrZSB0aGlzIGlzIHBlcmZvcm1lZCwgaXQgcmFpc2VzIGF3YXJlbmVzcyBzbyB0aGF0IHBlb3Bs ZSBpbiB0aGUgV0cgKGFuZCBBRHMpIHdpbGwgYXNrIG9mIGZ1dHVyZSB3b3JrLCAmcXVvdDtkb2Vz IHRoaXMgd29yayBvbiBhbiBJUHY2LW9ubHkgTVBMUyBuZXR3b3JrLA0KIGRvZXMgaXQgZGVwZW5k IG9uIGtub3duIGdhcHMgZG9jdW1lbnRlZCBpbiBSRkNubm5uIGJlaW5nIGFkZHJlc3NlZCwgb3Ig YXJlIGFkZGl0aW9uYWwgY2hhbmdlcyBuZWNlc3NhcnkgdG8gbWFrZSB0aGlzIHdvcmsgcHJvcGVy bHkgb24gSVB2Ni1vbmx5PyZxdW90OyZuYnNwOzwvZGl2Pg0KPGRpdj5TZWNvbmQsIEkgdGhpbmsg dGhpcyBnZW5lcmFsbHkgaGlnaGxpZ2h0cyBhIHByb2JsZW0gSUVURi13aWRlIHdoZW4gaXQgY29t ZXMgdG8gZ2FwIGFuYWx5c2VzLiBFaXRoZXIgdGhlIHdvcmsgaXMgYWxyZWFkeSBpbiBwcm9ncmVz cywgYW5kIGl0IHNlcnZlcyBhcyBhIG1ldGhvZCB0byBjYXRhbG9nIHRoZSBpc3N1ZXMgdG8gbWFr ZSBzdXJlIHdlIGhhdmUgdGhlbSBhbGwgYmVpbmcgYWRkcmVzc2VkLCBvciBpdCBzZXJ2ZXMgdG8g aWRlbnRpZnkNCiBwbGFjZXMgd2hlcmUgZnV0dXJlIHdvcmsgaXMgbmVlZGVkLiBUaGUgcHJvYmxl bSBpcyB0aGF0IHRoZSBJRVRGIGhhcyBubyBtZXRob2QgZGVmaW5lZCB0byBmb2xsb3cgdXAgb24g Z2FwIGFuYWx5c2VzIHRvIGVuc3VyZSB0aGF0IGZ1dHVyZSB3b3JrIGlkZW50aWZpZWQgYWN0dWFs bHkgZ2V0cyBjb21wbGV0ZWQsIHNob3J0IG9mIHRoZSBXRyBhZGRpbmcgaXRlbXMgdG8gaXRzIGNo YXJ0ZXIgdG8gZXhwbGljaXRseSBhZGRyZXNzIHRoZXNlIHRoaW5ncy4NCiBJZiB0aGUgZ2FwIGFu YWx5c2lzIHNwYW5zIFdHcywgb3IgdGhlcmUgaXNuJ3QgYW55b25lIGludGVyZXN0ZWQgaW4gYWRk cmVzc2luZyB0aGUgaWRlbnRpZmllZCBnYXAsIGl0IGNhbiBzb3J0IG9mIHJvdCBpbnNpZGUgdGhl IGFuYWx5c2lzIGFuZCBncmFkdWFsbHkgYmUgZm9yZ290dGVuLiBXZSdyZSBkZWFsaW5nIHdpdGgg dGhpcyBxdWVzdGlvbiBpbiBzdW5zZXQ0IG9uIHRoZSBvcmlnaW5hbCBzZXQgb2YgSVB2NiBnYXAg YW5hbHlzZXMgdGhhdCB3ZXJlDQogZG9uZSBvbiBSRkNzIDM3OTAtOTYsIGJlY2F1c2Ugbm8gb25l IGhhcyBhIGdvb2Qgc2Vuc2UgZm9yIHdoZXRoZXIgYWxsIG9mIHRoZSBnYXBzIGlkZW50aWZpZWQg aW4gdGhvc2UgZG9jdW1lbnRzIHdlcmUgYWRkcmVzc2VkLCBvciBhcmUgaW5kZWVkIHN0aWxsIHJl bGV2YW50LiBUaGlzIGRyYWZ0IGNhdGFsb2dzIGdhcHMgd2l0aCBwb2ludGVycyB0byB3aGVyZSB0 aGUgYXV0aG9ycyBrbm93IHRoZXJlIGlzIGFscmVhZHkgd29yayBiZWluZyBkb25lLA0KIHdoaWNo IHNlcnZlcyB0byBsaW5rIHRoZSB0d28sIGFuZCBlbnN1cmVzIHRoYXQgaXQncyBhcyBjbGVhciBh cyBwb3NzaWJsZSB3aGVyZSB0aGVyZSBhcmUgc3RpbGwgb3V0c3RhbmRpbmcgZ2FwcyB0aGF0IG5l ZWQgdG8gYmUgYWRkcmVzc2VkLCBhbmQgaXQnZCBiZSByZWFzb25hYmxlIHRvIGV4cGVjdCBhbnkg Zm9sbG93LW9uIGRvY3VtZW50cyB0aGF0IGFkZHJlc3MgZ2FwcyBpZGVudGlmaWVkIGFzIFRCRCBp biB0aGlzIGRvY3VtZW50IHRvIGZvcm1hbGx5DQogdXBkYXRlIHRoaXMgZG9jdW1lbnQgc28gdGhh dCB0aGUgbGluayBpcyBwcmVzZW50IGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQgdGhlIGZ1dHVy ZSBkb2N1bWVudHMgYWRkcmVzc2luZyBzb21lIG9mIHRoZSBnYXBzIHRoYXQgaXQgaWRlbnRpZmll ZCBhcyBub3QgaGF2aW5nIGZpeGVzIGluIHByb2dyZXNzLiBJdCdzIHRoZSBiZXN0IHdlIGNhbiBk byB3aXRoICZxdW90O2Zyb3plbiBpbiB0aW1lJnF1b3Q7IGRvY3VtZW50cyBsaWtlIHRoaXMsIGJ1 dCBJIHRoaW5rIGl0J3MNCiBhY2NlcHRhYmxlLiZuYnNwOzwvZGl2Pg0KPGRpdj5VbHRpbWF0ZWx5 LCBJIHRoaW5rIHlvdXIgcXVlc3Rpb24gaXMgYSBsYXJnZXIgaXNzdWUgYW5kIHRoaXMgZ2FwIGFu YWx5c2lzIGlzIG5vIGRpZmZlcmVudCB0aGFuIGFueSBvdGhlciDigJMgdGhlIHF1ZXN0aW9uIG9m ICZxdW90O3Nob3VsZCB3ZSBwdWJsaXNoJnF1b3Q7IGlzIHJlYWxseSAmcXVvdDtzaG91bGQgd2Ug cHVibGlzaA0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+YW55PC9zcGFuPiZuYnNw O2dhcCBhbmFseXNpcyBhcyBhbiBSRkMgZ2l2ZW4gdGhlIGxpbWl0YXRpb25zIG9mIHRoZSBzZXJp ZXM/JnF1b3Q7IGFuZCB0aGF0J3Mgbm90IHNvbWV0aGluZyB3ZSdyZSBnb2luZyB0byBzb2x2ZSBo ZXJlLCBzbyBJIHRoaW5rIGl0J3MgYSBtYXR0ZXIgb2YgcHVibGlzaGluZyB0aGUgZG9jdW1lbnQg aWYgdGhlIGNvbnRlbnQgaXMgaGVscGZ1bC4mbmJzcDs8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8cCBzdHlsZT0ibWFyZ2lu OiAwcHggMHB4IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PGI+TWlub3IgSXNzdWVzOjwv Yj48L3A+DQo8dWw+DQo8bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJy aTsiPlNvbWUgdGVybWlub2xvZ3kgd2FzIG5vdCBleHBhbmRlZCBiZWZvcmUvd2hlbiBpdCB3YXMg Zmlyc3QgdXNlZDogd2UgYWxsIGtub3cgd2hhdCBNUExTIGlzLCBidXQgb3RoZXJzIGxpa2UgTFNS LCBMRVIsIEZFQywgTDJWUE4sIEVWUE4sIE5HLW1WUE4sIGV0Yy4gc2hvdWxkIGJlIGV4cGFuZGVk Lg0KPC9saT48L3VsPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJy aTsiPldHXSBJIGJlbGlldmUgdGhpcyBpcyBmaXhlZCBub3c8L3A+DQo8dWw+DQo8bGkgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsiPlNlY3Rpb24gMy4xIChNUExTIERh dGEgUGxhbmUpOiAmcXVvdDtJbiB0aGUgY2FzZSB3aGVyZSBhbiBJUHY0IHByZWZpeCBpcyByZXNv bHZlZCBvdmVyIGFuIElQdjYgTFNQLCBhbiZuYnNwO0lQdjYgRXhwbGljaXQgTnVsbCBsYWJlbCBj YW5ub3QgaW1tZWRpYXRlbHkgcHJlY2VlZCBhbiBJUHY0IHBhY2tldC4mcXVvdDsgJm5ic3A7SXMg dGhlcmUgYSByZWZlcmVuY2UgZm9yIHRoaXMgc3RhdGVtZW50IG9yDQogaXMgdGhpcyBhIHJlcXVp cmVtZW50IHRvIGZpbGwgaW4gdGhlIGdhcD8gJm5ic3A7SWYgaXQgaXMgYSByZXF1aXJlbWVudCwg ZG8gd2UgbmVlZCB0byBhZGQgMjExOSBsYW5ndWFnZT8NCjwvbGk+PC91bD4NCjxwIHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij4tLTxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPkl0IHJlYWxseSBjb21lcyBmcm9tIFJGQyAzMDMy LCBhbmQgdGhlbiBSRkMgNDE4Mi4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+T25lIGV4YW1wbGUgaXMgcDwvc3Bhbj5yZXNlbnQgaW4g UkZDNDc5ODwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pkhvd2V2ZXIsIGFmdGVy IHJldmlldywgd2UndmUgcmVtb3ZlZCB0aGlzIHRleHQsIGJlY2F1c2Ugd2UgZG9uJ3QgdGhpbmsg dGhhdCB0aGlzIGlzIGFjdHVhbGx5IGEgZ2FwLCBhbmQgdGhlIHRleHQgd2FzIGNvbmZ1c2luZyAo ZXZlbiB0byB5b3VyIGh1bWJsZSBlZGl0b3IpLjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9E WV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyAiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjx1bD4NCjxs aSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+V2hlbiBhIGdhcCBl eGlzdHMsIHlvdSBjbGFzc2lmeSBpdCBhcyAmcXVvdDttYWpvciZxdW90OyBvciAmcXVvdDttaW5v ciZxdW90Oy4gJm5ic3A7V2hhdCBpcyB0aGUgY3JpdGVyaWEgdXNlZD8gJm5ic3A7SSB3b3VsZCBp bWFnaW5lIHRoYXQgZ2l2ZW4gdGhhdCBpdCBpcyBhIGdhcCBhbmFseXNpcywgdGhlIG9iamVjdGl2 ZSBpcyB0byBwb2ludCBvdXQgdGhlIG5lZWRzLCBub3QgY2hhcmFjdGVyaXplIHRoZW0gKGlmIEkN CiBuZWVkIGEgJnF1b3Q7bWlub3ImcXVvdDsgZ2FwIHRvIGJlIGZpbGxlZCBpbiBvcmRlciBmb3Ig bXkgbmV0d29yayBkZXBsb3ltZW50IHRvIG9wZXJhdGUsIGl0IGJlY29tZXMgJnF1b3Q7bWFqb3Im cXVvdDsgdG8gbWUpLg0KPC9saT48L3VsPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZh bWlseTogQ2FsaWJyaTsiPldHXSBBZGRlZCB0ZXh0IHRvIHRoZSBiZWdpbm5pbmcgb2Ygc2VjdGlv biAzIGV4cGxhaW5pbmcgdGhlIHRlcm1zOjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1mYW1pbHk6IENhbGlicmk7Ij4mcXVvdDtBIG5vdGUgYWJvdXQgdGVybWlub2xvZ3k6IEdhcHMg YXJlIHR5cGljYWxseSBjaGFyYWN0ZXJpemVkIGFzICZxdW90O01ham9yJnF1b3Q7LCAmcXVvdDtN aW5vciZxdW90OyBvciAmcXVvdDtub25lJnF1b3Q7LiBNYWpvciBnYXBzIHJlZmVyIHRvIHNpZ25p ZmljYW50IGNoYW5nZXMgbmVjZXNzYXJ5IGluIG9uZSBvciBtb3JlIHN0YW5kYXJkcyB0byBhZGRy ZXNzIHRoZSBnYXAgZHVlIHRvIGV4aXN0aW5nIHN0YW5kYXJkcw0KIGxhbmd1YWdlIGhhdmluZyBl aXRoZXIgbWlzc2luZyBmdW5jdGlvbmFsaXR5IGZvciBJUHY2LW9ubHkgb3BlcmF0aW9uIG9yIGV4 cGxpY2l0IGxhbmd1Z2UgcmVxdWlyaW5nIHRoZSB1c2Ugb2YgSVB2NCB3aXRoIG5vIElQdjYgYWx0 ZXJuYXRpdmVzIGRlZmluZWQuIE1pbm9yIGdhcHMgcmVmZXIgdG8gY2hhbmdlcyBuZWNlc3Nhcnkg cHJpbWFyaWx5IHRvIGNsYXJpZnkgZXhpc3Rpbmcgc3RhbmRhcmRzIGxhbmd1YWdlLiBVc3VhbGx5 IHRoZXNlIGNoYW5nZXMNCiBhcmUgbmVlZGVkIGluIG9yZGVyIHRvIGV4cGxpY2l0bHkgY29kaWZ5 IElQdjYgc3VwcG9ydCBpbiBwbGFjZXMgd2hlcmUgaXQgaXMgZWl0aGVyIGltcGxpY2l0IG9yIG9t aXR0ZWQgdG9kYXksIGJ1dCB0aGUgb21pc3Npb24gaXMgdW5saWtlbHkgdG8gcHJldmVudCBJUHY2 LW9ubHkgb3BlcmF0aW9uLiZxdW90OzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1m YW1pbHk6IENhbGlicmk7IG1pbi1oZWlnaHQ6IDE3cHg7Ij48YnI+DQo8L3A+DQo8dWw+DQo8bGkg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsiPlRoZSBpbnRyb2R1Y3Rp b24gdG8gdGhlIGRyYWZ0IHRhbGtzIGFib3V0ICZxdW90O2dhcHMgdGhhdCBtdXN0IGJlIGFkZHJl c3NlZCBpbiBvcmRlciB0byBhbGxvdyBNUExTLXJlbGF0ZWQgcHJvdG9jb2xzJm5ic3A7YW5kIGFw cGxpY2F0aW9ucyB0byBiZSB1c2VkIHdpdGggSVB2Ni1vbmx5IG5ldHdvcmtzJnF1b3Q7ICgmcXVv dDtJUHY2LW9ubHkgKG5vIElQdjQmbmJzcDtwcm92aXNpb25lZCBvbiB0aGUgZGV2aWNlKSZxdW90 OyksDQogd2hpY2ggZ2l2ZXMgdGhlIGltcHJlc3Npb24gdGhhdCBubyBJUHY0IGlzIHByZXNlbnQg aW4gdGhlIG5ldHdvcmsgYXQgYWxsLiAmbmJzcDsmbmJzcDtIb3dldmVyLCBzZXZlcmFsIGdhcHMg YXJlIGlkZW50aWZpZWQgdGhhdCBvY2N1ciBpbiAmcXVvdDttaXhlZCZxdW90OyBuZXR3b3Jrcywg d2hlcmUgaXNsYW5kcyBvZiBJUHY0L0lQdjYgZXhpc3QuICZuYnNwO0kgd291bGQgc3VnZ2VzdCBj bGFyaWZ5aW5nIHRoZSBzY29wZSBvZiB0aGUmbmJzcDtkb2N1bWVudCBpbiB0aGUgaW50cm9kdWN0 aW9uLiAmbmJzcDtTb21lDQogb2YgdGhlIHBsYWNlcyB3aGVyZSB0aGVzZSBzY2VuYXJpb3MgYXJl IGRpc2N1c3NlZCBpbmNsdWRlOiAmbmJzcDszLjIuMi4gKE11bHRpcG9pbnQgTERQKSwmbmJzcDsz LjMuMi4gKEwzVlBOKSwgJm5ic3A7My40LjEuIChFeHRlbmRlZCBJQ01QKSBhbmQmbmJzcDszLjQu Mi4gKExTUCBQaW5nKS4NCjwvbGk+PC91bD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1m YW1pbHk6IENhbGlicmk7Ij5XR10gYSBmZXcgc2VudGVuY2VzIGJlZm9yZSwgdGhlIGRvY3VtZW50 IHNheXMgJnF1b3Q7YW55IG5ldHdvcmtzIHdpbGwgbmVlZCB0byBzdGFydCBvcGVyYXRpbmcgc29t ZSBvciBhbGwgb2YgdGhlaXIgbmV0d29yayBub2RlcyBlaXRoZXIgYXMgcHJpbWFyaWx5IElQdjYg KG1vc3QgZnVuY3Rpb25zIHVzZSBJUHY2LCBhIGZldyBsZWdhY3kgZmVhdHVyZXMgdXNlIElQdjQp LCBvcg0KIGFzIElQdjYtb25seSAobm8gSVB2NCBwcm92aXNpb25lZCBvbiB0aGUgZGV2aWNlKSZx dW90OyBEbyB3ZSBzaW1wbHkgbmVlZCB0byBhZGQgc2ltaWxhciBsYW5ndWFnZSB0byB0aGUgbmV4 dC10by1sYXN0IHNlbnRlbmNlLCBkb2VzIHRoZSBleGlzdGluZyB0ZXh0IG1ha2UgaXQgY2xlYXIg bm93IHRoYXQgSSd2ZSBoaWdobGlnaHRlZCBpdCwgb3IgaXMgbW9yZSByZXF1aXJlZD88L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0OiAx N3B4OyI+PGJyPg0KPC9wPg0KPHVsPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1p bHk6IENhbGlicmk7Ij4zLjMuMS4xLiAoRVZQTikgJm5ic3A7SWYgdGhlIEVWUE4gd29yayBpcyBv dXQgb2YgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCwgdGhlbiB0YWtlIGl0IG91dC4gJm5ic3A7 QW5vdGhlciBvcHRpb24gbWF5IGJlIHRvIHRhbGsgYWJvdXQgYW55IGdhcHMgaW4gdGhlIGN1cnJl bnQgd29yay4gJm5ic3A7U2FtZSBjb21tZW50IGZvciBzZWN0aW9uJm5ic3A7My4zLjIuNC4zLiAo UEUtUEUgTXVsdGljYXN0DQogUm91dGluZyBQcm90b2NvbCkuIDwvbGk+PC91bD4NCjxwIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij5XR10gRVZQTiBkcmFmdCBpcyBw ZW5kaW5nIElFU0cvSUVURiBMQywgc28gaXQncyBub3Qgc28gbXVjaCBvZiBhIHdvcmsgaW4gcHJv Z3Jlc3MgYW55bW9yZSwgYW5kIHdpbGwgbGlrZWx5IGhpdCBwdWJsaWNhdGlvbiBwcmlvciB0byB0 aGlzIGRvY3VtZW50LiBJIGhhdmUgZW1haWxlZCBFVlBOIGF1dGhvcnMgdG8gcmVxdWVzdCB0aGF0 IHRoZXkgY29uc2lkZXIgRVZQTiBpbg0KIHRoZSBJUHY2LW9ubHkgb3BlcmF0aW9uIGNvbnRleHQg b2YgdGhpcyBkcmFmdCwgYW5kIGVpdGhlciBjb25maXJtIHRoYXQgdGhlcmUgYXJlIG5vIGdhcHMs IHRoYXQgdGhlcmUgYXJlIGRlcGVuZGVuY2llcyBvbiBnYXBzIGFscmVhZHkgaWRlbnRpZmllZCwg b3IgcmVzb2x2ZSBhbnkgZ2FwcyBwcmVzZW50IHRoYXQgYXJlIHVuaXF1ZSB0byBFVlBOIHByaW9y IHRvIExDLiBUaGUgc2VjdGlvbiB3aWxsIGJlIHVwZGF0ZWQgYWNjb3JkaW5nbHkgdG8gcmVtb3Zl DQogdGhlIGNvbW1lbnRzIGFib3V0IGl0IGJlaW5nIG91dCBvZiBzY29wZSBhbmQgYWRkIGEgYnJp ZWYgZ2FwIGFuYWx5c2lzIGJhc2VkIG9uIHRoZSByZXN1bHRzIG9mIHRoYXQgZGlzY3Vzc2lvbi4m bmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBt aW4taGVpZ2h0OiAxN3B4OyI+PGJyPg0KPC9wPg0KPHVsPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBw eDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij4zLjMuMi4gKEwzVlBOKSAmbmJzcDt0aGUgdGV4dCBz YXlzIHRoYXQgdGhlIGdhcHMgaW4gUkZDNDM2NCAobm8mbmJzcDtWUE4tSVB2NiBhZGRyZXNzIGFu ZCBhJm5ic3A7MTI4IGJpdCBuZXh0LWhvcCkgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiBSRkMgNDY1 OSwgYnV0IGl0IHRoZW4gaWRlbnRpZmllcyB0aGUgZ2FwIGFuZCBzYXlzIHRoYXQgJnF1b3Q7UkZD NDM2NCBtdXN0IGJlIHVwZGF0ZWQmcXVvdDsuICZuYnNwO1doYXQNCiB3b3VsZCB0aGF0IHVwZGF0 ZSBiZT8gPC9saT48L3VsPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaTsiPldHXSBZb3UncmUgcmlnaHQsIHRoaXMgd2FzIHJlYWxseSBjb25mdXNpbmcgYXMgd3Jp dHRlbi4gTWFkZSBzaWduaWZpY2FudCBjaGFuZ2VzIHRvIHRoaXMgc2VjdGlvbi4gVGhlcmUgYXJl IG5vIGdhcHMgaW4gNDM2NC4gVGhlIHJlYWwgcHJvYmxlbSBpcyB0aGF0IDQ2NTkgdXBkYXRlcyA0 MzY0IGFuZCBmaXhlcyB0aG9zZSBnYXBzLCBidXQgaXQgZG9lc24ndCBmb3JtYWxseQ0KIHVwZGF0 ZSA0MzY0IGluIHRoZSBtZXRhZGF0YSwgc28gaXQgbG9va3MgbGlrZSB0aGVyZSBhcmUgZ2FwcyBl eHRhbnQgaW4gNDM2NC4gSXQgYWxzbyBleHBsaWNpdGx5IGNhbGxzIHVzZSBjYXNlICMyIG91dCBv ZiBzY29wZS4mbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBD b25zb2xhczsgY29sb3I6IHJnYig0LCA0NiwgMjM4KTsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaTsgY29sb3I6IHJnYigwLCAwLCAwKTsiPkkgZmlsZWQgYW4gZXJyYXR1bSB0byBm aXggNDY1OSdzIG1ldGFkYXRhOg0KPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9l cnJhdGFfc2VhcmNoLnBocD9yZmM9NDY1OSZhbXA7ZWlkPTQwODciPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogQ29uc29sYXM7Ij5odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFy Y2gucGhwP3JmYz00NjU5JmFtcDtlaWQ9NDA4Nzwvc3Bhbj48L2E+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7IG1pbi1oZWlnaHQ6IDE3cHg7 Ij48YnI+DQo8L3A+DQo8dWw+DQo8bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTog Q2FsaWJyaTsiPlNlY3Rpb25zIDMuMy4yLjQuMy4gKFBFLVBFIE11bHRpY2FzdCBSb3V0aW5nIFBy b3RvY29sKSwmbmJzcDszLjMuMy4gKE1QTFMtVFApIGFuZCZuYnNwOzMuNC41LiAoTVBMUy1UUCBP QU0pJm5ic3A7YXJlIGluY2x1ZGVkLCBidXQgb3V0IG9mIHNjb3BlLi4gJm5ic3A7U2hvdWxkIHRo ZXkgYmUgcmVtb3ZlZD8gJm5ic3A7SWYgbm90LCB0aGVuIGEgc2hvcnQganVzdGlmaWNhdGlvbiBp biB0aGUgdGV4dCB3b3VsZA0KIGJlIG5pY2UuIDwvbGk+PC91bD4NCjxwIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij5XR10gY2xhcmlmaWVkPC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDogMTdweDsiPjxi cj4NCjwvcD4NCjx1bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxp YnJpOyI+My40LiAoTVBMUyBPQU0pICZuYnNwO1RoaXMgc2VudGVuY2UgJnF1b3Q7QWxsIG9mIHRo ZXNlJm5ic3A7bWVjaGFuaXNtcyB3b3JrIGluIHB1cmUgSVB2NiBlbnZpcm9ubWVudHMuJnF1b3Q7 IGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQgYWxsIHRoZSBtZWNoYW5pc21zIHdvcmsgY29ycmVj dGx5IGFuZCB0aGF0IHRoZXJlIGFyZSBubyBnYXBzLi5idXQgdGhlbiBzZXZlcmFsIGdhcHMgYXJl IGxpc3RlZC4NCjwvbGk+PC91bD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6 IENhbGlicmk7Ij5XR10gTWFkZSBzb21lIHdvcmRpbmcgY2hhbmdlcyBpbiAzLjQgYW5kIExTUCBw aW5nIHNlY3Rpb24gMy40LjIgZm9yIGNsYXJpdHkuJm5ic3A7PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDogMTdweDsiPjxicj4NCjwv cD4NCjx1bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+ VGFibGUgMTogSVB2Ni1vbmx5IE1QTFMgR2Fwcy4gJm5ic3A7VGhlIHRhYmxlIGRvZXNuJ3QgaW5j bHVkZSBhbGwgdGhlIGdhcHMgaWRlbnRpZmllZC4gJm5ic3A7Rm9yIGV4YW1wbGUsJm5ic3A7My4y LjIuIChNdWx0aXBvaW50IExEUCkgaXMgbm90IGluY2x1ZGVkIGluIHRoZSB0YWJsZSwgZXZlbiB0 aG91Z2ggYSBtYWpvciBnYXAgd2FzIGlkZW50aWZpZWQuICZuYnNwO0luIHRoaXMgY2FzZSwgdGhl IHdvcmsNCiBpbiB0aGUgdGFibGUgZm9yIExEUCBtYXkgYWxzbyBhZGRyZXNzIHRoZSBnYXAgaW4g bUxEUCwgYnV0IHRoYXQgaXMgbm90IHBvaW50ZWQgb3V0IGluIHRoZSB0YWJsZS4uICZuYnNwO0lu IHNob3J0LCB0aGUgdGFibGUgaXMgbm90Jm5ic3A7Y29tcGxldGUuDQo8L2xpPjwvdWw+DQo8cCBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+V0ddIEZpeGVkPC9wPg0K PHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDog MTdweDsiPjxicj4NCjwvcD4NCjx1bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyI+U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuICZuYnNwO1RoaXMgc2VjdGlv biB0YWxrcyBhYm91dCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBjdXJyZW50IHNwZWNpZmlj YXRpb25zLi5idXQgaXQgbGVhdmVzIG91dCBtZW50aW9uIG9mIHRoZSBmYWN0IHRoYXQgbmV3IHNw ZWNpZmljYXRpb25zICh0byBjbG9zZSB0aGUgZ2Fwcykgc2hvdWxkIChNVVNUID8pIGNvbnNpZGVy IHRoZQ0KIGVmZmVjdCBvZiBJUHY2LiA8L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+V0ddIEZpeGVkPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjog MHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDogMTdweDsiPjxicj4NCjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij48 Yj5OaXRzOjwvYj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDE0cHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyI+PGI+R2xvYmFsIEFDSy4gQ291cGxlIG9mIHNwZWNpZmljIGNvbW1lbnRz OjwvYj48L3A+DQo8dWw+DQo8bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaTsiPlNlY3Rpb24gMyAoR2FwIEFuYWx5c2lzKS4gJm5ic3A7WW91IHdyb3RlOiAmcXVvdDtU aGlzIGdhcCBhbmFseXNpcyBhaW1zIHRvIGFuc3dlciB0aGUgcXVlc3Rpb24sICZxdW90O3doYXQg YnJlYWtzIHdoZW4gb25lJm5ic3A7YXR0ZW1wdHMgdG8gdXNlIE1QTFMgZmVhdHVyZXMgb24gYSBu ZXR3b3JrIG9mIElQdjYtb25seSBkZXZpY2VzPyZxdW90OyAmbmJzcDtXaGlsZSBJIHVuZGVyc3Rh bmQgd2hhdCB5b3UncmUgYXNraW5nLA0KIGluIHJlYWxpdHkgeW91J3JlIHRyeWluZyB0byBhbnN3 ZXIgJnF1b3Q7d2hhdCBkb2Vzbid0IHdvcmsuLiZxdW90Oy4gJm5ic3A7QnJlYWtpbmcgaW1wbGll cyB0aGF0IGl0IG1heSB3b3JrIGZvciBhIHdoaWxlIGFuZCB0aGVuIHN0b3AgZG9pbmcgc28uDQo8 L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+ V0ddIGNoYW5nZWQgdG8gZmFpbHM8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0OiAxN3B4OyI+PGJyPg0KPC9wPg0KPHVsPg0KPGxpIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij4zLjMuMi4gKEwzVlBOKSAm bmJzcDsgVGhlIGdhcCBzZWN0aW9uIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgdGV4dDogJnF1b3Q7 RGlzY3Vzc2VkIGluIGZ1cnRoZXImbmJzcDtkZXRhaWwgYmVsb3cmcXVvdDsuICZuYnNwO0l0IHdv dWxkIGJlIG5pY2UgdG8gaGF2ZSBhbiBhY3R1YWwgcmVmZXJlbmNlIHRvIHRoZSBzZWN0aW9uIGlu c3RlYWQgb2YgdGhlIHRleHQuDQo8L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0K PGRpdj5XR10gSXQncyBpbiB0aGUgbmV4dCBwYXJhZ3JhcGgsIGlzIGZ1cnRoZXIgZ3VpZGFuY2Ug cmVhbGx5IG5lY2Vzc2FyeT88L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8dWw+DQo8bGkgc3R5bGU9Im1h cmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsiPkV2ZW4gdGhvdWdoIHNlY3Rpb25zIDMu My4yLjEgYW5kIDMuMy4yLjIgYXJlIHN1YnNlY3Rpb25zIG9mIDMuMy4yLCB3aXRoIHNvIG1hbnkg c2NlbmFyaW9zIGJlaW5nIGNvdmVyZWQsIGl0IGdldHMgaGFyZCB0byBrZWVwIHRyYWNrIG9mIHdo ZXJlIHNvbWV0aGluZyB3YXMmbmJzcDtkZXNjcmliZWQuICZuYnNwO0l0IHdvdWxkIGJlIHZlcnkg bmljZSB0byBpbmNsdWRlIHJlZmVyZW5jZXMNCiB0byB3aGVyZSAmcXVvdDt1c2UgY2FzZSAjMiZx dW90OyB3YXMgZGVmaW5lZCBpbiZuYnNwO3NhYyZuYnNwO29mIHRob3NlIHN1YnNlY3Rpb25zLiA8 L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+ V0ddIHdoaWxlIHRoZXNlIHJlZmVyZW5jZXMgY291bGQgYmUgYWRkZWQsIGl0IGNvdmVycyBsZXNz IHRoYW4gYSBwYWdlIG9mIHRleHQgd2l0aGluIG9uZSBzdWJzZWN0aW9uLiBJJ20gbm90IGNvbnZp bmNlZCB0aGlzIGlzIGFuIGFjdHVhbCBwcm9ibGVtPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4 OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDogMTdweDsiPjxicj4NCjwvcD4NCjx1 bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+My4zLjIu NC4yLiAoUC1UdW5uZWwgSW5zdGFudGlhdGlvbikgJm5ic3A7DQo8dWw+DQo8bGkgc3R5bGU9Im1h cmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsiPiZxdW90Oy4gLiAuY292ZXJlZCZuYnNw O2luIHByZXZpb3VzIHNlY3Rpb25zJnF1b3Q7LiAmbmJzcDtSZWZlcmVuY2VzIHBsZWFzZS48L2xp PjwvdWw+DQo8L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8 ZGl2PldHXSBhY2s8L2Rpdj4NCjx1bD4NCjx1bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZv bnQtZmFtaWx5OiBDYWxpYnJpOyI+JnF1b3Q7UElNIFRyZWUgYW5kIEluZ3Jlc3MgUmVwbGljYXRp b24gYXJlIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyZuYnNwO2RvY3VtZW50Li4mcXVvdDsmbmJz cDtiZWNhdXNlLi4gJm5ic3A7RWl0aGVyIGV4cGxhaW4gd2h5IG9yIHJlbW92ZSB0aGVtIGZyb20g dGhlIGxpc3QgcmlnaHQgYmVmb3JlLg0KPC9saT48L3VsPg0KPC91bD4NCjxwIHN0eWxlPSJtYXJn aW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij5XR10gZml4ZWQsIGRpc2N1c3Npb24gYWRk ZWQ8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4t aGVpZ2h0OiAxN3B4OyI+PGJyPg0KPC9wPg0KPHVsPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsg Zm9udC1mYW1pbHk6IENhbGlicmk7Ij4zLjQuMi4gKExTUCBQaW5nKSAmbmJzcDtzL0xTUCBQaW5n IHBhY2tldHMgYXJlIFVEUCBwYWNrZXRzIG92ZXIgYm90aCBJUHY0IGFuZCZuYnNwO0lQdjYvTFNQ IFBpbmcgcGFja2V0cyBhcmUgVURQIHBhY2tldHMgb3ZlciBlaXRoZXIgSVB2NCBvciZuYnNwO0lQ djY8L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10gYWNrPC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRw eDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyAiPg0KPHVsPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6 IENhbGlicmk7Ij5UaGVyZSBpcyBzb21lIHVuZXZlbiB0cmVhdG1lbnQgaW4gdGhlIGRlc2NyaXB0 aW9uIG9mIHRoZSBzdXBwb3J0L2dhcHMuICZuYnNwO0l0IHdvdWxkIGJlIG5pY2UgdG8gcHJvdmlk ZSB0aGUgc2FtZSBsZXZlbCBvZiBkZXRhaWwgZXZlcnl3aGVyZSAoaWYgbmVlZGVkKS4gJm5ic3A7 Rm9yIGV4YW1wbGUsIDMuMi4zLjIgKFJTVlAtVEUtUDJNUCkgcGxhaW5seSBtZW50aW9ucyB0aGF0 IFJGQzQ4NzUNCiBjb3ZlcnMgdGhlIHN1cHBvcnQgZm9yIElQdjYuLndoaWxlIDMuNC4zIChCRkQg T0FNKSBtZW50aW9ucyB3aGVyZSBJUHY2IHN1cHBvcnQgdXMgZGVmaW5lZCBidXQgaXQgYWxzbyBw b2ludHMgdG8gdGhlIHNwZWNpZmljIHNlY3Rpb25zLiAmbmJzcDtJTUhPLCB0aGUgYWRkaXRpb25h bCBkZXRhaWwgaXMgbm90IG5lZWRlZCAodW5sZXNzIHZlcnkgc3BlY2lmaWMgcG9pbnRzIG5lZWQg dG8gYmUgbWFkZSkuDQo8L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyI+V0ddIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoZSBkZXRhaWwgaXMgcHJv YmFibHkgbm90IGFic29sdXRlbHkgbmVjZXNzYXJ5LCBidXQgZG8gc2VlIGl0IGFzIHVzZWZ1bCBh bmQgdGhlcmVmb3JlIG5vIHJlYXNvbiB0byByZW1vdmUgaXQuJm5ic3A7PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvc3Bhbj48YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXki IHNpemU9IjEiPlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2lu ZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQog Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFk ZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUt bWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlz dHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNv bnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0bw0KIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D019124D2BF6Dwesleygeorgetwcablecom_-- From nobody Wed Aug 20 18:24:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202921A6F11 for ; Wed, 20 Aug 2014 18:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH1Ve8sD8AbX for ; Wed, 20 Aug 2014 18:24:46 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A317A1A6F53 for ; Wed, 20 Aug 2014 18:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1518; q=dns/txt; s=iport; t=1408584286; x=1409793886; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fxeqmgb2nRboD9ySyDyhP96QOYfYuQJYe+vF/3gf45s=; b=MmcHEgJDQgPTGaH4B7HGTUpRqErOJpRC8UKYEqdGwZ4RD7dN/gnzVqPF jtyMgKY65koN4BhrcbPDrIkbxte0QyDf3OR86B7oigIvq0azV7u39essY qeKHr8bP2tP9pqwgDSqVn7/YAyDqW3f4soF18uVIes33gi22Oyya8kyr7 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAEtJ9VOtJV2Y/2dsb2JhbABagmojgSoE1CMBgQ0Wd4QDAQEBBDo0CwwEAgEIDgMEAQELFAkHMhQJCAEBBAENBQiIOgHCaxePGzEHBoMpgR0BBI8SghOgKYNdbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,905,1400025600"; d="scan'208";a="70993306" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 21 Aug 2014 01:24:45 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7L1OiaB018570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 01:24:44 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 20:24:44 -0500 From: "Nobo Akiya (nobo)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+8ilRUv/hpET0IRlGIeWYgr95o5AAUoD/g Date: Thu, 21 Aug 2014 01:24:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VOWPiZUpZPdARNzm_wn1si_tZAI Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 01:24:49 -0000 Hi Ross, MPLS WG, I understand that my "support" as co-authors of this document does not coun= t towards this WG adoption poll, but I'd like to use this opportunity to sa= y that: (1) This document allows encoding of multiple Reply Modes in MPLS Echo Requ= est. (2) While (1) may be a trivial extension, significant benefit is that this = extension can eliminate virtually all instances of LSP Ping/Traceroute "tim= eout" due to responder not having the only one Reply Mode specified. (3) While (2) may just be a "would be nice" when LSP Ping/Traceroute is exe= cuted manually, avoiding "timeout" when executing LSP Ping/Traceroute from = applications/scripts is a great benefit. Due to above, I believe this document describes an useful extension that im= proves usability of the LSP Ping/Traceroute tool by users/applications/scri= pts. Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Wednesday, August 20, 2014 11:21 AM > To: mpls@ietf.org > Cc: 'mpls-chairs@tools.ietf.org' > Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode- > simple-02 >=20 > This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-re= ply- > mode-simple-02 > as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). >=20 > This poll will end Thursday September 4, 2014. >=20 > Thanks, Ross >=20 From nobody Wed Aug 20 19:53:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF341A04FA for ; Wed, 20 Aug 2014 19:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6Oxs8HhIr6q for ; Wed, 20 Aug 2014 19:53:24 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E1A1A0061 for ; Wed, 20 Aug 2014 19:53:24 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so12905634pdj.0 for ; Wed, 20 Aug 2014 19:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=O824WQan7gMdQyeofTCvXHrINsgSu2y/HGLMGj+eTrY=; b=No9OHQx7iXof1O53guTifexkUbIwnnx96JWNCrszkNbrr7TtL3YgHpmATAworwmlOq /ZvUmYAB047f+e1ABbedhPYdSiTLyu5FUZapIFCFT51w8zyMJVNAiEJra21tVyKbc8nB IZtNQIpR6upm4U22nErOXXtV5y0me2yi/3tyXQUgbQAlvezAGYLMmSHTJfKTcqaaHXjJ HC5cniaB6XfKd6FlxqEZrFi9CNjt5ZfsJo1Iw6c2bmWq35tlDr1lbd2LfRWl50YMipgb 3HCg83CNh8ykpYYo+Yp1KD7whiJaUOR2llIX28R+HFu9XqshS+6ERr6utgghBLXNTebV HumQ== X-Received: by 10.66.100.231 with SMTP id fb7mr197407pab.147.1408589603011; Wed, 20 Aug 2014 19:53:23 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id wc3sm85952430pac.18.2014.08.20.19.53.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 19:53:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_869094C2-501C-4F16-BEA4-DF1A6186148D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Wed, 20 Aug 2014 19:53:17 -0700 Message-Id: References: To: Ross Callon X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/uHqCoD9aLa4NREtCwnv8nS9OuyY Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 02:53:26 -0000 --Apple-Mail=_869094C2-501C-4F16-BEA4-DF1A6186148D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ross, et al, I have discussed over the mailing alias why I do not support this draft = in the current form. Authors and I could not converge to agreed conclusion. Here are things I would like to see in the draft=20 1. Provide an example with specific type of LSP and FEC type where is = useful and also why existing RFC=92s couldn=92t solve it. 2. Details on how this draft will reduce =91false failures=92, given = that every device has to support these new TLV=92s. As it was discussed in detail already over the mailing list, need to see = the benefits for these extensions. My point is, if problem is solved already with existing mechanisms, = there is no need to solve with different method. We use that argument = many times in the WG/IETF. But if it is indeed solving something which couldn=92t be solved thus = far (I haven=92t seen it yet), you will have my support. cheers -sam On Aug 20, 2014, at 8:20 AM, Ross Callon wrote: > This is to start a two week poll on adopting = draft-akiya-mpls-lsp-ping-reply-mode-simple-02 > as an MPLS working group document. > =20 > Please send your comments (support/not support) to the mpls working = group > mailing list (mpls@ietf.org). > =20 > This poll will end Thursday September 4, 2014. > =20 > Thanks, Ross > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_869094C2-501C-4F16-BEA4-DF1A6186148D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Ross, et al,

I have discussed over the mailing alias = why I do not support this draft in the current form.
<h= ttp://www.ietf.org/mail-archive/web/mpls/current/msg12403.html>
Authors and I could not converge to agreed = conclusion.

Here are things I would like to see = in the draft 

1. Provide an example with = specific type of LSP and FEC type where is useful and also why existing = RFC=92s couldn=92t solve it.
2. Details on how this draft will = reduce =91false failures=92, given that every device has to support = these new TLV=92s.

As it was discussed in = detail already over the mailing list, need to see the benefits for these = extensions.
My point is, if problem is solved already with = existing mechanisms, there is no need to solve with different method. We = use that argument many times in the WG/IETF.
But if it is = indeed solving something which couldn=92t be solved thus far (I haven=92t = seen it yet), you will have my = support.

cheers
-sam

On Aug 20, 2014, at 8:20 AM, Ross Callon <rcallon@juniper.net> = wrote:

This = is to start a two week poll on adopting = draft-akiya-mpls-lsp-ping-reply-mode-simple-02
as an MPLS = working group document.
 
Please send your = comments (support/not support) to the mpls working = group
mailing list (mpls@ietf.org).
 
This poll will end Thursday September 4, = 2014.
 
Thanks, = Ross
 
_________________________________= ______________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls

= --Apple-Mail=_869094C2-501C-4F16-BEA4-DF1A6186148D-- From nobody Wed Aug 20 23:59:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C721A03F4 for ; Wed, 20 Aug 2014 23:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 9mtfLlpIi_oM for ; Wed, 20 Aug 2014 23:59:06 -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 D63A21A0100 for ; Wed, 20 Aug 2014 23:59:05 -0700 (PDT) Received: from [192.168.0.101] (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 542C31801586; Thu, 21 Aug 2014 08:59:04 +0200 (CEST) Message-ID: <53F598B7.7060205@pi.nu> Date: Thu, 21 Aug 2014 08:59:03 +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: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-eY-0u_ahvdoGhGSkt4QV-IKafk Cc: "draft-ietf-mpls-pim-sm-over-mldp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] working group last call for draft-ietf-mpls-pim-sm-over-mldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 06:59:08 -0000 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-pim-sm-over-mldp. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There is one IPR disclosures against this document. All the authors and contributors have stated on the working group mailing list that they are not aware of any other IPRs that relates to this draft. This working group last call ends September 5, 2014. /Loa for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Aug 21 03:31:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1352B1A0104 for ; Thu, 21 Aug 2014 03:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 hpJpMPyRAUEJ for ; Thu, 21 Aug 2014 03:31:06 -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 0ECE41A00F0 for ; Thu, 21 Aug 2014 03:31:06 -0700 (PDT) Received: from [192.168.0.101] (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 821891801586; Thu, 21 Aug 2014 12:31:04 +0200 (CEST) Message-ID: <53F5CA67.9070500@pi.nu> Date: Thu, 21 Aug 2014 12:31:03 +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: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/oJTiGbo1h_nwl8c729md6BevkD8 Cc: "" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Shepherds for MPLS MIB modules X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 10:31:08 -0000 Working Group, We have for some time been looking for someone to help us shepherding our MIB modules. I'm happy to announce that Mach Chen and Young Lee has agreed to help us. Please help Mach and Young as they start working with the documents. We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id-mib. Further shepherd assignments will be done as soon as the details are sorted out. /Loa for the mpls wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Aug 21 10:30:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937D91A047D; Thu, 21 Aug 2014 10:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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=-0.668, 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 Zcz_kwNNYVCQ; Thu, 21 Aug 2014 10:30:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75131A04A7; Thu, 21 Aug 2014 10:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28754; q=dns/txt; s=iport; t=1408642235; x=1409851835; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XpI1V9A86d1D9XCAzF3zKzRS5BkKtH3tVAd6MZ2oUmg=; b=dBX6frY3L/WxG/tsbOIINoSQnUjjOyVEV7l1jLz27T2Dz35nwUBFr8rH u/UTHX2B3ZwFWp7CWDRUZ2mlZoHrcQtiul5cKgQe021Ft1BTTUzOZjN4i C5Mj1ZBk6RHjQmheET1t2hUm0EuRVOBzfAmi0h70FZY7fngyDD3Y3F+kz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAGUs9lOtJV2S/2dsb2JhbABPCoJHRoEqBNQdAYEPFneEAwEBAQQaDUQOEAIBCBEDAQIhBwcyFAkIAQEEAQ0FG4gnwysXiX+EagcFRhEHhEwFh0iHSoIThmOEP5UKg15sAYEGAR4GHIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,909,1406592000"; d="scan'208,217";a="349093681" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 21 Aug 2014 17:30:29 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7LHUT9n006172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 17:30:29 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.181]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 12:30:29 -0500 From: "Alvaro Retana (aretana)" To: "George, Wes" , "rtg-ads@tools.ietf.org" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uA Date: Thu, 21 Aug 2014 17:30:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_D01B67B26749Baretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0z_j6diLoP_dG_by2Nl3pbzgKv8 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:30:41 -0000 --_000_D01B67B26749Baretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 8/20/14 11:38 AM, "George, Wes" > wrote: Wes: Hi! Some comments in line.. Alvaro, thank you for the thorough review. Please find my responses below i= nline on behalf of the author team. We have an update in the edit buffer, a= waiting a few updates to the EVPN section and possibly the L2VPN section (t= o incorporate any necessary discussion of RFC 7117), but I wanted to go ahe= ad and respond now that most of the comments have been addressed in our edi= ts at least. Thanks, Wes George From: "Alvaro Retana (aretana)" > Date: Tuesday, August 5, 2014 at 2:44 PM To: "rtg-ads@tools.ietf.org" > Cc: "rtg-dir@ietf.org" >, "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" >, "mpls@ietf.org" > Subject: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Comments: I do have a couple of high-level items I want to bring up. Because I assum= e that these may have already been discussed in the appropriate WG(s) I'm n= ot listing them as major issues, and will defer to what the consensus has b= een so far. 1. Why do we need to publish this document? As I said above, I believe = the work is valuable, but it captures the state in time (today!) of the gap= s =97 it points to work that already solved a potential gap, or is in the p= rocess of solving them. A significant portion of the gaps are already bein= g addressed. Given the importance of IPv6, if published, soon this documen= t will have to be updated to say "nothing breaks". Again, the work is impo= rtant, but it may be better suited to be a "living document" as a guide for= what still needs to be addressed. If it is to be published, I would sugge= st avoiding links to work in progress, but limiting the content to identify= ing the gaps..and then letting the solution drafts/RFCs point back to this = document.. (ala requirements -> solution) 2. It is interesting to me that this draft came through the mpls WG, and= not one of the operations-focused groups..which presumably would be in a b= etter position to evaluate the needs described. Given that the document is= already in WG Last Call, I'm assuming that the alignment has already been = discussed and that proper cross-WG reviews have occurred. WG] Cross-WG reviews haven't occurred, but we view MPLS's active participan= ts as a superset of the participants of most of the MPLS-dependent WGs, and= also a good source of cross-WG generalists and experts on MPLS. It's uncle= ar to me what needs should be evaluated by the operations-focused WGs, give= n that the issue came from a problem that an actual operator experienced (n= amely, me) and I don't think that the need for MPLS to work on an IPv6-only= or IPv6-primary network is particularly controversial anyway. If people be= lieve that there isn't enough overlap, we can certainly solicit reviews fro= m some of the other WGs involved. Awaiting AD/WG chair guidance. I don't think it's controversial either. You did a better job explaining m= y point: the need for this work "came from a problem that an actual operato= r experienced". But I agree with you about the overlap in participation an= d yield to whatever the AD/WG chair suggest. We've discussed this question about whether to publish a gap analysis at al= l somewhat offline, but I'm including a few points for the record and for W= G comment here. First, my expectation is that the gap analysis shouldn't proceed to RFC unt= il a consensus exists that we have reasonably captured all of the existing = gaps. In other words, this is a documentation of all of the gaps that we as= a collective group of the Smart People Who Know About Such Things could th= ink of, and explicit documentation of areas without gaps to confirm that we= reviewed them to validate this. New gaps SHOULD NOT develop, as once a gap= analysis like this is performed, it raises awareness so that people in the= WG (and ADs) will ask of future work, "does this work on an IPv6-only MPLS= network, does it depend on known gaps documented in RFCnnnn being addresse= d, or are additional changes necessary to make this work properly on IPv6-o= nly?" Second, I think this generally highlights a problem IETF-wide when it comes= to gap analyses. Either the work is already in progress, and it serves as = a method to catalog the issues to make sure we have them all being addresse= d, or it serves to identify places where future work is needed. The problem= is that the IETF has no method defined to follow up on gap analyses to ens= ure that future work identified actually gets completed, short of the WG ad= ding items to its charter to explicitly address these things. If the gap an= alysis spans WGs, or there isn't anyone interested in addressing the identi= fied gap, it can sort of rot inside the analysis and gradually be forgotten= . We're dealing with this question in sunset4 on the original set of IPv6 g= ap analyses that were done on RFCs 3790-96, because no one has a good sense= for whether all of the gaps identified in those documents were addressed, = or are indeed still relevant. This draft catalogs gaps with pointers to whe= re the authors know there is already work being done, which serves to link = the two, and ensures that it's as clear as possible where there are still o= utstanding gaps that need to be addressed, and it'd be reasonable to expect= any follow-on documents that address gaps identified as TBD in this docume= nt to formally update this document so that the link is present between thi= s document and the future documents addressing some of the gaps that it ide= ntified as not having fixes in progress. It's the best we can do with "froz= en in time" documents like this, but I think it's acceptable. Ultimately, I think your question is a larger issue and this gap analysis i= s no different than any other =96 the question of "should we publish" is re= ally "should we publish any gap analysis as an RFC given the limitations of= the series?" and that's not something we're going to solve here, so I thin= k it's a matter of publishing the document if the content is helpful. I agree with pretty much everything [*] you wrote..specially the part about= it being a wider issue that we're not going to solve here =97 and that sho= uldn't stop this work. As I said at the beginning, I defer to the current = consensus. The summary of our offline discussion is very good. I do want to bring up = one point that you mentioned there: " WG] Given that these sorts of documents are ultimately snapshots in time, w= e are including everything that we know about, but we do have to be clear a= bout the limits of what that means. We as the authors made the decision to = limit that to existing RFCs, because if we open it to any drafts in progres= s, we end up not having a decent line to draw about when to declare things = done =96 which drafts do we wait for, do we hold the doc because a new draf= t showed up that we need to evaluate, etc etc. I'm open to suggestions abou= t alternate methods of defining that line, but it's a lot harder to analyze= standards that are still fluid because they're actively being refined by t= he WG =96 is a gap in a draft really a gap, or is it simply a problem that = must be addressed before the thing that draft is standardizing is actually = ready to move to RFC? I think it's the latter, and that a gap is something = that exists in a standard that has already been completed because it can't = be updated to address that gap without a new draft, while an existing draft= can be modified to address the issue with minimal effort. " I fully agree with you: the line for identifying gaps should be based on RF= Cs (not drafts). [*] The part that I don't agree with is related to this line and the last c= ouple of sentences of your second point above: "This draft catalogs gaps wi= th pointers to where the authors know there is already work being done, whi= ch serves to link the two, and ensures that it's as clear as possible where= there are still outstanding gaps that need to be addressed, and it'd be re= asonable to expect any follow-on documents that address gaps identified as = TBD in this document to formally update this document so that the link is p= resent between this document and the future documents addressing some of th= e gaps that it identified as not having fixes in progress. It's the best we= can do with "frozen in time" documents like this, but I think it's accepta= ble." Following your logic ("is a gap in a draft really a gap"), I don't think th= at a draft can categorically be referred to as solving a gap. While we wou= ld hope that the draft progresses as expected and that it does address the = gap..it may end up not covering it, being abandoned, moving in a different = direction, etc. I understand the reasoning behind pointing at the work in progress. This d= iscussion is one of those where there might be no ideal answer and we both = might be right (at least in part). I wanted to bring this point up for the= record..and in case anyone has a brilliant solution. We don't need to dwe= ll on this.. . . . * The introduction to the draft talks about "gaps that must be addresse= d in order to allow MPLS-related protocols and applications to be used with= IPv6-only networks" ("IPv6-only (no IPv4 provisioned on the device)"), whi= ch gives the impression that no IPv4 is present in the network at all. Ho= wever, several gaps are identified that occur in "mixed" networks, where is= lands of IPv4/IPv6 exist. I would suggest clarifying the scope of the docu= ment in the introduction. Some of the places where these scenarios are dis= cussed include: 3.2.2. (Multipoint LDP), 3.3.2. (L3VPN), 3.4.1. (Extended= ICMP) and 3.4.2. (LSP Ping). WG] a few sentences before, the document says "any networks will need to st= art operating some or all of their network nodes either as primarily IPv6 (= most functions use IPv6, a few legacy features use IPv4), or as IPv6-only (= no IPv4 provisioned on the device)" Do we simply need to add similar langua= ge to the next-to-last sentence, does the existing text make it clear now t= hat I've highlighted it, or is more required? I think you should add similar language to the next-to-last sentence; that = is where you're describing what this document is doing. The text before it = is ok, but it seems to provide some context on what's happening as people a= re moving..not defining the scope. Thanks! Alvaro. --_000_D01B67B26749Baretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 8/20/14 11:38 AM, "George, Wes" <wesley.george@twcable.com> wrote:

Wes:

Hi!

Some comments in line..

Alvaro, thank you for the thorough review. Please find my responses be= low inline on behalf of the author team. We have an update in the edit buff= er, awaiting a few updates to the EVPN section and possibly the L2VPN secti= on (to incorporate any necessary discussion of RFC 7117), but I wanted to go ahead and respond now that mos= t of the comments have been addressed in our edits at least. 

Thanks,

 

Wes George

 

From: "Alvaro Retana (aretana)= " <aretana@cisco.com> Date: Tuesday, August 5, 2014 at 2:= 44 PM
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.or= g" <dr= aft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] RtgDir review: draf= t-ietf-mpls-ipv6-only-gap-01

Comments:

I do have a couple of high-level items I want to bring up.  Because I = assume that these may have already been discussed in the appropriate WG(s) = I'm not listing them as major issues, and will defer to what the consensus = has been so far.
  1. Why do we need to publish this document?  As I said above, I belie= ve the work is valuable, but it captures the state in time (today!) of the = gaps =97 it points to work that already solved a potential gap, or is in th= e process of solving them.  A significant portion of the gaps are already being addressed.  Given the importanc= e of IPv6, if published, soon this document will have to be updated to say = "nothing breaks".  Again, the work is important, but it may = be better suited to be a "living document" as a guide for what still needs to be addressed.  If it is to be published, I wo= uld suggest avoiding links to work in progress, but limiting the content to= identifying the gaps..and then letting the solution drafts/RFCs point back= to this document..  (ala requirements -> solution)
  2. It is interesting to me that this draft came throu= gh the mpls WG, and not one of the operations-focused groups..which presuma= bly would be in a better position to evaluate the needs described.  Gi= ven that the document is already in WG Last Call, I'm assuming that the alignment has already been discussed and that proper cross-WG rev= iews have occurred.
WG] Cross-WG reviews haven't occurred, but we view MPLS's active parti= cipants as a superset of the participants of most of the MPLS-dependent WGs= , and also a good source of cross-WG generalists and experts on MPLS. It's = unclear to me what needs should be evaluated by the operations-focused WGs, given that the issue came from= a problem that an actual operator experienced (namely, me) and I don't thi= nk that the need for MPLS to work on an IPv6-only or IPv6-primary network i= s particularly controversial anyway. If people believe that there isn't enough overlap, we can certainly solici= t reviews from some of the other WGs involved. Awaiting AD/WG chair guidanc= e.

I don't think it's controversial either.  You did a better job ex= plaining my point: the need for this work "came from a problem that an= actual operator experienced".  But I agree with you about the ov= erlap in participation and yield to whatever the AD/WG chair suggest.


We've discussed this question about whether to publish a gap analysis = at all somewhat offline, but I'm including a few points for the record and = for WG comment here.

First, my expectation is that the gap analysis shouldn't proceed to RF= C until a consensus exists that we have reasonably captured all of the exis= ting gaps. In other words, this is a documentation of all of the gaps that = we as a collective group of the Smart People Who Know About Such Things could think of, and explicit docum= entation of areas without gaps to confirm that we reviewed them to validate= this. New gaps SHOULD NOT develop, as once a gap analysis like this is per= formed, it raises awareness so that people in the WG (and ADs) will ask of future work, "does this work o= n an IPv6-only MPLS network, does it depend on known gaps documented in RFC= nnnn being addressed, or are additional changes necessary to make this work= properly on IPv6-only?" 

Second, I think this generally highlights a problem IETF-wide when it = comes to gap analyses. Either the work is already in progress, and it serve= s as a method to catalog the issues to make sure we have them all being add= ressed, or it serves to identify places where future work is needed. The problem is that the IETF has no me= thod defined to follow up on gap analyses to ensure that future work identi= fied actually gets completed, short of the WG adding items to its charter t= o explicitly address these things. If the gap analysis spans WGs, or there isn't anyone interested in address= ing the identified gap, it can sort of rot inside the analysis and graduall= y be forgotten. We're dealing with this question in sunset4 on the original= set of IPv6 gap analyses that were done on RFCs 3790-96, because no one has a good sense for whether all of t= he gaps identified in those documents were addressed, or are indeed still r= elevant. This draft catalogs gaps with pointers to where the authors know t= here is already work being done, which serves to link the two, and ensures that it's as clear as possible w= here there are still outstanding gaps that need to be addressed, and it'd b= e reasonable to expect any follow-on documents that address gaps identified= as TBD in this document to formally update this document so that the link is present between this document and= the future documents addressing some of the gaps that it identified as not= having fixes in progress. It's the best we can do with "frozen in tim= e" documents like this, but I think it's acceptable. 

Ultimately, I think your question is a larger issue and this gap analy= sis is no different than any other =96 the question of "should we publ= ish" is really "should we publish any gap analysis as an RFC g= iven the limitations of the series?" and that's not something we're go= ing to solve here, so I think it's a matter of publishing the document if t= he content is helpful. 

I agree with pretty much everything [*] you wrote..specially the part = about it being a wider issue that we're not going to solve here =97 and tha= t shouldn't stop this work.  As I said at the beginning, I defer to th= e current consensus.


The summary of our offline discussion is very good.  I do want to= bring up one point that you mentioned there:

"
WG] Given that these sorts of documents are ultimately snapshots in ti= me, we are including everything that we know about, but we do have to be cl= ear about the limits of what that means. We as the authors made the decisio= n to limit that to existing RFCs, because if we open it to any drafts in progress, we end up not having a de= cent line to draw about when to declare things done =96 which drafts do we = wait for, do we hold the doc because a new draft showed up that we need to = evaluate, etc etc. I'm open to suggestions about alternate methods of defining that line, but it's a lot harder to an= alyze standards that are still fluid because they're actively being refined= by the WG =96 is a gap in a draft really a gap, or is it simply a problem = that must be addressed before the thing that draft is standardizing is actually ready to move to RFC? I thin= k it's the latter, and that a gap is something that exists in a standard th= at has already been completed because it can't be updated to address that g= ap without a new draft, while an existing draft can be modified to address the issue with minimal effort.&n= bsp;
"

I fully agree with you: the line for identifying gaps should be based = on RFCs (not drafts).

[*] The part that I don't agree with is related to this line and the l= ast couple of sentences of your second point above: "This draft catalo= gs gaps with pointers to where the authors know there is already work being= done, which serves to link the two, and ensures that it's as clear as possible where there are still outstandi= ng gaps that need to be addressed, and it'd be reasonable to expect any fol= low-on documents that address gaps identified as TBD in this document to fo= rmally update this document so that the link is present between this document and the future documents address= ing some of the gaps that it identified as not having fixes in progress. It= 's the best we can do with "frozen in time" documents like this, = but I think it's acceptable."

Following your logic ("is a gap in a draft really a gap"), I= don't think that a draft can categorically be referred to as solving a gap= .  While we would hope that the draft progresses as expected and that = it does address the gap..it may end up not covering it, being abandoned, moving in a different direction, etc.

I understand the reasoning behind pointing at the work in progress. &n= bsp;This discussion is one of those where there might be no ideal answer an= d we both might be right (at least in part).  I wanted to bring this p= oint up for the record..and in case anyone has a brilliant solution.  We don't need to dwell on this..

. . .


  • The introduction to the dr= aft talks about "gaps that must be addressed in order to allow MPLS-re= lated protocols and applications to be used with IPv6-only networks&qu= ot; ("IPv6-only (no IPv4 provisioned on the device)"), which gives the impression that no IPv4 is present in the network at all. =   However, several gaps are identified that occur in "mixed&= quot; networks, where islands of IPv4/IPv6 exist.  I would suggest cla= rifying the scope of the document in the introduction.  Some of the places where these scenarios are discussed include:  3.2.2. (M= ultipoint LDP), 3.3.2. (L3VPN),  3.4.1. (Extended ICMP) and = 3.4.2. (LSP Ping).

WG] a few sentences before,= the document says "any networks will need to start operating some or = all of their network nodes either as primarily IPv6 (most functions use IPv= 6, a few legacy features use IPv4), or as IPv6-only (no IPv4 provisioned on the device)" Do we simply need t= o add similar language to the next-to-last sentence, does the existing text= make it clear now that I've highlighted it, or is more required?

I think you should add similar language to the next-to-last sentence; = that is where you're describing what this document is doing. The text befor= e it is ok, but it seems to provide some context on what's happening as peo= ple are moving..not defining the scope.

Thanks!

Alvaro.

--_000_D01B67B26749Baretanaciscocom_-- From nobody Thu Aug 21 13:43:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BC31A70E1 for ; Thu, 21 Aug 2014 13:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.168 X-Spam-Level: X-Spam-Status: No, score=-115.168 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NoyR_KoskPV for ; Thu, 21 Aug 2014 13:43:15 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5501A6FAC for ; Thu, 21 Aug 2014 13:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14275; q=dns/txt; s=iport; t=1408653795; x=1409863395; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=myXEpxF9GqILjxeR0n7JBoXjBDV8OoTL/rce5ti3tBc=; b=T7SDB3LR+yrhXMvdKQIh71+4XJ163LOv9h3TPtlnBH6VZL92JdV0LIAU TdA7NavsswI5SMHGnUvLULL2BcfPYyUnvxCO1gosovNV4usMwB9pOJyGc 6HsU6F/qcsjQGPXOP2BPnddr/ZhtbzUTXwgbV/bxtdNcAXLericrY6U2W I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAOtY9lOtJA2K/2dsb2JhbABZgkcjI1NXBMpugVkBC4dMAYEQFneEAwEBAQMBAQEBKkELEAIBCBEEAQELHQcnCxQJCAIEAQ0FCAGIMQgBDMNdF457AQEeLQQGAYMvgR0FjxKCE4QpiFCTM4NebAGBDjmBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,375,1406592000"; d="scan'208,217"; a="71311240" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 21 Aug 2014 20:43:13 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7LKhDsL021700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 20:43:13 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 15:43:13 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin , Ross Callon Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPvOshzBnSrGC81kW4l9uZaVVid5vbhNJw Date: Thu, 21 Aug 2014 20:43:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.92] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943A3B4453xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rB2NqjBN4zt95HfUwxudTtny_3I Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 20:43:18 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943A3B4453xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, >> 1. Provide an example with specific type of LSP and FEC type where is us= eful and also why existing RFC's couldn't solve it. The title of this WG adoption poll may have created some confusion. The lat= est version of this document is -03. http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-03 The latest version has Appendix A which was added as result of your comment= s. >> 2. Details on how this draft will reduce 'false failures', given that ev= ery device has to support these new TLV's. The extension itself is backwards compatible (i.e. adds an optional TLV), b= ut benefit can obviously be achieved when corresponding LSRs support the ex= tension. If there are one or more LSRs not supporting this extension, then = it is no worse than today. Thanks! -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Wednesday, August 20, 2014 10:53 PM To: Ross Callon Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-= simple-02 Hi Ross, et al, I have discussed over the mailing alias why I do not support this draft in = the current form. Authors and I could not converge to agreed conclusion. Here are things I would like to see in the draft 1. Provide an example with specific type of LSP and FEC type where is usefu= l and also why existing RFC's couldn't solve it. 2. Details on how this draft will reduce 'false failures', given that every= device has to support these new TLV's. As it was discussed in detail already over the mailing list, need to see th= e benefits for these extensions. My point is, if problem is solved already with existing mechanisms, there i= s no need to solve with different method. We use that argument many times i= n the WG/IETF. But if it is indeed solving something which couldn't be solved thus far (I = haven't seen it yet), you will have my support. cheers -sam On Aug 20, 2014, at 8:20 AM, Ross Callon > wrote: This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_CECE764681BE964CBE1DFF78F3CDD3943A3B4453xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sam,=

 <= /p>

>> 1. Provide an example with specific type of LSP and FEC type where i= s useful and also why existing RFC’s couldn’t solve it.

 <= /p>

The title of this WG adop= tion poll may have created some confusion. The latest version of this docum= ent is -03.

 <= /p>

http://tools.i= etf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-03<= /span>

 <= /p>

The latest version has Ap= pendix A which was added as result of your comments.

 <= /p>

>> 2. Details on how this draft will reduce ‘false failures’= ;, given that every device has to support these new TLV’s.=

 <= /p>

The extension itself is b= ackwards compatible (i.e. adds an optional TLV), but benefit can obviously = be achieved when corresponding LSRs support the extension. If there are one or more LSRs not supporting this extension, then it is no= worse than today.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Wednesday, August 20, 2014 10:53 PM
To: Ross Callon
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02

 

Hi Ross, et al,

 

I have discussed over the mailing alias why I do not= support this draft in the current form.

Authors and I could not converge to agreed conclusio= n.

 

Here are things I would like to see in the draft&nbs= p;

 

1. Provide an example with specific type of LSP and = FEC type where is useful and also why existing RFC’s couldn’t s= olve it.

2. Details on how this draft will reduce ‘fals= e failures’, given that every device has to support these new TLVR= 17;s.

 

As it was discussed in detail already over the maili= ng list, need to see the benefits for these extensions.

My point is, if problem is solved already with exist= ing mechanisms, there is no need to solve with different method. We use tha= t argument many times in the WG/IETF.

But if it is indeed solving something which couldn&#= 8217;t be solved thus far (I haven’t seen it yet), you will have my s= upport.

 

cheers

-sam

 

On Aug 20, 2014, at 8:20 AM, Ross Callon <rcallon@juniper.net> wrote:



This is to start a two week poll on ado= pting draft-akiya-mpls-lsp-ping-reply-mode-simple-02

as an MPLS working group document.=

 

Please send your comments (support/not = support) to the mpls working group

mailing list (mpls@ietf.org).

 

This poll will end Thursday September 4= , 2014.

 

Thanks, Ross

 

______________________________________= _________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943A3B4453xmbalnx01ciscoc_-- From nobody Thu Aug 21 14:26:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E28E1A0AD0 for ; Thu, 21 Aug 2014 14:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Z56So9RpEJwO for ; Thu, 21 Aug 2014 14:26:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAEB1A0ACA for ; Thu, 21 Aug 2014 14:26:01 -0700 (PDT) Received: from CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) by CO2PR05MB954.namprd05.prod.outlook.com (10.141.198.28) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Thu, 21 Aug 2014 21:25:59 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Thu, 21 Aug 2014 21:25:57 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.1010.016; Thu, 21 Aug 2014 21:25:57 +0000 From: Ross Callon To: "Nobo Akiya (nobo)" , Sam Aldrin Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+8ilRUv/hpET0IRlGIeWYgr95o5AAYLqOAACVdzQAAAXtjAA== Date: Thu, 21 Aug 2014 21:25:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(41574002)(189002)(164054003)(377454003)(199003)(101416001)(76576001)(79102001)(81342001)(80022001)(76176999)(99396002)(81542001)(21056001)(77982001)(108616004)(90102001)(15202345003)(85306004)(64706001)(20776003)(66066001)(46102001)(74316001)(16236675004)(54356999)(2656002)(107046002)(74502001)(105586002)(99286002)(15975445006)(95666004)(87936001)(230783001)(19617315012)(83072002)(19609705001)(92566001)(74662001)(85852003)(19580395003)(76482001)(19625215002)(83322001)(31966008)(50986999)(106356001)(33646002)(19300405004)(18717965001)(86362001)(19580405001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a994da1eb2fc405aa508382b54eb8917CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_NtBokPVYiUfyLhnTCHB8OiKqkw Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 21:26:05 -0000 --_000_a994da1eb2fc405aa508382b54eb8917CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops, my apology. Yes, the poll for adoption is on version -03. Thanks, Ross From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] Sent: Thursday, August 21, 2014 4:43 PM To: Sam Aldrin; Ross Callon Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-= simple-02 Hi Sam, >> 1. Provide an example with specific type of LSP and FEC type where is us= eful and also why existing RFC's couldn't solve it. The title of this WG adoption poll may have created some confusion. The lat= est version of this document is -03. http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-03 The latest version has Appendix A which was added as result of your comment= s. >> 2. Details on how this draft will reduce 'false failures', given that ev= ery device has to support these new TLV's. The extension itself is backwards compatible (i.e. adds an optional TLV), b= ut benefit can obviously be achieved when corresponding LSRs support the ex= tension. If there are one or more LSRs not supporting this extension, then = it is no worse than today. Thanks! -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Wednesday, August 20, 2014 10:53 PM To: Ross Callon Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-= simple-02 Hi Ross, et al, I have discussed over the mailing alias why I do not support this draft in = the current form. Authors and I could not converge to agreed conclusion. Here are things I would like to see in the draft 1. Provide an example with specific type of LSP and FEC type where is usefu= l and also why existing RFC's couldn't solve it. 2. Details on how this draft will reduce 'false failures', given that every= device has to support these new TLV's. As it was discussed in detail already over the mailing list, need to see th= e benefits for these extensions. My point is, if problem is solved already with existing mechanisms, there i= s no need to solve with different method. We use that argument many times i= n the WG/IETF. But if it is indeed solving something which couldn't be solved thus far (I = haven't seen it yet), you will have my support. cheers -sam On Aug 20, 2014, at 8:20 AM, Ross Callon > wrote: This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_a994da1eb2fc405aa508382b54eb8917CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Oops, my apology. Yes, th= e poll for adoption is on version -03.

 <= /p>

Thanks, Ross

 <= /p>

From: Nobo Aki= ya (nobo) [mailto:nobo@cisco.com]
Sent: Thursday, August 21, 2014 4:43 PM
To: Sam Aldrin; Ross Callon
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02

 

Hi Sam,

 = ;

>> 1. Provide an example with specific type of LSP= and FEC type where is useful and also why existing RFC’s couldn̵= 7;t solve it.

 = ;

The title = of this WG adoption poll may have created some confusion. The latest versio= n of this document is -03.

 = ;

http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-03<= /a>

 = ;

The latest= version has Appendix A which was added as result of your comments.

 = ;

>> 2. Details on how this draft will reduce ‘= ;false failures’, given that every device has to support these new TL= V’s.

 = ;

The extens= ion itself is backwards compatible (i.e. adds an optional TLV), but benefit= can obviously be achieved when corresponding LSRs support the extension. If there are one or more LSRs not supporting this extension= , then it is no worse than today.

 = ;

Thanks!

 = ;

-Nobo=

 = ;

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Wednesday, August 20, 2014 10:53 PM
To: Ross Callon
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02

 

Hi Ross, et al,

 

I have discussed over the maili= ng alias why I do not support this draft in the current form.

Authors and I could not converg= e to agreed conclusion.

 

Here are things I would like to= see in the draft 

 

1. Provide an example with spec= ific type of LSP and FEC type where is useful and also why existing RFCR= 17;s couldn’t solve it.

2. Details on how this draft wi= ll reduce ‘false failures’, given that every device has to supp= ort these new TLV’s.

 

As it was discussed in detail a= lready over the mailing list, need to see the benefits for these extensions= .

My point is, if problem is solv= ed already with existing mechanisms, there is no need to solve with differe= nt method. We use that argument many times in the WG/IETF.

But if it is indeed solving som= ething which couldn’t be solved thus far (I haven’t seen it yet= ), you will have my support.

 

cheers

-sam

 

--_000_a994da1eb2fc405aa508382b54eb8917CO2PR05MB636namprd05pro_-- From nobody Thu Aug 21 17:57:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD2E1A0688; Thu, 21 Aug 2014 17:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPtdPIDJfbvs; Thu, 21 Aug 2014 17:57:31 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B5C1A0655; Thu, 21 Aug 2014 17:57:31 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id at20so5494560iec.25 for ; Thu, 21 Aug 2014 17:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jh5vDOmubQkWtOAbwZOD9moqrC5roK+9TJsA7V42j5U=; b=vkTMEamQhXUsZxyBymi14Ul68xlQafvVvMs8dGAhNqh3GPRg/+1vCfdMuU25Wjbdre VQcE/QMfMM3Ddk2IN3mN8hb/kypcWVWqASxrOYg67f46xMKcffWcdDGAh7oXXNX7UzVf 7tRV4pZ7sfzZijyt41/W40RC0GeDJgimH6M9GlNnnItZRkiz7SGsc0ocvOkW8Ad4BNca UXeMq1QG176QvqefGrUE/N+AGxL0NJxG/4uXZn+QVVJU/f9O1Q3lS71NC6Yn/LM18u4/ 5QS1arH7ogikOAtEnhITEqEYsDTAKt11iIgsykkmCPJx+/9qdqdlgbu8nTK+hS1fW8+E dMNA== MIME-Version: 1.0 X-Received: by 10.42.35.8 with SMTP id o8mr6631756icd.41.1408669050975; Thu, 21 Aug 2014 17:57:30 -0700 (PDT) Received: by 10.50.189.170 with HTTP; Thu, 21 Aug 2014 17:57:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Aug 2014 06:27:30 +0530 Message-ID: From: Dhruv Dhody To: "Alvaro Retana (aretana)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cpnNIbgopUCBMvwyc5UKDu134Dw Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 00:57:33 -0000 Hi Alvaro, Wes, > I fully agree with you: the line for identifying gaps should be based on > RFCs (not drafts). > > [*] The part that I don't agree with is related to this line and the last > couple of sentences of your second point above: "This draft catalogs gaps > with pointers to where the authors know there is already work being done, > which serves to link the two, and ensures that it's as clear as possible > where there are still outstanding gaps that need to be addressed, and it'd > be reasonable to expect any follow-on documents that address gaps identified > as TBD in this document to formally update this document so that the link is > present between this document and the future documents addressing some of > the gaps that it identified as not having fixes in progress. It's the best > we can do with "frozen in time" documents like this, but I think it's > acceptable." > > Following your logic ("is a gap in a draft really a gap"), I don't think > that a draft can categorically be referred to as solving a gap. While we > would hope that the draft progresses as expected and that it does address > the gap..it may end up not covering it, being abandoned, moving in a > different direction, etc. > > I understand the reasoning behind pointing at the work in progress. This > discussion is one of those where there might be no ideal answer and we both > might be right (at least in part). I wanted to bring this point up for the > record..and in case anyone has a brilliant solution. We don't need to dwell > on this.. How about we move the pointers to any work-in-progress to address the gaps to appendix, would that be a good compromise? Dhruv From nobody Thu Aug 21 18:24:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3A51A6F8D for ; Thu, 21 Aug 2014 18:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjD7IdTM2e57 for ; Thu, 21 Aug 2014 18:24:32 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DB41A06AB for ; Thu, 21 Aug 2014 18:24:32 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n16so8289393oag.27 for ; Thu, 21 Aug 2014 18:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=cybPmpLYtbWD/H2EkgbadBwx6eUUJ6aQQZFuZPq5hwQ=; b=wij9BtAnTrWiyWiA2ndlY2Ih1wNije5H4Ur71l2IiJKdPitQ5mg3L43YsRFuHES+Ai I+OU72UsAT6ZnoxHt1lrfx7ZwCl27MGgvbR7euzLuUTnqCDfBlI+0cQTKAfWZhJOSDcg RN16RBJ0+xlhRaT05YzkpQ+QThdspERwKJkPthbzZcRPZnGE1LYT5Es2TVAATu31zWwL RGoWj9o7IoMsahEvYcbHFTGQpUtKAbs1xOo2REgv+rLL2kCoe3FHNlgBoeou3TsPnUN9 I/HJvE340ki4tcnkowS6fEEDlxDDthtWr/qNpdl9Ots/P+AvU38OtQ5xpHOnqAOjqCz9 xQFA== X-Received: by 10.60.94.48 with SMTP id cz16mr1918646oeb.53.1408670671497; Thu, 21 Aug 2014 18:24:31 -0700 (PDT) Received: from [192.168.5.99] (ip-64-134-54-91.public.wayport.net. [64.134.54.91]) by mx.google.com with ESMTPSA id w4sm30068871obz.20.2014.08.21.18.24.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 18:24:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4133A8C1-207E-41ED-939C-75BA3735FB02" From: "Sam K. Aldrin" In-Reply-To: Date: Thu, 21 Aug 2014 18:24:25 -0700 Message-Id: References: To: Nobo Akiya (nobo) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/AEndFOBCKGIttVmCBPpYTcPvCjo Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 01:24:34 -0000 --Apple-Mail=_4133A8C1-207E-41ED-939C-75BA3735FB02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Nobo, Inline for my comments. On Aug 21, 2014, at 1:43 PM, Nobo Akiya (nobo) wrote: > Hi Sam, > =20 > >> 1. Provide an example with specific type of LSP and FEC type where = is useful and also why existing RFC=92s couldn=92t solve it. > =20 > The title of this WG adoption poll may have created some confusion. = The latest version of this document is -03. > =20 > = http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-03 > =20 > The latest version has Appendix A which was added as result of your = comments. Yes, I am looking at the v03 itself.:D. The appendix doesn't mention = which FEC type. The only FEC type this extension will be helpful is MPLS TP with IP = available on every node. There are no other LSP's or FEC types which fits this scenario. Do they? Let us take the MPLS TP with IP on every node. The scenario you are talking about is 'associated bidirectional' tunnel. Just because a 'vendor' implemented certain default method doesn't = require new TLV support. For associated bidirectional tunnel with IP on every node, perform reply = mode as IP. I don't think RFC4379 warrants certain default type to be fixed type for = a given FEC. I will also look at this way. When there is no reverse lsp available on = a given node, performing LSP ping with reply mode as reverse lsp is not = considered an issue. Rather it is user who chose wrong reply mode (or = vendor provided wrong default option). LSP ping as such provides option = to chose which reply mode to use.=20 > =20 > >> 2. Details on how this draft will reduce =91false failures=92, = given that every device has to support these new TLV=92s. > =20 > The extension itself is backwards compatible (i.e. adds an optional = TLV), but benefit can obviously be achieved when corresponding LSRs = support the extension. If there are one or more LSRs not supporting this = extension, then it is no worse than today. Then why to introduce new TLV, as it could be solved without it and by = using right reply mode. :D -sam > =20 > Thanks! > =20 > -Nobo > =20 > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Wednesday, August 20, 2014 10:53 PM > To: Ross Callon > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] Poll for Adoption = draft-akiya-mpls-lsp-ping-reply-mode-simple-02 > =20 > Hi Ross, et al, > =20 > I have discussed over the mailing alias why I do not support this = draft in the current form. > > Authors and I could not converge to agreed conclusion. > =20 > Here are things I would like to see in the draft=20 > =20 > 1. Provide an example with specific type of LSP and FEC type where is = useful and also why existing RFC=92s couldn=92t solve it. > 2. Details on how this draft will reduce =91false failures=92, given = that every device has to support these new TLV=92s. > =20 > As it was discussed in detail already over the mailing list, need to = see the benefits for these extensions. > My point is, if problem is solved already with existing mechanisms, = there is no need to solve with different method. We use that argument = many times in the WG/IETF. > But if it is indeed solving something which couldn=92t be solved thus = far (I haven=92t seen it yet), you will have my support. > =20 > cheers > -sam > =20 > On Aug 20, 2014, at 8:20 AM, Ross Callon wrote: >=20 >=20 > This is to start a two week poll on adopting = draft-akiya-mpls-lsp-ping-reply-mode-simple-02 > as an MPLS working group document. > =20 > Please send your comments (support/not support) to the mpls working = group > mailing list (mpls@ietf.org). > =20 > This poll will end Thursday September 4, 2014. > =20 > Thanks, Ross > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_4133A8C1-207E-41ED-939C-75BA3735FB02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Nobo,

Inline for my = comments.

On Aug 21, 2014, at 1:43 PM, Nobo = Akiya (nobo) wrote:

Hi = Sam,
 1. = Provide an example with specific type of LSP and FEC type where is = useful and also why existing RFC=92s couldn=92t solve = it.
The = title of this WG adoption poll may have created some confusion. The = latest version of this document is -03.
Yes, I am looking = at the v03 itself.:D. The appendix doesn't mention which FEC = type.




-sam
 
Hi Ross, et = al,
I have discussed over the = mailing alias why I do not support this draft in the current = form.
 
This poll will end Thursday September 4, = 2014.
Thanks, = Ross
mpls@ietf.org
References: <53F5CA67.9070500@pi.nu> In-Reply-To: <53F5CA67.9070500@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/w_3QX1Gqe8YxMCDvkJHDbrJelHE Cc: Leeyoung , "" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Update: Shepherds for MPLS MIB modules X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 08:57:41 -0000 Working Group, We have now also assigned Young Lee as the Document Shepherd for draft-ietf-mpls-tp-te-mib. /Loa for the mpls wg chairs On 2014-08-21 12:31, Loa Andersson wrote: > Working Group, > > We have for some time been looking for someone to help us shepherding > our MIB modules. I'm happy to announce that Mach Chen and Young Lee has > agreed to help us. > > Please help Mach and Young as they start working with the documents. > > We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id-mib. > > Further shepherd assignments will be done as soon as the details are > sorted out. > > > /Loa > for the mpls wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 22 03:34:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3899E1A00CA for ; Fri, 22 Aug 2014 03:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 PssEXWufMVt3 for ; Fri, 22 Aug 2014 03:34:04 -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 43D491A0092 for ; Fri, 22 Aug 2014 03:34:04 -0700 (PDT) Received: from [192.168.0.101] (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 D17B61802244; Fri, 22 Aug 2014 12:34:02 +0200 (CEST) Message-ID: <53F71C9A.8020308@pi.nu> Date: Fri, 22 Aug 2014 12:34:02 +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: "Nobo Akiya (nobo)" , Ross Callon , "mpls@ietf.org" References: 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/mpls/2C4jrYkkNHL_YXxMzGiWGLI8dyo Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 10:34:07 -0000 Nobo, On 2014-08-21 03:24, Nobo Akiya (nobo) wrote: > Hi Ross, MPLS WG, > > I understand that my "support" as co-authors of this document does not count towards this WG adoption poll, but I'd like to use this opportunity to say that: I think that what wg chairs says that a support mail from co-authors is redundant - co-authors are understood to support adoption of a document simply because they co-authors. However, mail like yours that gives background and arguments are always welcome, authors does not to keep silent in wglc. On the other hand supportive mail that only says "support" is a bit hard to deal with for working group chairs, that is because we are not just counting, we need to know what people think. Mails that only says "+1" are in the same category (or maybe worse). Mails sent to adoption poll should ideally be based on document review and contain some motivation for why there is support or non-support making a document a wg document. /Loa PS I'm also a co-author of this document, and it should be quite obvious that I support making it a wg document. -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 22 04:58:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2F21A0267 for ; Fri, 22 Aug 2014 04:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fJS6DJntLoV for ; Fri, 22 Aug 2014 04:58:11 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E8F1A00EB for ; Fri, 22 Aug 2014 04:58:10 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7MBfcOI025501 for ; Fri, 22 Aug 2014 12:41:38 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7MBfWkY025458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 22 Aug 2014 12:41:33 +0100 From: "Adrian Farrel" To: Date: Fri, 22 Aug 2014 12:58:01 +0100 Message-ID: <010e01cfbe00$54d2eae0$fe78c0a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac++AFGdRxYEp4A6Sa6WeCetrPJBpA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20898.007 X-TM-AS-Result: No--11.626-10.0-31-10 X-imss-scan-details: No--11.626-10.0-31-10 X-TMASE-MatchedRID: dVYa3yVSesToyJCZV0+mCEhEDfw/93BuH181YDtIVarM7zpEspqG/6TY tf9nwiNjbF7poigH+cNw2WXu5+qnAuc4dc7zuu2RT7jCYv2QJPH2kudi1D33ErJ3rmpkUU+TQSG U3Un9hF6Mc6UdzVWBosRab/kqwX/XGAdnzrnkM485f9Xw/xqKXdivpTdmVCR22bNx1HEv7HAqtq 5d3cxkNXOGGVViHtAm7t4H4EOuMXkFYbuHOZKZI/eZBdDLdCZ6duHE81uZSnY= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/M0XxYebyqkSkM3VA_prdax1m84w Subject: [mpls] Discussion of tuning Routing Area working groups X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 11:58:12 -0000 Hi, Just wanted to bring to your attention that there is a discussion on the Routing Discussion mailing list about possible ways to restructure a few of the working groups in the Routing Area. This concerns MPLS as the discussion relates to where to put work concerning TE Architecture and RSVP-TE. You can subscribe to the list and see the message archive at https://www.ietf.org/mailman/listinfo/routing-discussion Please join in if you have an opinion. Thanks, Adrian From nobody Fri Aug 22 05:42:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7181A01E7 for ; Fri, 22 Aug 2014 05:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 U-j-XUNqRX7g for ; Fri, 22 Aug 2014 05:42:36 -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 F2A8F1A01E1 for ; Fri, 22 Aug 2014 05:42:35 -0700 (PDT) Received: from [192.168.0.166] (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 9CA821802244; Fri, 22 Aug 2014 14:42:34 +0200 (CEST) Message-ID: <53F73ABA.6080504@pi.nu> Date: Fri, 22 Aug 2014 14:42:34 +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: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" References: <53D8C464.6040403@pi.nu> In-Reply-To: <53D8C464.6040403@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Dw_wMbm4xWJRVrHRfaSWNhJOhb4 Subject: [mpls] Closed: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 12:42:38 -0000 Working Group, This adoption poll is closed. We have a new working group document. Can the authors please post draft-ietf-mpls-p2mp-loose-path-reopt-00 with no other changes than file, version number and dates as compared to the draft we did poll. /Loa On 2014-07-30 12:09, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group > document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is one IPR claim against this document. > > The authors and contributors has stated on the working group mailing > list that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends August 14, 2014. > > /Loa > > for the MPLS wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 22 07:42:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FE21A0572; Fri, 22 Aug 2014 07:42:25 -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] 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 zYl_NEowNr7c; Fri, 22 Aug 2014 07:42:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EC41A016C; Fri, 22 Aug 2014 07:42:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140822144224.6037.75997.idtracker@ietfa.amsl.com> Date: Fri, 22 Aug 2014 07:42:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/AXnm5cKrj5j6gTiPpZVlzuRf7tA Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-p2mp-loose-path-reopt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 14:42:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Reoptimization of Point-to-Multipoint Traffic Engineering Loosely Routed LSPs Authors : Tarek Saad Rakesh Gandhi Zafar Ali Robert H. Venator Yuji Kamite Filename : draft-ietf-mpls-p2mp-loose-path-reopt-00.txt Pages : 11 Date : 2014-08-22 Abstract: For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Path (LSP), it is preferable in some cases to re-evaluate and re-optimize the entire P2MP-TE LSP by re-signaling all its S2L sub-LSP(s). Existing mechanisms allow the path re-evaluation and the signaling of a the notification of preferred path exists for a single S2L sub-LSP only. This document defines RSVP-TE signaling extensions to allow an ingress Label Switching Router (LSR) of a P2MP-TE LSP to trigger the re-evaluation of the entire LSP tree containing one or more S2L sub- LSPs whose paths are loose (or abstract) hop expanded, and for a mid- point LSR to signal to the ingress LSR that a better tree exists for the entire P2MP-TE LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-loose-path-reopt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-p2mp-loose-path-reopt-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 22 09:43:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DC91A0502; Fri, 22 Aug 2014 09:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 Zt5YcF84Ait9; Fri, 22 Aug 2014 09:43:44 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B893A1A0494; Fri, 22 Aug 2014 09:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3508; q=dns/txt; s=iport; t=1408725823; x=1409935423; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k4XirlTqgm/7qaDH9V9HfgW1+Ui4VulkyZm8zFqScl4=; b=WiP+pK1+71N5kU/BCFx1pn7gmu9kJdtKyt+TB+IH5okYvfN9PA57BypI Qo6AUhAAbkcttJiSOzlKUVAE4eYgCOAY9mtyOpdgCkhA3H9/OeCN209yA Q9b3S5pueXtU0enrSsOWqSQpL6XtgNIMTsibCFSWB1TviTHGZm+xsu3vl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAGpy91OtJV2b/2dsb2JhbABZgmojgSoE1CYBgQ8Wd4QDAQEBBHkMBAIBCBEDAQIvIREdCAEBBAENBRuIEwMRAb81DYUZF4l/gyCBejMHBoRGAQSHSIMehC2CE4kTghCOV4Y1g15sAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208";a="71566752" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 22 Aug 2014 16:43:42 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7MGhgDl031264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 16:43:42 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 11:43:42 -0500 From: "Carlos Pignataro (cpignata)" To: Dhruv Dhody , "Alvaro Retana (aretana)" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogA== Date: Fri, 22 Aug 2014 16:43:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [64.102.157.31] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CZjSgBuDaT35cpY-nyqlu74BK4U Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 16:43:45 -0000 -----Original Message----- From: Dhruv Dhody Date: Thursday, August 21, 2014 at 8:57 PM To: Alvaro Retana Cc: Wes George , "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Resent-From: Resent-To: Carlos Pignataro , Loa Andersson , Martin Vigoureux , Ross Callon , , Wes George , Alia Atlas , Adrian Farrel Resent-Date: Thursday, August 21, 2014 at 8:57 PM >Hi Alvaro, Wes, > >> I fully agree with you: the line for identifying gaps should be based on >> RFCs (not drafts). >> >> [*] The part that I don't agree with is related to this line and the >>last >> couple of sentences of your second point above: "This draft catalogs >>gaps >> with pointers to where the authors know there is already work being >>done, >> which serves to link the two, and ensures that it's as clear as possible >> where there are still outstanding gaps that need to be addressed, and >>it'd >> be reasonable to expect any follow-on documents that address gaps >>identified >> as TBD in this document to formally update this document so that the >>link is >> present between this document and the future documents addressing some >>of >> the gaps that it identified as not having fixes in progress. It's the >>best >> we can do with "frozen in time" documents like this, but I think it's >> acceptable." >> >> Following your logic ("is a gap in a draft really a gap"), I don't think >> that a draft can categorically be referred to as solving a gap. While >>we >> would hope that the draft progresses as expected and that it does >>address >> the gap..it may end up not covering it, being abandoned, moving in a >> different direction, etc. >> >> I understand the reasoning behind pointing at the work in progress. >>This >> discussion is one of those where there might be no ideal answer and we >>both >> might be right (at least in part). I wanted to bring this point up for >>the >> record..and in case anyone has a brilliant solution. We don't need to >>dwell >> on this.. > >How about we move the pointers to any work-in-progress to address the >gaps to appendix, would that be a good compromise? I agree with Alvaro=B9s point that a draft cannot be checked as the solutio= n of a gap. I also believe there is no perfect answer to this one. There is, however, another way in which draft-ietf-mpls-ipv6-only-gap points to I-Ds: As a very detailed description of a Gap. draft-ietf-mpls-ipv6-only-gap might have one paragraph / couple sentences describing a gap, and then point to an I-D that details the gap (and might or might not propose solutions). In this context, there might not be one-size-fit-all for the I-D references. I would not want to loose the consolidated references, but perhaps we need to be more precise about a why we are pointing to each I-D. Pointing as expanding the gap is OK, and maybe moving the =B3solution I-Ds=B2 to an Appendix is a good idea. Thanks, Carlos. > >Dhruv From nobody Fri Aug 22 10:06:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982091A069B; Fri, 22 Aug 2014 10:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC9W5vMogSAR; Fri, 22 Aug 2014 10:06:33 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 53F801A069A; Fri, 22 Aug 2014 10:06:33 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,382,1406606400"; d="scan'208";a="469878716" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Aug 2014 13:06:03 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 22 Aug 2014 13:06:32 -0400 From: "George, Wes" To: "Carlos Pignataro (cpignata)" , Dhruv Dhody , "Alvaro Retana (aretana)" Date: Fri, 22 Aug 2014 13:06:30 -0400 Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac++K2wFX3CjzDF/Sz68mP/z2ElwOg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 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/mpls/PqO3XF0pYfwD83gSvX422ksTE1E Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:06:34 -0000 DQo+PkhvdyBhYm91dCB3ZSBtb3ZlIHRoZSBwb2ludGVycyB0byBhbnkgd29yay1pbi1wcm9ncmVz cyB0byBhZGRyZXNzIHRoZQ0KPj5nYXBzIHRvIGFwcGVuZGl4LCB3b3VsZCB0aGF0IGJlIGEgZ29v ZCBjb21wcm9taXNlPw0KPg0KPkkgd291bGQgbm90IHdhbnQgdG8gbG9vc2UgdGhlIGNvbnNvbGlk YXRlZCByZWZlcmVuY2VzLCBidXQgcGVyaGFwcyB3ZSBuZWVkDQo+dG8gYmUgbW9yZSBwcmVjaXNl IGFib3V0IGEgd2h5IHdlIGFyZSBwb2ludGluZyB0byBlYWNoIEktRC4gUG9pbnRpbmcgYXMNCj5l eHBhbmRpbmcgdGhlIGdhcCBpcyBPSywgYW5kIG1heWJlIG1vdmluZyB0aGUgwrNzb2x1dGlvbiBJ LURzwrIgdG8gYW4NCj5BcHBlbmRpeCBpcyBhIGdvb2QgaWRlYS4NCg0KSSdtIG5vdCBjb252aW5j ZWQgdGhhdCBtdWNoIHdpbGwgYmUgZ2FpbmVkIGJ5IHN1Y2ggYSBjaGFuZ2UuIEl0IHNlZW1zIGxp a2UNCmNoYW5nZSBmb3IgdGhlIHNha2Ugb2YgY2hhbmdlLiBJIHdpbGwgZ28gYWxvbmcgd2l0aCBp dCBpZiBXRyBjb25zZW5zdXMNCnB1c2hlcyB0aGF0IGRpcmVjdGlvbiwgYnV0IG15IHByZWZlcmVu Y2Ugd291bGQgYmUgdG8gbGVhdmUgdGhlIHJlZmVyZW5jZXMNCmFzLWlzLiBJZiB3ZSBrbm93IHNv bWV0aGluZyBpcyBpbiBwcm9ncmVzcyB0aGF0IGlzIHRyeWluZyB0byBhZGRyZXNzIHRoZQ0KcHJv YmxlbSwgd2h5IG5vdCBkb2N1bWVudCB3aGF0IHdlIGtub3cgaW4gdGhlIHNhbWUgcGxhY2VzIGFz IHdlIGRpc2N1c3MNCnRoZSBnYXBzPyBXaGF0IHZhbHVlIGlzIHRoZXJlIGluIGhpZGluZyB0aGVz ZSB0aGluZ3MgaW4gYW4gYXBwZW5kaXgganVzdA0KYmVjYXVzZSB3ZSBhcmVuJ3QgY29tcGxldGVs eSBjZXJ0YWluIHRoYXQgd2hhdCB3ZSBiZWxpZXZlIHdpbGwgYWRkcmVzcyB0aGUNCmdhcCB3aWxs IGFjdHVhbGx5IGFkZHJlc3MgdGhlIGdhcD8NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQpBbnl0aGlu ZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBz ZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQoNClRo aXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2Fy bmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBj b25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdh cm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29w eWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQg YXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxl dGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50 b3V0Lg0K From nobody Fri Aug 22 10:14:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065751A0693; Fri, 22 Aug 2014 10:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 bBozvzBS3_Tj; Fri, 22 Aug 2014 10:14:29 -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 655471A069E; Fri, 22 Aug 2014 10:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3770; q=dns/txt; s=iport; t=1408727670; x=1409937270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yp1MEH28LENClKIlK40N5x8shm7TIw6s3j7SIhjzaOE=; b=a/P1gSR6Fgl5iUA9qaGE9+ZDDI/IXv71h1ktATi24Zp/QFSjPqBfG2vb zlK96EgvVo8kuxJtO5T1a22G1fY3nUR9rMwarb3AjC3Z7jck/6CXYgIgw fzED2PnSbMc9gbyKn4AUCk1DdPXvDsAa4EXrYjIoBZJ8ZCMeU+YvEWxDF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAOh591OtJV2S/2dsb2JhbABZgmojgSoEgnjRLgEZdhZ3hAMBAQEENDgGBwwEAgEIEQMBAgUoAgIfER0IAQEEAQ0FG4gTAxEBkxKcNQaPcA2FGReBJot5gVwBARwIKwcCAgKCbYFZAQSGEYkCghOJE4IQjleGNYNebAGBDjmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208";a="71576577" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP; 22 Aug 2014 17:14:30 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7MHESTv027459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 17:14:28 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 12:14:28 -0500 From: "Carlos Pignataro (cpignata)" To: "George, Wes" , Dhruv Dhody , "Alvaro Retana (aretana)" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogAAJK2EA//+/PAA= Date: Fri, 22 Aug 2014 17:14:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [64.102.157.31] Content-Type: text/plain; charset="euc-kr" Content-ID: <22B90EF4592D864EB100537A9ED97E51@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/fBt2R8MJQcupOF_gQtE3K9HKbsw Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:14:31 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiA8R2VvcmdlPiwgV2VzIEdlb3Jn ZSA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT4NCkRhdGU6IEZyaWRheSwgQXVndXN0IDIyLCAy MDE0IGF0IDE6MDYgUE0NClRvOiBDYXJsb3MgUGlnbmF0YXJvIDxjcGlnbmF0YUBjaXNjby5jb20+ LCBEaHJ1diBEaG9keQ0KPGRocnV2LmlldGZAZ21haWwuY29tPiwgQWx2YXJvIFJldGFuYSA8YXJl dGFuYUBjaXNjby5jb20+DQpDYzogInJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmciIDxydGctYWRzQHRv b2xzLmlldGYub3JnPiwgInJ0Zy1kaXJAaWV0Zi5vcmciDQo8cnRnLWRpckBpZXRmLm9yZz4sICJk cmFmdC1pZXRmLW1wbHMtaXB2Ni1vbmx5LWdhcC5hbGxAdG9vbHMuaWV0Zi5vcmciDQo8ZHJhZnQt aWV0Zi1tcGxzLWlwdjYtb25seS1nYXAuYWxsQHRvb2xzLmlldGYub3JnPiwgIm1wbHNAaWV0Zi5v cmciDQo8bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbXBsc10gUnRnRGlyIHJldmlldzog ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAtMDENCg0KPg0KPj4+SG93IGFib3V0IHdlIG1v dmUgdGhlIHBvaW50ZXJzIHRvIGFueSB3b3JrLWluLXByb2dyZXNzIHRvIGFkZHJlc3MgdGhlDQo+ Pj5nYXBzIHRvIGFwcGVuZGl4LCB3b3VsZCB0aGF0IGJlIGEgZ29vZCBjb21wcm9taXNlPw0KPj4N Cj4+SSB3b3VsZCBub3Qgd2FudCB0byBsb29zZSB0aGUgY29uc29saWRhdGVkIHJlZmVyZW5jZXMs IGJ1dCBwZXJoYXBzIHdlDQo+Pm5lZWQNCj4+dG8gYmUgbW9yZSBwcmVjaXNlIGFib3V0IGEgd2h5 IHdlIGFyZSBwb2ludGluZyB0byBlYWNoIEktRC4gUG9pbnRpbmcgYXMNCj4+ZXhwYW5kaW5nIHRo ZSBnYXAgaXMgT0ssIGFuZCBtYXliZSBtb3ZpbmcgdGhlIKn4c29sdXRpb24gSS1Ec6n3IHRvIGFu DQo+PkFwcGVuZGl4IGlzIGEgZ29vZCBpZGVhLg0KPg0KPkknbSBub3QgY29udmluY2VkIHRoYXQg bXVjaCB3aWxsIGJlIGdhaW5lZCBieSBzdWNoIGEgY2hhbmdlLiBJdCBzZWVtcyBsaWtlDQo+Y2hh bmdlIGZvciB0aGUgc2FrZSBvZiBjaGFuZ2UuIEkgd2lsbCBnbyBhbG9uZyB3aXRoIGl0IGlmIFdH IGNvbnNlbnN1cw0KPnB1c2hlcyB0aGF0IGRpcmVjdGlvbiwgYnV0IG15IHByZWZlcmVuY2Ugd291 bGQgYmUgdG8gbGVhdmUgdGhlIHJlZmVyZW5jZXMNCj5hcy1pcy4gSWYgd2Uga25vdyBzb21ldGhp bmcgaXMgaW4gcHJvZ3Jlc3MgdGhhdCBpcyB0cnlpbmcgdG8gYWRkcmVzcyB0aGUNCj5wcm9ibGVt LCB3aHkgbm90IGRvY3VtZW50IHdoYXQgd2Uga25vdyBpbiB0aGUgc2FtZSBwbGFjZXMgYXMgd2Ug ZGlzY3Vzcw0KPnRoZSBnYXBzPyBXaGF0IHZhbHVlIGlzIHRoZXJlIGluIGhpZGluZyB0aGVzZSB0 aGluZ3MgaW4gYW4gYXBwZW5kaXgganVzdA0KPmJlY2F1c2Ugd2UgYXJlbid0IGNvbXBsZXRlbHkg Y2VydGFpbiB0aGF0IHdoYXQgd2UgYmVsaWV2ZSB3aWxsIGFkZHJlc3MgdGhlDQo+Z2FwIHdpbGwg YWN0dWFsbHkgYWRkcmVzcyB0aGUgZ2FwPw0KDQpQZXJzb25hbGx5IEkgZG8gbm90IGhhdmUgYSBw YXJ0aWN1bGFyIHByZWZlcmVuY2UgYmV0d2VlbiBsZWF2aW5nIGNpdGF0aW9ucw0KdG8gSS1EcyB3 aGVyZSB0aGV5IGFyZSBvciBtb3ZpbmcgdGhlbSAoYXMgY28tZWRpdG9yIEkgcHJlZmVyIGxlYXZp bmcgdGhlbQ0Kd2hlcmUgdGhleSBhcmUgOi0pDQoNCkJ1dCB0aGUgcG9pbnQgSSB0aGluayBpcyBp bXBvcnRhbnQgdG8gY2xhcmlmeSBpbiB0aGUgZG9jdW1lbnQgaXMgd2hldGhlciBhDQpkcmFmdCBp cyByZWZlcmVuY2VkIGJlY2F1c2UgaXQgZGVzY3JpYmVzIGEgZ2FwIG9yIGJlY2F1c2UgaXQgZGVz Y3JpYmVzIGENCnBvdGVudGlhbCBzb2x1dGlvbiB0byBhIGdhcC4NCg0KVGhhbmtzLA0KDQpDYXJs b3MuDQoNCj4NCj5UaGFua3MsDQo+DQo+V2VzDQo+DQo+DQo+QW55dGhpbmcgYmVsb3cgdGhpcyBs aW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnmhr3MgbWFpbCBzZXJ2ZXIsIEkNCj5oYXZl IG5vIGNvbnRyb2wgb3ZlciBpdC4NCj4tLS0tLS0tLS0tLQ0KPg0KPg0KPg0KPlRoaXMgRS1tYWls IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxl DQo+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVu dGlhbCwgb3Igc3ViamVjdCB0bw0KPmNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIg Q2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KPmZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdQ0K PmFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQNCj50aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNv cHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbg0KPnJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBh bmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkNCj5wcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluDQo+ ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50 bHkgZGVsZXRlIHRoZQ0KPm9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQg YW55IHByaW50b3V0Lg0KDQo= From nobody Fri Aug 22 10:34:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A93A1A06DF; Fri, 22 Aug 2014 10:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWoCRTagRwkK; Fri, 22 Aug 2014 10:34:52 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E73B1A0702; Fri, 22 Aug 2014 10:34:52 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h3so1492248igd.5 for ; Fri, 22 Aug 2014 10:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kpeAM8YOuevG9OamOFLF7sBGiPKLvL5ai7XBXo613Vo=; b=Qk1DTdI8mht+oKgpmARE1ovScpx/1Au1kX1fJDNS5Sq8cdjNHp+Jf9mQaY2rvH9hOk ZV+QD4ipApF/U83pniF4f+E1xmyrZmVMACErNHWdZZuE/G9Ai3iUkjc3KUCWRwB3+8cQ fW009jh8KvsX2CcpIoMDxE+xgHEX8FYA7z4Hn38cbIN9T5QTOzQwkAO3ENbks4awRel3 p8epo4Lqo8nKQmiLWZsIIAgeqAr0XzGyO9WO/zGl8u4qOC+F4q+B7GNlc3UEuBJ+rob0 NsILp+rYcNL++6NsO9SnNmJndtlMeY4Lshv3Q8Ir6TiumBUBDnY410+eGp/mTjiTPXWJ Rb0Q== MIME-Version: 1.0 X-Received: by 10.50.111.167 with SMTP id ij7mr28213182igb.49.1408728891810; Fri, 22 Aug 2014 10:34:51 -0700 (PDT) Received: by 10.50.189.170 with HTTP; Fri, 22 Aug 2014 10:34:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Aug 2014 23:04:51 +0530 Message-ID: From: Dhruv Dhody To: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/z8cHDqO3lhXgfvEttS05dCdW7EQ Cc: "mpls@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "Alvaro Retana \(aretana\)" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:34:55 -0000 > -----Original Message----- > From: , Wes George > Date: Friday, August 22, 2014 at 1:06 PM > To: Carlos Pignataro , Dhruv Dhody > , Alvaro Retana > Cc: "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" > , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" > , "mpls@ietf.org" > > Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 > >> >>>>How about we move the pointers to any work-in-progress to address the >>>>gaps to appendix, would that be a good compromise? >>> >>>I would not want to loose the consolidated references, but perhaps we >>>need >>>to be more precise about a why we are pointing to each I-D. Pointing as >>>expanding the gap is OK, and maybe moving the =C2=B3solution I-Ds=C2=B2 = to an >>>Appendix is a good idea. >> >>I'm not convinced that much will be gained by such a change. It seems lik= e >>change for the sake of change. I will go along with it if WG consensus >>pushes that direction, but my preference would be to leave the references >>as-is. If we know something is in progress that is trying to address the >>problem, why not document what we know in the same places as we discuss >>the gaps? What value is there in hiding these things in an appendix just >>because we aren't completely certain that what we believe will address th= e >>gap will actually address the gap? > > Personally I do not have a particular preference between leaving citation= s > to I-Ds where they are or moving them (as co-editor I prefer leaving them > where they are :-) > > But the point I think is important to clarify in the document is whether = a > draft is referenced because it describes a gap or because it describes a > potential solution to a gap. > > Thanks, > > Carlos. I agree that the clarification as Carlos suggested would help. When I suggested moving the pointers-to-solutions to appendix, my thoughts was - since we do not have consensus on the solutions yet; we could explicitly state that the aim of the pointers in this appendix is to let the reader note that there are some proposed solutions in IETF, but they are work in progress and do not have consensus at the time of publication. There could be other solutions proposed at future time and the pointers should not be considered normative in any way. And a suitable text can be added for this. Change for the sake of change was not my intention :) Dhruv From nobody Fri Aug 22 11:48:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6F21A040B; Fri, 22 Aug 2014 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 pX32SN0UVwNP; Fri, 22 Aug 2014 11:48:37 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457E21A03C8; Fri, 22 Aug 2014 11:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=785; q=dns/txt; s=iport; t=1408733317; x=1409942917; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q/9c7HwOn5rrvj4XyA/cScvpB6lTu1T2Fj7Fp46d7Aw=; b=cR9UUs9oB+WYWK1QIK7L/ulOlw1cqS08Klf8yX6zosVWEHyYhfFso3X7 Nlsn/RKZFjK6DCdDUlk5vtf9H23U/FMMA/2K6fn5FGxCVHzIQyt2mcg2o VRC6YuDPlt8yQTomrCJ4jIu2sv+vsFvq8ftTRcSyK3YSa1FDVR76/reXt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFANGP91OtJA2K/2dsb2JhbABZgw2BKgTUJgGBEBZ3hAQBAQQ6PxACAQg2ECERJQIEAQ0FG4gTAxG/WQ2FGReNH4ItB4RMAQSPE4ITiROCEI5XhjWDXmyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208";a="71602794" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 22 Aug 2014 18:48:36 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7MImaBJ016067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 18:48:36 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.181]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 13:48:36 -0500 From: "Alvaro Retana (aretana)" To: Dhruv Dhody , "Carlos Pignataro (cpignata)" , "George, Wes" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogAAJK2EA//+/PACAAEivgP//0YgA Date: Fri, 22 Aug 2014 18:48:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C4C96189218D7419FFE86ACD9AE3776@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RV5YY2Se-i7A9LgbsVAGB3CHYOg Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 18:48:39 -0000 On 8/22/14 1:34 PM, "Dhruv Dhody" wrote: >we could explicitly state that the aim of the pointers in this >appendix is to let the reader note that there are some proposed >solutions in IETF, but they are work in progress and do not have >consensus at the time of publication. There could be other solutions >proposed at future time and the pointers should not be considered >normative in any way. Maybe we could make everyone happy if we add some "disclaimer" text (similar to what Dhruv wrote above). I'm thinking that it could go in Section 4 (Gap Summary) (no need for an appendix). This way we don't have to change the text anymore..we can leave the references as-is..and we address any potential mishap to the WIP. Thoughts? Alvaro. From nobody Fri Aug 22 11:51:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7B01A0AD7; Fri, 22 Aug 2014 11:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 3Q6U1koDG8Ze; Fri, 22 Aug 2014 11:50:57 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178911A0AD2; Fri, 22 Aug 2014 11:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=531; q=dns/txt; s=iport; t=1408733458; x=1409943058; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+UQ/gVMB1+KAe7s93/sf7QcTrUw4GOD6E73w+vXovFw=; b=Yq4T1E5j6p0J8vqg72/zTq0upbH61WFaBi63ZGe9G2nBD4fTzdjgjZoN m95iuV22+vzWhRbZbbIn/7IvXlEQoDfKbN0nsCywJu/uR53FfSj2xCTE/ NdKaEHNht2nSS+7HWzYg1reLZ7tVggxnwlPZpjKFfNh6m9p3UU6JBynXy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAGmQ91OtJA2G/2dsb2JhbABZgw2BLtQmAYEQFneEBAEBBDo/EAIBCDYQMiUCBA6IR8UBF49MB4RMAQSPE4ITiyOVDINegjSBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208";a="71600730" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 22 Aug 2014 18:50:58 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7MIouKK020334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 18:50:56 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.181]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 13:50:56 -0500 From: "Alvaro Retana (aretana)" To: "Carlos Pignataro (cpignata)" , "George, Wes" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogAAJK2EA//+/PACAABrfgA== Date: Fri, 22 Aug 2014 18:50:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <1ECCA331166C3D4F9E0C72EAB08D4835@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/U_LRjYBksaz2jg3JKREJfeRvc_k Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 18:50:58 -0000 Carlos/Wes: BTW, as I was taking another look at the -01 text (I know you have edits ready to commit), there's a couple more minor comments related to the references: 1. 3.2.1. (LDP) "Gap: Major, update to RFC 5036 in progress that should close this gap." The in-line reference points to rfc5036, but it should point to I-D.ietf-mpls-ldp-ipv6. 2. 3.5. (MIBs) "Gap: Major. Work underway to update RFC3811.." Same thing, the reference to the update should point to I-D.manral-mpls-rfc3811bis. Thanks! Alvaro. From nobody Fri Aug 22 12:41:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8721A061D; Fri, 22 Aug 2014 12:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 Qt4KJP8c9YYD; Fri, 22 Aug 2014 12:41:13 -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 66B981A058E; Fri, 22 Aug 2014 12:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1387; q=dns/txt; s=iport; t=1408736473; x=1409946073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CW4M5oPv5ijrCzERn0VLc3zaf4XySgC4jFedEKb0YVo=; b=ls1SLHUCAiut96D/dNo/T2pZqAik56BO9qu2Q6pI5MRoOfkaRXrUzj8x HOyD/8ZPsSsekOUmSlQXVG1qi+90J/hpAOxHwKYHiOOmB+r1ZabLNXFIm 1heRBHVR3Zb2l13fpLRmc65TGNTWUGxsYmD6dPuo6m+Qip4CGbJyReYvr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAP2b91OtJA2E/2dsb2JhbABZgmojgSoE1CcBgRAWd4QDAQEBBDo/DAQCAQgRAwECAR4QIREdCAIEAQ0FG4gTAxEBv1cNhRkXjR+CLQcGhEYBBI8TghOJE4IQjleGNYNebAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,383,1406592000"; d="scan'208";a="71610336" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP; 22 Aug 2014 19:41:12 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7MJfCwg007047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 19:41:12 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 14:41:12 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" , Dhruv Dhody , "George, Wes" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogAAJK2EA//+/PACAAEivgP//0YgAgAAOyAA= Date: Fri, 22 Aug 2014 19:41:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [64.102.157.31] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gx9b62imAw0XAw5FjFBhLxmEL2Y Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:41:15 -0000 -----Original Message----- From: Alvaro Retana Date: Friday, August 22, 2014 at 2:48 PM To: Dhruv Dhody , Carlos Pignataro , Wes George Cc: "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 >On 8/22/14 1:34 PM, "Dhruv Dhody" wrote: > >>we could explicitly state that the aim of the pointers in this >>appendix is to let the reader note that there are some proposed >>solutions in IETF, but they are work in progress and do not have >>consensus at the time of publication. There could be other solutions >>proposed at future time and the pointers should not be considered >>normative in any way. > >Maybe we could make everyone happy if we add some "disclaimer" text >(similar to what Dhruv wrote above). I'm thinking that it could go in >Section 4 (Gap Summary) (no need for an appendix). > >This way we don't have to change the text anymore..we can leave the >references as-is..and we address any potential mishap to the WIP. > >Thoughts? Works for me. Thanks, Carlos. > >Alvaro. > From nobody Fri Aug 22 13:34:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7141A6F6D for ; Fri, 22 Aug 2014 13:34:55 -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 frzZG59ERFWD for ; Fri, 22 Aug 2014 13:34:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998351A6F60 for ; Fri, 22 Aug 2014 13:34:51 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 22 Aug 2014 20:34:49 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.1010.016; Fri, 22 Aug 2014 20:34:49 +0000 From: Ross Callon To: "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" Thread-Topic: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) Thread-Index: AQHPtkRaMKTAIUispESn+VQ9zL0YXJvXjyCAgAWRXuA= Date: Fri, 22 Aug 2014 20:34:49 +0000 Message-ID: <9ace61def77942938bc577e4b6782680@CO2PR05MB636.namprd05.prod.outlook.com> References: <53EA3666.2040004@pi.nu> <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(164054003)(252514010)(199003)(13464003)(377454003)(51704005)(87936001)(33646002)(15202345003)(106356001)(19580405001)(74316001)(107046002)(81342001)(64706001)(101416001)(106116001)(80022001)(76482001)(31966008)(99396002)(90102001)(50986999)(83322001)(54356999)(74502001)(74662001)(108616004)(81542001)(105586002)(46102001)(76576001)(92566001)(2656002)(19580395003)(76176999)(95666004)(83072002)(20776003)(85306004)(79102001)(4396001)(86362001)(99286002)(85852003)(15975445006)(77982001)(66066001)(230783001)(21056001)(2501001)(43043002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.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/mpls/nyTCT1oh7q5cUlmu1rNu0yecgss Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:34:55 -0000 > The proposed solution is to have implementations complying to this draft > advertise the IPv6 prefix state advertisement control capability > (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization message > explicitly indicating support for LDP IPv6. Without the peer advertising > this capability, an LSR must not send IPv6 addresses and FECs to that pee= r. Speaking as an individual contributor, this seems IMHO to be the right solu= tion (noting that, in final text as would be published in an RFC, the "must= not" in the last sentence should be capitalized).=20 Thanks, Ross -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (= Mustapha) Sent: Tuesday, August 19, 2014 3:19 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-ipv6@tools.ietf.org Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc cl= osed) Dear all, The following are the details of the issue we found and the proposed soluti= on. We shared this first with the authors to get initial feedback. When an LSR which supports LDP IPv6 according to this draft is in a LAN wit= h a broadcast interface, it can peer with LSRs which support this draft and= LSRs which do not. When it peers using IPv4 LDP control plane with an LSR = which does not support this draft, we have seen during our testing an issue= that the advertisement of IPv6 addresses or IPv6 FECs to that peer will ca= use it to bring down the IPv4 LDP session. In other words, there are deployed LDP implementations which are compliant = to RFC 5036 for LDP IPv4 but are not compliant to RFC 5036 when it comes to= handling IPv6 address or IPv6 FECs over an LDP IPv4 session. This is makin= g us very concerned that when users enable dual-stack LDP IPv4/IPv6, they w= ill bring down LDP IPv4 sessions which have been working in a multi-vendor = environments for so many years. The proposed solution is to have implementations complying to this draft ad= vertise the IPv6 prefix state advertisement control capability (draft-ietf-= mpls-ldp-ip-pw-capability-07) in the initialization message explicitly indi= cating support for LDP IPv6. Without the peer advertising this capability, = an LSR must not send IPv6 addresses and FECs to that peer.=20 This approach is safer and has been followed when mLDP FEC was introduced a= s explained in Section 2.1 of RFC 6388. Also, this does not introduce any n= ew TLV to draft-ietf-mpls-ldp-ipv6. It just makes the exchange of LDP IPv6 = addresses and FECs conditional to both peers explicitly indicating support = for IPv6 capability during LDP session initialization.=20 We do not feel such a simple change justifies writing a new draft and havin= g to deal with backward compatibility of implementations across two drafts.= =20 We appreciate your comments on this matter. Regards, Mustapha. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, August 12, 2014 11:45 AM=09 > To: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-ipv6@t= ools.ietf.org > Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc clos= ed) >=20 > Working Group, >=20 > During what we thought would be a short wglc on draft-ietf-mpls-ldp-ipv6 > http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html > we had a comment that stopped us from continuing progressing the draft. >=20 > The short working group last call is now closed! >=20 > The comment we refer to was raised in a private mail to the working group= chairs > and the draft authors. >=20 > It says that there are a problem with some RFC 5036 non-compliant > implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no detail= ed > description of the exact problems. >=20 > We strongly encourage the people that made the comment(s) to write-up the > problem, either as >=20 > - a new draft (preferred); or > - in a mail to the working group mailing list >=20 > Once we an agreement to write a new draft or the write-up to the mailing,= we will > continue to ask the working group to see if we can agree to a way to prog= ress. We > like to see this write-up before September 1. Failing this we will contin= ue to progress > the draft-ietf-mpls-ldp-ipv6 as is. >=20 > /Loa > for the working group chairs > -- >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Aug 24 07:08:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC01A01F9 for ; Sun, 24 Aug 2014 07:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.168 X-Spam-Level: X-Spam-Status: No, score=-115.168 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_bsMsd1x-Si for ; Sun, 24 Aug 2014 07:08:38 -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 8AD141A016A for ; Sun, 24 Aug 2014 07:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27644; q=dns/txt; s=iport; t=1408889318; x=1410098918; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LEGFErgrqceJfFKL4h59p+Ie9pbtI2QnJ/p1GYiB2fM=; b=iig8qjf4GdmXCRoHRT9RDnoURMpxnSZqKszL2JJi8My8CnaWDRB+0MBY 8ORcOYURAeeMULaZHbKhkjI6kEteOH24HC2pVeYu+vvM+KFRaJtwv9U9v KTtFXTzreuSN7sdMwiR2bd9qxgHuGmzDiDYImRcIRCOmtI6gAW52imowA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAJfx+VOtJV2Z/2dsb2JhbABZgkcjI1NXBMpdgVkBC4dLAYEIFneEAwEBAQMBAQEBKkELEAIBCBEEAQELFgcHIQYLFAkIAgQOBQgBiCUDCQgBDLxIDYUiF4l/gyCBXAEBHi0EBgGDL4EdBY8TghOEKYRqg2iMf4Y1g15sAYEOOYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,390,1406592000"; d="scan'208,217";a="349955322" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 24 Aug 2014 14:08:36 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7OE8aHH002140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Aug 2014 14:08:36 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Sun, 24 Aug 2014 09:08:36 -0500 From: "Nobo Akiya (nobo)" To: "Sam K. Aldrin" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPvOshzBnSrGC81kW4l9uZaVVid5vbhNJwgACkx4CAA6BtIA== Date: Sun, 24 Aug 2014 14:08:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.212] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943A3B7735xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/YW0HamTt3PXmoOdxadGDAciEp3M Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 14:08:42 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943A3B7735xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, Please see in-line with [NOBO]. From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Thursday, August 21, 2014 9:24 PM To: Nobo Akiya (nobo) Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-= simple-02 Hi Nobo, Inline for my comments. On Aug 21, 2014, at 1:43 PM, Nobo Akiya (nobo) wrote: Hi Sam, >> 1. Provide an example with specific type of LSP and FEC type where is us= eful and also why existing RFC's couldn't solve it. The title of this WG adoption poll may have created some confusion. The lat= est version of this document is -03. http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-03 The latest version has Appendix A which was added as result of your comment= s. Yes, I am looking at the v03 itself.:D. The appendix doesn't mention which = FEC type. The only FEC type this extension will be helpful is MPLS TP with IP availab= le on every node. There are no other LSP's or FEC types which fits this scenario. Do they? [NOBO] MPLS TP and associated RSVP-TE for sure. The reason why Appendix A i= s generally described is that we will likely have more LSPs down the road. = One example will be associated SPRING LSPs where only the end-points have t= he state for the reverse LSP. Let us take the MPLS TP with IP on every node. The scenario you are talking about is 'associated bidirectional' tunnel. Just because a 'vendor' implemented certain default method doesn't require = new TLV support. For associated bidirectional tunnel with IP on every node, perform reply mo= de as IP. I don't think RFC4379 warrants certain default type to be fixed type for a = given FEC. [NOBO] What you say is true only if all operators prefer IP return path ove= r control channel and reverse LSP. I am aware of operators who wants to pre= fer control channel or reverse LSP whenever available, over IP path. The pr= eference really varies depending on operators. This is exactly where this e= xtension can benefit. I will also look at this way. When there is no reverse lsp available on a g= iven node, performing LSP ping with reply mode as reverse lsp is not consid= ered an issue. Rather it is user who chose wrong reply mode (or vendor prov= ided wrong default option). LSP ping as such provides option to chose which= reply mode to use. [NOBO] Ping is much simpler than traceroute. Take a look at Appendix A.1. I= n normal conditions, traceroute will work just fine with Reply Mode control= channel or reverse LSP, except when there's an error. Then there will be a= timeout and user/application will have to debug/re-try. If the extension d= escribed in this document was there, there is no timeout and user/applicati= on can immediately know where the breakage is. >> 2. Details on how this draft will reduce 'false failures', given that ev= ery device has to support these new TLV's. The extension itself is backwards compatible (i.e. adds an optional TLV), b= ut benefit can obviously be achieved when corresponding LSRs support the ex= tension. If there are one or more LSRs not supporting this extension, then = it is no worse than today. Then why to introduce new TLV, as it could be solved without it and by usin= g right reply mode. :D [NOBO] It is ideal to design a diagnostic tool to not have "timeout" but ra= ther get the response with a diagnostic reason. LSP Ping/Traceroute is a gr= eat diagnostic tool, but we are not using it enough IMHO. I, for one, think= network monitoring can significantly benefit if we have an application tha= t uses LSP Ping/Trace along with other OAM tools. And ever better if "timeo= ut" (of seconds) can be avoided. Despite the fact that we are still going on a parallel path, I do still app= reciate you reviewing the document ... your comments have helped this docum= ent into much better shape. Thanks! -Nobo -sam Thanks! -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Wednesday, August 20, 2014 10:53 PM To: Ross Callon Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-= simple-02 Hi Ross, et al, I have discussed over the mailing alias why I do not support this draft in = the current form. Authors and I could not converge to agreed conclusion. Here are things I would like to see in the draft 1. Provide an example with specific type of LSP and FEC type where is usefu= l and also why existing RFC's couldn't solve it. 2. Details on how this draft will reduce 'false failures', given that every= device has to support these new TLV's. As it was discussed in detail already over the mailing list, need to see th= e benefits for these extensions. My point is, if problem is solved already with existing mechanisms, there i= s no need to solve with different method. We use that argument many times i= n the WG/IETF. But if it is indeed solving something which couldn't be solved thus far (I = haven't seen it yet), you will have my support. cheers -sam On Aug 20, 2014, at 8:20 AM, Ross Callon > wrote: This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_CECE764681BE964CBE1DFF78F3CDD3943A3B7735xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sam,=

 <= /p>

Please see in-line with [= NOBO].

 <= /p>

From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com]
Sent: Thursday, August 21, 2014 9:24 PM
To: Nobo Akiya (nobo)
Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02

 

Hi Nobo,

 

Inline for my comments.

 

The only FEC type this extension will be helpful is = MPLS TP with IP available on every node.

There are no other LSP's or FEC types which fits thi= s scenario. Do they?

 

[NOBO] MPLS TP and associ= ated RSVP-TE for sure. The reason why Appendix A is generally described is = that we will likely have more LSPs down the road. One example will be associated SPRING LSPs where only the end-points have the state fo= r the reverse LSP.

 <= /p>

Let us take the MPLS TP with IP on every node.<= /o:p>

The scenario you are talking about is 'associated bi= directional' tunnel.

Just because a 'vendor' implemented certain default = method doesn't require new TLV support.

For associated bidirectional tunnel with IP on every= node, perform reply mode as IP.

I don't think RFC4379 warrants certain default type = to be fixed type for a given FEC.

 

[NOBO] What you say is tr= ue only if all operators prefer IP return path over control channel and rev= erse LSP. I am aware of operators who wants to prefer control channel or reverse LSP whenever available, over IP path. The preference re= ally varies depending on operators. This is exactly where this extension ca= n benefit.

 <= /p>

I will also look at this way. When there is no rever= se lsp available on a given node, performing LSP ping with reply mode as re= verse lsp is not considered an issue. Rather it is user who chose wrong rep= ly mode (or vendor provided wrong default option). LSP ping as such provides option to chose which reply mod= e to use. 

 <= /p>

[NOBO] Ping is much simpl= er than traceroute. Take a look at Appendix A.1. In normal conditions, trac= eroute will work just fine with Reply Mode control channel or reverse LSP, except when there’s an error. Then there will be a t= imeout and user/application will have to debug/re-try. If the extension des= cribed in this document was there, there is no timeout and user/application= can immediately know where the breakage is.

 

 <= /p>

>> 2. Details on how this draft will = reduce ‘false failures’, given that every device has to support= these new TLV’s.

 <= /p>

The extension itself is b= ackwards compatible (i.e. adds an optional TLV), but benefit can obviously = be achieved when corresponding LSRs support the extension. If there are one or more LSRs not supporting this extension, then it is no= worse than today.

Then why to introduce new TLV, as it could be solved= without it and by using right reply mode. :D

 

[NOBO] It is ideal to des= ign a diagnostic tool to not have “timeout” but rather get the = response with a diagnostic reason. LSP Ping/Traceroute is a great diagnosti= c tool, but we are not using it enough IMHO. I, for one, think network monit= oring can significantly benefit if we have an application that uses LSP Pin= g/Trace along with other OAM tools. And ever better if “timeout”= ; (of seconds) can be avoided.

 <= /p>

Despite the fact that we = are still going on a parallel path, I do still appreciate you reviewing the= document … your comments have helped this document into much better shape.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

-sam

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org= ] On Behalf Of Sam Aldrin
Sent: Wednesday, A= ugust 20, 2014 10:53 PM
To: Ross Callon Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls= ] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

 

Hi Ross, et al,

 

I have discussed over the mailing alias why I do not= support this draft in the current form.

Authors and I could not converge to agreed conclusio= n.

 

Here are things I would like to see in the draft&nbs= p;

 

1. Provide an example with specific type of LSP and = FEC type where is useful and also why existing RFC’s couldn’t s= olve it.

2. Details on how this draft will reduce ‘fals= e failures’, given that every device has to support these new TLVR= 17;s.

 

As it was discussed in detail already over the maili= ng list, need to see the benefits for these extensions.

My point is, if problem is solved already with exist= ing mechanisms, there is no need to solve with different method. We use tha= t argument many times in the WG/IETF.

But if it is indeed solving something which couldn&#= 8217;t be solved thus far (I haven’t seen it yet), you will have my s= upport.

 

cheers

-sam

 

On Aug 20, 2014, at 8:20 AM, Ross Callon <rcallon@juniper.net> wrote:




This is to start a two week poll on ado= pting draft-akiya-mpls-lsp-ping-reply-mode-simple-02

as an MPLS working group document.

 

Please send your comments (support/not = support) to the mpls working group

mailing list (mpls@ietf.org).

 

This poll will end Thursday September 4= , 2014.

 

Thanks, Ross

 

______________________________________= _________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943A3B7735xmbalnx01ciscoc_-- From mardemes@gmail.com Sun Aug 24 11:39:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9AE1A0668 for ; Sun, 24 Aug 2014 11:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 WnhMDj3hHfj9 for ; Sun, 24 Aug 2014 11:39:40 -0700 (PDT) Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D951A0657 for ; Sun, 24 Aug 2014 11:39:39 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id i57so10249979yha.21 for ; Sun, 24 Aug 2014 11:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Bu2MXSwhZ44VZDNKJw1PjWRq9TA9NavA7DU4MbgHXBQ=; b=VHIvkjz1X3rYfW/WO0rNE7w2VrGhN25qkjaMqIvWrWD/yGVSS/1ZgI67yAlSYePUEZ LrGLA5frvagOFfT6h/1Gn5B6whnmHU21rI6ZtmyO9QAO3FkqIKt5/yp7s++ogQ9VHWza 6Y83a7swET59X4QX23G1vy6Std7VHxp4tfRVXr6L7fZ09CmL9hmGyfS5YkN/cKpDchlc omIWVsbz1vDmWJEmu5Ts4OpOEAf8kaiMnadxSEHr6URe08CxPXWnsKXyaCJYZ+RzgaZ/ SHnLVndhsPEWfbgtikWzcKTwF0CR8xaQubp1vmiiG1CNOIcIh1ASHefEOKk2+9DaXBPT 9y2w== MIME-Version: 1.0 X-Received: by 10.236.39.173 with SMTP id d33mr6160007yhb.104.1408905579109; Sun, 24 Aug 2014 11:39:39 -0700 (PDT) Received: by 10.170.149.5 with HTTP; Sun, 24 Aug 2014 11:39:39 -0700 (PDT) Date: Sun, 24 Aug 2014 15:39:39 -0300 Message-ID: From: Martony Demes To: mpls@ietfa.amsl.com Content-Type: multipart/alternative; boundary=001a1136ac9090a21a0501646401 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/w5swvoMR10I826VnW4j9fg2RoG4 Subject: [mpls] Participation in Grupo X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 18:45:47 -0000 --001a1136ac9090a21a0501646401 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I want participation in grupo MPLS. --=20 * Martony Demes* * Analista de Tecnologia da Informa=C3=A7=C3=A3o * * 86 9990-9064 [WhatsApp]* * http://mardemes.com * --001a1136ac9090a21a0501646401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
=C2=A0 = =C2=A0 =C2=A0I want participation in grupo MPLS.


--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Martony Demes
=C2=A0 =C2=A0 =C2=A0Analista de Tecnologia da=C2=A0Informa=C3=A7=C3=A3o= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2= =A086 9990-9064 [WhatsApp]
= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0http://mardemes.com=C2=A0


=C2=A0


--001a1136ac9090a21a0501646401-- From nobody Sun Aug 24 22:15:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6FC1A8A16; Sun, 24 Aug 2014 22:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.893 X-Spam-Level: X-Spam-Status: No, score=-100.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcHkN6Hy9UV1; Sun, 24 Aug 2014 22:14:51 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341401A8A15; Sun, 24 Aug 2014 22:14:51 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-05-53fa71a3aa42 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.D5.05330.3A17AF35; Mon, 25 Aug 2014 01:13:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 25 Aug 2014 01:14:48 -0400 From: Gregory Mirsky To: "'draft-tissa-netmod-oam@tools.ietf.org'" Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9A== Date: Mon, 25 Aug 2014 05:14:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPn+6Swl/BBt8a+Sz2bnvJavH42yF2 i1tLV7JazL/YyGrxdL6kxec/2xgtjl/4zWgxb9cHJgcOjyVLfjJ5fLn8mS2AKYrLJiU1J7Ms tUjfLoEr4/yZ1ewFN6oqdrT/YGlg3JTVxcjJISFgIvHgxG0mCFtM4sK99WwgtpDAUUaJX4/0 IezljBJbvumA2GwCRhIvNvawg9giAuESK+7/ALK5OJgFGpkk5j5+BdYsLKAgsfndbxaIIlWJ /Y3/mSFsPYn38w+CxVmA4lc6JoIN4hXwlZjWfAaslxHoiO+n1oAdxCwgLnHryXyo4wQkluw5 zwxhi0q8fPyPFcJWkvj4ez47RH2+xJUdp1kgZgpKnJz5hGUCo/AsJKNmISmbhaQMIq4jsWD3 JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLYxAiMr2MSbLo7GPe8tDzEKMDBqMTD u2D7z2Ah1sSy4srcQ4zSHCxK4ryzaucFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk2JL7 oOnR171K7X9yJ/8N3Gi1VcxsvsNGufZ+i3lznpjezzKb6+DSW3XFP3ey28Rp7U0+1e/WlL2N 4t280WCqyoLXKxKfak7dan3F5eXBuX1f37vMrzaasdZdfjHjTTV2Kft/r8yuH+linHP6FN83 HfN7B7o3KpqlB1jWZUQdb45PPTBlUd4aJZbijERDLeai4kQAvcFrVJACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wGete1j-phv_sR62yqqUky-O-K4 Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" Subject: [mpls] draft-tissa-netmod-oam X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 05:14:54 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_-- From nobody Mon Aug 25 05:41:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FED1A9083; Mon, 25 Aug 2014 05:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIKBoqiM8xcw; Mon, 25 Aug 2014 05:41:32 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D2A201A9082; Mon, 25 Aug 2014 05:41:31 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,397,1406606400"; d="scan'208";a="472811971" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Aug 2014 08:40:46 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 25 Aug 2014 08:41:30 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "Carlos Pignataro (cpignata)" Date: Mon, 25 Aug 2014 08:41:31 -0400 Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac/AYeSUj/uHNwcbR/2RPaf3IY2GsA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 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/mpls/OFTpeTJ8UPq9Hh4FJ6fl3c6W5VE Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 12:41:33 -0000 QWx2YXJvIC0NCg0KV2hhdCB5b3UncmUgYWN0dWFsbHkgc2VlaW5nIGlzIHRoZSBhdXRvbWF0aWMg cHJvY2Vzc2luZyB0aGF0IHNlZXMNCiJSRkNOTk5OIiBhbmQgbWFrZXMgaXQgYSBoeXBlcmxpbmsg aW4gdGhlIEhUTUwgdmVyc2lvbi4gV2UgZGlkbid0IGFjdHVhbGx5DQphZGQgdGhlIHJlZmVyZW5j ZSB0byB0aGUgd29yayBpbiBwcm9ncmVzcyB0aGVyZSBhdCBhbGwuIEkgY2FuIGFkZCBpdC4NClRo YW5rcywNCg0KV2VzDQoNCg0KT24gOC8yMi8xNCwgMjo1MCBQTSwgIkFsdmFybyBSZXRhbmEgKGFy ZXRhbmEpIiA8YXJldGFuYUBjaXNjby5jb20+IHdyb3RlOg0KDQo+Q2FybG9zL1dlczoNCj4NCj5C VFcsIGFzIEkgd2FzIHRha2luZyBhbm90aGVyIGxvb2sgYXQgdGhlIC0wMSB0ZXh0IChJIGtub3cg eW91IGhhdmUgZWRpdHMNCj5yZWFkeSB0byBjb21taXQpLCB0aGVyZSdzIGEgY291cGxlIG1vcmUg bWlub3IgY29tbWVudHMgcmVsYXRlZCB0byB0aGUNCj5yZWZlcmVuY2VzOg0KPg0KPjEuIDMuMi4x LiAoTERQKSAiR2FwOiBNYWpvciwgdXBkYXRlIHRvIFJGQyA1MDM2IGluIHByb2dyZXNzIHRoYXQg c2hvdWxkDQo+Y2xvc2UgdGhpcyBnYXAuIiAgVGhlIGluLWxpbmUgcmVmZXJlbmNlIHBvaW50cyB0 byByZmM1MDM2LCBidXQgaXQgc2hvdWxkDQo+cG9pbnQgdG8gSS1ELmlldGYtbXBscy1sZHAtaXB2 Ni4NCj4NCj4yLiAzLjUuIChNSUJzKSAiR2FwOiBNYWpvci4gV29yayB1bmRlcndheSB0byB1cGRh dGUgUkZDMzgxMS4uIiAgU2FtZQ0KPnRoaW5nLCB0aGUgcmVmZXJlbmNlIHRvIHRoZSB1cGRhdGUg c2hvdWxkIHBvaW50IHRvDQo+SS1ELm1hbnJhbC1tcGxzLXJmYzM4MTFiaXMuDQo+DQo+VGhhbmtz IQ0KPg0KPkFsdmFyby4NCj4NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlv biB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Mon Aug 25 06:17:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C7E1A9095; Mon, 25 Aug 2014 06:17:18 -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] 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 ONFKTLCTp-YI; Mon, 25 Aug 2014 06:17:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4851A9085; Mon, 25 Aug 2014 06:17:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825131717.30746.87087.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 06:17:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7Q_rYMvWMdCiYkEnun9rt4RhGCI Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 13:17:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Gap Analysis for Operating IPv6-only MPLS Networks Authors : Wesley George Carlos Pignataro Filename : draft-ietf-mpls-ipv6-only-gap-02.txt Pages : 26 Date : 2014-08-25 Abstract: This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-only-gap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ipv6-only-gap-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ipv6-only-gap-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 25 06:25:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7001A8935 for ; Mon, 25 Aug 2014 06:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 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=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdXJwNR-edCA for ; Mon, 25 Aug 2014 06:25:06 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFE11A8932 for ; Mon, 25 Aug 2014 06:25:05 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,397,1406606400"; d="scan'208";a="479884834" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Aug 2014 09:24:24 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 25 Aug 2014 09:25:04 -0400 From: "George, Wes" To: "mpls@ietf.org" Date: Mon, 25 Aug 2014 09:25:05 -0400 Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt Thread-Index: Ac/AZ/qj+S4aenAKSXyufpLzIi/tLw== Message-ID: References: <20140825131717.30746.87087.idtracker@ietfa.amsl.com> In-Reply-To: <20140825131717.30746.87087.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 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/mpls/fmXvPgFAa4B_94V12Tls16XReHw Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 13:25:07 -0000 VGhpcyBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIGZyb20gQWx2YXJvJ3MgZXhjZWxsZW50IGFuZCB0 aG9yb3VnaCByZXZpZXcgYXQNCldHTEMsIGFuZCB3ZSB0aGluayBpdCdzIHJlYWR5IHRvIGdvLg0K DQpUaGUgdGV4dCBpbiB0aGUgRVZQTiBzZWN0aW9uICgzLjMuMS4xKSBpcyBzdGlsbCBzdWJqZWN0 IHRvIGNoYW5nZSwgYXMgd2UNCmhhdmUgbm90IGhlYXJkIGJhY2sgZnJvbSB0aGUgYXV0aG9ycyBv ZiB0aGUgRVZQTiBkcmFmdCwgc28gdGhlIGN1cnJlbnQNCnRleHQgaXMgYmFzZWQgb24gbXkgYWRt aXR0ZWRseSB1bnNraWxsZWQgcmV2aWV3Lg0KDQpUaGFua3MsDQoNCldlcw0KDQoNCg0KT24gOC8y NS8xNCwgOToxNyBBTSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4NCndyb3RlOg0KDQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+IFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNo aW5nIFdvcmtpbmcNCj5Hcm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAg ICAgICA6IEdhcCBBbmFseXNpcyBmb3IgT3BlcmF0aW5nIElQdjYtb25seSBNUExTDQo+TmV0d29y a3MNCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFdlc2xleSBHZW9yZ2UNCj4gICAgICAgICAg ICAgICAgICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4gICAgICAgRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAtMDIudHh0DQo+ICAgICAgIFBhZ2VzICAg ICAgICAgICA6IDI2DQo+ICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMDgtMjUNCj4NCj5B YnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IHJldmlld3MgdGhlIE11bHRpcHJvdG9jb2wgTGFi ZWwgU3dpdGNoaW5nIChNUExTKQ0KPiAgIHByb3RvY29sIHN1aXRlIGluIHRoZSBjb250ZXh0IG9m IElQdjYgYW5kIGlkZW50aWZpZXMgZ2FwcyB0aGF0IG11c3QNCj4gICBiZSBhZGRyZXNzZWQgaW4g b3JkZXIgdG8gYWxsb3cgTVBMUy1yZWxhdGVkIHByb3RvY29scyBhbmQNCj4gICBhcHBsaWNhdGlv bnMgdG8gYmUgdXNlZCB3aXRoIElQdjYtb25seSBuZXR3b3Jrcy4gIFRoaXMgZG9jdW1lbnQgaXMN Cj4gICBub3QgaW50ZW5kZWQgdG8gaGlnaGxpZ2h0IGEgcGFydGljdWxhciB2ZW5kb3IncyBpbXBs ZW1lbnRhdGlvbiAob3INCj4gICBsYWNrIHRoZXJlb2YpIGluIHRoZSBjb250ZXh0IG9mIElQdjYt b25seSBNUExTIGZ1bmN0aW9uYWxpdHksIGJ1dA0KPiAgIHJhdGhlciB0byBmb2N1cyBvbiBnYXBz IGluIHRoZSBzdGFuZGFyZHMgZGVmaW5pbmcgdGhlIE1QTFMgc3VpdGUuDQo+DQo+DQo+VGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAvDQo+ DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAtMDINCj4N Cj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1n YXAtMDINCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPklu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5m dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWlsaW5nIGxpc3QNCj5tcGxz QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoN Cg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGlt ZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVn ZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRp bWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9u LCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9m IGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5 IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkg cHJpbnRvdXQuDQo= From nobody Mon Aug 25 16:08:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079B81A0459 for ; Mon, 25 Aug 2014 16:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 LYrKTAeiE9Y1 for ; Mon, 25 Aug 2014 16:07:54 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC001A046D for ; Mon, 25 Aug 2014 16:07:30 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id eu11so22049138pac.4 for ; Mon, 25 Aug 2014 16:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=olF6qSx8NC3CuCr9GVjGI2g1JGzMSjMjbZ6ERXCSnt0=; b=M4mhUCmojuiK1zqrKdwLUA81a61hfB+g0sW/w6WeslwMmvVeQRMgRBd6Mxbdckr6/f 7FH61iEfsGY01ty5Ew7V4vUNtTpzzk3+TiPtBE8xQq1cIyLvAPzkGFNzVZBfjBA2y8vR qeiG9KIwkWvHAOoVkTaeZ8DHRF92SgBLk83ulMqyauKX70vgjl0C23l0LrGGncYBXoXv qfKvobJqVFbcM6/dR68CW6hUO3Fa0fJ0fW5NTQmhtzFCpo2dY5AqrvKaFC1cS9CBzzNS vXb7ZHCSpUnLUv1Hy/Zb+X9PlxRkIH7Lr+QZsIvhoCcvZCaUCM6G1YE3ZnbBw8tyE5tH ZlIA== X-Received: by 10.70.52.199 with SMTP id v7mr19374766pdo.49.1409008049628; Mon, 25 Aug 2014 16:07:29 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id gk11sm911031pbd.41.2014.08.25.16.07.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 16:07:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D99EBA3-885B-4CC7-9387-3E454DB67BA7" From: "Sam K. Aldrin" In-Reply-To: Date: Mon, 25 Aug 2014 16:07:22 -0700 Message-Id: References: To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/23SqNYGKhFB6uXeE5hFsR4NbesA Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 23:07:58 -0000 --Apple-Mail=_1D99EBA3-885B-4CC7-9387-3E454DB67BA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Nobo, Thanks for the reply. See my replies inline with %sam. Will keep it = brief. On Aug 24, 2014, at 7:08 AM, Nobo Akiya (nobo) wrote: > Hi Sam, > =20 > Please see in-line with [NOBO]. > =20 > From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com]=20 > Sent: Thursday, August 21, 2014 9:24 PM > To: Nobo Akiya (nobo) > Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] Poll for Adoption = draft-akiya-mpls-lsp-ping-reply-mode-simple-02 > =20 > Hi Nobo, > =20 > Inline for my comments. > =20 > On Aug 21, 2014, at 1:43 PM, Nobo Akiya (nobo) wrote: >=20 >=20 > Hi Sam, > =20 > >> 1. Provide an example with specific type of LSP and FEC type where = is useful and also why existing RFC=92s couldn=92t solve it. > =20 > The title of this WG adoption poll may have created some confusion. = The latest version of this document is -03. > =20 > = http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-03 > =20 > The latest version has Appendix A which was added as result of your = comments. > Yes, I am looking at the v03 itself.:D. The appendix doesn't mention = which FEC type. > The only FEC type this extension will be helpful is MPLS TP with IP = available on every node. > There are no other LSP's or FEC types which fits this scenario. Do = they? > =20 > [NOBO] MPLS TP and associated RSVP-TE for sure. The reason why = Appendix A is generally described is that we will likely have more LSPs = down the road. One example will be associated SPRING LSPs where only the = end-points have the state for the reverse LSP. %sam - RSVP-TE is still unidirectional LSP. For reverse direction it is = different LSP altogether. W.r.t. SPRING, Unless you want to discuss LSP = ping for SPRING here (I believe there exists a draft) do not want to = further that. > =20 > Let us take the MPLS TP with IP on every node. > The scenario you are talking about is 'associated bidirectional' = tunnel. > Just because a 'vendor' implemented certain default method doesn't = require new TLV support. > For associated bidirectional tunnel with IP on every node, perform = reply mode as IP. > I don't think RFC4379 warrants certain default type to be fixed type = for a given FEC. > =20 > [NOBO] What you say is true only if all operators prefer IP return = path over control channel and reverse LSP. I am aware of operators who = wants to prefer control channel or reverse LSP whenever available, over = IP path. The preference really varies depending on operators. This is = exactly where this extension can benefit. %sam - We discussed this before but ended up with opposite conclusion = :D. If user want to perform return path via lsp or via IP, nothing = prevents and one could chose either of them. The same goes for bitmap = size, selector size etc. > =20 > I will also look at this way. When there is no reverse lsp available = on a given node, performing LSP ping with reply mode as reverse lsp is = not considered an issue. Rather it is user who chose wrong reply mode = (or vendor provided wrong default option). LSP ping as such provides = option to chose which reply mode to use.=20 > =20 > [NOBO] Ping is much simpler than traceroute. Take a look at Appendix = A.1. In normal conditions, traceroute will work just fine with Reply = Mode control channel or reverse LSP, except when there=92s an error. = Then there will be a timeout and user/application will have to = debug/re-try. If the extension described in this document was there, = there is no timeout and user/application can immediately know where the = breakage is. %sam - Again, this is more of an implementation of workflow. Traceroute = is heavyweight and is performed only when needed or very infrequently. = Ping is performed regularly to detect MPLS failures. Infact, in one of = the vendor's implementation (I do not want to name :D), trace route is = performed only after 3 successive failures, performed rapidly. One could = perform single traceroute or two trace routes simultaneously with = different reply modes. In the case of MPLS TP, BFD is actually used for = failure detection, and lsp ping is used sparingly. The point I am making is, the problem is not with the existing = function/specification or how fast one could not detect, rather how the = workflow could be implemented and achieve the same or better result, = without implementing any changes. Fundamentally where I disagree is, why = solve when there is solution already. > =20 > =20 > >> 2. Details on how this draft will reduce =91false failures=92, = given that every device has to support these new TLV=92s. > =20 > The extension itself is backwards compatible (i.e. adds an optional = TLV), but benefit can obviously be achieved when corresponding LSRs = support the extension. If there are one or more LSRs not supporting this = extension, then it is no worse than today. > Then why to introduce new TLV, as it could be solved without it and by = using right reply mode. :D > =20 > [NOBO] It is ideal to design a diagnostic tool to not have =93timeout=94= but rather get the response with a diagnostic reason. LSP = Ping/Traceroute is a great diagnostic tool, but we are not using it = enough IMHO. I, for one, think network monitoring can significantly = benefit if we have an application that uses LSP Ping/Trace along with = other OAM tools. And ever better if =93timeout=94 (of seconds) can be = avoided. %sam - Having designed, deployed and trained how to use LSP = ping/traceroute, I beg to differ that it is not used effectively. I can = safely say, the same scenarios you are saying could be done or already = being done, without this enhancement. > =20 > Despite the fact that we are still going on a parallel path, I do = still appreciate you reviewing the document =85 your comments have = helped this document into much better shape. %sam - I am very happy to hear that and will continue to provide useful = comments :D -sam > =20 > Thanks! > =20 > -Nobo > =20 > -sam >=20 > =20 > Thanks! > =20 > -Nobo > =20 > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Wednesday, August 20, 2014 10:53 PM > To: Ross Callon > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] Poll for Adoption = draft-akiya-mpls-lsp-ping-reply-mode-simple-02 > =20 > Hi Ross, et al, > =20 > I have discussed over the mailing alias why I do not support this = draft in the current form. > > Authors and I could not converge to agreed conclusion. > =20 > Here are things I would like to see in the draft=20 > =20 > 1. Provide an example with specific type of LSP and FEC type where is = useful and also why existing RFC=92s couldn=92t solve it. > 2. Details on how this draft will reduce =91false failures=92, given = that every device has to support these new TLV=92s. > =20 > As it was discussed in detail already over the mailing list, need to = see the benefits for these extensions. > My point is, if problem is solved already with existing mechanisms, = there is no need to solve with different method. We use that argument = many times in the WG/IETF. > But if it is indeed solving something which couldn=92t be solved thus = far (I haven=92t seen it yet), you will have my support. > =20 > cheers > -sam > =20 > On Aug 20, 2014, at 8:20 AM, Ross Callon wrote: >=20 >=20 >=20 > This is to start a two week poll on adopting = draft-akiya-mpls-lsp-ping-reply-mode-simple-02 > as an MPLS working group document. > =20 > Please send your comments (support/not support) to the mpls working = group > mailing list (mpls@ietf.org). > =20 > This poll will end Thursday September 4, 2014. > =20 > Thanks, Ross > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_1D99EBA3-885B-4CC7-9387-3E454DB67BA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Nobo,

Thanks for the reply. = See my replies inline with %sam. Will keep it brief.
On Aug = 24, 2014, at 7:08 AM, Nobo Akiya (nobo) wrote:

Hi = Sam,
%sam = - RSVP-TE is still unidirectional LSP. For reverse direction it is = different LSP altogether. W.r.t. SPRING, Unless you want to discuss LSP = ping for SPRING here (I believe there exists a draft) do not want to = further that.
Let us take = the MPLS TP with IP on every node.
The scenario you are talking about is 'associated = bidirectional' tunnel.
Just because a 'vendor' implemented certain default = method doesn't require new TLV support.
For associated bidirectional tunnel with IP on every = node, perform reply mode as IP.
I don't think RFC4379 warrants certain default type to = be fixed type for a given FEC.
I will also = look at this way. When there is no reverse lsp available on a given = node, performing LSP ping with reply mode as reverse lsp is not = considered an issue. Rather it is user who chose wrong reply mode (or = vendor provided wrong default option). LSP ping as such provides option = to chose which reply mode to use. 
>> 2. Details on how = this draft will reduce =91false failures=92, given that every device has = to support these new TLV=92s.
The extension itself is backwards compatible (i.e. = adds an optional TLV), but benefit can obviously be achieved when = corresponding LSRs support the extension. If there are one or more LSRs = not supporting this extension, then it is no worse than = today.
%sa= m - Having designed, deployed and trained how to use LSP = ping/traceroute, I beg to differ that it is not used effectively. I can = safely say, the same scenarios you are saying could be done or already = being done, without this enhancement.
Thanks!
-Nobo
This is to start a two week poll on adopting = draft-akiya-mpls-lsp-ping-reply-mode-simple-02
as an MPLS working group = document.
 
Please send your comments (support/not support) to the = mpls working group
mailing list ( 
_______________________________________________
mpls = mailing list
mpls@ietf.org
To: Date: Tue, 26 Aug 2014 21:32:25 +0100 Message-ID: <080001cfc16c$da8b1350$8fa139f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/BbNYNTPSbs7mmTiC8qEhRq5l5uw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20908.000 X-TM-AS-Result: No--17.976-10.0-31-10 X-imss-scan-details: No--17.976-10.0-31-10 X-TMASE-MatchedRID: Mj3NuCQGYzKBHLccdfPpxmzBijri5+RVEtdrY/Wb3fPa+IH8mvgPVDzA K7q1A+Iip4greFLbomXiKbEoKAv3hZe/bF1ays2SJmbrB1j4Xwqgo7yEQ1t1y8JuW1juhakm35d D76rzBff94EKC68/eHVIfAqDjzY8QZaaZcM4sp6NbuDP8ZuCmXr7xhVTyv5qoY0DjZWmXtn6jxY yRBa/qJX3mXSdV7KK4OubYLCVnBVG8QIu4z6HhEH7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JyD3v05eUTbuuQLhFmMykddVTWg X-Mailman-Approved-At: Tue, 26 Aug 2014 14:02:14 -0700 Subject: [mpls] Routing Area Tuning - What I heard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:32:38 -0000 Hi, [Please respond on routing-discussion@ietf.org even though I am spamming several lists] Thanks for the input on this topic. I heard a number of opinions about whether to split TE architecture away from RSVP-TE. I think this leads to some roughish consensus as follows: TEAS - core RSVP-TE - RSVP-TE for generic cases - IGP-TE extensions in coordination with IGP WGs - TE architecture - including the applicability of PCE for TE in association with PCE WG - relationships with - OSPF and ISIS as above - PCE as above - MPLS for generalisation of packet-specific protocol extensions - CCAMP for generalisation of non-packet-specific protocol extensions CCAMP - non-packet technology-specific RSVP-TE - non-packet technology-specific IGP-TE in association with IGP WGs - consideration to generalise all protocol extensions via TEAS That leaves... MPLS as it is today, except: - All RSVP-TE work that is not technology-specific for packet goes to TEAS - Any TE architecture work goes to TEAS PCE as it is today, except: - Architectural application of PCE for TE goes to TEAS with coord back to PCE Can you please let me know whether I misheard you badly. Is this a split you can live with? Are there show-stopper issues? Thanks, Adrian From nobody Wed Aug 27 09:15:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BB71A0B0C; Wed, 27 Aug 2014 09:15:17 -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] 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 MlTHCawONoHL; Wed, 27 Aug 2014 09:15:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 836BC1A0AEA; Wed, 27 Aug 2014 09:15:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140827161515.15950.81196.idtracker@ietfa.amsl.com> Date: Wed, 27 Aug 2014 09:15:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Kfowm4c-d3wMXeOTRO_q8tOscJY Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc6374-udp-return-path-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:15:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : RFC6374 UDP Return Path Authors : Stewart Bryant Siva Sivabalan Sagar Soni Filename : draft-ietf-mpls-rfc6374-udp-return-path-00.txt Pages : 8 Date : 2014-08-27 Abstract: This document specifies the proceedure to be used by the Packet Loss and Delay Measurement for MPLS Networks protocol defined in RFC6374 when sending and processing MPLS performance management out-of-band responses for delay and loss measurements over an IP/UDP return path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-rfc6374-udp-return-path-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 27 15:52:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B001A016C for ; Wed, 27 Aug 2014 15:52: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, 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 86Yc2we3Buu2 for ; Wed, 27 Aug 2014 15:52:24 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2::152:127]) by ietfa.amsl.com (Postfix) with ESMTP id 318761A0140 for ; Wed, 27 Aug 2014 15:52:24 -0700 (PDT) Received: from [10.21.80.55] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 78B4982BA for ; Thu, 28 Aug 2014 00:52:22 +0200 (CEST) Message-ID: <53FE6124.808@venaas.com> Date: Wed, 27 Aug 2014 15:52:20 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Svc_LrNvTC-i_ZYcfyCqwKcluyo Subject: [mpls] Routing Directorate QA review of draft-ietf-mpls-pim-sm-over-mldp-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 22:52:26 -0000 Hi I've been selected as the routing directorate QA reviewer for draft-ietf-mpls-pim-sm-over-mldp-00. This is part of the QA process described at https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa The document looks great to me. It is easy to read and I cannot find any issues with it. The security considerations are quite short, I'm wondering if there truly are no other considerations. Idnits shows a few issues, please consider those. Stig From nobody Wed Aug 27 16:18:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C891A011B for ; Wed, 27 Aug 2014 16:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 nq0Jd9rZI_Rb for ; Wed, 27 Aug 2014 16:18:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B005A1A0110 for ; Wed, 27 Aug 2014 16:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6783; q=dns/txt; s=iport; t=1409181528; x=1410391128; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8QpdIO0s33Q+jgKG9kxOY3lfEMGL6EGW591Rs79nj2U=; b=FPjsh5Yg/1e8OmaZk/Vx4vVtzVpLVxFosq6/YtAgHM4jg/7wV7vGlLYZ 0INoGXGtQRohbFS5puIFVKLB/OzSPztyk6+UQpSAJa0yFk5MpxUzCHFkZ ekWuBn0JUF0dckBalAzmN2U2anUED77txADAT6N87WgxRMTZiUtFUTUPm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAPdm/lOtJV2Z/2dsb2JhbABbgw1TVwTMGgqHTwGBExZ3hAMBAQEDAQEBAWgDCwwCAgIBCA4DAwEBASgHGwwLFAkIAgQBDQUJEogfCA2/XxcEjmYQAgFPAgUGhEYFkS+ELYZ8gVuTP4NebAEBgUaBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,414,1406592000"; d="scan'208";a="350836637" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 27 Aug 2014 23:18:46 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7RNIktH022770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 23:18:46 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.218]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 18:18:46 -0500 From: "Rajiv Asati (rajiva)" To: Ross Callon , "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" Thread-Topic: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) Thread-Index: AQHPtkRUETSIq42RjU6bn6kiA9S5/5vX4vKAgAWVYICAB8ZjgA== Date: Wed, 27 Aug 2014 23:18:45 +0000 Message-ID: References: <53EA3666.2040004@pi.nu> <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> <9ace61def77942938bc577e4b6782680@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <9ace61def77942938bc577e4b6782680@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.225.74] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MpgHae5cOogmwWkn4CV6naepYNI Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 23:18:50 -0000 If this draft were to address the interoperability with rfc5036 non-compliant implementations, then it would be easier to rather leverage the =8Ctransport preference=B9 TLV that is already part of the version 13. This TLV was defined after the getting Adrian's and George=B9s feedback. http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-13#section-6.1.1 The reason for not agreeing to the alternate solution (of using IP Prefix capability etc.) is 2-fold: - not forward compatible (consider a deployment 5 yrs from now - IPv6-only MPLS network - now, the LSR will be expecting an unnecessary IPv6 prefix capability advertisement, and that=B9s not optimal, if not annoying) - not 100% backward compatible (does not solve the advertisement of v6 address binding to a v4 neighbor (which can also cause an outage to a non-compliant peer)) Thanks.=20 --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: Ross Callon Date: Friday, August 22, 2014 at 4:34 PM To: Mustapha Aissaoui , "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: RE: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) Resent-From: Resent-To: Carlos Pignataro , Rajiv Papneja , Rajiv Asati , Vishwas Manral , , Loa Andersson , Ross Callon , MARTIN VIGOUREUX Resent-Date: Friday, August 22, 2014 at 4:35 PM >> The proposed solution is to have implementations complying to this draft >> advertise the IPv6 prefix state advertisement control capability >> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization message >> explicitly indicating support for LDP IPv6. Without the peer advertising >> this capability, an LSR must not send IPv6 addresses and FECs to that >>peer. > >Speaking as an individual contributor, this seems IMHO to be the right >solution (noting that, in final text as would be published in an RFC, the >"must not" in the last sentence should be capitalized). > >Thanks, Ross > >-----Original Message----- >From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha >(Mustapha) >Sent: Tuesday, August 19, 2014 3:19 AM >To: mpls@ietf.org >Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-ipv6@tools.ietf.org >Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc >closed) > >Dear all, >The following are the details of the issue we found and the proposed >solution. We shared this first with the authors to get initial feedback. > >When an LSR which supports LDP IPv6 according to this draft is in a LAN >with a broadcast interface, it can peer with LSRs which support this >draft and LSRs which do not. When it peers using IPv4 LDP control plane >with an LSR which does not support this draft, we have seen during our >testing an issue that the advertisement of IPv6 addresses or IPv6 FECs to >that peer will cause it to bring down the IPv4 LDP session. > >In other words, there are deployed LDP implementations which are >compliant to RFC 5036 for LDP IPv4 but are not compliant to RFC 5036 when >it comes to handling IPv6 address or IPv6 FECs over an LDP IPv4 session. >This is making us very concerned that when users enable dual-stack LDP >IPv4/IPv6, they will bring down LDP IPv4 sessions which have been working >in a multi-vendor environments for so many years. > >The proposed solution is to have implementations complying to this draft >advertise the IPv6 prefix state advertisement control capability >(draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization message >explicitly indicating support for LDP IPv6. Without the peer advertising >this capability, an LSR must not send IPv6 addresses and FECs to that >peer.=20 > >This approach is safer and has been followed when mLDP FEC was introduced >as explained in Section 2.1 of RFC 6388. Also, this does not introduce >any new TLV to draft-ietf-mpls-ldp-ipv6. It just makes the exchange of >LDP IPv6 addresses and FECs conditional to both peers explicitly >indicating support for IPv6 capability during LDP session initialization. > >We do not feel such a simple change justifies writing a new draft and >having to deal with backward compatibility of implementations across two >drafts.=20 > >We appreciate your comments on this matter. > >Regards, >Mustapha. > > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Tuesday, August 12, 2014 11:45 AM=09 >> To: mpls@ietf.org; mpls-chairs@tools.ietf.org; >>draft-ietf-mpls-ldp-ipv6@tools.ietf.org >> Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc >>closed) >>=20 >> Working Group, >>=20 >> During what we thought would be a short wglc on draft-ietf-mpls-ldp-ipv6 >> http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html >> we had a comment that stopped us from continuing progressing the draft. >>=20 >> The short working group last call is now closed! >>=20 >> The comment we refer to was raised in a private mail to the working >>group chairs >> and the draft authors. >>=20 >> It says that there are a problem with some RFC 5036 non-compliant >> implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no >>detailed >> description of the exact problems. >>=20 >> We strongly encourage the people that made the comment(s) to write-up >>the >> problem, either as >>=20 >> - a new draft (preferred); or >> - in a mail to the working group mailing list >>=20 >> Once we an agreement to write a new draft or the write-up to the >>mailing, we will >> continue to ask the working group to see if we can agree to a way to >>progress. We >> like to see this write-up before September 1. Failing this we will >>continue to progress >> the draft-ietf-mpls-ldp-ipv6 as is. >>=20 >> /Loa >> for the working group chairs >> -- >>=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 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Aug 28 08:24:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D9C1A030A; Thu, 28 Aug 2014 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.168 X-Spam-Level: X-Spam-Status: No, score=-13.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 BDtdGBpeqD9G; Thu, 28 Aug 2014 08:24:33 -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 4C96D1A06FC; Thu, 28 Aug 2014 08:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29477; q=dns/txt; s=iport; t=1409239473; x=1410449073; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UUaWlJnTkIdT2jpeN2ooo6VAdPLfWpG3/ZUrZmZ7C7o=; b=haYGHHnGj4B1Y2Tx04CiPsMf2sKsQxzuhGAmkkvXrElFO6Ra94bOS4kG Ixc5ncHRZAYdoLggiZwDsm7CGKbmDBFuh2tpXZUkyqR0ctCz4DaFZjEsQ SlLkPv3Szn64ip29nnzxCJdyT1A+W37xaLUC3Jhge7MjN4QaQQTvbgU1G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACFJ/1OtJV2R/2dsb2JhbABbgkdGU1cE03YBgRkWd4QDAQEBBC05DAcQAgEIEQEDAQELFgcHMhQDBggBAQQBDQUIE4gnv0oXjnQnMQYBgy+BHQWRL6BIg15sgQYCHgYcgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,418,1406592000"; d="scan'208,217";a="351062464" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 28 Aug 2014 15:24:15 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7SFOF8Q007812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 15:24:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 10:24:15 -0500 From: "Tissa Senevirathne (tsenevir)" To: Gregory Mirsky , "'draft-tissa-netmod-oam@tools.ietf.org'" Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9AVplJ1w Date: Thu, 28 Aug 2014 15:24:14 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.14.1] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9OtgXg-kZJHeN4Q_fuTj_qXpYHY Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] draft-tissa-netmod-oam X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 15:24:39 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg Before answering the specific questions below, would like explain few aspe= cts related to the extended CFM model used here. CFM originally was design= ed exclusively for Ethernet. As part of the TRILL OAM work we decoupled CFM= model from Ethernet based addressing and made it addressing independent. T= hat is the CFM model that is referred here. CFM defines a complete fault model that include fault domains, Test point, = Layering etc. Strict definition of such is needed to develop a complete OAM= solution regardless of the underline technology. CFM does a fantastic job = in accomplishing that and AFIK there is no other model. We are leveraging t= hat model. The word generic OAM is utilized here to indicate that the model can be app= lied regardless of the underlying technology. YANG model is not a one-one copy of CFM YANG defined in MEF. Rather it is d= efined with address independent and extensibility in mind. With the above in mind, specific answers in-line: From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, August 24, 2014 10:15 PM To: 'draft-tissa-netmod-oam@tools.ietf.org' Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; 'netmod@= ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org Subject: draft-tissa-netmod-oam Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; [Answer] As stated above it is the OAM Model that is leveraged here. Regard= less of connection oriented or not the model on Fault domains, Test points = etc is valid. In theory connection oriented can be broken in to connection establishment = and data forwarding. With that in mind, one can define Fault domain and tes= t points. Followed by definition of the Fault identifications tools accordi= ngly. Do you have a preferred OAM tool for fault verification/isolation and loss= and performance monitoring for connection oriented connectuons ?. If so wo= uld like to review and map to the model. o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; [Answer] Please see the answer above and extended CFM model. It is the mod= el that is presented here, regardless of the connectioness, OAM tools need= fault domains and fault boundaries. Addidtionally as stated in the explana= tion above, there is nothing Ethernet in CFM, once the addressing is decoup= led. o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; [Answer] I think there is a miss understanding this model is not limited to= Ping and Trace route. Ping and traceroute are only examples to get the wor= k stared and discussion going. As we go along other tools will be mapped to= the model. o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". [Answer] I did not fully understand your point. o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. [Answer] As explained earlier terminology generic OAM is used to indicate = that the presented OAM model can be applied independent of the underlying t= echnology. In section 1, we have stated the following: "..In this document,= we take the [8021Q] CFM model and extend it to a technology independent fr= amework and build the corresponding YANG model accordingly. The YANG model = presented in this document is the base model and supports IP Ping and Trace= route. The generic OAM YANG model is designed such that it can be extended = to cover various technologies. Technology dependent nodes and RPC commands = are defined in technology specific YANG models, which use and extend the ba= se model defined here. .... " * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". [Answer] Can you please provide some example here, I am not quite clear. Guessing from the word peering, if we are referring to cascaded sections of= different technologies such as IP Cloud, MPLS cloud and another IP cloud. = Then the model presented here is the answer. You can have an end end OAM se= ssion at a higher MD-Level. Each of the clouds below can have separate OAM = at a lower MD-Level. These can be utilized for fault isolation. o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? [Answer] Please see the answers above. * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? [Answer] It is ".. can be", so it meant to be an example and other possibil= ities are not ruled out and model does not assume any such limitation. o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? [Answer] Yes model accept both UP/Down. One cannot say for IP there is no MEP. MEP is a functional abstraction of a= test point that generate and respond to OAM messages. In that regard IP de= vices today have an implicit MEP at the CPU. The model allow to provide mor= e semantics to the MEP and allow to create UP/Down per interface or other s= cope, hence providing more granularity in fault isolation/verification and = monitoring. Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Thank you for spending time to review and comment. We are updating the next= version with comments received so far and specifically during IETF in Cana= da. We are more than happy enhance where applicable or need more clarity. Regards, Greg --_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg=

 

Before answering the s= pecific questions below,  would like explain few aspects related to th= e extended CFM model used here. CFM  originally was designed exclusive= ly for Ethernet. As part of the TRILL OAM work we decoupled CFM model from Ethernet based addressing and made it addressi= ng independent. That is the CFM model that is referred here.

 

CFM defines a complete= fault model that include fault domains, Test point, Layering etc. Strict d= efinition of such is needed to develop a complete OAM solution regardless o= f the underline technology. CFM does a fantastic job in accomplishing that and AFIK there is no other model. We= are leveraging that model.

 

The word generic OAM i= s utilized here to indicate that the model can be applied regardless of the= underlying technology.

 

YANG model is not a on= e-one copy of CFM YANG defined in MEF. Rather it is defined with address in= dependent and extensibility in mind.

 

With the above in mind= , specific answers in-line:

 

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, August 24, 2014 10:15 PM
To: 'draft-tissa-netmod-oam@tools.ietf.org'
Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; '= netmod@ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org
Subject: draft-tissa-netmod-oam

 

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

 

 

[Answer] As stated abo= ve it is the OAM Model that is leveraged here. Regardless of connection ori= ented or not the model on Fault domains, Test points etc is valid.

 

In theory connection o= riented can be broken in to connection establishment and data forwarding. W= ith that in mind, one can define Fault domain and test points. Followed by = definition of the Fault identifications tools accordingly.

 

Do you have a preferre= d OAM tool  for fault verification/isolation and loss and performance = monitoring for connection oriented connectuons ?. If so would like to revie= w and map to the model.

 

 

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

 

[Answer]  Please = see the answer above and extended CFM model. It is the model that is presen= ted here, regardless of the connectioness,  OAM tools need fault domai= ns and fault boundaries. Addidtionally as stated in the explanation above, there is nothing Ethernet in CFM, once the addre= ssing is decoupled.

 

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

 

[Answer] I think there= is a miss understanding this model is not limited to Ping and Trace route.= Ping and traceroute are only examples to get the work stared and discussio= n going. As we go along other tools will be mapped to the model.

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

[Answer] I did not ful= ly understand your point.

 

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

 

[Answer]  As expl= ained earlier terminology generic OAM is used to indicate that the presente= d OAM model can be applied independent of the underlying technology. In sec= tion 1, we have stated the following: “..In this document, we take the [8021Q] CFM model and extend it to a technology= independent framework and build the corresponding YANG model accordingly. = The YANG model presented in this document is the base model and supports IP= Ping and Traceroute. The generic OAM YANG model is designed such that it can be extended to cover various t= echnologies. Technology dependent nodes and RPC commands are defined in tec= hnology specific YANG models, which use and extend the base model defined h= ere. …. “

 

 

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

[Answer]  Can you= please provide some example here, I am not quite clear.<= /p>

 

Guessing from the word= peering, if we are referring to cascaded sections of different technologie= s such as IP Cloud, MPLS cloud and another IP cloud. Then the model present= ed here is the answer. You can have an end end OAM session at a higher MD-Level. Each of the clouds below can = have separate OAM at a lower MD-Level. These can be utilized for fault isol= ation.

 

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

 

[Answer] Please see th= e answers above.

 

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

[Answer] It is “= .. can be”, so it meant to be an example and other possibilities are = not ruled out and model does not assume any such limitation.

 

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

[Answer] Yes model acc= ept both UP/Down.

 

One cannot say for IP = there is no MEP. MEP is a functional abstraction of a test point that gener= ate and respond to OAM messages. In that regard IP devices today have an im= plicit MEP at the CPU. The model allow to provide more semantics to the MEP and allow to create UP/Down per inter= face or other scope, hence providing more granularity in fault isolation/ve= rification and monitoring.

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Thank you for spending= time to review and comment. We are updating the next version with comments= received so far and specifically during IETF in Canada. We are more than h= appy enhance where applicable or need more clarity.

 

Regards,

    =     Greg

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_-- From nobody Thu Aug 28 09:55:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6031A87E2 for ; Thu, 28 Aug 2014 09:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 3Q8bMBoRP3Nk for ; Thu, 28 Aug 2014 09:55:15 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572981A87AF for ; Thu, 28 Aug 2014 09:54:27 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B392B1BB1E8DB; Thu, 28 Aug 2014 16:53:34 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s7SGrRTB031210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 18:53:36 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 28 Aug 2014 18:52:59 +0200 From: "Rabadan, Jorge (Jorge)" To: "George, Wes" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt Thread-Index: AQHPwGcQtPprax3VI0ytCwWPC4ptBpvhLaGAgAR7t4A= Date: Thu, 28 Aug 2014 16:52:58 +0000 Message-ID: References: <20140825131717.30746.87087.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <7231B16596014846BE290E0D65C7443B@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kYf3aVyDhL1swXMShcRkqhmaJzA Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 16:55:23 -0000 V2VzLA0KDQpOb3QgYW4gRVZQTiBhdXRob3IsIGJ1dCBJIGhhdmUgc29tZSBhIGNvdXBsZSBvZiBj b21tZW50cyBhYm91dCBzZWN0aW9uDQozLjMuMS4xOg0KDQotIE1pbm9yOiBFVlBOIGlzIGEgc2Vw YXJhdGUgQUZJL1NBRkkgc28gSSB3b3VsZCBub3QgbWFrZSBpdCBhIHN1Yi1zZWN0aW9uDQpvZiBM MlZQTiwgYnV0IEkgd291bGQgcmF0aGVyIHB1dCBpdCBhdCB0aGUgc2FtZSBsZXZlbC4gTm93IHRo YXQgdGhlIEwyVlBODQpXRyB3aWxsIG5vIGxvbmdlciBiZSBhIFdHIG9uIGl0cyBvd24sIEkgd291 bGQgbm90IGNsYXNzaWZ5IEVWUE4gYXMgTDJWUE4NCmFueW1vcmUuIEVWUE4gY2FuIGV2ZW4gZG8g TDMuDQoNCi0gV2h5IGRvZXMgRVZQTiBpbmhlcml0IFJGQyA2MDc0IGdhcHM/IEkgZG9u4oCZdCBz ZWUgYW55IGdhcCBpbiBhbnkgb2YgdGhlDQpFVlBOIGRlZmluZWQgcm91dGUgdHlwZXMgb3IgcHJv Y2VkdXJlcy4gSSB3b3VsZCByZW1vdmUgdGhhdCBhbmQga2VlcCB0aGUNCmRlcGVuZGVuY3kgb24g bUxEUCBhbmQgUkZDIDcxMTcgKGlmIGFueSkgZm9yIHRoZSBQTVNJIHR1bm5lbCBhdHRyaWJ1dGUN CnRoYXQgRVZQTiBpbmhlcml0cy4gT3RoZXIgdGhhbiB0aGF0IEkgc2VlIG5vIGdhcHMgaW4gRVZQ Ti4NCg0KVGhhbmsgeW91Lg0KSm9yZ2UNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogPEdlb3JnZT4sIFdlcyA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT4NCkRhdGU6IE1v bmRheSwgQXVndXN0IDI1LCAyMDE0IGF0IDY6MjUgQU0NClRvOiAibXBsc0BpZXRmLm9yZyIgPG1w bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt bXBscy1pcHY2LW9ubHktZ2FwLTAyLnR4dA0KDQo+VGhpcyBhZGRyZXNzZXMgdGhlIGNvbW1lbnRz IGZyb20gQWx2YXJvJ3MgZXhjZWxsZW50IGFuZCB0aG9yb3VnaCByZXZpZXcgYXQNCj5XR0xDLCBh bmQgd2UgdGhpbmsgaXQncyByZWFkeSB0byBnby4NCj4NCj5UaGUgdGV4dCBpbiB0aGUgRVZQTiBz ZWN0aW9uICgzLjMuMS4xKSBpcyBzdGlsbCBzdWJqZWN0IHRvIGNoYW5nZSwgYXMgd2UNCj5oYXZl IG5vdCBoZWFyZCBiYWNrIGZyb20gdGhlIGF1dGhvcnMgb2YgdGhlIEVWUE4gZHJhZnQsIHNvIHRo ZSBjdXJyZW50DQo+dGV4dCBpcyBiYXNlZCBvbiBteSBhZG1pdHRlZGx5IHVuc2tpbGxlZCByZXZp ZXcuDQo+DQo+VGhhbmtzLA0KPg0KPldlcw0KPg0KPg0KPg0KPk9uIDgvMjUvMTQsIDk6MTcgQU0s ICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+ d3JvdGU6DQo+DQo+Pg0KPj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+ZGlyZWN0b3JpZXMuDQo+PiBUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBXb3Jr aW5nDQo+Pkdyb3VwIG9mIHRoZSBJRVRGLg0KPj4NCj4+ICAgICAgICBUaXRsZSAgICAgICAgICAg OiBHYXAgQW5hbHlzaXMgZm9yIE9wZXJhdGluZyBJUHY2LW9ubHkgTVBMUw0KPj5OZXR3b3Jrcw0K Pj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFdlc2xleSBHZW9yZ2UNCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICBDYXJsb3MgUGlnbmF0YXJvDQo+PiAgICAgICBGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1pZXRmLW1wbHMtaXB2Ni1vbmx5LWdhcC0wMi50eHQNCj4+ICAgICAgIFBhZ2VzICAg ICAgICAgICA6IDI2DQo+PiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE0LTA4LTI1DQo+Pg0K Pj5BYnN0cmFjdDoNCj4+ICAgVGhpcyBkb2N1bWVudCByZXZpZXdzIHRoZSBNdWx0aXByb3RvY29s IExhYmVsIFN3aXRjaGluZyAoTVBMUykNCj4+ICAgcHJvdG9jb2wgc3VpdGUgaW4gdGhlIGNvbnRl eHQgb2YgSVB2NiBhbmQgaWRlbnRpZmllcyBnYXBzIHRoYXQgbXVzdA0KPj4gICBiZSBhZGRyZXNz ZWQgaW4gb3JkZXIgdG8gYWxsb3cgTVBMUy1yZWxhdGVkIHByb3RvY29scyBhbmQNCj4+ICAgYXBw bGljYXRpb25zIHRvIGJlIHVzZWQgd2l0aCBJUHY2LW9ubHkgbmV0d29ya3MuICBUaGlzIGRvY3Vt ZW50IGlzDQo+PiAgIG5vdCBpbnRlbmRlZCB0byBoaWdobGlnaHQgYSBwYXJ0aWN1bGFyIHZlbmRv cidzIGltcGxlbWVudGF0aW9uIChvcg0KPj4gICBsYWNrIHRoZXJlb2YpIGluIHRoZSBjb250ZXh0 IG9mIElQdjYtb25seSBNUExTIGZ1bmN0aW9uYWxpdHksIGJ1dA0KPj4gICByYXRoZXIgdG8gZm9j dXMgb24gZ2FwcyBpbiB0aGUgc3RhbmRhcmRzIGRlZmluaW5nIHRoZSBNUExTIHN1aXRlLg0KPj4N Cj4+DQo+PlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KPj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtaXB2 Ni1vbmx5LWdhcC8NCj4+DQo+PlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0Og0KPj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtaXB2 Ni1vbmx5LWdhcC0wMg0KPj4NCj4+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Og0KPj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLW1wbHMtaXB2Ni1vbmx5LWdhcC0wMg0KPj4NCj4+DQo+PlBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+PnN1Ym1pc3Np b24NCj4+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCj4+DQo+PkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pm1wbHMgbWFpbGluZyBsaXN0DQo+Pm1wbHNAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+DQo+DQo+VGhpcyBFLW1haWwgYW5kIGFu eSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj5wcm9w cmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBv ciBzdWJqZWN0IHRvDQo+Y29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4g VGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQo+Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91DQo+YXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBu b3RpZmllZA0KPnRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywg b3IgYWN0aW9uIHRha2VuIGluDQo+cmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRh Y2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseQ0KPnByb2hpYml0ZWQgYW5kIG1heSBi ZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4NCj5lcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxl dGUgdGhlDQo+b3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJp bnRvdXQuDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5tcGxzIG1haWxpbmcgbGlzdA0KPm1wbHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K From nobody Thu Aug 28 14:11:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBAE1A2130 for ; Thu, 28 Aug 2014 14:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 6g1KUJKKqbQS for ; Thu, 28 Aug 2014 14:11:29 -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 162A01A0B7F for ; Thu, 28 Aug 2014 14:11:29 -0700 (PDT) Received: from [192.168.0.188] (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 B903D18013DA; Thu, 28 Aug 2014 23:11:27 +0200 (CEST) Message-ID: <53FF9B03.7010300@pi.nu> Date: Thu, 28 Aug 2014 23:11:31 +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: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6MFBhZAP7fO853koJTXJSar3Qvw Cc: "" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Consensus call on draft-ietf-mpls-ipv6-only-gap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:11:36 -0000 Working Group, draft-ietf-mpls-ipv6-only-gap has been been through working group last, with only supportive comments. We also had a Routing Area Directorate review that also did not bring up any major technical points. However a few points were brought up, such as - this is a very important document, but since is a gap analysis it is also only document what is true at a certain point time, and the half-life of the document will be fairly short and it doubtful if there is value publishing it as an RFC. - There have also be been some ideas that we should move pointers pointers to an appendix or remove them entirely. In order to avoid mandating certain solutions before the become working group work items. The working group chairs find that the working group have consensus to move ahead with the document (version -02) as it has been updated after the wglc and reviews. The value in having the document publish by far outweigh not having it published. The benefits in moving the reference to an appendix (or removing them) is not comparable to have easily at hand when reading the document. However, once we have this document published as an RFC we understand that keeping on updating an RFC is hardly possible to follow the closing of the gaps. The working group chairs will address this issue once the RFC has been published. /Loa for the working group chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 29 02:18:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5569F1A06E7 for ; Fri, 29 Aug 2014 02:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 3LkSnIZda3AM for ; Fri, 29 Aug 2014 02:18:11 -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 6387E1A0478 for ; Fri, 29 Aug 2014 02:18:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIV99868; Fri, 29 Aug 2014 09:18:09 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 Aug 2014 10:18:08 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Fri, 29 Aug 2014 17:18:01 +0800 From: Mach Chen To: "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" Thread-Topic: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules Thread-Index: AQHPvSsIjXcmgWC890WmwTUyRwbbOJvnTCuw Date: Fri, 29 Aug 2014 09:18:00 +0000 Message-ID: References: <53F5CA67.9070500@pi.nu> In-Reply-To: <53F5CA67.9070500@pi.nu> 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/mpls/ioQH2x6hi5LR3R3f0T27m9pbCtg Cc: "" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: [mpls] Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 09:18:12 -0000 Hi Authors/Editors, I am assigned as Shepherd for draft-ietf-mpls-tp-oam-id-mib, the WG chairs = and Shepherd are working on the publication of draft-ietf-mpls-tp-oam-id-mi= b. I have reviewed version 05 of the draft, here are my comments and some ques= tions, please consider. =20 1.=20 Extract the acronym when first use, for example, LSP in the Introduction, a= nd it's not necessary to extract an acronym when each uses, for example, MP= LS in section 1 and section 3.2 . 2.=20 In RFC6370, it defines MPLS-TP point-to-point Tunnels identifiers, MPLS-TP = co-routed and associated bidirectional MPLS LSPs identifiers, MPLS-TP Pseud= owires Identifiers and Section Identifiers. And in Section 5 of RFC6370, th= ere are some text that describes the difference between "MPLS tunnel" and "= MPLS LSP". In this draft, there are many usages of "tunnel" in section 4, 5= and 6, and actually it should be "LSP". I know that sometimes people alter= natively use tunnel and LSP, but it's better to use the term in an accurate= way hence to reduce the confusion.=20 In addition, based on the mplsOamIdMegServicePointerType (only lsp, pw and = section listed), it implies that the MPLS-TP point-to-point Tunnels identif= iers are actually precluded in this document. Is my understanding right? If= so, it needs look through the document and refine the text to state it cle= arly.=20 Here are some example that may need updates: Section 4. OLD: " The MIB module supports configuration of OAM identifiers for point-to-point, co-routed bidirectional, associated bidirectional MPLS tunnels and MPLS Pseudowires. " NEW: " The MIB module supports configuration of OAM identifiers for MPLS-TP co-routed bidirectional LSPs, associated bidirectional LSPs, Sections and Pseudowires. " Section 5. s/...configurations for MPLS Tunnels and Pseudowires/...configurations for = MPLS-TP LSPs, Sections and Pseudowires Section 5.1 s/...for MPLS tunnels and pseudowires./...for MPLS-TP LSPs, Sections and Ps= eudowires. Section 6 s/...MPLS co-routed bidirectional tunnel/...MPLS-TP co-routed bidirectional= LSP s/...co-routed MPLS tunnel are illustrated here/...MPLS-TP co-routed bidire= ctional LSP are illustrated here 3. For mplsOamIdMeTable, since this is the identifier MIB, why do we needthe f= ollowing items? mplsOamIdMeProactiveOamPhbTCValue =3D 0, mplsOamIdMeOnDemandOamPhbTCValue =3D 0, It seems that they should not belong to this MIB, maybe better in other MIB= . 4. mplsOamIdMegPathFlow OBJECT-TYPE SYNTAX INTEGER { unidirectionalPointToPoint (1), coRoutedBidirectionalPointToPoint (2), associatedBidirectionalPointToPoint (3), unidirectionalPointToMultiPoint (4) Seems RFC6370 does not define how to identify a unidirectionalPointToMultiP= oint path, and from the Introduction of this document, the P2MP seems not b= e included. 5. mplsOamIdMegSubOperStatus OBJECT-TYPE SYNTAX BITS { megDown (0), meDown (1), oamAppDown (2), pathDown (3) } The bit 0 (megDown) indicates the MEG is down. The bit 1 (meDown) indicates the ME table is down. The bit 2 (oamAppDown) indicates that the OAM application has notified that the entity (LSP or PW) monitored by this MEG is down. Currently, BFD is the only supported OAM application. The bit 3 (pathDown) indicates that the underlying LSP or PW is down." I am not sure what's the mean of "down" here, especially the mean of "MEG i= s down", "ME table is down" and "LSP and PW is down"? 6. mplsOamIdMeServicePointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This variable represents a pointer to the MPLS-TP transport path. This value MUST point at an entry in the mplsTunnelEntry if mplsOamIdMegServicePointerType is configured as lsp (1) or at an entry in the pwEntry if mplsOamIdMegServicePointerType is configured as pseudowire (2). How about mplsOamIdMegServicePointerTypesection is configured as section (3= )? And draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtEntry for MPLS-TP tun= nels and pwExtEntry for MPLS-TP PWs, should the above mplsTunnelEntry and p= wEntry be changed to mplsTunnelExtEntry and pwExtEntry? 7. mplsOamIdMegServicePointerType OBJECT-TYPE SYNTAX INTEGER { lsp (1), pseudowire (2), section (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the service type for the MEG. If the service type indicates lsp, the service pointer in mplsOamIdMeTable points to an entry in the mplsTunnelTable [RFC3812]. Since draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtTable for MPLS-TP T= unnels and Pws, should the above mplsTunnelTable be mplsTunnelExtTable and = reference be draft-ietf-mpls-tp-te-mib-08? Best regards, Mach > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, August 21, 2014 6:31 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Joan Cucchiar= a; > Mach Chen; > Subject: Shepherds for MPLS MIB modules >=20 > Working Group, >=20 > We have for some time been looking for someone to help us shepherding our > MIB modules. I'm happy to announce that Mach Chen and Young Lee has agree= d > to help us. >=20 > Please help Mach and Young as they start working with the documents. >=20 > We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id-mib. >=20 > Further shepherd assignments will be done as soon as the details are sort= ed out. >=20 >=20 > /Loa > for the mpls wg chairs > -- >=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 Fri Aug 29 04:43:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9AD1A0102 for ; Fri, 29 Aug 2014 04:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 KhgZCF6I2oxd for ; Fri, 29 Aug 2014 04:42:32 -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 CB0C01A011B for ; Fri, 29 Aug 2014 04:42:31 -0700 (PDT) Received: from [192.168.0.188] (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 35BEC18013DA; Fri, 29 Aug 2014 13:42:30 +0200 (CEST) Message-ID: <54006726.1020206@pi.nu> Date: Fri, 29 Aug 2014 13:42:30 +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: "Rabadan, Jorge (Jorge)" , "George, Wes" , "mpls@ietf.org" References: <20140825131717.30746.87087.idtracker@ietfa.amsl.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/mpls/51eD15PD66_Do-xUGusuz34UIqE Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 11:42:54 -0000 Jorge, We will request publication now - there will be an AD evaluation and an IETF last call, we will fold your comments in as part of one of these reviews. /Loa On 2014-08-28 18:52, Rabadan, Jorge (Jorge) wrote: > Wes, > > Not an EVPN author, but I have some a couple of comments about section > 3.3.1.1: > > - Minor: EVPN is a separate AFI/SAFI so I would not make it a sub-section > of L2VPN, but I would rather put it at the same level. Now that the L2VPN > WG will no longer be a WG on its own, I would not classify EVPN as L2VPN > anymore. EVPN can even do L3. > > - Why does EVPN inherit RFC 6074 gaps? I don’t see any gap in any of the > EVPN defined route types or procedures. I would remove that and keep the > dependency on mLDP and RFC 7117 (if any) for the PMSI tunnel attribute > that EVPN inherits. Other than that I see no gaps in EVPN. > > Thank you. > Jorge > > > -----Original Message----- > From: , Wes > Date: Monday, August 25, 2014 at 6:25 AM > To: "mpls@ietf.org" > Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt > >> This addresses the comments from Alvaro's excellent and thorough review at >> WGLC, and we think it's ready to go. >> >> The text in the EVPN section (3.3.1.1) is still subject to change, as we >> have not heard back from the authors of the EVPN draft, so the current >> text is based on my admittedly unskilled review. >> >> Thanks, >> >> Wes >> >> >> >> On 8/25/14, 9:17 AM, "internet-drafts@ietf.org" >> wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Multiprotocol Label Switching Working >>> Group of the IETF. >>> >>> Title : Gap Analysis for Operating IPv6-only MPLS >>> Networks >>> Authors : Wesley George >>> Carlos Pignataro >>> Filename : draft-ietf-mpls-ipv6-only-gap-02.txt >>> Pages : 26 >>> Date : 2014-08-25 >>> >>> Abstract: >>> This document reviews the Multiprotocol Label Switching (MPLS) >>> protocol suite in the context of IPv6 and identifies gaps that must >>> be addressed in order to allow MPLS-related protocols and >>> applications to be used with IPv6-only networks. This document is >>> not intended to highlight a particular vendor's implementation (or >>> lack thereof) in the context of IPv6-only MPLS functionality, but >>> rather to focus on gaps in the standards defining the MPLS suite. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-only-gap/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-mpls-ipv6-only-gap-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ipv6-only-gap-02 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject to >> copyright belonging to Time Warner Cable. This E-mail is intended solely >> for the use of the individual or entity to which it is addressed. If you >> are not the intended recipient of this E-mail, you are hereby notified >> that any dissemination, distribution, copying, or action taken in >> relation to the contents of and attachments to this E-mail is strictly >> prohibited and may be unlawful. If you have received this E-mail in >> error, please notify the sender immediately and permanently delete the >> original and any copy of this E-mail and any printout. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Aug 29 05:19:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D0D1A01E5 for ; Fri, 29 Aug 2014 05:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 ElXXngjxZlP4 for ; Fri, 29 Aug 2014 05:19:38 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B791A01D6 for ; Fri, 29 Aug 2014 05:19:24 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A2B6F77BB07D0; Fri, 29 Aug 2014 12:19:20 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s7TCJMIB008840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 14:19:22 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 29 Aug 2014 14:19:22 +0200 From: "Rabadan, Jorge (Jorge)" To: Loa Andersson , "George, Wes" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt Thread-Index: AQHPwGcQtPprax3VI0ytCwWPC4ptBpvhLaGAgAR7t4CAAbDzAP//lPGA Date: Fri, 29 Aug 2014 12:19:22 +0000 Message-ID: References: <20140825131717.30746.87087.idtracker@ietfa.amsl.com> <54006726.1020206@pi.nu> In-Reply-To: <54006726.1020206@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: <42C3BCD4EFEC4F4EB2BC4D9674564C3D@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xRnQmqZNX6ySsyt7I_4W_upYS04 Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 12:19:40 -0000 T0suIFRoYW5rIHlvdSwgTG9hLg0KDQpKb3JnZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51Pg0KRGF0ZTogRnJpZGF5LCBBdWd1c3Qg MjksIDIwMTQgYXQgNDo0MiBBTQ0KVG86IEpvcmdlIFJhYmFkYW4gPGpvcmdlLnJhYmFkYW5AYWxj YXRlbC1sdWNlbnQuY29tPiwgIkdlb3JnZSwgV2VzIg0KPHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5j b20+LCAibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbXBscy1pcHY2LW9ubHktZ2FwLTAyLnR4dA0KDQo+Sm9y Z2UsDQo+DQo+V2Ugd2lsbCByZXF1ZXN0IHB1YmxpY2F0aW9uIG5vdyAtIHRoZXJlIHdpbGwgYmUg YW4gQUQgZXZhbHVhdGlvbiBhbmQgYW4NCj5JRVRGIGxhc3QgY2FsbCwgd2Ugd2lsbCBmb2xkIHlv dXIgY29tbWVudHMgaW4gYXMgcGFydCBvZiBvbmUgb2YgdGhlc2UNCj5yZXZpZXdzLg0KPg0KPi9M b2ENCj4NCj5PbiAyMDE0LTA4LTI4IDE4OjUyLCBSYWJhZGFuLCBKb3JnZSAoSm9yZ2UpIHdyb3Rl Og0KPj4gV2VzLA0KPj4NCj4+IE5vdCBhbiBFVlBOIGF1dGhvciwgYnV0IEkgaGF2ZSBzb21lIGEg Y291cGxlIG9mIGNvbW1lbnRzIGFib3V0IHNlY3Rpb24NCj4+IDMuMy4xLjE6DQo+Pg0KPj4gLSBN aW5vcjogRVZQTiBpcyBhIHNlcGFyYXRlIEFGSS9TQUZJIHNvIEkgd291bGQgbm90IG1ha2UgaXQg YQ0KPj5zdWItc2VjdGlvbg0KPj4gb2YgTDJWUE4sIGJ1dCBJIHdvdWxkIHJhdGhlciBwdXQgaXQg YXQgdGhlIHNhbWUgbGV2ZWwuIE5vdyB0aGF0IHRoZQ0KPj5MMlZQTg0KPj4gV0cgd2lsbCBubyBs b25nZXIgYmUgYSBXRyBvbiBpdHMgb3duLCBJIHdvdWxkIG5vdCBjbGFzc2lmeSBFVlBOIGFzIEwy VlBODQo+PiBhbnltb3JlLiBFVlBOIGNhbiBldmVuIGRvIEwzLg0KPj4NCj4+IC0gV2h5IGRvZXMg RVZQTiBpbmhlcml0IFJGQyA2MDc0IGdhcHM/IEkgZG9u4oCZdCBzZWUgYW55IGdhcCBpbiBhbnkg b2YgdGhlDQo+PiBFVlBOIGRlZmluZWQgcm91dGUgdHlwZXMgb3IgcHJvY2VkdXJlcy4gSSB3b3Vs ZCByZW1vdmUgdGhhdCBhbmQga2VlcCB0aGUNCj4+IGRlcGVuZGVuY3kgb24gbUxEUCBhbmQgUkZD IDcxMTcgKGlmIGFueSkgZm9yIHRoZSBQTVNJIHR1bm5lbCBhdHRyaWJ1dGUNCj4+IHRoYXQgRVZQ TiBpbmhlcml0cy4gT3RoZXIgdGhhbiB0aGF0IEkgc2VlIG5vIGdhcHMgaW4gRVZQTi4NCj4+DQo+ PiBUaGFuayB5b3UuDQo+PiBKb3JnZQ0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4gRnJvbTogPEdlb3JnZT4sIFdlcyA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT4N Cj4+IERhdGU6IE1vbmRheSwgQXVndXN0IDI1LCAyMDE0IGF0IDY6MjUgQU0NCj4+IFRvOiAibXBs c0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtbXBscy1pcHY2LW9ubHktZ2FwLTAyLnR4dA0KPj4NCj4+PiBUaGlz IGFkZHJlc3NlcyB0aGUgY29tbWVudHMgZnJvbSBBbHZhcm8ncyBleGNlbGxlbnQgYW5kIHRob3Jv dWdoDQo+Pj5yZXZpZXcgYXQNCj4+PiBXR0xDLCBhbmQgd2UgdGhpbmsgaXQncyByZWFkeSB0byBn by4NCj4+Pg0KPj4+IFRoZSB0ZXh0IGluIHRoZSBFVlBOIHNlY3Rpb24gKDMuMy4xLjEpIGlzIHN0 aWxsIHN1YmplY3QgdG8gY2hhbmdlLCBhcw0KPj4+d2UNCj4+PiBoYXZlIG5vdCBoZWFyZCBiYWNr IGZyb20gdGhlIGF1dGhvcnMgb2YgdGhlIEVWUE4gZHJhZnQsIHNvIHRoZSBjdXJyZW50DQo+Pj4g dGV4dCBpcyBiYXNlZCBvbiBteSBhZG1pdHRlZGx5IHVuc2tpbGxlZCByZXZpZXcuDQo+Pj4NCj4+ PiBUaGFua3MsDQo+Pj4NCj4+PiBXZXMNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiA4LzI1LzE0LCA5 OjE3IEFNLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIg0KPj4+PGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4NCj4+PiB3cm90ZToNCj4+Pg0KPj4+Pg0KPj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+Pj4gZGly ZWN0b3JpZXMuDQo+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE11bHRpcHJv dG9jb2wgTGFiZWwgU3dpdGNoaW5nIFdvcmtpbmcNCj4+Pj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+ Pj4+DQo+Pj4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogR2FwIEFuYWx5c2lzIGZvciBPcGVy YXRpbmcgSVB2Ni1vbmx5IE1QTFMNCj4+Pj4gTmV0d29ya3MNCj4+Pj4gICAgICAgICBBdXRob3Jz ICAgICAgICAgOiBXZXNsZXkgR2VvcmdlDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg Q2FybG9zIFBpZ25hdGFybw0KPj4+PiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1tcGxzLWlwdjYtb25seS1nYXAtMDIudHh0DQo+Pj4+ICAgICAgICBQYWdlcyAgICAgICAgICAg OiAyNg0KPj4+PiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0wOC0yNQ0KPj4+Pg0KPj4+ PiBBYnN0cmFjdDoNCj4+Pj4gICAgVGhpcyBkb2N1bWVudCByZXZpZXdzIHRoZSBNdWx0aXByb3Rv Y29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykNCj4+Pj4gICAgcHJvdG9jb2wgc3VpdGUgaW4gdGhl IGNvbnRleHQgb2YgSVB2NiBhbmQgaWRlbnRpZmllcyBnYXBzIHRoYXQgbXVzdA0KPj4+PiAgICBi ZSBhZGRyZXNzZWQgaW4gb3JkZXIgdG8gYWxsb3cgTVBMUy1yZWxhdGVkIHByb3RvY29scyBhbmQN Cj4+Pj4gICAgYXBwbGljYXRpb25zIHRvIGJlIHVzZWQgd2l0aCBJUHY2LW9ubHkgbmV0d29ya3Mu ICBUaGlzIGRvY3VtZW50IGlzDQo+Pj4+ICAgIG5vdCBpbnRlbmRlZCB0byBoaWdobGlnaHQgYSBw YXJ0aWN1bGFyIHZlbmRvcidzIGltcGxlbWVudGF0aW9uIChvcg0KPj4+PiAgICBsYWNrIHRoZXJl b2YpIGluIHRoZSBjb250ZXh0IG9mIElQdjYtb25seSBNUExTIGZ1bmN0aW9uYWxpdHksIGJ1dA0K Pj4+PiAgICByYXRoZXIgdG8gZm9jdXMgb24gZ2FwcyBpbiB0aGUgc3RhbmRhcmRzIGRlZmluaW5n IHRoZSBNUExTIHN1aXRlLg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAvDQo+Pj4+DQo+Pj4+IFRo ZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+PiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtaXB2Ni1vbmx5LWdhcC0wMg0KPj4+ Pg0KPj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1p cHY2LW9ubHktZ2FwLTAyDQo+Pj4+DQo+Pj4+DQo+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+Pj4+IHN1Ym1pc3Np b24NCj4+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+Pj4NCj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+PiBtcGxzQGll dGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K Pj4+DQo+Pj4NCj4+PiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZQ0KPj4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3 aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QNCj4+PnRvDQo+Pj4g Y29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMg aW50ZW5kZWQNCj4+PnNvbGVseQ0KPj4+IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmDQo+Pj55b3UNCj4+PiBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkDQo+Pj4gdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5n LCBvciBhY3Rpb24gdGFrZW4gaW4NCj4+PiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5k IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5DQo+Pj4gcHJvaGliaXRlZCBh bmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbg0K Pj4+IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1h bmVudGx5IGRlbGV0ZSB0aGUNCj4+PiBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9y Zw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtcGxz IG1haWxpbmcgbGlzdA0KPj4gbXBsc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo+Pg0KPg0KPi0tIA0KPg0KPg0KPkxvYSBBbmRlcnNzb24g ICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+U2Vu aW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj5IdWF3 ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQN Cg0K From nobody Fri Aug 29 05:49:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4A31A02A3 for ; Fri, 29 Aug 2014 05:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 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=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVbmSBLPrvrx for ; Fri, 29 Aug 2014 05:49:40 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7191A0296 for ; Fri, 29 Aug 2014 05:49:38 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,424,1406606400"; d="scan'208";a="496312687" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 29 Aug 2014 08:48:37 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 29 Aug 2014 08:49:37 -0400 From: "George, Wes" To: "Rabadan, Jorge (Jorge)" , "mpls@ietf.org" Date: Fri, 29 Aug 2014 08:49:36 -0400 Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt Thread-Index: Ac/Dh7BxgJUhyS8YQXGI3IuXdPocXA== Message-ID: References: <20140825131717.30746.87087.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 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/mpls/c8K6tOOqJCaVtehxeisQCaL4DRU Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 12:49:41 -0000 T24gOC8yOC8xNCwgMTI6NTIgUE0sICJSYWJhZGFuLCBKb3JnZSAoSm9yZ2UpIg0KPGpvcmdlLnJh YmFkYW5AYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToNCg0KDQo+LSBNaW5vcjogRVZQTiBpcyBh IHNlcGFyYXRlIEFGSS9TQUZJIHNvIEkgd291bGQgbm90IG1ha2UgaXQgYSBzdWItc2VjdGlvbg0K Pm9mIEwyVlBOLCBidXQgSSB3b3VsZCByYXRoZXIgcHV0IGl0IGF0IHRoZSBzYW1lIGxldmVsLiBO b3cgdGhhdCB0aGUgTDJWUE4NCj5XRyB3aWxsIG5vIGxvbmdlciBiZSBhIFdHIG9uIGl0cyBvd24s IEkgd291bGQgbm90IGNsYXNzaWZ5IEVWUE4gYXMgTDJWUE4NCj5hbnltb3JlLiBFVlBOIGNhbiBl dmVuIGRvIEwzLg0KV0ddIE15IHJlYWQgd2FzIHRoYXQgaXQgd2FzIHVzaW5nIEwyVlBOJ3MgQUZJ LCBidXQgZGVmaW5pbmcgYSBuZXcgU0FGSSwgc28NCmJ5IHN0cmljdCBpbnRlcnByZXRhdGlvbiwg aXQgaXMgYSBzdWJ0eXBlIG9mIEwyVlBOLiBJTUhPIGl0J3MgYSBiaXQNCmhhaXItc3BsaXR0aW5n IGVpdGhlciB3YXkuIFRoZSBhYnNlbmNlIG9yIHByZXNlbmNlIG9mIGEgV0cgZG9lc24ndCByZWFs bHkNCmZpZ3VyZSBpbnRvIG15IHRob3VnaHQgcHJvY2VzcyB3aGVuIGl0IGNvbWVzIHRvIGNsYXNz aWZpY2F0aW9uLCBlc3BlY2lhbGx5DQp3aXRoIHRoZSBvdmVyYWxsIHJlc3BpbiBvZiB0aGUgV0dz IGluIFJvdXRpbmcgQXJlYSwgYnV0IEknbSBvcGVuIHRvDQpmdXJ0aGVyIGRpc2N1c3Npb24gaWYg aXQgcmVhbGx5IG5lZWRzIHRvIGJlIGNoYW5nZWQuDQoNCj4NCj4tIFdoeSBkb2VzIEVWUE4gaW5o ZXJpdCBSRkMgNjA3NCBnYXBzPyBJIGRvbuKAmXQgc2VlIGFueSBnYXAgaW4gYW55IG9mIHRoZQ0K PkVWUE4gZGVmaW5lZCByb3V0ZSB0eXBlcyBvciBwcm9jZWR1cmVzLiBJIHdvdWxkIHJlbW92ZSB0 aGF0IGFuZCBrZWVwIHRoZQ0KPmRlcGVuZGVuY3kgb24gbUxEUCBhbmQgUkZDIDcxMTcgKGlmIGFu eSkgZm9yIHRoZSBQTVNJIHR1bm5lbCBhdHRyaWJ1dGUNCj50aGF0IEVWUE4gaW5oZXJpdHMuIE90 aGVyIHRoYW4gdGhhdCBJIHNlZSBubyBnYXBzIGluIEVWUE4uDQpXR10gZ29vZCB0byBrbm93IEkg d2FzIG1vc3RseSByZWFkaW5nIHRoaXMgcmlnaHQuIFRoZSByZWFzb24gdGhhdCBJIHNhaWQNCnRo YXQgaXQgaW5oZXJpdHMgNjA3NCBnYXBzIGlzIHRoYXQgaXQgY2FuIHVzZSBMRFAuIFRoZXJlZm9y ZSBpdCB3b24ndCB3b3JrDQpvdmVyIExEUCBvbiBhbiBJUHY2LW9ubHkgbmV0d29yayB1bnRpbCB0 aGUgZ2FwcyBpbiBMRFAgYXJlIGZpeGVkLCByaWdodD8NCk9yIGlzIHRoZXJlIHNvbWV0aGluZyBJ J20gbWlzc2luZyB0aGF0IG1ha2VzIHRoYXQgYW4gaW52YWxpZCBsb2dpY2FsIGxlYXA/DQoNClRo YW5rcyENCg0KV2VzIEdlb3JnZQ0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0 aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29w eXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3Nl bWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0 aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMg c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBv ZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Fri Aug 29 07:03:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901AD1A0384 for ; Fri, 29 Aug 2014 07:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 gmbhJzIVv-ew for ; Fri, 29 Aug 2014 07:03:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBC31A0382 for ; Fri, 29 Aug 2014 07:03:12 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 14F13408C865; Fri, 29 Aug 2014 14:03:08 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s7TE1pf5023683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 16:03:05 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 29 Aug 2014 16:02:11 +0200 From: "Rabadan, Jorge (Jorge)" To: "George, Wes" , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt Thread-Index: AQHPwGcQtPprax3VI0ytCwWPC4ptBpvhLaGAgAR7t4CAAcOzAP//nuyA Date: Fri, 29 Aug 2014 14:02:10 +0000 Message-ID: References: <20140825131717.30746.87087.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/c5C2HTC02_sTor_-1i6_zIcccYE Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 14:03:14 -0000 SGkgV2VzLA0KDQpQbGVhc2Ugc2VlIGluLWxpbmUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiA8R2VvcmdlPiwgV2VzIDx3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPg0KRGF0 ZTogRnJpZGF5LCBBdWd1c3QgMjksIDIwMTQgYXQgNTo0OSBBTQ0KVG86IEpvcmdlIFJhYmFkYW4g PGpvcmdlLnJhYmFkYW5AYWxjYXRlbC1sdWNlbnQuY29tPiwgIm1wbHNAaWV0Zi5vcmciDQo8bXBs c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbXBsc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1t cGxzLWlwdjYtb25seS1nYXAtMDIudHh0DQoNCj5PbiA4LzI4LzE0LCAxMjo1MiBQTSwgIlJhYmFk YW4sIEpvcmdlIChKb3JnZSkiDQo+PGpvcmdlLnJhYmFkYW5AYWxjYXRlbC1sdWNlbnQuY29tPiB3 cm90ZToNCj4NCj4NCj4+LSBNaW5vcjogRVZQTiBpcyBhIHNlcGFyYXRlIEFGSS9TQUZJIHNvIEkg d291bGQgbm90IG1ha2UgaXQgYSBzdWItc2VjdGlvbg0KPj5vZiBMMlZQTiwgYnV0IEkgd291bGQg cmF0aGVyIHB1dCBpdCBhdCB0aGUgc2FtZSBsZXZlbC4gTm93IHRoYXQgdGhlIEwyVlBODQo+PldH IHdpbGwgbm8gbG9uZ2VyIGJlIGEgV0cgb24gaXRzIG93biwgSSB3b3VsZCBub3QgY2xhc3NpZnkg RVZQTiBhcyBMMlZQTg0KPj5hbnltb3JlLiBFVlBOIGNhbiBldmVuIGRvIEwzLg0KPldHXSBNeSBy ZWFkIHdhcyB0aGF0IGl0IHdhcyB1c2luZyBMMlZQTidzIEFGSSwgYnV0IGRlZmluaW5nIGEgbmV3 IFNBRkksIHNvDQo+Ynkgc3RyaWN0IGludGVycHJldGF0aW9uLCBpdCBpcyBhIHN1YnR5cGUgb2Yg TDJWUE4uIElNSE8gaXQncyBhIGJpdA0KPmhhaXItc3BsaXR0aW5nIGVpdGhlciB3YXkuIFRoZSBh YnNlbmNlIG9yIHByZXNlbmNlIG9mIGEgV0cgZG9lc24ndCByZWFsbHkNCj5maWd1cmUgaW50byBt eSB0aG91Z2h0IHByb2Nlc3Mgd2hlbiBpdCBjb21lcyB0byBjbGFzc2lmaWNhdGlvbiwgZXNwZWNp YWxseQ0KPndpdGggdGhlIG92ZXJhbGwgcmVzcGluIG9mIHRoZSBXR3MgaW4gUm91dGluZyBBcmVh LCBidXQgSSdtIG9wZW4gdG8NCj5mdXJ0aGVyIGRpc2N1c3Npb24gaWYgaXQgcmVhbGx5IG5lZWRz IHRvIGJlIGNoYW5nZWQuDQoNCltKT1JHRV0gSWYgdGhlIGNsYXNzaWZpY2F0aW9uIGlzIGJhc2Vk IG9uIHRoZSBBRkksIGl0IGlzIG9rLiBJIGFncmVlIGl0IGlzDQpoYWlyLXNwbGl0dGluZy4NCg0K Pg0KPj4NCj4+LSBXaHkgZG9lcyBFVlBOIGluaGVyaXQgUkZDIDYwNzQgZ2Fwcz8gSSBkb27igJl0 IHNlZSBhbnkgZ2FwIGluIGFueSBvZiB0aGUNCj4+RVZQTiBkZWZpbmVkIHJvdXRlIHR5cGVzIG9y IHByb2NlZHVyZXMuIEkgd291bGQgcmVtb3ZlIHRoYXQgYW5kIGtlZXAgdGhlDQo+PmRlcGVuZGVu Y3kgb24gbUxEUCBhbmQgUkZDIDcxMTcgKGlmIGFueSkgZm9yIHRoZSBQTVNJIHR1bm5lbCBhdHRy aWJ1dGUNCj4+dGhhdCBFVlBOIGluaGVyaXRzLiBPdGhlciB0aGFuIHRoYXQgSSBzZWUgbm8gZ2Fw cyBpbiBFVlBOLg0KPldHXSBnb29kIHRvIGtub3cgSSB3YXMgbW9zdGx5IHJlYWRpbmcgdGhpcyBy aWdodC4gVGhlIHJlYXNvbiB0aGF0IEkgc2FpZA0KPnRoYXQgaXQgaW5oZXJpdHMgNjA3NCBnYXBz IGlzIHRoYXQgaXQgY2FuIHVzZSBMRFAuIFRoZXJlZm9yZSBpdCB3b24ndCB3b3JrDQo+b3ZlciBM RFAgb24gYW4gSVB2Ni1vbmx5IG5ldHdvcmsgdW50aWwgdGhlIGdhcHMgaW4gTERQIGFyZSBmaXhl ZCwgcmlnaHQ/DQo+T3IgaXMgdGhlcmUgc29tZXRoaW5nIEknbSBtaXNzaW5nIHRoYXQgbWFrZXMg dGhhdCBhbiBpbnZhbGlkIGxvZ2ljYWwgbGVhcD8NCg0KW0pPUkdFXSBSaWdodC4gRVZQTiBjYW4g dXNlIExEUCB0dW5uZWxzIGFzIGEgdHJhbnNwb3J0IG1lY2hhbmlzbSwgc28gSQ0Kd291bGQga2Vl cCB0aGUgcmVmZXJlbmNlIHRvIHNlY3Rpb24gMy4yLjEuIEhvd2V2ZXIgRVZQTiBkb2VzIG5vdCB1 c2UgdGhlDQpSRkMgNjA3NCBwcm9jZWR1cmVzIHRvIGRpc2NvdmVyIG1lbWJlcnNoaXAuIEl0IHRh a2VzIHNvbWUgcHJvY2VkdXJlcyBmcm9tDQpSRkMgNzExNyBidXQgcmVwbGFjaW5nIFJGQyA2MDc0 IHByb2NlZHVyZXMgZm9yIGl0cyBvd24gZGlzY292ZXJ5DQptZWNoYW5pc21zLg0KSSB3b3VsZCB0 aGVuIG1vZGlmeSB0aGUgdGV4dCBpbiB0aGlzIHdheToNCiJCZWNhdXNlIGl0IGNhbiB1c2UgZnVu Y3Rpb25zIGluIExEUCBhbmQgbUxEUCBpdCBpbmhlcml0cyBnYXBzIHByZXZpb3VzbHkNCmlkZW50 aWZpZWQgaW4gTERQIChTZWN0aW9uIDMuMi4xKS4gT25jZSB0aG9zZSBnYXBzIGFyZSByZXNvbHZl ZCwgaXQgc2hvdWxkDQpmdW5jdGlvbiBwcm9wZXJseQ0KICAgb24gSVB2Ni1vbmx5IG5ldHdvcmtz IGFzIGRlZmluZWQu4oCdDQoNCg0KTGV0IG1lIGtub3cgaWYgSSBhbSBtaXNzaW5nIHNvbWV0aGlu Zy4NClRoYW5rIHlvdSENCiANCg0KPg0KPlRoYW5rcyENCj4NCj5XZXMgR2VvcmdlDQo+DQo+DQo+ VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBX YXJuZXIgQ2FibGUNCj5wcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdl ZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvDQo+Y29weXJpZ2h0IGJlbG9uZ2luZyB0byBU aW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQo+Zm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3Nl ZC4gSWYgeW91DQo+YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWls LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZA0KPnRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3Ry aWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluDQo+cmVsYXRpb24gdG8gdGhlIGNv bnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseQ0KPnBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4NCj5lcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlDQo+b3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMg RS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQoNCg== From nobody Fri Aug 29 17:25:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FA81A7026 for ; Fri, 29 Aug 2014 17:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 sVaSDZG0Nmi3 for ; Fri, 29 Aug 2014 17:25:49 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234421A7021 for ; Fri, 29 Aug 2014 17:25:48 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 082D91E73DB0C; Sat, 30 Aug 2014 00:25:44 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s7U0PkPK000872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 20:25:46 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Fri, 29 Aug 2014 20:25:46 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) Thread-Index: AQHPtkReGJe0hsllSUWt55jdwggY6ZvXguRQgAXkqoCACAl2gIAC82tw Date: Sat, 30 Aug 2014 00:25:45 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D9471CE50@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <53EA3666.2040004@pi.nu> <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> <9ace61def77942938bc577e4b6782680@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7HR-uXN_n6123ig693wfmwMXy1A Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 00:25:52 -0000 Hi Rajiv, See inline below for some follow-up. Regards, Mustapha. > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Wednesday, August 27, 2014 7:19 PM > To: Ross Callon; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-ipv6@tools.ietf.org > Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc = closed) >=20 >=20 > If this draft were to address the interoperability with rfc5036 non-compl= iant > implementations, then it would be easier to rather leverage the =8Ctransp= ort > preference=B9 TLV that is already part of the version 13. > This TLV was defined after the getting Adrian's and George=B9s feedback. >=20 > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-13#section-6.1.1 MA> It is not a good idea to overload this new TLV with a capability advert= isement role. LDP has its own capability advertisement mechanism and there = is no need to confuse implementations with the handling of two mechanisms. =20 > The reason for not agreeing to the alternate solution (of using IP Prefix= capability > etc.) is 2-fold: >=20 > - not forward compatible (consider a deployment 5 yrs from now - IPv6-onl= y MPLS > network - now, the LSR will be expecting an unnecessary IPv6 prefix capab= ility > advertisement, and that=B9s not optimal, if not annoying) MA> IPv6-only network is not synonymous with a single FEC type network. It = will support many types of FECs in addition to the IPv6 prefix FEC: mLDP I= Pv6 FECs, PW FECs, IPv4 prefix FEC, etc. The LDP capabilities have been des= igned for the purpose of explicitly enabling or disabling capabilities incl= uding FEC type support on a given session. > - not 100% backward compatible (does not solve the advertisement of v6 ad= dress > binding to a v4 neighbor (which can also cause an outage to a non-complia= nt peer)) MA> I think it makes sense to tie the exchange of both IPv6 address message= s and IPv6 prefix FECs to the advertisement of the IPv6 capability by both = peers. If however there is a use case for decoupling the advertising of IPv= 6 addresses from IPv6 FECs, then a separate capability can be devised for a= ddresses but I do not think we need it. > Thanks. >=20 >=20 > -- > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Ross Callon > Date: Friday, August 22, 2014 at 4:34 PM > To: Mustapha Aissaoui , > "mpls@ietf.org" > Cc: "mpls-chairs@tools.ietf.org" , > "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" > > Subject: RE: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc > closed) > Resent-From: > Resent-To: Carlos Pignataro , Rajiv Papneja > , Rajiv Asati , Vishwas Manra= l > , , Loa Andersson , > Ross Callon , MARTIN VIGOUREUX > > Resent-Date: Friday, August 22, 2014 at 4:35 PM >=20 > >> The proposed solution is to have implementations complying to this dra= ft > >> advertise the IPv6 prefix state advertisement control capability > >> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization messag= e > >> explicitly indicating support for LDP IPv6. Without the peer advertisi= ng > >> this capability, an LSR must not send IPv6 addresses and FECs to that > >>peer. > > > >Speaking as an individual contributor, this seems IMHO to be the right > >solution (noting that, in final text as would be published in an RFC, th= e > >"must not" in the last sentence should be capitalized). > > > >Thanks, Ross > > > >-----Original Message----- > >From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustaph= a > >(Mustapha) > >Sent: Tuesday, August 19, 2014 3:19 AM > >To: mpls@ietf.org > >Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-ipv6@tools.ietf.org > >Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc > >closed) > > > >Dear all, > >The following are the details of the issue we found and the proposed > >solution. We shared this first with the authors to get initial feedback. > > > >When an LSR which supports LDP IPv6 according to this draft is in a LAN > >with a broadcast interface, it can peer with LSRs which support this > >draft and LSRs which do not. When it peers using IPv4 LDP control plane > >with an LSR which does not support this draft, we have seen during our > >testing an issue that the advertisement of IPv6 addresses or IPv6 FECs t= o > >that peer will cause it to bring down the IPv4 LDP session. > > > >In other words, there are deployed LDP implementations which are > >compliant to RFC 5036 for LDP IPv4 but are not compliant to RFC 5036 whe= n > >it comes to handling IPv6 address or IPv6 FECs over an LDP IPv4 session. > >This is making us very concerned that when users enable dual-stack LDP > >IPv4/IPv6, they will bring down LDP IPv4 sessions which have been workin= g > >in a multi-vendor environments for so many years. > > > >The proposed solution is to have implementations complying to this draft > >advertise the IPv6 prefix state advertisement control capability > >(draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization message > >explicitly indicating support for LDP IPv6. Without the peer advertising > >this capability, an LSR must not send IPv6 addresses and FECs to that > >peer. > > > >This approach is safer and has been followed when mLDP FEC was introduce= d > >as explained in Section 2.1 of RFC 6388. Also, this does not introduce > >any new TLV to draft-ietf-mpls-ldp-ipv6. It just makes the exchange of > >LDP IPv6 addresses and FECs conditional to both peers explicitly > >indicating support for IPv6 capability during LDP session initialization= . > > > >We do not feel such a simple change justifies writing a new draft and > >having to deal with backward compatibility of implementations across two > >drafts. > > > >We appreciate your comments on this matter. > > > >Regards, > >Mustapha. > > > > > >> -----Original Message----- > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > >> Sent: Tuesday, August 12, 2014 11:45 AM > >> To: mpls@ietf.org; mpls-chairs@tools.ietf.org; > >>draft-ietf-mpls-ldp-ipv6@tools.ietf.org > >> Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc > >>closed) > >> > >> Working Group, > >> > >> During what we thought would be a short wglc on draft-ietf-mpls-ldp-ip= v6 > >> http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html > >> we had a comment that stopped us from continuing progressing the draft= . > >> > >> The short working group last call is now closed! > >> > >> The comment we refer to was raised in a private mail to the working > >>group chairs > >> and the draft authors. > >> > >> It says that there are a problem with some RFC 5036 non-compliant > >> implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no > >>detailed > >> description of the exact problems. > >> > >> We strongly encourage the people that made the comment(s) to write-up > >>the > >> problem, either as > >> > >> - a new draft (preferred); or > >> - in a mail to the working group mailing list > >> > >> Once we an agreement to write a new draft or the write-up to the > >>mailing, we will > >> continue to ask the working group to see if we can agree to a way to > >>progress. We > >> like to see this write-up before September 1. Failing this we will > >>continue to progress > >> the draft-ietf-mpls-ldp-ipv6 as is. > >> > >> /Loa > >> for the working group chairs > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Aug 29 20:32:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904671A700C for ; Fri, 29 Aug 2014 20:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 e_8jfdrRK_6T for ; Fri, 29 Aug 2014 20:32:38 -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 EDC431A700B for ; Fri, 29 Aug 2014 20:32:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIW61193; Sat, 30 Aug 2014 03:32:36 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Aug 2014 04:32:35 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Sat, 30 Aug 2014 11:32:33 +0800 From: Mach Chen To: "Sam K. Aldrin" , "Nobo Akiya (nobo)" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPvOsdwjhGcp6uiEqhBQ5TeCNTy5vbARkAgABOkoCAA/otAIACKNwAgAcIvhA= Date: Sat, 30 Aug 2014 03:32:33 +0000 Message-ID: References: In-Reply-To: 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/mpls/RMnlpveNER_KDS8uU5A2JgVTF-g Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 03:32:39 -0000 Hi Sam, Some replies inline... Sniped. >=20 > Let us take the MPLS TP with IP on every node. > The scenario you are talking about is 'associated bidirectional' tunnel. > Just because a 'vendor' implemented certain default method doesn't requir= e > new TLV support. > For associated bidirectional tunnel with IP on every node, perform reply = mode as > IP. > I don't think RFC4379 warrants certain default type to be fixed type for = a given > FEC. >=20 > [NOBO] What you say is true only if all operators prefer IP return path o= ver > control channel and reverse LSP. I am aware of operators who wants to pre= fer > control channel or reverse LSP whenever available, over IP path. The pref= erence > really varies depending on operators. This is exactly where this extensio= n can > benefit. > %sam - We discussed this before but ended up with opposite conclusion :D.= If > user want to perform return path via lsp or via IP, nothing prevents and = one could > chose either of them. The same goes for bitmap size, selector size etc. Your assumption is that all nodes along the path support both IP and LSP re= turn path, this may not always true. In some mobile backhaul networks that= normally have access and core network parts, the nodes in the access may o= nly support pure MPLS-TP and not support IP forwarding; the nodes in the co= re part normally support IP/MPLS. Then takes the picture in A.2 as an examp= le: +----C------D----+ / \ A'----A------B G---H---H' \ / +----E------F----+ Where A', A, H and H' only support pure MPLS-TP and do not support IP forwa= rding, B and G support both LSP and IP return path, it means that reply mod= e 2 cannot be used when perform traceroute. But when "Reply via reverse LS= P" is used, since C, D, E and F may not have reverse LSP path but have IP = return path, it still cannot traceroute the whole path. In this case, actua= lly, any single reply mode cannot satisfy the requirement.=20 The essential of the Reply Mode Order TLV is to allow multiple reply modes = to be used for a specific LSP, and each responder can select its appropriat= e reply mode to return the echo reply. Best regards, Mach From nobody Fri Aug 29 23:59:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A181A8830; Fri, 29 Aug 2014 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbi3A8bSZ0Qi; Fri, 29 Aug 2014 23:59:25 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F751A8828; Fri, 29 Aug 2014 23:59:24 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-fd-5401215f795d Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DC.CD.05330.F5121045; Sat, 30 Aug 2014 02:57:03 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Sat, 30 Aug 2014 02:59:18 -0400 From: Gregory Mirsky To: Mach Chen , "pwe3@ietf.org" Thread-Topic: Mail regarding draft-ietf-pwe3-mpls-tp-oam-config Thread-Index: Ac/EHzNiM8L42u/HRiC1vK41AsrBRQAADI0w Date: Sat, 30 Aug 2014 06:59:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B828BE1@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPoG68ImOIQfN/EYsLa4Utbi1dyWrR 92kLiwOzR8uRt6weS5b8ZApgiuKySUnNySxLLdK3S+DKmH/vPVPBIc6K9Ts3szUwvmTvYuTk kBAwkei8e44RwhaTuHBvPVsXIxeHkMBRRonbfd1MEM5yRol33/Yxg1SxCRhJvNjYA9YtIuAq 8WPCcqAiDg5mAWWJU3dlQMLCAnYSm96fYIQosZf43vuNCcI2kliw9z4biM0ioCrx4fdXsDG8 Ar4Sz1d8BRsvJBAq8XPlDrB6ToEwieVrFoDVMwId9/3UGrA4s4C4xK0n85kgjhaQWLLnPDOE LSrx8vE/VghbUWJf/3R2iHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmMYrOQjJ2FpGUWkpZZ SFoWMLKsYuQoLU4ty003MtjECIyWYxJsujsY97y0PMQowMGoxMP74DtDiBBrYllxZe4hRmkO FiVx3lm184KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MOqf3pDntETSYJX8vqtmwpteLD/8 S+ihw91v+dMfTpxVkhjDeXTXXC6pXTFBekbK0xbd/SS1sZ1x97RKJwmbRZouYhYiK6o46sst 7pRFLFS+FONlsogheHbkt9dBf18VGfb0b3CP/b71nyd3esLTM52d0QuXXcmUf7qncN6yRQ8M NTuk46zUbymxFGckGmoxFxUnAgCquJSWdwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qhwfaRmdIJSAXt8yTgHbdDUrDjc Cc: "mpls@ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-pwe3-mpls-tp-oam-config X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 06:59:28 -0000 Hi Mach, I think that the draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf intended to be u= sed to configure OAM on MPLS-TP PWs. It lapsed and expired but I'm working = on updating it will publish shortly. Regards, Greg -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Mach Chen Sent: Friday, August 29, 2014 11:54 PM To: pwe3@ietf.org Subject: [PWE3] Mail regarding draft-ietf-pwe3-mpls-tp-oam-config Hi, We submitted an update before Toronto meeting, and are working an update to= refine and polish the document.=20 This draft intends to solve a requirement (Requirement 51) of MPLS-TP: "If the control plane is used, it MUST support the configuration and modification of OAM maintenance points as well as the activation/ deactivation of OAM when the transport path or transport service is established or modified (Requirement 51)[RFC5654]. " We'd really like more reviews and feedbacks from the WG, any comments (is t= his document useful? is the solution technical right? etc.) are welcome!=20 Thanks, Mach _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Sat Aug 30 00:22:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB911A8844; Sat, 30 Aug 2014 00:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 IuPZXI5WBD36; Sat, 30 Aug 2014 00:21:57 -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 AA0121A8849; Sat, 30 Aug 2014 00:21:55 -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 BIW70471; Sat, 30 Aug 2014 07:21:53 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Aug 2014 08:21:53 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Sat, 30 Aug 2014 15:21:50 +0800 From: Mach Chen To: Gregory Mirsky , "pwe3@ietf.org" Thread-Topic: Mail regarding draft-ietf-pwe3-mpls-tp-oam-config Thread-Index: Ac/EHzNiM8L42u/HRiC1vK41AsrBRQAADI0wAAA1eWA= Date: Sat, 30 Aug 2014 07:21:50 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B828BE1@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B828BE1@eusaamb103.ericsson.se> 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/mpls/gzmnWImDkYPtdSNQnxaaRixjxUY Cc: "mpls@ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-pwe3-mpls-tp-oam-config X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 07:22:01 -0000 Hi Greg, Thanks for your prompt response! Yes, I know that draft. Actually, during the MPLS-TP era, there are three r= elevant drafts (this document, one is in ccamp and the one you mentioned) t= hat intend to realize OAM configuration. I guess, the reason for this is th= at there is a requirement (it requires that the control plane MUST support = this function) in RFC5654: "The MPLS-TP control plane MUST support the configuration and modification of OAM maintenance points as well as the activation/ deactivation of OAM when the transport path or transport service is established or modified." These three drafts have been there for a long time, and the draft (http://t= ools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-12) has already= in the publish process.=20 I'd like hear the WG's opinions on how to progress this draft,=20 1. Is this document useful? 2. Is there still interest to progress this draft? Best regards, Mach=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Saturday, August 30, 2014 2:59 PM > To: Mach Chen; pwe3@ietf.org > Cc: mpls@ietf.org > Subject: RE: Mail regarding draft-ietf-pwe3-mpls-tp-oam-config >=20 > Hi Mach, > I think that the draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf intended to be= used to > configure OAM on MPLS-TP PWs. It lapsed and expired but I'm working on > updating it will publish shortly. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Mach Chen > Sent: Friday, August 29, 2014 11:54 PM > To: pwe3@ietf.org > Subject: [PWE3] Mail regarding draft-ietf-pwe3-mpls-tp-oam-config >=20 > Hi, >=20 > We submitted an update before Toronto meeting, and are working an update = to > refine and polish the document. >=20 > This draft intends to solve a requirement (Requirement 51) of MPLS-TP: >=20 > "If the control plane is used, it MUST support the configuration and > modification of OAM maintenance points as well as the activation/ > deactivation of OAM when the transport path or transport service is > established or modified (Requirement 51)[RFC5654]. > " > We'd really like more reviews and feedbacks from the WG, any comments (is= this > document useful? is the solution technical right? etc.) are welcome! >=20 > Thanks, > Mach >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From nobody Sat Aug 30 01:33:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FAA1A06C1 for ; Sat, 30 Aug 2014 01:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 824BogFTXbtp for ; Sat, 30 Aug 2014 01:32:57 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C4E1A006F for ; Sat, 30 Aug 2014 01:32:57 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id p10so2029431pdj.11 for ; Sat, 30 Aug 2014 01:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O+F4pyDsZwkE1jmq7XisfVeHxvJ1naHU3CpTaDOMWmU=; b=YZjg/8vizNwbQ4zjcRQp5xsWcbQQcRTvEQBZCeyvNsmyj7YVav7ZTdiPpnK3kAHA0E HqlDgYpKbrwKKRS/nx4IqsVv6dd7lDDNEP7LIWGopR+IpLkRFR9wj6YH4sSh8U5YZNNL mkJDpTsRRWOycBcW+8wnqrG3fgjk5d/ZdSUOHCdbF8Ht6EvwVB91L/ndi8EfcpNGrXen IqgjSidAgVp71wXjOFyB23GiEqjZWg85NHhj+ZDr/Vuj6C/pN2qVu36RyBqKSqywoyS0 3tXBKWx/frMjvgotuedGAVhWZMAWvG1e3mp/Pvra//mpTCGC5XR0NQfmS4wsa2dqW//w Wocg== X-Received: by 10.70.98.129 with SMTP id ei1mr22245531pdb.27.1409387576336; Sat, 30 Aug 2014 01:32:56 -0700 (PDT) Received: from [192.168.1.3] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id qp15sm2079856pbb.54.2014.08.30.01.32.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Aug 2014 01:32:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Sat, 30 Aug 2014 01:32:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <813CE748-0469-4BE4-8FD5-8B88696A1AEA@gmail.com> References: To: Mach Chen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sujJf9uv2iYjDXhqqNkeFWHBGd8 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 08:32:59 -0000 Hi Mach, Inline for my brief comments On Aug 29, 2014, at 8:32 PM, Mach Chen wrote: > Hi Sam, >=20 > Some replies inline... >=20 > Sniped. >=20 >>=20 >> Let us take the MPLS TP with IP on every node. >> The scenario you are talking about is 'associated bidirectional' = tunnel. >> Just because a 'vendor' implemented certain default method doesn't = require >> new TLV support. >> For associated bidirectional tunnel with IP on every node, perform = reply mode as >> IP. >> I don't think RFC4379 warrants certain default type to be fixed type = for a given >> FEC. >>=20 >> [NOBO] What you say is true only if all operators prefer IP return = path over >> control channel and reverse LSP. I am aware of operators who wants to = prefer >> control channel or reverse LSP whenever available, over IP path. The = preference >> really varies depending on operators. This is exactly where this = extension can >> benefit. >> %sam - We discussed this before but ended up with opposite conclusion = :D. If >> user want to perform return path via lsp or via IP, nothing prevents = and one could >> chose either of them. The same goes for bitmap size, selector size = etc. >=20 > Your assumption is that all nodes along the path support both IP and = LSP return path, this may not always true. In some mobile backhaul = networks that normally have access and core network parts, the nodes in = the access may only support pure MPLS-TP and not support IP forwarding; = the nodes in the core part normally support IP/MPLS. Then takes the = picture in A.2 as an example: >=20 > +----C------D----+ > / \ > A'----A------B G---H---H' > \ / > +----E------F----+ >=20 > Where A', A, H and H' only support pure MPLS-TP and do not support IP = forwarding, B and G support both LSP and IP return path, it means that = reply mode 2 cannot be used when perform traceroute. But when "Reply = via reverse LSP" is used, since C, D, E and F may not have reverse LSP = path but have IP return path, it still cannot traceroute the whole path. = In this case, actually, any single reply mode cannot satisfy the = requirement.=20 Neither does this new TLV will help, nor mandating IP reply mode only = trace is what I am advocating. Head end do not know which nodes support IP or which don't.=20 For the same topology, If C,D,E and F do not support IP, this new TLV is = not going to help you either. Solution cannot be topology specific, where the initiator do not know = what the topology is or will be. What you have is a solution, trying to find a problem. As I said in my earlier emails, performing IP and reply via LSP trace = simultaneously could achieve the same result, for mixed mode (some nodes = do not support IP) topology. Performance or diagnosing is not an issue = as Timeout value, ttl value etc are all configurable and 4379 does not = mandate what those values should be. >=20 > The essential of the Reply Mode Order TLV is to allow multiple reply = modes to be used for a specific LSP, and each responder can select its = appropriate reply mode to return the echo reply. You could achieve that without the need for new TLV and upgrade of the = network. cheers -sam >=20 >=20 > Best regards, > Mach From nobody Sat Aug 30 02:40:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFEA1A8904 for ; Sat, 30 Aug 2014 02:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 UL9MT-YqKeXu for ; Sat, 30 Aug 2014 02:40:17 -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 53EB81A8901 for ; Sat, 30 Aug 2014 02:40:16 -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 BIW76687; Sat, 30 Aug 2014 09:40:14 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Aug 2014 10:40:12 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Sat, 30 Aug 2014 17:40:06 +0800 From: Mach Chen To: Sam Aldrin Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPvOsdwjhGcp6uiEqhBQ5TeCNTy5vbARkAgABOkoCAA/otAIACKNwAgAcIvhD//96TAIAAj/Nw Date: Sat, 30 Aug 2014 09:40:05 +0000 Message-ID: References: <813CE748-0469-4BE4-8FD5-8B88696A1AEA@gmail.com> In-Reply-To: <813CE748-0469-4BE4-8FD5-8B88696A1AEA@gmail.com> 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/mpls/jyp_22W0f89-fv_zONx34tMBnVo Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 09:40:19 -0000 Hi Sam, Thanks for your prompt response! Please see my reply inline... > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Saturday, August 30, 2014 4:33 PM > To: Mach Chen > Cc: Nobo Akiya (nobo); Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf= .org > Subject: Re: [mpls] Poll for Adoption > draft-akiya-mpls-lsp-ping-reply-mode-simple-02 >=20 > Hi Mach, >=20 > Inline for my brief comments > On Aug 29, 2014, at 8:32 PM, Mach Chen wrote: >=20 > > Hi Sam, > > > > Some replies inline... > > > > Sniped. > > > >> > >> Let us take the MPLS TP with IP on every node. > >> The scenario you are talking about is 'associated bidirectional' tunne= l. > >> Just because a 'vendor' implemented certain default method doesn't > >> require new TLV support. > >> For associated bidirectional tunnel with IP on every node, perform > >> reply mode as IP. > >> I don't think RFC4379 warrants certain default type to be fixed type > >> for a given FEC. > >> > >> [NOBO] What you say is true only if all operators prefer IP return > >> path over control channel and reverse LSP. I am aware of operators > >> who wants to prefer control channel or reverse LSP whenever > >> available, over IP path. The preference really varies depending on > >> operators. This is exactly where this extension can benefit. > >> %sam - We discussed this before but ended up with opposite conclusion > >> :D. If user want to perform return path via lsp or via IP, nothing > >> prevents and one could chose either of them. The same goes for bitmap = size, > selector size etc. > > > > Your assumption is that all nodes along the path support both IP and LS= P return > path, this may not always true. In some mobile backhaul networks that > normally have access and core network parts, the nodes in the access may = only > support pure MPLS-TP and not support IP forwarding; the nodes in the core= part > normally support IP/MPLS. Then takes the picture in A.2 as an example: > > > > +----C------D----+ > > / \ > > A'----A------B G---H---H' > > \ / > > +----E------F----+ > > > > Where A', A, H and H' only support pure MPLS-TP and do not support IP > forwarding, B and G support both LSP and IP return path, it means that re= ply > mode 2 cannot be used when perform traceroute. But when "Reply via rever= se > LSP" is used, since C, D, E and F may not have reverse LSP path but have= IP > return path, it still cannot traceroute the whole path. In this case, act= ually, any > single reply mode cannot satisfy the requirement. > Neither does this new TLV will help, nor mandating IP reply mode only tra= ce is > what I am advocating. > Head end do not know which nodes support IP or which don't. > For the same topology, If C,D,E and F do not support IP, this new TLV is = not going > to help you either. No, it can help only if C, D, E and F know how to handle the Reply Mode TLV= . For your case, if C does not support IP, but it should support at least o= ne other reply mode and then use that mode to send back the echo reply.=20 > Solution cannot be topology specific, where the initiator do not know wha= t the > topology is or will be. > What you have is a solution, trying to find a problem. The above scenario is a very typical MBB scenario that deploys pure MPLS-TP= in access and reuse the IP/MPLS for core network. And even if operators kn= ow (and normally they do) the topologies, they cannot depend on the existin= g mechanisms to trace the path for reason that a single reply mode cannot a= pply to an LSP that across nodes support different modes. >=20 > As I said in my earlier emails, performing IP and reply via LSP trace sim= ultaneously > could achieve the same result, for mixed mode (some nodes do not support = IP) > topology.=20 Given the above example, since A', A, H and H' only support pure MPLS forwa= rding and do not support IP forwarding, you cannot perform IP and rely via = LSP trace simultaneously. Because when you reply mode 2 (IP path) to perfor= m trace, the echo request will be dropped at A and will not have chance to = reach to other nodes. Similarly, if you use reply via LSP, C,D, E and F wil= l not find a reverse path. Thanks, Mach > Performance or diagnosing is not an issue as Timeout value, ttl value > etc are all configurable and 4379 does not mandate what those values shou= ld be. >=20 >=20 > > > > The essential of the Reply Mode Order TLV is to allow multiple reply mo= des to > be used for a specific LSP, and each responder can select its appropriate= reply > mode to return the echo reply. > You could achieve that without the need for new TLV and upgrade of the > network. >=20 > cheers > -sam > > > > > > Best regards, > > Mach From nobody Sat Aug 30 03:00:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35D91A8908 for ; Sat, 30 Aug 2014 03:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 Xc0clMnaHCL6 for ; Sat, 30 Aug 2014 03:00:36 -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 B42211A891E for ; Sat, 30 Aug 2014 03:00:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLX97828; Sat, 30 Aug 2014 10:00:34 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Aug 2014 11:00:33 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Sat, 30 Aug 2014 18:00:29 +0800 From: Mach Chen To: Sam Aldrin Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPvOsdwjhGcp6uiEqhBQ5TeCNTy5vbARkAgABOkoCAA/otAIACKNwAgAcIvhD//96TAIAAj/NwgAANv/A= Date: Sat, 30 Aug 2014 10:00:28 +0000 Message-ID: References: <813CE748-0469-4BE4-8FD5-8B88696A1AEA@gmail.com> 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/mpls/NVSDbRB3Oh13ZgPwsXBpWhNzwoU Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 10:00:38 -0000 Hi Sam, > > As I said in my earlier emails, performing IP and reply via LSP trace > > simultaneously could achieve the same result, for mixed mode (some > > nodes do not support IP) topology. >=20 > Given the above example, since A', A, H and H' only support pure MPLS > forwarding and do not support IP forwarding, you cannot perform IP and re= ly via > LSP trace simultaneously. Because when you reply mode 2 (IP path) to perf= orm > trace, the echo request will be dropped at A and will not have chance to = reach to > other nodes.=20 Here I mean the nodes that do not support IP path will not correctly return= the echo reply. Best regards, Mach > -----Original Message----- > From: Mach Chen > Sent: Saturday, August 30, 2014 5:40 PM > To: 'Sam Aldrin' > Cc: Nobo Akiya (nobo); Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf= .org > Subject: RE: [mpls] Poll for Adoption > draft-akiya-mpls-lsp-ping-reply-mode-simple-02 >=20 > Hi Sam, >=20 > Thanks for your prompt response! >=20 > Please see my reply inline... >=20 > > -----Original Message----- > > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > > Sent: Saturday, August 30, 2014 4:33 PM > > To: Mach Chen > > Cc: Nobo Akiya (nobo); Ross Callon; mpls@ietf.org; > > mpls-chairs@tools.ietf.org > > Subject: Re: [mpls] Poll for Adoption > > draft-akiya-mpls-lsp-ping-reply-mode-simple-02 > > > > Hi Mach, > > > > Inline for my brief comments > > On Aug 29, 2014, at 8:32 PM, Mach Chen wrote: > > > > > Hi Sam, > > > > > > Some replies inline... > > > > > > Sniped. > > > > > >> > > >> Let us take the MPLS TP with IP on every node. > > >> The scenario you are talking about is 'associated bidirectional' tun= nel. > > >> Just because a 'vendor' implemented certain default method doesn't > > >> require new TLV support. > > >> For associated bidirectional tunnel with IP on every node, perform > > >> reply mode as IP. > > >> I don't think RFC4379 warrants certain default type to be fixed > > >> type for a given FEC. > > >> > > >> [NOBO] What you say is true only if all operators prefer IP return > > >> path over control channel and reverse LSP. I am aware of operators > > >> who wants to prefer control channel or reverse LSP whenever > > >> available, over IP path. The preference really varies depending on > > >> operators. This is exactly where this extension can benefit. > > >> %sam - We discussed this before but ended up with opposite > > >> conclusion :D. If user want to perform return path via lsp or via > > >> IP, nothing prevents and one could chose either of them. The same > > >> goes for bitmap size, > > selector size etc. > > > > > > Your assumption is that all nodes along the path support both IP and > > > LSP return > > path, this may not always true. In some mobile backhaul networks that > > normally have access and core network parts, the nodes in the access > > may only support pure MPLS-TP and not support IP forwarding; the nodes > > in the core part normally support IP/MPLS. Then takes the picture in A.= 2 as an > example: > > > > > > +----C------D----+ > > > / \ > > > A'----A------B G---H---H' > > > \ / > > > +----E------F----+ > > > > > > Where A', A, H and H' only support pure MPLS-TP and do not support > > > IP > > forwarding, B and G support both LSP and IP return path, it means that > > reply mode 2 cannot be used when perform traceroute. But when "Reply > > via reverse LSP" is used, since C, D, E and F may not have reverse > > LSP path but have IP return path, it still cannot traceroute the whole > > path. In this case, actually, any single reply mode cannot satisfy the > requirement. > > Neither does this new TLV will help, nor mandating IP reply mode only > > trace is what I am advocating. > > Head end do not know which nodes support IP or which don't. > > For the same topology, If C,D,E and F do not support IP, this new TLV > > is not going to help you either. >=20 > No, it can help only if C, D, E and F know how to handle the Reply Mode T= LV. For > your case, if C does not support IP, but it should support at least one o= ther reply > mode and then use that mode to send back the echo reply. >=20 > > Solution cannot be topology specific, where the initiator do not know > > what the topology is or will be. > > What you have is a solution, trying to find a problem. >=20 > The above scenario is a very typical MBB scenario that deploys pure MPLS-= TP in > access and reuse the IP/MPLS for core network. And even if operators know= (and > normally they do) the topologies, they cannot depend on the existing > mechanisms to trace the path for reason that a single reply mode cannot a= pply to > an LSP that across nodes support different modes. >=20 > > > > As I said in my earlier emails, performing IP and reply via LSP trace > > simultaneously could achieve the same result, for mixed mode (some > > nodes do not support IP) topology. >=20 > Given the above example, since A', A, H and H' only support pure MPLS > forwarding and do not support IP forwarding, you cannot perform IP and re= ly via > LSP trace simultaneously. Because when you reply mode 2 (IP path) to perf= orm > trace, the echo request will be dropped at A and will not have chance to = reach to > other nodes. Similarly, if you use reply via LSP, C,D, E and F will not f= ind a reverse > path. >=20 >=20 > Thanks, > Mach >=20 > > Performance or diagnosing is not an issue as Timeout value, ttl value > > etc are all configurable and 4379 does not mandate what those values sh= ould > be. > > > > > > > > > > The essential of the Reply Mode Order TLV is to allow multiple reply > > > modes to > > be used for a specific LSP, and each responder can select its > > appropriate reply mode to return the echo reply. > > You could achieve that without the need for new TLV and upgrade of the > > network. > > > > cheers > > -sam > > > > > > > > > Best regards, > > > Mach From nobody Sat Aug 30 04:19:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37741A89BE for ; Sat, 30 Aug 2014 04:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 T5f9odKM50nC for ; Sat, 30 Aug 2014 04:19:24 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B0D1A89C0 for ; Sat, 30 Aug 2014 04:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9939; q=dns/txt; s=iport; t=1409397563; x=1410607163; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=P9Ju/zBzxhp4HJm2CGAjDTZcGxVuZLIy/S5KLXKgdoQ=; b=bFYSmQoVJt+aTtr5LcH27H1r5VxnHg/tK6PROTAtC3+NlNSAiXvfh3Ju cTe/GOKM9h+9hMJF2PTLrJPB5fXXM1LrgmIobYAa7TZhz0GP4LXWlUQ+p gVhFBzEH2Db8FJKvEeC0yfYCh9OAw6WWd1NHjVWOOTOIZF3rtHiAdkpbf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAFyyAVStJV2T/2dsb2JhbABbgw1TV8dtCodMAYERFneEAwEBAQMBAQEBaAMLBQcCAgIBCBEDAQEBAScHGwwLFAkIAgQOBQkSiB8IDbt6ARcEjmcQAgEcMwIFBoMpgR0FkTGELoZ9gVuTQ4NhbAEBgk0BAQE X-IronPort-AV: E=Sophos;i="5.04,431,1406592000"; d="scan'208";a="73638710" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP; 30 Aug 2014 11:19:21 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7UBJKGl006870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 30 Aug 2014 11:19:20 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.218]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sat, 30 Aug 2014 06:19:20 -0500 From: "Rajiv Asati (rajiva)" To: "Aissaoui, Mustapha (Mustapha)" Thread-Topic: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) Thread-Index: AQHPtkRUETSIq42RjU6bn6kiA9S5/5vX4vKAgAWVYICAB8ZjgIADenSAgABiy10= Date: Sat, 30 Aug 2014 11:19:20 +0000 Message-ID: <7A384EF8-93FE-4157-8726-6B0F4DD3D47B@cisco.com> References: <53EA3666.2040004@pi.nu> <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> <9ace61def77942938bc577e4b6782680@CO2PR05MB636.namprd05.prod.outlook.com> , <4A79394211F1AF4EB57D998426C9340D9471CE50@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D9471CE50@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1T32ww_sTQNA85mY3tMPQUkPDBg Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 11:19:26 -0000 Hi Mustapha,=20 TR field is useful in case of dual-stack environment and using it for deter= mining whether the peer implementation is compliant (wrt handling v6 addres= s bindings and label bindings) is simple and straight forward.=20 When v6-only peer implementations exist (and become a new norm), TR field u= sage would become moot. And we wouldn't have to see them. A very good thing= , IMO. =20 We need to think about how much of this baggage needs to carry over when si= ngle-stack ipv6 networks become a new norm (like single-stack ipv4 has been= ).=20 Given that this draft already has built-in means to accommodate the RFC5036= non-compliant peer issue and do so in a simple manner, it is not necessary= to require changing other drafts, IMO.=20 Cheers, Raj PS; While there are multiple types of FECs, and it would be wise to dictate= the default behavior (v6 FECs advertised) in v6-only environment with an o= ption to change it. This is nothing different from current protocol machine= ry. > On Aug 29, 2014, at 8:25 PM, "Aissaoui, Mustapha (Mustapha)" wrote: >=20 > Hi Rajiv, > See inline below for some follow-up. >=20 > Regards, > Mustapha. >=20 >> -----Original Message----- >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >> Sent: Wednesday, August 27, 2014 7:19 PM >> To: Ross Callon; Aissaoui, Mustapha (Mustapha); mpls@ietf.org >> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-ipv6@tools.ietf.org >> Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc= closed) >>=20 >>=20 >> If this draft were to address the interoperability with rfc5036 non-comp= liant >> implementations, then it would be easier to rather leverage the =8Ctrans= port >> preference=B9 TLV that is already part of the version 13. >> This TLV was defined after the getting Adrian's and George=B9s feedback. >>=20 >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-13#section-6.1.1 > MA> It is not a good idea to overload this new TLV with a capability adve= rtisement role. LDP has its own capability advertisement mechanism and ther= e is no need to confuse implementations with the handling of two mechanisms= . >=20 >> The reason for not agreeing to the alternate solution (of using IP Prefi= x capability >> etc.) is 2-fold: >>=20 >> - not forward compatible (consider a deployment 5 yrs from now - IPv6-on= ly MPLS >> network - now, the LSR will be expecting an unnecessary IPv6 prefix capa= bility >> advertisement, and that=B9s not optimal, if not annoying) > MA> IPv6-only network is not synonymous with a single FEC type network. I= t will support many types of FECs in addition to the IPv6 prefix FEC: mLDP= IPv6 FECs, PW FECs, IPv4 prefix FEC, etc. The LDP capabilities have been d= esigned for the purpose of explicitly enabling or disabling capabilities in= cluding FEC type support on a given session. >=20 >> - not 100% backward compatible (does not solve the advertisement of v6 a= ddress >> binding to a v4 neighbor (which can also cause an outage to a non-compli= ant peer)) > MA> I think it makes sense to tie the exchange of both IPv6 address messa= ges and IPv6 prefix FECs to the advertisement of the IPv6 capability by bot= h peers. If however there is a use case for decoupling the advertising of I= Pv6 addresses from IPv6 FECs, then a separate capability can be devised for= addresses but I do not think we need it. >=20 >=20 >> Thanks. >>=20 >>=20 >> -- >> Cheers, >> Rajiv Asati >> Distinguished Engineer, Cisco >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Ross Callon >> Date: Friday, August 22, 2014 at 4:34 PM >> To: Mustapha Aissaoui , >> "mpls@ietf.org" >> Cc: "mpls-chairs@tools.ietf.org" , >> "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" >> >> Subject: RE: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc >> closed) >> Resent-From: >> Resent-To: Carlos Pignataro , Rajiv Papneja >> , Rajiv Asati , Vishwas Manr= al >> , , Loa Andersson , >> Ross Callon , MARTIN VIGOUREUX >> >> Resent-Date: Friday, August 22, 2014 at 4:35 PM >>=20 >>>> The proposed solution is to have implementations complying to this dra= ft >>>> advertise the IPv6 prefix state advertisement control capability >>>> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization messag= e >>>> explicitly indicating support for LDP IPv6. Without the peer advertisi= ng >>>> this capability, an LSR must not send IPv6 addresses and FECs to that >>>> peer. >>>=20 >>> Speaking as an individual contributor, this seems IMHO to be the right >>> solution (noting that, in final text as would be published in an RFC, t= he >>> "must not" in the last sentence should be capitalized). >>>=20 >>> Thanks, Ross >>>=20 >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha >>> (Mustapha) >>> Sent: Tuesday, August 19, 2014 3:19 AM >>> To: mpls@ietf.org >>> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-ipv6@tools.ietf.org >>> Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wgl= c >>> closed) >>>=20 >>> Dear all, >>> The following are the details of the issue we found and the proposed >>> solution. We shared this first with the authors to get initial feedback= . >>>=20 >>> When an LSR which supports LDP IPv6 according to this draft is in a LAN >>> with a broadcast interface, it can peer with LSRs which support this >>> draft and LSRs which do not. When it peers using IPv4 LDP control plane >>> with an LSR which does not support this draft, we have seen during our >>> testing an issue that the advertisement of IPv6 addresses or IPv6 FECs = to >>> that peer will cause it to bring down the IPv4 LDP session. >>>=20 >>> In other words, there are deployed LDP implementations which are >>> compliant to RFC 5036 for LDP IPv4 but are not compliant to RFC 5036 wh= en >>> it comes to handling IPv6 address or IPv6 FECs over an LDP IPv4 session= . >>> This is making us very concerned that when users enable dual-stack LDP >>> IPv4/IPv6, they will bring down LDP IPv4 sessions which have been worki= ng >>> in a multi-vendor environments for so many years. >>>=20 >>> The proposed solution is to have implementations complying to this draf= t >>> advertise the IPv6 prefix state advertisement control capability >>> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization message >>> explicitly indicating support for LDP IPv6. Without the peer advertisin= g >>> this capability, an LSR must not send IPv6 addresses and FECs to that >>> peer. >>>=20 >>> This approach is safer and has been followed when mLDP FEC was introduc= ed >>> as explained in Section 2.1 of RFC 6388. Also, this does not introduce >>> any new TLV to draft-ietf-mpls-ldp-ipv6. It just makes the exchange of >>> LDP IPv6 addresses and FECs conditional to both peers explicitly >>> indicating support for IPv6 capability during LDP session initializatio= n. >>>=20 >>> We do not feel such a simple change justifies writing a new draft and >>> having to deal with backward compatibility of implementations across tw= o >>> drafts. >>>=20 >>> We appreciate your comments on this matter. >>>=20 >>> Regards, >>> Mustapha. >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >>>> Sent: Tuesday, August 12, 2014 11:45 AM >>>> To: mpls@ietf.org; mpls-chairs@tools.ietf.org; >>>> draft-ietf-mpls-ldp-ipv6@tools.ietf.org >>>> Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc >>>> closed) >>>>=20 >>>> Working Group, >>>>=20 >>>> During what we thought would be a short wglc on draft-ietf-mpls-ldp-ip= v6 >>>> http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html >>>> we had a comment that stopped us from continuing progressing the draft= . >>>>=20 >>>> The short working group last call is now closed! >>>>=20 >>>> The comment we refer to was raised in a private mail to the working >>>> group chairs >>>> and the draft authors. >>>>=20 >>>> It says that there are a problem with some RFC 5036 non-compliant >>>> implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no >>>> detailed >>>> description of the exact problems. >>>>=20 >>>> We strongly encourage the people that made the comment(s) to write-up >>>> the >>>> problem, either as >>>>=20 >>>> - a new draft (preferred); or >>>> - in a mail to the working group mailing list >>>>=20 >>>> Once we an agreement to write a new draft or the write-up to the >>>> mailing, we will >>>> continue to ask the working group to see if we can agree to a way to >>>> progress. We >>>> like to see this write-up before September 1. Failing this we will >>>> continue to progress >>>> the draft-ietf-mpls-ldp-ipv6 as is. >>>>=20 >>>> /Loa >>>> for the working group chairs >>>> -- >>>>=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 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >=20 From nobody Sat Aug 30 11:04:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E7A1A06D4 for ; Sat, 30 Aug 2014 11:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VZRvQ6UDv3v for ; Sat, 30 Aug 2014 11:04:38 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3391A04B6 for ; Sat, 30 Aug 2014 11:04:38 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so8854124pad.7 for ; Sat, 30 Aug 2014 11:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=J0wLfFUKYGmB7sV942/ytq+9RdMs0MiNxLHTDBbieaQ=; b=cZGeId4VHTwD74JiCzrYMDRcknHqJGs8Q7b1pnlvLQSiMGQ5wH6VwFfAgHohjXJDgq nadnHgmrfdjqc51EVnTPg//GA9gWhrDCNA+5oBbzYGHFReD0RB4Ctbf1KR88ByUa3okE XPUCZQO5eDx+TAd1zBo47DIifYIiYcg4IAOq81NhJ5dxGzkdK3F5xi84OKP0Bg3AScK4 TI5K5L8S/Py5WF0x0w60WPrGSSGZf+mz8QuDmwgpg2ai2XcnQj+xnc/rFZiATxtiU4b2 1HP0ypDRrO9U4qBiD2EWcqSykurCCvB17/TGc94YZ+Lmvk/KD9bTkp1rShyaAUk7+flO wZlw== X-Received: by 10.68.69.69 with SMTP id c5mr4915811pbu.155.1409421877786; Sat, 30 Aug 2014 11:04:37 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id ow8sm3366870pbb.62.2014.08.30.11.04.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Aug 2014 11:04:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A607A209-DEB7-45CD-8915-537D921F370A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Sat, 30 Aug 2014 11:04:33 -0700 Message-Id: References: <813CE748-0469-4BE4-8FD5-8B88696A1AEA@gmail.com> To: Mach Chen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rcWY3pB8Uyo_CPr_b2MkN0o0EzM Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 18:04:40 -0000 --Apple-Mail=_A607A209-DEB7-45CD-8915-537D921F370A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Mach, See inline. On Aug 30, 2014, at 2:40 AM, Mach Chen wrote: > Hi Sam, >=20 > Thanks for your prompt response! >=20 > Please see my reply inline... >=20 >> -----Original Message----- >> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] >> Sent: Saturday, August 30, 2014 4:33 PM >> To: Mach Chen >> Cc: Nobo Akiya (nobo); Ross Callon; mpls@ietf.org; = mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] Poll for Adoption >> draft-akiya-mpls-lsp-ping-reply-mode-simple-02 >>=20 >> Hi Mach, >>=20 >> Inline for my brief comments >> On Aug 29, 2014, at 8:32 PM, Mach Chen wrote: >>=20 >>> Hi Sam, >>>=20 >>> Some replies inline... >>>=20 >>> Sniped. >>>=20 >>>>=20 >>>> Let us take the MPLS TP with IP on every node. >>>> The scenario you are talking about is 'associated bidirectional' = tunnel. >>>> Just because a 'vendor' implemented certain default method doesn't >>>> require new TLV support. >>>> For associated bidirectional tunnel with IP on every node, perform >>>> reply mode as IP. >>>> I don't think RFC4379 warrants certain default type to be fixed = type >>>> for a given FEC. >>>>=20 >>>> [NOBO] What you say is true only if all operators prefer IP return >>>> path over control channel and reverse LSP. I am aware of operators >>>> who wants to prefer control channel or reverse LSP whenever >>>> available, over IP path. The preference really varies depending on >>>> operators. This is exactly where this extension can benefit. >>>> %sam - We discussed this before but ended up with opposite = conclusion >>>> :D. If user want to perform return path via lsp or via IP, nothing >>>> prevents and one could chose either of them. The same goes for = bitmap size, >> selector size etc. >>>=20 >>> Your assumption is that all nodes along the path support both IP and = LSP return >> path, this may not always true. In some mobile backhaul networks = that >> normally have access and core network parts, the nodes in the access = may only >> support pure MPLS-TP and not support IP forwarding; the nodes in the = core part >> normally support IP/MPLS. Then takes the picture in A.2 as an = example: >>>=20 >>> +----C------D----+ >>> / \ >>> A'----A------B G---H---H' >>> \ / >>> +----E------F----+ >>>=20 >>> Where A', A, H and H' only support pure MPLS-TP and do not support = IP >> forwarding, B and G support both LSP and IP return path, it means = that reply >> mode 2 cannot be used when perform traceroute. But when "Reply via = reverse >> LSP" is used, since C, D, E and F may not have reverse LSP path but = have IP >> return path, it still cannot traceroute the whole path. In this case, = actually, any >> single reply mode cannot satisfy the requirement. >> Neither does this new TLV will help, nor mandating IP reply mode only = trace is >> what I am advocating. >> Head end do not know which nodes support IP or which don't. >> For the same topology, If C,D,E and F do not support IP, this new TLV = is not going >> to help you either. >=20 > No, it can help only if C, D, E and F know how to handle the Reply = Mode TLV. For your case, if C does not support IP, but it should support = at least one other reply mode and then use that mode to send back the = echo reply.=20 Please quote with real LSP example you are talking about and which other = way and reply mode you are talking about. Please refer to earlier emails, why I say that. >=20 >> Solution cannot be topology specific, where the initiator do not know = what the >> topology is or will be. >> What you have is a solution, trying to find a problem. >=20 > The above scenario is a very typical MBB scenario that deploys pure = MPLS-TP in access and reuse the IP/MPLS for core network. And even if = operators know (and normally they do) the topologies, they cannot depend = on the existing mechanisms to trace the path for reason that a single = reply mode cannot apply to an LSP that across nodes support different = modes. I have deployed and helped networks operated and troubleshoot them, so I = know what I am talking about. Provided examples how one could make it work without the need. Also = provided why this TLV cannot help in the so called mixed mode. In your own example, if C, D, E and F do not support =91IP=92 (not just = new TLV), your solution do not work. >=20 >>=20 >> As I said in my earlier emails, performing IP and reply via LSP trace = simultaneously >> could achieve the same result, for mixed mode (some nodes do not = support IP) >> topology.=20 >=20 > Given the above example, since A', A, H and H' only support pure MPLS = forwarding and do not support IP forwarding, you cannot perform IP and = rely via LSP trace simultaneously. Because when you reply mode 2 (IP = path) to perform trace, the echo request will be dropped at A and will = not have chance to reach to other nodes. Similarly, if you use reply via = LSP, C,D, E and F will not find a reverse path. Really? Then what is the purpose of TTL? Could you care to explain how = the node drops a packet when TTL do not expire? -sam >=20 >=20 > Thanks, > Mach >=20 >> Performance or diagnosing is not an issue as Timeout value, ttl value >> etc are all configurable and 4379 does not mandate what those values = should be. >>=20 >>=20 >>>=20 >>> The essential of the Reply Mode Order TLV is to allow multiple reply = modes to >> be used for a specific LSP, and each responder can select its = appropriate reply >> mode to return the echo reply. >> You could achieve that without the need for new TLV and upgrade of = the >> network. >>=20 >> cheers >> -sam >>>=20 >>>=20 >>> Best regards, >>> Mach --Apple-Mail=_A607A209-DEB7-45CD-8915-537D921F370A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Mach,

See inline.


Hi Sam,

Thanks for your = prompt response!

Please see my reply inline...

-----Original Message-----
From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]Sent: Saturday, August 30, 2014 4:33 PM
To: Mach Chen
Cc: Nobo = Akiya (nobo); Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org<= br>Subject: Re: [mpls] Poll for = Adoption
draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Hi = Mach,

Inline for my brief comments
On Aug 29, 2014, at 8:32 = PM, Mach Chen <mach.chen@huawei.com> = wrote:

Hi Sam,

Some replies = inline...

Sniped.


Let us = take the MPLS TP with IP on every node.
The scenario you are talking = about is 'associated bidirectional' tunnel.
Just because a 'vendor' = implemented certain default method doesn't
require new TLV = support.
For associated bidirectional tunnel with IP on every node, = perform
reply mode as IP.
I don't think RFC4379 warrants certain = default type to be fixed type
for a given FEC.

[NOBO] What you = say is true only if all operators prefer IP return
path over control = channel and reverse LSP. I am aware of operators
who wants to prefer = control channel or reverse LSP whenever
available, over IP path. The = preference really varies depending on
operators. This is exactly = where this extension can benefit.
%sam - We discussed this before but = ended up with opposite conclusion
:D. If user want to perform return = path via lsp or via IP, nothing
prevents and one could chose either = of them. The same goes for bitmap = size,
selector size etc.

Your assumption is that all nodes along the path = support both IP and LSP return
path, this may not always = true.  In some mobile backhaul networks that
normally have = access and core network parts, the nodes in the access may = only
support pure MPLS-TP and not support IP forwarding; the nodes in = the core part
normally support IP/MPLS. Then takes the picture in A.2 = as an example:

         &n= bsp;           &nbs= p;     +----C------D----+
   &n= bsp;           &nbs= p;         / =             &n= bsp;           &nbs= p;         \
A'----A------= B =             &n= bsp;           &nbs= p;         G---H---H'
&nbs= p;            =             \ =             &n= bsp;           &nbs= p;        /
   &= nbsp;           &nb= sp;          +----E-----= -F----+

Where A', A, H and H' only support pure MPLS-TP and do = not support IP
forwarding, B and G support both LSP and = IP return path, it means that reply
mode 2 cannot be used when = perform traceroute. But when  "Reply via reverse
LSP" is used, = since  C, D, E and F may not have reverse LSP path but have = IP
return path, it still cannot traceroute the whole path. In this = case, actually, any
single reply mode cannot satisfy the = requirement.
Neither does this new TLV will help, nor mandating IP = reply mode only trace is
what I am advocating.
Head end do not = know which nodes support IP or which don't.
For the same topology, If = C,D,E and F do not support IP, this new TLV is not going
to help you = either.

No, it can help only if C, D, E and F know = how to handle the Reply Mode TLV. For your case, if C does not support = IP, but it should support at least one other reply mode and then use = that mode to send back the echo reply. 
Please = quote with real LSP example you are talking about and which other way = and reply mode you are talking about.
Please refer to earlier = emails, why I say that.


Solution = cannot be topology specific, where the initiator do not know what = the
topology is or will be.
What you have is a solution, trying to = find a problem.

The above scenario is a very typical = MBB scenario that deploys pure MPLS-TP in access and reuse the IP/MPLS = for core network. And even if operators know (and normally they do) the = topologies, they cannot depend on the existing mechanisms to trace the = path for reason that a single reply mode cannot apply to an LSP that = across nodes support different modes.
I have = deployed and helped networks operated and troubleshoot them, so I know = what I am talking about.
Provided examples how one could make = it work without the need. Also provided why this TLV cannot help in the = so called mixed mode.
In your own example, if C, D, E and F do = not support =91IP=92 (not just new TLV), your solution do not = work.


As I said in my earlier emails, = performing IP and reply via LSP trace simultaneously
could achieve = the same result, for mixed mode (some nodes do not support = IP)
topology. 

Given = the above example, since A', A, H and H' only support pure MPLS = forwarding and do not support IP forwarding, you cannot perform IP and = rely via LSP trace simultaneously. Because when you reply mode 2 (IP = path) to perform trace, the echo request will be dropped at A and will = not have chance to reach to other nodes. Similarly, if you use reply via = LSP, C,D, E and F will not find a reverse = path.
Really? Then what is the purpose of TTL? = Could you care to explain how the node drops a packet when TTL do not = expire?

-sam


Thanks,
Mach

Performance= or diagnosing is not an issue as Timeout value, ttl value
etc are = all configurable and 4379 does not mandate what those values should = be.



The essential of the Reply = Mode Order TLV is to allow multiple reply modes to
be = used for a specific LSP, and each responder can select its appropriate = reply
mode to return the echo reply.
You could achieve that = without the need for new TLV and upgrade of = the
network.

cheers
-sam


Best = regards,
Mach

= --Apple-Mail=_A607A209-DEB7-45CD-8915-537D921F370A-- From nobody Sat Aug 30 20:53:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB981A6F76 for ; Sat, 30 Aug 2014 20:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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=-0.668, 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 tBqJGF1Auz1W for ; Sat, 30 Aug 2014 20:53:44 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7501A6F72 for ; Sat, 30 Aug 2014 20:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7364; q=dns/txt; s=iport; t=1409457223; x=1410666823; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5x0dxF5MLH2sWn1QQTIf/w1YY43ceA+xbEuKY4Vv44g=; b=FYyqY/ZfTtXOIs+CwcPvnCjfM9gkW5RrVvCeueH6rjpn8t7AM95G/ZRh K7p2j3HKpBPXGYhPfEj7RUefemV5KdIHs9HqGkhSEbmUGgJXfJSxvHavg zdtGGod+TC2yJZLxAPOM7+hqkRQcPZxtEVuUKoUk8vo23O0Hl8Cl6J8Jb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAOubAlStJA2F/2dsb2JhbABbgkdGU1cEzyMBgQ0Wd4QDAQEBBC1BCxACAQgOAwQBAQsdBzIUCQgBAQQBDQUIiDq7DgEXjxwxBgGDL4EdBZExoEmDYWyBSIEHAQEB X-IronPort-AV: E=Sophos; i="5.04,435,1406592000"; d="scan'208,217"; a="73682866" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 31 Aug 2014 03:53:41 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7V3rfEO003315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 31 Aug 2014 03:53:41 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.183]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Sat, 30 Aug 2014 22:53:41 -0500 From: "Faisal Iqbal (faiqbal)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+8ilRUv/hpET0IRlGIeWYgr95o5AIQ7ZvA Date: Sun, 31 Aug 2014 03:53:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.4] Content-Type: multipart/alternative; boundary="_000_E7820E943E0928409E27AA7805EA720375695BDCxmbalnx15ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/pKqOZCvJKz7ZD0Xy6oY2KKxYvXE Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 03:53:46 -0000 --_000_E7820E943E0928409E27AA7805EA720375695BDCxmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After closely following the lively debates among Nobo, Mach, and Sam, I bel= ieve that this document solves a very real problem. Simplifying Reply Mode = via this draft will ease up on several implementation and deployment headac= hes, coming from different preferred reply modes for various LSP types. I support this draft to be adopted as MPLS working group document. Regards, Faisal Iqbal From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, August 20, 2014 11:21 AM To: mpls@ietf.org Cc: 'mpls-chairs@tools.ietf.org' Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02 This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross --_000_E7820E943E0928409E27AA7805EA720375695BDCxmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After closely following t= he lively debates among Nobo, Mach, and Sam, I believe that this document s= olves a very real problem. Simplifying Reply Mode via this draft will ease up on several implementation and deployment headaches, com= ing from different preferred reply modes for various LSP types.<= /span>

 <= /p>

I support this draft to b= e adopted as MPLS working group document.

 <= /p>

Regards,

Faisal Iqbal

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 11:21 AM
To: mpls@ietf.org
Cc: 'mpls-chairs@tools.ietf.org'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mo= de-simple-02

 

This is to start a two week poll on ado= pting draft-akiya-mpls-lsp-ping-reply-mode-simple-02

as an MPLS working group document.=

 

Please send your comments (support/not = support) to the mpls working group

mailing list (mpls@ietf.org).

 

This poll will end Thursday September 4= , 2014.

 

Thanks, Ross

 

--_000_E7820E943E0928409E27AA7805EA720375695BDCxmbalnx15ciscoc_--