From nobody Mon Dec 1 00:23: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 D2B861A1AA2 for ; Mon, 1 Dec 2014 00:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu0QMLHinJEf for ; Mon, 1 Dec 2014 00:23:30 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671BD1A0199 for ; Mon, 1 Dec 2014 00:23:30 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.195.163]) (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 CAC1F180110A; Mon, 1 Dec 2014 09:23:26 +0100 (CET) Message-ID: <547C2577.3020202@pi.nu> Date: Mon, 01 Dec 2014 16:23:19 +0800 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" , "draft-ietf-mpls-oam-ipv6-rao@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/xhUNsuTlmnOE_Rec0czxLBVpDlo Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR poll on draft-ietf-mpls-oam-ipv6-rao 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, 01 Dec 2014 08:23:33 -0000 Working group, The authors of draft-ietf-mpls-oam-ipv6-rao has told the wg chairs that it is time to start the working group last call process for this draft. We will do so shortly, we will do an IPR poll first and follow up with the wglc. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-oam-ipv6-rao? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 1 05:40: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 DE7511A1BB8 for ; Mon, 1 Dec 2014 05:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUubqe6Xj5we for ; Mon, 1 Dec 2014 05:40:20 -0800 (PST) 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 8217D1A1BBF for ; Mon, 1 Dec 2014 05:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1887; q=dns/txt; s=iport; t=1417441222; x=1418650822; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UZRxktFAgM6pT2S+IkBNf8p5+GDC6lXerJIW4wz1K0w=; b=eIOy6hSiJPOoKl2FU2gbEY2jyr+WRYTqewA/MRAgTAIm3OxnU3pGw0sW c57B7XcJLa//nvmiZfZf2p1vgnCG/MnVZ/ZAGDLkr+5hBFQh3xJMjFQzX Yj/0Bcx/7PY7wnX56ZGu+9r15NdHXewMf6bZCCH75p8WaTDbthQjdM0ci s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAENvfFStJV2Y/2dsb2JhbABbgmMjgSkEzS4CgRMWAQEBAQF9hAIBAQEEOjEDBgUMAgICAQgRBAEBCxQJBxsXFAkIAgQBDQUIiDgB0ysBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBJAVEAIBHjEHBoMjgR8BBI59ggiMcIM7kFqDe2+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="373412566" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 01 Dec 2014 13:40:21 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB1DeJDS001623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 13:40:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 07:40:19 -0600 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-oam-ipv6-rao Thread-Index: AQHQDUAca3IPj7q2r06dS8jw88TYxpx6veyg Date: Mon, 1 Dec 2014 13:40:18 +0000 Message-ID: References: <547C2577.3020202@pi.nu> In-Reply-To: <547C2577.3020202@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.228] 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/DV8utuwUtqsF_PiSMQz4iTzGhHo Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-oam-ipv6-rao 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, 01 Dec 2014 13:40:23 -0000 Hi Loa, I am not aware of any IPRs that applies to draft-ietf-mpls-oam-ipv6-rao. Thanks! -Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Monday, December 01, 2014 3:23 AM > To: mpls@ietf.org; draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Tarek Saad > (tsaad) > Subject: IPR poll on draft-ietf-mpls-oam-ipv6-rao >=20 > Working group, >=20 > The authors of draft-ietf-mpls-oam-ipv6-rao has told the wg chairs that i= t is > time to start the working group last call process for this draft. >=20 > We will do so shortly, we will do an IPR poll first and follow up with th= e wglc. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-oam-ipv6-rao? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are no IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to t= his > email regardless of whether or not you are aware of any relevant IPR. >=20 > *The response needs to be sent to the MPLS wg mailing list.* >=20 > The document will not advance to the next stage until a response has been > received from each author and contributor. >=20 > 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. >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 1 05:54: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 768C41A1BC3 for ; Mon, 1 Dec 2014 05:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CElmN7dnMgBI for ; Mon, 1 Dec 2014 05:54:16 -0800 (PST) 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 6B8FE1A1BB8 for ; Mon, 1 Dec 2014 05:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1536; q=dns/txt; s=iport; t=1417442056; x=1418651656; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=30B7I3yUM/ZP3MheCnMBWMyxGCJdjLFiNHfohqq9VaA=; b=ESPg2eub4rsW0YX91vfPbBArTbvGmr1Ng4loZLvyuO5kMxtZprUn8UF/ BgLzecDE24um78Kry7pbhRs7GCPuXynCumMg+63bakXIR4XCW7sNrmkqa sIMO3ves57LbUpgQbV/1oo/1GF71ni/veOSkmhPWHUdaQSh+R7RGbnKVE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAKVxfFStJV2S/2dsb2JhbABbgmMjgSkExDmIdgKBExYBAQEBAX2EAwEBBDoxAwYFDgICAQg2EBsXJQIEAQ0FiEAB0zYBAQEBAQEBAQEBAQEBAQEBAQEBARgEkBUQAgFPB4RIAQSOfYIIi0KBLoM7kFqDe2+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="101515931" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 01 Dec 2014 13:54:15 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB1DsFQp013798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 13:54:15 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 07:54:15 -0600 From: "Carlos Pignataro (cpignata)" To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-oam-ipv6-rao Thread-Index: AQHQDUAcC3VoUutjZ0CGrWayouS8j5x60taA Date: Mon, 1 Dec 2014 13:54:14 +0000 Message-ID: References: <547C2577.3020202@pi.nu> In-Reply-To: <547C2577.3020202@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.150.53.143] 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/fePcpTpI_wFCBdGEtDjPG9JeNno Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-oam-ipv6-rao 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, 01 Dec 2014 13:54:19 -0000 Loa, I am not aware of any IPR that applies to this document. Thanks, Carlos. On 12/1/14, 3:23 AM, "Loa Andersson" wrote: >Working group, > >The authors of draft-ietf-mpls-oam-ipv6-rao has told the wg chairs >that it is time to start the working group last call process for >this draft. > >We will do so shortly, we will do an IPR poll first and follow up >with the wglc. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-ietf-mpls-oam-ipv6-rao? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >Currently there are no IPR disclosures that relates to this document. > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. > >*The response needs to be sent to the MPLS wg mailing list.* > >The document will not advance to the next stage until a response has >been received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > >Thanks, Loa >(as MPLS WG co-chair) >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 1 07:19:10 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 85A3A1A1A3D for ; Thu, 27 Nov 2014 22:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi08pIMgrbpz for ; Thu, 27 Nov 2014 22:32:31 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC761A1A38 for ; Thu, 27 Nov 2014 22:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2232; q=dns/txt; s=iport; t=1417156351; x=1418365951; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=51WA6jS573ZlU3mm201ZQSXfsPpGp3Y2dtN+/I+kX7A=; b=Qml8dECV8TDNBNhsSk9iGHZfX2j/TyhQc9gzoBop046ol36/FED9qryK ZZROrrXVtbsWz5AsulobC7TAEaaWJviWNgCSdWJKFb3f+ZO25GWL45L85 vqdLaRLubMvfJMIOrtdh67cYEw3cJe/T0KUhgrSP2vITS7GGySPSaJ6KN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAMAVeFStJA2D/2dsb2JhbABbgwZRXMc3hk0CgQkWAQEBAQF9hAMBAQQ6MQcHDgICAQg2EBsXJQIEAQ0FCYg3DdF0AQEBAQEBAQEBAQEBAQEBAQEBGgSQFRACAU8HhE0FkmWMHJccg3xvAYFHgQIBAQE X-IronPort-AV: E=Sophos;i="5.07,474,1413244800"; d="scan'208";a="100841674" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 28 Nov 2014 06:32:30 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sAS6WUd6005373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 06:32:30 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 00:32:30 -0600 From: "Tarek Saad (tsaad)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: MPLS Yang team(s) Thread-Index: AQHQCgaYwyhs1chlfE21I1ZVbc4DCpx1pugA Date: Fri, 28 Nov 2014 06:32:29 +0000 Message-ID: References: <5476BC82.3020907@pi.nu> In-Reply-To: <5476BC82.3020907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.86.254.217] Content-Type: text/plain; charset="us-ascii" Content-ID: <574824E2475C5F4F9A32AC538CE92156@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gBZ3YS4n1EvE7QmjphpwSWHjH4U X-Mailman-Approved-At: Mon, 01 Dec 2014 07:19:01 -0800 Cc: "Matt Hartley \(mhartley\)" , "vbeeram@juniper.net" , "jescia.chenxia@huawei.com" , "Reshad Rahman \(rrahman\)" , "" , "mpls-chairs@tools.ietf.org" , "Zafar Ali \(zali\)" , "Robert Sawaya \(rsawaya\)" , "zengxinzong@huawei.com" Subject: Re: [mpls] MPLS Yang team(s) 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, 28 Nov 2014 06:32:33 -0000 copying MPLS YANG team members explicitly. Regards, Tarek On 2014-11-27, 12:54 AM, "Loa Andersson" wrote: >Working Group, > >We got a mail asking about the status of the MPLS Yang teams. > >The background is that the authors of the mpls-yang IDs were asked >to prepare a joint presentation at the Honolulu meeting. The authors >(and other interested) met during the week and came up with >http://www.ietf.org/proceedings/91/slides/slides-91-mpls-13.pptx > >We very much appreciate the work done by everyone involved. And believe >it will form a good base to move ahead on. > >At the end of the presentation the relation of this work to generic >yang-attempts were brought up. The answer was pretty much that we do >not know yet. > >The YANG teams are not formalized working group design teams. We will >need to see the effects of getting the rtg-area tuning fully in place >first. > >For the time being they are individual initiatives, pretty much as an >individual draft, however the output from the teams are there out in the >open and can be discussed, and will serve as a basis if and when we >decide on design teams. > >The coordination points that can be seen now, and what the teams should >be aware of and take into consideration. > >High level OAM model (LIME) > - probably not that much impact on MPLS TE and LDP yang models > >Generic TE model > - it is likely that this will be done in teas > - but that mpls data palne specifics will go to mpls > - the MPLS TE yang team should be aware of this > >LDP model > - likely to stay (mostly) in MPLS > >Routing-area coordination > - Qin Wu and Dave Sinicrope is the coordinators for this, and the > teams should coordinate as necessary. > > >With that the current (individual) yang teams should keep up the >good work and wait for the other pieces fall into place. > >/Loa >for the mpls wg chairs > >PS > >Tarek, > >Can you copy this to all members of the yang teams > > > > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 1 07:21: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 9C61F1A3BA7 for ; Mon, 1 Dec 2014 07:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 5LMpNiC_vTmo for ; Mon, 1 Dec 2014 07:21:24 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::726]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565491A1DFA for ; Mon, 1 Dec 2014 07:20:19 -0800 (PST) Received: from pc6 (86.184.62.161) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 1 Dec 2014 15:18:13 +0000 Message-ID: <03df01d00d7a$0bce8740$4001a8c0@gateway.2wire.net> From: t.petch To: Mach Chen References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com>, Date: Mon, 1 Dec 2014 15:18:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.62.161] X-ClientProxiedBy: AM3PR03CA035.eurprd03.prod.outlook.com (10.141.191.163) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Forefront-PRVS: 0412A98A59 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(50226001)(84392001)(81686999)(81816999)(50466002)(76176999)(44716002)(66066001)(86362001)(64706001)(20776003)(47776003)(4396001)(44736004)(1556002)(87286001)(14496001)(77096004)(97736003)(50986999)(31966008)(61296003)(42186005)(101416001)(104166001)(46102003)(102836001)(89996001)(23756003)(87976001)(88136002)(116806002)(77156002)(229853001)(120916001)(99396003)(92726001)(110136001)(62236002)(21056001)(107046002)(33646002)(106356001)(93886004)(105586002)(122386002)(92566001)(62966003)(93916002)(95666004)(40100003)(1456002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kNrFycrPwBTrhe8ZX7G893Oe6sI Cc: mpls@ietf.org Subject: [mpls] Return Path Specified 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, 01 Dec 2014 15:21:28 -0000 Mach Some of the language in RFC7110 looks a little quirky. s.4.3.1 "the recommended type value is 26" looks like 'recommended' should have been elided post-IANA s.4 "The Reply Path TLV contains one or more nested sub-TLVs that can be used" s.4.2 Reply Path (RP) TLV "It is variable in length and can contain zero, one or more Target FEC sub-TLVs" seem to be in conflict s5.4 "When an echo reply is received, if the Reply Mode is "Reply via Specified Path" and the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and if the return path is an MPLS LSP. " I am left expecting a comma and a main clause (unless the remainder of the paragraph is the main clause). "When an echo reply is received with return code set to "Malformed echo request received" and the Subcode set to zero. " Ditto And, since I am at it:-) s.6 OLD "whether the return path LSP has the destination to the initiator." NEW "whether the return path LSP has a destination of the initiator." OLD "That means, when sending echo request, the initiator should choose a proper source address according the specified return path LSP to help the receiver to make the decision." NEW "That means, when sending an echo request, the initiator should select a source address that helps the receiver to find a return path." [I think!] Sorry that this is a year late:-( Tom Petch From nobody Mon Dec 1 09:34: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 48A821A6FC6 for ; Mon, 1 Dec 2014 09:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmVCjVJscTZQ for ; Mon, 1 Dec 2014 09:34:42 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646DF1A870D for ; Mon, 1 Dec 2014 09:34:39 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1429.namprd05.prod.outlook.com (25.160.107.151) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 1 Dec 2014 17:34:34 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0026.003; Mon, 1 Dec 2014 17:34:34 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: Repeated WG last call on draft-ietf-mpls-in-udp Thread-Index: AdADfizmaLLWumJtQOCK1HaJAtF5tAD3Q2eQAYxlYnA= Date: Mon, 1 Dec 2014 17:34:34 +0000 Message-ID: References: <92cfc78ef38f4e9aa6d8345353afe746@BY1PR0501MB1430.namprd05.prod.outlook.com> In-Reply-To: <92cfc78ef38f4e9aa6d8345353afe746@BY1PR0501MB1430.namprd05.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:;SRVR:BY1PR0501MB1429; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1429; x-forefront-prvs: 0412A98A59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(164054003)(189002)(46102003)(62966003)(77156002)(21056001)(101416001)(15202345003)(15975445006)(54356999)(97736003)(2501002)(76176999)(19625215002)(31966008)(19580405001)(66066001)(106356001)(19580395003)(19609705001)(16236675004)(20776003)(74316001)(64706001)(120916001)(92566001)(95666004)(108616004)(99286002)(230783001)(99396003)(122556002)(86362001)(107046002)(2351001)(40100003)(19300405004)(76576001)(33646002)(18717965001)(110136001)(2656002)(50986999)(4396001)(19617315012)(105586002)(87936001)(77096004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1429; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_c340c42e5acf45deba64b2f237e8e253BY1PR0501MB1430namprd05_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kudVun6veu3eegW-qJouIkTYbG4 Cc: "'draft-ietf-mpls-in-udp@tools.ietf.org'" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 17:34:45 -0000 --_000_c340c42e5acf45deba64b2f237e8e253BY1PR0501MB1430namprd05_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder: We are in the middle of a (repeated) WGLC on draft-ietf-mpls-in-u= dp. So far there have been no replies (or at least I haven't seen any). Ple= ase send technical comments, and (if you are happy with the document as is)= also send indications of support. Thanks, Ross From: Ross Callon [mailto:rcallon@juniper.net] Sent: Sunday, November 23, 2014 4:28 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; 'Martin Vigoureux' (martin.vigoureux@alcate= l-lucent.com); 'draft-ietf-mpls-in-udp@tools.ietf.org' Subject: Repeated WG last call on draft-ietf-mpls-in-udp Working Group, This is to start a two week Working Group last call on draft-ietf-mpls-in-= udp-07.txt. Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. You will recall that this document passed WG last call more than a year ago= . However, the subsequent IETF last call (in January 2014) resulted in a lengthy discussio= n, particularly over issues related to congestion and to the use (or non-use) of the UDP checksu= m with IPv6. After discussions in the March and July meetings this year (in London and T= oronto, respectively), a design team was formed to come up with improved text relat= ed to congestion control and checksum use. The document has been updated signific= antly and the changes were presented at the recent IETF meeting in Honolulu, in both = MPLS and TSVWG WGs. There is one IPR claim that applies to this draft, which can be seen at: https://datatracker.ietf.org/ipr/1941/ The coauthors and contributor have indicated that they don't know of any ot= her IPR applicable to this draft. If anyone else in the working group is aware = of IPR claims against this draft, the time to disclose that is now. This working group last call will end on December 8, 2014. Ross for the wg co-chairs PS: Please also note that if you look at an earlier version of the document= on the IETF tools web site, due to some sort of glitch in the tools server there is not= a place to click under "version" at the top of the page to get version 7. However, the corre= ct version is available at both https://tools.ietf.org/html/draft-ietf-mpls-in-udp-07 and= also on the datatracker at https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/. --_000_c340c42e5acf45deba64b2f237e8e253BY1PR0501MB1430namprd05_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reminder: We are in the m= iddle of a (repeated) WGLC on draft-ietf-mpls-in-udp. So far there have bee= n no replies (or at least I haven’t seen any). Please send technical comments, and (if you are happy with the document as is) also se= nd indications of support.

 <= /p>

Thanks, Ross

 <= /p>

From: Ross Cal= lon [mailto:rcallon@juniper.net]
Sent: Sunday, November 23, 2014 4:28 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; 'Martin Vigoureux' (martin.vigoureux= @alcatel-lucent.com); 'draft-ietf-mpls-in-udp@tools.ietf.org'
Subject: Repeated WG last call on draft-ietf-mpls-in-udp<= /span>

 

Working Group,

 

This is to start a two week Working Gro= up last call on  draft-ietf-mpls-in-udp-07.txt.

 

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

 

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.<= /o:p>

 

You will recall that this document pass= ed WG last call more than a year ago. However, the

subsequent IETF last call (in January 2= 014) resulted in a lengthy discussion, particularly over

issues related to congestion and to the= use (or non-use) of the UDP checksum with IPv6.

After discussions in the March and July= meetings this year (in London and Toronto,

respectively), a design team was formed= to come up with improved text related to

congestion control and checksum use. Th= e document has been updated significantly and

the changes were presented at the recen= t IETF meeting in Honolulu, in both MPLS and

TSVWG WGs.

 

There is one IPR claim that applies to = this draft, which can be seen at:

 

The coauthors and contributor have indi= cated that they don’t know of any other

IPR applicable to this draft. If anyone= else in the working group is aware of IPR

claims against this draft, the time to = disclose that is now.

 

This working group last call will end o= n December 8, 2014.

 

Ross

for the wg co-chairs<= /p>

 

PS: Please also note that if you look a= t an earlier version of the document on the IETF

tools web site, due to some sort of gli= tch in the tools server there is not a place to click

under “version” at the top = of the page to get version 7. However, the correct version is

available at both https://tools.ietf.org/html/draft-ietf-mpls-in-udp-= 07 and also on the

datatracker at https://datatracker.ietf.org/doc/draft-ietf-mpls= -in-udp/.

 

 <= /p>

--_000_c340c42e5acf45deba64b2f237e8e253BY1PR0501MB1430namprd05_-- From nobody Mon Dec 1 09:42: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 E7BDE1A8704; Mon, 1 Dec 2014 09:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m10G-aT0AF1g; Mon, 1 Dec 2014 09:41:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0D71A8726; Mon, 1 Dec 2014 09:41:53 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141201174153.7756.96443.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 09:41:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/DsE1GzkBbp5PWyV8ayozPhjA_T0 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'mLDP In-Band Signaling with Wildcards' to Proposed Standard (draft-ietf-mpls-mldp-in-band-wildcard-encoding-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: Mon, 01 Dec 2014 17:41:58 -0000 The IESG has approved the following document: - 'mLDP In-Band Signaling with Wildcards' (draft-ietf-mpls-mldp-in-band-wildcard-encoding-03.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-wildcard-encoding/ Technical Summary There are scenarios in which an IP multicast tree traverses an MPLS domain. It may be desirable to convert the IP multicast tree "seamlessly" to an MPLS multipoint label switched path (MP-LSP) when the multicast tree enters into the MPLS domain. Similarly, the MP-LSP is converted back to an IP multicast tree when the MPLS domain is exited. Previous documents specify procedures for certain kinds of IP multicast trees to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). These 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. Working Group Summary This document and another document (draft-ietf-mpls-pim-sm-over-mldp) at the time they were adopted as working group document had a certain overlap. draft-ietf-mpls-pim-sm-over-mldp is just being prepared for wglc The overlap was resolved by clearly scoping the two documents, and after that both documents has progressed smoothly. Document Quality We know of existing implementations of this protocol. We also know of vendors that plan to implement and operators that have deployed the protocol. The level of review for this document is good, it has been reviewed by the shepherd and wg chairs a number of times, it has been through MPLS-RT review, wg adoption poll, wglc and RTG Area Quality Assurance review. Personnel Loa Andersson is the Document Shepherd. Adrian Farrel is the Responsible AD. RFC Editor Note Section 2 s/This draft also/This document also/ From nobody Mon Dec 1 11:11:49 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 3F1D91A899E; Mon, 1 Dec 2014 11:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0lPqi6SKrhK; Mon, 1 Dec 2014 11:11:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDE41A89A9; Mon, 1 Dec 2014 11:09:26 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141201190926.12641.8688.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 11:09:26 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hAb8ybryhE77bOEcTq59NPaW7lc Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Document Action: 'Gap Analysis for Operating IPv6-only MPLS Networks' to Informational RFC (draft-ietf-mpls-ipv6-only-gap-04.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, 01 Dec 2014 19:11:42 -0000 The IESG has approved the following document: - 'Gap Analysis for Operating IPv6-only MPLS Networks' (draft-ietf-mpls-ipv6-only-gap-04.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-only-gap/ Technical Summary This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and not to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality. In the data plane, MPLS fully supports IPv6 and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps work is in progress to upgrade the relevant protocols. Working Group Summary There is a good support in the working group for this draft, and it is needed to figure out the gaps that needs to be filled to run MPLS in a IPv6 only network; the draft point to several issues that needs to be addressed. There were comments during wglc that has been addressed. This document were one of the first documents that did go through the new Quality Assurance(QA) that is started for Rtg Area documents. This review was done in parallel with the wglc. The QA review concluded that this is a very useful document of good quality. There were a set of technical and editorial comments that were addressed in the process to resolve the wglc comments. The QA also resulted in a comment that said that this document is a gap analysis and as such gives a description at one point in time, and ask if this should be published as a living document instead. This was discussed but the working group and the working group chairs called consensus in a mail to the working group. http://www.ietf.org/mail-archive/web/mpls/current/msg12752.html Saying: "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." That said the wg chairs are agreeable to, as soon as the RFC is published start following the process of filling the MPLS/IPv6 gaps, we believe that this eventually cover more than the MPLS specification and that it is a job that will be relevant for the entire rtg area. Document Quality This is an informational and a gap analysis document, no implementations are expected. On the other hand there are already activities and drafts looks to filling the gaps identified in the document. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd. Adrian Farrel is the Responsible Area Director. From nobody Mon Dec 1 11:12: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 BAE051A898C; Mon, 1 Dec 2014 11:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqPdZ_xQvPP8; Mon, 1 Dec 2014 11:12:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 329701A8999; Mon, 1 Dec 2014 11:11:28 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141201191128.3404.32514.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 11:11:28 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EmtJtBNoa3iLS2fwpi3kXYpY724 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs' to Proposed Standard (draft-ietf-mpls-pim-sm-over-mldp-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: Mon, 01 Dec 2014 19:12:44 -0000 The IESG has approved the following document: - 'Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs' (draft-ietf-mpls-pim-sm-over-mldp-03.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-pim-sm-over-mldp/ Technical Summary When IP multicast trees created by PIM-SM in Any Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switched Paths are established using Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP). Working Group Summary Originally there was an overlap between this document and draft-ietf-mpls-mldp-in-band-wildcard-encoding. This was resolved to the satisfaction of the working group, document shepherd, wg chairs and the authors of both document, before the documents were adopted as working group document. Document Quality We are currently not aware of any implementations of this specification. Personnel Adrian Farrel is the Responsible AD. Loa Andersson is the Document Shepherd. RFC Editor Note There are six authors named on the front of this document. This reflects the combined author teams of two merged documents. The RFC editor is requested to make an exception to the five- author rule for this document. From nobody Mon Dec 1 13:53: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 A00C61A1BCA for ; Mon, 1 Dec 2014 13:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nODYFvAF0Qzq for ; Mon, 1 Dec 2014 13:53:43 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23BD41A1BC2 for ; Mon, 1 Dec 2014 13:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1504; q=dns/txt; s=iport; t=1417470823; x=1418680423; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CKEwN806WOm98rkh31+zyXd2hoKzRGMBW9egw6ZdFj4=; b=d/fC+fYKRJsGW/4x1ZkG9zAB2WV27ASVVsmb1XKDYTLPj1ndXQvNSEAd EWooTrFp0Lug0GVQpQj+YW66ySUgC/IjqMoFfImKDbcxVblYT11Ssj2Sw TkCZYJkGHtq0LUXJYtpxmUT8jAwtaiaPnJ13xY0s5nKmLlEgLneeg43/P E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFANTifFStJV2U/2dsb2JhbABbgwaBKQTMegKBFxYBAQEBAX2EAwEBBDoxAwYFDgICAQg2EBsXJQIEAQ0FiEDVdQEBAQEBAQEBAQEBAQEBAQEBAQEBGASQCRACAU8HhEgBBJBhiyWBLIM4kD2De2+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.07,496,1413244800"; d="scan'208";a="376676073" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 01 Dec 2014 21:53:42 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sB1Lrg2s026458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 21:53:42 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.207]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 15:53:42 -0600 From: "Kamran Raza (skraza)" To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-oam-ipv6-rao Thread-Index: AQHQDUAc00TuCnaOfkenqL/SGZHQ5Jx7WM4A Date: Mon, 1 Dec 2014 21:53:41 +0000 Message-ID: References: <547C2577.3020202@pi.nu> In-Reply-To: <547C2577.3020202@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [161.44.212.210] 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/DIA_OERX0Mk9jAZy0cbi48p7gXw Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-oam-ipv6-rao 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, 01 Dec 2014 21:53:44 -0000 I am not aware of any IPR related to this document. On 2014-12-01, 3:23 AM, "Loa Andersson" wrote: >Working group, > >The authors of draft-ietf-mpls-oam-ipv6-rao has told the wg chairs >that it is time to start the working group last call process for >this draft. > >We will do so shortly, we will do an IPR poll first and follow up >with the wglc. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-ietf-mpls-oam-ipv6-rao? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >Currently there are no IPR disclosures that relates to this document. > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. > >*The response needs to be sent to the MPLS wg mailing list.* > >The document will not advance to the next stage until a response has >been received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > >Thanks, Loa >(as MPLS WG co-chair) >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 1 21:24: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 BA8BF1A00F8 for ; Mon, 1 Dec 2014 21:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dkd_aOI45F8C for ; Mon, 1 Dec 2014 21:24:11 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103441A00EA for ; Mon, 1 Dec 2014 21:24:11 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.195.163]) (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 AE90F180155B; Tue, 2 Dec 2014 06:24:07 +0100 (CET) Message-ID: <547D4CEF.2070908@pi.nu> Date: Tue, 02 Dec 2014 13:23:59 +0800 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" References: <92cfc78ef38f4e9aa6d8345353afe746@BY1PR0501MB1430.namprd05.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3hghbUHsd7ZyY_sr1V7H34dnqgU Cc: "'draft-ietf-mpls-in-udp@tools.ietf.org'" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 05:24:16 -0000 Ross, I'm a wg chair, but you carried the load shepherding this document. I've not been that involved, at least not lately. I have re-read the document, and support the publication. /Loa On 2014-12-02 01:34, Ross Callon wrote: > Reminder: We are in the middle of a (repeated) WGLC on > draft-ietf-mpls-in-udp. So far there have been no replies (or at least I > haven’t seen any). Please send technical comments, and (if you are happy > with the document as is) also send indications of support. > > Thanks, Ross > > *From:*Ross Callon [mailto:rcallon@juniper.net] > *Sent:* Sunday, November 23, 2014 4:28 PM > *To:* mpls@ietf.org > *Cc:* mpls-chairs@tools.ietf.org; 'Martin Vigoureux' > (martin.vigoureux@alcatel-lucent.com); > 'draft-ietf-mpls-in-udp@tools.ietf.org' > *Subject:* Repeated WG last call on draft-ietf-mpls-in-udp > > Working Group, > > This is to start a two week Working Group last call on > draft-ietf-mpls-in-udp-07.txt. > > Please send your comments to the mpls working group mailing list > (mpls@ietf.org ). > > Please send both technical comments, and (if you are happy with the > document as is) > > also send indications of support. > > You will recall that this document passed WG last call more than a year > ago. However, the > > subsequent IETF last call (in January 2014) resulted in a lengthy > discussion, particularly over > > issues related to congestion and to the use (or non-use) of the UDP > checksum with IPv6. > > After discussions in the March and July meetings this year (in London > and Toronto, > > respectively), a design team was formed to come up with improved text > related to > > congestion control and checksum use. The document has been updated > significantly and > > the changes were presented at the recent IETF meeting in Honolulu, in > both MPLS and > > TSVWG WGs. > > There is one IPR claim that applies to this draft, which can be seen at: > > https://datatracker.ietf.org/ipr/1941/ > > The coauthors and contributor have indicated that they don’t know of any > other > > IPR applicable to this draft. If anyone else in the working group is > aware of IPR > > claims against this draft, the time to disclose that is now. > > This working group last call will end on December 8, 2014. > > Ross > > for the wg co-chairs > > PS: Please also note that if you look at an earlier version of the > document on the IETF > > tools web site, due to some sort of glitch in the tools server there is > not a place to click > > under “version” at the top of the page to get version 7. However, the > correct version is > > available at both https://tools.ietf.org/html/draft-ietf-mpls-in-udp-07 > and also on the > > datatracker at https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/. > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Dec 2 01: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 132AD1A19EC for ; Tue, 2 Dec 2014 01:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znU0QQ77GxzK for ; Tue, 2 Dec 2014 01:09:01 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAEF51A0AF7 for ; Tue, 2 Dec 2014 01:09:00 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.195.163]) (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 14059180155B; Tue, 2 Dec 2014 10:08:57 +0100 (CET) Message-ID: <547D81A1.30905@pi.nu> Date: Tue, 02 Dec 2014 17:08:49 +0800 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" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/K0hf52r8WaKRiXxddcnBBriw_wI Cc: "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: [mpls] draft-ietf-mpls-oam-ipv6-rao 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, 02 Dec 2014 09:09:03 -0000 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-oam-ipv6-rao. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There is no IPR disclosures against this document. All the authors 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 December 16, 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 Tue Dec 2 01:15: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 CAE291A0381 for ; Tue, 2 Dec 2014 01:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuwcZDAJFRLS for ; Tue, 2 Dec 2014 01:15:31 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C43C1A19FA for ; Tue, 2 Dec 2014 01:15:19 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.195.163]) (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 AC8B5180159B; Tue, 2 Dec 2014 10:15:16 +0100 (CET) Message-ID: <547D831C.30201@pi.nu> Date: Tue, 02 Dec 2014 17:15:08 +0800 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" References: <547D81A1.30905@pi.nu> In-Reply-To: <547D81A1.30905@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/pB6Lx4i4tkIbYal0gg4ITxmFPGY Cc: "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: [mpls] Working group lst call for draft-ietf-mpls-oam-ipv6-rao 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, 02 Dec 2014 09:15:33 -0000 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-oam-ipv6-rao. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There is no IPR disclosures against this document. All the authors 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 December 16, 2014. /Loa for the MPLS wg chairs PS Just set the topic right -- 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 Dec 2 01:30:04 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 BFD4E1A1A31 for ; Tue, 2 Dec 2014 01:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqxzLM69wGHM for ; Tue, 2 Dec 2014 01:29:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311F71A19EF for ; Tue, 2 Dec 2014 01:29:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMG74993; Tue, 02 Dec 2014 09:29:56 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 2 Dec 2014 09:29:54 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.51]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Tue, 2 Dec 2014 17:29:51 +0800 From: Mach Chen To: "t.petch" Thread-Topic: Return Path Specified Thread-Index: AQHQDXoM/oPCAG8YmECFH7fEf2ElxZx7jMHw Date: Tue, 2 Dec 2014 09:29:50 +0000 Message-ID: References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com>, <03df01d00d7a$0bce8740$4001a8c0@gateway.2wire.net> In-Reply-To: <03df01d00d7a$0bce8740$4001a8c0@gateway.2wire.net> 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/q2m3UpHRFxer_WroeT9uXDia5_8 Cc: "mpls@ietf.org" Subject: Re: [mpls] Return Path Specified 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, 02 Dec 2014 09:30:00 -0000 Hi Tom, Thanks for your detail reading of the RFC. > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Monday, December 01, 2014 11:18 PM > To: Mach Chen > Cc: mpls@ietf.org > Subject: Return Path Specified >=20 > Mach >=20 > Some of the language in RFC7110 looks a little quirky. >=20 > s.4.3.1 > "the recommended type value is 26" > looks like 'recommended' should have been elided post-IANA Yes, indeed.=20 >=20 > s.4 > "The Reply Path TLV contains one or more nested sub-TLVs that can be used= " >=20 > s.4.2 Reply Path (RP) TLV > "It is variable in length and can contain zero, one or more Target FEC s= ub-TLVs" >=20 > seem to be in conflict The later is the intention and reflects final consensus, but failed to make= the former align with this consensus.=20 >=20 > s5.4 > "When an echo reply is received, if the Reply Mode is "Reply via > Specified Path" and the Reply Path return code is "The echo reply was > sent successfully using the specified Reply Path", and if the return > path is an MPLS LSP. " >=20 > I am left expecting a comma and a main clause (unless the remainder of th= e > paragraph is the main clause). Yes, there was a main clause, it was considered redundant and removed direc= tly in a version but forgot to change the last period to a comma. =20 >=20 > "When an echo reply is received with return code set to "Malformed > echo request received" and the Subcode set to zero. " >=20 > Ditto >=20 > And, since I am at it:-) Same as above. >=20 > s.6 > OLD > "whether the return path LSP has the destination to the initiator." > NEW > "whether the return path LSP has a destination of the initiator." >=20 > OLD > "That means, when sending echo request, the initiator > should choose a proper source address according the specified return > path LSP to help the receiver to make the decision." > NEW > "That means, when sending an echo request, the initiator > should select a source address that helps the receiver to > find a return path." [I think!] >=20 I am OK with the above refinement.=20 > Sorry that this is a year late:-( Indeed. But maybe you could report corresponding erratum, that will be usef= ul.=20 I realize that above bugs will be reduced if there was language QA review a= t that time.=20 Thanks, Mach >=20 > Tom Petch >=20 From nobody Tue Dec 2 07:34: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 CCB141A1BB9 for ; Tue, 2 Dec 2014 07:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBYeNHvJl9II for ; Tue, 2 Dec 2014 07:34:05 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACBB1A026F for ; Tue, 2 Dec 2014 07:34:05 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id b13so10418266qcw.23 for ; Tue, 02 Dec 2014 07:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UrAT7WW9kDOand6NaDLyBQZV+XrEEvGbfDz6Dgp9SwE=; b=h9AlW2CIPLyjg8FIVQ/dN5nUbHi+uCgg2S4sn0t1WInWQKV5kCixCrmjeQ/FWwm+bs UKLrxLxbXGmP4Pe3oPCnsFg2xDEmO/ax9Tf9RMInbaGFnQ+mwJOF+Ntzr0FRFtwAdelP si9yUHYQc0fVHmr6buD8QaSTInIqxs3mLUWnuiMDkIGsEFzP32Jogfydyj66saOT++fF Rj2Hx0NQ0ySrA6wCEb+oVDXFvKLP/cw0adi32ZNYVuPbF1l0NMk/uGfPEN1ooe92nPyG IoGHYYHrXeYZ8OgdRmXurlwF1FONEFFMS4ioQyewNI5bSWE3mwucQPUMK24kp8Kc6lV5 Bt6A== X-Received: by 10.140.94.229 with SMTP id g92mr21910286qge.77.1417534444228; Tue, 02 Dec 2014 07:34:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.89.133 with HTTP; Tue, 2 Dec 2014 07:33:44 -0800 (PST) In-Reply-To: References: <92cfc78ef38f4e9aa6d8345353afe746@BY1PR0501MB1430.namprd05.prod.outlook.com> From: "Andrew G. Malis" Date: Tue, 2 Dec 2014 10:33:44 -0500 Message-ID: To: Ross Callon Content-Type: multipart/alternative; boundary=001a113a0e8e0156d705093d75a8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lqjJK6AZKCYbnlapIpAclwz3b9Y Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-in-udp@tools.ietf.org" Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:34:09 -0000 --001a113a0e8e0156d705093d75a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ross, I think you just picked a bad week to run this WGLC. I've contributed to previous revisions of this draft, and and on re-review, it looks to be in great shape and I support publication. Cheers, Andy On Mon, Dec 1, 2014 at 12:34 PM, Ross Callon wrote: > Reminder: We are in the middle of a (repeated) WGLC on > draft-ietf-mpls-in-udp. So far there have been no replies (or at least I > haven=E2=80=99t seen any). Please send technical comments, and (if you ar= e happy > with the document as is) also send indications of support. > > > > Thanks, Ross > > > > *From:* Ross Callon [mailto:rcallon@juniper.net] > *Sent:* Sunday, November 23, 2014 4:28 PM > *To:* mpls@ietf.org > *Cc:* mpls-chairs@tools.ietf.org; 'Martin Vigoureux' ( > martin.vigoureux@alcatel-lucent.com); ' > draft-ietf-mpls-in-udp@tools.ietf.org' > *Subject:* Repeated WG last call on draft-ietf-mpls-in-udp > > > > Working Group, > > > > This is to start a two week Working Group last call on > draft-ietf-mpls-in-udp-07.txt. > > > > Please send your comments to the mpls working group mailing list ( > mpls@ietf.org). > > > > Please send both technical comments, and (if you are happy with the > document as is) > > also send indications of support. > > > > You will recall that this document passed WG last call more than a year > ago. However, the > > subsequent IETF last call (in January 2014) resulted in a lengthy > discussion, particularly over > > issues related to congestion and to the use (or non-use) of the UDP > checksum with IPv6. > > After discussions in the March and July meetings this year (in London and > Toronto, > > respectively), a design team was formed to come up with improved text > related to > > congestion control and checksum use. The document has been updated > significantly and > > the changes were presented at the recent IETF meeting in Honolulu, in bot= h > MPLS and > > TSVWG WGs. > > > > There is one IPR claim that applies to this draft, which can be seen at: > > https://datatracker.ietf.org/ipr/1941/ > > > > The coauthors and contributor have indicated that they don=E2=80=99t know= of any > other > > IPR applicable to this draft. If anyone else in the working group is awar= e > of IPR > > claims against this draft, the time to disclose that is now. > > > > This working group last call will end on December 8, 2014. > > > > Ross > > for the wg co-chairs > > > > PS: Please also note that if you look at an earlier version of the > document on the IETF > > tools web site, due to some sort of glitch in the tools server there is > not a place to click > > under =E2=80=9Cversion=E2=80=9D at the top of the page to get version 7. = However, the > correct version is > > available at both https://tools.ietf.org/html/draft-ietf-mpls-in-udp-07 > and also on the > > datatracker at https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/. > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --001a113a0e8e0156d705093d75a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ross,

I think you just picked a bad wee= k to run this WGLC.

I've contributed to previo= us revisions of this draft, and and on re-review, it looks to be in great s= hape and I support publication.

Cheers,
= Andy

O= n Mon, Dec 1, 2014 at 12:34 PM, Ross Callon <rcallon@juniper.net&g= t; wrote:

Reminder: We are in the m= iddle of a (repeated) WGLC on draft-ietf-mpls-in-udp. So far there have bee= n no replies (or at least I haven=E2=80=99t seen any). Please send technical comments, and (if you are happy with the document as is) also se= nd indications of support.

=C2=A0

Thanks, Ross

=C2=A0

From: Ross Cal= lon [mailto:rcallo= n@juniper.net]
Sent: Sunday, November 23, 2014 4:28 PM
To: mpls@ietf.org=
Cc: = mpls-chairs@tools.ietf.org; 'Martin Vigoureux' (martin.vigoureux@= alcatel-lucent.com); 'draft-ietf-mpls-in-udp@tools.ietf.org'= ;
Subject: Repeated WG last call on draft-ietf-mpls-in-udp

=C2=A0

Working Group,

=C2=A0

This is to start a two week Working Gro= up last call on=C2=A0 draft-ietf-mpls-in-udp-07.txt.

=C2=A0

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

=C2=A0

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

=C2=A0

You will recall that this document pass= ed WG last call more than a year ago. However, the

subsequent IETF last call (in January 2= 014) resulted in a lengthy discussion, particularly over

issues related to congestion and to the= use (or non-use) of the UDP checksum with IPv6.

After discussions in the March and July= meetings this year (in London and Toronto,

respectively), a design team was formed= to come up with improved text related to

congestion control and checksum use. Th= e document has been updated significantly and

the changes were presented at the recen= t IETF meeting in Honolulu, in both MPLS and

TSVWG WGs.

=C2=A0

There is one IPR claim that applies to = this draft, which can be seen at:

=C2=A0

The coauthors and contributor have indi= cated that they don=E2=80=99t know of any other

IPR applicable to this draft. If anyone= else in the working group is aware of IPR

claims against this draft, the time to = disclose that is now.

=C2=A0

This working group last call will end o= n December 8, 2014.

=C2=A0

Ross

for the wg co-chairs

=C2=A0

PS: Please also note that if you look a= t an earlier version of the document on the IETF

tools web site, due to some sort of gli= tch in the tools server there is not a place to click

under =E2=80=9Cversion=E2=80=9D at the = top of the page to get version 7. However, the correct version is

available at both https://tools.ietf.org/html/draft= -ietf-mpls-in-udp-07 and also on the

datatracker at https://datatracker.ietf.org/d= oc/draft-ietf-mpls-in-udp/.

=C2=A0

=C2=A0


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


--001a113a0e8e0156d705093d75a8-- From nobody Tue Dec 2 07:53: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 2F6CC1A1BE0 for ; Tue, 2 Dec 2014 07:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LamWmGxe1bE0 for ; Tue, 2 Dec 2014 07:53:31 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDAC1A1BFA for ; Tue, 2 Dec 2014 07:53:31 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB2FrSRA001388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2014 10:53:29 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sB2FrSRA001388 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1417535610; bh=6/CZAku2+bPVokOk/2Uogk0DM3Y=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=wp1HEg37KbE4oBiLnDhmRdJzteUG3Q0/RjnPM7YayTE6rmg0nc37m77L48Aaaa+QQ 6ukRB25vnZpP93mcmliTkDC9PqR7QCe/8l9apweND3koUDO1P5gIuKIAEszaQOBQJM 4F1b1q1btHnDfL8q8E7jhTYW0JHOwzU1AavU16dY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sB2FrSRA001388 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd56.lss.emc.com (RSA Interceptor); Tue, 2 Dec 2014 10:52:41 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB2FrIo3019075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 10:53:18 -0500 Received: from MXHUB204.corp.emc.com (10.253.68.30) by mxhub29.corp.emc.com (128.222.70.169) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 2 Dec 2014 10:53:17 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.125]) by MXHUB204.corp.emc.com ([fe80::ce7:65a1:5e89:81ab%12]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 10:53:17 -0500 From: "Black, David" To: Ross Callon , "mpls@ietf.org" Thread-Topic: Repeated WG last call on draft-ietf-mpls-in-udp Thread-Index: AQHQB2R+JgZaamfF4kGIqMsXrGfZspx7Xy0AgAEh5sA= Date: Tue, 2 Dec 2014 15:53:17 +0000 Message-ID: References: <92cfc78ef38f4e9aa6d8345353afe746@BY1PR0501MB1430.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: [10.238.45.72] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936282721MX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/danCdZeYyz9gW3OAgBG7pIwy3zk Cc: "'draft-ietf-mpls-in-udp@tools.ietf.org'" Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:53:35 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936282721MX104CL02corpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As someone who wrote and contributed to enough text for the revised draft t= hat I'm now an author, I support its publication. Thanks, --David From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, December 01, 2014 12:35 PM To: mpls@ietf.org Cc: 'draft-ietf-mpls-in-udp@tools.ietf.org'; mpls-chairs@tools.ietf.org Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp Reminder: We are in the middle of a (repeated) WGLC on draft-ietf-mpls-in-u= dp. So far there have been no replies (or at least I haven't seen any). Ple= ase send technical comments, and (if you are happy with the document as is)= also send indications of support. Thanks, Ross From: Ross Callon [mailto:rcallon@juniper.net] Sent: Sunday, November 23, 2014 4:28 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; 'Martin = Vigoureux' (martin.vigoureux@alcatel-lucent.com); 'draft-ietf-mpls-in-udp@tools.ietf.org' Subject: Repeated WG last call on draft-ietf-mpls-in-udp Working Group, This is to start a two week Working Group last call on draft-ietf-mpls-in-= udp-07.txt. Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. You will recall that this document passed WG last call more than a year ago= . However, the subsequent IETF last call (in January 2014) resulted in a lengthy discussio= n, particularly over issues related to congestion and to the use (or non-use) of the UDP checksu= m with IPv6. After discussions in the March and July meetings this year (in London and T= oronto, respectively), a design team was formed to come up with improved text relat= ed to congestion control and checksum use. The document has been updated signific= antly and the changes were presented at the recent IETF meeting in Honolulu, in both = MPLS and TSVWG WGs. There is one IPR claim that applies to this draft, which can be seen at: https://datatracker.ietf.org/ipr/1941/ The coauthors and contributor have indicated that they don't know of any ot= her IPR applicable to this draft. If anyone else in the working group is aware = of IPR claims against this draft, the time to disclose that is now. This working group last call will end on December 8, 2014. Ross for the wg co-chairs PS: Please also note that if you look at an earlier version of the document= on the IETF tools web site, due to some sort of glitch in the tools server there is not= a place to click under "version" at the top of the page to get version 7. However, the corre= ct version is available at both https://tools.ietf.org/html/draft-ietf-mpls-in-udp-07 and= also on the datatracker at https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/. --_000_CE03DB3D7B45C245BCA0D24327794936282721MX104CL02corpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As someone who wrote and contributed to enough= text for the revised draft that I’m now an author, I support its pub= lication.

 

Thanks,
--David

 

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, December 01, 2014 12:35 PM
To: mpls@ietf.org
Cc: 'draft-ietf-mpls-in-udp@tools.ietf.org'; mpls-chairs@tools.ietf.= org
Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp<= o:p>

 

Reminder: We are in the m= iddle of a (repeated) WGLC on draft-ietf-mpls-in-udp. So far there have bee= n no replies (or at least I haven’t seen any). Please send technical comments, and (if you are happy with the document as is) also se= nd indications of support.

 <= /p>

Thanks, Ross

 <= /p>

From: Ross Cal= lon [mailto:rcallon@juniper.net]
Sent: Sunday, November 23, 2014 4:28 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org; 'Martin Vigoureux' (martin.vigoureux@alcatel-lucent.com); 'draft-ietf-mpls-in= -udp@tools.ietf.org'
Subject: Repeated WG last call on draft-ietf-mpls-in-udp<= /span>

 

Working Group,

 

This is to start a two week Working Gro= up last call on  draft-ietf-mpls-in-udp-07.txt.

 

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

 

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.<= /o:p>

 

You will recall that this document pass= ed WG last call more than a year ago. However, the

subsequent IETF last call (in January 2= 014) resulted in a lengthy discussion, particularly over

issues related to congestion and to the= use (or non-use) of the UDP checksum with IPv6.

After discussions in the March and July= meetings this year (in London and Toronto,

respectively), a design team was formed= to come up with improved text related to

congestion control and checksum use. Th= e document has been updated significantly and

the changes were presented at the recen= t IETF meeting in Honolulu, in both MPLS and

TSVWG WGs.

 

There is one IPR claim that applies to = this draft, which can be seen at:

 

The coauthors and contributor have indi= cated that they don’t know of any other

IPR applicable to this draft. If anyone= else in the working group is aware of IPR

claims against this draft, the time to = disclose that is now.

 

This working group last call will end o= n December 8, 2014.

 

Ross

for the wg co-chairs<= /p>

 

PS: Please also note that if you look a= t an earlier version of the document on the IETF

tools web site, due to some sort of gli= tch in the tools server there is not a place to click

under “version” at the top = of the page to get version 7. However, the correct version is

available at both https://tools.ietf.org/html/draft-ietf-mpls-in-udp-= 07 and also on the

datatracker at https://datatracker.ietf.org/doc/draft-ietf-mpls= -in-udp/.

 

 <= /p>

--_000_CE03DB3D7B45C245BCA0D24327794936282721MX104CL02corpemcc_-- From nobody Tue Dec 2 08:56: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 C7DAE1A1EF5 for ; Tue, 2 Dec 2014 08:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTO9FsVU1YT1 for ; Tue, 2 Dec 2014 08:56:03 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::752]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D407F1A1EEE for ; Tue, 2 Dec 2014 08:56:02 -0800 (PST) Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 16:37:27 +0000 Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0026.003; Tue, 2 Dec 2014 16:37:27 +0000 From: Alexander Vainshtein To: "mpls@ietf.org" Thread-Topic: [mpls] Working group lst call for draft-ietf-mpls-oam-ipv6-rao Thread-Index: AQHQDhCWO3sRG13S3EWFgB4O2gu+tpx8gCpA Date: Tue, 2 Dec 2014 16:37:27 +0000 Message-ID: <70733660605b49f8bd2535e0284c0490@DB3PR03MB0812.eurprd03.prod.outlook.com> References: <547D81A1.30905@pi.nu> <547D831C.30201@pi.nu> In-Reply-To: <547D831C.30201@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0812; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0812; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(189002)(51704005)(377454003)(252514010)(77156002)(33646002)(62966003)(106356001)(106116001)(110136001)(101416001)(95666004)(31966008)(92566001)(74316001)(107046002)(2351001)(105586002)(86362001)(76576001)(4396001)(122556002)(19580405001)(19580395003)(68736005)(2656002)(66066001)(99396003)(15975445006)(50986999)(76176999)(54356999)(108616004)(230783001)(20776003)(64706001)(46102003)(97736003)(21056001)(40100003)(120916001)(87936001)(2501002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0812; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dtrikSwTC2-DUNM-V-FFjwjpKvw Cc: "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Working group lst call for draft-ietf-mpls-oam-ipv6-rao 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, 02 Dec 2014 16:56:05 -0000 Support. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, December 02, 2014 11:15 AM > To: mpls@ietf.org; mpls-chairs@tools.ietf.org > Cc: draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org > Subject: [mpls] Working group lst call for draft-ietf-mpls-oam-ipv6-rao >=20 > Working Group, >=20 > This is to initiate a two week working group last call on > draft-ietf-mpls-oam-ipv6-rao. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). >=20 > There is no IPR disclosures against this document. All the authors > have stated on the working group mailing list that they are not aware > of any other IPRs that relates to this draft. >=20 > This working group last call ends December 16, 2014. >=20 > /Loa > for the MPLS wg chairs >=20 > PS > Just set the topic right >=20 >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Dec 2 13:53: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 487BD1A6FC3 for ; Tue, 2 Dec 2014 13:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQPVvumYD1fj; Tue, 2 Dec 2014 13:52:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA461A6F40; Tue, 2 Dec 2014 13:52:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org, mpls-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202215253.4356.91090.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 13:52:53 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gw4Ral59VXkmTPPiaJ0XKBlGoSc Subject: [mpls] State changed: charter-ietf-mpls-06-08 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, 02 Dec 2014 21:53:01 -0000 State changed to IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-mpls/ From nobody Tue Dec 2 18:01: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 81EED1A8912 for ; Tue, 2 Dec 2014 18:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmaetgRquPzp for ; Tue, 2 Dec 2014 18:01:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04051A8908 for ; Tue, 2 Dec 2014 18:01:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMH47288; Wed, 03 Dec 2014 02:01:41 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 3 Dec 2014 02:01:39 +0000 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.140]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 3 Dec 2014 10:01:35 +0800 From: Youjianjie To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-you-mpls-spring-sfc-oam-00.txt Thread-Index: AQHQDpvnTi3uavZWREu0bbELXWSr0Jx9HE/w Date: Wed, 3 Dec 2014 02:01:34 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IvcIZMqn_4ECUYdk7NnwRf6q8DU Subject: [mpls] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-you-mpls-spring-sfc-oam-00=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 02:01:49 -0000 SGksDQoNClRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIGZvciBkZXRlY3Rpbmcgc2Vy dmljZSBmdW5jdGlvbiBjb25uZWN0aXZpdHkgYW5kIGF2YWlsYWJpbGl0eSBpbiBNUExTLSBTUFJJ TkcgbmV0d29ya3MuDQpZb3VyIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVk LiANCg0KQlIsDQpKaWFuamllDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANCuWPkemAgeaXtumXtDogMjAxNOW5tDEy5pyIM+aXpSA5OjUzDQrmlLbku7bkuro6IFlvdWpp YW5qaWU7IFh1eGlhb2h1OyBYdXhpYW9odTsgWW91amlhbmppZQ0K5Li76aKYOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXlvdS1tcGxzLXNwcmluZy1zZmMtb2FtLTAwLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15b3UtbXBscy1zcHJpbmctc2ZjLW9hbS0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmlhbmppZSBZb3UgYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQteW91LW1wbHMt c3ByaW5nLXNmYy1vYW0NClJldmlzaW9uOgkwMA0KVGl0bGU6CQlTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nIE9BTSBpbiBNUExTLVNQUklORyBOZXR3b3Jrcw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0x Mi0wMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOA0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlvdS1tcGxz LXNwcmluZy1zZmMtb2FtLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlvdS1tcGxzLXNwcmluZy1zZmMtb2FtLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlvdS1tcGxzLXNwcmluZy1z ZmMtb2FtLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNp bXBsZSBhbmQgZWZmaWNpZW50IG1lY2hhbmlzbSBmb3INCiAgIGRldGVjdGluZyBzZXJ2aWNlIGZ1 bmN0aW9uIGNvbm5lY3Rpdml0eSBhbmQgYXZhaWxhYmlsaXR5IGluIE11bHRpLQ0KICAgUHJvdG9j b2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKSAtIFNQUklORyBuZXR3b3Jrcy4gIFRoaXMgZG9jdW1l bnQNCiAgIHByb3Bvc2VzIHNvbWUgbmV3IGluZm9ybWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgY2Fy cmllZCBpbiBhbiBNUExTDQogICAiZWNobyByZXF1ZXN0IiBhbmQgImVjaG8gcmVwbHkiIGZvciB0 aGUgcHVycG9zZXMgb2YgU0YgY29ubmVjdGl2aXR5DQogICBhbmQgYXZhaWxhYmlsaXR5IGRldGVj dGlvbi4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Dec 2 18:42: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 AB84A1A8991 for ; Tue, 2 Dec 2014 18:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.05 X-Spam-Level: X-Spam-Status: No, score=-99.05 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwAtOcoxah8P for ; Tue, 2 Dec 2014 18:42:22 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDBB1A000D for ; Tue, 2 Dec 2014 18:42:21 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-6d-547e1c5d64f4 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 42.7F.25146.D5C1E745; Tue, 2 Dec 2014 21:09:02 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 21:42:19 -0500 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "mpls@ietf.org" Thread-Topic: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt Thread-Index: AQHP5mbq3C4ZY0u84U+EaqbSy61/u5x6ZoEA Date: Wed, 3 Dec 2014 02:42:18 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8A9937@eusaamb103.ericsson.se> References: <20140930184855.14746.88552.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B854360@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/mixed; boundary="_004_7347100B5761DC41A166AC17F22DF1121B8A9937eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyuXRPgm6cTF2Iwcpdiha3lq5ktZjdEe/A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZeybtIupYPpTtorGY03sDYyn1rB1MXJySAiY SJzuW84EYYtJXLi3HijOxSEkcIRRYvW6z6wQzjJGiW1fJ7ODVLEJGEm82NgDZosIeErc/rgX bJKwQJjElImHWSHi4RI/p65ggbCNJP7/eAJmswioSDQv2AS2jVfAV6L/3RyoBScYJY73/wRL cAIlFj6+xwhiMwKd9P3UGrA4s4C4xK0n86FOFZF4ePE01AuiEi8f/2OFsBUl9vVPZ4eoz5RY f/kTO8QyQYmTM5+wTGAUmYVk1CwkZbOQlEHE8yXWXNkHZetL7Jl4CsrWlli28DUzhK0ncW/H X1ZM8WCJh6t+QM13lVjw+RhQDReQfYFR4sDUV1CDFCWmdD9kX8DIs4qRo7Q4tSw33chwEyMw eo9JsDnuYFzwyfIQowAHoxIPrwFPXYgQa2JZcWXuIUZpDhYlcV7N6nnBQgLpiSWp2ampBalF 8UWlOanFhxiZODilGhgTas/eE7EL4I9cfl7519qsTcx6D0Ri9aZOWj61pjZ372HXjKb3xT0i KlzTFJgqD9tPnN1g4aT0gFdD4eGM43/+RjPkTTu7o7O9e239qa85Vna6NrbJHf7RCTP7M+MF jhV87DwWOzlaR4qPw0zgIdPyBfxVl5u6JZf9myDOINZZLv/POfzcXSWW4oxEQy3mouJEAHd6 R3y/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/OsjW1ZsRVst6H1vAdbd-zBURt-I Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.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, 03 Dec 2014 02:42:33 -0000 --_004_7347100B5761DC41A166AC17F22DF1121B8A9937eusaamb103erics_ Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8A9937eusaamb103erics_" --_000_7347100B5761DC41A166AC17F22DF1121B8A9937eusaamb103erics_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Nobo, many thanks for your thoughtful comments and am terribly sorry it took me s= o long to get back with resolution. Please find my notes in-lined and tagge= d by GIM>>. Regards, Greg PS. Attached is work-in progress with updates based on your review. -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] Sent: Sunday, October 12, 2014 2:53 PM To: Gregory Mirsky; mpls@ietf.org Subject: RE: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-co= nf-07.txt Hi Greg, I have only read through half of the document, but please find below my com= ments. =3D=3D Comments =3D=3D (1) In Section 2.1 Typically intermediate nodes should not process or modify any of the OAM configuration TLVs but simply forward them to the end-node. Should above "should not" be upper case "SHOULD NOT"? GIM>> I think that "SHOULD NOT" is too restrictive particularly because the= next sentence lists the exclusion. I've re-phrased the sentence to: Typically intermediate nodes simply forward OAM configuration TLVs to= the end-node without any processing or modification. At least one exceptio= n to this is if the FMS sub-TLV is present. Would you agree? (2) In Section 2.1.1, slight rephrase. [OLD] For this specification, BFD MUST be run in either one of the two modes: [NEW] For this specification, BFD MUST run in either one of the two modes: GIM=1B$B"d=1B(B done (3) In Section 2.2, naming convention The MPLS OAM Functions TLV presented in Figure 1 is carried as a TLV of the LSP Echo request/response messages [RFC4379]. Proper name is MPLS echo request/reply as per described in Section 3 of RFC= 4379. GIM=1B$B"d=1B(B done (MPLS Echo Request/Reply) (4) In Section 2.2, there's an inconsistency with flags Figure 1 describes 5 flags (CVLDF) while Table 1 describes 6 flags (CVFLDT)= . GIM>> Great catch, thank you. Fixed the Figure 1. (5) In Section 2.2, BFD Configuration sub-TLV ... If the I flag is set, the "BFD Authentication sub-TLV" may be included. The "may" should probably be "MAY" above. GIM>> true, done (6) In Section 2.2.1 Length: indicates the length of the TLV including sub-TLVs but excluding the Type and Length field, in octets. This description seems wrong. I think what you want to say is: Length: indicates the sub-TLV length in octets, excluding the sub- type and Length fields (4). GIM>> thank you, great catch. Similar wording is several other places throu= ghout the document. Fixed all to the following: Length - indicates the length of the Value field in octets (7) In Section 2.2.1 PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic continuity monitoring messages. Perhaps I missed this, but I couldn't find what goes into the PHB bits (3 b= its) and what behaviors are expected. Can you elaborate? GIM>> PHB, in this case and in 2.2.1. BFD Configuration sub-TLV, meant as = QoS setting. At the time the document was started, if I=1B$B!G=1B(Bm not mi= staken, we still referred to the three bit-long field as EXP, not as TC. Wo= uld changing PHB to TC help? (8) In Section 2.2.1 Integrity (I): If set BFD Authentication MUST be enabled. If the BFD Configuration sub-TLV does not include a BFD Authentication sub-TLV the authentication MUST use Keyed SHA1 with an empty pre-shared key (all 0s). What happens when receiver cannot support the requested authentication (inc= luding SHA1 w/ an empty key)? GIM>> More thanks :) Here=1B$B!G=1B(Bs new text I=1B$B!G=1B(Bve added: If the egress LSR does not support BFD Authentication an error MUST be gene= rated: "OAM Problem/BFD Authentication Unsupported". (re-named to match err= or code name in RSVP-TE MPLS-TP OAM configuration doc.) (Error codes listed in IANA Considerations sub-section 3.2. OAM configurat= ion errors) (9) In Section 2.2.1 Encapsulation Capability (G): if set, it shows the capability of encapsulating BFD messages into G-ACh channel. If both the G bit and U bit are set, configuration gives precedence to the G bit. Encapsulation Capability (U): if set, it shows the capability of encapsulating BFD messages into IP/UDP packets. If both the G bit and U bit are set, configuration gives precedence to the G bit. If neither G nor U are set, then is that considered an error case? GIM>> Strike! Here=1B$B!G=1B(Bs additional text: If the egress LSR does not support any of the ingress LSR Encapsulation Cap= abilities an error MUST be generated: "OAM Problem/Unsupported BFD Encapsul= ation format". And the new Error code to be added to the table for IANA to assign. (10) In Section 2.2.1 The BFD Configuration sub-TLV MUST include the following sub-TLVs in the LSP Echo reply message: - Local Discriminator sub-TLV; Are we missing some error cases? For example, if Bidirectional(B) bit is no= t set, then there is no need for MPLS echo reply to contain "Local Discrimi= nator sub-TLV", no? GIM>> Changed to =1B$B!H=1B(BMPLS Echo Reply=1B$B!I=1B(B and =1B$B!H=1B(BMP= LS Echo Request=1B$B!I=1B(B were appropriate. Updated text now: The BFD Configuration sub-TLV MUST include the following sub-TLVs in the LSP Echo reply message: - Local Discriminator sub-TLV, if B flag is set in the MPLS Echo Requ= est; (11) In Section 2.2.1 Version: identifies the BFD protocol version. If a node does not support a specific BFD version an error must be generated: "OAM Problem/Unsupported OAM Version". I'm assuming that this error code is TBD2. However, in Section 3.2 (IANA Se= ction), the name is slightly different. | TBD2 | MPLS OAM Unsupported Functionality | This document | Additionally, I didn't see any description on where/how other error codes (= TBD3-TBD6) are to be used. I can guess, but perhaps it would be good idea t= o spell them out in relevant sections. GIM>> I=1B$B!G=1B(Bve changed the explanation of TBD2 error to =1B$B!H=1B(B= OAM Problem/Unsupported BFD Version=1B$B!I=1B(B. Error codes been mapped to appropriate sections and the table in IANA Consi= derations sections updated accordingly. (12) In Section 2.2.4 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Auth. sub-type (103) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Key ID | Reserved (0s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of this TLV mandates latter 16 bits to be all zero(0)'s. However,= all authentication TLVs defined in RFC5880 and others (ex: draft-ietf-bfd-= generic-crypto-auth) use the latter 16 bits (ex: Auth Key ID) but it's depe= ndant on the Auth Type. Perhaps this sub-TLV can better be aligned. Somethi= ng like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Auth. sub-type (103) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Key ID | Depends on Auth Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GIM>> Configuration of BFD Authentication is currently out of scope of this= document. The BFD Authentication sub-TLV can be used to coordinate Auth. T= ype and Auth. Key ID selection by BFD peers, assuming that their Authentica= tion configured. Section 2.1.1: The BFD Authentication sub-TLV is used to specify which authenticatio= n method that should be used and which pre-shared key/ password that should= be used for this particular session. How the key exchange is performed is= out of scope of this document. =3D=3D Typos =3D=3D (1) Typo in Table of Contents (and Section 2.2.8 title) s/2.2.8. Fault Managemet Signal sub-TLV/2.2.8. Fault Management Signal sub-= TLV/ GIM>> done (2) Typo in Section 1.1 s/MEP - Maintanence Entity Group End Point/MEP - Maintenance Entity Group E= nd Point/ GIM>> done (3) Typo in Section 2.2.4 s/exluding the Type/excluding the Type/ GIM>> done (4) Typo in Section 2.2.5 s/exluding the Type/excluding the Type/ GIM>> done (5) Typo in Section 3.1 s/allocation specied in that/allocation specified in that/ GIM>> done (6) Typo in Section 3.1 s/IANA maintians a registry/IANA maintains a registry/ GIM>> done (7) Typo in Section 3.1 s/IANA maintians a registry/IANA maintains a registry/ GIM>> done Thanks! - Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky > Sent: Tuesday, September 30, 2014 2:54 PM > To: mpls@ietf.org > Subject: [mpls] FW: I-D Action: > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf- > 07.txt > > Dear All, > minor updates and bringing this work back on track. > Your comments, questions and suggestions always welcome and greatly > appreciated. > > Regards, > Greg > > PS. RSVP-based companion doc been in the IESG queue been prepared for > AD to review. > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, September 30, 2014 11:49 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching > Working Group of the IETF. > > Title : Configuration of Pro-Active Operations, Adminis= tration, and > Maintenance (OAM) Functions for MPLS-based Transport Networks using > LSP Ping > Authors : Elisa Bellagamba > Gregory Mirsky > Loa Andersson > Pontus Skoldstrom > Dave Ward > John Drake > Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt > Pages : 21 > Date : 2014-09-30 > > Abstract: > This specification describes the configuration of pro-active MPLS-TP > Operations, Administration, and Maintenance (OAM) Functions for a > given LSP using a set of TLVs that are carried by the LSP-Ping > protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-0 > 7 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf-07 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --_000_7347100B5761DC41A166AC17F22DF1121B8A9937eusaamb103erics_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi Nobo,
many thanks for your thoughtful comments and am terribly sorry it took= me so long to get back with resolution. Please find my notes in-lined and = tagged by GIM>>.
 
        Regards,
           &nbs= p;    Greg
 
PS. Attached is work-in progress with updates based on your review.
 
-----Original Message-----
From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]
Sent: Sunday, October 12, 2014 2:53 PM
To: Gregory Mirsky; <= u>mpls@ietf.org
Subject: RE: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-co= nf-07.txt
 
Hi Greg,
 
I have only read through half of the document, but please find below m= y comments.
 
=3D=3D Comments =3D=3D
 
(1) In Section 2.1
 
   Typically intermediate nodes should not process or modify= any of the
   OAM configuration TLVs but simply forward them to the end= -node.
 
Should above "should not" be upper case "SHOULD NOT&quo= t;?
GIM>> I think that "SHOULD NOT" is too restrictive par= ticularly because the next sentence lists the exclusion.
I've re-phrased the sentence to:
Typically intermediate nodes simply forwa= rd OAM configuration TLVs to the end-node without any processing or modific= ation. At least one exception to this is if the FMS sub-TLV is present.
Would you agree?
 
(2) In Section 2.1.1, slight rephrase.
 
[OLD]
   For this specification, BFD MUST be run in either one of = the two
   modes:
 
[NEW]
   For this specification, BFD MUST run in either one of the= two
   modes:
GIM=1B$B"d=1B(B done
 
(3) In Section 2.2, naming convention
 
   The MPLS OAM Functions TLV presented in Figure 1 is carri= ed as a TLV
   of the LSP Echo request/response messages [RFC4379].
 
Proper name is MPLS echo request/reply as per described in Section 3 o= f RFC4379.
GIM=1B$B"d=1B(B done (MPLS Echo Req= uest/Reply)
 
(4) In Section 2.2, there's an inconsistency with flags
 
Figure 1 describes 5 flags (CVLDF) while Table 1 describes 6 flags (CV= FLDT).
GIM>> Great catch, thank you. Fixed the Figure 1.
 
(5) In Section 2.2, BFD Configuration sub-TLV ...
 
      If the I flag is set, the "BFD
      Authentication sub-TLV" may be inc= luded.
 
The "may" should probably be "MAY" above.
GIM>> true, done
 
(6) In Section 2.2.1
 
   Length: indicates the length of the TLV including sub-TLV= s but
   excluding the Type and Length field, in octets.
 
This description seems wrong. I think what you want to say is:
 
   Length: indicates the sub-TLV length in octets, excluding= the sub-
   type and Length fields (4).
GIM>> thank you, great catch. Similar wording is several other p= laces throughout the document. Fixed all to the following:
Length - indicates the length of the Valu= e field in octets
 
(7) In Section 2.2.1
 
   PHB: Identifies the Per-Hop Behavior (PHB) to be used for= periodic
   continuity monitoring messages.
 
Perhaps I missed this, but I couldn't find what goes into the PHB bits= (3 bits) and what behaviors are expected. Can you elaborate?
GIM>> PHB, in this case and in 2.2.1.  BFD Configuration su= b-TLV, meant as QoS setting. At the time the document was started, if I=1B$= B!G=1B(Bm not mistaken, we still referred to the three bit-long field as EX= P, not as TC. Would changing PHB to TC help?
 
(8) In Section 2.2.1
 
   Integrity (I): If set BFD Authentication MUST be enabled.=   If the BFD
   Configuration sub-TLV does not include a BFD Authenticati= on sub-TLV
   the authentication MUST use Keyed SHA1 with an empty pre-= shared key
   (all 0s).
 
What happens when receiver cannot support the requested authentication= (including SHA1 w/ an empty key)?
GIM>> More thanks J
Here=1B$B!G=1B(Bs new text I=1B$B!G=1B(Bve added:
If the egress LSR does not support BFD Authentication an error MUST be= generated: "OAM Problem/BFD Authentication Unsupported". (re-nam= ed to match error code name in RSVP-TE MPLS-TP OAM configuration doc.)
(Error codes listed in IANA Considerations sub-section 3.2.  OAM = configuration errors)
 
(9) In Section 2.2.1
 
   Encapsulation Capability (G): if set, it shows the capabi= lity of
   encapsulating BFD messages into G-ACh channel.  If b= oth the G bit and
   U bit are set, configuration gives precedence to the G bi= t.
 
   Encapsulation Capability (U): if set, it shows the capabi= lity of
   encapsulating BFD messages into IP/UDP packets.  If = both the G bit
   and U bit are set, configuration gives precedence to the = G bit.
 
If neither G nor U are set, then is that considered an error case?
 
GIM>> Strike! Here=1B$B!G=1B(Bs additional text:
If the egress LSR does not support any of the ingress LSR Encapsulatio= n Capabilities an error MUST be generated: "OAM Problem/Unsupported BF= D Encapsulation format".
And the new Error code to be added to the table for IANA to assign.
 
(10) In Secti­­­­­­on 2.2.1
 
   The BFD Configuration sub-TLV MUST include the following = sub-TLVs in
   the LSP Echo reply message:
 
      - Local Discriminator sub-TLV;
 
Are we missing some error cases? For example, if Bidirectional(B) bit = is not set, then there is no need for MPLS echo reply to contain "Loca= l Discriminator sub-TLV", no?
GIM>> Changed to =1B$B!H=1B(BMPLS Echo Reply=1B$B!I=1B(B and =1B= $B!H=1B(BMPLS Echo Request=1B$B!I=1B(B were appropriate.
Updated text now:
   The BFD Configuration sub-TLV MUST include the following = sub-TLVs in
   the LSP Echo reply message:
 
      - Local Discriminator sub-TLV, if B fla= g is set in the MPLS Echo Request;
 
(11) In Section 2.2.1
 
   Version: identifies the BFD protocol version.  If a = node does not
   support a specific BFD version an error must be generated= : "OAM
   Problem/Unsupported OAM Version".
 
I'm assuming that this error code is TBD2. However, in Section 3.2 (IA= NA Section), the name is slightly different.
 
| TBD2  | MPLS OAM Unsupported Functionality   &nb= sp;    | This document |
 
Additionally, I didn't see any description on where/how other error co= des (TBD3-TBD6) are to be used. I can guess, but perhaps it would be good i= dea to spell them out in relevant sections.
GIM>> I=1B$B!G=1B(Bve changed the explanation of TBD2 error to = =1B$B!H=1B(BOAM Problem/Unsupported BFD Version=1B$B!I=1B(B.
Error codes been mapped to appropriate sections and the table in IANA = Considerations sections updated accordingly.
 
(12) In Section 2.2.4
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |    BFD Auth. sub-type (103)   = |             L= ength            |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |   Auth Type   |  Auth Key ID&n= bsp; |         Reserved (0s) &= nbsp;       |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
The value of this TLV mandates latter 16 bits to be all zero(0)'s. How= ever, all authentication TLVs defined in RFC5880 and others (ex: draft-ietf= -bfd-generic-crypto-auth) use the latter 16 bits (ex: Auth Key ID) but it's= dependant on the Auth Type. Perhaps this sub-TLV can better be aligned. Something like:
 
0           &nb= sp;       1     &nbs= p;             = 2            &n= bsp;      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
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
|    BFD Auth. sub-type (103)   |  =            Length &n= bsp;          |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
|   Auth Type   |  Auth Key ID  | &= nbsp;    Depends on Auth Type     |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 
GIM>> Configuration of BFD Authentication is currently out of sc= ope of this document. The BFD Authentication sub-TLV can be used to coordin= ate Auth. Type and Auth. Key ID selection by BFD peers, assuming that their= Authentication configured. Section 2.1.1:
The BFD Authentication sub-TLV is used to= specify which authentication method that should be used and which pre-shar= ed key/ password that should be used for this particular session.  How= the key exchange is performed is out of scope of this document.
 
=3D=3D Typos =3D=3D
 
(1) Typo in Table of Contents (and Section 2.2.8 title)
 
s/2.2.8. Fault Managemet Signal sub-TLV/2.2.8. Fault Management Signal= sub-TLV/
GIM>> done
 
(2) Typo in Section 1.1
 
s/MEP - Maintanence Entity Group End Point/MEP - Maintenance Entity Gr= oup End Point/
GIM>> done
 
(3) Typo in Section 2.2.4
 
s/exluding the Type/excluding the Type/
GIM>> done
 
(4) Typo in Section 2.2.5
 
s/exluding the Type/excluding the Type/
GIM>> done
 
(5) Typo in Section 3.1
 
s/allocation specied in that/allocation specified in that/
GIM>> done
(6) Typo in Section 3.1
 
s/IANA maintians a registry/IANA maintains a registry/
GIM>> done
(7) Typo in Section 3.1
 
s/IANA maintians a registry/IANA maintains a registry/
GIM>> done
Thanks!
 
- Nobo
 
> -----Original Message-----
> From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Gregory Mirsky
> Sent: Tuesday, September 30, 2014 2:54 PM
> Subject: [mpls] FW: I-D Action:
> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-
> 07.txt
>
> Dear All,
> minor updates and bringing this work back on track.
> Your comments, questions and suggestions always welcome and great= ly
> appreciated.
>
>        Regards,
>           =      Greg
>
> PS. RSVP-based companion doc been in the IESG queue been prepared= for
> AD to review.
>
> -----Original Message-----
> From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of internet-
> Sent: Tuesday, September 30, 2014 11:49 AM
> Subject: [mpls] I-D Action:
> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Draft= s
> directories.
>  This draft is a work item of the Multiprotocol Label Switch= ing
> Working Group of the IETF.
>
>         Title  =          : Configuration of Pro-Act= ive Operations, Administration, and
> Maintenance (OAM) Functions for MPLS-based Transport Networks usi= ng
> LSP Ping
>         Authors &nbs= p;       : Elisa Bellagamba
>           =             &nb= sp;   Gregory Mirsky
>           =             &nb= sp;   Loa Andersson
>           =             &nb= sp;   Pontus Skoldstrom
>           =             &nb= sp;   Dave Ward
>           =             &nb= sp;   John Drake
>        Filename  &nb= sp;     : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.= txt
>        Pages   =         : 21
>        Date   &= nbsp;        : 2014-09-30
>
> Abstract:
>    This specification describes the configuration = of pro-active MPLS-TP
>    Operations, Administration, and Maintenance (OA= M) Functions for a
>    given LSP using a set of TLVs that are carried = by the LSP-Ping
>    protocol.
>
>
> The IETF datatracker status page for this draft is:
> conf/
>
> There's also a htmlized version available at:
> 7
>
> A diff from the previous version is available at:
> conf-07
>
>
> Please note that it may take a couple of minutes from the time of=
> submission until the htmlized version and diff are available at t= ools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
>
> _______________________________________________
> mpls mailing list
>
> _______________________________________________
> mpls mailing list
 
--_000_7347100B5761DC41A166AC17F22DF1121B8A9937eusaamb103erics_-- --_004_7347100B5761DC41A166AC17F22DF1121B8A9937eusaamb103erics_ Content-Type: text/plain; name="draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt" Content-Description: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt Content-Disposition: attachment; filename="draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt"; size=56161; creation-date="Wed, 03 Dec 2014 02:30:59 GMT"; modification-date="Wed, 03 Dec 2014 02:31:08 GMT" Content-Transfer-Encoding: base64 DQoNCg0KDQpNUExTIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBFLiBCZWxsYWdhbWJhLCBFZC4NCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBNaXJza3ksIEVkLg0KSW50ZW5kZWQgc3RhdHVz OiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29u DQpFeHBpcmVzOiBKdW5lIDcsIDIwMTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBMLiBBbmRlcnNzb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEh1YXdlaQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUC4gU2tvbGRzdHJvbSwgRWQuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQWNyZW8gQUINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRC4gV2FyZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4g RHJha2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSnVuaXBlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciA0LCAyMDE0DQoNCg0KQ29uZmlndXJhdGlv biBvZiBQcm8tQWN0aXZlIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQgTWFpbnRlbmFu Y2UNCiAgICAoT0FNKSBGdW5jdGlvbnMgZm9yIE1QTFMtYmFzZWQgVHJhbnNwb3J0IE5ldHdvcmtz IHVzaW5nIExTUCBQaW5nDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1t cGxzLXRwLW9hbS1jb25mLTA4DQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBk ZXNjcmliZXMgdGhlIGNvbmZpZ3VyYXRpb24gb2YgcHJvLWFjdGl2ZSBNUExTLVRQDQogICBPcGVy YXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kIE1haW50ZW5hbmNlIChPQU0pIEZ1bmN0aW9ucyBm b3IgYQ0KICAgZ2l2ZW4gTFNQIHVzaW5nIGEgc2V0IG9mIFRMVnMgdGhhdCBhcmUgY2FycmllZCBi eSB0aGUgTFNQLVBpbmcNCiAgIHByb3RvY29sLg0KDQpTdGF0dXMgb2YgVGhpcyBNZW1vDQoNCiAg IFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0 aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n DQogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0NCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJl IGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt RHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRo YW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwg ZXhwaXJlIG9uIEp1bmUgNywgMjAxNS4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmln aHQgKGMpIDIwMTQgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUN CiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQoNCg0KDQoNCkJl bGxhZ2FtYmEsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKdW5lIDcsIDIwMTUgICAgICAgICAgICAg ICAgICBbUGFnZSAxXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgIEV4dGVuc2lvbnMgZm9yIE1Q TFMtVFAgT0FNIENvbmYgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIFRoaXMgZG9jdW1lbnQg aXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zp c2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRm Lm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRp b24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBj YXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3 aXRoIHJlc3BlY3QNCiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFj dGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExp Y2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVzdCBM ZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KICAg ZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0KDQpUYWJsZSBvZiBDb250 ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDINCiAgICAgMS4xLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0 aGlzIGRvY3VtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAgIDEuMS4xLiAg VGVybWlub2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0 DQogICAgICAgMS4xLjIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDQNCiAgIDIuICBUaGVvcnkgb2YgT3BlcmF0aW9ucyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAyLjEuICBNUExTIE9BTSBD b25maWd1cmF0aW9uIE9wZXJhdGlvbiBPdmVydmlldyAuIC4gLiAuIC4gLiAuIC4gICA0DQogICAg ICAgMi4xLjEuICBDb25maWd1cmF0aW9uIG9mIEJGRCBzZXNzaW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDUNCiAgICAgICAyLjEuMi4gIENvbmZpZ3VyYXRpb24gb2YgUGVyZm9ybWFuY2Ug TW9uaXRvcmluZyAuIC4gLiAuIC4gLiAuICAgNQ0KICAgICAgIDIuMS4zLiAgQ29uZmlndXJhdGlv biBvZiBGYXVsdCBNYW5hZ2VtZW50IFNpZ25hbHMgLiAuIC4gLiAuIC4gICA2DQogICAgIDIuMi4g IE1QTFMgT0FNIEZ1bmN0aW9ucyBUTFYgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDYNCiAgICAgICAyLjIuMS4gIEJGRCBDb25maWd1cmF0aW9uIHN1Yi1UTFYgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgOA0KICAgICAgIDIuMi4yLiAgTG9jYWwgRGlzY3JpbWluYXRv ciBzdWItVExWIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQogICAgICAgMi4yLjMuICBO ZWdvdGlhdGlvbiBUaW1lciBQYXJhbWV0ZXJzIHN1Yi1UTFYgIC4gLiAuIC4gLiAuIC4gLiAgMTAN CiAgICAgICAyLjIuNC4gIEJGRCBBdXRoZW50aWNhdGlvbiBzdWItVExWICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxMg0KICAgICAgIDIuMi41LiAgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQg c3ViLVRMViAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyDQogICAgICAgMi4yLjYuICBQTSBMb3Nz IE1lYXN1cmVtZW50IHN1Yi1UTFYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQNCiAgICAg ICAyLjIuNy4gIFBNIERlbGF5IE1lYXN1cmVtZW50IHN1Yi1UTFYgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxNQ0KICAgICAgIDIuMi44LiAgRmF1bHQgTWFuYWdlbWVudCBTaWduYWwgc3ViLVRM ViAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2DQogICAgICAgMi4yLjkuICBTb3VyY2UgTUVQLUlE IHN1Yi1UTFYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgNCiAgIDMuICBTdW1t YXJ5IG9mIE1QTFMgT0FNIGNvbmZpZ3VyYXRpb24gZXJyb3JzICAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxOA0KICAgNC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDE5DQogICAgIDQuMS4gIFRMViBhbmQgc3ViLVRMViBBbGxvY2F0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjANCiAgICAgNC4yLiAgT0FNIGNv bmZpZ3VyYXRpb24gZXJyb3JzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMA0K ICAgNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDIxDQogICA2LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjENCiAgICAgNi4xLiAgTm9ybWF0aXZlIFJl ZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMg0KICAgICA2 LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDIzDQogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjMNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgY29uZmlndXJhdGlvbiBvZiBwcm8tYWN0aXZlIE1QTFMt VFANCiAgIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQgTWFpbnRlbmFuY2UgKE9BTSkg RnVuY3Rpb25zIGZvciBhDQogICBnaXZlbiBMU1AgdXNpbmcgVExWcyBjYXJyaWVkIGluIExTUC1Q aW5nIFtSRkM0Mzc5XS4gIEluIHBhcnRpY3VsYXIgaXQNCiAgIHNwZWNpZmllcyB0aGUgbWVjaGFu aXNtcyBuZWNlc3NhcnkgdG8gZXN0YWJsaXNoIE1QTFMtVFAgT0FNIGVudGl0aWVzDQogICBhdCB0 aGUgbWFpbnRlbmFuY2UgcG9pbnRzIGZvciBtb25pdG9yaW5nIGFuZCBwZXJmb3JtaW5nIG1lYXN1 cmVtZW50cw0KDQoNCg0KQmVsbGFnYW1iYSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEp1bmUgNywg MjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAg RXh0ZW5zaW9ucyBmb3IgTVBMUy1UUCBPQU0gQ29uZiAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0K ICAgb24gYW4gTFNQLCBhcyB3ZWxsIGFzIGRlZmluaW5nIGluZm9ybWF0aW9uIGVsZW1lbnRzIGFu ZCBwcm9jZWR1cmVzIHRvDQogICBjb25maWd1cmUgcHJvLWFjdGl2ZSBNUExTLVRQIE9BTSBmdW5j dGlvbnMgcnVubmluZyBiZXR3ZWVuIExFUnMuDQogICBJbml0aWFsaXphdGlvbiBhbmQgY29udHJv bCBvZiBvbi1kZW1hbmQgTVBMUy1UUCBPQU0gZnVuY3Rpb25zIGFyZQ0KICAgZXhwZWN0ZWQgdG8g YmUgY2FycmllZCBvdXQgYnkgZGlyZWN0bHkgYWNjZXNzaW5nIG5ldHdvcmsgbm9kZXMgdmlhIGEN CiAgIG1hbmFnZW1lbnQgaW50ZXJmYWNlOyBoZW5jZSBjb25maWd1cmF0aW9uIGFuZCBjb250cm9s IG9mIG9uLWRlbWFuZA0KICAgT0FNIGZ1bmN0aW9ucyBhcmUgb3V0LW9mLXNjb3BlIGZvciB0aGlz IGRvY3VtZW50Lg0KDQogICBUaGUgVHJhbnNwb3J0IFByb2ZpbGUgb2YgTVBMUyBtdXN0LCBieSBk ZWZpbml0aW9uIFtSRkM1NjU0XSwgYmUNCiAgIGNhcGFibGUgb2Ygb3BlcmF0aW5nIHdpdGhvdXQg YSBjb250cm9sIHBsYW5lLiAgVGhlcmVmb3JlIHRoZXJlIGFyZQ0KICAgc2V2ZXJhbCBvcHRpb25z IGZvciBjb25maWd1cmluZyBNUExTLVRQIE9BTSwgd2l0aG91dCBhIGNvbnRyb2wgcGxhbmUNCiAg IGJ5IGVpdGhlciB1c2luZyBhbiBOTVMgb3IgTFNQIFBpbmcsIG9yIHdpdGggYSBjb250cm9sIHBs YW5lIHVzaW5nDQogICBzaWduYWxpbmcgcHJvdG9jb2xzIFJTVlAtVEUgW1JGQzMyMDldIGFuZC9v ciBULUxEUCBbUkZDNTAzNl0uDQoNCiAgIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFAp IGRlc2NyaWJlcyBhIHByb2ZpbGUgb2YgTVBMUyB0aGF0DQogICBlbmFibGVzIG9wZXJhdGlvbmFs IG1vZGVscyB0eXBpY2FsIGluIHRyYW5zcG9ydCBuZXR3b3Jrcywgd2hpbGUNCiAgIHByb3ZpZGlu ZyBhZGRpdGlvbmFsIE9BTSwgc3Vydml2YWJpbGl0eSBhbmQgb3RoZXIgbWFpbnRlbmFuY2UNCiAg IGZ1bmN0aW9ucyBub3QgY3VycmVudGx5IHN1cHBvcnRlZCBieSBNUExTLiAgW1JGQzU4NjBdIGRl ZmluZXMgdGhlDQogICByZXF1aXJlbWVudHMgZm9yIHRoZSBPQU0gZnVuY3Rpb25hbGl0eSBvZiBN UExTLVRQLg0KDQogICBQcm8tYWN0aXZlIE1QTFMtVFAgT0FNIGlzIHBlcmZvcm1lZCBieSBzZXQg b2YgcHJvdG9jb2xzLCBCaS0NCiAgIGRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChC RkQpIFtSRkM2NDI4XSBmb3IgQ29udGludWl0eQ0KICAgQ2hlY2svQ29ubmVjdGl2aXR5IFZlcmlm aWNhdGlvbiwgdGhlIGRlbGF5IG1lYXN1cmVtZW50IHByb3RvY29sIChETSkNCiAgIFtSRkM2Mzc0 XSwgW1JGQzYzNzVdIGZvciBkZWxheSBhbmQgZGVsYXkgdmFyaWF0aW9uIChqaXR0ZXIpDQogICBt ZWFzdXJlbWVudHMsIGFuZCB0aGUgbG9zcyBtZWFzdXJlbWVudCAoTE0pIHByb3RvY29sIFtSRkM2 Mzc0XSwNCiAgIFtSRkM2Mzc1XSBmb3IgcGFja2V0IGxvc3MgYW5kIHRocm91Z2hwdXQgbWVhc3Vy ZW1lbnRzLiAgQWRkaXRpb25hbGx5DQogICB0aGVyZSBpcyBhIG51bWJlciBvZiBGYXVsdCBNYW5h Z2VtZW50IFNpZ25hbHMgdGhhdCBjYW4gYmUgY29uZmlndXJlZC4NCg0KICAgQkZEIGlzIGEgcHJv dG9jb2wgdGhhdCBwcm92aWRlcyBsb3ctb3ZlcmhlYWQsIGZhc3QgZGV0ZWN0aW9uIG9mDQogICBm YWlsdXJlcyBpbiB0aGUgcGF0aCBiZXR3ZWVuIHR3byBmb3J3YXJkaW5nIGVuZ2luZXMsIGluY2x1 ZGluZyB0aGUNCiAgIGludGVyZmFjZXMsIGRhdGEgbGluayhzKSwgYW5kLCB0byB0aGUgZXh0ZW50 IHBvc3NpYmxlLCB0aGUgZm9yd2FyZGluZw0KICAgZW5naW5lcyB0aGVtc2VsdmVzLiAgQkZEIGNh biBiZSB1c2VkIHRvIGRldGVjdCB0aGUgY29udGludWl0eSBhbmQNCiAgIG1pcy1jb25uZWN0aW9u IGRlZmVjdHMgb2YgTVBMUy1UUCBwb2ludC10by1wb2ludCBhbmQgbWlnaHQgYWxzbyBiZQ0KICAg ZXh0ZW5kZWQgdG8gc3VwcG9ydCBwb2ludC10by1tdWx0aXBvaW50IGxhYmVsIHN3aXRjaGVkIHBh dGhzIChMU1BzKS4NCg0KICAgVGhlIGRlbGF5IGFuZCBsb3NzIG1lYXN1cmVtZW50cyBwcm90b2Nv bHMgW1JGQzYzNzRdLCBbUkZDNjM3NV0gdXNlIGENCiAgIHNpbXBsZSBxdWVyeS9yZXNwb25zZSBt b2RlbCBmb3IgcGVyZm9ybWluZyBib3RoIHVuaS0gYW5kIGJpLQ0KICAgZGlyZWN0aW9uYWwgbWVh c3VyZW1lbnRzIHRoYXQgYWxsb3cgdGhlIG9yaWdpbmF0aW5nIG5vZGUgdG8gbWVhc3VyZQ0KICAg cGFja2V0IGxvc3MgYW5kIGRlbGF5IGluIGZvcndhcmQgb3IgZm9yd2FyZCBhbmQgcmV2ZXJzZSBk aXJlY3Rpb25zLg0KICAgQnkgdGltZXN0YW1waW5nIGFuZC9vciB3cml0aW5nIGN1cnJlbnQgcGFj a2V0IGNvdW50ZXJzIHRvIHRoZQ0KICAgbWVhc3VyZW1lbnQgcGFja2V0cyBhdCBmb3VyIHRpbWVz IChUeCBhbmQgUnggaW4gYm90aCBkaXJlY3Rpb25zKQ0KICAgY3VycmVudCBkZWxheXMgYW5kIHBh Y2tldCBsb3NzZXMgY2FuIGJlIGNhbGN1bGF0ZWQuICBCeSBwZXJmb3JtaW5nDQogICBzdWNjZXNz aXZlIGRlbGF5IG1lYXN1cmVtZW50cyB0aGUgZGVsYXkgYW5kL29yIGludGVyLXBhY2tldCBkZWxh eQ0KICAgdmFyaWF0aW9uIChqaXR0ZXIpIGNhbiBiZSBjYWxjdWxhdGVkLiAgQ3VycmVudCB0aHJv dWdocHV0IGNhbiBiZQ0KICAgY2FsY3VsYXRlZCBmcm9tIHRoZSBwYWNrZXQgbG9zcyBtZWFzdXJl bWVudHMgYnkgZGl2aWRpbmcgdGhlIG51bWJlcg0KICAgb2YgcGFja2V0cyBzZW50L3JlY2VpdmVk IHdpdGggdGhlIHRpbWUgaXQgdG9vayB0byBwZXJmb3JtIHRoZQ0KICAgbWVhc3VyZW1lbnQsIGdp dmVuIGJ5IHRoZSB0aW1lc3RhbXAgaW4gTE0gaGVhZGVyLiAgQ29tYmluZWQgd2l0aCBhDQogICBw YWNrZXQgZ2VuZXJhdG9yIHRoZSB0aHJvdWdocHV0IG1lYXN1cmVtZW50IGNhbiBiZSB1c2VkIHRv IG1lYXN1cmUNCiAgIHRoZSBtYXhpbXVtIGNhcGFjaXR5IG9mIGEgcGFydGljdWxhciBMU1AuICBJ dCBzaG91bGQgYmUgbm90ZWQgdGhhdA0KDQoNCg0KQmVsbGFnYW1iYSwgZXQgYWwuICAgICAgICBF eHBpcmVzIEp1bmUgNywgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoNCg0KSW50ZXJu ZXQtRHJhZnQgICAgICAgRXh0ZW5zaW9ucyBmb3IgTVBMUy1UUCBPQU0gQ29uZiAgICAgICBEZWNl bWJlciAyMDE0DQoNCg0KICAgaGVyZSB3ZSBhcmUgbm90IGNvbmZpZ3VyaW5nIG9uLWRlbWFuZCB0 aHJvdWdocHV0IGVzdGltYXRlcyBiYXNlZCBvbg0KICAgc2F0dXJhdGluZyB0aGUgY29ubmVjdGlv biBhcyBkZWZpbmVkIGluIFtSRkM2MzcxXS4gIFJhdGhlciwgd2Ugb25seQ0KICAgZW5hYmxlIHRo ZSBlc3RpbWF0aW9uIG9mIHRoZSBjdXJyZW50IHRocm91Z2hwdXQgYmFzZWQgb24gbG9zcw0KICAg bWVhc3VyZW1lbnRzLg0KDQoxLjEuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQN Cg0KMS4xLjEuICBUZXJtaW5vbG9neQ0KDQogICBCRkQgLSBCaWRpcmVjdGlvbmFsIEZvcndhcmRp bmcgRGV0ZWN0aW9uDQoNCiAgIERNIC0gRGVsYXkgTWVhc3VyZW1lbnQNCg0KICAgRk1TIC0gRmF1 bHQgTWFuYWdlbWVudCBTaWduYWwNCg0KICAgRy1BQ2ggLSBHZW5lcmljIEFzc29jaWF0ZWQgQ2hh bm5lbA0KDQogICBMU1AgLSBMYWJlbCBTd2l0Y2hlZCBQYXRoDQoNCiAgIExNIC0gTG9zcyBNZWFz dXJlbWVudA0KDQogICBNRVAgLSBNYWludGVuYW5jZSBFbnRpdHkgR3JvdXAgRW5kIFBvaW50DQoN CiAgIE1QTFMgLSBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcNCg0KICAgTVBMUy1UUCAt IE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUNCg0KICAgUE0gLSBQZXJmb3JtYW5jZSBNZWFzdXJlbWVu dA0KDQoxLjEuMi4gIFJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KDQogICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAi U0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05B TCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJl ZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uDQoNCjIuICBUaGVvcnkgb2YgT3BlcmF0aW9ucw0KDQoy LjEuICBNUExTIE9BTSBDb25maWd1cmF0aW9uIE9wZXJhdGlvbiBPdmVydmlldw0KDQogICBUaGUg TVBMUy1UUCBPQU0gdG9vbCBzZXQgaXMgZGVzY3JpYmVkIGluIHRoZSBbUkZDNjY2OV0uDQoNCiAg IExTUCBQaW5nLCBvciBhbHRlcm5hdGl2ZWx5IFJTVlAtVEUgW1JTVlAtVEUtQ09ORl0sIGNhbiBi ZSB1c2VkIHRvDQogICBzaW1wbHkgZW5hYmxlIHRoZSBkaWZmZXJlbnQgT0FNIGZ1bmN0aW9ucywg Ynkgc2V0dGluZyB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgZmxhZ3MgaW4gdGhlIE1QTFMgT0FNIEZ1 bmN0aW9ucyBUTFYsIFNlY3Rpb24gMi4yLiAgRm9yDQogICBhIG1vcmUgZGV0YWlsZWQgY29uZmln dXJhdGlvbiBvbmUgbWF5IGluY2x1ZGUgc3ViLVRMVnMgZm9yIHRoZQ0KICAgZGlmZmVyZW50IE9B TSBmdW5jdGlvbnMgaW4gb3JkZXIgdG8gc3BlY2lmeSB2YXJpb3VzIHBhcmFtZXRlcnMgaW4NCiAg IGRldGFpbC4NCg0KDQoNCg0KQmVsbGFnYW1iYSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEp1bmUg NywgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAg ICAgRXh0ZW5zaW9ucyBmb3IgTVBMUy1UUCBPQU0gQ29uZiAgICAgICBEZWNlbWJlciAyMDE0DQoN Cg0KICAgVHlwaWNhbGx5IGludGVybWVkaWF0ZSBub2RlcyBzaW1wbHkgZm9yd2FyZCBPQU0gY29u ZmlndXJhdGlvbiBUTFZzIHRvDQogICB0aGUgZW5kLW5vZGUgd2l0aG91dCBhbnkgcHJvY2Vzc2lu ZyBvciBtb2RpZmljYXRpb24gQXQgbGVhc3Qgb25lDQogICBleGNlcHRpb24gdG8gdGhpcyBpcyBp ZiB0aGUgRk1TIHN1Yi1UTFYgU2VjdGlvbiAyLjIuOCBpcyBwcmVzZW50Lg0KICAgVGhpcyBzdWIt VExWIGhhcyB0byBiZSBleGFtaW5lZCBldmVuIGJ5IGludGVybWVkaWF0ZSBub2Rlcy4gIFRoZSBz dWItDQogICBUTFYgTUFZIGJlIHByZXNlbnQgaWYgYSBmbGFnIGlzIHNldCBpbiB0aGUgTVBMUyBP QU0gRnVuY3Rpb25zIFRMVi4NCg0KMi4xLjEuICBDb25maWd1cmF0aW9uIG9mIEJGRCBzZXNzaW9u cw0KDQogICBGb3IgdGhpcyBzcGVjaWZpY2F0aW9uLCBCRkQgTVVTVCBydW4gaW4gZWl0aGVyIG9u ZSBvZiB0aGUgdHdvIG1vZGVzOg0KDQogICAgICAtIEFzeW5jaHJvbm91cyBtb2RlLCB3aGVyZSBi b3RoIHNpZGVzIHNob3VsZCBiZSBpbiBhY3RpdmUgbW9kZQ0KDQogICAgICAtIFVuaWRpcmVjdGlv bmFsIG1vZGUNCg0KICAgSW4gdGhlIHNpbXBsZXN0IHNjZW5hcmlvIExTUCBQaW5nIFtSRkM1ODg0 XSwgb3IgYWx0ZXJuYXRpdmVseSBSU1ZQLVRFDQogICBbUlNWUC1URS1DT05GXSwgaXMgdXNlZCBv bmx5IHRvIGJvb3RzdHJhcCBhIEJGRCBzZXNzaW9uIGZvciBhbiBMU1AsDQogICB3aXRob3V0IGFu eSB0aW1lciBuZWdvdGlhdGlvbi4NCg0KICAgVGltZXIgbmVnb3RpYXRpb24gY2FuIGJlIHBlcmZv cm1lZCBlaXRoZXIgaW4gc3Vic2VxdWVudCBCRkQgY29udHJvbA0KICAgbWVzc2FnZXMgKGluIHRo aXMgY2FzZSB0aGUgb3BlcmF0aW9uIGlzIHNpbWlsYXIgdG8gTFNQIFBpbmcgYmFzZWQNCiAgIGJv b3RzdHJhcHBpbmcgZGVzY3JpYmVkIGluIFtSRkM1ODg0XSkgb3IgZGlyZWN0bHkgaW4gdGhlIExT UC1QaW5nDQogICBjb25maWd1cmF0aW9uIG1lc3NhZ2VzLg0KDQogICBXaGVuIEJGRCBDb250cm9s IHBhY2tldHMgYXJlIHRyYW5zcG9ydGVkIGluIHRoZSBBQ0ggZW5jYXBzdWxhdGlvbg0KICAgdGhl eSBhcmUgbm90IHByb3RlY3RlZCBieSBhbnkgZW5kLXRvLWVuZCBjaGVja3N1bSwgb25seSBsb3dl ci1sYXllcnMNCiAgIGFyZSBwcm92aWRpbmcgZXJyb3IgZGV0ZWN0aW9uL2NvcnJlY3Rpb24uICBB IHNpbmdsZSBiaXQgZXJyb3IsIGUuZy4gYQ0KICAgZmxpcHBlZCBiaXQgaW4gdGhlIEJGRCBTdGF0 ZSBmaWVsZCBjb3VsZCBjYXVzZSB0aGUgcmVjZWl2aW5nIGVuZCB0bw0KICAgd3JvbmdseSBjb25j bHVkZSB0aGF0IHRoZSBsaW5rIGlzIGRvd24gYW5kIGluIHR1cm4gdHJpZ2dlciBwcm90ZWN0aW9u DQogICBzd2l0Y2hpbmcuICBUbyBwcmV2ZW50IHRoaXMgZnJvbSBoYXBwZW5pbmcgdGhlIEJGRCBD b25maWd1cmF0aW9uIHN1Yi0NCiAgIFRMViwgU2VjdGlvbiAyLjIuMSwgaGFzIGFuIEludGVncml0 eSBmbGFnIHRoYXQgd2hlbiBzZXQgZW5hYmxlcyBCRkQNCiAgIEF1dGhlbnRpY2F0aW9uIHVzaW5n IEtleWVkIFNIQTEgd2l0aCBhbiBlbXB0eSBrZXkgKGFsbCAwcykgW1JGQzU4ODBdLg0KICAgVGhp cyB3b3VsZCBtYWtlIGV2ZXJ5IEJGRCBDb250cm9sIHBhY2tldCBjYXJyeSBhbiBTSEExIGhhc2gg b2YgaXRzZWxmDQogICB0aGF0IGNhbiBiZSB1c2VkIHRvIGRldGVjdCBlcnJvcnMuDQoNCiAgIElm IEJGRCBBdXRoZW50aWNhdGlvbiB1c2luZyBhIHByZS1zaGFyZWQga2V5L3Bhc3N3b3JkIGlzIGRl c2lyZWQNCiAgIChpLmUuIGF1dGhlbnRpY2F0aW9uIGFuZCBub3Qgb25seSBlcnJvciBkZXRlY3Rp b24pIHRoZSBCRkQNCiAgIEF1dGhlbnRpY2F0aW9uIHN1Yi1UTFYsIFNlY3Rpb24gMi4yLjQsIE1V U1QgYmUgaW5jbHVkZWQgaW4gdGhlIEJGRA0KICAgQ29uZmlndXJhdGlvbiBzdWItVExWLiAgVGhl IEJGRCBBdXRoZW50aWNhdGlvbiBzdWItVExWIGlzIHVzZWQgdG8NCiAgIHNwZWNpZnkgd2hpY2gg YXV0aGVudGljYXRpb24gbWV0aG9kIHRoYXQgc2hvdWxkIGJlIHVzZWQgYW5kIHdoaWNoDQogICBw cmUtc2hhcmVkIGtleS8gcGFzc3dvcmQgdGhhdCBzaG91bGQgYmUgdXNlZCBmb3IgdGhpcyBwYXJ0 aWN1bGFyDQogICBzZXNzaW9uLiAgSG93IHRoZSBrZXkgZXhjaGFuZ2UgaXMgcGVyZm9ybWVkIGlz IG91dCBvZiBzY29wZSBvZiB0aGlzDQogICBkb2N1bWVudC4NCg0KMi4xLjIuICBDb25maWd1cmF0 aW9uIG9mIFBlcmZvcm1hbmNlIE1vbml0b3JpbmcNCg0KICAgSXQgaXMgcG9zc2libGUgdG8gY29u ZmlndXJlIFBlcmZvcm1hbmNlIE1vbml0b3JpbmcgZnVuY3Rpb25hbGl0aWVzDQogICBzdWNoIGFz IExvc3MsIERlbGF5LCBEZWxheS9JbnRlcnBhY2tldCBEZWxheSB2YXJpYXRpb24gKGppdHRlciks IGFuZA0KICAgVGhyb3VnaHB1dCBhcyBkZXNjcmliZWQgaW4gW1JGQzYzNzRdLg0KDQoNCg0KQmVs bGFnYW1iYSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEp1bmUgNywgMjAxNSAgICAgICAgICAgICAg ICAgIFtQYWdlIDVdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgRXh0ZW5zaW9ucyBmb3IgTVBM Uy1UUCBPQU0gQ29uZiAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAgV2hlbiBjb25maWd1cmlu ZyBQZXJmb3JtYW5jZSBtb25pdG9yaW5nIGZ1bmN0aW9uYWxpdGllcyBpdCBpcw0KICAgcG9zc2li bGUgdG8gY2hvb3NlIGVpdGhlciB0aGUgZGVmYXVsdCBjb25maWd1cmF0aW9uLCBieSBvbmx5IHNl dHRpbmcNCiAgIHRoZSByZXNwZWN0aXZlIGZsYWdzIGluIHRoZSBNUExTIE9BTSBmdW5jdGlvbnMg VExWLCBvciBhIGN1c3RvbWl6ZWQNCiAgIGNvbmZpZ3VyYXRpb24uICBUbyBjdXN0b21pemUgdGhl IGNvbmZpZ3VyYXRpb24gb25lIHdvdWxkIHNldCB0aGUNCiAgIHJlc3BlY3RpdmUgZmxhZ3MgaW4g dGhlIGluY2x1ZGluZyB0aGUgcmVzcGVjdGl2ZSBMb3NzIGFuZC9vciBEZWxheQ0KICAgc3ViLVRM VnMpLg0KDQogICBCeSBzZXR0aW5nIHRoZSBQTSBMb3NzIGZsYWcgaW4gdGhlIE1QTFMgT0FNIEZ1 bmN0aW9ucyBUTFYgYW5kDQogICBpbmNsdWRpbmcgdGhlIFBNIExvc3Mgc3ViLVRMViwgU2VjdGlv biAyLjIuNiwgb25lIGNhbiBjb25maWd1cmUgdGhlDQogICBtZWFzdXJlbWVudCBpbnRlcnZhbCBh bmQgbG9zcyB0aHJlc2hvbGQgdmFsdWVzIGZvciB0cmlnZ2VyaW5nDQogICBwcm90ZWN0aW9uLg0K DQogICBEZWxheSBtZWFzdXJlbWVudHMgYXJlIGNvbmZpZ3VyZWQgYnkgc2V0dGluZyBQTSBEZWxh eSBmbGFnIGluIHRoZQ0KICAgTVBMUyBPQU0gRnVuY3Rpb25zIFRMViBhbmQgaW5jbHVkaW5nIHRo ZSBQTSBEZWxheSBzdWItVExWLA0KICAgU2VjdGlvbiAyLjIuNywgb25lIGNhbiBjb25maWd1cmUg dGhlIG1lYXN1cmVtZW50IGludGVydmFsIGFuZCB0aGUNCiAgIGRlbGF5IHRocmVzaG9sZCB2YWx1 ZXMgZm9yIHRyaWdnZXJpbmcgcHJvdGVjdGlvbi4NCg0KMi4xLjMuICBDb25maWd1cmF0aW9uIG9m IEZhdWx0IE1hbmFnZW1lbnQgU2lnbmFscw0KDQogICBUbyBjb25maWd1cmUgRmF1bHQgTWFuYWdl bWVudCBTaWduYWxzIChGTVMpIGFuZCB0aGVpciByZWZyZXNoIHRpbWUNCiAgIHRoZSBGTVMgZmxh ZyBpbiB0aGUgTVBMUyBPQU0gRnVuY3Rpb25zIFRMViBNVVNUIGJlIHNldCBhbmQgdGhlIEZNUw0K ICAgc3ViLVRMViBNVVNUIGJlIGluY2x1ZGVkLiAgV2hlbiBjb25maWd1cmluZyBGTVMsIGFuIGlt cGxlbWVudGF0aW9uDQogICBjYW4gZW5hYmxlIHRoZSBkZWZhdWx0IGNvbmZpZ3VyYXRpb24gYnkg c2V0dGluZyB0aGUgRk1TIGZsYWcgaW4gdGhlDQogICBPQU0gRnVuY3Rpb24gRmxhZ3Mgc3ViLVRM Vi4gIElmIGFuIGltcGxlbWVudGF0aW9uIHdpc2hlcyB0byBtb2RpZnkNCiAgIHRoZSBkZWZhdWx0 IGNvbmZpZ3VyYXRpb24gaXQgaW5jbHVkZXMgYSBNUExTIE9BTSBGTVMgc3ViLVRMVi4NCg0KICAg SWYgYW4gaW50ZXJtZWRpYXRlIHBvaW50IGlzIG1lYW50IHRvIG9yaWdpbmF0ZSBmYXVsdCBtYW5h Z2VtZW50DQogICBzaWduYWwgbWVzc2FnZXMgdGhpcyBtZWFucyB0aGF0IHN1Y2ggYW4gaW50ZXJt ZWRpYXRlIHBvaW50IGlzDQogICBhc3NvY2lhdGVkIHRvIGEgU2VydmVyIE1FUCB0aHJvdWdoIGEg Y28tbG9jYXRlZCBNUExTLVRQIGNsaWVudC9zZXJ2ZXINCiAgIGFkYXB0YXRpb24gZnVuY3Rpb24u ICBTdWNoIGEgU2VydmVyIE1FUCBuZWVkcyB0byBiZSBjb25maWd1cmVkIGJ5IGl0cw0KICAgb3du IExTUC1waW5nIHNlc3Npb24gb3IsIGFsdGVybmF0aXZlbHksIHZpYSBhbiBOTVMgb3IgUlNWUC1U RS4NCiAgIEhvd2V2ZXIsIGJ5IHNldHRpbmcgdGhlIFMgZmxhZyBTZWN0aW9uIDIuMi44IGluIHRo ZSBGTVMgc3ViLVRMViBhDQogICBjbGllbnQgTFNQIGNhbiBpbmRpY2F0ZSB0aGF0IGl0IHdvdWxk IGxpa2UgYW4gYXNzb2NpYXRpb24gdG8gYmUNCiAgIGNyZWF0ZWQgdG8gdGhlIHNlcnZlciBNRVAo cykgb24gYW55IGludGVybWVkaWF0ZSBub2Rlcy4NCg0KMi4yLiAgTVBMUyBPQU0gRnVuY3Rpb25z IFRMVg0KDQogICBUaGUgTVBMUyBPQU0gRnVuY3Rpb25zIFRMViBwcmVzZW50ZWQgaW4gRmlndXJl IDEgaXMgY2FycmllZCBhcyBhIFRMVg0KICAgb2YgdGhlIE1QTFMgRWNobyBSZXF1ZXN0L1JlcGx5 IG1lc3NhZ2VzIFtSRkM0Mzc5XS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJlbGxhZ2FtYmEs IGV0IGFsLiAgICAgICAgRXhwaXJlcyBKdW5lIDcsIDIwMTUgICAgICAgICAgICAgICAgICBbUGFn ZSA2XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgIEV4dGVuc2lvbnMgZm9yIE1QTFMtVFAgT0FN IENvbmYgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgICAwICAgICAgICAgICAgICAgICAgIDEg ICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgfCAgTVBMUyBPQU0gRnVuYy4gVHlwZSAoVEJBMSkgICB8ICAgICAgICAgICBM ZW5ndGggICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8Q3xWfEZ8THxEfFR8ICAgICAg ICAgICBSZXNlcnZlZCAgKE1CWikgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1Yi1UTFZzICAg ICAgICAgICAgICAgICAgICAgICAgICAgIH4NCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQog ICAgICAgICAgICAgICAgICBGaWd1cmUgMTogTVBMUyBPQU0gRnVuY3Rpb25zIFRMViBmb3JtYXQN Cg0KICAgVGhlIE1QTFMgT0FNIEZ1bmN0aW9ucyBUTFYgY29udGFpbnMgYSBudW1iZXIgb2YgZmxh Z3MgaW5kaWNhdGluZw0KICAgd2hpY2ggT0FNIGZ1bmN0aW9ucyBzaG91bGQgYmUgYWN0aXZhdGVk IGFzIHdlbGwgYXMgT0FNIGZ1bmN0aW9uDQogICBzcGVjaWZpYyBzdWItVExWcyB3aXRoIGNvbmZp Z3VyYXRpb24gcGFyYW1ldGVycyBmb3IgdGhlIHBhcnRpY3VsYXINCiAgIGZ1bmN0aW9uLg0KDQog ICBUeXBlOiBpbmRpY2F0ZXMgdGhlIE1QTFMgT0FNIEZ1bmN0aW9ucyBUTFYgU2VjdGlvbiA0Lg0K DQogICBMZW5ndGg6IHRoZSBsZW5ndGggb2YgdGhlIE1QTFMgT0FNIEZ1bmN0aW9uIEZsYWdzIGZp ZWxkIGluY2x1ZGluZyB0aGUNCiAgIHRvdGFsIGxlbmd0aCBvZiB0aGUgc3ViLVRMVnMgaW4gb2N0 ZXRzLg0KDQogICBNUExTIE9BTSBGdW5jdGlvbiBGbGFnczogYSBiaXRtYXAgbnVtYmVyZWQgZnJv bSBsZWZ0IHRvIHJpZ2h0IGFzDQogICBzaG93biBpbiB0aGUgZmlndXJlLg0KDQogICBUaGVzZSBm bGFncyBhcmUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFzIHByZXNlbnRlZCBpbiBUYWJsZSAx Og0KDQogICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICAgQml0ICAgICB8IE1QTFMgT0FNIEZ1bmN0aW9u ICB8IERlc2NyaXB0aW9uICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgUG9zaXRpb24gIHwg ICAgICAgIEZsYWcgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCiAgIHwgICAgIDAgICAgICB8ICAgICAgICAgQyAgICAgICAgICB8IENv bnRpbnVpdHkgQ2hlY2sgKENDKSAgICAgICAgICAgfA0KICAgfCAgICAgMSAgICAgIHwgICAgICAg ICBWICAgICAgICAgIHwgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiAoQ1YpICB8DQogICB8ICAg ICAyICAgICAgfCAgICAgICAgIEYgICAgICAgICAgfCBGYXVsdCBNYW5hZ2VtZW50IFNpZ25hbCAo Rk1TKSAgIHwNCiAgIHwgICAgIDMgICAgICB8ICAgICAgICAgTCAgICAgICAgICB8IFBlcmZvcm1h bmNlIE1lYXN1cmVtZW50L0xvc3MgICAgfA0KICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgIHwgKFBNL0xvc3MpICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICA0ICAg ICAgfCAgICAgICAgIEQgICAgICAgICAgfCBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudC9EZWxheSAg IHwNCiAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8IChQTS9EZWxheSkgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgfCAgICAgNSAgICAgIHwgICAgICAgICBUICAgICAgICAg IHwgVGhyb3VnaHB1dCBNZWFzdXJlbWVudCkgICAgICAgICB8DQogICB8ICAgIDYtMzEgICAgfCAg ICAgICAgICAgICAgICAgICAgfCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KDQogICAgICAgICAgICAgICAgICAgICAgICBUYWJsZSAxOiBNUExTIE9B TSBUTFYgRmxhZ3MNCg0KICAgU3ViLVRMVnMgY29ycmVzcG9uZGluZyB0byB0aGUgZGlmZmVyZW50 IGZsYWdzIGFyZSBhcyBmb2xsb3dzOg0KDQoNCg0KDQpCZWxsYWdhbWJhLCBldCBhbC4gICAgICAg IEV4cGlyZXMgSnVuZSA3LCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCg0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICBFeHRlbnNpb25zIGZvciBNUExTLVRQIE9BTSBDb25mICAgICAgIERl Y2VtYmVyIDIwMTQNCg0KDQogICAgICAtIEJGRCBDb25maWd1cmF0aW9uIHN1Yi1UTFYsIHdoaWNo IE1VU1QgYmUgaW5jbHVkZWQgaWYgdGhlIENDIGFuZC8NCiAgICAgIG9yIHRoZSBDViBPQU0gRnVu Y3Rpb24gZmxhZyBpcyBzZXQuICBUaGlzIHN1Yi1UTFYgTVVTVCBjYXJyeSBhDQogICAgICAiQkZE IExvY2FsIERpc2NyaW1pbmF0b3Igc3ViLVRMViIgYW5kIGEgIlRpbWVyIE5lZ290aWF0aW9uDQog ICAgICBQYXJhbWV0ZXJzIHN1Yi1UTFYiIGlmIHRoZSBOIGZsYWcgaXMgY2xlYXJlZC4gIFRoZSAi U291cmNlIE1FUC1JRA0KICAgICAgc3ViLVRMViIgTVVTVCBhbHNvIGJlIGluY2x1ZGVkLiAgSWYg dGhlIEkgZmxhZyBpcyBzZXQsIHRoZSAiQkZEDQogICAgICBBdXRoZW50aWNhdGlvbiBzdWItVExW IiBNQVkgYmUgaW5jbHVkZWQuDQoNCiAgICAgIC0gUE0gTG9zcyBzdWItVExWIHdpdGhpbiB0aGUg IlBlcmZvcm1hbmNlIE1vbml0b3Jpbmcgc3ViLVRMViIsDQogICAgICB3aGljaCBNQVkgYmUgaW5j bHVkZWQgaWYgdGhlIFBNL0xvc3MgT0FNIEZ1bmN0aW9uIGZsYWcgaXMgc2V0LiAgSWYNCiAgICAg IHRoZSAiUE0gTG9zcyBzdWItVExWIiBpcyBub3QgaW5jbHVkZWQsIGRlZmF1bHQgY29uZmlndXJh dGlvbg0KICAgICAgdmFsdWVzIGFyZSB1c2VkLiAgU3VjaCBzdWItVExWIE1BWSBhbHNvIGJlIGlu Y2x1ZGVkIGluIGNhc2UgdGhlDQogICAgICBUaHJvdWdocHV0IGZ1bmN0aW9uIGZsYWcgaXMgc2V0 IGFuZCB0aGVyZSBpcyB0aGUgbmVlZCB0byBzcGVjaWZ5DQogICAgICBtZWFzdXJlbWVudCBpbnRl cnZhbCBkaWZmZXJlbnQgZnJvbSB0aGUgZGVmYXVsdCBvbmVzLiAgSW4gZmFjdCB0aGUNCiAgICAg IHRocm91Z2hwdXQgbWVhc3VyZW1lbnQgbWFrZSB1c2Ugb2YgdGhlIHNhbWUgdG9vbCBhcyB0aGUg bG9zcw0KICAgICAgbWVhc3VyZW1lbnQsIGhlbmNlIHRoZSBzYW1lIFRMViBpcyB1c2VkLg0KDQog ICAgICAtIFBNIERlbGF5IHN1Yi1UTFYgd2l0aGluIHRoZSAiUGVyZm9ybWFuY2UgTW9uaXRvcmlu ZyBzdWItVExWIiwNCiAgICAgIHdoaWNoIE1BWSBiZSBpbmNsdWRlZCBpZiB0aGUgUE0vRGVsYXkg T0FNIEZ1bmN0aW9uIGZsYWcgaXMgc2V0Lg0KICAgICAgSWYgdGhlICJQTSBEZWxheSBzdWItVExW IiBpcyBub3QgaW5jbHVkZWQsIGRlZmF1bHQgY29uZmlndXJhdGlvbg0KICAgICAgdmFsdWVzIGFy ZSB1c2VkLg0KDQogICAgICAtIEZNUyBzdWItVExWLCB3aGljaCBNQVkgYmUgaW5jbHVkZWQgaWYg dGhlIEZNUyBPQU0gRnVuY3Rpb24gZmxhZw0KICAgICAgaXMgc2V0LiAgSWYgdGhlICJGTVMgc3Vi LVRMViIgaXMgbm90IGluY2x1ZGVkLCBkZWZhdWx0DQogICAgICBjb25maWd1cmF0aW9uIHZhbHVl cyBhcmUgdXNlZC4NCg0KMi4yLjEuICBCRkQgQ29uZmlndXJhdGlvbiBzdWItVExWDQoNCiAgIFRo ZSBCRkQgQ29uZmlndXJhdGlvbiBzdWItVExWLCBkZXBpY3RlZCBGaWd1cmUgMiwgaXMgZGVmaW5l ZCBmb3IgQkZEDQogICBPQU0gc3BlY2lmaWMgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzLiAgVGhl ICJCRkQgQ29uZmlndXJhdGlvbiBzdWItDQogICBUTFYiIGlzIGNhcnJpZWQgYXMgYSBzdWItVExW IG9mIHRoZSAiT0FNIEZ1bmN0aW9ucyBUTFYiLg0KDQogICBUaGlzIFRMViBhY2NvbW1vZGF0ZXMg Z2VuZXJpYyBCRkQgT0FNIGluZm9ybWF0aW9uIGFuZCBjYXJyaWVzIHN1Yi0NCiAgIFRMVnMuDQoN CiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCBCRkQgQ29uZi4gc3ViLXR5 cGUgICAgKDEwMCkgICB8ICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHwNCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICB8VmVycy58IFBIQiB8TnxTfEl8R3xVfEJ8ICAgUmVzZXJ2ZWQgKHNldCB0byBhbGwg MHMpICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICAgICAgICAgICAgIEZpZ3VyZSAy OiBCRkQgQ29uZmlndXJhdGlvbiBzdWItVExWIGZvcm1hdA0KDQogICBTdWItdHlwZTogaW5kaWNh dGVzIGEgbmV3IHN1Yi10eXBlLCB0aGUgQkZEIENvbmZpZ3VyYXRpb24gc3ViLVRMVg0KICAgKElB TkEgdG8gZGVmaW5lLCBzdWdnZXN0ZWQgdmFsdWUgMTAwKS4NCg0KICAgTGVuZ3RoOiBpbmRpY2F0 ZXMgdGhlIGxlbmd0aCBvZiB0aGUgVmFsdWUgZmllbGQgaW4gb2N0ZXRzICg0KS4NCg0KDQoNCkJl bGxhZ2FtYmEsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKdW5lIDcsIDIwMTUgICAgICAgICAgICAg ICAgICBbUGFnZSA4XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgIEV4dGVuc2lvbnMgZm9yIE1Q TFMtVFAgT0FNIENvbmYgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIFZlcnNpb246IGlkZW50 aWZpZXMgdGhlIEJGRCBwcm90b2NvbCB2ZXJzaW9uLiAgSWYgYSBub2RlIGRvZXMgbm90DQogICBz dXBwb3J0IGEgc3BlY2lmaWMgQkZEIHZlcnNpb24gYW4gZXJyb3IgbXVzdCBiZSBnZW5lcmF0ZWQ6 ICJPQU0NCiAgIFByb2JsZW0vVW5zdXBwb3J0ZWQgT0FNIFZlcnNpb24iLg0KDQogICBQSEI6IElk ZW50aWZpZXMgdGhlIFBlci1Ib3AgQmVoYXZpb3IgKFBIQikgdG8gYmUgdXNlZCBmb3IgcGVyaW9k aWMNCiAgIGNvbnRpbnVpdHkgbW9uaXRvcmluZyBtZXNzYWdlcy4NCg0KICAgQkZEIE5lZ290aWF0 aW9uIChOKTogSWYgc2V0IHRpbWVyIG5lZ290aWF0aW9uL3JlLW5lZ290aWF0aW9uIHZpYSBCRkQN CiAgIENvbnRyb2wgTWVzc2FnZXMgaXMgZW5hYmxlZCwgd2hlbiBjbGVhcmVkIGl0IGlzIGRpc2Fi bGVkLg0KDQogICBTeW1tZXRyaWMgc2Vzc2lvbiAoUyk6IElmIHNldCB0aGUgQkZEIHNlc3Npb24g TVVTVCB1c2Ugc3ltbWV0cmljDQogICB0aW1pbmcgdmFsdWVzLg0KDQogICBJbnRlZ3JpdHkgKEkp OiBJZiBzZXQgQkZEIEF1dGhlbnRpY2F0aW9uIE1VU1QgYmUgZW5hYmxlZC4gIElmIHRoZSBCRkQN CiAgIENvbmZpZ3VyYXRpb24gc3ViLVRMViBkb2VzIG5vdCBpbmNsdWRlIGEgQkZEIEF1dGhlbnRp Y2F0aW9uIHN1Yi1UTFYNCiAgIHRoZSBhdXRoZW50aWNhdGlvbiBNVVNUIHVzZSBLZXllZCBTSEEx IHdpdGggYW4gZW1wdHkgcHJlLXNoYXJlZCBrZXkNCiAgIChhbGwgMHMpLiAgSWYgdGhlIGVncmVz cyBMU1IgZG9lcyBub3Qgc3VwcG9ydCBCRkQgQXV0aGVudGljYXRpb24gYW4NCiAgIGVycm9yIE1V U1QgYmUgZ2VuZXJhdGVkOiAiT0FNIFByb2JsZW0vQkZEIEF1dGhlbnRpY2F0aW9uDQogICB1bnN1 cHBvcnRlZCIuDQoNCiAgIEVuY2Fwc3VsYXRpb24gQ2FwYWJpbGl0eSAoRyk6IGlmIHNldCwgaXQg c2hvd3MgdGhlIGNhcGFiaWxpdHkgb2YNCiAgIGVuY2Fwc3VsYXRpbmcgQkZEIG1lc3NhZ2VzIGlu dG8gRy1BQ2ggY2hhbm5lbC4gIElmIGJvdGggdGhlIEcgYml0IGFuZA0KICAgVSBiaXQgYXJlIHNl dCwgY29uZmlndXJhdGlvbiBnaXZlcyBwcmVjZWRlbmNlIHRvIHRoZSBHIGJpdC4NCg0KICAgRW5j YXBzdWxhdGlvbiBDYXBhYmlsaXR5IChVKTogaWYgc2V0LCBpdCBzaG93cyB0aGUgY2FwYWJpbGl0 eSBvZg0KICAgZW5jYXBzdWxhdGluZyBCRkQgbWVzc2FnZXMgaW50byBJUC9VRFAgcGFja2V0cy4g IElmIGJvdGggdGhlIEcgYml0DQogICBhbmQgVSBiaXQgYXJlIHNldCwgY29uZmlndXJhdGlvbiBn aXZlcyBwcmVjZWRlbmNlIHRvIHRoZSBHIGJpdC4NCg0KICAgSWYgdGhlIGVncmVzcyBMU1IgZG9l cyBub3Qgc3VwcG9ydCBhbnkgb2YgdGhlIGluZ3Jlc3MgTFNSDQogICBFbmNhcHN1bGF0aW9uIENh cGFiaWxpdGllcyBhbiBlcnJvciBNVVNUIGJlIGdlbmVyYXRlZDogIk9BTSBQcm9ibGVtLw0KICAg VW5zdXBwb3J0ZWQgQkZEIEVuY2Fwc3VsYXRpb24gZm9ybWF0Ii4NCg0KICAgQmlkaXJlY3Rpb25h bCAoQik6IGlmIHNldCwgaXQgY29uZmlndXJlcyBCRkQgaW4gdGhlIEJpZGlyZWN0aW9uYWwNCiAg IG1vZGUuICBJZiBpdCBpcyBub3Qgc2V0IGl0IGNvbmZpZ3VyZXMgQkZEIGluIHVuaWRpcmVjdGlv bmFsIG1vZGUuICBJbg0KICAgdGhlIHNlY29uZCBjYXNlLCB0aGUgc291cmNlIG5vZGUgZG9lcyBu b3QgZXhwZWN0IGFueSBEaXNjcmltaW5hdG9yDQogICB2YWx1ZXMgYmFjayBmcm9tIHRoZSBkZXN0 aW5hdGlvbiBub2RlLg0KDQogICBSZXNlcnZlZDogUmVzZXJ2ZWQgZm9yIGZ1dHVyZSBzcGVjaWZp Y2F0aW9uIGFuZCBzZXQgdG8gMCBvbg0KICAgdHJhbnNtaXNzaW9uIGFuZCBpZ25vcmVkIHdoZW4g cmVjZWl2ZWQuDQoNCiAgIFRoZSBCRkQgQ29uZmlndXJhdGlvbiBzdWItVExWIE1VU1QgaW5jbHVk ZSB0aGUgZm9sbG93aW5nIHN1Yi1UTFZzIGluDQogICB0aGUgTVBMUyBFY2hvIFJlcXVlc3QgbWVz c2FnZToNCg0KICAgICAgLSBMb2NhbCBEaXNjcmltaW5hdG9yIHN1Yi1UTFYsIGlmIEIgZmxhZyBp cyBzZXQgaW4gdGhlIE1QTFMgRWNobw0KICAgICAgUmVxdWVzdDsNCg0KICAgICAgLSBOZWdvdGlh dGlvbiBUaW1lciBQYXJhbWV0ZXJzIHN1Yi1UTFYgaWYgdGhlIE4gZmxhZyBpcyBjbGVhcmVkLg0K DQoNCg0KDQpCZWxsYWdhbWJhLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSnVuZSA3LCAyMDE1ICAg ICAgICAgICAgICAgICAgW1BhZ2UgOV0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICBFeHRlbnNp b25zIGZvciBNUExTLVRQIE9BTSBDb25mICAgICAgIERlY2VtYmVyIDIwMTQNCg0KDQogICBUaGUg QkZEIENvbmZpZ3VyYXRpb24gc3ViLVRMViBNVVNUIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBzdWIt VExWcyBpbg0KICAgdGhlIE1QTFMgRWNobyBSZXBseSBtZXNzYWdlOg0KDQogICAgICAtIExvY2Fs IERpc2NyaW1pbmF0b3Igc3ViLVRMVjsNCg0KICAgICAgLSBOZWdvdGlhdGlvbiBUaW1lciBQYXJh bWV0ZXJzIHN1Yi1UTFYgaWY6DQoNCiAgICAgICAgIC0gdGhlIE4gYW5kIFMgZmxhZ3MgYXJlIGNs ZWFyZWQsIG9yIGlmOg0KDQogICAgICAgICAtIHRoZSBOIGZsYWcgaXMgY2xlYXJlZCBhbmQgdGhl IFMgZmxhZyBpcyBzZXQsIGFuZCB0aGUNCiAgICAgICAgIE5lZ290aWF0aW9uIFRpbWVyIFBhcmFt ZXRlcnMgc3ViLVRMViByZWNlaXZlZCBieSB0aGUgZWdyZXNzDQogICAgICAgICBjb250YWlucyB1 bnN1cHBvcnRlZCB2YWx1ZXMuICBJbiB0aGlzIGNhc2UgYW4gdXBkYXRlZA0KICAgICAgICAgTmVn b3RpYXRpb24gVGltZXIgUGFyYW1ldGVycyBzdWItVExWLCBjb250YWluaW5nIHZhbHVlcw0KICAg ICAgICAgc3VwcG9ydGVkIGJ5IHRoZSBlZ3Jlc3Mgbm9kZSwgaXMgcmV0dXJuZWQgdG8gdGhlIGlu Z3Jlc3MuDQoNCjIuMi4yLiAgTG9jYWwgRGlzY3JpbWluYXRvciBzdWItVExWDQoNCiAgIFRoZSBM b2NhbCBEaXNjcmltaW5hdG9yIHN1Yi1UTFYgaXMgY2FycmllZCBhcyBhIHN1Yi1UTFYgb2YgdGhl ICJCRkQNCiAgIENvbmZpZ3VyYXRpb24gc3ViLVRMViIgYW5kIGlzIGRlcGljdGVkIGluIEZpZ3Vy ZSAzLg0KDQogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgIExjbC4gRGlz Y3IuIHN1Yi1UeXBlICgxMDEpICAgfCAgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgICB8DQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgTG9jYWwgRGlzY3JpbWluYXRv ciAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgICAgICAgICAgIEZp Z3VyZSAzOiBMb2NhbCBEaXNjcmltaW5hdG9yIHN1Yi1UTFYgZm9ybWF0DQoNCiAgIFR5cGU6IGlu ZGljYXRlcyBhIG5ldyB0eXBlLCB0aGUgIkxvY2FsIERpc2NyaW1pbmF0b3Igc3ViLVRMViIgKElB TkENCiAgIHRvIGRlZmluZSwgc3VnZ2VzdGVkIHZhbHVlIDEwMSkuDQoNCiAgIExlbmd0aDogaW5k aWNhdGVzIHRoZSBsZW5ndGggb2YgdGhlIFZhbHVlIGZpZWxkIGluIG9jdGV0cyAuICg0KQ0KDQog ICBMb2NhbCBEaXNjcmltaW5hdG9yOiBBIHVuaXF1ZSwgbm9uemVybyBkaXNjcmltaW5hdG9yIHZh bHVlIGdlbmVyYXRlZA0KICAgYnkgdGhlIHRyYW5zbWl0dGluZyBzeXN0ZW0gYW5kIHJlZmVycmlu ZyB0byBpdHNlbGYsIHVzZWQgdG8NCiAgIGRlbXVsdGlwbGV4IG11bHRpcGxlIEJGRCBzZXNzaW9u cyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2Ygc3lzdGVtcy4NCg0KMi4yLjMuICBOZWdvdGlhdGlv biBUaW1lciBQYXJhbWV0ZXJzIHN1Yi1UTFYNCg0KICAgVGhlIE5lZ290aWF0aW9uIFRpbWVyIFBh cmFtZXRlcnMgc3ViLVRMViBpcyBjYXJyaWVkIGFzIGEgc3ViLVRMViBvZg0KICAgdGhlIEJGRCBD b25maWd1cmF0aW9uIHN1Yi1UTFYgYW5kIGlzIGRlcGljdGVkIGluIEZpZ3VyZSA0Lg0KDQoNCg0K DQoNCg0KDQoNCkJlbGxhZ2FtYmEsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKdW5lIDcsIDIwMTUg ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgIEV4dGVu c2lvbnMgZm9yIE1QTFMtVFAgT0FNIENvbmYgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgICAw ICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAg ICAzDQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCBOZWdvLiBUaW1lciBzdWItdHlwZSAo MTAyKSAgICB8ICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICB8ICAgICAgICAgQWNjZXB0YWJsZSBNaW4uIEFzeW5jaHJvbm91cyBUWCBpbnRlcnZhbCAgICAg ICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICBBY2NlcHRhYmxlIE1pbi4gQXN5 bmNocm9ub3VzIFJYIGludGVydmFsICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAg ICAgICAgICAgICAgIFJlcXVpcmVkIEVjaG8gVFggSW50ZXJ2YWwgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgICAgICAgRmlndXJlIDQ6IE5lZ290aWF0aW9uIFRp bWVyIFBhcmFtZXRlcnMgc3ViLVRMViBmb3JtYXQNCg0KICAgU3ViLXR5cGU6IGluZGljYXRlcyBh IG5ldyBzdWItdHlwZSwgdGhlIE5lZ290aWF0aW9uIFRpbWVyIFBhcmFtZXRlcnMNCiAgIHN1Yi1U TFYgKElBTkEgdG8gZGVmaW5lLCBzdWdnZXN0ZWQgdmFsdWUgMTAyKS4NCg0KICAgTGVuZ3RoOiBp bmRpY2F0ZXMgdGhlIGxlbmd0aCBvZiB0aGUgVmFsdWUgZmllbGQgaW4gb2N0ZXRzICgxMikuDQoN CiAgIEFjY2VwdGFibGUgTWluLiBBc3luY2hyb25vdXMgVFggaW50ZXJ2YWw6IGluIGNhc2Ugb2Yg UyAoc3ltbWV0cmljKQ0KICAgZmxhZyBzZXQgaW4gdGhlIEJGRCBDb25maWd1cmF0aW9uIHN1Yi1U TFYsIGRlZmluZWQgaW4gU2VjdGlvbiAyLjIuMSwNCiAgIGl0IGV4cHJlc3NlcyB0aGUgZGVzaXJl ZCB0aW1lIGludGVydmFsIChpbiBtaWNyb3NlY29uZHMpIGF0IHdoaWNoIHRoZQ0KICAgaW5ncmVz cyBMRVIgaW50ZW5kcyB0byBib3RoIHRyYW5zbWl0IGFuZCByZWNlaXZlIEJGRCBwZXJpb2RpYyBj b250cm9sDQogICBwYWNrZXRzLiAgSWYgdGhlIHJlY2VpdmluZyBlZGdlIExTUiBjYW4gbm90IHN1 cHBvcnQgc3VjaCB2YWx1ZSwgaXQNCiAgIFNIT1VMRCByZXBseSB3aXRoIGFuIGludGVydmFsIGdy ZWF0ZXIgdGhhbiB0aGUgb25lIHByb3Bvc2VkLg0KDQogICBJbiBjYXNlIG9mIFMgKHN5bW1ldHJp YykgZmxhZyBjbGVhcmVkIGluIHRoZSBCRkQgQ29uZmlndXJhdGlvbiBzdWItDQogICBUTFYsIHRo aXMgZmllbGQgZXhwcmVzc2VzIHRoZSBkZXNpcmVkIHRpbWUgaW50ZXJ2YWwgKGluIG1pY3Jvc2Vj b25kcykNCiAgIGF0IHdoaWNoIGEgZWRnZSBMU1IgaW50ZW5kcyB0byB0cmFuc21pdCBCRkQgcGVy aW9kaWMgY29udHJvbCBwYWNrZXRzDQogICBpbiBpdHMgdHJhbnNtaXR0aW5nIGRpcmVjdGlvbi4N Cg0KICAgQWNjZXB0YWJsZSBNaW4uIEFzeW5jaHJvbm91cyBSWCBpbnRlcnZhbDogaW4gY2FzZSBv ZiBTIChzeW1tZXRyaWMpDQogICBmbGFnIHNldCBpbiB0aGUgQkZEIENvbmZpZ3VyYXRpb24gc3Vi LVRMViwgRmlndXJlIDIsIHRoaXMgZmllbGQgTVVTVA0KICAgYmUgZXF1YWwgdG8gQWNjZXB0YWJs ZSBNaW4uIEFzeW5jaHJvbm91cyBUWCBpbnRlcnZhbCBhbmQgaGFzIG5vDQogICBhZGRpdGlvbmFs IG1lYW5pbmcgcmVzcGVjdCB0byB0aGUgb25lIGRlc2NyaWJlZCBmb3IgIkFjY2VwdGFibGUgTWlu Lg0KICAgQXN5bmNocm9ub3VzIFRYIGludGVydmFsIi4NCg0KICAgSW4gY2FzZSBvZiBTIChzeW1t ZXRyaWMpIGZsYWcgY2xlYXJlZCBpbiB0aGUgQkZEIENvbmZpZ3VyYXRpb24gc3ViLQ0KICAgVExW LCBpdCBleHByZXNzZXMgdGhlIG1pbmltdW0gdGltZSBpbnRlcnZhbCAoaW4gbWljcm9zZWNvbmRz KSBhdA0KICAgd2hpY2ggZWRnZSBMU1JzIGNhbiByZWNlaXZlIEJGRCBwZXJpb2RpYyBjb250cm9s IHBhY2tldHMuICBJbiBjYXNlDQogICB0aGlzIHZhbHVlIGlzIGdyZWF0ZXIgdGhhbiB0aGUgdmFs dWUgb2YgQWNjZXB0YWJsZSBNaW4uIEFzeW5jaHJvbm91cw0KICAgVFggaW50ZXJ2YWwgcmVjZWl2 ZWQgZnJvbSB0aGUgb3RoZXIgZWRnZSBMU1IsIHN1Y2ggZWRnZSBMU1IgTVVTVA0KICAgYWRvcHQg dGhlIGludGVydmFsIGV4cHJlc3NlZCBpbiB0aGlzIEFjY2VwdGFibGUgTWluLiBBc3luY2hyb25v dXMgUlgNCiAgIGludGVydmFsLg0KDQogICBSZXF1aXJlZCBFY2hvIFRYIEludGVydmFsOiB0aGUg bWluaW11bSBpbnRlcnZhbCAoaW4gbWljcm9zZWNvbmRzKQ0KICAgYmV0d2VlbiByZWNlaXZlZCBC RkQgRWNobyBwYWNrZXRzIHRoYXQgdGhpcyBzeXN0ZW0gaXMgY2FwYWJsZSBvZg0KICAgc3VwcG9y dGluZywgbGVzcyBhbnkgaml0dGVyIGFwcGxpZWQgYnkgdGhlIHNlbmRlciBhcyBkZXNjcmliZWQg aW4NCg0KDQoNCkJlbGxhZ2FtYmEsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKdW5lIDcsIDIwMTUg ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgIEV4dGVu c2lvbnMgZm9yIE1QTFMtVFAgT0FNIENvbmYgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIFtS RkM1ODgwXSBzZWN0LiA2LjguOS4gIFRoaXMgdmFsdWUgaXMgYWxzbyBhbiBpbmRpY2F0aW9uIGZv ciB0aGUNCiAgIHJlY2VpdmluZyBzeXN0ZW0gb2YgdGhlIG1pbmltdW0gaW50ZXJ2YWwgYmV0d2Vl biB0cmFuc21pdHRlZCBCRkQgRWNobw0KICAgcGFja2V0cy4gIElmIHRoaXMgdmFsdWUgaXMgemVy bywgdGhlIHRyYW5zbWl0dGluZyBzeXN0ZW0gZG9lcyBub3QNCiAgIHN1cHBvcnQgdGhlIHJlY2Vp cHQgb2YgQkZEIEVjaG8gcGFja2V0cy4gIElmIHRoZSByZWNlaXZpbmcgc3lzdGVtIGNhbg0KICAg bm90IHN1cHBvcnQgdGhpcyB2YWx1ZSB0aGUgIlVuc3VwcG9ydGVkIEJGRCBUWCBFY2hvIHJhdGUg aW50ZXJ2YWwiDQogICBlcnJvciBNVVNUIGJlIGdlbmVyYXRlZC4gIEJ5IGRlZmF1bHQgdGhlIHZh bHVlIGlzIHNldCB0byAwLg0KDQoyLjIuNC4gIEJGRCBBdXRoZW50aWNhdGlvbiBzdWItVExWDQoN CiAgIFRoZSAiQkZEIEF1dGhlbnRpY2F0aW9uIHN1Yi1UTFYiIGlzIGNhcnJpZWQgYXMgYSBzdWIt VExWIG9mIHRoZSAiQkZEDQogICBDb25maWd1cmF0aW9uIHN1Yi1UTFYiIGFuZCBpcyBkZXBpY3Rl ZCBpbiBGaWd1cmUgNS4NCg0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg ICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8 ICAgIEJGRCBBdXRoLiBzdWItdHlwZSAoMTAzKSAgIHwgICAgICAgICAgICAgTGVuZ3RoICAgICAg ICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICBBdXRoIFR5cGUgICB8ICBBdXRoIEtleSBJRCAg fCAgICAgICAgIFJlc2VydmVkICgwcykgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICAg ICAgICAgICAgRmlndXJlIDU6IEJGRCBBdXRoZW50aWNhdGlvbiBzdWItVExWIGZvcm1hdA0KDQog ICBTdWItdHlwZTogaW5kaWNhdGVzIGEgbmV3IHR5cGUsIHRoZSBCRkQgQXV0aGVudGljYXRpb24g c3ViLVRMViAoSUFOQQ0KICAgdG8gZGVmaW5lLCBzdWdnZXN0ZWQgdmFsdWUgMTAzKS4NCg0KICAg TGVuZ3RoOiBpbmRpY2F0ZXMgdGhlIGxlbmd0aCBvZiB0aGUgVmFsdWUgZmllbGQgaW4gb2N0ZXRz ICg0KS4NCg0KICAgQXV0aCBUeXBlOiBpbmRpY2F0ZXMgd2hpY2ggdHlwZSBvZiBhdXRoZW50aWNh dGlvbiB0byB1c2UuICBUaGUgc2FtZQ0KICAgdmFsdWVzIGFzIGFyZSBkZWZpbmVkIGluIHNlY3Rp b24gNC4xIG9mIFtSRkM1ODgwXSBhcmUgdXNlZC4NCg0KICAgQXV0aCBLZXkgSUQ6IGluZGljYXRl cyB3aGljaCBhdXRoZW50aWNhdGlvbiBrZXkgb3IgcGFzc3dvcmQNCiAgIChkZXBlbmRpbmcgb24g QXV0aCBUeXBlKSBzaG91bGQgYmUgdXNlZC4gIEhvdyB0aGUga2V5IGV4Y2hhbmdlIGlzDQogICBw ZXJmb3JtZWQgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBJZiB0aGUgZWdyZXNz IExTUiBkb2VzDQogICBub3Qgc3VwcG9ydCB0aGlzIEF1dGggS2V5IElEIGFuICJPQU0gUHJvYmxl bS9NaXNtYXRjaCBvZiBCRkQNCiAgIEF1dGhlbnRpY2F0aW9uIEtleSBJRCIgZXJyb3IgTVVTVCBi ZSBnZW5lcmF0ZWQuDQoNCiAgIFJlc2VydmVkOiBSZXNlcnZlZCBmb3IgZnV0dXJlIHNwZWNpZmlj YXRpb24gYW5kIHNldCB0byAwIG9uDQogICB0cmFuc21pc3Npb24gYW5kIGlnbm9yZWQgd2hlbiBy ZWNlaXZlZC4NCg0KMi4yLjUuICBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBzdWItVExWDQoNCiAg IElmIHRoZSBNUExTIE9BTSBGdW5jdGlvbnMgVExWIGhhcyBlaXRoZXIgdGhlIEwgKExvc3MpLCBE IChEZWxheSkgb3IgVA0KICAgKFRocm91Z2hwdXQpIGZsYWcgc2V0LCB0aGUgUGVyZm9ybWFuY2Ug TWVhc3VyZW1lbnQgc3ViLVRMViBNVVNUIGJlDQogICBwcmVzZW50LiAgRmFpbHVyZSB0byBpbmNs dWRlIHRoZSBjb3JyZWN0IHN1Yi1UTFZzIE1VU1QgcmVzdWx0IGluIGFuDQogICAiT0FNIFByb2Js ZW0vIENvbmZpZ3VyYXRpb24gRXJyb3IiIGVycm9yIGJlaW5nIGdlbmVyYXRlZC4NCg0KICAgVGhl IFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IHN1Yi1UTFYgcHJvdmlkZXMgdGhlIGNvbmZpZ3VyYXRp b24NCiAgIGluZm9ybWF0aW9uIG1lbnRpb25lZCBpbiBTZWN0aW9uIDcgb2YgW1JGQzYzNzRdLiAg SXQgaW5jbHVkZXMgc3VwcG9ydA0KDQoNCg0KQmVsbGFnYW1iYSwgZXQgYWwuICAgICAgICBFeHBp cmVzIEp1bmUgNywgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoNCg0KSW50ZXJuZXQt RHJhZnQgICAgICAgRXh0ZW5zaW9ucyBmb3IgTVBMUy1UUCBPQU0gQ29uZiAgICAgICBEZWNlbWJl ciAyMDE0DQoNCg0KICAgZm9yIHRoZSBjb25maWd1cmF0aW9uIG9mIHF1YWxpdHkgdGhyZXNob2xk cyBhbmQsIGFzIGRlc2NyaWJlZCBpbg0KICAgW1JGQzYzNzRdLCAidGhlIGNyb3NzaW5nIG9mIHdo aWNoIHdpbGwgdHJpZ2dlciB3YXJuaW5ncyBvciBhbGFybXMsDQogICBhbmQgcmVzdWx0IHJlcG9y dGluZyBhbmQgZXhjZXB0aW9uIG5vdGlmaWNhdGlvbiB3aWxsIGJlIGludGVncmF0ZWQNCiAgIGlu dG8gdGhlIHN5c3RlbS13aWRlIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQgcmVwb3J0aW5nIGZyYW1l d29yay4iDQoNCiAgIEluIGNhc2UgdGhlIHZhbHVlcyBuZWVkIHRvIGJlIGRpZmZlcmVudCB0aGFu IHRoZSBkZWZhdWx0IG9uZXMgdGhlDQogICBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBzdWItVExW IE1BWSBpbmNsdWRlIHRoZSBmb2xsb3dpbmcgc3ViLVRMVnM6DQoNCiAgICAgIC0gUE0gTG9zcyBz dWItVExWIGlmIHRoZSBMIGZsYWcgaXMgc2V0IGluIHRoZSBNUExTIE9BTSBGdW5jdGlvbnMNCiAg ICAgIFRMVjsNCg0KICAgICAgLSBQTSBEZWxheSBzdWItVExWIGlmIHRoZSBEIGZsYWcgaXMgc2V0 IGluIHRoZSBNUExTIE9BTSBGdW5jdGlvbnMNCiAgICAgIFRMVi4NCg0KICAgVGhlIFBlcmZvcm1h bmNlIE1lYXN1cmVtZW50IHN1Yi1UTFYgZGVwaWN0ZWQgaW4gRmlndXJlIDYgaXMgY2FycmllZA0K ICAgYXMgYSBzdWItVExWIG9mIHRoZSBNUExTIE9BTSBGdW5jdGlvbnMgVExWLg0KDQogICAgMCAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAg Mw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgUGVyZiBNb25pdG9yaW5nIFR5cGUgKDIw MCkgICAgfCAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg fER8THxKfFl8S3xDfCAgICAgICAgICAgIFJlc2VydmVkIChzZXQgdG8gYWxsIDBzKSAgICAgICAg ICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgICAgICAgICBGaWd1cmUgNjogUGVyZm9ybWFu Y2UgTWVhc3VyZW1lbnQgc3ViLVRMViBmb3JtYXQNCg0KICAgU3ViLXR5cGU6IGluZGljYXRlcyBh IG5ldyBzdWItdHlwZSwgdGhlIFBlcmZvcm1hbmNlIE1hbmFnZW1lbnQgc3ViLQ0KICAgVExWIiAo SUFOQSB0byBkZWZpbmUsIHN1Z2dlc3RlZCB2YWx1ZSAyMDApLg0KDQogICBMZW5ndGg6IGluZGlj YXRlcyB0aGUgbGVuZ3RoIG9mIHRoZSBWYWx1ZSBmaWVsZCBpbiBvY3RldHMgKDQpLg0KDQogICBD b25maWd1cmF0aW9uIEZsYWdzLCBmb3IgdGhlIHNwZWNpZmljIGZ1bmN0aW9uIGRlc2NyaXB0aW9u IHBsZWFzZQ0KICAgcmVmZXIgdG8gW1JGQzYzNzRdOg0KDQogICAgICAtIEQ6IERlbGF5IGluZmVy cmVkL2RpcmVjdCAoMD1JTkZFUlJFRCwgMT1ESVJFQ1QpLiAgSWYgdGhlIGVncmVzcw0KICAgICAg TFNSIGRvZXMgbm90IHN1cHBvcnQgc3BlY2lmaWVkIG1vZGUgYW4gIk9BTSBQcm9ibGVtL1Vuc3Vw cG9ydGVkDQogICAgICBEZWxheSBNb2RlIiBlcnJvciBNVVNUIGJlIGdlbmVyYXRlZC4NCg0KICAg ICAgLSBMOiBMb3NzIGluZmVycmVkL2RpcmVjdCAoMD1JTkZFUlJFRCwgMT1ESVJFQ1QpLiAgSWYg dGhlIGVncmVzcw0KICAgICAgTFNSIGRvZXMgbm90IHN1cHBvcnQgc3BlY2lmaWVkIG1vZGUgYW4g Ik9BTSBQcm9ibGVtL1Vuc3VwcG9ydGVkDQogICAgICBMb3NzIE1vZGUiIGVycm9yIE1VU1QgYmUg Z2VuZXJhdGVkLg0KDQogICAgICAtIEo6IERlbGF5IHZhcmlhdGlvbi9qaXR0ZXIgKDE9QUNUSVZF LCAwPU5PVCBBQ1RJVkUpLiAgSWYgdGhlDQogICAgICBlZ3Jlc3MgTFNSIGRvZXMgbm90IHN1cHBv cnQgRGVsYXkgdmFyaWF0aW9uIG1lYXN1cmVtZW50cyBhbmQgdGhlIEoNCiAgICAgIGZsYWcgaXMg c2V0LCBhbiAiT0FNIFByb2JsZW0vRGVsYXkgdmFyaWF0aW9uIHVuc3VwcG9ydGVkIiBlcnJvcg0K ICAgICAgTVVTVCBiZSBnZW5lcmF0ZWQuDQoNCg0KDQoNCkJlbGxhZ2FtYmEsIGV0IGFsLiAgICAg ICAgRXhwaXJlcyBKdW5lIDcsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDQoNCklu dGVybmV0LURyYWZ0ICAgICAgIEV4dGVuc2lvbnMgZm9yIE1QTFMtVFAgT0FNIENvbmYgICAgICAg RGVjZW1iZXIgMjAxNA0KDQoNCiAgICAgIC0gWTogRHlhZGljICgxPUFDVElWRSwgMD1OT1QgQUNU SVZFKS4gIElmIHRoZSBlZ3Jlc3MgTFNSIGRvZXMgbm90DQogICAgICBzdXBwb3J0IER5YWRpYyBt b2RlIGFuZCB0aGUgWSBmbGFnIGlzIHNldCwgYW4gIk9BTSBQcm9ibGVtL0R5YWRpYw0KICAgICAg bW9kZSB1bnN1cHBvcnRlZCIgZXJyb3IgTVVTVCBiZSBnZW5lcmF0ZWQuDQoNCiAgICAgIC0gSzog TG9vcGJhY2sgKDE9QUNUSVZFLCAwPU5PVCBBQ1RJVkUpLiAgSWYgdGhlIGVncmVzcyBMU1IgZG9l cw0KICAgICAgbm90IHN1cHBvcnQgTG9vcGJhY2sgbW9kZSBhbmQgdGhlIEsgZmxhZyBpcyBzZXQs IGFuICJPQU0gUHJvYmxlbS8NCiAgICAgIExvb3BiYWNrIG1vZGUgdW5zdXBwb3J0ZWQiIGVycm9y IE1VU1QgYmUgZ2VuZXJhdGVkLg0KDQogICAgICAtIEM6IENvbWJpbmVkICgxPUFDVElWRSwgMD1O T1QgQUNUSVZFKS4gIElmIHRoZSBlZ3Jlc3MgTFNSIGRvZXMNCiAgICAgIG5vdCBzdXBwb3J0IENv bWJpbmVkIG1vZGUgYW5kIHRoZSBDIGZsYWcgaXMgc2V0LCBhbiAiT0FNIFByb2JsZW0vDQogICAg ICBDb21iaW5lZCBtb2RlIHVuc3VwcG9ydGVkIiBlcnJvciBNVVNUIGJlIGdlbmVyYXRlZC4NCg0K ICAgUmVzZXJ2ZWQ6IFJlc2VydmVkIGZvciBmdXR1cmUgc3BlY2lmaWNhdGlvbiBhbmQgc2V0IHRv IDAgb24NCiAgIHRyYW5zbWlzc2lvbiBhbmQgaWdub3JlZCB3aGVuIHJlY2VpdmVkLg0KDQoyLjIu Ni4gIFBNIExvc3MgTWVhc3VyZW1lbnQgc3ViLVRMVg0KDQogICBUaGUgUE0gTG9zcyBNZWFzdXJl bWVudCBzdWItVExWIGRlcGljdGVkIGluIEZpZ3VyZSA3IGlzIGNhcnJpZWQgYXMgYQ0KICAgc3Vi LVRMViBvZiB0aGUgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgc3ViLVRMVi4NCg0KICAgIDAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMN CiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICBQTSBMb3NzIHN1Yi10eXBlICgyMDEpICAg ICAgIHwgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwg T1RGIHxUfEJ8ICAgICAgICAgICAgICBSZXNlcnZlZCAoc2V0IHRvIGFsbCAwcykgICAgICAgICAg ICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgTWVhc3VyZW1lbnQg SW50ZXJ2YWwgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAg ICAgICAgICAgICAgICAgICBUZXN0IEludGVydmFsICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgTG9zcyBUaHJlc2hvbGQg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICAgICAgICAg ICBGaWd1cmUgNzogUE0gTG9zcyBNZWFzdXJlbWVudCBzdWItVExWIGZvcm1hdA0KDQogICBTdWIt dHlwZTogaW5kaWNhdGVzIGEgbmV3IHN1Yi10eXBlLCB0aGUgUE0gTG9zcyBNZWFzdXJlbWVudCBz dWItVExWDQogICAoSUFOQSB0byBkZWZpbmUsIHN1Z2dlc3RlZCB2YWx1ZSAyMDEpLg0KDQogICBM ZW5ndGg6IGluZGljYXRlcyB0aGUgbGVuZ3RoIG9mIHRoZSBWYWx1ZSBmaWVsZCBpbiBvY3RldHMg KDE2KS4NCg0KICAgT1RGOiBPcmlnaW4gVGltZXN0YW1wIEZvcm1hdCBvZiB0aGUgT3JpZ2luIFRp bWVzdGFtcCBmaWVsZCBkZXNjcmliZWQNCiAgIGluIFtSRkM2Mzc0XS4gIEJ5IGRlZmF1bHQgaXQg aXMgc2V0IHRvIElFRUUgMTU4OCB2ZXJzaW9uIDEuICBJZiB0aGUNCiAgIGVncmVzcyBMU1IgY2Fu bm90IHN1cHBvcnQgdGhpcyB2YWx1ZSBhbiAiT0FNIFByb2JsZW0vVW5zdXBwb3J0ZWQNCiAgIFRp bWVzdGFtcCBGb3JtYXQiIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVkLg0KDQogICBDb25maWd1cmF0 aW9uIEZsYWdzLCBwbGVhc2UgcmVmZXIgdG8gW1JGQzYzNzRdIGZvciBmdXJ0aGVyIGRldGFpbHM6 DQoNCg0KDQoNCkJlbGxhZ2FtYmEsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKdW5lIDcsIDIwMTUg ICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgIEV4dGVu c2lvbnMgZm9yIE1QTFMtVFAgT0FNIENvbmYgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgICAg IC0gVDogVHJhZmZpYy1jbGFzcy1zcGVjaWZpYyBtZWFzdXJlbWVudCBpbmRpY2F0b3IuICBTZXQg dG8gMSB3aGVuDQogICAgICB0aGUgbWVhc3VyZW1lbnQgb3BlcmF0aW9uIGlzIHNjb3BlZCB0byBw YWNrZXRzIG9mIGEgcGFydGljdWxhcg0KICAgICAgdHJhZmZpYyBjbGFzcyAoRFNDUCB2YWx1ZSks IGFuZCAwIG90aGVyd2lzZS4gIFdoZW4gc2V0IHRvIDEsIHRoZQ0KICAgICAgRFMgZmllbGQgb2Yg dGhlIG1lc3NhZ2UgaW5kaWNhdGVzIHRoZSBtZWFzdXJlZCB0cmFmZmljIGNsYXNzLiAgQnkNCiAg ICAgIGRlZmF1bHQgaXQgaXMgc2V0IHRvIDEuDQoNCiAgICAgIC0gQjogT2N0ZXQgKGJ5dGUpIGNv dW50LiAgV2hlbiBzZXQgdG8gMSwgaW5kaWNhdGVzIHRoYXQgdGhlDQogICAgICBDb3VudGVyIDEt NCBmaWVsZHMgcmVwcmVzZW50IG9jdGV0IGNvdW50cy4gIFdoZW4gc2V0IHRvIDAsDQogICAgICBp bmRpY2F0ZXMgdGhhdCB0aGUgQ291bnRlciAxLTQgZmllbGRzIHJlcHJlc2VudCBwYWNrZXQgY291 bnRzLiAgQnkNCiAgICAgIGRlZmF1bHQgaXQgaXMgc2V0IHRvIDAuDQoNCiAgIFJlc2VydmVkOiBS ZXNlcnZlZCBmb3IgZnV0dXJlIHNwZWNpZmljYXRpb24gYW5kIHNldCB0byAwIG9uDQogICB0cmFu c21pc3Npb24gYW5kIGlnbm9yZWQgd2hlbiByZWNlaXZlZC4NCg0KICAgTWVhc3VyZW1lbnQgSW50 ZXJ2YWw6IHRoZSB0aW1lIGludGVydmFsIChpbiBtaWxsaXNlY29uZHMpIGF0IHdoaWNoDQogICBM b3NzIE1lYXN1cmVtZW50IHF1ZXJ5IG1lc3NhZ2VzIE1VU1QgYmUgc2VudCBvbiBib3RoIGRpcmVj dGlvbnMuICBJZg0KICAgdGhlIGVkZ2UgTFNSIHJlY2VpdmluZyB0aGUgUGF0aCBtZXNzYWdlIGNh biBub3Qgc3VwcG9ydCBzdWNoIHZhbHVlLA0KICAgaXQgU0hPVUxEIHJlcGx5IHdpdGggYSBoaWdo ZXIgaW50ZXJ2YWwuICBCeSBkZWZhdWx0IGl0IGlzIHNldCB0bw0KICAgKDEwMCkgYXMgcGVyIFtS RkM2Mzc1XS4NCg0KICAgVGVzdCBJbnRlcnZhbDogdGVzdCBtZXNzYWdlcyBpbnRlcnZhbCBpbiBt aWxsaXNlY29uZHMgYXMgZGVzY3JpYmVkIGluDQogICBbUkZDNjM3NF0uICBCeSBkZWZhdWx0IGl0 IGlzIHNldCB0byAoMTApIGFzIHBlciBbUkZDNjM3NV0uDQoNCiAgIExvc3MgVGhyZXNob2xkOiB0 aGUgdGhyZXNob2xkIHZhbHVlIG9mIG1lYXN1cmVkIGxvc3QgcGFja2V0cyBwZXINCiAgIG1lYXN1 cmVtZW50IG92ZXIgd2hpY2ggYWN0aW9uKHMpIFNIT1VMRCBiZSB0cmlnZ2VyZWQuDQoNCjIuMi43 LiAgUE0gRGVsYXkgTWVhc3VyZW1lbnQgc3ViLVRMVg0KDQogICBUaGUgUE0gRGVsYXkgTWVhc3Vy ZW1lbnQgc3ViLVRMViIgZGVwaWN0ZWQgaW4gRmlndXJlIDggaXMgY2FycmllZCBhcw0KICAgYSBz dWItVExWIG9mIHRoZSBQZXJmb3JtYW5jZSBNb25pdG9yaW5nIHN1Yi1UTFYuDQoNCiAgICAwICAg ICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAz DQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgUE0gRGVsYXkgVHlwZSAoMjAyKSAgICAg ICAgICB8ICAgICAgICAgIExlbmd0aCAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8 IE9URiB8VHxCfCAgICAgICAgICAgICBSZXNlcnZlZCAoc2V0IHRvIGFsbCAwcykgICAgICAgICAg ICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgIE1lYXN1cmVtZW50 IEludGVydmFsICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAg ICAgICAgICAgICAgICAgICAgVGVzdCBJbnRlcnZhbCAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgIERlbGF5IFRocmVzaG9s ZCAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICAgICAgICAg ICAgRmlndXJlIDg6IFBNIERlbGF5IE1lYXN1cmVtZW50IHN1Yi1UTFYgZm9ybWF0DQoNCg0KDQoN Cg0KQmVsbGFnYW1iYSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEp1bmUgNywgMjAxNSAgICAgICAg ICAgICAgICAgW1BhZ2UgMTVdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgRXh0ZW5zaW9ucyBm b3IgTVBMUy1UUCBPQU0gQ29uZiAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAgU3ViLXR5cGU6 IGluZGljYXRlcyBhIG5ldyBzdWItdHlwZSwgdGhlIFBNIERlbGF5IE1lYXN1cmVtZW50IHN1Yi1U TFYiDQogICAoSUFOQSB0byBkZWZpbmUsIHN1Z2dlc3RlZCB2YWx1ZSAyMDIpLg0KDQogICBMZW5n dGg6IGluZGljYXRlcyB0aGUgbGVuZ3RoIG9mIHRoZSBWYWx1ZSBmaWVsZCBpbiBvY3RldHMgKDE2 KS4NCg0KICAgT1RGOiBPcmlnaW4gVGltZXN0YW1wIEZvcm1hdCBvZiB0aGUgT3JpZ2luIFRpbWVz dGFtcCBmaWVsZCBkZXNjcmliZWQNCiAgIGluIFtSRkM2Mzc0XS4gIEJ5IGRlZmF1bHQgaXQgaXMg c2V0IHRvIElFRUUgMTU4OCB2ZXJzaW9uIDEuICBJZiB0aGUNCiAgIGVncmVzcyBMU1IgY2Fubm90 IHN1cHBvcnQgdGhpcyB2YWx1ZSBhbiAiT0FNIFByb2JsZW0vVW5zdXBwb3J0ZWQNCiAgIFRpbWVz dGFtcCBGb3JtYXQiIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVkLg0KDQogICBDb25maWd1cmF0aW9u IEZsYWdzLCBwbGVhc2UgcmVmZXIgdG8gW1JGQzYzNzRdIGZvciBmdXJ0aGVyIGRldGFpbHM6DQoN CiAgICAgIC0gVDogVHJhZmZpYy1jbGFzcy1zcGVjaWZpYyBtZWFzdXJlbWVudCBpbmRpY2F0b3Iu ICBTZXQgdG8gMSB3aGVuDQogICAgICB0aGUgbWVhc3VyZW1lbnQgb3BlcmF0aW9uIGlzIHNjb3Bl ZCB0byBwYWNrZXRzIG9mIGEgcGFydGljdWxhcg0KICAgICAgdHJhZmZpYyBjbGFzcyAoRFNDUCB2 YWx1ZSksIGFuZCAwIG90aGVyd2lzZS4gIFdoZW4gc2V0IHRvIDEsIHRoZQ0KICAgICAgRFMgZmll bGQgb2YgdGhlIG1lc3NhZ2UgaW5kaWNhdGVzIHRoZSBtZWFzdXJlZCB0cmFmZmljIGNsYXNzLiAg QnkNCiAgICAgIGRlZmF1bHQgaXQgaXMgc2V0IHRvIDEuDQoNCiAgICAgIC0gQjogT2N0ZXQgKGJ5 dGUpIGNvdW50LiAgV2hlbiBzZXQgdG8gMSwgaW5kaWNhdGVzIHRoYXQgdGhlDQogICAgICBDb3Vu dGVyIDEtNCBmaWVsZHMgcmVwcmVzZW50IG9jdGV0IGNvdW50cy4gIFdoZW4gc2V0IHRvIDAsDQog ICAgICBpbmRpY2F0ZXMgdGhhdCB0aGUgQ291bnRlciAxLTQgZmllbGRzIHJlcHJlc2VudCBwYWNr ZXQgY291bnRzLiAgQnkNCiAgICAgIGRlZmF1bHQgaXQgaXMgc2V0IHRvIDAuDQoNCiAgIFJlc2Vy dmVkOiBSZXNlcnZlZCBmb3IgZnV0dXJlIHNwZWNpZmljYXRpb24gYW5kIHNldCB0byAwIG9uDQog ICB0cmFuc21pc3Npb24gYW5kIGlnbm9yZWQgd2hlbiByZWNlaXZlZC4NCg0KICAgTWVhc3VyZW1l bnQgSW50ZXJ2YWw6IHRoZSB0aW1lIGludGVydmFsIChpbiBtaWxsaXNlY29uZHMpIGF0IHdoaWNo DQogICBEZWxheSBNZWFzdXJlbWVudCBxdWVyeSBtZXNzYWdlcyBNVVNUIGJlIHNlbnQgb24gYm90 aCBkaXJlY3Rpb25zLiAgSWYNCiAgIHRoZSBlZGdlIExTUiByZWNlaXZpbmcgdGhlIFBhdGggbWVz c2FnZSBjYW4gbm90IHN1cHBvcnQgc3VjaCB2YWx1ZSwNCiAgIGl0IGNhbiByZXBseSB3aXRoIGEg aGlnaGVyIGludGVydmFsLiAgQnkgZGVmYXVsdCBpdCBpcyBzZXQgdG8gKDEwMDApDQogICBhcyBw ZXIgW1JGQzYzNzVdLg0KDQogICBUZXN0IEludGVydmFsOiB0ZXN0IG1lc3NhZ2VzIGludGVydmFs IChpbiBtaWxsaXNlY29uZHMpIGFzIGRlc2NyaWJlZA0KICAgaW4gW1JGQzYzNzRdLiAgQnkgZGVm YXVsdCBpdCBpcyBzZXQgdG8gKDEwKSBhcyBwZXIgW1JGQzYzNzVdLg0KDQogICBEZWxheSBUaHJl c2hvbGQ6IHRoZSB0aHJlc2hvbGQgdmFsdWUgb2YgbWVhc3VyZWQgdHdvLXdheSBkZWxheSAoaW4N CiAgIG1pbGxpc2Vjb25kcykgb3ZlciB3aGljaCBhY3Rpb24ocykgU0hPVUxEIGJlIHRyaWdnZXJl ZC4NCg0KMi4yLjguICBGYXVsdCBNYW5hZ2VtZW50IFNpZ25hbCBzdWItVExWDQoNCiAgIFRoZSBG TVMgc3ViLVRMViBkZXBpY3RlZCBpbiBGaWd1cmUgOSBpcyBjYXJyaWVkIGFzIGEgc3ViLVRMViBv ZiB0aGUNCiAgIE1QTFMgT0FNIENvbmZpZ3VyYXRpb24gc3ViLVRMVi4gIFdoZW4gYm90aCB3b3Jr aW5nIGFuZCBwcm90ZWN0aW9uDQogICBwYXRocyBhcmUgY29uZmlndXJlZCwgYm90aCBMU1BzIFNI T1VMRCBiZSBjb25maWd1cmVkIHdpdGggaWRlbnRpY2FsDQogICBzZXR0aW5ncyBvZiB0aGUgRSBm bGFnLCBUIGZsYWcsIGFuZCB0aGUgcmVmcmVzaCB0aW1lci4NCg0KDQoNCg0KDQoNCg0KQmVsbGFn YW1iYSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEp1bmUgNywgMjAxNSAgICAgICAgICAgICAgICAg W1BhZ2UgMTZdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgRXh0ZW5zaW9ucyBmb3IgTVBMUy1U UCBPQU0gQ29uZiAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICB8ICAgICAgIEZNUyBzdWItdHlwZSAoMzAwKSAgICAgIHwgICAgICAg ICAgICBMZW5ndGggICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHxFfFN8VHwgUmVzZXJ2 ZWQgKHNldCB0byBhbGwgMHMpfCAgICAgIFJlZnJlc2ggVGltZXIgICAgICB8IFBIQiB8DQogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KDQogICAgICAgICAgICAgRmlndXJlIDk6IEZhdWx0IE1hbmFnZW1lbnQgU2lnbmFs IHN1Yi1UTFYgZm9ybWF0DQoNCiAgIFN1Yi10eXBlOiBpbmRpY2F0ZXMgYSBuZXcgc3ViLXR5cGUs IHRoZSBGTVMgc3ViLVRMViAoSUFOQSB0byBkZWZpbmUsDQogICBzdWdnZXN0ZWQgdmFsdWUgMzAw KS4NCg0KICAgTGVuZ3RoOiBpbmRpY2F0ZXMgdGhlIGxlbmd0aCBvZiB0aGUgVmFsdWUgZmllbGQg aW4gb2N0ZXRzICg0KS4NCg0KICAgRk1TIFNpZ25hbCBGbGFncyBhcmUgdXNlZCB0byBlbmFibGUg dGhlIEZNUyBzaWduYWxzIGF0IGVuZCBwb2ludCBNRVBzDQogICBhbmQgdGhlIFNlcnZlciBNRVBz IG9mIHRoZSBsaW5rcyBvdmVyIHdoaWNoIHRoZSBMU1AgaXMgZm9yd2FyZGVkLiAgSW4NCiAgIHRo aXMgZG9jdW1lbnQgb25seSB0aGUgUyBmbGFnIHBlcnRhaW5zIHRvIFNlcnZlciBNRVBzLg0KDQog ICBUaGUgZm9sbG93aW5nIGZsYWdzIGFyZSBkZWZpbmVkOg0KDQogICAgICAtIEU6IEVuYWJsZSBB bGFybSBJbmRpY2F0aW9uIFNpZ25hbCAoQUlTKSBhbmQgTG9jayBSZXBvcnQgKExLUikNCiAgICAg IHNpZ25hbGxpbmcgYXMgZGVzY3JpYmVkIGluIFtSRkM2NDI3XS4gIERlZmF1bHQgdmFsdWUgaXMg MQ0KICAgICAgKGVuYWJsZWQpLiAgSWYgdGhlIGVncmVzcyBNRVAgZG9lcyBub3Qgc3VwcG9ydCBG TVMgc2lnbmFsDQogICAgICBnZW5lcmF0aW9uIGFuICJPQU0gUHJvYmxlbS9GYXVsdCBtYW5hZ2Vt ZW50IHNpZ25hbGluZyB1bnN1cHBvcnRlZCINCiAgICAgIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVk Lg0KDQogICAgICAtIFM6IEluZGljYXRlIHRvIGEgc2VydmVyIE1FUCB0aGF0IGl0IHNob3VsZCB0 cmFuc21pdCBBSVMgYW5kIExLUg0KICAgICAgc2lnbmFscyBvbiB0aGUgY2xpZW50IExTUC4gIERl ZmF1bHQgdmFsdWUgaXMgMCAoZGlzYWJsZWQpLiAgSWYgYQ0KICAgICAgU2VydmVyIE1FUCB3aGlj aCBpcyBjYXBhYmxlIG9mIGdlbmVyYXRpbmcgRk1TIG1lc3NhZ2VzIGlzIGZvciBzb21lDQogICAg ICByZWFzb24gdW5hYmxlIHRvIGRvIHNvIGZvciB0aGUgTFNQIGJlaW5nIHNpZ25hbGxlZCBhbiAi T0FNDQogICAgICBQcm9ibGVtL1VuYWJsZSB0byBjcmVhdGUgZmF1bHQgbWFuYWdlbWVudCBhc3Nv Y2lhdGlvbiIgZXJyb3IgTVVTVA0KICAgICAgYmUgZ2VuZXJhdGVkLg0KDQogICAgICAtIFQ6IFNl dCB0aW1lciB2YWx1ZSwgZW5hYmxlZCB0aGUgY29uZmlndXJhdGlvbiBvZiBhIHNwZWNpZmljDQog ICAgICB0aW1lciB2YWx1ZS4gIERlZmF1bHQgdmFsdWUgaXMgMCAoZGlzYWJsZWQpLg0KDQogICAg ICAtIFJlbWFpbmluZyBiaXRzOiBSZXNlcnZlZCBmb3IgZnV0dXJlIHNwZWNpZmljYXRpb24gYW5k IHNldCB0byAwLg0KDQogICBSZWZyZXNoIFRpbWVyOiBpbmRpY2F0ZXMgdGhlIHJlZnJlc2ggdGlt ZXIgb2YgZmF1bHQgaW5kaWNhdGlvbg0KICAgbWVzc2FnZXMsIGluIHNlY29uZHMuICBUaGUgdmFs dWUgTVVTVCBiZSBiZXR3ZWVuIDEgdG8gMjAgc2Vjb25kcyBhcw0KICAgc3BlY2lmaWVkIGZvciB0 aGUgUmVmcmVzaCBUaW1lciBmaWVsZCBpbiBbUkZDNjQyN10uICBJZiB0aGUgZWRnZSBMU1INCiAg IHJlY2VpdmluZyB0aGUgUGF0aCBtZXNzYWdlIGNhbiBub3Qgc3VwcG9ydCB0aGUgdmFsdWUgaXQg U0hPVUxEIHJlcGx5DQogICB3aXRoIGEgaGlnaGVyIHRpbWVyIHZhbHVlLg0KDQogICBQSEI6IGlk ZW50aWZpZXMgdGhlIHBlci1ob3AgYmVoYXZpb3Igb2YgcGFja2V0cyB3aXRoIGZhdWx0IG1hbmFn ZW1lbnQNCiAgIGluZm9ybWF0aW9uLg0KDQoNCg0KDQpCZWxsYWdhbWJhLCBldCBhbC4gICAgICAg IEV4cGlyZXMgSnVuZSA3LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxN10NCg0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICBFeHRlbnNpb25zIGZvciBNUExTLVRQIE9BTSBDb25mICAgICAgIERl Y2VtYmVyIDIwMTQNCg0KDQoyLjIuOS4gIFNvdXJjZSBNRVAtSUQgc3ViLVRMVg0KDQogICBUaGUg U291cmNlIE1FUC1JRCBzdWItVExWIGRlcGljdGVkIGluIEZpZ3VyZSAxMCBpcyBjYXJyaWVkIGFz IGEgc3ViLQ0KICAgVExWIG9mIHRoZSBNUExTIE9BTSBGdW5jdGlvbnMgVExWLg0KDQogICBOb3Rl IHRoYXQgc3VwcG9ydCBvZiBJVFUgSURzIGlzIG91dC1vZi1zY29wZS4NCg0KICAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICB8IFNvdXJjZSBNRVAtSUQgc3ViLXR5cGUgKDQwMCkg IHwgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgIFNvdXJjZSBOb2RlIElEICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgVHVubmVsIElEICAgICAgICAgICB8ICAg ICAgICAgICBMU1AgSUQgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgICAgICAg ICAgICAgIEZpZ3VyZSAxMDogU291cmNlIE1FUC1JRCBzdWItVExWIGZvcm1hdA0KDQogICBTdWIt dHlwZTogaW5kaWNhdGVzIGEgbmV3IHN1Yi10eXBlLCB0aGUgU291cmNlIE1FUC1JRCBzdWItVExW IChJQU5BDQogICB0byBkZWZpbmUsIHN1Z2dlc3RlZCB2YWx1ZSA0MDApLg0KDQogICBMZW5ndGg6 IGluZGljYXRlcyB0aGUgbGVuZ3RoIG9mIHRoZSBWYWx1ZSBmaWVsZCBpbiBvY3RldHMgKDgpLg0K DQogICBTb3VyY2UgTm9kZSBJRDogMzItYml0IG5vZGUgaWRlbnRpZmllciBhcyBkZWZpbmVkIGlu IFtSRkM2MzcwXS4NCg0KICAgVHVubmVsIElEOiBhIDE2LWJpdCB1bnNpZ25lZCBpbnRlZ2VyIHVu aXF1ZSB0byB0aGUgbm9kZSBhcyBkZWZpbmVkIGluDQogICBbUkZDNjM3MF0uDQoNCiAgIExTUCBJ RDogYSAxNi1iaXQgdW5zaWduZWQgaW50ZWdlciB1bmlxdWUgd2l0aGluIHRoZSBUdW5uZWxfSUQg YXMNCiAgIGRlZmluZWQgaW4gW1JGQzYzNzBdLg0KDQozLiAgU3VtbWFyeSBvZiBNUExTIE9BTSBj b25maWd1cmF0aW9uIGVycm9ycw0KDQogICBUaGlzIGlzIHRoZSBzdW1tYXJ5IG9mIFJldHVybiBD b2RlcyBbUkZDNDM3OV0gZGVmaW5lZCBpbiB0aGlzDQogICBkb2N1bWVudDoNCg0KICAgICAgLSBJ ZiBhbiBlZ3Jlc3MgTFNSIGRvZXMgbm90IHN1cHBvcnQgdGhlIHNwZWNpZmllZCBCRkQgdmVyc2lv biwgYW4NCiAgICAgIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVkOiAiT0FNIFByb2JsZW0vVW5zdXBw b3J0ZWQgQkZEIFZlcnNpb24iLg0KDQogICAgICAtIElmIGFuIGVncmVzcyBMU1IgZG9lcyBub3Qg c3VwcG9ydCB0aGUgc3BlY2lmaWVkIEJGRA0KICAgICAgRW5jYXBzdWxhdGlvbiBmb3JtYXQsIGFu IGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVkOiAiT0FNIFByb2JsZW0vDQogICAgICBVbnN1cHBvcnRl ZCBCRkQgRW5jYXBzdWxhdGlvbiBmb3JtYXQiLg0KDQogICAgICAtIElmIGFuIGVncmVzcyBMU1Ig ZG9lcyBub3Qgc3VwcG9ydCBCRkQgQXV0aGVudGljYXRpb24sIGFuZCBpdCBpcw0KICAgICAgcmVx dWVzdGVkLCBhbiBlcnJvciBNVVNUIGJlIGdlbmVyYXRlZDogIk9BTSBQcm9ibGVtL0JGRA0KICAg ICAgQXV0aGVudGljYXRpb24gdW5zdXBwb3J0ZWQiLg0KDQoNCg0KDQpCZWxsYWdhbWJhLCBldCBh bC4gICAgICAgIEV4cGlyZXMgSnVuZSA3LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxOF0N Cg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICBFeHRlbnNpb25zIGZvciBNUExTLVRQIE9BTSBDb25m ICAgICAgIERlY2VtYmVyIDIwMTQNCg0KDQogICAgICAtIElmIGFuIGVncmVzcyBMU1IgZG9lcyBu b3Qgc3VwcG9ydCB0aGUgc3BlY2lmaWVkIEJGRA0KICAgICAgQXV0aGVudGljYXRpb24gVHlwZSwg YW4gZXJyb3IgTVVTVCBiZSBnZW5lcmF0ZWQ6ICJPQU0gUHJvYmxlbS8NCiAgICAgIFVuc3VwcG9y dGVkIEJGRCBBdXRoZW50aWNhdGlvbiBUeXBlIi4NCg0KICAgICAgLSBJZiBhbiBlZ3Jlc3MgTFNS IGlzIG5vdCBhYmxlIHRvIHVzZSB0aGUgc3BlY2lmaWVkIEF1dGhlbnRpY2F0aW9uDQogICAgICBL ZXkgSUQsIGFuIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVkOiAiT0FNIFByb2JsZW0vTWlzbWF0Y2gg b2YgQkZEDQogICAgICBBdXRoZW50aWNhdGlvbiBLZXkgSUQiLg0KDQogICAgICAtIElmIGFuIGVn cmVzcyBMU1IgZG9lcyBub3Qgc3VwcG9ydCB0aGUgc3BlY2lmaWVkIFRpbWVzdGFtcA0KICAgICAg Rm9ybWF0LCBhbiBlcnJvciBNVVNUIGJlIGdlbmVyYXRlZDogIk9BTSBQcm9ibGVtL1Vuc3VwcG9y dGVkDQogICAgICBUaW1lc3RhbXAgRm9ybWF0Ii4NCg0KICAgICAgLSBJZiBhbiBlZ3Jlc3MgTFNS IGRvZXMgbm90IHN1cHBvcnQgc3BlY2lmaWVkIERlbGF5IG1vZGUsIGFuICJPQU0NCiAgICAgIFBy b2JsZW0vVW5zdXBwb3J0ZWQgRGVsYXkgTW9kZSIgZXJyb3IgTVVTVCBiZSBnZW5lcmF0ZWQuDQoN CiAgICAgIC0gSWYgYW4gZWdyZXNzIExTUiBkb2VzIG5vdCBzdXBwb3J0IHNwZWNpZmllZCBMb3Nz IG1vZGUsIGFuICJPQU0NCiAgICAgIFByb2JsZW0vVW5zdXBwb3J0ZWQgTG9zcyBNb2RlIiBlcnJv ciBNVVNUIGJlIGdlbmVyYXRlZC4NCg0KICAgICAgLSBJZiBhbiBlZ3Jlc3MgTFNSIGRvZXMgbm90 IHN1cHBvcnQgRGVsYXkgdmFyaWF0aW9uIG1lYXN1cmVtZW50cywNCiAgICAgIGFuZCBpdCBpcyBy ZXF1ZXN0ZWQsIGFuICJPQU0gUHJvYmxlbS9EZWxheSB2YXJpYXRpb24gdW5zdXBwb3J0ZWQiDQog ICAgICBlcnJvciBNVVNUIGJlIGdlbmVyYXRlZC4NCg0KICAgICAgLSBJZiBhbiBlZ3Jlc3MgTFNS IGRvZXMgbm90IHN1cHBvcnQgRHlhZGljIG1vZGUsIGFuZCBpdCBpcw0KICAgICAgcmVxdWVzdGVk LCBhbiAiT0FNIFByb2JsZW0vRHlhZGljIG1vZGUgdW5zdXBwb3J0ZWQiIGVycm9yIE1VU1QgYmUN CiAgICAgIGdlbmVyYXRlZC4NCg0KICAgICAgLSBJZiBhbiBlZ3Jlc3MgTFNSIGRvZXMgbm90IHN1 cHBvcnQgTG9vcGJhY2sgbW9kZSwgYW5kIGl0IGlzDQogICAgICByZXF1ZXN0ZWQsIGFuICJPQU0g UHJvYmxlbS9Mb29wYmFjayBtb2RlIHVuc3VwcG9ydGVkIiBlcnJvciBNVVNUDQogICAgICBiZSBn ZW5lcmF0ZWQuDQoNCiAgICAgIC0gSWYgYW4gZWdyZXNzIExTUiBkb2VzIG5vdCBzdXBwb3J0IENv bWJpbmVkIG1vZGUsIGFuZCBpdCBpcw0KICAgICAgcmVxdWVzdGVkLCBhbiAiT0FNIFByb2JsZW0v Q29tYmluZWQgbW9kZSB1bnN1cHBvcnRlZCIgZXJyb3IgTVVTVA0KICAgICAgYmUgZ2VuZXJhdGVk Lg0KDQogICAgICAtIElmIGFuIGVncmVzcyBMU1IgZG9lcyBub3Qgc3VwcG9ydCBGYXVsdCBNb25p dG9yaW5nIFNpZ25hbHMsIGFuZA0KICAgICAgaXQgaXMgcmVxdWVzdGVkLCBhbiAiT0FNIFByb2Js ZW0vRmF1bHQgbWFuYWdlbWVudCBzaWduYWxpbmcNCiAgICAgIHVuc3VwcG9ydGVkIiBlcnJvciBN VVNUIGJlIGdlbmVyYXRlZC4NCg0KICAgICAgLSBJZiBhbiBpbnRlcm1lZGlhdGUgc2VydmVyIE1F UCBzdXBwb3J0cyBGYXVsdCBNb25pdG9yaW5nIFNpZ25hbHMNCiAgICAgIGJ1dCBpcyB1bmFibGUg dG8gY3JlYXRlIGFuIGFzc29jaWF0aW9uLCB3aGVuIHJlcXVlc3RlZCB0byBkbyBzbywNCiAgICAg IGFuICJPQU0gUHJvYmxlbS9VbmFibGUgdG8gY3JlYXRlIGZhdWx0IG1hbmFnZW1lbnQgYXNzb2Np YXRpb24iDQogICAgICBlcnJvciBNVVNUIGJlIGdlbmVyYXRlZC4NCg0KNC4gIElBTkEgQ29uc2lk ZXJhdGlvbnMNCg0KDQoNCg0KDQoNCg0KQmVsbGFnYW1iYSwgZXQgYWwuICAgICAgICBFeHBpcmVz IEp1bmUgNywgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQoNCg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgRXh0ZW5zaW9ucyBmb3IgTVBMUy1UUCBPQU0gQ29uZiAgICAgICBEZWNlbWJlciAy MDE0DQoNCg0KNC4xLiAgVExWIGFuZCBzdWItVExWIEFsbG9jYXRpb24NCg0KICAgTm90ZTogVGhl IElBTkEgY29uc2lkZXJhdGlvbnMgaW4gdGhpcyBkb2N1bWVudCBpcyB3cml0dGVuIGFjY29yZGlu Zw0KICAgdG8gdGhlIGFsbG9jYXRpb24gcG9saWNpZXMgc3BlY2lmaWVkIGluIFJGQzQzNzkuICBI b3dldmVyIHRoZXJlIGlzIGENCiAgIGRyYWZ0IHRoYXQgc3VnZ2VzdCBjaGFuZ2VzIHRvIHRoZXNl IGFsbG9jYXRpb24gcG9saWNpZXMsIGRyYWZ0LXBhYy0NCiAgIG1wbHMtbHNwLXBpbmctdGx2cy1h bmQtc3ViLXRsdnMtcmVnaXN0cnkgaWYgdGhlIHdvcmtpbmcgZ3JvdXAgYWNjZXB0DQogICB0aGUg bmV3IGFsbG9jYXRpb24gc3BlY2lmaWVkIGluIHRoYXQgZHJhZnQgdGhlIGFsbG9jYXRpb25zIG1h ZGUgdGhpcw0KICAgZHJhZnQsIHRoaXMgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGluIHRo aXMgZG9jdW1lbnQgd2lsbCBiZSByZS0NCiAgIHdyaXR0ZW4uDQoNCiAgIElBTkEgbWFpbnRhaW5z IGEgcmVnaXN0cnkgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKSBMYWJlbA0K ICAgU3dpdGNoZWQgUGF0aHMgKExTUHMpIFBpbmcgUGFyYW1ldGVycyByZWdpc3RyeSwgYW5kIHdp dGhpbiB0aGF0DQogICByZWdpc3RyeSBhIHN1Yi1yZWdpc3RyeSBUTFZzIGFuZCBzdWItVExWcy4N Cg0KICAgSUFOQSBpcyByZXF1ZXN0ZWQgYSBuZXcgVExWIGZyb20gdGhlIHN0YW5kYXJkcyBhY3Rp b24gcmFuZ2UgKDAtMTYzODMpDQogICBhbmQgc3ViLVRMVnMgYXMgZm9sbG93cyBmcm9tIHRoaXMg c3ViLXJlZ2lzdHJ5Lg0KDQogICArLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgVHlwZSB8IFN1Yi10eXBlIHwg VmFsdWUgRmllbGQgICAgICAgICAgICAgICAgICAgICB8IFJlZmVyZW5jZSAgICAgfA0KICAgKy0t LS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rDQogICB8IFRCQTEgfCAgICAgICAgICB8IE1QTFMgT0FNIEZ1bmN0aW9ucyAgICAg ICAgICAgICAgfCBUaGlzIGRvY3VtZW50IHwNCiAgIHwgICAgICB8IDEwMCAgICAgIHwgQkZEIENv bmZpZ3VyYXRpb24gICAgICAgICAgICAgICB8IFRoaXMgZG9jdW1lbnQgfA0KICAgfCAgICAgIHwg MTAxICAgICAgfCBCRkQgTG9jYWwgRGlzY3JpbWluYXRvciAgICAgICAgIHwgVGhpcyBkb2N1bWVu dCB8DQogICB8ICAgICAgfCAxMDIgICAgICB8IEJGRCBOZWdvdGlhdGlvbiBUaW1lciAgICAgICAg ICAgfCBUaGlzIGRvY3VtZW50IHwNCiAgIHwgICAgICB8ICAgICAgICAgIHwgUGFyYW1ldGVycyAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfA0KICAgfCAgICAgIHwgMTAzICAg ICAgfCBCRkQgQXV0aGVudGljYXRpb24gICAgICAgICAgICAgIHwgVGhpcyBkb2N1bWVudCB8DQog ICB8ICAgICAgfCAyMDAgICAgICB8IFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50ICAgICAgICAgfCBU aGlzIGRvY3VtZW50IHwNCiAgIHwgICAgICB8IDIwMSAgICAgIHwgUE0gTG9zcyBNZWFzdXJlbWVu dCAgICAgICAgICAgICB8IFRoaXMgZG9jdW1lbnQgfA0KICAgfCAgICAgIHwgMjAyICAgICAgfCBQ TSBEZWxheSBNZWFzdXJlbWVudCAgICAgICAgICAgIHwgVGhpcyBkb2N1bWVudCB8DQogICB8ICAg ICAgfCAyMDMgICAgICB8IEZhdWx0IE1hbmFnZW1lbnQgU2lnbmFsICAgICAgICAgfCBUaGlzIGRv Y3VtZW50IHwNCiAgIHwgICAgICB8IDIwNCAgICAgIHwgU291cmNlIE1FUC1JRCAgICAgICAgICAg ICAgICAgICB8IFRoaXMgZG9jdW1lbnQgfA0KICAgKy0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAg ICAgICAgICAgIFRhYmxlIDI6IElBTkEgVExWIFR5cGUgQWxsb2NhdGlvbg0KDQo0LjIuICBPQU0g Y29uZmlndXJhdGlvbiBlcnJvcnMNCg0KICAgSUFOQSBtYWludGFpbnMgYSByZWdpc3RyeSAiTXVs dGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKQ0KICAgTGFiZWwgU3dpdGNoZWQgUGF0 aHMgKExTUHMpIFBpbmcgUGFyYW1ldGVycyIgcmVnaXN0cnksIGFuZCB3aXRoaW4NCiAgIHRoYXQg cmVnaXN0cnkgYSBzdWItcmVnaXN0cnkgIlJldHVybiBDb2RlcyIuDQoNCiAgIElBTkEgaXMgcmVx dWVzdGVkIHRvIGFzc2lnbiBuZXcgUmV0dXJuIENvZGVzIGZyb20gdGhlIFN0YW5kYXJkcw0KICAg QWN0aW9uIHJhbmdlICgwLTE5MSkgYXMgZm9sbG93czoNCg0KDQoNCg0KDQoNCg0KDQpCZWxsYWdh bWJhLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSnVuZSA3LCAyMDE1ICAgICAgICAgICAgICAgICBb UGFnZSAyMF0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICBFeHRlbnNpb25zIGZvciBNUExTLVRQ IE9BTSBDb25mICAgICAgIERlY2VtYmVyIDIwMTQNCg0KDQogICArLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiAgIHwg RXJyb3IgVmFsdWUgICB8IERlc2NyaXB0aW9uICAgICAgICAgICAgICAgICAgICAgICB8IFJlZmVy ZW5jZSAgICAgfA0KICAgfCBTdWItY29kZXMgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgVEJBMyAg ICAgICAgICB8IE9BTSBQcm9ibGVtL1Vuc3VwcG9ydGVkIEJGRCAgICAgICB8IFRoaXMgZG9jdW1l bnQgfA0KICAgfCAgICAgICAgICAgICAgIHwgVmVyc2lvbiAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICB8DQogICB8IFRCQTQgICAgICAgICAgfCBPQU0gUHJvYmxlbS9V bnN1cHBvcnRlZCBCRkQgICAgICAgfCBUaGlzIGRvY3VtZW50IHwNCiAgIHwgICAgICAgICAgICAg ICB8IEVuY2Fwc3VsYXRpb24gZm9ybWF0ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfA0K ICAgfCBUQkE1ICAgICAgICAgIHwgT0FNIFByb2JsZW0vVW5zdXBwb3J0ZWQgQkZEICAgICAgIHwg VGhpcyBkb2N1bWVudCB8DQogICB8ICAgICAgICAgICAgICAgfCBBdXRoZW50aWNhdGlvbiBUeXBl ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwNCiAgIHwgVEJBNiAgICAgICAgICB8IE9B TSBQcm9ibGVtL01pc21hdGNoIG9mIEJGRCAgICAgICB8IFRoaXMgZG9jdW1lbnQgfA0KICAgfCAg ICAgICAgICAgICAgIHwgQXV0aGVudGljYXRpb24gS2V5IElEICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICB8DQogICB8IFRCQTcgICAgICAgICAgfCBPQU0gUHJvYmxlbS9VbnN1cHBvcnRlZCBU aW1lc3RhbXAgfCBUaGlzIGRvY3VtZW50IHwNCiAgIHwgICAgICAgICAgICAgICB8IEZvcm1hdCAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfA0KICAgfCBUQkE4ICAg ICAgICAgIHwgT0FNIFByb2JsZW0vVW5zdXBwb3J0ZWQgRGVsYXkgICAgIHwgVGhpcyBkb2N1bWVu dCB8DQogICB8ICAgICAgICAgICAgICAgfCBNb2RlICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgIHwNCiAgIHwgVEJBOSAgICAgICAgICB8IE9BTSBQcm9ibGVtL1Vu c3VwcG9ydGVkIExvc3MgTW9kZSB8IFRoaXMgZG9jdW1lbnQgfA0KICAgfCBUQkExMCAgICAgICAg IHwgT0FNIFByb2JsZW0vRGVsYXkgdmFyaWF0aW9uICAgICAgIHwgVGhpcyBkb2N1bWVudCB8DQog ICB8ICAgICAgICAgICAgICAgfCB1bnN1cHBvcnRlZCAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgIHwNCiAgIHwgVEJBMTEgICAgICAgICB8IE9BTSBQcm9ibGVtL0R5YWRpYyBt b2RlICAgICAgICAgICB8IFRoaXMgZG9jdW1lbnQgfA0KICAgfCAgICAgICAgICAgICAgIHwgdW5z dXBwb3J0ZWQgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8DQogICB8IFRC QTEyICAgICAgICAgfCBPQU0gUHJvYmxlbS9Mb29wYmFjayBtb2RlICAgICAgICAgfCBUaGlzIGRv Y3VtZW50IHwNCiAgIHwgICAgICAgICAgICAgICB8IHVuc3VwcG9ydGVkICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgfA0KICAgfCBUQkExMyAgICAgICAgIHwgT0FNIFByb2Js ZW0vQ29tYmluZWQgbW9kZSAgICAgICAgIHwgVGhpcyBkb2N1bWVudCB8DQogICB8ICAgICAgICAg ICAgICAgfCB1bnN1cHBvcnRlZCAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg IHwNCiAgIHwgVEJBMTQgICAgICAgICB8IE9BTSBQcm9ibGVtL0ZhdWx0IG1hbmFnZW1lbnQgICAg ICB8IFRoaXMgZG9jdW1lbnQgfA0KICAgfCAgICAgICAgICAgICAgIHwgc2lnbmFsaW5nIHVuc3Vw cG9ydGVkICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8DQogICB8IFRCQTE1ICAgICAgICAg fCBPQU0gUHJvYmxlbS9VbmFibGUgdG8gY3JlYXRlICAgICAgfCBUaGlzIGRvY3VtZW50IHwNCiAg IHwgICAgICAgICAgICAgICB8IGZhdWx0IG1hbmFnZW1lbnQgYXNzb2NpYXRpb24gICAgICB8ICAg ICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgICBUYWJs ZSAzOiBJQU5BIFJldHVybiBDb2RlcyBBbGxvY2F0aW9uDQoNCjUuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucw0KDQogICBUaGUgc2lnbmFsaW5nIG9mIE9BTSByZWxhdGVkIHBhcmFtZXRlcnMgYW5k IHRoZSBhdXRvbWF0aWMNCiAgIGVzdGFibGlzaG1lbnQgb2YgT0FNIGVudGl0aWVzIGludHJvZHVj ZXMgYWRkaXRpb25hbCBzZWN1cml0eQ0KICAgY29uc2lkZXJhdGlvbnMgdG8gdGhvc2UgZGlzY3Vz c2VkIGluIFtSRkMzNDczXS4gIEluIHBhcnRpY3VsYXIsIGENCiAgIG5ldHdvcmsgZWxlbWVudCBj b3VsZCBiZSBvdmVybG9hZGVkIGlmIGFuIGF0dGFja2VyIHdlcmUgdG8gcmVxdWVzdA0KICAgaGln aCBmcmVxdWVuY3kgbGl2ZWxpbmVzcyBtb25pdG9yaW5nIG9mIGEgbGFyZ2UgbnVtYmVyIG9mIExT UHMsDQogICB0YXJnZXRpbmcgYSBzaW5nbGUgbmV0d29yayBlbGVtZW50Lg0KDQo2LiAgUmVmZXJl bmNlcw0KDQoNCg0KDQoNCg0KDQoNCkJlbGxhZ2FtYmEsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBK dW5lIDcsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDIxXQ0KDQoNCkludGVybmV0LURyYWZ0 ICAgICAgIEV4dGVuc2lvbnMgZm9yIE1QTFMtVFAgT0FNIENvbmYgICAgICAgRGVjZW1iZXIgMjAx NA0KDQoNCjYuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5l ciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoN CiAgIFtSRkMzNDczXSAgQmVyZ2VyLCBMLiwgIkdlbmVyYWxpemVkIE11bHRpLVByb3RvY29sIExh YmVsIFN3aXRjaGluZw0KICAgICAgICAgICAgICAoR01QTFMpIFNpZ25hbGluZyBSZXNvdXJjZSBS ZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljDQogICAgICAgICAgICAgIEVuZ2luZWVyaW5nIChS U1ZQLVRFKSBFeHRlbnNpb25zIiwgUkZDIDM0NzMsIEphbnVhcnkgMjAwMy4NCg0KICAgW1JGQzQz NzldICBLb21wZWxsYSwgSy4gYW5kIEcuIFN3YWxsb3csICJEZXRlY3RpbmcgTXVsdGktUHJvdG9j b2wNCiAgICAgICAgICAgICAgTGFiZWwgU3dpdGNoZWQgKE1QTFMpIERhdGEgUGxhbmUgRmFpbHVy ZXMiLCBSRkMgNDM3OSwNCiAgICAgICAgICAgICAgRmVicnVhcnkgMjAwNi4NCg0KICAgW1JGQzU2 NTRdICBOaXZlbi1KZW5raW5zLCBCLiwgQnJ1bmdhcmQsIEQuLCBCZXR0cywgTS4sIFNwcmVjaGVy LCBOLiwNCiAgICAgICAgICAgICAgYW5kIFMuIFVlbm8sICJSZXF1aXJlbWVudHMgb2YgYW4gTVBM UyBUcmFuc3BvcnQgUHJvZmlsZSIsDQogICAgICAgICAgICAgIFJGQyA1NjU0LCBTZXB0ZW1iZXIg MjAwOS4NCg0KICAgW1JGQzU4NjBdICBWaWdvdXJldXgsIE0uLCBXYXJkLCBELiwgYW5kIE0uIEJl dHRzLCAiUmVxdWlyZW1lbnRzIGZvcg0KICAgICAgICAgICAgICBPcGVyYXRpb25zLCBBZG1pbmlz dHJhdGlvbiwgYW5kIE1haW50ZW5hbmNlIChPQU0pIGluIE1QTFMNCiAgICAgICAgICAgICAgVHJh bnNwb3J0IE5ldHdvcmtzIiwgUkZDIDU4NjAsIE1heSAyMDEwLg0KDQogICBbUkZDNTg4MF0gIEth dHosIEQuIGFuZCBELiBXYXJkLCAiQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0K ICAgICAgICAgICAgICAoQkZEKSIsIFJGQyA1ODgwLCBKdW5lIDIwMTAuDQoNCiAgIFtSRkM1ODg0 XSAgQWdnYXJ3YWwsIFIuLCBLb21wZWxsYSwgSy4sIE5hZGVhdSwgVC4sIGFuZCBHLiBTd2FsbG93 LA0KICAgICAgICAgICAgICAiQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZE KSBmb3IgTVBMUyBMYWJlbA0KICAgICAgICAgICAgICBTd2l0Y2hlZCBQYXRocyAoTFNQcykiLCBS RkMgNTg4NCwgSnVuZSAyMDEwLg0KDQogICBbUkZDNjM3MF0gIEJvY2NpLCBNLiwgU3dhbGxvdywg Ry4sIGFuZCBFLiBHcmF5LCAiTVBMUyBUcmFuc3BvcnQNCiAgICAgICAgICAgICAgUHJvZmlsZSAo TVBMUy1UUCkgSWRlbnRpZmllcnMiLCBSRkMgNjM3MCwgU2VwdGVtYmVyIDIwMTEuDQoNCiAgIFtS RkM2Mzc0XSAgRnJvc3QsIEQuIGFuZCBTLiBCcnlhbnQsICJQYWNrZXQgTG9zcyBhbmQgRGVsYXkN CiAgICAgICAgICAgICAgTWVhc3VyZW1lbnQgZm9yIE1QTFMgTmV0d29ya3MiLCBSRkMgNjM3NCwg U2VwdGVtYmVyIDIwMTEuDQoNCiAgIFtSRkM2NDI3XSAgU3dhbGxvdywgRy4sIEZ1bGlnbm9saSwg QS4sIFZpZ291cmV1eCwgTS4sIEJvdXRyb3MsIFMuLA0KICAgICAgICAgICAgICBhbmQgRC4gV2Fy ZCwgIk1QTFMgRmF1bHQgTWFuYWdlbWVudCBPcGVyYXRpb25zLA0KICAgICAgICAgICAgICBBZG1p bmlzdHJhdGlvbiwgYW5kIE1haW50ZW5hbmNlIChPQU0pIiwgUkZDIDY0MjcsIE5vdmVtYmVyDQog ICAgICAgICAgICAgIDIwMTEuDQoNCiAgIFtSRkM2NDI4XSAgQWxsYW4sIEQuLCBTd2FsbG93IEVk LiAsIEcuLCBhbmQgSi4gRHJha2UgRWQuICwgIlByb2FjdGl2ZQ0KICAgICAgICAgICAgICBDb25u ZWN0aXZpdHkgVmVyaWZpY2F0aW9uLCBDb250aW51aXR5IENoZWNrLCBhbmQgUmVtb3RlDQogICAg ICAgICAgICAgIERlZmVjdCBJbmRpY2F0aW9uIGZvciB0aGUgTVBMUyBUcmFuc3BvcnQgUHJvZmls ZSIsIFJGQw0KICAgICAgICAgICAgICA2NDI4LCBOb3ZlbWJlciAyMDExLg0KDQoNCg0KDQoNCg0K DQoNCkJlbGxhZ2FtYmEsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKdW5lIDcsIDIwMTUgICAgICAg ICAgICAgICAgIFtQYWdlIDIyXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgIEV4dGVuc2lvbnMg Zm9yIE1QTFMtVFAgT0FNIENvbmYgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCjYuMi4gIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzMyMDldICBBd2R1Y2hlLCBELiwgQmVyZ2VyLCBM LiwgR2FuLCBELiwgTGksIFQuLCBTcmluaXZhc2FuLCBWLiwNCiAgICAgICAgICAgICAgYW5kIEcu IFN3YWxsb3csICJSU1ZQLVRFOiBFeHRlbnNpb25zIHRvIFJTVlAgZm9yIExTUA0KICAgICAgICAg ICAgICBUdW5uZWxzIiwgUkZDIDMyMDksIERlY2VtYmVyIDIwMDEuDQoNCiAgIFtSRkM1MDM2XSAg QW5kZXJzc29uLCBMLiwgTWluZWksIEkuLCBhbmQgQi4gVGhvbWFzLCAiTERQDQogICAgICAgICAg ICAgIFNwZWNpZmljYXRpb24iLCBSRkMgNTAzNiwgT2N0b2JlciAyMDA3Lg0KDQogICBbUkZDNjM3 MV0gIEJ1c2ksIEkuIGFuZCBELiBBbGxhbiwgIk9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBh bmQNCiAgICAgICAgICAgICAgTWFpbnRlbmFuY2UgRnJhbWV3b3JrIGZvciBNUExTLUJhc2VkIFRy YW5zcG9ydCBOZXR3b3JrcyIsDQogICAgICAgICAgICAgIFJGQyA2MzcxLCBTZXB0ZW1iZXIgMjAx MS4NCg0KICAgW1JGQzYzNzVdICBGcm9zdCwgRC4gYW5kIFMuIEJyeWFudCwgIkEgUGFja2V0IExv c3MgYW5kIERlbGF5DQogICAgICAgICAgICAgIE1lYXN1cmVtZW50IFByb2ZpbGUgZm9yIE1QTFMt QmFzZWQgVHJhbnNwb3J0IE5ldHdvcmtzIiwNCiAgICAgICAgICAgICAgUkZDIDYzNzUsIFNlcHRl bWJlciAyMDExLg0KDQogICBbUkZDNjY2OV0gIFNwcmVjaGVyLCBOLiBhbmQgTC4gRmFuZywgIkFu IE92ZXJ2aWV3IG9mIHRoZSBPcGVyYXRpb25zLA0KICAgICAgICAgICAgICBBZG1pbmlzdHJhdGlv biwgYW5kIE1haW50ZW5hbmNlIChPQU0pIFRvb2xzZXQgZm9yIE1QTFMtDQogICAgICAgICAgICAg IEJhc2VkIFRyYW5zcG9ydCBOZXR3b3JrcyIsIFJGQyA2NjY5LCBKdWx5IDIwMTIuDQoNCiAgIFtS U1ZQLVRFLUNPTkZdDQogICAgICAgICAgICAgIEJlbGxhZ2FtYmEsIEUuLCBBbmRlcnNzb24sIEwu LCBXYXJkLCBELiwgYW5kIFAuDQogICAgICAgICAgICAgIFNrb2xkc3Ryb20sICJDb25maWd1cmF0 aW9uIG9mIHByby1hY3RpdmUgTVBMUy1UUA0KICAgICAgICAgICAgICBPcGVyYXRpb25zLCBBZG1p bmlzdHJhdGlvbiwgYW5kIE1haW50ZW5hbmNlIChPQU0pDQogICAgICAgICAgICAgIEZ1bmN0aW9u cyBVc2luZyBSU1ZQLVRFIiwgMjAxMiwgPGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS0NCiAgICAg ICAgICAgICAgbXBscy10cC1vYW0tZXh0Pi4NCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIEVs aXNhIEJlbGxhZ2FtYmEgKGVkaXRvcikNCiAgIEVyaWNzc29uDQoNCiAgIEVtYWlsOiBlbGlzYS5i ZWxsYWdhbWJhQGVyaWNzc29uLmNvbQ0KDQoNCiAgIEdyZWdvcnkgTWlyc2t5IChlZGl0b3IpDQog ICBFcmljc3Nvbg0KDQogICBFbWFpbDogR3JlZ29yeS5NaXJza3lAZXJpY3Nzb24uY29tDQoNCg0K ICAgTG9hIEFuZGVyc3Nvbg0KICAgSHVhd2VpDQoNCiAgIEVtYWlsOiBsb2FAbWFpbDAxLmh1YXdl aS5jb20NCg0KDQoNCg0KDQpCZWxsYWdhbWJhLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSnVuZSA3 LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAyM10NCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAg ICBFeHRlbnNpb25zIGZvciBNUExTLVRQIE9BTSBDb25mICAgICAgIERlY2VtYmVyIDIwMTQNCg0K DQogICBQb250dXMgU2tvbGRzdHJvbSAoZWRpdG9yKQ0KICAgQWNyZW8gQUINCiAgIEVsZWN0cnVt IDIzNg0KICAgS2lzdGEgIDE2NCA0MA0KICAgU3dlZGVuDQoNCiAgIFBob25lOiArNDYgOCA2MzI3 NzMxDQogICBFbWFpbDogcG9udHVzLnNrb2xkc3Ryb21AYWNyZW8uc2UNCg0KDQogICBEYXZlIFdh cmQNCiAgIENpc2NvDQoNCiAgIEVtYWlsOiBkd2FyZEBjaXNjby5jb20NCg0KDQogICBKb2huIERy YWtlDQogICBKdW5pcGVyDQoNCiAgIEVtYWlsOiBqZHJha2VAanVuaXBlci5uZXQNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQmVs bGFnYW1iYSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEp1bmUgNywgMjAxNSAgICAgICAgICAgICAg ICAgW1BhZ2UgMjRdDQoNCg== --_004_7347100B5761DC41A166AC17F22DF1121B8A9937eusaamb103erics_-- From nobody Tue Dec 2 23:32: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 558DA1A00F0; Tue, 2 Dec 2014 23:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HafvC8skRPdy; Tue, 2 Dec 2014 23:32:44 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D371A0022; Tue, 2 Dec 2014 23:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33983; q=dns/txt; s=iport; t=1417591963; x=1418801563; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=kfbdfdUlO3VhERPcjApafYtrw4JlnDm8zeYd8WK9/Wo=; b=VWycUZt5fyt843rSkag13CmsMghw8YSkDS6A/5VaalaYpQdPzrwvXWhz idV+JlAJdppLMVZuhvJd9REf9Q5tZ69JknS0uAxOA98zn/9ekPtvWI6kU VXPKsBooi8RdQAZyxHtgi23HqrKqhkE0iqD+LJ6r3HIBXpm97z2csFh1V c=; X-IronPort-AV: E=Sophos;i="5.07,506,1413244800"; d="scan'208,217";a="258830877" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Dec 2014 07:32:39 +0000 Received: from [64.103.108.91] (dhcp-bdlk10-data-vlan301-64-103-108-91.cisco.com [64.103.108.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB37Wc5M016442; Wed, 3 Dec 2014 07:32:39 GMT Message-ID: <547EBC95.6020608@cisco.com> Date: Wed, 03 Dec 2014 07:32:37 +0000 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: stephane.litkowski@orange.com, Uma Chunduri , Alia Atlas , Loa Andersson References: <546BDF65.2030203@pi.nu> <3682_1416561775_546F046F_3682_717_1_9E32478DFA9976438E7A22F69B08FF92177BF0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A60469152008633F44A97E@eusaamb105.ericsson.se> <18727_1416732463_54719F2F_18727_12486_1_9E32478DFA9976438E7A22F69B08FF92178256@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <18727_1416732463_54719F2F_18727_12486_1_9E32478DFA9976438E7A22F69B08FF92178256@OPEXCLILM34.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------090208080800000303090409" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RSZnj87ews7S4uRiajOl5FmrPl4 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "rtgwg@ietf.org" Subject: Re: [mpls] maturity of the MRT technology 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: Wed, 03 Dec 2014 07:32:49 -0000 This is a multi-part message in MIME format. --------------090208080800000303090409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have been mulling this over for a while and I am wondering how the current industry debate on SDN vs traditional distributed routing plays into this. You could build a case that whilst there always needs to be a base topology that needs to be calculated using a traditional distributed routing protocol (for absolute resilience and bootstrapping) any domain wide repair topology could be better implemented through SDN since it benefits from a global perspective. That would suggest that whilst we might benefit from standardizing the advertisement of some IPFRR related parameters, and would certainly benefit from standardization of the YANG models needed to control the IPFRR subsystem, the method of calculating the repair topology itself ought to be private to the orchestrator. The classical argument against this is concern with the time to reinstate the repair topology after a failure, but I am not sure how significant this is since (a) normally this would be an incremental change, and (b) given that we would normally be computing this on some high end platform it could have the results of any single failure (or restore) pre-computed. - Stewart On 23/11/2014 08:47, stephane.litkowski@orange.com wrote: > > HI Uma, > > >Is this because of domain wide deployment requirements MRT brings-in > (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in > the network? > > No, domain-wide deployment is not an issue. The issue I see in MRT > (for my use case) is unoptimality of the FRR path (at least using > lowpoint algorithm). But anyway, as I mentioned, I'm not opposed to > make MRT progressing at all. It's good to have multiple tools. > > Best Regards, > > *From:*Uma Chunduri [mailto:uma.chunduri@ericsson.com] > *Sent:* Friday, November 21, 2014 20:37 > *To:* LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson > *Cc:* mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org > *Subject:* RE: maturity of the MRT technology > > >I'm not a great supporter of MRT implementation in my network, because it > does not address correctly my use cases but despite of this, > > Is this because of domain wide deployment requirements MRT brings-in > (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in > the network? > > > I deeply think that it's another item in the FRR toolchest (like LFA, > remote LFA ...), > > >it will be up to each Service Provider to choose the appropriate > technology based on its own use case/constraints. > > I agree with above. It depends on the particular deployment scenario > and applicability for that network. > > -- > > Uma C. > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of > *stephane.litkowski@orange.com > *Sent:* Friday, November 21, 2014 1:23 AM > *To:* Alia Atlas; Loa Andersson > *Cc:* mpls@ietf.org ; mpls-chairs@tools.ietf.org > ; > draft-atlas-mpls-ldp-mrt@tools.ietf.org > ; rtgwg@ietf.org > > *Subject:* Re: [mpls] maturity of the MRT technology > > +1 > > As for all FRR technologies, MRT has pros and cons, and this does not > influence the maturity of the technical solutions. We already had > multiple discussions online and offline on technical details leading > now to documents that are quite detailed and well understood > technology (with pros and cons as I mentioned). I'm not a great > supporter of MRT implementation in my network, because it does not > address correctly my use cases but despite of this, I deeply think > that it's another item in the FRR toolchest (like LFA, remote LFA > ...), it will be up to each Service Provider to choose the appropriate > technology based on its own use case/constraints. Processing of MRT , > IMHO, should be done as LFA and other similar technologies so standard > track sounds good to me. > > We already seen much less mature technologies going to standard track > and being RFC without any running code after ... > > Best Regards, > > Stephane > > *From:*rtgwg [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Alia Atlas > *Sent:* Thursday, November 20, 2014 19:17 > *To:* Loa Andersson > *Cc:* mpls@ietf.org ; mpls-chairs@tools.ietf.org > ; > draft-atlas-mpls-ldp-mrt@tools.ietf.org > ; VIGOUREUX, MARTIN > (MARTIN); rtgwg@ietf.org > *Subject:* Re: maturity of the MRT technology > > Loa, > > Without any hats on, I would note: > > a) As far as I'm aware, this has seen two independent prototypes > implemented. > > b) I have not heard any concrete technical concerns. Stewart and I > did specificallly > > discuss MRT this past IETF. I am, of course, quite interested in > hearing any > > concrete technical concerns. > > c) I'd be happy seeing this question asked of more drafts :-) > > Regards, > > Alia > > On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson > wrote: > > Working Groups, > > We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been > posted to the mpls wg mailing list. > > In his MPLS-RT review Stewart Bryant says: > > "I have concerns about whether or not MRT technology has the maturity > expected in the standards track. However that decision needs to be > taken in RTGWG and MPLS needs to follow their and lead in determining > the fate and track of this draft. This draft should not be published > ahead of the drafts that define the technology that it is supporting." > > He also says that he see no reason not to go ahead and start the poll to > see if we have consensus to adopt the document as an mpls wg document. > > The question Stewart ask is valid, and we'd like input from the rtgwg > and rtgwg chairs (copied on this mail). We will also copy both the > poll for adoption and the wglc to the rtgwg mailing list. > > /Loa > mpls wg co-chair > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------090208080800000303090409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I have been mulling this over for a while and I am wondering
how the current industry debate on SDN vs traditional distributed
routing plays into this.

You could build a  case that whilst there always needs to be a base
topology that needs to be calculated using a traditional distributed
routing protocol (for absolute resilience and bootstrapping) any
domain wide repair topology could be better implemented through
SDN since it benefits from a global perspective.

That would suggest that whilst we might benefit from standardizing
the advertisement of some IPFRR related parameters, and would
certainly benefit from standardization of the YANG models needed
to control the IPFRR subsystem, the method of calculating the
repair topology itself ought to be private to the orchestrator.

The classical argument against this is concern with the time to
reinstate the repair topology after a failure, but I am not sure
how significant this is since (a) normally this would be an incremental
change, and (b) given that we would normally be computing this
on some high end platform it could have the results of any single
failure (or restore) pre-computed.

- Stewart

On 23/11/2014 08:47, stephane.litkowski@orange.com wrote:

HI Uma,

 

> Is this because of domain wide deployment requirements MRT brings-in (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network?

 

No, domain-wide deployment is not an issue. The issue I see in MRT (for my use case) is unoptimality of the FRR path (at least using lowpoint algorithm). But anyway, as I mentioned, I’m not opposed to make MRT progressing at all. It’s good to have multiple tools.

 

Best Regards,

 

 

From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
Sent: Friday, November 21, 2014 20:37
To: LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org
Subject: RE: maturity of the MRT technology

 

>I’m not a great supporter of MRT implementation in my network, because it does not address correctly my use cases but despite of this,

 

Is this because of domain wide deployment requirements MRT brings-in (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network?

 

> I deeply think that it’s another item in the FRR toolchest (like LFA, remote LFA …),

>it will be up to each Service Provider to choose the appropriate technology based on its own use case/constraints.

 

I agree with above.  It depends on the particular deployment scenario and applicability for that network.

 

--

Uma C.

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Friday, November 21, 2014 1:23 AM
To: Alia Atlas; Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org
Subject: Re: [mpls] maturity of the MRT technology

 

+1

 

As for all FRR technologies, MRT has pros and cons, and this does not influence the maturity of the technical solutions. We already had multiple discussions online and offline on technical details leading now to documents that are quite detailed and well understood technology (with pros and cons as I mentioned). I’m not a great supporter of MRT implementation in my network, because it does not address correctly my use cases but despite of this, I deeply think that it’s another item in the FRR toolchest (like LFA, remote LFA …), it will be up to each Service Provider to choose the appropriate technology based on its own use case/constraints. Processing of MRT , IMHO, should be done as LFA and other similar technologies so standard track sounds good to me.

 

We already seen much less mature technologies going to standard track and being RFC without any running code after …

 

Best Regards,

 

Stephane

 

 

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, November 20, 2014 19:17
To: Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); rtgwg@ietf.org
Subject: Re: maturity of the MRT technology

 

Loa,

 

Without any hats on, I would note:

 

a) As far as I'm aware, this has seen two independent prototypes implemented.

b) I have not heard any concrete technical concerns.  Stewart and I did specificallly

discuss MRT this past IETF.  I am, of course, quite interested in hearing any

concrete technical concerns.

 

c) I'd be happy seeing this question asked of more drafts :-)

 

Regards,

Alia

 

 

On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson <loa@pi.nu> wrote:

Working Groups,

We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been
posted to the mpls wg mailing list.

In his MPLS-RT review Stewart Bryant says:

"I have concerns about whether or not MRT technology has the  maturity
 expected in the standards track. However that decision needs to be
 taken in RTGWG and MPLS needs to follow their and lead in determining
 the fate and track of this draft. This draft should not be published
 ahead of the drafts that define the technology that it is supporting."

He also says that he see no reason not to go ahead and start the poll to
see if we have consensus to adopt the document as an mpls wg document.

The question Stewart ask is valid, and we'd like input from the rtgwg
and rtgwg chairs (copied on this mail). We will also copy both the
poll for adoption and the wglc to the rtgwg mailing list.

/Loa
mpls wg co-chair
--


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

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

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

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

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------090208080800000303090409-- From nobody Wed Dec 3 00:06: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 210271A00E6; Wed, 3 Dec 2014 00:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7AS0qPpFV9j; Wed, 3 Dec 2014 00:06:19 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB45B1A00DF; Wed, 3 Dec 2014 00:06:18 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-01-547e6847c93e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AE.E3.25146.7486E745; Wed, 3 Dec 2014 02:32:56 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 03:06:16 -0500 From: Uma Chunduri To: "stbryant@cisco.com" , "stephane.litkowski@orange.com" , Alia Atlas , "Loa Andersson" Thread-Topic: maturity of the MRT technology Thread-Index: AQHQA4z1PNuAPA+Nnk6RopB29XnlN5xqKS2AgAD9AACAAFZlEIACxG8AgA+iVYD//6+tUA== Date: Wed, 3 Dec 2014 08:06:16 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F47FA39@eusaamb105.ericsson.se> References: <546BDF65.2030203@pi.nu> <3682_1416561775_546F046F_3682_717_1_9E32478DFA9976438E7A22F69B08FF92177BF0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A60469152008633F44A97E@eusaamb105.ericsson.se> <18727_1416732463_54719F2F_18727_12486_1_9E32478DFA9976438E7A22F69B08FF92178256@OPEXCLILM34.corporate.adroot.infra.ftgroup> <547EBC95.6020608@cisco.com> In-Reply-To: <547EBC95.6020608@cisco.com> 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_1B502206DFA0C544B7A60469152008633F47FA39eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyuXRPiK5HRl2IweRHyhafHl5itnh2fhmj xb+5c5gtvl9awmJxa+lKVosLb34zW5x7OofR4uveh6wOHB5Tfm9k9dg56y67x5IlP5k8Wp6d ZPOYNb2NzePL5c9sAWxRXDYpqTmZZalF+nYJXBknHjxkLVi+hqni6g6xBsbrbUxdjJwcEgIm EnNXfWGFsMUkLtxbz9bFyMUhJHCEUeLKk53MEM4yRonNr1czglSxCehJfJz6kx0kISKwnlFi wf7fLCAOs8AtRokvk+aBVQkLaEscvLgPbK6IgI7Ehbvz2CHsMImFl6aA2SwCKhJHz5wCs3kF fCXedH+E2n2MWWLN9qtsIAlOAU2JtZt2gRUxAh34/dQasMOZBcQlbj2ZD/WEgMSSPeeZIWxR iZeP/0E9pCTx8fd8doj6fInOxR+YIZYJSpyc+YRlAqPoLCSjZiEpm4WkDCKuI7Fg9yc2CFtb YtnC18ww9pkDj5mQxRcwsq9i5CgtTi3LTTcy3MQIjOFjEmyOOxgXfLI8xCjAwajEw2vAUxci xJpYVlyZe4hRmoNFSZxXs3pesJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGGX7tu9MXCLaX JzImBa7vUmV/uS6c9W7gNobVGs5evj6sob7BnVklZ7nCQ9m9uA62q8mvW+SS/m/D3av/OxJY nWp6D7ecSFIzUxKQlFeoePCranKT1rKAm1eU1rb8r71QpCsfdL1ON3HptsIXHN99E6pF33R/ Pj2rfTqD0qRJdxifFp2cKqzEUpyRaKjFXFScCADarqb0wgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EZcnmQaI2rUZMaZ7OKsqxmsnZSg Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "rtgwg@ietf.org" Subject: Re: [mpls] maturity of the MRT technology 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, 03 Dec 2014 08:06:26 -0000 --_000_1B502206DFA0C544B7A60469152008633F47FA39eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stewart, Great thoughts.. Essentially you are saying use X algorithm (LFA/rLFA/MRT/combination-o- th= ese/some-great-alternate-path-hunting-algorithm) to compute alternate paths by a controller for each node and program these fo= r link/node failures as per operator choice. Perhaps it's futuristic but that future may not be that far!! >The classical argument against this is concern with the time to >reinstate the repair topology after a failure, but I am not sure >how significant this is since (a) normally this would be an incremental >change, and (b) given that we would normally be computing this >on some high end platform it could have the results of any single >failure (or restore) pre-computed. Given a typical 1000 node network with bunch of links at each node every to= pology change has to be factored to compute and distribute alternates to al= l the nodes. If we really put the alternate computation off from each node and centraliz= ed at a controller (which is really powerful) we still need to factor the d= istribution (and delays surrounding it) part of computed results for all the nodes This is an interesting thing to model. Else the concern will continue to li= nger given the local computation/protection experience in a non-SDN routing= model. Again, in any case some delay MAY be tolerable as these are alternatives c= omputed for getting ready for next failure any ways. -- Uma C. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Tuesday, December 02, 2014 11:33 PM To: stephane.litkowski@orange.com; Uma Chunduri; Alia Atlas; Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@too= ls.ietf.org; rtgwg@ietf.org Subject: Re: maturity of the MRT technology I have been mulling this over for a while and I am wondering how the current industry debate on SDN vs traditional distributed routing plays into this. You could build a case that whilst there always needs to be a base topology that needs to be calculated using a traditional distributed routing protocol (for absolute resilience and bootstrapping) any domain wide repair topology could be better implemented through SDN since it benefits from a global perspective. That would suggest that whilst we might benefit from standardizing the advertisement of some IPFRR related parameters, and would certainly benefit from standardization of the YANG models needed to control the IPFRR subsystem, the method of calculating the repair topology itself ought to be private to the orchestrator. The classical argument against this is concern with the time to reinstate the repair topology after a failure, but I am not sure how significant this is since (a) normally this would be an incremental change, and (b) given that we would normally be computing this on some high end platform it could have the results of any single failure (or restore) pre-computed. - Stewart On 23/11/2014 08:47, stephane.litkowski@orange.com wrote: HI Uma, > Is this because of domain wide deployment requirements MRT brings-in (as = elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network= ? No, domain-wide deployment is not an issue. The issue I see in MRT (for my = use case) is unoptimality of the FRR path (at least using lowpoint algorith= m). But anyway, as I mentioned, I'm not opposed to make MRT progressing at = all. It's good to have multiple tools. Best Regards, From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, November 21, 2014 20:37 To: LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org Subject: RE: maturity of the MRT technology >I'm not a great supporter of MRT implementation in my network, because it = does not address correctly my use cases but despite of this, Is this because of domain wide deployment requirements MRT brings-in (as el= aborated by Stewart?) or you are ok with LFA/rLFA coverage in the network? > I deeply think that it's another item in the FRR toolchest (like LFA, rem= ote LFA ...), >it will be up to each Service Provider to choose the appropriate technolog= y based on its own use case/constraints. I agree with above. It depends on the particular deployment scenario and a= pplicability for that network. -- Uma C. From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@o= range.com Sent: Friday, November 21, 2014 1:23 AM To: Alia Atlas; Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org Subject: Re: [mpls] maturity of the MRT technology +1 As for all FRR technologies, MRT has pros and cons, and this does not influ= ence the maturity of the technical solutions. We already had multiple discu= ssions online and offline on technical details leading now to documents tha= t are quite detailed and well understood technology (with pros and cons as = I mentioned). I'm not a great supporter of MRT implementation in my network= , because it does not address correctly my use cases but despite of this, I= deeply think that it's another item in the FRR toolchest (like LFA, remote= LFA ...), it will be up to each Service Provider to choose the appropriate= technology based on its own use case/constraints. Processing of MRT , IMHO= , should be done as LFA and other similar technologies so standard track so= unds good to me. We already seen much less mature technologies going to standard track and b= eing RFC without any running code after ... Best Regards, Stephane From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Thursday, November 20, 2014 19:17 To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); rtgw= g@ietf.org Subject: Re: maturity of the MRT technology Loa, Without any hats on, I would note: a) As far as I'm aware, this has seen two independent prototypes implemente= d. b) I have not heard any concrete technical concerns. Stewart and I did spe= cificallly discuss MRT this past IETF. I am, of course, quite interested in hearing a= ny concrete technical concerns. c) I'd be happy seeing this question asked of more drafts :-) Regards, Alia On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson = > wrote: Working Groups, We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been posted to the mpls wg mailing list. In his MPLS-RT review Stewart Bryant says: "I have concerns about whether or not MRT technology has the maturity expected in the standards track. However that decision needs to be taken in RTGWG and MPLS needs to follow their and lead in determining the fate and track of this draft. This draft should not be published ahead of the drafts that define the technology that it is supporting." He also says that he see no reason not to go ahead and start the poll to see if we have consensus to adopt the document as an mpls wg document. The question Stewart ask is valid, and we'd like input from the rtgwg and rtgwg chairs (copied on this mail). We will also copy both the poll for adoption and the wglc to the rtgwg mailing list. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_1B502206DFA0C544B7A60469152008633F47FA39eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stewart,

 <= /p>

Great thoughts..

 <= /p>

Essentially you are sayin= g use X algorithm  (LFA/rLFA/MRT/combination-o- these/some-great-alter= nate-path-hunting-algorithm) to

compute alternate paths b= y a controller  for each node and program these for link/node failures= as per operator choice.

 <= /p>

Perhaps  it’s = futuristic but that future may not be that far!!

 <= /p>

>The classical argument against this is concern w= ith the time to
>reinstate the repair topology after a failure, but I am not sure
>how significant this is since (a) normally this would be an incremental=
>change, and (b) given that we would normally be computing this
>on some high end platform it could have the results of any single
>failure (or restore) pre-computed.

 <= /p>

Given a typical 1000 node= network with bunch of links at each node every topology change has to be f= actored to compute and distribute alternates to all the nodes.

If we really put the alte= rnate computation off from each node and centralized at a controller (which= is really powerful) we still need to factor the distribution (and delays surrounding it) part of

computed results for all = the nodes

 <= /p>

This is an interesting th= ing to model. Else the concern will continue to linger given the local comp= utation/protection experience in a non-SDN routing model.=

Again, in any case some d= elay MAY  be tolerable as these are alternatives computed for getting = ready for next failure any ways.

--

Uma C.<= /p>

 <= /p>

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Tuesday, December 02, 2014 11:33 PM
To: stephane.litkowski@orange.com; Uma Chunduri; Alia Atlas; Loa And= ersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-= mrt@tools.ietf.org; rtgwg@ietf.org
Subject: Re: maturity of the MRT technology

 

I have been mulling this over for a while and I am w= ondering
how the current industry debate on SDN vs traditional distributed
routing plays into this.

You could build a  case that whilst there always needs to be a base topology that needs to be calculated using a traditional distributed
routing protocol (for absolute resilience and bootstrapping) any
domain wide repair topology could be better implemented through
SDN since it benefits from a global perspective.

That would suggest that whilst we might benefit from standardizing
the advertisement of some IPFRR related parameters, and would
certainly benefit from standardization of the YANG models needed
to control the IPFRR subsystem, the method of calculating the
repair topology itself ought to be private to the orchestrator.

The classical argument against this is concern with the time to
reinstate the repair topology after a failure, but I am not sure
how significant this is since (a) normally this would be an incremental
change, and (b) given that we would normally be computing this
on some high end platform it could have the results of any single
failure (or restore) pre-computed.

- Stewart

On 23/11/2014 08:47, steph= ane.litkowski@orange.com wrote:

HI Uma,=

 <= /p>

> Is this because of d= omain wide deployment requirements MRT brings-in (as elaborated by Stewart?= ) or you are ok with LFA/rLFA coverage in the network?

 <= /p>

No, domain-wide deploymen= t is not an issue. The issue I see in MRT (for my use case) is unoptimality= of the FRR path (at least using lowpoint algorithm). But anyway, as I mentioned, I’m not opposed to make MRT progressing at a= ll. It’s good to have multiple tools.

 <= /p>

Best Regards,=

 <= /p>

 <= /p>

From: Uma Chun= duri [mailto:uma.chunduri@eric= sson.com]
Sent: Friday, November 21, 2014 20:37
To: LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org
Subject: RE: maturity of the MRT technology

 

>I’m not a great= supporter of MRT implementation in my network, because it does not address= correctly my use cases but despite of this,

 <= /p>

Is this because of domain= wide deployment requirements MRT brings-in (as elaborated by Stewart?) or = you are ok with LFA/rLFA coverage in the network?

 <= /p>

> I deeply think that = it’s another item in the FRR toolchest (like LFA, remote LFA …)= ,

>it will be up to each= Service Provider to choose the appropriate technology based on its own use= case/constraints.

 <= /p>

I agree with above.  = ;It depends on the particular deployment scenario and applicability for tha= t network.

 <= /p>

--

Uma C.<= /p>

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: Friday, November 21, 2014 1:23 AM
To: Alia Atlas; Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org
Subject: Re: [mpls] maturity of the MRT technology=

 

+1<= /p>

 <= /p>

As for all FRR technologi= es, MRT has pros and cons, and this does not influence the maturity of the = technical solutions. We already had multiple discussions online and offline on technical details leading now to documents that are = quite detailed and well understood technology (with pros and cons as I ment= ioned). I’m not a great supporter of MRT implementation in my network= , because it does not address correctly my use cases but despite of this, I deeply think that it’s another i= tem in the FRR toolchest (like LFA, remote LFA …), it will be up to e= ach Service Provider to choose the appropriate technology based on its own = use case/constraints. Processing of MRT , IMHO, should be done as LFA and other similar technologies so standard track sou= nds good to me.

 <= /p>

We already seen much less= mature technologies going to standard track and being RFC without any runn= ing code after …

 <= /p>

Best Regards,=

 <= /p>

Stephane

 <= /p>

 <= /p>

From: rtgwg [<= a href=3D"mailto:rtgwg-bounces@ietf.org">mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, November 20, 2014 19:17
To: Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); rtgwg@ietf.org
Subject: Re: maturity of the MRT technology

 

Loa,

 

Without any hats on, I would note:

 

a) As far as I'm aware, this has seen two independen= t prototypes implemented.

b) I have not heard any concrete technical concerns.=   Stewart and I did specificallly

discuss MRT this past IETF.  I am, of course, q= uite interested in hearing any

concrete technical concerns.

 

c) I'd be happy seeing this question asked of more d= rafts :-)

 

Regards,

Alia

 

 

On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrote:=

Working Groups,

We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been posted to the mpls wg mailing list.

In his MPLS-RT review Stewart Bryant says:

"I have concerns about whether or not MRT technology has the  mat= urity
 expected in the standards track. However that decision needs to be  taken in RTGWG and MPLS needs to follow their and lead in determining=
 the fate and track of this draft. This draft should not be published<= br>  ahead of the drafts that define the technology that it is supporting.= "

He also says that he see no reason not to go ahead and start the poll to see if we have consensus to adopt the document as an mpls wg document.

The question Stewart ask is valid, and we'd like input from the rtgwg
and rtgwg chairs (copied on this mail). We will also copy both the
poll for adoption and the wglc to the rtgwg mailing list.

/Loa
mpls wg co-chair
--


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

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

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.




_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ie=
tf.org/mailman/listinfo/rtgwg




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_1B502206DFA0C544B7A60469152008633F47FA39eusaamb105erics_-- From nobody Wed Dec 3 06:25: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 EE5121A1B35; Wed, 3 Dec 2014 06:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgCLB7Fcg8XF; Wed, 3 Dec 2014 06:25:35 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::763]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28EBA1A1B2A; Wed, 3 Dec 2014 06:25:35 -0800 (PST) Received: from CO2PR05CA024.namprd05.prod.outlook.com (10.141.241.152) by DM2PR05MB446.namprd05.prod.outlook.com (10.141.104.142) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 3 Dec 2014 14:25:11 +0000 Received: from BL2FFO11FD051.protection.gbl (2a01:111:f400:7c09::131) by CO2PR05CA024.outlook.office365.com (2a01:111:e400:1429::24) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Wed, 3 Dec 2014 14:25:11 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BL2FFO11FD051.mail.protection.outlook.com (10.173.161.213) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Wed, 3 Dec 2014 14:25:11 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 3 Dec 2014 06:24:56 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sB3EOtR80359; Wed, 3 Dec 2014 06:24:55 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201412031424.sB3EOtR80359@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <54478.1417616694.1@juniper.net> Date: Wed, 3 Dec 2014 06:24:55 -0800 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(52314003)(189002)(24454002)(199003)(51704005)(479174003)(120916001)(99396003)(84676001)(23726002)(87936001)(47776003)(20776003)(64706001)(110136001)(46102003)(77096005)(68736005)(21056001)(102836001)(50986999)(77156002)(62966003)(50466002)(6806004)(19580395003)(19580405001)(44976005)(54356999)(97736003)(46406003)(105596002)(95666004)(86362001)(69596002)(97756001)(16796002)(81156004)(31966008)(106466001)(2351001)(107046002)(92566001)(4396001)(92726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB446; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-Forefront-PRVS: 0414DF926F Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=yakov@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CWft-B_FJ1y8TmQ0Q8WNxnnUbPw Cc: "mpls@ietf.org" , "rtgwg@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] maturity of the MRT technology 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, 03 Dec 2014 14:25:37 -0000 Stephane, On 23/11/2014 08:47, stephane.litkowski@orange.com wrote: > Hi Uma, > > >Is this because of domain wide deployment requirements MRT brings-in > (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in > the network? > > No, domain-wide deployment is not an issue. The issue I see in MRT > (for my use case) is unoptimality of the FRR path (at least using > lowpoint algorithm). But anyway, as I mentioned, I'm not opposed to > make MRT progressing at all. It's good to have multiple tools. While MRT may result in "unoptimality of the FRR path", why this unoptimality really matters that much, given that FRR suppose to be used for only a short period of time until IGP convergence? Yakov. From nobody Wed Dec 3 06:48:48 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 D61DF1A1B01; Wed, 3 Dec 2014 06:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyYz4Ur8UFoY; Wed, 3 Dec 2014 06:48:40 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E5D1A1B22; Wed, 3 Dec 2014 06:48:40 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id q200so6932898ykb.35 for ; Wed, 03 Dec 2014 06:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NClGK0epbcUAVdkFN16cuX0d7lU9wNo/enpw9CpOqYE=; b=FnLEmaJE9xfveQkNJwyzzAwZxut/6qrX/V2KH/DFbVY20YhToo2ORMdNPUcrkT6Wb1 dEYU5uJ5PB8/VzTbwSW+PgyYUC0xvs1nY7fz/aPLQIvZz6A7ZZ2tbtXVMElTx7ww6gZC ciNCSfZhEcilmAlr+hrRRWZ1V4nXStreyj+4I/Ql1yHhzLJGP66fZzzEZe3NQQCPXoVI sorBOhkmBz1uz5i86tCVdbuypy97FxZ8b9dHW01k5SrGfBnJ/4AVoX7TP//L3dHzW5wv vNJSWapInCEzVhQoYB6EGj64X7axuFaQqADfOHA9ikYtjffePuwH1Lxc13qlqhFeaS/z 8zDQ== MIME-Version: 1.0 X-Received: by 10.170.202.196 with SMTP id t187mr7357695yke.36.1417618119424; Wed, 03 Dec 2014 06:48:39 -0800 (PST) Received: by 10.170.172.86 with HTTP; Wed, 3 Dec 2014 06:48:39 -0800 (PST) In-Reply-To: <547EBC95.6020608@cisco.com> References: <546BDF65.2030203@pi.nu> <3682_1416561775_546F046F_3682_717_1_9E32478DFA9976438E7A22F69B08FF92177BF0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A60469152008633F44A97E@eusaamb105.ericsson.se> <18727_1416732463_54719F2F_18727_12486_1_9E32478DFA9976438E7A22F69B08FF92178256@OPEXCLILM34.corporate.adroot.infra.ftgroup> <547EBC95.6020608@cisco.com> Date: Wed, 3 Dec 2014 09:48:39 -0500 Message-ID: From: Alia Atlas To: Stewart Bryant Content-Type: multipart/alternative; boundary=001a1139d06a6f8337050950f03c Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hM-vPEKhMqIpMaMs9_ULrT0Gwtg Cc: "rtgwg@ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] maturity of the MRT technology 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, 03 Dec 2014 14:48:45 -0000 --001a1139d06a6f8337050950f03c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stewart, It's always fun to speculate about what technology the future may hold. Certainly a way to ease deployment of a new technology like MRT could include using a single device to compute and distribute the alternates; partially deployment is also quite reasonable to handle parts of the network topology that don't have full LFA protection. The question of needing to distribute alternates from a centralized locatio= n ties back to how reasonable is the single failure assumption? I haven't seen any recent studies indicating that the mean time between failures has increased. So - there's the question of whether fast-reroute provides enough protection to be worth the added complexity if the protection can't be reapplied within, say, 5 seconds. Regards, Alia On Wed, Dec 3, 2014 at 2:32 AM, Stewart Bryant wrote: > I have been mulling this over for a while and I am wondering > how the current industry debate on SDN vs traditional distributed > routing plays into this. > > You could build a case that whilst there always needs to be a base > topology that needs to be calculated using a traditional distributed > routing protocol (for absolute resilience and bootstrapping) any > domain wide repair topology could be better implemented through > SDN since it benefits from a global perspective. > > That would suggest that whilst we might benefit from standardizing > the advertisement of some IPFRR related parameters, and would > certainly benefit from standardization of the YANG models needed > to control the IPFRR subsystem, the method of calculating the > repair topology itself ought to be private to the orchestrator. > > The classical argument against this is concern with the time to > reinstate the repair topology after a failure, but I am not sure > how significant this is since (a) normally this would be an incremental > change, and (b) given that we would normally be computing this > on some high end platform it could have the results of any single > failure (or restore) pre-computed. > > - Stewart > > > On 23/11/2014 08:47, stephane.litkowski@orange.com wrote: > > HI Uma, > > > > > Is this because of domain wide deployment requirements MRT brings-in > (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the > network? > > > > No, domain-wide deployment is not an issue. The issue I see in MRT (for m= y > use case) is unoptimality of the FRR path (at least using lowpoint > algorithm). But anyway, as I mentioned, I=E2=80=99m not opposed to make M= RT > progressing at all. It=E2=80=99s good to have multiple tools. > > > > Best Regards, > > > > > > *From:* Uma Chunduri [mailto:uma.chunduri@ericsson.com > ] > *Sent:* Friday, November 21, 2014 20:37 > *To:* LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson > *Cc:* mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org > *Subject:* RE: maturity of the MRT technology > > > > >I=E2=80=99m not a great supporter of MRT implementation in my network, b= ecause it > does not address correctly my use cases but despite of this, > > > > Is this because of domain wide deployment requirements MRT brings-in (as > elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the netwo= rk? > > > > > I deeply think that it=E2=80=99s another item in the FRR toolchest (lik= e LFA, > remote LFA =E2=80=A6), > > >it will be up to each Service Provider to choose the appropriate > technology based on its own use case/constraints. > > > > I agree with above. It depends on the particular deployment scenario and > applicability for that network. > > > > -- > > Uma C. > > > > *From:* mpls [mailto:mpls-bounces@ietf.org ] *On > Behalf Of *stephane.litkowski@orange.com > *Sent:* Friday, November 21, 2014 1:23 AM > *To:* Alia Atlas; Loa Andersson > *Cc:* mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org > *Subject:* Re: [mpls] maturity of the MRT technology > > > > +1 > > > > As for all FRR technologies, MRT has pros and cons, and this does not > influence the maturity of the technical solutions. We already had multipl= e > discussions online and offline on technical details leading now to > documents that are quite detailed and well understood technology (with pr= os > and cons as I mentioned). I=E2=80=99m not a great supporter of MRT implem= entation > in my network, because it does not address correctly my use cases but > despite of this, I deeply think that it=E2=80=99s another item in the FRR= toolchest > (like LFA, remote LFA =E2=80=A6), it will be up to each Service Provider = to choose > the appropriate technology based on its own use case/constraints. > Processing of MRT , IMHO, should be done as LFA and other similar > technologies so standard track sounds good to me. > > > > We already seen much less mature technologies going to standard track and > being RFC without any running code after =E2=80=A6 > > > > Best Regards, > > > > Stephane > > > > > > *From:* rtgwg [mailto:rtgwg-bounces@ietf.org ] *O= n > Behalf Of *Alia Atlas > *Sent:* Thursday, November 20, 2014 19:17 > *To:* Loa Andersson > *Cc:* mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-atlas-mpls-ldp-mrt@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); > rtgwg@ietf.org > *Subject:* Re: maturity of the MRT technology > > > > Loa, > > > > Without any hats on, I would note: > > > > a) As far as I'm aware, this has seen two independent prototypes > implemented. > > b) I have not heard any concrete technical concerns. Stewart and I did > specificallly > > discuss MRT this past IETF. I am, of course, quite interested in hearing > any > > concrete technical concerns. > > > > c) I'd be happy seeing this question asked of more drafts :-) > > > > Regards, > > Alia > > > > > > On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson wrote: > > Working Groups, > > We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been > posted to the mpls wg mailing list. > > In his MPLS-RT review Stewart Bryant says: > > "I have concerns about whether or not MRT technology has the maturity > expected in the standards track. However that decision needs to be > taken in RTGWG and MPLS needs to follow their and lead in determining > the fate and track of this draft. This draft should not be published > ahead of the drafts that define the technology that it is supporting." > > He also says that he see no reason not to go ahead and start the poll to > see if we have consensus to adopt the document as an mpls wg document. > > The question Stewart ask is valid, and we'd like input from the rtgwg > and rtgwg chairs (copied on this mail). We will also copy both the > poll for adoption and the wglc to the rtgwg mailing list. > > /Loa > mpls wg co-chair > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > ________________________________________________________________________= _________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > > _______________________________________________ > rtgwg mailing listrtgwg@ietf.orghttps://www.ietf.org/mailman/listinfo/rtg= wg > > > > -- > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > --001a1139d06a6f8337050950f03c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stewart,

It's always fun to specula= te about what technology the future may hold.
Certainly a way to = ease deployment of a new technology like MRT could
include using = a single device to compute and distribute the alternates; partially
deployment is also quite reasonable to handle parts of the network topol= ogy
that don't have full LFA protection.

=
The question of needing to distribute alternates from a centralized lo= cation
ties back to how reasonable is the single failure assumpti= on?=C2=A0 I haven't seen
any recent studies indicating that t= he mean time between failures has increased.
So - there's the= question of whether fast-reroute provides enough protection to
b= e worth the added complexity if the protection can't be reapplied withi= n, say,
5 seconds.

Regards,
Al= ia

On Wed, D= ec 3, 2014 at 2:32 AM, Stewart Bryant <stbryant@cisco.com> = wrote:
=20 =20 =20
I have been mulling this over for a while and I am wondering
how the current industry debate on SDN vs traditional distributed
routing plays into this.

You could build a=C2=A0 case that whilst there always needs to be a base
topology that needs to be calculated using a traditional distributed
routing protocol (for absolute resilience and bootstrapping) any
domain wide repair topology could be better implemented through
SDN since it benefits from a global perspective.

That would suggest that whilst we might benefit from standardizing the advertisement of some IPFRR related parameters, and would
certainly benefit from standardization of the YANG models needed
to control the IPFRR subsystem, the method of calculating the
repair topology itself ought to be private to the orchestrator.

The classical argument against this is concern with the time to
reinstate the repair topology after a failure, but I am not sure
how significant this is since (a) normally this would be an incremental
change, and (b) given that we would normally be computing this
on some high end platform it could have the results of any single
failure (or restore) pre-computed.

- Stewart


On 23/11/2014 08:47, stephane.litkowski@orange.com wrote:
=20 =20 =20

HI Uma,

=C2=A0<= /u>

> Is this because of domain wide deployment requirements MRT brings-in (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network?

=C2=A0<= /u>

No, domain-wide deployment is not an issue. The issue I see in MRT (for my use case) is unoptimality of the FRR path (at least using lowpoint algorithm). But anyway, as I mentioned, I=E2=80=99m not opposed to make MRT progressing at all. It=E2= =80=99s good to have multiple tools.

=C2=A0<= /u>

Best Regards,

=C2=A0<= /u>

=C2=A0<= /u>

From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
Sent: Friday, November 21, 2014 20:37
To: LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org
Subject: RE: maturity of the MRT technology

=C2=A0

>I=E2=80=99m not a great supporter of MRT implementation in my network, because it does not address correctly my use cases but despite of this,

=C2=A0<= /u>

Is this because of domain wide deployment requirements MRT brings-in (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network?

=C2=A0<= /u>

> I deeply think that it=E2=80=99s another item in the FRR toolch= est (like LFA, remote LFA =E2=80=A6),

>it will be up to each Service Provider to choose the appropriate technology based on its own use case/constraints.

=C2=A0<= /u>

I agree with above.=C2=A0 It depends on the particular deployment scenario and applicability for that network.

=C2=A0<= /u>

--

Uma C.

=C2=A0<= /u>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Friday, November 21, 2014 1:23 AM
To: Alia Atlas; Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org
Subject: Re: [mpls] maturity of the MRT technology

=C2=A0

+1<= /span>

=C2=A0<= /u>

As for all FRR technologies, MRT has pros and cons, and this does not influence the maturity of the technical solutions. We already had multiple discussions online and offline on technical details leading now to documents that are quite detailed and well understood technology (with pros and cons as I mentioned). I=E2=80=99m not a great supporter of MRT implementation in my network, because it does not address correctly my use cases but despite of this, I deeply think that it=E2=80=99s another item in the FRR toolchest (like LFA, remote LFA =E2=80=A6), it will be up to each Service Provider t= o choose the appropriate technology based on its own use case/constraints. Processing of MRT , IMHO, should be done as LFA and other similar technologies so standard track sounds good to me.

=C2=A0<= /u>

We already seen much less mature technologies going to standard track and being RFC without any running code after =E2=80=A6=

=C2=A0<= /u>

Best Regards,

=C2=A0<= /u>

Stephane

=C2=A0<= /u>

=C2=A0<= /u>

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, November 20, 2014 19:17
To: Loa Andersson
Cc: m= pls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); rtgwg@ietf.org
Subject: Re: maturity of the MRT technology

=C2=A0

Loa,

=C2=A0

Without any hats on, I would note:

=C2=A0

a) As far as I'm aware, this has see= n two independent prototypes implemented.

b) I have not heard any concrete technical concerns.=C2=A0 Stewart and I did specificallly<= /u>

discuss MRT this past IETF.=C2=A0 I am, = of course, quite interested in hearing any

concrete technical concerns.

=C2=A0

c) I'd be happy seeing this question asked of more drafts :-)

=C2=A0

Regards,

Alia

=C2=A0

=C2=A0

On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson <= loa@pi.nu> wrote:

Working Groups,

We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been
posted to the mpls wg mailing list.

In his MPLS-RT review Stewart Bryant says:

"I have concerns about whether or not MRT technology has the=C2=A0 maturity
=C2=A0expected in the standards track. However that decision needs to be
=C2=A0taken in RTGWG and MPLS needs to follow their and lead = in determining
=C2=A0the fate and track of this draft. This draft should not be published
=C2=A0ahead of the drafts that define the technology that it = is supporting."

He also says that he see no reason not to go ahead and start the poll to
see if we have consensus to adopt the document as an mpls wg document.

The question Stewart ask is valid, and we'd like input from the rtgwg
and rtgwg chairs (copied on this mail). We will also copy both the
poll for adoption and the wglc to the rtgwg mailing list.

/Loa
mpls wg co-chair
--


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

_______________________________________________
rtgwg mailing list
r= tgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg=

=C2=A0

______________________________________________________________=
___________________________________________________________
        
=C2=A0

        
Ce message et ses pieces jointes peuvent contenir des informat=
ions confidentielles ou privilegiees et ne doivent donc

        
pas etre diffuses, exploites ou copies sans autorisation. Si v=
ous avez recu ce message par erreur, veuillez le signaler
        
a l'expediteur et le detruire ainsi que les pieces jointes=
. Les messages electroniques etant susceptibles d'alteration,=


        
Orange decline toute responsabilite si ce message a ete altere=
, deforme ou falsifie. Merci.

        
=C2=A0

        
This message and its attachments may contain confidential or p=
rivileged information that may be protected by law;

        
they should not be distributed, used or copied without authori=
sation.

        
If you have received this email in error, please notify the se=
nder and delete this message and its attachments.

        
As emails may be altered, Orange is not liable for messages th=
at have been modified, changed or falsified.

        
Thank you.

      
________________________________________________________________=
_________________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.



_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/rtgwg



--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/c=
ri/index.html

--001a1139d06a6f8337050950f03c-- From nobody Wed Dec 3 08:25: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 A3AA11A89A7; Wed, 3 Dec 2014 08:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFwq6Jm9vsA7; Wed, 3 Dec 2014 08:25:24 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923A81A87D0; Wed, 3 Dec 2014 08:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45173; q=dns/txt; s=iport; t=1417623801; x=1418833401; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=mcFhFfsgNb24TRh/uSolTjREHp54DOjWweGyjXbCs0o=; b=hHHf2RTIqj70ym2gzAdULEpwPeIecKYSjNFS/Fjw9ZYmTRGOHFNlpk2p YmI8bJ0EgsY+KulLzkknKzq4IiBsyJUhaskzIdfC4dZxHb9hYpZcVGpBu 9EyFifNP5SxLj3xJ4iW5T3Xpzo4mh3eFbo1RKUczspe0HcsVqnlqbwnet M=; X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208,217";a="259276322" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Dec 2014 16:23:17 +0000 Received: from [64.103.108.91] (dhcp-bdlk10-data-vlan301-64-103-108-91.cisco.com [64.103.108.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB3GNGwt018764; Wed, 3 Dec 2014 16:23:16 GMT Message-ID: <547F38F4.3030908@cisco.com> Date: Wed, 03 Dec 2014 16:23:16 +0000 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: Alia Atlas References: <546BDF65.2030203@pi.nu> <3682_1416561775_546F046F_3682_717_1_9E32478DFA9976438E7A22F69B08FF92177BF0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A60469152008633F44A97E@eusaamb105.ericsson.se> <18727_1416732463_54719F2F_18727_12486_1_9E32478DFA9976438E7A22F69B08FF92178256@OPEXCLILM34.corporate.adroot.infra.ftgroup> <547EBC95.6020608@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040601010802080000030908" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kIewOXiYB1HsBjmNqBB4qtaRI2M Cc: "rtgwg@ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] maturity of the MRT technology 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: Wed, 03 Dec 2014 16:25:32 -0000 This is a multi-part message in MIME format. --------------040601010802080000030908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/12/2014 14:48, Alia Atlas wrote: > Stewart, > > It's always fun to speculate about what technology the future may hold. Well SDN is more current design phase than future, although it could be redesign of old technology since this is the way that transport networks have always worked. > Certainly a way to ease deployment of a new technology like MRT could > include using a single device to compute and distribute the > alternates; partially > deployment is also quite reasonable to handle parts of the network > topology > that don't have full LFA protection. Of course this does not just apply to MRT, it applies to any/all of the algorithms. > > The question of needing to distribute alternates from a centralized > location > ties back to how reasonable is the single failure assumption? Are you talking about failure of the SDN controller or the need to deal with multiple concurrent network failures? SDN controller reliability is a subject in itself, which I assume to be getting focus by the SDN teams. > I haven't seen > any recent studies indicating that the mean time between failures has > increased. > So - there's the question of whether fast-reroute provides enough > protection to > be worth the added complexity if the protection can't be reapplied > within, say, > 5 seconds. How realistic is that requirement? My understanding is that MRFB in the types of networks that need IPFRR is weeks rather than seconds, and large parts of the network are disjoint WRT to repair strategy, so the first priority is to remove any repairs that would loop as a result of invocation of a repair in the presence of a missing link, second is to replace those repairs and third is to re-optimize the repairs, but I would be surprised if that needed to be completed in seconds. We have an existence proof for some of the above in transport networks which can't react in that sort of time and rely use an SDN approach. - Stewart > > Regards, > Alia > > On Wed, Dec 3, 2014 at 2:32 AM, Stewart Bryant > wrote: > > I have been mulling this over for a while and I am wondering > how the current industry debate on SDN vs traditional distributed > routing plays into this. > > You could build a case that whilst there always needs to be a base > topology that needs to be calculated using a traditional distributed > routing protocol (for absolute resilience and bootstrapping) any > domain wide repair topology could be better implemented through > SDN since it benefits from a global perspective. > > That would suggest that whilst we might benefit from standardizing > the advertisement of some IPFRR related parameters, and would > certainly benefit from standardization of the YANG models needed > to control the IPFRR subsystem, the method of calculating the > repair topology itself ought to be private to the orchestrator. > > The classical argument against this is concern with the time to > reinstate the repair topology after a failure, but I am not sure > how significant this is since (a) normally this would be an > incremental > change, and (b) given that we would normally be computing this > on some high end platform it could have the results of any single > failure (or restore) pre-computed. > > - Stewart > > > On 23/11/2014 08:47, stephane.litkowski@orange.com > wrote: >> >> HI Uma, >> >> >Is this because of domain wide deployment requirements MRT >> brings-in (as elaborated by Stewart?) or you are ok with LFA/rLFA >> coverage in the network? >> >> No, domain-wide deployment is not an issue. The issue I see in >> MRT (for my use case) is unoptimality of the FRR path (at least >> using lowpoint algorithm). But anyway, as I mentioned, I’m not >> opposed to make MRT progressing at all. It’s good to have >> multiple tools. >> >> Best Regards, >> >> *From:*Uma Chunduri [mailto:uma.chunduri@ericsson.com] >> *Sent:* Friday, November 21, 2014 20:37 >> *To:* LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson >> *Cc:* mpls@ietf.org ; >> mpls-chairs@tools.ietf.org ; >> draft-atlas-mpls-ldp-mrt@tools.ietf.org >> ; rtgwg@ietf.org >> >> *Subject:* RE: maturity of the MRT technology >> >> >I’m not a great supporter of MRT implementation in my network, >> because it does not address correctly my use cases but despite of >> this, >> >> Is this because of domain wide deployment requirements MRT >> brings-in (as elaborated by Stewart?) or you are ok with LFA/rLFA >> coverage in the network? >> >> > I deeply think that it’s another item in the FRR toolchest (like >> LFA, remote LFA …), >> >> >it will be up to each Service Provider to choose the appropriate >> technology based on its own use case/constraints. >> >> I agree with above. It depends on the particular deployment >> scenario and applicability for that network. >> >> -- >> >> Uma C. >> >> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of >> *stephane.litkowski@orange.com >> *Sent:* Friday, November 21, 2014 1:23 AM >> *To:* Alia Atlas; Loa Andersson >> *Cc:* mpls@ietf.org ; >> mpls-chairs@tools.ietf.org ; >> draft-atlas-mpls-ldp-mrt@tools.ietf.org >> ; rtgwg@ietf.org >> >> *Subject:* Re: [mpls] maturity of the MRT technology >> >> +1 >> >> As for all FRR technologies, MRT has pros and cons, and this does >> not influence the maturity of the technical solutions. We already >> had multiple discussions online and offline on technical details >> leading now to documents that are quite detailed and well >> understood technology (with pros and cons as I mentioned). I’m >> not a great supporter of MRT implementation in my network, >> because it does not address correctly my use cases but despite of >> this, I deeply think that it’s another item in the FRR toolchest >> (like LFA, remote LFA …), it will be up to each Service Provider >> to choose the appropriate technology based on its own use >> case/constraints. Processing of MRT , IMHO, should be done as LFA >> and other similar technologies so standard track sounds good to me. >> >> We already seen much less mature technologies going to standard >> track and being RFC without any running code after … >> >> Best Regards, >> >> Stephane >> >> *From:*rtgwg [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Alia >> Atlas >> *Sent:* Thursday, November 20, 2014 19:17 >> *To:* Loa Andersson >> *Cc:* mpls@ietf.org ; >> mpls-chairs@tools.ietf.org ; >> draft-atlas-mpls-ldp-mrt@tools.ietf.org >> ; VIGOUREUX, >> MARTIN (MARTIN); rtgwg@ietf.org >> *Subject:* Re: maturity of the MRT technology >> >> Loa, >> >> Without any hats on, I would note: >> >> a) As far as I'm aware, this has seen two independent prototypes >> implemented. >> >> b) I have not heard any concrete technical concerns. Stewart and >> I did specificallly >> >> discuss MRT this past IETF. I am, of course, quite interested in >> hearing any >> >> concrete technical concerns. >> >> c) I'd be happy seeing this question asked of more drafts :-) >> >> Regards, >> >> Alia >> >> On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson > > wrote: >> >> Working Groups, >> >> We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews >> has been >> posted to the mpls wg mailing list. >> >> In his MPLS-RT review Stewart Bryant says: >> >> "I have concerns about whether or not MRT technology has the >> maturity >> expected in the standards track. However that decision needs to be >> taken in RTGWG and MPLS needs to follow their and lead in >> determining >> the fate and track of this draft. This draft should not be published >> ahead of the drafts that define the technology that it is >> supporting." >> >> He also says that he see no reason not to go ahead and start the >> poll to >> see if we have consensus to adopt the document as an mpls wg >> document. >> >> The question Stewart ask is valid, and we'd like input from the rtgwg >> and rtgwg chairs (copied on this mail). We will also copy both the >> poll for adoption and the wglc to the rtgwg mailing list. >> >> /Loa >> mpls wg co-chair >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------040601010802080000030908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 03/12/2014 14:48, Alia Atlas wrote:
Stewart,

It's always fun to speculate about what technology the future may hold.
Well SDN is more current design phase than future, although it could be
redesign of old technology since this is the way that transport networks
have always worked.

Certainly a way to ease deployment of a new technology like MRT could
include using a single device to compute and distribute the alternates; partially
deployment is also quite reasonable to handle parts of the network topology
that don't have full LFA protection.
Of course this does not just apply to MRT, it applies to any/all of the
algorithms.

The question of needing to distribute alternates from a centralized location
ties back to how reasonable is the single failure assumption? 
Are you talking about failure of the SDN controller or the need to deal with
multiple concurrent network failures? SDN controller reliability is a
subject in itself, which I assume to be getting focus by the SDN teams.
I haven't seen
any recent studies indicating that the mean time between failures has increased.
So - there's the question of whether fast-reroute provides enough protection to
be worth the added complexity if the protection can't be reapplied within, say,
5 seconds.

How realistic is that requirement?

My understanding is that MRFB in the types of networks that need IPFRR is weeks
rather than seconds, and large parts of the network are disjoint WRT to repair
strategy, so the first priority is to remove any repairs that would loop as a result
of invocation of a repair in the presence of a missing link,  second is to
replace those repairs and third is to re-optimize the repairs, but I would be
surprised if that needed to be completed in seconds.

We have an existence proof for some of the above in transport networks which
can't react in that sort of time and rely use an SDN approach.

- Stewart


Regards,
Alia

On Wed, Dec 3, 2014 at 2:32 AM, Stewart Bryant <stbryant@cisco.com> wrote:
I have been mulling this over for a while and I am wondering
how the current industry debate on SDN vs traditional distributed
routing plays into this.

You could build a  case that whilst there always needs to be a base
topology that needs to be calculated using a traditional distributed
routing protocol (for absolute resilience and bootstrapping) any
domain wide repair topology could be better implemented through
SDN since it benefits from a global perspective.

That would suggest that whilst we might benefit from standardizing
the advertisement of some IPFRR related parameters, and would
certainly benefit from standardization of the YANG models needed
to control the IPFRR subsystem, the method of calculating the
repair topology itself ought to be private to the orchestrator.

The classical argument against this is concern with the time to
reinstate the repair topology after a failure, but I am not sure
how significant this is since (a) normally this would be an incremental
change, and (b) given that we would normally be computing this
on some high end platform it could have the results of any single
failure (or restore) pre-computed.

- Stewart


On 23/11/2014 08:47, stephane.litkowski@orange.com wrote:

HI Uma,

 

> Is this because of domain wide deployment requirements MRT brings-in (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network?

 

No, domain-wide deployment is not an issue. The issue I see in MRT (for my use case) is unoptimality of the FRR path (at least using lowpoint algorithm). But anyway, as I mentioned, I’m not opposed to make MRT progressing at all. It’s good to have multiple tools.

 

Best Regards,

 

 

From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
Sent: Friday, November 21, 2014 20:37
To: LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org
Subject: RE: maturity of the MRT technology

 

>I’m not a great supporter of MRT implementation in my network, because it does not address correctly my use cases but despite of this,

 

Is this because of domain wide deployment requirements MRT brings-in (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network?

 

> I deeply think that it’s another item in the FRR toolchest (like LFA, remote LFA …),

>it will be up to each Service Provider to choose the appropriate technology based on its own use case/constraints.

 

I agree with above.  It depends on the particular deployment scenario and applicability for that network.

 

--

Uma C.

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Friday, November 21, 2014 1:23 AM
To: Alia Atlas; Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org
Subject: Re: [mpls] maturity of the MRT technology

 

+1

 

As for all FRR technologies, MRT has pros and cons, and this does not influence the maturity of the technical solutions. We already had multiple discussions online and offline on technical details leading now to documents that are quite detailed and well understood technology (with pros and cons as I mentioned). I’m not a great supporter of MRT implementation in my network, because it does not address correctly my use cases but despite of this, I deeply think that it’s another item in the FRR toolchest (like LFA, remote LFA …), it will be up to each Service Provider to choose the appropriate technology based on its own use case/constraints. Processing of MRT , IMHO, should be done as LFA and other similar technologies so standard track sounds good to me.

 

We already seen much less mature technologies going to standard track and being RFC without any running code after …

 

Best Regards,

 

Stephane

 

 

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, November 20, 2014 19:17
To: Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); rtgwg@ietf.org
Subject: Re: maturity of the MRT technology

 

Loa,

 

Without any hats on, I would note:

 

a) As far as I'm aware, this has seen two independent prototypes implemented.

b) I have not heard any concrete technical concerns.  Stewart and I did specificallly

discuss MRT this past IETF.  I am, of course, quite interested in hearing any

concrete technical concerns.

 

c) I'd be happy seeing this question asked of more drafts :-)

 

Regards,

Alia

 

 

On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson <loa@pi.nu> wrote:

Working Groups,

We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been
posted to the mpls wg mailing list.

In his MPLS-RT review Stewart Bryant says:

"I have concerns about whether or not MRT technology has the  maturity
 expected in the standards track. However that decision needs to be
 taken in RTGWG and MPLS needs to follow their and lead in determining
 the fate and track of this draft. This draft should not be published
 ahead of the drafts that define the technology that it is supporting."

He also says that he see no reason not to go ahead and start the poll to
see if we have consensus to adopt the document as an mpls wg document.

The question Stewart ask is valid, and we'd like input from the rtgwg
and rtgwg chairs (copied on this mail). We will also copy both the
poll for adoption and the wglc to the rtgwg mailing list.

/Loa
mpls wg co-chair
--


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

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

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

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

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html





-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------040601010802080000030908-- From nobody Wed Dec 3 09:40: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 BE05B1A1DBC; Wed, 3 Dec 2014 09:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V4bKHmh2o1L; Wed, 3 Dec 2014 09:40:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D42B21A1BA9; Wed, 3 Dec 2014 09:40:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141203174039.14529.28696.idtracker@ietfa.amsl.com> Date: Wed, 03 Dec 2014 09:40:39 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/N1EcgY73ME_e4S1n4qNDQ-FxV1o Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] Benoit Claise's No Objection on charter-ietf-mpls-06-08: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 17:40:45 -0000 Benoit Claise has entered the following ballot position for charter-ietf-mpls-06-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-mpls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To avoid any potential confusions with LIME, I would prefer: OLD: The working group's responsibilities include procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) including the necessary management objects expressed as YANG models or MIB modules. NEW: The working group's responsibilities include procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), for MPLS packet encapsulation, and for the related Operation, Administration, and Maintenance (OAM) including the necessary management objects expressed as YANG models or MIB modules. One clarifying question (sorry I missed that one during the previous review). I don't understand what the following mean: - Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications. What is an OAM "framework"? An architecture, a new (set of) protocol(s), protocol extensions, something else? From nobody Wed Dec 3 11:59: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 255911A6FF5; Wed, 3 Dec 2014 11:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbHy8A_eMryn; Wed, 3 Dec 2014 11:59:26 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81E31A8998; Wed, 3 Dec 2014 11:59:24 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-68-547f0f6486af Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 23.24.25146.46F0F745; Wed, 3 Dec 2014 14:25:56 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 14:59:23 -0500 From: Uma Chunduri To: "stbryant@cisco.com" Thread-Topic: maturity of the MRT technology Thread-Index: AQHQA4z1PNuAPA+Nnk6RopB29XnlN5xqKS2AgAD9AACAAFZlEIACxG8AgA+iVYCAAHnUgIAAGm8A///hs7A= Date: Wed, 3 Dec 2014 19:59:22 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F48215B@eusaamb105.ericsson.se> References: <546BDF65.2030203@pi.nu> <3682_1416561775_546F046F_3682_717_1_9E32478DFA9976438E7A22F69B08FF92177BF0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A60469152008633F44A97E@eusaamb105.ericsson.se> <18727_1416732463_54719F2F_18727_12486_1_9E32478DFA9976438E7A22F69B08FF92178256@OPEXCLILM34.corporate.adroot.infra.ftgroup> <547EBC95.6020608@cisco.com> <547F38F4.3030908@cisco.com> In-Reply-To: <547F38F4.3030908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F48215Beusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyuXRPoG4Kf32IwcKJuhafHl5itnh2fhmj xb+5c5gtvl9awmJxa+lKVosLb34zW5x7OofR4uveh6wOHB5Tfm9k9dg56y67x5IlP5k8Wp6d ZPOYNb2NzePL5c9sAWxRXDYpqTmZZalF+nYJXBlNLzYxFWwIqng+4StTA2NPQBcjJ4eEgInE v/v3GCFsMYkL99azgdhCAkcYJR4/4uti5AKylzFKrGu4zQSSYBPQk/g49Sc7iC0ioCsxe8MN RpAiZoGzTBINky+CTRIW0JY4eHEfK0SRjsSFu/OgGpIk3t/ZABZnEVCReLzgENg2XgFfiS9P 9jJBbFvDIrFoy3tmkASngKbE2eeLwYoYgc77fmoN2BXMAuISt57MZ4I4W0BiyZ7zzBC2qMTL x/9YIWwliUlLz7FC1OdL/N/0nx1imaDEyZlPWCYwis5CMmoWkrJZSMpmMXIAxTUl1u/ShyhR lJjS/ZAdwtaQaJ0zlx1ZfAEj+ypGjtLi1LLcdCPDTYzA2D0mwea4g3HBJ8tDjAIcjEo8vAY8 dSFCrIllxZW5hxilOViUxHk1q+cFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBco3A75sqt d6f3nAj8nfzHNbuwR/WVq8Akjy2R7yMnpq3ZctFtcnASb2q0DtPUM082RJk0xvQxctXVp3IU Xb4VYlfSWxxu4BQyK31dW0ukzqvdnt0mJ1Vt+nvyEwz//4pnDM0Ty5lbvps/fNl3TiXm17m/ OW7s++75+tE6zocJm6eeX3//wV0lluKMREMt5qLiRAAUKZaivgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0ZXUdrzdxrUPrkT-YvlsxE6wgJI Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "rtgwg@ietf.org" Subject: Re: [mpls] maturity of the MRT technology 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, 03 Dec 2014 19:59:29 -0000 --_000_1B502206DFA0C544B7A60469152008633F48215Beusaamb105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2V0dGluZyBiYWNrIG9uIHlvdXIgb3JpZ2luYWwgcG9zdCwgYWZ0ZXIgYSBiaXQgb2YgbW9yZSB0 aGlua2luZzoNCg0KUGVyaGFwcyBjZW50cmFsaXplZCBvciBkaXN0cmlidXRlZCBjb21wdXRpbmcg b2YgcmVwYWlyIHBhdGggYXBwcm9hY2ggcHJvcy9jb25zIGFyZSBpbnRlcmVzdGluZyB0byBkaXNj dXNzIDsNCg0KPlRoYXQgd291bGQgc3VnZ2VzdCB0aGF0IHdoaWxzdCB3ZSBtaWdodCBiZW5lZml0 IGZyb20gc3RhbmRhcmRpemluZw0KPnRoZSBhZHZlcnRpc2VtZW50IG9mIHNvbWUgSVBGUlIgcmVs YXRlZCBwYXJhbWV0ZXJzLCBhbmQgd291bGQNCj5jZXJ0YWlubHkgYmVuZWZpdCBmcm9tIHN0YW5k YXJkaXphdGlvbiBvZiB0aGUgWUFORyBtb2RlbHMgbmVlZGVkDQo+dG8gY29udHJvbCB0aGUgSVBG UlIgc3Vic3lzdGVtLA0KDQpTdXJlLg0KDQo+dGhlIG1ldGhvZCBvZiBjYWxjdWxhdGluZyB0aGUN Cj5yZXBhaXIgdG9wb2xvZ3kgaXRzZWxmIG91Z2h0IHRvIGJlIHByaXZhdGUgdG8gdGhlIG9yY2hl c3RyYXRvci4NCg0KV2hlbiB3ZSBhZ3JlZSB0byBzdGFuZGFyZGl6ZSB0aGUgSVBGUlIgcmVsYXRl ZCBwYXJhbWV0ZXJzLCBJTU8gaXTigJlzIGltcG9ydGFudCB0byBzdGFuZGFyZGl6ZSB0aGUgcmVs ZXZhbnQgYWxnb3JpdGhtIHRvbyByZWdhcmRsZXNzIG9mIHdoZXJlIGl04oCZcyB1c2VkLg0KDQpJ ZiBpdCBpcyB1c2VkIGluIGEgZGlzdHJpYnV0ZWQgbWFubmVyIHRoaXMgcXVlc3Rpb24gaXMgbGVz cyByZWxldmFudCBhcyBpdOKAmXMgbW9zdGx5ICBtdWx0aS12ZW5kb3IgZGVwbG95bWVudHMuDQoN CkV2ZW4gd2hlbiBhbiBvcmNoZXN0cmF0b3IgaXMgY29tcHV0aW5nIHVzaW5nIGEgcGFydGljdWxh ciBhbGdvcml0aG0gSU1PLCBpdOKAmXMgaW1wb3J0YW50IFZlbmRvciBYIGFuZCBWZW5kb3IgWSBv ZiB0aGUgY29udHJvbGxlciBkbyB0aGUgc2FtZSB0aGluZyBhbmQNCmFsc28gdGhpcyBoYXMgdG8g YmUgKmNsZWFybHkqIHVuZGVyc3Rvb2QgdG8gdmFsaWRhdGUgKHRvIHNlZSB0aGUgY29ybmVyIGNh c2VzIGFyZSB3b3JraW5nIGNvcnJlY3QpICBhbmQgZGVidWcgc3R1ZmYsIG9uY2UgZGVwbG95ZWQu DQoNClByb3ByaWV0YXJ5IHN0dWZmIG1heSBjb21lIHdpdGggdGhlaXIgb3duIGNvc3Qvcmlzay4N Cg0KLS0NClVtYSBDLg0K --_000_1B502206DFA0C544B7A60469152008633F48215Beusaamb105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdl dHRpbmcgYmFjayBvbiB5b3VyIG9yaWdpbmFsIHBvc3QsIGFmdGVyIGEgYml0IG9mIG1vcmUgdGhp bmtpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5QZXJoYXBzIGNlbnRyYWxpemVkIG9yIGRpc3RyaWJ1dGVkIGNvbXB1 dGluZyBvZiByZXBhaXIgcGF0aCBhcHByb2FjaCBwcm9zL2NvbnMgYXJlIGludGVyZXN0aW5nIHRv IGRpc2N1c3MgOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCiZndDtUaGF0IHdvdWxkIHN1Z2dlc3QgdGhhdCB3aGlsc3Qgd2UgbWlnaHQgYmVuZWZpdCBm cm9tIHN0YW5kYXJkaXppbmc8YnI+DQomZ3Q7dGhlIGFkdmVydGlzZW1lbnQgb2Ygc29tZSBJUEZS UiByZWxhdGVkIHBhcmFtZXRlcnMsIGFuZCB3b3VsZDxicj4NCiZndDtjZXJ0YWlubHkgYmVuZWZp dCBmcm9tIHN0YW5kYXJkaXphdGlvbiBvZiB0aGUgWUFORyBtb2RlbHMgbmVlZGVkIDxicj4NCiZn dDt0byBjb250cm9sIHRoZSBJUEZSUiBzdWJzeXN0ZW0sIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3VyZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDt0aGUgbWV0aG9kIG9mIGNhbGN1bGF0aW5nIHRo ZSA8YnI+DQomZ3Q7cmVwYWlyIHRvcG9sb2d5IGl0c2VsZiBvdWdodCB0byBiZSBwcml2YXRlIHRv IHRoZSBvcmNoZXN0cmF0b3IuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+V2hlbiB3ZSBhZ3JlZSB0byBzdGFuZGFyZGl6ZSB0aGUgSVBGUlIgcmVs YXRlZCBwYXJhbWV0ZXJzLCBJTU8gaXTigJlzIGltcG9ydGFudCB0byBzdGFuZGFyZGl6ZSB0aGUg cmVsZXZhbnQgYWxnb3JpdGhtIHRvbyByZWdhcmRsZXNzIG9mIHdoZXJlIGl04oCZcyB1c2VkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SWYgaXQgaXMgdXNlZCBpbiBhIGRpc3RyaWJ1dGVkIG1hbm5lciB0aGlzIHF1ZXN0 aW9uIGlzIGxlc3MgcmVsZXZhbnQgYXMgaXTigJlzIG1vc3RseSAmbmJzcDttdWx0aS12ZW5kb3Ig ZGVwbG95bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVuIHdoZW4gYW4gb3JjaGVzdHJhdG9yIGlzIGNvbXB1 dGluZyB1c2luZyBhIHBhcnRpY3VsYXIgYWxnb3JpdGhtIElNTywgaXTigJlzIGltcG9ydGFudCBW ZW5kb3IgWCBhbmQgVmVuZG9yIFkgb2YgdGhlIGNvbnRyb2xsZXIgZG8gdGhlIHNhbWUgdGhpbmcg YW5kDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YWxzbyB0aGlzIGhhcyB0byBiZSAq PGI+Y2xlYXJseTwvYj4qIHVuZGVyc3Rvb2QgdG8gdmFsaWRhdGUgKHRvIHNlZSB0aGUgY29ybmVy IGNhc2VzIGFyZSB3b3JraW5nIGNvcnJlY3QpICZuYnNwO2FuZCBkZWJ1ZyBzdHVmZiwgb25jZSBk ZXBsb3llZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlByb3ByaWV0YXJ5IHN0dWZmIG1heSBjb21lIHdpdGggdGhlaXIg b3duIGNvc3Qvcmlzay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5VbWEgQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_1B502206DFA0C544B7A60469152008633F48215Beusaamb105erics_-- From nobody Wed Dec 3 13:17: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 EF3951AC3F9 for ; Wed, 3 Dec 2014 13:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 s18it0sJ8UUv for ; Wed, 3 Dec 2014 13:17:46 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 590D21AC409 for ; Wed, 3 Dec 2014 13:17:38 -0800 (PST) Received: (qmail 3813 invoked by uid 0); 3 Dec 2014 21:17:37 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 3 Dec 2014 21:17:37 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id P9Ha1p00u2SSUrH019HdJa; Wed, 03 Dec 2014 14:17:37 -0700 X-Authority-Analysis: v=2.1 cv=Hd2HEE08 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=tmfM0ahnralQQMuNnfcA:9 a=wPNLvfGTeEIA:10 a=k0LuJNu7CxwA:10 a=M72IryqdaUwA:10 a=sIVsILfLpIAA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=lENs+y78F57MXfijZZ17qXCke5kAggQPHq4yrKpRlDk=; b=QD+3l4read7akgdfhtYyj7vUCPMlC8SVx52F5cgeIYq5P9GxtH59fuoDD4zrEHtCtwbyJqoBPPGdGCnRrK4DinA8IC5H8IrvdGx8LL7FIZnVZNj957CkQUOg84Y/N0Sj; Received: from box313.bluehost.com ([69.89.31.113]:34921 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XwHIk-00056a-M5; Wed, 03 Dec 2014 14:17:34 -0700 Message-ID: <547F7E01.8040506@labn.net> Date: Wed, 03 Dec 2014 16:17:53 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CCAMP , mpls@ietf.org References: <20141119202211.5915.48053.idtracker@ietfa.amsl.com> In-Reply-To: <20141119202211.5915.48053.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141119202211.5915.48053.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6nz-o0SqjDwJNqr2MDOZO0pmhYM Subject: [mpls] Fwd: [Teas] New Non-WG Mailing List: Teas -- Traffic Engineering Architecture and Signaling working group discussion list 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, 03 Dec 2014 21:17:47 -0000 FYI - in case you missed it... Lou -------- Original Message -------- Subject: [Teas] New Non-WG Mailing List: Teas -- Traffic Engineering Architecture and Signaling working group discussion list Date: Wed, 19 Nov 2014 12:22:11 -0800 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: lberger@labn.net, teas@ietf.org, db3546@att.com A new IETF non-working group email list has been created. List address: teas@ietf.org Archive: http://www.ietf.org/mail-archive/web/teas/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/teas Purpose: This list is for the discussion of architectures for Traffic Engineered networks and for signaling techniques utilising RSVP-TE. For additional information, please contact the list administrators. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Wed Dec 3 16:49: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 A31CD1A8780; Wed, 3 Dec 2014 16:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt3r7rhqPaMb; Wed, 3 Dec 2014 16:48:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DF01A1A94; Wed, 3 Dec 2014 16:48:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141204004851.14668.24495.idtracker@ietfa.amsl.com> Date: Wed, 03 Dec 2014 16:48:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ucj87UeCyHQvuWacv22fwhwGAIo Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 00:48:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Operations, Administration, and Management (OAM) Identifiers Management Information Base (MIB) Authors : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-mpls-tp-oam-id-mib-06.txt Pages : 27 Date : 2014-12-03 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) and MPLS based Transport Profile (TP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mib-06 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 Dec 3 16:56: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 173351A1BF2 for ; Wed, 3 Dec 2014 16:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmYHuw6Komuk for ; Wed, 3 Dec 2014 16:55:05 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CC21A6EE0 for ; Wed, 3 Dec 2014 16:55:04 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id ge10so13504744lab.31 for ; Wed, 03 Dec 2014 16:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a3kCiXIf8IgpB4lgK63TTaIAFdNFBYNCVxvwy2Q6yAI=; b=ggqUAPsCblCFTKj5c2Akxx/1zbypU0aVr2Oa4uxdDFYN8bj/lclFAivH/ezUuPVCEo AQzPhDTGvY8l9EsrgOfpnM2K1uGie0EKA9vLspl2X4EWTOynh3ud1PoVAWFVPg+O07is O9CNxuOq0hHl5iIwQDpmyvY9kjroHQo2FChiwnJzAwKePql8XBM2YE2V0lYUiWupsGlF TCjmP3Jn1UggNzOThImKlBmA2IKCc9tEQN1nLFD1HiOagf3s1GonNXK28+pcBSjv7MI6 ODV2zogZHOUIe9v9qp4zgJJdJh7TWz251lN0x+hjNhSR3T6sn0CSGHIVwMECU2hMwgJC haAA== MIME-Version: 1.0 X-Received: by 10.112.27.133 with SMTP id t5mr6674691lbg.45.1417654502721; Wed, 03 Dec 2014 16:55:02 -0800 (PST) Received: by 10.25.137.86 with HTTP; Wed, 3 Dec 2014 16:55:02 -0800 (PST) In-Reply-To: References: <53F5CA67.9070500@pi.nu> Date: Wed, 3 Dec 2014 16:55:02 -0800 Message-ID: From: Venkatesan Mahalingam To: Mach Chen Content-Type: multipart/alternative; boundary=001a1133b04a0c8dd20509596962 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/b0NervWLA0pDzxIlq83FrkGUONQ Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [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: Thu, 04 Dec 2014 00:55:09 -0000 --001a1133b04a0c8dd20509596962 Content-Type: text/plain; charset=UTF-8 Mach, We have addressed your comments and uploaded the new version 06. Please review again and provide your feedback. http://tools.ietf.org/id/draft-ietf-mpls-tp-oam-id-mib-06.txt -MPLS OAM MIB Team On Wed, Sep 10, 2014 at 6:55 PM, Mach Chen wrote: > Hi Venkat, > > > > Thanks for considering my comments and your prompt response! > > > > Looking forward to see the updates. > > > > Best regards, > > Mach > > > > *From:* Venkatesan Mahalingam [mailto:venkat.mahalingams@gmail.com] > *Sent:* Thursday, September 11, 2014 9:45 AM > > *To:* Mach Chen > *Cc:* draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara; < > mpls-ads@tools.ietf.org>; mpls@ietf.org > *Subject:* Re: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: > Shepherds for MPLS MIB modules > > > > Mach, > > > > Thanks for the prompt response. Please see inline. > > > > > > -Venkat. > > > > On Wed, Sep 10, 2014 at 6:36 PM, Mach Chen wrote: > > Hi Venkatesan, > > Thanks for your response! > > Please see my replies inline... > > > From: Venkatesan Mahalingam [mailto:venkat.mahalingams@gmail.com] > > Sent: Thursday, September 11, 2014 6:40 AM > > To: Mach Chen > > Cc: draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > mpls-chairs@tools.ietf.org; > > VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara; ; > > mpls@ietf.org > > Subject: Re: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: > Shepherds > > for MPLS MIB modules > > > > > Hi Mach, > > > > Thanks for your thorough review. Please find below our responses > in-lined. > > > > -MPLS OAM MIB team > > > > On Fri, Aug 29, 2014 at 2:18 AM, Mach Chen wrote: > > 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-mib. > > > > I have reviewed version 05 of the draft, here are my comments and some > > questions, please consider. > > > > 1. > > Extract the acronym when first use, for example, LSP in the > Introduction, and it's > > not necessary to extract an acronym when each uses, for example, MPLS in > > section 1 and section 3.2 . > > Thanks, will change it in the next version. > > > > 2. > > In RFC6370, it defines MPLS-TP point-to-point Tunnels identifiers, > MPLS-TP > > co-routed and associated bidirectional MPLS LSPs identifiers, MPLS-TP > > Pseudowires Identifiers and Section Identifiers. And in Section 5 of > RFC6370, > > there 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 > alternatively use > > tunnel and LSP, but it's better to use the term in an accurate way hence > to reduce > > the confusion. > > Yes, will state that explicitly in the next version. > > > > In addition, based on the mplsOamIdMegServicePointerType (only lsp, pw > and > > section listed), it implies that the MPLS-TP point-to-point Tunnels > identifiers 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 clearly. > > mplsOamIdMegServicePointerType object is defined generically to handle > any > > kind of service pointer (Tunnel, LSP, PW) these service pointers can be > used for > > MPLS/MPLS-TP path. > > Here, I am not prefer to the difference between MPLS and MPLS-TP. > > Of cause, if the intention is to apply this MIB to both MPLS and MPLS-TP > path, it's better to add some text to explicitly state this (e.g., in the > Abstract and/or Introduction section). > > Actually, the above question related to the definition of > mplsOamIdMegServicePointerType, it's defined as below: > mplsOamIdMegServicePointerType OBJECT-TYPE > SYNTAX INTEGER { > lsp (1), > pseudowire (2), > section (3) > } > Here, only lsp, pw and section listed, based on the fact that Tunnel is > not the same thing as LSP. If MPLS Tunnel is included, then there may need > the fourth item: tunnel (4), right? > > Got it. Yes, Thanks. > > > > > > 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. > > " > > As mentioned above. we dont need to change the text (MPLS to MPLS-TP), > will > > enhance the existing text to make the intention of this MIB clear. > > OK, I am fine with the idea to make this MIB generally apply to MPLS and > MPLS-TP, but as said above, some intention text may needed. > > In addition, when you begin to enhance the text, please consider which > paths(e.g., Tunnel, LSP, PW and Section) you intend to include and make all > relevant text consistent. > > Sure. will update in the next version. > > > > > > 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 > > Pseudowires. > > > > 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 > > bidirectional LSP are illustrated here Same as above. > > OK, same as above, the difference between Tunnel and LSP. > > ACK. > > > > > > 3. > > > > For mplsOamIdMeTable, since this is the identifier MIB, why do we needthe > > following items? > > mplsOamIdMeProactiveOamPhbTCValue = 0, > > mplsOamIdMeOnDemandOamPhbTCValue = 0, > > > > It seems that they should not belong to this MIB, maybe better in other > MIB. > > PHB TC values are defined in this MIB to basically use these values in > > Proactive(BFD)/OnDemand(LSP Ping) sessions. > > I know they are useful, I am just not sure whether they should belong to > this MIB, since this MIB is just an OAM identifier MIB. > > Will discuss internally and decide on this. > > > > > 4. > > > > mplsOamIdMegPathFlow OBJECT-TYPE > > SYNTAX INTEGER { > > unidirectionalPointToPoint (1), > > coRoutedBidirectionalPointToPoint (2), > > associatedBidirectionalPointToPoint (3), > > unidirectionalPointToMultiPoint (4) > > > > Seems RFC6370 does not define how to identify a > > unidirectionalPointToMultiPoint path, and from the Introduction of this > > document, the P2MP seems not be included. > > > > We will add more information for P2MP in the next version after the > internal > > discussion. > > OK, please do. > > ACK > > > > > 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 is > > down", "ME table is down" and "LSP and PW is down"? > > We defined this object to notify the operational status of MEG, ME, OAM > app > > and the MPLS/MPLS-TP path, will add more information in the next version. > > OK, please do. > > ACK > > > > > 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)? > > Section is not yet taken care in this MIB. Will add missing information > after > > internal discussion. > > OK, please do. > > ACK > > > > > And draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtEntry for MPLS-TP > > tunnels and pwExtEntry for MPLS-TP PWs, should the above mplsTunnelEntry > > and pwEntry be changed to mplsTunnelExtEntry and pwExtEntry? > > No,Tunnel & PW entries are augmented to have the extra fields in the new > tables > > for MPLS-TP. The base table should be sufficient for the MPLS/MPLS-TP > path to > > OAM config association. > > OK. > > ACK > > > > > > 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 > > Tunnels and Pws, should the above mplsTunnelTable be mplsTunnelExtTable > and > > reference be draft-ietf-mpls-tp-te-mib-08? > > No, as stated above, this MIB is mainly defined to provide OAM configs > for MPLS > > & MPLS-TP paths. > > OK. > > ACK > > > Best regards, > Mach > > > > > > 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 > > > Cucchiara; Mach Chen; > > > Subject: Shepherds for MPLS MIB modules > > > > > > 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 > > > --001a1133b04a0c8dd20509596962 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mach,

We have addressed your comments a= nd uploaded the new version 06. Please review again and provide your feedba= ck.


-MPLS OAM MIB Team

On Wed, Sep 10= , 2014 at 6:55 PM, Mach Chen <mach.chen@huawei.com> wrote= :

Hi Venkat,

=C2=A0

Thanks for considering my comments and your prompt response!=

=C2=A0

Looking forward to see the updates.

=C2=A0

Best regards,

Mach

=C2=A0

From: Venkatesan Mahalingam [mailto:venkat.mahalingams@gmail.com]
Sent: Thursday, September 11= , 2014 9:45 AM


To: Mach Chen
Cc: draft-ietf-mpls-t= p-oam-id-mib@tools.ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MA= RTIN); Joan Cucchiara; <mpls-ads@tools.ietf.org>; mpls@ietf.org
Subject: Re: Shepherd review= of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules

=C2=A0=

Mach,<= /p>

=C2=A0=

Thanks for the prompt response. Pl= ease see inline.

=C2=A0=

=C2=A0=

-Venkat.

=C2=A0=

On Wed, Sep 10, 2014 at 6:36 PM, M= ach Chen <mach= .chen@huawei.com> wrote:

Hi Venkatesan,

Thanks for your response!

Please see my replies inline...

> From: Venkatesan Mahalingam [mailto:venkat.mahalingams@gmail.com]
> Sent: Thursday, September 11, 2014 6:40 AM
> To: Mach Chen
> Cc: draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; mpls-chairs= @tools.ietf.org;
> VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara; <mpls-ads@tools.ietf.org>;
> mpls@ietf.org > Subject: Re: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: She= pherds
> for MPLS MIB modules
>

>= ; Hi Mach,
>
> Thanks for your thorough review. Please find below our responses in-li= ned.
>
> -MPLS OAM MIB team
>
> On Fri, Aug 29, 2014 at 2:18 AM, Mach Chen <mach.chen@huawei.com> wrote:
> Hi Authors/Editors,
>
> I am assigned as Shepherd for draft-ietf-mpls-tp-oam-id-mib, the WG ch= airs and
> Shepherd are working on the publication of draft-ietf-mpls-tp-oam-id-m= ib.
>
> I have reviewed version 05 of the draft, here are my comments and some=
> questions, please consider.
>
> 1.
> Extract the acronym when first use, for example, LSP in the Introducti= on, and it's
> not necessary to extract an acronym when each uses, for example, MPLS = in
> section 1 and section 3.2 .
> Thanks, will change it in the next version.
>
> 2.
> In RFC6370, it defines MPLS-TP point-to-point Tunnels identifiers, MPL= S-TP
> co-routed and associated bidirectional MPLS LSPs identifiers, MPLS-TP<= br> > Pseudowires Identifiers and Section Identifiers. And in Section 5 of R= FC6370,
> there are some text that describes the difference between "MPLS t= unnel" and
> "MPLS LSP". In this draft, there are many usages of "tu= nnel" in section 4, 5 and 6,
> and actually it should be "LSP". I know that sometimes peopl= e alternatively use
> tunnel and LSP, but it's better to use the term in an accurate way= hence to reduce
> the confusion.
> Yes, will state that explicitly in the next version.
>
> In addition, based on the mplsOamIdMegServicePointerType (only lsp, pw= and
> section listed), it implies that the MPLS-TP point-to-point Tunnels id= entifiers 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 clearly.
>=C2=A0 mplsOamIdMegServicePointerType object is defined generically to = handle any
> kind of service pointer (Tunnel, LSP, PW) these service pointers can b= e used for
> MPLS/MPLS-TP path.

Her= e, I am not prefer to the difference between MPLS and MPLS-TP.

Of cause, if the intention is to apply this MIB to both MPLS and MPLS-TP pa= th, it's better to add some text to explicitly state this (e.g., in the= Abstract and/or Introduction section).

Actually, the above question related to the definition of mplsOamIdMegServi= cePointerType, it's defined as below:
=C2=A0 =C2=A0 =C2=A0 =C2=A0mplsOamIdMegServicePointerType OBJECT-TYPE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 INTEGE= R {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 lsp (1),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 pseudowire (2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 section (3)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 }
Here, only lsp, pw and section listed, based on the fact that Tunnel is not= the same thing as LSP. If MPLS Tunnel is included, then there may need the= fourth item: tunnel (4), right?

Got it. Yes, Thanks.=


>
> Here are some example that may need updates:
>
> Section 4.
>
> OLD:
> "
> The MIB module supports configuration of OAM identifiers for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point-to-point, co-routed bidirectio= nal, associated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bidirectional MPLS tunnels and MPLS = Pseudowires.
> "
> NEW:
> "
> The MIB module supports configuration of OAM identifiers for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MPLS-TP co-routed bidirectional LSPs= , associated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bidirectional LSPs, Sections and Pse= udowires.
> "
> As mentioned above. we dont need to change the text (MPLS to MPLS-TP),= will
> enhance the existing text to make the intention of this MIB clear.

OK, I am fine with the idea to make this MIB generally apply to MPLS and MP= LS-TP, but as said above, some intention text may needed.

In addition, when you begin to enhance the text, please consider which path= s(e.g., Tunnel, LSP, PW and Section) you intend to include and make all rel= evant text consistent.

Sure. will update in the next vers= ion.=C2=A0


>
> 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 a= nd
> Pseudowires.
>
> Section 6
>
> s/...MPLS co-routed bidirectional tunnel/...MPLS-TP co-routed bidirect= ional LSP
>
> s/...co-routed MPLS tunnel are illustrated here/...MPLS-TP co-routed > bidirectional LSP are illustrated here Same as above.

OK, same as above, the difference between Tunnel and LSP.

ACK.=C2=A0

>
> 3.
>
> For mplsOamIdMeTable, since this is the identifier MIB, why do we need= the
> following items?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 mplsOamIdMeProactiveOamPhbTCValue =3D 0, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 mplsOamIdMeOnDemandOamPhbTCValue=C2=A0 =3D = 0,
>
> It seems that they should not belong to this MIB, maybe better in othe= r MIB.
> PHB TC values are defined in this MIB to basically use these values in=
> Proactive(BFD)/OnDemand(LSP Ping) sessions.

I know they are useful, I am just not sure whether they should belong to th= is MIB, since this MIB is just an OAM identifier MIB.<= /font>

Will discuss internally and decide= on this.=C2=A0

>= ;
> 4.
>
> mplsOamIdMegPathFlow OBJECT-TYPE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2= =A0 INTEGER {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0unidirectionalPointToPoint (1),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0coRoutedBidirectionalPointToPoint (2),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0associatedBidirectionalPointToPoint (3),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0unidirectionalPointToMultiPoint (4)
>
> Seems RFC6370 does not define how to identify a
> unidirectionalPointToMultiPoint path, and from the Introduction of thi= s
> document, the P2MP seems not be included.
>
> We will add more information for P2MP in the next version after the in= ternal
> discussion.

OK, please do.

ACK=C2=A0

>= ;
> 5.
>
> mplsOamIdMegSubOperStatus OBJECT-TYPE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2= =A0BITS {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0megDown (0),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0meDown (1),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0oamAppDown (2),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0pathDown (3)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The bit 0 (megD= own) indicates the MEG is down.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The bit 1 (meDo= wn) indicates the ME table is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 down.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The bit 2 (oamA= ppDown) indicates that the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAM application= has notified that the entity (LSP or PW)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 monitored by th= is MEG is down. Currently, BFD is the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only supported = OAM application.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The bit 3 (path= Down) indicates that the underlying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LSP or PW is do= wn."
>
> I am not sure what's the mean of "down" here, especially= the mean of "MEG is
> down", "ME table is down" and "LSP and PW is down&= quot;?
> We defined this object to notify the operational status of MEG, ME, OA= M app
> and the MPLS/MPLS-TP path, will add more information in the next versi= on.

OK, please do.

ACK=C2=A0

>= ;
> 6.
>
> mplsOamIdMeServicePointer OBJECT-TYPE
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2= =A0 RowPointer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAX-ACCESS=C2=A0 =C2=A0 read-c= reate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STATUS=C2=A0 =C2=A0 =C2=A0 =C2= =A0 current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DESCRIPTION
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"This variable rep= resents a pointer to the MPLS-TP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 transport path. This v= alue MUST point at an entry in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mplsTunnelEntry if mpl= sOamIdMegServicePointerType
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is configured as lsp (= 1) or at an entry in the pwEntry if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mplsOamIdMegServicePoi= nterType is configured
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 as pseudowire (2).
>
> How about mplsOamIdMegServicePointerTypesection is configured as secti= on
> (3)?
> Section is not yet taken care in this MIB. Will add missing informatio= n after
> internal discussion.

OK, please do.

ACK=C2=A0

>= ;
> And draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtEntry for MPLS-T= P
> tunnels and pwExtEntry for MPLS-TP PWs, should the above mplsTunnelEnt= ry
> and pwEntry be changed to mplsTunnelExtEntry and pwExtEntry?
> No,Tunnel & PW entries are augmented to have the extra fields in t= he new tables
> for MPLS-TP. The base table should be sufficient for the MPLS/MPLS-TP = path to
> OAM config association.

OK.

ACK=C2=A0

>
> 7.
> mplsOamIdMegServicePointerType OBJECT-TYPE
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2= =A0 INTEGER {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lsp (1),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pseudowire (2),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0section (3)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAX-ACCESS=C2=A0 =C2=A0 read-c= reate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STATUS=C2=A0 =C2=A0 =C2=A0 =C2= =A0 current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DESCRIPTION
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Indicates the ser= vice type for the MEG.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the service type in= dicates lsp, the service pointer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in mplsOamIdMeTable po= ints to an entry in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the mplsTunnelTable [R= FC3812].
>
> Since draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtTable for MPLS= -TP
> Tunnels and Pws, should the above mplsTunnelTable be mplsTunnelExtTabl= e and
> reference be draft-ietf-mpls-tp-te-mib-08?
> No, as stated above, this MIB is mainly defined to provide OAM configs= for MPLS
> & MPLS-TP paths.

OK.

ACK=C2=A0


Best regards,
Mach

>
> 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
> > Cucchiara; Mach Chen; <mpls-ads@tools.ietf.org>
> > Subject: Shepherds for MPLS MIB modules
> >
> > Working Group,
> >
> > We have for some time been looking for someone to help us shepher= ding
> > our MIB modules. I'm happy to announce that Mach Chen and You= ng Lee
> > has agreed to help us.
> >
> > Please help Mach and Young as they start working with the documen= ts.
> >
> > 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=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
> > Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu Huawei
> > Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

=C2=A0=


--001a1133b04a0c8dd20509596962-- From nobody Wed Dec 3 17:32: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 9E5E31A6FDB for ; Wed, 3 Dec 2014 17:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMOY5ulrOuPG for ; Wed, 3 Dec 2014 17:29:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705561A6FCD for ; Wed, 3 Dec 2014 17:29:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMI57436; Thu, 04 Dec 2014 01:29:56 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Dec 2014 01:29:54 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.51]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Thu, 4 Dec 2014 09:29:51 +0800 From: Mach Chen To: Venkatesan Mahalingam Thread-Topic: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules Thread-Index: AQHQD1z3wcnm9yIkd0OIPsBxZ9FTRZx+pGgg Date: Thu, 4 Dec 2014 01:29:51 +0000 Message-ID: References: <53F5CA67.9070500@pi.nu> 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_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B2E505ESZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ji-_DI-KcTZ7BK0fN37Y6bIsdok Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [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: Thu, 04 Dec 2014 01:30:04 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B2E505ESZXEMA510MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVmVua2F0LA0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGVzLCBJIHdpbGwgcmV2aWV3IGl0IHNv b24uDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KRnJvbTogVmVua2F0ZXNhbiBNYWhhbGluZ2Ft IFttYWlsdG86dmVua2F0Lm1haGFsaW5nYW1zQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBE ZWNlbWJlciAwNCwgMjAxNCA4OjU1IEFNDQpUbzogTWFjaCBDaGVuDQpDYzogZHJhZnQtaWV0Zi1t cGxzLXRwLW9hbS1pZC1taWJAdG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnOyBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKTsgSm9hbiBDdWNjaGlhcmE7IDxtcGxzLWFk c0B0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTaGVwaGVyZCBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWIvL1JFOiBTaGVwaGVyZHMgZm9y IE1QTFMgTUlCIG1vZHVsZXMNCg0KTWFjaCwNCg0KV2UgaGF2ZSBhZGRyZXNzZWQgeW91ciBjb21t ZW50cyBhbmQgdXBsb2FkZWQgdGhlIG5ldyB2ZXJzaW9uIDA2LiBQbGVhc2UgcmV2aWV3IGFnYWlu IGFuZCBwcm92aWRlIHlvdXIgZmVlZGJhY2suDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYi0wNi50eHQNCg0KLU1QTFMgT0FNIE1JQiBUZWFt DQoNCk9uIFdlZCwgU2VwIDEwLCAyMDE0IGF0IDY6NTUgUE0sIE1hY2ggQ2hlbiA8bWFjaC5jaGVu QGh1YXdlaS5jb208bWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBWZW5r YXQsDQoNClRoYW5rcyBmb3IgY29uc2lkZXJpbmcgbXkgY29tbWVudHMgYW5kIHlvdXIgcHJvbXB0 IHJlc3BvbnNlIQ0KDQpMb29raW5nIGZvcndhcmQgdG8gc2VlIHRoZSB1cGRhdGVzLg0KDQpCZXN0 IHJlZ2FyZHMsDQpNYWNoDQoNCkZyb206IFZlbmthdGVzYW4gTWFoYWxpbmdhbSBbbWFpbHRvOnZl bmthdC5tYWhhbGluZ2Ftc0BnbWFpbC5jb208bWFpbHRvOnZlbmthdC5tYWhhbGluZ2Ftc0BnbWFp bC5jb20+XQ0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxMSwgMjAxNCA5OjQ1IEFNDQoNClRv OiBNYWNoIENoZW4NCkNjOiBkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYkB0b29scy5pZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWJAdG9vbHMuaWV0Zi5vcmc+ OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc+OyBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKTsgSm9hbiBDdWNjaGlhcmE7IDxtcGxz LWFkc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc+PjsgbXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBTaGVwaGVyZCBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWIvL1JFOiBTaGVwaGVyZHMgZm9y IE1QTFMgTUlCIG1vZHVsZXMNCg0KTWFjaCwNCg0KVGhhbmtzIGZvciB0aGUgcHJvbXB0IHJlc3Bv bnNlLiBQbGVhc2Ugc2VlIGlubGluZS4NCg0KDQotVmVua2F0Lg0KDQpPbiBXZWQsIFNlcCAxMCwg MjAxNCBhdCA2OjM2IFBNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzpt YWNoLmNoZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgVmVua2F0ZXNhbiwNCg0KVGhhbmtzIGZv ciB5b3VyIHJlc3BvbnNlIQ0KDQpQbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5saW5lLi4uDQoNCj4g RnJvbTogVmVua2F0ZXNhbiBNYWhhbGluZ2FtIFttYWlsdG86dmVua2F0Lm1haGFsaW5nYW1zQGdt YWlsLmNvbTxtYWlsdG86dmVua2F0Lm1haGFsaW5nYW1zQGdtYWlsLmNvbT5dDQo+IFNlbnQ6IFRo dXJzZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMTQgNjo0MCBBTQ0KPiBUbzogTWFjaCBDaGVuDQo+IENj OiBkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYkB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJh ZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWJAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+Ow0KPiBWSUdP VVJFVVgsIE1BUlRJTiAoTUFSVElOKTsgSm9hbiBDdWNjaGlhcmE7IDxtcGxzLWFkc0B0b29scy5p ZXRmLm9yZzxtYWlsdG86bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc+PjsNCj4gbXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFNoZXBoZXJkIHJldmlldyBv ZiBkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYi8vUkU6IFNoZXBoZXJkcw0KPiBmb3IgTVBM UyBNSUIgbW9kdWxlcw0KPg0KPiBIaSBNYWNoLA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgdGhvcm91 Z2ggcmV2aWV3LiBQbGVhc2UgZmluZCBiZWxvdyBvdXIgcmVzcG9uc2VzIGluLWxpbmVkLg0KPg0K PiAtTVBMUyBPQU0gTUlCIHRlYW0NCj4NCj4gT24gRnJpLCBBdWcgMjksIDIwMTQgYXQgMjoxOCBB TSwgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbTxtYWlsdG86bWFjaC5jaGVuQGh1YXdl aS5jb20+PiB3cm90ZToNCj4gSGkgQXV0aG9ycy9FZGl0b3JzLA0KPg0KPiBJIGFtIGFzc2lnbmVk IGFzIFNoZXBoZXJkIGZvciBkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYiwgdGhlIFdHIGNo YWlycyBhbmQNCj4gU2hlcGhlcmQgYXJlIHdvcmtpbmcgb24gdGhlIHB1YmxpY2F0aW9uIG9mIGRy YWZ0LWlldGYtbXBscy10cC1vYW0taWQtbWliLg0KPg0KPiBJIGhhdmUgcmV2aWV3ZWQgdmVyc2lv biAwNSBvZiB0aGUgZHJhZnQsIGhlcmUgYXJlIG15IGNvbW1lbnRzIGFuZCBzb21lDQo+IHF1ZXN0 aW9ucywgcGxlYXNlIGNvbnNpZGVyLg0KPg0KPiAxLg0KPiBFeHRyYWN0IHRoZSBhY3JvbnltIHdo ZW4gZmlyc3QgdXNlLCBmb3IgZXhhbXBsZSwgTFNQIGluIHRoZSBJbnRyb2R1Y3Rpb24sIGFuZCBp dCdzDQo+IG5vdCBuZWNlc3NhcnkgdG8gZXh0cmFjdCBhbiBhY3JvbnltIHdoZW4gZWFjaCB1c2Vz LCBmb3IgZXhhbXBsZSwgTVBMUyBpbg0KPiBzZWN0aW9uIDEgYW5kIHNlY3Rpb24gMy4yIC4NCj4g VGhhbmtzLCB3aWxsIGNoYW5nZSBpdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KPg0KPiAyLg0KPiBJ biBSRkM2MzcwLCBpdCBkZWZpbmVzIE1QTFMtVFAgcG9pbnQtdG8tcG9pbnQgVHVubmVscyBpZGVu dGlmaWVycywgTVBMUy1UUA0KPiBjby1yb3V0ZWQgYW5kIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCBNUExTIExTUHMgaWRlbnRpZmllcnMsIE1QTFMtVFANCj4gUHNldWRvd2lyZXMgSWRlbnRpZmll cnMgYW5kIFNlY3Rpb24gSWRlbnRpZmllcnMuIEFuZCBpbiBTZWN0aW9uIDUgb2YgUkZDNjM3MCwN Cj4gdGhlcmUgYXJlIHNvbWUgdGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuICJNUExTIHR1bm5lbCIgYW5kDQo+ICJNUExTIExTUCIuIEluIHRoaXMgZHJhZnQsIHRoZXJl IGFyZSBtYW55IHVzYWdlcyBvZiAidHVubmVsIiBpbiBzZWN0aW9uIDQsIDUgYW5kIDYsDQo+IGFu ZCBhY3R1YWxseSBpdCBzaG91bGQgYmUgIkxTUCIuIEkga25vdyB0aGF0IHNvbWV0aW1lcyBwZW9w bGUgYWx0ZXJuYXRpdmVseSB1c2UNCj4gdHVubmVsIGFuZCBMU1AsIGJ1dCBpdCdzIGJldHRlciB0 byB1c2UgdGhlIHRlcm0gaW4gYW4gYWNjdXJhdGUgd2F5IGhlbmNlIHRvIHJlZHVjZQ0KPiB0aGUg Y29uZnVzaW9uLg0KPiBZZXMsIHdpbGwgc3RhdGUgdGhhdCBleHBsaWNpdGx5IGluIHRoZSBuZXh0 IHZlcnNpb24uDQo+DQo+IEluIGFkZGl0aW9uLCBiYXNlZCBvbiB0aGUgbXBsc09hbUlkTWVnU2Vy dmljZVBvaW50ZXJUeXBlIChvbmx5IGxzcCwgcHcgYW5kDQo+IHNlY3Rpb24gbGlzdGVkKSwgaXQg aW1wbGllcyB0aGF0IHRoZSBNUExTLVRQIHBvaW50LXRvLXBvaW50IFR1bm5lbHMgaWRlbnRpZmll cnMgYXJlDQo+IGFjdHVhbGx5IHByZWNsdWRlZCBpbiB0aGlzIGRvY3VtZW50LiBJcyBteSB1bmRl cnN0YW5kaW5nIHJpZ2h0PyBJZiBzbywgaXQgbmVlZHMNCj4gbG9vayB0aHJvdWdoIHRoZSBkb2N1 bWVudCBhbmQgcmVmaW5lIHRoZSB0ZXh0IHRvIHN0YXRlIGl0IGNsZWFybHkuDQo+ICBtcGxzT2Ft SWRNZWdTZXJ2aWNlUG9pbnRlclR5cGUgb2JqZWN0IGlzIGRlZmluZWQgZ2VuZXJpY2FsbHkgdG8g aGFuZGxlIGFueQ0KPiBraW5kIG9mIHNlcnZpY2UgcG9pbnRlciAoVHVubmVsLCBMU1AsIFBXKSB0 aGVzZSBzZXJ2aWNlIHBvaW50ZXJzIGNhbiBiZSB1c2VkIGZvcg0KPiBNUExTL01QTFMtVFAgcGF0 aC4NCkhlcmUsIEkgYW0gbm90IHByZWZlciB0byB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIE1QTFMg YW5kIE1QTFMtVFAuDQoNCk9mIGNhdXNlLCBpZiB0aGUgaW50ZW50aW9uIGlzIHRvIGFwcGx5IHRo aXMgTUlCIHRvIGJvdGggTVBMUyBhbmQgTVBMUy1UUCBwYXRoLCBpdCdzIGJldHRlciB0byBhZGQg c29tZSB0ZXh0IHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhpcyAoZS5nLiwgaW4gdGhlIEFic3RyYWN0 IGFuZC9vciBJbnRyb2R1Y3Rpb24gc2VjdGlvbikuDQoNCkFjdHVhbGx5LCB0aGUgYWJvdmUgcXVl c3Rpb24gcmVsYXRlZCB0byB0aGUgZGVmaW5pdGlvbiBvZiBtcGxzT2FtSWRNZWdTZXJ2aWNlUG9p bnRlclR5cGUsIGl0J3MgZGVmaW5lZCBhcyBiZWxvdzoNCiAgICAgICBtcGxzT2FtSWRNZWdTZXJ2 aWNlUG9pbnRlclR5cGUgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgICAgIElOVEVH RVIgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxzcCAoMSksDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgcHNldWRvd2lyZSAoMiksDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgc2VjdGlvbiAoMykNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCkhlcmUsIG9ubHkgbHNw LCBwdyBhbmQgc2VjdGlvbiBsaXN0ZWQsIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgVHVubmVsIGlz IG5vdCB0aGUgc2FtZSB0aGluZyBhcyBMU1AuIElmIE1QTFMgVHVubmVsIGlzIGluY2x1ZGVkLCB0 aGVuIHRoZXJlIG1heSBuZWVkIHRoZSBmb3VydGggaXRlbTogdHVubmVsICg0KSwgcmlnaHQ/DQpH b3QgaXQuIFllcywgVGhhbmtzLg0KDQo+DQo+IEhlcmUgYXJlIHNvbWUgZXhhbXBsZSB0aGF0IG1h eSBuZWVkIHVwZGF0ZXM6DQo+DQo+IFNlY3Rpb24gNC4NCj4NCj4gT0xEOg0KPiAiDQo+IFRoZSBN SUIgbW9kdWxlIHN1cHBvcnRzIGNvbmZpZ3VyYXRpb24gb2YgT0FNIGlkZW50aWZpZXJzIGZvcg0K PiAgICAgICAgICBwb2ludC10by1wb2ludCwgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwsIGFzc29j aWF0ZWQNCj4gICAgICAgICAgYmlkaXJlY3Rpb25hbCBNUExTIHR1bm5lbHMgYW5kIE1QTFMgUHNl dWRvd2lyZXMuDQo+ICINCj4gTkVXOg0KPiAiDQo+IFRoZSBNSUIgbW9kdWxlIHN1cHBvcnRzIGNv bmZpZ3VyYXRpb24gb2YgT0FNIGlkZW50aWZpZXJzIGZvcg0KPiAgICAgICAgICBNUExTLVRQIGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMsIGFzc29jaWF0ZWQNCj4gICAgICAgICAgYmlkaXJl Y3Rpb25hbCBMU1BzLCBTZWN0aW9ucyBhbmQgUHNldWRvd2lyZXMuDQo+ICINCj4gQXMgbWVudGlv bmVkIGFib3ZlLiB3ZSBkb250IG5lZWQgdG8gY2hhbmdlIHRoZSB0ZXh0IChNUExTIHRvIE1QTFMt VFApLCB3aWxsDQo+IGVuaGFuY2UgdGhlIGV4aXN0aW5nIHRleHQgdG8gbWFrZSB0aGUgaW50ZW50 aW9uIG9mIHRoaXMgTUlCIGNsZWFyLg0KDQpPSywgSSBhbSBmaW5lIHdpdGggdGhlIGlkZWEgdG8g bWFrZSB0aGlzIE1JQiBnZW5lcmFsbHkgYXBwbHkgdG8gTVBMUyBhbmQgTVBMUy1UUCwgYnV0IGFz IHNhaWQgYWJvdmUsIHNvbWUgaW50ZW50aW9uIHRleHQgbWF5IG5lZWRlZC4NCg0KSW4gYWRkaXRp b24sIHdoZW4geW91IGJlZ2luIHRvIGVuaGFuY2UgdGhlIHRleHQsIHBsZWFzZSBjb25zaWRlciB3 aGljaCBwYXRocyhlLmcuLCBUdW5uZWwsIExTUCwgUFcgYW5kIFNlY3Rpb24pIHlvdSBpbnRlbmQg dG8gaW5jbHVkZSBhbmQgbWFrZSBhbGwgcmVsZXZhbnQgdGV4dCBjb25zaXN0ZW50Lg0KU3VyZS4g d2lsbCB1cGRhdGUgaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KPg0KPiBTZWN0aW9uIDUuDQo+DQo+ IHMvLi4uY29uZmlndXJhdGlvbnMgZm9yIE1QTFMgVHVubmVscyBhbmQgUHNldWRvd2lyZXMvLi4u Y29uZmlndXJhdGlvbnMgZm9yDQo+IE1QTFMtVFAgTFNQcywgU2VjdGlvbnMgYW5kIFBzZXVkb3dp cmVzDQo+DQo+IFNlY3Rpb24gNS4xDQo+DQo+IHMvLi4uZm9yIE1QTFMgdHVubmVscyBhbmQgcHNl dWRvd2lyZXMuLy4uLmZvciBNUExTLVRQIExTUHMsIFNlY3Rpb25zIGFuZA0KPiBQc2V1ZG93aXJl cy4NCj4NCj4gU2VjdGlvbiA2DQo+DQo+IHMvLi4uTVBMUyBjby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCB0dW5uZWwvLi4uTVBMUy1UUCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1ANCj4NCj4gcy8u Li5jby1yb3V0ZWQgTVBMUyB0dW5uZWwgYXJlIGlsbHVzdHJhdGVkIGhlcmUvLi4uTVBMUy1UUCBj by1yb3V0ZWQNCj4gYmlkaXJlY3Rpb25hbCBMU1AgYXJlIGlsbHVzdHJhdGVkIGhlcmUgU2FtZSBh cyBhYm92ZS4NCg0KT0ssIHNhbWUgYXMgYWJvdmUsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gVHVu bmVsIGFuZCBMU1AuDQpBQ0suDQoNCj4NCj4gMy4NCj4NCj4gRm9yIG1wbHNPYW1JZE1lVGFibGUs IHNpbmNlIHRoaXMgaXMgdGhlIGlkZW50aWZpZXIgTUlCLCB3aHkgZG8gd2UgbmVlZHRoZQ0KPiBm b2xsb3dpbmcgaXRlbXM/DQo+ICAgICAgICBtcGxzT2FtSWRNZVByb2FjdGl2ZU9hbVBoYlRDVmFs dWUgPSAwLA0KPiAgICAgICAgbXBsc09hbUlkTWVPbkRlbWFuZE9hbVBoYlRDVmFsdWUgID0gMCwN Cj4NCj4gSXQgc2VlbXMgdGhhdCB0aGV5IHNob3VsZCBub3QgYmVsb25nIHRvIHRoaXMgTUlCLCBt YXliZSBiZXR0ZXIgaW4gb3RoZXIgTUlCLg0KPiBQSEIgVEMgdmFsdWVzIGFyZSBkZWZpbmVkIGlu IHRoaXMgTUlCIHRvIGJhc2ljYWxseSB1c2UgdGhlc2UgdmFsdWVzIGluDQo+IFByb2FjdGl2ZShC RkQpL09uRGVtYW5kKExTUCBQaW5nKSBzZXNzaW9ucy4NCg0KSSBrbm93IHRoZXkgYXJlIHVzZWZ1 bCwgSSBhbSBqdXN0IG5vdCBzdXJlIHdoZXRoZXIgdGhleSBzaG91bGQgYmVsb25nIHRvIHRoaXMg TUlCLCBzaW5jZSB0aGlzIE1JQiBpcyBqdXN0IGFuIE9BTSBpZGVudGlmaWVyIE1JQi4NCldpbGwg ZGlzY3VzcyBpbnRlcm5hbGx5IGFuZCBkZWNpZGUgb24gdGhpcy4NCj4NCj4gNC4NCj4NCj4gbXBs c09hbUlkTWVnUGF0aEZsb3cgT0JKRUNULVRZUEUNCj4gICAgICAgICAgIFNZTlRBWCAgICAgICAg SU5URUdFUiB7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5pZGlyZWN0aW9uYWxQb2lu dFRvUG9pbnQgKDEpLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvUm91dGVkQmlkaXJl Y3Rpb25hbFBvaW50VG9Qb2ludCAoMiksDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgYXNz b2NpYXRlZEJpZGlyZWN0aW9uYWxQb2ludFRvUG9pbnQgKDMpLA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIHVuaWRpcmVjdGlvbmFsUG9pbnRUb011bHRpUG9pbnQgKDQpDQo+DQo+IFNlZW1z IFJGQzYzNzAgZG9lcyBub3QgZGVmaW5lIGhvdyB0byBpZGVudGlmeSBhDQo+IHVuaWRpcmVjdGlv bmFsUG9pbnRUb011bHRpUG9pbnQgcGF0aCwgYW5kIGZyb20gdGhlIEludHJvZHVjdGlvbiBvZiB0 aGlzDQo+IGRvY3VtZW50LCB0aGUgUDJNUCBzZWVtcyBub3QgYmUgaW5jbHVkZWQuDQo+DQo+IFdl IHdpbGwgYWRkIG1vcmUgaW5mb3JtYXRpb24gZm9yIFAyTVAgaW4gdGhlIG5leHQgdmVyc2lvbiBh ZnRlciB0aGUgaW50ZXJuYWwNCj4gZGlzY3Vzc2lvbi4NCg0KT0ssIHBsZWFzZSBkby4NCkFDSw0K Pg0KPiA1Lg0KPg0KPiBtcGxzT2FtSWRNZWdTdWJPcGVyU3RhdHVzIE9CSkVDVC1UWVBFDQo+ICAg ICAgICAgICBTWU5UQVggICAgICAgQklUUyB7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIG1l Z0Rvd24gKDApLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBtZURvd24gKDEpLA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICBvYW1BcHBEb3duICgyKSwNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgcGF0aERvd24gKDMpDQo+ICAgICAgICAgICAgICAgICAgICAgICAgfQ0KPiAgICAgICAg ICAgICAgICBUaGUgYml0IDAgKG1lZ0Rvd24pIGluZGljYXRlcyB0aGUgTUVHIGlzIGRvd24uDQo+ ICAgICAgICAgICAgICAgIFRoZSBiaXQgMSAobWVEb3duKSBpbmRpY2F0ZXMgdGhlIE1FIHRhYmxl IGlzDQo+ICAgICAgICAgICAgICAgIGRvd24uDQo+ICAgICAgICAgICAgICAgIFRoZSBiaXQgMiAo b2FtQXBwRG93bikgaW5kaWNhdGVzIHRoYXQgdGhlDQo+ICAgICAgICAgICAgICAgIE9BTSBhcHBs aWNhdGlvbiBoYXMgbm90aWZpZWQgdGhhdCB0aGUgZW50aXR5IChMU1Agb3IgUFcpDQo+ICAgICAg ICAgICAgICAgIG1vbml0b3JlZCBieSB0aGlzIE1FRyBpcyBkb3duLiBDdXJyZW50bHksIEJGRCBp cyB0aGUNCj4gICAgICAgICAgICAgICAgb25seSBzdXBwb3J0ZWQgT0FNIGFwcGxpY2F0aW9uLg0K PiAgICAgICAgICAgICAgICBUaGUgYml0IDMgKHBhdGhEb3duKSBpbmRpY2F0ZXMgdGhhdCB0aGUg dW5kZXJseWluZw0KPiAgICAgICAgICAgICAgICBMU1Agb3IgUFcgaXMgZG93bi4iDQo+DQo+IEkg YW0gbm90IHN1cmUgd2hhdCdzIHRoZSBtZWFuIG9mICJkb3duIiBoZXJlLCBlc3BlY2lhbGx5IHRo ZSBtZWFuIG9mICJNRUcgaXMNCj4gZG93biIsICJNRSB0YWJsZSBpcyBkb3duIiBhbmQgIkxTUCBh bmQgUFcgaXMgZG93biI/DQo+IFdlIGRlZmluZWQgdGhpcyBvYmplY3QgdG8gbm90aWZ5IHRoZSBv cGVyYXRpb25hbCBzdGF0dXMgb2YgTUVHLCBNRSwgT0FNIGFwcA0KPiBhbmQgdGhlIE1QTFMvTVBM Uy1UUCBwYXRoLCB3aWxsIGFkZCBtb3JlIGluZm9ybWF0aW9uIGluIHRoZSBuZXh0IHZlcnNpb24u DQoNCk9LLCBwbGVhc2UgZG8uDQpBQ0sNCj4NCj4gNi4NCj4NCj4gbXBsc09hbUlkTWVTZXJ2aWNl UG9pbnRlciBPQkpFQ1QtVFlQRQ0KPg0KPiAgICAgICAgICAgU1lOVEFYICAgICAgICBSb3dQb2lu dGVyDQo+ICAgICAgICAgICBNQVgtQUNDRVNTICAgIHJlYWQtY3JlYXRlDQo+ICAgICAgICAgICBT VEFUVVMgICAgICAgIGN1cnJlbnQNCj4gICAgICAgICAgIERFU0NSSVBUSU9ODQo+ICAgICAgICAg ICAgICJUaGlzIHZhcmlhYmxlIHJlcHJlc2VudHMgYSBwb2ludGVyIHRvIHRoZSBNUExTLVRQDQo+ ICAgICAgICAgICAgICB0cmFuc3BvcnQgcGF0aC4gVGhpcyB2YWx1ZSBNVVNUIHBvaW50IGF0IGFu IGVudHJ5IGluIHRoZQ0KPiAgICAgICAgICAgICAgbXBsc1R1bm5lbEVudHJ5IGlmIG1wbHNPYW1J ZE1lZ1NlcnZpY2VQb2ludGVyVHlwZQ0KPiAgICAgICAgICAgICAgaXMgY29uZmlndXJlZCBhcyBs c3AgKDEpIG9yIGF0IGFuIGVudHJ5IGluIHRoZSBwd0VudHJ5IGlmDQo+ICAgICAgICAgICAgICBt cGxzT2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGUgaXMgY29uZmlndXJlZA0KPiAgICAgICAgICAg ICAgYXMgcHNldWRvd2lyZSAoMikuDQo+DQo+IEhvdyBhYm91dCBtcGxzT2FtSWRNZWdTZXJ2aWNl UG9pbnRlclR5cGVzZWN0aW9uIGlzIGNvbmZpZ3VyZWQgYXMgc2VjdGlvbg0KPiAoMyk/DQo+IFNl Y3Rpb24gaXMgbm90IHlldCB0YWtlbiBjYXJlIGluIHRoaXMgTUlCLiBXaWxsIGFkZCBtaXNzaW5n IGluZm9ybWF0aW9uIGFmdGVyDQo+IGludGVybmFsIGRpc2N1c3Npb24uDQoNCk9LLCBwbGVhc2Ug ZG8uDQpBQ0sNCj4NCj4gQW5kIGRyYWZ0LWlldGYtbXBscy10cC10ZS1taWItMDggZGVmaW5lcyBt cGxzVHVubmVsRXh0RW50cnkgZm9yIE1QTFMtVFANCj4gdHVubmVscyBhbmQgcHdFeHRFbnRyeSBm b3IgTVBMUy1UUCBQV3MsIHNob3VsZCB0aGUgYWJvdmUgbXBsc1R1bm5lbEVudHJ5DQo+IGFuZCBw d0VudHJ5IGJlIGNoYW5nZWQgdG8gbXBsc1R1bm5lbEV4dEVudHJ5IGFuZCBwd0V4dEVudHJ5Pw0K PiBObyxUdW5uZWwgJiBQVyBlbnRyaWVzIGFyZSBhdWdtZW50ZWQgdG8gaGF2ZSB0aGUgZXh0cmEg ZmllbGRzIGluIHRoZSBuZXcgdGFibGVzDQo+IGZvciBNUExTLVRQLiBUaGUgYmFzZSB0YWJsZSBz aG91bGQgYmUgc3VmZmljaWVudCBmb3IgdGhlIE1QTFMvTVBMUy1UUCBwYXRoIHRvDQo+IE9BTSBj b25maWcgYXNzb2NpYXRpb24uDQoNCk9LLg0KQUNLDQoNCj4NCj4gNy4NCj4gbXBsc09hbUlkTWVn U2VydmljZVBvaW50ZXJUeXBlIE9CSkVDVC1UWVBFDQo+DQo+ICAgICAgICAgICBTWU5UQVggICAg ICAgIElOVEVHRVIgew0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbHNwICgxKSwNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBzZXVkb3dpcmUgKDIpLA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc2VjdGlvbiAoMykNCj4gICAgICAgICAgICAgICAgICAgICAgICAg fQ0KPiAgICAgICAgICAgTUFYLUFDQ0VTUyAgICByZWFkLWNyZWF0ZQ0KPiAgICAgICAgICAgU1RB VFVTICAgICAgICBjdXJyZW50DQo+ICAgICAgICAgICBERVNDUklQVElPTg0KPiAgICAgICAgICAg ICAiSW5kaWNhdGVzIHRoZSBzZXJ2aWNlIHR5cGUgZm9yIHRoZSBNRUcuDQo+ICAgICAgICAgICAg ICBJZiB0aGUgc2VydmljZSB0eXBlIGluZGljYXRlcyBsc3AsIHRoZSBzZXJ2aWNlIHBvaW50ZXIN Cj4gICAgICAgICAgICAgIGluIG1wbHNPYW1JZE1lVGFibGUgcG9pbnRzIHRvIGFuIGVudHJ5IGlu DQo+ICAgICAgICAgICAgICB0aGUgbXBsc1R1bm5lbFRhYmxlIFtSRkMzODEyXS4NCj4NCj4gU2lu Y2UgZHJhZnQtaWV0Zi1tcGxzLXRwLXRlLW1pYi0wOCBkZWZpbmVzIG1wbHNUdW5uZWxFeHRUYWJs ZSBmb3IgTVBMUy1UUA0KPiBUdW5uZWxzIGFuZCBQd3MsIHNob3VsZCB0aGUgYWJvdmUgbXBsc1R1 bm5lbFRhYmxlIGJlIG1wbHNUdW5uZWxFeHRUYWJsZSBhbmQNCj4gcmVmZXJlbmNlIGJlIGRyYWZ0 LWlldGYtbXBscy10cC10ZS1taWItMDg/DQo+IE5vLCBhcyBzdGF0ZWQgYWJvdmUsIHRoaXMgTUlC IGlzIG1haW5seSBkZWZpbmVkIHRvIHByb3ZpZGUgT0FNIGNvbmZpZ3MgZm9yIE1QTFMNCj4gJiBN UExTLVRQIHBhdGhzLg0KDQpPSy4NCkFDSw0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCj4NCj4g QmVzdCByZWdhcmRzLA0KPiBNYWNoDQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51PG1haWx0bzpsb2FAcGku bnU+XQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjEsIDIwMTQgNjozMSBQTQ0KPiA+IFRv OiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiA+IENjOiBtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBWSUdP VVJFVVgsIE1BUlRJTiAoTUFSVElOKTsgSm9hbg0KPiA+IEN1Y2NoaWFyYTsgTWFjaCBDaGVuOyA8 bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYWRzQHRvb2xzLmlldGYub3JnPj4N Cj4gPiBTdWJqZWN0OiBTaGVwaGVyZHMgZm9yIE1QTFMgTUlCIG1vZHVsZXMNCj4gPg0KPiA+IFdv cmtpbmcgR3JvdXAsDQo+ID4NCj4gPiBXZSBoYXZlIGZvciBzb21lIHRpbWUgYmVlbiBsb29raW5n IGZvciBzb21lb25lIHRvIGhlbHAgdXMgc2hlcGhlcmRpbmcNCj4gPiBvdXIgTUlCIG1vZHVsZXMu IEknbSBoYXBweSB0byBhbm5vdW5jZSB0aGF0IE1hY2ggQ2hlbiBhbmQgWW91bmcgTGVlDQo+ID4g aGFzIGFncmVlZCB0byBoZWxwIHVzLg0KPiA+DQo+ID4gUGxlYXNlIGhlbHAgTWFjaCBhbmQgWW91 bmcgYXMgdGhleSBzdGFydCB3b3JraW5nIHdpdGggdGhlIGRvY3VtZW50cy4NCj4gPg0KPiA+IFdl J3ZlIGFzc2lnbmVkIE1hY2ggYXMgU2hlcGhlcmQgZm9yIGRyYWZ0LWlldGYtbXBscy10cC1vYW0t aWQtbWliLg0KPiA+DQo+ID4gRnVydGhlciBzaGVwaGVyZCBhc3NpZ25tZW50cyB3aWxsIGJlIGRv bmUgYXMgc29vbiBhcyB0aGUgZGV0YWlscyBhcmUgc29ydGVkDQo+IG91dC4NCj4gPg0KPiA+DQo+ ID4gL0xvYQ0KPiA+IGZvciB0aGUgbXBscyB3ZyBjaGFpcnMNCj4gPiAtLQ0KPiA+DQo+ID4NCj4g PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEu aHVhd2VpLmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPg0KPiA+IFNlbmlvciBNUExT IEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51PG1haWx0bzpsb2FAcGku bnU+IEh1YXdlaQ0KPiA+IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYg NzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2ND4NCg0KDQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B2E505ESZXEMA510MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDAwRkE0LkQ5NEM2NEUwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8bzpUYXJnZXRTY3JlZW5TaXplPjEwMjR4NzY4PC9vOlRhcmdldFNjcmVlblNpemU+DQo8L286 T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMTA8L3c6Wm9vbT4NCjx3OlNw ZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6 VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNj aGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0K PHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFs d2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhl bWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WkgtQ048L3c6TGlkVGhlbWVBc2lhbj4NCjx3Okxp ZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6 Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFw cGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRvbnRWZXJ0QWxp Z25DZWxsV2l0aFNwLz4NCjx3OkRvbnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFibGVzLz4NCjx3 OkRvbnRWZXJ0QWxpZ25JblR4YngvPg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4NCjx3OkNhY2hl ZENvbEJhbGFuY2UvPg0KPHc6VXNlRkVMYXlvdXQvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8dzpC cm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8L3c6QnJvd3NlckxldmVsPg0K PG06bWF0aFByPg0KPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KPG06YnJrQmlu IG06dmFsPSJiZWZvcmUiLz4NCjxtOmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQo8bTpzbWFs bEZyYWMgbTp2YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+ DQo8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpkZWZKYyBtOnZhbD0iY2VudGVyR3JvdXAiLz4N CjxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+ DQo8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwvbTptYXRoUHI+PC93OldvcmREb2N1bWVu dD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50 U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9InRydWUiIERl ZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExh dGVudFN0eWxlQ291bnQ9IjI2NyI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3Jt YXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3Jt YXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2Mg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0i dG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5h bWU9InRvYyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9u dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i U3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9IlN0cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIyMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i RGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBH cmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5n IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBM aXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdo dCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlz dCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBH cmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBH cmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdo dCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g R3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJE YXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hh ZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQg MyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBM aXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xv cmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1w aGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFG b3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHki Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFb ZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJ bXNvLWZvbnQtYWx0OlNpbVN1bjsNCgltc28tZm9udC1jaGFyc2V0OjEzNDsNCgltc28tZ2VuZXJp Yy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250 LXNpZ25hdHVyZTozIDY4MDQ2MDI4OCAyMiAwIDI2MjE0NSAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsN Cgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJ bXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUg MTEwNzMwNTcyNyAwIDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsN Cgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJs ZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA5MjkyOSAxMDczNzg2MTExIDkgMCA0MTUgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1p bHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJl Oi01MjAwODE2NjUgLTEwNzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1z by1mb250LWNoYXJzZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJbXNv LWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjMgNjgwNDYwMjg4IDIy IDAgMjYyMTQ1IDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5 bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hv dzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KcA0KCXttc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OuWui+S9kzt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi 5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6OS4wcHQ7DQoJ Zm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFu LkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5 bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXVuaGlk ZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbm lofmnKw7DQoJbXNvLWFuc2ktZm9udC1zaXplOjkuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZTo5 LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OuWui+S9 kzsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWhhbnNpLWZvbnQtZmFt aWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWZvbnQta2Vy bmluZzowcHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCglt c28tYW5zaS1mb250LXNpemU6MTAuNXB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWhhbnNp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFtZToi IjsNCgltc28tc3BsLWU6eWVzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsNCgltc28taGVh ZGVyLW1hcmdpbjozNi4wcHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzYuMHB0Ow0KCW1zby1wYXBl ci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOuaZrumAmuihqOagvDsN Cgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7 DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFs dDowY20gNS40cHQgMGNtIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowY207DQoJbXNvLXBhcmEt bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglm b250LXNpemU6MTAuNXB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZm9udC1rZXJuaW5nOjEuMHB0O30NCjwvc3R5bGU+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl IiBzdHlsZT0idGFiLWludGVydmFsOjIxLjBwdCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtt c28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNv LWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpDQo8c3BhbiBjbGFzcz0iU3BlbGxFIj5WZW5rYXQ8L3NwYW4+LDxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFt aWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJp ZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRp LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MNCiBmb3IgdGhlIHVwZGF0ZXMsIEkgd2lsbCByZXZpZXcgaXQgc29vbi48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250 LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21z by1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28t YmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QmVzdA0KIHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYWNoPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJU YWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztmb250LXdlaWdo dDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9t YSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiBWZW5rYXRlc2Fu IE1haGFsaW5nYW0gW21haWx0bzp2ZW5rYXQubWFoYWxpbmdhbXNAZ21haWwuY29tXSA8YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBUaHVyc2Rh eSwgRGVjZW1iZXIgMDQsIDIwMTQgODo1NSBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBNYWNoIENoZW48YnI+DQo8Yj48c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+Q2M6PC9zcGFuPjwvYj4gZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1p ZC1taWJAdG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBWSUdPVVJF VVgsIE1BUlRJTiAoTUFSVElOKTsgSm9hbiBDdWNjaGlhcmE7ICZsdDttcGxzLWFkc0B0b29scy5p ZXRmLm9yZyZndDs7IG1wbHNAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogU2hlcGhlcmQgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtbXBscy10cC1vYW0taWQtbWliLy9SRTogU2hlcGhlcmRzIGZvciBNUExTIE1JQiBtb2R1 bGVzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+TWFj aCw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i 5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPldlIGhh dmUgYWRkcmVzc2VkIHlvdXIgY29tbWVudHMgYW5kIHVwbG9hZGVkIHRoZSBuZXcgdmVyc2lvbiAw Ni4gUGxlYXNlIHJldmlldyBhZ2FpbiBhbmQgcHJvdmlkZSB5b3VyIGZlZWRiYWNrLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWu i+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWIt MDYudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1p ZC1taWItMDYudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4tTVBMUyBPQU0gTUlCIFRlYW08bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T24gV2VkLCBTZXAgMTAsIDIwMTQg YXQgNjo1NSBQTSwgTWFjaCBDaGVuICZsdDs8YSBocmVmPSJtYWlsdG86bWFjaC5jaGVuQGh1YXdl aS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWNoLmNoZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGkgVmVua2F0LDwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIGNvbnNpZGVy aW5nIG15IGNvbW1lbnRzIGFuZA0KIHlvdXIgcHJvbXB0IHJlc3BvbnNlITwvc3Bhbj48L2ZvbnQ+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Mb29raW5nIGZvcndhcmQgdG8gc2VlIHRoZSB1cGRhdGVzLjwvc3Bhbj48 L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjwvZm9udD48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYWNoPC9zcGFuPjwv Zm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tb3V0bGluZS1sZXZlbDoxIj4NCjxi Pjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPg0KIFZlbmthdGVzYW4gTWFoYWxpbmdhbSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzp2ZW5rYXQubWFoYWxpbmdhbXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmVua2F0Lm1h aGFsaW5nYW1zQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBUaHVyc2RheSwgU2VwdGVtYmVyIDExLCAyMDE0IDk6 NDUgQU08L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gTWFjaCBD aGVuPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOjwvc3Bhbj48L2I+ IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYkB0b29scy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWJAdG9v bHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj4NCm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsgVklH T1VSRVVYLCBNQVJUSU4gKE1BUlRJTik7IEpvYW4gQ3VjY2hpYXJhOyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1wbHMtYWRzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1hZHNAdG9v bHMuaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogU2hlcGhlcmQgcmV2aWV3IG9mIGRy YWZ0LWlldGYtbXBscy10cC1vYW0taWQtbWliLy9SRTogU2hlcGhlcmRzIGZvciBNUExTIE1JQiBt b2R1bGVzPC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIz IiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+TWFjaCw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9 IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5UaGFua3MgZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuIFBsZWFzZSBzZWUgaW5saW5lLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIz IiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPi1WZW5rYXQuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T24gV2VkLCBTZXAgMTAs IDIwMTQgYXQgNjozNiBQTSwgTWFjaCBDaGVuICZsdDs8YSBocmVmPSJtYWlsdG86bWFjaC5jaGVu QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWNoLmNoZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7 DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhpIFZlbmthdGVzYW4sPGJyPg0KPGJyPg0KVGhhbmtzIGZv ciB5b3VyIHJlc3BvbnNlITxicj4NCjxicj4NClBsZWFzZSBzZWUgbXkgcmVwbGllcyBpbmxpbmUu Li48YnI+DQo8YnI+DQomZ3Q7IEZyb206IFZlbmthdGVzYW4gTWFoYWxpbmdhbSBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzp2ZW5rYXQubWFoYWxpbmdhbXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dmVua2F0Lm1haGFsaW5nYW1zQGdtYWlsLmNvbTwvYT5dPGJyPg0KJmd0OyBTZW50OiBUaHVy c2RheSwgU2VwdGVtYmVyIDExLCAyMDE0IDY6NDAgQU08YnI+DQomZ3Q7IFRvOiBNYWNoIENoZW48 YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1t aWJAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtbXBscy10cC1v YW0taWQtbWliQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptcGxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZzwvYT47PGJyPg0KJmd0OyBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKTsgSm9hbiBDdWNj aGlhcmE7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tcGxzLWFkc0B0b29scy5pZXRmLm9yZzwvYT4mZ3Q7Ozxicj4NCiZndDsgPGEg aHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3Jn PC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFNoZXBoZXJkIHJldmlldyBvZiBkcmFmdC1pZXRm LW1wbHMtdHAtb2FtLWlkLW1pYi8vUkU6IFNoZXBoZXJkczxicj4NCiZndDsgZm9yIE1QTFMgTUlC IG1vZHVsZXM8YnI+DQomZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyBIaSBNYWNoLDxicj4N CiZndDs8YnI+DQomZ3Q7IFRoYW5rcyBmb3IgeW91ciB0aG9yb3VnaCByZXZpZXcuIFBsZWFzZSBm aW5kIGJlbG93IG91ciByZXNwb25zZXMgaW4tbGluZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgLU1Q TFMgT0FNIE1JQiB0ZWFtPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gRnJpLCBBdWcgMjksIDIwMTQg YXQgMjoxOCBBTSwgTWFjaCBDaGVuICZsdDs8YSBocmVmPSJtYWlsdG86bWFjaC5jaGVuQGh1YXdl aS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWNoLmNoZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiZndDsgSGkgQXV0aG9ycy9FZGl0b3JzLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYW0g YXNzaWduZWQgYXMgU2hlcGhlcmQgZm9yIGRyYWZ0LWlldGYtbXBscy10cC1vYW0taWQtbWliLCB0 aGUgV0cgY2hhaXJzIGFuZDxicj4NCiZndDsgU2hlcGhlcmQgYXJlIHdvcmtpbmcgb24gdGhlIHB1 YmxpY2F0aW9uIG9mIGRyYWZ0LWlldGYtbXBscy10cC1vYW0taWQtbWliLjxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgaGF2ZSByZXZpZXdlZCB2ZXJzaW9uIDA1IG9mIHRoZSBkcmFmdCwgaGVyZSBhcmUg bXkgY29tbWVudHMgYW5kIHNvbWU8YnI+DQomZ3Q7IHF1ZXN0aW9ucywgcGxlYXNlIGNvbnNpZGVy Ljxicj4NCiZndDs8YnI+DQomZ3Q7IDEuPGJyPg0KJmd0OyBFeHRyYWN0IHRoZSBhY3JvbnltIHdo ZW4gZmlyc3QgdXNlLCBmb3IgZXhhbXBsZSwgTFNQIGluIHRoZSBJbnRyb2R1Y3Rpb24sIGFuZCBp dCdzPGJyPg0KJmd0OyBub3QgbmVjZXNzYXJ5IHRvIGV4dHJhY3QgYW4gYWNyb255bSB3aGVuIGVh Y2ggdXNlcywgZm9yIGV4YW1wbGUsIE1QTFMgaW48YnI+DQomZ3Q7IHNlY3Rpb24gMSBhbmQgc2Vj dGlvbiAzLjIgLjxicj4NCiZndDsgVGhhbmtzLCB3aWxsIGNoYW5nZSBpdCBpbiB0aGUgbmV4dCB2 ZXJzaW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IDIuPGJyPg0KJmd0OyBJbiBSRkM2MzcwLCBpdCBk ZWZpbmVzIE1QTFMtVFAgcG9pbnQtdG8tcG9pbnQgVHVubmVscyBpZGVudGlmaWVycywgTVBMUy1U UDxicj4NCiZndDsgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTVBMUyBM U1BzIGlkZW50aWZpZXJzLCBNUExTLVRQPGJyPg0KJmd0OyBQc2V1ZG93aXJlcyBJZGVudGlmaWVy cyBhbmQgU2VjdGlvbiBJZGVudGlmaWVycy4gQW5kIGluIFNlY3Rpb24gNSBvZiBSRkM2MzcwLDxi cj4NCiZndDsgdGhlcmUgYXJlIHNvbWUgdGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuICZxdW90O01QTFMgdHVubmVsJnF1b3Q7IGFuZDxicj4NCiZndDsgJnF1b3Q7TVBM UyBMU1AmcXVvdDsuIEluIHRoaXMgZHJhZnQsIHRoZXJlIGFyZSBtYW55IHVzYWdlcyBvZiAmcXVv dDt0dW5uZWwmcXVvdDsgaW4gc2VjdGlvbiA0LCA1IGFuZCA2LDxicj4NCiZndDsgYW5kIGFjdHVh bGx5IGl0IHNob3VsZCBiZSAmcXVvdDtMU1AmcXVvdDsuIEkga25vdyB0aGF0IHNvbWV0aW1lcyBw ZW9wbGUgYWx0ZXJuYXRpdmVseSB1c2U8YnI+DQomZ3Q7IHR1bm5lbCBhbmQgTFNQLCBidXQgaXQn cyBiZXR0ZXIgdG8gdXNlIHRoZSB0ZXJtIGluIGFuIGFjY3VyYXRlIHdheSBoZW5jZSB0byByZWR1 Y2U8YnI+DQomZ3Q7IHRoZSBjb25mdXNpb24uPGJyPg0KJmd0OyBZZXMsIHdpbGwgc3RhdGUgdGhh dCBleHBsaWNpdGx5IGluIHRoZSBuZXh0IHZlcnNpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgSW4g YWRkaXRpb24sIGJhc2VkIG9uIHRoZSBtcGxzT2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGUgKG9u bHkgbHNwLCBwdyBhbmQ8YnI+DQomZ3Q7IHNlY3Rpb24gbGlzdGVkKSwgaXQgaW1wbGllcyB0aGF0 IHRoZSBNUExTLVRQIHBvaW50LXRvLXBvaW50IFR1bm5lbHMgaWRlbnRpZmllcnMgYXJlPGJyPg0K Jmd0OyBhY3R1YWxseSBwcmVjbHVkZWQgaW4gdGhpcyBkb2N1bWVudC4gSXMgbXkgdW5kZXJzdGFu ZGluZyByaWdodD8gSWYgc28sIGl0IG5lZWRzPGJyPg0KJmd0OyBsb29rIHRocm91Z2ggdGhlIGRv Y3VtZW50IGFuZCByZWZpbmUgdGhlIHRleHQgdG8gc3RhdGUgaXQgY2xlYXJseS48YnI+DQomZ3Q7 Jm5ic3A7IG1wbHNPYW1JZE1lZ1NlcnZpY2VQb2ludGVyVHlwZSBvYmplY3QgaXMgZGVmaW5lZCBn ZW5lcmljYWxseSB0byBoYW5kbGUgYW55PGJyPg0KJmd0OyBraW5kIG9mIHNlcnZpY2UgcG9pbnRl ciAoVHVubmVsLCBMU1AsIFBXKSB0aGVzZSBzZXJ2aWNlIHBvaW50ZXJzIGNhbiBiZSB1c2VkIGZv cjxicj4NCiZndDsgTVBMUy9NUExTLVRQIHBhdGguPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMiIGZhY2U9 IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IZXJl LCBJIGFtIG5vdCBwcmVmZXIgdG8gdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBNUExTIGFuZCBNUExT LVRQLjxicj4NCjxicj4NCk9mIGNhdXNlLCBpZiB0aGUgaW50ZW50aW9uIGlzIHRvIGFwcGx5IHRo aXMgTUlCIHRvIGJvdGggTVBMUyBhbmQgTVBMUy1UUCBwYXRoLCBpdCdzIGJldHRlciB0byBhZGQg c29tZSB0ZXh0IHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhpcyAoZS5nLiwgaW4gdGhlIEFic3RyYWN0 IGFuZC9vciBJbnRyb2R1Y3Rpb24gc2VjdGlvbikuPGJyPg0KPGJyPg0KQWN0dWFsbHksIHRoZSBh Ym92ZSBxdWVzdGlvbiByZWxhdGVkIHRvIHRoZSBkZWZpbml0aW9uIG9mIG1wbHNPYW1JZE1lZ1Nl cnZpY2VQb2ludGVyVHlwZSwgaXQncyBkZWZpbmVkIGFzIGJlbG93Ojxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO21wbHNPYW1JZE1lZ1NlcnZpY2VQb2ludGVyVHlwZSBPQkpFQ1QtVFlQ RTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU1lOVEFYJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IElOVEVHRVIgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgbHNwICgxKSw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHBzZXVkb3dpcmUgKDIpLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VjdGlvbiAoMyk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB9PGJyPg0KSGVyZSwgb25seSBsc3AsIHB3IGFuZCBzZWN0aW9uIGxpc3RlZCwgYmFz ZWQgb24gdGhlIGZhY3QgdGhhdCBUdW5uZWwgaXMgbm90IHRoZSBzYW1lIHRoaW5nIGFzIExTUC4g SWYgTVBMUyBUdW5uZWwgaXMgaW5jbHVkZWQsIHRoZW4gdGhlcmUgbWF5IG5lZWQgdGhlIGZvdXJ0 aCBpdGVtOiB0dW5uZWwgKDQpLCByaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2T Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkdvdCBpdC4gWWVz LCBUaGFua3MuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YnI+DQomZ3Q7PGJyPg0KJmd0OyBIZXJlIGFyZSBzb21l IGV4YW1wbGUgdGhhdCBtYXkgbmVlZCB1cGRhdGVzOjxicj4NCiZndDs8YnI+DQomZ3Q7IFNlY3Rp b24gNC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPTEQ6PGJyPg0KJmd0OyAmcXVvdDs8YnI+DQomZ3Q7 IFRoZSBNSUIgbW9kdWxlIHN1cHBvcnRzIGNvbmZpZ3VyYXRpb24gb2YgT0FNIGlkZW50aWZpZXJz IGZvcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBvaW50LXRv LXBvaW50LCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCwgYXNzb2NpYXRlZDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJpZGlyZWN0aW9uYWwgTVBMUyB0dW5uZWxz IGFuZCBNUExTIFBzZXVkb3dpcmVzLjxicj4NCiZndDsgJnF1b3Q7PGJyPg0KJmd0OyBORVc6PGJy Pg0KJmd0OyAmcXVvdDs8YnI+DQomZ3Q7IFRoZSBNSUIgbW9kdWxlIHN1cHBvcnRzIGNvbmZpZ3Vy YXRpb24gb2YgT0FNIGlkZW50aWZpZXJzIGZvcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IE1QTFMtVFAgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcywgYXNz b2NpYXRlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJpZGly ZWN0aW9uYWwgTFNQcywgU2VjdGlvbnMgYW5kIFBzZXVkb3dpcmVzLjxicj4NCiZndDsgJnF1b3Q7 PGJyPg0KJmd0OyBBcyBtZW50aW9uZWQgYWJvdmUuIHdlIGRvbnQgbmVlZCB0byBjaGFuZ2UgdGhl IHRleHQgKE1QTFMgdG8gTVBMUy1UUCksIHdpbGw8YnI+DQomZ3Q7IGVuaGFuY2UgdGhlIGV4aXN0 aW5nIHRleHQgdG8gbWFrZSB0aGUgaW50ZW50aW9uIG9mIHRoaXMgTUlCIGNsZWFyLjxicj4NCjxi cj4NCk9LLCBJIGFtIGZpbmUgd2l0aCB0aGUgaWRlYSB0byBtYWtlIHRoaXMgTUlCIGdlbmVyYWxs eSBhcHBseSB0byBNUExTIGFuZCBNUExTLVRQLCBidXQgYXMgc2FpZCBhYm92ZSwgc29tZSBpbnRl bnRpb24gdGV4dCBtYXkgbmVlZGVkLjxicj4NCjxicj4NCkluIGFkZGl0aW9uLCB3aGVuIHlvdSBi ZWdpbiB0byBlbmhhbmNlIHRoZSB0ZXh0LCBwbGVhc2UgY29uc2lkZXIgd2hpY2ggcGF0aHMoZS5n LiwgVHVubmVsLCBMU1AsIFBXIGFuZCBTZWN0aW9uKSB5b3UgaW50ZW5kIHRvIGluY2x1ZGUgYW5k IG1ha2UgYWxsIHJlbGV2YW50IHRleHQgY29uc2lzdGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPlN1cmUuIHdpbGwgdXBkYXRlIGluIHRoZSBuZXh0IHZlcnNpb24uJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZWN0aW9uIDUuPGJyPg0KJmd0Ozxi cj4NCiZndDsgcy8uLi5jb25maWd1cmF0aW9ucyBmb3IgTVBMUyBUdW5uZWxzIGFuZCBQc2V1ZG93 aXJlcy8uLi5jb25maWd1cmF0aW9ucyBmb3I8YnI+DQomZ3Q7IE1QTFMtVFAgTFNQcywgU2VjdGlv bnMgYW5kIFBzZXVkb3dpcmVzPGJyPg0KJmd0Ozxicj4NCiZndDsgU2VjdGlvbiA1LjE8YnI+DQom Z3Q7PGJyPg0KJmd0OyBzLy4uLmZvciBNUExTIHR1bm5lbHMgYW5kIHBzZXVkb3dpcmVzLi8uLi5m b3IgTVBMUy1UUCBMU1BzLCBTZWN0aW9ucyBhbmQ8YnI+DQomZ3Q7IFBzZXVkb3dpcmVzLjxicj4N CiZndDs8YnI+DQomZ3Q7IFNlY3Rpb24gNjxicj4NCiZndDs8YnI+DQomZ3Q7IHMvLi4uTVBMUyBj by1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0dW5uZWwvLi4uTVBMUy1UUCBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBMU1A8YnI+DQomZ3Q7PGJyPg0KJmd0OyBzLy4uLmNvLXJvdXRlZCBNUExTIHR1bm5l bCBhcmUgaWxsdXN0cmF0ZWQgaGVyZS8uLi5NUExTLVRQIGNvLXJvdXRlZDxicj4NCiZndDsgYmlk aXJlY3Rpb25hbCBMU1AgYXJlIGlsbHVzdHJhdGVkIGhlcmUgU2FtZSBhcyBhYm92ZS48YnI+DQo8 YnI+DQpPSywgc2FtZSBhcyBhYm92ZSwgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBUdW5uZWwgYW5k IExTUC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFDSy4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi Pjxicj4NCiZndDs8YnI+DQomZ3Q7IDMuPGJyPg0KJmd0Ozxicj4NCiZndDsgRm9yIG1wbHNPYW1J ZE1lVGFibGUsIHNpbmNlIHRoaXMgaXMgdGhlIGlkZW50aWZpZXIgTUlCLCB3aHkgZG8gd2UgbmVl ZHRoZTxicj4NCiZndDsgZm9sbG93aW5nIGl0ZW1zPzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgbXBsc09hbUlkTWVQcm9hY3RpdmVPYW1QaGJUQ1ZhbHVlID0gMCw8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1wbHNPYW1JZE1lT25EZW1hbmRPYW1QaGJU Q1ZhbHVlJm5ic3A7ID0gMCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCBzZWVtcyB0aGF0IHRoZXkg c2hvdWxkIG5vdCBiZWxvbmcgdG8gdGhpcyBNSUIsIG1heWJlIGJldHRlciBpbiBvdGhlciBNSUIu PGJyPg0KJmd0OyBQSEIgVEMgdmFsdWVzIGFyZSBkZWZpbmVkIGluIHRoaXMgTUlCIHRvIGJhc2lj YWxseSB1c2UgdGhlc2UgdmFsdWVzIGluPGJyPg0KJmd0OyBQcm9hY3RpdmUoQkZEKS9PbkRlbWFu ZChMU1AgUGluZykgc2Vzc2lvbnMuPGJyPg0KPGJyPg0KSSBrbm93IHRoZXkgYXJlIHVzZWZ1bCwg SSBhbSBqdXN0IG5vdCBzdXJlIHdoZXRoZXIgdGhleSBzaG91bGQgYmVsb25nIHRvIHRoaXMgTUlC LCBzaW5jZSB0aGlzIE1JQiBpcyBqdXN0IGFuIE9BTSBpZGVudGlmaWVyIE1JQi48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPldpbGwgZGlzY3VzcyBpbnRlcm5hbGx5IGFuZCBkZWNp ZGUgb24gdGhpcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDs8YnI+DQomZ3Q7IDQuPGJyPg0KJmd0Ozxicj4N CiZndDsgbXBsc09hbUlkTWVnUGF0aEZsb3cgT0JKRUNULVRZUEU8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTWU5UQVgmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgSU5URUdFUiB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt1bmlkaXJlY3Rpb25hbFBvaW50VG9Qb2ludCAoMSksPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb1JvdXRlZEJpZGlyZWN0aW9uYWxQ b2ludFRvUG9pbnQgKDIpLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7YXNzb2NpYXRlZEJpZGlyZWN0aW9uYWxQb2ludFRvUG9pbnQgKDMpLDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dW5pZGlyZWN0aW9uYWxQ b2ludFRvTXVsdGlQb2ludCAoNCk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZWVtcyBSRkM2MzcwIGRv ZXMgbm90IGRlZmluZSBob3cgdG8gaWRlbnRpZnkgYTxicj4NCiZndDsgdW5pZGlyZWN0aW9uYWxQ b2ludFRvTXVsdGlQb2ludCBwYXRoLCBhbmQgZnJvbSB0aGUgSW50cm9kdWN0aW9uIG9mIHRoaXM8 YnI+DQomZ3Q7IGRvY3VtZW50LCB0aGUgUDJNUCBzZWVtcyBub3QgYmUgaW5jbHVkZWQuPGJyPg0K Jmd0Ozxicj4NCiZndDsgV2Ugd2lsbCBhZGQgbW9yZSBpbmZvcm1hdGlvbiBmb3IgUDJNUCBpbiB0 aGUgbmV4dCB2ZXJzaW9uIGFmdGVyIHRoZSBpbnRlcm5hbDxicj4NCiZndDsgZGlzY3Vzc2lvbi48 YnI+DQo8YnI+DQpPSywgcGxlYXNlIGRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIz IiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+QUNLJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PGJyPg0KJmd0OyA1Ljxicj4NCiZndDs8YnI+DQomZ3Q7 IG1wbHNPYW1JZE1lZ1N1Yk9wZXJTdGF0dXMgT0JKRUNULVRZUEU8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTWU5UQVgmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtCSVRTIHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 bWVnRG93biAoMCksPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21l RG93biAoMSksPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29hbUFw cERvd24gKDIpLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYXRo RG93biAoMyk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRo ZSBiaXQgMCAobWVnRG93bikgaW5kaWNhdGVzIHRoZSBNRUcgaXMgZG93bi48YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUg Yml0IDEgKG1lRG93bikgaW5kaWNhdGVzIHRoZSBNRSB0YWJsZSBpczxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRvd24uPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgVGhlIGJpdCAyIChvYW1BcHBEb3duKSBpbmRpY2F0ZXMgdGhhdCB0aGU8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBP QU0gYXBwbGljYXRpb24gaGFzIG5vdGlmaWVkIHRoYXQgdGhlIGVudGl0eSAoTFNQIG9yIFBXKTxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IG1vbml0b3JlZCBieSB0aGlzIE1FRyBpcyBkb3duLiBDdXJyZW50bHksIEJGRCBpcyB0 aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBvbmx5IHN1cHBvcnRlZCBPQU0gYXBwbGljYXRpb24uPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIGJp dCAzIChwYXRoRG93bikgaW5kaWNhdGVzIHRoYXQgdGhlIHVuZGVybHlpbmc8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBMU1Ag b3IgUFcgaXMgZG93bi4mcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFtIG5vdCBzdXJlIHdo YXQncyB0aGUgbWVhbiBvZiAmcXVvdDtkb3duJnF1b3Q7IGhlcmUsIGVzcGVjaWFsbHkgdGhlIG1l YW4gb2YgJnF1b3Q7TUVHIGlzPGJyPg0KJmd0OyBkb3duJnF1b3Q7LCAmcXVvdDtNRSB0YWJsZSBp cyBkb3duJnF1b3Q7IGFuZCAmcXVvdDtMU1AgYW5kIFBXIGlzIGRvd24mcXVvdDs/PGJyPg0KJmd0 OyBXZSBkZWZpbmVkIHRoaXMgb2JqZWN0IHRvIG5vdGlmeSB0aGUgb3BlcmF0aW9uYWwgc3RhdHVz IG9mIE1FRywgTUUsIE9BTSBhcHA8YnI+DQomZ3Q7IGFuZCB0aGUgTVBMUy9NUExTLVRQIHBhdGgs IHdpbGwgYWRkIG1vcmUgaW5mb3JtYXRpb24gaW4gdGhlIG5leHQgdmVyc2lvbi48YnI+DQo8YnI+ DQpPSywgcGxlYXNlIGRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSLl rovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QUNLJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250 IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mZ3Q7PGJyPg0KJmd0OyA2Ljxicj4NCiZndDs8YnI+DQomZ3Q7IG1wbHNPYW1J ZE1lU2VydmljZVBvaW50ZXIgT0JKRUNULVRZUEU8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U1lOVEFYJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFJvd1BvaW50ZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtNQVgtQUNDRVNTJm5ic3A7ICZuYnNwOyByZWFkLWNyZWF0ZTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NUQVRVUyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBjdXJyZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7REVTQ1JJUFRJT048YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7VGhpcyB2YXJpYWJsZSByZXBy ZXNlbnRzIGEgcG9pbnRlciB0byB0aGUgTVBMUy1UUDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0IHBhdGguIFRoaXMgdmFs dWUgTVVTVCBwb2ludCBhdCBhbiBlbnRyeSBpbiB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1wbHNUdW5uZWxFbnRyeSBpZiBtcGxz T2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIGNvbmZpZ3VyZWQgYXMgbHNwICgxKSBvciBh dCBhbiBlbnRyeSBpbiB0aGUgcHdFbnRyeSBpZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbXBsc09hbUlkTWVnU2VydmljZVBvaW50ZXJU eXBlIGlzIGNvbmZpZ3VyZWQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGFzIHBzZXVkb3dpcmUgKDIpLjxicj4NCiZndDs8YnI+DQomZ3Q7 IEhvdyBhYm91dCBtcGxzT2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGVzZWN0aW9uIGlzIGNvbmZp Z3VyZWQgYXMgc2VjdGlvbjxicj4NCiZndDsgKDMpPzxicj4NCiZndDsgU2VjdGlvbiBpcyBub3Qg eWV0IHRha2VuIGNhcmUgaW4gdGhpcyBNSUIuIFdpbGwgYWRkIG1pc3NpbmcgaW5mb3JtYXRpb24g YWZ0ZXI8YnI+DQomZ3Q7IGludGVybmFsIGRpc2N1c3Npb24uPGJyPg0KPGJyPg0KT0ssIHBsZWFz ZSBkby48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFDSyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIzIiBm YWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ Jmd0Ozxicj4NCiZndDsgQW5kIGRyYWZ0LWlldGYtbXBscy10cC10ZS1taWItMDggZGVmaW5lcyBt cGxzVHVubmVsRXh0RW50cnkgZm9yIE1QTFMtVFA8YnI+DQomZ3Q7IHR1bm5lbHMgYW5kIHB3RXh0 RW50cnkgZm9yIE1QTFMtVFAgUFdzLCBzaG91bGQgdGhlIGFib3ZlIG1wbHNUdW5uZWxFbnRyeTxi cj4NCiZndDsgYW5kIHB3RW50cnkgYmUgY2hhbmdlZCB0byBtcGxzVHVubmVsRXh0RW50cnkgYW5k IHB3RXh0RW50cnk/PGJyPg0KJmd0OyBObyxUdW5uZWwgJmFtcDsgUFcgZW50cmllcyBhcmUgYXVn bWVudGVkIHRvIGhhdmUgdGhlIGV4dHJhIGZpZWxkcyBpbiB0aGUgbmV3IHRhYmxlczxicj4NCiZn dDsgZm9yIE1QTFMtVFAuIFRoZSBiYXNlIHRhYmxlIHNob3VsZCBiZSBzdWZmaWNpZW50IGZvciB0 aGUgTVBMUy9NUExTLVRQIHBhdGggdG88YnI+DQomZ3Q7IE9BTSBjb25maWcgYXNzb2NpYXRpb24u PGJyPg0KPGJyPg0KT0suPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IuWu i+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BQ0smbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxicj4NCiZndDs8YnI+DQomZ3Q7IDcuPGJyPg0KJmd0OyBtcGxzT2FtSWRNZWdT ZXJ2aWNlUG9pbnRlclR5cGUgT0JKRUNULVRZUEU8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U1lOVEFYJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IElOVEVHRVIgezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2xzcCAoMSksPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHNldWRvd2lyZSAoMiksPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VjdGlvbiAoMyk8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01BWC1BQ0NFU1MmbmJzcDsgJm5ic3A7 IHJlYWQtY3JlYXRlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7U1RBVFVTJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGN1cnJlbnQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtERVNDUklQVElPTjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVv dDtJbmRpY2F0ZXMgdGhlIHNlcnZpY2UgdHlwZSBmb3IgdGhlIE1FRy48YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElmIHRoZSBzZXJ2aWNl IHR5cGUgaW5kaWNhdGVzIGxzcCwgdGhlIHNlcnZpY2UgcG9pbnRlcjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW4gbXBsc09hbUlkTWVU YWJsZSBwb2ludHMgdG8gYW4gZW50cnkgaW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBtcGxzVHVubmVsVGFibGUgW1JGQzM4MTJd Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFNpbmNlIGRyYWZ0LWlldGYtbXBscy10cC10ZS1taWItMDgg ZGVmaW5lcyBtcGxzVHVubmVsRXh0VGFibGUgZm9yIE1QTFMtVFA8YnI+DQomZ3Q7IFR1bm5lbHMg YW5kIFB3cywgc2hvdWxkIHRoZSBhYm92ZSBtcGxzVHVubmVsVGFibGUgYmUgbXBsc1R1bm5lbEV4 dFRhYmxlIGFuZDxicj4NCiZndDsgcmVmZXJlbmNlIGJlIGRyYWZ0LWlldGYtbXBscy10cC10ZS1t aWItMDg/PGJyPg0KJmd0OyBObywgYXMgc3RhdGVkIGFib3ZlLCB0aGlzIE1JQiBpcyBtYWlubHkg ZGVmaW5lZCB0byBwcm92aWRlIE9BTSBjb25maWdzIGZvciBNUExTPGJyPg0KJmd0OyAmYW1wOyBN UExTLVRQIHBhdGhzLjxicj4NCjxicj4NCk9LLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXpl PSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+QUNLJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KTWFj aDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkcyw8 YnI+DQomZ3Q7IE1hY2g8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPl08YnI+ DQomZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCA2OjMxIFBNPGJyPg0K Jmd0OyAmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86 bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZzwvYT47IFZJR09VUkVVWCwgTUFSVElOIChNQVJUSU4pOyBKb2FuPGJyPg0K Jmd0OyAmZ3Q7IEN1Y2NoaWFyYTsgTWFjaCBDaGVuOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHMt YWRzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1hZHNAdG9vbHMuaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBTaGVwaGVyZHMgZm9yIE1QTFMgTUlC IG1vZHVsZXM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV29ya2luZyBHcm91cCw8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV2UgaGF2ZSBmb3Igc29tZSB0aW1lIGJlZW4gbG9v a2luZyBmb3Igc29tZW9uZSB0byBoZWxwIHVzIHNoZXBoZXJkaW5nPGJyPg0KJmd0OyAmZ3Q7IG91 ciBNSUIgbW9kdWxlcy4gSSdtIGhhcHB5IHRvIGFubm91bmNlIHRoYXQgTWFjaCBDaGVuIGFuZCBZ b3VuZyBMZWU8YnI+DQomZ3Q7ICZndDsgaGFzIGFncmVlZCB0byBoZWxwIHVzLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyBQbGVhc2UgaGVscCBNYWNoIGFuZCBZb3VuZyBhcyB0aGV5IHN0 YXJ0IHdvcmtpbmcgd2l0aCB0aGUgZG9jdW1lbnRzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBXZSd2ZSBhc3NpZ25lZCBNYWNoIGFzIFNoZXBoZXJkIGZvciBkcmFmdC1pZXRmLW1wbHMt dHAtb2FtLWlkLW1pYi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRnVydGhlciBzaGVw aGVyZCBhc3NpZ25tZW50cyB3aWxsIGJlIGRvbmUgYXMgc29vbiBhcyB0aGUgZGV0YWlscyBhcmUg c29ydGVkPGJyPg0KJmd0OyBvdXQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IC9Mb2E8YnI+DQomZ3Q7ICZndDsgZm9yIHRoZSBtcGxzIHdnIGNoYWlyczxicj4N CiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBMb2EgQW5kZXJzc29uJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW1haWw6IDxhIGhyZWY9 Im1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmxvYUBtYWls MDEuaHVhd2VpLmNvbTwvYT48YnI+DQomZ3Q7ICZndDsgU2VuaW9yIE1QTFMgRXhwZXJ0Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRh cmdldD0iX2JsYW5rIj4NCmxvYUBwaS5udTwvYT4gSHVhd2VpPGJyPg0KJmd0OyAmZ3Q7IFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiA8YSBocmVmPSJ0 ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7NDYg NzM5IDgxIDIxIDY0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250 IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B2E505ESZXEMA510MBXchi_-- From nobody Thu Dec 4 02:37: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 9589E1A01AA; Thu, 4 Dec 2014 02:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtrPPNTYSfl0; Thu, 4 Dec 2014 02:37:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79D71A0146; Thu, 4 Dec 2014 02:37:09 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id EFAD03B4529; Thu, 4 Dec 2014 11:37:07 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C36A82380A0; Thu, 4 Dec 2014 11:37:07 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.149]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0210.002; Thu, 4 Dec 2014 11:37:07 +0100 From: To: Yakov Rekhter Thread-Topic: [mpls] maturity of the MRT technology Thread-Index: AQHQDwT05s13BieLpE2AHYP0TmNrfpx/Oe4w Date: Thu, 4 Dec 2014 10:37:07 +0000 Message-ID: <29576_1417689427_54803953_29576_3299_1_9E32478DFA9976438E7A22F69B08FF920C73E8FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <201412031424.sB3EOtR80359@magenta.juniper.net> In-Reply-To: <201412031424.sB3EOtR80359@magenta.juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.4.95723 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-64HgqImQPMv1zqLl3EPcigNmcw Cc: "mpls@ietf.org" , "rtgwg@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] maturity of the MRT technology 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, 04 Dec 2014 10:37:12 -0000 Hi Yakov, Thanks to point this important subject. Consider the case where you have a link failure, it is easy for our custome= rs to understand that their traffic have been impacted because the traffic = was crossing the link that has failed. Now, if to protect this link, we enable FRR and FRR path uses an "uncontrol= led" path. When the link fails, traffic is switched to FRR path and may use= some paths that is not well sized to handle this traffic. This may create congestion on some links. Congestion will affect traffic th= at is not directly concerned by the failure, so customer will loss some tra= ffic. For sure, the congestion duration will be bound to the convergence ti= me (~seconds), but for some critical applications (that are not essential r= equiring LLQ -> so QoS may not fully help in this, in customer data class i= s congestionned), this is not acceptable. And customers cannot understand t= hat they are impacted by an issue in another region of the world. (It's lik= e the well known "Butterfly effect" :) ) This problematic is quite similar to the microloop one. Microloops are impa= cting traffic which is not directly concerned by the failure. And globally = we already had complains for both issues (FRR using bad path and microloops= ). Hope it helps to understand our concern. Best Regards, Stephane -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net]=20 Sent: Wednesday, December 03, 2014 15:25 To: LITKOWSKI Stephane SCE/IBNF Cc: Uma Chunduri; Alia Atlas; Loa Andersson; mpls@ietf.org; mpls-chairs@too= ls.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org Subject: Re: [mpls] maturity of the MRT technology=20 Stephane, On 23/11/2014 08:47, stephane.litkowski@orange.com wrote: =20 > Hi Uma, > > >Is this because of domain wide deployment requirements MRT brings-in > (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in=20 > the network? > > No, domain-wide deployment is not an issue. The issue I see in MRT=20 > (for my use case) is unoptimality of the FRR path (at least using=20 > lowpoint algorithm). But anyway, as I mentioned, I'm not opposed to=20 > make MRT progressing at all. It's good to have multiple tools. While MRT may result in "unoptimality of the FRR path", why this unoptimali= ty really matters that much, given that FRR suppose to be used for only a s= hort period of time until IGP convergence? Yakov. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Dec 4 04:11: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 6E8591A0302; Thu, 4 Dec 2014 04:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwZyYJez7NnG; Thu, 4 Dec 2014 04:11:24 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A0C1A026E; Thu, 4 Dec 2014 04:11:24 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB4CBJtM005373; Thu, 4 Dec 2014 12:11:19 GMT 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 sB4CBEbN005219 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2014 12:11:17 GMT From: "Adrian Farrel" To: "'Benoit Claise'" , "'The IESG'" References: <20141203174039.14529.28696.idtracker@ietfa.amsl.com> In-Reply-To: <20141203174039.14529.28696.idtracker@ietfa.amsl.com> Date: Thu, 4 Dec 2014 12:11:09 -0000 Message-ID: <0e8201d00fbb$66964710$33c2d530$@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: AQG7Scj1DFIiqt78MjHH/c/WiMn1pZyo4OCA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21148.006 X-TM-AS-Result: No--10.128-10.0-31-10 X-imss-scan-details: No--10.128-10.0-31-10 X-TMASE-MatchedRID: zGP2F0O7j/s4HKI/yaqRm0bKkLkJUU4ffkSt9GqmKVV0AEElu1jPgxjU z+fA5iS285FpXkUwv+BhflX0WGmQPDzemDCU+QwmuIwLnB3Aqp0uLZ3AqIxH3Ea+7cKvw60WZvo +mFW19mBMB97Lthp7cWyDWc5znwaG6k7nluwp/XrkNIw8RlACQ4LsLasl5ROhIGzQ5T0/q1uQvj YuaSnzm+AAg1nydkJweTjw/FyRX6RNfs8n85Te8v7E6GNqs6ceseWplitmp0j6C0ePs7A07RQEL 0GGu6SDob6A0sQPSwOcN6+vb/CvB5YxvUCSS9GT1B/OUG+VMrc= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HXwLYz4_pGDCfuK75isEvyXQ0Bg Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] Benoit Claise's No Objection on charter-ietf-mpls-06-08: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 12:11:30 -0000 Hi Benoit, > To avoid any potential confusions with LIME, I would prefer: > OLD: > > The working group's responsibilities include procedures and > protocols for the distribution of labels between Label Switching > Routers (LSRs), MPLS packet encapsulation, and for Operation, > Administration, and Maintenance (OAM) including the necessary > management objects expressed as YANG models or MIB modules. > > NEW: > > The working group's responsibilities include procedures and > protocols for the distribution of labels between Label Switching > Routers (LSRs), for MPLS packet encapsulation, and for the related > Operation, > Administration, and Maintenance (OAM) including the necessary > management objects expressed as YANG models or MIB modules. Took me a moment to figure your concern. I think you are worried that it appears to say *all* OAM. This now reads... The working group's responsibilities include procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) for MPLS systems including the necessary management objects expressed as YANG models or MIB modules. > One clarifying question (sorry I missed that one during the previous > review). I don't understand what the following mean: > > - Define an overall OAM framework for topology-driven, traffic > engineered, and transport profile MPLS applications. > > What is an OAM "framework"? An architecture, a new (set of) protocol(s), > protocol extensions, something else? A bit clumsy, perhaps. But it is old text. The objective is to achieve a common set of approaches and tools across the full family of MPLS applications. This now reads: - Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications to achieve a common set of approaches and tools across the full family of MPLS applications. Cheers, Adrian From nobody Thu Dec 4 04:57: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 8EC9E1A039A; Thu, 4 Dec 2014 04:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWHkdBA03jE4; Thu, 4 Dec 2014 04:57:25 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4311A03E1; Thu, 4 Dec 2014 04:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2172; q=dns/txt; s=iport; t=1417697844; x=1418907444; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gdwrxA9i1kUPE2yjWzhr8sKB09bNC9iTDIGaZ+eNqxo=; b=XrNprzyIzp+zzShhP6Kz2nPVpjhazoWTwV0Z/MnZWdmi5FAClqZXwl65 y/KRMRPXKzeYxwDxSjMQ5Z+NfDlQjmPZ3tI2jNLra/w+Yp0ulyVVHNbW6 tI5+9WdvQANustKSCdVZOzOtqsoPukatShaBGQYffmShKN58Yu+9RtITu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAK1ZgFRIo8UY/2dsb2JhbABa0RoCgTIBAQEBAX2EAwEBBDhAARALEg8WDwkDAgECATcOBgEMAQcBAYg61jYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkGYHhEIBBJpagSKFeokSg2mCNYFFPoJ1AQEB X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="48147578" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 04 Dec 2014 12:57:19 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB4Cv8gu024365; Thu, 4 Dec 2014 12:57:14 GMT Message-ID: <54805A22.2050008@cisco.com> Date: Thu, 04 Dec 2014 13:57:06 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'The IESG'" References: <20141203174039.14529.28696.idtracker@ietfa.amsl.com> <0e8201d00fbb$66964710$33c2d530$@olddog.co.uk> In-Reply-To: <0e8201d00fbb$66964710$33c2d530$@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/XQpiCJsavkt_DpAM-AA1NwPZ_9o Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] Benoit Claise's No Objection on charter-ietf-mpls-06-08: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 12:57:26 -0000 Thanks Adrian for taking care of my comments. Regards, Benoit > Hi Benoit, > >> To avoid any potential confusions with LIME, I would prefer: >> OLD: >> >> The working group's responsibilities include procedures and >> protocols for the distribution of labels between Label Switching >> Routers (LSRs), MPLS packet encapsulation, and for Operation, >> Administration, and Maintenance (OAM) including the necessary >> management objects expressed as YANG models or MIB modules. >> >> NEW: >> >> The working group's responsibilities include procedures and >> protocols for the distribution of labels between Label Switching >> Routers (LSRs), for MPLS packet encapsulation, and for the related >> Operation, >> Administration, and Maintenance (OAM) including the necessary >> management objects expressed as YANG models or MIB modules. > Took me a moment to figure your concern. I think you are worried that it appears > to say *all* OAM. > > This now reads... > > The working group's responsibilities include procedures and > protocols for the distribution of labels between Label Switching > Routers (LSRs), MPLS packet encapsulation, and for Operation, > Administration, and Maintenance (OAM) for MPLS systems > including the necessary management objects expressed as > YANG models or MIB modules. > >> One clarifying question (sorry I missed that one during the previous >> review). I don't understand what the following mean: >> >> - Define an overall OAM framework for topology-driven, traffic >> engineered, and transport profile MPLS applications. >> >> What is an OAM "framework"? An architecture, a new (set of) protocol(s), >> protocol extensions, something else? > A bit clumsy, perhaps. But it is old text. > > The objective is to achieve a common set of approaches and tools across the full > family of MPLS applications. > > This now reads: > > - Define an overall OAM framework for topology-driven, traffic > engineered, and transport profile MPLS applications to achieve > a common set of approaches and tools across the full family of > MPLS applications. > > Cheers, > Adrian > > . > From nobody Thu Dec 4 05:26: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 CB33A1A1A6D; Thu, 4 Dec 2014 05:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHc9CNlx-_sI; Thu, 4 Dec 2014 05:26:08 -0800 (PST) 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 AFF611A1A50; Thu, 4 Dec 2014 05:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7129; q=dns/txt; s=iport; t=1417699568; x=1418909168; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=K2KkHerU8Z1RR0DQge5LKgJnxK6kuLUEUqEdeZUytu4=; b=FBpvU3o7qurI3I4wWSRjJGMO/yY1Gy5d6ypdp8WQu3i4gxeiMbFSLDQ8 aJJ7PWgDmHq+6TxrT1m4iewj95fq2qddS7j4us4hnKZH2J/pGcav/tOVg NBO5OGlPqYQoUdrQnwQ4o/KK1w8em9kwKGQV3fudSNM0F/lVnRIE48n2m 0=; X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208,217";a="261092785" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Dec 2014 13:26:06 +0000 Received: from [64.103.108.115] (dhcp-bdlk10-data-vlan301-64-103-108-115.cisco.com [64.103.108.115]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB4DQ2je016433; Thu, 4 Dec 2014 13:26:05 GMT Message-ID: <548060EA.6070500@cisco.com> Date: Thu, 04 Dec 2014 13:26:02 +0000 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: Uma Chunduri References: <546BDF65.2030203@pi.nu> <3682_1416561775_546F046F_3682_717_1_9E32478DFA9976438E7A22F69B08FF92177BF0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A60469152008633F44A97E@eusaamb105.ericsson.se> <18727_1416732463_54719F2F_18727_12486_1_9E32478DFA9976438E7A22F69B08FF92178256@OPEXCLILM34.corporate.adroot.infra.ftgroup> <547EBC95.6020608@cisco.com> <547F38F4.3030908@cisco.com> <1B502206DFA0C544B7A60469152008633F48215B@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F48215B@eusaamb105.ericsson.se> Content-Type: multipart/alternative; boundary="------------070307020802060702090804" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dBEICFGxR8PaN8gIV7wFO6yQcOI Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "rtgwg@ietf.org" Subject: Re: [mpls] maturity of the MRT technology 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, 04 Dec 2014 13:26:10 -0000 This is a multi-part message in MIME format. --------------070307020802060702090804 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/12/2014 19:59, Uma Chunduri wrote: > > >the method of calculating the > >repair topology itself ought to be private to the orchestrator. > > When we agree to standardize the IPFRR related parameters, IMO it’s > important to standardize the relevant algorithm too regardless of > where it’s used. > > If it is used in a distributed manner this question is less relevant > as it’s mostly multi-vendor deployments. > > Even when an orchestrator is computing using a particular algorithm > IMO, it’s important Vendor X and Vendor Y of the controller do the > same thing and > > also this has to be **clearly** understood to validate (to see the > corner cases are working correct) and debug stuff, once deployed. > > Proprietary stuff may come with their own cost/risk. > I would appreciate hearing the operator's perspective(s) on this. Will we see two vendor's controllers operate over the same set of nodes such that identical behaviour is required, or is this an area where we are likely to see customization to execute the repair in a way that best suits the specifics of the network and the applicable business model? Stewart --------------070307020802060702090804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 03/12/2014 19:59, Uma Chunduri wrote:

 

>the method of calculating the
>repair topology itself ought to be private to the orchestrator.

 

When we agree to standardize the IPFRR related parameters, IMO it’s important to standardize the relevant algorithm too regardless of where it’s used.

 

If it is used in a distributed manner this question is less relevant as it’s mostly  multi-vendor deployments.

 

Even when an orchestrator is computing using a particular algorithm IMO, it’s important Vendor X and Vendor Y of the controller do the same thing and

also this has to be *clearly* understood to validate (to see the corner cases are working correct)  and debug stuff, once deployed.

 

Proprietary stuff may come with their own cost/risk.

I would appreciate hearing the operator's perspective(s) on this.

Will we see two vendor's controllers operate over the same set of nodes such that identical behaviour is required, or is this an area where we are likely to see customization to execute the repair in a way that best suits the specifics of the network and the applicable business model?

Stewart
--------------070307020802060702090804-- From nobody Thu Dec 4 06:09: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 C9C881AD3B7; Thu, 4 Dec 2014 06:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRVrBfdRJbIg; Thu, 4 Dec 2014 06:09:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4B21AD384; Thu, 4 Dec 2014 06:09:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141204140912.10658.21011.idtracker@ietfa.amsl.com> Date: Thu, 04 Dec 2014 06:09:12 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HD1pAy6J6axiBHIeViRH3uIs2iY Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] Stephen Farrell's Yes on charter-ietf-mpls-06-10: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 14:09:22 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-mpls-06-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-mpls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- And thanks once more for the security work item. From nobody Thu Dec 4 07:55:49 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 2AB3F1A0137 for ; Thu, 4 Dec 2014 07:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XBFDijBEjt5T for ; Thu, 4 Dec 2014 07:55:45 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.5]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CA71AD3F9 for ; Thu, 4 Dec 2014 07:55:43 -0800 (PST) Received: from [216.82.250.51] by server-5.bemta-12.messagelabs.com id FD/CA-03158-EF380845; Thu, 04 Dec 2014 15:55:42 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-2.tower-108.messagelabs.com!1417708542!23187704!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13884 invoked from network); 4 Dec 2014 15:55:42 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-2.tower-108.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Dec 2014 15:55:42 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id D904F1DEC9; Thu, 4 Dec 2014 15:55:41 +0000 (GMT) Received: from USADCWVEHT01.corp.global.level3.com (10.2.36.141) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Dec 2014 08:55:41 -0700 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by usadcwveht01.corp.global.level3.com ([::1]) with mapi id 14.03.0158.001; Thu, 4 Dec 2014 10:55:40 -0500 From: "Osborne, Eric" To: "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAP2no76f67h7pbRmWY0LHccfco7w== Date: Thu, 4 Dec 2014 15:55:39 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD01049215@USIDCWVEMBX08.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.206] 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/j5wmARcpzdf__LanFpbAXinx-q0 Cc: "mpls@ietf.org" Subject: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 04 Dec 2014 15:55:48 -0000 I forgot to cc the list so I'm resending my comments on this draft. Here is my review: - is the document coherent? Not really...it needs some serious copyediting. See the wall of text belo= w. None of my copyedit comments should be considered blockers for WG adopt= ion. - is it useful? Very much so. This mechanism will make troubleshooting easier and proacti= ve monitoring much better. - is it ready for WG adoption? Yes. It needs some cleanup but the technology seems sound. It's certainl= y mature enough to be adopted by the WG. Document comments: This isn't a line-by-line critique and I'm not a terribly good Real Editor(= tm) anyways so I've tried to keep these comments general and constructive. General: the document needs an infusion of pronouns and definite articles. = Things like "Result raises a limitation" (sec. 1.2) should be "The result = raises.." or 'This result raises...'. I've called out some of the places w= here this needs to happen, but not all of them. Section 1.1: s/terminologies/terms/ Section 1.2: the first paragraph needs a rewrite, it's messy. Also, the bu= llet points that end in '...is [succeeding|failing]' should be '...have [su= cceeded|failed]'. And 'With above scenario' needs to be 'With the above sc= enario' or something. Sections 3-5: These sections could use a reorg. Starting with procedures f= or using new TLVs before defining the new TLVs feels awkward. I suggest ta= king sections [3,4,5] and reordering as [5,3,4]. =20 Section 3: This section needs a little introduction. Something like "This = section describes the handling of the new TLVs by nodes which understand th= em. There are two cases - nodes which understand the TLVs but which for so= me reason cannot describe LAG members separately, and nodes which both unde= rstand the new TLVs and are able to describe LAG members separately". =20 Section 3.2: " The responder LSRs that understands the LAG Interface Info T= LV and are able to describe outgoing LAG member links separately are to use the follow procedures"=20 needs some singular/plural cleanup: " A responder LSR that understands the LAG Interface Info TLV and is able to describe outgoing LAG member links separately uses the follow procedures" or something like that. Section 3.3: "Above procedures..." -> "The procedures above..." Section 4.2: Same kind of cleanup as 3.2: "Responder LSRs that understands.= ." -> "Responder LSRs which understand..." Section 4.3: "described procedures in this section" -> "the procedures desc= ribed in this section" Section 4.3: "following checks" -> "the following checks". Also, the error= case is a little confusing. The first half of the error case is actually = a success, and I spent some time going back and forth between the first hal= f of the success case and the failure case to figure out whether they were = different. It would benefit from some clarifying text, perhaps something l= ike "An error case is any case where the OAM across a LAG fails, either par= tial or fully. A partial failure is where some LAG member traversals behav= e as they should and some don't, and a full failure is where no LAG member = traversals behave as they should". Sections 5-8: no comments on the TLVs themselves, I don't know OAM well eno= ugh to find any hidden mines here. This is for the WG to pore over. Section 9: "As result of" -> "as a result of". Also, "additional processin= g are required" -> "additional processing is required" Section 11: "Authors" -> "The authors". Appendix A: I get that this section is intended to list out problems that a= ren't solved by the mechanisms in this document. It's probably worth addin= g text in Section 2 that describes the limitations of the proposed mechanis= m, something like "Most[*] LAGs are built from p2p links, and thus router X= and router X+1 have the same number of LAG members. It is possible to bui= ld LAGs asymmetrically by using Ethernet switches in the middle. Appendix = A lists some cases which this document does not address; if an operator dep= loys LAGs in a manner similar to what's shown in Appendix A, the mechanisms= in this document may not suit them". I know Section 2 has a bullet at the= end that hints at this, but I think it should be more explicit. [*] I believe this to be true. I am willing to be wrong. It has happened= before. eric From nobody Thu Dec 4 09:40: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 83CF01A6FC4 for ; Thu, 4 Dec 2014 09:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1MwGc35u6Dq for ; Thu, 4 Dec 2014 09:40:37 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED021A0393 for ; Thu, 4 Dec 2014 09:40:36 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB4HeZ4G017234; Thu, 4 Dec 2014 17:40:35 GMT 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 sB4HeYR7017228 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2014 17:40:34 GMT From: "Adrian Farrel" To: Date: Thu, 4 Dec 2014 17:40:29 -0000 Message-ID: <0fa601d00fe9$65b71bc0$31255340$@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: AdAP6WLWlNwx7OAhR2uCoLuYCVEPwA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21150.001 X-TM-AS-Result: No--14.143-10.0-31-10 X-imss-scan-details: No--14.143-10.0-31-10 X-TMASE-MatchedRID: TJB/0L//SMUTY/HRCFabdCe3N/QUhiGU1Ga2L87qPQLIvQIyugvKdX0d vgXHBmfWCCtTOTfjKzkdd+wHVoSfOmpw4IniioZqF6z9HGHKwNvomPrNi98UBAbYcy9YQl6ecUP QjSOUQN17fwzvbJ3HQxiQhZYtD6u5U+0LzHD1pkjucXIIWH+vc6PAonsrI1ywK1ATzNYHAii+KO yzJ38gNT+218HSJD0EgRLV8vrJRQXoyJCZV0+mCK6cG/SCexsP6WNmYQcB5Ews7eP5cPCWQ/0h0 riQa/EtzK7PHiQkiDAt/oHnHqGh4hFz/PEz2ag14nbwqqmOd2lQCOsAlaxN70UNHQAoZf5cjkn7 jhL59/Ke96jvNPvIsJq2VmRSTag3nPecQ/hKOMDg6z4GbKMS7Z6KYa03LCO2myiLZetSf8nJ4y0 wP1A6AMaUO+wtQNbajoczmuoPCq2yKHKqilNZdVSr+wpDP/RkF37so+ZFMAS5cvAn3HEkXfmwYr PP6aW9 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/isRvw4FzEaT8_55IfWADhedklRA Cc: draft-ietf-mpls-ldp-ipv6@tools.ietf.org Subject: [mpls] Moving forward with draft-ietf-mpls-ldp-ipv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:40:38 -0000 Hi working group, I have been watching the progress with draft-ietf-mpls-ldp-ipv6. It came to me as a publication request after several WG last calls. Each one seemed to close with a few issues that were addressed in a consensual way, but shortly after there were more comments that needed work and resulted in a respin and a further last call. I had some comments during my AD review and returned the document to the WG to have them fixed. A new revision addressed my comments and further late issues that were raised in the WG. The working group held a further last call to confirm the final version of the document and that all seemed to be good. So the chairs re-issued the publication request to me. But now there have been further emails raising or re-raising issues. Of course, we want to get the spec right. So all comments are welcome. But there is a sense in which we must all work to reach consensus and agree on what to publish. That work requires attention and responsiveness (it does not work to drag out a conversation with long, long pauses between emails), and it does not work to insist on one way of doing something being "somewhat better" than another way if the selected way is not demonstrably harmful and has wide support from the working group. I asked the chairs to tell me whether they believe that there is WG consensus around the current version of the document. They say that there is, but that there remains a minority opinion that the document should use a different approach. The document shepherd write-up reflects this by saying We have not been able to fully converge on the last comment, the Shepherd and wg chairs are convinced that version -14 represent the working group consensus and think we should progress the document now. I plan to start the IETF last call for this document. During that time it would be helpful if those who support the document voiced their opinions preferably with substantive comments (i.e., this is not a vote) and those who have issues should also raise them. However, it is not constructive or helpful to simply re-open old issues that have been closed with consensus on the mailing list. Nor is it helpful to say the equivalent of "I don't like doing it this way." If you have a concern with the current draft, please try to explain what is broken and how that will damage interoperability or functionality in the Internet. Please can everyone work hard to send any comments within the last call period and using the correct email lists. Thanks, Adrian From nobody Thu Dec 4 09:47: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 B59901A038C for ; Thu, 4 Dec 2014 09:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwCcxnD5Hteu for ; Thu, 4 Dec 2014 09:47:02 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3211A0155 for ; Thu, 4 Dec 2014 09:47:01 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB4HkxGb014064 for ; Thu, 4 Dec 2014 17:46:59 GMT 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 sB4HkwD9014048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2014 17:46:59 GMT From: "Adrian Farrel" To: Date: Thu, 4 Dec 2014 17:46:54 -0000 Message-ID: <0fab01d00fea$4af2e2a0$e0d8a7e0$@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: AdAP6kisMWeGMMQrRUaT2MttUQpsyw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21150.001 X-TM-AS-Result: No--0.713-10.0-31-10 X-imss-scan-details: No--0.713-10.0-31-10 X-TMASE-MatchedRID: LCb8eCaOGWC6de0YULw0Fq+dYEguu4aVGWAN/II9wcQnyZAGkQFaTqPF jJEFr+olfeZdJ1XsorgUBfgS1SLQ+AtuKBGekqUpbGVEmIfjf3t8UIw9VaIxzwiMgRJLp/Yzsnm wtwSTZDoW7gql7P4yisngZVOOIl6Uuet5r9Bdhvd06cjxY8Ylm1csa0AGV/SbwvwdumFAO/g= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Qj-ucmq5p1zPCTckVxVJu2ygNlI Subject: [mpls] Recharter and TEAS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:47:03 -0000 Hi, The IESG has just approved the creation of TEAS and the re-chartering of MPLS. Formal announcements of these changes will come out soon and I will be working with all of the chairs to ensure that documents are assigned to the right WGs and that milestones are posted. Adrian From nobody Thu Dec 4 11:37: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 7E0301A033A; Thu, 4 Dec 2014 11:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp6PXhkNkOmJ; Thu, 4 Dec 2014 11:37:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FF11A0154; Thu, 4 Dec 2014 11:37:00 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> Date: Thu, 04 Dec 2014 11:37:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eBS_w7eo-cg6qaJcOelor7DFU-s Cc: mpls@ietf.org Subject: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 19:37:01 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Updates to LDP for IPv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036 and RFC 6720. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Dec 5 04:57: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 4B90C1ACE6A for ; Fri, 5 Dec 2014 04:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_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 LzO8Ebjs0uFN for ; Fri, 5 Dec 2014 04:57:50 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069391ACE6B for ; Fri, 5 Dec 2014 04:57:50 -0800 (PST) Received: from pc6 (86.184.62.161) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 5 Dec 2014 12:57:26 +0000 Message-ID: <00b401d0108b$07065b20$4001a8c0@gateway.2wire.net> From: t.petch To: Mach Chen References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com>, <03df01d00d7a$0bce8740$4001a8c0@gateway.2wire.net> Date: Fri, 5 Dec 2014 11:58:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.62.161] X-ClientProxiedBy: AM3PR01CA038.eurprd01.prod.exchangelabs.com (10.141.191.28) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Forefront-PRVS: 04163EF38A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(37854004)(13464003)(51444003)(199003)(377454003)(189002)(51704005)(33646002)(50466002)(47776003)(77156002)(1556002)(110136001)(61296003)(42186005)(87976001)(62966003)(120916001)(97736003)(46102003)(68736005)(101416001)(116806002)(44716002)(40100003)(122386002)(93886004)(20776003)(99396003)(64706001)(62236002)(84392001)(19580395003)(19580405001)(66066001)(86362001)(105586002)(50986999)(89996001)(31966008)(107046002)(44736004)(76176999)(14496001)(50226001)(92566001)(23756003)(106356001)(4396001)(81686999)(81816999)(77096005)(21056001)(1456002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Ro1aTlQVQv4RcOnG71znbFBBEgE Cc: mpls Subject: Re: [mpls] Return Path Specified 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, 05 Dec 2014 12:57:52 -0000 Mach Yes, that is clearer now. I think that an Editorial Erratum would be in order, details below. Do you agree? Section 4.3.1 says " the recommended type value is 26." It should say " the type value is 26." Section 4 says "The Reply Path TLV contains one or more nested sub-TLVs that can be used" It should say "The Reply Path TLV contains zero or more nested sub-TLVs that can be used" Section 5.4 says "When an echo reply is received, if the Reply Mode is "Reply via Specified Path" and the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and if the return path is an MPLS LSP. The ingress LSR MUST perform FEC validation" It should say "When an echo reply is received, if the Reply Mode is "Reply via Specified Path" and the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and if the return path is an MPLS LSP, the ingress LSR MUST perform FEC validation" Section 5.4 says "When an echo reply is received with return code set to "Malformed echo request received" and the Subcode set to zero. It is possible that the egress LSR may not know the "Reply via Specified Path" Reply Mode, the operator may choose to re-perform another LSP ping by using one of the four Reply Modes defined [RFC4379]." It should say "When an echo reply is received with return code set to "Malformed echo request received" and the Subcode set to zero, it is possible that the egress LSR may not know the "Reply via Specified Path" Reply Mode; the operator may choose to re-perform another LSP ping by using one of the four Reply Modes defined in [RFC4379]." Notes: The WG commended a value of 26 to IANA for the "IPv4 RSVP Tunnel sub-TLV Type" which IANA confirmed. Leaving in the 'recommended' introduces a element of uncertainty that is best avoided. As section 4.2 correctly states, the Reply Path TLV can contain zero sub-TLVs; this brings section 4 inline. In section 5.4, the conditional clauses and the main clause have been separated by periods, not commas, which creates uncertainty as to whether or not text of the main clause has been elided. The last two I raised do not seem worthy of an erratum. Tom Petch ----- Original Message ----- From: "Mach Chen" To: "t.petch" Cc: Sent: Tuesday, December 02, 2014 9:29 AM Hi Tom, Thanks for your detail reading of the RFC. > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Monday, December 01, 2014 11:18 PM > To: Mach Chen > Cc: mpls@ietf.org > Subject: Return Path Specified > > Mach > > Some of the language in RFC7110 looks a little quirky. > > s.4.3.1 > "the recommended type value is 26" > looks like 'recommended' should have been elided post-IANA Yes, indeed. > > s.4 > "The Reply Path TLV contains one or more nested sub-TLVs that can be used" > > s.4.2 Reply Path (RP) TLV > "It is variable in length and can contain zero, one or more Target FEC sub-TLVs" > > seem to be in conflict The later is the intention and reflects final consensus, but failed to make the former align with this consensus. > > s5.4 > "When an echo reply is received, if the Reply Mode is "Reply via > Specified Path" and the Reply Path return code is "The echo reply was > sent successfully using the specified Reply Path", and if the return > path is an MPLS LSP. " > > I am left expecting a comma and a main clause (unless the remainder of the > paragraph is the main clause). Yes, there was a main clause, it was considered redundant and removed directly in a version but forgot to change the last period to a comma. > > "When an echo reply is received with return code set to "Malformed > echo request received" and the Subcode set to zero. " > > Ditto > > And, since I am at it:-) Same as above. > > s.6 > OLD > "whether the return path LSP has the destination to the initiator." > NEW > "whether the return path LSP has a destination of the initiator." > > OLD > "That means, when sending echo request, the initiator > should choose a proper source address according the specified return > path LSP to help the receiver to make the decision." > NEW > "That means, when sending an echo request, the initiator > should select a source address that helps the receiver to > find a return path." [I think!] > I am OK with the above refinement. > Sorry that this is a year late:-( Indeed. But maybe you could report corresponding erratum, that will be useful. I realize that above bugs will be reduced if there was language QA review at that time. Thanks, Mach > > Tom Petch > From nobody Fri Dec 5 06:23: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 ACF691A1BEF; Fri, 5 Dec 2014 06:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I65dGGarAzJH; Fri, 5 Dec 2014 06:23:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD9B1A1B76; Fri, 5 Dec 2014 06:22:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205142259.3251.48542.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 06:22:59 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lHX_omKVV2QHfimbc8OnkqFmGkw Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-relay-reply-06.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, 05 Dec 2014 14:23:09 -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 : Relayed Echo Reply mechanism for LSP Ping Authors : Jian Luo Lizhong Jin Thomas Nadeau George Swallow Filename : draft-ietf-mpls-lsp-ping-relay-reply-06.txt Pages : 15 Date : 2014-12-05 Abstract: In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying LSR may not have the available route to the initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying Label Switching Router (LSR) to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-relay-reply-06 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 Dec 5 07:42: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 61DE41ACEC5; Fri, 5 Dec 2014 07:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4QLcbSsx_2X; Fri, 5 Dec 2014 07:42:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DE71ACE97; Fri, 5 Dec 2014 07:42:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205154247.3527.48590.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 07:42:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/m76qyW7LBRyyMba3ZROdWCBBE9E Cc: mpls WG Subject: [mpls] WG Action: Rechartered Multiprotocol Label Switching (mpls) 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, 05 Dec 2014 15:42:50 -0000 The Multiprotocol Label Switching (mpls) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Multiprotocol Label Switching (mpls) ------------------------------------------------ Current Status: Active WG Chairs: Loa Andersson George Swallow Ross Callon Secretaries: Tarek Saad Assigned Area Director: Adrian Farrel Mailing list Address: mpls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mpls Archive: http://www.ietf.org/mail-archive/web/mpls/ Charter: The MPLS working group is responsible for standardizing technology for label switching and for the implementation of label-switched paths over packet based link-level technologies. The working group's responsibilities include procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) for MPLS systems including the necessary management objects expressed as YANG models or MIB modules. The current WG focus areas and work items are: - Maintain existing MPLS requirements, mechanisms, and protocols, as currently documented in RFCs, in coordination with other working groups that work in overlapping areas including the BESS, BFD, CCAMP, OPSAWG, PALS, SPRING, and TEAS working groups. - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE for packet networks, and LSP Ping to meet new requirements. - Document MPLS-specific aspects of traffic engineering including for multi-areas/multi-AS scenarios in cooperation with the TEAS working group. - Coordinate the work on RSVP-TE with CCAMP and TEAS. In the cases where there is an overlap, generic parts will be done by the TEAS working group, MPLS data plane specific parts will be done by the MPLS working group, and support for any other specific data planes will be done by the CCAMP working group. The TEAS working group acts as the hub for coordinating this work, and the MPLS working group will track agreements about work to be done in this working group through milestones in this charter. - Define data models for MPLS working group related solutions. YANG models and MIB modules may be considered. Coordinate with the LIME and NETMOD working groups for core YANG models. - Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications to achieve a common set of approaches and tools across the full family of MPLS applications. - Define the necessary extensions for MPLS key protocols for dual- stack and IPv6-only networks. - Document current implementation practices for MPLS load sharing. - Document mechanisms for securing MPLS protocols and data plane. - Document mechanisms for adding multi-topology support to existing MPLS protocols. - Define the necessary protection protocols and scenarios for transport profile MPLS applications - Document use cases for MPLS protocols. Milestones: Done - Submit documents from original MPLS effort to IESG Done - Framework for IP multicast over label-switched paths ready for advancement. Done - LDP fault tolerance specification ready for advancement to Proposed Standard. Done - Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done - Specification for MPLS-specific recovery ready for advancement. Done - Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards Done - Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done - Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done - Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Done - Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Done - Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Done - Submit an OAM Framework Document to the IESG for publication as an Informational RFC Done - Submit a BCP on MPLS load sharing to the IESG Done - Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Done - Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Done - Submit point to multipoint TE MIB to IESG as proposed standard Done - Submit EXP field clarification document to IESG as proposed standard Done - Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Done - Submit LDP extensions for P2MP LSPs Done - Submit MPLS security framework for publication as an informational RFC Done - Submit requirements for point-to-multipoint extensions to LDP Done - Submit draft-ietf-mpls-ldp-gtsm for publication Done - Submit draft-ietf-mpls-tp-itu-t-identifiers for publication Done - Submit draft-ietf-mpls-entropy-label for publication Done - Submit draft-ietf-mpls-tp-security-framework for publication Done - Submit draft-ietf-mpls-ipv6-pw-lsp-ping for publication Done - Submit draft-ietf-mpls-mldp-in-band-signaling for publication Done - Submit draft-ietf-mpls-tp-ethernet-addressing for publication Done - Submit draft-ietf-mpls-tp-ring-protection for publication Done - Submit draft-ietf-mpls-tp-use-cases-and-design for publication Done - Submit draft-ietf-mpls-gach-adv for publication Done - Submit draft-ietf-mpls-retire-ach-tlv for publication Done - Submit draft-ietf-mpls-tp-mip-mep-map for publication Done - Submit draft-ietf-mpls-tp-rosetta-stone for publication Done - Submit draft-ietf-mpls-ldp-dod for publication Done - Submit draft-ietf-mpls-return-path-specified-lsp-ping for publication Done - Submit draft-ietf-mpls-targeted-mldp for publication Done - Submit draft-ietf-mpls-mldp-hsmp for publication Done - Submit draft-ietf-mpls-tp-p2mp-framework for publication Done - draft-ietf-mpls-tp-psc-itu Done - Submit draft-ietf-mpls-moving-iana-registries for publication Done - Submit draft-ietf-mpls-ldp-hello-crypto-auth for publication Done - Submit draft-ietf-mpls-extended-admin-group for publication Done - Submit draft-ietf-mpls-forwardig for publication Apr 2014 - Submit draft-ietf-mpls-in-udp for publication Done - Submit draft-ietf-mpls-special-purpose-labels May 2014 - Submit draft-ietf-mpls-ldp-ipv6 for publication Done - Submit draft-ietf-mpls-ldp-applicability-label-adv for publication Done - Submit draft-ietf-mpls-lsp-ping-ttl-tlv for publication Done - Submit draft-ietf-mpls-psc-updates for publication Done - Submit draft-ietf-mpls-ldp-multi-topology for publication Jun 2014 - Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication Done - Submit draft-ietf-mpls-ldp-ip-pw-capability for publication Aug 2014 - Submit draft-ietf-mpls-tp-linear-protection-mib Done - Submit draft-ietf-mpls-smp-requirements for publication Sep 2014 - Submit draft-ietf-mpls-rsvp-egress-protection for publication Sep 2014 - Submit draft-ietf-mpls-rsvp-ingress-protection for publication Sep 2014 - Submit draft-ietf-mpls-rsvp-te-hsmp-lsp Sep 2014 - Submit draft-ietf-mpls-te-express-path Done - Submit draft-ietf-mpls-deprecate-bgp-entropy-label for publication Oct 2014 - Submit draft-ietf-mpls-seamless-mpls for publication Oct 2014 - Submit draft-ietf-mpls-mldp-node-protection for publication Done - Submit draft-ietf-mpls-mldp-in-band-wildcard-encoding for publication Done - Submit draft-ietf-mpls-pim-sm-over-mldp Nov 2014 - Submit draft-ietf-mpls-lsp-ping-relay-reply for publication Dec 2014 - Submit draft-ietf-mpls-tp-oam-id-mib for publication Dec 2014 - Submit draft-ietf-mpls-tp-te-mib for publication Dec 2014 - Submit draft-ietf-mpls-seamless-mcast for publication Jan 2015 - Submit draft-ietf-mpls-proxy-lsp-ping fpr publication Jan 2015 - Submit draft-ietf-mpls-p2mp-loose-path-reopt for publicatiion Jan 2015 - Submit draft-ietf-mpls-lsp-ping-reply-mode-simple for publication Jan 2015 - Submit draft-ietf-mpls-rfc6374-udp-return-path for publicatiion Done - Submit draft-ietf-mpls-ipv6-only-gap for publication Jan 2015 - Submit draft-ietf-mpls-lsp-ping-registry for publication From nobody Fri Dec 5 18:14: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 CD0541A8A09 for ; Fri, 5 Dec 2014 18:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnNjmEqFaScY for ; Fri, 5 Dec 2014 18:14:13 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFD41A89C7 for ; Fri, 5 Dec 2014 18:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3588; q=dns/txt; s=iport; t=1417832053; x=1419041653; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MxNyEq07s7vIPr+yFx8OTixVRfMBlsHrUh6asaqM0dY=; b=YC6Pk43EWulhd+NzVRZVAiCxQRlCv0N+nCBV/SZjlTsSc4chQRMWFaB9 ge+fv9P8p6Fg8EomBQOmalpc7jRQpWebSPq1WVekzrFJRtq0t8iaq9jdM rjOR+CVh1Oa6NbvcvUNMWELE+zFUpe4bBby87yivfUWSPKdvO7yyHbGuG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUIAEVlglStJA2N/2dsb2JhbABZgmQigS6DAcVFAYQXAhx8FgEBAQEBfYQCAQEBAwEjEUoLAgEIGgIGIAICAjAVBwkCBAEaiCoJAb8YllkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSiOdjiCbzKBFQEEjVyBaos7gxKCYIhJg2KDb4I0fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,526,1413244800"; d="scan'208";a="378030173" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 06 Dec 2014 02:14:12 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB62EC8v009621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Dec 2014 02:14:12 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 20:14:12 -0600 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "mpls@ietf.org" Thread-Topic: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt Thread-Index: AQHP3N/yKiIOeV/h40KFxRIhCU+K2Zws9IjQgFD7zwCABEGCEA== Date: Sat, 6 Dec 2014 02:14:11 +0000 Message-ID: References: <20140930184855.14746.88552.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B854360@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B8A9937@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8A9937@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.198.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IbXA7Aal83f497j_aRR---84f_g Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 02:14:15 -0000 SGkgR3JlZywNCg0KPiBtYW55IHRoYW5rcyBmb3IgeW91ciB0aG91Z2h0ZnVsIGNvbW1lbnRzIGFu ZCBhbSB0ZXJyaWJseSBzb3JyeSBpdCB0b29rIG1lDQo+IHNvIGxvbmcgdG8gZ2V0IGJhY2sgd2l0 aCByZXNvbHV0aW9uLiBQbGVhc2UgZmluZCBteSBub3RlcyBpbi1saW5lZCBhbmQNCj4gdGFnZ2Vk IGJ5IEdJTT4+Lg0KDQpbTk9CT10gVGhhbmtzIGZvciBjb25zaWRlcmluZyBteSBjb21tZW50cy4g U25pcHBpbmcgaW4gb25seSB0aG9zZSBjb21tZW50cyBJIGhhZCBzb21lIHJlc3BvbnNlcyB0by4g UGxlYXNlIGxvb2sgZm9yIFtOT0JPXSBpbi1saW5lLg0KDQo+IFBTLiBBdHRhY2hlZCBpcyB3b3Jr LWluIHByb2dyZXNzIHdpdGggdXBkYXRlcyBiYXNlZCBvbiB5b3VyIHJldmlldy4NCg0KW05PQk9d IEkgYXBwcmVjaWF0ZSB5b3UgYXR0YWNoaW5nIHRoYXQuIEkgZG8gcGxhbiB0byByZWFkIHRoZSB1 cGRhdGVkIHZlcnNpb24gc29vbiwgYnV0IGRvIGdvIGFoZWFkIHdpdGggcHVibGljYXRpb24sIHBl cmhhcHMgYWZ0ZXIgb25lIGNvbW1lbnQgYmVsb3cgaXMgY2xvc2VkIG9mZi4NCiANCj4gKDEpIElu IFNlY3Rpb24gMi4xDQo+IA0KPiDCoMKgIFR5cGljYWxseSBpbnRlcm1lZGlhdGUgbm9kZXMgc2hv dWxkIG5vdCBwcm9jZXNzIG9yIG1vZGlmeSBhbnkgb2YgdGhlDQo+IMKgwqAgT0FNIGNvbmZpZ3Vy YXRpb24gVExWcyBidXQgc2ltcGx5IGZvcndhcmQgdGhlbSB0byB0aGUgZW5kLW5vZGUuDQo+IA0K PiBTaG91bGQgYWJvdmUgInNob3VsZCBub3QiIGJlIHVwcGVyIGNhc2UgIlNIT1VMRCBOT1QiPw0K PiBHSU0+PiBJIHRoaW5rIHRoYXQgIlNIT1VMRCBOT1QiIGlzIHRvbyByZXN0cmljdGl2ZSBwYXJ0 aWN1bGFybHkgYmVjYXVzZSB0aGUNCj4gbmV4dCBzZW50ZW5jZSBsaXN0cyB0aGUgZXhjbHVzaW9u Lg0KPiBJJ3ZlIHJlLXBocmFzZWQgdGhlIHNlbnRlbmNlIHRvOg0KPiBUeXBpY2FsbHkgaW50ZXJt ZWRpYXRlIG5vZGVzIHNpbXBseSBmb3J3YXJkIE9BTSBjb25maWd1cmF0aW9uIFRMVnMgdG8gdGhl DQo+IGVuZC1ub2RlIHdpdGhvdXQgYW55IHByb2Nlc3Npbmcgb3IgbW9kaWZpY2F0aW9uLiBBdCBs ZWFzdCBvbmUgZXhjZXB0aW9uIHRvDQo+IHRoaXMgaXMgaWYgdGhlIEZNUyBzdWItVExWIGlzIHBy ZXNlbnQuDQo+IFdvdWxkIHlvdSBhZ3JlZT8NCg0KW05PQk9dIFllcyBJIGFncmVlIHdpdGggeW91 ciBwb2ludCBhbmQgdGhlIHJlcGhyYXNlZCB0ZXh0IGxvb2tzIGdvb2QuDQoNCj4gKDcpIEluIFNl Y3Rpb24gMi4yLjENCj4gDQo+IMKgwqAgUEhCOiBJZGVudGlmaWVzIHRoZSBQZXItSG9wIEJlaGF2 aW9yIChQSEIpIHRvIGJlIHVzZWQgZm9yIHBlcmlvZGljDQo+IMKgwqAgY29udGludWl0eSBtb25p dG9yaW5nIG1lc3NhZ2VzLg0KPiANCj4gUGVyaGFwcyBJIG1pc3NlZCB0aGlzLCBidXQgSSBjb3Vs ZG4ndCBmaW5kIHdoYXQgZ29lcyBpbnRvIHRoZSBQSEIgYml0cyAoMyBiaXRzKQ0KPiBhbmQgd2hh dCBiZWhhdmlvcnMgYXJlIGV4cGVjdGVkLiBDYW4geW91IGVsYWJvcmF0ZT8NCj4gR0lNPj4gUEhC LCBpbiB0aGlzIGNhc2UgYW5kIGluIDIuMi4xLsKgIEJGRCBDb25maWd1cmF0aW9uIHN1Yi1UTFYs IG1lYW50IGFzDQo+IFFvUyBzZXR0aW5nLiBBdCB0aGUgdGltZSB0aGUgZG9jdW1lbnQgd2FzIHN0 YXJ0ZWQsIGlmIEnigJltIG5vdCBtaXN0YWtlbiwgd2UNCj4gc3RpbGwgcmVmZXJyZWQgdG8gdGhl IHRocmVlIGJpdC1sb25nIGZpZWxkIGFzIEVYUCwgbm90IGFzIFRDLiBXb3VsZCBjaGFuZ2luZw0K PiBQSEIgdG8gVEMgaGVscD8NCg0KW05PQk9dIEkgc2VlLiBJbiB0aGF0IGNhc2UsIHllcyByZW5h bWluZyB0aGUgZmllbGQgZnJvbSBQSEIgdG8gVEMgaXMgYSBoZWxwZnVsIGNoYW5nZS4gSSBkbyBo YXZlIGZ1cnRoZXIgcXVlc3Rpb25zIHdoaWNoIEkgaG9wZSB3aWxsIGhlbHAgeW91IHRvIGNvb2sg dXAgbmVjZXNzYXJ5IGNoYW5nZS90ZXh0cyB0byBjbGFyaWZ5IHRoaXMgZmllbGQuDQotIEFzIGZv ciB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IsIHRoZSByZWNlaXZlciBvZiB0aGlzIFRMViBpcyB0byB1 c2UgdGhlIFRDIHZhbHVlIHNwZWNpZmllZCBpbiB0aGlzIFRMViBhcyB0aGUgVEMgdmFsdWUgaW4g dGhlIGxhYmVsIGNhcnJ5aW5nIHRyYW5zbWl0dGVkIEJGRCBwYWNrZXRzPyBJZiBzbywgaXMgdGhh dCBleHBlY3RlZCBiZWhhdmlvciBhIFNIT1VMRCBvciBNVVNUIGZvciB0aGUgcmVjZWl2ZXI/IFNI T1VMRCBpcyBwcm9iYWJseSBtb3JlIGFwcHJvcHJpYXRlLCBhcyB0aGF0IHdpbGwgYWxsb3cgYSBu b2RlIHRvIG92ZXJyaWRlIHRoZSBzdWdnZXN0ZWQgdmFsdWUgaWYvd2hlbiBuZWVkZWQgKGkuZS4s IHZpYSBjb25maWd1cmF0aW9uKS4NCi0gSXQgZG9lc24ndCBsb29rIGxpa2UgdGhlcmUncyBhbnkg d2F5IGZvciB0aGUgc2VuZGVyIG9mIHRoaXMgVExWIHRvIHNheSAieW91IGRlY2lkZSB0aGUgVEMg ZmllbGQiLiBJZiBzdWNoIGluc3RydWN0aW9uIGlzIG1vcmUgb2YgdGhlIG5vcm1hbCBtb2RlIG9m IG9wZXJhdGlvbiwgdGhlbiBwZXJoYXBzIG1vdmluZyB0aGlzIFBIQi9UQyBmaWVsZCBpbnRvIGEg U3ViLVRMViBtaWdodCBiZSBtb3JlIGFwcHJvcHJpYXRlLiANCg0KVGhhbmtzIQ0KDQotTm9ibw0K From nobody Fri Dec 5 18:17: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 9584D1A8782 for ; Fri, 5 Dec 2014 18:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHd0WRzFwB6c for ; Fri, 5 Dec 2014 18:17:20 -0800 (PST) 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 DC9A81A8A12 for ; Fri, 5 Dec 2014 18:17:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5317; q=dns/txt; s=iport; t=1417832240; x=1419041840; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Av2mIxeIfCpTHajge/mCkYWP0usiMlLgUMwp5XDk24o=; b=FTmlAE7d04qmkJ3GUOed4FQcm7X2AmvYe12RL6DqHoCEng4ugbIu+NsV 7mszN0fAtgHWUA9dd2UFzZiYMzB1xUNig32+TUt7NQkPqooX5aeFc7N7O GATqTNV9eP+xiG3FjE4KsmL8YT7nAmJ9UYEdXdOciRAAe/9B5+lcIeilJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAPllglStJA2M/2dsb2JhbABZgmQigSoEyEYBhBcCgRgWAQEBAQF9hAIBAQEEJxM/DAQCAQgRBAEBCxQJBzIUCQgBAQQBDQUIiDMB1XIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkB4xBwaDG4EVAQSNXIFqizuLUIJrg2KDb2+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,526,1413244800"; d="scan'208";a="374915133" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 06 Dec 2014 02:17:19 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sB62HIKQ008288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Dec 2014 02:17:19 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; Fri, 5 Dec 2014 20:17:18 -0600 From: "Nobo Akiya (nobo)" To: "Osborne, Eric" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAP2no76f67h7pbRmWY0LHccfco7wBIBBRA Date: Sat, 6 Dec 2014 02:17:18 +0000 Message-ID: References: <63CB93BC589C1B4BAFDB41A0A19B7ACD01049215@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACD01049215@USIDCWVEMBX08.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.198.95] 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/iNMRWlD_m_R-prUeASJge-gNsrI Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 06 Dec 2014 02:17:25 -0000 Hi Eric, Many thanks for thorough review of this document and providing constructive= comments. We will go through your comments and update the document once ot= her comments from MPLS-RT team come in. Thanks! -Nobo > -----Original Message----- > From: Osborne, Eric [mailto:eric.osborne@level3.com] > Sent: Thursday, December 04, 2014 10:56 AM > To: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; mpls- > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > Cc: mpls@ietf.org > Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath >=20 > I forgot to cc the list so I'm resending my comments on this draft. >=20 > Here is my review: >=20 > - is the document coherent? > Not really...it needs some serious copyediting. See the wall of text > below. None of my copyedit comments should be considered blockers for > WG adoption. >=20 > - is it useful? > Very much so. This mechanism will make troubleshooting easier > and proactive monitoring much better. >=20 > - is it ready for WG adoption? > Yes. It needs some cleanup but the technology seems sound. It's > certainly mature enough to be adopted by the WG. >=20 >=20 > Document comments: >=20 > This isn't a line-by-line critique and I'm not a terribly good Real Edito= r(tm) > anyways so I've tried to keep these comments general and constructive. >=20 > General: the document needs an infusion of pronouns and definite articles= . > Things like "Result raises a limitation" (sec. 1.2) should be "The result > raises.." or 'This result raises...'. I've called out some of the places= where > this needs to happen, but not all of them. >=20 > Section 1.1: s/terminologies/terms/ >=20 > Section 1.2: the first paragraph needs a rewrite, it's messy. Also, the = bullet > points that end in '...is [succeeding|failing]' should be '...have > [succeeded|failed]'. And 'With above scenario' needs to be 'With the abo= ve > scenario' or something. >=20 > Sections 3-5: These sections could use a reorg. Starting with procedures= for > using new TLVs before defining the new TLVs feels awkward. I suggest > taking sections [3,4,5] and reordering as [5,3,4]. >=20 > Section 3: This section needs a little introduction. Something like "Thi= s > section describes the handling of the new TLVs by nodes which understand > them. There are two cases - nodes which understand the TLVs but which fo= r > some reason cannot describe LAG members separately, and nodes which > both understand the new TLVs and are able to describe LAG members > separately". >=20 > Section 3.2: " The responder LSRs that understands the LAG Interface Info > TLV and > are able to describe outgoing LAG member links separately are to use > the follow procedures" > needs some singular/plural cleanup: > " A responder LSR that understands the LAG Interface Info TLV and > is able to describe outgoing LAG member links separately uses > the follow procedures" > or something like that. >=20 > Section 3.3: "Above procedures..." -> "The procedures above..." >=20 > Section 4.2: Same kind of cleanup as 3.2: "Responder LSRs that > understands.." -> "Responder LSRs which understand..." >=20 > Section 4.3: "described procedures in this section" -> "the procedures > described in this section" >=20 > Section 4.3: "following checks" -> "the following checks". Also, the err= or > case is a little confusing. The first half of the error case is actually= a success, > and I spent some time going back and forth between the first half of the > success case and the failure case to figure out whether they were differe= nt. > It would benefit from some clarifying text, perhaps something like "An er= ror > case is any case where the OAM across a LAG fails, either partial or full= y. A > partial failure is where some LAG member traversals behave as they should > and some don't, and a full failure is where no LAG member traversals > behave as they should". >=20 > Sections 5-8: no comments on the TLVs themselves, I don't know OAM well > enough to find any hidden mines here. This is for the WG to pore over. >=20 > Section 9: "As result of" -> "as a result of". Also, "additional process= ing are > required" -> "additional processing is required" >=20 > Section 11: "Authors" -> "The authors". >=20 > Appendix A: I get that this section is intended to list out problems that > aren't solved by the mechanisms in this document. It's probably worth > adding text in Section 2 that describes the limitations of the proposed > mechanism, something like "Most[*] LAGs are built from p2p links, and thu= s > router X and router X+1 have the same number of LAG members. It is > possible to build LAGs asymmetrically by using Ethernet switches in the > middle. Appendix A lists some cases which this document does not > address; if an operator deploys LAGs in a manner similar to what's shown = in > Appendix A, the mechanisms in this document may not suit them". I know > Section 2 has a bullet at the end that hints at this, but I think it shou= ld be > more explicit. >=20 >=20 > [*] I believe this to be true. I am willing to be wrong. It has happen= ed > before. >=20 >=20 >=20 >=20 >=20 >=20 > eric From nobody Fri Dec 5 20:36: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 608071A1AA8 for ; Fri, 5 Dec 2014 20:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.51 X-Spam-Level: X-Spam-Status: No, score=-16.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svmGz9AR6fKD for ; Fri, 5 Dec 2014 20:36:46 -0800 (PST) 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 980501A87B0 for ; Fri, 5 Dec 2014 20:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30669; q=dns/txt; s=iport; t=1417840606; x=1419050206; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=komZRK8Kj0lSDgCA8EhCJsJMZp+c2mhRpTezrYkBFTw=; b=c8acsDSKvNVDZVqbzBVVmvuKCMiiDvC4/vIvXzKBPEAvkE1kZ6Ckx2VI S5RfM1BR2uoKlj4O4vSreCnviIIR2OAymjmetbzqHTbUQUEyBvYwLNyj8 9ua/Pb3n3QxSBnfRnnWqJImo9G62ngmXYdr96Y4VqSkbHR1els+aVZlas A=; X-Files: IETF MPLS-TE YANG Design Discussions.ics, IETF MPLS-TE YANG Design Discussions[1].ics : 5982, 5699 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFAAuHglStJA2L/2dsb2JhbAA/GoJDQ1JYBMZPhhECgREWAQEBAQF9hAMBAQSBCQIBCEYCHxEbAQYDAgQTDogYAxINOM8SDYV1AQEBAQEBAQEBAQEBAQEBAQEBARUEjiKBSxEBNRcLhDYFj0aBb4IPhDKBaY0uhhGDb28BBIEHOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,527,1413244800"; d="ics'?scan'208,217";a="378383270" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP; 06 Dec 2014 04:36:45 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB64ajYC029296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 6 Dec 2014 04:36:45 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 22:36:45 -0600 From: "Tarek Saad (tsaad)" To: "mpls@ietf.org" Thread-Topic: IETF MPLS-TE YANG Design Discussions Thread-Index: AQHQEKowxWoKKZSdmU6mFZwemhFbj5yCC+gA Date: Sat, 6 Dec 2014 04:36:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.86.253.5] Content-Type: multipart/mixed; boundary="_005_D0A7EFE21571A1tsaadciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/egHlhQ1-_UguwfSEHRsTYpt37QM Subject: [mpls] FW: IETF MPLS-TE YANG Design Discussions 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, 06 Dec 2014 04:36:49 -0000 --_005_D0A7EFE21571A1tsaadciscocom_ Content-Type: multipart/alternative; boundary="_000_D0A7EFE21571A1tsaadciscocom_" --_000_D0A7EFE21571A1tsaadciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Attendees: Santosh Esale ; Rakesh Gandhi (rgandhi) ; Robert Sawaya (rsawaya) ; Matt Hartley (mhartley) = ; lizhenbin@huawei.com ; zengxinz= ong@huawei.com ; xufeng.liu@ericsson.com ; dhruv.dhody@huawei.com ; Vero Zhen= g ; Sam Aldrin ; Vishnu Pavan= Beeram ; jescia.chenxia@huawei.com ; Zafar Ali (zali) ; Lou Berger = ; George Swallow (swallow) ; Shah, Himanshu ; VICTOR LOPEZ ALVAREZ A group of us (from above) met on Thursday 12/4 for the first time to discu= ss MPLS TE YANG model. Below are minutes/notes. Next meeting is scheduled f= or next Wednesday 12/10. - Next steps/AIs: - Team: to check-in all existing YANG models to GitHub: https://github.= com/ietf-mpls-yang/te - Team: phase 1 to tackle links and link attributes for phase 1 * team to communicate proposed attributes over email. * in-progress model for TE links will be discussed next week - Team: to use email to send proposals - Tarek: to send an email with minutes to the WG group * include invitations for next meetings - Tarek: to schedule weekly meeting for next wednesday onwards Recording of meeting @ https://cisco.webex.com/ciscosales/lsr.php?RCID=3D7a824854ae304230ab579f697= 7974239 Meeting minutes/Notes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Meeting organization/time (do we need to meet more often?) * Meet weekly, * OK to keep Thursday 7:00pm EST * Poll for next weekly meeting Wednesday 7:00pm EST * Consideration for holidays - Scope of our work: * MPLS TE YANG model: TE base yang types TE base yang model RSVP-TE extensions to TE base yang model * MPLS Tunnels/links: Config, operational/state, notification, rpcs * Topology (proposal to handle in another effort in TEAS) - Do we need an alias to communicate/send queries? * use mpls WG alias as long as manageable (not noisy) * may create another alias to use too - Agree on tools/process: * repository in GitHub: https://github.com/ietf-mpls-yang/te * check-in all yang models to date: * tagged iet-mpls-te-(1/2/3).yang * create ietf-mpls-te.yang * to include sanitized/agreed data model to be presented at IET= F * create common draft draft-common-mpls-te-yang-model * review/commit process? * Need to converge - Divide the work into phases * ph1: TE Links: link attributes (local TE links) - Admin Groups, Extended Admin Groups (config) - SRLGs (config) - local/remote identifiers (config) - reservable bandwidth (config) - RSVP per interface properties - etc. - CAC (state) -- LSPs admitted on the link * ph2: TE Tunnels: * ph3: TE LSPs * ph4: TE Globals/templates properties - Revisit MPLS Yang module(s) hierarchy. Proposal: + ietf-mpls-base-types.yang | + -- ietf-mpls-ldp-types.yang (imports mpls-base-types) + -- ietf-mpls-te-types.yang (imports mpls-base-types) + -- ietf-mpls-te-pce-types.yang (imports mpls-base-types) + -- etc. + ietf-mpls-base.yang + -- ietf-mpls-te-base.yang (augments ietf-mpls-base.yang) + -- ietf-mpls-te-rsvp.yang (augments ietf-mpls-te-base.yang) + -- ietf-gmpls-te.yang (augments ietf-mpls-te-base.yang ? au= gments ietf-mpls-te-rsvp.yang, both ?) - encoding types (PSC, LSC, FSC, etc.)? - OTN/Optical + ietf-mpls-oam - the MPLS OAM YANG model (to augment MPLS-TE model whenever needed) - Where does MPLS data plane YANG state sit? - In respective MPLS Yang models =97 identified with data plane disting= uisher (?) - data/control plane state and data plane state may not be in sync alwa= ys (e.g. in transient post FRR) Regards, Tare --_000_D0A7EFE21571A1tsaadciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6D0D27D0FA0F6844BA703D0167B76AE1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Attendees:
Santosh Esale <sesale@juniper.net>; Rakesh Gandhi (rgandhi) <= rgandhi@cisco.com>; Robert Sawaya (rsawaya) <rsawaya@cisco.com>; M= att Hartley (mhartley) <mhartley@cisco.com>; lizhenbin@huawei.com <= ;lizhenbin@huawei.com>; zengxinzong@huawei.com <zengxinzong@huawei.co= m>; xufeng.liu@ericsson.com <xufeng.liu@ericsson.com>; dhruv.dhody@huawe= i.com <dhruv.dhody@huawei.com>; Vero Zheng <vero.zheng@huawei.com&= gt;; Sam Aldrin <aldrin.ietf@gmail.com>; Vishnu Pavan Beeram <vbee= ram@juniper.net>; jescia.chenxia@huawei.com <jescia.chenxia@huawei.co= m>; Zafar Ali (zali) <zali@cisco.com>; Lou Berger <lberger@labn.net&g= t;; George Swallow (swallow) <swallow@cisco.com>; Shah, Himanshu <= hshah@ciena.com>; VICTOR LOPEZ ALVAREZ <victor.lopezalvarez@telefonic= a.com>

A group o= f us (from above) met on Thursday 12/4 for the first time to discuss MPLS T= E YANG model. Below are minutes/notes. Next meeting is scheduled for next W= ednesday 12/10.

- Next steps/AIs:
    - Team: to check-in all existing YANG models to GitHub: = https://github.com/ietf-mpls-yang/te
    - Team: phase 1 to tackle links and link attributes for = phase 1
       * team to communicate proposed attributes o= ver email.
       * in-progress model for TE links will be di= scussed next week
    - Team: to use email to send proposals
    - Tarek: to send an email with minutes to the WG group
       * include invitations for next meetings
    - Tarek: to schedule weekly meeting for next wednesday o= nwards
 


Mee= ting minutes/Notes:
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Meeting organization/time (do we need to meet more often?)
    * Meet weekly,
    * OK to keep Thursday 7:00pm EST
    * Poll for next weekly meeting Wednesday 7:00pm EST
    * Consideration for holidays

- Scope of our work:
    * MPLS TE YANG model:
        TE base yang types
        TE base yang model
        RSVP-TE extensions to TE base yang model
    * MPLS Tunnels/links: Config, operational/state, notific= ation, rpcs
    * Topology (proposal to handle in another effort in TEAS= )

- Do we need an alias to communicate/send queries?
    * use mpls WG alias as long as manageable (not noisy)
    * may create another alias to use too

- Agree on tools/process:
    * repository in GitHub: https://github.com/ietf-mpls-yang/te
        * check-in all yang models to date:
            * tagged iet-mpls-te-(1/2/3)= .yang
        * create ietf-mpls-te.yang
            * to include sanitized/agree= d data model to be presented at IETF
        * create common draft draft-common-mpls-te= -yang-model
    * review/commit process?
        * Need to converge

- Divide the work into phases
    * ph1: TE Links:
        link attributes (local TE links)
        - Admin Groups, Extended Admin Groups (con= fig)
        - SRLGs (config)
        - local/remote identifiers (config)
        - reservable bandwidth (config)
            - RSVP per interface propert= ies
            - etc.
        - CAC (state) -- LSPs admitted on the link=

    * ph2: TE Tunnels:
    * ph3: TE LSPs
    * ph4: TE Globals/templates properties

- Revisit MPLS Yang module(s) hierarchy. Proposal:
+ ietf-mpls-base-types.yang
       |
       + -- ietf-mpls-ldp-types.yang (imports = mpls-base-types)
       + -- ietf-mpls-te-types.yang  (imp= orts mpls-base-types)
       + -- ietf-mpls-te-pce-types.yang  = (imports mpls-base-types)
       + -- etc.
+ ietf-mpls-base.yang
     + -- ietf-mpls-te-base.yang (augments ietf-mpl= s-base.yang)
              + -- ietf-mpls-te= -rsvp.yang (augments ietf-mpls-te-base.yang)
              + -- ietf-gmpls-t= e.yang (augments ietf-mpls-te-base.yang ? augments ietf-mpls-te-rsvp.yang, = both ?)
                    = - encoding types (PSC, LSC, FSC, etc.)?
                    = - OTN/Optical
+ ietf-mpls-oam
    - the MPLS OAM YANG model (to augment MPLS-TE model when= ever needed)

- Where does MPLS data plane YANG state sit?
    - In respective MPLS Yang models =97 identified with dat= a plane distinguisher (?)
    - data/control plane state and data plane state may not = be in sync always (e.g. in transient post FRR)

Regards,
Tare
--_000_D0A7EFE21571A1tsaadciscocom_-- --_005_D0A7EFE21571A1tsaadciscocom_ Content-Type: text/calendar; name="IETF MPLS-TE YANG Design Discussions.ics" Content-Description: IETF MPLS-TE YANG Design Discussions.ics Content-Disposition: attachment; filename="IETF MPLS-TE YANG Design Discussions.ics"; size=5982; creation-date="Sat, 06 Dec 2014 04:36:44 GMT"; modification-date="Sat, 06 Dec 2014 04:36:44 GMT" Content-ID: <55992C838457A141B4D6D50652CAAF0A@emea.cisco.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KUFJPRElEOi0vL01pY3Jvc29mdCBDb3Jwb3Jh dGlvbi8vT3V0bG9vayBmb3IgTWFjIE1JTUVESVIvL0VODQpNRVRIT0Q6UFVCTElTSA0KQkVHSU46 VlRJTUVaT05FDQpUWklEOkVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpDQpYLUVOVE9VUkFHRS1U WklEOjQNClgtRU5UT1VSQUdFLUNGVElNRVpPTkU6VVMvRWFzdGVybg0KQkVHSU46REFZTElHSFQN ClRaTkFNRTpEYXlsaWdodA0KUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7 QllNT05USD0zDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VUVE86LTA0MDANCkRUU1RBUlQ6 MjAxNTAzMDhUMDIwMDAwDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk5BTUU6U3Rh bmRhcmQNClJSVUxFOkZSRVE9WUVBUkxZO0lOVEVSVkFMPTE7QllEQVk9MVNVO0JZTU9OVEg9MTEN ClRaT0ZGU0VURlJPTTotMDQwMA0KVFpPRkZTRVRUTzotMDUwMA0KRFRTVEFSVDoyMDE0MTEwMlQw MjAwMDANCkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpVSUQ6NUZC REQ2RDYtRkVBOS00Mjk4LTlGQzEtQzFDQjJENTIyRDE1DQpYLUVOVE9VUkFHRV9VVUlEOjVGQkRE NkQ2LUZFQTktNDI5OC05RkMxLUMxQ0IyRDUyMkQxNQ0KRFRTVEFNUDoyMDE0MTIwNVQxODQ3MDBa DQpEVFNUQVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpIjoyMDE0MTIxMFQxOTAw MDANCkRURU5EO1RaSUQ9IkVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpIjoyMDE0MTIxMFQyMDAw MDANCkxBU1QtTU9ESUZJRUQ6MjAxNDEyMDVUMjIxNTAwWg0KU1VNTUFSWTpJRVRGIE1QTFMtVEUg WUFORyBEZXNpZ24gRGlzY3Vzc2lvbnMNCkRFU0NSSVBUSU9OOjxGZWVsIGZyZWUgdG8gZm9yd2Fy ZCB0byBvdGhlcnMgYXMgbmVlZGVkPlxuXG5cblxuUGxhY2Vob2xkZXINCiAgZm9yIHdlZWtseSBJ RVRGIE1QTFMgVEUgWUFORyBtb2RlbCBkZXNpZ24NCiAgZGlzY3Vzc2lvbnMuXG5cblxuXG5SZWdh cmRzXCxcblxuVGFyZWtcblxuVGhpcyBpcyBhIFdlYkV4IE9ubHkgbWVldGluZy4NCiAgWW91IHdp bGwgbm90IGJlIGFibGUgdG8gdXBncmFkZSB0byBhIFdlYkV4ICYgVGVsZVByZXNlbmNlDQogIG1l ZXRpbmcuXG5cblxuXG4qKioqKioqIERPIE5PVCBERUxFVEUgT1IgQ0hBTkdFIEFOWSBPRiBUSEUg VEVYVCBCRUxPVw0KICBUSElTIExJTkUgKioqKioqKiBcblxuXG5cbk1lZXRpbmcgTnVtYmVyOiAz MDIyMTUzNTYgXG5cbk1lZXRpbmcNCiAgUGFzc3dvcmQ6IFRFVEVURQ0KICBcblxuXG5cbi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gXG5cblRv DQogIGpvaW4gdGhpcyBtZWV0aW5nIChOb3cgZnJvbSBtb2JpbGUgZGV2aWNlcyEpDQogIFxuXG4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFxu XG4xLiBHbyB0bw0KICBodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjby9qLnBocD9NVElEPW0y MGNjYWI4NDgzMzczNTg1MzIzN2JhMjE1ODUwZGNmDQogYlxuXG5cblxuMi4gRW50ZXIgdGhlIG1l ZXRpbmcgcGFzc3dvcmQ6IFRFVEVURSBcblxuMy4gQ2xpY2sgJ0pvaW4gTm93Jy4NCiAgXG5cbjQu IEZvbGxvdyB0aGUgaW5zdHJ1Y3Rpb25zIHRoYXQgYXBwZWFyIG9uIHlvdXIgc2NyZWVuLg0KICBc blxuXG5cblxuXG4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogLS0tIFxuXG5BTEVSVDpUb2xsLUZyZWUgRGlhbCBSZXN0cmljdGlv bnMgZm9yICg0MDgpIGFuZCAoOTE5KSBBcmVhIENvZGVzDQogIFxuXG4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIFxuXG5c blxuVGhlIGFmZmVjdGVkIHRvbGwgZnJlZSBudW1iZXJzIGFyZTogKDg2NikgNDMyLTk5MDMgZm9y IHRoZSBTYW4NCiAgSm9zZS9NaWxwaXRhcyBhcmVhIGFuZCAoODY2KSAzNDktMzUyMCBmb3IgdGhl IFJUUCBhcmVhLiBcblxuXG5cblBsZWFzZQ0KICBkaWFsIHRoZSBsb2NhbCBhY2Nlc3MgbnVtYmVy IGZvciB5b3VyIGFyZWEgZnJvbSB0aGUgbGlzdCBiZWxvdzogXG5cbi0NCiAgU2FuIEpvc2UvTWls cGl0YXMgKDQwOCkgYXJlYTogNTI1LTY4MDAgXG5cbi0gUlRQICg5MTkpIGFyZWE6IDM5Mi0zMzMw DQogIFxuXG5cblxuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSBcblxuVG8NCiAgam9pbiB0aGUgdGVsZWNvbmZlcmVuY2Ugb25seQ0KICBcblxu LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBc blxuMS4gRGlhbA0KICBpbnRvIENpc2NvIFdlYkV4ICh2aWV3IGFsbCBHbG9iYWwgQWNjZXNzIE51 bWJlcnMgYXQNCiAgaHR0cDovL2Npc2NvLmNvbS9lbi9VUy9hYm91dC9kb2luZ19idXNpbmVzcy9j b25mZXJlbmNpbmcvaW5kZXguaHRtbCkNCiAgXG5cbjIuIEZvbGxvdyB0aGUgcHJvbXB0cyB0byBl bnRlciB0aGUgTWVldGluZyBOdW1iZXIgKGxpc3RlZCBhYm92ZSkgb3INCiAgQWNjZXNzIENvZGUg Zm9sbG93ZWQgYnkgdGhlICMgc2lnbi4gXG5cblxuXG5TYW4gSm9zZVwsIENBOg0KICArMS40MDgu NTI1LjY4MDAgXG5cblJUUDogKzEuOTE5LjM5Mi4zMzMwIFxuXG5cblxuVVMvQ2FuYWRhOg0KICAr MS44NjYuNDMyLjk5MDMgXG5cblVuaXRlZCBLaW5nZG9tOiArNDQuMjAuODgyNC4wMTE3IFxuXG5c blxuSW5kaWE6DQogICs5MS44MC40MzUwLjExMTEgXG5cbkdlcm1hbnk6ICs0OS42MTkuNjc3My45 MDAyIFxuXG5cblxuSmFwYW46DQogICs4MS4zLjU3NjMuOTM5NCBcblxuQ2hpbmE6ICs4Ni4xMC44 NTE1LjU2NjYNCiAgXG5cblxuXG5odHRwOi8vd3d3LndlYmV4LmNvbVxuXG5cblxuQ0NQOisxNDA4 NTI1NjgwMHgzMDIyMTUzNTYjDQogIFxuXG5cblxuSU1QT1JUQU5UIE5PVElDRTogVGhpcyBXZWJF eCBzZXJ2aWNlIGluY2x1ZGVzIGEgZmVhdHVyZSB0aGF0DQogIGFsbG93cyBhdWRpbyBhbmQgYW55 IGRvY3VtZW50cyBhbmQgb3RoZXIgbWF0ZXJpYWxzIGV4Y2hhbmdlZCBvciB2aWV3ZWQNCiAgZHVy aW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvblws IHlvdQ0KICBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3Ug ZG8gbm90IGNvbnNlbnQgdG8gdGhlDQogIHJlY29yZGluZ1wsIGRpc2N1c3MgeW91ciBjb25jZXJu cyB3aXRoIHRoZSBtZWV0aW5nIGhvc3QgcHJpb3IgdG8gdGhlDQogIHN0YXJ0IG9mIHRoZSByZWNv cmRpbmcgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uIFBsZWFzZSBub3RlIHRoYXQgYW55DQog IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUgc3ViamVjdCB0byBkaXNjb3ZlcnkgaW4gdGhlIGV2ZW50 IG9mDQogIGxpdGlnYXRpb24uXG4NCkxPQ0FUSU9OOndlYmV4DQpPUkdBTklaRVI6TUFJTFRPOnRz YWFkQGNpc2NvLmNvbQ0KU0VRVUVOQ0U6MQ0KUlJVTEU6RlJFUT1XRUVLTFk7Q09VTlQ9MjA7SU5U RVJWQUw9MjtCWURBWT1XRTtXS1NUPVNVDQpBVFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtS U1ZQPUZBTFNFO0NOPSJTYW50b3NoDQogIEVzYWxlIjtQQVJUU1RBVD1BQ0NFUFRFRDpNQUlMVE86 c2VzYWxlQGp1bmlwZXIubmV0DQpBVFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZB TFNFO0NOPSJSYWtlc2ggR2FuZGhpDQogIChyZ2FuZGhpKSI7UEFSVFNUQVQ9QUNDRVBURUQ6TUFJ TFRPOnJnYW5kaGlAY2lzY28uY29tDQpBVFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQ PUZBTFNFO0NOPSJSb2JlcnQgU2F3YXlhDQogIChyc2F3YXlhKSI7UEFSVFNUQVQ9TkVFRFMtQUNU SU9OOk1BSUxUTzpyc2F3YXlhQGNpc2NvLmNvbQ0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBB TlQ7UlNWUD1GQUxTRTtDTj0iTWF0dCBIYXJ0bGV5DQogIChtaGFydGxleSkiO1BBUlRTVEFUPU5F RURTLUFDVElPTjpNQUlMVE86bWhhcnRsZXlAY2lzY28uY29tDQpBVFRFTkRFRTtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPUZBTFNFO0NOPWxpemhlbmJpbkBodWF3ZWkuY29tO1BBUlRTVEFUPQ0K IE5FRURTLUFDVElPTjpNQUlMVE86bGl6aGVuYmluQGh1YXdlaS5jb20NCkFUVEVOREVFO1JPTEU9 UkVRLVBBUlRJQ0lQQU5UO1JTVlA9RkFMU0U7Q049emVuZ3hpbnpvbmdAaHVhd2VpLmNvbTtQQVJU U1RBDQogVD1ORUVEUy1BQ1RJT046TUFJTFRPOnplbmd4aW56b25nQGh1YXdlaS5jb20NCkFUVEVO REVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9RkFMU0U7Q049eHVmZW5nLmxpdUBlcmljc3Nv bi5jb207UEFSVFNUDQogQVQ9TkVFRFMtQUNUSU9OOk1BSUxUTzp4dWZlbmcubGl1QGVyaWNzc29u LmNvbQ0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTtDTj1kaHJ1di5k aG9keUBodWF3ZWkuY29tO1BBUlRTVEENCiBUPU5FRURTLUFDVElPTjpNQUlMVE86ZGhydXYuZGhv ZHlAaHVhd2VpLmNvbQ0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTtD Tj0iVmVybw0KICBaaGVuZyI7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OOk1BSUxUTzp2ZXJvLnpoZW5n QGh1YXdlaS5jb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9RkFMU0U7Q049 IlNhbQ0KICBBbGRyaW4iO1BBUlRTVEFUPU5FRURTLUFDVElPTjpNQUlMVE86YWxkcmluLmlldGZA Z21haWwuY29tDQpBVFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZBTFNFO0NOPSJW aXNobnUgUGF2YW4NCiAgQmVlcmFtIjtQQVJUU1RBVD1ORUVEUy1BQ1RJT046TUFJTFRPOnZiZWVy YW1AanVuaXBlci5uZXQNCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9RkFMU0U7 Q049amVzY2lhLmNoZW54aWFAaHVhd2VpLmNvbTtQQVJUDQogU1RBVD1ORUVEUy1BQ1RJT046TUFJ TFRPOmplc2NpYS5jaGVueGlhQGh1YXdlaS5jb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQ QU5UO1JTVlA9RkFMU0U7Q049bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7UEFSDQogVFNUQVQ9 TkVFRFMtQUNUSU9OOk1BSUxUTzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KQVRURU5ERUU7 Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTtDTj0iWmFmYXIgQWxpDQogICh6YWxpKSI7 UEFSVFNUQVQ9QUNDRVBURUQ6TUFJTFRPOnphbGlAY2lzY28uY29tDQpBVFRFTkRFRTtST0xFPVJF US1QQVJUSUNJUEFOVDtSU1ZQPUZBTFNFO0NOPSJMb3UNCiAgQmVyZ2VyIjtQQVJUU1RBVD1ORUVE Uy1BQ1RJT046TUFJTFRPOmxiZXJnZXJAbGFibi5uZXQNCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJ Q0lQQU5UO1JTVlA9RkFMU0U7Q049Ikdlb3JnZSBTd2FsbG93DQogIChzd2FsbG93KSI7UEFSVFNU QVQ9TkVFRFMtQUNUSU9OOk1BSUxUTzpzd2FsbG93QGNpc2NvLmNvbQ0KQVRURU5ERUU7Uk9MRT1S RVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTtDTj0iU2hhaCwNCiAgSGltYW5zaHUiO1BBUlRTVEFU PU5FRURTLUFDVElPTjpNQUlMVE86aHNoYWhAY2llbmEuY29tDQpBVFRFTkRFRTtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPUZBTFNFO0NOPSJWSUNUT1IgTE9QRVoNCiAgQUxWQVJFWiI7UEFSVFNU QVQ9TkVFRFMtQUNUSU9OOk1BSUxUTzp2aWN0b3IubG9wZXphbHZhcmV6QHRlbGVmb25pY2EuY29t DQpYLU1JQ1JPU09GVC1DRE8tQlVTWVNUQVRVUzpCVVNZDQpYLU1JQ1JPU09GVC1DRE8tQUxMREFZ RVZFTlQ6RkFMU0UNClgtTUlDUk9TT0ZULUNETy1JTlNUVFlQRToxDQpCRUdJTjpWQUxBUk0NCkFD VElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSRU1JTkRFUg0KVFJJR0dFUjtSRUxBVEVEPVNUQVJU Oi1QVDAwSDE1TTAwUw0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --_005_D0A7EFE21571A1tsaadciscocom_ Content-Type: text/calendar; name="IETF MPLS-TE YANG Design Discussions[1].ics" Content-Description: IETF MPLS-TE YANG Design Discussions[1].ics Content-Disposition: attachment; filename="IETF MPLS-TE YANG Design Discussions[1].ics"; size=5699; creation-date="Sat, 06 Dec 2014 04:36:44 GMT"; modification-date="Sat, 06 Dec 2014 04:36:44 GMT" Content-ID: <5C906FBE60C864438A83418996D7CD65@emea.cisco.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KUFJPRElEOi0vL01pY3Jvc29mdCBDb3Jwb3Jh dGlvbi8vT3V0bG9vayBmb3IgTWFjIE1JTUVESVIvL0VODQpNRVRIT0Q6UFVCTElTSA0KQkVHSU46 VlRJTUVaT05FDQpUWklEOkVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpDQpYLUVOVE9VUkFHRS1U WklEOjQNClgtRU5UT1VSQUdFLUNGVElNRVpPTkU6VVMvRWFzdGVybg0KQkVHSU46REFZTElHSFQN ClRaTkFNRTpEYXlsaWdodA0KUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7 QllNT05USD0zDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VUVE86LTA0MDANCkRUU1RBUlQ6 MjAxNTAzMDhUMDIwMDAwDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk5BTUU6U3Rh bmRhcmQNClJSVUxFOkZSRVE9WUVBUkxZO0lOVEVSVkFMPTE7QllEQVk9MVNVO0JZTU9OVEg9MTEN ClRaT0ZGU0VURlJPTTotMDQwMA0KVFpPRkZTRVRUTzotMDUwMA0KRFRTVEFSVDoyMDE0MTEwMlQw MjAwMDANCkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpVSUQ6RkJD Q0JDQjEtNjIxMi00MjkxLTkzQjgtOUI2QjczNUVCMDcyDQpYLUVOVE9VUkFHRV9VVUlEOkZCQ0NC Q0IxLTYyMTItNDI5MS05M0I4LTlCNkI3MzVFQjA3Mg0KRFRTVEFNUDoyMDE0MTIwNVQxODQ3MDBa DQpEVFNUQVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpIjoyMDE0MTIwNFQxOTAw MDANCkRURU5EO1RaSUQ9IkVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpIjoyMDE0MTIwNFQyMDAw MDANCkxBU1QtTU9ESUZJRUQ6MjAxNDEyMDVUMTg0NzAwWg0KU1VNTUFSWTpJRVRGIE1QTFMtVEUg WUFORyBEZXNpZ24gRGlzY3Vzc2lvbnMNCkRFU0NSSVBUSU9OOlBsYWNlaG9sZGVyIGZvciB3ZWVr bHkgSUVURiBNUExTIFRFIFlBTkcgbW9kZWwgZGVzaWduDQogIGRpc2N1c3Npb25zLlxuXG5cblxu UmVnYXJkc1wsXG5cblRhcmVrXG5cblxuXG5UaGlzIGlzIGEgV2ViRXggT25seQ0KICBtZWV0aW5n LiBZb3Ugd2lsbCBub3QgYmUgYWJsZSB0byB1cGdyYWRlIHRvIGEgV2ViRXggJiBUZWxlUHJlc2Vu Y2UNCiAgbWVldGluZy5cblxuXG5cbioqKioqKiogRE8gTk9UIERFTEVURSBPUiBDSEFOR0UgQU5Z IE9GIFRIRSBURVhUIEJFTE9XDQogIFRISVMgTElORSAqKioqKioqIFxuXG5cblxuTWVldGluZyBO dW1iZXI6IDIwMTcyNTkxOSBcblxuTWVldGluZw0KICBQYXNzd29yZDogVEVURVRFDQogIFxuXG5c blxuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSBcblxuVG8NCiAgam9pbiB0aGlzIG1lZXRpbmcgKE5vdyBmcm9tIG1vYmlsZSBkZXZpY2VzISkN CiAgXG5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0gXG5cbjEuIEdvIHRvDQogIGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2NvL2oucGhw P01USUQ9bWQ4Mzg0MmQ2M2FjZGQzYTg1NGIyYTk5MTc5OGY4NGENCiBlXG5cblxuXG4yLiBFbnRl ciB0aGUgbWVldGluZyBwYXNzd29yZDogVEVURVRFIFxuXG4zLiBDbGljayAnSm9pbiBOb3cnLg0K ICBcblxuNC4gRm9sbG93IHRoZSBpbnN0cnVjdGlvbnMgdGhhdCBhcHBlYXIgb24geW91ciBzY3Jl ZW4uDQogIFxuXG5cblxuXG5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAtLS0gXG5cbkFMRVJUOlRvbGwtRnJlZSBEaWFsIFJl c3RyaWN0aW9ucyBmb3IgKDQwOCkgYW5kICg5MTkpIEFyZWEgQ29kZXMNCiAgXG5cbi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiAgXG5cblxuXG5UaGUgYWZmZWN0ZWQgdG9sbCBmcmVlIG51bWJlcnMgYXJlOiAoODY2KSA0MzIt OTkwMyBmb3IgdGhlIFNhbg0KICBKb3NlL01pbHBpdGFzIGFyZWEgYW5kICg4NjYpIDM0OS0zNTIw IGZvciB0aGUgUlRQIGFyZWEuIFxuXG5cblxuUGxlYXNlDQogIGRpYWwgdGhlIGxvY2FsIGFjY2Vz cyBudW1iZXIgZm9yIHlvdXIgYXJlYSBmcm9tIHRoZSBsaXN0IGJlbG93OiBcblxuLQ0KICBTYW4g Sm9zZS9NaWxwaXRhcyAoNDA4KSBhcmVhOiA1MjUtNjgwMCBcblxuLSBSVFAgKDkxOSkgYXJlYTog MzkyLTMzMzANCiAgXG5cblxuXG4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIFxuXG5Ubw0KICBqb2luIHRoZSB0ZWxlY29uZmVyZW5jZSBvbmx5 DQogIFxuXG4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tIFxuXG4xLiBEaWFsDQogIGludG8gQ2lzY28gV2ViRXggKHZpZXcgYWxsIEdsb2JhbCBB Y2Nlc3MgTnVtYmVycyBhdA0KICBodHRwOi8vY2lzY28uY29tL2VuL1VTL2Fib3V0L2RvaW5nX2J1 c2luZXNzL2NvbmZlcmVuY2luZy9pbmRleC5odG1sKQ0KICBcblxuMi4gRm9sbG93IHRoZSBwcm9t cHRzIHRvIGVudGVyIHRoZSBNZWV0aW5nIE51bWJlciAobGlzdGVkIGFib3ZlKSBvcg0KICBBY2Nl c3MgQ29kZSBmb2xsb3dlZCBieSB0aGUgIyBzaWduLiBcblxuXG5cblNhbiBKb3NlXCwgQ0E6DQog ICsxLjQwOC41MjUuNjgwMCBcblxuUlRQOiArMS45MTkuMzkyLjMzMzAgXG5cblxuXG5VUy9DYW5h ZGE6DQogICsxLjg2Ni40MzIuOTkwMyBcblxuVW5pdGVkIEtpbmdkb206ICs0NC4yMC44ODI0LjAx MTcgXG5cblxuXG5JbmRpYToNCiAgKzkxLjgwLjQzNTAuMTExMSBcblxuR2VybWFueTogKzQ5LjYx OS42NzczLjkwMDIgXG5cblxuXG5KYXBhbjoNCiAgKzgxLjMuNTc2My45Mzk0IFxuXG5DaGluYTog Kzg2LjEwLjg1MTUuNTY2Ng0KICBcblxuXG5cbmh0dHA6Ly93d3cud2ViZXguY29tXG5cblxuXG5D Q1A6KzE0MDg1MjU2ODAweDIwMTcyNTkxOSMNCiAgXG5cblxuXG5JTVBPUlRBTlQgTk9USUNFOiBU aGlzIFdlYkV4IHNlcnZpY2UgaW5jbHVkZXMgYSBmZWF0dXJlIHRoYXQNCiAgYWxsb3dzIGF1ZGlv IGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBtYXRlcmlhbHMgZXhjaGFuZ2VkIG9yIHZpZXdl ZA0KICBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uXCwgeW91DQogIGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3Mu IElmIHlvdSBkbyBub3QgY29uc2VudCB0byB0aGUNCiAgcmVjb3JkaW5nXCwgZGlzY3VzcyB5b3Vy IGNvbmNlcm5zIHdpdGggdGhlIG1lZXRpbmcgaG9zdCBwcmlvciB0byB0aGUNCiAgc3RhcnQgb2Yg dGhlIHJlY29yZGluZyBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi4gUGxlYXNlIG5vdGUgdGhh dCBhbnkNCiAgc3VjaCByZWNvcmRpbmdzIG1heSBiZSBzdWJqZWN0IHRvIGRpc2NvdmVyeSBpbiB0 aGUgZXZlbnQgb2YNCiAgbGl0aWdhdGlvbi5cbg0KTE9DQVRJT046d2ViZXgNCk9SR0FOSVpFUjpN QUlMVE86dHNhYWRAY2lzY28uY29tDQpTRVFVRU5DRTo2DQpSUlVMRTpGUkVRPVdFRUtMWTtDT1VO VD0yMDtJTlRFUlZBTD0yO0JZREFZPVRIO1dLU1Q9U1UNCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJ Q0lQQU5UO1JTVlA9RkFMU0U7Q049IlNhbnRvc2gNCiAgRXNhbGUiO1BBUlRTVEFUPU5FRURTLUFD VElPTjpNQUlMVE86c2VzYWxlQGp1bmlwZXIubmV0DQpBVFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJ UEFOVDtSU1ZQPUZBTFNFO0NOPSJSYWtlc2ggR2FuZGhpDQogIChyZ2FuZGhpKSI7UEFSVFNUQVQ9 QUNDRVBURUQ6TUFJTFRPOnJnYW5kaGlAY2lzY28uY29tDQpBVFRFTkRFRTtST0xFPVJFUS1QQVJU SUNJUEFOVDtSU1ZQPUZBTFNFO0NOPSJSb2JlcnQgU2F3YXlhDQogIChyc2F3YXlhKSI7UEFSVFNU QVQ9TkVFRFMtQUNUSU9OOk1BSUxUTzpyc2F3YXlhQGNpc2NvLmNvbQ0KQVRURU5ERUU7Uk9MRT1S RVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTtDTj0iTWF0dCBIYXJ0bGV5DQogIChtaGFydGxleSki O1BBUlRTVEFUPU5FRURTLUFDVElPTjpNQUlMVE86bWhhcnRsZXlAY2lzY28uY29tDQpBVFRFTkRF RTtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZBTFNFO0NOPWxpemhlbmJpbkBodWF3ZWkuY29t O1BBUlRTVEFUPQ0KIE5FRURTLUFDVElPTjpNQUlMVE86bGl6aGVuYmluQGh1YXdlaS5jb20NCkFU VEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9RkFMU0U7Q049emVuZ3hpbnpvbmdAaHVh d2VpLmNvbTtQQVJUU1RBDQogVD1ORUVEUy1BQ1RJT046TUFJTFRPOnplbmd4aW56b25nQGh1YXdl aS5jb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9RkFMU0U7Q049eHVmZW5n LmxpdUBlcmljc3Nvbi5jb207UEFSVFNUDQogQVQ9TkVFRFMtQUNUSU9OOk1BSUxUTzp4dWZlbmcu bGl1QGVyaWNzc29uLmNvbQ0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxT RTtDTj1kaHJ1di5kaG9keUBodWF3ZWkuY29tO1BBUlRTVEENCiBUPU5FRURTLUFDVElPTjpNQUlM VE86ZGhydXYuZGhvZHlAaHVhd2VpLmNvbQ0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1GQUxTRTtDTj0iVmVybw0KICBaaGVuZyI7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OOk1BSUxU Tzp2ZXJvLnpoZW5nQGh1YXdlaS5jb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JT VlA9RkFMU0U7Q049IlNhbQ0KICBBbGRyaW4iO1BBUlRTVEFUPU5FRURTLUFDVElPTjpNQUlMVE86 YWxkcmluLmlldGZAZ21haWwuY29tDQpBVFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQ PUZBTFNFO0NOPSJWaXNobnUgUGF2YW4NCiAgQmVlcmFtIjtQQVJUU1RBVD1ORUVEUy1BQ1RJT046 TUFJTFRPOnZiZWVyYW1AanVuaXBlci5uZXQNCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5U O1JTVlA9RkFMU0U7Q049amVzY2lhLmNoZW54aWFAaHVhd2VpLmNvbTtQQVJUDQogU1RBVD1ORUVE Uy1BQ1RJT046TUFJTFRPOmplc2NpYS5jaGVueGlhQGh1YXdlaS5jb20NCkFUVEVOREVFO1JPTEU9 UkVRLVBBUlRJQ0lQQU5UO1JTVlA9RkFMU0U7Q049bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7 UEFSDQogVFNUQVQ9TkVFRFMtQUNUSU9OOk1BSUxUTzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y Zw0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTtDTj0iWmFmYXIgQWxp DQogICh6YWxpKSI7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OOk1BSUxUTzp6YWxpQGNpc2NvLmNvbQ0K QVRURU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTtDTj0iR2VvcmdlIFN3YWxs b3cNCiAgKHN3YWxsb3cpIjtQQVJUU1RBVD1ORUVEUy1BQ1RJT046TUFJTFRPOnN3YWxsb3dAY2lz Y28uY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtSU1ZQPUZBTFNFO0NOPSJTaGFo LA0KICBIaW1hbnNodSI7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OOk1BSUxUTzpoc2hhaEBjaWVuYS5j b20NClgtTUlDUk9TT0ZULUNETy1CVVNZU1RBVFVTOkJVU1kNClgtTUlDUk9TT0ZULUNETy1BTExE QVlFVkVOVDpGQUxTRQ0KWC1NSUNST1NPRlQtQ0RPLUlOU1RUWVBFOjENCkJFR0lOOlZBTEFSTQ0K QUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJFTUlOREVSDQpUUklHR0VSO1JFTEFURUQ9U1RB UlQ6LVBUMDBIMTVNMDBTDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --_005_D0A7EFE21571A1tsaadciscocom_-- From nobody Sat Dec 6 21:20: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 576001A86FA for ; Sat, 6 Dec 2014 21:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMINRtv1yKI4 for ; Sat, 6 Dec 2014 21:20:19 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21ADB1A86F9 for ; Sat, 6 Dec 2014 21:20:19 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.68.235]) (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 6DDB4180110A; Sun, 7 Dec 2014 06:20:15 +0100 (CET) Message-ID: <5483E38A.8000406@pi.nu> Date: Sun, 07 Dec 2014 13:20:10 +0800 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/rkEcK0CGUTofGsdPolCEH-hJ6cw Cc: "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: [mpls] IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath 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, 07 Dec 2014 05:20:22 -0000 Working group, The authors of draft-akiya-mpls-lsp-ping-lag-multipath has told the wg chairs the document is ready to be adopted as a working group document. The document is curretly in an MPLS-RT review. Before we start the wg adoption poll the MPLS-RT review will be concluded and the document updated. In parallel we will also do an IPR pll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-akiya-mpls-lsp-ping-lag- multipath? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Dec 7 17: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 839E21A1B17 for ; Sun, 7 Dec 2014 17:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsmctZtEZFH8 for ; Sun, 7 Dec 2014 17:07:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C201A1B1F for ; Sun, 7 Dec 2014 17:07:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMO57440; Mon, 08 Dec 2014 01:07:11 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 8 Dec 2014 01:07:10 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Mon, 8 Dec 2014 09:07:07 +0800 From: Mach Chen To: "t.petch" Thread-Topic: [mpls] Return Path Specified Thread-Index: AQHQDXoM/oPCAG8YmECFH7fEf2ElxZx7jMHwgAVwlp6AA+39sA== Date: Mon, 8 Dec 2014 01:07:07 +0000 Message-ID: References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com>, <03df01d00d7a$0bce8740$4001a8c0@gateway.2wire.net> <00b401d0108b$07065b20$4001a8c0@gateway.2wire.net> In-Reply-To: <00b401d0108b$07065b20$4001a8c0@gateway.2wire.net> 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/1W6iZG4U7T2M91f9nYSgRfj-Jvs Cc: mpls Subject: Re: [mpls] Return Path Specified 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, 08 Dec 2014 01:07:18 -0000 Hi Tom, Yes, I agree with the proposal. Thanks, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of t.petch > Sent: Friday, December 05, 2014 7:58 PM > To: Mach Chen > Cc: mpls > Subject: Re: [mpls] Return Path Specified >=20 > Mach >=20 > Yes, that is clearer now. >=20 > I think that an Editorial Erratum would be in order, details below. Do y= ou agree? >=20 > Section 4.3.1 says >=20 > " the recommended type value is 26." >=20 > It should say >=20 > " the type value is 26." >=20 > Section 4 says >=20 > "The Reply Path TLV contains one or more nested sub-TLVs that can be used= " >=20 > It should say >=20 > "The Reply Path TLV contains zero or more nested sub-TLVs that can be use= d" >=20 > Section 5.4 says >=20 > "When an echo reply is received, if the Reply Mode is "Reply via > Specified Path" and the Reply Path return code is "The echo reply was > sent successfully using the specified Reply Path", and if the return > path is an MPLS LSP. The ingress LSR MUST perform FEC validation" >=20 > It should say >=20 > "When an echo reply is received, if the Reply Mode is "Reply via > Specified Path" and the Reply Path return code is "The echo reply was > sent successfully using the specified Reply Path", and if the return > path is an MPLS LSP, the ingress LSR MUST perform FEC validation" >=20 > Section 5.4 says >=20 > "When an echo reply is received with return code set to "Malformed > echo request received" and the Subcode set to zero. It is possible > that the egress LSR may not know the "Reply via Specified Path" Reply > Mode, the operator may choose to re-perform another LSP ping by using > one of the four Reply Modes defined [RFC4379]." >=20 > It should say >=20 > "When an echo reply is received with return code set to "Malformed > echo request received" and the Subcode set to zero, it is possible > that the egress LSR may not know the "Reply via Specified Path" Reply > Mode; the operator may choose to re-perform another LSP ping by using > one of the four Reply Modes defined in [RFC4379]." >=20 > Notes: >=20 > The WG commended a value of 26 to IANA for the "IPv4 RSVP Tunnel sub-TLV > Type" which IANA confirmed. Leaving in the 'recommended' introduces a > element of uncertainty that is best avoided. >=20 > As section 4.2 correctly states, the Reply Path TLV can contain zero sub-= TLVs; this > brings section 4 inline. >=20 > In section 5.4, the conditional clauses and the main clause have been sep= arated > by periods, not commas, which creates uncertainty as to whether or not te= xt of > the main clause has been elided. >=20 > >=20 > The last two I raised do not seem worthy of an erratum. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Mach Chen" > To: "t.petch" > Cc: > Sent: Tuesday, December 02, 2014 9:29 AM >=20 > Hi Tom, >=20 > Thanks for your detail reading of the RFC. >=20 > > -----Original Message----- > > From: t.petch [mailto:ietfc@btconnect.com] > > Sent: Monday, December 01, 2014 11:18 PM > > To: Mach Chen > > Cc: mpls@ietf.org > > Subject: Return Path Specified > > > > Mach > > > > Some of the language in RFC7110 looks a little quirky. > > > > s.4.3.1 > > "the recommended type value is 26" > > looks like 'recommended' should have been elided post-IANA >=20 > Yes, indeed. >=20 > > > > s.4 > > "The Reply Path TLV contains one or more nested sub-TLVs that can be > used" > > > > s.4.2 Reply Path (RP) TLV > > "It is variable in length and can contain zero, one or more Target > FEC sub-TLVs" > > > > seem to be in conflict >=20 > The later is the intention and reflects final consensus, but failed to ma= ke the > former align with this consensus. >=20 > > > > s5.4 > > "When an echo reply is received, if the Reply Mode is "Reply via > > Specified Path" and the Reply Path return code is "The echo reply > was > > sent successfully using the specified Reply Path", and if the > return > > path is an MPLS LSP. " > > > > I am left expecting a comma and a main clause (unless the remainder of > the > > paragraph is the main clause). >=20 > Yes, there was a main clause, it was considered redundant and removed dir= ectly > in a version but forgot to change the last period to a comma. >=20 > > > > "When an echo reply is received with return code set to "Malformed > > echo request received" and the Subcode set to zero. " > > > > Ditto > > > > And, since I am at it:-) >=20 > Same as above. >=20 > > > > s.6 > > OLD > > "whether the return path LSP has the destination to the initiator." > > NEW > > "whether the return path LSP has a destination of the initiator." > > > > OLD > > "That means, when sending echo request, the initiator > > should choose a proper source address according the specified > return > > path LSP to help the receiver to make the decision." > > NEW > > "That means, when sending an echo request, the initiator > > should select a source address that helps the receiver to > > find a return path." [I think!] > > >=20 > I am OK with the above refinement. >=20 > > Sorry that this is a year late:-( >=20 > Indeed. But maybe you could report corresponding erratum, that will be us= eful. >=20 > I realize that above bugs will be reduced if there was language QA review= at that > time. >=20 > Thanks, > Mach > > > > Tom Petch > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Dec 8 07:47: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 A17321A877A for ; Mon, 8 Dec 2014 07:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdqqTYCdOHLI for ; Mon, 8 Dec 2014 07:46:58 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2DD1A8770 for ; Mon, 8 Dec 2014 07:46:57 -0800 (PST) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB291.namprd05.prod.outlook.com (10.141.23.26) with Microsoft SMTP Server (TLS) id 15.1.31.17; Mon, 8 Dec 2014 15:46:55 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.01.0031.000; Mon, 8 Dec 2014 15:46:55 +0000 From: Chris Bowers To: Gregory Mirsky , Loa Andersson , Mach Chen , "stbryant@cisco.com" Thread-Topic: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Thread-Index: AQHP8qICze265rJddE+rgb0RrQAFyZxnCKiAgBp3ErA= Date: Mon, 8 Dec 2014 15:46:55 +0000 Message-ID: References: <20141027160938.19401.5417.idtracker@ietfa.amsl.com> <544F7D57.8030609@pi.nu> <7347100B5761DC41A166AC17F22DF1121B89337A@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B89337A@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB291; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB291; x-forefront-prvs: 041963B986 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(164054003)(377454003)(13464003)(377424004)(107046002)(97736003)(92566001)(54206007)(99286002)(2656002)(106116001)(68736005)(40100003)(122556002)(74316001)(21056001)(86362001)(76176999)(19300405004)(101416001)(19609705001)(99396003)(50986999)(31966008)(4396001)(77096005)(54606007)(230783001)(120916001)(33656002)(76576001)(77156002)(87936001)(62966003)(2501002)(54356999)(19617315012)(66066001)(19580395003)(16236675004)(19625215002)(19580405001)(46102003)(20776003)(106356001)(105586002)(15975445007)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB291; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BLUPR05MB292C0E426C116D4C011D825A9640BLUPR05MB292namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qtVlbIrFhdWjiOoWpYWtvlA6V0U Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-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, 08 Dec 2014 15:47:03 -0000 --_000_BLUPR05MB292C0E426C116D4C011D825A9640BLUPR05MB292namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, Thanks for the review. Please see responses inline. From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, November 18, 2014 3:31 PM To: Loa Andersson; Mach Chen; stbryant@cisco.com Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@too= ls.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Dear Authors, MPLS WG chairs, et. al, I've been asked to review the draft-atlas-mpls-ldp-mrt-02.txt. The document is very well written, technically sound and clearly addresses = integral part of MRT-FRR solution. It is ready for the WG adoption in my opinion. Below are my comments to authors that are should not be viewed as gating th= e adoption: * section 4.1, I'd consider padding the MRT Capability TLV with ext= ra 3 octets and changing the Length field accordingly to 4; [CB] I'm not sure that I understand your suggestion here. The MRT Capabil= ity TLV we are defining is an LDP Capability Parameter TLV (as defined in s= ection 3 of RFC 5561). It carries no Capability Data. So its length is 1 = to account for the S-bit and 7 reserved bits. Are you suggesting that we a= dd 3 bytes of empty Capability Data and set the length to 4? Or did you ha= ve something else in mind? * section 4.3, a bit strange that IANA request to allocate MT-IDs f= or MRT-Red and MRT-Blue is in ietf-rtgwg-mrt-frr-architecture and not in th= is document as for Rainbow-MRT's MT-ID (section 4.2). Perhaps by grouping a= ll in one request would make it logistically easier and minimize inter-depe= ndency of the MRT-FRR documents. [CB] The reasoning behind the current placement of the IANA requests is th= e following. (Note that we'll be changing "LDP Multi-Topology (MT) ID Name = Space" to "MPLS Multi-Topology Identifiers" in the IANA section of ietf-rt= gwg-mrt-frr-architecture to match the change in naming of the IANA registry= that occurred as drafts leading to RFC7307 were revised.) The MPLS Multi-Topology Identifiers registry requests in ietf-rtgwg-mrt-frr= -architecture are for MPLS MT-IDs for MRT-Red and Blue for the Default Pro= file. The Default Profile specifies for example using the lowpoint algorit= hm to compute the GADAG. This Default Profile has MRT profile value=3D0. = It is possible that a future document could specify another MRT profile wi= th a different algorithm for computing the GADAG which we could call MRT Pr= ofile1 with MRT profile value =3D1. This new document would also need to i= nclude an IANA request to allocate values for MPLS MT-IDs for MRT-Red and B= lue for MRT Profile 1. The MPLS Multi-Topology Identifiers registry request in draft-atlas-mpls-ld= p-mrt is for the Rainbow MRT MPLS MT-ID. This MPLS MT-ID provides a way t= o identify the Rainbow MRT FEC, which provides an optimization specific to = LDP forwarding on MRTs at ABRs. The Rainbow FEC forwarding behavior is ind= ependent of the MRT Profile, so if different MRT Profiles are defined in th= e future, a new Rainbow MRT MPLS MT-ID will not need to be defined. So th= e idea is that the IANA requests in ietf-rtgwg-mrt-frr-architecture are spe= cific to the Default MRT Profile. In the supporting documents like draft-a= tlas-mpls-ldp-mrt as well as draft-li-isis-mrt and draft-atlas-ospf-mrt the= IANA requests are for values that are independent of a specific MRT profil= e. Thank you for your kind consideration. Regards, Greg -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Tuesday, October 28, 2014 4:26 AM To: Mach Chen; stbryant@cisco.com; Gregory Mirsk= y Cc: mpls-chairs@tools.ietf.org; VIGOUREU= X, MARTIN (MARTIN); draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Mach, Stewart and Greg, You have be selected as MPLS-RT reviewers for draft-atlas-mpls-ldp-mrt. Note to authors: You have been CC'd on this email so that you can know that= this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (i= e, is it likely to be actually useful in operational networks), and is the = document technically sound? We are interested in knowing whether the docum= ent is ready to be considered for WG adoption (ie, it doesn't have to be pe= rfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secreta= ry, and CC'd to the MPLS WG email list. If necessary, comments may be sent = privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document= , and what can wait until the document is a working group document and the = working group has the revision control. Are you able to review this draft by Nov 18, 2014? Please respond in a time= ly fashion. Thanks, Loa (as MPLS WG chair) -------- Original Message -------- Subject: [mpls] I-D Action: draft-atlas-mpls-ldp-mrt-02.txt Date: Mon, 27 Oct 2014 09:09:38 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gr= oup of the IETF. Title : LDP Extensions to Support Maximally Redundant Trees Authors : Alia Atlas Kishore Tiruveedhula Chris Bowers Jeff Tantsura IJsbrand Wijnands Filename : draft-atlas-mpls-ldp-mrt-02.txt Pages : 16 Date : 2014-10-27 Abstract: This document specifies extensions to LDP to support the creation of label-switched paths for Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR. The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for LSRs and LERs advertising the MRT Capability. MRT-FRR uses LDP multi-topology extensions and requires three different multi-topology IDs to be allocated from the LDP MT-ID space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-atlas-mpls-ldp-mrt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-atlas-mpls-ldp-mrt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-atlas-mpls-ldp-mrt-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_BLUPR05MB292C0E426C116D4C011D825A9640BLUPR05MB292namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg, 

 <= /p>

Thanks for the review.&nb= sp; Please see responses inline.

 <= /p>

From: mpls [= mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 18, 2014 3:31 PM
To: Loa Andersson; Mach Chen; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-= mrt@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.tx= t

 

Dear Authors, MPLS WG chairs, et. al,

I've been asked to review the draft-atl= as-mpls-ldp-mrt-02.txt.

 

The document is very well written, tech= nically sound and clearly addresses integral part of MRT-FRR solution.=

It is ready for the WG adoption in my o= pinion.

 

Below are my comments to authors that a= re should not be viewed as gating the adoption:

·         section 4.1, I'd consider paddi= ng the MRT Capability TLV with extra 3 octets and changing the Length field= accordingly to 4;

[CB]  I’m not sure that I un= derstand your suggestion here.  The MRT Capability TLV we are defining is an LDP Capability Parameter TLV (as defined in section 3 of RFC 5561).&= nbsp; It carries no Capability Data.  So its length is 1 to account fo= r the S-bit and 7 reserved bits.  Are you suggesting that we add 3 byt= es of empty Capability Data and set the length to 4?  Or did you have something else in mind?

·         section 4.3, a bit strange that= IANA request to allocate MT-IDs for MRT-Red and MRT-Blue is in ietf-rtgwg-= mrt-frr-architecture and not in this document as for Rainbow-MRT’s MT-ID (section 4.2). Perhaps by grouping all in one request would make it = logistically easier and minimize inter-dependency of the MRT-FRR documents.=

[CB]  The reasoning behind the cur= rent placement of the IANA requests is the following. (Note that we’ll be changing “LDP Multi-Topology (MT) ID Name Space”= ; to  “MPLS Multi-Topology Identifiers” in the IANA sectio= n of ietf-rtgwg-mrt-frr-architecture to match the change in naming of the I= ANA registry that occurred as drafts leading to RFC7307 were revised.)=

The MPLS Multi-Topology Identifiers reg= istry requests in ietf-rtgwg-mrt-frr-architecture are for MPLS MT-IDs  for MRT-Red and Blue for the Default Profile.  The = Default Profile specifies for example using the lowpoint algorithm to compu= te the GADAG.  This Default Profile has MRT profile value=3D0. &n= bsp; It is possible that a future document could specify another MRT profile with a different algorithm for computing the GADAG which we co= uld call MRT Profile1 with MRT profile value =3D1.  This new document = would also need to include an IANA request to allocate values for MPLS MT-I= Ds for MRT-Red and Blue for MRT Profile 1.

The MPLS Multi-Topology I= dentifiers registry request in draft-atlas-mpls-ldp-mrt is for the Rainbow = MRT MPLS MT-ID.  This MPLS  MT-ID provides a way to identify the Rainbow MRT FEC, which provides an optimization specific to LDP forwar= ding on MRTs at ABRs.  The Rainbow FEC forwarding behavior is independ= ent of the MRT Profile, so if different MRT Profiles are defined in the fut= ure, a new Rainbow MRT MPLS MT-ID will not need to be defined.   So the idea is that the IANA requests = in ietf-rtgwg-mrt-frr-architecture are specific to the Default MRT Profile.=   In the supporting documents like draft-atlas-mpls-ldp-mrt as well as= draft-li-isis-mrt and draft-atlas-ospf-mrt the IANA requests are for values that are independent of a specific MRT profil= e. 

 <= /p>

 

Thank you for your kind consideration.<= o:p>

 

      &nb= sp; Regards,

      &nb= sp;         Greg<= /p>

 

-----Original Message-----
From: Loa Andersson [mailt= o:loa@pi.nu]
Sent: Tuesday, October 28, 2014 4:26 AM
To: Mach Chen; st= bryant@cisco.com; Gregory Mirsky
Cc: mpls-= chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); draft-atlas-mpls-ldp-mrt@tools.ietf.org
Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt

 

Mach, Stewart and Greg,

 

You have be selected as MPLS-RT reviewe= rs for  draft-atlas-mpls-ldp-mrt.

 

Note to authors: You have been CC'd on = this email so that you can know that this review is going on. However, plea= se do not review your own document.

 

Reviews should comment on whether the d= ocument is coherent, is it useful (ie, is it likely to be actually useful i= n operational networks), and is the document technically sound?  We are interested in knowing whether the document is ready to= be considered for WG adoption (ie, it doesn't have to be perfect at this p= oint, but should be a good start).

 

Reviews should be sent to the document = authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list.= If necessary, comments may be sent privately to only the WG chairs.

 

If you have technical comments you shou= ld try to be explicit about what

*really* need to be resolved before ado= pting it as a working group document, and what can wait until the document = is a working group document and the working group has the revision control.

 

Are you able to review this draft by No= v 18, 2014? Please respond in a timely fashion.

 

 

Thanks, Loa

(as MPLS WG chair)

 

 

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

Subject: [mpls] I-D Action: draft-atlas= -mpls-ldp-mrt-02.txt

Date: Mon, 27 Oct 2014 09:09:38 -0700

 

 

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.=

 

      &nb= sp;  Title          = : LDP Extensions to Support Maximally Redundant

Trees

      &nb= sp;  Authors         : Alia At= las

      &nb= sp;            =         Kishore Tiruveedhula<= /span>

      &nb= sp;            =         Chris Bowers

      &nb= sp;            =         Jeff Tantsura<= /p>

      &nb= sp;            =         IJsbrand Wijnands

      &nb= sp; Filename        : draft-atlas-mpls-l= dp-mrt-02.txt

      &nb= sp; Pages           : 16<= o:p>

      &nb= sp; Date            = : 2014-10-27

 

Abstract:

    This document specif= ies extensions to LDP to support the creation of

    label-switched paths= for Maximally Redundant Trees (MRT).  A prime

    use of MRTs is for u= nicast and multicast IP/LDP Fast-Reroute, which

    we will refer to as = MRT-FRR.

 

    The sole protocol ex= tension to LDP is simply the ability to advertise

    an MRT Capability.&n= bsp; This document describes that extension and the

    associated behavior = expected for LSRs and LERs advertising the MRT

    Capability.

 

    MRT-FRR uses LDP mul= ti-topology extensions and requires three

    different multi-topo= logy IDs to be allocated from the LDP MT-ID

    space.

 

 

The IETF datatracker status page for th= is draft is:

 

There's also a htmlized version availab= le at:

 

A diff from the previous version is ava= ilable at:

 

 

Please note that it may take a couple o= f minutes from the time of submission until the htmlized version and diff a= re available at tools.ietf.org.

 

Internet-Drafts are also available by a= nonymous FTP at:

 

_______________________________________= ________

mpls mailing list

 

 

 

--_000_BLUPR05MB292C0E426C116D4C011D825A9640BLUPR05MB292namprd_-- From nobody Mon Dec 8 07:47: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 25E141A90D7 for ; Mon, 8 Dec 2014 07:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziRvu_N0WQav for ; Mon, 8 Dec 2014 07:47:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:705]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B07A1A90D1 for ; Mon, 8 Dec 2014 07:47:19 -0800 (PST) Received: from BLUPR05MB289.namprd05.prod.outlook.com (10.141.23.19) by BLUPR05MB037.namprd05.prod.outlook.com (10.255.210.145) with Microsoft SMTP Server (TLS) id 15.1.31.17; Mon, 8 Dec 2014 15:46:57 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB289.namprd05.prod.outlook.com (10.141.23.19) with Microsoft SMTP Server (TLS) id 15.1.31.17; Mon, 8 Dec 2014 15:46:56 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.01.0031.000; Mon, 8 Dec 2014 15:46:56 +0000 From: Chris Bowers To: "stbryant@cisco.com" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , 'Martin Vigoureux' Thread-Topic: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt Thread-Index: AQHP93e30VTGyfrvjEyHETM/OX7+QZyB4PCA Date: Mon, 8 Dec 2014 15:46:56 +0000 Message-ID: References: <545799DB.6010402@cisco.com> In-Reply-To: <545799DB.6010402@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB289;UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB289; x-forefront-prvs: 041963B986 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(377454003)(107046002)(19625215002)(40100003)(16236675004)(77156002)(2201001)(66066001)(76176999)(4396001)(19300405004)(54206007)(50986999)(54356999)(122556002)(74316001)(21056001)(120916001)(2656002)(99396003)(20776003)(101416001)(106356001)(92566001)(105586002)(106116001)(33656002)(86362001)(87936001)(46102003)(99286002)(19580395003)(19580405001)(31966008)(62966003)(97736003)(54606007)(2501002)(68736005)(230783001)(102836002)(77096005)(76576001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB289; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BLUPR05MB292FBB73AE8BFF4DD008374A9640BLUPR05MB292namprd_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB037; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Mn8mXZMzXcGbnz1A3nxh9uFEjDQ Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 15:47:30 -0000 --_000_BLUPR05MB292FBB73AE8BFF4DD008374A9640BLUPR05MB292namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, Thanks for the feedback on the text. Please see responses inline From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Monday, November 03, 2014 9:06 AM To: draft-atlas-mpls-ldp-mrt@tools.ietf.org; mpls-chairs@tools.ietf.org; 'M= artin Vigoureux' Cc: mpls@ietf.org Subject: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt This draft is a support draft for the work on MRT that is being led in RTGWG. I have concerns about whether or not MRT technology has the maturity expected in the standards track. However that decision needs to be taken in RTGWG and MPLS needs to follow their and lead in determining the fate and track of this draft. This draft should not be published ahead of the drafts that define the technology that it is supporting. That said, the draft is well written and I cannot see any reason why it should not be put forward for adoption as an MPLS WG draft. I have some minor comments below which should be looked at when the draft is next revised. - Stewart =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LDP Extensions to Support Maximally Redundant Trees draft-atlas-mpls-ldp-mrt-02 1. Introduction IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and node failures in an arbitrary network topology where the failure doesn't split the network. It can also be deployed incrementally; an SB> NIT isn't the more common term partition the network? [CB] agreed. MRT Island is formed of connected supporting routers and the MRTs are computed inside that island. 3. Terminology For ease of reading, some of the terminology defined in [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. SB> Minor point - repeating definitions means you you need SB> to track the definitions in multiple drafts in the design SB> and publication phase. I appreciate the convenience, but SB> you should think hard about whether to retain this. [CB] Good point. I will see if anyone else has strong opinions on keeping = this section. Redundant Trees (RT): A pair of trees where the path from any node X to the root R along the first tree is node-disjoint with the path from the same node X to the root along the second tree. These can be computed in 2-connected graphs. Maximally Redundant Trees (MRT): A pair of trees where the path from any node X to the root R along the first tree and the path from the same node X to the root along the second tree share the minimum number of nodes and the minimum number of links. Each such shared node is a cut-vertex. Any shared links are cut-links. Any RT is an MRT but many MRTs are not RTs. The two MRTs are referred to as MRT-Blue and MRT-Red. MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used to described the associated forwarding topology and MT-ID. Specifically, MRT-Red is the decreasing MRT where links in the GADAG are taken in the direction from a higher topologically ordered node to a lower one. SB> Minor point - you should expand and reference GADAG [CB] Agreed. If we decide to keep the terminology section in this draft, = then I will add GADAG as well. 4. Overview of LDP Signaling Extensions for MRT SB> Nit - there is an English problem between the into para below SB> and the list that follows. It does not scan from the intro to SB> each member of the list. [CB] Agreed. I have reworded the intro and the list items to read better,= to be included in the next update. Routers need to know which of their neighbors support MRT. Supporting MRT indicates several different aspects of behavior, as listed below. 1. Support for Multi-Topology (MT) - this MAY also be indicated via the Multi-Topology LDP Capability [RFC7307]. 2. Understand the Rainbow MRT MT-ID and apply the associated labels to all relevant MT-IDs. 3. Advertise the Rainbow MRT MT-ID to the appropriate neighbors for the associated prefix. 4. If acting as LDP egress for a prefix in the default topology, also advertise and act as egress for the same prefix in MRT-Red and MRT-Blue. 5. For a FEC learned from a neighbor that does not support MRT, originate FECS for MRT-Red and MRT-Blue with the same prefix. SB> Nit s/FECS/FECs/ [CB] Agreed. This MRT Island egress behavior is to support an MRT Island that does not include all routers in the area/level. 4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 An LSR which advertises the MRT LDP capability is expected to advertise MRT-related FEC-label bindings for both IPv4 and IPv6 address families, if the LSR originates shortest-path FEC-label bindings for those address families. SB> Surely the rule is that the you advertise bindings for the SB> set of address families you support. That makes you IPv4 and/or SB> IPv6 and/or IPvn agnostic. [CB] The issue that this sentence intends to address is the following. Su= ppose that someone wants to run a network with IPv4 and IPv6 with LDP for b= oth IPv4 and IPv6, but only wants to run MRT for the IPv4 FECs (for some un= specified reason). The LDP MRT Capability Advertisement defined in this do= cument does not distinguish between IPv4 and IPv6, so this scenario is not = supported. We considered adding a mechanism to distinguish between IPv4 a= nd IPv6 MRT LDP Capability, but decided that supporting the scenario above = was not worth the added complexity. If the WG has a different opinion, we= can revisit this. Do this make sense, or would you suggest additional tex= t to clarify? --_000_BLUPR05MB292FBB73AE8BFF4DD008374A9640BLUPR05MB292namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart,

 <= /p>

Thanks for the feedback o= n the text.  Please see responses inline

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, November 03, 2014 9:06 AM
To: draft-atlas-mpls-ldp-mrt@tools.ietf.org; mpls-chairs@tools.ietf.= org; 'Martin Vigoureux'
Cc: mpls@ietf.org
Subject: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt

 

This draft is a support draft for the work on MRT that is being <=
/o:p>
led in RTGWG.
 
I have concerns about whether or not MRT technology has the  matu=
rity 
expected in the standards track. However that decision needs to be 
taken in RTGWG and MPLS needs to follow their and lead in determining =

the fate and track of this draft. This draft should not be published <=
o:p>
ahead of the drafts that define the technology that it is supporting.<=
o:p>
 
That said, the draft is well written and I cannot see any <=
/pre>

reason why it should not be put forward for adoption as 

an MPLS WG draft.


 


I have some minor comments below which should be looked at when


the draft is next revised.


 


 


- Stewart


 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


 


 


 


 


          LDP Extensions =
to Support Maximally Redundant Trees


           &nbs=
p;          draft-atlas-mpls-l=
dp-mrt-02


 


 


 


1.  Introduction


 


 


 


   IP/LDP Fast-Reroute using MRTs can provide 100% coverage =
for link and


   node failures in an arbitrary network topology where the =
failure


   doesn't split the network.  It can also be deployed =
incrementally; an


 


SB> NIT isn't the more common term partition the network?


[CB]  agreed.


 


   MRT Island is formed of connected supporting routers and =
the MRTs are


   computed inside that island.


 


 


3.  Terminology


 


   For ease of reading, some of the terminology defined in


   [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here.


 


SB> Minor point - repeating definitions means you you need


SB> to track the definitions in multiple drafts in the design<=
/o:p>


SB> and publication phase. I appreciate the convenience, but


SB> you should think hard about whether to retain this.<=
/pre>

 


[CB] Good point.  I will see if anyone=
 else has strong opinions on keeping this section.


 


 Redundant Trees (RT):   A pair of trees where the path=
 from any node


      X to the root R along the first tree is=
 node-disjoint with the


      path from the same node X to the root a=
long the second tree.


      These can be computed in 2-connected gr=
aphs.


 


   Maximally Redundant Trees (MRT):   A pair of tr=
ees where the path


      from any node X to the root R along the=
 first tree and the path


      from the same node X to the root along =
the second tree share the


      minimum number of nodes and the minimum=
 number of links.  Each


      such shared node is a cut-vertex. =
 Any shared links are cut-links.


      Any RT is an MRT but many MRTs are not =
RTs.  The two MRTs are


      referred to as MRT-Blue and MRT-Red.


 


   MRT-Red:   MRT-Red is used to describe one of t=
he two MRTs; it is


      used to described the associated forwar=
ding topology and MT-ID.


      Specifically, MRT-Red is the decreasing=
 MRT where links in the


      GADAG are taken in the direction from a=
 higher topologically


      ordered node to a lower one.=



 


SB> Minor point - you should expand and reference GADAG<=
/pre>

[CB]  Agreed.  If we decide to ke=
ep the terminology section in this draft, then I will add GADAG as well.&nb=
sp; 


 


 


4.  Overview of LDP Signaling Extensions for MRT


 


SB> Nit - there is an English problem between the into para below


SB> and the list that follows. It does not scan from the intro to


SB> each member of the list.


 


[CB]  Agreed.  I have reworded th=
e intro and the list items to read better, to be included in the next updat=
e. 


 


   Routers need to know which of their neighbors support MRT=
.


   Supporting MRT indicates several different aspects of beh=
avior, as


   listed below.


 


   1.  Support for Multi-Topology (MT) - this MAY also =
be indicated via


       the Multi-Topology LDP Capability=
 [RFC7307].


 


   2.  Understand the Rainbow MRT MT-ID and apply the a=
ssociated labels


       to all relevant MT-IDs.


 


   3.  Advertise the Rainbow MRT MT-ID to the appropria=
te neighbors for


       the associated prefix.=



 


   4.  If acting as LDP egress for a prefix in the defa=
ult topology,


       also advertise and act as egress =
for the same prefix in MRT-Red


       and MRT-Blue.


 


   5.  For a FEC learned from a neighbor that does not =
support MRT,


       originate FECS for MRT-Red and MR=
T-Blue with the same prefix.


SB> Nit s/FECS/FECs/


[CB]  Agreed.  =



       This MRT Island egress behav=
ior is to support an MRT Island that


       does not include all routers in t=
he area/level.


 


 


4.1.1.  Interaction of LDP MRT Capability with IPv4 and IPv6=



 


   An LSR which advertises the MRT LDP capability is expecte=
d to


   advertise MRT-related FEC-label bindings for both IPv4 an=
d IPv6


   address families, if the LSR originates shortest-path FEC=
-label


   bindings for those address families.


 


SB> Surely the rule is that the you advertise bindings for the=



SB> set of address families you support. That makes you IPv4 and/or=



SB> IPv6 and/or IPvn agnostic.


 


[CB]  The issue that this sentence int=
ends to address is the following.  Suppose that someone wants to run a=
 network with IPv4 and IPv6 with LDP for both IPv4 and IPv6, but only wants=
 to run MRT for the IPv4 FECs (for some unspecified reason).  The LDP =
MRT Capability Advertisement defined in this document does not distinguish =
between IPv4 and IPv6, so this scenario is not supported.  We consider=
ed  adding a mechanism to distinguish between IPv4 and IPv6 MRT LDP Ca=
pability, but decided that supporting the scenario above was not  wort=
h the added complexity.  If the WG has a different opinion, we can rev=
isit this.  Do this make sense, or would you suggest additional text t=
o clarify?
--_000_BLUPR05MB292FBB73AE8BFF4DD008374A9640BLUPR05MB292namprd_-- From nobody Mon Dec 8 08:57: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 772011AC3C4 for ; Mon, 8 Dec 2014 08:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys6gs2U22bMr for ; Mon, 8 Dec 2014 08:57:23 -0800 (PST) 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 3B4E81AC3B8 for ; Mon, 8 Dec 2014 08:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1466; q=dns/txt; s=iport; t=1418057843; x=1419267443; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lWvairtiwXx3xAnMhkdzHJR5tZzINAVc4a0JWK1vKIQ=; b=N9HOhi5TXUZHZPwAqNQ8gLpB1z03DG8v+LVm3D2D+msflyKBAM9mLvSf o4T/8EP4ISkRpciRgwZpClzeeq4OFWsMzPb4ZIvnC7lZ0PduPdsfxs0Ps 4kN9vck5vMHDiBtlTWKWYJcRLAAbkEq/btx4isW3QrPF9FW99rRm0H2QQ A=; X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="261764707" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Dec 2014 16:57:21 +0000 Received: from [64.103.108.105] (dhcp-bdlk10-data-vlan301-64-103-108-105.cisco.com [64.103.108.105]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sB8GvLIA024716; Mon, 8 Dec 2014 16:57:21 GMT Message-ID: <5485D873.5070105@cisco.com> Date: Mon, 08 Dec 2014 16:57:23 +0000 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: Chris Bowers , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "'Martin Vigoureux'" References: <545799DB.6010402@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/Kct7eG7Qm4o1wddsY0IXHTIDcK0 Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt 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: Mon, 08 Dec 2014 16:57:25 -0000 On 08/12/2014 15:46, Chris Bowers wrote: > > 4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 > > An LSR which advertises the MRT LDP capability is expected to > advertise MRT-related FEC-label bindings for both IPv4 and IPv6 > address families, if the LSR originates shortest-path FEC-label > bindings for those address families. > > SB> Surely the rule is that the you advertise bindings for the > SB> set of address families you support. That makes you IPv4 and/or > SB> IPv6 and/or IPvn agnostic. > > [CB] The issue that this sentence intends to address is the following. Suppose that someone wants to run a network with IPv4 and IPv6 with LDP for both IPv4 and IPv6, but only wants to run MRT for the IPv4 FECs (for some unspecified reason). The LDP MRT Capability Advertisement defined in this document does not distinguish between IPv4 and IPv6, so this scenario is not supported. We considered adding a mechanism to distinguish between IPv4 and IPv6 MRT LDP Capability, but decided that supporting the scenario above was not worth the added complexity. If the WG has a different opinion, we can revisit this. Do this make sense, or would you suggest additional text to clarify? Hi Chris I think that needs re-wording since we have to be able to cope with IPv4 only, IPv4+IPv6 and in the future IPv6 only. As you have written the text it's not clear to me that we support that. - Stewart From nobody Mon Dec 8 09:05: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 EFBCF1AC3EA for ; Mon, 8 Dec 2014 09:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69YQRW7kn85I for ; Mon, 8 Dec 2014 09:05:20 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5F21AC3E9 for ; Mon, 8 Dec 2014 09:05:19 -0800 (PST) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail21.telekom.de with ESMTP; 08 Dec 2014 18:05:17 +0100 X-IronPort-AV: E=Sophos;i="5.07,539,1413237600"; d="scan'208";a="180578329" Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 08 Dec 2014 18:05:16 +0100 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.13]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 8 Dec 2014 18:05:16 +0100 From: To: , , , , Date: Mon, 8 Dec 2014 18:05:15 +0100 Thread-Topic: MPLS-RT review of draft-esale-mpls-app-aware-tldp Thread-Index: AdAHuenYxQLa2WB8SbCAkirzugDBcwLSDIcQ Message-ID: References: <5472E0DF.5080109@pi.nu> In-Reply-To: <5472E0DF.5080109@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Ni6MWOYpOKOOEqkmbRBGORmFAl8 Cc: mpls@ietf.org, lizho.jin@gmail.com Subject: Re: [mpls] MPLS-RT review of draft-esale-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 17:05:23 -0000 Hi, I was asked to perform a review of your individual internet draft draft-esa= le-mpls-app-aware-tldp. I have reviewed version -02 of your draft. The document expresses the demand to signal the application capabilities of= a targeted LDP (tLDP) session in the session setup phase and in a session = re-negotiation phase. It specifies the encoding and the procedures applicab= le for tLDP sessions to negotiate the targeted application capabilities (TA= C). The applications are the "purpose" of the label binding (e.g. LDPv4 or = v6 tunneling, Remote LFA or FEC128/129 PW). The proposed procedures satisfy available security and operational concerns= , that LDP peers have to setup a tLDP session without the knowledge about i= ts application (by configuration). Its implementation is useful (and requir= ed) in operational networks, especially in tLDP deployments without complet= e configured tLDP on both ends. We have had the same problem in our network= . The document describes the backward compatible behavior with LSR without th= e support of the procedures specified. I think the document is coherent and ready to be adopted by the WG. It desc= ribes the need (section 1) and its implementation (section 2 to 6) and expl= ains some use cases (section 7). I have some minor editorial comments, which I will send in a separate mail. Regards Thomas=20 -----Urspr=FCngliche Nachricht----- Von: Loa Andersson [mailto:loa@pi.nu]=20 Gesendet: Montag, 24. November 2014 08:40 An: tsaad@cisco.com; Beckhaus, Thomas; Lizhong Jin Cc: draft-esale-mpls-app-aware-tldp@tools.ietf.org; mpls-chairs@tools.ietf.= org; VIGOUREUX, MARTIN (MARTIN) Betreff: MPLS-RT review of draft-esale-mpls-app-aware-tldp Tarek, Thomas and Lizhong, You have be selected as MPLS-RT reviewers for draft-esale-mpls-app- aware-t= ldp. Note to authors: You have been CC'd on this email so that you can know that= this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (i= e, is it likely to be actually useful in operational networks), and is the = document technically sound? We are interested in knowing whether the docum= ent is ready to be considered for WG adoption (ie, it doesn't have to be pe= rfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secreta= ry, and CC'd to the MPLS WG email list. If necessary, comments may be sent = privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document= , and what can wait until the document is a working group document and the = working group has the revision control. Are you able to review this draft by Dec 9, 2014? Please respond in a timel= y fashion. Thanks, Loa (as MPLS WG chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 8 09:38: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 196AE1A6F98 for ; Mon, 8 Dec 2014 09:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S16bmAzZdIb for ; Mon, 8 Dec 2014 09:38:21 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDB51A1BF9 for ; Mon, 8 Dec 2014 09:38:21 -0800 (PST) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB291.namprd05.prod.outlook.com (10.141.23.26) with Microsoft SMTP Server (TLS) id 15.1.31.17; Mon, 8 Dec 2014 17:38:19 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.01.0031.000; Mon, 8 Dec 2014 17:38:19 +0000 From: Chris Bowers To: "stbryant@cisco.com" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , 'Martin Vigoureux' Thread-Topic: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt Thread-Index: AQHP93e30VTGyfrvjEyHETM/OX7+QZyB4PCAgARAM4CAAAoTYA== Date: Mon, 8 Dec 2014 17:38:19 +0000 Message-ID: References: <545799DB.6010402@cisco.com> <5485D873.5070105@cisco.com> In-Reply-To: <5485D873.5070105@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB291; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB291; x-forefront-prvs: 041963B986 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174003)(377454003)(13464003)(51444003)(199003)(51704005)(24454002)(189002)(77156002)(87936001)(76576001)(2501002)(62966003)(54606007)(230783001)(33656002)(120916001)(50986999)(4396001)(31966008)(99396003)(77096005)(106356001)(20776003)(102836002)(105586002)(66066001)(54356999)(19580405001)(46102003)(19580395003)(106116001)(2656002)(92566001)(107046002)(97736003)(99286002)(54206007)(68736005)(101416001)(86362001)(76176999)(21056001)(40100003)(2201001)(122556002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB291; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; 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/-xKtIKVueROChe-RQyFiRfyFG0c Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 17:38:23 -0000 Stewart, Thanks. I've added the following text to clarify. Tell me if this works. Chris 4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 The MRT LDP Capability Advertisement does not distinguish between IPv4 and IPv6 address families. An LSR which advertises the MRT LDP capability is expected to advertise MRT-related FEC-label bindings for the same address families for which it advertises shortest-path FEC-label bindings. Therefore, an LSR advertising MRT LDP capability and shortest path FEC-label bindings for IPv4 only (or IPv6 only) would be expected to advertise MRT-related FEC-label binding for IPv4 only (or IPv6 only). An LSR advertising the MRT LDP capability and shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. In this scenario, advertising MRT-related FEC-label bindings only for IPv4 only (or only for IPv6) is not supported. -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Monday, December 08, 2014 10:57 AM To: Chris Bowers; draft-atlas-mpls-ldp-mrt@tools.ietf.org; mpls-chairs@tool= s.ietf.org; 'Martin Vigoureux' Cc: mpls@ietf.org Subject: Re: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt On 08/12/2014 15:46, Chris Bowers wrote: > =20 > 4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 > =20 > An LSR which advertises the MRT LDP capability is expected to > advertise MRT-related FEC-label bindings for both IPv4 and IPv6 > address families, if the LSR originates shortest-path FEC-label > bindings for those address families. > =20 > SB> Surely the rule is that the you advertise bindings for the set of=20 > SB> address families you support. That makes you IPv4 and/or > SB> IPv6 and/or IPvn agnostic. > =20 > [CB] The issue that this sentence intends to address is the following. = Suppose that someone wants to run a network with IPv4 and IPv6 with LDP for= both IPv4 and IPv6, but only wants to run MRT for the IPv4 FECs (for some = unspecified reason). The LDP MRT Capability Advertisement defined in this = document does not distinguish between IPv4 and IPv6, so this scenario is no= t supported. We considered adding a mechanism to distinguish between IPv4= and IPv6 MRT LDP Capability, but decided that supporting the scenario abov= e was not worth the added complexity. If the WG has a different opinion, = we can revisit this. Do this make sense, or would you suggest additional t= ext to clarify? Hi Chris I think that needs re-wording since we have to be able to cope with IPv4 only, IPv4+IPv6 and in the future IPv6 only. As you have written the t= ext it's not clear to me that we support that. - Stewart From nobody Mon Dec 8 10:59: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 037BA1A879C for ; Mon, 8 Dec 2014 10:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxoW2muXOiiJ for ; Mon, 8 Dec 2014 10:59:21 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CDA1A0047 for ; Mon, 8 Dec 2014 10:59:21 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.156.138]) (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 0CDC2180006E; Mon, 8 Dec 2014 19:59:17 +0100 (CET) Message-ID: <5485F500.1010103@pi.nu> Date: Tue, 09 Dec 2014 02:59:12 +0800 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" References: <92cfc78ef38f4e9aa6d8345353afe746@BY1PR0501MB1430.namprd05.prod.outlook.com> In-Reply-To: <92cfc78ef38f4e9aa6d8345353afe746@BY1PR0501MB1430.namprd05.prod.outlook.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/U_fIx_QLL01dtkBtYV16DZ0Jhmo Cc: "'draft-ietf-mpls-in-udp@tools.ietf.org'" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 18:59:24 -0000 Working Group, Since Ross during the process to shepherd this document also became a co-author I've taken over as Document Shepherd. First, this wglc is closed. There has been at least one comment that need to be discussed. Second, we have done an earlier IPR poll, so far so good, but since we late in the process have added two co-authors I want them to respond whether or not they are aware of any other IPRs than those that have been disclosed. /Loa mpls wg co-chair On 2014-11-24 05:28, Ross Callon wrote: > Working Group, > > This is to start a two week Working Group last call on > draft-ietf-mpls-in-udp-07.txt. > > Please send your comments to the mpls working group mailing list > (mpls@ietf.org ). > > Please send both technical comments, and (if you are happy with the > document as is) > > also send indications of support. > > You will recall that this document passed WG last call more than a year > ago. However, the > > subsequent IETF last call (in January 2014) resulted in a lengthy > discussion, particularly over > > issues related to congestion and to the use (or non-use) of the UDP > checksum with IPv6. > > After discussions in the March and July meetings this year (in London > and Toronto, > > respectively), a design team was formed to come up with improved text > related to > > congestion control and checksum use. The document has been updated > significantly and > > the changes were presented at the recent IETF meeting in Honolulu, in > both MPLS and > > TSVWG WGs. > > There is one IPR claim that applies to this draft, which can be seen at: > > https://datatracker.ietf.org/ipr/1941/ > > The coauthors and contributor have indicated that they don’t know of any > other > > IPR applicable to this draft. If anyone else in the working group is > aware of IPR > > claims against this draft, the time to disclose that is now. > > This working group last call will end on December 8, 2014. > > Ross > > for the wg co-chairs > > PS: Please also note that if you look at an earlier version of the > document on the IETF > > tools web site, due to some sort of glitch in the tools server there is > not a place to click > > under “version” at the top of the page to get version 7. However, the > correct version is > > available at both https://tools.ietf.org/html/draft-ietf-mpls-in-udp-07 > and also on the > > datatracker at https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 8 11:06: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 5A4DF1A8822 for ; Mon, 8 Dec 2014 11:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFQi2LaNh0Wc for ; Mon, 8 Dec 2014 11:06:28 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665551A8826 for ; Mon, 8 Dec 2014 11:06:27 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB8J6Ol7002710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2014 14:06:26 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com sB8J6Ol7002710 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418065586; bh=WXlSL+Sca38HSNSg4BMcfTAi0yU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ESDmo91dLx16pARNrVNiEr0dqVjrgkAwN3tKCMExs0oa8XdhPYxSB4oUKKK8d16n3 D3LQGLvitG3jOZx/yfuFaXN5PAIuIuL8KZL6kKommWby/WUv8P+Q+hF6l+F7goUXTo x54oRCx87MiMw9GM7GXGO5YDDNvtWC3WatnAHN1c= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com sB8J6Ol7002710 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Mon, 8 Dec 2014 14:05:23 -0500 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB8J68mA025330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 14:06:09 -0500 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub34.corp.emc.com (10.254.93.82) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 8 Dec 2014 14:06:08 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB206.corp.emc.com ([fe80::843c:2a27:6ea:5f63%12]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 14:06:08 -0500 From: "Black, David" To: Loa Andersson , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp Thread-Index: AQHQB2R+JgZaamfF4kGIqMsXrGfZspyGdyQA//+s1RA= Date: Mon, 8 Dec 2014 19:06:07 +0000 Message-ID: References: <92cfc78ef38f4e9aa6d8345353afe746@BY1PR0501MB1430.namprd05.prod.outlook.com> <5485F500.1010103@pi.nu> In-Reply-To: <5485F500.1010103@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5M6vle6hv2VitCKilTN24IE3Pok Cc: "'draft-ietf-mpls-in-udp@tools.ietf.org'" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 19:06:35 -0000 > Second, we have done an earlier IPR poll, so far so good, but since > we late in the process have added two co-authors I want them to > respond whether or not they are aware of any other IPRs than those > that have been disclosed. As one of the new authors, I am not aware of any additional IPR related to this draft beyond the IPR that has been disclosed. Thanks, --David > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Monday, December 08, 2014 1:59 PM > To: Ross Callon; mpls@ietf.org > Cc: 'draft-ietf-mpls-in-udp@tools.ietf.org'; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp >=20 > Working Group, >=20 > Since Ross during the process to shepherd this document also became a > co-author I've taken over as Document Shepherd. >=20 > First, this wglc is closed. >=20 > There has been at least one comment that need to be discussed. >=20 > Second, we have done an earlier IPR poll, so far so good, but since > we late in the process have added two co-authors I want them to > respond whether or not they are aware of any other IPRs than those > that have been disclosed. >=20 > /Loa > mpls wg co-chair >=20 > On 2014-11-24 05:28, Ross Callon wrote: > > Working Group, > > > > This is to start a two week Working Group last call on > > draft-ietf-mpls-in-udp-07.txt. > > > > Please send your comments to the mpls working group mailing list > > (mpls@ietf.org ). > > > > Please send both technical comments, and (if you are happy with the > > document as is) > > > > also send indications of support. > > > > You will recall that this document passed WG last call more than a year > > ago. However, the > > > > subsequent IETF last call (in January 2014) resulted in a lengthy > > discussion, particularly over > > > > issues related to congestion and to the use (or non-use) of the UDP > > checksum with IPv6. > > > > After discussions in the March and July meetings this year (in London > > and Toronto, > > > > respectively), a design team was formed to come up with improved text > > related to > > > > congestion control and checksum use. The document has been updated > > significantly and > > > > the changes were presented at the recent IETF meeting in Honolulu, in > > both MPLS and > > > > TSVWG WGs. > > > > There is one IPR claim that applies to this draft, which can be seen at= : > > > > https://datatracker.ietf.org/ipr/1941/ > > > > The coauthors and contributor have indicated that they don't know of an= y > > other > > > > IPR applicable to this draft. If anyone else in the working group is > > aware of IPR > > > > claims against this draft, the time to disclose that is now. > > > > This working group last call will end on December 8, 2014. > > > > Ross > > > > for the wg co-chairs > > > > PS: Please also note that if you look at an earlier version of the > > document on the IETF > > > > tools web site, due to some sort of glitch in the tools server there is > > not a place to click > > > > under "version" at the top of the page to get version 7. However, the > > correct version is > > > > available at both https://tools.ietf.org/html/draft-ietf-mpls-in-udp-07 > > and also on the > > > > datatracker at https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/= . > > >=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 Mon Dec 8 11:15: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 1297C1ACDA5 for ; Mon, 8 Dec 2014 11:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dre9JRRjX3an for ; Mon, 8 Dec 2014 11:15:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:777]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5966D1A8846 for ; Mon, 8 Dec 2014 11:15:51 -0800 (PST) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1432.namprd05.prod.outlook.com (25.160.107.154) with Microsoft SMTP Server (TLS) id 15.1.31.17; Mon, 8 Dec 2014 19:15:28 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0031.000; Mon, 8 Dec 2014 19:15:28 +0000 From: Ross Callon To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp Thread-Index: AdADfizmaLLWumJtQOCK1HaJAtF5tAD3Q2eQAu900QAAAD3XgAAASk5Q Date: Mon, 8 Dec 2014 19:15:27 +0000 Message-ID: References: <92cfc78ef38f4e9aa6d8345353afe746@BY1PR0501MB1430.namprd05.prod.outlook.com> <5485F500.1010103@pi.nu> 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.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1432; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1432; x-forefront-prvs: 041963B986 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(252514010)(189002)(24454002)(377424004)(199003)(51704005)(13464003)(164054003)(54606007)(99286002)(107046002)(2656002)(2501002)(106356001)(19580395003)(31966008)(19580405001)(66066001)(4396001)(102836002)(76176999)(86362001)(105586002)(54206007)(21056001)(77156002)(50986999)(92566001)(74316001)(15975445007)(54356999)(62966003)(87936001)(230783001)(46102003)(101416001)(20776003)(76576001)(33656002)(64706001)(68736005)(97736003)(120916001)(40100003)(122556002)(99396003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1432; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; 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/oaq5wNhHcsQSNaA9oG0hN7cG1zU Cc: "'draft-ietf-mpls-in-udp@tools.ietf.org'" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 19:15:54 -0000 I am not aware of any undisclosed IPR on this document.=20 Thanks, Ross -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Monday, December 08, 2014 2:06 PM To: Loa Andersson; Ross Callon; mpls@ietf.org Cc: 'draft-ietf-mpls-in-udp@tools.ietf.org'; mpls-chairs@tools.ietf.org; Bl= ack, David Subject: RE: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp > Second, we have done an earlier IPR poll, so far so good, but since > we late in the process have added two co-authors I want them to > respond whether or not they are aware of any other IPRs than those > that have been disclosed. As one of the new authors, I am not aware of any additional IPR related to this draft beyond the IPR that has been disclosed. Thanks, --David > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Monday, December 08, 2014 1:59 PM > To: Ross Callon; mpls@ietf.org > Cc: 'draft-ietf-mpls-in-udp@tools.ietf.org'; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] Repeated WG last call on draft-ietf-mpls-in-udp >=20 > Working Group, >=20 > Since Ross during the process to shepherd this document also became a > co-author I've taken over as Document Shepherd. >=20 > First, this wglc is closed. >=20 > There has been at least one comment that need to be discussed. >=20 > Second, we have done an earlier IPR poll, so far so good, but since > we late in the process have added two co-authors I want them to > respond whether or not they are aware of any other IPRs than those > that have been disclosed. >=20 > /Loa > mpls wg co-chair >=20 > On 2014-11-24 05:28, Ross Callon wrote: > > Working Group, > > > > This is to start a two week Working Group last call on > > draft-ietf-mpls-in-udp-07.txt. > > > > Please send your comments to the mpls working group mailing list > > (mpls@ietf.org ). > > > > Please send both technical comments, and (if you are happy with the > > document as is) > > > > also send indications of support. > > > > You will recall that this document passed WG last call more than a year > > ago. However, the > > > > subsequent IETF last call (in January 2014) resulted in a lengthy > > discussion, particularly over > > > > issues related to congestion and to the use (or non-use) of the UDP > > checksum with IPv6. > > > > After discussions in the March and July meetings this year (in London > > and Toronto, > > > > respectively), a design team was formed to come up with improved text > > related to > > > > congestion control and checksum use. The document has been updated > > significantly and > > > > the changes were presented at the recent IETF meeting in Honolulu, in > > both MPLS and > > > > TSVWG WGs. > > > > There is one IPR claim that applies to this draft, which can be seen at= : > > > > https://datatracker.ietf.org/ipr/1941/ > > > > The coauthors and contributor have indicated that they don't know of an= y > > other > > > > IPR applicable to this draft. If anyone else in the working group is > > aware of IPR > > > > claims against this draft, the time to disclose that is now. > > > > This working group last call will end on December 8, 2014. > > > > Ross > > > > for the wg co-chairs > > > > PS: Please also note that if you look at an earlier version of the > > document on the IETF > > > > tools web site, due to some sort of glitch in the tools server there is > > not a place to click > > > > under "version" at the top of the page to get version 7. However, the > > correct version is > > > > available at both https://tools.ietf.org/html/draft-ietf-mpls-in-udp-07 > > and also on the > > > > datatracker at https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/= . > > >=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 Mon Dec 8 13:44: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 B09111A1B89 for ; Mon, 8 Dec 2014 13:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.49 X-Spam-Level: X-Spam-Status: No, score=-13.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMPcR5-cpg3z for ; Mon, 8 Dec 2014 13:44:31 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC021A0033 for ; Mon, 8 Dec 2014 13:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1827; q=dns/txt; s=iport; t=1418075071; x=1419284671; h=from:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=dDTaxwfdFkIsr9QeIByeUYIgMb2K9Jbz/LVVaQeVReI=; b=IlmSTv4QzQLAgLHLdaAlKIBbqaWtOyqGmKXMnaqTtPfNmvAkfdi+5KyG eEosGy4b1Gy0tkMxEH1cvvONBh+Sx0nWZaWyTqD5E8UyxBAnCJ6BniJ+e tIxn9ZfNxOVjTtnMVItbHbYxYHxmYC5rT1FGeqOKEqAHAFMPJ7yfo18Vj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0QAFsbhlStJA2G/2dsb2JhbABWA4MGgS7LeCqBDRYBAQEBAX2Deg86PxIBPkInEgWFdYJD1jcBAQEBAQEBAwIBH5AsEBiCbIE5BY4NiRWRaoNub4FFfgEBBQ X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="378567273" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 08 Dec 2014 21:44:30 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sB8LiUeZ025184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Dec 2014 21:44:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 15:44:30 -0600 From: "George Swallow (swallow)" Thread-Topic: IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AQHQEzAl/HURR8BpSk6WNvnMyiHA8A== Date: Mon, 8 Dec 2014 21:44:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.56.173] Content-Type: text/plain; charset="us-ascii" Content-ID: <46C4C63350B4BF4F8A44E3BA02777D98@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lxPA7tgr9F9o_F91cq9JJDWR8ns Cc: "mpls@ietf.org" Subject: [mpls] IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath 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, 08 Dec 2014 21:44:33 -0000 Loa - Cisco has IPR. See below. George On 12/8/14 3:18 PM, "Rachel Albright -X (ralbrigh - Independent Contractor at Cisco)" wrote: >Cisco is the owner of US Patent No. 7,782,790 relating to the subject >matter of "Label Switched Path (LSP) Ping/Trace Multipath Support for >Link Aggregation Group (LAG) Interfaces" >. >=20 >If technology in this document is included in a standard adopted by IETF >and any claims of any Cisco patents are necessary for practicing the >standard, any party will have the right to use any such patent claims >under reasonable, non-discriminatory terms, with reciprocity, to >implement and fully comply with the standard. >=20 >The reasonable non-discriminatory terms are: >=20 >If this standard is adopted, Cisco will not assert any patents owned or >controlled by Cisco against any party for making, using, selling, >importing or offering for sale a product that implements the standard, >provided, however that Cisco retains the right to assert its patents >(including the right to claim past royalties) against any party that >asserts a patent it owns or controls (either directly or indirectly) >against Cisco or any of Cisco's affiliates or successors in title or >against any products of Cisco or any products of any of Cisco's >affiliates either alone or in combination with other products; and Cisco >retains the right to assert its patents against any product or portion >thereof that is not necessary for compliance with the standard. >=20 >Royalty-bearing licenses will be available to anyone who prefers that >option. > >For information contact: >=20 >Dan Lang >Vice President and Deputy General Counsel >Cisco Systems, Inc. >+1 408-526-6672 >standards-ipr@cisco.com > From nobody Mon Dec 8 14:13: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 F19681ACFFD; Mon, 8 Dec 2014 14:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jqbzbrEG7Fc; Mon, 8 Dec 2014 14:13:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0A41ACEC0; Mon, 8 Dec 2014 14:13:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: nobo@cisco.com, swallow@cisco.com, stephane.litkowski@orange.com, bruno.decraene@orange.com, jdrake@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208221312.22457.99102.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 14:13:12 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gh5csDvdUPgFrY9BA4F6jsKr5p4 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Cisco's Statement of IPR Related to draft-akiya-mpls-lsp-ping-lag-multipath-04 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, 08 Dec 2014 22:13:21 -0000 Dear Nobo Akiya, George Swallow, Stephane Litkowski, Bruno Decraene, John Drake: An IPR disclosure that pertains to your Internet-Draft entitled "Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces" (draft-akiya-mpls-lsp-ping-lag-multipath) was submitted to the IETF Secretariat on 2014-12-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2496/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-akiya-mpls- lsp-ping-lag-multipath-04.""); The IETF Secretariat From nobody Mon Dec 8 14:24: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 CEF211A1B89 for ; Mon, 8 Dec 2014 14:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGU7KA8eScUK for ; Mon, 8 Dec 2014 14:24:00 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD45A1A026C for ; Mon, 8 Dec 2014 14:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2483; q=dns/txt; s=iport; t=1418077439; x=1419287039; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CQ67cA1cu/3pISDCrdt3eYHGqvg5yMKUNY0e9EFtf58=; b=DLcIEYnDUE5c0aFfiIbuxWt6zx3yWio0CEmcdecXxFmTmHkg5bSLYdWj F5Pfr2oEWXAhwH1ZhkjFXJkgJ+OfQCgIzAQbB0A3ZncvOOY3ekQIgEUj2 nEtDXOF9pbeuZO3H/b4KWUaRdR0wrzaitD46XQrtMnnsICbQ6Z2tYryIL Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FABokhlStJV2b/2dsb2JhbABWA4JkIlJcxWUKhgkCgSYWAQEBAQF9hAIBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIiDABDNY4AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQCyEQBwYLgxCBFQWMM4Famn+Dbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="103808790" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 08 Dec 2014 22:23:58 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB8MNwLd007779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 22:23:58 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 16:23:58 -0600 From: "Nobo Akiya (nobo)" To: "Loa Andersson (loa@pi.nu)" Thread-Topic: IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AQHQEzAlxlhAUVkwAU68Wro2hOg2mpyGRItw Date: Mon, 8 Dec 2014 22:23:58 +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.24.198.204] 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/9XH6mJO-taU0GGnZsQ_c7fU-xbk Cc: "mpls@ietf.org" Subject: Re: [mpls] IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath 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, 08 Dec 2014 22:24:02 -0000 Hi Loa One IPR pointed by George below is the only IPR, that I'm aware of, that is= applicable to draft-akiya-mpls-lsp-ping-lag-multipath document. Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow > (swallow) > Sent: Monday, December 08, 2014 4:44 PM > Cc: mpls@ietf.org > Subject: [mpls] IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath >=20 > Loa - >=20 > Cisco has IPR. See below. >=20 > George >=20 > On 12/8/14 3:18 PM, "Rachel Albright -X (ralbrigh - Independent Contracto= r > at Cisco)" wrote: >=20 > >Cisco is the owner of US Patent No. 7,782,790 relating to the subject > >matter of "Label Switched Path (LSP) Ping/Trace Multipath Support for > >Link Aggregation Group (LAG) Interfaces" > >. > > > >If technology in this document is included in a standard adopted by > >IETF and any claims of any Cisco patents are necessary for practicing > >the standard, any party will have the right to use any such patent > >claims under reasonable, non-discriminatory terms, with reciprocity, to > >implement and fully comply with the standard. > > > >The reasonable non-discriminatory terms are: > > > >If this standard is adopted, Cisco will not assert any patents owned or > >controlled by Cisco against any party for making, using, selling, > >importing or offering for sale a product that implements the standard, > >provided, however that Cisco retains the right to assert its patents > >(including the right to claim past royalties) against any party that > >asserts a patent it owns or controls (either directly or indirectly) > >against Cisco or any of Cisco's affiliates or successors in title or > >against any products of Cisco or any products of any of Cisco's > >affiliates either alone or in combination with other products; and > >Cisco retains the right to assert its patents against any product or > >portion thereof that is not necessary for compliance with the standard. > > > >Royalty-bearing licenses will be available to anyone who prefers that > >option. > > > >For information contact: > > > >Dan Lang > >Vice President and Deputy General Counsel Cisco Systems, Inc. > >+1 408-526-6672 > >standards-ipr@cisco.com > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Dec 8 16: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 649D31A1A16; Mon, 8 Dec 2014 16:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBU3ijxRCfSf; Mon, 8 Dec 2014 16:24:47 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0108.outbound.protection.outlook.com [65.55.169.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80BD31A0AF7; Mon, 8 Dec 2014 16:24:47 -0800 (PST) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BN3PR0501MB1425.namprd05.prod.outlook.com (25.160.117.147) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 9 Dec 2014 00:24:45 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.01.0031.000; Tue, 9 Dec 2014 00:24:45 +0000 From: John E Drake To: IETF Secretariat , "nobo@cisco.com" , "swallow@cisco.com" , "stephane.litkowski@orange.com" , "bruno.decraene@orange.com" Thread-Topic: IPR Disclosure: Cisco's Statement of IPR Related to draft-akiya-mpls-lsp-ping-lag-multipath-04 Thread-Index: AQHQEzQuhluPVthL7kqlM4T8d85usJyGZpIw Date: Tue, 9 Dec 2014 00:24:45 +0000 Message-ID: References: <20141208221312.22457.99102.idtracker@ietfa.amsl.com> In-Reply-To: <20141208221312.22457.99102.idtracker@ietfa.amsl.com> 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:;SRVR:BN3PR0501MB1425; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1425; x-forefront-prvs: 0420213CCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(199003)(13464003)(189002)(377454003)(51704005)(20776003)(46102003)(31966008)(74316001)(101416001)(76576001)(102836002)(15975445007)(21056001)(64706001)(66066001)(33656002)(2201001)(97736003)(2501002)(54206007)(19580405001)(4396001)(19580395003)(77096005)(68736005)(106356001)(99286002)(106116001)(99396003)(107046002)(105586002)(86362001)(92566001)(54356999)(62966003)(230783001)(122556002)(40100003)(77156002)(50986999)(76176999)(120916001)(54606007)(2656002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1425; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; 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/9aXbNBo4IfOaFntTAHLvIqcmcFo Cc: "mpls@ietf.org" , Ross Callon , "ipr-announce@ietf.org" Subject: Re: [mpls] IPR Disclosure: Cisco's Statement of IPR Related to draft-akiya-mpls-lsp-ping-lag-multipath-04 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, 09 Dec 2014 00:24:49 -0000 Tm8gSVBSIG9mIHdoaWNoIEkgYW0gYXdhcmUuDQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpK b2huDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSUVURiBTZWNyZXRh cmlhdCBbbWFpbHRvOmlldGYtaXByQGlldGYub3JnXQ0KPiBTZW50OiBNb25kYXksIERlY2VtYmVy IDA4LCAyMDE0IDU6MTMgUE0NCj4gVG86IG5vYm9AY2lzY28uY29tOyBzd2FsbG93QGNpc2NvLmNv bTsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207DQo+IGJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb207IEpvaG4gRSBEcmFrZQ0KPiBDYzogYWRyaWFuQG9sZGRvZy5jby51azsgYWthdGxhc0Bn bWFpbC5jb207IGxvYUBwaS5udTsNCj4gc3dhbGxvd0BjaXNjby5jb207IFJvc3MgQ2FsbG9uOyBt cGxzQGlldGYub3JnOyBpcHItYW5ub3VuY2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogSVBSIERpc2Ns b3N1cmU6IENpc2NvJ3MgU3RhdGVtZW50IG9mIElQUiBSZWxhdGVkIHRvIGRyYWZ0LWFraXlhLW1w bHMtDQo+IGxzcC1waW5nLWxhZy1tdWx0aXBhdGgtMDQNCj4gDQo+IA0KPiBEZWFyIE5vYm8gQWtp eWEsIEdlb3JnZSBTd2FsbG93LCBTdGVwaGFuZSBMaXRrb3dza2ksIEJydW5vIERlY3JhZW5lLA0K PiBKb2huIERyYWtlOg0KPiANCj4gIEFuIElQUiBkaXNjbG9zdXJlIHRoYXQgcGVydGFpbnMgdG8g eW91ciBJbnRlcm5ldC1EcmFmdCBlbnRpdGxlZCAiTGFiZWwNCj4gU3dpdGNoZWQgUGF0aCAoTFNQ KSBQaW5nL1RyYWNlIE11bHRpcGF0aCBTdXBwb3J0IGZvciBMaW5rIEFnZ3JlZ2F0aW9uDQo+IEdy b3VwIChMQUcpIEludGVyZmFjZXMiIChkcmFmdC1ha2l5YS1tcGxzLWxzcC1waW5nLWxhZy1tdWx0 aXBhdGgpIHdhcw0KPiBzdWJtaXR0ZWQgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgb24gMjAxNC0x Mi0wOCBhbmQgaGFzIGJlZW4gcG9zdGVkIG9uIHRoZQ0KPiAiSUVURiBQYWdlIG9mIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBSaWdodHMgRGlzY2xvc3VyZXMiDQo+IChodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2lwci8yNDk2LykuIFRoZSB0aXRsZSBvZiB0aGUgSVBSIGRpc2Nsb3N1cmUgaXMN Cj4gIkNpc2NvJ3MgU3RhdGVtZW50IG9mIElQUiBSZWxhdGVkIHRvIGRyYWZ0LWFraXlhLW1wbHMt IGxzcC1waW5nLWxhZy1tdWx0aXBhdGgtDQo+IDA0LiIiKTsNCj4gDQo+IFRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From nobody Mon Dec 8 19:27: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 20D471A0177; Mon, 8 Dec 2014 19:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2K7XnH_5GtG; Mon, 8 Dec 2014 19:27:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135C11A01AA; Mon, 8 Dec 2014 19:27:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPV30464; Tue, 09 Dec 2014 03:27:28 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Dec 2014 03:27:27 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Tue, 9 Dec 2014 11:27:22 +0800 From: Mach Chen To: "jcucchiara@mindspring.com" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt Thread-Index: AQHQD1wwmjpyVIbGj0WOTJkx2IIkPpyGn5bw Date: Tue, 9 Dec 2014 03:27:21 +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/50dBRJ58W2h1QaUeeNzgL_62ru4 Cc: "mib-doctors@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" , "mpls@ietf.org" Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.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, 09 Dec 2014 03:27:33 -0000 Hi Joan, The authors uploaded a revision to address the Shepherd's comments. I have = reviewed this version and am OK with it.=20 Would you please take a look at the latest version of this document? If you= are OK with it, we can move it forward. Thanks, Mach -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Thursday, December 04, 2014 8:49 AM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Operations, Administration, and Managemen= t (OAM) Identifiers Management Information Base (MIB) Authors : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-mpls-tp-oam-id-mib-06.txt Pages : 27 Date : 2014-12-03 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) and MPLS based Transport Profile (TP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-oam-id-mib-06 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Dec 8 22:15: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 B88DC1A1AF2 for ; Mon, 8 Dec 2014 22:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Lgsg6VK7iM7 for ; Mon, 8 Dec 2014 22:15:10 -0800 (PST) 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 05C511A011F for ; Mon, 8 Dec 2014 22:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4016; q=dns/txt; s=iport; t=1418105710; x=1419315310; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CtFJye0xA8Tn9gicP2jRZcDWiwn0DTAZAvuWVYRVYNY=; b=ZMrbPDXkeu+aXYZsszKgdHwf6tPnAr2QCZDc7Lap7geCj4dCs/1yUkH2 9NfNTFFSeeFqR94DWOC7lWLH4E7RTv7AG/XF1RbsIZcrQaKUlZ/V/6W+1 hpFtI8nDadp2MxdC2bc/ZJNsk+XaVFl/9Ylxca4gNLjtYrkgdFL9zCGsA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FADSThlStJA2H/2dsb2JhbABZgwaBKgTMGwKBKhYBAQEBAX2EAwEBBCdEDg4CAgEIRhsXJQIEDgWIONZSAQEBAQEBAQEBAQEBAQEBAQEBARkEj1YRAR0zB4Q2BY4NhVeDPoENgl+HSoJWg16Dbm+BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,542,1413244800"; d="scan'208";a="379011860" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 09 Dec 2014 06:15:00 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sB96ExBd008554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 06:14:59 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 00:14:59 -0600 From: "Tarek Saad (tsaad)" To: "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-esale-mpls-app-aware-tldp Thread-Index: AQHQB7nqwGAhLtpNtkqw0RELIqf865yG8DuA Date: Tue, 9 Dec 2014 06:14:59 +0000 Message-ID: References: <5472E0DF.5080109@pi.nu> In-Reply-To: <5472E0DF.5080109@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.86.245.49] 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/7vtPnAx52g32vlfnMecDSbt__Ng Cc: "draft-esale-mpls-app-aware-tldp@tools.ietf.org" , Lizhong Jin , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-esale-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 06:15:11 -0000 Hi, below is my MPLS-RT review: - is the document coherent? Yes, in general, but can benefit from another editorial round. - is it useful? Yes, being able to control T-LDP session establishment on-demand using new targeted application capability TLV is useful. - is it technically sound? Yes, but can benefit from being more explicit on how it complements and possibly co-exists with work defined in draft-ietf-mpls-ldp-ip-pw-capability. For example, when conflicting TAC/SAC are used and how it can be interpreted? Another (idea) is can do without extra mappings for Targeted Application Element to State Advertisement Control (SAC) Elements as defined in draft-ietf-mpls-ldp-ip-pw-capability (can it be unified app-id instead?)? - is it ready for WG adoption? Yes, but recommend undergoing another round of cleanup/editing before. =3D=3D=3D Comments: Section 2: * Value of U/F-bits: suggest being explicit on the recommended values=8B e.g. The value of the U-bit for the TLV 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 value of F-bit MUST be set to 0, so to not forward. * (Targeted Application Identifier (TA-Id)): would recommend making E-bit be at position 0 to be consistent with other definitions. Section 3:=20 * it MUST teard down -> it MUST tear down * withdral -> withdrawal * repeated TA-Ids/TAEs on receive may be considered malformed (?) to be consitent with procedures in draft-ietf-mpls-ldp-ip-pw-capability? * can elaborate on the new requirement below.. What are implications of not accepting by default? "Also, currently the remote LSR accepts asymmetric extended Hellos by default or by appropriate configuration. With this document, it should accept by default in order to then accept or reject the tLDP session based on the application information.=B2 Section 4: * s/an LSR MAY using/an LSR MAY use Section 5: * "The E-bit of the Targeted Application Element MUST be set to 1 to enable Targeted application.=B2. How to handle when E-bit is 0 on RX, is it malformed, or ignored? * can be more elaborative on handling TAC update in LDP capability message.. * s/disbaled/disabled * s/udpates/updates * "The LSR MAY add a different KeepAlive Time=B2, why? not clear how relate= d? Section 6: * s/initialazation/initialization * s/procceds/proceeds * s/establishemt/establishment Regards, Tarek On 2014-11-24, 2:40 AM, "Loa Andersson" wrote: >Tarek, Thomas and Lizhong, > >You have be selected as MPLS-RT reviewers for draft-esale-mpls-app- >aware-tldp. > >Note to authors: You have been CC'd on this email so that you can know >that this review is going on. However, please do not review your own >document. > >Reviews should comment on whether the document is coherent, is it >useful (ie, is it likely to be actually useful in operational >networks), and is the document technically sound? We are interested >in knowing whether the document is ready to be considered for WG >adoption (ie, it doesn't have to be perfect at this point, but should be >a good start). > >Reviews should be sent to the document authors, WG co-chairs and >WG secretary, and CC'd to the MPLS WG email list. If necessary, comments >may be sent privately to only the WG chairs. > >If you have technical comments you should try to be explicit about what >*really* need to be resolved before adopting it as a working group >document, and what can wait until the document is a working group >document and the working group has the revision control. > >Are you able to review this draft by Dec 9, 2014? Please respond in a >timely fashion. > > >Thanks, Loa >(as MPLS WG chair) >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 8 23:52:49 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 7A2ED1A6ED9 for ; Mon, 8 Dec 2014 23:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw_R__YD38IO for ; Mon, 8 Dec 2014 23:52:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1551A3BA6 for ; Mon, 8 Dec 2014 23:52:45 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 4AB2A2DC0F5; Tue, 9 Dec 2014 08:52:43 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2D86C4C0AD; Tue, 9 Dec 2014 08:52:43 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Tue, 9 Dec 2014 08:52:42 +0100 From: To: Loa Andersson Thread-Topic: IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AQHQEd2DHECRKtV97UarUHprYlL/pZyG5bRQ Date: Tue, 9 Dec 2014 07:52:41 +0000 Message-ID: <18658_1418111563_5486AA4B_18658_105_1_53C29892C857584299CBF5D05346208A0728D476@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <5483E38A.8000406@pi.nu> In-Reply-To: <5483E38A.8000406@pi.nu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bacLEceYL3mQO1GAt3sEIiudxqo Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath 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, 09 Dec 2014 07:52:47 -0000 Loa,=20 > Are you aware of any IPR that applies to draft-akiya-mpls-lsp-ping-lag-mu= ltipath? I'm not aware of non disclosed IPR. Bruno > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Sunday, December 07, 2014 6:20 AM > To: mpls@ietf.org > Cc: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; mpls- > chairs@tools.ietf.org > Subject: IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath >=20 > Working group, >=20 > The authors of draft-akiya-mpls-lsp-ping-lag-multipath has told the wg ch= airs > the document is ready to be adopted as a working group document. >=20 > The document is curretly in an MPLS-RT review. Before we start the wg > adoption poll the MPLS-RT review will be concluded and the document > updated. In parallel we will also do an IPR pll. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-akiya-mpls-lsp-ping-lag- > multipath? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are no IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to t= his > email regardless of whether or not you are aware of any relevant IPR. >=20 > *The response needs to be sent to the MPLS wg mailing list.* >=20 > The document will not advance to the next stage until a response has been > received from each author and contributor. >=20 > 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. >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Dec 9 00:13: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 CB2241A6F15 for ; Tue, 9 Dec 2014 00:13:49 -0800 (PST) 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 F952rni9SDZ7 for ; Tue, 9 Dec 2014 00:13:47 -0800 (PST) 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 8689F1A6F03 for ; Tue, 9 Dec 2014 00:13:47 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id z10so87308pdj.28 for ; Tue, 09 Dec 2014 00:13:46 -0800 (PST) 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=I15qffbM/ez6HFu9BJErhdr6uh9fSefxf2gyHbZglGM=; b=Dquy/yUnHeB1LAyrE33ndozrm5EwXcJUmOcZK4IXlPKR51031EX+vzCFxLSP4Xy+B4 pOOQZ56G/7UO9FmMzNlwkzQOI1LqAvX02saaF4bBbhnEpEWo8jhJbmugdZALVsXPQkLB oXfTAFAVt+tYXH+HN75PoqWX8cK/wPLIjN7qxxSg8frWx5U+6M1LoY15ehUIzFzN87l0 CipN9ggu6jj7gRdfooV8Ank2FpRRxe4jSTxweiFv6PgTlA6FT8a2tyctq1quWdVSmT42 WQ4hBMwyHqwLPZwazVuA8cgmW/fL8Y87QpCb616V91URKVxQovYikEcZYyNvwm4yo74x KmYg== X-Received: by 10.70.13.1 with SMTP id d1mr28717006pdc.132.1418112826810; Tue, 09 Dec 2014 00:13:46 -0800 (PST) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id fn5sm690914pdb.55.2014.12.09.00.13.43 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Dec 2014 00:13:45 -0800 (PST) From: "Lizhong Jin" To: References: <5472E0DF.5080109@pi.nu> In-Reply-To: Date: Tue, 9 Dec 2014 16:13:37 +0800 Message-ID: <065a01d01388$0d851590$288f40b0$@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: AQFsJKjUDduq7lVJTh6jFOJ/+pNIkADabRvxnUfy0wA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hbysffBgDBSfVn9vQfyfYqP3y9A Cc: draft-esale-mpls-app-aware-tldp@tools.ietf.org Subject: [mpls] FW: MPLS-RT review of draft-esale-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 08:13:50 -0000 Forget to cc to the WG list, sorry. Lizhong -----Original Message----- From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: 2014=C4=EA12=D4=C29=C8=D5 15:58 To: 'Loa Andersson'; 'tsaad@cisco.com'; 'thomas.beckhaus@telekom.de' Cc: 'draft-esale-mpls-app-aware-tldp@tools.ietf.org'; 'mpls-chairs@tools.ietf.org'; 'VIGOUREUX, MARTIN (MARTIN)' Subject: RE: MPLS-RT review of draft-esale-mpls-app-aware-tldp Hi authors, I review the document, and it is technically sound and useful, and ready = for adoption. Some minor comments are as below. Section 3, "On the receipt of a valid TAC TLV...". You do not say = explicitly how to handle the E bit, ignore? Section 3, "If it sets the session setup retry interval to maximum, the session MAY stay in a non-operational state". " non-operational " should = be " NON EXISTENT " according definition in RFC5036? Section 3, have you consider the overflow of Configuration Sequence = Number? I did not see that in RFC5036. Section 4, it seems there is still some application missed, e.g., = Entropy Label Capability, HSMP LSP Capability, etc. Regards Lizhong > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 2014=C4=EA11=D4=C224=C8=D5 15:40 > To: tsaad@cisco.com; thomas.beckhaus@telekom.de; Lizhong Jin > Cc: draft-esale-mpls-app-aware-tldp@tools.ietf.org; mpls-=20 > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > Subject: MPLS-RT review of draft-esale-mpls-app-aware-tldp >=20 > Tarek, Thomas and Lizhong, >=20 > You have be selected as MPLS-RT reviewers for draft-esale-mpls-app-=20 > aware-tldp. >=20 > Note to authors: You have been CC'd on this email so that you can know = > that this review is going on. However, please do not review your own document. >=20 > Reviews should comment on whether the document is coherent, is it=20 > useful (ie, is it likely to be actually useful in operational=20 > networks), and is the document technically sound? We are interested=20 > in knowing whether the document is ready to be considered for WG=20 > adoption (ie, it doesn't have to be perfect at this point, but should = be a good start). >=20 > Reviews should be sent to the document authors, WG co-chairs and WG=20 > secretary, and CC'd to the MPLS WG email list. If necessary, comments=20 > may be sent privately to only the WG chairs. >=20 > If you have technical comments you should try to be explicit about=20 > what > *really* need to be resolved before adopting it as a working group=20 > document, and what can wait until the document is a working group=20 > document and the working group has the revision control. >=20 > Are you able to review this draft by Dec 9, 2014? Please respond in a=20 > timely fashion. >=20 >=20 > Thanks, Loa > (as MPLS WG chair) > -- >=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 Dec 9 01:55: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 C770E1A1B12 for ; Tue, 9 Dec 2014 01:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK5GIlJwvCfE for ; Tue, 9 Dec 2014 01:55:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82F41A0100 for ; Tue, 9 Dec 2014 01:55:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPV65786; Tue, 09 Dec 2014 09:55:06 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Dec 2014 09:55:05 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Tue, 9 Dec 2014 17:54:59 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Working group lst call for draft-ietf-mpls-oam-ipv6-rao Thread-Index: AQHQDhCOy/5QjKh16EyIxBh/D+AkiZyHD4sA Date: Tue, 9 Dec 2014 09:54:59 +0000 Message-ID: References: <547D81A1.30905@pi.nu> <547D831C.30201@pi.nu> In-Reply-To: <547D831C.30201@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/hBlsjlmW599ILloA9tVPESUh6nw Cc: "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] Working group lst call for draft-ietf-mpls-oam-ipv6-rao 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, 09 Dec 2014 09:55:10 -0000 Hi, I have reviewed version 2 of this draft, it's short and well written. I thi= nk that it's ready for publication. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, December 02, 2014 5:15 PM > To: mpls@ietf.org; mpls-chairs@tools.ietf.org > Cc: draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org > Subject: [mpls] Working group lst call for draft-ietf-mpls-oam-ipv6-rao >=20 > Working Group, >=20 > This is to initiate a two week working group last call on > draft-ietf-mpls-oam-ipv6-rao. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). >=20 > There is no IPR disclosures against this document. All the authors > have stated on the working group mailing list that they are not aware > of any other IPRs that relates to this draft. >=20 > This working group last call ends December 16, 2014. >=20 > /Loa > for the MPLS wg chairs >=20 > PS > Just set the topic right >=20 >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Dec 9 03:26: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 E1CCF1A1B10 for ; Tue, 9 Dec 2014 03:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_Vdjd4CopBV for ; Tue, 9 Dec 2014 03:26:28 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8E21A1AC2 for ; Tue, 9 Dec 2014 03:26:27 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.192.192]) (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 AF4421801590; Tue, 9 Dec 2014 12:26:24 +0100 (CET) Message-ID: <5486DC5A.5010902@pi.nu> Date: Tue, 09 Dec 2014 19:26:18 +0800 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/kxbE4-HOhmyhsUbH6gP3JyCz-_g Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org Subject: [mpls] Implementation poll on draft-ietf-mpls-tp-oam-id-mib 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, 09 Dec 2014 11:26:30 -0000 Working Group, The Publication Request for draft-ietf-mpls-tp-oam-id-mib. Mach Chen is the document shepherd. One question he will have to answer in the Shepherd Write Up is about existing or intended implementations. This is to start the Implementation Poll. If you have or are aware of existing implementations of draft-ietf-mpls- tp-oam-id-mib please send this information to the working group mailing list (mpls@ietf.org) or directly to the working group chairs. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Dec 9 03:46: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 43F381A006B for ; Tue, 9 Dec 2014 03:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA8s2A3chPot for ; Tue, 9 Dec 2014 03:46:43 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CFD1A0126 for ; Tue, 9 Dec 2014 03:46:43 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.192.192]) (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 53D171801590; Tue, 9 Dec 2014 12:46:38 +0100 (CET) Message-ID: <5486E117.9070301@pi.nu> Date: Tue, 09 Dec 2014 19:46:31 +0800 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: <54716BEC.9050700@pi.nu> In-Reply-To: <54716BEC.9050700@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/yZveODiixsaPhspSJ5nt9-x5NqQ Cc: "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" Subject: [mpls] Concluded - poll to see if we have consensus to adopt draft-akiya-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 11:46:45 -0000 Working Group, This adoption poll has concluded, and we have a new working group document. Can the authors please re-post the draft with no other changes than administrative information (date and version) as draft-ietf-mpls- entropy-lsp-ping-00. /Loa for the wg chairs On 2014-11-23 13:09, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-akiya-mpls-entropy-lsp-ping-04 as an MPLS working group document. > > A bit if background, we had this document almost ready to go to the > working group adoption poll, but a discussion between authors and chairs > converged on that it would be beneficial to have to new IANA registries > set up. Since those registries would include code points defined in > other documents we could not define the registries in the current > document. We now have draft-ietf-mpls-lsp-ping-registry adopted as a > working group document, and can now progress draft-akiya-mpls-entropy- > lsp-ping. > > 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 two IPR disclosures directly against this document. > > The authors has all stated on the working group mailing > list that they are unaware of any other IPR claims against this draft > than the two disclosed. > > 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 December 8, 2014. > > /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 Dec 9 05:25: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 1694C1A1A8E for ; Tue, 9 Dec 2014 05:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, 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 zxBkBEiYJAGO for ; Tue, 9 Dec 2014 05:25:24 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E631A1A3E for ; Tue, 9 Dec 2014 05:25:24 -0800 (PST) Received: from [216.82.250.83] by server-1.bemta-12.messagelabs.com id F5/D7-02950-348F6845; Tue, 09 Dec 2014 13:25:23 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1418131522!17104434!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26766 invoked from network); 9 Dec 2014 13:25:23 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2014 13:25:23 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id 9E7AB2AA17; Tue, 9 Dec 2014 13:25:22 +0000 (GMT) Received: from USADCWVEHT01.corp.global.level3.com (10.2.36.141) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 06:25:22 -0700 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by usadcwveht01.corp.global.level3.com ([::1]) with mapi id 14.03.0158.001; Tue, 9 Dec 2014 08:25:21 -0500 From: "Osborne, Eric" To: "Tarek Saad (tsaad)" , "mpls@ietf.org" Thread-Topic: IETF MPLS-TE YANG Design Discussions Thread-Index: AQHQEKowxWoKKZSdmU6mFZwemhFbj5yCC+gAgAU5buA= Date: Tue, 9 Dec 2014 13:25:19 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD010FA766@USIDCWVEMBX08.corp.global.level3.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.1.196.207] 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/qZNtcig4GdO5EGwkBJol_FbyiZA Subject: Re: [mpls] IETF MPLS-TE YANG Design Discussions 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, 09 Dec 2014 13:25:27 -0000 Where do things go which are not strictly tunnel properties, but which are = only used on TE tunnels? Phase 2? I'm thinking of things like autoroute/i= gp-shortcuts - it's nothing to do with the links or the LSP but it really o= nly shows up as a feature used on TE links. eric > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad) > Sent: Friday, December 05, 2014 11:37 PM > To: mpls@ietf.org > Subject: [mpls] FW: IETF MPLS-TE YANG Design Discussions >=20 > Attendees: > Santosh Esale ; Rakesh Gandhi (rgandhi) > ; Robert Sawaya (rsawaya) ; Matt > Hartley (mhartley) ; lizhenbin@huawei.com > ; zengxinzong@huawei.com > ; xufeng.liu@ericsson.com > ; dhruv.dhody@huawei.com > ; Vero Zheng ; Sam > Aldrin ; Vishnu Pavan Beeram > ; jescia.chenxia@huawei.com > ; Zafar Ali (zali) ; Lou Berge= r > ; George Swallow (swallow) ; Shah, > Himanshu ; VICTOR LOPEZ ALVAREZ > >=20 > A group of us (from above) met on Thursday 12/4 for the first time to dis= cuss > MPLS TE YANG model. Below are minutes/notes. Next meeting is scheduled fo= r > next Wednesday 12/10. >=20 > - Next steps/AIs: > - Team: to check-in all existing YANG models to GitHub: > https://github.com/ietf-mpls-yang/te > - Team: phase 1 to tackle links and link attributes for phase 1 > * team to communicate proposed attributes over email. > * in-progress model for TE links will be discussed next week > - Team: to use email to send proposals > - Tarek: to send an email with minutes to the WG group > * include invitations for next meetings > - Tarek: to schedule weekly meeting for next wednesday onwards >=20 > Recording of meeting @ > https://cisco.webex.com/ciscosales/lsr.php?RCID=3D7a824854ae304230ab579f6= 9 > 77974239 >=20 >=20 > Meeting minutes/Notes: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - Meeting organization/time (do we need to meet more often?) > * Meet weekly, > * OK to keep Thursday 7:00pm EST > * Poll for next weekly meeting Wednesday 7:00pm EST > * Consideration for holidays >=20 > - Scope of our work: > * MPLS TE YANG model: > TE base yang types > TE base yang model > RSVP-TE extensions to TE base yang model > * MPLS Tunnels/links: Config, operational/state, notification, rpcs > * Topology (proposal to handle in another effort in TEAS) >=20 > - Do we need an alias to communicate/send queries? > * use mpls WG alias as long as manageable (not noisy) > * may create another alias to use too >=20 > - Agree on tools/process: > * repository in GitHub: https://github.com/ietf-mpls-yang/te > * check-in all yang models to date: > * tagged iet-mpls-te-(1/2/3).yang > * create ietf-mpls-te.yang > * to include sanitized/agreed data model to be presented at I= ETF > * create common draft draft-common-mpls-te-yang-model > * review/commit process? > * Need to converge >=20 > - Divide the work into phases > * ph1: TE Links: > link attributes (local TE links) > - Admin Groups, Extended Admin Groups (config) > - SRLGs (config) > - local/remote identifiers (config) > - reservable bandwidth (config) > - RSVP per interface properties > - etc. > - CAC (state) -- LSPs admitted on the link >=20 > * ph2: TE Tunnels: > * ph3: TE LSPs > * ph4: TE Globals/templates properties >=20 > - Revisit MPLS Yang module(s) hierarchy. Proposal: > + ietf-mpls-base-types.yang > | > + -- ietf-mpls-ldp-types.yang (imports mpls-base-types) > + -- ietf-mpls-te-types.yang (imports mpls-base-types) > + -- ietf-mpls-te-pce-types.yang (imports mpls-base-types) > + -- etc. > + ietf-mpls-base.yang > + -- ietf-mpls-te-base.yang (augments ietf-mpls-base.yang) > + -- ietf-mpls-te-rsvp.yang (augments ietf-mpls-te-base.yan= g) > + -- ietf-gmpls-te.yang (augments ietf-mpls-te-base.yang ? = augments > ietf-mpls-te-rsvp.yang, both ?) > - encoding types (PSC, LSC, FSC, etc.)? > - OTN/Optical > + ietf-mpls-oam > - the MPLS OAM YANG model (to augment MPLS-TE model whenever > needed) >=20 > - Where does MPLS data plane YANG state sit? > - In respective MPLS Yang models - identified with data plane disting= uisher > (?) > - data/control plane state and data plane state may not be in sync al= ways > (e.g. in transient post FRR) >=20 > Regards, > Tare From nobody Tue Dec 9 05:33:48 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 C85181A1ADF for ; Tue, 9 Dec 2014 05:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iZEp7BYfu1T for ; Tue, 9 Dec 2014 05:33:45 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559011A1A6D for ; Tue, 9 Dec 2014 05:33:45 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.192.192]) (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 986521801590; Tue, 9 Dec 2014 14:33:42 +0100 (CET) Message-ID: <5486FA2F.6020109@pi.nu> Date: Tue, 09 Dec 2014 21:33:35 +0800 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" , Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QCxWq76ePtK9KPh5nQfW2-dqPZw Subject: [mpls] short working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 09 Dec 2014 13:33:47 -0000 Working Group, This is to start a one week working group last call on draft-ietf-mpls- lsp-ping-relay-reply. We requested publication if version -03 and the document is now in version -06. Please find a diff at: https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-lsp-ping-relay-reply-03&difftype=--html&submit=Go%21&url2=draft-ietf-mpls-lsp-ping-relay-reply-06 Please send your comments to the MPLS wg mailing list (mpls@ietf.org), yes/support or no/do not support, in the case of non-support it is important that you give technical reasons for this. Please send your comments on December 17 the latest. /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 Tue Dec 9 05:43: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 3195F1A03FF for ; Tue, 9 Dec 2014 05:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5r3cqr8YQTu for ; Tue, 9 Dec 2014 05:42:57 -0800 (PST) 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 499BF1A1B0D for ; Tue, 9 Dec 2014 05:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3470; q=dns/txt; s=iport; t=1418132577; x=1419342177; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TN8Kqu+TqvrZJQ7/r8JDODo1SaGLm1wA92zS+nfRf7k=; b=aP1+zCW3rgfWst7HYg99NLOXDBCbJFtaW4FhwE/hVPmvk058Q+379kzZ ZzNPCr0pBapE2SQir6BVpnNdNKeWBYe3Iz4OUMFu28uXDmT2CRe3zS5qz AYzQ6Ky+yet8lzZjRVZAducdbVTcVoxuBYY+VR/04xkXX1mPUVFaOLUUh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAPr7hlStJA2D/2dsb2JhbABWA4JkIlJYBMYRCoYJAoEoFgEBAQEBfYQCAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBA4FCIgwAQzWfAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkAshEAcGC4MQgRUFjDOBWpp/g25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="104025254" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP; 09 Dec 2014 13:42:56 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB9Dgufp001885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 13:42:56 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 07:42:56 -0600 From: "Nobo Akiya (nobo)" To: "Loa Andersson (loa@pi.nu)" Thread-Topic: IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AQHQEzAlxlhAUVkwAU68Wro2hOg2mpyGRItwgAD/DVA= Date: Tue, 9 Dec 2014 13:42: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.62] 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/Wu4HI77O1V1lugdtCQ1TLF4osaE Cc: "mpls@ietf.org" Subject: Re: [mpls] IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath 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, 09 Dec 2014 13:42:59 -0000 Hi Loa, MPLS WG, I'd like to also add a comment regarding the time gap of the patent filing = date and its IPR disclosure to draft-akiya- mpls-lsp-ping-lag-multipath. IP= R disclosed below, US Patent No. 7,782,790, was originally filed in 2006. W= hen draft-akiya- mpls-lsp-ping-lag-multipath was posted, it was not immedia= tely clear to us that this IPR was applicable to the draft. Hence the delay= . Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Monday, December 08, 2014 5:24 PM > To: Loa Andersson (loa@pi.nu) > Cc: mpls@ietf.org > Subject: Re: [mpls] IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath >=20 > Hi Loa >=20 > One IPR pointed by George below is the only IPR, that I'm aware of, that = is > applicable to draft-akiya-mpls-lsp-ping-lag-multipath document. >=20 > Thanks! >=20 > -Nobo >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow > > (swallow) > > Sent: Monday, December 08, 2014 4:44 PM > > Cc: mpls@ietf.org > > Subject: [mpls] IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath > > > > Loa - > > > > Cisco has IPR. See below. > > > > George > > > > On 12/8/14 3:18 PM, "Rachel Albright -X (ralbrigh - Independent > > Contractor at Cisco)" wrote: > > > > >Cisco is the owner of US Patent No. 7,782,790 relating to the subject > > >matter of "Label Switched Path (LSP) Ping/Trace Multipath Support for > > >Link Aggregation Group (LAG) Interfaces" > > >. > > > > > >If technology in this document is included in a standard adopted by > > >IETF and any claims of any Cisco patents are necessary for practicing > > >the standard, any party will have the right to use any such patent > > >claims under reasonable, non-discriminatory terms, with reciprocity, > > >to implement and fully comply with the standard. > > > > > >The reasonable non-discriminatory terms are: > > > > > >If this standard is adopted, Cisco will not assert any patents owned > > >or controlled by Cisco against any party for making, using, selling, > > >importing or offering for sale a product that implements the > > >standard, provided, however that Cisco retains the right to assert > > >its patents (including the right to claim past royalties) against any > > >party that asserts a patent it owns or controls (either directly or > > >indirectly) against Cisco or any of Cisco's affiliates or successors > > >in title or against any products of Cisco or any products of any of > > >Cisco's affiliates either alone or in combination with other > > >products; and Cisco retains the right to assert its patents against > > >any product or portion thereof that is not necessary for compliance wi= th > the standard. > > > > > >Royalty-bearing licenses will be available to anyone who prefers that > > >option. > > > > > >For information contact: > > > > > >Dan Lang > > >Vice President and Deputy General Counsel Cisco Systems, Inc. > > >+1 408-526-6672 > > >standards-ipr@cisco.com > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Dec 9 06:33: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 073431A6FD2 for ; Tue, 9 Dec 2014 06:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nlu4PSnZDdrm for ; Tue, 9 Dec 2014 06:33:16 -0800 (PST) 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 1AA841A6FCE for ; Tue, 9 Dec 2014 06:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2666; q=dns/txt; s=iport; t=1418135595; x=1419345195; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lGqO4Yt6y7iUSMKWDRrVYERQqffsfks9M+8yB/Ou7wQ=; b=TsdMxJyXl2u/+Bnpf+FX9mxfCASa4Pxho+56eYCkmG6hoV2ROsyc7TZl Z7+/i+nqql4IIaEcuDISbr78QJeL+6dWzB/4nLUzD+j72lGZvrXVQfgnU wUerzskN+HvtoBGC/LvJx2OOOKUjpv+5NBUrNOFPT+XKwYB369foTVWf5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFADUHh1StJA2L/2dsb2JhbABZgmQiUlgExhMKhgkCgSMWAQEBAQF9hAIBAQEEAQEBNzEDCwwCAgIBCBEEAQEBChQJBxsMCxQJCAIEAQ0FCIgwAQzXCgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBI9WEQEfMQcGgxuBFQWMM4FaiiKCX4ogg16CMIE+b4EMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="104043780" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP; 09 Dec 2014 14:33:14 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB9EXEum015892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 14:33:14 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 08:33:14 -0600 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Concluded - poll to see if we have consensus to adopt draft-akiya-mpls-entropy-lsp-ping Thread-Index: AQHQBtujjf/YFaFQ0E20eLelc8zusJyHomqA///JveA= Date: Tue, 9 Dec 2014 14:33:13 +0000 Message-ID: References: <54716BEC.9050700@pi.nu> <5486E117.9070301@pi.nu> In-Reply-To: <5486E117.9070301@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.62] 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/WDc3DI55j1bhQWd9VqPnAdCzzgU Cc: "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Concluded - poll to see if we have consensus to adopt draft-akiya-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 14:33:18 -0000 Hi Loa, draft-ietf-mpls-entropy-lsp-ping-00 has been submitted, and is pending the = chair approval. Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, December 09, 2014 6:47 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-akiya-mpls-entropy-lsp- > ping@tools.ietf.org > Subject: [mpls] Concluded - poll to see if we have consensus to adopt dra= ft- > akiya-mpls-entropy-lsp-ping >=20 > Working Group, >=20 > This adoption poll has concluded, and we have a new working group > document. >=20 > Can the authors please re-post the draft with no other changes than > administrative information (date and version) as draft-ietf-mpls- entrop= y- > lsp-ping-00. >=20 > /Loa > for the wg chairs >=20 > On 2014-11-23 13:09, Loa Andersson wrote: > > Working Group, > > > > This is to start a two week poll on adopting > > draft-akiya-mpls-entropy-lsp-ping-04 as an MPLS working group document. > > > > A bit if background, we had this document almost ready to go to the > > working group adoption poll, but a discussion between authors and > > chairs converged on that it would be beneficial to have to new IANA > > registries set up. Since those registries would include code points > > defined in other documents we could not define the registries in the > > current document. We now have draft-ietf-mpls-lsp-ping-registry > > adopted as a working group document, and can now progress > > draft-akiya-mpls-entropy- lsp-ping. > > > > 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 two IPR disclosures directly against this document. > > > > The authors has all stated on the working group mailing list that they > > are unaware of any other IPR claims against this draft than the two > > disclosed. > > > > 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 December 8, 2014. > > > > /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 Dec 9 07:31: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 754E31A873C for ; Tue, 9 Dec 2014 07:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu_Rt01y8-DR for ; Tue, 9 Dec 2014 07:31:26 -0800 (PST) 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 6A60B1A8737 for ; Tue, 9 Dec 2014 07:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3101; q=dns/txt; s=iport; t=1418139084; x=1419348684; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MuDEbwFizuv1gR473xfqmJpFMvCkJA8wE4Ma2/sINrQ=; b=gYn0+0l/+ELQ55jZH+RK9rcRi+1EY+vhQNqoHCoyfdgMXm3TyTU3WLA4 NOzASObmvopB8DEk2YD/beFk1TXWdzjKRZ3f4Ze50HtI32bnvPK765tGe 536zgD1o9QFEcyGtOZN2c5WSN/PAjq/NZSdP7guwqjocJjiGWvKP5/tIw 8=; X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="263048138" 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; 09 Dec 2014 15:31:23 +0000 Received: from [64.103.80.244] ([64.103.80.244]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB9FVMnC022205; Tue, 9 Dec 2014 15:31:22 GMT Message-ID: <548715C9.7080809@cisco.com> Date: Tue, 09 Dec 2014 15:31:21 +0000 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: Chris Bowers , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "'Martin Vigoureux'" References: <545799DB.6010402@cisco.com> <5485D873.5070105@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/RyJFrTq82Vi9IzfgF1dpRapI5sU Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt 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, 09 Dec 2014 15:31:28 -0000 Chris That looks good. Thanks Stewart On 08/12/2014 17:38, Chris Bowers wrote: > Stewart, > > Thanks. I've added the following text to clarify. Tell me if this works. > > Chris > > 4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 > > The MRT LDP Capability Advertisement does not distinguish between > IPv4 and IPv6 address families. An LSR which advertises the MRT LDP > capability is expected to advertise MRT-related FEC-label bindings > for the same address families for which it advertises shortest-path > FEC-label bindings. Therefore, an LSR advertising MRT LDP capability > and shortest path FEC-label bindings for IPv4 only (or IPv6 only) > would be expected to advertise MRT-related FEC-label binding for IPv4 > only (or IPv6 only). An LSR advertising the MRT LDP capability and > shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected > to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. > In this scenario, advertising MRT-related FEC-label bindings only for > IPv4 only (or only for IPv6) is not supported. > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, December 08, 2014 10:57 AM > To: Chris Bowers; draft-atlas-mpls-ldp-mrt@tools.ietf.org; mpls-chairs@tools.ietf.org; 'Martin Vigoureux' > Cc: mpls@ietf.org > Subject: Re: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt > > On 08/12/2014 15:46, Chris Bowers wrote: >> >> 4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 >> >> An LSR which advertises the MRT LDP capability is expected to >> advertise MRT-related FEC-label bindings for both IPv4 and IPv6 >> address families, if the LSR originates shortest-path FEC-label >> bindings for those address families. >> >> SB> Surely the rule is that the you advertise bindings for the set of >> SB> address families you support. That makes you IPv4 and/or >> SB> IPv6 and/or IPvn agnostic. >> >> [CB] The issue that this sentence intends to address is the following. Suppose that someone wants to run a network with IPv4 and IPv6 with LDP for both IPv4 and IPv6, but only wants to run MRT for the IPv4 FECs (for some unspecified reason). The LDP MRT Capability Advertisement defined in this document does not distinguish between IPv4 and IPv6, so this scenario is not supported. We considered adding a mechanism to distinguish between IPv4 and IPv6 MRT LDP Capability, but decided that supporting the scenario above was not worth the added complexity. If the WG has a different opinion, we can revisit this. Do this make sense, or would you suggest additional text to clarify? > Hi Chris > > I think that needs re-wording since we have to be able to cope with > IPv4 only, IPv4+IPv6 and in the future IPv6 only. As you have written the text it's not clear to me that we support that. > > - Stewart > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Tue Dec 9 07: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 8C6361A8751; Tue, 9 Dec 2014 07:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k6Gqh4IWpWd; Tue, 9 Dec 2014 07:32:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6201A6F2A; Tue, 9 Dec 2014 07:32:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209153228.31080.62227.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 07:32:28 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wN9rv7RN834oydrDjlWAgffaRQQ Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-entropy-lsp-ping-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: Tue, 09 Dec 2014 15:32:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL) Authors : Nobo Akiya George Swallow Carlos Pignataro Andrew G. Malis Sam Aldrin Filename : draft-ietf-mpls-entropy-lsp-ping-00.txt Pages : 21 Date : 2014-12-09 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute are used to exercise specific paths of Equal-Cost Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) described in RFC6790, the ability for LSP Ping and Traceroute operation to discover and exercise ECMP paths has been lost in scenarios which LSRs apply deviating load balance techniques. One such scenario is when some LSRs apply EL based load balancing while other LSRs apply non-EL based load balancing (ex: IP). Another scenario is when EL based LSP is stitched with another LSP which can be EL based or non-EL based. This document extends the MPLS LSP Ping and Traceroute mechanisms to restore the ability of exercising specific paths of ECMP over LSP which make use of Entropy Label. This document updates RFC4379, RFC6424 and RFC6790. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-lsp-ping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-entropy-lsp-ping-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 Tue Dec 9 08:36: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 A25791A0397; Tue, 9 Dec 2014 07:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGK8oN6bHYf9; Tue, 9 Dec 2014 07:23:25 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB681A1C00; Tue, 9 Dec 2014 07:23:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PQZoSQ0FFqOJzkn98emWSdKyn7NgCSiRBtdKrGkkOlhuRePcSy5BEcZyvtNw7g+9; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.144] (helo=JoanTower) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XyMd9-0006wg-Mp; Tue, 09 Dec 2014 10:23:15 -0500 From: "Joan Cucchiara" To: "'Mach Chen'" References: In-Reply-To: Date: Tue, 9 Dec 2014 10:23:14 -0500 Message-ID: <033e01d013c4$0d4d9390$27e8bab0$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJBibtMqsEH8UaSXi7ZnH2b8M8cnZukdHlQ Content-Language: en-us X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654005fb438e1b17175429bc128806b2a9172fee374a2a11089350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.144 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/tGK3fND9xlkkzVs5oC7i13e78pM X-Mailman-Approved-At: Tue, 09 Dec 2014 08:36:24 -0800 Cc: mib-doctors@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.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, 09 Dec 2014 15:23:28 -0000 Mach, I'll take a look soon. Can you tell me what MIB compilers this has been compiled with? Thanks, -Joan > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Monday, December 08, 2014 10:27 PM > To: jcucchiara@mindspring.com > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > mib-doctors@ietf.org; mpls@ietf.org > Subject: FW: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > Hi Joan, > > The authors uploaded a revision to address the Shepherd's comments. I have > reviewed this version and am OK with it. > > Would you please take a look at the latest version of this document? If you > are OK with it, we can move it forward. > > Thanks, > Mach > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, December 04, 2014 8:49 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group > of the IETF. > > Title : MPLS-TP Operations, Administration, and Management > (OAM) Identifiers Management Information Base (MIB) > Authors : Sam Aldrin > Venkatesan Mahalingam > Kannan KV Sampath > Thomas D. Nadeau > Filename : draft-ietf-mpls-tp-oam-id-mib-06.txt > Pages : 27 > Date : 2014-12-03 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes Operations, Administration, and > Management (OAM) identifiers related managed objects for > Multiprotocol Label Switching (MPLS) and MPLS based Transport Profile > (TP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mib-06 > > > 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 > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4794 / Virus Database: 4235/8703 - Release Date: 12/08/14 From nobody Tue Dec 9 09:34: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 743FF1A1A46 for ; Tue, 9 Dec 2014 09:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVG0zh3QrRC7 for ; Tue, 9 Dec 2014 09:34:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 02F481A07BD for ; Tue, 9 Dec 2014 09:34:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E25BF18123F; Tue, 9 Dec 2014 09:33:46 -0800 (PST) To: mach.chen@huawei.com, wayne.caowei@huawei.com, ning.so@tatacommunications.com, frederic.jounay@orange.ch, simon.delord@alcatel-lucent.com, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141209173346.E25BF18123F@rfc-editor.org> Date: Tue, 9 Dec 2014 09:33:46 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5XFuIAFDMgBo2EHvdrwx-jinvAs Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC7110 (4195) 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, 09 Dec 2014 17:34:39 -0000 The following errata report has been submitted for RFC7110, "Return Path Specified Label Switched Path (LSP) Ping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7110&eid=4195 -------------------------------------- Type: Editorial Reported by: tom petch Section: 5.4 Original Text ------------- When an echo reply is received, if the Reply Mode is "Reply via Specified Path" and the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and if the return path is an MPLS LSP. The ingress LSR MUST perform FEC validation (based on the FEC Stack information of the return path carried in the Reply Path TLV) as an egress LSR does when receiving an echo request, the FEC validation process (relevant to "ping" mode) defined in Section 4.4.1 of [RFC4379] applies here. When an echo reply is received with return code set to "Malformed echo request received" and the Subcode set to zero. It is possible that the egress LSR may not know the "Reply via Specified Path" Reply Mode, the operator may choose to re-perform another LSP ping by using one of the four Reply Modes defined [RFC4379]. Corrected Text -------------- When an echo reply is received, if the Reply Mode is "Reply via Specified Path" and the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and if the return path is an MPLS LSP, the ingress LSR MUST perform FEC validation (based on the FEC Stack information of the return path carried in the Reply Path TLV) as an egress LSR does when receiving an echo request, the FEC validation process (relevant to "ping" mode) defined in Section 4.4.1 of [RFC4379] applies here. When an echo reply is received with return code set to "Malformed echo request received" and the Subcode set to zero, it is possible that the egress LSR may not know the "Reply via Specified Path" Reply Mode; the operator may choose to re-perform another LSP ping by using one of the four Reply Modes defined in [RFC4379]. Notes ----- In the first two paragraphs of section 5.4, the conditional clauses and the main clause have been separated by periods, not commas, which creates uncertainty as to whether or not text of the main clause has been elided. This changes the periods into commas. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7110 (draft-ietf-mpls-return-path-specified-lsp-ping-15) -------------------------------------- Title : Return Path Specified Label Switched Path (LSP) Ping Publication Date : January 2014 Author(s) : M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Dec 9 09:36: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 8B6081A897F for ; Tue, 9 Dec 2014 09:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Mp7qcBmfRGk for ; Tue, 9 Dec 2014 09:36:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9961A1A46 for ; Tue, 9 Dec 2014 09:36:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 39C7518123F; Tue, 9 Dec 2014 09:35:33 -0800 (PST) To: mach.chen@huawei.com, wayne.caowei@huawei.com, ning.so@tatacommunications.com, frederic.jounay@orange.ch, simon.delord@alcatel-lucent.com, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141209173533.39C7518123F@rfc-editor.org> Date: Tue, 9 Dec 2014 09:35:33 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/YHHMTsQoiYG0kY245OnMDRoMb5k Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC7110 (4196) 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, 09 Dec 2014 17:36:24 -0000 The following errata report has been submitted for RFC7110, "Return Path Specified Label Switched Path (LSP) Ping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7110&eid=4196 -------------------------------------- Type: Editorial Reported by: tom petch Section: 4.3.1 Original Text ------------- the recommended type value is 26. Corrected Text -------------- the type value is 26. Notes ----- The WG commended a value of 26 to IANA for the "IPv4 RSVP Tunnel sub-TLV Type" which IANA confirmed. Leaving in the 'recommended' introduces a element of uncertainty that is best avoided. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7110 (draft-ietf-mpls-return-path-specified-lsp-ping-15) -------------------------------------- Title : Return Path Specified Label Switched Path (LSP) Ping Publication Date : January 2014 Author(s) : M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Dec 9 09:38: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 329041A8A23 for ; Tue, 9 Dec 2014 09:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DXy_mR2RPEG for ; Tue, 9 Dec 2014 09:37:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 644F01A8A1D for ; Tue, 9 Dec 2014 09:37:59 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 55F2B18123F; Tue, 9 Dec 2014 09:37:09 -0800 (PST) To: mach.chen@huawei.com, wayne.caowei@huawei.com, ning.so@tatacommunications.com, frederic.jounay@orange.ch, simon.delord@alcatel-lucent.com, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141209173709.55F2B18123F@rfc-editor.org> Date: Tue, 9 Dec 2014 09:37:09 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Le5JLzivojobAdwaDhfaXbPzbvc Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC7110 (4197) 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, 09 Dec 2014 17:38:01 -0000 The following errata report has been submitted for RFC7110, "Return Path Specified Label Switched Path (LSP) Ping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7110&eid=4197 -------------------------------------- Type: Editorial Reported by: tom petch Section: 4 Original Text ------------- The Reply Path TLV contains one or more nested sub-TLVs that can be used Corrected Text -------------- The Reply Path TLV contains zero or more nested sub-TLVs that can be used Notes ----- As section 4.2 correctly states, the Reply Path TLV can contain zero sub-TLVs; this brings section 4 inline. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7110 (draft-ietf-mpls-return-path-specified-lsp-ping-15) -------------------------------------- Title : Return Path Specified Label Switched Path (LSP) Ping Publication Date : January 2014 Author(s) : M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Dec 9 09: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 70CD71A00AD for ; Tue, 9 Dec 2014 09:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_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 f8oSz6DdD7lm for ; Tue, 9 Dec 2014 09:59:18 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3271A1AA7 for ; Tue, 9 Dec 2014 09:59:17 -0800 (PST) Received: from pc6 (86.151.40.56) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 9 Dec 2014 17:41:03 +0000 Message-ID: <021201d013d7$4a2cf0e0$4001a8c0@gateway.2wire.net> From: t.petch To: Mach Chen References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com>, <03df01d00d7a$0bce8740$4001a8c0@gateway.2wire.net> <00b401d0108b$07065b20$4001a8c0@gateway.2wire.net> Date: Tue, 9 Dec 2014 17:40:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.151.40.56] X-ClientProxiedBy: DB4PR03CA0037.eurprd03.prod.outlook.com (25.160.39.175) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-Forefront-PRVS: 0420213CCD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(51444003)(51704005)(13464003)(377454003)(189002)(37854004)(14496001)(44716002)(62236002)(84392001)(66066001)(20776003)(110136001)(47776003)(19580405001)(64706001)(19580395003)(561944003)(101416001)(97736003)(120916001)(89996001)(87976001)(1556002)(99396003)(46102003)(31966008)(93886004)(42186005)(23756003)(61296003)(50226001)(44736004)(50466002)(4396001)(107046002)(77156002)(62966003)(116806002)(106356001)(40100003)(105586002)(21056001)(86362001)(81686999)(81816999)(77096005)(68736005)(33646002)(50986999)(92566001)(1456003)(122386002)(15975445007)(76176999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB059; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1to_M037tUIAWTWNydCwlNOJhkA Cc: mpls Subject: Re: [mpls] Return Path Specified 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, 09 Dec 2014 17:59:20 -0000 Mach eeeeee .... I thought I knew how to submit an Erratum (memo to self - read the I-D before it becomes an RFC). I have submitted them but it became three separate Errata - I could not find a way to stitch them together. Tom ----- Original Message ----- From: "Mach Chen" To: "t.petch" Cc: "mpls" Sent: Monday, December 08, 2014 1:07 AM Hi Tom, Yes, I agree with the proposal. Thanks, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of t.petch > Sent: Friday, December 05, 2014 7:58 PM > To: Mach Chen > Cc: mpls > Subject: Re: [mpls] Return Path Specified > > Mach > > Yes, that is clearer now. > > I think that an Editorial Erratum would be in order, details below. Do you agree? > > Section 4.3.1 says > > " the recommended type value is 26." > > It should say > > " the type value is 26." > > Section 4 says > > "The Reply Path TLV contains one or more nested sub-TLVs that can be used" > > It should say > > "The Reply Path TLV contains zero or more nested sub-TLVs that can be used" > > Section 5.4 says > > "When an echo reply is received, if the Reply Mode is "Reply via > Specified Path" and the Reply Path return code is "The echo reply was > sent successfully using the specified Reply Path", and if the return > path is an MPLS LSP. The ingress LSR MUST perform FEC validation" > > It should say > > "When an echo reply is received, if the Reply Mode is "Reply via > Specified Path" and the Reply Path return code is "The echo reply was > sent successfully using the specified Reply Path", and if the return > path is an MPLS LSP, the ingress LSR MUST perform FEC validation" > > Section 5.4 says > > "When an echo reply is received with return code set to "Malformed > echo request received" and the Subcode set to zero. It is possible > that the egress LSR may not know the "Reply via Specified Path" Reply > Mode, the operator may choose to re-perform another LSP ping by using > one of the four Reply Modes defined [RFC4379]." > > It should say > > "When an echo reply is received with return code set to "Malformed > echo request received" and the Subcode set to zero, it is possible > that the egress LSR may not know the "Reply via Specified Path" Reply > Mode; the operator may choose to re-perform another LSP ping by using > one of the four Reply Modes defined in [RFC4379]." > > Notes: > > The WG commended a value of 26 to IANA for the "IPv4 RSVP Tunnel sub-TLV > Type" which IANA confirmed. Leaving in the 'recommended' introduces a > element of uncertainty that is best avoided. > > As section 4.2 correctly states, the Reply Path TLV can contain zero sub-TLVs; this > brings section 4 inline. > > In section 5.4, the conditional clauses and the main clause have been separated > by periods, not commas, which creates uncertainty as to whether or not text of > the main clause has been elided. > > > > The last two I raised do not seem worthy of an erratum. > > Tom Petch > > ----- Original Message ----- > From: "Mach Chen" > To: "t.petch" > Cc: > Sent: Tuesday, December 02, 2014 9:29 AM > > Hi Tom, > > Thanks for your detail reading of the RFC. > > > -----Original Message----- > > From: t.petch [mailto:ietfc@btconnect.com] > > Sent: Monday, December 01, 2014 11:18 PM > > To: Mach Chen > > Cc: mpls@ietf.org > > Subject: Return Path Specified > > > > Mach > > > > Some of the language in RFC7110 looks a little quirky. > > > > s.4.3.1 > > "the recommended type value is 26" > > looks like 'recommended' should have been elided post-IANA > > Yes, indeed. > > > > > s.4 > > "The Reply Path TLV contains one or more nested sub-TLVs that can be > used" > > > > s.4.2 Reply Path (RP) TLV > > "It is variable in length and can contain zero, one or more Target > FEC sub-TLVs" > > > > seem to be in conflict > > The later is the intention and reflects final consensus, but failed to make the > former align with this consensus. > > > > > s5.4 > > "When an echo reply is received, if the Reply Mode is "Reply via > > Specified Path" and the Reply Path return code is "The echo reply > was > > sent successfully using the specified Reply Path", and if the > return > > path is an MPLS LSP. " > > > > I am left expecting a comma and a main clause (unless the remainder of > the > > paragraph is the main clause). > > Yes, there was a main clause, it was considered redundant and removed directly > in a version but forgot to change the last period to a comma. > > > > > "When an echo reply is received with return code set to "Malformed > > echo request received" and the Subcode set to zero. " > > > > Ditto > > > > And, since I am at it:-) > > Same as above. > > > > > s.6 > > OLD > > "whether the return path LSP has the destination to the initiator." > > NEW > > "whether the return path LSP has a destination of the initiator." > > > > OLD > > "That means, when sending echo request, the initiator > > should choose a proper source address according the specified > return > > path LSP to help the receiver to make the decision." > > NEW > > "That means, when sending an echo request, the initiator > > should select a source address that helps the receiver to > > find a return path." [I think!] > > > > I am OK with the above refinement. > > > Sorry that this is a year late:-( > > Indeed. But maybe you could report corresponding erratum, that will be useful. > > I realize that above bugs will be reduced if there was language QA review at that > time. > > Thanks, > Mach > > > > Tom Petch > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Dec 9 11:06: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 0B8441A8F40; Tue, 9 Dec 2014 11:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvj_eLc9P-_h; Tue, 9 Dec 2014 11:05:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 90EFD1A8F3E; Tue, 9 Dec 2014 11:05:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A4813181CEE; Tue, 9 Dec 2014 11:04:47 -0800 (PST) To: ietfc@btconnect.com, mach.chen@huawei.com, wayne.caowei@huawei.com, ning.so@tatacommunications.com, frederic.jounay@orange.ch, simon.delord@alcatel-lucent.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141209190447.A4813181CEE@rfc-editor.org> Date: Tue, 9 Dec 2014 11:04:47 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BjhXKMpYc0pvOZlvD7BgMzFOHUU Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, mpls@ietf.org Subject: [mpls] [Errata Verified] RFC7110 (4195) 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, 09 Dec 2014 19:05:48 -0000 The following errata report has been verified for RFC7110, "Return Path Specified Label Switched Path (LSP) Ping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7110&eid=4195 -------------------------------------- Status: Verified Type: Editorial Reported by: tom petch Date Reported: 2014-12-09 Verified by: Adrian Farrel (IESG) Section: 5.4 Original Text ------------- When an echo reply is received, if the Reply Mode is "Reply via Specified Path" and the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and if the return path is an MPLS LSP. The ingress LSR MUST perform FEC validation (based on the FEC Stack information of the return path carried in the Reply Path TLV) as an egress LSR does when receiving an echo request, the FEC validation process (relevant to "ping" mode) defined in Section 4.4.1 of [RFC4379] applies here. When an echo reply is received with return code set to "Malformed echo request received" and the Subcode set to zero. It is possible that the egress LSR may not know the "Reply via Specified Path" Reply Mode, the operator may choose to re-perform another LSP ping by using one of the four Reply Modes defined [RFC4379]. Corrected Text -------------- When an echo reply is received, if the Reply Mode is "Reply via Specified Path" and the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and if the return path is an MPLS LSP, the ingress LSR MUST perform FEC validation (based on the FEC Stack information of the return path carried in the Reply Path TLV) as an egress LSR does when receiving an echo request, the FEC validation process (relevant to "ping" mode) defined in Section 4.4.1 of [RFC4379] applies here. When an echo reply is received with return code set to "Malformed echo request received" and the Subcode set to zero, it is possible that the egress LSR may not know the "Reply via Specified Path" Reply Mode; the operator may choose to re-perform another LSP ping by using one of the four Reply Modes defined in [RFC4379]. Notes ----- In the first two paragraphs of section 5.4, the conditional clauses and the main clause have been separated by periods, not commas, which creates uncertainty as to whether or not text of the main clause has been elided. This changes the periods into commas. -------------------------------------- RFC7110 (draft-ietf-mpls-return-path-specified-lsp-ping-15) -------------------------------------- Title : Return Path Specified Label Switched Path (LSP) Ping Publication Date : January 2014 Author(s) : M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Dec 9 11:21: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 CACB71A1A2F; Tue, 9 Dec 2014 11:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chQjVP4ulvTn; Tue, 9 Dec 2014 11:21:47 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 357E31A1A0B; Tue, 9 Dec 2014 11:21:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DC87D181CEB; Tue, 9 Dec 2014 11:20:56 -0800 (PST) To: ietfc@btconnect.com, mach.chen@huawei.com, wayne.caowei@huawei.com, ning.so@tatacommunications.com, frederic.jounay@orange.ch, simon.delord@alcatel-lucent.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141209192056.DC87D181CEB@rfc-editor.org> Date: Tue, 9 Dec 2014 11:20:56 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eaio7M1JBg8SwpmeUx9Ju86_dAI Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, mpls@ietf.org Subject: [mpls] [Errata Verified] RFC7110 (4196) 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, 09 Dec 2014 19:21:49 -0000 The following errata report has been verified for RFC7110, "Return Path Specified Label Switched Path (LSP) Ping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7110&eid=4196 -------------------------------------- Status: Verified Type: Editorial Reported by: tom petch Date Reported: 2014-12-09 Verified by: Adrian Farrel (IESG) Section: 4.3.1 Original Text ------------- the recommended type value is 26. Corrected Text -------------- the type value is 26. Notes ----- The WG commended a value of 26 to IANA for the "IPv4 RSVP Tunnel sub-TLV Type" which IANA confirmed. Leaving in the 'recommended' introduces a element of uncertainty that is best avoided. -------------------------------------- RFC7110 (draft-ietf-mpls-return-path-specified-lsp-ping-15) -------------------------------------- Title : Return Path Specified Label Switched Path (LSP) Ping Publication Date : January 2014 Author(s) : M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Dec 9 11:22: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 304E11A1BBE; Tue, 9 Dec 2014 11:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TMsyvXQbQxv; Tue, 9 Dec 2014 11:22:28 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B98791A1A0B; Tue, 9 Dec 2014 11:22:28 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 738D1181CEB; Tue, 9 Dec 2014 11:21:38 -0800 (PST) To: ietfc@btconnect.com, mach.chen@huawei.com, wayne.caowei@huawei.com, ning.so@tatacommunications.com, frederic.jounay@orange.ch, simon.delord@alcatel-lucent.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141209192138.738D1181CEB@rfc-editor.org> Date: Tue, 9 Dec 2014 11:21:38 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZJZz9vwKWanuD4No52ogVYgsD6M Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, mpls@ietf.org Subject: [mpls] [Errata Verified] RFC7110 (4197) 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, 09 Dec 2014 19:22:30 -0000 The following errata report has been verified for RFC7110, "Return Path Specified Label Switched Path (LSP) Ping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7110&eid=4197 -------------------------------------- Status: Verified Type: Technical Reported by: tom petch Date Reported: 2014-12-09 Verified by: Adrian Farrel (IESG) Section: 4 Original Text ------------- The Reply Path TLV contains one or more nested sub-TLVs that can be used Corrected Text -------------- The Reply Path TLV contains zero or more nested sub-TLVs that can be used Notes ----- As section 4.2 correctly states, the Reply Path TLV can contain zero sub-TLVs; this brings section 4 inline. -------------------------------------- RFC7110 (draft-ietf-mpls-return-path-specified-lsp-ping-15) -------------------------------------- Title : Return Path Specified Label Switched Path (LSP) Ping Publication Date : January 2014 Author(s) : M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Dec 9 11:34: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 E479C1A037B for ; Tue, 9 Dec 2014 11:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 9Z1WHOsAbfzl for ; Tue, 9 Dec 2014 11:34:19 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8221A0032 for ; Tue, 9 Dec 2014 11:34:19 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB9JY91f010185; Tue, 9 Dec 2014 19:34:09 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB9JY7vR010169 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 19:34:08 GMT From: "Adrian Farrel" To: "'t.petch'" , "'Mach Chen'" References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com>, <03df01d00d7a$0bce8740$4001a8c0@gateway.2wire.net> <00b401d0108b$07065b20$4001a8c0@gateway.2wire.net> <021201d013d7$4a2cf0e0$4001a8c0@gateway.2wire.net> In-Reply-To: <021201d013d7$4a2cf0e0$4001a8c0@gateway.2wire.net> Date: Tue, 9 Dec 2014 19:34:03 -0000 Message-ID: <050301d013e7$17126900$45373b00$@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: AQDvUuzBZsiZPl8xBa6B/Epp0feQGQJyHQlIAw7yCEYCP9VsPgHJMwjsAb+My3QBTVQg/gEWa71cA2b7OmudwIM1UA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21162.002 X-TM-AS-Result: No--30.031-10.0-31-10 X-imss-scan-details: No--30.031-10.0-31-10 X-TMASE-MatchedRID: H0/uSqZo4D6nykMun0J1wlu4M/xm4KZepPpgsd/tgYjZwATo6wn66jY/ 6zSFssWpgjAzL+hW03U+XCsUdMew+Ub4MhIR2zPLjhXy0Khej9K36GGfwjLoZdp1biJhIyNRcBa 45GbRMhp/lXEQ0jMYOrHyebymXrvoed6FhOj8IzoD2WXLXdz+AX4yToAKzDgm3XgCp7wTMXyqzB k3OfQMkAPtQsPs6PZvaqguUO9xiAVCI2iUrGleqmivjLE8DPtZ77AMeyyT87zaqqH/oHw+kQV25 mKnlcPs6DTBTyHUz86bOgSAVyxuqpZJdzT1VDBh1bFtmBqqFLTA2cNJy/qKUmJkJOQVCIpweDQZ Zv+Gu31fdi65/0J2HjnN7Z2uT8G5B011LpxMs1gER9Ta+6BEXbPksiHb4g58pGRxRa9xIGkjw4m s98ZEXcCuTARCrHfw38tGqrfrt0Ljpwa9zJqeRkhEDfw/93BuMVx/3ZYby7/aK015iKn7OFKTeW +F3fxdlLtY/XDViw4fKM+QT8rKpC95uXownWhRW3dczJ1RoxdX8rAwuXKY7DCn/izeFSUYDjZwj rQ6CQWekrOjtm4oRhw58L6+gfo0GAdnzrnkM485f9Xw/xqKXcidYBYDjITpp2c3EY8h4cmrusVR y4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VjclZ1N4i-KmJ-ZkbsUUsoIvPF4 Cc: 'mpls' Subject: Re: [mpls] Return Path Specified 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, 09 Dec 2014 19:34:22 -0000 Hi Tom, Thanks for the work. I just approved the three errata reports. Actually, it is much nicer to have them as separate reports because it is clearer what I am verifying and the notes are easier to read. They should appear on the link from the datatracker page for the RFC once the scripts have had a chance to turn. Cheers, Adrian > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of t.petch > Sent: 09 December 2014 17:41 > To: Mach Chen > Cc: mpls > Subject: Re: [mpls] Return Path Specified > > Mach > > eeeeee .... I thought I knew how to submit an Erratum (memo to self - > read the I-D before it becomes an RFC). > > I have submitted them but it became three separate Errata - I could not > find a way to stitch them together. > > Tom > > ----- Original Message ----- > From: "Mach Chen" > To: "t.petch" > Cc: "mpls" > Sent: Monday, December 08, 2014 1:07 AM > > > Hi Tom, > > Yes, I agree with the proposal. > > Thanks, > Mach > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of t.petch > > Sent: Friday, December 05, 2014 7:58 PM > > To: Mach Chen > > Cc: mpls > > Subject: Re: [mpls] Return Path Specified > > > > Mach > > > > Yes, that is clearer now. > > > > I think that an Editorial Erratum would be in order, details below. > Do you agree? > > > > Section 4.3.1 says > > > > " the recommended type value is 26." > > > > It should say > > > > " the type value is 26." > > > > Section 4 says > > > > "The Reply Path TLV contains one or more nested sub-TLVs that can be > used" > > > > It should say > > > > "The Reply Path TLV contains zero or more nested sub-TLVs that can be > used" > > > > Section 5.4 says > > > > "When an echo reply is received, if the Reply Mode is "Reply via > > Specified Path" and the Reply Path return code is "The echo reply > was > > sent successfully using the specified Reply Path", and if the > return > > path is an MPLS LSP. The ingress LSR MUST perform FEC validation" > > > > It should say > > > > "When an echo reply is received, if the Reply Mode is "Reply via > > Specified Path" and the Reply Path return code is "The echo reply > was > > sent successfully using the specified Reply Path", and if the > return > > path is an MPLS LSP, the ingress LSR MUST perform FEC validation" > > > > Section 5.4 says > > > > "When an echo reply is received with return code set to "Malformed > > echo request received" and the Subcode set to zero. It is possible > > that the egress LSR may not know the "Reply via Specified Path" > Reply > > Mode, the operator may choose to re-perform another LSP ping by > using > > one of the four Reply Modes defined [RFC4379]." > > > > It should say > > > > "When an echo reply is received with return code set to "Malformed > > echo request received" and the Subcode set to zero, it is possible > > that the egress LSR may not know the "Reply via Specified Path" > Reply > > Mode; the operator may choose to re-perform another LSP ping by > using > > one of the four Reply Modes defined in [RFC4379]." > > > > Notes: > > > > The WG commended a value of 26 to IANA for the "IPv4 RSVP Tunnel > sub-TLV > > Type" which IANA confirmed. Leaving in the 'recommended' introduces a > > element of uncertainty that is best avoided. > > > > As section 4.2 correctly states, the Reply Path TLV can contain zero > sub-TLVs; this > > brings section 4 inline. > > > > In section 5.4, the conditional clauses and the main clause have been > separated > > by periods, not commas, which creates uncertainty as to whether or not > text of > > the main clause has been elided. > > > > > > > > The last two I raised do not seem worthy of an erratum. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Mach Chen" > > To: "t.petch" > > Cc: > > Sent: Tuesday, December 02, 2014 9:29 AM > > > > Hi Tom, > > > > Thanks for your detail reading of the RFC. > > > > > -----Original Message----- > > > From: t.petch [mailto:ietfc@btconnect.com] > > > Sent: Monday, December 01, 2014 11:18 PM > > > To: Mach Chen > > > Cc: mpls@ietf.org > > > Subject: Return Path Specified > > > > > > Mach > > > > > > Some of the language in RFC7110 looks a little quirky. > > > > > > s.4.3.1 > > > "the recommended type value is 26" > > > looks like 'recommended' should have been elided post-IANA > > > > Yes, indeed. > > > > > > > > s.4 > > > "The Reply Path TLV contains one or more nested sub-TLVs that can be > > used" > > > > > > s.4.2 Reply Path (RP) TLV > > > "It is variable in length and can contain zero, one or more Target > > FEC sub-TLVs" > > > > > > seem to be in conflict > > > > The later is the intention and reflects final consensus, but failed to > make the > > former align with this consensus. > > > > > > > > s5.4 > > > "When an echo reply is received, if the Reply Mode is "Reply via > > > Specified Path" and the Reply Path return code is "The echo reply > > was > > > sent successfully using the specified Reply Path", and if the > > return > > > path is an MPLS LSP. " > > > > > > I am left expecting a comma and a main clause (unless the remainder > of > > the > > > paragraph is the main clause). > > > > Yes, there was a main clause, it was considered redundant and removed > directly > > in a version but forgot to change the last period to a comma. > > > > > > > > "When an echo reply is received with return code set to "Malformed > > > echo request received" and the Subcode set to zero. " > > > > > > Ditto > > > > > > And, since I am at it:-) > > > > Same as above. > > > > > > > > s.6 > > > OLD > > > "whether the return path LSP has the destination to the initiator." > > > NEW > > > "whether the return path LSP has a destination of the initiator." > > > > > > OLD > > > "That means, when sending echo request, the initiator > > > should choose a proper source address according the specified > > return > > > path LSP to help the receiver to make the decision." > > > NEW > > > "That means, when sending an echo request, the initiator > > > should select a source address that helps the receiver to > > > find a return path." [I think!] > > > > > > > I am OK with the above refinement. > > > > > Sorry that this is a year late:-( > > > > Indeed. But maybe you could report corresponding erratum, that will be > useful. > > > > I realize that above bugs will be reduced if there was language QA > review at that > > time. > > > > Thanks, > > Mach > > > > > > Tom Petch > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Dec 9 16:05: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 E43CB1A87C4 for ; Tue, 9 Dec 2014 16:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwxv8DxxlU9p for ; Tue, 9 Dec 2014 16:05:14 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB6B1A1C02 for ; Tue, 9 Dec 2014 16:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5866; q=dns/txt; s=iport; t=1418169913; x=1419379513; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=7IxD2GN4imLGHXh19SVNKjU+ZhJiMK5kX+XbSHTbLsA=; b=WXK20zTBFQO9KAD+YCHs58DiiB8s4zgbG5KXVnpI4o1EPNK+KXzx0/WX lwBbHMSEn5BK05lRhKJhyet6bOP3bFiMS+5iJCF1amJ4Qqsju6rz5FTu+ MvIV6Qkt0Js0PkNfbdICgITIgmwv2E8/Z546ojPmwp506MRWS22FJ8X8G Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAIGNh1StJV2R/2dsb2JhbAA/GoMGUlgExgQMhgcCgSgWAQEBAQF9hAIBAQEEAQEBaxcGAQgRAwEBASgoBgsUCQoEARKIJAMRDTjRNw2FXAEBAQEBAQEBAQEBAQEBAQEBAQEBFASNWIFJEQEdCDiEMAWJF4Rxg1aDcIFIi2mFdYNubwGBCzl+AQEB X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208";a="104214748" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP; 10 Dec 2014 00:05:12 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBA05C5J013414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Dec 2014 00:05:12 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.128]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 18:05:12 -0600 From: "Rajiv Asati (rajiva)" To: "Osborne, Eric" , "Tarek Saad (tsaad)" , "mpls@ietf.org" Thread-Topic: [mpls] IETF MPLS-TE YANG Design Discussions Thread-Index: AQHQFAz3Urh0vUA7FUOsj0sqmF/oHg== Date: Wed, 10 Dec 2014 00:05:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.224.35] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <154606D291EA6A4B8C252C54FA406A65@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lJh2kcEEGokWCox9qM7kFjs93aE Subject: Re: [mpls] IETF MPLS-TE YANG Design Discussions 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, 10 Dec 2014 00:05:18 -0000 Hi Eric, Good point. They should likely fit in 'grouping lsp-properties=B9 https://github.com/ietf-mpls-yang/te/blob/master/draft-rgandhi-mpls-te.yang --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: , Eric Date: Tuesday, December 9, 2014 at 8:25 AM To: "Tarek Saad (tsaad)" , "mpls@ietf.org" Subject: Re: [mpls] IETF MPLS-TE YANG Design Discussions >Where do things go which are not strictly tunnel properties, but which >are only used on TE tunnels? Phase 2? I'm thinking of things like >autoroute/igp-shortcuts - it's nothing to do with the links or the LSP >but it really only shows up as a feature used on TE links. > > > > > >eric > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad >>(tsaad) >> Sent: Friday, December 05, 2014 11:37 PM >> To: mpls@ietf.org >> Subject: [mpls] FW: IETF MPLS-TE YANG Design Discussions >>=20 >> Attendees: >> Santosh Esale ; Rakesh Gandhi (rgandhi) >> ; Robert Sawaya (rsawaya) ; Matt >> Hartley (mhartley) ; lizhenbin@huawei.com >> ; zengxinzong@huawei.com >> ; xufeng.liu@ericsson.com >> ; dhruv.dhody@huawei.com >> ; Vero Zheng ; Sam >> Aldrin ; Vishnu Pavan Beeram >> ; jescia.chenxia@huawei.com >> ; Zafar Ali (zali) ; Lou >>Berger >> ; George Swallow (swallow) ; Shah, >> Himanshu ; VICTOR LOPEZ ALVAREZ >> >>=20 >> A group of us (from above) met on Thursday 12/4 for the first time to >>discuss >> MPLS TE YANG model. Below are minutes/notes. Next meeting is scheduled >>for >> next Wednesday 12/10. >>=20 >> - Next steps/AIs: >> - Team: to check-in all existing YANG models to GitHub: >> https://github.com/ietf-mpls-yang/te >> >> - Team: phase 1 to tackle links and link attributes for phase 1 >> * team to communicate proposed attributes over email. >> * in-progress model for TE links will be discussed next week >> - Team: to use email to send proposals >> - Tarek: to send an email with minutes to the WG group >> * include invitations for next meetings >> - Tarek: to schedule weekly meeting for next wednesday onwards >>=20 >> Recording of meeting @ >> https://cisco.webex.com/ciscosales/lsr.php?RCID=3D7a824854ae304230ab579f= 69 >> 77974239 >>=20 >>=20 >> Meeting minutes/Notes: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> - Meeting organization/time (do we need to meet more often?) >> * Meet weekly, >> * OK to keep Thursday 7:00pm EST >> * Poll for next weekly meeting Wednesday 7:00pm EST >> * Consideration for holidays >>=20 >> - Scope of our work: >> * MPLS TE YANG model: >> TE base yang types >> TE base yang model >> RSVP-TE extensions to TE base yang model >> * MPLS Tunnels/links: Config, operational/state, notification, rpcs >> * Topology (proposal to handle in another effort in TEAS) >>=20 >> - Do we need an alias to communicate/send queries? >> * use mpls WG alias as long as manageable (not noisy) >> * may create another alias to use too >>=20 >> - Agree on tools/process: >> * repository in GitHub: https://github.com/ietf-mpls-yang/te >> * check-in all yang models to date: >> * tagged iet-mpls-te-(1/2/3).yang >> * create ietf-mpls-te.yang >> * to include sanitized/agreed data model to be presented at >>IETF >> * create common draft draft-common-mpls-te-yang-model >> * review/commit process? >> * Need to converge >>=20 >> - Divide the work into phases >> * ph1: TE Links: >> link attributes (local TE links) >> - Admin Groups, Extended Admin Groups (config) >> - SRLGs (config) >> - local/remote identifiers (config) >> - reservable bandwidth (config) >> - RSVP per interface properties >> - etc. >> - CAC (state) -- LSPs admitted on the link >>=20 >> * ph2: TE Tunnels: >> * ph3: TE LSPs >> * ph4: TE Globals/templates properties >>=20 >> - Revisit MPLS Yang module(s) hierarchy. Proposal: >> + ietf-mpls-base-types.yang >> | >> + -- ietf-mpls-ldp-types.yang (imports mpls-base-types) >> + -- ietf-mpls-te-types.yang (imports mpls-base-types) >> + -- ietf-mpls-te-pce-types.yang (imports mpls-base-types) >> + -- etc. >> + ietf-mpls-base.yang >> + -- ietf-mpls-te-base.yang (augments ietf-mpls-base.yang) >> + -- ietf-mpls-te-rsvp.yang (augments >>ietf-mpls-te-base.yang) >> + -- ietf-gmpls-te.yang (augments ietf-mpls-te-base.yang >>? augments >> ietf-mpls-te-rsvp.yang, both ?) >> - encoding types (PSC, LSC, FSC, etc.)? >> - OTN/Optical >> + ietf-mpls-oam >> - the MPLS OAM YANG model (to augment MPLS-TE model whenever >> needed) >>=20 >> - Where does MPLS data plane YANG state sit? >> - In respective MPLS Yang models - identified with data plane >>distinguisher >> (?) >> - data/control plane state and data plane state may not be in sync >>always >> (e.g. in transient post FRR) >>=20 >> Regards, >> Tare > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Dec 9 16: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 6349D1A0404 for ; Tue, 9 Dec 2014 16:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-8Q5YMSTk5s for ; Tue, 9 Dec 2014 16:22:14 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6BF1A0399 for ; Tue, 9 Dec 2014 16:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8664; q=dns/txt; s=iport; t=1418170934; x=1419380534; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qa3kUy89xMMEBcnlgW974QXf4OOysv6VID8CQpHHmhc=; b=E7m8kRfF/NQ+iqFvg+DHY1HtaURnepPIsivU7l8ZzdhAKuvtBLH1CrHJ M++/f5CQ4fvNrNECebw0Oj51pyaZsOZI3vFPC+oWmY34MiG1MuIZpLcXE GM6DF8UzodD4eIKTr/6FCcTkHV23k5rkayqsDBQquM7Aibh4ETEbdpUPJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIHAAiRh1StJV2P/2dsb2JhbAA/GoMGUlgEgwHDAwyGBwIcgQwWAQEBAQF9hAIBAQEEAQEBMToXBAIBCBEDAQEBBSMFAgIfBgsUCQgCBAESiCQDEQ04oxKcXgaRQQ2FXAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSCMOIFJEQEdCBAiBAKCY4FNBY4Ig1aDcIFIi2mFdYNubwGBCzl+AQEB X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208";a="378924934" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 10 Dec 2014 00:22:13 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sBA0MCp1006971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Dec 2014 00:22:13 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 18:22:12 -0600 From: "Tarek Saad (tsaad)" To: "Rajiv Asati (rajiva)" , "Osborne, Eric" , "mpls@ietf.org" Thread-Topic: [mpls] IETF MPLS-TE YANG Design Discussions Thread-Index: AQHQFAz3Urh0vUA7FUOsj0sqmF/oHpyIB1YA Date: Wed, 10 Dec 2014 00:22: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.5.141003 x-originating-ip: [10.86.253.56] Content-Type: text/plain; charset="euc-kr" Content-ID: <03F70739FEC5BF44A11E33573F4C3B5B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/GGpYU0aSGTyJ1NsWEaqIeEyEtZs Subject: Re: [mpls] IETF MPLS-TE YANG Design Discussions 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, 10 Dec 2014 00:22:17 -0000 SGkgRXJpYywgUmFqaXYsDQoNClllcywgdGhlIHdheSB3ZSBoYXZlIGdyb3VwZWQgdGhlc2UgcHJv cGVydGllcyAoZS5nLiB0dW5uZWwgaWdwLXNob3J0Y3V0cykNCmluIA0KaHR0cHM6Ly9naXRodWIu Y29tL2lldGYtbXBscy15YW5nL3RlL2Jsb2IvbWFzdGVyL2RyYWZ0LXJnYW5kaGktbXBscy10ZS55 YW5nDQogaXMgdW5kZXIgImdyb3VwaW5nIHJvdXRpbmctcHJvcGVydGllc6GxIHdoaWNoIGlzIHBh cnQgb2YgImdyb3VwaW5nDQp0dW5uZWwtdGVtcGxhdGWhsS4NCg0KUmVnYXJkcywNClRhcmVrDQoN Ck9uIDIwMTQtMTItMDksIDc6MDUgUE0sICJSYWppdiBBc2F0aSAocmFqaXZhKSIgPHJhaml2YUBj aXNjby5jb20+IHdyb3RlOg0KDQo+SGkgRXJpYywNCj4NCj5Hb29kIHBvaW50LiBUaGV5IHNob3Vs ZCBsaWtlbHkgZml0IGluICdncm91cGluZyBsc3AtcHJvcGVydGllc6n2DQo+DQo+DQo+aHR0cHM6 Ly9naXRodWIuY29tL2lldGYtbXBscy15YW5nL3RlL2Jsb2IvbWFzdGVyL2RyYWZ0LXJnYW5kaGkt bXBscy10ZS55YW4NCj5nDQo+DQo+DQo+LS0gDQo+Q2hlZXJzLA0KPlJhaml2IEFzYXRpDQo+RGlz dGluZ3Vpc2hlZCBFbmdpbmVlciwgQ2lzY28NCj4NCj4NCj4NCj4NCj4NCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IDxPc2Jvcm5lPiwgRXJpYyA8ZXJpYy5vc2Jvcm5lQGxldmVs My5jb20+DQo+RGF0ZTogVHVlc2RheSwgRGVjZW1iZXIgOSwgMjAxNCBhdCA4OjI1IEFNDQo+VG86 ICJUYXJlayBTYWFkICh0c2FhZCkiIDx0c2FhZEBjaXNjby5jb20+LCAibXBsc0BpZXRmLm9yZyIN Cj48bXBsc0BpZXRmLm9yZz4NCj5TdWJqZWN0OiBSZTogW21wbHNdIElFVEYgTVBMUy1URSBZQU5H IERlc2lnbiBEaXNjdXNzaW9ucw0KPg0KPj5XaGVyZSBkbyB0aGluZ3MgZ28gd2hpY2ggYXJlIG5v dCBzdHJpY3RseSB0dW5uZWwgcHJvcGVydGllcywgYnV0IHdoaWNoDQo+PmFyZSBvbmx5IHVzZWQg b24gVEUgdHVubmVscz8gIFBoYXNlIDI/ICBJJ20gdGhpbmtpbmcgb2YgdGhpbmdzIGxpa2UNCj4+ YXV0b3JvdXRlL2lncC1zaG9ydGN1dHMgLSBpdCdzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgbGlu a3Mgb3IgdGhlIExTUA0KPj5idXQgaXQgcmVhbGx5IG9ubHkgc2hvd3MgdXAgYXMgYSBmZWF0dXJl IHVzZWQgb24gVEUgbGlua3MuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ZXJpYw0KPj4NCj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IG1wbHMgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUYXJlayBTYWFkDQo+Pj4odHNhYWQpDQo+Pj4g U2VudDogRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCAxMTozNyBQTQ0KPj4+IFRvOiBtcGxzQGll dGYub3JnDQo+Pj4gU3ViamVjdDogW21wbHNdIEZXOiBJRVRGIE1QTFMtVEUgWUFORyBEZXNpZ24g RGlzY3Vzc2lvbnMNCj4+PiANCj4+PiBBdHRlbmRlZXM6DQo+Pj4gU2FudG9zaCBFc2FsZSA8c2Vz YWxlQGp1bmlwZXIubmV0PjsgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4+PiA8cmdhbmRoaUBj aXNjby5jb20+OyBSb2JlcnQgU2F3YXlhIChyc2F3YXlhKSA8cnNhd2F5YUBjaXNjby5jb20+OyBN YXR0DQo+Pj4gSGFydGxleSAobWhhcnRsZXkpIDxtaGFydGxleUBjaXNjby5jb20+OyBsaXpoZW5i aW5AaHVhd2VpLmNvbQ0KPj4+IDxsaXpoZW5iaW5AaHVhd2VpLmNvbT47IHplbmd4aW56b25nQGh1 YXdlaS5jb20NCj4+PiA8emVuZ3hpbnpvbmdAaHVhd2VpLmNvbT47IHh1ZmVuZy5saXVAZXJpY3Nz b24uY29tDQo+Pj4gPHh1ZmVuZy5saXVAZXJpY3Nzb24uY29tPjsgZGhydXYuZGhvZHlAaHVhd2Vp LmNvbQ0KPj4+IDxkaHJ1di5kaG9keUBodWF3ZWkuY29tPjsgVmVybyBaaGVuZyA8dmVyby56aGVu Z0BodWF3ZWkuY29tPjsgU2FtDQo+Pj4gQWxkcmluIDxhbGRyaW4uaWV0ZkBnbWFpbC5jb20+OyBW aXNobnUgUGF2YW4gQmVlcmFtDQo+Pj4gPHZiZWVyYW1AanVuaXBlci5uZXQ+OyBqZXNjaWEuY2hl bnhpYUBodWF3ZWkuY29tDQo+Pj4gPGplc2NpYS5jaGVueGlhQGh1YXdlaS5jb20+OyBaYWZhciBB bGkgKHphbGkpIDx6YWxpQGNpc2NvLmNvbT47IExvdQ0KPj4+QmVyZ2VyDQo+Pj4gPGxiZXJnZXJA bGFibi5uZXQ+OyBHZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdykgPHN3YWxsb3dAY2lzY28uY29tPjsg U2hhaCwNCj4+PiBIaW1hbnNodSA8aHNoYWhAY2llbmEuY29tPjsgVklDVE9SIExPUEVaIEFMVkFS RVoNCj4+PiA8dmljdG9yLmxvcGV6YWx2YXJlekB0ZWxlZm9uaWNhLmNvbT4NCj4+PiANCj4+PiBB IGdyb3VwIG9mIHVzIChmcm9tIGFib3ZlKSBtZXQgb24gVGh1cnNkYXkgMTIvNCBmb3IgdGhlIGZp cnN0IHRpbWUgdG8NCj4+PmRpc2N1c3MNCj4+PiBNUExTIFRFIFlBTkcgbW9kZWwuIEJlbG93IGFy ZSBtaW51dGVzL25vdGVzLiBOZXh0IG1lZXRpbmcgaXMgc2NoZWR1bGVkDQo+Pj5mb3INCj4+PiBu ZXh0IFdlZG5lc2RheSAxMi8xMC4NCj4+PiANCj4+PiAtIE5leHQgc3RlcHMvQUlzOg0KPj4+ICAg ICAtIFRlYW06IHRvIGNoZWNrLWluIGFsbCBleGlzdGluZyBZQU5HIG1vZGVscyB0byBHaXRIdWI6 DQo+Pj4gaHR0cHM6Ly9naXRodWIuY29tL2lldGYtbXBscy15YW5nL3RlDQo+Pj48aHR0cHM6Ly9n aXRodWIuY29tL2lldGYtbXBscy15YW5nL3RlPg0KPj4+ICAgICAtIFRlYW06IHBoYXNlIDEgdG8g dGFja2xlIGxpbmtzIGFuZCBsaW5rIGF0dHJpYnV0ZXMgZm9yIHBoYXNlIDENCj4+PiAgICAgICAg KiB0ZWFtIHRvIGNvbW11bmljYXRlIHByb3Bvc2VkIGF0dHJpYnV0ZXMgb3ZlciBlbWFpbC4NCj4+ PiAgICAgICAgKiBpbi1wcm9ncmVzcyBtb2RlbCBmb3IgVEUgbGlua3Mgd2lsbCBiZSBkaXNjdXNz ZWQgbmV4dCB3ZWVrDQo+Pj4gICAgIC0gVGVhbTogdG8gdXNlIGVtYWlsIHRvIHNlbmQgcHJvcG9z YWxzDQo+Pj4gICAgIC0gVGFyZWs6IHRvIHNlbmQgYW4gZW1haWwgd2l0aCBtaW51dGVzIHRvIHRo ZSBXRyBncm91cA0KPj4+ICAgICAgICAqIGluY2x1ZGUgaW52aXRhdGlvbnMgZm9yIG5leHQgbWVl dGluZ3MNCj4+PiAgICAgLSBUYXJlazogdG8gc2NoZWR1bGUgd2Vla2x5IG1lZXRpbmcgZm9yIG5l eHQgd2VkbmVzZGF5IG9ud2FyZHMNCj4+PiANCj4+PiBSZWNvcmRpbmcgb2YgbWVldGluZyBADQo+ Pj4gDQo+Pj5odHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2xzci5waHA/UkNJRD03 YTgyNDg1NGFlMzA0MjMwYWI1NzlmNjkNCj4+PiA3Nzk3NDIzOQ0KPj4+IA0KPj4+IA0KPj4+IE1l ZXRpbmcgbWludXRlcy9Ob3RlczoNCj4+PiA9PT09PT09PT09PT09PT09PT09PQ0KPj4+IC0gTWVl dGluZyBvcmdhbml6YXRpb24vdGltZSAoZG8gd2UgbmVlZCB0byBtZWV0IG1vcmUgb2Z0ZW4/KQ0K Pj4+ICAgICAqIE1lZXQgd2Vla2x5LA0KPj4+ICAgICAqIE9LIHRvIGtlZXAgVGh1cnNkYXkgNzow MHBtIEVTVA0KPj4+ICAgICAqIFBvbGwgZm9yIG5leHQgd2Vla2x5IG1lZXRpbmcgV2VkbmVzZGF5 IDc6MDBwbSBFU1QNCj4+PiAgICAgKiBDb25zaWRlcmF0aW9uIGZvciBob2xpZGF5cw0KPj4+IA0K Pj4+IC0gU2NvcGUgb2Ygb3VyIHdvcms6DQo+Pj4gICAgICogTVBMUyBURSBZQU5HIG1vZGVsOg0K Pj4+ICAgICAgICAgVEUgYmFzZSB5YW5nIHR5cGVzDQo+Pj4gICAgICAgICBURSBiYXNlIHlhbmcg bW9kZWwNCj4+PiAgICAgICAgIFJTVlAtVEUgZXh0ZW5zaW9ucyB0byBURSBiYXNlIHlhbmcgbW9k ZWwNCj4+PiAgICAgKiBNUExTIFR1bm5lbHMvbGlua3M6IENvbmZpZywgb3BlcmF0aW9uYWwvc3Rh dGUsIG5vdGlmaWNhdGlvbiwgcnBjcw0KPj4+ICAgICAqIFRvcG9sb2d5IChwcm9wb3NhbCB0byBo YW5kbGUgaW4gYW5vdGhlciBlZmZvcnQgaW4gVEVBUykNCj4+PiANCj4+PiAtIERvIHdlIG5lZWQg YW4gYWxpYXMgdG8gY29tbXVuaWNhdGUvc2VuZCBxdWVyaWVzPw0KPj4+ICAgICAqIHVzZSBtcGxz IFdHIGFsaWFzIGFzIGxvbmcgYXMgbWFuYWdlYWJsZSAobm90IG5vaXN5KQ0KPj4+ICAgICAqIG1h eSBjcmVhdGUgYW5vdGhlciBhbGlhcyB0byB1c2UgdG9vDQo+Pj4gDQo+Pj4gLSBBZ3JlZSBvbiB0 b29scy9wcm9jZXNzOg0KPj4+ICAgICAqIHJlcG9zaXRvcnkgaW4gR2l0SHViOiBodHRwczovL2dp dGh1Yi5jb20vaWV0Zi1tcGxzLXlhbmcvdGUNCj4+PiAgICAgICAgICogY2hlY2staW4gYWxsIHlh bmcgbW9kZWxzIHRvIGRhdGU6DQo+Pj4gICAgICAgICAgICAgKiB0YWdnZWQgaWV0LW1wbHMtdGUt KDEvMi8zKS55YW5nDQo+Pj4gICAgICAgICAqIGNyZWF0ZSBpZXRmLW1wbHMtdGUueWFuZw0KPj4+ ICAgICAgICAgICAgICogdG8gaW5jbHVkZSBzYW5pdGl6ZWQvYWdyZWVkIGRhdGEgbW9kZWwgdG8g YmUgcHJlc2VudGVkIGF0DQo+Pj5JRVRGDQo+Pj4gICAgICAgICAqIGNyZWF0ZSBjb21tb24gZHJh ZnQgZHJhZnQtY29tbW9uLW1wbHMtdGUteWFuZy1tb2RlbA0KPj4+ICAgICAqIHJldmlldy9jb21t aXQgcHJvY2Vzcz8NCj4+PiAgICAgICAgICogTmVlZCB0byBjb252ZXJnZQ0KPj4+IA0KPj4+IC0g RGl2aWRlIHRoZSB3b3JrIGludG8gcGhhc2VzDQo+Pj4gICAgICogcGgxOiBURSBMaW5rczoNCj4+ PiAgICAgICAgIGxpbmsgYXR0cmlidXRlcyAobG9jYWwgVEUgbGlua3MpDQo+Pj4gICAgICAgICAt IEFkbWluIEdyb3VwcywgRXh0ZW5kZWQgQWRtaW4gR3JvdXBzIChjb25maWcpDQo+Pj4gICAgICAg ICAtIFNSTEdzIChjb25maWcpDQo+Pj4gICAgICAgICAtIGxvY2FsL3JlbW90ZSBpZGVudGlmaWVy cyAoY29uZmlnKQ0KPj4+ICAgICAgICAgLSByZXNlcnZhYmxlIGJhbmR3aWR0aCAoY29uZmlnKQ0K Pj4+ICAgICAgICAgICAgIC0gUlNWUCBwZXIgaW50ZXJmYWNlIHByb3BlcnRpZXMNCj4+PiAgICAg ICAgICAgICAtIGV0Yy4NCj4+PiAgICAgICAgIC0gQ0FDIChzdGF0ZSkgLS0gTFNQcyBhZG1pdHRl ZCBvbiB0aGUgbGluaw0KPj4+IA0KPj4+ICAgICAqIHBoMjogVEUgVHVubmVsczoNCj4+PiAgICAg KiBwaDM6IFRFIExTUHMNCj4+PiAgICAgKiBwaDQ6IFRFIEdsb2JhbHMvdGVtcGxhdGVzIHByb3Bl cnRpZXMNCj4+PiANCj4+PiAtIFJldmlzaXQgTVBMUyBZYW5nIG1vZHVsZShzKSBoaWVyYXJjaHku IFByb3Bvc2FsOg0KPj4+ICsgaWV0Zi1tcGxzLWJhc2UtdHlwZXMueWFuZw0KPj4+ICAgICAgICB8 DQo+Pj4gICAgICAgICsgLS0gaWV0Zi1tcGxzLWxkcC10eXBlcy55YW5nIChpbXBvcnRzIG1wbHMt YmFzZS10eXBlcykNCj4+PiAgICAgICAgKyAtLSBpZXRmLW1wbHMtdGUtdHlwZXMueWFuZyAgKGlt cG9ydHMgbXBscy1iYXNlLXR5cGVzKQ0KPj4+ICAgICAgICArIC0tIGlldGYtbXBscy10ZS1wY2Ut dHlwZXMueWFuZyAgKGltcG9ydHMgbXBscy1iYXNlLXR5cGVzKQ0KPj4+ICAgICAgICArIC0tIGV0 Yy4NCj4+PiArIGlldGYtbXBscy1iYXNlLnlhbmcNCj4+PiAgICAgICsgLS0gaWV0Zi1tcGxzLXRl LWJhc2UueWFuZyAoYXVnbWVudHMgaWV0Zi1tcGxzLWJhc2UueWFuZykNCj4+PiAgICAgICAgICAg ICAgICsgLS0gaWV0Zi1tcGxzLXRlLXJzdnAueWFuZyAoYXVnbWVudHMNCj4+PmlldGYtbXBscy10 ZS1iYXNlLnlhbmcpDQo+Pj4gICAgICAgICAgICAgICArIC0tIGlldGYtZ21wbHMtdGUueWFuZyAo YXVnbWVudHMgaWV0Zi1tcGxzLXRlLWJhc2UueWFuZw0KPj4+PyBhdWdtZW50cw0KPj4+IGlldGYt bXBscy10ZS1yc3ZwLnlhbmcsIGJvdGggPykNCj4+PiAgICAgICAgICAgICAgICAgICAgIC0gZW5j b2RpbmcgdHlwZXMgKFBTQywgTFNDLCBGU0MsIGV0Yy4pPw0KPj4+ICAgICAgICAgICAgICAgICAg ICAgLSBPVE4vT3B0aWNhbA0KPj4+ICsgaWV0Zi1tcGxzLW9hbQ0KPj4+ICAgICAtIHRoZSBNUExT IE9BTSBZQU5HIG1vZGVsICh0byBhdWdtZW50IE1QTFMtVEUgbW9kZWwgd2hlbmV2ZXINCj4+PiBu ZWVkZWQpDQo+Pj4gDQo+Pj4gLSBXaGVyZSBkb2VzIE1QTFMgZGF0YSBwbGFuZSBZQU5HIHN0YXRl IHNpdD8NCj4+PiAgICAgLSBJbiByZXNwZWN0aXZlIE1QTFMgWWFuZyBtb2RlbHMgLSBpZGVudGlm aWVkIHdpdGggZGF0YSBwbGFuZQ0KPj4+ZGlzdGluZ3Vpc2hlcg0KPj4+ICg/KQ0KPj4+ICAgICAt IGRhdGEvY29udHJvbCBwbGFuZSBzdGF0ZSBhbmQgZGF0YSBwbGFuZSBzdGF0ZSBtYXkgbm90IGJl IGluIHN5bmMNCj4+PmFsd2F5cw0KPj4+IChlLmcuIGluIHRyYW5zaWVudCBwb3N0IEZSUikNCj4+ PiANCj4+PiBSZWdhcmRzLA0KPj4+IFRhcmUNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pm1wbHMgbWFpbGluZyBsaXN0DQo+Pm1wbHNAaWV0 Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+DQoN Cg== From nobody Tue Dec 9 19:21: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 A9A601A88B4; Tue, 9 Dec 2014 19:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIC48n9jGwTO; Tue, 9 Dec 2014 19:21:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA831A8871; Tue, 9 Dec 2014 19:21:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMR36032; Wed, 10 Dec 2014 03:21:30 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Dec 2014 03:21:28 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Wed, 10 Dec 2014 11:21:25 +0800 From: Mach Chen To: Joan Cucchiara Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt Thread-Index: AQHQD1wwmjpyVIbGj0WOTJkx2IIkPpyGn5bwgABDrgCAAU13cA== Date: Wed, 10 Dec 2014 03:21:24 +0000 Message-ID: References: <033e01d013c4$0d4d9390$27e8bab0$@mindspring.com> In-Reply-To: <033e01d013c4$0d4d9390$27e8bab0$@mindspring.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/Pg3IO_htdQrw0_kPUOzbaJ3KoRM Cc: "mib-doctors@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.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, 10 Dec 2014 03:21:34 -0000 Thanks Joan, I have tried OiDViEW MIB Complier and it passed the check. Best regards, Mach > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > Sent: Tuesday, December 09, 2014 11:23 PM > To: Mach Chen > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-oam-id-mib@tools.ietf.= org; > mib-doctors@ietf.org; mpls@ietf.org > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt >=20 > Mach, >=20 > I'll take a look soon. Can you tell me what MIB compilers this has been = compiled > with? >=20 > Thanks, > -Joan >=20 > > -----Original Message----- > > From: Mach Chen [mailto:mach.chen@huawei.com] > > Sent: Monday, December 08, 2014 10:27 PM > > To: jcucchiara@mindspring.com > > Cc: mpls-chairs@tools.ietf.org; > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > > mib-doctors@ietf.org; mpls@ietf.org > > Subject: FW: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > Hi Joan, > > > > The authors uploaded a revision to address the Shepherd's comments. I > > have reviewed this version and am OK with it. > > > > Would you please take a look at the latest version of this document? > > If > you > > are OK with it, we can move it forward. > > > > Thanks, > > Mach > > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Thursday, December 04, 2014 8:49 AM > > To: i-d-announce@ietf.org > > Cc: mpls@ietf.org > > Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Multiprotocol Label Switching > > Working > Group > > of the IETF. > > > > Title : MPLS-TP Operations, Administration, and > Management > > (OAM) Identifiers Management Information Base (MIB) > > Authors : Sam Aldrin > > Venkatesan Mahalingam > > Kannan KV Sampath > > Thomas D. Nadeau > > Filename : draft-ietf-mpls-tp-oam-id-mib-06.txt > > Pages : 27 > > Date : 2014-12-03 > > > > Abstract: > > This memo defines a portion of the Management Information Base (MIB) > > for use with network management protocols in the Internet community. > > In particular, it describes Operations, Administration, and > > Management (OAM) identifiers related managed objects for > > Multiprotocol Label Switching (MPLS) and MPLS based Transport Profil= e > > (TP). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-06 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-oam-id-mib-06 > > > > > > 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 > > > > > > ----- > > No virus found in this message. > > Checked by AVG - www.avg.com > > Version: 2014.0.4794 / Virus Database: 4235/8703 - Release Date: > > 12/08/14 >=20 From nobody Tue Dec 9 21:55: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 618461A1B73 for ; Tue, 9 Dec 2014 21:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8pNvCaFEvD3 for ; Tue, 9 Dec 2014 21:54:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2791A013B for ; Tue, 9 Dec 2014 21:54:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPW51904; Wed, 10 Dec 2014 05:54:53 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Dec 2014 05:54:52 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Wed, 10 Dec 2014 13:54:50 +0800 From: Mach Chen To: "adrian@olddog.co.uk" , "'t.petch'" Thread-Topic: [mpls] Return Path Specified Thread-Index: AQHQDXoM/oPCAG8YmECFH7fEf2ElxZx7jMHwgAVwlp6AA+39sIACqFsm//+ZbYCAATE/gA== Date: Wed, 10 Dec 2014 05:54:50 +0000 Message-ID: References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com>, <03df01d00d7a$0bce8740$4001a8c0@gateway.2wire.net> <00b401d0108b$07065b20$4001a8c0@gateway.2wire.net> <021201d013d7$4a2cf0e0$4001a8c0@gateway.2wire.net> <050301d013e7$17126900$45373b00$@olddog.co.uk> In-Reply-To: <050301d013e7$17126900$45373b00$@olddog.co.uk> 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/Adi6LiVp-rwTYV5CCKDgLk6E1rQ Cc: 'mpls' Subject: Re: [mpls] Return Path Specified 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, 10 Dec 2014 05:54:58 -0000 Thanks Adrian and Tom, Yes, another way to see the Errata is to visit the htmlized version of the = RFC, the link is on the right of header. Best regards, Mach > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, December 10, 2014 3:34 AM > To: 't.petch'; Mach Chen > Cc: 'mpls' > Subject: RE: [mpls] Return Path Specified >=20 > Hi Tom, >=20 > Thanks for the work. > I just approved the three errata reports. >=20 > Actually, it is much nicer to have them as separate reports because it is= clearer > what I am verifying and the notes are easier to read. >=20 > They should appear on the link from the datatracker page for the RFC once= the > scripts have had a chance to turn. >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of t.petch > > Sent: 09 December 2014 17:41 > > To: Mach Chen > > Cc: mpls > > Subject: Re: [mpls] Return Path Specified > > > > Mach > > > > eeeeee .... I thought I knew how to submit an Erratum (memo to self - > > read the I-D before it becomes an RFC). > > > > I have submitted them but it became three separate Errata - I could > > not find a way to stitch them together. > > > > Tom > > > > ----- Original Message ----- > > From: "Mach Chen" > > To: "t.petch" > > Cc: "mpls" > > Sent: Monday, December 08, 2014 1:07 AM > > > > > > Hi Tom, > > > > Yes, I agree with the proposal. > > > > Thanks, > > Mach > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of t.petch > > > Sent: Friday, December 05, 2014 7:58 PM > > > To: Mach Chen > > > Cc: mpls > > > Subject: Re: [mpls] Return Path Specified > > > > > > Mach > > > > > > Yes, that is clearer now. > > > > > > I think that an Editorial Erratum would be in order, details below. > > Do you agree? > > > > > > Section 4.3.1 says > > > > > > " the recommended type value is 26." > > > > > > It should say > > > > > > " the type value is 26." > > > > > > Section 4 says > > > > > > "The Reply Path TLV contains one or more nested sub-TLVs that can be > > used" > > > > > > It should say > > > > > > "The Reply Path TLV contains zero or more nested sub-TLVs that can > > > be > > used" > > > > > > Section 5.4 says > > > > > > "When an echo reply is received, if the Reply Mode is "Reply via > > > Specified Path" and the Reply Path return code is "The echo reply > > was > > > sent successfully using the specified Reply Path", and if the > > return > > > path is an MPLS LSP. The ingress LSR MUST perform FEC validation" > > > > > > It should say > > > > > > "When an echo reply is received, if the Reply Mode is "Reply via > > > Specified Path" and the Reply Path return code is "The echo reply > > was > > > sent successfully using the specified Reply Path", and if the > > return > > > path is an MPLS LSP, the ingress LSR MUST perform FEC validation" > > > > > > Section 5.4 says > > > > > > "When an echo reply is received with return code set to "Malformed > > > echo request received" and the Subcode set to zero. It is possibl= e > > > that the egress LSR may not know the "Reply via Specified Path" > > Reply > > > Mode, the operator may choose to re-perform another LSP ping by > > using > > > one of the four Reply Modes defined [RFC4379]." > > > > > > It should say > > > > > > "When an echo reply is received with return code set to "Malformed > > > echo request received" and the Subcode set to zero, it is possible > > > that the egress LSR may not know the "Reply via Specified Path" > > Reply > > > Mode; the operator may choose to re-perform another LSP ping by > > using > > > one of the four Reply Modes defined in [RFC4379]." > > > > > > Notes: > > > > > > The WG commended a value of 26 to IANA for the "IPv4 RSVP Tunnel > > sub-TLV > > > Type" which IANA confirmed. Leaving in the 'recommended' introduces > > > a element of uncertainty that is best avoided. > > > > > > As section 4.2 correctly states, the Reply Path TLV can contain zero > > sub-TLVs; this > > > brings section 4 inline. > > > > > > In section 5.4, the conditional clauses and the main clause have > > > been > > separated > > > by periods, not commas, which creates uncertainty as to whether or > > > not > > text of > > > the main clause has been elided. > > > > > > > > > > > > The last two I raised do not seem worthy of an erratum. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Mach Chen" > > > To: "t.petch" > > > Cc: > > > Sent: Tuesday, December 02, 2014 9:29 AM > > > > > > Hi Tom, > > > > > > Thanks for your detail reading of the RFC. > > > > > > > -----Original Message----- > > > > From: t.petch [mailto:ietfc@btconnect.com] > > > > Sent: Monday, December 01, 2014 11:18 PM > > > > To: Mach Chen > > > > Cc: mpls@ietf.org > > > > Subject: Return Path Specified > > > > > > > > Mach > > > > > > > > Some of the language in RFC7110 looks a little quirky. > > > > > > > > s.4.3.1 > > > > "the recommended type value is 26" > > > > looks like 'recommended' should have been elided post-IANA > > > > > > Yes, indeed. > > > > > > > > > > > s.4 > > > > "The Reply Path TLV contains one or more nested sub-TLVs that can > > > > be > > > used" > > > > > > > > s.4.2 Reply Path (RP) TLV > > > > "It is variable in length and can contain zero, one or more > > > > Target > > > FEC sub-TLVs" > > > > > > > > seem to be in conflict > > > > > > The later is the intention and reflects final consensus, but failed > > > to > > make the > > > former align with this consensus. > > > > > > > > > > > s5.4 > > > > "When an echo reply is received, if the Reply Mode is "Reply via > > > > Specified Path" and the Reply Path return code is "The echo > > > > reply > > > was > > > > sent successfully using the specified Reply Path", and if the > > > return > > > > path is an MPLS LSP. " > > > > > > > > I am left expecting a comma and a main clause (unless the > > > > remainder > > of > > > the > > > > paragraph is the main clause). > > > > > > Yes, there was a main clause, it was considered redundant and > > > removed > > directly > > > in a version but forgot to change the last period to a comma. > > > > > > > > > > > "When an echo reply is received with return code set to "Malformed > > > > echo request received" and the Subcode set to zero. " > > > > > > > > Ditto > > > > > > > > And, since I am at it:-) > > > > > > Same as above. > > > > > > > > > > > s.6 > > > > OLD > > > > "whether the return path LSP has the destination to the initiator." > > > > NEW > > > > "whether the return path LSP has a destination of the initiator." > > > > > > > > OLD > > > > "That means, when sending echo request, the initiator > > > > should choose a proper source address according the specified > > > return > > > > path LSP to help the receiver to make the decision." > > > > NEW > > > > "That means, when sending an echo request, the initiator > > > > should select a source address that helps the receiver to > > > > find a return path." [I think!] > > > > > > > > > > I am OK with the above refinement. > > > > > > > Sorry that this is a year late:-( > > > > > > Indeed. But maybe you could report corresponding erratum, that will > > > be > > useful. > > > > > > I realize that above bugs will be reduced if there was language QA > > review at that > > > time. > > > > > > Thanks, > > > Mach > > > > > > > > Tom Petch > > > > > > > > > > _______________________________________________ > > > 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 Dec 10 06:38: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 05B221A9023; Wed, 10 Dec 2014 06:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZPOXpOzFulz; Wed, 10 Dec 2014 06:38:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 368F31A1B6A; Wed, 10 Dec 2014 06:38:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210143844.26816.87465.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 06:38:44 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1OSie8xuIkyKjeUGhX0cb8oTnNg Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-li-mpls-ldp-mt-mib-06.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, 10 Dec 2014 14:38:46 -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 : Management Information Base for MPLS LDP Multi Topology Authors : Chen Li Lianyuan Li Lu Huang Tao Chou Quintin Zhao Emily Chen Filename : draft-li-mpls-ldp-mt-mib-06.txt Pages : 29 Date : 2014-12-10 Abstract: This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for Multi-Topology Networks over Multi-protocol Label Switching(MPLS) Label Switching Routers(LSRs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-li-mpls-ldp-mt-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-li-mpls-ldp-mt-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-li-mpls-ldp-mt-mib-06 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 Dec 10 18:39: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 19A7A1A1B63 for ; Wed, 10 Dec 2014 18:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLrpzP7kkzNi for ; Wed, 10 Dec 2014 18:39:02 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631151A1AAC for ; Wed, 10 Dec 2014 18:39:02 -0800 (PST) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB290.namprd05.prod.outlook.com (10.141.23.24) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 02:38:39 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.01.0031.000; Thu, 11 Dec 2014 02:38:39 +0000 From: Chris Bowers To: Mach Chen , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-atlas-mpls-ldp-mrt Thread-Index: AdADEjRBDChTwzKkRkOoLP9pbSL8oQOUZU+Q Date: Thu, 11 Dec 2014 02:38:39 +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.239.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB290; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB290; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(13464003)(199003)(189002)(377454003)(33656002)(20776003)(21056001)(64706001)(101416001)(54356999)(230783001)(92566001)(86362001)(54606007)(50986999)(76176999)(4396001)(31966008)(97736003)(46102003)(87936001)(2656002)(19580395003)(19580405001)(62966003)(77156002)(74316001)(99396003)(107046002)(77096005)(68736005)(120916001)(105586002)(54206007)(40100003)(66066001)(122556002)(106356001)(102836002)(76576001)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB290; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; 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/GsrB9655trsvQulQy7TTPnHkNJM Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 02:39:04 -0000 Mach, Thanks for the comments. Please see inline below [CB]. -----Original Message----- From: Mach Chen [mailto:mach.chen@huawei.com]=20 Sent: Tuesday, November 18, 2014 3:30 AM To: draft-atlas-mpls-ldp-mrt@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; 'Martin Vigoureux'; mpls@ietf.org Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt Hi Authors, I am assigned as a MPLS-RT reviewer of draft-atlas-mpls-ldp-mrt.=20 The draft is well written and ready for a call adoption. I have two comment= s as below: 1. It's better to expand the acronyms (e.g., MRT, LDP, etc.) in the first usag= e. [CB] Agreed. Will add to next revision. 2.=20 "4.1. MRT Capability Advertisement It is not possible to support MRT without supporting the LDP multi- topology extensions, but it is possible that the only use of the multi-topology extensions is for MRT. In that case, a router MAY not negotiate the multi-topology capability and only negotiate the MRT Capability with its LDP peers. Negotiation of the multi-topology capability is not required with negotiation of the MRT capability." Personally, I'd like that the MRT capability does not coupled with MT capab= ility. This may bring extra logic/complex to the implementation. Suppose th= at an LSR advertises the MRT capability to its neighbors and then withdraw = it later, then the receiver LSRs have to determine whether withdraw the MT = capability as well. More seriously, for the MT capability negotiation proce= ss, since it does not know whether there is MRT, so when an LSR receives an= MT withdraw, how it handles its MT capability?=20 [CB] Based on your feedback, we propose to require MT capability to be exp= licitly negotiated whenever MRT capability is negotiated. New proposed tex= t deletes the paragraph above, and adds the following text. Are you OK wi= th this approach? ------------------ 4.1.1. Interaction of MRT Capability and MT Capability =20 An LSR advertising the LDP MRT Capability MUST also advertise the LDP Multi-topology (MT) capability. If an LSR negotiates LDP MRT Capability with an LDP neighbor without also negotiating the LDP MT Capability, the LSR MUST behave as if LDP MRT Capability has not been negotiated and respond with the "MRT Capability negotiated without MT Capability" status code in the LDP Notification message (defined in this document). The E-bit of this Notification should be set to 0 to indicate that this is an Advisory Notification. The LDP session SHOULD NOT be terminated. =20 ......... =20 7. IANA Considerations ...... IANA is requested to allocate a value for the new LDP Status Code (the first free value in the range 0x00000032-0x00000036) from the LDP registry "Status Code Name Space": "MRT Capability negotiated without MT Capability" (TBA-MRT-LDP-3). =20 Value E Description Reference Notes / Reg. Date ------------- - ------------------------- --------- ----------------- TBA-MRT-LDP-3 0 MRT Capability negotiated [This draft] without MT Capability --------- Best regards, Mach From nobody Wed Dec 10 18:50: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 333641A1A91; Wed, 10 Dec 2014 18:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOndwzO-Dltp; Wed, 10 Dec 2014 18:50:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F891A1AAC; Wed, 10 Dec 2014 18:50:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141211025020.28760.58271.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 18:50:20 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NHpDjr-6F90HlAJPYjSEdJqsrZc Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 02:50:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Encapsulating MPLS in UDP Authors : Xiaohu Xu Nischal Sheth Lucy Yong Ross Callon David Black Filename : draft-ietf-mpls-in-udp-08.txt Pages : 17 Date : 2014-12-10 Abstract: This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol). The MPLS-in-UDP encapsulation technology MUST only be deployed within a service provider network or networks of an adjacent set of co-operating service providers where congestion control is not a concern. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 10 19:20: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 174781A802C; Wed, 10 Dec 2014 19:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l6Ucu4BjOQY; Wed, 10 Dec 2014 19:20:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826D11A7017; Wed, 10 Dec 2014 19:20:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMS43760; Thu, 11 Dec 2014 03:20:03 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Dec 2014 03:20:02 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.199]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 11 Dec 2014 11:19:57 +0800 From: Xuxiaohu To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-in-udp-08.txt Thread-Index: AQHQFO1ard30L+ymaU+CGnGv0IMp6JyJt3Qg Date: Thu, 11 Dec 2014 03:19:56 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082EB5D1@NKGEML512-MBS.china.huawei.com> References: <20141211025020.28760.58271.idtracker@ietfa.amsl.com> In-Reply-To: <20141211025020.28760.58271.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] 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/FkRLqfkMw6VBC_n_CiojmBEON-0 Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-in-udp-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 03:20:08 -0000 Hi all, The major changes since -07 version are: 1) Two co-authors (Carlos and Yongbin) are moved from the co-author list to= the contributor list due to the strict limitation on the total number of c= o-authors. 2) One additional contributor (Adrian) is added. Best regards, Xiaohu > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, December 11, 2014 10:50 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiprotocol Label Switching Working G= roup of > the IETF. >=20 > Title : Encapsulating MPLS in UDP > Authors : Xiaohu Xu > Nischal Sheth > Lucy Yong > Ross Callon > David Black > Filename : draft-ietf-mpls-in-udp-08.txt > Pages : 17 > Date : 2014-12-10 >=20 > Abstract: > This document specifies an IP-based encapsulation for MPLS, called > MPLS-in-UDP (User Datagram Protocol). The MPLS-in-UDP encapsulation > technology MUST only be deployed within a service provider network or > networks of an adjacent set of co-operating service providers where > congestion control is not a concern. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-in-udp-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-in-udp-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Dec 10 22:57:10 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 4B4671A8A8D for ; Wed, 10 Dec 2014 22:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3wF3SGm_fpQ for ; Wed, 10 Dec 2014 22:57:04 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F68A1A8A46 for ; Wed, 10 Dec 2014 22:57:04 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.161.96]) (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 169151801215; Thu, 11 Dec 2014 07:57:00 +0100 (CET) Message-ID: <54894036.8040900@pi.nu> Date: Thu, 11 Dec 2014 14:56:54 +0800 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 Farrel References: <20141211025020.28760.58271.idtracker@ietfa.amsl.com> In-Reply-To: <20141211025020.28760.58271.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141211025020.28760.58271.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7q2483M_GJ6s8MfUU3o-YHQnHk8 Cc: "mpls@ietf.org" Subject: [mpls] Fwd: I-D Action: draft-ietf-mpls-in-udp-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 06:57:09 -0000 Adrian, Since you have been added as a contributor between version -07 and -08, I need an IPR statement from you. /Loa -------- Original Message -------- Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-08.txt Date: Wed, 10 Dec 2014 18:50:20 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Encapsulating MPLS in UDP Authors : Xiaohu Xu Nischal Sheth Lucy Yong Ross Callon David Black Filename : draft-ietf-mpls-in-udp-08.txt Pages : 17 Date : 2014-12-10 Abstract: This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol). The MPLS-in-UDP encapsulation technology MUST only be deployed within a service provider network or networks of an adjacent set of co-operating service providers where congestion control is not a concern. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Dec 11 01:58: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 37AAE1ACDB2 for ; Thu, 11 Dec 2014 01:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P2kVC9oQohH for ; Thu, 11 Dec 2014 01:58:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0EA1ACDB4 for ; Thu, 11 Dec 2014 01:58:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPX88638; Thu, 11 Dec 2014 09:58:22 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Dec 2014 09:58:21 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Thu, 11 Dec 2014 17:58:14 +0800 From: Mach Chen To: "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAVKPwyhbH8gQvjQzCk980lKW6BMQ== Date: Thu, 11 Dec 2014 09:58:12 +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/7mF7HrmjzwBgYtgwWjI-QbOsKjI Cc: mpls , "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 11 Dec 2014 09:58:27 -0000 Hi Authors, I have finished my MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipat= h, here are my comments, hope they are help. 1.=20 This is a useful draft that tries to address a real network problem. The so= lution part works but may need some optimization.=20 2. The draft uses the LAG Interface Info TLV to implicitly notify the responde= rs to return the LAG member information. IMHO, the G bit is more appropriat= e for the purpose, and then there is no need to carry the LAG Interface Inf= o TLV in the echo request.=20 3. According to the definition of LAG Interface Info TLV, it is used to return= the LAG process capable of the responder LSR (not specific LAG interface).= Actually, it can be generalized as an LSR capability TLV that is not only = limited to LAG capability, it may be used for future extension. 4. Section 3 and Section 4 have large amount of overlap context. I think Secti= on 3 is actually a subset (just for discovery) of Section 4. I'd suggest to= merge the two sections.=20 5. Section 3.2: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDMAP fields describing LAG interface with DS Flags G set | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I got confused when I firstly see this, suggest to use the whole DDMAP stru= cture or just show the sub-TLV part of DDMAP. If you really want to use thi= s style, it's better to replace "|" with "~". There is the same issue for Figure 3. 6. Section 4.3: o Error case: * Traversing LAG member=3D1 at TTL=3Dn results in LAG member=3D1' as the incoming interface at TTL=3Dn+1. * Traversing LAG member=3D2 at TTL=3Dn results in LAG member=3D1' as the incoming interface at TTL=3Dn+1. For the first bullet, I guess you intend to say: * Traversing LAG member=3D1 at TTL=3Dn results in LAG member=3D2' as the incoming interface at TTL=3Dn+1. BTW, why the above cases are error cases? If 1 (or 2) and 1' (or 2') are s= upposed to be the two ends of a member link. If a packet traversing 1 at TT= L=3Dn, how will the packet come out of other interfaces other than 1'?=20 I guess you intend to say a packet is expected to be traversed 1 at TTL=3Dn= , but mis-forwarded to other link, then result in the packet comes out of t= he non-desired link at TTL=3Dn+1. Right? Best regards, Mach From nobody Thu Dec 11 07:48: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 E37B11ACEFB for ; Thu, 11 Dec 2014 07:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIdADJF6Q8Ud for ; Thu, 11 Dec 2014 07:48:08 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAA21A9009 for ; Thu, 11 Dec 2014 07:48:04 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBBFm2si026191; Thu, 11 Dec 2014 15:48:02 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBBFm1kn026185 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 15:48:02 GMT From: "Adrian Farrel" To: "'Loa Andersson'" Date: Thu, 11 Dec 2014 15:47:57 -0000 Message-ID: <036f01d01559$d5ed8490$81c88db0$@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: AdAVWdClimC162nDTnGsacoym/agKw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21168.004 X-TM-AS-Result: No--19.475-10.0-31-10 X-imss-scan-details: No--19.475-10.0-31-10 X-TMASE-MatchedRID: 6otD/cJAac2nykMun0J1wmzBijri5+RVYpovC7zX5q/OBknaLbUbt8Lm p4jPUF8tRFsqph676uDCO1VyCzVozruz8zGC5XEHU+OjsPhIWDjeODcrQ+LNziSPufJfHBYzaVt vYPBkvgPjwIdTpLUhIc4JGyAngPORVyi2q9SFnKpWjqaf7FeZ1batoqEMsH1djNnoU1fopouUfD H3TE2AyBQ5T6KyKLqzuuq7MJRSxv65GIsyuQXvep1U1lojafr/mGSSol4Uei0z91mDYZLM5bJUB icQ01GRgEBR2HjnXivaZiJAj8isJFYwdrAHWNZlHPCema1j/6t9LQinZ4QefL6qvLNjDYTwzz3j ehzeneyrusVRy4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NU5P9b3ewjXbCHhDEp7a1bKa6R0 Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-ietf-mpls-in-udp-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 15:48:11 -0000 Thanks Loa, I am unaware of any IPR that needs to be disclosed for this document. Thanks, Adrian > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 11 December 2014 06:57 > To: Adrian Farrel > Cc: mpls@ietf.org > Subject: Fwd: [mpls] I-D Action: draft-ietf-mpls-in-udp-08.txt > > Adrian, > > Since you have been added as a contributor between version -07 and -08, > I need an IPR statement from you. > > /Loa > > > -------- Original Message -------- > Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-08.txt > Date: Wed, 10 Dec 2014 18:50:20 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: mpls@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > Title : Encapsulating MPLS in UDP > Authors : Xiaohu Xu > Nischal Sheth > Lucy Yong > Ross Callon > David Black > Filename : draft-ietf-mpls-in-udp-08.txt > Pages : 17 > Date : 2014-12-10 > > Abstract: > This document specifies an IP-based encapsulation for MPLS, called > MPLS-in-UDP (User Datagram Protocol). The MPLS-in-UDP encapsulation > technology MUST only be deployed within a service provider network or > networks of an adjacent set of co-operating service providers where > congestion control is not a concern. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-in-udp-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Dec 11 16:38: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 B64E31A90C9 for ; Thu, 11 Dec 2014 16:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-VyC8pXkPjc for ; Thu, 11 Dec 2014 16:38:43 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D3F1A90C8 for ; Thu, 11 Dec 2014 16:38:42 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-04-5489dc6daf39 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 80.3F.25146.D6CD9845; Thu, 11 Dec 2014 19:03:26 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 19:38:40 -0500 From: Gregory Mirsky To: Chris Bowers , Loa Andersson , Mach Chen , "stbryant@cisco.com" Thread-Topic: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Thread-Index: AQHP8qH/uHA7SUa1rUOsPm4H8eedM5xnCKiAgBp3ErCACaraoIAANMiQ Date: Fri, 12 Dec 2014 00:38:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8B2CD7@eusaamb103.ericsson.se> References: <20141027160938.19401.5417.idtracker@ietfa.amsl.com> <544F7D57.8030609@pi.nu> <7347100B5761DC41A166AC17F22DF1121B89337A@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8B2CD7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyuXRPrG7enc4Qg3krRCx+rHe1eHZ+GaPF v7lzmC0urBW2+H5pCYvFraUrWS3OPZ3D6MDuMeX3RlaPliNvWT2WLPnJ5HG96Sq7x6zpbWwe Xy5/Zgtgi+KySUnNySxLLdK3S+DK6D55lrng0SumihuPv7E3MH44zNTFyMkhIWAisfT+VjYI W0ziwr31QDYXh5DAEUaJprdPWSCc5YwSLefPMYNUsQkYSbzY2MMOkhARmMAo8fDjBWYQh1lg O6PE0edNYLOEBewkpk7aCLZDRMBe4nPrF9YuRg4g203i3bxykDCLgKrEhbnPwYbyCvhKvFh7 mBFi20EmiZnnnrGDJDgFoiX+bl7ECmIzAt33/dQasJnMAuISt57Mh/pBQGLJnvPMELaoxMvH /1ghbCWJOa+vMUPU50sc+roHapmgxMmZT1gmMIrOQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18 zQxjnznwmAlZfAEj+ypGjtLi1LLcdCPDTYzAqD0mwea4g3HBJ8tDjAIcjEo8vBs4OkOEWBPL iitzDzFKc7AoifNqVs8LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBo/PuD3GX5yxeMp21N vX9rYt75JW/fTmiWXrrpenFj6t9rExoTd1+8Ot2FT7mwRebFZttaS+nIj3JcbPF6namTLrzU /Z4bpXvYS/y32I2/6genXf3YKrfm/oPKI++N/WKCbpun1nuk70p6d8cuVIbnx8rHRmdnfcze Wnx34t7m5uTvi0M+R5fvV2Ipzkg01GIuKk4EAMJQclO7AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/TY2lQeBZHeAO4cm9x-pEn0Veiks Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-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, 12 Dec 2014 00:38:49 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8B2CD7eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, I apologies for belated response to your thorough consideration o= f my comments. Please find my notes in-lined and tagged GIM>>. I'm fine with the explanations and recommend the draft to be considered for= WG adoption. Regards, Greg From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Friday, December 12, 2014 5:19 AM To: Gregory Mirsky Subject: FW: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Greg, Are you good with these responses? Chris From: Chris Bowers Sent: Monday, December 08, 2014 9:47 AM To: 'Gregory Mirsky'; Loa Andersson; Mach Chen; stbryant@cisco.com Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: RE: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Greg, Thanks for the review. Please see responses inline. From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, November 18, 2014 3:31 PM To: Loa Andersson; Mach Chen; stbryant@cisco.com Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Dear Authors, MPLS WG chairs, et. al, I've been asked to review the draft-atlas-mpls-ldp-mrt-02.txt. The document is very well written, technically sound and clearly addresses = integral part of MRT-FRR solution. It is ready for the WG adoption in my opinion. Below are my comments to authors that are should not be viewed as gating th= e adoption: * section 4.1, I'd consider padding the MRT Capability TLV with ext= ra 3 octets and changing the Length field accordingly to 4; [CB] I'm not sure that I understand your suggestion here. The MRT Capabil= ity TLV we are defining is an LDP Capability Parameter TLV (as defined in s= ection 3 of RFC 5561). It carries no Capability Data. So its length is 1 = to account for the S-bit and 7 reserved bits. Are you suggesting that we a= dd 3 bytes of empty Capability Data and set the length to 4? Or did you ha= ve something else in mind? GIM>> Yes, the 3 bytes of additional padding to make Length 4. * section 4.3, a bit strange that IANA request to allocate MT-IDs f= or MRT-Red and MRT-Blue is in ietf-rtgwg-mrt-frr-architecture and not in th= is document as for Rainbow-MRT's MT-ID (section 4.2). Perhaps by grouping a= ll in one request would make it logistically easier and minimize inter-depe= ndency of the MRT-FRR documents. [CB] The reasoning behind the current placement of the IANA requests is th= e following. (Note that we'll be changing "LDP Multi-Topology (MT) ID Name = Space" to "MPLS Multi-Topology Identifiers" in the IANA section of ietf-rt= gwg-mrt-frr-architecture to match the change in naming of the IANA registry= that occurred as drafts leading to RFC7307 were revised.) The MPLS Multi-Topology Identifiers registry requests in ietf-rtgwg-mrt-frr= -architecture are for MPLS MT-IDs for MRT-Red and Blue for the Default Pro= file. The Default Profile specifies for example using the lowpoint algorit= hm to compute the GADAG. This Default Profile has MRT profile value=3D0. = It is possible that a future document could specify another MRT profile wi= th a different algorithm for computing the GADAG which we could call MRT Pr= ofile1 with MRT profile value =3D1. This new document would also need to i= nclude an IANA request to allocate values for MPLS MT-IDs for MRT-Red and B= lue for MRT Profile 1. The MPLS Multi-Topology Identifiers registry request in draft-atlas-mpls-ld= p-mrt is for the Rainbow MRT MPLS MT-ID. This MPLS MT-ID provides a way t= o identify the Rainbow MRT FEC, which provides an optimization specific to = LDP forwarding on MRTs at ABRs. The Rainbow FEC forwarding behavior is ind= ependent of the MRT Profile, so if different MRT Profiles are defined in th= e future, a new Rainbow MRT MPLS MT-ID will not need to be defined. So th= e idea is that the IANA requests in ietf-rtgwg-mrt-frr-architecture are spe= cific to the Default MRT Profile. In the supporting documents like draft-a= tlas-mpls-ldp-mrt as well as draft-li-isis-mrt and draft-atlas-ospf-mrt the= IANA requests are for values that are independent of a specific MRT profil= e. GIM>> Thank you for the utmost detailed explanation, I think I understand i= t better now. Had or would these relationships between objects of IANA regi= stries, that you've described, be captured in any of MRT documents? I think= that it is clearly should not delay this document adoption by the WG but t= horough explanation in IANA Considerations section, even if it repeats cont= ent of identical sections in other documents related to MRT, would be helpf= ul. Thank you for your kind consideration. Regards, Greg -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Tuesday, October 28, 2014 4:26 AM To: Mach Chen; stbryant@cisco.com; Gregory Mirsk= y Cc: mpls-chairs@tools.ietf.org; VIGOUREU= X, MARTIN (MARTIN); draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Mach, Stewart and Greg, You have be selected as MPLS-RT reviewers for draft-atlas-mpls-ldp-mrt. Note to authors: You have been CC'd on this email so that you can know that= this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (i= e, is it likely to be actually useful in operational networks), and is the = document technically sound? We are interested in knowing whether the docum= ent is ready to be considered for WG adoption (ie, it doesn't have to be pe= rfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secreta= ry, and CC'd to the MPLS WG email list. If necessary, comments may be sent = privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document= , and what can wait until the document is a working group document and the = working group has the revision control. Are you able to review this draft by Nov 18, 2014? Please respond in a time= ly fashion. Thanks, Loa (as MPLS WG chair) -------- Original Message -------- Subject: [mpls] I-D Action: draft-atlas-mpls-ldp-mrt-02.txt Date: Mon, 27 Oct 2014 09:09:38 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gr= oup of the IETF. Title : LDP Extensions to Support Maximally Redundant Trees Authors : Alia Atlas Kishore Tiruveedhula Chris Bowers Jeff Tantsura IJsbrand Wijnands Filename : draft-atlas-mpls-ldp-mrt-02.txt Pages : 16 Date : 2014-10-27 Abstract: This document specifies extensions to LDP to support the creation of label-switched paths for Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR. The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for LSRs and LERs advertising the MRT Capability. MRT-FRR uses LDP multi-topology extensions and requires three different multi-topology IDs to be allocated from the LDP MT-ID space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-atlas-mpls-ldp-mrt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-atlas-mpls-ldp-mrt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-atlas-mpls-ldp-mrt-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_7347100B5761DC41A166AC17F22DF1121B8B2CD7eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chris, I apologies for= belated response to your thorough consideration of my comments. Please fin= d my notes in-lined and tagged GIM>>.

 <= /p>

I’m fine with the e= xplanations and recommend the draft to be considered for WG adoption.<= /o:p>

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Chris Bo= wers [mailto:cbowers@juniper.net]
Sent: Friday, December 12, 2014 5:19 AM
To: Gregory Mirsky
Subject: FW: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt<= /o:p>

 

Greg,

 <= /p>

Are you good with these r= esponses? 

 <= /p>

Chris

 <= /p>

From: Chris = Bowers
Sent: Monday, December 08, 2014 9:47 AM
To: 'Gregory Mirsky'; Loa Andersson; Mach Chen; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org
Subject: RE: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt<= /o:p>

 

Greg, 

 <= /p>

Thanks for the review.&nb= sp; Please see responses inline.

 <= /p>

From: mpls [= mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 18, 2014 3:31 PM
To: Loa Andersson; Mach Chen; = stbryant@cisco.com
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.tx= t

 

Dear Authors, MPLS WG chairs, et. al,

I've been asked to review the draft-atl= as-mpls-ldp-mrt-02.txt.

 

The document is very well written, tech= nically sound and clearly addresses integral part of MRT-FRR solution.=

It is ready for the WG adoption in my o= pinion.

 

Below are my comments to authors that a= re should not be viewed as gating the adoption:

·         section 4.1, I'd consider padding the MRT Capability TL= V with extra 3 octets and changing the Length field accordingly to 4;<= /o:p>

[CB]  I’m not sure that I un= derstand your suggestion here.  The MRT Capability TLV we are defining is an LDP Capability Parameter TLV (as defined in section 3 of RFC 5561).&= nbsp; It carries no Capability Data.  So its length is 1 to account fo= r the S-bit and 7 reserved bits.  Are you suggesting that we add 3 byt= es of empty Capability Data and set the length to 4?  Or did you have something else in mind?

GIM>> Yes, the 3 bytes of additio= nal padding to make Length 4.

·         section 4.3, a bit strange that IANA request to allocat= e MT-IDs for MRT-Red and MRT-Blue is in ietf-rtgwg-mrt-frr-architecture and= not in this document as for Rainbow-MRT’s MT-ID (section 4.2). Perhaps by grouping all in one request would make it logistically ea= sier and minimize inter-dependency of the MRT-FRR documents.

[CB]  The reasoning behind the cur= rent placement of the IANA requests is the following. (Note that we’ll be changing “LDP Multi-Topology (MT) ID Name Space”= ; to  “MPLS Multi-Topology Identifiers” in the IANA sectio= n of ietf-rtgwg-mrt-frr-architecture to match the change in naming of the I= ANA registry that occurred as drafts leading to RFC7307 were revised.)=

The MPLS Multi-Topology Identifiers reg= istry requests in ietf-rtgwg-mrt-frr-architecture are for MPLS MT-IDs  for MRT-Red and Blue for the Default Profile.  The = Default Profile specifies for example using the lowpoint algorithm to compu= te the GADAG.  This Default Profile has MRT profile value=3D0. &n= bsp; It is possible that a future document could specify another MRT profile with a different algorithm for computing the GADAG which we co= uld call MRT Profile1 with MRT profile value =3D1.  This new document = would also need to include an IANA request to allocate values for MPLS MT-I= Ds for MRT-Red and Blue for MRT Profile 1.

The MPLS Multi-Topology I= dentifiers registry request in draft-atlas-mpls-ldp-mrt is for the Rainbow = MRT MPLS MT-ID.  This MPLS  MT-ID provides a way to identify the Rainbow MRT FEC, which provides an optimization specific to LDP forwar= ding on MRTs at ABRs.  The Rainbow FEC forwarding behavior is independ= ent of the MRT Profile, so if different MRT Profiles are defined in the fut= ure, a new Rainbow MRT MPLS MT-ID will not need to be defined.   So the idea is that the IANA requests = in ietf-rtgwg-mrt-frr-architecture are specific to the Default MRT Profile.=   In the supporting documents like draft-atlas-mpls-ldp-mrt as well as= draft-li-isis-mrt and draft-atlas-ospf-mrt the IANA requests are for values that are independent of a specific MRT profil= e. 

 <= /p>

GIM>> Thank you for= the utmost detailed explanation, I think I understand it better now. Had o= r would these relationships between objects of IANA registries, that you’ve described, be captured in any of MRT documents? I think = that it is clearly should not delay this document adoption by the WG but th= orough explanation in IANA Considerations section, even if it repeats conte= nt of identical sections in other documents related to MRT, would be helpful.

 <= /p>

 

Thank you for your kind consideration.<= o:p>

 

      &nb= sp; Regards,

      &nb= sp;         Greg<= /p>

 

-----Original Message-----
From: Loa Andersson [mailt= o:loa@pi.nu]
Sent: Tuesday, October 28, 2014 4:26 AM
To: Mach Chen; st= bryant@cisco.com; Gregory Mirsky
Cc: mpls-= chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); draft-atlas-mpls-ldp-mrt@tools.ietf.org
Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt

 

Mach, Stewart and Greg,

 

You have be selected as MPLS-RT reviewe= rs for  draft-atlas-mpls-ldp-mrt.

 

Note to authors: You have been CC'd on = this email so that you can know that this review is going on. However, plea= se do not review your own document.

 

Reviews should comment on whether the d= ocument is coherent, is it useful (ie, is it likely to be actually useful i= n operational networks), and is the document technically sound?  We are interested in knowing whether the document is ready to= be considered for WG adoption (ie, it doesn't have to be perfect at this p= oint, but should be a good start).

 

Reviews should be sent to the document = authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list.= If necessary, comments may be sent privately to only the WG chairs.

 

If you have technical comments you shou= ld try to be explicit about what

*really* need to be resolved before ado= pting it as a working group document, and what can wait until the document = is a working group document and the working group has the revision control.

 

Are you able to review this draft by No= v 18, 2014? Please respond in a timely fashion.

 

 

Thanks, Loa

(as MPLS WG chair)

 

 

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

Subject: [mpls] I-D Action: draft-atlas= -mpls-ldp-mrt-02.txt

Date: Mon, 27 Oct 2014 09:09:38 -0700

 

 

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.=

 

      &nb= sp;  Title          = : LDP Extensions to Support Maximally Redundant

Trees

      &nb= sp;  Authors         : Alia At= las

      &nb= sp;            =         Kishore Tiruveedhula<= /span>

      &nb= sp;            =         Chris Bowers

      &nb= sp;            =         Jeff Tantsura<= /p>

      &nb= sp;            =         IJsbrand Wijnands

      &nb= sp; Filename        : draft-atlas-mpls-l= dp-mrt-02.txt

      &nb= sp; Pages           : 16<= o:p>

      &nb= sp; Date            = : 2014-10-27

 

Abstract:

    This document specif= ies extensions to LDP to support the creation of

    label-switched paths= for Maximally Redundant Trees (MRT).  A prime

    use of MRTs is for u= nicast and multicast IP/LDP Fast-Reroute, which

    we will refer to as = MRT-FRR.

 

    The sole protocol ex= tension to LDP is simply the ability to advertise

    an MRT Capability.&n= bsp; This document describes that extension and the

    associated behavior = expected for LSRs and LERs advertising the MRT

    Capability.

 

    MRT-FRR uses LDP mul= ti-topology extensions and requires three

    different multi-topo= logy IDs to be allocated from the LDP MT-ID

    space.

 

 

The IETF datatracker status page for th= is draft is:

 

There's also a htmlized version availab= le at:

 

A diff from the previous version is ava= ilable at:

 

 

Please note that it may take a couple o= f minutes from the time of submission until the htmlized version and diff a= re available at tools.ietf.org.

 

Internet-Drafts are also available by a= nonymous FTP at:

 

_______________________________________= ________

mpls mailing list

 

 

 

--_000_7347100B5761DC41A166AC17F22DF1121B8B2CD7eusaamb103erics_-- From nobody Thu Dec 11 18:26:48 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 C8F821A914F for ; Thu, 11 Dec 2014 18:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKjkzYphvg_H for ; Thu, 11 Dec 2014 18:26:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA801A914D for ; Thu, 11 Dec 2014 18:26:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMT46127; Fri, 12 Dec 2014 02:26:42 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 12 Dec 2014 02:26:41 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Fri, 12 Dec 2014 10:26:37 +0800 From: Mach Chen To: Chris Bowers , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-atlas-mpls-ldp-mrt Thread-Index: AdADEjRBDChTwzKkRkOoLP9pbSL8oQOUZU+QARO6plA= Date: Fri, 12 Dec 2014 02:26:36 +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/5He5_ahYy8hkwdiou9Dz_Me8MZY Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 02:26:46 -0000 Hi Chris, Thanks for considering my comments, I am OK with your proposal. Best regards, Mach > -----Original Message----- > From: Chris Bowers [mailto:cbowers@juniper.net] > Sent: Thursday, December 11, 2014 10:39 AM > To: Mach Chen; draft-atlas-mpls-ldp-mrt@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org; 'Martin Vigoureux'; mpls@ietf.org > Subject: RE: MPLS-RT review of draft-atlas-mpls-ldp-mrt >=20 > Mach, >=20 > Thanks for the comments. Please see inline below [CB]. >=20 > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Tuesday, November 18, 2014 3:30 AM > To: draft-atlas-mpls-ldp-mrt@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org; 'Martin Vigoureux'; mpls@ietf.org > Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt >=20 > Hi Authors, >=20 > I am assigned as a MPLS-RT reviewer of draft-atlas-mpls-ldp-mrt. >=20 > The draft is well written and ready for a call adoption. I have two comme= nts as > below: >=20 > 1. >=20 > It's better to expand the acronyms (e.g., MRT, LDP, etc.) in the first us= age. >=20 > [CB] Agreed. Will add to next revision. >=20 > 2. >=20 > "4.1. MRT Capability Advertisement > It is not possible to support MRT without supporting the LDP multi- > topology extensions, but it is possible that the only use of the > multi-topology extensions is for MRT. In that case, a router MAY not > negotiate the multi-topology capability and only negotiate the MRT > Capability with its LDP peers. Negotiation of the multi-topology > capability is not required with negotiation of the MRT capability." >=20 > Personally, I'd like that the MRT capability does not coupled with MT cap= ability. > This may bring extra logic/complex to the implementation. Suppose that an= LSR > advertises the MRT capability to its neighbors and then withdraw it later= , then the > receiver LSRs have to determine whether withdraw the MT capability as wel= l. > More seriously, for the MT capability negotiation process, since it does = not know > whether there is MRT, so when an LSR receives an MT withdraw, how it hand= les > its MT capability? >=20 > [CB] Based on your feedback, we propose to require MT capability to be > explicitly negotiated whenever MRT capability is negotiated. New propose= d > text deletes the paragraph above, and adds the following text. Are you = OK > with this approach? >=20 > ------------------ > 4.1.1. Interaction of MRT Capability and MT Capability >=20 > An LSR advertising the LDP MRT Capability MUST also advertise the LDP > Multi-topology (MT) capability. If an LSR negotiates LDP MRT > Capability with an LDP neighbor without also negotiating the LDP MT > Capability, the LSR MUST behave as if LDP MRT Capability has not been > negotiated and respond with the "MRT Capability negotiated without MT > Capability" status code in the LDP Notification message (defined in > this document). The E-bit of this Notification should be set to 0 to > indicate that this is an Advisory Notification. The LDP session > SHOULD NOT be terminated. >=20 > ......... >=20 > 7. IANA Considerations > ...... > IANA is requested to allocate a value for the new LDP Status Code > (the first free value in the range 0x00000032-0x00000036) from the > LDP registry "Status Code Name Space": "MRT Capability negotiated > without MT Capability" (TBA-MRT-LDP-3). >=20 > Value E Description Reference Notes / Reg. > Date > ------------- - ------------------------- --------- ----------------= - > TBA-MRT-LDP-3 0 MRT Capability negotiated [This draft] > without MT Capability >=20 > --------- >=20 >=20 >=20 >=20 > Best regards, > Mach From nobody Thu Dec 11 21:02: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 C94721A7017; Thu, 11 Dec 2014 21:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V6g58b19OTU; Thu, 11 Dec 2014 21:01:52 -0800 (PST) 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 6ED491A1A69; Thu, 11 Dec 2014 21:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10542; q=dns/txt; s=iport; t=1418360512; x=1419570112; h=from:to:cc:subject:date:message-id:mime-version; bh=MzLtlaAa9nXl0YOTjfpZs1LgldcS5gUmAV3f2DpQHq0=; b=hIdmaXD26s5l89mOcpGDgRD6wZyDnWBThGMGCiqpCaaZ4Jquk2atIX8J 6vx6t6wEMsEcffNKS030UxTNRzIqskMBR5RnPct3ZzuvPPa7fDxiKNhzC yv4shTDy5mWH/ELPFVOlqsqkxEICEjeHkAc2uMqina65vWiDyaB6jTBD6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFACN2ilStJV2d/2dsb2JhbABZgkNDUlgExXeFboEZFgEBAQEBfYQTeRIBRygRFBMEDgWIGAMRDdIUDYVQAQEBAQEBAQMBAQEBAQEBARYEjUqBRhEBTASEMAWMKoFVgz6DboFDgQyKHzqFTiKDbG6BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,561,1413244800"; d="scan'208,217";a="376553915" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 12 Dec 2014 05:01:51 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sBC51p8S020514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Dec 2014 05:01:51 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 23:01:51 -0600 From: "Tarek Saad (tsaad)" To: "mpls@ietf.org" Thread-Topic: IETF MPLS-TE YANG Design Discussions (12/10, Meeting # 2) Thread-Index: AQHQFci9bg5/9ZmGq0+zzaRUvlCFeA== Date: Fri, 12 Dec 2014 05:01:50 +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.5.141003 x-originating-ip: [10.86.254.71] Content-Type: multipart/alternative; boundary="_000_D0AFD9BF15DA23tsaadciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3mJ31gBDUDJ4PGdyTFW6p_6TqW0 Cc: "mpls-chairs@tools.ietf.org" , "teas-chairs@ietf.org" Subject: [mpls] IETF MPLS-TE YANG Design Discussions (12/10, Meeting # 2) 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, 12 Dec 2014 05:01:59 -0000 --_000_D0AFD9BF15DA23tsaadciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Attendees: Santosh Esale >; Rakesh Gandh= i (rgandhi) >; Robert Sawaya (r= sawaya) >; Matt Hartley (mhartl= ey) >; lizhenbin@huawei.com >; zengxinzong@huawei.com >; xufeng.liu@ericsson.com >; dhruv.dhody@huawei.com >; Vero Zheng >; Sam Aldrin >; Vishnu Pavan Beeram >; jescia.chenxia@huawei.com >; Zafar = Ali (zali) >; Lou Berger >; George Swallow (swallow) >; Shah, Himanshu >; VICTOR LOPEZ ALVAREZ > MPLS-TE YANG meeting #2 Wednesday 12/10 @ 7:00pm EST Project wiki: https://github.com/ietf-mpls-yang/te/wiki/MPLS-TE-YANG The group met on Wednesday 12/10. Below are minutes/notes. Next meeting is = scheduled for Thursday 12/18. Meeting Summary . team progressed with TE link data model a. In addition to the reference models (non-final), the following models = were created and checked-in: - ietf-mpls-te.yang - ietf-mpls-te-types.yang - ietf-mpls-te-rsvp.yang . Work-in-progress for TE link model was discussed - Base MPLS-TE link data reperesentation to be added in ietf-mpls-te.ya= ng - RSVP-TE specific link data extensions to be added in ietf-mpls-te-rsv= p.yang - Common grouping to go in iet-mpls-te-types.yang. Other models can imp= ort and reuse. . Team to review the checked-in of the models above and make modifications = as needed. - to discuss changes/additions in next meeting . Discussed possibility of having the top of the MPLS-TE tree off a routing= instance . Tools - to use github syntax highlighted diff feature https://github.com/blog/193= 2-syntax-highlighted-diffs - to use github to add comments inline into the new diffs - to use github to report issues and notify . Next steps/AIs: - Team: to review/add/update link data node in the model Pavan will share comments. . To use if-feature for vendor specific supported features - xufeng.liu@ericsson.com to report if-feature can still be used with choic= e/case . RSVP Yang model - The point of defining RSVP groupings and an RSVP (non-TE) YANG model was = discussed a. Need to be able to enable RSVP on interface for non-TE (e.g. IPv4 flows) b. May require defining module in ietf-rsvp.yang. Module ietf-mpls-te-rsvp.= yang can import AIs: to send email to alias /WG-chair=92s to get their thoughts on defining= RSVP-specific YANG module (e.g. etf-rsvp.yang module) that ietf-mpls-te-rs= vp.yang can import. Regards, Tarek --_000_D0AFD9BF15DA23tsaadciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Attendees:

MPLS-TE Y= ANG meeting #2 Wednesday 12/10 @ 7:00pm EST
Project wiki: https://github.com/ietf-mpls-yang/te/wiki/MPLS-TE-YANG<= /div>

The group met on Wednesday 12/10. Below are minutes/notes. Next meetin= g is scheduled for Thursday 12/18.

Meeting Summary
. team progressed with TE link data model
  a. In addition to the reference models (non-final), the followi= ng models were created and checked-in:
     - ietf-mpls-te.yang
     - ietf-mpls-te-types.yang
     - ietf-mpls-te-rsvp.yang

. Work-in-progress for TE link model was discussed
    - Base MPLS-TE link data reperesentation to be added in = ietf-mpls-te.yang
    - RSVP-TE specific link data extensions to be added in i= etf-mpls-te-rsvp.yang
    - Common grouping to go in iet-mpls-te-types.yang. Other= models can import and reuse.

. Team to review the checked-in of the models above and make modificat= ions as needed.
- to d= iscuss changes/additions in next meeting

. Discussed possibility of having the top of the MPLS-TE tree off a ro= uting instance

. Tools
- to u= se github syntax highlighted diff feature https://github.com/blog/1932-synt= ax-highlighted-diffs
- to u= se github to add comments inline into the new diffs
- to u= se github to report issues and notify

. Next steps/AIs:
    - Team: to review/add/update link data node in the model=
    Pavan will share comments.

. To use if-feature for vendor specific supported features
- xufe= ng.liu@ericsson.com to report if-feature can still be used with choice/case=

. RSVP Yang model
- The = point of defining RSVP groupings and an RSVP (non-TE) YANG model was discus= sed
a. Nee= d to be able to enable RSVP on interface for non-TE (e.g. IPv4 flows)
b. May= require defining module in ietf-rsvp.yang. Module ietf-mpls-te-rsvp.yang c= an import
AIs: to send email to alias /WG-chair=92s to get their thoughts on def= ining RSVP-specific YANG module (e.g. etf-rsvp.yang module) that ietf-mpls-= te-rsvp.yang can import.

Regards,
Tarek
 --_000_D0AFD9BF15DA23tsaadciscocom_-- From nobody Thu Dec 11 21:52: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 7F35F1AC3D3 for ; Thu, 11 Dec 2014 21:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck7zVnrz1ff3 for ; Thu, 11 Dec 2014 21:52:14 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F98D1AC3D0 for ; Thu, 11 Dec 2014 21:52:14 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.161.96]) (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 4D4871801590; Fri, 12 Dec 2014 06:52:10 +0100 (CET) Message-ID: <548A8287.4050101@pi.nu> Date: Fri, 12 Dec 2014 13:52:07 +0800 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" , Adrian Farrel References: <5486FA2F.6020109@pi.nu> In-Reply-To: <5486FA2F.6020109@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/RAhjvkoATbJdUjOtz3tw7OAEkUc Subject: [mpls] Closed - short working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 12 Dec 2014 05:52:16 -0000 Working Group, This working group last call is closed. The reason is that we got comments from two of the authors to the effect the even though the draft is past IETF LC (with comments resolved), it is not ready even for a first wglc. I asked the responsible AD to send the draft back to the working group. The outline plan is as follows: 1. Ask the authors to post a new version of the document (this mail) 3. Ask all of the authors to verify to the shepherd and mailing list that this version is ready for wglc. 4. Run a new wglc 5. Re-write the Shepherd Write-up and request publication again 6. Normal process from there ... Merry Xmas! /Loa On 2014-12-09 21:33, Loa Andersson wrote: > Working Group, > > This is to start a one week working group last call on draft-ietf-mpls- > lsp-ping-relay-reply. We requested publication if version -03 and the > document is now in version -06. > > Please find a diff at: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-lsp-ping-relay-reply-03&difftype=--html&submit=Go%21&url2=draft-ietf-mpls-lsp-ping-relay-reply-06 > > > Please send your comments to the MPLS wg mailing list (mpls@ietf.org), > yes/support or no/do not support, in the case of non-support it is > important that you give technical reasons for this. > > Please send your comments on December 17 the latest. > > /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 Dec 12 07:55: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 23EFE1ACE1A; Fri, 12 Dec 2014 07:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g79iGSqdLP4; Fri, 12 Dec 2014 07:55:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E18881ACE5A; Fri, 12 Dec 2014 07:54:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212155454.7986.92605.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 07:54:54 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rLByg0K41xaD0c1NhepfldGc6YY Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-deprecate-bgp-entropy-label-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: Fri, 12 Dec 2014 15:55:16 -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 : Deprecation of BGP Entropy Label Capability Attribute Authors : John G. Scudder Kireeti Kompella Filename : draft-ietf-mpls-deprecate-bgp-entropy-label-02.txt Pages : 4 Date : 2014-12-12 Abstract: RFC 6790 defines the BGP Entropy Label Capability attribute. Regrettably, it has a bug: although RFC 6790 mandates that Entropy Label-incapable routers must remove the attribute, in practice this requirement can't be guaranteed to be fulfilled. This specification deprecates the attribute. A forthcoming document will propose a replacement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-deprecate-bgp-entropy-label-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-deprecate-bgp-entropy-label-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 Fri Dec 12 08:10: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 E60DC1ACE7D for ; Fri, 12 Dec 2014 08:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipgHyDpbNJ-0 for ; Fri, 12 Dec 2014 08:10:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B831ACE77 for ; Fri, 12 Dec 2014 08:10:13 -0800 (PST) Received: from DM2PR05MB686.namprd05.prod.outlook.com (10.141.176.147) by DM2PR05MB301.namprd05.prod.outlook.com (10.141.103.19) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 12 Dec 2014 16:10:11 +0000 Received: from DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) by DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) with mapi id 15.01.0031.000; Fri, 12 Dec 2014 16:10:11 +0000 From: Kishore Tiruveedhula To: Gregory Mirsky , Chris Bowers , Loa Andersson , Mach Chen , "stbryant@cisco.com" Thread-Topic: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Thread-Index: AQHQFiYaP/jNyqZo7UObKcbfL3Dncg== Date: Fri, 12 Dec 2014 16:10:10 +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.6.141106 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB301; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB301; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(51444003)(13464003)(189002)(377454003)(199003)(377424004)(46102003)(77156002)(102836002)(107046002)(120916001)(16236675004)(2501002)(101416001)(21056001)(106356001)(31966008)(68736005)(122556002)(77096005)(15975445007)(62966003)(19580405001)(19580395003)(99396003)(230783001)(19617315012)(99286002)(105586002)(97736003)(106116001)(92566001)(64706001)(19625215002)(19300405004)(66066001)(20776003)(4396001)(87936001)(54356999)(83506001)(86362001)(2656002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB301; H:DM2PR05MB686.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D0B077C91901Ckishoretjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BcHKK-Ex7SQ8kQSD0WrLcIDBabo Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-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, 12 Dec 2014 16:10:22 -0000 --_000_D0B077C91901Ckishoretjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Greg, Regarding the first comment, I think this may create confusion as the R= FC 5561 tells that any data added after =93Reserved=94 considered as the = =93Capability Data=94. So, I think the padding 3 bytes is not needed. Eve= n if you see the other LDP capabilities, for example P2MP, MP2MP and MBB de= fined in the RFC 6388 (https://wiki.tools.ietf.org/html/rfc6388#page-6 ) fo= llows the same thing without padding. Please let me know if you are okay w= ithout adding padding in the MRT capability also. Section 3 RFC 5561: https://wiki.tools.ietf.org/html/rfc5561#page-4 : The format of a "Capability Parameter" TLV is as follows: 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| TLV Code Point | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ Capability Data | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Kishore From: Gregory Mirsky > Date: Thursday, December 11, 2014 at 7:38 PM To: Chris Bowers >, Loa And= ersson >, Mach Chen >, "stbryant@cisco.com" <= stbryant@cisco.com> Cc: "mpls@ietf.org" >, "mpls-chairs@tools.ietf.org" >, "draft-atlas-mp= ls-ldp-mrt@tools.ietf.org" = > Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Hi Chris, I apologies for belated response to your thorough consideration o= f my comments. Please find my notes in-lined and tagged GIM>>. I=92m fine with the explanations and recommend the draft to be considered f= or WG adoption. Regards, Greg From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Friday, December 12, 2014 5:19 AM To: Gregory Mirsky Subject: FW: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Greg, Are you good with these responses? Chris From: Chris Bowers Sent: Monday, December 08, 2014 9:47 AM To: 'Gregory Mirsky'; Loa Andersson; Mach Chen; stbryant@cisco.com Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: RE: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Greg, Thanks for the review. Please see responses inline. From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, November 18, 2014 3:31 PM To: Loa Andersson; Mach Chen; stbryant@cisco.com Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Dear Authors, MPLS WG chairs, et. al, I've been asked to review the draft-atlas-mpls-ldp-mrt-02.txt. The document is very well written, technically sound and clearly addresses = integral part of MRT-FRR solution. It is ready for the WG adoption in my opinion. Below are my comments to authors that are should not be viewed as gating th= e adoption: =B7 section 4.1, I'd consider padding the MRT Capability TLV with e= xtra 3 octets and changing the Length field accordingly to 4; [CB] I=92m not sure that I understand your suggestion here. The MRT Capab= ility TLV we are defining is an LDP Capability Parameter TLV (as defined in= section 3 of RFC 5561). It carries no Capability Data. So its length is = 1 to account for the S-bit and 7 reserved bits. Are you suggesting that we= add 3 bytes of empty Capability Data and set the length to 4? Or did you = have something else in mind? GIM>> Yes, the 3 bytes of additional padding to make Length 4. =B7 section 4.3, a bit strange that IANA request to allocate MT-IDs= for MRT-Red and MRT-Blue is in ietf-rtgwg-mrt-frr-architecture and not in = this document as for Rainbow-MRT=92s MT-ID (section 4.2). Perhaps by groupi= ng all in one request would make it logistically easier and minimize inter-= dependency of the MRT-FRR documents. [CB] The reasoning behind the current placement of the IANA requests is th= e following. (Note that we=92ll be changing =93LDP Multi-Topology (MT) ID N= ame Space=94 to =93MPLS Multi-Topology Identifiers=94 in the IANA section = of ietf-rtgwg-mrt-frr-architecture to match the change in naming of the IAN= A registry that occurred as drafts leading to RFC7307 were revised.) The MPLS Multi-Topology Identifiers registry requests in ietf-rtgwg-mrt-frr= -architecture are for MPLS MT-IDs for MRT-Red and Blue for the Default Pro= file. The Default Profile specifies for example using the lowpoint algorit= hm to compute the GADAG. This Default Profile has MRT profile value=3D0. = It is possible that a future document could specify another MRT profile wi= th a different algorithm for computing the GADAG which we could call MRT Pr= ofile1 with MRT profile value =3D1. This new document would also need to i= nclude an IANA request to allocate values for MPLS MT-IDs for MRT-Red and B= lue for MRT Profile 1. The MPLS Multi-Topology Identifiers registry request in draft-atlas-mpls-ld= p-mrt is for the Rainbow MRT MPLS MT-ID. This MPLS MT-ID provides a way t= o identify the Rainbow MRT FEC, which provides an optimization specific to = LDP forwarding on MRTs at ABRs. The Rainbow FEC forwarding behavior is ind= ependent of the MRT Profile, so if different MRT Profiles are defined in th= e future, a new Rainbow MRT MPLS MT-ID will not need to be defined. So th= e idea is that the IANA requests in ietf-rtgwg-mrt-frr-architecture are spe= cific to the Default MRT Profile. In the supporting documents like draft-a= tlas-mpls-ldp-mrt as well as draft-li-isis-mrt and draft-atlas-ospf-mrt the= IANA requests are for values that are independent of a specific MRT profil= e. GIM>> Thank you for the utmost detailed explanation, I think I understand i= t better now. Had or would these relationships between objects of IANA regi= stries, that you=92ve described, be captured in any of MRT documents? I thi= nk that it is clearly should not delay this document adoption by the WG but= thorough explanation in IANA Considerations section, even if it repeats co= ntent of identical sections in other documents related to MRT, would be hel= pful. Thank you for your kind consideration. Regards, Greg -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Tuesday, October 28, 2014 4:26 AM To: Mach Chen; stbryant@cisco.com; Gregory Mirsk= y Cc: mpls-chairs@tools.ietf.org; VIGOUREU= X, MARTIN (MARTIN); draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt Mach, Stewart and Greg, You have be selected as MPLS-RT reviewers for draft-atlas-mpls-ldp-mrt. Note to authors: You have been CC'd on this email so that you can know that= this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (i= e, is it likely to be actually useful in operational networks), and is the = document technically sound? We are interested in knowing whether the docum= ent is ready to be considered for WG adoption (ie, it doesn't have to be pe= rfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secreta= ry, and CC'd to the MPLS WG email list. If necessary, comments may be sent = privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document= , and what can wait until the document is a working group document and the = working group has the revision control. Are you able to review this draft by Nov 18, 2014? Please respond in a time= ly fashion. Thanks, Loa (as MPLS WG chair) -------- Original Message -------- Subject: [mpls] I-D Action: draft-atlas-mpls-ldp-mrt-02.txt Date: Mon, 27 Oct 2014 09:09:38 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gr= oup of the IETF. Title : LDP Extensions to Support Maximally Redundant Trees Authors : Alia Atlas Kishore Tiruveedhula Chris Bowers Jeff Tantsura IJsbrand Wijnands Filename : draft-atlas-mpls-ldp-mrt-02.txt Pages : 16 Date : 2014-10-27 Abstract: This document specifies extensions to LDP to support the creation of label-switched paths for Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR. The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for LSRs and LERs advertising the MRT Capability. MRT-FRR uses LDP multi-topology extensions and requires three different multi-topology IDs to be allocated from the LDP MT-ID space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-atlas-mpls-ldp-mrt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-atlas-mpls-ldp-mrt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-atlas-mpls-ldp-mrt-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_D0B077C91901Ckishoretjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8A367DBAEDED7046B3D3573289C1FF68@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Greg,
    Regarding the first comment, I think this may create con= fusion as the RFC 5561 tells that any data added after =93Reserved=94 consi= dered as the =93Capability Data=94.   So, I think the padding 3 bytes = is not needed. Even if you see the other LDP capabilities, for example P2MP, MP2MP and MBB defined in the RFC 6388 (https://wiki.tools.ietf.org/html= /rfc6388#page-6 ) follows the same thing without padding.  Pl= ease let me know if you are okay without adding padding in the MRT capability also.

Section 3 RFC 5561: 
   The format of a "Capability Parameter" =
TLV is as follows:

      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
      +-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+
      |U|F| TLV Code Point            |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+
      |S| Reserved    |                                               |
      +-+-+-+-+-+-+-+-+       Capabilit=
y Data                         |
      |                                               +-+-+-=
3;-+-+-+-+-+
      |                                               |
      +-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+

Thanks,
Kishore

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Thursday, December 11, 2014 a= t 7:38 PM
To: Chris Bowers <cbowers@juniper.net>, Loa Andersson <loa@pi.nu>, Mach Chen <mach.chen@huawei.com>, "stbryant@cisco.com" <stbryant@cisco.com>
Cc: "mpls@ietf.org" <mpls@i= etf.org>, "mpls-c= hairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-atl= as-mpls-ldp-mrt@tools.ietf.org" <draft-atlas-mpls-ldp-mrt@tools.ietf.org>= ;
Subject: Re: [mpls] MPLS-RT review = of draft-atlas-mpls-ldp-mrt-02.txt

Hi Chris, I apologies for belated r= esponse to your thorough consideration of my comments. Please find my notes= in-lined and tagged GIM>>.

 

I=92m fine with the explanations an= d recommend the draft to be considered for WG adoption.

 

      = ;          Regards,=

      = ;            &n= bsp;            = ; Greg

 

From: Chris Bowers [mailto:cbowers@juniper.net]
Sent: Friday, December 12, 2014 5:19 AM
To: Gregory Mirsky
Subject: FW: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt<= /o:p>

 

Greg,

 

Are you good with these responses?&= nbsp;

 

Chris

 

From: Chris Bowers
Sent: Monday, December 08, 2014 9:47 AM
To: 'Gregory Mirsky'; Loa Andersson; Mach Chen; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org
Subject: RE: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt<= /o:p>

 

Greg, 

 

Thanks for the review.  Please= see responses inline.

 

From: mpls [m= ailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 18, 2014 3:31 PM
To: Loa Andersson; Mach Chen; = stbryant@cisco.com
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.tx= t

 

Dear Authors, MPLS WG chairs, et. al,

I've been asked to review the draft-atlas-mpls-ldp-mrt-02.tx= t.

 

The document is very well written, technically sound and cle= arly addresses integral part of MRT-FRR solution.

It is ready for the WG adoption in my opinion.

 

Below are my comments to authors that are should not be view= ed as gating the adoption:

=B7=          section = 4.1, I'd consider padding the MRT Capability TLV with extra 3 octets and ch= anging the Length field accordingly to 4;

[CB]  I=92m not sure that I understand your = suggestion here.  The MRT Capability TLV we are defining is an LDP Capability Parameter TLV (as defined in section 3 of RF= C 5561).  It carries no Capability Data.  So its length is 1 to a= ccount for the S-bit and 7 reserved bits.  Are you suggesting that we = add 3 bytes of empty Capability Data and set the length to 4?  Or did you have something else in mind?

GIM>> Yes, the 3 bytes of additional paddin= g to make Length 4.

=B7=          section = 4.3, a bit strange that IANA request to allocate MT-IDs for MRT-Red and MRT= -Blue is in ietf-rtgwg-mrt-frr-architecture and not in this document as for= Rainbow-MRT=92s MT-ID (section 4.2). Perhaps by grouping all in one request would make it logistically easier a= nd minimize inter-dependency of the MRT-FRR documents.

[CB]  The reasoning behind the current place= ment of the IANA requests is the following. (Note that we=92ll be changing =93LDP Multi-Topology (MT) ID Name Space=94= to  =93MPLS Multi-Topology Identifiers=94 in the IANA section of ietf= -rtgwg-mrt-frr-architecture to match the change in naming of the IANA regis= try that occurred as drafts leading to RFC7307 were revised.)

The MPLS Multi-Topology Identifiers registry requ= ests in ietf-rtgwg-mrt-frr-architecture are for MPLS MT-IDs  for MRT-Red and Blue for the Default Profile.&nb= sp; The Default Profile specifies for example using the lowpoint algorithm = to compute the GADAG.  This Default Profile has MRT profile value=3D0.=    It is possible that a future document could specify another MRT profile with a different algorithm for computing the GADAG whi= ch we could call MRT Profile1 with MRT profile value =3D1.  This new d= ocument would also need to include an IANA request to allocate values for M= PLS MT-IDs for MRT-Red and Blue for MRT Profile 1.

The MPLS Multi-Topology Identifiers= registry request in draft-atlas-mpls-ldp-mrt is for the Rainbow MRT MPLS M= T-ID.  This MPLS  MT-ID provides a way to identify the Rainbow MRT FEC, which provides an optimization specific t= o LDP forwarding on MRTs at ABRs.  The Rainbow FEC forwarding behavior= is independent of the MRT Profile, so if different MRT Profiles are define= d in the future, a new Rainbow MRT MPLS MT-ID will not need to be defined.   So the idea is that the IAN= A requests in ietf-rtgwg-mrt-frr-architecture are specific to the Default M= RT Profile.  In the supporting documents like draft-atlas-mpls-ldp-mrt= as well as draft-li-isis-mrt and draft-atlas-ospf-mrt the IANA requests are for values that are independent of a specific MRT pr= ofile. 

 

GIM>> Thank you for the utmos= t detailed explanation, I think I understand it better now. Had or would th= ese relationships between objects of IANA registries, that you=92ve described, be captured in any of MRT documents? = I think that it is clearly should not delay this document adoption by the W= G but thorough explanation in IANA Considerations section, even if it repea= ts content of identical sections in other documents related to MRT, would be helpful.

 

 

Thank you for your kind consideration.

 

        Regards,

          =       Greg

 

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu]
Sent: Tuesday, October 28, 2014 4:26 AM
To: Mach Chen; stbryant@cisco.com; = Gregory Mirsky
Cc: mpls-chairs@tools.ietf.org= ; VIGOUREUX, MARTIN (MARTIN); draft-atlas-mpls-= ldp-mrt@tools.ietf.org
Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt

 

Mach, Stewart and Greg,

 

You have be selected as MPLS-RT reviewers for  draft-at= las-mpls-ldp-mrt.

 

Note to authors: You have been CC'd on this email so that yo= u can know that this review is going on. However, please do not review your= own document.

 

Reviews should comment on whether the document is coherent, = is it useful (ie, is it likely to be actually useful in operational network= s), and is the document technically sound?  We are interested in knowing whether the document is ready to= be considered for WG adoption (ie, it doesn't have to be perfect at this p= oint, but should be a good start).

 

Reviews should be sent to the document authors, WG co-chairs= and WG secretary, and CC'd to the MPLS WG email list. If necessary, commen= ts may be sent privately to only the WG chairs.

 

If you have technical comments you should try to be explicit= about what

*really* need to be resolved before adopting it as a working= group document, and what can wait until the document is a working group do= cument and the working group has the revision control.

 

Are you able to review this draft by Nov 18, 2014? Please re= spond in a timely fashion.

 

 

Thanks, Loa

(as MPLS WG chair)

 

 

-------- Original Message --------

Subject: [mpls] I-D Action: draft-atlas-mpls-ldp-mrt-02.txt<= o:p>

Date: Mon, 27 Oct 2014 09:09:38 -0700

 

 

A New Internet-Draft is available from the on-line Internet-= Drafts directories.

  This draft is a work item of the Multiprotocol Label = Switching Working Group of the IETF.

 

         Title =           : LDP Extensions to = Support Maximally Redundant

Trees

         Authors&nbs= p;        : Alia Atlas=

          =             &nb= sp;    Kishore Tiruveedhula

          =             &nb= sp;    Chris Bowers

          =             &nb= sp;    Jeff Tantsura

          =             &nb= sp;    IJsbrand Wijnands

        Filename &nb= sp;      : draft-atlas-mpls-ldp-mrt-02.txt

        Pages  =          : 16

        Date  &= nbsp;         : 2014-10-27

 

Abstract:

    This document specifies extensions to LDP= to support the creation of

    label-switched paths for Maximally Redund= ant Trees (MRT).  A prime

    use of MRTs is for unicast and multicast = IP/LDP Fast-Reroute, which

    we will refer to as MRT-FRR.

 

    The sole protocol extension to LDP is sim= ply the ability to advertise

    an MRT Capability.  This document de= scribes that extension and the

    associated behavior expected for LSRs and= LERs advertising the MRT

    Capability.

 

    MRT-FRR uses LDP multi-topology extension= s and requires three

    different multi-topology IDs to be alloca= ted from the LDP MT-ID

    space.

 

 

The IETF datatracker status page for this draft is:

 

There's also a htmlized version available at:

 

A diff from the previous version is available at:=

 

 

Please note that it may take a couple of minutes from the ti= me of submission until the htmlized version and diff are available at tools= .ietf.org.

 

Internet-Drafts are also available by anonymous FTP at:=

 

_______________________________________________

mpls mailing list

 

 

 

 --_000_D0B077C91901Ckishoretjunipernet_-- From nobody Fri Dec 12 10:22: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 07E931A8718; Fri, 12 Dec 2014 10:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7TPtBsc2vqZ; Fri, 12 Dec 2014 10:08:37 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id BE7E51A86EF; Fri, 12 Dec 2014 10:08:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bRYB+P7apbIjLeNGSapG9WNPv0svW3wWJT+UTYMtWprcQIEq5LYBU9m6LcXPiWAg; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.144] (helo=JoanTower) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XzUdQ-0001Vs-OX; Fri, 12 Dec 2014 13:08:12 -0500 From: "Joan Cucchiara" To: "'Mach Chen'" References: <033e01d013c4$0d4d9390$27e8bab0$@mindspring.com> In-Reply-To: Date: Fri, 12 Dec 2014 13:08:01 -0500 Message-ID: <066401d01636$977ef7b0$c67ce710$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJBibtMqsEH8UaSXi7ZnH2b8M8cnQHdtXpJAcCEz0ObjGcEEA== Content-Language: en-us X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654be25a7663df989370f9ffd8634580729667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.144 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xYWdmFY8HVGnxO_mhGLrIQiHHhs X-Mailman-Approved-At: Fri, 12 Dec 2014 10:22:21 -0800 Cc: mib-doctors@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.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, 12 Dec 2014 18:08:40 -0000 Mach, I will take a look over the weekend. Should be compiled by smilint too I think, but I can look into doing that. Thanks, -Joan > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Tuesday, December 09, 2014 10:21 PM > To: Joan Cucchiara > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > mib-doctors@ietf.org; mpls@ietf.org > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > Thanks Joan, > > I have tried OiDViEW MIB Complier and it passed the check. > > Best regards, > Mach > > > -----Original Message----- > > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > > Sent: Tuesday, December 09, 2014 11:23 PM > > To: Mach Chen > > Cc: mpls-chairs@tools.ietf.org; > > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > > mib-doctors@ietf.org; mpls@ietf.org > > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > Mach, > > > > I'll take a look soon. Can you tell me what MIB compilers this has > > been compiled with? > > > > Thanks, > > -Joan > > > > > -----Original Message----- > > > From: Mach Chen [mailto:mach.chen@huawei.com] > > > Sent: Monday, December 08, 2014 10:27 PM > > > To: jcucchiara@mindspring.com > > > Cc: mpls-chairs@tools.ietf.org; > > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > > > mib-doctors@ietf.org; mpls@ietf.org > > > Subject: FW: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > Hi Joan, > > > > > > The authors uploaded a revision to address the Shepherd's comments. > > > I have reviewed this version and am OK with it. > > > > > > Would you please take a look at the latest version of this document? > > > If > > you > > > are OK with it, we can move it forward. > > > > > > Thanks, > > > Mach > > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > > > drafts@ietf.org > > > Sent: Thursday, December 04, 2014 8:49 AM > > > To: i-d-announce@ietf.org > > > Cc: mpls@ietf.org > > > Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Multiprotocol Label Switching > > > Working > > Group > > > of the IETF. > > > > > > Title : MPLS-TP Operations, Administration, and > > Management > > > (OAM) Identifiers Management Information Base (MIB) > > > Authors : Sam Aldrin > > > Venkatesan Mahalingam > > > Kannan KV Sampath > > > Thomas D. Nadeau > > > Filename : draft-ietf-mpls-tp-oam-id-mib-06.txt > > > Pages : 27 > > > Date : 2014-12-03 > > > > > > Abstract: > > > This memo defines a portion of the Management Information Base > (MIB) > > > for use with network management protocols in the Internet > community. > > > In particular, it describes Operations, Administration, and > > > Management (OAM) identifiers related managed objects for > > > Multiprotocol Label Switching (MPLS) and MPLS based Transport Profile > > > (TP). > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/ > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-06 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mib-06 > > > > > > > > > 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 > > > > > > > > > ----- > > > No virus found in this message. > > > Checked by AVG - www.avg.com > > > Version: 2014.0.4794 / Virus Database: 4235/8703 - Release Date: > > > 12/08/14 > > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4794 / Virus Database: 4235/8709 - Release Date: 12/09/14 From nobody Fri Dec 12 10:50: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 0DE7A1A9145; Fri, 12 Dec 2014 10:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw-jwwRdR5Oa; Fri, 12 Dec 2014 10:50:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6DC1AC418; Fri, 12 Dec 2014 10:50:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212185031.14913.74891.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 10:50:31 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/h_rxluxHgo9Sy8fWRyBIrz3IYt8 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Deprecation of BGP Entropy Label Capability Attribute' to Proposed Standard (draft-ietf-mpls-deprecate-bgp-entropy-label-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: Fri, 12 Dec 2014 18:50:40 -0000 The IESG has approved the following document: - 'Deprecation of BGP Entropy Label Capability Attribute' (draft-ietf-mpls-deprecate-bgp-entropy-label-02.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact person is Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label/ Technical Summary RFC 6790 defines the BGP Entropy Label Capability attribute. RFC 67890 has a bug: although RFC 6790 mandates that Entropy Label-incapable routers must remove the attribute, in practice this requirement can't be guaranteed to be fulfilled. This specification deprecates the attribute. A forthcoming document will propose a replacement. Working Group Summary This document is simple and takes an action that is generally agreed upon. The working group supports this document, no especially rough points. Document Quality This draft deprecates the BGP Entropy Label Capability Attribute. No known implementations support this attribute. Personnel Loa Andersson is the Document Shepherd. Spencer Dawkins is the Responsible AD. Since both co-authors of this draft and both Routing ADs all have the same affiliation, Spencer Dawkins is acting as responsible AD. From nobody Fri Dec 12 16:57: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 3AE9D1A8842 for ; Fri, 12 Dec 2014 16:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.911 X-Spam-Level: X-Spam-Status: No, score=-113.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlenHXDHvUl3 for ; Fri, 12 Dec 2014 16:57:53 -0800 (PST) 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 E01FF1A7113 for ; Fri, 12 Dec 2014 16:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8091; q=dns/txt; s=iport; t=1418432272; x=1419641872; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JY78ihuK1ZPGcJHQSxPBqI8idQJeCf5wA+CcXZJ9xz0=; b=KOcQnVzK9z+AXEBBj+DgPfL2yAznYfClcC68qgThRvAGAnOtiCQSHRYg ulIRYEbsbYJ6RJUcWKrJkZDZzYuJiGW5uGgCmTBQRDPRwEpYNpzDInZjM 23NAc8H2+qBQsftwTdIa8okbZLAFhD9TlMNkpXe19OSc3ZYBdA/9zz+6H I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAHqOi1StJV2Z/2dsb2JhbABZgmQigSoEy3ICgRUWAQEBAQF9hAwBAQEDAScTPwUHBAIBCBEEAQELFAkHMhQJCAEBBAENBQiIHAgB2DwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0ExBwaDEIETAQSMKoFViXqCXoIxh2WDOCKDbG6BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,567,1413244800"; d="scan'208";a="105352054" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 13 Dec 2014 00:57:52 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBD0vqmh032561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Dec 2014 00:57:52 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 18:57:51 -0600 From: "Nobo Akiya (nobo)" To: "Osborne, Eric" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAP2no76f67h7pbRmWY0LHccfco7wGir7EQ Date: Sat, 13 Dec 2014 00:57:51 +0000 Message-ID: References: <63CB93BC589C1B4BAFDB41A0A19B7ACD01049215@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACD01049215@USIDCWVEMBX08.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.105.196] 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/oPuHts0VNUnddzHxwHWecu3GY-c Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 13 Dec 2014 00:57:55 -0000 Hi Eric, Again, thanks for reviewing this document and providing comments. Please see in-line for [NOBO]. > -----Original Message----- > From: Osborne, Eric [mailto:eric.osborne@level3.com] > Sent: Thursday, December 04, 2014 10:56 AM > To: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; mpls- > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > Cc: mpls@ietf.org > Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath >=20 > I forgot to cc the list so I'm resending my comments on this draft. >=20 > Here is my review: >=20 > - is the document coherent? > Not really...it needs some serious copyediting. See the wall of text > below. None of my copyedit comments should be considered blockers for > WG adoption. [NOBO] English is so much more difficult than technical problems, thanks fo= r the wall of texts :) >=20 > - is it useful? > Very much so. This mechanism will make troubleshooting easier > and proactive monitoring much better. [NOBO] I am very happy to hear that you found it this extension to be benef= icial. >=20 > - is it ready for WG adoption? > Yes. It needs some cleanup but the technology seems sound. It's > certainly mature enough to be adopted by the WG. [NOBO] Thanks! >=20 >=20 > Document comments: >=20 > This isn't a line-by-line critique and I'm not a terribly good Real Edito= r(tm) > anyways so I've tried to keep these comments general and constructive. >=20 > General: the document needs an infusion of pronouns and definite articles= . > Things like "Result raises a limitation" (sec. 1.2) should be "The result > raises.." or 'This result raises...'. I've called out some of the places= where > this needs to happen, but not all of them. [NOBO] I appreciate it. I have addressed the one you pointed out, and will = ask co-authors if they can do a English review. >=20 > Section 1.1: s/terminologies/terms/ [NOBO] Fixed. >=20 > Section 1.2: the first paragraph needs a rewrite, it's messy. Also, the = bullet > points that end in '...is [succeeding|failing]' should be '...have > [succeeded|failed]'. And 'With above scenario' needs to be 'With the abo= ve > scenario' or something. [NOBO] ACK. >=20 > Sections 3-5: These sections could use a reorg. Starting with procedures= for > using new TLVs before defining the new TLVs feels awkward. I suggest > taking sections [3,4,5] and reordering as [5,3,4]. [NOBO] Pre-00 version originally had the document structure similar to [5, = 3, 4], but describing the procedures prior to the new TLVs was suggested fr= om a very long timer IETF participant. With that said, "feel awkward" is so= mething that I'd like to address. After the text you suggested in the next = comment, let me add following text. Note that Section 5, Section 6, Section 7 and Section 8 describe the new TLVs, and looking over those sections first may make it easier to read this section. Would that work? >=20 > Section 3: This section needs a little introduction. Something like "Thi= s > section describes the handling of the new TLVs by nodes which understand > them. There are two cases - nodes which understand the TLVs but which fo= r > some reason cannot describe LAG members separately, and nodes which > both understand the new TLVs and are able to describe LAG members > separately". [NOBO] Like the texts and thanks! Have added. >=20 > Section 3.2: " The responder LSRs that understands the LAG Interface Info > TLV and > are able to describe outgoing LAG member links separately are to use > the follow procedures" > needs some singular/plural cleanup: > " A responder LSR that understands the LAG Interface Info TLV and > is able to describe outgoing LAG member links separately uses > the follow procedures" > or something like that. [NOBO] Incorporated :) >=20 > Section 3.3: "Above procedures..." -> "The procedures above..." [NOBO] Fixed. >=20 > Section 4.2: Same kind of cleanup as 3.2: "Responder LSRs that > understands.." -> "Responder LSRs which understand..." [NOBO] Done. >=20 > Section 4.3: "described procedures in this section" -> "the procedures > described in this section" [NOBO] Done. >=20 > Section 4.3: "following checks" -> "the following checks". Also, the err= or > case is a little confusing. The first half of the error case is actually= a success, > and I spent some time going back and forth between the first half of the > success case and the failure case to figure out whether they were differe= nt. [NOBO] You are right, I had to spend a minute myself comparing the success/= error cases. > It would benefit from some clarifying text, perhaps something like "An er= ror > case is any case where the OAM across a LAG fails, either partial or full= y. A > partial failure is where some LAG member traversals behave as they should > and some don't, and a full failure is where no LAG member traversals > behave as they should". [NOBO] I've taken your idea, but restructured as follows. With additional logics, the initiator LSR can perform following checks in a scenario where the initiator knows that there is a LAG, with two LAG members, between TTL=3Dn and TTL=3Dn+1, and has the multipath information to traverse the two LAG members. The initiator LSR sends two MPLS echo request messages to traverse the two LAG members at TTL=3D1: o Success case: * One MPLS echo request message reaches TTL=3Dn+1 on an LAG member 1. * The other MPLS echo request message reaches TTL=3Dn+1 on an LAG member 2. The two MPLS echo request messages sent by the initiator LSR reach two different LAG members at the immediate downstream LSR. o Error case: * One MPLS echo request message reaches TTL=3Dn+1 on an LAG member 1. * The other MPLS echo request message also reaches TTL=3Dn+1 on an LAG member 1. One or two MPLS echo request messages sent by the initiator LSR does not reach the immediate downstream LSR, or the two MPLS echo request messages reach a same LAG member at the immediate downstream LSR. >=20 > Sections 5-8: no comments on the TLVs themselves, I don't know OAM well > enough to find any hidden mines here. This is for the WG to pore over. [NOBO] :) >=20 > Section 9: "As result of" -> "as a result of". Also, "additional process= ing are > required" -> "additional processing is required" [NOBO] Fixed. >=20 > Section 11: "Authors" -> "The authors". [NOBO] Fixed. >=20 > Appendix A: I get that this section is intended to list out problems that > aren't solved by the mechanisms in this document. It's probably worth > adding text in Section 2 that describes the limitations of the proposed > mechanism, something like "Most[*] LAGs are built from p2p links, and thu= s > router X and router X+1 have the same number of LAG members. It is > possible to build LAGs asymmetrically by using Ethernet switches in the > middle. Appendix A lists some cases which this document does not > address; if an operator deploys LAGs in a manner similar to what's shown = in > Appendix A, the mechanisms in this document may not suit them". I know > Section 2 has a bullet at the end that hints at this, but I think it shou= ld be > more explicit. [NOBO] Good idea. I have added the suggested text at the end of Section 2. >=20 >=20 > [*] I believe this to be true. I am willing to be wrong. It has happen= ed > before. [NOBO] Not that I think you are wrong, and often you are not, I have replac= ed "Most [*]" with "Many" in the suggested text to soften the statement, ju= st to be on the safe side :) There are comments from Mach and Yimin that I need to go through and reflec= t into the document. I will publish a revision shortly after doing so. Thanks! -Nobo >=20 >=20 >=20 >=20 >=20 >=20 > eric From nobody Fri Dec 12 21:07: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 6BCA51A9245 for ; Fri, 12 Dec 2014 21:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyrqBa9heYaF for ; Fri, 12 Dec 2014 21:07:33 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D12B1A924E for ; Fri, 12 Dec 2014 21:07:32 -0800 (PST) Received: from SN2PR0501MB1070.namprd05.prod.outlook.com (25.160.59.15) by SN2PR0501MB1071.namprd05.prod.outlook.com (25.160.59.150) with Microsoft SMTP Server (TLS) id 15.1.31.17; Sat, 13 Dec 2014 05:07:30 +0000 Received: from SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) by SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) with mapi id 15.01.0031.000; Sat, 13 Dec 2014 05:07:30 +0000 From: Yimin Shen To: "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "Nobo Akiya (nobo)" , "Tarek Saad (tsaad)" Thread-Topic: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAWkq+I6dTANiYXSfWbIAmdrlJPpQ== Date: Sat, 13 Dec 2014 05:07:30 +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.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0501MB1071; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:SN2PR0501MB1071; x-forefront-prvs: 04244E0DC5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(99286002)(120916001)(66066001)(102836002)(2656002)(230783001)(87936001)(122556002)(20776003)(105586002)(77156002)(62966003)(99396003)(92566001)(4396001)(106356001)(107046002)(68736005)(40100003)(74316001)(101416001)(54356999)(64706001)(76576001)(21056001)(33656002)(50986999)(97736003)(31966008)(229853001)(86362001)(54606007)(46102003)(54206007); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0501MB1071; H:SN2PR0501MB1070.namprd05.prod.outlook.com; FPR:; SPF:None; 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/r_zTig4tjU2rKi8RLHRq79UJeek Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 13 Dec 2014 05:07:36 -0000 Hi authors, I was asked by the MPLS WG chairs to review this draft. Thanks Nobo for cla= rifying some points for me during the review. Here are my primary comments.= =20 This draft is trying to address multi-path discovery and verification for L= SPs over LAGs, which is a valid but challenging use case with a long histor= y. From this perspective, I think the draft shows a good effort. The mechanism tries to extend LSP traceroute, which is a layer-3 OAM tool, = to explore and exercise layer-2 multi-paths. It may be debatable whether th= is is a layer violation, but I'd like to leave it to the WG.=20 Nevertheless, I can see some challenges that the mechanism faces. These cha= llenges are essentially related to the lack of layer-2 visibility on layer-= 3 routers. Specifically, the draft uses an interface index to indentify eac= h LAG member link, which is a layer-2 link. However, the two routers at the= endpoints of a LAG normally do not have the info of the LAG member link in= dices of each other. This results in some limitations in multi-path verific= ation: [1] It doesn't support incoming LAG member link verification for Echo Reque= st on the downstream router of a LAG. IOW, the ingress router may set an Ec= ho Request's destination to a 127/8 prefix according to the multi-path info= of a particular LAG member link, but the downstream router has no way to v= erify that the upstream router indeed sent the Echo Request over the claime= d LAG member link. This is due to the lack of local and remote LAG member l= ink association, and the lack of upstream LAG member link identification in= the Echo Request. Without incoming LAG member link verification, this trac= eroute would not provide more useful information than traditional LSP trace= rotue over LAG as a single layer-3 interface. [2] For the above reason, it does not support verification for individual e= nd-2-end paths, which is a desired mode in troubleshooting and pinpointing = a problem path. [3] For the same reason, the draft has to require the ingress router to alw= ays verify all paths. In particular, the ingress needs to match the count o= f Echo Request sent and the count of Echo Reply received, and verify the 1-= 1 relationship between upstream member links and downstream member links. T= his may give the users some idea about the forwarding behavior on the LAG, = but not the ability to detect all failure scenarios.=20 Therefore, the current draft does not seem to be sufficient or reliable eno= ugh. I'd suggest the authors to address the above issue before WG adoption. Thanks and regards, -- Yimin Shen Juniper Networks From nobody Sat Dec 13 18:28: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 C00631A1BF1 for ; Sat, 13 Dec 2014 18:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.911 X-Spam-Level: X-Spam-Status: No, score=-113.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFFG05eQJmO8 for ; Sat, 13 Dec 2014 18:28:54 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875221A1A68 for ; Sat, 13 Dec 2014 18:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5364; q=dns/txt; s=iport; t=1418524134; x=1419733734; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PfoztWith9KLN4C/NSHe62ngX0vt6XcZX+/17spPYoM=; b=ZiNUBj9jDHP31AI60eoRvDwACnK4OkJguViu6jRIhN/aXrN0OWoVZr6O sBLvF7yMKXwDhdCdS3NJAENF6LAQVDGnB1mofWdu7X+9LtCme2SDwm9kh 7m12/w8SKMi7jv+WqeG5UNL+NfpeUJ59WoB60DmfMjYceDoh9KvqvzNFE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFANL0jFStJA2B/2dsb2JhbABZgmQiUlgExUsKhXICgREWAQEBAQF9hAwBAQEDAQEBATc0CwwEAgEIEQQBAQsUCQcnCxQJCAEBBAENBQgTiAkIAQzWMAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEigqFECcxBwaDEIETBYwsgVaJeoJeihaDOCKCAByBUG6BAwIeBhx+AQEB X-IronPort-AV: E=Sophos;i="5.07,573,1413244800"; d="scan'208";a="105669177" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 14 Dec 2014 02:28:53 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBE2SrDH016677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Dec 2014 02:28:53 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; Sat, 13 Dec 2014 20:28:53 -0600 From: "Nobo Akiya (nobo)" To: Mach Chen , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAVKPwymqws9OR9iE+MmZxSZHkFdABwA+qQ Date: Sun, 14 Dec 2014 02:28:52 +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.24.6.9] 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/FRn6blQxs_WuEHxpbRQb0y33JOQ Cc: mpls , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 14 Dec 2014 02:28:57 -0000 Hi Mach, Many thanks for reviewing this document and providing great comments. I par= ticularly liked your generic LSR Capability TLV suggestion :) Please see in-line for [NOBO]. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen > Sent: Thursday, December 11, 2014 4:58 AM > To: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org > Cc: mpls; mpls-chairs@tools.ietf.org > Subject: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath >=20 > Hi Authors, >=20 > I have finished my MPLS-RT review of draft-akiya-mpls-lsp-ping-lag- > multipath, here are my comments, hope they are help. >=20 > 1. > This is a useful draft that tries to address a real network problem. The > solution part works but may need some optimization. >=20 > 2. > The draft uses the LAG Interface Info TLV to implicitly notify the respon= ders > to return the LAG member information. IMHO, the G bit is more appropriate > for the purpose, and then there is no need to carry the LAG Interface Inf= o > TLV in the echo request. [NOBO] Right, I see what you mean there. The presence of the G bit will be = similar to the I bit in the DS Flags then, a flag to request a specific beh= avior on the responder and to request inclusion of a specific TLV. It's sli= ghtly overloading (i.e., the flag will have different meaning in MPLS echo = request/reply messages) but I think this optimization is reasonable. I will= make this change in the next revision. >=20 > 3. > According to the definition of LAG Interface Info TLV, it is used to retu= rn the > LAG process capable of the responder LSR (not specific LAG interface). > Actually, it can be generalized as an LSR capability TLV that is not only > limited to LAG capability, it may be used for future extension. [NOBO] This is a good idea Mach. I will rename this TLV to "LSR Capability = TLV" and expand the flags field from 16 bits to 32 bits. Although when comb= ining your comment (2) and (3), there's a bit of a conflict. The LSR Capabi= lity TLV should be a generic TLV that initiator LSR includes in the MPLS ec= ho request when wanting to query the capability of the responder LSR, not s= omething that the responder LSR includes automatically into the MPLS echo r= eply. Thus, I have changed the document such that: a. Defines a generic LSR Capability TLV. b. Recommends the initiator LSR to include the LSR Capability TLV in the MP= LS echo request when using the LAG multipath mechanism. c. If MPLS echo request contains LSR capability TLV, then the responder TLV= includes the LSR Capability TLV in the MPLS echo reply, with appropriate b= its set. >=20 > 4. > Section 3 and Section 4 have large amount of overlap context. I think Sec= tion > 3 is actually a subset (just for discovery) of Section 4. I'd suggest to = merge > the two sections. [NOBO] I'd like to keep the discovery (Section 3) and validation (Section 4= ) to be separate sections. I am pretty sure that there'll be implementation= s that can easily implement the discovery but will take longer time to impl= ement the validation aspect ... which is why capability U/D bits also exist= s. >=20 > 5. > Section 3.2: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DDMAP fields describing LAG interface with DS Flags G set | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > I got confused when I firstly see this, suggest to use the whole DDMAP > structure or just show the sub-TLV part of DDMAP. If you really want to u= se > this style, it's better to replace "|" with "~". >=20 > There is the same issue for Figure 3. [NOBO] You are right. Let me go with "~". >=20 > 6. > Section 4.3: > o Error case: > * Traversing LAG member=3D1 at TTL=3Dn results in LAG member=3D1' = as > the incoming interface at TTL=3Dn+1. > * Traversing LAG member=3D2 at TTL=3Dn results in LAG member=3D1' = as > the incoming interface at TTL=3Dn+1. >=20 > For the first bullet, I guess you intend to say: > * Traversing LAG member=3D1 at TTL=3Dn results in LAG member=3D2' = as > the incoming interface at TTL=3Dn+1. [NOBO] Eric also suggested to clean up the success/error cases. I think the= y will be much cleaner in the next revision. Stay tuned. >=20 > BTW, why the above cases are error cases? If 1 (or 2) and 1' (or 2') are > supposed to be the two ends of a member link. If a packet traversing 1 at > TTL=3Dn, how will the packet come out of other interfaces other than 1'? [NOBO] It can happen the hashing logic is broken or hash buckets are corrup= ted and pointing to unexpected LAG member. >=20 > I guess you intend to say a packet is expected to be traversed 1 at TTL= =3Dn, but > mis-forwarded to other link, then result in the packet comes out of the n= on- > desired link at TTL=3Dn+1. Right? [NOBO] Exactly! Thanks! -Nobo >=20 >=20 > Best regards, > Mach >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Dec 14 06:48: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 85C751A6FAD for ; Sun, 14 Dec 2014 06:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLptSF6KCg6G for ; Sun, 14 Dec 2014 06:48:05 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DFF1A6FA8 for ; Sun, 14 Dec 2014 06:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5618; q=dns/txt; s=iport; t=1418568485; x=1419778085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hQ7/krfCqZJTllwPVbbnwS3/oBSK4kUfSLAUdLPGhV4=; b=VccJQ/LKwyIiU6wMsCyKo/vLySMaHaywrM5uDQa8N7BXbBR+aYhtvNBp 3FW4Sc6Tz67MwGTfQnzDlcgV/Y4XrZcHKPZFeE5pX8ckIuXaWL1maUMtl nRfw7Jpqav0LLIJf5BTSKHg8UZ+SDiWiWVgu8F5XlM1hAe143QRn/Xl10 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAP+hjVStJA2M/2dsb2JhbABQCoJkIoEqBMtHAoEPFgEBAQEBfYQMAQEBAwEOLCsNBwwEAgEIDgMEAQELFAkHMhQJCAEBBAENBQiIHAgB0GIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjxAGCwEfMQcGgxCBEwWOAol6gl6KFoM4IoNsboEMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,575,1413244800"; d="scan'208";a="105756331" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 14 Dec 2014 14:48:04 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sBEEm4gX022576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Dec 2014 14:48:04 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; Sun, 14 Dec 2014 08:48:04 -0600 From: "Nobo Akiya (nobo)" To: Yimin Shen , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "Tarek Saad (tsaad)" Thread-Topic: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAWkq+I6dTANiYXSfWbIAmdrlJPpQBFq1Aw Date: Sun, 14 Dec 2014 14:48:03 +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.24.6.9] 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/U3j_HIPdeRxDni962bHrTdKY56Q Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 14 Dec 2014 14:48:07 -0000 Hi Yimin, Thank you for taking time to review this document and providing comments. Please see in-line for [NOBO]. > -----Original Message----- > From: Yimin Shen [mailto:yshen@juniper.net] > Sent: Saturday, December 13, 2014 12:08 AM > To: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; Nobo Akiya > (nobo); Tarek Saad (tsaad) > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag- > multipath >=20 > Hi authors, >=20 > I was asked by the MPLS WG chairs to review this draft. Thanks Nobo for > clarifying some points for me during the review. Here are my primary > comments. >=20 > This draft is trying to address multi-path discovery and verification for= LSPs > over LAGs, which is a valid but challenging use case with a long history.= From > this perspective, I think the draft shows a good effort. >=20 > The mechanism tries to extend LSP traceroute, which is a layer-3 OAM tool= , > to explore and exercise layer-2 multi-paths. It may be debatable whether > this is a layer violation, but I'd like to leave it to the WG. [NOBO] I think that's a fair statement. Although I'd like to point out that= , without "some extensions" to the LSP Ping/Trace or other tools, there is = no interoperable way to identify some faults of LSP over LAG today, that's = a really bad thing. >=20 > Nevertheless, I can see some challenges that the mechanism faces. These > challenges are essentially related to the lack of layer-2 visibility on l= ayer-3 > routers. Specifically, the draft uses an interface index to indentify eac= h LAG > member link, which is a layer-2 link. However, the two routers at the > endpoints of a LAG normally do not have the info of the LAG member link > indices of each other. This results in some limitations in multi-path > verification: [NOBO] Yes that's a correct statement, and if we were to create a mechanism= such that the two L3 endpoints across a LAG (or LAGs) has visibility of ea= ch other, that's a rather a large problem requiring much wider extensions, = possibility beyond the LSP Ping/Trace tools. >=20 > [1] It doesn't support incoming LAG member link verification for Echo > Request on the downstream router of a LAG. IOW, the ingress router may > set an Echo Request's destination to a 127/8 prefix according to the mult= i- > path info of a particular LAG member link, but the downstream router has > no way to verify that the upstream router indeed sent the Echo Request > over the claimed LAG member link. This is due to the lack of local and > remote LAG member link association, and the lack of upstream LAG member > link identification in the Echo Request. Without incoming LAG member link > verification, this traceroute would not provide more useful information > than traditional LSP tracerotue over LAG as a single layer-3 interface. >=20 > [2] For the above reason, it does not support verification for individual= end- > 2-end paths, which is a desired mode in troubleshooting and pinpointing a > problem path. >=20 > [3] For the same reason, the draft has to require the ingress router to a= lways > verify all paths. In particular, the ingress needs to match the count of = Echo > Request sent and the count of Echo Reply received, and verify the 1-1 > relationship between upstream member links and downstream member > links. This may give the users some idea about the forwarding behavior on > the LAG, but not the ability to detect all failure scenarios. [NOBO] The limitation that you identified in [1] is valid, and the approach= described in [3] does indeed require more MPLS echo request/reply packets.= However, what this mechanism and the approach described in [3] will provid= e is a guarantee that the initiator LSR is able to exercise all LAG members= for a given LSP. And that provides a way to discover whether or not the tr= affic over LSP is black holing or not on this LAG. Yes there is still a cor= ner case of faulty FIB that causes some LAG members to criss-cross and land= up on unexpected LAG members on the other side, but that's the only case a= nd that's not a big problem when looking at "anti-black-hole" extension. =20 >=20 > Therefore, the current draft does not seem to be sufficient or reliable > enough. I'd suggest the authors to address the above issue before WG > adoption. [NOBO] I tend to think this mechanism strikes a good balance between the co= verage and the simplicity, and is well worth pursuing. I'd rather invest ti= me in implementing this, rather than get "traffic is black holing!!" custom= er cases, and I certainly hope that operators feel the same way. [NOBO] Through our off-list email exchanges, you provided one comment that = requires a document change. Which is, what should the responder LSR do when= received multipath information does not map to a LAG member link. To addre= ss this, I have added following texts below Figure 2. When none of the received multipath information maps to a particular LAG member link, then the responder LSR MUST still place the Interface Index Sub-TLV for that LAG member link in the DDMAP but inclusion of the Multipath Data Sub-TLV for that LAG member link is OPTIONAL. If the Multipath Data Sub-TLV is included, then the Multipath Length field of the Multipath Data Sub-TLV MUST be zero. Again thanks for your time and effort to review this document! -Nobo >=20 >=20 > Thanks and regards, >=20 > -- > Yimin Shen > Juniper Networks From nobody Sun Dec 14 19:29: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 631981A038A; Sun, 14 Dec 2014 19:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIaG3nwJuTXF; Sun, 14 Dec 2014 19:29:37 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id ECBDF1A037B; Sun, 14 Dec 2014 19:29:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=md6DaRtKwTAdU1cetkePAldVUIT5iE9qHIu9IvkXFRtWtYAiE/RtsvFfu7nMya7p; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.144] (helo=JoanTower) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Y0MLf-0003fY-Of; Sun, 14 Dec 2014 22:29:27 -0500 From: "Joan Cucchiara" To: "'Mach Chen'" References: <033e01d013c4$0d4d9390$27e8bab0$@mindspring.com> <066401d01636$977ef7b0$c67ce710$@mindspring.com> In-Reply-To: <066401d01636$977ef7b0$c67ce710$@mindspring.com> Date: Sun, 14 Dec 2014 22:29:25 -0500 Message-ID: <078c01d01817$53d8b590$fb8a20b0$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJBibtMqsEH8UaSXi7ZnH2b8M8cnQHdtXpJAcCEz0MCU9Q53Jt9hNOA Content-Language: en-us X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26545ac3765dfb851ae8a32f77260352d58b86936b69e59fefa2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.144 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-U-tZ-6r062QtplaPuApgrhAyH8 Cc: mib-doctors@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] [MIB-DOCTORS] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.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, 15 Dec 2014 03:29:39 -0000 Mach, Comments below (3 of them). Thanks, -Joan smilint compiler output: -------------------- While processing your request the following errors and/or warnings have been found: mibs/MPLS-OAM-ID-STD-MIB.my:22: [4] {module-identity-registration} warning: uncontrolled MODULE-IDENTITY registration mibs/MPLS-OAM-ID-STD-MIB.my:5: [5] {import-unused} warning: identifier `zeroDotZero' imported from module `SNMPv2-SMI' is never used mibs/MPLS-OAM-ID-STD-MIB.my:10: [5] {import-unused} warning: identifier `TEXTUAL-CONVENTION' imported from module `SNMPv2-TC' is never used Additional descriptions of some error/warning messages: Warning: module-identity-registration (level 4) Message: uncontrolled MODULE-IDENTITY registration Description: The identities of IETF MIB modules should be registered below mib-2, transmission, or snmpModules so that the registration space can be controlled by IANA. 1) Would like to see the Level 5 warnings fixed because that is a minor edit. I am okay with the level 4 warning because most of the MPLS MIBs are registered under mplsStdMIB branch. Compliance Statement of the MIB ---------------------------------------------- 2) Compliance (mentioned this before) There is no read-only compliance. Has it been made clear to the WGs (MPLS and PWE3) that SNMP sets will need to be supported in order to be compliant with the MIB? Section 8. Security Section --------------------------------- 3) Please fix the incomplete sentence which is: "These are the tables and objects and their sensitivity/vulnerability: " > -----Original Message----- > From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of > Joan Cucchiara > Sent: Friday, December 12, 2014 1:08 PM > To: 'Mach Chen' > Cc: mib-doctors@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp- > oam-id-mib@tools.ietf.org; mpls@ietf.org > Subject: Re: [MIB-DOCTORS] [mpls] I-D Action: draft-ietf-mpls-tp-oam-id- > mib-06.txt > > Mach, > > I will take a look over the weekend. Should be compiled by smilint too I > think, but I can look into doing that. > > Thanks, > -Joan > > > -----Original Message----- > > From: Mach Chen [mailto:mach.chen@huawei.com] > > Sent: Tuesday, December 09, 2014 10:21 PM > > To: Joan Cucchiara > > Cc: mpls-chairs@tools.ietf.org; > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > > mib-doctors@ietf.org; mpls@ietf.org > > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > Thanks Joan, > > > > I have tried OiDViEW MIB Complier and it passed the check. > > > > Best regards, > > Mach > > > > > -----Original Message----- > > > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > > > Sent: Tuesday, December 09, 2014 11:23 PM > > > To: Mach Chen > > > Cc: mpls-chairs@tools.ietf.org; > > > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > > > mib-doctors@ietf.org; mpls@ietf.org > > > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > Mach, > > > > > > I'll take a look soon. Can you tell me what MIB compilers this has > > > been compiled with? > > > > > > Thanks, > > > -Joan > > > > > > > -----Original Message----- > > > > From: Mach Chen [mailto:mach.chen@huawei.com] > > > > Sent: Monday, December 08, 2014 10:27 PM > > > > To: jcucchiara@mindspring.com > > > > Cc: mpls-chairs@tools.ietf.org; > > > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > > > > mib-doctors@ietf.org; mpls@ietf.org > > > > Subject: FW: [mpls] I-D Action: > > > > draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > > > Hi Joan, > > > > > > > > The authors uploaded a revision to address the Shepherd's comments. > > > > I have reviewed this version and am OK with it. > > > > > > > > Would you please take a look at the latest version of this document? > > > > If > > > you > > > > are OK with it, we can move it forward. > > > > > > > > Thanks, > > > > Mach > > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > > > > drafts@ietf.org > > > > Sent: Thursday, December 04, 2014 8:49 AM > > > > To: i-d-announce@ietf.org > > > > Cc: mpls@ietf.org > > > > Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > This draft is a work item of the Multiprotocol Label Switching > > > > Working > > > Group > > > > of the IETF. > > > > > > > > Title : MPLS-TP Operations, Administration, and > > > Management > > > > (OAM) Identifiers Management Information Base (MIB) > > > > Authors : Sam Aldrin > > > > Venkatesan Mahalingam > > > > Kannan KV Sampath > > > > Thomas D. Nadeau > > > > Filename : draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > Pages : 27 > > > > Date : 2014-12-03 > > > > > > > > Abstract: > > > > This memo defines a portion of the Management Information Base > > (MIB) > > > > for use with network management protocols in the Internet > > community. > > > > In particular, it describes Operations, Administration, and > > > > Management (OAM) identifiers related managed objects for > > > > Multiprotocol Label Switching (MPLS) and MPLS based Transport > Profile > > > > (TP). > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/ > > > > > > > > There's also a htmlized version available at: > > > > http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-06 > > > > > > > > A diff from the previous version is available at: > > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mib-06 > > > > > > > > > > > > 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 > > > > > > > > > > > > ----- > > > > No virus found in this message. > > > > Checked by AVG - www.avg.com > > > > Version: 2014.0.4794 / Virus Database: 4235/8703 - Release Date: > > > > 12/08/14 > > > > > > > > > > > ----- > > No virus found in this message. > > Checked by AVG - www.avg.com > > Version: 2014.0.4794 / Virus Database: 4235/8709 - Release Date: > > 12/09/14 > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4794 / Virus Database: 4235/8722 - Release Date: 12/12/14 From nobody Sun Dec 14 19:37: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 3FEFA1A0390; Sun, 14 Dec 2014 19:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YAMTXDrSVcS; Sun, 14 Dec 2014 19:37:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F221A037B; Sun, 14 Dec 2014 19:37:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQA87768; Mon, 15 Dec 2014 03:37:13 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 15 Dec 2014 03:37:12 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Mon, 15 Dec 2014 11:37:05 +0800 From: Mach Chen To: Joan Cucchiara Thread-Topic: [mpls] [MIB-DOCTORS] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt Thread-Index: AQHQGBdinpDEsmyfOEmLt4/SP1jU05yP/37A Date: Mon, 15 Dec 2014 03:37:05 +0000 Message-ID: References: <033e01d013c4$0d4d9390$27e8bab0$@mindspring.com> <066401d01636$977ef7b0$c67ce710$@mindspring.com> <078c01d01817$53d8b590$fb8a20b0$@mindspring.com> In-Reply-To: <078c01d01817$53d8b590$fb8a20b0$@mindspring.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/P3VlCPDKXTnHH96v36Kf6zCQteY Cc: "mib-doctors@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] [MIB-DOCTORS] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.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, 15 Dec 2014 03:37:18 -0000 Hi Joan, Many thanks for taking your time to review the document and the detailed co= mments! To the Authors: Please look at Joan's comments and address them accordingly. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Joan Cucchiara > Sent: Monday, December 15, 2014 11:29 AM > To: Mach Chen > Cc: mib-doctors@ietf.org; mpls-chairs@tools.ietf.org; > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; mpls@ietf.org > Subject: Re: [mpls] [MIB-DOCTORS] I-D Action: > draft-ietf-mpls-tp-oam-id-mib-06.txt >=20 >=20 > Mach, >=20 > Comments below (3 of them). >=20 > Thanks, > -Joan >=20 >=20 > smilint compiler output: > -------------------- > While processing your request the following errors and/or warnings have b= een > found: >=20 > mibs/MPLS-OAM-ID-STD-MIB.my:22: [4] {module-identity-registration} warnin= g: > uncontrolled MODULE-IDENTITY registration > mibs/MPLS-OAM-ID-STD-MIB.my:5: [5] {import-unused} warning: identifier > `zeroDotZero' imported from module `SNMPv2-SMI' is never used > mibs/MPLS-OAM-ID-STD-MIB.my:10: [5] {import-unused} warning: identifier > `TEXTUAL-CONVENTION' imported from module `SNMPv2-TC' is never used >=20 > Additional descriptions of some error/warning messages: >=20 > Warning: module-identity-registration (level 4) > Message: uncontrolled MODULE-IDENTITY registration > Description: The identities of IETF MIB modules should be registered belo= w > mib-2, transmission, or snmpModules so that the registration > space can be controlled by IANA. >=20 > 1) Would like to see the Level 5 warnings fixed because that is a mino= r > edit. I am okay with the level 4 warning because most of the MPLS MIBs = are > registered under mplsStdMIB branch. >=20 >=20 > Compliance Statement of the MIB > ---------------------------------------------- > 2) Compliance (mentioned this before) >=20 > There is no read-only compliance. Has it been made clear to the WGs (MPLS= and > PWE3) that SNMP sets will need to be supported in order to be compliant = with > the MIB? >=20 > Section 8. Security Section > --------------------------------- > 3) Please fix the incomplete sentence which is: > "These are the tables and objects and their sensitivity/vulnerability: " >=20 >=20 >=20 > > -----Original Message----- > > From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of > > Joan Cucchiara > > Sent: Friday, December 12, 2014 1:08 PM > > To: 'Mach Chen' > > Cc: mib-doctors@ietf.org; mpls-chairs@tools.ietf.org; > > draft-ietf-mpls-tp- oam-id-mib@tools.ietf.org; mpls@ietf.org > > Subject: Re: [MIB-DOCTORS] [mpls] I-D Action: > > draft-ietf-mpls-tp-oam-id- mib-06.txt > > > > Mach, > > > > I will take a look over the weekend. Should be compiled by smilint t= oo > I > > think, but I can look into doing that. > > > > Thanks, > > -Joan > > > > > -----Original Message----- > > > From: Mach Chen [mailto:mach.chen@huawei.com] > > > Sent: Tuesday, December 09, 2014 10:21 PM > > > To: Joan Cucchiara > > > Cc: mpls-chairs@tools.ietf.org; > > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > > > mib-doctors@ietf.org; mpls@ietf.org > > > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > Thanks Joan, > > > > > > I have tried OiDViEW MIB Complier and it passed the check. > > > > > > Best regards, > > > Mach > > > > > > > -----Original Message----- > > > > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > > > > Sent: Tuesday, December 09, 2014 11:23 PM > > > > To: Mach Chen > > > > Cc: mpls-chairs@tools.ietf.org; > > > > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > > > > mib-doctors@ietf.org; mpls@ietf.org > > > > Subject: RE: [mpls] I-D Action: > > > > draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > > > Mach, > > > > > > > > I'll take a look soon. Can you tell me what MIB compilers this > > > > has been compiled with? > > > > > > > > Thanks, > > > > -Joan > > > > > > > > > -----Original Message----- > > > > > From: Mach Chen [mailto:mach.chen@huawei.com] > > > > > Sent: Monday, December 08, 2014 10:27 PM > > > > > To: jcucchiara@mindspring.com > > > > > Cc: mpls-chairs@tools.ietf.org; > > > > draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > > > > > mib-doctors@ietf.org; mpls@ietf.org > > > > > Subject: FW: [mpls] I-D Action: > > > > > draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > > > > > Hi Joan, > > > > > > > > > > The authors uploaded a revision to address the Shepherd's comment= s. > > > > > I have reviewed this version and am OK with it. > > > > > > > > > > Would you please take a look at the latest version of this docume= nt? > > > > > If > > > > you > > > > > are OK with it, we can move it forward. > > > > > > > > > > Thanks, > > > > > Mach > > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > > > > > drafts@ietf.org > > > > > Sent: Thursday, December 04, 2014 8:49 AM > > > > > To: i-d-announce@ietf.org > > > > > Cc: mpls@ietf.org > > > > > Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts > > > > directories. > > > > > This draft is a work item of the Multiprotocol Label Switching > > > > > Working > > > > Group > > > > > of the IETF. > > > > > > > > > > Title : MPLS-TP Operations, Administration, and > > > > Management > > > > > (OAM) Identifiers Management Information Base (MIB) > > > > > Authors : Sam Aldrin > > > > > Venkatesan Mahalingam > > > > > Kannan KV Sampath > > > > > Thomas D. Nadeau > > > > > Filename : draft-ietf-mpls-tp-oam-id-mib-06.txt > > > > > Pages : 27 > > > > > Date : 2014-12-03 > > > > > > > > > > Abstract: > > > > > This memo defines a portion of the Management Information > > > > > Base > > > (MIB) > > > > > for use with network management protocols in the Internet > > > community. > > > > > In particular, it describes Operations, Administration, and > > > > > Management (OAM) identifiers related managed objects for > > > > > Multiprotocol Label Switching (MPLS) and MPLS based Transport > > Profile > > > > > (TP). > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/ > > > > > > > > > > There's also a htmlized version available at: > > > > > http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-06 > > > > > > > > > > A diff from the previous version is available at: > > > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-oam-id-mib-= 0 > > > > > 6 > > > > > > > > > > > > > > > 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.o= rg. > > > > > > > > > > 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 > > > > > > > > > > > > > > > ----- > > > > > No virus found in this message. > > > > > Checked by AVG - www.avg.com > > > > > Version: 2014.0.4794 / Virus Database: 4235/8703 - Release Date: > > > > > 12/08/14 > > > > > > > > > > > > > > > > ----- > > > No virus found in this message. > > > Checked by AVG - www.avg.com > > > Version: 2014.0.4794 / Virus Database: 4235/8709 - Release Date: > > > 12/09/14 > > > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > > > > > ----- > > No virus found in this message. > > Checked by AVG - www.avg.com > > Version: 2014.0.4794 / Virus Database: 4235/8722 - Release Date: > > 12/12/14 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Dec 14 19:38: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 82D121A0390 for ; Sun, 14 Dec 2014 19:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AhETB78vihG for ; Sun, 14 Dec 2014 19:38:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A9C1A037B for ; Sun, 14 Dec 2014 19:38:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMV67790; Mon, 15 Dec 2014 03:38:27 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 15 Dec 2014 03:38:23 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Mon, 15 Dec 2014 11:38:10 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAVKPwyhbH8gQvjQzCk980lKW6BMQB2ajUAAEGynIA= Date: Mon, 15 Dec 2014 03:38:09 +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/UpYzl3RvD6oz2M6qk2T3MywXIkI Cc: mpls , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 15 Dec 2014 03:38:31 -0000 Hi Nobo, Thanks for considering my comments! And I am OK with your proposals to my c= omments. Best regards, Mach > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Sunday, December 14, 2014 10:29 AM > To: Mach Chen; draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org > Cc: mpls; mpls-chairs@tools.ietf.org > Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath >=20 > Hi Mach, >=20 > Many thanks for reviewing this document and providing great comments. I > particularly liked your generic LSR Capability TLV suggestion :) >=20 > Please see in-line for [NOBO]. >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen > > Sent: Thursday, December 11, 2014 4:58 AM > > To: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org > > Cc: mpls; mpls-chairs@tools.ietf.org > > Subject: [mpls] MPLS-RT review of > > draft-akiya-mpls-lsp-ping-lag-multipath > > > > Hi Authors, > > > > I have finished my MPLS-RT review of draft-akiya-mpls-lsp-ping-lag- > > multipath, here are my comments, hope they are help. > > > > 1. > > This is a useful draft that tries to address a real network problem. > > The solution part works but may need some optimization. > > > > 2. > > The draft uses the LAG Interface Info TLV to implicitly notify the > > responders to return the LAG member information. IMHO, the G bit is > > more appropriate for the purpose, and then there is no need to carry > > the LAG Interface Info TLV in the echo request. >=20 > [NOBO] Right, I see what you mean there. The presence of the G bit will b= e > similar to the I bit in the DS Flags then, a flag to request a specific b= ehavior on the > responder and to request inclusion of a specific TLV. It's slightly overl= oading (i.e., > the flag will have different meaning in MPLS echo request/reply messages)= but I > think this optimization is reasonable. I will make this change in the nex= t revision. >=20 > > > > 3. > > According to the definition of LAG Interface Info TLV, it is used to > > return the LAG process capable of the responder LSR (not specific LAG > interface). > > Actually, it can be generalized as an LSR capability TLV that is not > > only limited to LAG capability, it may be used for future extension. >=20 > [NOBO] This is a good idea Mach. I will rename this TLV to "LSR Capabilit= y TLV" and > expand the flags field from 16 bits to 32 bits. Although when combining y= our > comment (2) and (3), there's a bit of a conflict. The LSR Capability TLV = should be a > generic TLV that initiator LSR includes in the MPLS echo request when wan= ting to > query the capability of the responder LSR, not something that the respond= er LSR > includes automatically into the MPLS echo reply. Thus, I have changed the > document such that: >=20 > a. Defines a generic LSR Capability TLV. > b. Recommends the initiator LSR to include the LSR Capability TLV in the = MPLS > echo request when using the LAG multipath mechanism. > c. If MPLS echo request contains LSR capability TLV, then the responder T= LV > includes the LSR Capability TLV in the MPLS echo reply, with appropriate = bits set. >=20 > > > > 4. > > Section 3 and Section 4 have large amount of overlap context. I think > > Section > > 3 is actually a subset (just for discovery) of Section 4. I'd suggest > > to merge the two sections. >=20 > [NOBO] I'd like to keep the discovery (Section 3) and validation (Section= 4) to be > separate sections. I am pretty sure that there'll be implementations that= can > easily implement the discovery but will take longer time to implement the > validation aspect ... which is why capability U/D bits also exists. >=20 > > > > 5. > > Section 3.2: > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | DDMAP fields describing LAG interface with DS Flags G set | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I got confused when I firstly see this, suggest to use the whole DDMAP > > structure or just show the sub-TLV part of DDMAP. If you really want > > to use this style, it's better to replace "|" with "~". > > > > There is the same issue for Figure 3. >=20 > [NOBO] You are right. Let me go with "~". >=20 > > > > 6. > > Section 4.3: > > o Error case: > > * Traversing LAG member=3D1 at TTL=3Dn results in LAG member=3D1= ' as > > the incoming interface at TTL=3Dn+1. > > * Traversing LAG member=3D2 at TTL=3Dn results in LAG member=3D1= ' as > > the incoming interface at TTL=3Dn+1. > > > > For the first bullet, I guess you intend to say: > > * Traversing LAG member=3D1 at TTL=3Dn results in LAG member=3D2= ' as > > the incoming interface at TTL=3Dn+1. >=20 > [NOBO] Eric also suggested to clean up the success/error cases. I think t= hey will > be much cleaner in the next revision. Stay tuned. >=20 > > > > BTW, why the above cases are error cases? If 1 (or 2) and 1' (or 2') > > are supposed to be the two ends of a member link. If a packet > > traversing 1 at TTL=3Dn, how will the packet come out of other interfac= es other > than 1'? >=20 > [NOBO] It can happen the hashing logic is broken or hash buckets are corr= upted > and pointing to unexpected LAG member. >=20 > > > > I guess you intend to say a packet is expected to be traversed 1 at > > TTL=3Dn, but mis-forwarded to other link, then result in the packet > > comes out of the non- desired link at TTL=3Dn+1. Right? >=20 > [NOBO] Exactly! >=20 > Thanks! >=20 > -Nobo >=20 > > > > > > Best regards, > > Mach > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Dec 14 21:52: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 CDFD11A1A0B; Sun, 14 Dec 2014 21:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A28lqCoXwn2W; Sun, 14 Dec 2014 21:52:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD35D1A19F6; Sun, 14 Dec 2014 21:52:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215055237.30345.13942.idtracker@ietfa.amsl.com> Date: Sun, 14 Dec 2014 21:52:37 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KEwpUf4SuQ5_b36Lagra4F1PJmU Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-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: Mon, 15 Dec 2014 05:52:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) Authors : Venkatesan Mahalingam Kannan KV Sampath Sam Aldrin Thomas D. Nadeau Filename : draft-ietf-mpls-tp-te-mib-10.txt Pages : 58 Date : 2014-12-14 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects and textual conventions for Tunnels, Identifiers and Label Switching Router to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-te-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-te-mib-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-te-mib-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 Sun Dec 14 23:36: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 8A8321A1A23 for ; Sun, 14 Dec 2014 23:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UxUYmqSnmd3 for ; Sun, 14 Dec 2014 23:36:16 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25F91A1A29 for ; Sun, 14 Dec 2014 23:36:15 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id i138so7601232oig.36 for ; Sun, 14 Dec 2014 23:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8aum+nl69gWbYIVRPt8VJPR73ZKd6zeq8pVbqzWWoDw=; b=i9q0RTlT3m1YkGY5FR4HhLkFG4RJs17XhagzEFOoBcDrxsPDQKRjjcE4SZVPOpvYv9 AZYFbTrb9qox22XJWR9hqSb4nGPbp1ghSCeHRaJiDi+XHQsijvopRiG9+3seFUvyBNNu 4EFQmWHWRDoA8qdi9XoD064/364yWVooujfyu8Id3ogX5geUYBMJm6OLeFZ/CUE+Xi44 ws+JTRi7X51IX33rG2UPQN/BNsa+MSv62wYzqBAdwndTY5jwjPAVOOhoW6Y49hUEbaRZ t4IGp4rGHd0p56/MA3+acueMQBARcWp0wy5UWWgASUTtO/zm1PZ0eOv6zL577oo9aqrt 4mpQ== MIME-Version: 1.0 X-Received: by 10.202.178.11 with SMTP id b11mr5045420oif.117.1418628975099; Sun, 14 Dec 2014 23:36:15 -0800 (PST) Received: by 10.182.28.133 with HTTP; Sun, 14 Dec 2014 23:36:14 -0800 (PST) Received: by 10.182.28.133 with HTTP; Sun, 14 Dec 2014 23:36:14 -0800 (PST) In-Reply-To: <547D831C.30201@pi.nu> References: <547D81A1.30905@pi.nu> <547D831C.30201@pi.nu> Date: Mon, 15 Dec 2014 01:36:14 -0600 Message-ID: From: Luay Jalil To: Loa Andersson Content-Type: multipart/alternative; boundary=001a113cd284210354050a3c4c12 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HbymGRffuyzHSHbbJYZ-HcDIFTs Cc: "mpls@ietf.org" , "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Working group lst call for draft-ietf-mpls-oam-ipv6-rao 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, 15 Dec 2014 07:36:17 -0000 --001a113cd284210354050a3c4c12 Content-Type: text/plain; charset=UTF-8 Support Regards, Luay On Dec 2, 2014 3:15 AM, "Loa Andersson" wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-oam-ipv6-rao. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There is no IPR disclosures against this document. All the authors > 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 December 16, 2014. > > /Loa > for the MPLS wg chairs > > PS > Just set the topic right > > > -- > > > 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 > --001a113cd284210354050a3c4c12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Support

Regards,
Luay

On Dec 2, 2014 3:15 AM, "Loa Andersson"= ; <loa@pi.nu> wrote:
=C2=A0Working Group,

=C2=A0This is to initiate a two week working group last call on
=C2=A0draft-ietf-mpls-oam-ipv6-rao.

=C2=A0Please send your comments to the mpls wg mailing list (mpls@ietf.org).

=C2=A0There is no IPR disclosures against this document. All the authors =C2=A0have stated on the working group mailing list that they are not aware=
=C2=A0of any other IPRs that relates to this draft.

=C2=A0This working group last call ends December 16, 2014.

=C2=A0/Loa
=C2=A0for the MPLS wg chairs

PS
Just set the topic right


--


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

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
--001a113cd284210354050a3c4c12-- From nobody Mon Dec 15 07:35: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 D950D1A6FFD; Mon, 15 Dec 2014 07:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYrYFWAnbN9h; Mon, 15 Dec 2014 07:35:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB3E1A6FEE; Mon, 15 Dec 2014 07:35:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215153516.12830.67220.idtracker@ietfa.amsl.com> Date: Mon, 15 Dec 2014 07:35:16 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CpTsw4tY2opZEJ-T5azouOiVHL0 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-atlas-mpls-ldp-mrt-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: Mon, 15 Dec 2014 15:35: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 : LDP Extensions to Support Maximally Redundant Trees Authors : Alia Atlas Kishore Tiruveedhula Chris Bowers Jeff Tantsura IJsbrand Wijnands Filename : draft-atlas-mpls-ldp-mrt-03.txt Pages : 16 Date : 2014-12-15 Abstract: This document specifies extensions to the Label Distribution Protocol(LDP) to support the creation of label-switched paths for Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR. The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for LSRs and LERs advertising the MRT Capability. MRT-FRR uses LDP multi-topology extensions and requires three different multi-topology IDs to be allocated from the LDP MT-ID space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-atlas-mpls-ldp-mrt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-atlas-mpls-ldp-mrt-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-atlas-mpls-ldp-mrt-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 Mon Dec 15 21:50: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 D91181A038E for ; Mon, 15 Dec 2014 21:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEPzio_C6MV1 for ; Mon, 15 Dec 2014 21:50:26 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5E31A038A for ; Mon, 15 Dec 2014 21:50:26 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.93.13]) (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 9A006180155B; Tue, 16 Dec 2014 06:50:23 +0100 (CET) Message-ID: <548FC81B.5060107@pi.nu> Date: Tue, 16 Dec 2014 13:50:19 +0800 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/9IMxYB9oVD95tY6UsFWG5RlQbko Cc: "mpls-chairs@tools.ietf.org" , draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: [mpls] IPR poll on draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 05:50:29 -0000 Working group, An adoption poll has been started on draft-atlas-mpls-ldp-mrt. We will run the IPR poll in parallel. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-atlas-mpls-ldp-mrt? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 15 21:51: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 277541A038E for ; Mon, 15 Dec 2014 21:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mozj7lD7cFAw for ; Mon, 15 Dec 2014 21:51:51 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89251A0371 for ; Mon, 15 Dec 2014 21:51:50 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.93.13]) (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 4046B180155B; Tue, 16 Dec 2014 06:51:47 +0100 (CET) Message-ID: <548FC870.3090901@pi.nu> Date: Tue, 16 Dec 2014 13:51:44 +0800 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/nZ1egRwi4tEy7YoZ7Y8YplgVjbg Cc: "mpls-chairs@tools.ietf.org" , draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 05:51:52 -0000 Working Group, This is to start a two week poll on adopting draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There is no IPR disclosures directly against this document. An IPR poll will be done in parallel to the adoption poll, and the adoption poll will not be closed before we have responses from all authors. If you are on the the mpls working group mailing list and aware of IPR that relates to this draft, you should respond to the IPR poll. This poll ends January 2, 2015. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Dec 16 02:47: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 EB3B81A1A97 for ; Tue, 16 Dec 2014 02:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfawvmKftj5Q for ; Tue, 16 Dec 2014 02:47:12 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2571A1A92 for ; Tue, 16 Dec 2014 02:47:12 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 5D824264624 for ; Tue, 16 Dec 2014 11:47:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3C4504C146 for ; Tue, 16 Dec 2014 11:47:10 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.149]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 11:47:10 +0100 From: To: "mpls@ietf.org" Thread-Topic: IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AQHQEd2DQcON9wMSaEKtIbJ6DFkQMZyRuqGAgABcAGCAAADd0A== Date: Tue, 16 Dec 2014 10:47:09 +0000 Message-ID: <32128_1418726830_54900DAE_32128_261_1_9E32478DFA9976438E7A22F69B08FF920C746A54@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5483E38A.8000406@pi.nu> <548FCDCB.3090803@pi.nu> <19845_1418726658_54900D02_19845_14769_1_9E32478DFA9976438E7A22F69B08FF920C746A3B@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <19845_1418726658_54900D02_19845_14769_1_9E32478DFA9976438E7A22F69B08FF920C746A3B@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jmKJ9s_r4_7UIKWeAY1qL2Oq_ko Subject: [mpls] FW: IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath 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, 16 Dec 2014 10:47:15 -0000 Hi, I'm not aware of any IPR regarding this document. Stephane -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Tuesday, December 16, 2014 07:15 To: LITKOWSKI Stephane SCE/IBNF Cc: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; mpls-chairs@too= ls.ietf.org Subject: Re: IPR Poll on draft-akiya-mpls-lsp-ping-lag-multipath Stephane, I have not seen your response to the IPR poll. /Loa On 2014-12-07 13:20, Loa Andersson wrote: > Working group, > > The authors of draft-akiya-mpls-lsp-ping-lag-multipath has told the wg=20 > chairs the document is ready to be adopted as a working group=20 > document. > > The document is curretly in an MPLS-RT review. Before we start the wg=20 > adoption poll the MPLS-RT review will be concluded and the document=20 > updated. In parallel we will also do an IPR pll. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-akiya-mpls-lsp-ping-lag- multipath? > > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are no IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond=20 > to this email regardless of whether or not you are aware of any=20 > relevant IPR. > > *The response needs to be sent to the MPLS wg mailing list.* > > The document will not advance to the next stage until a response has=20 > been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author=20 > or contributor, then please explicitly respond only if you are aware=20 > of any IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Dec 16 05:35: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 CD3151A1B56 for ; Tue, 16 Dec 2014 05:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YNnUDZz3IYV for ; Tue, 16 Dec 2014 05:35:50 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324C51A1B0C for ; Tue, 16 Dec 2014 05:35:50 -0800 (PST) Received: from SN2PR0501MB1070.namprd05.prod.outlook.com (25.160.59.15) by SN2PR0501MB1070.namprd05.prod.outlook.com (25.160.59.15) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 16 Dec 2014 13:35:27 +0000 Received: from SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) by SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) with mapi id 15.01.0031.000; Tue, 16 Dec 2014 13:35:27 +0000 From: Yimin Shen To: "Nobo Akiya (nobo)" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "Tarek Saad (tsaad)" Thread-Topic: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAWkq+I6dTANiYXSfWbIAmdrlJPpQBFq1AwAGFau4A= Date: Tue, 16 Dec 2014 13:35:27 +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:;SRVR:SN2PR0501MB1070; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:SN2PR0501MB1070; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(164054003)(51444003)(13464003)(199003)(51704005)(105586002)(31966008)(86362001)(19580405001)(66066001)(68736005)(122556002)(102836002)(20776003)(99396003)(2900100001)(230783001)(2950100001)(54606007)(101416001)(40100003)(33656002)(107046002)(120916001)(50986999)(46102003)(54206007)(2656002)(4396001)(76576001)(77156002)(54356999)(21056001)(106356001)(19580395003)(97736003)(76176999)(74316001)(87936001)(62966003)(92566001)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0501MB1070; H:SN2PR0501MB1070.namprd05.prod.outlook.com; FPR:; SPF:None; 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/wB4Lhbiiic4z6HWNVSAs83Bh3v4 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 16 Dec 2014 13:35:53 -0000 Nobo, authors, I can support the document for WG adoption. However I believe it can signif= icantly improve if "incoming LAG member link verification" and "individual = end-to-end path verification" are supported. Therefore, I'd like to make a = couple of suggestions. 1. Add an "Applicability" section to describe the current limitations. - The general lack of layer-2 visibility in a layer-3 network, especially f= or LAG member indices. - No incoming LAG member link verification at downstream router. - No individual end-to-end path verification. - Failure scenarios that may not be detected. - Your strategy to balance coverage and simplicity that you mentioned below= .=20 2. For completeness and future compatibility, include/describe the procedur= es of "incoming LAG member link verification" and "individual end-to-end pa= th verification", assuming the LAG member index visibility issue is resolve= d. - This visibility could be achieved through some protocol, or learning from= a central controller. - For this reason, the document may need to allow "Interface Index Sub-TLV = of LAG member link" learned from Echo Reply to be reflected in the next Ech= o Request.=20 Thanks, /Yimin -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Sunday, December 14, 2014 9:48 AM To: Yimin Shen; draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; Tar= ek Saad (tsaad) Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: RE: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-m= ultipath Hi Yimin, Thank you for taking time to review this document and providing comments. Please see in-line for [NOBO]. > -----Original Message----- > From: Yimin Shen [mailto:yshen@juniper.net] > Sent: Saturday, December 13, 2014 12:08 AM > To: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; Nobo Akiya=20 > (nobo); Tarek Saad (tsaad) > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-=20 > multipath >=20 > Hi authors, >=20 > I was asked by the MPLS WG chairs to review this draft. Thanks Nobo=20 > for clarifying some points for me during the review. Here are my=20 > primary comments. >=20 > This draft is trying to address multi-path discovery and verification=20 > for LSPs over LAGs, which is a valid but challenging use case with a=20 > long history. From this perspective, I think the draft shows a good effor= t. >=20 > The mechanism tries to extend LSP traceroute, which is a layer-3 OAM=20 > tool, to explore and exercise layer-2 multi-paths. It may be debatable=20 > whether this is a layer violation, but I'd like to leave it to the WG. [NOBO] I think that's a fair statement. Although I'd like to point out that= , without "some extensions" to the LSP Ping/Trace or other tools, there is = no interoperable way to identify some faults of LSP over LAG today, that's = a really bad thing. >=20 > Nevertheless, I can see some challenges that the mechanism faces.=20 > These challenges are essentially related to the lack of layer-2=20 > visibility on layer-3 routers. Specifically, the draft uses an=20 > interface index to indentify each LAG member link, which is a layer-2=20 > link. However, the two routers at the endpoints of a LAG normally do=20 > not have the info of the LAG member link indices of each other. This=20 > results in some limitations in multi-path > verification: [NOBO] Yes that's a correct statement, and if we were to create a mechanism= such that the two L3 endpoints across a LAG (or LAGs) has visibility of ea= ch other, that's a rather a large problem requiring much wider extensions, = possibility beyond the LSP Ping/Trace tools. >=20 > [1] It doesn't support incoming LAG member link verification for Echo=20 > Request on the downstream router of a LAG. IOW, the ingress router may=20 > set an Echo Request's destination to a 127/8 prefix according to the=20 > multi- path info of a particular LAG member link, but the downstream=20 > router has no way to verify that the upstream router indeed sent the=20 > Echo Request over the claimed LAG member link. This is due to the lack=20 > of local and remote LAG member link association, and the lack of=20 > upstream LAG member link identification in the Echo Request. Without=20 > incoming LAG member link verification, this traceroute would not=20 > provide more useful information than traditional LSP tracerotue over LAG = as a single layer-3 interface. >=20 > [2] For the above reason, it does not support verification for=20 > individual end- 2-end paths, which is a desired mode in=20 > troubleshooting and pinpointing a problem path. >=20 > [3] For the same reason, the draft has to require the ingress router=20 > to always verify all paths. In particular, the ingress needs to match=20 > the count of Echo Request sent and the count of Echo Reply received,=20 > and verify the 1-1 relationship between upstream member links and=20 > downstream member links. This may give the users some idea about the=20 > forwarding behavior on the LAG, but not the ability to detect all failure= scenarios. [NOBO] The limitation that you identified in [1] is valid, and the approach= described in [3] does indeed require more MPLS echo request/reply packets.= However, what this mechanism and the approach described in [3] will provid= e is a guarantee that the initiator LSR is able to exercise all LAG members= for a given LSP. And that provides a way to discover whether or not the tr= affic over LSP is black holing or not on this LAG. Yes there is still a cor= ner case of faulty FIB that causes some LAG members to criss-cross and land= up on unexpected LAG members on the other side, but that's the only case a= nd that's not a big problem when looking at "anti-black-hole" extension. =20 >=20 > Therefore, the current draft does not seem to be sufficient or=20 > reliable enough. I'd suggest the authors to address the above issue=20 > before WG adoption. [NOBO] I tend to think this mechanism strikes a good balance between the co= verage and the simplicity, and is well worth pursuing. I'd rather invest ti= me in implementing this, rather than get "traffic is black holing!!" custom= er cases, and I certainly hope that operators feel the same way. [NOBO] Through our off-list email exchanges, you provided one comment that = requires a document change. Which is, what should the responder LSR do when= received multipath information does not map to a LAG member link. To addre= ss this, I have added following texts below Figure 2. When none of the received multipath information maps to a particular LAG member link, then the responder LSR MUST still place the Interface Index Sub-TLV for that LAG member link in the DDMAP but inclusion of the Multipath Data Sub-TLV for that LAG member link is OPTIONAL. If the Multipath Data Sub-TLV is included, then the Multipath Length field of the Multipath Data Sub-TLV MUST be zero. Again thanks for your time and effort to review this document! -Nobo >=20 >=20 > Thanks and regards, >=20 > -- > Yimin Shen > Juniper Networks From nobody Tue Dec 16 05:59: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 935A31A1AC2 for ; Tue, 16 Dec 2014 05:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4_Iog9F7W6i for ; Tue, 16 Dec 2014 05:59:08 -0800 (PST) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E381A1ABB for ; Tue, 16 Dec 2014 05:59:08 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id z6so6062357yhz.39 for ; Tue, 16 Dec 2014 05:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xgpg1YEPGeGQaywnu9PuppQAD8djoJt7qLtxpm5RstE=; b=jOt16rZyFLBCglyzXyb6B/O/PGRduIYiGu8d15RWbDUrQpQ9R8MG4oTd4sFCyCi5+c h+cezO/Tl+h66lcvaGL022FWRFxnl6j9aWwsTvW0OA5S5dNaqDS5EvAmYAFlJMfai1YX EoyiVbDMBzHd2UV5t7smZlzZwXlrFrFRa2/SsiLhgXI5Npz0FOnUwTBlP0m27L39l0HA qJ3ibo01743FP3chu8qYuCKRgXxhhW9eB83E3rJ0nmpaAuWowLLhVLvfndGY7pQwa2X2 Ol53dYb84/MSb5XAvEdh9AMgD3fYnFbYelg15BA0j9q0ZZghetYNY+D7U4/TxJiNGCR5 uYeQ== MIME-Version: 1.0 X-Received: by 10.170.86.65 with SMTP id d62mr30133118yka.52.1418738344964; Tue, 16 Dec 2014 05:59:04 -0800 (PST) Received: by 10.170.136.132 with HTTP; Tue, 16 Dec 2014 05:59:04 -0800 (PST) In-Reply-To: <548FC81B.5060107@pi.nu> References: <548FC81B.5060107@pi.nu> Date: Tue, 16 Dec 2014 08:59:04 -0500 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=001a113949b614fd20050a55c3a9 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/M_IC7cRSdGJd1DErhX-NryeYX0c Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:59:10 -0000 --001a113949b614fd20050a55c3a9 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 12:50 AM, Loa Andersson wrote: > Working group, > > An adoption poll has been started on draft-atlas-mpls-ldp-mrt. > We will run the IPR poll in parallel. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-atlas-mpls-ldp-mrt? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are no IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. > I am not aware of any IPR against this draft. Alia > *The response needs to be sent to the MPLS wg mailing list.* > > The document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > mpls wg co-chair > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a113949b614fd20050a55c3a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 16, 2014 at 12:50 AM, Loa Andersson <loa@pi.nu> wrote:
=
Working group,

An adoption poll has been started on draft-atlas-mpls-ldp-mrt.
We will run the IPR poll in parallel.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-atlas-mpls-ldp-mrt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

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

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR.

I am not aware of any IPR against = this draft. =C2=A0

Alia
=C2=A0
*The response needs to be sent to the MPLS wg mailing list.*

The document will not advance to the next stage until a response has been r= eceived from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Loa
mpls wg co-chair
--


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

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

--001a113949b614fd20050a55c3a9-- From nobody Tue Dec 16 06:37: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 12DF31A1B6E for ; Tue, 16 Dec 2014 06:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0Jexl42dJUm for ; Tue, 16 Dec 2014 06:37:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A21B1A1B53 for ; Tue, 16 Dec 2014 06:37:37 -0800 (PST) Received: from DM2PR05MB686.namprd05.prod.outlook.com (10.141.176.147) by DM2PR05MB688.namprd05.prod.outlook.com (10.141.176.152) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 16 Dec 2014 14:37:14 +0000 Received: from DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) by DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) with mapi id 15.01.0031.000; Tue, 16 Dec 2014 14:37:14 +0000 From: Kishore Tiruveedhula To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPQ2pqLyS/lHJUiaYlH9AVHt3pyR9YSA Date: Tue, 16 Dec 2014 14:37:14 +0000 Message-ID: References: <548FC81B.5060107@pi.nu> In-Reply-To: <548FC81B.5060107@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB688; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB688; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(252514010)(189002)(479174004)(199003)(164054003)(24454002)(51704005)(2501002)(2656002)(86362001)(19580395003)(19580405001)(54356999)(68736005)(97736003)(106116001)(105586002)(99286002)(66066001)(20776003)(76176999)(87936001)(83506001)(2950100001)(230783001)(50986999)(46102003)(99396003)(102836002)(77156002)(77096005)(40100003)(101416001)(62966003)(92566001)(107046002)(120916001)(21056001)(31966008)(4396001)(106356001)(2900100001)(122556002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB688; H:DM2PR05MB686.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <1839BC0927962D449DDD50158ABE7C92@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2D1sR3IF3kORCeHeu-dTjL3Ua38 Cc: "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 14:37:39 -0000 I am not aware of any IPR against this draft. Thanks, Kishore =20 On 12/16/14, 12:50 AM, "Loa Andersson" wrote: >Working group, > >An adoption poll has been started on draft-atlas-mpls-ldp-mrt. >We will run the IPR poll in parallel. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-atlas-mpls-ldp-mrt? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >Currently there are no IPR disclosures that relates to this document. > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. > >*The response needs to be sent to the MPLS wg mailing list.* > >The document will not advance to the next stage until a response has >been received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > >Thanks, Loa >mpls wg co-chair >--=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 Dec 16 07:27: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 5E9B01A1B9C for ; Tue, 16 Dec 2014 07:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDvNhfIk9qbb for ; Tue, 16 Dec 2014 07:27:24 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41721A1B99 for ; Tue, 16 Dec 2014 07:27:22 -0800 (PST) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB289.namprd05.prod.outlook.com (10.141.23.19) with Microsoft SMTP Server (TLS) id 15.1.36.22; Tue, 16 Dec 2014 15:27:00 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.01.0031.000; Tue, 16 Dec 2014 15:27:00 +0000 From: Chris Bowers To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPQ31/SIqygxN02o36yRKg7p1ZySV0UA Date: Tue, 16 Dec 2014 15:27:00 +0000 Message-ID: References: <548FC81B.5060107@pi.nu> In-Reply-To: <548FC81B.5060107@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB289; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB289; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(252514010)(164054003)(377454003)(189002)(13464003)(199003)(19580395003)(54356999)(77156002)(122556002)(54606007)(62966003)(2656002)(4396001)(40100003)(19580405001)(54206007)(86362001)(33656002)(2900100001)(50986999)(92566001)(87936001)(76176999)(101416001)(46102003)(21056001)(99396003)(120916001)(2501002)(64706001)(20776003)(99286002)(66066001)(105586002)(106356001)(97736003)(230783001)(76576001)(77096005)(74316001)(106116001)(107046002)(2950100001)(31966008)(102836002)(68736005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB289; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; 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 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2014 15:27:00.6973 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB289 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ib6BeT1Jxd-I66dqfpogA12pLuI Cc: "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 15:27:31 -0000 I am not aware of any IPR against this draft. Chris -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, December 15, 2014 11:50 PM To: mpls@ietf.org Cc: draft-atlas-mpls-ldp-mrt@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: IPR poll on draft-atlas-mpls-ldp-mrt Working group, An adoption poll has been started on draft-atlas-mpls-ldp-mrt. We will run the IPR poll in parallel. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-atlas-mpls-ldp-mrt? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been r= eceived from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Loa mpls wg co-chair --=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 Dec 16 09:17: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 8BC471A1BE3 for ; Tue, 16 Dec 2014 09:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLiJyMTkkSJ4 for ; Tue, 16 Dec 2014 09:17:20 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02381A6FF7 for ; Tue, 16 Dec 2014 09:16:54 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 62EEF9FDD6B96 for ; Tue, 16 Dec 2014 17:16:49 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sBGHGphA007390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Dec 2014 12:16:51 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 12:16:51 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "mpls@ietf.org" Thread-Topic: Missing RFC in draft-ietf-mpls-ipv6-only-gap? Thread-Index: AdAZVBPagBYA92emSYaWc/+rU9V7tA== Date: Tue, 16 Dec 2014 17:16:50 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947C1FAE@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Btm6cshNUy7JVOqmVAbHa09STdE Subject: [mpls] Missing RFC in 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: Tue, 16 Dec 2014 17:17:22 -0000 Dear all, I recently was made aware of RFC 5549 which seems to cover a couple of the = gaps in draft-ietf-mpls-ipv6-only-gap: https://tools.ietf.org/html/rfc5549 RFC 5549 extends MP-BGP with the ability for an IPv4 NLRI (AFI=3D1, SAFI=3D= 1), labeled IPv4 NLRI (AFI=3D1, SAFI=3D4), and VPN-IPv4 NLRI (AFI=3D1, SAFI= =3D128) to use an IPv6 next-hop. This would I believe cover scenario 2 in s= ections 3.3.2, 3.3.2.1, and 3.3.2.1 for the above types of routes. I missed this during the MPLS-RT review and I appreciate if the authors cou= ld confirm my observation.=20 I apologize if this was already discussed. Regards, Mustapha.=20 From nobody Tue Dec 16 09:21:56 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 455F91A700C; Tue, 16 Dec 2014 09:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQD1a289nWjE; Tue, 16 Dec 2014 09:21:50 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E9E1A6FF3; Tue, 16 Dec 2014 09:21:46 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 7D48B5F880F91; Tue, 16 Dec 2014 17:21:42 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sBGHLhfQ009509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 12:21:43 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 12:21:43 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9A Date: Tue, 16 Dec 2014 17:21:42 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> In-Reply-To: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wRpaNqzF5jEpAXNRqHyijORVoXU Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:21:53 -0000 Hi Adrian and all, I was the one who raised the interop issues we found while testing our impl= ementation of LDP IPv6 against existing and deployed implementations. I pro= posed a simple method of using the existing FEC advertisement capability at= the session level as a way for an LSR to detect if an implementation suppo= rt LDP IPv6 FECs and IPv6 addresses. This existing FEC advertisement capabi= lity at session level is defined in draft-ietf-mpls-ldp-ip-pw-capability-08= but with the limitation that it can be used only to disable support of IPv= 6 FECs in LDP Initialization Message; we proposed to generalize the method = to also indicate explicit support for IPv6 FECs and IPv6 Addresses in LDP I= nitialization Message. This method is safe and was also used with mLDP P2M= P and MP2MP FECs when they were introduced. The intent here is that all ses= sion level capabilities in LDP should follow RFC 5561 approach. There was an individual contributor which supported the proposal on the mai= ling list but the authors chose to ignore it and went with a proposal which= overloaded the meaning of the dual-stack capability TLV. Regardless of the= merit of either method, the discussion on the MPLS mailing list was not cl= osed properly from my perspective. Now here is the concern I raised with using the dual-stack capability. Not = only this TLV is an adjacency level feature which is has nothing to do with= FEC capability advertisement, but it is introducing complexity in the impl= ementation which now has to check dual-stack capability for *each* adjacenc= y to the peer *and* the session level FEC capability to decide what the pee= r is capable of at the *session level*. Having said that, I want to keep the spirit of cooperation and make sure we= get this draft published. To that effect, I am not opposed to its publicat= ion as long as the following points are clarified in the draft since now FE= C capability of the LSR peer is determined by a check a both adjacency and = session levels: 1. The draft is missing the behavior when multiple adjacencies exist to the= same LSR and the peer LSR advertised the dual-stack capability only over a= subset of these Hello adjacencies.=20 I assume here the peer LSR is considered to be dual-stack capable as soon a= s any of the Hello adjacencies includes the dual-stack capability. This wou= ld allow a hitless upgrade scenario from an older implementation to one whi= ch complies to this draft 2. Similarly, what would be the behavior if a hello adjacency changes from = sending the dual-stack capability to not sending it? This would be for exam= ple in a hitless downgrade to a version of LDP which does not comply to thi= s draft.=20 I assume here that the session must be bounced since the LSRs need a clean = state to not send IPv6 addresses and IPv6 FECs.=20 3. The document defines 2 values for the dual-stack capability TR. It does = not mention the behavior when an unknown value is received. =20 Will that be considered a fatal error? 4. The draft is missing the behavior of when the peer LSR does not advertis= e the dual-stack capability in all the Hello adjacencies but it advertised = the enabling or disabling of the IPv6 prefix FEC capability in the session = initialization message.=20 I assume here that the absence of the dual-stack capability overrides any s= ession level IPv6 FEC prefix capability advertisement.=20 5. The draft is missing the behavior of when the peer LSR does not advertis= e the dual-stack capability in all the Hello adjacencies but it advertised = the enabling of the IPv6 prefix FEC capability in the session Capability me= ssage. I assume the same behavior as in (4) applies here. Regards, Mustapha. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG > Sent: Thursday, December 04, 2014 2:37 PM > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: (Updates to = LDP for IPv6) > to Proposed Standard >=20 >=20 > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'Updates to LDP for IPv6' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the ietf@iet= f.org > mailing lists by 2014-12-18. Exceptionally, comments may be sent to iesg@= ietf.org > instead. In either case, please retain the beginning of the Subject line = to allow > automated sorting. >=20 > Abstract >=20 > The Label Distribution Protocol (LDP) specification defines > procedures to exchange label bindings over either IPv4, or IPv6 or > both networks. This document corrects and clarifies the LDP behavior > when IPv6 network is used (with or without IPv4). This document > updates RFC 5036 and RFC 6720. >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Dec 16 10:26:04 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 085801ACD2D for ; Tue, 16 Dec 2014 10:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRd2mLsdEbKC for ; Tue, 16 Dec 2014 10:26:01 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCE31A802A for ; Tue, 16 Dec 2014 10:26:00 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-65-54901c560390 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0C.A7.25146.65C10945; Tue, 16 Dec 2014 12:49:42 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 13:25:59 -0500 From: Jeff Tantsura To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPQ2cOz6Y/R7AEerj1GjY0qZYpySV0MA Date: Tue, 16 Dec 2014 18:25:58 +0000 Message-ID: References: <548FC81B.5060107@pi.nu> In-Reply-To: <548FC81B.5060107@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPrG6YzIQQgycnzS2enV/GaPFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoErY07/J7aCifwV X3c2MjcwTuLpYuTkkBAwkdjcM48JwhaTuHBvPVsXIxeHkMARRokjK1exQjjLGSXmn5wOVsUm YCDx/9txFhBbRMBOYuOrf4wgRcwC0xglDv89DVYkLGAo0dF6lwmiyEji7dQdrDD2tYvPwOIs AqoSu068ZgSxeQXMJU5MawSzhQRUJP7cuMcMYnMC1WycvIkdxGYEOu/7qTVgvcwC4hK3nsyH OltAYsme88wQtqjEy8f/wHaJCuhJPNuwmR0iriTx8fd8doheHYkFuz+xQdjWEov+rIWytSWW LXzNDHGPoMTJmU9YJjBKzEKybhaS9llI2mchaZ+FpH0BI+sqRo7S4tSy3HQjw02MwHg8JsHm uINxwSfLQ4wCHIxKPLwb9PtDhFgTy4orcw8xSnOwKInzalbPCxYSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAOH/ilNUlio8NF1/uehLHYP/lvP2Mj+pzXgTyfVnmKDHRbIGLUec7xdDbVx3n 662o1CvQ+ty/pmxb/IK5l+z6/afplfQlnv3Fb7fWfH/SVwH3/fsOruY6rS3+fBF7ceu1ux/a 3SSlgs9wRmps8HSfsZhtr7bb5UWsAv9YVaqzmbMevV9+Tay7VYmlOCPRUIu5qDgRAATwpTqo AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3OgSrZVXqDybg5UNdFfqrpYrI1c Cc: "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:26:03 -0000 Hi Loa, I am not aware of any IPR against this draft. Cheers, Jeff -----Original Message----- From: Loa Andersson Date: Monday, December 15, 2014 at 9:50 PM To: "mpls@ietf.org" Cc: "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: IPR poll on draft-atlas-mpls-ldp-mrt Resent-To: Alia Atlas , , IJsbrand Wijnands , Jeff Tantsura , , , Loa Andersson , , >Working group, > >An adoption poll has been started on draft-atlas-mpls-ldp-mrt. >We will run the IPR poll in parallel. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-atlas-mpls-ldp-mrt? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >Currently there are no IPR disclosures that relates to this document. > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. > >*The response needs to be sent to the MPLS wg mailing list.* > >The document will not advance to the next stage until a response has >been received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > >Thanks, Loa >mpls wg co-chair >--=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 Dec 16 10:27: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 30AA81A872F for ; Tue, 16 Dec 2014 10:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hDgAjCpWZ9I for ; Tue, 16 Dec 2014 10:26:47 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE371ACD96 for ; Tue, 16 Dec 2014 10:26:47 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-c5-549028b25755 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EC.F8.03307.2B820945; Tue, 16 Dec 2014 13:42:27 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 13:26:45 -0500 From: Jeff Tantsura To: Loa Andersson , "mpls@ietf.org" Thread-Topic: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPRoqBDNyFVNHE6totqgj9et9pySV3wA Date: Tue, 16 Dec 2014 18:26:45 +0000 Message-ID: References: <548FC870.3090901@pi.nu> In-Reply-To: <548FC870.3090901@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <9AD08E228A7EC8449850A6D18BE91D77@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXRPgu5mjQkhBl/msVg8O7+M0eLf3DnM Ft8vLWGxuLV0JasDi8eSJT+ZPGZNb2Pz+HL5M1sAcxSXTUpqTmZZapG+XQJXxru9z5kLFvJW LFnxkrWB8SFXFyMnh4SAicT+i9/ZIGwxiQv31oPZQgJHGCWmzJLuYuQCspcD2U8vMYEk2AQM JP5/O84CYosI2ElsfPWPEaSIWWAao8Thv6fBioQFAiVWz/8OVRQksWL2HNYuRg4g20jiyXUb kDCLgKrE1r8HwUp4Bcwl1n/sZoRYrCKxb/EWFpByTqCaaTt4QMKMQLd9P7UGbDqzgLjErSfz mSBuFpBYsuc8M4QtKvHy8T9WEFtUQE/i2YbN7BBxJYmPv+ezQ/TqSCzY/YkNwraWuLfwNTOE rS2xDMrmFRCUODnzCcsERolZSNbNQtI+C0n7LCTts5C0L2BkXcXIUVqcWpabbmSwiREYicck 2HR3MO55aXmIUYCDUYmHd4N+f4gQa2JZcWXuIUZpDhYlcd5ZtfOChQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTCuDT1YIthmKj1J7CpzbnnVJ3sG77c8Dh3aCrr9+7YkLni7Qk7sRcLDycuz 5vBJZUQ535VblsXK+vFHz2xTo5mZ884ZGtmJz37DHtfU8XZJ0MGbH50eBXLsmPfTwe7IhKm3 nXhEpeY3V/bpxhyqVvQur3ORfWaUxuCe+CNi8reIXN0AA5t3dkosxRmJhlrMRcWJAEES5lil AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RQvOK--7DQvmdCtJx1ZI1mSojbg Cc: "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:26:52 -0000 Support as co-author. Cheers, Jeff -----Original Message----- From: Loa Andersson Date: Monday, December 15, 2014 at 9:51 PM To: "mpls@ietf.org" Cc: "draft-atlas-mpls-ldp-mrt@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Resent-To: Alia Atlas , , IJsbrand Wijnands , Jeff Tantsura , , , Loa Andersson , , >Working Group, > >This is to start a two week poll on adopting >draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls@ietf.org). Please give a technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >There is no IPR disclosures directly against this document. An IPR >poll will be done in parallel to the adoption poll, and the adoption >poll will not be closed before we have responses from all authors. > >If you are on the the mpls working group mailing list and >aware of IPR that relates to this draft, you should respond to the >IPR poll. > >This poll ends January 2, 2015. > >/Loa > >--=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 Dec 16 10:51:49 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 1517A1ACDD3 for ; Tue, 16 Dec 2014 10:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsgi0geiFQyr for ; Tue, 16 Dec 2014 10:51:45 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1731ACDC9 for ; Tue, 16 Dec 2014 10:51:44 -0800 (PST) Received: by mail-yk0-f182.google.com with SMTP id 131so6196845ykp.13 for ; Tue, 16 Dec 2014 10:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+2Atke9AjQmLL3NJpxcuH67pTzpgtGNpXKG14bK5BNo=; b=Q0CygMmbR5kIFQcf6uTRK56+yVacWBrMEyXRHZGz/3xftRYnvcseZ1SLureTMhZuSO I4yZV9Wc2tOA/HCDZj4+zuGJyIF6dYyUgY1wAvINyy3VAfhaCmff0ZoDIov/HwtwbLJP Ms/SERefwq+06JEPImz5N3XjxeydPF5NntkqXpVhxfeGd78t2+YzaJEAzqKRdnhAieH3 SWXgzKFwS6ZHfO3pWMdDc8JAiUXpNup/tacO+IpcHiY/ZNO094d/NWBgQj4lJmsKLvio XhjnQ0g/jLLXvOkDbVPwygmWOuAHRvcnq8PJCvClirThsrmkBIIVeKACYm69drG8bof5 5z5w== MIME-Version: 1.0 X-Received: by 10.170.128.207 with SMTP id u198mr30216290ykb.51.1418755903295; Tue, 16 Dec 2014 10:51:43 -0800 (PST) Received: by 10.170.136.132 with HTTP; Tue, 16 Dec 2014 10:51:43 -0800 (PST) In-Reply-To: References: <548FC870.3090901@pi.nu> Date: Tue, 16 Dec 2014 13:51:43 -0500 Message-ID: From: Alia Atlas To: Jeff Tantsura Content-Type: multipart/alternative; boundary=001a1139511ca396c4050a59d9b1 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/T_x5CJFlxDa_3XXFWZdt6wOlqzE Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:51:48 -0000 --001a1139511ca396c4050a59d9b1 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 1:26 PM, Jeff Tantsura wrote: > Support as co-author. > Likewise, of course. Alia > > Cheers, > Jeff > > > > > -----Original Message----- > From: Loa Andersson > Date: Monday, December 15, 2014 at 9:51 PM > To: "mpls@ietf.org" > Cc: "draft-atlas-mpls-ldp-mrt@tools.ietf.org" > , "mpls-chairs@tools.ietf.org" > > Subject: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt > Resent-To: Alia Atlas , , > IJsbrand Wijnands , Jeff Tantsura > , , , > Loa Andersson , , > > >Working Group, > > > >This is to start a two week poll on adopting > >draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. > > > >Please send your comments (support/not support) to the mpls working > >group mailing list (mpls@ietf.org). Please give a technical > >motivation for your support/not support, especially if you think that > >the document should not be adopted as a working group document. > > > >There is no IPR disclosures directly against this document. An IPR > >poll will be done in parallel to the adoption poll, and the adoption > >poll will not be closed before we have responses from all authors. > > > >If you are on the the mpls working group mailing list and > >aware of IPR that relates to this draft, you should respond to the > >IPR poll. > > > >This poll ends January 2, 2015. > > > >/Loa > > > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a1139511ca396c4050a59d9b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 16, 2014 at 1:26 PM, Jeff Tantsura <jeff.tantsura@eri= csson.com> wrote:
Support as co-author.<= br>

Likewise, of course.
Alia
=C2=A0

Cheers,
Jeff




-----Original Message-----
From: Loa Andersson <loa@pi.nu>
Date: Monday, December 15, 2014 at 9:51 PM
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "draft-= atlas-mpls-ldp-mrt@tools.ietf.org"
<draft-atlas-= mpls-ldp-mrt@tools.ietf.org>, "mpls-chairs@tools.ietf.org"
<mpls-chairs@tools.ietf.or= g>
Subject: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt=
Resent-To: Alia Atlas <akatlas@ju= niper.net>, <cbowers@junip= er.net>,
IJsbrand Wijnands <ice@cisco.com>= ;, Jeff Tantsura
<jeff.tantsura@ericsson.co= m>, <kishoret@juniper.net= >, <swallow@cisco.com>= ;,
Loa Andersson <loa@pi.nu>, <rcallon@juniper.net>, <tsaad@cisco.com>

>Working Group,
>
>This is to start a two week poll on adopting
>draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document.
>
>Please send your comments (support/not support) to the mpls working
>group mailing list (mpls@ietf.org)= . Please give a technical
>motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document.
>
>There is no IPR disclosures directly against this document. An IPR
>poll will be done in parallel to the adoption poll, and the adoption >poll will not be closed before we have responses from all authors.
>
>If you are on the the mpls working group mailing list and
>aware of IPR that relates to this draft, you should respond to the
>IPR poll.
>
>This poll ends January 2, 2015.
>
>/Loa
>
>--
>
>
>Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
>Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.= nu
>Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64<= br>
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001a1139511ca396c4050a59d9b1-- From nobody Tue Dec 16 10:57: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 9CE111ACDEC for ; Tue, 16 Dec 2014 10:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtUERh1tdpId for ; Tue, 16 Dec 2014 10:56:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BF81ACDD6 for ; Tue, 16 Dec 2014 10:56:48 -0800 (PST) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 16 Dec 2014 18:56:26 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.01.0031.000; Tue, 16 Dec 2014 18:56:26 +0000 From: Chris Bowers To: Loa Andersson , "mpls@ietf.org" Thread-Topic: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPRoquhUxgjdhUys7FFmQqRlNJySkeQQ Date: Tue, 16 Dec 2014 18:56:26 +0000 Message-ID: References: <548FC870.3090901@pi.nu> In-Reply-To: <548FC870.3090901@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] authentication-results: pi.nu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB292; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB292; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(13464003)(377454003)(252514010)(120916001)(21056001)(64706001)(102836002)(2501002)(33656002)(77096005)(66066001)(230783001)(74316001)(97736003)(46102003)(31966008)(2900100001)(68736005)(92566001)(40100003)(62966003)(99396003)(106116001)(122556002)(77156002)(106356001)(99286002)(105586002)(4396001)(76576001)(20776003)(2656002)(86362001)(101416001)(107046002)(19580395003)(54606007)(76176999)(50986999)(2950100001)(54356999)(19580405001)(87936001)(54206007); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB292; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; 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/v5OdlAWJRY-S-zzZ2iS-T-0hD4M Cc: "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:56:58 -0000 Support as a co-author. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, December 15, 2014 11:52 PM To: mpls@ietf.org Cc: draft-atlas-mpls-ldp-mrt@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Working Group, This is to start a two week poll on adopting draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group 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 no IPR disclosures directly against this document. An IPR poll wil= l be done in parallel to the adoption poll, and the adoption poll will not = be closed before we have responses from all authors. If you are on the the mpls working group mailing list and aware of IPR that= relates to this draft, you should respond to the IPR poll. This poll ends January 2, 2015. /Loa --=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 Dec 16 12:15: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 0B56F1A8744 for ; Tue, 16 Dec 2014 12:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh0aFOHOuspj for ; Tue, 16 Dec 2014 12:15:16 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC0F1A8729 for ; Tue, 16 Dec 2014 12:15:16 -0800 (PST) Received: from DM2PR05MB686.namprd05.prod.outlook.com (10.141.176.147) by DM2PR05MB685.namprd05.prod.outlook.com (10.141.176.145) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 16 Dec 2014 20:15:14 +0000 Received: from DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) by DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) with mapi id 15.01.0031.000; Tue, 16 Dec 2014 20:15:14 +0000 From: Kishore Tiruveedhula To: Loa Andersson , "mpls@ietf.org" Thread-Topic: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPRo6TnfMRb0yEW5hD7AY4rzmJySVEKA Date: Tue, 16 Dec 2014 20:15:13 +0000 Message-ID: References: <548FC870.3090901@pi.nu> In-Reply-To: <548FC870.3090901@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB685; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB685; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(164054003)(377454003)(199003)(252514010)(51704005)(479174004)(19580405001)(86362001)(62966003)(77156002)(92566001)(120916001)(2501002)(97736003)(4396001)(77096005)(102836002)(50986999)(31966008)(101416001)(21056001)(68736005)(105586002)(87936001)(40100003)(46102003)(76176999)(99286002)(99396003)(230783001)(36756003)(122556002)(107046002)(83506001)(19580395003)(106116001)(64706001)(2656002)(20776003)(54356999)(106356001)(2900100001)(2950100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB685; H:DM2PR05MB686.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <38C698E15A83E94895FE8F45A897A10F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3L1VNsUvjwmgp4V3vaihiEKCR4o Cc: "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 20:15:24 -0000 Support as co-author. Thanks, Kishore On 12/16/14, 12:51 AM, "Loa Andersson" wrote: >Working Group, > >This is to start a two week poll on adopting >draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls@ietf.org). Please give a technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >There is no IPR disclosures directly against this document. An IPR >poll will be done in parallel to the adoption poll, and the adoption >poll will not be closed before we have responses from all authors. > >If you are on the the mpls working group mailing list and >aware of IPR that relates to this draft, you should respond to the >IPR poll. > >This poll ends January 2, 2015. > >/Loa > >--=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 Dec 16 13:02: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 299851A87E1 for ; Tue, 16 Dec 2014 13:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrV1Bp_xgcS9 for ; Tue, 16 Dec 2014 13:02:47 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7093A1A87DF for ; Tue, 16 Dec 2014 13:02:47 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-22-54904d3b9596 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BE.C3.03307.B3D40945; Tue, 16 Dec 2014 16:18:19 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 16:02:39 -0500 From: Uma Chunduri To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPRpj45naGsy9UyWrlfNbCwDNJyStRzw Date: Tue, 16 Dec 2014 21:02:39 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F4BD686@eusaamb105.ericsson.se> References: <548FC870.3090901@pi.nu> In-Reply-To: <548FC870.3090901@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPlK6174QQg6lvJC2enV/GaPFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoErY/KxiUwFB7gr fr1axdrA2M3ZxcjJISFgIrF09XRWCFtM4sK99WxdjFwcQgJHGCUWf9sM5SxnlNjUsw2sik1A T+Lj1J/sILaIgJ3Exlf/GEFsZoFpjBKT/tmA2MICERLtpy6zQtRESrzd8gDKNpL486oPrJ5F QFViwv5GoDgHB6+Ar8SZJ7IgYSEBFYl9i7ewgIQ5gUqm7eABCTMC3fb91BomiE3iEreezGeC uFlAYsme88wQtqjEy8f/oH5Rkpi09BwrRL2OxILdn9ggbG2JZQtfg9XzCghKnJz5hGUCo9gs JGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw2MQIj6JgEm+4Oxj0vLQ8xCnAwKvHwbtDvDxFi TSwrrsw9xCjNwaIkzjurdl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZJfHu2Z+xrCV90 eJU+D5/d9H39X4/HXZOrPahyxjJQaHnLYfnLz1vefH3pvs/u/Lr1lX7RaziYheLbjrhcn/d9 ZYzB0XWmxTOPTBBYb7vQcerX1cGy8dOXZzYv9ZHVzd4h9OXSa5uCpaf1j91+O7NOMqy0hid7 /tzkjYyifQwb/xwOyPtoHFeoxFKckWioxVxUnAgAtdQ00IECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EB1ddxJ_4oTfr3sm-CQRZgrrAQk Cc: "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 21:02:49 -0000 Support. -- Uma C. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, December 15, 2014 9:52 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-= ldp-mrt Working Group, This is to start a two week poll on adopting draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group 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 no IPR disclosures directly against this document. An IPR poll wil= l be done in parallel to the adoption poll, and the adoption poll will not = be closed before we have responses from all authors. If you are on the the mpls working group mailing list and aware of IPR that= relates to this draft, you should respond to the IPR poll. This poll ends January 2, 2015. /Loa --=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 Dec 16 16:14: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 A7F661A0393; Tue, 16 Dec 2014 16:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r8Fl1IAa6GY; Tue, 16 Dec 2014 16:13:53 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8435C1A026F; Tue, 16 Dec 2014 16:13:52 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id F131E47AB4EB; Wed, 17 Dec 2014 00:13:46 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sBH0DmCi027634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 19:13:48 -0500 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Dec 2014 19:13:48 -0500 Received: from SG70YWXCHMBA08.zap.alcatel-lucent.com ([169.254.8.137]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 08:13:42 +0800 From: "Dutta, Pranjal K (Pranjal)" To: "Aissaoui, Mustapha (Mustapha)" , "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgAm5T0A= Date: Wed, 17 Dec 2014 00:13:42 +0000 Message-ID: References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: multipart/alternative; boundary="_000_ABD110CD5D879A4BB51C269846E4CA311E253BSG70YWXCHMBA08zap_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Vylr-dBPrTIKpgu4p_8VYQ-yFR4 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 00:13:58 -0000 --_000_ABD110CD5D879A4BB51C269846E4CA311E253BSG70YWXCHMBA08zap_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with the points raised by Mustapha. Thanks, Pranjal -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (= Mustapha) Sent: Tuesday, December 16, 2014 9:22 AM To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: (Updates t= o LDP for IPv6) to Proposed Standard Hi Adrian and all, I was the one who raised the interop issues we found while testing our impl= ementation of LDP IPv6 against existing and deployed implementations. I pro= posed a simple method of using the existing FEC advertisement capability at= the session level as a way for an LSR to detect if an implementation suppo= rt LDP IPv6 FECs and IPv6 addresses. This existing FEC advertisement capabi= lity at session level is defined in draft-ietf-mpls-ldp-ip-pw-capability-08= but with the limitation that it can be used only to disable support of IPv= 6 FECs in LDP Initialization Message; we proposed to generalize the method = to also indicate explicit support for IPv6 FECs and IPv6 Addresses in LDP I= nitialization Message. This method is safe and was also used with mLDP P2M= P and MP2MP FECs when they were introduced. The intent here is that all ses= sion level capabilities in LDP should follow RFC 5561 approach. There was an individual contributor which supported the proposal on the mai= ling list but the authors chose to ignore it and went with a proposal which= overloaded the meaning of the dual-stack capability TLV. Regardless of the= merit of either method, the discussion on the MPLS mailing list was not cl= osed properly from my perspective. Now here is the concern I raised with using the dual-stack capability. Not = only this TLV is an adjacency level feature which is has nothing to do with= FEC capability advertisement, but it is introducing complexity in the impl= ementation which now has to check dual-stack capability for *each* adjacenc= y to the peer *and* the session level FEC capability to decide what the pee= r is capable of at the *session level*. Having said that, I want to keep the spirit of cooperation and make sure we= get this draft published. To that effect, I am not opposed to its publicat= ion as long as the following points are clarified in the draft since now FE= C capability of the LSR peer is determined by a check a both adjacency and = session levels: 1. The draft is missing the behavior when multiple adjacencies exist to the= same LSR and the peer LSR advertised the dual-stack capability only over a= subset of these Hello adjacencies. I assume here the peer LSR is considered to be dual-stack capable as soon a= s any of the Hello adjacencies includes the dual-stack capability. This wou= ld allow a hitless upgrade scenario from an older implementation to one whi= ch complies to this draft 2. Similarly, what would be the behavior if a hello adjacency changes from = sending the dual-stack capability to not sending it? This would be for exam= ple in a hitless downgrade to a version of LDP which does not comply to thi= s draft. I assume here that the session must be bounced since the LSRs need a clean = state to not send IPv6 addresses and IPv6 FECs. 3. The document defines 2 values for the dual-stack capability TR. It does = not mention the behavior when an unknown value is received. Will that be considered a fatal error? 4. The draft is missing the behavior of when the peer LSR does not advertis= e the dual-stack capability in all the Hello adjacencies but it advertised = the enabling or disabling of the IPv6 prefix FEC capability in the session = initialization message. I assume here that the absence of the dual-stack capability overrides any s= ession level IPv6 FEC prefix capability advertisement. 5. The draft is missing the behavior of when the peer LSR does not advertis= e the dual-stack capability in all the Hello adjacencies but it advertised = the enabling of the IPv6 prefix FEC capability in the session Capability me= ssage. I assume the same behavior as in (4) applies here. Regards, Mustapha. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG > Sent: Thursday, December 04, 2014 2:37 PM > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: (Updates > to LDP for IPv6) to Proposed Standard > > > The IESG has received a request from the Multiprotocol Label Switching > WG > (mpls) to consider the following document: > - 'Updates to LDP for IPv6' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-12-18. Exceptio= nally, comments may > be sent to iesg@ietf.org instead. In either case, p= lease retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > The Label Distribution Protocol (LDP) specification defines > procedures to exchange label bindings over either IPv4, or IPv6 or > both networks. This document corrects and clarifies the LDP behavior > when IPv6 network is used (with or without IPv4). This document > updates RFC 5036 and RFC 6720. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_ABD110CD5D879A4BB51C269846E4CA311E253BSG70YWXCHMBA08zap_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with the po= ints raised by Mustapha.

 

Thanks,<= /span>

Pranjal<= /span>

 

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (= Mustapha)
Sent: Tuesday, December 16, 2014 9:22 AM
To: ietf@ietf.org; IETF-Announce
Cc: mpls@ietf.org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Upd= ates to LDP for IPv6) to Proposed Standard

 

Hi Adrian and all,

I was the one who raised the interop issues we fo= und while testing our implementation of LDP IPv6 against existing and deplo= yed implementations. I proposed a simple method of using the existing FEC a= dvertisement capability at the session level as a way for an LSR to detect if an implementation support LDP IPv6 = FECs and IPv6 addresses. This existing FEC advertisement capability at sess= ion level is defined in draft-ietf-mpls-ldp-ip-pw-capability-08 but with th= e limitation that it can be used only to disable support of IPv6 FECs in LDP Initialization Message; we pro= posed to generalize the method to also indicate explicit support for IPv6 F= ECs and IPv6 Addresses in LDP Initialization Message.  This method is = safe and was also used with mLDP P2MP and MP2MP FECs when they were introduced. The intent here is that all sess= ion level capabilities in LDP should follow RFC 5561 approach.

 

There was an individual contributor which support= ed the proposal on the mailing list but the authors chose to ignore it and = went with a proposal which overloaded the meaning of the dual-stack capabil= ity TLV. Regardless of the merit of either method, the discussion on the MPLS mailing list was not closed prop= erly from my perspective.

 

Now here is the concern I raised with using the d= ual-stack capability. Not only this TLV is an adjacency level feature which= is has nothing to do with FEC capability advertisement, but it is introduc= ing complexity in the implementation which now has to check dual-stack capability for *each* adjacency to the p= eer *and* the session level FEC capability to decide what the peer is capab= le of at the *session level*.

 

Having said that, I want to keep the spirit of co= operation and make sure we get this draft published. To that effect, I am n= ot opposed to its publication as long as the following points are clarified= in the draft since now FEC capability of the LSR peer is determined by a check a both adjacency and session leve= ls:

 

1. The draft is missing the behavior when multipl= e adjacencies exist to the same LSR and the peer LSR advertised the dual-st= ack capability only over a subset of these Hello adjacencies.

I assume here the peer LSR is considered to be du= al-stack capable as soon as any of the Hello adjacencies includes the dual-= stack capability. This would allow a hitless upgrade scenario from an older= implementation to one which complies to this draft

 

2. Similarly, what would be the behavior if a hel= lo adjacency changes from sending the dual-stack capability to not sending = it? This would be for example in a hitless downgrade to a version of LDP wh= ich does not comply to this draft.

I assume here that the session must be bounced si= nce the LSRs need a clean state to not send IPv6 addresses and IPv6 FECs.

 

3. The document defines 2 values for the dual-sta= ck capability TR. It does not mention the behavior when an unknown value is= received.  

Will that be considered a fatal error?=

 

4. The draft is missing the behavior of when the = peer LSR does not advertise the dual-stack capability in all the Hello adja= cencies but it advertised the enabling or disabling of the IPv6 prefix FEC = capability in the session initialization message.

I assume here that the absence of the dual-stack = capability overrides any session level IPv6 FEC prefix capability advertise= ment.

 

5. The draft is missing the behavior of when the = peer LSR does not advertise the dual-stack capability in all the Hello adja= cencies but it advertised the enabling of the IPv6 prefix FEC capability in= the session Capability message.

I assume the same behavior as in (4) applies here= .

 

Regards,

Mustapha.

 

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

> From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of The IESG

> Sent: Thursday, December 04, 2014 2:37 PM

> To: IETF-Announce

> Cc: mpls@ietf.org

> Subject: [mpls] Last Call: <draft-ietf-mp= ls-ldp-ipv6-14.txt> (Updates

> to LDP for IPv6) to Proposed Standard

>

>

> The IESG has received a request from the Mul= tiprotocol Label Switching

> WG

> (mpls) to consider the following document:

> - 'Updates to LDP for IPv6'

>   <draft-ietf-mpls-ldp-ipv6-14.= txt> as Proposed Standard

>

> The IESG plans to make a decision in the nex= t few weeks, and solicits

> final comments on this action. Please send s= ubstantive comments to the

> ietf@ietf.org mailing= lists by 2014-12-18. Exceptionally, comments may

> be sent to = iesg@ietf.org<= /a> instead. In either case, please retain the

> beginning of the Subject line to allow autom= ated sorting.

>

> Abstract

>

>    The Label Distribution Pro= tocol (LDP) specification defines

>    procedures to exchange lab= el bindings over either IPv4, or IPv6 or

>    both networks. This docume= nt corrects and clarifies the LDP behavior

>    when IPv6 network is used = (with or without IPv4). This document

>    updates RFC 5036 and RFC 6= 720.

>

> The file can be obtained via

> http://datatracker.ie= tf.org/doc/draft-ietf-mpls-ldp-ipv6/

>

> IESG discussion can be tracked via

> http://datatracker.ie= tf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/

>

>

> No IPR declarations have been submitted dire= ctly on this I-D.

>

> ____________________________________________= ___

> mpls mailing list

> mpls@ietf.org

> https://ww= w.ietf.org/mailman/listinfo/mpls

 

_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.iet= f.org/mailman/listinfo/mpls

--_000_ABD110CD5D879A4BB51C269846E4CA311E253BSG70YWXCHMBA08zap_-- From nobody Tue Dec 16 18:17: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 01EA11A0248 for ; Tue, 16 Dec 2014 18:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SgXslknk7uj for ; Tue, 16 Dec 2014 18:17:32 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9381A0072 for ; Tue, 16 Dec 2014 18:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9375; q=dns/txt; s=iport; t=1418782652; x=1419992252; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G0z82yhnkzPc0vUeCQ8NEAco2COAyTwy3Ny5fY083kE=; b=HueGDeROvfM8MAp9/LC2PDpxcfUFwO9MVJc6GVFeSh0hLGNip1bcN1FI cr26Ix6NfmXRQrzojn6Y23xTIXalHg8pWgidCyBciqCBRX4kzYHRQJNdu 0doed8mGptQLD2md/318rediupIkVBGV1pKm09Le6+8K/G0/6Kl6sniE9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFALbmkFStJV2Y/2dsb2JhbABQCoJkIoEqBMtyAoEeFgEBAQEBfYQMAQEBBA4sKwgFBwwEAgEIDgMEAQELFAkHMhQJCAEBBAENBQiIJAHUZQEBAQEBAQEBAQEBAQEBAQEBAQEBARePEAYLAR8xBwaDEIETBYwxgVaJe4Jeh0OCVYM4IoNsboEFBxcGHH4BAQE X-IronPort-AV: E=Sophos;i="5.07,590,1413244800"; d="scan'208";a="113728457" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by mtv-iport-2.cisco.com with ESMTP; 17 Dec 2014 02:17:31 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBH2HVpR017420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 02:17:31 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 20:17:30 -0600 From: "Nobo Akiya (nobo)" To: Yimin Shen , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "Tarek Saad (tsaad)" Thread-Topic: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAWkq+I6dTANiYXSfWbIAmdrlJPpQBFq1AwAGFau4AAGuHhoA== Date: Wed, 17 Dec 2014 02:17:30 +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.24.76.183] 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/M3PiwTVpa-mqZJXxHXAc95OBp8E Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 17 Dec 2014 02:17:35 -0000 Hi Yimin, My apologies for top posting. I wanted to respond to your (2) first and the= n discuss (1), and found it easier with top posting. Sure, what I can do is to update the document so that both "incoming LAG me= mber link verification" and "individual end- to-end path verification" are = supported, but defines "how an LSR obtains interface index from remote LSRs= " to be outside the scope of the document. Specifically: - Extend the Interface Index Sub-TLV to have (L)ocal and (R)emote flags. - For a LAG member, the DDMAP MUST contain the Interface Index Sub-TLV with= the (L)ocal flag. - For a LAG member, the DDMAP MAY contain the Interface Index Sub-TLV with = the (R)emote flag. - State that how an LSR obtains the Interface Index of the incoming interfa= ces of the downstream LSR is outside the scope of this document. - Update the responder LSR procedures of DDMAP handling. - Update the initiator LSR procedures of DDMAP handling. - Break up the validation section into 2 parts: One for "incoming LAG membe= r link verification" and one for "individual end- to-end path verification"= . Note, with all of these changes (i.e., including procedures for future usag= e when more inter-node information is available), all aspects of your sugge= sted topics for the new Applicability section are already covered or are ou= tside the scope of this document. Given that, do you see it as a MUST to ad= d the new Applicability section? Thanks! -Nobo > -----Original Message----- > From: Yimin Shen [mailto:yshen@juniper.net] > Sent: Tuesday, December 16, 2014 8:35 AM > To: Nobo Akiya (nobo); draft-akiya-mpls-lsp-ping-lag- > multipath@tools.ietf.org; Tarek Saad (tsaad) > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: RE: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag= - > multipath >=20 > Nobo, authors, >=20 > I can support the document for WG adoption. However I believe it can > significantly improve if "incoming LAG member link verification" and > "individual end-to-end path verification" are supported. Therefore, I'd l= ike > to make a couple of suggestions. >=20 > 1. Add an "Applicability" section to describe the current limitations. > - The general lack of layer-2 visibility in a layer-3 network, especially= for LAG > member indices. > - No incoming LAG member link verification at downstream router. > - No individual end-to-end path verification. > - Failure scenarios that may not be detected. > - Your strategy to balance coverage and simplicity that you mentioned > below. >=20 > 2. For completeness and future compatibility, include/describe the > procedures of "incoming LAG member link verification" and "individual end= - > to-end path verification", assuming the LAG member index visibility issue= is > resolved. > - This visibility could be achieved through some protocol, or learning fr= om a > central controller. > - For this reason, the document may need to allow "Interface Index Sub-TL= V > of LAG member link" learned from Echo Reply to be reflected in the next > Echo Request. >=20 >=20 > Thanks, >=20 > /Yimin >=20 >=20 >=20 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Sunday, December 14, 2014 9:48 AM > To: Yimin Shen; draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; > Tarek Saad (tsaad) > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: RE: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag= - > multipath >=20 > Hi Yimin, >=20 > Thank you for taking time to review this document and providing comments. >=20 > Please see in-line for [NOBO]. >=20 > > -----Original Message----- > > From: Yimin Shen [mailto:yshen@juniper.net] > > Sent: Saturday, December 13, 2014 12:08 AM > > To: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; Nobo Akiya > > (nobo); Tarek Saad (tsaad) > > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > > Subject: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag- > > multipath > > > > Hi authors, > > > > I was asked by the MPLS WG chairs to review this draft. Thanks Nobo > > for clarifying some points for me during the review. Here are my > > primary comments. > > > > This draft is trying to address multi-path discovery and verification > > for LSPs over LAGs, which is a valid but challenging use case with a > > long history. From this perspective, I think the draft shows a good eff= ort. > > > > The mechanism tries to extend LSP traceroute, which is a layer-3 OAM > > tool, to explore and exercise layer-2 multi-paths. It may be debatable > > whether this is a layer violation, but I'd like to leave it to the WG. >=20 > [NOBO] I think that's a fair statement. Although I'd like to point out th= at, > without "some extensions" to the LSP Ping/Trace or other tools, there is = no > interoperable way to identify some faults of LSP over LAG today, that's a > really bad thing. >=20 > > > > Nevertheless, I can see some challenges that the mechanism faces. > > These challenges are essentially related to the lack of layer-2 > > visibility on layer-3 routers. Specifically, the draft uses an > > interface index to indentify each LAG member link, which is a layer-2 > > link. However, the two routers at the endpoints of a LAG normally do > > not have the info of the LAG member link indices of each other. This > > results in some limitations in multi-path > > verification: >=20 > [NOBO] Yes that's a correct statement, and if we were to create a > mechanism such that the two L3 endpoints across a LAG (or LAGs) has > visibility of each other, that's a rather a large problem requiring much = wider > extensions, possibility beyond the LSP Ping/Trace tools. >=20 > > > > [1] It doesn't support incoming LAG member link verification for Echo > > Request on the downstream router of a LAG. IOW, the ingress router may > > set an Echo Request's destination to a 127/8 prefix according to the > > multi- path info of a particular LAG member link, but the downstream > > router has no way to verify that the upstream router indeed sent the > > Echo Request over the claimed LAG member link. This is due to the lack > > of local and remote LAG member link association, and the lack of > > upstream LAG member link identification in the Echo Request. Without > > incoming LAG member link verification, this traceroute would not > > provide more useful information than traditional LSP tracerotue over LA= G > as a single layer-3 interface. > > > > [2] For the above reason, it does not support verification for > > individual end- 2-end paths, which is a desired mode in > > troubleshooting and pinpointing a problem path. > > > > [3] For the same reason, the draft has to require the ingress router > > to always verify all paths. In particular, the ingress needs to match > > the count of Echo Request sent and the count of Echo Reply received, > > and verify the 1-1 relationship between upstream member links and > > downstream member links. This may give the users some idea about the > > forwarding behavior on the LAG, but not the ability to detect all failu= re > scenarios. >=20 > [NOBO] The limitation that you identified in [1] is valid, and the approa= ch > described in [3] does indeed require more MPLS echo request/reply packets= . > However, what this mechanism and the approach described in [3] will > provide is a guarantee that the initiator LSR is able to exercise all LAG > members for a given LSP. And that provides a way to discover whether or > not the traffic over LSP is black holing or not on this LAG. Yes there is= still a > corner case of faulty FIB that causes some LAG members to criss-cross and > land up on unexpected LAG members on the other side, but that's the only > case and that's not a big problem when looking at "anti-black-hole" > extension. >=20 > > > > Therefore, the current draft does not seem to be sufficient or > > reliable enough. I'd suggest the authors to address the above issue > > before WG adoption. >=20 > [NOBO] I tend to think this mechanism strikes a good balance between the > coverage and the simplicity, and is well worth pursuing. I'd rather inves= t > time in implementing this, rather than get "traffic is black holing!!" > customer cases, and I certainly hope that operators feel the same way. >=20 > [NOBO] Through our off-list email exchanges, you provided one comment > that requires a document change. Which is, what should the responder LSR > do when received multipath information does not map to a LAG member > link. To address this, I have added following texts below Figure 2. >=20 > When none of the received multipath information maps to a particular > LAG member link, then the responder LSR MUST still place the > Interface Index Sub-TLV for that LAG member link in the DDMAP but > inclusion of the Multipath Data Sub-TLV for that LAG member link is > OPTIONAL. If the Multipath Data Sub-TLV is included, then the > Multipath Length field of the Multipath Data Sub-TLV MUST be zero. >=20 > Again thanks for your time and effort to review this document! >=20 > -Nobo >=20 > > > > > > Thanks and regards, > > > > -- > > Yimin Shen > > Juniper Networks From nobody Tue Dec 16 18:35:43 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 DA6E11A0242 for ; Tue, 16 Dec 2014 18:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VhsBmKU8W15 for ; Tue, 16 Dec 2014 18:35:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992BB1A0072 for ; Tue, 16 Dec 2014 18:35:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQD78860; Wed, 17 Dec 2014 02:35:38 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 17 Dec 2014 02:35:37 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Wed, 17 Dec 2014 10:35:34 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPRpNmK3IN2smEy0aLOF7LF4LJyRvkxQ Date: Wed, 17 Dec 2014 02:35:33 +0000 Message-ID: References: <548FC870.3090901@pi.nu> In-Reply-To: <548FC870.3090901@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/4c4SnLdoIj-2S4WXHY0KqRK7v3s Cc: "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 02:35:42 -0000 Yes/support. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, December 16, 2014 1:52 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org > Subject: [mpls] poll to see if we have consensus to adopt > draft-atlas-mpls-ldp-mrt >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-atlas-mpls-ldp-mrt-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 no IPR disclosures directly against this document. An IPR poll w= ill be done > in parallel to the adoption poll, and the adoption poll will not be close= d before we > have responses from all authors. >=20 > If you are on the the mpls working group mailing list and aware of IPR th= at relates > to this draft, you should respond to the IPR poll. >=20 > This poll ends January 2, 2015. >=20 > /Loa >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Dec 16 22:04: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 AAB741A1E0E; Tue, 16 Dec 2014 22:04:07 -0800 (PST) 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 hi6toxSZvpUI; Tue, 16 Dec 2014 22:04:05 -0800 (PST) Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168331A1DE2; Tue, 16 Dec 2014 22:04:02 -0800 (PST) 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 1Y17i8-0006nk-Bh; Wed, 17 Dec 2014 08:03:48 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Wed, 17 Dec 2014 08:03:47 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2423812.xY77hCPTRJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201412170803.47595.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/86tVP63cX-lbKx1Z6QgBRjWqGsI Cc: "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: 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, 17 Dec 2014 06:04:08 -0000 --nextPart2423812.xY77hCPTRJ Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday, December 16, 2014 07:21:42 PM Aissaoui, Mustapha=20 (Mustapha) wrote: > Hi Adrian and all, > I was the one who raised the interop issues we found > while testing our implementation of LDP IPv6 against > existing and deployed implementations. Mustapha, I'm curious - are testing against other LDPv6=20 implementations, or LDPv4 implementations? Mark. --nextPart2423812.xY77hCPTRJ 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) iQIcBAABAgAGBQJUkRzDAAoJEGcZuYTeKm+GY4wQAIJJaRmsO1C7qGHrH/YvRmtg drEcwUo6IH2UxGsTx0Op39NPJ2j4LqtLftxk/JhGK7e4giKyI5s0AnwoWNvZXYF8 c2uUz7m9YJzEyGSjPfkmV/W0WMZPHsvGVfUNVTAbP+fraKNP4tTAGw6ZwL2idccK 40W5kUU9BbAB/krbuyNp9g+3JFXIfVxG1FO6laD1q9T1pPEpnN4LZI7y1Wc5MCS8 49RubKAYpq4bNC1lpht7nrB/VbHGzYpUUMnBUvxnKjLfmsYVCuEVLzwZxE7Tjkio BJl66NA9zzbj26maygbtDTTN0mbpSutk3Ih+VsB7+vWuYkaaHoJqRgq92ZBYa+QQ cp90DCaq/IhMRKQlBojYOsRD/XlGWuTFfZkaFsKnVw9umySXKDlirqAjYLlV94SG BXemnM5/seQglY+vnfod6kfU4Agwqx3anLR/SpFFvnbmNS1ozbCeF+vF0XaSBtnl 0SBeqQS8qWJRh2gxJTAV+wyo38M6e3RAmWWi9Pz1zgu4lbNkyIcvt9hOwT0tlV92 BG1bfaRKk3jL+oP1kRgx1WodRhEgK9w1ED1Q1yd9blfRkElza6xo8rJJ4PpAW14I cYrVWFg/lMtBBFSa5QXwLNnRlkRDQrdRDBdhiasiR1i6rPWUc7gpSCKYcXj1T2pq G7U/6ubOp8Bp4moWppQL =zLkt -----END PGP SIGNATURE----- --nextPart2423812.xY77hCPTRJ-- From nobody Wed Dec 17 02:50: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 5BE681A888B for ; Wed, 17 Dec 2014 02:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.071 X-Spam-Level: X-Spam-Status: No, score=-0.071 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYQRyRJ-Zcdv for ; Wed, 17 Dec 2014 02:50:30 -0800 (PST) Received: from smtp06.msg.oleane.net (smtp06.msg.oleane.net [62.161.4.6]) by ietfa.amsl.com (Postfix) with ESMTP id 66E831A1EFE for ; Wed, 17 Dec 2014 02:50:29 -0800 (PST) Received: from MGosseDellM6800 ([46.218.58.213]) (authenticated) by smtp06.msg.oleane.net (MSA) with ESMTP id sBHAkWjZ010620 for ; Wed, 17 Dec 2014 11:46:33 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: References: In-Reply-To: Date: Wed, 17 Dec 2014 11:50:27 +0100 Message-ID: <004501d019e7$4520c660$cf625320$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01D019EF.A6E9C240" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdAZ5dfzrHfdL9dCS+WGgWv9PvjDsAAAVFTQ Content-Language: fr X-Backend: vm-smtp-sophos19v3 X-PMX-Spam: Probability=11% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.17.103920 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Uu93EVQp0pBt5tAN1JT-N6C5KC4 Subject: [mpls] MPLS SDN World Congress Paris 2015 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 10:50:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0046_01D019EF.A6E9C240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Segment routing use cases, SDN migration, NFV PoCs reports, open source vs standards: the 17th edition of MPLS SDN World, co-located with the NFV & SDN Summit, will address in detail the current major technology issues impacting the core networks infrastructures. The agendas are online: http://www.uppersideconferences.com/mpls-sdn/mpls_sdn_2015_agenda_conference _day_1.html ------=_NextPart_000_0046_01D019EF.A6E9C240 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Segment routing use cases, SDN = migration, NFV PoCs reports, open source vs standards: the 17th edition = of MPLS SDN World, = co-located with the NFV & = SDN Summit, will address in detail the current major technology = issues impacting the core networks = infrastructures.

 

The agendas are online: http://www.uppersideconferences.com/mpls-sdn/mpls= _sdn_2015_agenda_conference_day_1.html

 

<= /body> ------=_NextPart_000_0046_01D019EF.A6E9C240-- From nobody Wed Dec 17 05:10: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 7BBDD1A8A59 for ; Wed, 17 Dec 2014 05:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7KaSDDCPAHK for ; Wed, 17 Dec 2014 05:10:17 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29891A8A54 for ; Wed, 17 Dec 2014 05:10:16 -0800 (PST) Received: from SN2PR0501MB1070.namprd05.prod.outlook.com (25.160.59.15) by SN2PR0501MB1072.namprd05.prod.outlook.com (25.160.59.151) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 17 Dec 2014 13:10:14 +0000 Received: from SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) by SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) with mapi id 15.01.0031.000; Wed, 17 Dec 2014 13:10:14 +0000 From: Yimin Shen To: "Nobo Akiya (nobo)" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "Tarek Saad (tsaad)" Thread-Topic: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAWkq+I6dTANiYXSfWbIAmdrlJPpQBFq1AwAGFau4AAGuHhoAAX5fbg Date: Wed, 17 Dec 2014 13:10:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0501MB1072; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:SN2PR0501MB1072; x-forefront-prvs: 042857DBB5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51914003)(377454003)(51444003)(41574002)(164054003)(189002)(51704005)(199003)(40100003)(106356001)(46102003)(86362001)(62966003)(54356999)(93886004)(120916001)(230783001)(105586002)(33656002)(77156002)(20776003)(76176999)(68736005)(64706001)(101416001)(74316001)(19580405001)(99396003)(99286002)(31966008)(107046002)(50986999)(122556002)(54206007)(66066001)(54606007)(21056001)(87936001)(97736003)(4396001)(92566001)(2656002)(102836002)(2900100001)(19580395003)(76576001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0501MB1072; H:SN2PR0501MB1070.namprd05.prod.outlook.com; FPR:; SPF:None; 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/6RnxrHQLPM6_fbYoitfKRs4nogw Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 17 Dec 2014 13:10:21 -0000 Hi Nobo, This approach sounds fine to me. Thanks for the flexibility. Please see inline... Thanks, /Yimin -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Tuesday, December 16, 2014 9:18 PM To: Yimin Shen; draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; Tar= ek Saad (tsaad) Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: RE: comments for MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-m= ultipath Hi Yimin, My apologies for top posting. I wanted to respond to your (2) first and the= n discuss (1), and found it easier with top posting. Sure, what I can do is to update the document so that both "incoming LAG me= mber link verification" and "individual end- to-end path verification" are = supported, but defines "how an LSR obtains interface index from remote LSRs= " to be outside the scope of the document. [yshen] Treating how to get interface index as out of scope is fine. Specifically: - Extend the Interface Index Sub-TLV to have (L)ocal and (R)emote flags. - For a LAG member, the DDMAP MUST contain the Interface Index Sub-TLV with= the (L)ocal flag. - For a LAG member, the DDMAP MAY contain the Interface Index Sub-TLV with = the (R)emote flag. - State that how an LSR obtains the Interface Index of the incoming interfa= ces of the downstream LSR is outside the scope of this document. - Update the responder LSR procedures of DDMAP handling. - Update the initiator LSR procedures of DDMAP handling. - Break up the validation section into 2 parts: One for "incoming LAG membe= r link verification" and one for "individual end- to-end path verification"= . Note, with all of these changes (i.e., including procedures for future usag= e when more inter-node information is available), all aspects of your sugge= sted topics for the new Applicability section are already covered or are ou= tside the scope of this document. Given that, do you see it as a MUST to ad= d the new Applicability section? [yshen] Given what you've outlined above, I agree that an Applicability sec= tion may not be needed.=20 Thanks! -Nobo > -----Original Message----- > From: Yimin Shen [mailto:yshen@juniper.net] > Sent: Tuesday, December 16, 2014 8:35 AM > To: Nobo Akiya (nobo); draft-akiya-mpls-lsp-ping-lag-=20 > multipath@tools.ietf.org; Tarek Saad (tsaad) > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: RE: comments for MPLS-RT review of=20 > draft-akiya-mpls-lsp-ping-lag- multipath >=20 > Nobo, authors, >=20 > I can support the document for WG adoption. However I believe it can=20 > significantly improve if "incoming LAG member link verification" and=20 > "individual end-to-end path verification" are supported. Therefore,=20 > I'd like to make a couple of suggestions. >=20 > 1. Add an "Applicability" section to describe the current limitations. > - The general lack of layer-2 visibility in a layer-3 network,=20 > especially for LAG member indices. > - No incoming LAG member link verification at downstream router. > - No individual end-to-end path verification. > - Failure scenarios that may not be detected. > - Your strategy to balance coverage and simplicity that you mentioned=20 > below. >=20 > 2. For completeness and future compatibility, include/describe the=20 > procedures of "incoming LAG member link verification" and "individual=20 > end- to-end path verification", assuming the LAG member index=20 > visibility issue is resolved. > - This visibility could be achieved through some protocol, or learning=20 > from a central controller. > - For this reason, the document may need to allow "Interface Index=20 > Sub-TLV of LAG member link" learned from Echo Reply to be reflected in=20 > the next Echo Request. >=20 >=20 > Thanks, >=20 > /Yimin >=20 >=20 >=20 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Sunday, December 14, 2014 9:48 AM > To: Yimin Shen;=20 > draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; > Tarek Saad (tsaad) > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: RE: comments for MPLS-RT review of=20 > draft-akiya-mpls-lsp-ping-lag- multipath >=20 > Hi Yimin, >=20 > Thank you for taking time to review this document and providing comments. >=20 > Please see in-line for [NOBO]. >=20 > > -----Original Message----- > > From: Yimin Shen [mailto:yshen@juniper.net] > > Sent: Saturday, December 13, 2014 12:08 AM > > To: draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org; Nobo=20 > > Akiya (nobo); Tarek Saad (tsaad) > > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > > Subject: comments for MPLS-RT review of=20 > > draft-akiya-mpls-lsp-ping-lag- multipath > > > > Hi authors, > > > > I was asked by the MPLS WG chairs to review this draft. Thanks Nobo=20 > > for clarifying some points for me during the review. Here are my=20 > > primary comments. > > > > This draft is trying to address multi-path discovery and=20 > > verification for LSPs over LAGs, which is a valid but challenging=20 > > use case with a long history. From this perspective, I think the draft = shows a good effort. > > > > The mechanism tries to extend LSP traceroute, which is a layer-3 OAM=20 > > tool, to explore and exercise layer-2 multi-paths. It may be=20 > > debatable whether this is a layer violation, but I'd like to leave it t= o the WG. >=20 > [NOBO] I think that's a fair statement. Although I'd like to point out=20 > that, without "some extensions" to the LSP Ping/Trace or other tools,=20 > there is no interoperable way to identify some faults of LSP over LAG=20 > today, that's a really bad thing. >=20 > > > > Nevertheless, I can see some challenges that the mechanism faces. > > These challenges are essentially related to the lack of layer-2=20 > > visibility on layer-3 routers. Specifically, the draft uses an=20 > > interface index to indentify each LAG member link, which is a=20 > > layer-2 link. However, the two routers at the endpoints of a LAG=20 > > normally do not have the info of the LAG member link indices of each=20 > > other. This results in some limitations in multi-path > > verification: >=20 > [NOBO] Yes that's a correct statement, and if we were to create a=20 > mechanism such that the two L3 endpoints across a LAG (or LAGs) has=20 > visibility of each other, that's a rather a large problem requiring=20 > much wider extensions, possibility beyond the LSP Ping/Trace tools. >=20 > > > > [1] It doesn't support incoming LAG member link verification for=20 > > Echo Request on the downstream router of a LAG. IOW, the ingress=20 > > router may set an Echo Request's destination to a 127/8 prefix=20 > > according to the > > multi- path info of a particular LAG member link, but the downstream=20 > > router has no way to verify that the upstream router indeed sent the=20 > > Echo Request over the claimed LAG member link. This is due to the=20 > > lack of local and remote LAG member link association, and the lack=20 > > of upstream LAG member link identification in the Echo Request.=20 > > Without incoming LAG member link verification, this traceroute would=20 > > not provide more useful information than traditional LSP tracerotue=20 > > over LAG > as a single layer-3 interface. > > > > [2] For the above reason, it does not support verification for=20 > > individual end- 2-end paths, which is a desired mode in=20 > > troubleshooting and pinpointing a problem path. > > > > [3] For the same reason, the draft has to require the ingress router=20 > > to always verify all paths. In particular, the ingress needs to=20 > > match the count of Echo Request sent and the count of Echo Reply=20 > > received, and verify the 1-1 relationship between upstream member=20 > > links and downstream member links. This may give the users some idea=20 > > about the forwarding behavior on the LAG, but not the ability to=20 > > detect all failure > scenarios. >=20 > [NOBO] The limitation that you identified in [1] is valid, and the=20 > approach described in [3] does indeed require more MPLS echo request/repl= y packets. > However, what this mechanism and the approach described in [3] will=20 > provide is a guarantee that the initiator LSR is able to exercise all=20 > LAG members for a given LSP. And that provides a way to discover=20 > whether or not the traffic over LSP is black holing or not on this=20 > LAG. Yes there is still a corner case of faulty FIB that causes some=20 > LAG members to criss-cross and land up on unexpected LAG members on=20 > the other side, but that's the only case and that's not a big problem whe= n looking at "anti-black-hole" > extension. >=20 > > > > Therefore, the current draft does not seem to be sufficient or=20 > > reliable enough. I'd suggest the authors to address the above issue=20 > > before WG adoption. >=20 > [NOBO] I tend to think this mechanism strikes a good balance between=20 > the coverage and the simplicity, and is well worth pursuing. I'd=20 > rather invest time in implementing this, rather than get "traffic is blac= k holing!!" > customer cases, and I certainly hope that operators feel the same way. >=20 > [NOBO] Through our off-list email exchanges, you provided one comment=20 > that requires a document change. Which is, what should the responder=20 > LSR do when received multipath information does not map to a LAG=20 > member link. To address this, I have added following texts below Figure 2= . >=20 > When none of the received multipath information maps to a particular > LAG member link, then the responder LSR MUST still place the > Interface Index Sub-TLV for that LAG member link in the DDMAP but > inclusion of the Multipath Data Sub-TLV for that LAG member link is > OPTIONAL. If the Multipath Data Sub-TLV is included, then the > Multipath Length field of the Multipath Data Sub-TLV MUST be zero. >=20 > Again thanks for your time and effort to review this document! >=20 > -Nobo >=20 > > > > > > Thanks and regards, > > > > -- > > Yimin Shen > > Juniper Networks From nobody Wed Dec 17 05:27: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 AF9271A8A86; Wed, 17 Dec 2014 05:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2ykSdIbHaf2; Wed, 17 Dec 2014 05:27:02 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6871A8A85; Wed, 17 Dec 2014 05:27:01 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 286AD2F98A889; Wed, 17 Dec 2014 13:26:57 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id sBHDQr42006441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 08:26:58 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 08:26:54 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "mark.tinka@seacom.mu" , "mpls@ietf.org" Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgApvIICAACbQ0A== Date: Wed, 17 Dec 2014 13:26:54 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947C2515@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> <201412170803.47595.mark.tinka@seacom.mu> In-Reply-To: <201412170803.47595.mark.tinka@seacom.mu> 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/uLwjlWV95gbAEON_1UrYc6LilAI Cc: "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 13:27:03 -0000 Hi Mark, It is actually testing against existing LDP IPv4 implementations when the L= SR compliant to this draft sends LDP IPv6 FECs and LDP IPv6 addresses over = the LDP IPv4 session. Here is a brief summary of the issues as I described to the list this summe= r: " 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. " Regards, Mustapha. > -----Original Message----- > From: Mark Tinka [mailto:mark.tinka@seacom.mu] > Sent: Wednesday, December 17, 2014 1:04 AM > To: mpls@ietf.org > Cc: Aissaoui, Mustapha (Mustapha); ietf@ietf.org; IETF-Announce > Subject: Re: [mpls] Last Call: (Updates= to LDP for > IPv6) to Proposed Standard >=20 > On Tuesday, December 16, 2014 07:21:42 PM Aissaoui, Mustapha > (Mustapha) wrote: >=20 > > Hi Adrian and all, > > I was the one who raised the interop issues we found while testing our > > implementation of LDP IPv6 against existing and deployed > > implementations. >=20 > Mustapha, I'm curious - are testing against other LDPv6 implementations, = or LDPv4 > implementations? >=20 > Mark. From nobody Wed Dec 17 12:08: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 BDEF21A86F7 for ; Wed, 17 Dec 2014 12:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITyPv1fFNJOl for ; Wed, 17 Dec 2014 12:08:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9021A6FF0 for ; Wed, 17 Dec 2014 12:08:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EAB02181CD8; Wed, 17 Dec 2014 12:07:49 -0800 (PST) To: ppan@hammerheadsystems.com, swallow@cisco.com, aatlas@avici.com, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141217200749.EAB02181CD8@rfc-editor.org> Date: Wed, 17 Dec 2014 12:07:49 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gruZTLE2MHuQbG0qnfdCmsnIiWk Cc: rfc-editor@rfc-editor.org, mpls@ietf.org Subject: [mpls] [Technical Errata Reported] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:08:11 -0000 The following errata report has been submitted for RFC4090, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4090&eid=4203 -------------------------------------- Type: Technical Reported by: Yakov Rekhter Section: 6 Original Text ------------- Whenever the PLR has a backup path available, the PLR MUST set the "local protection available" flag. Corrected Text -------------- Whenever the PLR has a one-to-one backup LSP or bypass tunnel available, the PLR MUST set the "local protection available" flag. Notes ----- In the case of facility-based FRR the PLR must set the "local protection available" flag if it has the bypass tunnel available. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07) -------------------------------------- Title : Fast Reroute Extensions to RSVP-TE for LSP Tunnels Publication Date : May 2005 Author(s) : P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Dec 17 12:17: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 720151A874E; Wed, 17 Dec 2014 12:17:51 -0800 (PST) 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 Bo8zjiPrKVYe; Wed, 17 Dec 2014 12:17:49 -0800 (PST) Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB591A86F7; Wed, 17 Dec 2014 12:17:49 -0800 (PST) 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 1Y1L2U-0001Lb-L8; Wed, 17 Dec 2014 22:17:42 +0200 From: Mark Tinka Organization: SEACOM To: "Aissaoui, Mustapha (Mustapha)" Date: Wed, 17 Dec 2014 22:17:38 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412170803.47595.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C2515@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C2515@US70UWXCHMBA04.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2135838.YQI8hhhvAA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201412172217.41962.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4nA-A-gNTeyKV6eFBRmR6Jb0a60 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: 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, 17 Dec 2014 20:17:51 -0000 --nextPart2135838.YQI8hhhvAA Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday, December 17, 2014 03:26:54 PM Aissaoui,=20 Mustapha (Mustapha) wrote: > It is actually testing against existing LDP IPv4 > implementations when the LSR compliant to this draft > sends LDP IPv6 FECs and LDP IPv6 addresses over the LDP > IPv4 session. >=20 > Here is a brief summary of the issues as I described to > the list this summer: " > 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 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. " Thanks for the explanation, Mustapha. Operationally, sounds a bit like IS-IS in a mixed single and=20 dual stack environment, but with IS-IS running in ST (Single=20 Topology) mode. Of course, the IS-IS solution is to support MT (Multi- Topology) so that adjacencies between a single stack and=20 dual stack device work just fine. I realize I'm simplifying things a bit, but not sure if we=20 can borrow a leaf from the IS-IS solution, if we are going=20 to implement an integrated LDPv4/LDPv6 in the same code=20 base. One more question - are you implying that this issue is not=20 present in a point-to-point topology? Mark. --nextPart2135838.YQI8hhhvAA 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) iQIcBAABAgAGBQJUkeTlAAoJEGcZuYTeKm+Gc7UP/2P4k3snsHvIU9GZ7G/z1q1g hlC0sMklkRcJEuSqL5pjm+lLU/7JrkLabaIVVWUBOa9dLRExdfZ/N73h71S6DxwU YhGM4qDLUXQUtqmc0Ijcbfsecia5NS/gJFxbb6rNXEeahNsdtWsyo/9cCt8yJ2qA cNAUVbh9XNhcbNRN4sl8EXpOeHoRtQYL8pHefLym1f2g8dFwVq5weyxDFg8WAb/T drCHw0ddrE4Yrl6X9dCz9hGw6lobzwBKUrbg8y9AI+Cw8KZ/n7VwCX6mQ91HTYHQ 1S2y3ei/qvSQnz6zoK5omr/vvpaft0OxHVVmsLIwS7qp/zSCeS71wS3bLo/4B8qW pw1y4vco5asgHed3iAoHxtB5yWBfQOxW2sxXzxX7LP9Tx42NMJK8C9w3x5QROR2F bw5Yyk3dN0qNrgHf83FW9QeEL9wM3ao6pbauaLQwNjiEVwAg2KYaN8s0y43U34sI l64a6O2Co/8ibjT2cERESgyXeYWGYRgJ0DF0lBB7aJqxrHG7gBP553KgV8vAdBcB hsLnSUTxddD2O0Ngm6BsQmoK6DXDqvR6C3QNsK/8/buhNQXXwPZ2kfnArnCSmXQq GPHjyRNfii1LgXY9+aAGjn/T40Ox04xR7Xxmg+gH2PXouANG7r+A0yAFNtOn33SB LhzwctlRrxIAMuOWCiWk =zNPb -----END PGP SIGNATURE----- --nextPart2135838.YQI8hhhvAA-- From nobody Wed Dec 17 12:19: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 B9B811A1BD2 for ; Wed, 17 Dec 2014 12:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwgebkq4EDTb for ; Wed, 17 Dec 2014 12:19:36 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3027E1A8734 for ; Wed, 17 Dec 2014 12:19:36 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id i57so7376417yha.7 for ; Wed, 17 Dec 2014 12:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2DgC6CggpvcNsUWmnT//QGx81mpeB60ebQx85+5UGas=; b=qeUC+Y6CK3Zpm/eF51AxagSC+mEunMGvuy6OYqohE0tI++qJCHs33M3PnIVve3yFzt cadic5cDgzR85NUwNXOAgbi5ogp6XTUV40R6PEDWaBtRLi6+W9mQjmnOQTfoTb7lOTHd uHCi9jFYDc7MyY2Zg83yjxGvUxIJ7HyXKB8FZSsCcCRlVBUUtiKI0x9Hem1F3akJ3Hxe 2ODeRuUuDtfFFDgUuyDpznTSmlqW9isi0573Iez42vtstKvuwk/ALGnSH7kj3Nt6VLCz 8Us0uT6N6rXbWRyjV4jKWza0pq6DVtabU+Sh0DpVnoDR56LHFEBx6q0kg5jzeSflUMAZ xAVw== MIME-Version: 1.0 X-Received: by 10.170.134.72 with SMTP id a69mr36493331ykc.103.1418847573489; Wed, 17 Dec 2014 12:19:33 -0800 (PST) Received: by 10.170.136.132 with HTTP; Wed, 17 Dec 2014 12:19:33 -0800 (PST) In-Reply-To: <20141217200749.EAB02181CD8@rfc-editor.org> References: <20141217200749.EAB02181CD8@rfc-editor.org> Date: Wed, 17 Dec 2014 15:19:33 -0500 Message-ID: From: Alia Atlas To: Yakov Rekhter Content-Type: multipart/alternative; boundary=001a11397a2c9bda6e050a6f31ae Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4DbtaVxN7iwlH4yffykzarP2c-g Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] [Technical Errata Reported] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:19:38 -0000 --001a11397a2c9bda6e050a6f31ae Content-Type: text/plain; charset=UTF-8 Hi Yakov, Could you clarify your point for this errata? In RFC 4090, in the terminology it says: " Backup Path: The LSP that is responsible for backing up one protected LSP. A backup path refers to either a detour LSP or a backup tunnel. Backup Tunnel: The LSP that is used to backup up one of the many LSPs in many-to-one backup." Thanks, Alia On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC4090, > "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4090&eid=4203 > > -------------------------------------- > Type: Technical > Reported by: Yakov Rekhter > > Section: 6 > > Original Text > ------------- > Whenever the PLR has a backup path available, the PLR MUST set > the "local protection available" flag. > > > Corrected Text > -------------- > Whenever the PLR has a one-to-one backup LSP or bypass tunnel > available, the PLR MUST set the "local protection available" flag. > > > Notes > ----- > In the case of facility-based FRR the PLR must set the "local protection > available" flag if it has the bypass tunnel available. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07) > -------------------------------------- > Title : Fast Reroute Extensions to RSVP-TE for LSP Tunnels > Publication Date : May 2005 > Author(s) : P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed. > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > > --001a11397a2c9bda6e050a6f31ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yakov,

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

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

Thanks,
A= lia

On= Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System <rfc-editor@rfc-e= ditor.org> wrote:
The foll= owing errata report has been submitted for RFC4090,
"Fast Reroute Extensions to RSVP-TE for LSP Tunnels".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D4090&eid=3D4203

--------------------------------------
Type: Technical
Reported by: Yakov Rekhter <yakov@j= uniper.net>

Section: 6

Original Text
-------------
Whenever the PLR has a backup path available, the PLR MUST set
the "local protection available" flag.


Corrected Text
--------------
Whenever the PLR has a one-to-one backup LSP or bypass tunnel
available, the PLR MUST set the "local protection available" flag= .


Notes
-----
In the case of facility-based FRR the PLR must set the "local protecti= on available" flag if it has the bypass tunnel available.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Fast Reroute = Extensions to RSVP-TE for LSP Tunnels
Publication Date=C2=A0 =C2=A0 : May 2005
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: P. Pan, Ed., G. Swallow= , Ed., A. Atlas, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Multiprotocol Labe= l Switching
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Routing
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG


--001a11397a2c9bda6e050a6f31ae-- From nobody Wed Dec 17 13:06: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 25ACD1A903B for ; Wed, 17 Dec 2014 13:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_PLEASE=2.3, 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 V6j1nHtWq8pI for ; Wed, 17 Dec 2014 13:05:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BC21A877C for ; Wed, 17 Dec 2014 13:05:54 -0800 (PST) Received: from CO2PR05CA051.namprd05.prod.outlook.com (10.141.241.179) by DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 17 Dec 2014 21:05:31 +0000 Received: from BL2FFO11FD030.protection.gbl (2a01:111:f400:7c09::104) by CO2PR05CA051.outlook.office365.com (2a01:111:e400:1429::51) with Microsoft SMTP Server (TLS) id 15.1.36.23 via Frontend Transport; Wed, 17 Dec 2014 21:05:30 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD030.mail.protection.outlook.com (10.173.161.40) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Wed, 17 Dec 2014 21:05:30 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 17 Dec 2014 13:05:29 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sBHL52u19645; Wed, 17 Dec 2014 13:05:02 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201412172105.sBHL52u19645@magenta.juniper.net> To: Alia Atlas In-Reply-To: References: <20141217200749.EAB02181CD8@rfc-editor.org> X-MH-In-Reply-To: Alia Atlas message dated "Wed, 17 Dec 2014 15:19:33 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <58853.1418850301.1@juniper.net> Date: Wed, 17 Dec 2014 13:05:01 -0800 From: Yakov Rekhter X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(51704005)(189002)(199003)(377454003)(164054003)(24454002)(37854004)(97756001)(4396001)(1411001)(15188155005)(110136001)(46102003)(16796002)(19617315012)(16799955002)(87936001)(47776003)(69596002)(54356999)(77096005)(15975445007)(50986999)(68736005)(46406003)(64706001)(31966008)(20776003)(81156004)(99396003)(84676001)(21056001)(120916001)(107046002)(19580395003)(106466001)(23726002)(50466002)(97736003)(512874002)(62966003)(77156002)(575784001)(19580405001)(2950100001)(76176999)(105596002)(86362001)(6806004)(92566001)(299355004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB445; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR05MB445; X-Forefront-PRVS: 042857DBB5 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/pSIvKi8fy0H3Dn2xpt_BXyk8_k8 Cc: "mpls@ietf.org" , Ross Callon Subject: Re: [mpls] [Technical Errata Reported] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 21:05:58 -0000 Alia, > Hi Yakov, > > Could you clarify your point for this errata? In RFC 4090, in the > terminology it says: > "Backup Path: The LSP that is responsible for backing up one > protected LSP. A backup path refers to either a > detour LSP or a backup tunnel. > > Backup Tunnel: The LSP that is used to backup up one of the many > LSPs in many-to-one backup." In the terminology it also says: "Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility." My point is that (unless the term "bypass tunnel" means the same as "backup path" or "backup tunnel") in many-to-one backup the "local protection available" flag for a given protected LSP MUST be set when the PLR has a *bypass* tunnel for that LSP. Yakov. > Thanks, > Alia > > On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > > > The following errata report has been submitted for RFC4090, > > "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4090&eid=4203 > > > > -------------------------------------- > > Type: Technical > > Reported by: Yakov Rekhter > > > > Section: 6 > > > > Original Text > > ------------- > > Whenever the PLR has a backup path available, the PLR MUST set > > the "local protection available" flag. > > > > > > Corrected Text > > -------------- > > Whenever the PLR has a one-to-one backup LSP or bypass tunnel > > available, the PLR MUST set the "local protection available" flag. > > > > > > Notes > > ----- > > In the case of facility-based FRR the PLR must set the "local protection > > available" flag if it has the bypass tunnel available. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07) > > -------------------------------------- > > Title : Fast Reroute Extensions to RSVP-TE for LSP Tunnels > > Publication Date : May 2005 > > Author(s) : P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed. > > Category : PROPOSED STANDARD > > Source : Multiprotocol Label Switching > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > > > > > --001a11397a2c9bda6e050a6f31ae > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > >
Hi Yakov,

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

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

Thanks,
A= > lia

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

> > --001a11397a2c9bda6e050a6f31ae-- From nobody Wed Dec 17 13:23: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 070361A871C for ; Wed, 17 Dec 2014 13:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_PLEASE=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dMlZ8j7zIAq for ; Wed, 17 Dec 2014 13:23:31 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB531A1BCB for ; Wed, 17 Dec 2014 13:23:29 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id i57so7511049yha.12 for ; Wed, 17 Dec 2014 13:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GY1LVr1KAxjpYoTgz+NeDBFFOlBW7uwrMFGpbaM+wRs=; b=Hi+N63JRYzDGlX0h7we2FBgkRB9S36PqUGTefZ+HaOmyqXdDPRjnToSnqgSD1zctSA 0vt4R2frUV1hhCtiScqq419b5Z0xxTtvXcCL5sExvYojQuSprWjB83ELkHWT4CAuPE+H fuTw+kHKaX27llW05ABaR/KreMp2O3x3UHiJGXJYtMNixHDrRW3yrFj0euDmbzXlDJzy myLiGz6bVs8onMAhzBs/OiJlKCgwrFsu6nXnxu4LI1GQNhlAuUTlKDc9/X64zVMZghZU k4g19tTOls8pGofP5OqPZbL6Vu05JpodC2IeQOnuzs1t/JgPQq+IqrhW5r78jolaKJ4w fFkw== MIME-Version: 1.0 X-Received: by 10.236.26.116 with SMTP id b80mr31942907yha.60.1418851409103; Wed, 17 Dec 2014 13:23:29 -0800 (PST) Received: by 10.170.136.132 with HTTP; Wed, 17 Dec 2014 13:23:29 -0800 (PST) In-Reply-To: <201412172105.sBHL52u19645@magenta.juniper.net> References: <20141217200749.EAB02181CD8@rfc-editor.org> <201412172105.sBHL52u19645@magenta.juniper.net> Date: Wed, 17 Dec 2014 16:23:29 -0500 Message-ID: From: Alia Atlas To: Yakov Rekhter Content-Type: multipart/alternative; boundary=047d7b5d99a33a914b050a70164e Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MT-CVzeDzOvyt32laz1Q6-aYRtU Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] [Technical Errata Reported] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 21:23:37 -0000 --047d7b5d99a33a914b050a70164e Content-Type: text/plain; charset=UTF-8 Yakov, On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter wrote: > Alia, > > > Hi Yakov, > > > > Could you clarify your point for this errata? In RFC 4090, in the > > terminology it says: > > "Backup Path: The LSP that is responsible for backing up one > > protected LSP. A backup path refers to either a > > detour LSP or a backup tunnel. > > > > Backup Tunnel: The LSP that is used to backup up one of the many > > LSPs in many-to-one backup." > > In the terminology it also says: > > "Bypass Tunnel: An LSP that is used to protect a set of LSPs > passing over a common facility." > > My point is that (unless the term "bypass tunnel" means the same > as "backup path" or "backup tunnel") in many-to-one backup > the "local protection available" flag for a given protected LSP > MUST be set when the PLR has a *bypass* tunnel for that LSP. > Ah - ok. A backup path that uses a bypass tunnel is not just the bypass tunnel itself. There's the state associated for the protected LSP that also needs to be created and installed. In more concrete terms, this is installing an out-segment with the appropriate label for the protected LSP to be understood by the merge point as well as an outer label for the bypass LSP. So, the text refers to a backup path instead of a bypass tunnel because having the bypass tunnel isn't quite sufficient. Does that make sense to you? Regards, Alia > Yakov. > > > Thanks, > > Alia > > > > On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System < > > rfc-editor@rfc-editor.org> wrote: > > > > > The following errata report has been submitted for RFC4090, > > > "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata_search.php?rfc=4090&eid=4203 > > > > > > -------------------------------------- > > > Type: Technical > > > Reported by: Yakov Rekhter > > > > > > Section: 6 > > > > > > Original Text > > > ------------- > > > Whenever the PLR has a backup path available, the PLR MUST set > > > the "local protection available" flag. > > > > > > > > > Corrected Text > > > -------------- > > > Whenever the PLR has a one-to-one backup LSP or bypass tunnel > > > available, the PLR MUST set the "local protection available" flag. > > > > > > > > > Notes > > > ----- > > > In the case of facility-based FRR the PLR must set the "local > protection > > > available" flag if it has the bypass tunnel available. > > > > > > Instructions: > > > ------------- > > > This erratum is currently posted as "Reported". If necessary, please > > > use "Reply All" to discuss whether it should be verified or > > > rejected. When a decision is reached, the verifying party (IESG) > > > can log in to change the status and edit the report, if necessary. > > > > > > -------------------------------------- > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07) > > > -------------------------------------- > > > Title : Fast Reroute Extensions to RSVP-TE for LSP > Tunnels > > > Publication Date : May 2005 > > > Author(s) : P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed. > > > Category : PROPOSED STANDARD > > > Source : Multiprotocol Label Switching > > > Area : Routing > > > Stream : IETF > > > Verifying Party : IESG > > > > > > > > > > --001a11397a2c9bda6e050a6f31ae > > Content-Type: text/html; charset="UTF-8" > > Content-Transfer-Encoding: quoted-printable > > > >
Hi Yakov,

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

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

Thanks,
A= > > lia

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

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

On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter <= yakov@juniper.net> wrote:
Alia,

> Hi Yakov,
>
> Could you clarify your point for this errata?=C2=A0 In RFC 4090, in th= e
> terminology it says:
>=C2=A0 "Backup Path: The LSP that is responsible for backing up on= e
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 protected LSP.=C2=A0 A backup path refers to either a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 detour LSP or a backup tunnel.
>
>=C2=A0 =C2=A0Backup Tunnel: The LSP that is used to backup up one of th= e many
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LSPs in = many-to-one backup."

In the terminology it also says:

=C2=A0 =C2=A0"Bypass Tunnel: An LSP that is used to protect a set of L= SPs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 passing over a common facility.&q= uot;

My point is that (unless the term "bypass tunnel" means the same<= br> as "backup path" or "backup tunnel") in many-to-one bac= kup
the "local protection available" flag for a given protected LSP MUST be set when the PLR has a *bypass* tunnel for that LSP.

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

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

Regards,
Alia
=C2=A0
Yakov.

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

--047d7b5d99a33a914b050a70164e-- From nobody Wed Dec 17 13:43: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 84FFF1A877C for ; Wed, 17 Dec 2014 13:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VxzydUth-8F for ; Wed, 17 Dec 2014 13:43:00 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::791]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A0C1A0163 for ; Wed, 17 Dec 2014 13:43:00 -0800 (PST) Received: from BL2PR05CA0019.namprd05.prod.outlook.com (10.255.226.19) by BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) with Microsoft SMTP Server (TLS) id 15.1.36.22; Wed, 17 Dec 2014 21:42:37 +0000 Received: from BL2FFO11FD017.protection.gbl (2a01:111:f400:7c09::134) by BL2PR05CA0019.outlook.office365.com (2a01:111:e400:c04::19) with Microsoft SMTP Server (TLS) id 15.1.36.23 via Frontend Transport; Wed, 17 Dec 2014 21:42:36 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD017.mail.protection.outlook.com (10.173.161.35) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Wed, 17 Dec 2014 21:42:35 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 17 Dec 2014 13:42:19 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sBHLfqu40272; Wed, 17 Dec 2014 13:41:52 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201412172141.sBHLfqu40272@magenta.juniper.net> To: Alia Atlas In-Reply-To: References: <20141217200749.EAB02181CD8@rfc-editor.org> <201412172105.sBHL52u19645@magenta.juniper.net> X-MH-In-Reply-To: Alia Atlas message dated "Wed, 17 Dec 2014 16:23:29 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59339.1418852512.1@juniper.net> Date: Wed, 17 Dec 2014 13:41:52 -0800 From: Yakov Rekhter X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(24454002)(199003)(37854004)(164054003)(189002)(105596002)(107046002)(93886004)(99396003)(16799955002)(87936001)(23726002)(110136001)(512874002)(15188155005)(50466002)(20776003)(46102003)(120916001)(47776003)(76176999)(21056001)(16601075003)(64706001)(54356999)(1411001)(2950100001)(97736003)(31966008)(16796002)(4396001)(68736005)(77096005)(69596002)(19580405001)(19580395003)(6806004)(84676001)(81156004)(15975445007)(106466001)(19617315012)(575784001)(92566001)(50986999)(77156002)(62966003)(86362001)(97756001)(46406003)(299355004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB433; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB433; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB433; X-Forefront-PRVS: 042857DBB5 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB433; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2014 21:42:35.9623 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB433 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/k71egi4HFslYOtYVYuLAECHqRsM Cc: "mpls@ietf.org" , Ross Callon Subject: Re: [mpls] [Technical Errata Reported] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 21:43:05 -0000 Alia, > Yakov, > > On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter wrote: > > > Alia, > > > > > Hi Yakov, > > > > > > Could you clarify your point for this errata? In RFC 4090, in the > > > terminology it says: > > > "Backup Path: The LSP that is responsible for backing up one > > > protected LSP. A backup path refers to either a > > > detour LSP or a backup tunnel. > > > > > > Backup Tunnel: The LSP that is used to backup up one of the many > > > LSPs in many-to-one backup." > > > > In the terminology it also says: > > > > "Bypass Tunnel: An LSP that is used to protect a set of LSPs > > passing over a common facility." > > > > My point is that (unless the term "bypass tunnel" means the same > > as "backup path" or "backup tunnel") in many-to-one backup > > the "local protection available" flag for a given protected LSP > > MUST be set when the PLR has a *bypass* tunnel for that LSP. > > > > Ah - ok. A backup path that uses a bypass tunnel is not just the bypass > tunnel itself. Correct. > There's the state associated for the protected LSP that > also needs to be created and installed. In more concrete terms, this > is installing an out-segment with the appropriate label for the protected > LSP to be understood by the merge point as > well as an outer label for the bypass LSP. > > So, the text refers to a backup path instead of a bypass tunnel because > having the bypass tunnel isn't quite sufficient. > Does that make sense to you? The current text is incorrect. This is because a PLR may signal a backup path at the time of failure. Yet, one should not wait for the failure to set the "local protection available" flag. The PLR should set this flag as soon as it has a *bypass* tunnel. Yakov. > > Regards, > Alia > > > > Yakov. > > > > > Thanks, > > > Alia > > > > > > On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System < > > > rfc-editor@rfc-editor.org> wrote: > > > > > > > The following errata report has been submitted for RFC4090, > > > > "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > http://www.rfc-editor.org/errata_search.php?rfc=4090&eid=4203 > > > > > > > > -------------------------------------- > > > > Type: Technical > > > > Reported by: Yakov Rekhter > > > > > > > > Section: 6 > > > > > > > > Original Text > > > > ------------- > > > > Whenever the PLR has a backup path available, the PLR MUST set > > > > the "local protection available" flag. > > > > > > > > > > > > Corrected Text > > > > -------------- > > > > Whenever the PLR has a one-to-one backup LSP or bypass tunnel > > > > available, the PLR MUST set the "local protection available" flag. > > > > > > > > > > > > Notes > > > > ----- > > > > In the case of facility-based FRR the PLR must set the "local > > protection > > > > available" flag if it has the bypass tunnel available. > > > > > > > > Instructions: > > > > ------------- > > > > This erratum is currently posted as "Reported". If necessary, please > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. When a decision is reached, the verifying party (IESG) > > > > can log in to change the status and edit the report, if necessary. > > > > > > > > -------------------------------------- > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07) > > > > -------------------------------------- > > > > Title : Fast Reroute Extensions to RSVP-TE for LSP > > Tunnels > > > > Publication Date : May 2005 > > > > Author(s) : P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed. > > > > Category : PROPOSED STANDARD > > > > Source : Multiprotocol Label Switching > > > > Area : Routing > > > > Stream : IETF > > > > Verifying Party : IESG > > > > > > > > > > > > > > --001a11397a2c9bda6e050a6f31ae > > > Content-Type: text/html; charset="UTF-8" > > > Content-Transfer-Encoding: quoted-printable > > > > > >
Hi Yakov,

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

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

Thanks,
A= > > > lia

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

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

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

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

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

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

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

> > --047d7b5d99a33a914b050a70164e-- From nobody Wed Dec 17 13: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 0ED601A7021 for ; Wed, 17 Dec 2014 13:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXJFokF4r2FQ for ; Wed, 17 Dec 2014 13:46:29 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C21D1A877C for ; Wed, 17 Dec 2014 13:46:26 -0800 (PST) Received: by mail-yh0-f50.google.com with SMTP id 29so8111581yhl.9 for ; Wed, 17 Dec 2014 13:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EpGgkk3a3EvR1bFNa1xk0KfRa3uqY1CTjEVPqYprPIg=; b=WAQwst0DQhb8pLjPpLVQqP/hPm36hZ9ke6OrHHBPU3gx4cC0N7CsIokrMfOABjKuxq VDCrWaugqm+hvHZ7KVNNSv3+74K7MNBjsm35hN9P0wUIkA4GYEBtKwIWAcQnSq2CEIXs S118DyCmhkx+f92SEvABXQ25PaPTmQLeguUjgwHpmfr40pIwfKG77n7IpWw3KvzsTOcD tghGCllbLe/5Eer1hHc9Q7SyWO3f9OfCm1UX1JhkMVw2rDo06yoF7l0M0LBJOnMKplvY 30SiBZmy6gkuGGWiNcLcmaybo6j2ia5t3Us82Y7qSWPBCkETOblwhhHAPSNUQnsrX2iI Basw== MIME-Version: 1.0 X-Received: by 10.236.223.198 with SMTP id v66mr33144225yhp.38.1418852785255; Wed, 17 Dec 2014 13:46:25 -0800 (PST) Received: by 10.170.136.132 with HTTP; Wed, 17 Dec 2014 13:46:25 -0800 (PST) In-Reply-To: <201412172141.sBHLfqu40272@magenta.juniper.net> References: <20141217200749.EAB02181CD8@rfc-editor.org> <201412172105.sBHL52u19645@magenta.juniper.net> <201412172141.sBHLfqu40272@magenta.juniper.net> Date: Wed, 17 Dec 2014 16:46:25 -0500 Message-ID: From: Alia Atlas To: Yakov Rekhter Content-Type: multipart/alternative; boundary=001a11c1e9ee40fd19050a7068c9 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QgNWN_olV9WaT17VuBpCnYYWAS0 Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] [Technical Errata Reported] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 21:46:36 -0000 --001a11c1e9ee40fd19050a7068c9 Content-Type: text/plain; charset=UTF-8 Yakov, On Wed, Dec 17, 2014 at 4:41 PM, Yakov Rekhter wrote: > Alia, > > > Yakov, > > > > On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter > wrote: > > > > > Alia, > > > > > > > Hi Yakov, > > > > > > > > Could you clarify your point for this errata? In RFC 4090, in the > > > > terminology it says: > > > > "Backup Path: The LSP that is responsible for backing up one > > > > protected LSP. A backup path refers to > either a > > > > detour LSP or a backup tunnel. > > > > > > > > Backup Tunnel: The LSP that is used to backup up one of the many > > > > LSPs in many-to-one backup." > > > > > > In the terminology it also says: > > > > > > "Bypass Tunnel: An LSP that is used to protect a set of LSPs > > > passing over a common facility." > > > > > > My point is that (unless the term "bypass tunnel" means the same > > > as "backup path" or "backup tunnel") in many-to-one backup > > > the "local protection available" flag for a given protected LSP > > > MUST be set when the PLR has a *bypass* tunnel for that LSP. > > > > > > > Ah - ok. A backup path that uses a bypass tunnel is not just the bypass > > tunnel itself. > > Correct. > > > There's the state associated for the protected LSP that > > also needs to be created and installed. In more concrete terms, this > > is installing an out-segment with the appropriate label for the protected > > LSP to be understood by the merge point as > > well as an outer label for the bypass LSP. > > > > So, the text refers to a backup path instead of a bypass tunnel because > > having the bypass tunnel isn't quite sufficient. > > Does that make sense to you? > > The current text is incorrect. This is because a PLR may signal a > backup path at the time of failure. Yet, one should not wait for > the failure to set the "local protection available" flag. The PLR > should set this flag as soon as it has a *bypass* tunnel. > The backup path is created by the PLR before the failure and thus, before the associated signaling. Once the PLR has done the work to create a backup path using an existing bypass tunnel - which is internal work - then the PLR should set the "local protection available" flag. Alia > Yakov. > > > > > Regards, > > Alia > > > > > > > Yakov. > > > > > > > Thanks, > > > > Alia > > > > > > > > On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System < > > > > rfc-editor@rfc-editor.org> wrote: > > > > > > > > > The following errata report has been submitted for RFC4090, > > > > > "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > http://www.rfc-editor.org/errata_search.php?rfc=4090&eid=4203 > > > > > > > > > > -------------------------------------- > > > > > Type: Technical > > > > > Reported by: Yakov Rekhter > > > > > > > > > > Section: 6 > > > > > > > > > > Original Text > > > > > ------------- > > > > > Whenever the PLR has a backup path available, the PLR MUST set > > > > > the "local protection available" flag. > > > > > > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > Whenever the PLR has a one-to-one backup LSP or bypass tunnel > > > > > available, the PLR MUST set the "local protection available" flag. > > > > > > > > > > > > > > > Notes > > > > > ----- > > > > > In the case of facility-based FRR the PLR must set the "local > > > protection > > > > > available" flag if it has the bypass tunnel available. > > > > > > > > > > Instructions: > > > > > ------------- > > > > > This erratum is currently posted as "Reported". If necessary, > please > > > > > use "Reply All" to discuss whether it should be verified or > > > > > rejected. When a decision is reached, the verifying party (IESG) > > > > > can log in to change the status and edit the report, if necessary. > > > > > > > > > > -------------------------------------- > > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07) > > > > > -------------------------------------- > > > > > Title : Fast Reroute Extensions to RSVP-TE for LSP > > > Tunnels > > > > > Publication Date : May 2005 > > > > > Author(s) : P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed. > > > > > Category : PROPOSED STANDARD > > > > > Source : Multiprotocol Label Switching > > > > > Area : Routing > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > > > > > > > > > > > > > > --001a11397a2c9bda6e050a6f31ae > > > > Content-Type: text/html; charset="UTF-8" > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > >
Hi Yakov,

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

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

Thanks,
A= > > > > lia

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

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

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

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

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

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

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

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

On Wed, Dec 17, 2014 at 4:41 PM, Yakov Rekhter <= yakov@juniper.net> wrote:
Alia,

> Yakov,
>
> On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter <yakov@juniper.net> wrote:
>
> > Alia,
> >
> > > Hi Yakov,
> > >
> > > Could you clarify your point for this errata?=C2=A0 In RFC 4= 090, in the
> > > terminology it says:
> > >=C2=A0 "Backup Path: The LSP that is responsible for bac= king up one
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 protected LSP.=C2=A0 A backup path refers to eithe= r a
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 detour LSP or a backup tunnel.
> > >
> > >=C2=A0 =C2=A0Backup Tunnel: The LSP that is used to backup up= one of the many
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 LSPs in many-to-one backup."
> >
> > In the terminology it also says:
> >
> >=C2=A0 =C2=A0 "Bypass Tunnel: An LSP that is used to protect = a set of LSPs
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0passing over a com= mon facility."
> >
> > My point is that (unless the term "bypass tunnel" means= the same
> > as "backup path" or "backup tunnel") in many-= to-one backup
> > the "local protection available" flag for a given prote= cted LSP
> > MUST be set when the PLR has a *bypass* tunnel for that LSP.
> >
>
> Ah - ok.=C2=A0 A backup path that uses a bypass tunnel is not just the= bypass
> tunnel itself.

Correct.

> There's the state associated for the protected LSP that
> also needs to be created and installed.=C2=A0 In more concrete terms, = this
> is installing an out-segment with the appropriate label for the protec= ted
> LSP to be understood by the merge point as
> well as an outer label for the bypass LSP.
>
> So, the text refers to a backup path instead of a bypass tunnel becaus= e
> having the bypass tunnel isn't quite sufficient.
> Does that make sense to you?

The current text is incorrect. This is because a PLR may signal a backup path at the time of failure. Yet, one should not wait for
the failure to set the "local protection available" flag. The PLR=
should set this flag as soon as it has a *bypass* tunnel.
<= div>
The backup path is created by the PLR before the failure= and thus, before the
associated signaling.=C2=A0 Once the PLR ha= s done the work to create a backup path using
an existing bypass = tunnel - which is internal work - then the PLR should set
the &qu= ot;local protection available" flag. =C2=A0

A= lia=C2=A0

=C2=A0
Yakov.

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

--001a11c1e9ee40fd19050a7068c9-- From nobody Wed Dec 17 18:12: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 AD98B1A0021 for ; Wed, 17 Dec 2014 18:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMvaXwmpDpVM for ; Wed, 17 Dec 2014 18:12:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EA01A007C for ; Wed, 17 Dec 2014 18:12:04 -0800 (PST) Received: from BY2PR05CA040.namprd05.prod.outlook.com (10.141.250.30) by DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 18 Dec 2014 02:11:40 +0000 Received: from BN1BFFO11FD024.protection.gbl (2a01:111:f400:7c10::1:173) by BY2PR05CA040.outlook.office365.com (2a01:111:e400:2c5f::30) with Microsoft SMTP Server (TLS) id 15.1.36.23 via Frontend Transport; Thu, 18 Dec 2014 02:11:40 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD024.mail.protection.outlook.com (10.58.144.87) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Thu, 18 Dec 2014 02:11:39 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 17 Dec 2014 18:11:38 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sBI2BBW53068; Wed, 17 Dec 2014 18:11:11 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201412180211.sBI2BBW53068@magenta.juniper.net> To: Alia Atlas In-Reply-To: References: <20141217200749.EAB02181CD8@rfc-editor.org> <201412172105.sBHL52u19645@magenta.juniper.net> <201412172141.sBHLfqu40272@magenta.juniper.net> X-MH-In-Reply-To: Alia Atlas message dated "Wed, 17 Dec 2014 16:46:25 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64323.1418868671.1@juniper.net> Date: Wed, 17 Dec 2014 18:11:11 -0800 From: Yakov Rekhter X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(199003)(37854004)(24454002)(51704005)(189002)(106466001)(23726002)(50466002)(19580405001)(120916001)(107046002)(19580395003)(21056001)(105596002)(76176999)(2950100001)(575784001)(92566001)(6806004)(86362001)(512874002)(62966003)(97736003)(77156002)(15974865002)(15188155005)(110136001)(19617315012)(46102003)(87936001)(47776003)(16799955002)(1411001)(97756001)(4396001)(16796002)(93886004)(16601075003)(99396003)(84676001)(81156004)(15975445007)(77096005)(54356999)(69596002)(64706001)(15395725005)(50986999)(31966008)(20776003)(46406003)(68736005)(579004)(559001)(299355004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB445; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR05MB445; X-Forefront-PRVS: 042957ACD7 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/g-zjgQI7JleCCxErl_GnXADyoTM Cc: "mpls@ietf.org" , Ross Callon Subject: Re: [mpls] [Technical Errata Reported] RFC4090 (4203) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 02:12:14 -0000 Alia, > > Alia, > > > > > Yakov, > > > > > > On Wed, Dec 17, 2014 at 4:05 PM, Yakov Rekhter > > wrote: > > > > > > > Alia, > > > > > > > > > Hi Yakov, > > > > > > > > > > Could you clarify your point for this errata? In RFC 4090, in the > > > > > terminology it says: > > > > > "Backup Path: The LSP that is responsible for backing up one > > > > > protected LSP. A backup path refers to > > > > > either a detour LSP or a backup tunnel. > > > > > > > > > > Backup Tunnel: The LSP that is used to backup up one of the many > > > > > LSPs in many-to-one backup." > > > > > > > > In the terminology it also says: > > > > > > > > "Bypass Tunnel: An LSP that is used to protect a set of LSPs > > > > passing over a common facility." > > > > > > > > My point is that (unless the term "bypass tunnel" means the same > > > > as "backup path" or "backup tunnel") in many-to-one backup > > > > the "local protection available" flag for a given protected LSP > > > > MUST be set when the PLR has a *bypass* tunnel for that LSP. > > > > > > > > > > Ah - ok. A backup path that uses a bypass tunnel is not just the bypass > > > tunnel itself. > > > > Correct. > > > > > There's the state associated for the protected LSP that > > > also needs to be created and installed. In more concrete terms, this > > > is installing an out-segment with the appropriate label for the protected > > > LSP to be understood by the merge point as > > > well as an outer label for the bypass LSP. > > > > > > So, the text refers to a backup path instead of a bypass tunnel because > > > having the bypass tunnel isn't quite sufficient. > > > Does that make sense to you? > > > > The current text is incorrect. This is because a PLR may signal a > > backup path at the time of failure. Yet, one should not wait for > > the failure to set the "local protection available" flag. The PLR > > should set this flag as soon as it has a *bypass* tunnel. > > The backup path is created by the PLR before the failure and thus, before > the associated signaling. Once the PLR has done the work to create > a backup path using an existing bypass tunnel - which is internal > work - then the PLR should set the "local protection available" flag. Perhaps we should step back and ask whether the quote from section 6: Whenever the PLR has a backup path available, the PLR MUST set the "local protection available" flag. talks about forwarding state or control plane state. Is there any text in rfc4090 that answers this question ? Yakov. > > Alia > > > > > Yakov. > > > > > > > > Regards, > > > Alia > > > > > > > > > > Yakov. > > > > > > > > > Thanks, > > > > > Alia > > > > > > > > > > On Wed, Dec 17, 2014 at 3:07 PM, RFC Errata System < > > > > > rfc-editor@rfc-editor.org> wrote: > > > > > > > > > > > The following errata report has been submitted for RFC4090, > > > > > > "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". > > > > > > > > > > > > -------------------------------------- > > > > > > You may review the report below and at: > > > > > > http://www.rfc-editor.org/errata_search.php?rfc=4090&eid=4203 > > > > > > > > > > > > -------------------------------------- > > > > > > Type: Technical > > > > > > Reported by: Yakov Rekhter > > > > > > > > > > > > Section: 6 > > > > > > > > > > > > Original Text > > > > > > ------------- > > > > > > Whenever the PLR has a backup path available, the PLR MUST set > > > > > > the "local protection available" flag. > > > > > > > > > > > > > > > > > > Corrected Text > > > > > > -------------- > > > > > > Whenever the PLR has a one-to-one backup LSP or bypass tunnel > > > > > > available, the PLR MUST set the "local protection available" flag. > > > > > > > > > > > > > > > > > > Notes > > > > > > ----- > > > > > > In the case of facility-based FRR the PLR must set the "local > > > > protection > > > > > > available" flag if it has the bypass tunnel available. > > > > > > > > > > > > Instructions: > > > > > > ------------- > > > > > > This erratum is currently posted as "Reported". If necessary, > > please > > > > > > use "Reply All" to discuss whether it should be verified or > > > > > > rejected. When a decision is reached, the verifying party (IESG) > > > > > > can log in to change the status and edit the report, if necessary. > > > > > > > > > > > > -------------------------------------- > > > > > > RFC4090 (draft-ietf-mpls-rsvp-lsp-fastreroute-07) > > > > > > -------------------------------------- > > > > > > Title : Fast Reroute Extensions to RSVP-TE for LSP > > > > Tunnels > > > > > > Publication Date : May 2005 > > > > > > Author(s) : P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed. > > > > > > Category : PROPOSED STANDARD > > > > > > Source : Multiprotocol Label Switching > > > > > > Area : Routing > > > > > > Stream : IETF > > > > > > Verifying Party : IESG > > > > > > > > > > > > > > > > > > > > > > --001a11397a2c9bda6e050a6f31ae > > > > > Content-Type: text/html; charset="UTF-8" > > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > >
Hi Yakov,

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

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

Thanks,
A= > > > > > lia

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

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

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

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

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

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

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

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

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

A= > lia=C2=A0

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

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

> > --001a11c1e9ee40fd19050a7068c9-- From nobody Thu Dec 18 05:21: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 D79491A88EB for ; Thu, 18 Dec 2014 05:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE9IUdBL16K4 for ; Thu, 18 Dec 2014 05:21:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820041A88CB for ; Thu, 18 Dec 2014 05:21:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQF45992; Thu, 18 Dec 2014 13:21:27 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 18 Dec 2014 13:21:26 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 18 Dec 2014 21:21:21 +0800 From: Qin Wu To: Loa Andersson , "mpls@ietf.org" Thread-Topic: Notification: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPXnSfB0jsxaG0mJCejjdniUXZyVVyhw Date: Thu, 18 Dec 2014 13:21:20 +0000 Message-ID: References: <548FC870.3090901@pi.nu> <548FCAEE.3000007@pi.nu> In-Reply-To: <548FCAEE.3000007@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] 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/rxIrk6H5VSFnQ4s6PKMpE_KBing Subject: Re: [mpls] Notification: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 13:21:32 -0000 Support since I believe this draft provides an important technology (MRT-FR= R) needed in the IP/LDP deployment. Regards! -Qin -------- Original Message -------- Subject: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-= ldp-mrt Date: Tue, 16 Dec 2014 13:51:44 +0800 From: Loa Andersson To: mpls@ietf.org CC: mpls-chairs@tools.ietf.org , draft-atlas-mp= ls-ldp-mrt@tools.ietf.org Working Group, This is to start a two week poll on adopting draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group 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 no IPR disclosures directly against this document. An IPR poll wil= l be done in parallel to the adoption poll, and the adoption poll will not = be closed before we have responses from all authors. If you are on the the mpls working group mailing list and aware of IPR that= relates to this draft, you should respond to the IPR poll. This poll ends January 2, 2015. /Loa --=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 _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From nobody Thu Dec 18 06:00: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 908821A89B9 for ; Thu, 18 Dec 2014 06:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 061Ghlk3qoGf for ; Thu, 18 Dec 2014 06:00:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9B01A8955 for ; Thu, 18 Dec 2014 06:00:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNB37656; Thu, 18 Dec 2014 14:00:47 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 18 Dec 2014 14:00:46 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.46]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 18 Dec 2014 22:00:41 +0800 From: Lizhenbin To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Thread-Index: AQHQGPRvP2/MlwWTFUysC9z6iOtAbpyVYsqi Date: Thu, 18 Dec 2014 14:00:40 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D2C6A24E9@nkgeml506-mbx.china.huawei.com> References: <548FC870.3090901@pi.nu> In-Reply-To: <548FC870.3090901@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.170.86] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/PPhjZxGqTjLbKKrnpVvaLOEZKbg Cc: "mpls-chairs@tools.ietf.org" , "draft-atlas-mpls-ldp-mrt@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgY29u?= =?gb2312?b?c2Vuc3VzIHRvIGFkb3B0CWRyYWZ0LWF0bGFzLW1wbHMtbGRwLW1ydA==?= 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, 18 Dec 2014 14:00:51 -0000 SGkgTG9hLA0KSSBTdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGUgZHJhZnQuIFdlIHRoaW5rIHRo ZSBjb21iaW5hdGlvbiBvZiBNUlQgYW5kIExEUCBNVCBjYW4gc29sdmUgdGhlIGlzc3VlIG9uIElQ L0xEUCBGUlIgdmVyeSB3ZWxsLiBJdCB3aWxsIGRvIGdyZWF0IGhlbHAgdG8gdGhlIGhpZ2ggYXZp bGFiaWxpdHkgb2YgSVAvTERQIG5ldHdvcmsgd2hpY2ggYWxyZWFkeSBoYXZlIHRoZSBhZHZhbnRh Z2UgaW4gc2NhbGFiaWxpdHkuDQoNCg0KUmVnYXJkcywNClJvYmluDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IG1wbHMgW21wbHMtYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBMb2EgQW5kZXJzc29uIFtsb2FAcGkubnVdDQq3osvNyrG85DogMjAx NMTqMTLUwjE2yNUgMTM6NTENCsrVvP7IyzogbXBsc0BpZXRmLm9yZw0Ks63LzTogbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWF0bGFzLW1wbHMtbGRwLW1ydEB0b29scy5pZXRmLm9y Zw0K1vfM4jogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgY29uc2Vuc3VzIHRvIGFkb3B0 ICAgIGRyYWZ0LWF0bGFzLW1wbHMtbGRwLW1ydA0KDQpXb3JraW5nIEdyb3VwLA0KDQpUaGlzIGlz IHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBhZG9wdGluZw0KZHJhZnQtYXRsYXMtbXBscy1s ZHAtbXJ0LTAzIGFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4NCg0KUGxlYXNlIHNl bmQgeW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMgd29ya2lu Zw0KZ3JvdXAgbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnKS4gUGxlYXNlIGdpdmUgYSB0ZWNo bmljYWwNCm1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxs eSBpZiB5b3UgdGhpbmsgdGhhdA0KdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBh cyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNClRoZXJlIGlzIG5vIElQUiBkaXNjbG9zdXJl cyBkaXJlY3RseSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuIEFuIElQUg0KcG9sbCB3aWxsIGJlIGRv bmUgaW4gcGFyYWxsZWwgdG8gdGhlIGFkb3B0aW9uIHBvbGwsIGFuZCB0aGUgYWRvcHRpb24NCnBv bGwgd2lsbCBub3QgYmUgY2xvc2VkIGJlZm9yZSB3ZSBoYXZlIHJlc3BvbnNlcyBmcm9tIGFsbCBh dXRob3JzLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxp bmcgbGlzdCBhbmQNCmF3YXJlIG9mIElQUiB0aGF0IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdCwgeW91 IHNob3VsZCByZXNwb25kIHRvIHRoZQ0KSVBSIHBvbGwuDQoNClRoaXMgcG9sbCBlbmRzIEphbnVh cnkgMiwgMjAxNS4NCg0KL0xvYQ0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAg ICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBl cnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KSHVhd2VpIFRlY2hub2xvZ2ll cyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0K bXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz From nobody Thu Dec 18 07:38: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 BC6141A8FD6 for ; Thu, 18 Dec 2014 07:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_31=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 Rwc0cq7peYDU for ; Thu, 18 Dec 2014 07:37:44 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.104]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BF91A8BC4 for ; Thu, 18 Dec 2014 07:37:44 -0800 (PST) Received: from [216.82.253.147] by server-8.bemta-7.messagelabs.com id DA/B0-03121-7C4F2945; Thu, 18 Dec 2014 15:37:43 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-10.tower-165.messagelabs.com!1418917063!20388903!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3743 invoked from network); 18 Dec 2014 15:37:43 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-10.tower-165.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Dec 2014 15:37:43 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id 649782A7E9; Thu, 18 Dec 2014 15:37:43 +0000 (GMT) Received: from USADCWVEHT01.corp.global.level3.com (10.2.36.141) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 18 Dec 2014 08:37:43 -0700 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by usadcwveht01.corp.global.level3.com ([::1]) with mapi id 14.03.0158.001; Thu, 18 Dec 2014 10:37:42 -0500 From: "Osborne, Eric" To: "Nobo Akiya (nobo)" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAP2no76f67h7pbRmWY0LHccfco7wGir7EQARynwYA= Date: Thu, 18 Dec 2014 15:37:40 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD01107AD8@USIDCWVEMBX08.corp.global.level3.com> References: <63CB93BC589C1B4BAFDB41A0A19B7ACD01049215@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.205] 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/RvMD05v8CKMyKfcRiN0jLcQ_yhs Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 18 Dec 2014 15:37:58 -0000 Hi Nobo- I've trimmed this a bit and replied to specific comments inline with EO#.= Where there's no reply, please take that as acceptance of whatever change= s you have proposed or made. ... > > Sections 3-5: These sections could use a reorg. Starting with procedur= es for > > using new TLVs before defining the new TLVs feels awkward. I suggest > > taking sections [3,4,5] and reordering as [5,3,4]. >=20 > [NOBO] Pre-00 version originally had the document structure similar to [5= , 3, > 4], but describing the procedures prior to the new TLVs was suggested fro= m a > very long timer IETF participant. With that said, "feel awkward" is somet= hing > that I'd like to address. After the text you suggested in the next commen= t, let > me add following text. >=20 > Note that Section 5, Section 6, > Section 7 and Section 8 describe the new TLVs, and looking over those > sections first may make it easier to read this section. >=20 > Would that work? EO# Sure, that works. ... > > It would benefit from some clarifying text, perhaps something like "An = error > > case is any case where the OAM across a LAG fails, either partial or fu= lly. A > > partial failure is where some LAG member traversals behave as they shou= ld > > and some don't, and a full failure is where no LAG member traversals > > behave as they should". >=20 > [NOBO] I've taken your idea, but restructured as follows. >=20 > With additional logics, the initiator LSR can perform following > checks in a scenario where the initiator knows that there is a LAG, > with two LAG members, between TTL=3Dn and TTL=3Dn+1, and has the > multipath information to traverse the two LAG members. >=20 > The initiator LSR sends two MPLS echo request messages to traverse > the two LAG members at TTL=3D1: >=20 > o Success case: >=20 > * One MPLS echo request message reaches TTL=3Dn+1 on an LAG member > 1. >=20 > * The other MPLS echo request message reaches TTL=3Dn+1 on an LAG > member 2. >=20 > The two MPLS echo request messages sent by the initiator LSR reach > two different LAG members at the immediate downstream LSR. >=20 > o Error case: >=20 > * One MPLS echo request message reaches TTL=3Dn+1 on an LAG member > 1. >=20 > * The other MPLS echo request message also reaches TTL=3Dn+1 on an > LAG member 1. >=20 > One or two MPLS echo request messages sent by the initiator LSR > does not reach the immediate downstream LSR, or the two MPLS echo > request messages reach a same LAG member at the immediate > downstream LSR. EO# Yes, I think that's cleaner. =20 Thanks! eric From nobody Thu Dec 18 07:38:49 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 0D9D01A8A3C; Thu, 18 Dec 2014 07:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kko1xOeaBAZp; Thu, 18 Dec 2014 07:38:45 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608231A1B39; Thu, 18 Dec 2014 07:38:45 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 17498822DAEB0; Thu, 18 Dec 2014 15:38:39 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sBIFcchP019335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 10:38:40 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 10:38:16 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "mark.tinka@seacom.mu" Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgApvIICAACbQ0IAAx8AAgAAnohA= Date: Thu, 18 Dec 2014 15:38:16 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947C3282@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412170803.47595.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C2515@US70UWXCHMBA04.zam.alcatel-lucent.com> <201412172217.41962.mark.tinka@seacom.mu> In-Reply-To: <201412172217.41962.mark.tinka@seacom.mu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mN76KTShvsYNbEjlindUyfo3O20 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 15:38:48 -0000 Hi Mark, The issue will exist on a p2p link but in that case you could always add a = per-interface configuration knob which disables the dual-stack behavior and= will prevent sending IPv6 FECs and IPv6 addresses over a session on that l= ink. Regards, Mustapha.=20 > -----Original Message----- > From: Mark Tinka [mailto:mark.tinka@seacom.mu] > Sent: Wednesday, December 17, 2014 3:18 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > Subject: Re: [mpls] Last Call: (Updates= to LDP for > IPv6) to Proposed Standard >=20 > On Wednesday, December 17, 2014 03:26:54 PM Aissaoui, Mustapha (Mustapha) > wrote: >=20 > > It is actually testing against existing LDP IPv4 implementations when > > the LSR compliant to this draft sends LDP IPv6 FECs and LDP IPv6 > > addresses over the LDP > > IPv4 session. > > > > Here is a brief summary of the issues as I described to the list this > > summer: " > > 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. " >=20 > Thanks for the explanation, Mustapha. >=20 > Operationally, sounds a bit like IS-IS in a mixed single and dual stack e= nvironment, > but with IS-IS running in ST (Single > Topology) mode. >=20 > Of course, the IS-IS solution is to support MT (Multi- > Topology) so that adjacencies between a single stack and dual stack devic= e work > just fine. >=20 > I realize I'm simplifying things a bit, but not sure if we can borrow a l= eaf from the IS- > IS solution, if we are going to implement an integrated LDPv4/LDPv6 in th= e same > code base. >=20 > One more question - are you implying that this issue is not present in a = point-to-point > topology? >=20 > Mark. From nobody Thu Dec 18 08:29: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 DF30E1A911F; Thu, 18 Dec 2014 08:29:29 -0800 (PST) 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 K_I10Tl5toGo; Thu, 18 Dec 2014 08:29:28 -0800 (PST) Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E3A1A9107; Thu, 18 Dec 2014 08:27:44 -0800 (PST) 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 1Y1dvL-0004Ts-OQ; Thu, 18 Dec 2014 18:27:35 +0200 From: Mark Tinka Organization: SEACOM To: "Aissaoui, Mustapha (Mustapha)" Date: Thu, 18 Dec 2014 18:27:31 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412172217.41962.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C3282@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C3282@US70UWXCHMBA04.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2194590.b14FHuCpeS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201412181827.34972.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3Y2nE59BdbDG-SUKhGrUlErohgg Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: 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: Thu, 18 Dec 2014 16:29:30 -0000 --nextPart2194590.b14FHuCpeS Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, December 18, 2014 05:38:16 PM Aissaoui,=20 Mustapha (Mustapha) wrote: > Hi Mark, > The issue will exist on a p2p link... Yes, figured as much. > but in that case you > could always add a per-interface configuration knob > which disables the dual-stack behavior and will prevent > sending IPv6 FECs and IPv6 addresses over a session on > that link. Yes, easier to do on a point-to-point link compared to a=20 broadcast network. That said, I'm still for more of an MT-type solution a la=20 IS-IS, so that this applies to the entire protocol. This=20 way, operators do not have to fuff around with yet-another- knob (until they really have to). Any thoughts around this? Cheers, Mark. --nextPart2194590.b14FHuCpeS 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) iQIcBAABAgAGBQJUkwB2AAoJEGcZuYTeKm+GtCAP/2g1uQXxdKhmBYeBiBs3p+vT wfoYNsN+cZcDOVqIHw2G9bfyt4XAFd55oHj8rm4R24svNzZjn8aLkbizS74DGDAT 0QLakMznv2WAuBn9H8KOOrsUG1jXVKzhvQGT10odD0UfeS3iVisr69ekKHnwZuGT tEzBsH7PDv/bOiYdCvbEPBOevYY4NmyUJLhvaJxJ/0JsqyPxB/UWBFqtbg7y1y9n WrT+tGLEbuyTls37K7B/zufiZ6fwqb/Q2BC7BJwW0zqWJegAZQBj0UylDHFxm3S8 iav5+k8HDNnc6jRmoH7r0U9tZTOHvtBMo2okepRA7kndZ/qyAb/cZVhJg3PlQXHk bJWLlVpChgJijWeW1swdxdAfttUliFE8vnteZb25j8gNrhjCU/mVhVkrNsEaABzC sg9S0rxlUUrCAD6LCBmnMAvKiz6CKiFsR6c48p3zjawVsyv+AEw7r0jm6SynSrBs lqX8QkDacy/JqFo+M4aaQWNPp5DXW4ZvjdGv5oKY6TAeMG2DdHvMpTOnrMlneVl5 UfNi03/xZ16R6i3i7QzR8YUXBey+tmnDYbxkNsrP3Cfbl3lpSBfc3+UGQVRtLd2g xrrdufGt0zP7+M0MjtJU7vORiGb5RtKDqzc0zImkdPMsVg31/zdqKe/7Hoe+TNKn sLxPQdMFk4Rq6FplIFag =uBZn -----END PGP SIGNATURE----- --nextPart2194590.b14FHuCpeS-- From nobody Thu Dec 18 13:44: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 F3A931A9036 for ; Thu, 18 Dec 2014 13:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.911 X-Spam-Level: X-Spam-Status: No, score=-113.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HcWU7JMXW6c for ; Thu, 18 Dec 2014 13:44:38 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B62D1A9009 for ; Thu, 18 Dec 2014 13:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3629; q=dns/txt; s=iport; t=1418939080; x=1420148680; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BFVKfas5a9ZOcBpA/TyWzJAP4YrI9TtYGfnQZthZLIY=; b=QRzwin2swoDggn7grtdE2CExWUpOYWNl1++6bXyP8bCJgur6plWuoPyT U58kVBIpzjZpE4B12eU9vY31kQCwN2mW9ILUndUur6w0R0wKjRTzmuyEJ B3Ls2WbyJMy7ImYl2qOhoFQBe/iwfpga9+hoX61H+sESEee1xkMwqgzxo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAIxJk1StJV2Z/2dsb2JhbABbgmQigSoEzBACgSYWAQEBAQF9hAwBAQEEOj8MBAIBCBEEAQELFAkHMhQJCAEBBAENBQiIJAHPMQEBAQEBAQEBAQEBAQEBAQEBAQEBARePQTEHBoMQgRMBBIwzgVeJfYJhgjGHa4M4IoNsb4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,603,1413244800"; d="scan'208";a="381189472" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 18 Dec 2014 21:44:39 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBILibZ2020786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 21:44:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 15:44:37 -0600 From: "Nobo Akiya (nobo)" To: "Osborne, Eric" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "Mach Chen (mach.chen@huawei.com)" , Yimin Shen Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath Thread-Index: AdAP2no76f67h7pbRmWY0LHccfco7wGir7EQARynwYAADN6BgA== Date: Thu, 18 Dec 2014 21:44:36 +0000 Message-ID: References: <63CB93BC589C1B4BAFDB41A0A19B7ACD01049215@USIDCWVEMBX08.corp.global.level3.com> <63CB93BC589C1B4BAFDB41A0A19B7ACD01107AD8@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACD01107AD8@USIDCWVEMBX08.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.138.65] 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/tS22qswi5TxSPFs7AR_kptpWtSQ Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath 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, 18 Dec 2014 21:44:40 -0000 Hi Eric, Mach, Yimin, Consolidating the reply to all MPLS-RT reviewers. Again, many thanks all for taking time to review and provide very good comm= ents. We have an updated version of the document circulating amongst the authors = now, and should be able to post -05 within few days. Thanks! -Nobo > -----Original Message----- > From: Osborne, Eric [mailto:eric.osborne@level3.com] > Sent: Thursday, December 18, 2014 10:38 AM > To: Nobo Akiya (nobo); draft-akiya-mpls-lsp-ping-lag- > multipath@tools.ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN > (MARTIN) > Cc: mpls@ietf.org > Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath >=20 > Hi Nobo- >=20 > I've trimmed this a bit and replied to specific comments inline with EO= #. > Where there's no reply, please take that as acceptance of whatever change= s > you have proposed or made. >=20 > ... >=20 >=20 > > > Sections 3-5: These sections could use a reorg. Starting with > > > procedures for using new TLVs before defining the new TLVs feels > > > awkward. I suggest taking sections [3,4,5] and reordering as [5,3,4]= . > > > > [NOBO] Pre-00 version originally had the document structure similar to > > [5, 3, 4], but describing the procedures prior to the new TLVs was > > suggested from a very long timer IETF participant. With that said, > > "feel awkward" is something that I'd like to address. After the text > > you suggested in the next comment, let me add following text. > > > > Note that Section 5, Section 6, > > Section 7 and Section 8 describe the new TLVs, and looking over thos= e > > sections first may make it easier to read this section. > > > > Would that work? >=20 > EO# Sure, that works. >=20 > ... >=20 > > > It would benefit from some clarifying text, perhaps something like > > > "An error case is any case where the OAM across a LAG fails, either > > > partial or fully. A partial failure is where some LAG member > > > traversals behave as they should and some don't, and a full failure > > > is where no LAG member traversals behave as they should". > > > > [NOBO] I've taken your idea, but restructured as follows. > > > > With additional logics, the initiator LSR can perform following > > checks in a scenario where the initiator knows that there is a LAG, > > with two LAG members, between TTL=3Dn and TTL=3Dn+1, and has the > > multipath information to traverse the two LAG members. > > > > The initiator LSR sends two MPLS echo request messages to traverse > > the two LAG members at TTL=3D1: > > > > o Success case: > > > > * One MPLS echo request message reaches TTL=3Dn+1 on an LAG memb= er > > 1. > > > > * The other MPLS echo request message reaches TTL=3Dn+1 on an LA= G > > member 2. > > > > The two MPLS echo request messages sent by the initiator LSR reac= h > > two different LAG members at the immediate downstream LSR. > > > > o Error case: > > > > * One MPLS echo request message reaches TTL=3Dn+1 on an LAG memb= er > > 1. > > > > * The other MPLS echo request message also reaches TTL=3Dn+1 on = an > > LAG member 1. > > > > One or two MPLS echo request messages sent by the initiator LSR > > does not reach the immediate downstream LSR, or the two MPLS echo > > request messages reach a same LAG member at the immediate > > downstream LSR. >=20 >=20 > EO# Yes, I think that's cleaner. >=20 > Thanks! >=20 >=20 >=20 >=20 >=20 > eric From nobody Thu Dec 18 15:25: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 E9C711A90E7; Thu, 18 Dec 2014 15:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyOWcXWyQCug; Thu, 18 Dec 2014 15:25:21 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68921A87F2; Thu, 18 Dec 2014 15:25:20 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 7E3C5E3E21235; Thu, 18 Dec 2014 23:25:15 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sBINP8rZ026398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 18:25:17 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 18:25:16 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "mark.tinka@seacom.mu" Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgApvIICAACbQ0IAAx8AAgAAnohCAASpngP//xxbA Date: Thu, 18 Dec 2014 23:25:15 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947C4616@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412172217.41962.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C3282@US70UWXCHMBA04.zam.alcatel-lucent.com> <201412181827.34972.mark.tinka@seacom.mu> In-Reply-To: <201412181827.34972.mark.tinka@seacom.mu> 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/Mzp81b5GXZbFMEEJgxSbb1n6O_o Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 23:25:23 -0000 Hi Mark, both proposed methods to solve this LDP backward compatibility issue rely o= n detecting a specific TLV from the peer. So, the absence of the TLV will i= ndicate that the peer LSR is not compliant to the LDP IPv6 draft in a simil= ar way ISIS uses the absence of the Multi-Topology TLV to consider the neig= hbor is MT=3D0 capable only. So there is no need for a CLI knob.=20 What we were debating is if we should use the LDP capability TLV mechanism = which LDP uses to advertise any new capability not supported by previous im= plementations versus overloading another TLV which was not meant for capabi= lity discovery. Mustapha. =20 > -----Original Message----- > From: Mark Tinka [mailto:mark.tinka@seacom.mu] > Sent: Thursday, December 18, 2014 11:28 AM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > Subject: Re: [mpls] Last Call: (Updates= to LDP for > IPv6) to Proposed Standard >=20 > On Thursday, December 18, 2014 05:38:16 PM Aissaoui, Mustapha (Mustapha) > wrote: >=20 > > Hi Mark, > > The issue will exist on a p2p link... >=20 > Yes, figured as much. >=20 > > but in that case you > > could always add a per-interface configuration knob which disables the > > dual-stack behavior and will prevent sending IPv6 FECs and IPv6 > > addresses over a session on that link. >=20 > Yes, easier to do on a point-to-point link compared to a broadcast networ= k. >=20 > That said, I'm still for more of an MT-type solution a la IS-IS, so that = this applies to > the entire protocol. This way, operators do not have to fuff around with = yet-another- > knob (until they really have to). >=20 > Any thoughts around this? >=20 > Cheers, >=20 > Mark. From nobody Thu Dec 18 19:31: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 233EB1A9163; Thu, 18 Dec 2014 19:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hc75LvdRgdRX; Thu, 18 Dec 2014 19:30:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B18D1A9138; Thu, 18 Dec 2014 19:30:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219033055.12792.27178.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 19:30:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sA20px8SyfBUDwnzqiSE7t8vTPI Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-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: Fri, 19 Dec 2014 03:30:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Encapsulating MPLS in UDP Authors : Xiaohu Xu Nischal Sheth Lucy Yong Ross Callon David Black Filename : draft-ietf-mpls-in-udp-09.txt Pages : 17 Date : 2014-12-18 Abstract: This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol) for situations where UDP encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. MPLS- in-UDP is primarily applicable to service provider networks, and additional restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-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 Thu Dec 18 22:47: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 2C8CB1A9026; Thu, 18 Dec 2014 22:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2mfBR2K0SJH; Thu, 18 Dec 2014 22:47:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ED51A1A9C; Thu, 18 Dec 2014 22:47:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219064750.28656.74497.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 22:47:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1lHZYuJ3cd8pL8XT8CHt4efeXcc Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 06:47:52 -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-TP Traffic Engineering (TE) Management Information Base (MIB) Authors : Venkatesan Mahalingam Kannan KV Sampath Sam Aldrin Thomas D. Nadeau Filename : draft-ietf-mpls-tp-te-mib-11.txt Pages : 61 Date : 2014-12-18 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects and textual conventions for Tunnels, Identifiers and Label Switching Router to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-te-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-te-mib-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-te-mib-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 18 23:49: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 4C5E51A1B48 for ; Thu, 18 Dec 2014 23:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs1J-Y7dkhJU for ; Thu, 18 Dec 2014 23:49:03 -0800 (PST) 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 BE1FA1A1B17 for ; Thu, 18 Dec 2014 23:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1451; q=dns/txt; s=iport; t=1418975342; x=1420184942; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PNYr8j4TRTVXQyC3oVPeLapb9ZgC5Z7QhGBF5tFZHR0=; b=PmpY6pE6dkuplXZgSaO0UNpkKlrUhL2CCTST0FzigxhKrnA84RA9lHkx e91qa1FMaFCm7S9GITeExQjqmG9qtW3Ztt1DGRO68xiO7F742svG8JmTL Vc4+mcyLYEX0Gf1+o02ntlH3fhW3C/XaDADAwDOlQ9EUfnADvECUg4nZS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0JAMnXk1StJssW/2dsb2JhbABahDCzZgEBAQEBAQUBd5cvAoExAQEBAQF9hA0BAQMBawMGBQUJAgtGGzwGE4gkCM9XAQEBAQEBAQEBAQEBAQEBAQEBAQEYBIV8iRAQAgEcMweDFoETBZZ8gQ2CYo1ZIoNtPTGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.07,605,1413244800"; d="scan'208";a="280488478" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 19 Dec 2014 07:49:00 +0000 Received: from ams-iwijnand-88111.cisco.com (ams-iwijnand-88111.cisco.com [10.60.202.92]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBJ7mw9q014947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Dec 2014 07:48:59 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: IJsbrand Wijnands In-Reply-To: <548FC81B.5060107@pi.nu> Date: Fri, 19 Dec 2014 08:48:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <781A2B28-4653-4EB7-B1CE-451E40088B77@cisco.com> References: <548FC81B.5060107@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/SmyfVKJUy5mz8HDhzR7I23toE4A Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 07:49:04 -0000 Hi Loa, I=92m not aware of related IPR to this draft, Thx, Ice. On 16 Dec 2014, at 06:50, Loa Andersson wrote: > Working group, >=20 > An adoption poll has been started on draft-atlas-mpls-ldp-mrt. > We will run the IPR poll in parallel. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-atlas-mpls-ldp-mrt? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are no IPR disclosures that relates to this document. >=20 > 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. >=20 > *The response needs to be sent to the MPLS wg mailing list.* >=20 > The document will not advance to the next stage until a response has = been received from each author and contributor. >=20 > 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. >=20 > Thanks, Loa > mpls wg co-chair > --=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 Dec 19 04:16: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 4760D1A916A for ; Fri, 19 Dec 2014 04:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjE0naAZo-Mw for ; Fri, 19 Dec 2014 04:16:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 931411A9170 for ; Fri, 19 Dec 2014 04:16:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219121643.9260.92454.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 04:16:43 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bXFD5ZEPjzggV_NqRupDDWrJ3ZM Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 12:16:45 -0000 Changed milestone "Submit draft-ietf-mpls-tp-te-mib for publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Dec 19 04:25: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 9E5FF1A6F7F; Fri, 19 Dec 2014 04:24:57 -0800 (PST) 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 0EQ-p0qYZW4D; Fri, 19 Dec 2014 04:24:56 -0800 (PST) Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C12C1A6F2E; Fri, 19 Dec 2014 04:24:55 -0800 (PST) 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 1Y1wbu-0008S5-R4; Fri, 19 Dec 2014 14:24:46 +0200 From: Mark Tinka Organization: SEACOM To: "Aissaoui, Mustapha (Mustapha)" Date: Fri, 19 Dec 2014 14:24:45 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412181827.34972.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C4616@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C4616@US70UWXCHMBA04.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2618500.qoVPgfzSpL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201412191424.45419.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Pcsr8gkuPF4qymYsBo645zdhwy4 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: 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: Fri, 19 Dec 2014 12:24:57 -0000 --nextPart2618500.qoVPgfzSpL Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, December 19, 2014 01:25:15 AM Aissaoui, Mustapha=20 (Mustapha) wrote: > What we were debating is if we should use the LDP > capability TLV mechanism which LDP uses to advertise any > new capability not supported by previous implementations > versus overloading another TLV which was not meant for > capability discovery. As an operator, having to upgrade a non-compliant device=20 that is not yet ready to run LDPv6 so that a neighboring=20 LDPv6-capable device planning to run LDPv6 can still form=20 LDPv4 adjacencies is quite heavy-handed. Upgrading a device for anything LDPv6 should, ideally, be in=20 the interest of getting LDPv6 deployed, and not to prevent=20 LDPv4 adjacency tear-down due to capability incompatibility. On the other hand, it might be worthwhile looking into=20 adding a knob for an LDPv6-compliant device to tell it to=20 have backwards compatibility with non-compliant devices on=20 the wire. Since one would, in all likelihood, be upgrading a=20 non-compliant device to make it compliant, the heavy-hand=20 makes sense here since an operator needs to get the code in=20 anyway. Mark. --nextPart2618500.qoVPgfzSpL 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) iQIcBAABAgAGBQJUlBkNAAoJEGcZuYTeKm+GnKYQAIjEtJ2TD19f1jGfFS1rMTEr A5P2ueyD0bCAiQdaTtnMN0Wtexrrc+8JEae6XgH3Iy6QcKcmxRQcFV8Ft2twXigB 5/leSJ1JYhXPTEKFAyEU4Zjf2JhCANNql28lHQOR4n/5g5Z7tVorsC8Sxgj9c4eZ +IeDwUZ5v5hw1qf3vETHh2Y0/i9Wrtn79WNCu6FkGBavYuTgk759dfPY+gfDr9GJ N+NLUD3AOd/78SQUfYUbxtDJBsp0du10RmPJHFbtYrLbQQaw03pabUmPSuNM5aB2 tCBzFaPPshuyXhSplS4hQ7kZ6Fqgo3IKQH2Tw7QQKpC3i6+dL2VWQtJ4l49Ayt9j v1PbN89VqyakVgkRHgg/dsl9FBXjU4axZvJNxvtCKogAtpaG3amiG6nKrMW4oKHa RFdTt5AJaKKvv9OX/X0peF7d4slZTji7MYul3dfzZp8b3wEKOFD7YmoiDBTq3OuQ PpJw0m5h+uARfUbV928v2+gRtnbaClKxJYIOHTzA3VFMj6errDfqBcq/tXbjjV9E TJulXptnbAEXcOTRyyKbK2y76kAh8qGUh70BSAb804ZjNALlD6kRT3/UxUcFAPjj ZSelAoJoCzRt4kgJxIsbOwmNE5U+ZQ2idMHHy+6ICHj2jk0u/Z1ZeGu5sZK1F9o0 CL3FEV3h6VRgx4Rc47JB =tmnK -----END PGP SIGNATURE----- --nextPart2618500.qoVPgfzSpL-- From nobody Fri Dec 19 06:14: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 749C61A8875; Fri, 19 Dec 2014 06:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E3LztDoHhN2; Fri, 19 Dec 2014 06:14:23 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1302A1A1A99; Fri, 19 Dec 2014 06:14:22 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 2D148F69C149C; Fri, 19 Dec 2014 14:14:17 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sBJEEHbK011681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 09:14:17 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 09:14:17 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "mark.tinka@seacom.mu" Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgApvIICAACbQ0IAAx8AAgAAnohCAASpngP//xxbAgAGHa4D//7nVwA== Date: Fri, 19 Dec 2014 14:14:17 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947C48D5@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412181827.34972.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C4616@US70UWXCHMBA04.zam.alcatel-lucent.com> <201412191424.45419.mark.tinka@seacom.mu> In-Reply-To: <201412191424.45419.mark.tinka@seacom.mu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/omPujveCjWEJ0SjI2fxWuKiT4Dc Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 14:14:30 -0000 Hi Mark, Indeed the reason I raised the issue in the summer was to make sure we do n= ot disrupt existing LDPv4 deployments and that we do not need to upgrade a = LDPv4 node which does not comply to this LDPv6 spec. So, both proposed meth= ods put the onus on the LDPv6 compliant node to automatically detect a rout= er which is not compliant to LDPv6 such that it will not send to that node = LDP IPv6 FECs and IPv6 addresses.=20 >From that perspective, the draft now addressed the issue. My latest message= was raising concerns about the specific method added to the draft and by w= hich the LDPv6 compliant LSR goes about addressing the issue.=20 I hope this clarifies the situation. Regards, Mustapha. > -----Original Message----- > From: Mark Tinka [mailto:mark.tinka@seacom.mu] > Sent: Friday, December 19, 2014 7:25 AM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > Subject: Re: [mpls] Last Call: (Updates= to LDP for > IPv6) to Proposed Standard >=20 > On Friday, December 19, 2014 01:25:15 AM Aissaoui, Mustapha > (Mustapha) wrote: >=20 > > What we were debating is if we should use the LDP capability TLV > > mechanism which LDP uses to advertise any new capability not supported > > by previous implementations versus overloading another TLV which was > > not meant for capability discovery. >=20 > As an operator, having to upgrade a non-compliant device that is not yet = ready to > run LDPv6 so that a neighboring LDPv6-capable device planning to run LDPv= 6 can > still form > LDPv4 adjacencies is quite heavy-handed. >=20 > Upgrading a device for anything LDPv6 should, ideally, be in the interest= of getting > LDPv6 deployed, and not to prevent > LDPv4 adjacency tear-down due to capability incompatibility. >=20 > On the other hand, it might be worthwhile looking into adding a knob for = an LDPv6- > compliant device to tell it to have backwards compatibility with non-comp= liant > devices on the wire. Since one would, in all likelihood, be upgrading a n= on-compliant > device to make it compliant, the heavy-hand makes sense here since an ope= rator > needs to get the code in anyway. >=20 > Mark. From nobody Fri Dec 19 08:29: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 CA90A1A88C9; Fri, 19 Dec 2014 08:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V07UssGA5r_k; Fri, 19 Dec 2014 08:29:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7C41A8960; Fri, 19 Dec 2014 08:29:01 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219162901.26406.53743.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 08:29:01 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cOtgIGLUZKiK4yfyAngl8-HShcc Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)' to Proposed Standard (draft-ietf-mpls-tp-te-mib-11.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 16:29:07 -0000 The IESG has approved the following document: - 'MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)' (draft-ietf-mpls-tp-te-mib-11.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-te-mib/ Technical Summary The document defines a portion of the MIB for use with network management protocols, and describes managed objects for Tunnels, Identifiers, Label Switching Router and Textual conventions for MPLS-TP. These MIB modules extend the existing MPLS MIB objects for both MPLS and MPLS-TP operations, because of this the MPLS-TP name is not included in the MIB module names. The existing MPLS-TE MIB [RFC3812] and the GMPLS-TE MIB [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. The MIB modules defined in draft-ietf-mpls-tp-te-mib should be used in conjunction with [RFC3812] and its companion document [RFC3813] for MPLS-TP tunnel configuration and management. Working Group Summary There were no issues in the working group process. However, the AD review caused the document to be returned to the working group for significant changes. Document Quality We know of several implementations of the MIB module. There are significant number of vendors that either has or will implement the MIB module. Personnel Young Lee is the Document Shepherd. Adrian Farrel is the Responsible Area Director From nobody Fri Dec 19 10:22: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 2CD351ACCF9; Fri, 19 Dec 2014 10:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 V-l1VlOAkqzi; Fri, 19 Dec 2014 10:22:33 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABED1ACD1E; Fri, 19 Dec 2014 10:22:32 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBJIMST0010459; Fri, 19 Dec 2014 18:22:29 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBJIMPnm010395 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2014 18:22:26 GMT From: "Adrian Farrel" To: "'Aissaoui, Mustapha \(Mustapha\)'" , References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412181827.34972.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C4616@US70UWXCHMBA04.zam.alcatel-lucent.com> <201412191424.45419.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C48D5@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C48D5@US70UWXCHMBA04.zam.alcatel-lucent.com> Date: Fri, 19 Dec 2014 18:22:17 -0000 Message-ID: <078001d01bb8$ba013c80$2e03b580$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEavZr4LLvEoVKVBHX9h497xfv8bQFic8MEArQt0NUBhvNK4AIMca6CncSj6vA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21188.002 X-TM-AS-Result: No--40.018-10.0-31-10 X-imss-scan-details: No--40.018-10.0-31-10 X-TMASE-MatchedRID: Ojx+9XBBWGvZNO+XkKeVnSrFJXkaeddx6hUo8ujhEXt9c66OtqoXQuiY +s2L3xQETzZrG+KJluYuLLrhEK94BjM9Cwl5qH1FcgRuMUq2K0gvmfQHDKJ1l9igeTkdjx3hbd6 rGhWOAwT4JyR+b5tvoPG399+Ui/tdWTXzX6U+UCa21u7MJ+0iRTzr4TJKjukKuIwLnB3Aqp0GF+ E6mzeNqN9RlPzeVuQQHIDypuQ6GngxcSfgz4Zxa/FPDHhQkgxyVddl4Ia+kJPPhdXKEUVkchmyT BaqiJvcfeB8ZkBTx8v96qgBvkbYNGWETisY1v9qOaKAZa7BhDzHqyfFy3TE0kst+Oj0y0ls2D/7 bUIJlF2iwcw4+Mrtw2c4B71z5rPYeACX81jEw+u/akshkYK9vygaoyC9I8oNmlaAItiONP32v20 RxLDyN2sSgW01iDQLeyKvlsbWzZYhvNeGEEojjwTgsVt779d+Y2JnK7gKcXL7/v/5alNYeh852j gffnmIULzpjrEhojrN/2wFL5/vDMb0m1re9TVL/s8l/i/pT2u31G6CKdUG1fYiLRVJ915DWLk7K HjvnCRXPwnnY5XL5LppSwuYPeB79p+FCsxUVBOGCLqQvRi5SGFqPXSLpNdAQr2qXCJMSV91k+gP 1XamtJsoi2XrUn/JyeMtMD9QOgCk8oKXKhRLPI2j49Ftap9EkGUtrowrXLg= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-aSRPQpjGGPgv5X6vaT8n9sWgFI Cc: mpls@ietf.org, ietf@ietf.org, 'IETF-Announce' Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: afarrel@juniper.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 18:22:35 -0000 Mustapha, It will fall to me to try to draw some form of consensus out of this discussion so I have would like to clarify some things. Are you reporting an interop problem with widely deployed implementations, or an interop problem with one release of one implementation? The latter is what I would call a bug, since the problem is a failure to conform to 5036. The former is, of course, a bigger problem. Are you reporting a problem that is exclusive to multi-access links? While this is an important use case, it is a little marginal. In short, do you have a corner case comprising of: - multi-access link - combined legacy v4 nodes and new v6 nodes - a non-conformant v4 node ...or is the problem larger than that? Thanks, Adrian > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha > (Mustapha) > Sent: 19 December 2014 14:14 > To: mark.tinka@seacom.mu > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > Subject: Re: [mpls] Last Call: (Updates to LDP for > IPv6) to Proposed Standard > > Hi Mark, > Indeed the reason I raised the issue in the summer was to make sure we do not > disrupt existing LDPv4 deployments and that we do not need to upgrade a LDPv4 > node which does not comply to this LDPv6 spec. So, both proposed methods put > the onus on the LDPv6 compliant node to automatically detect a router which is > not compliant to LDPv6 such that it will not send to that node LDP IPv6 FECs and > IPv6 addresses. > > >From that perspective, the draft now addressed the issue. My latest message > was raising concerns about the specific method added to the draft and by which > the LDPv6 compliant LSR goes about addressing the issue. > > I hope this clarifies the situation. > > Regards, > Mustapha. > > > -----Original Message----- > > From: Mark Tinka [mailto:mark.tinka@seacom.mu] > > Sent: Friday, December 19, 2014 7:25 AM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > Subject: Re: [mpls] Last Call: (Updates to LDP > for > > IPv6) to Proposed Standard > > > > On Friday, December 19, 2014 01:25:15 AM Aissaoui, Mustapha > > (Mustapha) wrote: > > > > > What we were debating is if we should use the LDP capability TLV > > > mechanism which LDP uses to advertise any new capability not supported > > > by previous implementations versus overloading another TLV which was > > > not meant for capability discovery. > > > > As an operator, having to upgrade a non-compliant device that is not yet ready > to > > run LDPv6 so that a neighboring LDPv6-capable device planning to run LDPv6 > can > > still form > > LDPv4 adjacencies is quite heavy-handed. > > > > Upgrading a device for anything LDPv6 should, ideally, be in the interest of > getting > > LDPv6 deployed, and not to prevent > > LDPv4 adjacency tear-down due to capability incompatibility. > > > > On the other hand, it might be worthwhile looking into adding a knob for an > LDPv6- > > compliant device to tell it to have backwards compatibility with non-compliant > > devices on the wire. Since one would, in all likelihood, be upgrading a non- > compliant > > device to make it compliant, the heavy-hand makes sense here since an > operator > > needs to get the code in anyway. > > > > Mark. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Dec 19 11:11:10 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 83A731ACD6A; Fri, 19 Dec 2014 11:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KojBAC1jviPP; Fri, 19 Dec 2014 11:10:52 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C361A9072; Fri, 19 Dec 2014 11:10:52 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 4D9B270F1716; Fri, 19 Dec 2014 19:10:47 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sBJJAmOT030351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 14:10:48 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 14:10:48 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "afarrel@juniper.net" , "mark.tinka@seacom.mu" Thread-Topic: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgApvIICAACbQ0IAAx8AAgAAnohCAASpngP//xxbAgAGHa4D//7nVwIAAqhCA//+yBpA= Date: Fri, 19 Dec 2014 19:10:47 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D947C4A74@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412181827.34972.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C4616@US70UWXCHMBA04.zam.alcatel-lucent.com> <201412191424.45419.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C48D5@US70UWXCHMBA04.zam.alcatel-lucent.com> <078001d01bb8$ba013c80$2e03b580$@juniper.net> In-Reply-To: <078001d01bb8$ba013c80$2e03b580$@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ChhzJ_PUS67oO7G12gpOB5PNIAo Cc: "mpls@ietf.org" , "ietf@ietf.org" , 'IETF-Announce' Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 19:11:04 -0000 Hi Adrian, We found interop issues with two other widely deployed implementations in w= hich the LDP IPv4 session was brought down.=20 One implementation was with receiving IPv6 addresses over the LDPv4 session= and the behavior did not seem to change with a few versions of the impleme= ntation we tried. The second implementation was with IPv6 FECs over the LDP= v4 session. This last one was fixed in a subsequent release but we lately f= ound out that there were still issues with withdrawing/releasing the IPv6 F= ECs. The issue exists in both p2p and broadcast interfaces. The thing is that as= soon as a router is upgraded to this implementation, it will automatically= begin advertising IPv6 addresses and IPv6 FECs over the LDPv4 session. Bas= ed on testing so far, and we have not tested all possible OS and hardware v= ersions, we believe it is risky to advertise these by default and hence our= proposal to play it safe and only advertise them if the peer LSR explicitl= y advertised its support for IPv6 FECs by including the IPv6 FEC capability= in the session initialization.=20 The draft now added a similar check using the dual-stack capability TLV at = the adjacency level instead of our proposal of using the capability TLV at = the session level. It does complicate the check of the peer capabilities an= d as such I provided comments in the last call email to clarify the behavio= r of that proposal. Regards, Mustapha. > -----Original Message----- > From: Adrian Farrel [mailto:afarrel@juniper.net] > Sent: Friday, December 19, 2014 1:22 PM > To: Aissaoui, Mustapha (Mustapha); mark.tinka@seacom.mu > Cc: mpls@ietf.org; ietf@ietf.org; 'IETF-Announce' > Subject: RE: [mpls] Last Call: (Updates= to LDP for > IPv6) to Proposed Standard >=20 > Mustapha, >=20 > It will fall to me to try to draw some form of consensus out of this disc= ussion so I > have would like to clarify some things. >=20 > Are you reporting an interop problem with widely deployed implementations= , or an > interop problem with one release of one implementation? The latter is wha= t I would > call a bug, since the problem is a failure to conform to 5036. The former= is, of > course, a bigger problem. >=20 > Are you reporting a problem that is exclusive to multi-access links? Whil= e this is an > important use case, it is a little marginal. >=20 > In short, do you have a corner case comprising of: > - multi-access link > - combined legacy v4 nodes and new v6 nodes > - a non-conformant v4 node > ...or is the problem larger than that? >=20 > Thanks, > Adrian >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, > > Mustapha > > (Mustapha) > > Sent: 19 December 2014 14:14 > > To: mark.tinka@seacom.mu > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > Subject: Re: [mpls] Last Call: > > (Updates to > LDP for > > IPv6) to Proposed Standard > > > > Hi Mark, > > Indeed the reason I raised the issue in the summer was to make sure we > > do not disrupt existing LDPv4 deployments and that we do not need to > > upgrade a LDPv4 node which does not comply to this LDPv6 spec. So, > > both proposed methods put the onus on the LDPv6 compliant node to > > automatically detect a router which is not compliant to LDPv6 such > > that it will not send to that node LDP IPv6 FECs > and > > IPv6 addresses. > > > > >From that perspective, the draft now addressed the issue. My latest > > >message > > was raising concerns about the specific method added to the draft and > > by which the LDPv6 compliant LSR goes about addressing the issue. > > > > I hope this clarifies the situation. > > > > Regards, > > Mustapha. > > > > > -----Original Message----- > > > From: Mark Tinka [mailto:mark.tinka@seacom.mu] > > > Sent: Friday, December 19, 2014 7:25 AM > > > To: Aissaoui, Mustapha (Mustapha) > > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > > Subject: Re: [mpls] Last Call: > > > (Updates to > LDP > > for > > > IPv6) to Proposed Standard > > > > > > On Friday, December 19, 2014 01:25:15 AM Aissaoui, Mustapha > > > (Mustapha) wrote: > > > > > > > What we were debating is if we should use the LDP capability TLV > > > > mechanism which LDP uses to advertise any new capability not > > > > supported by previous implementations versus overloading another > > > > TLV which was not meant for capability discovery. > > > > > > As an operator, having to upgrade a non-compliant device that is not > > > yet > ready > > to > > > run LDPv6 so that a neighboring LDPv6-capable device planning to run > > > LDPv6 > > can > > > still form > > > LDPv4 adjacencies is quite heavy-handed. > > > > > > Upgrading a device for anything LDPv6 should, ideally, be in the > > > interest of > > getting > > > LDPv6 deployed, and not to prevent > > > LDPv4 adjacency tear-down due to capability incompatibility. > > > > > > On the other hand, it might be worthwhile looking into adding a knob > > > for an > > LDPv6- > > > compliant device to tell it to have backwards compatibility with > non-compliant > > > devices on the wire. Since one would, in all likelihood, be > > > upgrading a non- > > compliant > > > device to make it compliant, the heavy-hand makes sense here since > > > an > > operator > > > needs to get the code in anyway. > > > > > > Mark. > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Dec 19 13:18:04 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 9A9FF1A8546; Fri, 19 Dec 2014 13:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGOk9O_uO_YZ; Fri, 19 Dec 2014 13:18:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E081A016A; Fri, 19 Dec 2014 13:18:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: Loa Andersson , George Swallow , Ross Callon X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219211800.17387.25219.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 13:18:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dDIEeJjpLR-m_b2J-bCuU826Khk Cc: mpls@ietf.org, naotaka.morita@ntt-at.co.jp Subject: [mpls] New Liaison Statement, "LS on ITU-T SG15 OTNT standardization work plan to mpls" 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, 19 Dec 2014 21:18:02 -0000 Title: LS on ITU-T SG15 OTNT standardization work plan to mpls Submission Date: 2014-12-19 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1369/ Please reply by 2015-06-07 From: ITU-T SG 15 (Greg Jones ) To: Multiprotocol Label Switching (Loa Andersson , George Swallow , Ross Callon ) Cc: Adrian Farrel ,Alia Atlas ,mpls@ietf.org,John Drake ,Scott Mansfield Response Contact: naotaka.morita@ntt-at.co.jp Technical Contact: Purpose: For comment Body: Thank you for your previous review and comments on “Optical Transport Networks & Technologies standardization work plan.†Attached is Issue 19, the latest version that was updated by the SG15 meeting in December 2014. We appreciate your continued review and comments which allow us to keep the document up-to-date. Attach: − OTNT standardization work plan, Issue 19 (TD282/PLEN Rev.1) Attachments: LS on ITU-T SG15 OTNT standardization work plan to mpls https://datatracker.ietf.org/documents/LIAISON/liaison-2014-12-19-itu-t-sg-15-mpls-ls-on-itu-t-sg15-otnt-standardization-work-plan-to-mpls-attachment-1.zip From nobody Fri Dec 19 13:48: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 B133C1AC3EA; Fri, 19 Dec 2014 13:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsUMNZyjoX8y; Fri, 19 Dec 2014 13:48:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 134831A1BD2; Fri, 19 Dec 2014 13:48:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: Loa Andersson , George Swallow , Ross Callon X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219214821.10356.40147.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 13:48:21 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MCtJW6OmoE6OlLOLVweyY6GcDZI Cc: mpls@ietf.org, huub.van-helvoort@ties.itu.int, jessy.rouyer@alcatel-lucent.com, tom.huber@coriant.com, lihan@chinamobile.com, naotaka.morita@ntt-at.co.jp Subject: [mpls] New Liaison Statement, "LS on update to MPLS-TP work in ITU-T SG15" 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, 19 Dec 2014 21:48:23 -0000 Title: LS on update to MPLS-TP work in ITU-T SG15 Submission Date: 2014-12-19 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1370/ From: ITU-T SG 15 (Greg Jones ) To: Multiprotocol Label Switching (Loa Andersson , George Swallow , Ross Callon ) Cc: Adrian Farrel ,Alia Atlas ,mpls@ietf.org,John Drake ,Scott Mansfield Response Contact: naotaka.morita@ntt-at.co.jp, tom.huber@coriant.com, lihan@chinamobile.com, jessy.rouyer@alcatel-lucent.com, huub.van-helvoort@ties.itu.int, alessandro.dalessandro@telecomitalia.it, Kam.Lam@alcatel-lucent.com, scott.mansfield@ericsson.com Technical Contact: Purpose: For information Body: ITU-T SG15 wishes to inform the IETF MPLS WG that ITU-T SG15 has initiated at our December 2014 closing plenary meeting the final approval process for: - Corrigendum 1 to Recommendation ITU-T G.8112/Y.1371 (2012). This Corrigendum replaces a bibliographical reference to draft-ietf-mpls-tp-ethernet-addressing-08 with a normative reference to published IETF RFC 7213. - Recommendation ITU-T G.8151/Y.1374. This Recommendation incorporates Amendment 1 (2012) and Amendment 2 (2013) into the base document (Recommendation ITU-T G.8151/Y.1374-2012), includes extensions for managing Recommendations ITU-T G.8121.1/Y.1381.1 and ITU-T G.8121.2/Y.1381.2 functionalities, and maintenance items. - Recommendation ITU-T G.8101/Y.1355. This Recommendation adds items defined in Recommendation ITU-T G.8131/Y.1382 (2014) and IETF RFC 7087. ITU-T SG15 also wishes to inform the IETF MPLS WG of an update to the ITU-T SG15 work programme to include an amendment to Recommendation ITU-T G.8131/Y.1382, Linear protection switching for MPLS transport profile. This amendment provides 3 editorial enhancements to the text in the approved Recommendation without introducing any change in behaviour: - Adding an illustration in clause 8.1 of the format of the APC PDU for the convenience of the reader. Currently, the Recommendation references RFC6378 for the base PDU and RFC7271 for a mandatory TLV to be included within that PDU but does not illustrate the format of the PDU after those two components have been put together. - Updating the description of the Type field of the aforementioned TLV from ‘TBD’ to ‘1’ to reflect the IANA assignment that has been made. - A number of clauses describe configurable parameters of the protection mechanism. The amendment adds text to identify the specific management information signals that are used to configure those parameters. The initial draft of this amendment is attached together with the consented texts. The amendment to Recommendation ITU-T G.8131/Y.1382 is targeted for consent at the July 2015 meeting of SG15. Attach: − Draft Amendment 1 to Recommendation ITU-T G.8131/Y.1382 (2014) (latest draft) (TD287/WP3) − Draft Corrigendum 1 to Recommendation ITU-T G.8112/Y.1371 (2012) (Consented, 5 December 2014) (TD349/PLEN) − Draft revised Recommendation ITU-T G.8151/Y.1374 (Consented, 5 December 2014) (TD302/PLEN Rev.1) − Draft revised Recommendation ITU-T G.8101/Y.1355 (Consented, 5 December 2014) (TD326/PLEN Rev.1) Attachments: LS on update to MPLS-TP work in ITU-T SG15 https://datatracker.ietf.org/documents/LIAISON/liaison-2014-12-19-itu-t-sg-15-mpls-ls-on-update-to-mpls-tp-work-in-itu-t-sg15-attachment-1.zip From nobody Sat Dec 20 20: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 9ED1C1A0145 for ; Sat, 20 Dec 2014 20:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e91zFrugYPYU for ; Sat, 20 Dec 2014 20:49:34 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B2D1A0140 for ; Sat, 20 Dec 2014 20:49:34 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.74.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 210C61801590; Sun, 21 Dec 2014 05:49:30 +0100 (CET) Message-ID: <54965155.9010203@pi.nu> Date: Sun, 21 Dec 2014 12:49:25 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" References: <547D81A1.30905@pi.nu> In-Reply-To: <547D81A1.30905@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BiSQWHvFpYVuqUgKK2SxWls38o0 Cc: "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: [mpls] Closed: draft-ietf-mpls-oam-ipv6-rao 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, 21 Dec 2014 04:49:36 -0000 Working Group, This wglc is closed, we only have supporting responses. Can (one of) the authors confirm that they are ready to go ahead and request publication for this version (-02) of the document. /Loa On 2014-12-02 17:08, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-oam-ipv6-rao. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There is no IPR disclosures against this document. All the authors > 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 December 16, 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 Sat Dec 20 21:43: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 B4EDF1A015F for ; Sat, 20 Dec 2014 21:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UAz1rt-F3Hz for ; Sat, 20 Dec 2014 21:43:48 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B371A0113 for ; Sat, 20 Dec 2014 21:43:48 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.74.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5EDD91801590; Sun, 21 Dec 2014 06:43:45 +0100 (CET) Message-ID: <54965E0B.3050701@pi.nu> Date: Sun, 21 Dec 2014 13:43:39 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <548FC870.3090901@pi.nu> In-Reply-To: <548FC870.3090901@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NGbBit_KCNtm-Arbc26q_qhh9_0 Cc: "mpls-chairs@tools.ietf.org" , draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: [mpls] Update:: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 05:43:49 -0000 Working Group, This is to notify that all authors has now responded to the IPR poll, they are all unaware of any IPRs that relate to this document. /Loa On 2014-12-16 13:51, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is no IPR disclosures directly against this document. An IPR > poll will be done in parallel to the adoption poll, and the adoption > poll will not be closed before we have responses from all authors. > > If you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, you should respond to the > IPR poll. > > This poll ends January 2, 2015. > > /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Dec 21 06:57: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 355BE1A0AC8; Sun, 21 Dec 2014 06:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMvLRpBuq5JS; Sun, 21 Dec 2014 06:57:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8451A19E9; Sun, 21 Dec 2014 06:57:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141221145735.2408.52761.idtracker@ietfa.amsl.com> Date: Sun, 21 Dec 2014 06:57:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/DJammO6K-FAIBGIz_0N_QNTMMFY Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 14:57:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces Authors : Nobo Akiya George Swallow Stephane Litkowski Bruno Decraene John E. Drake Filename : draft-akiya-mpls-lsp-ping-lag-multipath-05.txt Pages : 27 Date : 2014-12-21 Abstract: This document defines an extension to the MPLS Label Switched Path (LSP) Ping and Traceroute as specified in RFC 4379. The extension allows the MPLS LSP Ping and Traceroute to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. This document updates RFC4379 and RFC6424. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag-multipath/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-multipath-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-akiya-mpls-lsp-ping-lag-multipath-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 21 07:12: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 D295C1A1A16 for ; Sun, 21 Dec 2014 07:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbhSHsUN-IBo for ; Sun, 21 Dec 2014 07:12:10 -0800 (PST) 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 A7BC71A1A10 for ; Sun, 21 Dec 2014 07:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3614; q=dns/txt; s=iport; t=1419174730; x=1420384330; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EU6ij8MBYMk/6/n3bNJPaBrAFsxjnOYBnsgwhz6hETQ=; b=HSt1plG5v6ZElPP0s84m0RbIQBTXvG10KpUQJCT9L8FI1HW3e9THwqw9 QlgYwcXIGNDaoJD80o1ON2FFFaWLYl8YF2Ut2za9UwaOTvBmgE64vmk45 ZAtt4rg177lVkdOPdq8kBpCrp2GAZUOBHq+OSxonlfx/KFFH6Ej0YvbfY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFANrillStJV2Z/2dsb2JhbABbgmQiUlMFBMYpDIVuAoERFgEBAQEBfYQMAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQTCAGIIwEHBc4uAQEBAQEBAQEBAQEBAQEBAQEBARmPQTgGgxCBEwWMOoFXgz6GQTCCNIdLhg8ig25vgQUkHH4BAQE X-IronPort-AV: E=Sophos;i="5.07,617,1413244800"; d="scan'208";a="382066019" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 21 Dec 2014 15:12:08 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBLFC8e5017421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 21 Dec 2014 15:12:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Sun, 21 Dec 2014 09:12:08 -0600 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-05.txt Thread-Index: AQHQHS6TQX/jmA0gOUSKjt+Pgyd/CJyaI7vA Date: Sun, 21 Dec 2014 15:12:07 +0000 Message-ID: References: <20141221145735.2408.52761.idtracker@ietfa.amsl.com> In-Reply-To: <20141221145735.2408.52761.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.77.10] 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/2CoggjP7Tn69AH7CVR24SaVL-vw Subject: Re: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-05.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, 21 Dec 2014 15:12:13 -0000 Dear MPLS WG, The authors have published -05 of draft-akiya-mpls-lsp-ping-lag-multipath, = addressing comments from MPLS-RT review teams (thanks Eric, Mach, Yimin!). The authors believe that the document is in good shape, and we would like t= o request the WG to adopt -05 as a WG document. Here are the highlights of the changes from -04 to 05: * Renamed LAG Interface Info TLV to LSR Capability TLV. * Generalized the usage of the LSR Capability TLV. * Deleted Interface Index Sub-TLV, and created Local Interface Index Sub-TL= V and Remote Interface Index Sub-TLV. * Updated the responder LSR DDMAP procedures to describe the downstream LAG= member link with rules: - The Local Interface Index Sub-TLV is mandatory. - The Remote Interface Index Sub-TLV is optional. - The Multipath Data Sub-TLV is mandatory. * Explicitly state how a responder LSR obtains remote interface index is ou= tside the scope of the document. * The LAG member link traversal validation procedures is split into two app= roaches. - Incoming LAG Member Links Verification (what we had before). - Individual End-to-End Path Verification (newly added). * Update initiator/responder procedures to accommodate above changes. Remaining changes are either minor text changes/additions for better clarif= ications or language corrections. Thanks! Nobo, on behalf of authors > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Sunday, December 21, 2014 9:58 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-05.tx= t >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. >=20 > Title : Label Switched Path (LSP) Ping/Trace Multipath = Support for > Link Aggregation Group (LAG) Interfaces > Authors : Nobo Akiya > George Swallow > Stephane Litkowski > Bruno Decraene > John E. Drake > Filename : draft-akiya-mpls-lsp-ping-lag-multipath-05.txt > Pages : 27 > Date : 2014-12-21 >=20 > Abstract: > This document defines an extension to the MPLS Label Switched Path > (LSP) Ping and Traceroute as specified in RFC 4379. The extension > allows the MPLS LSP Ping and Traceroute to discover and exercise > specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link > Aggregation Group (LAG) interfaces. >=20 > This document updates RFC4379 and RFC6424. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag-multipath/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-multipath-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-lsp-ping-lag-multipat= h- > 05 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Dec 21 07:38: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 7254D1A1A92 for ; Sun, 21 Dec 2014 07:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMBxHpx9Plhf for ; Sun, 21 Dec 2014 07:38:51 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF641A1A8F for ; Sun, 21 Dec 2014 07:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=317; q=dns/txt; s=iport; t=1419176331; x=1420385931; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aFRGlu05BHtl4Y+oqol2b7nLVR36I97NM8MO6YVH5YA=; b=btvBLg3izQFl/BznxS95O8qjeyQYr/Z7PANYJQFtD3pZ4LsIYySLVxPh SPIFvwGOVBxxfilcY0mo8jb1eIWgy8V+0rbo37sq8++FX34YIE7uWWkoM F05a71cCJGYizSkrGQ/M2bLzR2NE659W2jmI1i1vg7R1r0puUprH8LZI+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACnpllStJA2F/2dsb2JhbABbgmQigS7MIwKBERYBAQEBAX2EDQEBAwE6PwULAgEIIhQQMiUCBAENDYgcCAHOJwEBAQEBAQEBAQEBAQEBAQEBAQEBARePQTEHgxaBEwEEjDqBV5o9IoNugjR+AQEB X-IronPort-AV: E=Sophos;i="5.07,617,1413244800"; d="scan'208";a="381688204" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 21 Dec 2014 15:38:32 +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 sBLFcW6N014609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Dec 2014 15:38:32 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Sun, 21 Dec 2014 09:38:32 -0600 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: Closed: [mpls] draft-ietf-mpls-oam-ipv6-rao Thread-Index: AQHQDg+7FuN0w8kOK0Wtda1HmceqApyZ+3KAgABQUqA= Date: Sun, 21 Dec 2014 15:38:32 +0000 Message-ID: References: <547D81A1.30905@pi.nu> <54965155.9010203@pi.nu> In-Reply-To: <54965155.9010203@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.77.10] 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/p9RmuXTFN7D1lKIMaRiR7ShyDl0 Cc: "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] Closed: draft-ietf-mpls-oam-ipv6-rao 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, 21 Dec 2014 15:38:52 -0000 Hi Loa, > This wglc is closed, we only have supporting responses. Can (one of) the > authors confirm that they are ready to go ahead and request publication f= or > this version (-02) of the document. Yes the authors do believe that the version -02 is ready to go ahead. Thanks! -Nobo, Carlos, Kamran From nobody Sun Dec 21 07:59: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 D87C91A1B3D for ; Sun, 21 Dec 2014 07:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBHt-fghElUg for ; Sun, 21 Dec 2014 07:59:25 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56831A1B2F for ; Sun, 21 Dec 2014 07:59:24 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.74.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 24E7D1801591; Sun, 21 Dec 2014 16:59:21 +0100 (CET) Message-ID: <5496EE53.6090009@pi.nu> Date: Sun, 21 Dec 2014 23:59:15 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cqv_4cYvjelrm40CoHevD8Uhj04 Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 15:59:27 -0000 Working Group, This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There is one IPR disclosures directly against this document. All the authors has stated on the working group mailing that they are unaware of any undisclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends January 7, 2015. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Dec 21 08:02: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 6A4FA1A1B53; Sun, 21 Dec 2014 08:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 RDBZjTrHb1oM; Sun, 21 Dec 2014 08:02:23 -0800 (PST) Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496BB1A1B3D; Sun, 21 Dec 2014 08:02:22 -0800 (PST) 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 1Y2ixR-0001Za-Uj; Sun, 21 Dec 2014 18:02:13 +0200 From: Mark Tinka Organization: SEACOM To: "Aissaoui, Mustapha (Mustapha)" Date: Sun, 21 Dec 2014 18:02:13 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412191424.45419.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C48D5@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C48D5@US70UWXCHMBA04.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4135576.2gdEm0gdD0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201412211802.13360.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/A3cB7qF3qQmao56ZItzfBHb3fas Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: 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: Sun, 21 Dec 2014 16:02:25 -0000 --nextPart4135576.2gdEm0gdD0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, December 19, 2014 04:14:17 PM Aissaoui, Mustapha=20 (Mustapha) wrote: > Indeed the reason I raised the issue in the summer was to > make sure we do not disrupt existing LDPv4 deployments > and that we do not need to upgrade a LDPv4 node which > does not comply to this LDPv6 spec. So, both proposed > methods put the onus on the LDPv6 compliant node to > automatically detect a router which is not compliant to > LDPv6 such that it will not send to that node LDP IPv6 > FECs and IPv6 addresses. >=20 > From that perspective, the draft now addressed the issue. > My latest message was raising concerns about the > specific method added to the draft and by which the > LDPv6 compliant LSR goes about addressing the issue. >=20 > I hope this clarifies the situation. Thanks, Mustapha. Mark. --nextPart4135576.2gdEm0gdD0 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) iQIcBAABAgAGBQJUlu8FAAoJEGcZuYTeKm+G63sP/RDM9beCQz2UwOCvsHWb+fSj P+zTnT3HbTfA7WcOtLHfft7MX5FwT5vmY7GdNxPqO5iVY2yWRYhEMOGON42uSSGB pjYt4urM9RViFBTOR01SL4IW/0AtSzPs+ViCA7nEfLnB+CPDaFrGCK/TcYKpClja KJknNKJQNrqObeQ0IK9LHArPqB7M5d1o85ANwIJI0bSJth+qnD5cwuoHobu6IWdg FqtLGEVwUgMejNszKfDZdpCcj39VsgcYBzFpA1Z+11TYnpEkjRoHUJXyO8C/gPZ6 BtlF7oBk/a1sU02XRojOm9J2i5YiA6Vu+HNWpduuiRlU0ttjIZWqUPbrko/JXndN H0rYn5s6zMrHC/dSe2Q2zti+T80HRdsGZiwphnGNmH5dLy7sQi1ZZ2689C3bBOwZ yjpo/ep9qPnkcz9eRLiA6i8J4uAlFGa5TfcbpVR4trvgi3FH1jCaly8wDI4tdRjg NohjRR/HV3b9Yr/oJlXIcNPkT2NKEr73/c6kqiCg9bnTljEIq4UDZbMi08T+UXXN t9BFSR9cfssPE5SSW7mb2AwROo8ngDK1RVYPC7WRciyZaQcSvD2xU0bNa7TB4MFO jS7sIw6SwOQyosKmSEBb/LkDfL+t7b3+J48R1qSiQX758T0u960Aflr9mdAMfNge XEKKqtZTA43ObWdrpNGj =4RJu -----END PGP SIGNATURE----- --nextPart4135576.2gdEm0gdD0-- From nobody Sun Dec 21 10:14: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 777931A1EF1 for ; Sun, 21 Dec 2014 10:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mo1yr12sLDZ for ; Sun, 21 Dec 2014 10:13:56 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B001A1EEE for ; Sun, 21 Dec 2014 10:13:56 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 79B5F3B4F2C; Sun, 21 Dec 2014 19:13:54 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 5FB663840B1; Sun, 21 Dec 2014 19:13:54 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Sun, 21 Dec 2014 19:13:54 +0100 From: To: Loa Andersson Thread-Topic: Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Thread-Index: AQHQHTcaDmbl0sW0nEOiUjceRX50yZyaWKyg Date: Sun, 21 Dec 2014 18:13:53 +0000 Message-ID: <27847_1419185634_54970DE2_27847_14288_1_53C29892C857584299CBF5D05346208A0EADE213@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <5496EE53.6090009@pi.nu> In-Reply-To: <5496EE53.6090009@pi.nu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.21.93920 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EWkkpTVcHJZVU266I7w8KLv_wwg Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 18:13:58 -0000 SGkgTG9hLCBhbGwNCg0KPiBUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBhZG9w dGluZw0KPiBkcmFmdC1ha2l5YS1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGgtMDUgYXMgYW4g TVBMUyB3b3JraW5nIGdyb3VwDQo+IGRvY3VtZW50Lg0KDQpTdXBwb3J0IGFzIGNvLWF1dGhvcjog TEFHIGFyZSBkZXBsb3llZCBpbiBuZXR3b3JrcywgdGhleSBoYXZlIHRvIGJlIHN1cHBvcnRlZC4N Cg0KVGhhbmtzLA0KQnJ1bm8NCg0KPiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBp Lm51XSA+IFNlbnQ6IFN1bmRheSwgRGVjZW1iZXIgMjEsIDIwMTQgNDo1OSBQTQ0KPiANCj4gV29y a2luZyBHcm91cCwNCj4gDQo+IFRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIGFk b3B0aW5nDQo+IGRyYWZ0LWFraXlhLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC0wNSBhcyBh biBNUExTIHdvcmtpbmcgZ3JvdXANCj4gZG9jdW1lbnQuDQo+IA0KPiBQbGVhc2Ugc2VuZCB5b3Vy IGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQo+IGdy b3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2Fs IG1vdGl2YXRpb24gZm9yIHlvdXINCj4gc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBp ZiB5b3UgdGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZQ0KPiBhZG9wdGVkIGFz IGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCj4gDQo+IFRoZXJlIGlzIG9uZSBJUFIgZGlzY2xv c3VyZXMgZGlyZWN0bHkgYWdhaW5zdCB0aGlzIGRvY3VtZW50LiBBbGwgdGhlIGF1dGhvcnMNCj4g aGFzIHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIHRoYXQgdGhleSBhcmUgdW5h d2FyZSBvZiBhbnkNCj4gdW5kaXNjbG9zZWQgSVBScyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+ IA0KPiBIb3dldmVyIGlmIHlvdSBhcmUgb24gdGhlIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFp bGluZyBsaXN0IGFuZCBhd2FyZSBvZg0KPiBJUFIgdGhhdCByZWxhdGVzIHRvIHRoaXMgZHJhZnQs IHRoZSB0aW1lIHRvIGRpc2Nsb3NlIHRoaXMgaXMgbm93Lg0KPiANCj4gVGhpcyBwb2xsIGVuZHMg SmFudWFyeSA3LCAyMDE1Lg0KPiANCj4gL0xvYQ0KPiAtLQ0KPiANCj4gDQo+IExvYSBBbmRlcnNz b24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+ IFNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+ IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAy MSA2NA0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Sun Dec 21 11:44: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 6AE451A6FCF for ; Sun, 21 Dec 2014 11:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO-Z0vZZNH-7 for ; Sun, 21 Dec 2014 11:44:30 -0800 (PST) Received: from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9051A7020 for ; Sun, 21 Dec 2014 11:44:29 -0800 (PST) Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 22 Dec 2014 05:44:24 +1000 Received: from d23dlp02.au.ibm.com (202.81.31.213) by e23smtp07.au.ibm.com (202.81.31.204) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 22 Dec 2014 05:44:22 +1000 Received: from d23relay08.au.ibm.com (d23relay08.au.ibm.com [9.185.71.33]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id EFBBB2BB004D for ; Mon, 22 Dec 2014 06:44:21 +1100 (EST) Received: from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119]) by d23relay08.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sBLJiLtx40501480 for ; Mon, 22 Dec 2014 06:44:21 +1100 Received: from d23av05.au.ibm.com (localhost [127.0.0.1]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sBLJiLcm021386 for ; Mon, 22 Dec 2014 06:44:21 +1100 Received: from d23ml044.nz.ibm.com (d23ml044.nz.ibm.com [9.191.155.151]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id sBLJiLbx021338 for ; Mon, 22 Dec 2014 06:44:21 +1100 In-Reply-To: References: X-KeepSent: C5BC1F1B:5FB631A6-CC257DB5:006A2BB0; type=4; name=$KeepSent To: mpls@ietf.org X-Mailer: IBM Notes Release 9.0.1SHF211 December 19, 2013 Message-ID: From: Sean Muller Date: Mon, 22 Dec 2014 08:22:39 +1300 X-MIMETrack: Serialize by Router on d23ml044/23/M/IBM(Release 9.0.1|October 14, 2013) at 22/12/2014 08:44:20 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14122119-0025-0000-0000-000000C9A666 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QmIibLZrblEG3FNle5zrt43VSRU Subject: [mpls] help 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, 21 Dec 2014 19:44:35 -0000 unsubscribe From: mpls-request@ietf.org To: mpls@ietf.org Date: 22/12/2014 07:14 a.m. Subject: mpls Digest, Vol 128, Issue 50 Sent by: "mpls" Send mpls mailing list submissions to mpls@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/mpls or, via email, send a message with subject or body 'help' to mpls-request@ietf.org You can reach the person managing the list at mpls-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mpls digest..." Today's Topics: 1. Closed: draft-ietf-mpls-oam-ipv6-rao (Loa Andersson) 2. Update:: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt (Loa Andersson) 3. I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-05.txt (internet-drafts@ietf.org) 4. Re: I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-05.txt (Nobo Akiya (nobo)) 5. Re: Closed: draft-ietf-mpls-oam-ipv6-rao (Nobo Akiya (nobo)) 6. Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document (Loa Andersson) 7. Re: Last Call: (Updates to LDP for IPv6) to Proposed Standard (Mark Tinka) 8. Re: Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document (bruno.decraene@orange.com) ---------------------------------------------------------------------- Message: 1 Date: Sun, 21 Dec 2014 12:49:25 +0800 From: Loa Andersson To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Cc: "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: [mpls] Closed: draft-ietf-mpls-oam-ipv6-rao Message-ID: <54965155.9010203@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Working Group, This wglc is closed, we only have supporting responses. Can (one of) the authors confirm that they are ready to go ahead and request publication for this version (-02) of the document. /Loa On 2014-12-02 17:08, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-oam-ipv6-rao. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There is no IPR disclosures against this document. All the authors > 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 December 16, 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 ------------------------------ Message: 2 Date: Sun, 21 Dec 2014 13:43:39 +0800 From: Loa Andersson To: "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , draft-atlas-mpls-ldp-mrt@tools.ietf.org Subject: [mpls] Update:: poll to see if we have consensus to adopt draft-atlas-mpls-ldp-mrt Message-ID: <54965E0B.3050701@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Working Group, This is to notify that all authors has now responded to the IPR poll, they are all unaware of any IPRs that relate to this document. /Loa On 2014-12-16 13:51, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-atlas-mpls-ldp-mrt-03 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is no IPR disclosures directly against this document. An IPR > poll will be done in parallel to the adoption poll, and the adoption > poll will not be closed before we have responses from all authors. > > If you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, you should respond to the > IPR poll. > > This poll ends January 2, 2015. > > /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 ------------------------------ Message: 3 Date: Sun, 21 Dec 2014 06:57:35 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-05.txt Message-ID: <20141221145735.2408.52761.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces Authors : Nobo Akiya George Swallow Stephane Litkowski Bruno Decraene John E. Drake Filename : draft-akiya-mpls-lsp-ping-lag-multipath-05.txt Pages : 27 Date : 2014-12-21 Abstract: This document defines an extension to the MPLS Label Switched Path (LSP) Ping and Traceroute as specified in RFC 4379. The extension allows the MPLS LSP Ping and Traceroute to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. This document updates RFC4379 and RFC6424. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag-multipath/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-multipath-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-akiya-mpls-lsp-ping-lag-multipath-05 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/ ------------------------------ Message: 4 Date: Sun, 21 Dec 2014 15:12:07 +0000 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-05.txt Message-ID: Content-Type: text/plain; charset="us-ascii" Dear MPLS WG, The authors have published -05 of draft-akiya-mpls-lsp-ping-lag-multipath, addressing comments from MPLS-RT review teams (thanks Eric, Mach, Yimin!). The authors believe that the document is in good shape, and we would like to request the WG to adopt -05 as a WG document. Here are the highlights of the changes from -04 to 05: * Renamed LAG Interface Info TLV to LSR Capability TLV. * Generalized the usage of the LSR Capability TLV. * Deleted Interface Index Sub-TLV, and created Local Interface Index Sub-TLV and Remote Interface Index Sub-TLV. * Updated the responder LSR DDMAP procedures to describe the downstream LAG member link with rules: - The Local Interface Index Sub-TLV is mandatory. - The Remote Interface Index Sub-TLV is optional. - The Multipath Data Sub-TLV is mandatory. * Explicitly state how a responder LSR obtains remote interface index is outside the scope of the document. * The LAG member link traversal validation procedures is split into two approaches. - Incoming LAG Member Links Verification (what we had before). - Individual End-to-End Path Verification (newly added). * Update initiator/responder procedures to accommodate above changes. Remaining changes are either minor text changes/additions for better clarifications or language corrections. Thanks! Nobo, on behalf of authors > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Sunday, December 21, 2014 9:58 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-lag-multipath-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > Title : Label Switched Path (LSP) Ping/Trace Multipath Support for > Link Aggregation Group (LAG) Interfaces > Authors : Nobo Akiya > George Swallow > Stephane Litkowski > Bruno Decraene > John E. Drake > Filename : draft-akiya-mpls-lsp-ping-lag-multipath-05.txt > Pages : 27 > Date : 2014-12-21 > > Abstract: > This document defines an extension to the MPLS Label Switched Path > (LSP) Ping and Traceroute as specified in RFC 4379. The extension > allows the MPLS LSP Ping and Traceroute to discover and exercise > specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link > Aggregation Group (LAG) interfaces. > > This document updates RFC4379 and RFC6424. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag-multipath/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-multipath-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-akiya-mpls-lsp-ping-lag-multipath- > 05 > > > 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 ------------------------------ Message: 5 Date: Sun, 21 Dec 2014 15:38:32 +0000 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Cc: "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] Closed: draft-ietf-mpls-oam-ipv6-rao Message-ID: Content-Type: text/plain; charset="us-ascii" Hi Loa, > This wglc is closed, we only have supporting responses. Can (one of) the > authors confirm that they are ready to go ahead and request publication for > this version (-02) of the document. Yes the authors do believe that the version -02 is ready to go ahead. Thanks! -Nobo, Carlos, Kamran ------------------------------ Message: 6 Date: Sun, 21 Dec 2014 23:59:15 +0800 From: Loa Andersson To: "mpls@ietf.org" Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Message-ID: <5496EE53.6090009@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Working Group, This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There is one IPR disclosures directly against this document. All the authors has stated on the working group mailing that they are unaware of any undisclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends January 7, 2015. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 ------------------------------ Message: 7 Date: Sun, 21 Dec 2014 18:02:13 +0200 From: Mark Tinka To: "Aissaoui, Mustapha (Mustapha)" Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Updates to LDP for IPv6) to Proposed Standard Message-ID: <201412211802.13360.mark.tinka@seacom.mu> Content-Type: text/plain; charset="us-ascii" On Friday, December 19, 2014 04:14:17 PM Aissaoui, Mustapha (Mustapha) wrote: > Indeed the reason I raised the issue in the summer was to > make sure we do not disrupt existing LDPv4 deployments > and that we do not need to upgrade a LDPv4 node which > does not comply to this LDPv6 spec. So, both proposed > methods put the onus on the LDPv6 compliant node to > automatically detect a router which is not compliant to > LDPv6 such that it will not send to that node LDP IPv6 > FECs and IPv6 addresses. > > From that perspective, the draft now addressed the issue. > My latest message was raising concerns about the > specific method added to the draft and by which the > LDPv6 compliant LSR goes about addressing the issue. > > I hope this clarifies the situation. Thanks, Mustapha. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: < http://www.ietf.org/mail-archive/web/mpls/attachments/20141221/17cc4be3/attachment.asc > ------------------------------ Message: 8 Date: Sun, 21 Dec 2014 18:13:53 +0000 From: To: Loa Andersson Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Message-ID: <27847_1419185634_54970DE2_27847_14288_1_53C29892C857584299CBF5D05346208A0EADE213@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="utf-8" Hi Loa, all > This is to start a two week poll on adopting > draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group > document. Support as co-author: LAG are deployed in networks, they have to be supported. Thanks, Bruno > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Sunday, December 21, 2014 4:59 PM > > Working Group, > > This is to start a two week poll on adopting > draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group > document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical motivation for your > support/not support, especially if you think that the document should not be > adopted as a working group document. > > There is one IPR disclosures directly against this document. All the authors > has stated on the working group mailing that they are unaware of any > undisclosed IPRs against this document. > > However if you are on the the mpls working group mailing list and aware of > IPR that relates to this draft, the time to disclose this is now. > > This poll ends January 7, 2015. > > /Loa > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ------------------------------ Subject: Digest Footer _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------------------------------ End of mpls Digest, Vol 128, Issue 50 ************************************* From nobody Sun Dec 21 20:01: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 42EED1A0095 for ; Sun, 21 Dec 2014 20:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXCd_0R18SHL for ; Sun, 21 Dec 2014 20:01:17 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549C21A008F for ; Sun, 21 Dec 2014 20:01:17 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.74.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 14ECF1801591; Mon, 22 Dec 2014 05:01:13 +0100 (CET) Message-ID: <54979784.5010902@pi.nu> Date: Mon, 22 Dec 2014 12:01:08 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" References: <547D81A1.30905@pi.nu> <54965155.9010203@pi.nu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Ip4PaDL1pBMJ4BbeqPYRmEkoEGI Cc: "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] Closed: draft-ietf-mpls-oam-ipv6-rao 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, 22 Dec 2014 04:01:19 -0000 Nobo, Tnx - it will take me a couple of days to do the Shepherd Write-up. /Loa On 2014-12-21 23:38, Nobo Akiya (nobo) wrote: > Hi Loa, > >> This wglc is closed, we only have supporting responses. Can (one of) the >> authors confirm that they are ready to go ahead and request publication for >> this version (-02) of the document. > > Yes the authors do believe that the version -02 is ready to go ahead. > > Thanks! > > -Nobo, Carlos, Kamran > -- 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 Dec 21 20:06: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 56E631A009E for ; Sun, 21 Dec 2014 20:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rndNN_Nz9Kc9 for ; Sun, 21 Dec 2014 20:05:59 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313971A0097 for ; Sun, 21 Dec 2014 20:05:59 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.74.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D33301801591; Mon, 22 Dec 2014 05:05:55 +0100 (CET) Message-ID: <5497989A.7020601@pi.nu> Date: Mon, 22 Dec 2014 12:05:46 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hfdHdlrQIRKiXFHlueX8zt6qQrQ Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: [mpls] Implementation poll on draft-ietf-mpls-oam-ipv6-rao 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, 22 Dec 2014 04:06:00 -0000 Working Group, We are preparing draft-ietf-mpls-oam-ipv6-rao for publication request. One of the questions we have to answer in the Shepherds Write-up is if there are any existing implementations. This is to start an implementation poll on draft-ietf-mpls-oam-ipv6-rao. If you have an implementation or know about one, please send the information to the mpls wg mailing list or to the mpls wg chairs. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 22 05:36: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 3BB7D1A8F39 for ; Mon, 22 Dec 2014 05:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-MkavOqXrAA for ; Mon, 22 Dec 2014 05:36:16 -0800 (PST) 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 20E4C1A8F38 for ; Mon, 22 Dec 2014 05:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2090; q=dns/txt; s=iport; t=1419255376; x=1420464976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bU9Gkx+/HEXmpr1IB+a4cisxwhMJziTVZfKXPPlOx+k=; b=FtMdW0sYmoCkxtHCFwoOm7yUDJKd2qg9G8rwqUb9Woa4cBCLuiuxMb1K bvG3WUnZZ5gIxAXKqyMs9mH+dXI8CGW0qYEcipV4plpwemdzTzk/bfcCu uPJhCeWip1x6+4sI+qu0LRSJ2e9dA+ImtRdIBgaNmm6JZqe6z7hbBKyXs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwFAJ4dmFStJA2E/2dsb2JhbABbgmQigSoEgwDJMwIcfxYBAQEBAX2EDAEBAQQjETcDCwwCAgIBCBEEAQEDAgYdAwICAhkXFAEICAIEAQ0FCIgkAblXlXMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIEdjW8RAR8WGwcGgmIugRMBBIw6gVeJf4Jkh0uGDyKDbm+BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="107539397" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 22 Dec 2014 13:36:15 +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 sBMDaFoS026843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 13:36:15 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 07:36:15 -0600 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: Implementation poll on draft-ietf-mpls-oam-ipv6-rao Thread-Index: AQHQHZyZOHRWul57XECPpeoIBhxOvZybmnQA Date: Mon, 22 Dec 2014 13:36:14 +0000 Message-ID: References: <5497989A.7020601@pi.nu> In-Reply-To: <5497989A.7020601@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2O5hUXVomC0fkSQUHszIYSBq3aE Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] Implementation poll on draft-ietf-mpls-oam-ipv6-rao 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, 22 Dec 2014 13:36:18 -0000 SGkgTG9hLA0KDQpDaXNjbyBoYXMgaW1wbGVtZW50ZWQgTFNQIFBpbmcvVHJhY2Vyb3V0ZSBtb2Rp ZmljYXRpb25zIHRvIHN1cHBvcnQgTERQIElQdjYsIGR1cmluZyB3aGljaCB3ZSBmb3VuZCB0aGUg bGFjayBvZiBJUHY2IFJBTyBhdmFpbGFiaWxpdHkgZm9yIE1QTFMgT0FNLiBUaGUgcGxhbiBpcyB0 byB1cGRhdGUgdGhpcyBpbXBsZW1lbnRhdGlvbiBvbmNlIGRyYWZ0LWlldGYtbXBscy1vYW0taXB2 Ni1yYW8gcHJvZ3Jlc3NlcyAod2hpY2ggYWxyZWFkeSBoYXMpIGFuZCB0aGUgY29kZSBwb2ludCBo YXMgYmVlbiBhbGxvY2F0ZWQgKHdoaWNoIGhhcyBub3QgYmVlbiBkb25lKS4gU28gdGhlIGhvb2tz IGFyZSBpbiBwbGFjZSwgYnV0IHRoZSBhbnN3ZXIgaXMgbm90IGEgY29tcGxldGUgInllcyIuIEhv d2V2ZXIsIGR1ZSB0byB0aGUgbmF0dXJlIG9mIHRoaXMgZG9jdW1lbnQgKGkuZS4sIGRlZmluZXMg YSBjb2RlIHBvaW50IGJ1dCBhYnNvbHV0ZWx5IG5vIHByb2NlZHVyZXMpLCBJIGhvcGUgdGhhdCB0 aGUgZG9jdW1lbnQgY2FuIHN0aWxsIHByb2dyZXNzLg0KDQpUaGFua3MhDQoNCi1Ob2JvDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9hIEFuZGVyc3NvbiBbbWFpbHRv OmxvYUBwaS5udV0NCj4gU2VudDogU3VuZGF5LCBEZWNlbWJlciAyMSwgMjAxNCAxMTowNiBQTQ0K PiBUbzogbXBsc0BpZXRmLm9yZw0KPiBDYzogbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRy YWZ0LWlldGYtbXBscy1vYW0taXB2Ni1yYW9AdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogSW1w bGVtZW50YXRpb24gcG9sbCBvbiBkcmFmdC1pZXRmLW1wbHMtb2FtLWlwdjYtcmFvDQo+IA0KPiBX b3JraW5nIEdyb3VwLA0KPiANCj4gV2UgYXJlIHByZXBhcmluZyBkcmFmdC1pZXRmLW1wbHMtb2Ft LWlwdjYtcmFvIGZvciBwdWJsaWNhdGlvbiByZXF1ZXN0Lg0KPiBPbmUgb2YgdGhlIHF1ZXN0aW9u cyB3ZSBoYXZlIHRvIGFuc3dlciBpbiB0aGUgU2hlcGhlcmRzIFdyaXRlLXVwIGlzIGlmDQo+IHRo ZXJlIGFyZSBhbnkgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLg0KPiANCj4gVGhpcyBpcyB0byBz dGFydCBhbiBpbXBsZW1lbnRhdGlvbiBwb2xsIG9uIGRyYWZ0LWlldGYtbXBscy1vYW0taXB2Ni1y YW8uDQo+IElmIHlvdSBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9yIGtub3cgYWJvdXQgb25lLCBw bGVhc2Ugc2VuZCB0aGUNCj4gaW5mb3JtYXRpb24gdG8gdGhlIG1wbHMgd2cgbWFpbGluZyBsaXN0 IG9yIHRvIHRoZSBtcGxzIHdnIGNoYWlycy4NCj4gDQo+IC9Mb2ENCj4gZm9yIHRoZSBtcGxzIHdn IGNvLWNoYWlycw0KPiAtLQ0KPiANCj4gDQo+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAg ICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+IFNlbmlvciBNUExTIEV4cGVy dCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+IEh1YXdlaSBUZWNobm9sb2dp ZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K From nobody Mon Dec 22 07:43: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 553B91A912F for ; Mon, 22 Dec 2014 07:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb66AKjd4r-Z for ; Mon, 22 Dec 2014 07:43:13 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336D41A912D for ; Mon, 22 Dec 2014 07:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1469; q=dns/txt; s=iport; t=1419262993; x=1420472593; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O2oku5R8mrZirpCyFgqFH4/yw+zW058AhDQ6pCemOu8=; b=CmH1VfO3GzkEhZW3q06BFv94GRGMzx2OWsQaOe+YXk9qoUTsDG1J8c3U u5MFbnEwJisML9V6ZuHqeI14uVqH5u96eCBdF8wtFXNelkBspqKgkKLgT ae2B2iGMQkhKY1RoYwlj/+AKUbbvR/LlrTxFDcZESDzi37KsSHL3j+HWb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFACA7mFStJA2D/2dsb2JhbABbgmQiUljEIoIbCoRigQ4CgRkWAQEBAQF9hAwBAQEDAQEBATcxAwsFCQICAQgYHgULGwwLJQIEDgWIJAgBDNALAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEjwwRAR0zB4MWgRMFjhGIcoENgmSKIYM5IoIygTxvgQyBNwEBAQ X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="107525640" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP; 22 Dec 2014 15:43:11 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBMFhB1A024131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 15:43:11 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 09:43:10 -0600 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Thread-Index: AQHQHTckx666jT06a0a5I2X0lmkb4JybwYvy Date: Mon, 22 Dec 2014 15:43:10 +0000 Message-ID: <79A94E24-2B63-4016-95CF-F113A2FA0BD3@cisco.com> References: <5496EE53.6090009@pi.nu> In-Reply-To: <5496EE53.6090009@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/EUvB2ybDi_djjSMCHSVtga8LNRU Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 15:43:15 -0000 Loa, I support adoption of this document. LAGs are widely deployed and this docu= ment addresses a real issue.=20 Thanks, Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Dec 21, 2014, at 10:59 AM, Loa Andersson wrote: >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-akiya-mpls-lsp-ping-lag-multipath-05 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 disclosures directly against this document. All the > authors has stated on the working group mailing that they are unaware of > any undisclosed IPRs against this document. >=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 January 7, 2015. >=20 > /Loa > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Dec 22 08:52: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 571501A1A92 for ; Mon, 22 Dec 2014 08:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM8QVMm7NxfV for ; Mon, 22 Dec 2014 08:52:46 -0800 (PST) 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 8B9681A1A8E for ; Mon, 22 Dec 2014 08:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1308; q=dns/txt; s=iport; t=1419267166; x=1420476766; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=U3qZqrD8JapJTG2Huey0d5zKTru5ZjFAUgjO1/kKZvc=; b=MK8L8e+dH85QL57beFfb6Q8YEYrWZlcXR0qbW2z+NFxLKUlT/Imwm5y+ /b8a74MoTBbmEb/WZGcqQoxB2mprDuDDovM0h98t0ZlnJEBF53mcTxYSf U3QEHFRf8/2TZ3oFGa9QHOCSjrelhE27ohwxVBLgfJxOS4HpiQAYbv4xr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAElLmFStJA2B/2dsb2JhbABRCoMGUlgExCCCGwqEYoEOAoEZFgEBAQEBfYQNAQEEAQEBNzEDCw4EAQg2BSYMCyUCBAENBYgsDdAFAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEjwwGCwFQB4QpBY4RiHKBDYJkiiGDOSKCMoE8b4EMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="378828030" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP; 22 Dec 2014 16:52:45 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBMGqj96007987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 16:52:45 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.194]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 10:52:45 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Thread-Index: AQHQHTcl9AvzHZp2t0WsdZYR7CgkFJyb5b4A Date: Mon, 22 Dec 2014 16:52:44 +0000 Message-ID: In-Reply-To: <5496EE53.6090009@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.203.112] Content-Type: text/plain; charset="us-ascii" Content-ID: <7027802A635A9D4588CF9A1E5C5E2419@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/r0P53cin1KsFHFc0p1eDbjyf9QU Cc: "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 16:52:48 -0000 Hi, Support. Having a way to identify LAG multi path (in LSP) is good. Thanks, Nagendra On 12/21/14, 10:59 AM, "Loa Andersson" wrote: >Working Group, > >This is to start a two week poll on adopting >draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group >document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls@ietf.org). Please give a technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >There is one IPR disclosures directly against this document. All the >authors has stated on the working group mailing that they are unaware of >any undisclosed IPRs against this document. > >However if you are on the the mpls working group mailing list and >aware of IPR that relates to this draft, the time to disclose >this is now. > >This poll ends January 7, 2015. > >/Loa >--=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 Mon Dec 22 11:08: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 22ADF1A6F2B for ; Mon, 22 Dec 2014 11:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq2vcN0CTkXz for ; Mon, 22 Dec 2014 11:07:54 -0800 (PST) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E093D1A3B9F for ; Mon, 22 Dec 2014 11:07:53 -0800 (PST) Received: by mail-yh0-f45.google.com with SMTP id f10so2555625yha.18 for ; Mon, 22 Dec 2014 11:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=lLUqbj/mhSsMJrBtRRCXhyWy5lcEYoLqTv/iFs6cw+8=; b=MGaUeR9CFaygdYWagOne4zu/RE1pyGH37e2Z95IxjYkyHsSYVJc/KcNQzPcv37/aCR YHNSyaGl2YKBqX9uOAiH4dUXAHXAm/QCH+TreYmbbLFGDQyWGK68ujapYFYIb8zs+3R7 x16at8wcjjvHq4N+siXdI/8VJDi8N1rPz543HL+N9pe4NVb3qD0MPX6Rrk7d7kofyFiP jKO/xZOZNHbD8qfrfZqTrewk6T7oK1cGZxEriQ3r6wK1wzu1t7JQXGSJRmXQZhX/e4nu Hebw/VEbBLzAzAKNKIReAmw4DKcp0IyCNNUqGT3XY9rfkbOw/ZKN9HEaqvqQgQHaAygJ HZZg== MIME-Version: 1.0 X-Received: by 10.170.218.212 with SMTP id k203mr21303924ykf.15.1419275273066; Mon, 22 Dec 2014 11:07:53 -0800 (PST) Received: by 10.170.133.18 with HTTP; Mon, 22 Dec 2014 11:07:53 -0800 (PST) Date: Mon, 22 Dec 2014 14:07:53 -0500 Message-ID: From: Alia Atlas To: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-in-udp@tools.ietf.org, Loa Andersson , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a113a83b67d6137050ad2c681 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/r3bTd3SFJ8KddQI44WenE8Z0AKM Subject: [mpls] AD review of draft-ietf-mpls-in-udp-09 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, 22 Dec 2014 19:07:59 -0000 --001a113a83b67d6137050ad2c681 Content-Type: text/plain; charset=UTF-8 As usual, I have done my AD review of this draft before progressing it to IETF Last Call. I have a few minor comments, as given below, but nothing that prevents my requesting an IETF Last Call now. Due to the holidays, I will ask for that to end about Jan 12. Thanks very much for the hard work on this draft - finding a good way forward that clearly articulates the trade-offs and considerations wasn't easy. Please address my comments along with IETF Last Call concerns. Minor comments: 1) In the abstract, "MPLS-in-UDP is primarily applicable to service provider networks" but when this was first discussed, at least, I believe it was targeting data center networks also. Has that changed? Similarly in Sec 1.3, it says "The MPLS-in-UDP encapsulation technology MUST only be deployed within a Service Provider (SP) network..." I certainly agree that it shouldn't escape into the open Internet, but am concerned that the applicability doesn't also apply to data-center networks. Sec 3.1 is also focused on service provider networks, though at least corporate networks are mentioned. 2) In Sec 3.1, it says "This check will often be part of the MPLS LSR forwarding logic, but MUST be scoped to the specific tunnel." I do not understand what this scoping means? The MPLS labels are frequently per-platform, though of course context-labels and per-interface labels are also used. For the per-platform labels, is new behavior expected??? 3) In Sec 4, it says: "That is to say, if the destination IP address is a multicast address, the top label SHOULD be upstream-assigned, otherwise if the destination IP address is a ..." This seems to require that the IP network is capable of supporting multicast where one can easily see using MPLS-in-UDP tunnels to provide point-to-point tunnels. Is there a reason that the negotiation mechanism to set up the MPLS-in-UDP tunnel wouldn't also be able to specify alternate destination IP addresses for upstrteam-assigned? How much discussion and agreement has this limitation had?? 4) I notice a difference in the applicability statement and Sec 5. In the former, no use of MPLS-in-UDP on the general Internet is allowed, but in the latter, if the MPLS has only congestion-controlled traffic, then it is permitted. Given the current agreed text in Sec 5, perhaps an additional sentence in Sec 5 along the lines of "Despite this discussion of which MPLS traffic may be congestion-controlled for network deployment considerations, as previously specified in Sec 1.3, the MPLS-in-UDP encapsulation technology MUST NOT be used across the open Internet." Thanks, Alia --001a113a83b67d6137050ad2c681 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As usual, I have done my AD review of this draft befo= re progressing it to IETF Last Call.=C2=A0 I have a few minor comments, as = given below, but nothing that prevents my requesting an IETF Last Call now.= =C2=A0 Due to the holidays, I will ask for that to end about Jan 12.
<= div>
Thanks very much for the hard work on this draft - findi= ng a good way forward that clearly articulates the trade-offs and considera= tions wasn't easy.

Please address my comments = along with IETF Last Call concerns.

Minor comments= :

1) In the abstract, "MPLS-= in-UDP is primarily applicable to service provider networks" =C2=A0but= when this was first discussed, at least, I believe it was targeting data c= enter networks also.=C2=A0 Has that changed?

Similarly in Sec 1.3, it says "The MP= LS-in-UDP encapsulation technology MUST only be deployed within=C2=A0a Service Provider (SP) network..." =C2=A0I certainly agree that= it shouldn't escape into the open Internet, but am concerned that the = applicability doesn't also apply to data-center networks. =C2=A0=

Sec 3.1 is also focused= on service provider networks, though at least=C2=A0corporate=C2=A0networks are mentioned.
=C2=A0
2) In Sec 3.1, it says "This check w= ill often be=C2=A0part of the MPLS LSR forwarding logic, but MU= ST be scoped to the=C2=A0specific tunnel." =C2=A0I do not = understand what this scoping means?=C2=A0 The MPLS labels are frequently pe= r-platform, though of course context-labels and per-interface labels are al= so used.=C2=A0 For the per-platform labels, is new behavior expected???

3) In Sec 4, it says:<= /div>
"That is to say, if the=C2=A0= destination IP address is a multicast address, the top label SHOULD<= span style=3D"color:rgb(0,0,0);font-size:12.7272720336914px;line-height:1.2= em">=C2=A0be upstream-assigned, otherwise if the destination IP address is = a ..." =C2=A0 This seems to require that the IP network is capable of = supporting multicast where one can easily see using MPLS-in-UDP tunnels to = provide point-to-point tunnels.=C2=A0 Is there a reason that the negotiatio= n mechanism to set up the MPLS-in-UDP tunnel wouldn't also be able to s= pecify alternate destination IP addresses for upstrteam-assigned?=C2=A0 How= much discussion and agreement has this limitation had??
<= span style=3D"color:rgb(0,0,0);font-size:12.7272720336914px;line-height:1.2= em">
4) I notice a difference in the applicabilit= y statement and Sec 5.=C2=A0 In the former, no use of MPLS-in-UDP on the ge= neral Internet is allowed, but in the latter, if the MPLS has only congesti= on-controlled traffic, then it is permitted.=C2=A0 Given the current agreed= text in Sec 5, perhaps an additional sentence in Sec 5 along the lines of= =C2=A0

"Despite this discussion of which= MPLS traffic may be congestion-controlled for network deployment considera= tions, as previously specified in Sec 1.3, the MPLS-in-UDP encapsulation te= chnology MUST NOT be used across the open Internet."=C2=A0

Thanks,
Alia
--001a113a83b67d6137050ad2c681-- From nobody Mon Dec 22 11:11: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 A0FBB1A1EE9 for ; Mon, 22 Dec 2014 11:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f2zIDFNSMZs; Mon, 22 Dec 2014 11:11:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D074F1A6EEC; Mon, 22 Dec 2014 11:11:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, "Loa Andersson" , mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141222191114.9415.24104.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 11:11:14 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rUC14efbRUSfEs4UFT6ZgpzYzfA Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 19:11:28 -0000 IESG state changed to Last Call Requested from Waiting for AD Go-Ahead::Point Raised - writeup needed Please issue the IETF Last Call for 3 weeks, due to the end of year holidays. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ From nobody Mon Dec 22 11:11: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 C9A8A1A916A; Mon, 22 Dec 2014 11:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69-d7l65lYeS; Mon, 22 Dec 2014 11:11:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DBA1A6EE7; Mon, 22 Dec 2014 11:11:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org, "Loa Andersson" , iesg-secretary@ietf.org, iesg@ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141222191125.6487.48383.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 11:11:25 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HXcKJttCtedA-nBVc2rYOw_2HzA Subject: [mpls] Telechat update notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 19:11:40 -0000 Placed on agenda for telechat - 2015-01-22 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ From nobody Mon Dec 22 12:03: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 AF4891A6FF0; Mon, 22 Dec 2014 12:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l--HkWh2xFJb; Mon, 22 Dec 2014 12:03:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5981A1BD4; Mon, 22 Dec 2014 12:03:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141222200352.32605.36332.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 12:03:52 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2q5q0U1R2X4ziXDRCQ3g-hgrPfg Cc: mpls@ietf.org Subject: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 20:03:55 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Encapsulating MPLS in UDP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-01-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol) for situations where UDP encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. MPLS- in-UDP is primarily applicable to service provider networks, and additional restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1941/ http://datatracker.ietf.org/ipr/2198/ From nobody Mon Dec 22 12:04: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 C7BE21A6FC9 for ; Mon, 22 Dec 2014 12:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzgaxAxVBXtG; Mon, 22 Dec 2014 12:03:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9129B1A6FEA; Mon, 22 Dec 2014 12:03:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org, "Loa Andersson" , mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141222200354.32605.52231.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 12:03:54 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_3LHmITYe3vdTpEic8lf0qDjIn8 Subject: [mpls] ID Tracker State Update Notice: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 20:03:58 -0000 Last call has been made for draft-ietf-mpls-in-udp and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ From nobody Mon Dec 22 13:28: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 1436C1A8739 for ; Mon, 22 Dec 2014 13:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVuSNiCNcTPu for ; Mon, 22 Dec 2014 13:28:19 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C761A874F for ; Mon, 22 Dec 2014 13:28:18 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id m20so3856764qcx.26 for ; Mon, 22 Dec 2014 13:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sD7rHiJzs6FM8CarpOO3FnjEM7tISpqIrZ0G935ZzGs=; b=uC9QJzzQNXAfmD0yCYFNYyHIgOh0E9ronN0HIGtA7RNYLMV5DSJ3d/rCyPTYw2TFUs XG2Q2k4WiKsu287udoqu6ieyZ44jCQpoXcOpl9ymgAb22iwvVEquXjFHIpCEuf/xM+7u fpzSZoYjaBtzR5KpAtmBJEYZXP2Xn9hYmsNVlKkGQUj/MG9AfY8ribxaOYnBQg0kajw2 AzJfneLZQP0w5bXj84Akbl4p4eRD9iQMwQb7P4+zPAIXTanfkpkffFGscjOPnLRH1F8J rd9phk8SP6IQ1LK6eB7eDQT0f2yseCzeWNlNUMIqupfIICYoNYlW9+lUfYJ2uKk2k/7V xNGw== MIME-Version: 1.0 X-Received: by 10.140.25.169 with SMTP id 38mr37405332qgt.57.1419283698159; Mon, 22 Dec 2014 13:28:18 -0800 (PST) Received: by 10.96.65.5 with HTTP; Mon, 22 Dec 2014 13:28:18 -0800 (PST) In-Reply-To: <5496EE53.6090009@pi.nu> References: <5496EE53.6090009@pi.nu> Date: Mon, 22 Dec 2014 13:28:18 -0800 Message-ID: From: Sam Aldrin To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11c12cdcaa1814050ad4bc8e Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ni1h12-3BRXGTYylDCPywfFXowI Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 21:28:21 -0000 --001a11c12cdcaa1814050ad4bc8e Content-Type: text/plain; charset=UTF-8 The problem area is valid and solving those problems will help in LAG deployments. There is definitely potential for the ID to create a more deterministic solution and WG group could take it up from here. Hence, I support its adoption. -sam On Sun, Dec 21, 2014 at 7:59 AM, Loa Andersson wrote: > > Working Group, > > This is to start a two week poll on adopting > draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group > document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is one IPR disclosures directly against this document. All the > authors has stated on the working group mailing that they are unaware of > any undisclosed IPRs against this document. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends January 7, 2015. > > /Loa > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11c12cdcaa1814050ad4bc8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The problem area is valid and solving those problems will = help in LAG deployments.
There is definitely potential for the ID to cr= eate a more deterministic solution and WG group could take it up from here.=
Hence, I support its adoption.

-sam=C2= =A0

On= Sun, Dec 21, 2014 at 7:59 AM, Loa Andersson <loa@pi.nu> wrote:Working Group,

This is to start a two week poll on adopting
draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group<= br> document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There is one IPR disclosures directly against this document. All the
authors has stated on the working group mailing that they are unaware of any undisclosed IPRs against this document.

However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

This poll ends January 7, 2015.

/Loa
--


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

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
--001a11c12cdcaa1814050ad4bc8e-- From nobody Mon Dec 22 19: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 C03D71ACD3D for ; Mon, 22 Dec 2014 19:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZDQyRjmQ5IN for ; Mon, 22 Dec 2014 19:42:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB211A0055 for ; Mon, 22 Dec 2014 19:42:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNE99583; Tue, 23 Dec 2014 03:42:34 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 23 Dec 2014 03:42:34 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Tue, 23 Dec 2014 11:42:29 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Thread-Index: AQHQHTciyj+BY8qWTEuyFtE60OzDZpyciiig Date: Tue, 23 Dec 2014 03:42:29 +0000 Message-ID: References: <5496EE53.6090009@pi.nu> In-Reply-To: <5496EE53.6090009@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/nk0XpLGZZ8PKLSdf6vy-Tfzvw-Q Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 03:42:38 -0000 Hi, I have read the draft and support the adoption of the draft. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Sunday, December 21, 2014 11:59 PM > To: mpls@ietf.org > Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus to adopt > draft-akiya-mpls-lsp-ping-lag-multipath as a working group document >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group docum= ent. >=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 disclosures directly against this document. All the auth= ors has > stated on the working group mailing that they are unaware of any undisclo= sed > IPRs against this document. >=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 January 7, 2015. >=20 > /Loa > -- >=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 Dec 23 05:10: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 61C331A1A28 for ; Tue, 23 Dec 2014 05:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7FLWyYE8EM4 for ; Tue, 23 Dec 2014 05:10:43 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC051A8A72 for ; Tue, 23 Dec 2014 05:01:00 -0800 (PST) Received: from SN2PR0501MB1070.namprd05.prod.outlook.com (25.160.59.15) by SN2PR0501MB1072.namprd05.prod.outlook.com (25.160.59.151) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 23 Dec 2014 13:00:59 +0000 Received: from SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) by SN2PR0501MB1070.namprd05.prod.outlook.com ([25.160.59.15]) with mapi id 15.01.0031.000; Tue, 23 Dec 2014 13:00:59 +0000 From: Yimin Shen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Thread-Index: AQHQHTce6PAHpndAREKSbtKrPPwcu5ydI15w Date: Tue, 23 Dec 2014 13:00:59 +0000 Message-ID: References: <5496EE53.6090009@pi.nu> In-Reply-To: <5496EE53.6090009@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] authentication-results: spf=none (sender IP is ) smtp.mailfrom=yshen@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0501MB1072; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:SN2PR0501MB1072; x-forefront-prvs: 04347F8039 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(252514010)(164054003)(189002)(377454003)(199003)(120916001)(101416001)(99396003)(31966008)(2900100001)(99286002)(54356999)(46102003)(40100003)(64706001)(33656002)(76176999)(74316001)(77156002)(230783001)(19580405001)(20776003)(105586002)(68736005)(106356001)(107046002)(2501002)(122556002)(54206007)(97736003)(15975445007)(102836002)(62966003)(86362001)(76576001)(50986999)(4396001)(2656002)(106116001)(54606007)(66066001)(2950100001)(92566001)(21056001)(19580395003)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0501MB1072; H:SN2PR0501MB1070.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FUQH-ZDrqXz1If3JS9ZK_PfRfZk Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 13:10:45 -0000 Hi, I have read the rev 05 of this draft. I think it is a technically sound sol= ution for a valid use case. I support it to be adopted by the WG. Thanks, /Yimin Shen Juniper Networks -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Sunday, December 21, 2014 10:59 AM To: mpls@ietf.org Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org Subject: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-= lsp-ping-lag-multipath as a working group document Working Group, This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group documen= t. 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 disclosures directly against this document. All the author= s has stated on the working group mailing that they are unaware of any undi= sclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends January 7, 2015. /Loa --=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 Dec 23 10:54: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 9C3741A1ABC for ; Tue, 23 Dec 2014 10:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g2iVYxGCroF for ; Tue, 23 Dec 2014 10:54:35 -0800 (PST) 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 3FDD01A1AB9 for ; Tue, 23 Dec 2014 10:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1711; q=dns/txt; s=iport; t=1419360875; x=1420570475; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e9M7hX2K/EvRAsx9ZtfbIc9VemjaeNnLBhXXCadZNtA=; b=CUqqa4aQfQFOugdFOTkuadc9Y+5v/2AwqAXsmuWm89ZK2GGsPE8LPGui EPZmZL0aVQpQMJCew7EJsFn1uf6utV5FGPKKi1VEldMTk8zusvJ/LyiXW Ics1NB2iW5bx1g54qM0pHc9Wl2JtRfON9vcJUKZKBcGeU9X9BuvbAPsYu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAGe5mVStJV2Z/2dsb2JhbABbgwaBKgTMMwKBGRYBAQEBAX2EDAEBAQRrAwsMAgICAQgRBAEBKAcbFxQJCAIEAQ0FiCzNaAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEjwwRAVAHBoQjAQSOFIhzgQ2CZYdNhg8ig25vgQw5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,633,1413244800"; d="scan'208";a="107950524" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 23 Dec 2014 18:54:32 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBNIsV2Z026510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Dec 2014 18:54:31 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.65]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 12:54:31 -0600 From: "Kamran Raza (skraza)" To: "Nobo Akiya (nobo)" , Loa Andersson , "mpls@ietf.org" Thread-Topic: Implementation poll on draft-ietf-mpls-oam-ipv6-rao Thread-Index: AQHQHZyZakbSR9THa0iEGQGwGsRCMZycAd4AgAGXaAA= Date: Tue, 23 Dec 2014 18:54:31 +0000 Message-ID: References: <5497989A.7020601@pi.nu> 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.4.140807 x-originating-ip: [10.86.244.163] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0A2AC887E6373E4894B1D67D8E0FF5BE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/b-f7qLneKVFmgfNBGMmQTCr9J3I Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] Implementation poll on draft-ietf-mpls-oam-ipv6-rao 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, 23 Dec 2014 18:54:36 -0000 +1 (to what Nobo already stated) =8B Kamran On 2014-12-22, 8:36 AM, "Nobo Akiya (nobo)" wrote: >Hi Loa, > >Cisco has implemented LSP Ping/Traceroute modifications to support LDP >IPv6, during which we found the lack of IPv6 RAO availability for MPLS >OAM. The plan is to update this implementation once >draft-ietf-mpls-oam-ipv6-rao progresses (which already has) and the code >point has been allocated (which has not been done). So the hooks are in >place, but the answer is not a complete "yes". However, due to the nature >of this document (i.e., defines a code point but absolutely no >procedures), I hope that the document can still progress. > >Thanks! > >-Nobo > >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Sunday, December 21, 2014 11:06 PM >> To: mpls@ietf.org >> Cc: mpls-chairs@tools.ietf.org; >>draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org >> Subject: Implementation poll on draft-ietf-mpls-oam-ipv6-rao >>=20 >> Working Group, >>=20 >> We are preparing draft-ietf-mpls-oam-ipv6-rao for publication request. >> One of the questions we have to answer in the Shepherds Write-up is if >> there are any existing implementations. >>=20 >> This is to start an implementation poll on draft-ietf-mpls-oam-ipv6-rao. >> If you have an implementation or know about one, please send the >> information to the mpls wg mailing list or to the mpls wg chairs. >>=20 >> /Loa >> 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 From nobody Tue Dec 23 18:07: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 66B301A8834 for ; Tue, 23 Dec 2014 18:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHJ5faw8GDGP for ; Tue, 23 Dec 2014 18:07:00 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37A91A1B23 for ; Tue, 23 Dec 2014 18:06:59 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.191.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2AB7B1801590; Wed, 24 Dec 2014 03:06:54 +0100 (CET) Message-ID: <549A1FBA.5090101@pi.nu> Date: Wed, 24 Dec 2014 10:06:50 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk, draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, "mpls@ietf.org" , "" References: <93b3674a34519a14bcc636882d63e404.squirrel@spey.erg.abdn.ac.uk> In-Reply-To: <93b3674a34519a14bcc636882d63e404.squirrel@spey.erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/H9zDOBNlTGbP-t4mooDQOM-aAi4 Subject: Re: [mpls] [Fwd: Repeated WG last call on draft-ietf-mpls-in-udp] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 02:07:05 -0000 Gorry, Working Group, Authors, We have received the the comments below from Gorry - tnx! The document is in IETF Last Call, my suggestion (Shepherd cape on) is that these comments are addressed together with other LC comments. /Loa On 2014-12-23 23:15, gorry@erg.abdn.ac.uk wrote: > Forwarded: fixing typo in recipient address > > ---------------------------- Original Message ---------------------------- > Subject: Repeated WG last call on draft-ietf-mpls-in-udp > From: gorry@erg.abdn.ac.uk > Date: Tue, December 23, 2014 3:13 pm > To: draft-ietf-mpls-in-udp@tools.ietf.org' > mpls-chairs@tools.ietf.org > Cc: gorry@erg.abdn.ac.uk > bcc: "david black" > -------------------------------------------------------------------------- > > Hi all, > > MPLS Chairs:: I'm OK with forwarding this message to the mailing list - > normally I would have replied to the WGLC, but was somewhat overloaded > this last month. > > Best wishes, > > Gorry > > ==== > > Overall: > I have read the latest version of draft-ietf-mpls-in-udp. > > In many places the new text is much clearer, and seems to more clearly > express what should be done. It also much more clearly captures the scope > of deployment - which in my mind helps to justify the approach taken. > > I think with minor corrections this is ready to proceed. > > Comments follow: > > Abstract: > - The deployment scenario for this protocol is very narrow, I think it is > important that this should appear in the abstract: > "The MPLS-in-UDP encapsulation technology must only be deployed within a > Service Provider (SP) network or networks of an adjacent set of > co-operating SPs where congestion control is not a concern, rather than > over the Internet where congestion control is required." > > S1.1: > - There is an entropy field in the IPv6 header (flow label) that can be > used for this purpose. RFC6438 describes this, and should be cited as an > existing mechanism for IPv6. > > S3: > - RFC5405 states "SHOULD" use a UDP checksum for IPv4, in that case, it > may be wise to simply provide a line or two to say why the current method > was chosen. > > S3.1: > Currently says: > /c. An MPLS-in-UDP receiver node SHOULD only allow the use of UDP > zero-checksum mode for IPv6 on a single UDP port regardless of sender. / > - but the UDP API defines port pairs, os this is confusing. I think it > would be clearer to state: > /c. An MPLS-in-UDP receiver node SHOULD only allow the use of UDP > zero-checksum mode for IPv6 on a single received UDP Destination Port > regardless of the sender. / > > S5: > Currently says: > / For this reason, where MPLS-in-UDP tunneling is used to carry IP traffic > that is known to be congestion controlled, the UDP tunnels MAY be used > across any combination of a single service provider, multiple cooperating > service providers, or across the general > Internet. / > - I disagree with this (without commenting on whether the argument holds > for the general Internet). My main point of disagreement is that this sets > a different applicability statement to that of section 1.3. If the > statement here were to read as below, I would have no issue (if this > directly followed 1.3): > / For this reason, where MPLS-in-UDP tunneling is used to carry IP traffic > that is known to be congestion controlled, the UDP tunnels MAY be used > within > a Service Provider (SP) network or networks of an adjacent set of > co-operating SPs. / > - If a different scope is intended this would need careful consideration. > > S5: > Currently says: > > / b. Deployment of packet filters that block the UDP ports assigned for > MPLS-over-UDP. > / > - I agree, but I think actually it is wiser to state: > / b. Deployment of packet filters that block the UDP Destination Ports > used for MPLS-over-UDP. > / > > S6: > Discusses issues with IPsec, but I think could usefully point back at > RFC6438 as an alternative that could be used. > > -- end -- > > > > > -- 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 Dec 24 00:10: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 4291C1ACD65 for ; Wed, 24 Dec 2014 00:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5DpNQuBdSc9 for ; Wed, 24 Dec 2014 00:09:51 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 06CD61ACD7E for ; Wed, 24 Dec 2014 00:09:50 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 33) id 008BC2B44B2; Wed, 24 Dec 2014 08:09:48 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by spey.erg.abdn.ac.uk with HTTP; Wed, 24 Dec 2014 08:09:48 -0000 Message-ID: In-Reply-To: <549A1FBA.5090101@pi.nu> References: <93b3674a34519a14bcc636882d63e404.squirrel@spey.erg.abdn.ac.uk> <549A1FBA.5090101@pi.nu> Date: Wed, 24 Dec 2014 08:09:48 -0000 From: gorry@erg.abdn.ac.uk To: "Loa Andersson" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4JObjyxLK_kBpUKIQnNYwos-p_E Cc: gorry@erg.abdn.ac.uk, draft-ietf-mpls-in-udp@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls-ads@tools.ietf.org, "mpls@ietf.org" Subject: Re: [mpls] [Fwd: Repeated WG last call on draft-ietf-mpls-in-udp] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 08:09:55 -0000 Thanks - look forward to seeing a reply or revised version then. Gorry > Gorry, Working Group, Authors, > > We have received the the comments below from Gorry - tnx! > > The document is in IETF Last Call, my suggestion (Shepherd cape on) is > that these comments are addressed together with other LC comments. > > /Loa > > On 2014-12-23 23:15, gorry@erg.abdn.ac.uk wrote: >> Forwarded: fixing typo in recipient address >> >> ---------------------------- Original Message >> ---------------------------- >> Subject: Repeated WG last call on draft-ietf-mpls-in-udp >> From: gorry@erg.abdn.ac.uk >> Date: Tue, December 23, 2014 3:13 pm >> To: draft-ietf-mpls-in-udp@tools.ietf.org' >> mpls-chairs@tools.ietf.org >> Cc: gorry@erg.abdn.ac.uk >> bcc: "david black" >> -------------------------------------------------------------------------- >> >> Hi all, >> >> MPLS Chairs:: I'm OK with forwarding this message to the mailing list - >> normally I would have replied to the WGLC, but was somewhat overloaded >> this last month. >> >> Best wishes, >> >> Gorry >> >> ==== >> >> Overall: >> I have read the latest version of draft-ietf-mpls-in-udp. >> >> In many places the new text is much clearer, and seems to more clearly >> express what should be done. It also much more clearly captures the >> scope >> of deployment - which in my mind helps to justify the approach taken. >> >> I think with minor corrections this is ready to proceed. >> >> Comments follow: >> >> Abstract: >> - The deployment scenario for this protocol is very narrow, I think it >> is >> important that this should appear in the abstract: >> "The MPLS-in-UDP encapsulation technology must only be deployed within a >> Service Provider (SP) network or networks of an adjacent set of >> co-operating SPs where congestion control is not a concern, rather than >> over the Internet where congestion control is required." >> >> S1.1: >> - There is an entropy field in the IPv6 header (flow label) that can be >> used for this purpose. RFC6438 describes this, and should be cited as an >> existing mechanism for IPv6. >> >> S3: >> - RFC5405 states "SHOULD" use a UDP checksum for IPv4, in that case, it >> may be wise to simply provide a line or two to say why the current >> method >> was chosen. >> >> S3.1: >> Currently says: >> /c. An MPLS-in-UDP receiver node SHOULD only allow the use of UDP >> zero-checksum mode for IPv6 on a single UDP port regardless of sender. / >> - but the UDP API defines port pairs, os this is confusing. I think it >> would be clearer to state: >> /c. An MPLS-in-UDP receiver node SHOULD only allow the use of UDP >> zero-checksum mode for IPv6 on a single received UDP Destination Port >> regardless of the sender. / >> >> S5: >> Currently says: >> / For this reason, where MPLS-in-UDP tunneling is used to carry IP >> traffic >> that is known to be congestion controlled, the UDP tunnels MAY be used >> across any combination of a single service provider, multiple >> cooperating >> service providers, or across the general >> Internet. / >> - I disagree with this (without commenting on whether the argument holds >> for the general Internet). My main point of disagreement is that this >> sets >> a different applicability statement to that of section 1.3. If the >> statement here were to read as below, I would have no issue (if this >> directly followed 1.3): >> / For this reason, where MPLS-in-UDP tunneling is used to carry IP >> traffic >> that is known to be congestion controlled, the UDP tunnels MAY be used >> within >> a Service Provider (SP) network or networks of an adjacent set of >> co-operating SPs. / >> - If a different scope is intended this would need careful >> consideration. >> >> S5: >> Currently says: >> >> / b. Deployment of packet filters that block the UDP ports assigned >> for >> MPLS-over-UDP. >> / >> - I agree, but I think actually it is wiser to state: >> / b. Deployment of packet filters that block the UDP Destination >> Ports >> used for MPLS-over-UDP. >> / >> >> S6: >> Discusses issues with IPsec, but I think could usefully point back at >> RFC6438 as an alternative that could be used. >> >> -- end -- >> >> >> >> >> > > -- > > > 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 Dec 24 06:02: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 A71731A0395 for ; Wed, 24 Dec 2014 06:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiNjT24Gvu_W for ; Wed, 24 Dec 2014 06:02:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2482F1A8A66 for ; Wed, 24 Dec 2014 06:02:37 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 556DA26419B; Wed, 24 Dec 2014 15:02:35 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3823035C061; Wed, 24 Dec 2014 15:02:35 +0100 (CET) Received: from OPEXCLILM33.corporate.adroot.infra.ftgroup ([169.254.3.53]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 24 Dec 2014 15:02:35 +0100 From: To: "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Thread-Index: AQHQHTceuMGFZsZdOkWNx1uJizeftpyeyCkA Date: Wed, 24 Dec 2014 14:02:34 +0000 Message-ID: <30799_1419429755_549AC77B_30799_10658_1_95B8C2085563754CA854528418622B3D5F4876DA@OPEXCLILM33.corporate.adroot.infra.ftgroup> References: <5496EE53.6090009@pi.nu> In-Reply-To: <5496EE53.6090009@pi.nu> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/I7G4romoiuRCU_R3xufDQOj05qk Cc: "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 14:02:40 -0000 Hi, I have read the draft and support it, this is something very valuable to ha= ve. LAG is deployed on the network! Many thanks for your work! /Youssef El Fathi Orange -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Sunday, December 21, 2014 16:59 To: mpls@ietf.org Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org Subject: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-= lsp-ping-lag-multipath as a working group document Working Group, This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group documen= t. 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 disclosures directly against this document. All the author= s has stated on the working group mailing that they are unaware of any undi= sclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends January 7, 2015. /Loa --=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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Sun Dec 28 07:04: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 E3DD31AD49E for ; Sun, 28 Dec 2014 07:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtJ044t9ssaU for ; Sun, 28 Dec 2014 07:03:55 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5618A1AD49A for ; Sun, 28 Dec 2014 07:03:55 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBSF3qC3000778; Sun, 28 Dec 2014 15:03:52 GMT Received: from 950129200 (089144216030.atnat0025.highway.a1.net [89.144.216.30]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBSF3oGx000772 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2014 15:03:51 GMT From: "Adrian Farrel" To: "'Sam Aldrin'" References: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> <364122F3-AD7C-4112-8C66-14CF969E1079@gmail.com> In-Reply-To: Date: Sun, 28 Dec 2014 15:03:52 -0000 Message-ID: <013f01d022af$7fe6d5c0$7fb48140$@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: AQF/pdyeP66Oj6m75MIWld08Pg9XHgGBADhynMxWKmCAbbN6sA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21208.000 X-TM-AS-Result: No--28.993-10.0-31-10 X-imss-scan-details: No--28.993-10.0-31-10 X-TMASE-MatchedRID: B0+RG8xpjtQR9y8WJPyXEARH1Nr7oERdYQXxsZnRwoK638ZUY6gSd0fT bYOVmH5hP7FMkdJAvcWVvrZECjivP8MghOBF/IjDSEQN/D/3cG6jwKJ7KyNcsBxUkJPe1WBqS20 1H/juErwxcSfgz4Zxa/FPDHhQkgxyxKyJxTtOG82VUcz8XpiS9H4yToAKzDgmELmxs+COG+BZHT +k2bSlgg7Fh6BDZ9ioFlJ4sYlbz1oXxDT5fLk+OhJo06V2lHTe1wL0WtLXyRqH9PPDfpM6JTPqf jabMGZqvNRgKxmpoNZPEDRwTI4UCVggjL+VpskxD/kvWlRHe/bgUGEwBpeNTLv408/GP5Hq02TS vqRko5BO712NxKQ6LGf2QdIZiKbcveAuzzZGHSqcgbKevk5shiFq4bKNOR/1grAXgr/AjP3kGht p+k1ZM+/dZmuh5TNQK+5FmIUWylRvcVEEeBXWYN3g9aqN5Jaa+LidURF+DB1b6PBUqmq+UiC/o9 NHMVFaKblw5AV0O1m3vaAK3P1mVmdFG6nTUK7LlTsGW3DmpUtCs7hdHoFFA6mp2lu7TDs6Oh6S9 a07un4KUF1Ascej2f2MRbBEoEvRHGB7BpLrj6XuHEdX1jmsoK9EfrNTdfJm9QRYGtaJGWFnmFse ZUOtSAZlBbstE/UBpA3/Rh+Xwym7s/MxguVxBxkLyT/Tdtjl0wHvRbIG2MflVq8GsBXjBeu8ykI iv8CsRZQAoZysUSvF+fjFK01nut2webIjp6kSl1zsjZ1/6awpWss5kPUFdCBzIZ6+1+0no8WMkQ Wv6iV95l0nVeyiuEIhOWyY9/MAC24oEZ6SpSk+Mqg+CyrtwA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/s3nDHno2CqrbEJCT-6EzcGcdUCA Cc: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org, 'mpls' Subject: Re: [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, 28 Dec 2014 15:03:59 -0000 Hello Sam, authors, all, Did I miss some update of this document? It's now 133 days since I first did my review, and the changes requested were not huge. I know we all run out of energy towards the end of publication process, but if there is no-one in the WG concerned to take this the final few steps, then perhaps the WG doesn't need to request publication. Thanks, Adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 19 October 2014 21:31 > To: 'Sam Aldrin' > Cc: 'draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org'; 'mpls' > Subject: RE: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping > > Hi Sam, > > > >> Do you really need the pre-RFC5378 disclaimer? > > As this updates or add to RFC4379, we need that. Would you agree? > > No, not really. > You can included it if you believe you are reproducing text that does not have a > transfer of copyright and for which it is hard to get the authors to confirm > copyright transfer. But the act of updating is not, itself, a reason to include the > disclaimer. > > > >> Section 2 would be enhanced by a figure. > [snip] > > %sam - We deliberated on this and feel it will add more confusion than helping > > the reader to understand. Also, it may necessitates lot of changes to the text to > > reflect the use of R1, R2 etc. > > Would you be ok if we don't add this ASCII art and keep it simple? > > I won't object more than to say "I thought it would help". > > > >> It seems that proxy ping messages would be relatively easy to spoof. > > >> This, combined with the fact that the receipt of a proxy ping causes > > >> the proxy to retain state and to issue echo requests to the network > > >> looks like two DoS vectors for the price of one. > > >> > > >> So, I think you need: > > >> - discussion of authentication for proxy requests > > >> - recommendation to rate limit receipt of proxy requests > > >> - recommendation to discard "duplicate" proxy requests > > >> > > %sam - Proxy do NOT maintain any state. Hence, not sure why the above apply > > to proxy and not regular Echo requests. When proxy echo request is, it > > (proxy LSR) merely issues a request and no state is maintained on it. > > For ex: it has no way to discard duplicate requests, because is doesn't maintain > > any state for the requests. > > I read in 3.2 (the description of processing at a Proxy) > > The header fields Sender's Handle and Sequence Number are not > examined, but are saved to be included in the MPLS proxy ping reply > or MPLS Echo Request messages. > > Maybe that "saving" is ambiguous? Maybe this is an implementation specific note > for the message that is being built, and is not actually "state". If so, I think you > should strike "saved to be", s/messages/message/ and add "...if one is sent as a > direct result of the received message." > > Anyhow, the fact that a branch node will make copies of a ping to send > downstream *is* a vector. > > > >> I'm not quite sure about the initiator being allowed to instruct the > > >> proxy about which source port it must use in an echo request. > > >> > > >> (Incidentally, Section 3.2 doesn't restate that this has to happen > > >> although 3.2.4.1 does restate it). > > >> > > >> What happens if the proxy request asks for a reserved port number to be > > >> used? What if the port is already in use by the proxy for something > > >> else? Why does it matter which source port the proxy uses? Why does the > > >> proxy need to be able to control that? Why can't the proxy select its > > >> own source port? > > %sam - I think there is some confusion here. The source port number is not to > > request Proxy to use, rather to issue a request, so that the replying router > > could send the reply back to the initiator at the right port. > > proxy echo request does not specify what port Proxy has to use. > > Section 3.1 is about how to handle a received Proxy message > > The Reply mode and Global Flags of the Proxy Echo Parameters TLV are > set to the values to be used in the MPLS Echo Request message header. > The Source UDP Port is set to the value to be used in the MPLS Echo > Request packet. The TTL is set to the value to be used in the > outgoing MPLS label stack. See Section 5.1 for further details. > > 3.2.4.1 is describing how to build an echo request from a proxy request. > > The message is then encapsulated in a UDP packet. The source UDP > port is copied from the Proxy Echo Parameters TLV. The destination > port copied from the proxy ping request message. > > And to be clear section 5.1 describes the Proxy Echo Parameters TLV > > The Proxy Echo Parameters TLV is a TLV that MUST be included in an > MPLS proxy ping request message. > > I didn't go back and search the rest of the document. > > If you do not intend that the proxy message can control the ports used in the > echo request, I think you have some text to fix. But surely this text is clear and > reflects the intention of the WG, in which case my questions hold. > > Cheers, > Adrian From nobody Sun Dec 28 11:59: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 98B391A907C for ; Sun, 28 Dec 2014 11:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIlvGfwlM_pC for ; Sun, 28 Dec 2014 11:59:09 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FDA71A9078 for ; Sun, 28 Dec 2014 11:59:09 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id y13so15879636pdi.17 for ; Sun, 28 Dec 2014 11:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GCVUjTety/aYy4fvkTCHHbrNmcKXssUmiZLKiALEdr4=; b=p+/Dzzcw+PmZ0m2N3Vbo1odjjxLHRn5qH5+AKwrYOgY9azdbWnkQn/wUXqgbbCjNRR +rv8wkOpL/hVpDJ0VZR8GVis1IRi3bxW1hFKWwo+PE9lQy1x9nKsYLmcPagLWG7EdRZ6 rwsieilOnOXJ02A2R76Z8fpdYwO8jILVa3hgbT9OLZEMT8X8tP48OE8L+6LK4AR5z2dy FRJytEPd+Mbs6vSzsbvyl7BWFWzTxtxPWDVBBh0R7LdrlAeyk/m2pqhl5O0JjPalD3Lh RlbUh3BjEbFkAltzPPBRjYk9zQlDkUryduZWPuWQpG1phk3DLgBC6pl5frNpRj1tDzlb wsOA== X-Received: by 10.70.8.197 with SMTP id t5mr26908791pda.84.1419796748810; Sun, 28 Dec 2014 11:59:08 -0800 (PST) Received: from ?IPv6:2002:6b03:9a3c:e472:5989:fa35:e4f3:ee08? ([2002:6b03:9a3c:e472:5989:fa35:e4f3:ee08]) by mx.google.com with ESMTPSA id fu1sm33538431pbb.91.2014.12.28.11.59.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Dec 2014 11:59:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Sam Aldrin In-Reply-To: <013f01d022af$7fe6d5c0$7fb48140$@olddog.co.uk> Date: Sun, 28 Dec 2014 11:59:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <041f01cfe64c$51eb1ea0$f5c15be0$@olddog.co.uk> <364122F3-AD7C-4112-8C66-14CF969E1079@gmail.com> <013f01d022af$7fe6d5c0$7fb48140$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KQHuYyRKZBFd7yvhG6t13-dJTKg Cc: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org, mpls Subject: Re: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 19:59:11 -0000 Hi Adrian, I am sorry for not publishing a new version. I will do it at the earliest. Sorry again for the delay. -sam > On Dec 28, 2014, at 7:03 AM, Adrian Farrel = wrote: >=20 > Hello Sam, authors, all, >=20 > Did I miss some update of this document? > It's now 133 days since I first did my review, and the changes = requested were > not huge. >=20 > I know we all run out of energy towards the end of publication = process, but if > there is no-one in the WG concerned to take this the final few steps, = then > perhaps the WG doesn't need to request publication. >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: 19 October 2014 21:31 >> To: 'Sam Aldrin' >> Cc: 'draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org'; 'mpls' >> Subject: RE: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping >>=20 >> Hi Sam, >>=20 >>>>> Do you really need the pre-RFC5378 disclaimer? >>> As this updates or add to RFC4379, we need that. Would you agree? >>=20 >> No, not really. >> You can included it if you believe you are reproducing text that does = not have > a >> transfer of copyright and for which it is hard to get the authors to = confirm >> copyright transfer. But the act of updating is not, itself, a reason = to > include the >> disclaimer. >>=20 >>>>> Section 2 would be enhanced by a figure. >> [snip] >>> %sam - We deliberated on this and feel it will add more confusion = than > helping >>> the reader to understand. Also, it may necessitates lot of changes = to the > text to >>> reflect the use of R1, R2 etc. >>> Would you be ok if we don't add this ASCII art and keep it simple? >>=20 >> I won't object more than to say "I thought it would help". >>=20 >>>>> It seems that proxy ping messages would be relatively easy to = spoof. >>>>> This, combined with the fact that the receipt of a proxy ping = causes >>>>> the proxy to retain state and to issue echo requests to the = network >>>>> looks like two DoS vectors for the price of one. >>>>>=20 >>>>> So, I think you need: >>>>> - discussion of authentication for proxy requests >>>>> - recommendation to rate limit receipt of proxy requests >>>>> - recommendation to discard "duplicate" proxy requests >>>>>=20 >>> %sam - Proxy do NOT maintain any state. Hence, not sure why the = above apply >>> to proxy and not regular Echo requests. When proxy echo request is, = it=20 >>> (proxy LSR) merely issues a request and no state is maintained on = it. >>> For ex: it has no way to discard duplicate requests, because is = doesn't > maintain >>> any state for the requests. >>=20 >> I read in 3.2 (the description of processing at a Proxy) >>=20 >> The header fields Sender's Handle and Sequence Number are not >> examined, but are saved to be included in the MPLS proxy ping reply >> or MPLS Echo Request messages. >>=20 >> Maybe that "saving" is ambiguous? Maybe this is an implementation = specific > note >> for the message that is being built, and is not actually "state". If = so, I > think you >> should strike "saved to be", s/messages/message/ and add "...if one = is sent as > a >> direct result of the received message." >>=20 >> Anyhow, the fact that a branch node will make copies of a ping to = send >> downstream *is* a vector. >>=20 >>>>> I'm not quite sure about the initiator being allowed to instruct = the >>>>> proxy about which source port it must use in an echo request. >>>>>=20 >>>>> (Incidentally, Section 3.2 doesn't restate that this has to happen >>>>> although 3.2.4.1 does restate it). >>>>>=20 >>>>> What happens if the proxy request asks for a reserved port number = to be >>>>> used? What if the port is already in use by the proxy for = something >>>>> else? Why does it matter which source port the proxy uses? Why = does the >>>>> proxy need to be able to control that? Why can't the proxy select = its >>>>> own source port? >>> %sam - I think there is some confusion here. The source port number = is not > to >>> request Proxy to use, rather to issue a request, so that the = replying router >>> could send the reply back to the initiator at the right port. >>> proxy echo request does not specify what port Proxy has to use. >>=20 >> Section 3.1 is about how to handle a received Proxy message >>=20 >> The Reply mode and Global Flags of the Proxy Echo Parameters TLV = are >> set to the values to be used in the MPLS Echo Request message = header. >> The Source UDP Port is set to the value to be used in the MPLS Echo >> Request packet. The TTL is set to the value to be used in the >> outgoing MPLS label stack. See Section 5.1 for further details. >>=20 >> 3.2.4.1 is describing how to build an echo request from a proxy = request. >>=20 >> The message is then encapsulated in a UDP packet. The source UDP >> port is copied from the Proxy Echo Parameters TLV. The destination >> port copied from the proxy ping request message. >>=20 >> And to be clear section 5.1 describes the Proxy Echo Parameters TLV >>=20 >> The Proxy Echo Parameters TLV is a TLV that MUST be included in an >> MPLS proxy ping request message. >>=20 >> I didn't go back and search the rest of the document. >>=20 >> If you do not intend that the proxy message can control the ports = used in the >> echo request, I think you have some text to fix. But surely this text = is clear > and >> reflects the intention of the WG, in which case my questions hold. >>=20 >> Cheers, >> Adrian >=20 From nobody Sun Dec 28 16:47: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 60DFE1AC3C5 for ; Sun, 28 Dec 2014 16:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdV7-MQiyZGX for ; Sun, 28 Dec 2014 16:47:03 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5485E1AC3C0 for ; Sun, 28 Dec 2014 16:47:03 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-92-54a05330926f Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 02.D6.03307.03350A45; Sun, 28 Dec 2014 20:00:00 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Sun, 28 Dec 2014 19:47:00 -0500 From: Gregory Mirsky To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Thread-Index: AQHQHTcenjcMzMgQZ0yvfaZH5Clod5ylx0XA Date: Mon, 29 Dec 2014 00:46:59 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8C8905@eusaamb103.ericsson.se> References: <5496EE53.6090009@pi.nu> In-Reply-To: <5496EE53.6090009@pi.nu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPuK5B8IIQg/PzJC2urdrBZvFv7hxm i1tLV7I6MHssWfKTyWPW9DY2jy+XP7MFMEdx2aSk5mSWpRbp2yVwZVxZ+IKpYCdPxYGLgQ2M 3zi7GDk5JARMJHY/OcQGYYtJXLi3Hsjm4hASOMIosX/mCxYIZzmjxNG2ZawgVWwCRhIvNvaw g9giAnYSG1/9YwQpYhaYxSjxYf5ydhBHWKCZUaJ3dgdYRkSghVHi0I+VrBAtRhKvZp9hBrFZ BFQlbi0/C2bzCvhKXGpewQRiCwmoSLz+d4UFxOYEqrm0+TPYOkagA7+fWgNWwywgLnHryXwm iMMFJJbsOc8MYYtKvHz8jxXCVpL4+Hs+O0S9jsSC3Z/YIGxtiWULX0PtFZQ4OfMJywRGsVlI xs5C0jILScssJC0LGFlWMXKUFqeW5aYbGWxiBMbPMQk23R2Me15aHmIU4GBU4uEtWDU/RIg1 say4MvcQozQHi5I476zaecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGCPcLnEvZn5+X7z3 15INf2WnTdrv3yp97auq3cwmrSO979ZX8XPnXpCdeS/eNavlRy9bdMIrVbV9cxyFd7LIq8x+ XscQcehP3NxpV6/N7bXP3/j3T+cTneOPFkxsPSA1O/DCZ6Vggysy64RLeYJ3eu3uK+/8ZL/3 ScPFnE9HThvlGyb9v3B/zXslluKMREMt5qLiRABnVuLIgAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3LW6LLfd81gTlhInBwQQfgli6JY Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 00:47:05 -0000 Dear All, I've read the document and support its adoption by the MPLS WG. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Sunday, December 21, 2014 7:59 AM To: mpls@ietf.org Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org Subject: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-= lsp-ping-lag-multipath as a working group document Working Group, This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-lag-multipath-05 as an MPLS working group documen= t. 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 disclosures directly against this document. All the author= s has stated on the working group mailing that they are unaware of any undi= sclosed IPRs against this document. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends January 7, 2015. /Loa --=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 Mon Dec 29 13:36: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 9B0541ACD6B for ; Mon, 29 Dec 2014 13:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dktKtjsSnr4r for ; Mon, 29 Dec 2014 13:36:51 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31531ACD65 for ; Mon, 29 Dec 2014 13:36:48 -0800 (PST) Received: from [216.82.242.131] by server-6.bemta-8.messagelabs.com id EB/E7-13960-F69C1A45; Mon, 29 Dec 2014 21:36:47 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-12.tower-76.messagelabs.com!1419889004!37185334!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30442 invoked from network); 29 Dec 2014 21:36:45 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-12.tower-76.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Dec 2014 21:36:45 -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.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id B0EFF2AC77; Mon, 29 Dec 2014 21:36:44 +0000 (GMT) Received: from USADCWVEHT02.corp.global.level3.com (10.2.36.142) by USIDCWVEHT02.corp.global.level3.com (10.1.142.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Dec 2014 14:36:44 -0700 Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by usadcwveht02.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Mon, 29 Dec 2014 16:36:43 -0500 From: "Osborne, Eric" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document Thread-Index: AQHQHTcc47PWMIIrRUOq0AeirR7sMJynJIpg Date: Mon, 29 Dec 2014 21:36:42 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD01AE9BBD@USIDCWVEMBX03.corp.global.level3.com> References: <5496EE53.6090009@pi.nu> In-Reply-To: <5496EE53.6090009@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.207] 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/ze3VgWiJu2dPI0-7fYw5nR4Lie0 Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpls-lsp-ping-lag-multipath as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 21:36:52 -0000 Support, like everyone else and for the same reasons. eric > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Sunday, December 21, 2014 10:59 AM > To: mpls@ietf.org > Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-lag-multipath@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus to adopt draft-akiya-mpl= s-lsp- > ping-lag-multipath as a working group document >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-akiya-mpls-lsp-ping-lag-multipath-05 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 disclosures directly against this document. All the > authors has stated on the working group mailing that they are unaware of > any undisclosed IPRs against this document. >=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 January 7, 2015. >=20 > /Loa > -- >=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